[Bug] MQTT topic ahoydtu/ctrl/power/0 doesn't react on updates - just on changes #1539
Comments
BerziOnline
changed the title
|
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. |
|
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. 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. |
|
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. |
|
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. |
|
@knickohr @BerziOnline habe ich das richtig verstanden ? Man kann das MQTT topic Das hört / merkt sich der MQTT Broker / Mosquitto und sendet es auch brav an die AhoyDTU, So lange das Kommando des Inverters Ihrer Meinung nach in einem Zustand ist, |
|
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 !
|
|
Also das topic dient für das was @knickohr gerade beschrieben hat. Setzt man es auf 0, geht der Inverter in den Standby. 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. Heruntergebrochen kann ich nochmal beschreiben in welchem Szenario es bspw. nicht klappt:
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. |
|
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. |
|
@knickohr genau darauf wollte ich hinaus, liegt es jetzt daran, dass
|
|
@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. |
|
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. |
|
@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 ? |
Zu Fall 1: Meine Ansprüche sind gering:
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: Zu Fall 3: |
|
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 ? 🤪 |
|
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: 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 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. |
Platform
ESP32
Assembly
the DTU was already assembled
nRF24L01+ Module
nRF24L01+ plus
Antenna
external antenna
Power Stabilization
Elko (~100uF)
Connection picture
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/0does 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 text was updated successfully, but these errors were encountered: