[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.