[Bug] MQTT topic ahoydtu/ctrl/power/0 doesn't react on updates - just on changes

[BerziOnline]

Platform

ESP32

Assembly

the DTU was already assembled

nRF24L01+ Module

nRF24L01+ plus

Antenna

external antenna

Power Stabilization

Elko (~100uF)

Connection picture

• [ ] I will attach/upload an Image of my wiring

Version

0.8.92

Github Hash

96eb787

Build & Flash Method

was already installed

Setup

I am using MQTT commands to the MQTT topics within the iobroker datapoints. The problem occurs since many versions, so it is not related to the single one I am using right now.

Debug Serial Log output

No response

Error description

The MQTT topic ahoydtu/ctrl/power/0 does not react, if the old value is the same. But the old value doesn't have to be the real power status of the inverter.

You can set '0' for poweroff and '1' for poweron over this topic. If your limit is set to zero, but you won't poweroff your inverter it goes on with about 27W producing, if there is a power source (battery) available. So if you really want to stop producing you have to use this topic.

The problem with this topic here is, that it just reacts to "changes". This means you cannot shutdown the inverter anymore if you sent a '0' a few hours ago and the inverter is running since then again. In your topic there is still your old '0' inside. Sending another '0' to poweroff in a new situation again takes no effect - you can send it hundred times. The only way to bring in a new reaction is toggle the topic once to '1' back again and then set it to '0' again. The same behaviour is the other way around if you want to poweron with '1' and your last command has been already the '1'.

Toggling around in own iobroker script logics to fix this bug is possible, but not very stable for all different cases.

So in conclusion the problem is that the topic just has the last command (not the real status) and then ignores commands what are the same as last time, but this is a realistic scenario to happen.

The solution in my eyes would be:

• the topic does react on updates, not just on changes (preferred solution I think)
• the topic has the real status inside, so the scenario is killed, because then the same command as the status really needs no reaction (but because this topic is just for sending commands and not for keeping actual status, I think the first one should be the better fix)

[knickohr]

Da es hier ein deutsches Projekt ist kann man auch gerne deutsch schreiben.

Ich verstehe Dein Problem nicht, oder mein Englisch ist dermaßen schlecht 🤪 Nein nicht wirklich, aber ich verstehe es trotzdem nicht,

Du schreibst das …Power… reagiert nicht auf gleicht Werte. Das ist in meinen Augen vollkommen korrekt. Warum willst Du den Inverter noch einmal ausschalten wenn er es schon ist ?

So ganz nebenbei, ein Limit auf 0 setzen geht in die Hose. Vielleicht ist es das Problem. Ein Limit kann minimal auf min. 2% gesetzt werden, besser 3. das steht auch so im Handbuch, ansonsten macht der Inverter dumme Sachen.

[BerziOnline]

Ich setze kein Limit auf 0, ich wollte nur in Erinnerung rufen, dass es damit nicht geht, falls Stimmen laut werden, warum man den WR überhaupt aus/einschalten wollen würde :-)

Ich möchte auch keinen WR ausschalten, der bereits aus ist. Und ihn auch nicht anschalten, wenn er bereits an ist.

Es geht darum, dass es Szenarien gibt in denen der echte aktuelle Status des WR nicht dem letzten vesandten Command entspricht. Das ist auch in Ordnung so. Zwischen dem letzten verschickten Command besteht immerhin keine Beziehung zum echten Status des WR. Das ist ja beim Senden des Limits bspw. das Gleiche und auch i. O. .

Es geht aber darum, dass man hier nur die Wahl zwischen 0 und 1 hat und ein Command ignoriert wird, wenn man bspw. einen Tag zuvor bereits das Gleiche Cmd geschickt hatte. Hat sich der WR bspw. mal aufgehangen, war mal unerwartet stromlos, wurde über einen anderen Weg geschaltet, wurde gestartet, aber hat beim letzten Cmd nicht reagiert, ein Cmd ging verloren, etc. - so kann es passieren, dass dein letztes Cmd nicht mehr dem entspricht, was der WR gerade in Wirklichkeit tut. So hast du bspw. das letzte Mal eine '1' geschickt und der WR ist aber nicht an. Von nun an kannst du den WR über dieses Topic nicht mehr anschalten, weil jede gesandte 1 ignoriert wird. Obwohl der WR aber aus ist.

Der Workaround ist, dass man ihn selbst nochmal per MQTT "ausschaltet", bevor man ihn anschaltet. Wenn man also mit diesem Topic in verschiedenen Scripten arbeiten möchte, so muss man immer eine Logik hinterlegen, die das betrachtet, da man mit dem Topic sonst nicht zuverlässig arbeiten kann.

[knickohr]

Ja, jetzt sind wir beim Thema. Das ist bekannt und daran kann man leider nicht viel ändern. Das Beste ist immer, zumindest beim Setzen eines Limuts, darauf zu warten ob ein Ack kommt. Auch das erneute Setzen eines gleichen Wertes geht ins Leere, es kommt sogar nicht mal ein Ack.

Das sind auch die Punkte die ich immer wieder jedem vorhalte wenn er Nulleinspeisung per Script über die API oder MQTT machen will. Das System ist recht träge da es ja durch Ahoy durch muß und sogar durch den Broker, HA, … und wie diese Tools alle heißen.

Deshalb sind wir schon dran, eine „bedarfsoptimierte Leistungsregelung“ direkt in Ahoy zu implementieren die dann ohne Zwischenschritte direkt mit dem WR kommuniziert.

Ach ja, das Power ON/OFF, sowie ein temporär (non persistant) Gesetzes Limit überlebt die Nacht nicht ! Wenn also der ainverter mal stromlos war, dann geht er immer an wenn Strom kommt. Einzig das letzte dauerhaft (persistant) Limit bleibt erhalten. Dies sollte aber nicht zu oft gesetzt werden, da die Speicherzelle hier mit der Zeit kaputtgeschrieben wird.

[BerziOnline]

Ich habe aber gar keine Probleme mit der Nulleinspeisung oder dem Limit. Das passt schon so. Auch das Warten auf das Ack ist hier kein Problem - denn die Szenarien die ich benannt habe werden allesamt davon nicht abgefangen.

Es geht wirklich nur um das On/Off.

Dein letzter Abschnitt ist bspw. genau solch ein Szenario.

Man schaltet den WR Abends mit '0' aus. Über die Nacht hat ausnahmsweise der Reststrom der Batterie mal nicht ausgereicht. Nun startet der WR am nächsten Tage ungefragt und tut Dinge, obwohl man ihn ausgeschaltet haben möchte. Das fängt man natürlich ab, da es ja genügend Indikatoren gibt für "oh, der WR ist an, obwohl ich wollte, dass er aus ist". Man kann ihn aber genau dann mit 0 gar nicht mehr ausschalten, weil man ihn ja erst gestern schon ausgeschaltet hatte.

[stefan123t]

@knickohr @BerziOnline habe ich das richtig verstanden ?

Man kann das MQTT topic ahoydtu/ctrl/power/0 auf einen Wert (0/1) setzen.

Das hört / merkt sich der MQTT Broker / Mosquitto und sendet es auch brav an die AhoyDTU, aber erst wenn die AhoyDTU einen anderen (davon verschiedenen) Wert empfängt, wird sie wieder aktiv darauf reagieren und den Inverter aus-/einschalten.

So lange das Kommando des Inverters Ihrer Meinung nach in einem Zustand ist, bleibt es so lange so, bis man einmal das Gegen-Kommando gesendet hat, oder die AhoyDTU neu gestartet hat, damit sie sich neu initialisiert.

[knickohr]

Ja und nein 😅

Mit dem Kommando und Wert 0 schaltest Du die Inverter in den Standby. Er macht nichts mehr, verbraucht dann nur so 1 bis 2 W und regelt natürlich auch nicht mehr. Der Wert 1 weckt ihn wieder auf.

Das bleibt solange erhalten wie der WR DC-Spannung hat. Dann initialisiert er sich wieder auf das voreingestellte permanente Limit.

Nicht zu verwechseln mit dem Topic zum Setzen eines Limits !

[BerziOnline]

@stefan123t

Also das topic dient für das was @knickohr gerade beschrieben hat.

Setzt man es auf 0, geht der Inverter in den Standby. Setzt man es auf 1, startet der Inverter mit dem aktuell gesetzten gesetzten Limit.

Nun muss man wissen, dass sich dieses Topic nur wie ein "Command" und nicht wie ein "Status" verhält. Sprich, wenn in dem topic "0" zuletzt geschrieben wurde, dann bedeutet das nicht automatisch, dass der Inverter auch wirklich im Standby ist. Das soll auch nicht das Problem dieses topics sein. Das Problem ist aber, dass eine weitere "0" nicht mehr zum Ausschalten in den Standby führt, weil es nur bei einer Änderung einen Command schickt. Aber das hält es nicht für nötig von 0 auf 0. Aber das ist eine zu voreilige Annahme für ein topic, was sich um den "echten" status nicht schert. Die Werte sollte also auch beim Überschreiben, und nicht nur einer Änderung, an den Inverter geschickt werden. So jedenfalls meine Annahme warum es nicht klappt.

Heruntergebrochen kann ich nochmal beschreiben in welchem Szenario es bspw. nicht klappt:

1. Man schaltet den Inverter in den Standby mit "0". Es steht nun in dem Topic für immer "0", solange kein neues Command geschickt wird. Auch wenn der Inverter aus anderen Gründen wieder starten sollte.
2. Der WR wird nun bspw. über Nacht stromlos (also ganz aus, was nicht mehr standby ist). Am nächsten Tag wird er bei verfügbarem Strom wieder starten. Ein anderes Szenario wäre eine Steuerung an MQTT vorbei (bspw. über die Webseite), auch dann hat man einen anderen Zustand als im letzten MQTT-Command dieses topics
3. Wenn man nun sieht "oh, der Inverter ist an und ich wollte das gar nicht", dann haut man natürlich eine "0" in das Topic. Und genau das funktioniert dann nicht. Man muss selbst eine 1 reinschreiben, um dann wieder eine 0 mit anschließendem Effekt reinschreiben zu können.

Gleiches gilt natürlich auch invertiert andersherum, wenn man "1" haben will und diese schon drin ist.

Man muss also jedes Mal eine Abfangfunktion schreiben, um das zu handlen.

Die Lösung wäre, dass dieses Topic bei Aktualisierung, nicht nur bei Änderung an den Inverter feuert. Der Inverter selbst ist nicht das Problem in meinen Augen.

[knickohr]

Aufpassen mit Topics die retained geflaggt sind ! Das hat hier schon manche Steuerung das Genick gebrochen. Je nach Broker und Automatisation setzt diese alle Topics auf retained 😱

Sowohl Ahoy als auch meine Steuerung (Node-Red über Mosquitto standalone, nicht die in HA integrierte) haben damit keine Probleme. Beide Seiten senden und empfangen das mit QoS=2, es kommt also sicher beim Broker bzw. Ahoy an, aber eben nur genau einmal.

Es gibt eine Rückmeldung von dem Inverter : Es ist der Alarmcode 124 „Shut down by remote control“. Leider kommt dieser Code nur verzögert weil die Alarmcodes nur gelegentlich von Ahoy abgefragt werden.

Startzeit gibt an wann der inverter in den Standby geschickt wurde und Stop wann er wieder in den normalen Betrieb erweckt wurde.

[stefan123t]

@knickohr genau darauf wollte ich hinaus, liegt es jetzt daran, dass

1. der Wert im topic retained wird,
2. die AhoyDTU auf das Update nicht reagiert oder
3. der WR auf das Shutdown / PowerOff nicht reagiert ?

[BerziOnline]

@stefan123t jetzt verstehe ich deine Nachfrage - sorry. Und ja, du hast das Problem verstanden, wenn ich jetzt deine 3 Möglichkeiten so sehe. Du hast Recht, in dieser Kette kann es an jedem dieser Punkte scheitern. Tatsächlich bin ich etwas überfragt wie ich dir die Info genau dazu geben könnte. Aus stupider Anwendersicht, weiß ich, dass das "0" auf "0" schreiben den laufenden Inverter nicht in den Standby setzen würde.

Für mich war das immer gleichbedeutend mit "der broker schickt das wohl nicht mehr los zur AhoyDTU". Tatsächlich hast du aber Recht, es könnte auch am 2. Punkt liegen. Aber dazu müsste die AhoyDTU dann ja denken der Inverter wäre im Standby, wenn man auf die Oberfläche schaut, um es an diesem Punkt festzumachen, oder? Das ist nicht der Fall. Soweit ich die Szenarien im Sinn habe, wusste die AhoyDTU schon über den korrekten Status (also hier "Inverter läuft") Bescheid und ein simpler Klick hat ihn auch in den Standby gebracht. Sodass ich eher deinen ersten Punkt vermute. (insofern ich das mit dem "retained" richtig deute)

Dass der WR sich selbst wehrt vermute ich am wenigsten, dafür gab es keine Indizien im Ablauf. Dann würde er sich ja bspw. auch wehren, wenn man ihn über die AhoyDTU (also ohne MQTT) direkt in dieser Situation steuern will - das tut er aber nicht. Es hängt meines Erachtens schon mit der MQTT-Kommunikation zusammen.

[knickohr]

Na das läßt sich doch testen !

Fall 1 : Frage die retained Topics vom Broker ab

Fall 2 : Sende 0, warte bis der WR Standby ist, dann schalte ihn an beiden Seiten kurz stromlos. Warte bis er wieder online ist und sende erneut 0. Wenn er jetzt wieder Standby geht, dann gibt es Ahoy durch.

Fall 3 : Kann man über die WebGUI von Ahoy probieren.

Einfach alle Fälle damit durchspielen.

[stefan123t]

@BerziOnline so da hast Du es, jetzt darfst Du es auch testen und selber herausfinden an welcher Stelle der Hund / Bug begraben ist.

Eventuell steht das issue auch im Zusammenhang mit dem retained Flag in #1582, bitte mal bei Dir vergleichen / überprüfen ?

[BerziOnline]

Na das läßt sich doch testen !

Fall 1 : Frage die retained Topics vom Broker ab

Fall 2 : Sende 0, warte bis der WR Standby ist, dann schalte ihn an beiden Seiten kurz stromlos. Warte bis er wieder online ist und sende erneut 0. Wenn er jetzt wieder Standby geht, dann gibt es Ahoy durch.

Fall 3 : Kann man über die WebGUI von Ahoy probieren.

Zu Fall 1: Ich weiß leider nicht, wie ich nachsehen kann, ob das Topic wirklich retained ist oder nicht. Insofern ich mich in der Sache retained aber eingelesen habe, ist das nicht das angestrebte Verhalten hier. Wie ich das mit dem retain-flag gelesen habe, würde die geschriebene 0, den Inverter (der bspw. am nächsten Tag wieder hochfährt) wieder eine "0" schicken, um diesen erneut in den Standby zu schicken. Das ist ja aber eigentlich nicht mein beschriebenes Problem. Das Problem ist nur, dass man eben nicht nochmal erneut die "0" schicken kann, weil diese vom Broker ignoriert wird, solange der Wert keine Änderung innehat.

Meine Ansprüche sind gering: Ein Command soll einfach nur dann gesendet werden, wenn es einmalig initiiert wird. Ungeachtet, ob es eine Änderung für den Broker darstellt oder nicht. Also eben bei einer geschriebenen "Aktualisierung", anstatt lediglich bei einer "Änderung". Es ist nicht das Ziel irgendwas dauerhaft zu senden oder zu aktualisieren, dadurch soll das hier alles gar nicht aufgebauscht werden.

• Setze einmalig "0", sende einmalig "0".
• Setze einmalig "1", sende einmalig "1".
• Fertig O:-)

Und das klappt im Moment nur bei einer Änderung, also wenn der alte gesetzte Wert dem neuen widerspricht. Wohlwissend, dass das Control-Command aber gar nicht den wirklichen Zustand des Inverters kennt (und das auch nicht dessen Aufgabe ist), deckt das dann eben ein paar Fälle nicht mehr ab, seinen Inverter zuverlässig steuern zu können.

Zu Fall 2: Genau das klappt nicht. Der Inverter fährt einfach hoch (was ja richtig ist). Ein setzen einer neuen "0" im Topic, wenn zuvor eine "0" geschrieben stand, versetzt ihn dann nicht mehr in den Standby (was dann dieses Command ab diesem Zeitpunkt unzuverlässig macht). Es ist zwingend nötig das Topic dann künstlich in eine "1" zu schreiben, um dann wieder eine "0" schreiben zu können, die den Inverter dann auch wieder in den Standby versetzt. Genau das ist das Problem.

Zu Fall 3: Das klappt problemlos zu jedem Zustand, der eventuell beschriebene Probleme aufwirft.

[knickohr]

Zu Fall 1 :

Dieser Befehl gibt Dir alle retained Topics aus die der Broker vorhält.

Ein retained Topic wird immer dann wieder vom Broker erneut gesendet wenn sich der Client neu verbindet. In diesem Fall ist es NICHT der WR, sondern Ahoy der Client !

Zu Fall 2 :

Der Inverter muß aber wieder von sich selbst aus hoch fahren wenn er auf beiden Seiten stromlos war, ansonsten hat Dein WR was an der Klatsche. Der Zustand Standby ist nicht permanent, sondern nur temporär im Speicher geschrieben. Es geht sogar soweit das es wenn er Nachts keine DC-Spannung hat, am anderen Morgen wieder normal hochfährt.

Und hier kommen wir wieder zu Fall 1. Könnte es sein das Du Ahoy Nachts bootest, oder Ahoy selbst Rebootet ? Denn Dann greift das retained Topic und setzt ihn sofort wieder auf Standby wenn es als Wert 0 hat.

Zu Fall 3 :

Wenn Fall 3 funktioniert, auch wenn vorher schon 0 oder 1 über MQTT gesendet wurden UND der WR in dem entgegengesetzten Zustand ist wie gesendet wurde, dann ist die Sache für mich eindeutig. dein Broker, bzw. Deine Automatisation macht hier irgendwelchen Murks. Mein Favorit ist immer noch dieses retained Topic 😉

Retained Topics sind ein Segen wenn man sicherstellen will das die Automatisation in einem sauberen Zustand nach einem Stromausfall oder sonst welche Unterbrechungen hochkommen soll.

Es kann aber auch zu einem Fluch werden wenn man die falschen Topics als retained flaggt. HA ist z.B. so ein Broker der gerne alles als retained flaggt, auch ESPhome macht default solche völlig sinnlose Sachen. Damit ist der eigentliche Sinn von retained Topics bzw. MQTT in meinen Augen von der Anwendung nicht verstanden worden.

Als Beispiel, wir hatten hier schon Issues bei dem sich Ahoy im Kreise gebootet hat, endlos, immer wieder wenige Sekunden nach dem Neustart. Der Grund war ein Topic mit dem man Ahoy rebooten kann. Dummerweise hat der User, bzw. dessen Automatisation oder Broker es auf true und retained gesetzt. Kannst Dir ja jetzt denken was passiert ist, nachdem sich der Client (Ahoy) neu am Broker angemeldet hat ? 🤪

[BerziOnline]

Ich weiß langsam nicht mehr genau wie ich es erklären soll :D

Ich schreibe doch, dass es völlig normal ist, dass der Inverter nachdem er stromlos war wieder hochfährt. Das stört mich doch gar nicht. Ich will auch nicht, dass der Inverter danach gezwungen wird in den Standby zu gehen, nur weil einmal vor 12 Stunden die "0" geschickt wurde und noch im Broker steht. Das wäre ja absoluter Quatsch. Es ist einfach nur nicht möglich ihn dann wieder in den Standby über das besagte Topic zu senden.

Über jeden anderen Weg ist es möglich.

Ich selbst habe auch nie retain oder nicht retain gefordert und benötige deshalb auch nicht die Vor- und Nachteile davon diskutiert.

Es ist nur wie es ist: Aktualisierungen werden von dem Topic ignoriert, Änderungen klappen.

Mehr kann ich dazu einfach nicht mehr sagen. Wenn das für alle anderen kein Problem darstellt, dann können wir das Issue gerne schließen. Es ist nur so, dass folgendes Szenario bspw. eben nicht klappt:

03.11. 15 Uhr => Topic wird auf "0" gesetzt und WR ist im Standby 03.11. 19 Uhr => WR wird ohne PV stromlos und geht aus 04.11. 08 Uhr => WR fährt durch PV Strom wieder hoch 04.11. 09 Uhr => WR soll durch Topic "0" in Standby gesetzt werden, was nicht klappt, weil 0 auf 0 ignoriert wird

In diesem Zustand kann man den WR problemlos über alle anderen Wege wie gewohnt in den Standby versetzen oder man setzt eben das Topic künstlich zuvor von 0 auf 1, um es dann wieder auf 0 setzen zu können und den WR in Standby zu versetzen.

Wenn ihr das für normal haltet, dann lasst uns das Issue schließen. Ich komme mit meiner Abfangroutine klar, halte ein Ctrl-Topic, das aber nur manchmal greift nicht für normal und habe deshalb ein Issue eröffnet.