Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Power Limit fail-safe #728

Open
mpolak77 opened this issue Mar 2, 2023 · 10 comments
Open

Feature Request: Power Limit fail-safe #728

mpolak77 opened this issue Mar 2, 2023 · 10 comments
Assignees
Labels
enhancement New feature or request

Comments

@mpolak77
Copy link

mpolak77 commented Mar 2, 2023

Es wäre gut, wenn die Power Limit Funktion ein "fail-safe" hat, welches den/die Inverter auf einen vorkonfigurierbaren Power-Wert setzt wenn Updates über MQTT/Rest für einen einstellbaren Zeitraum ausgeblieben sind (zB. weil das kontrollierende Programm gecrashed ist, oder es Netzwerkproblem gibt).

Hintergrund
Ich betreibe eine Einspeiselimitierung mit einer ahoy-dtu, die von einem Shelly 3em mit Tasmota mit Scriptinginterface über REST-API angesteuert wird (limit_nonpersistent_absolute) ... und leider ist der WLAN Router etwas Buggy und manchmal geht die Verbindung zwischen Shelly und Ahoy flöten

@tqma1
Copy link

tqma1 commented Mar 2, 2023

Nur mal frei gedacht:
Persistentes Limit setzen und mit nonpersistant übersteuern.
Würde doch meiner Logik nach das Problem lösen - oder ?

@mpolak77
Copy link
Author

mpolak77 commented Mar 2, 2023

Ich war/bin der Meinung, dass "persistence" nur damit zu tun hat, ob der Limit-Wert die "Nacht" bzw. den Inverter-Restart überlebt oder nicht.
D.h. das würde nur funktionieren, wenn der Inverter bei Netzwerkfehlern neu starten würde. In meinem Fall fallen leider nur bestimmte Netzwerkteilnehmer aus .... also kann man das wirklich nur erkennen, wenn die API calls bzw MQTT messages aus bleiben

@tqma1
Copy link

tqma1 commented Mar 2, 2023

Das bedeutet der Wechselrichter benötigt das nonpersistant Limit nicht zyklisch?
Kenne das eben von sehr sensiblen Systemen so, das eine Übersteuerung in einem gewissen Zyklus immer wieder neu gesendet werden muss ansonsten geht es zurück auf den Standard-Wert (persistent)
=> somit unterstütze ich dieses Enhancement

@mpolak77
Copy link
Author

mpolak77 commented Mar 2, 2023 via email

@lumapu
Copy link
Owner

lumapu commented Mar 5, 2023

verstehe eure Idee, kann man bestimmt integrieren. Welche Größenordnung denkt ihr braucht das timeout ca.?
60s bis 60min?

@tqma1
Copy link

tqma1 commented Mar 5, 2023

Gegenfrage: wie oft kann der Netzbetreiber tatsächlich auslesen und somit feststellen das mehr eingespeist wird als zulässig?
Somit wäre ich irgendwo zwischen 60 Sekunden und max. 15 Minuten (15 Minuten Werte stellt ja auch der Netzbetreiber auf Anforderung zur Verfügung)

@mpolak77
Copy link
Author

mpolak77 commented Mar 5, 2023

Denke auch, dass eher in der 15min Range sinnvoll ist. Man könnte es auch als Vielfaches der Kommunikationszeit mit dem Inverter definieren?

@KG3RK3N
Copy link
Contributor

KG3RK3N commented Mar 5, 2023

Ich denke es macht Sinn das dann auch in den Einstellungen zu ergänzen damit es auf die eigenen Bedürfnisse angepasst werden kann.

@lumapu
Copy link
Owner

lumapu commented Mar 6, 2023

ja genau in den Einstellungen soll man das timeout konfigurieren können, nur der Wertebereich war unklar

@lumapu lumapu self-assigned this Mar 10, 2023
@lumapu lumapu added the enhancement New feature or request label Mar 10, 2023
@stefan123t
Copy link
Collaborator

@lumapu das ist nach wie vor ein interessantes Feature, wurde auch bei OpenDTU so ähnlich schon nachgefragt:
tbnobody/OpenDTU#2195 bzw. tbnobody/OpenDTU#2325

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants