Nach Deaktivieren/Aktivieren von MQTT werden zyklisch falsche Limit-Werte übertragen

[ntfrnd]

What happened?

Ich weiß nicht, ob es ein Bug ist. Ich konnte es reproduzieren und glaube, dass es an OpenDTU liegen könnte.

Nach Deaktivieren und erneutem Aktivieren der MQTT-Übertragung in den OpenDTU-MQTT-Einstellungen werden zyklisch nicht nachvollziehbare Limit-Werte übertragen. Hier mit dem MQTT-Explorer beobachtet:

To Reproduce Bug

Ich hatte mittels MQTT das "cmd/limit_nonpersistent_absolute" auf 300W gesetzt, der HM600 hat dies akzeptiert.
In der OpenDTU-GUI steht

Die Rückmeldung erfolgte über MQTT in "status/limit_absolute" mit 300 W. Von daher alles ok.

Nun deaktiviere ich in den OpenDTU-Einstellungen die MQTT-Übertragung, warte etwas, schalte diese wieder ein. Dann dauert es kurz und schon wird im 5 sec. Takt das Limit (status/limit_absolute) geändert, wie man auf dem oberen Bild sieht.

150 W (entspricht 20%) -> 300 W -> 600 W ->150 W ->300 W -> 600 W usw. das Ganze wiederholt sich ein paar Mal, bis das Limit schließlich bei 600 W bleibt.
Dies sieht man aber nur über MQTT in "status/limit_absolute" - auf der OpenDTU-GUI bleibt es unverändert (weiß jetzt nicht mehr, ob es der Wert vor dem MQTT-Deaktivieren war oder die 600W).
Die 600 W könnten das "cmd/limit_persistent_absolute" sein, dass dann greift. Ist aber nicht nachvollziehbar, denn vor einigen Tagen habe ich das Limit über die OpenDTU-GUI auf 300 W dauerhaft gesetzt. Jeden Morgen startet er seitdem mit 300 W, ebenso wenn er spannungslos war und neu bootet.

Für mich ist das Verhalten nicht nachvollziehbar.
Vielleicht kann mal jemand anderes dies ausprobieren?

Expected Behavior

Aktuelles Limit wird vom HM600 ausgelesen und übertragen. Das sollte dem vorherigen entsprechen, da der HM600 ja nicht spannungslos war bzw. neu gebootet hat. Von daher sehe ich keine Grund, warum er sein Limit ändern sollte.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

b8ced54

Relevant log/trace output

No response

Anything else?

No response

[tbnobody]

Beim aktivieren des MQTT werden auf jeden fall die retainten Werte übernommen. Also wenn du aktuell retained auf absolut 300W stehen hast, dann aber auf non persistant 200W schreibst ist es normal das nach einem mqtt reconnect wieder 300W angewendet werden. um das zu verhindern dürftest du keine retained values setzen. Dieses Auf und Ab sieht erstmal seltsam aus. Auf der Console sollten aber alle empfangenen MQTT Nachrichten mitgelogged werden. Da sollte man am besten sehen was passiert.

[ntfrnd]

Kann ich nochmal probieren, wenn wieder Sonne scheint und in die Konsole schauen.
Ich habe mir als unabhängigen Teilnehmer den MQTT-Explorer genommen um zu sehen, was hier so passiert.

Wer setzt das retain-flag? Ist das die Einstellung im iobroker->MQTT-Adapter? Das gilt aber dann wohl für alles, was dieser tut und nicht für einzelne topics, oder? Kann das bei einzelnen Nachrichten auch gesetzt werden?
Mir ist nicht bewusst, dass das hier gesetzt ist.

Wenn ich dich richtig verstehe, würde er in meinem Beispiel

nach einem reconnect zwischen limit_persistent_absolute = 600W und limit_nonpersistent_absolute = 300W wechseln, weil er gleichzeitig beide Werte "erstmalig" bekommt, richtig?
Und die 150W sind dann die limit_nonpersistent_relative = 20, die er ebenfalls "erstmalig" sieht.
Hab ich das richtig wiedergegeben? Das würde das jedenfalls erklären.

Dann frage ich mich, warum er nicht nur einmal alle drei Werte einstellt und dann ist es gut bzw. warum macht er das einige Male und hört dann auf. Es könnte ja auch unendlich so weitergehen, was bremst ihn aus?

Und die alles entscheidende Frage: wie kann man das verhindern?
Der HM600 soll einfach so weiterlaufen wie vorher, also in diesem Fall mit limit_nonpersistent_absolute = 300W. Und das müsste er gar nicht neu bekommen, weil das kennt er ja schon.

[tbnobody]

Wer setzt das retain-flag?

Das retain flag setzt derjenige der die topic published. Das Protokol selbst sieht vor, dass es für jeden einzelnen publish individuell sein kann. Was der jeweilige Client (in deinem Fall wohl IOBroker) macht, kann ich leider nicht sagen.

nach einem reconnect zwischen limit_persistent_absolute = 600W und limit_nonpersistent_absolute = 300W wechseln, weil er gleichzeitig beide Werte "erstmalig" bekommt, richtig?

Nein. limit_nonpersistent* topics erlaube ich nur als non-retained. Wenn da etwas als retained kommt werden diese ignoriert.
Bei den 600W in limit_persistent_absolute hast du fast recht. Nach einem Reconnect werden diese gesetzt. Jetzt kommt das große ABER.

Stelle dir folgendes vor:

• DTU ist online
• Du setzt die Topic (limit_persistent_absolute) retained auf 600 --> DTU nimmt 600
• Dann non-persistent auf 450 --> DTU nimmt 450
• Du restartest die DTU --> DTU holt sich den letzten retained Wert also 600
  Nachdem man bei dir nur den einen Screenshot sieht, ist nicht erkennbar ob die 600 retained sind oder nicht retained. Sie könnten auch einfach zwischenzeitlich gesetzt worden sein.

Testen kann man das ganz einfach. MQTT-Explorer disconnecten und zum Broker verbinden. Alles was direkt nach dem Verbinden an topics da ist ist mit ziemlicher Sicherheit retained. Wenn garkeine Topic retained wäre, dann wäre die ansicht beim Verbinden erst einmal komplett leer..

[ntfrnd]

Ich habe geprüft, ob beim MQTT im iobroker das retain-flag gesetzt wird oder ob man das einstellen kann.
Dort steht u.a. "If your client has problems with retained messages you can force ioBroker MQTT-Broker to send messages without retain flag with Publish messages without "retain" flag option. In this case the messages will be stored in States-DB anyway."

Meine Einstellungen im iobroker sind:

Von daher sollte es eigentlich passen. Oder der mqqt-iobroker hat eien Bug?

[tbnobody]

kann ich so nicht beantworten... wie gesagt. blick in die console und schauen was an topics empfangen wird. Verwendest du scripts welche das limit ändern? ggf. passiert hier etwas wenn das erstemal wieder aktuelle produktionsdaten gepublished werden.

[ntfrnd]

Ich hab noch weiter probiert....das Verhalten verändert sich, wenn man "Eigene States beim Verbinden publizieren" ausschaltet.
Dann werden noch vorhandene Werte in den cmd-topics nicht mehr übertragen, und OpenDTU sendet diese nicht mehr an den Inverter. Das sieht man auch in der Konsole, wenn man schnell genug klickt zwischen "MQTT aktivieren -> bestätigen" und "Konsole".

Allerdings habe ich mit dieser Einstellung so meine Probleme. Andere Teilnehmer, die sich auch mit dem ioBroker-MQTT-Adapter-Broker verbinden, erhalten dann erstmal keine Werte. Erst wenn sich was ändert, gibt's einen publish. Damit passiert folgendes: Wert1 steht auf x, stundenlang, Teilnehmer ABC wird hochgefahren, meldet sich am MQTT-Broker an, er bekommt keine Werte, weiß also im ersten Moment keinen Ist-Zustand, kann nichts tun. Irgendwann ändert sich Wert1 auf y, MQTT-Broker published das und Teilnehmer ABC kriegt Info, nun kann er damit was anfangen. Auch eine Visu würde solange keinen Wert anzeigen. Das ist meiner Meinung nach sinnfrei.
Setze ich den Haken bei "Eigene States beim Verbinden publizieren", so bekommt Teilnehmer ABC sofort beim Verbinden den Wert1 = x mitgeteilt, egal wie alt dieser schon ist - aber er ist gültig - und kann diesen sofort benutzen.
Das wäre für mich das richtige Verhalten. Oder habe ich einen Denkfehler oder ein Verständnisproblem???

Von daher DARF m.E. OpenDTU mit den publizierten cmd-topics beim Verbinden gar nichts tun (die können ja ewig alt sein und auch zeitlich nicht zusammenpassen, z.B. 100% Limit und Inverter=0), sondern erst mit der nächsten Änderung.

[stefan123t]

@ntfrnd wo finden wir denn Deine Consolen Ausgabe ?

Kannst Du das nochmal reproduzieren und dabei einen Mitschnitt des USB Serial Logs machen ?