Neues MQTT Plugin

[Msinn]

Hab ich hier schon geschrieben

Das in den vielen langen Posts hier im Thread untergegangen. Ich habe es zumindest über die Browser Suche nicht (wieder)-gefunden.

Mit dem Tool MQTT Explorer sieht man auch, dass das Item einfach nicht geschrieben wird (es fehlt ganz schlicht).

Was meinst Du damit? Items werden in Richtung MQTT nicht geschrieben der MQTT Explorer sieht nur Telegramme.

Meinst Du dass dort ein Telegramm mit leerer Payload ankommt oder dass gar kein Telegramm ankommt?

[TCr82]

Dass gar keins ankommt und somit der Eintrag Heizung/WW/Schaltzeiten gar nicht auftaucht. Dafür spricht ja auch dass debug log, denn dort kommt der Eintrag (in Bezug auf dass mqtt) trotz Definition gar nicht zu Gespräch

[Msinn]

Was passiert denn, wenn Du dem Item Daten zuweist, die weniger komplex sind? Siehst Du dann im MQTT Explorer ein Telegramm? Was passiert wenn Du retain auf False setzt?

[TCr82]

Hi,

es läuft nun, aber was es genau war weiss ich nicht, da ich dummerweise zwei Sachen auf einmal geändert habe.

1. Habe ich den mosquitto von 1.4.15 (distributions-standard) auf 2.0.4 aktualisiert
2. Dann ist mir aufgefallen, dass die enforce_updates: yes die ich rein Gebaut habe, falsch eingerückt waren und deswegen gar keine Items mehr geladen waren. Also hab ich das noch korrigiert und dann lief es. Ich vermute aber, dass es daran lag - das enforce_updates kümmert sich ja darum, dass die Daten über die Plugins gesendet werden, auch ohne Änderung der Werte.

Trotzdem danke für die Unterstütung und den denkanstoß

[TCr82]

Hab mal eine Frage:

mqtt_topic_init

Laut Doku ist das ja wie mqtt_topic_out, nur dass zuerst ein Paket gesendet wird. Die Frage ist aber, welches: Lesen oder Schreiben? Leider geht das daraus nicht 100%ig hervor.

Ich Frage deswegen, da ich ein Raspi im Keller an der Heizung habe und die Items Prinzipiell vom Viessmann Plugin Initialisiert werden sollen, dass ganze dann aber per MQTT zum Hauptrechner der auch die Visu bereitstellt gesendet werden soll. Manche Items will ich natürlich auch per Visu updaten können.

Bedeutet, dass ich ja an der Heizung auch MQTT lesen will/muss.

Mein problem ist aber, dass ich beim Starten vom shNG an der Heizung (also beim Laden der Items/Plugins) immer ein Schreibbefehl vom MQTT bekomme, obwohl ich das ja garnicht will.

2021-01-10 17:50:44 INFO plugins.viessmann_dev Update item: technik.heizung.HK1.Schaltzeiten, item has been changed outside this plugin

Geändert hab ich am Item auf dem Hauptrechner in dem Moment nichts.

[TCr82]

Ich dachte Eigentlich, wenn ich das Item so definiere, dass es kein Init beim Start macht:

technik:
    heizung:
        HK1:
            Schaltzeiten:
                name: HK1 Schaltzeiten im UZSU dict Format
                type: dict
                cache: yes
                enforce_updates: yes
                viess_timer: Timer_A1M1
                viess_init: true
                viess_send: true
                mqtt_topic_out: Heizung/HK1/Schaltzeiten
                mqtt_topic_in: Heizung/HK1/Schaltzeiten
                mqtt_retain: true

[Msinn]

Bei Deiner Beschreibung hat das aber nichts damit zu tun, ob Du mqtt_topic_out oder mqtt_topic_init verwendest.

So wie Du das item definiert hast, kommt bei jedem Connect ein Telegramm vom Broker, weil Du den Broker angewiesen hast das zu tun (Retain Flag).

[TCr82]

Mit anderen Worten, einfach das mqtt_retain weg nehmen, die Items im Broker löschen, shNG neu starten und es sollte nicht mehr passieren? Teste ich später mal.

[Msinn]

Ja, das Retain Flag weist den Broker an die Information zu speichern und auszuliefern, auch wenn der veröffentlichende Client nicht mehr aktiv ist. Damit bekommt jeder Client der sich anmeldet und das Topic subscribt genau das Telegramm. Genaueres dazu findest Du in der MQTT Protokoll Doku v3.1.

[TCr82]

Also ich habe zuletzt das "enforce_updates: yes" wieder raus gemacht, zusammen mit dem entfernen des Retain Flags funktioniert es wohl jetzt "fast" wie gewollt.

Problem ist, dass wenn ich jetzt den Hauptserver neu starte bzw den shNG Dienst, dass er bestimmte Werte die nicht zyklisch gesendet werden, nie wieder bekommt.

Dem bin ich jetzt entgegen gegangen, in dem ich auf dem Hauptserver noch den cache für die Items aktiviert habe. So ganz "sauber" ist das ja aber nicht.

Theoretisch könnte nämlich ja ein anderer Wert gesendet worden sein, den der Hauptserver so erst spät oder garnicht mehr bekommt - aber denke das kommt wohl ehrer nicht vor bzw. die Verspätung sollte nicht so spät sein.

Als Idee kommt mir auch gerade, dass ich ein neu lesen triggern könnte, aber wenn sich ja aus sicht der Heizung nichts geändert hat wird ja wieder nichts gesendet wegen dem entfernen von enforce_updates

Ich lasse es jetzt erstmal so, es sieht mir bis jetzt am besten aus.... vielleicht hat ja noch wer einen Tipp, dann immer her damit.

[Msinn]

Du könntest entweder dem Heizungs-System beibringen, dass solche Werte periodisch gesendet werden oder dem Hauptsystem. Eibringen, dass es beim start ein Telegramm schickt, welches dem Heizungs-System signalisiert diese Werte zu senden.

[TCr82]

oder dem Hauptsystem. Eibringen, dass es beim start ein Telegramm schickt, welches dem Heizungs-System signalisiert diese Werte zu senden.

In der Theorie dachte ich, dass dies durch dass MQTT System genau so funktioniert. In der Praxis geht es wohl aber nicht so?

Wenn wir mal ein aktuelles Beispiel von mir heran ziehen:

Ein Item auf dem Heizungsrechner:

technik:
    heizung:
        HK1:
            Schaltzeiten:
                name: HK1 Schaltzeiten im UZSU dict Format
                type: dict
                viess_timer: Timer_A1M1
                viess_init: true
                viess_send: true
                mqtt_topic_init: Heizung/HK1/Schaltzeiten
                mqtt_topic_in: Heizung/HK1/Schaltzeiten

Hier das Item vom Hauptrechner auf dem die VISU auch läuft.

technik:
    heizung:
        name: Heizung
        sv_page: room
        sv_img: message_service.svg

        ha:
            name: Heizungsanlage

            HK1:
                Schaltzeiten:
                    name: HK1 Schaltzeiten im UZSU dict Format
                    type: dict
                    cache: yes
                    visu_acl: rw
                    mqtt_topic_in: Heizung/HK1/Schaltzeiten

Also ich dachte, dass beim starten des Hauptrechners bzw. des shNG Dienstes dieser die Daten mit mqtt_topic_in über den Broker beim Heizungsrechner anfragt. So wie ich es aber jetzt von dir verstanden hatte, registriert er sich nur am Broker auf dem Topic für eingehende Telegramme. Der Broker kann? das selbst nicht als anfrage weiter leiten?

Sorry ich kenne mich mit dem MQTT Protokoll nicht wirklich aus muss ich gestehen.

EDIT: PS: Ich weiss dass ich das Item auf dem Hauptrechner noch nicht für topic_out eingerichtet habe...

[Msinn]

Das hast Du ein falsches Verständnis von MQTT.

• MQTT Clients kennen einander nicht
• MQTT Clients „fragen“ auch erstmal nichts an. Sie melden nur beim Broker das Interesse an aneim Topic an. Bis Sie das Interesse wieder abmelden, schickt der Broker alle Pakete zu diesem Topic an den interessierten Client. (Egal von welchem anderen Client sie gepublisht werden).
• Das einzige was dem was Du möchtest nahe kommt, ist das Retain Flag. Damkt signalisiert ein Client, dass Pakete die er publiziert vom Broker gespeichert werden und an alle Clients die dieses Topic subscriben weitersendet, auch wenn das nach dem originären publizieren ist. Der Broker verteilt dieses Paket dann aber auch weiter, wenn der ursprünloche Publizierer nicht mal mehr online ist. Das macht der Broker, bis er ein neues Telegramm zu dem Topic erhält. Das Retain Flag ist also mit Vorsicht zu genießen.

Was Dich am Rtain Flag störte, war, dass beim Retain Flag störte, war dass das Haupt-shng bei jedem Neustart die Werte als neue Werte interpretierte. Das lässt sich durch das cache Attribut verhindern. Allerdings bekommst Du dann immer noch Daten, selbst wenn das Heizungs-shng komplett ausgefallen sein sollte.

Der einzig saubere Weg ist eine Art Ping an das Heizungs-shng, damit es die benötigten Daten erneut schickt.

[gama]

Gibt es zu dem "ping" bzw. zyklischen request ein best practice?

Ich habe auch das Problem, dass ich das topic "heizung/status"abonniert habe. Der Heizungsclient schickt jedoch nur updates, wenn ich das triggere. Also muss ich auf das topic "heizung/status/get" einen Wert senden. Der Heizungsclient aktuallisiert daraufhin "heizung/status" und ich habe einen aktuellen Status.

Jetzt braucht man 2 items um den Status aktuell zu halten, einer hält den letzten Wert und hat "heizung/status" abonniert, das andere item schreibt per cycle regelmäßig auf "heizung/status/get" um einen poll auszulösen.

Wie geht man bei MQTT allgemein mit poll requests um? Ich kenn mich da leider zu wenig aus...
Vielleicht wäre es auch hilfreich ein mqtt_topic_poll zu haben, dann könnte man sich den Aufwand mit dem zweiten Item sparen.

[Msinn]

Wie geht man bei MQTT allgemein mit poll requests um?

Gar nicht. Die Idee von MQTT ist, dass Devices ihre Infos publizieren und wer möchte, darauf lauscht. Ein Polling ist prinzipiell in MQTT nicht vorgesehen. Man kann höchstens auf einem Topic ein "Bitte meldet euch" senden, worauf die Device dann reagieren können.

Ein Polling ist nicht möglich, da es zwischen Devices keine 1-zu-1 Kommunikation gibt. Ein Topic kann von einer beliebigen Anzahl Devices gesendet werden und auf ein Topic kann eine beliebige Anzahl von Devices hören.

Man kann nur sicherstellen, dass ein Topic nur von einem Device geschrieben wird und dass nur ein Device auf ein entsprechendes "Ping-Topic" reagiert. Das Reagieren auf ein solches "Ping-Topic" muss aber in der Software des Devices implementiert werden. MQTT als Übertragungsprotokoll hilft einem da nicht weiter.

Falls (wie bei @TCr82) der Daten liefernde Client auch ein SmartHomeNG System ist, kann man dass natürlich über entsprechende Items und eval/on_update/on_change Ausdrücke implementieren.


Nachtrag:
Tasmota Devices lösen z.B. das Problem, indem sie wichtige Informationen als "Telemetry" periodisch senden. man kann dort über ein MQTT Topic (oder in der Web Oberfläche des Devices) einstellen, wie häufig das passieren soll.