kein mqtt update auf letzten wert

[c-o-m-m-a-n-d-e-r]

What happened?

Wenn der Wechselrichter "offline" geht weil nicht mehr genügend Leistung anliegt wird mqtt nicht mehr geupdatet und somit bleibt dauerhaft der letzte Wert stehen.

To Reproduce Bug

Einfach beobachten wenn der WR Abends offline geht, im Topic bleibt der letzte Wert stehen (bei mir gerade Summe 1,1W)

Expected Behavior

Ein letztes mal sollten die Werte geupdatet werden so das klar ist das nichts mehr produziert wird.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

854af46

Relevant log/trace output

No response

Anything else?

Ich "glaube" das liegt an der if clause in Zeile 17 mqttpublishing ... hab noch den Code nicht weiter geprüft, aber es klingt nach der Hoymiles.getRadio()->isIdle() abfrage ... da müsste er zumindest ein mal noch updaten.

Mal gucken, vielleicht find ich heute Abend Zeit mir das näher anzugucken, dann könnt ich mich an ein PR setzen.

[madmartin]

Hallo @c-o-m-m-a-n-d-e-r ,

als "Erkennung" damit klar ist daß "nichts mehr produziert wird" gibt es

solar//status/reachable 0 solar//status/producing 0 solar//status/last_update 1669301329

und daß die live-daten nicht aktualisiert wenn es nichts zu aktualisieren gibt ist so beabsichtigt. Standardmässig sind die Werte ja alle mit "retained" gesetzt, daß heißt der mqtt broker behält immer die letzten Werte, auch wenn openDTU abgeschaltet würde.

Wie soll das denn Deiner Meinung nach funktionieren? Als "letzte Werte" alles mit Nullen senden? Wann wäre denn dieser Zeitpunkt für die "letzten Werte" - wenn eine Zeit X keine Änderungen mehr kommen? Was wäre dann wenn mal die Funkverbindung eine Weile gestört ist?

Meiner Meinung nach passt das genau so wie es ist. Bitte das "BUG" flag entfernen, es handelt sich um gewolltes Verhalten.

[c-o-m-m-a-n-d-e-r]

Mhhh ich empfinde es nicht als korrekt, gerade auch wenn der Wechselrichter nicht mehr ansprechbar ist dann dürfte ja nicht einfach angenommen werden das da noch ein paar Watt produziert werden ...

Weil in dem Fall wäre ja theoretisch zu updaten. Der Wechselrichter schaltet ab und somit wird 0 Watt produziert.

Die Punkte reachable / producing etc sind für weitere verarbeitung ja richtig und wichtig, aber wenn man sich angenommen nur den Wert der gerade produziert wird ausgeben lässt, z.B in einer influxdb2 speichert und da dann als letztes steht das er noch 1 Watt produziert mhhh ...

Wenn es gewolltes verhalten ist ok, dann darf das hier meinetwegen auch geschlossen werden, aber ich glaub ob das Verhalten richtig ist darüber könnte man jetzt diskutieren :-)

VG Paul

P.S : Ich finde keine Möglichkeit das Flag anzupassen ...

[madmartin]

angenommen nur den Wert der gerade produziert wird ausgeben lässt, z.B in einer influxdb2 speichert

Genau so passiert es. Wenn produziert wird, gibts neue Werte. In dem Moment wo der Wechselrichter aufhört zu produzieren werden KEINE NEUEN mqtt nachrichten wie

solar/<serial>/0/power

gesendet. Also gibt es m.E. genau KEIN Problem.

Starte doch mal Deinen MQTT-client mit einer Option, die nur "frische" Werte anzeigt, keine die "retained" sind - bei mosquitto_sub ist das die Option -R:

mosquitto_sub -h <mqtt-host> -R -v -t solar/\#

und siehe da: wenn es dunkel ist, kommen keine power werte.

Wenn Dein Programm also auch nachts fortwährend Power-Werte in die influxdb schreibt, dann stimmt an Deiner Programmlogik etwas nicht.

[c-o-m-m-a-n-d-e-r]

Na was heisst fortwährend ? Die Kette ist openDTU -> mqtt -> iobroker -> influxdb2 Wobei nur neue Werte gespeichert werden. Was natürlich im Umkehrschluss bedeutet der letzte Wert vorm schlafen legen bleibt bestehen.

Wie gesagt, ich kann damit leben wenn das Verhalten so gewollt ist. Auf mich macht es den Eindruck das es falsch ist. Ich passe mein Dashboard dann halt dahingehend an ...

Nichts desto trotz klasse Arbeit !

[tbnobody]

Ich muss ehrlich gesagt sagen, ich bin noch unschlüssig was falsch oder richtig ist. Es gibt auch hier eine intensive discussion: https://github.com/lumapu/ahoy/issues/416

aktuell glaube ich mag ich das thema noch etwas aufschieben. hängt auch irgendwie mit der neuen topic struktur zusammen. und vorher hab ich noch ein paar themen die ich mir zuerst ansehen möchte.

[madmartin]

Ich persönlich finde es richtig so. Der letzte Wert ist eben der letzte Wert, der kann auch länger her sein als das MQTT Publish intervall.

An welchen Kriterien möchtest Du denn festmachen WANN der richtige Zeitpunkt wäre die MQTT Nachrichten zu verschicken wo dann Power=0 drin steht? Nach "letzte Meldung vom INverter >x sekunden"? Nach Uhrzeit? Das erste könnte mehrmals am Tag passieren, wenn es Funkstörungen gibt. Das wäre dann falsch positiv. Das zweite - Uhrzeit - ändert sich übers Jahr. m.E. zu kompliziert. Und was ist mit den Leuten die einen Inverter an einer Batterie nutzen? Das ist meiner Meinung nach alles nicht wirklich "objektiv".

[stefan123t]

@madmartin für das zweite Uhrzeit kann man über den Standort die Zeiten des Sonnenuntergangs ziemlich genau berechnen. Auch die Yield und Total Topics könnte man ggf. um 0:00 Uhr oder bei Sonnenuntergang auf 0.00 setzen.

Das erste mit den Funktstörungen sehe ich genau so, das kann man eigentlich nur konfigurierbar machen nach X Sekunden und jeder stellt es ein wie er möchte oder läßt es aus, damit er immer die Fläche unter der Kurve berechnen kann und keine Einbrüche durch Übertragungsfehler bekommt. Ich sehe das dann aber objektiv eher als "falsch negativ" an :smile: mir fehlt ja in meinen Daten der Ertrag der evtl. sogar da war, dann lieber linear weiter bis zum nächsten Datenpunkt.

[c-o-m-m-a-n-d-e-r]

@madmartin : ja aber der letzte wert entspricht ja nicht dem ist zustand ... der letzte wert müsste 0 sein, da er halt nicht mehr produziert.

Ich kenn die Problematik mit der API eines Dienstleister bei uns im Unternehmen, die vermischen auch immer munter status => ok und status => error. Da passiert es das du eine Abfrage tätigst und status => error bekommst nur weil keine Datensätze gefunden wurden (aus einem SAP System)... aber die Abfrage ist ja nicht auf einen Error gelaufen sondern liefert halt 0 Datensätze zurück ... ist zum Haare raufen...

Hier ist halt die besondere Problematik das der WR sich schlafen legt wenn er nicht mehr produziert ... Wenn ich jetzt z.B meinen Fronius via API abfrage bekomme ich ja auch ordentlich die 0 zurück geliefert.

Klar beim Hoymiles müsste man ein wenig mehr Logik einbauen da übern Tag theoretisch auch mal der Funk aussetzen kann, das verstehe ich. Aber das könnte man ja relativ einfach wie von @stefan123t schon beschrieben machen via Auf und Untergang machen. Kommt nichts zwischen Aufgang und Untergang ist vermutlich der Funk gestört ... kommt nichts mehr nach Sonnenuntergang ist eher wahrscheinlich das er sich einfach schlafen gelegt hat.

[JauntyJosef]

Die original DTU Pro liefert bei der Modbus TCP Abfrage auch den Wert 0, wenn der WR nicht mehr produziert. Ich speichere meine Daten auch in InfluxDB. Da sind alle anderen Werte als 0 (über Nacht) dann eher kontraproduktiv.

[MartinNemec]

I agree with both sides of the discussion. I believe the "not updating values" is correct for all values but for one: namely YieldDay. There should be one additional update at midnight, as with the new day the sum of last day is not what to be expected...

[magic21nrw]

I can confirm this behaviour.

What if you use the information for a 0 Watts calculation? Then it is misleading because you are not getting the correct 0 for the calculation. I mean it is only 1 or 2 Watts but it is kept during the night time as already mentioned.

The solution would be to combine it with producing status and change the watts to 0 if producing is 0. Otherwise the status would be logically wrong if we have producing = 0 and watts > 0. This would be an inconsistent state which contradicts each other. The question is, if it is possible to internally check if producing is set to 0, then watts must be 0 as well. I would strongly vote for this behaviour.

[o0shojo0o]

@tbnobody gibt es hier Neuigkeiten? Ich würde sonst in meinen ioBroker Adapter eine "Nullung" mit einbauen, sofern das nicht seitens OpenDTU vorgesehen ist. Der schönere Weg wäre es natürlich wenn es der OpenDTU (vielleicht konfigurierbar on/off) machen würde.

PS: Werte die ich dafür vorschlagen würde:

• */current
• */irradiation
• */power
• */voltage
• */frequency
• */powerdc
• */reactivepower
• */temperature

[tbnobody]

@o0shojo0o ich bin gerade dabei die neuen mqtt topics zu implementieren. dafür musste ich zuerst die hoymiles lib entsprechend anpassen. hier bin ich jetzt hoffentlich durch. prometheus output und webapi bin ich gerade am fertig stellen. Dann kommt der mqtt kram dran......

das thema mit der nullung sehe ich als ähnliche struktur wie die offsets für diverse values.

theoretisch gibts ja auch 2 verschiedene typen von nullungen... bei nichterreichbarkeit und bei mitternacht. wenn mans schlau macht bekommt man ggf. beides unter :-)

[morph027]

Häng mich mal an. Hab gerade geflashed und den ersten Tag erzeugt ;)

Hab mir im HA einfach eine Automatisierung angelegt, die beim Wechseln Producing=on auf Producing=off einach den Wert 0 an das passende Topic pushed.

[tbnobody]

Wenn der Wechselrichter "offline" geht weil nicht mehr genügend Leistung anliegt wird mqtt nicht mehr geupdatet und somit bleibt dauerhaft der letzte Wert stehen.

There is a now a setting per inverter which sets all runtime values to zero if the inverter is no more reachable.

Implemented in 6127fbe940fd70bd6014d71e978d94516271cd78

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.