DPL "Oberes Leistungslimit" editierbar per Skript?

[peff74]

Nabend,
ich habe jetzt im Winter meinen "Bastelakku" am System um zu testen, wie das mit der Heizung klappt etc.
Diese ist nur S8P12 mit nicht mehr allzu fitten Zellen, daher will ich ihn nicht arg belasten.
So kam mir der Gedanke, dass wenn das System nur mit Akku läuft, gerne das "Oberes Leistungslimit" anpassen zu wollen. Einen MQTT Wert habe ich nicht gefunden, übersehen?

Was mir in dem Zusammenhang auch mal wieder ins Gesicht gefallen ist, ist die "Anzahl der Konfigurationsspeicherungen" wofür die dieser Counter eigentlich?

Grüsse in die Runde
Peff

[peff74]

Habe heute Morgen ein wenig gespielt und bin auf die API gestossen.
Versuche mit Postman und curl schlugen aber immer mit der folgen Meldung fehl:
"type": "warning",
"message": "No values found!"

Versucht hatte ich es z.B. hiermit:
curl -u "admin:password" http://IP/api/powerlimiter/config -d 'data={"enabled":true,"verbose_logging":true,"solar_passthrough_enabled":true,"solar_passthrough_losses":3,"battery_drain_strategy":0,"is_inverter_behind_powermeter":true,"inverter_id":0,"inverter_channel_id":0,"target_power_consumption":0,"target_power_consumption_hysteresis":10,"lower_power_limit":30,"upper_power_limit":111,"battery_soc_start_threshold":80,"battery_soc_stop_threshold":20,"voltage_start_threshold":45.2,"voltage_stop_threshold":38.5,"voltage_load_correction_factor":0.001,"inverter_restart_hour":0,"full_solar_passthrough_soc":100,"full_solar_passthrough_start_voltage":100,"full_solar_passthrough_stop_voltage":100}'

Auch das Beispiel aus dem Wiki mit dem NTP schlägt fehl.
curl -u "admin:password" http://IP/api/ntp/config -d 'data={"ntp_server":"my.own.ntp.server.home","ntp_timezone":"CET-1CEST,M3.5.0,M10.5.0/3","ntp_timezone_descr":"Europe/Berlin"}'

{ "type": "warning", "message": "No values found!", "code": 1002 }

[schlimmchen]

Wenn du das versuchen willst, dann musst du alle Einstellungen übermitteln. Den Fehler erhälst du, wenn schon nur eine Einstellung nicht übertragen wird.

Das Ändern dieser Einstellung über MQTT wird nicht unterstützt.

[peff74]

O.K.
bleiben wir beim NTP Beispiel, damit ich's vielleicht verstehe.
Wenn ich mir das anschaue, wenn ich die Werte über den Webbrowser schicke:

Dann müsste dies ja funktionieren, da alle Daten drin sind.
curl -u "admin:PW" http://IP/api/ntp/config -d 'data={"ntp_server":"pool.ntp.org","ntp_timezone":"CET-1CEST,M3.5.0,M10.5.0/3","ntp_timezone_descr":"Europe/Berlin","longitude":10.45149994,"latitude":49.16569902,"sunsettype":1}'

Will aber leider net :-(

[peff74]

Das Problem sind die ' es müssen " am DatenString sein.
Brettvordenkopfschlag

curl -u "admin:PW" http://IP/api/ntp/config -d "data={"ntp_server":"pool.ntp.org","ntp_timezone":"CET-1CEST,M3.5.0,M10.5.0/3","ntp_timezone_descr":"Europe/Berlin","longitude":10.45149994,"latitude":49.16569902,"sunsettype":1}"

[Napizaki]

Hallo zusammen,
ich würde ebenfalls gerne das obere Leistungslimit des DPL von extern (Home Assistant) schreiben. Das klappt auch alles soweit über die API.

Jetzt aber zu meiner Frage: ist es irgendwie schädlich für die Hardware (z. B. Flash-Speicher) dieses Limit häufig zu überschreiben?

[schlimmchen]

ist es irgendwie schädlich für die Hardware (z. B. Flash-Speicher)

Ja. Aber Zehntausend Schreibzyklen hast du in jedem Fall. Falls in irgendeiner Weise irgendein Wear-Leveling implementiert ist, und davon gehe ich aus, hast du sicherlich mindestens 100 Tausend. Bis dahin ist dein ESP32 obsolet 😉 Also mach dir darüber keine Gedanken.

Aber wenn das so viele Leute benutzen, dann wäre ein Override via MQTT durchaus sinnvoll. Das Problem ist aber, dass schon der Mode, den man per MQTT setzen kann, total versteckt und intransparent ist. Ein weiteres solches intransparentes Datum ist super schlecht. Es bräuchte dann schon irgendwie eine Kachel im Live View, wo der Zustand dieser Parameter ersichtlich wird. Meiner Meinung nach.

[Napizaki]

OK, danke für die schnelle Antwort.
Mein vorhaben wäre folgendes: Ich möchte das Limit dynamisch anpassen, damit nie mehr als 600W über die am HM (1600W) angeschlossene Phase über den Zähler ins Netz eingespeist wird. Wenn jetzt, als Beispiel, meine Waschmaschine an der gleichen Phase hängt wie der HM, dann kann er das Limit hoch setzen (z. B. 1200W) - es gibt natürlich ein Max-Wert, damit die elektrische Anlage sicher ist und nicht überlastet wird. Es wird also ständig das "Obere Limit" neu berechnet, um so viel Leistung selbst zu verbrauchen, aber nie mehr als 600W ins Netz eingespeist wird. Das würde aber bedeuten, dass es sehr schnell viele Schreibzyklen werden.
Was natürlich noch besser wäre: OpenDTU-onBattery unterstützt dieses Feature von sich aus ;-)

[spcqike]

Welchen Hintergrund hat diese Logik? 600W ins Netz (also export ins Grid) und > 600W im Haus?

Hoymiles sind keine Inselwechselrichter. Eine legale 600W Anlage wird er mit dieser Logik dennoch nicht.

[Napizaki]

Man könnte es auch zum Laden des E-Autos benutzen - in diesem Fall in der Garage, wo auch die PV-Anlage untergebracht ist. Ist das E-Auto angesteckt und lädt, dann wird das Limit automatisch hoch gesetzt. Ja, ich gebe zu, dass es vermutlich nicht ganz legal wäre - aber die Smart-Meter würden es nicht merken. Das Powerlimit über das UI höher zu setzen als 600W ist auch nicht legal - man kann es aber trotzdem machen.
Ein anderer Anwendungsfall, das Limit per MQTT zu setzten wäre z. B. an Tagen mit schlechtem Wetter. Kommt wenig von der PV kann man das Limit verringern, um zum Beispiel bei Lasten, die Takten (wie z. B. Induktionskochfeld oder Wärmedecke) nicht unnötig viel Strom einzuspeisen.

[Squint5471]

Würde das auch gerne dynamisch nach Wetter und/oder Verbrauchern anpassen können :) aktuell ist das also nur über die API möglich, wo immer alle Parameter gesendet werden müssen?

[schlimmchen]

Korrekt. Die Idee ist, dass du den Satz Einstellungen abholst als JSON, diese JSON parst, die gewünschte Einstellung änderst, und die geänderte JSON dann wieder als Einstellung abschickst.

Das wird aber einfacher werden mit der Implementierung von #724, dann geht das auch über MQTT.