Neues MQTT Plugin

[Msinn]

Da die Devices eigene Vorstellungen haben wie ihre Topics strukturiert sind, wirst Du damit keinen Erfolg haben falls Du eine größere Zahl unterschiedlicher Devices nutzt.

Du darfst auch nicht vergessen, dass MQTT nur ein Transport Protokoll ist und kein Nutzdaten Protokoll. Bis inclusive MQTT Protokoll v3.1.1 ist die Payload eines Telegramms neue ein Array of Byte und damit unstrukturiert.

Damit gibt es auch keine Regel, ob Devices bestimmte Informationen als Telegramme mit unterschiedlichen Topics senden oder mit nur einem Topic und die Daten in der Payload weiter strukturieren.

Es macht daher auch keinen Sinn ein Tasmota Device statt mit dem Tasmota Plugin mit dem MQTT Plugin zu steuern, es sei denn Du möchtest eine steile Lernkurve nehmen. Und das was Du dabei lernst kannst Du mit hoher Wahrscheinlichkeit nur auf Tasmota Devices anwenden, weil das nächste Device es völlig anders macht. So hat die Topic Struktur von Tasmota Devices z.B. keine Ähnlichkeit mit der Topic Struktur von Shelly Devices, auch wenn beides 230V Zwischenstecker sind...

[awknx]

Na ja, ich dachte daran , nicht nur die Tasmota einzubinden, sondern das Ganze universell wie bei KNX oder den SHNG Items zu strukturieren.

[Msinn]

Wozu willst Du eine Topic Struktur definieren? Du brauchst doch nur die oberste Ebene festzulegen (einen eindeutigen Namen für jedes Tasmota Device). Die Unterstruktur definiert Tasmota doch schon.

[awknx]

Da ich mich nun auch endlich mal mit MQTT befasse (meine Tasmota sind bereits mit KNX eingebunden, aber ich möchte mal wieder über den Tellerrand schauen), habe ich in einem ersten Schritt den Broker (Mosquitto) aufgesetzt und den Tasmotas das Sprechen beigebracht. Das Ganze sehe ich nun auch schön im MQTT Explorer.

Anders gesagt, in das Thema einbischen eingelesen und gebastelt. So weit so gut :-)

Die große Frage, bevor ich da weiter mache ist nun - wie definiert man sich von Anfang an eine sinnvolle Topic- Struktur? Wie macht ihr das bzw. habt ihr da ein paar Praxisbeispiele für die Kombi KNX-SHNG-SV?

Viele Grüße
Andi

[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.

[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]

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.

[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]

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]

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]

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]

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]

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]

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

[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.