MQTT openWB CC "vergisst" immer wieder Werte

[zimberg44]

QoS=0 und Retain ohne individuelle Einstellung, also (Node-RED-)default.

Im Übrigen kann ich beobachten, wie gewisse Werte (set) im Sekundentakt und diejenige ohne set im 10-Sekundentakt ändern. Im Übrigen update ich nur noch wenige Topics im Sekundentakt, sondern im 10-Sekundentakt, was bspw. für die Spannung mehr als ausreichend ist.

[hominidae]

...just 4 the record: die defaults in node-red sind anders.
Die Einstellungen für QOS und retain eines mqtt-out Nodes sind (im Dialog/UI) in der aktuellen Version "empty", also keine Einstellung...damit erwartet er die Settings in den msg-properties der Nachrichten selbst.
Glaubt man der Anleitung sind die Default Einstellungen (wenn die msg nix vorgibt/überschreibt) dann Qos = 0 und retain = false.

für openWB sind alle topics immer retain-ed, also braucht es retain = true.
Den Parameter QoS würde ich im mqtt-out auf 1 oder 2 stellen, bei 0 kann auch mal nix rübergehen, insbesondere wenn über WLAN angebunden oder einem anderen Glitch in den Komponenten.

[zimberg44]

Ich verstehe die Rückmeldung nicht so ganz.

Seitens EVU setze ich durch MQTT-Meldungen "set" Topics im Broker. All diese Meldungen kommen auch regelmässig ab, weshalb die QoS derselben kaum im Zusammenhang mit dem geschilderten Problem stehen kann und ich nicht einsehe, weshalb Retain eine Rolle spielen soll.

Der openWB CC "liest" offenbar die vorgenannten "set" Topics und "schreibt" zugehörige Topics (ohne set).

Meine Beobachtung bestrifft nicht die "set" Topics, sondern die zugehörigen Topics, welche ausschliesslich vom openWB CC geschrieben werden. Da diese Topics dasselbe Verhalten zeigen, wie die Status-Anzeigen des openWB CC sehe ich noch weniger ein Zusammenhang mit dem Setzen der "set" Topics.

Ich bin mal auf Ver 1.7.010Stable zurück gegangen, wo das Problem bisher nicht mehr aufgetaucht ist.

[hominidae]

..retain hat eine Auswirkung auf den Subscriber.

Ein Subscriber bekommt, nachdem er sich subscribed hat, erst bei der dann nächsten Änderung eines Topics die Info hierzu.
Ist das Topic aber mit retain-Flag versehen (und das muss beim publish-Vorgang angegeben werden) bekommt der Subscriber den aktuellen Wert des Topic, sobald er sich (neu) subscribed.

Ich kenne jetzt den inneren Aufbau nicht, gehe mal davon aus, dass die mit /set eingelieferten Werte irgendwie subscribed sind...vom Subscriber (noch evtl. weiterer Bearbeitung) in der Ramdisk landen und von dort wieder in die lesenden Topics gepublished werden.
Ich hatte schon den Effekt, das Topics nach dem Start zwar retained, aber später nicht mehr retained auftauchen....Bug oder Feature?
Ausgehend davon, dass eigentlich alle lesend angebotenen Topics retain-ed sein sollten, kann es nicht schaden, das grundsätzlich zu setzen

[zimberg44]

Ja, klar, ich setze retain nun bei allen set Topics; weil es nicht schadet. Bei den QoS sehe ich nicht ein, weshalb 0 nicht passen sollte.

Ich gehe davon aus, dass der openWB CC sich selber beim MQTT-Broker "subscribt", welcher auf dem selben Pi läuft, und deshalb die entsprechenden openWB-CC-Einstellungen (und nicht diejenigen eines anderen - schreibenden - Subscribers für andere Topics) wesentlich sind.

Mein lesender Subscriber (auf einem andere Pi), welcher die Topics liest, welche durch den openWB CC gesetzt werden, bekommt dieselben "leeren" Informationen, wie der openWB CC selbst (welcher dies dann im Status auch "leer" anzeigt).

Die Ursache des Problems muss wohl zwischen openWB CC und MQTT-Broker auf demselben Pi gesucht werden. Allenfalls sind mein lesender und der openWB CC MQTT vom selben MQTT-Bug des MQTT betroffen und ist im openWB CC alles richtig.

[openWB]

Ich gehe davon aus, dass der openWB CC sich selber beim MQTT-Broker "subscribt", welcher auf dem selben Pi läuft, und deshalb die entsprechenden openWB-CC-Einstellungen (und nicht diejenigen eines anderen - schreibenden - Subscribers für andere Topics) wesentlich sind.

Richtig.

Mein lesender Subscriber (auf einem andere Pi), welcher die Topics liest, welche durch den openWB CC gesetzt werden, bekommt dieselben "leeren" Informationen, wie der openWB CC selbst (welcher dies dann im Status auch "leer" anzeigt).

Der openWB Daemon subscribed sich, wenn auf ../set/evu/APhaseX etwas ankommt wird geprüft ob es gültig ist. (float > -1000 & float < 1000).
Wenn das der Fall ist wird der Wert in die Ramdisk geschrieben (ramdisk/bezuga1).
Die Regellogik schreibt dann zyklisch (alle 10 Sekunden) den Wert aus der ramdisk nach ../evu/APhaseX


Nutzt du Mosquitto Version 1.4.10?

[zimberg44]

mosquitto version 1.5.7

[openWB]

Vielleicht hängt es damit zusammen.
Du kannst mal prüfen welcher Wert in der ramdisk steht wenn die Anzeige leer ist (bezuga1 / bezuga2 / bezuga3 )