MQTT openWB CC "vergisst" immer wieder Werte

[zimberg44]

Der openWB CC "vergisst" immer wieder die einen oder anderen Werte, obschon diese laufend im zugehörigen set (via mqtt) neu gesetzt werden.

- set/evu/APhase1 wird laufend aktualisiert
- evu/APhase1 wird plötzlich nicht mehr aktualisiert

Manchmal ist eine Phase-Spanung, manchmal eine Phase-Leistung betroffen. Manchmal stimmt die Bezugsmenge dann doch, manchmal ist sie dann 0.

Ursache?

[hominidae]

...eigentlich sind die topics ausserhalb openWB/set/ doch nur read-only da....in meiner 1.7.018N ist unter openWB/set/ kein evu-Untertopic.
Also kann man da über MQTT wohl nicht setzen?

[zimberg44]

Ja, ich setze auch nur openWB/set ...

Beim lesen der Topics (ohne "set"), sind diese teilweise plötzlich leer, erscheinen dann auch im Status nicht mehr und teilweise fällt dann auch der Bezug auf 0.

[hominidae]

...will sagen, das Du die nicht über openWB set setzen kannst, oder?

In meiner, mit EVU-Kit sind nur die openWB/evu/... Werte im broker...unter set sind die nicht....ergo werden die nicht ausgewertet, selbst Du die topics füllst.


...ober habe ich was übersehen...nur das topic zu publishen reicht ja nicht...muss ein Stück code da sein, dass es in das andere, read-only topic umsetzt?

[zimberg44]

Die openWB/set/evu Werte werden sehr wohl ausgewertet und der openWB CC schreibt Werte nach openWB/evu.
Plötzlich fehlen aber dann die einen Werte unter openWB/evu, wo sie (im 10 sek. Takt) unter openWB/set/evu weiterhin aktualisiert werden.

[hominidae]

Ah...verstehe, es geht um den Faden, hier: viewtopic.php?f=4&t=772

OK, wenn es implementiert ist, dann wohl noch nicht vollständig, würde ich sagen.
Schliesslich habe ich in der gleichen Nightly keine topics unter openWB/set und da müssten sie doch auftauchen, wenn (wie bei mir) ein Evu-Kit da ist

Edit: also eher ein Fall für den 1.7er Rückmelde-Faden?

[mrinas]

hm, interessant. Ich übergebe auch EVU Daten per MQTT. Das hat zu Begin einwandfrei funktioniert und dann irgendwann von jetzt auf gleich nicht mehr, wobei ich ein paarmal Strom am Raspberry verloren hab, hatte das erstmal darauf geschoben. Da das noch nicht produktiv genutzt wird hab' ich mir da auch erstmal nicht so viel gedacht.

In meinem Fall schreibe ich alle Werte und sehe im MQTTExplorer auch dass diese sauber ankommen, in der openWB selber taucht aber gar nichts davon auf. Ist also etwas anders als bei Dir.

Hat das bei Dir überhaupt schon mal sauber funktioniert oder kann ich ggf. auch noch ein Problem mit dem Datenformat vorliegen, meine dass einzelne Werte als Int und nicht als Float erwartet werden.

[zimberg44]

Es funktioniert bei mir auch über längere Zeit einwandfrei bis openWB CC eben vergesslich wird. Nach Reboot ist es dann wieder ok.

[openWB]

Sind es vereinzelt Werte oder immer der gleiche?
Wie sieht ein nicht übertragener Wert aus, sprich einer der im set übernommen wird aber nicht im /evu/ landet?

[truckl]

Ohne zu implizieren daß es das hier diskutierte, knonkrete Problem löst:
Wäre es der Stabilität der MQTT-set-Operationen nicht generell zuträglich wenn "mqttsub.py" das Subscribe auf "openWB/set/#" mit QoS Level 2 (ExactlyOnce) machen würde und eine feste Client-ID verwendet?
Bei meinem Code für die Bridge-Konfiguration hab ich mir darüber jedenfalls extra Gedanken gemacht und die Bridge mit voller Absicht in beide Richtungen mit QoS 2 und einer festen Client-ID parametrisiert.

Derzeit ist im "mqttsub.py" kein QoS angegeben, was laut Paho-MQTT Manual dem Default von 0 (AtMostOnce) entspricht. Das erlaubt auch "gar nicht".
Die Client-ID wird nicht gesetzt, was bedeutet daß eine zufällige ID erzeugt wird. Das nimmt dem MQTT-Broker die Chance, Daten mit QoS 1 und 2 Daten stabil, auch über verlorene Verbindungen hinaus zuzustellen (eine ganz gute Erklärung dafür ist z.B. hier).

Der Absender der EVU-Daten muß natürlich ebenfalls sicherstellen die Daten mindestens mit QoS 1 (AtLeastOnce), besser 2 (ExactlyOnce) zu versenden.

Weitere Idee:
Wenn beim Absender auch noch "Retain" gesetzt würde, dann übernähme der MQTT-Server auch noch die Rekonfiguration bzw. Übermittlung der letzten Werte im Falle eines Neustarts (vorheriges, geregeltes herunterfahren vorausgesetzt so daß der Server die Werte persistieren kann) oder verlorener Verbindung.
Allerdings hab ich nicht untersucht wie der restliche openWB-Code reagieren würde, wenn beim Neustart oder Re-connect erst mal ein ganzer Schwung (alter) set-Daten empfangen wird . Würde das also derzeit allerhöchstens für sehr experimentierfreudige Experten-Nutzer in nicht-kritischer Umgebung empfehlen .