Neues MQTT Plugin

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

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]

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

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

Ich verstehe. D.h. diese Platzhalter bei den Topics sind dann auch mit Vorsicht zu benutzen, weil jedes Device komplett anders strukturiert sein könnte.

Das Tasmota Plugin habe ich gesehen, ich wollte aber den Broker eher systemunabhängig machen und nciht nur SHNG bedienen.

[Msinn]

Wo siehst Du beim MQTT Broker denn eine SmartHomeNG Abhängigkeit?

Ich glaube Du bist noch in einer falschen Gedankenwlt verhaftet. Mach in Deinem Gehirn mal einen Werks-Reset und vergiss alles zu Device-Adressierung, dass Du von KNX, IP oder ähnlichen Protokollen kennst.

Hier werden Informationen addressiert. Wenn Du zum Beispiel bei der Temperaturmessung in einem Raum Redundanz herstellen und 5 Sensoren implementieren möchtest, dann werden diese 5 Devices einfach alle das selbe Topic senden und im System, welches die Daten verarbeitet kommen nur 5 mal so viele Temperaturmeldungen an. Das System muss dabei nicht wissen, dass die Messungen von 5 verschiedenen Devices kommen.

Aber was wir hier diskutieren hat mit dem MQTT Plugin nichts zu tun. Wir sind in der Diskussion bei den Basics des MQTT Protokolls und dessen Nutzung.

[awknx]

Ich sehe beim Broker keine Abhängigkeit, das bezog sich auf das Tasmota Plugin.

Ich hab jetzt mal den Werksreset gemacht, hatte das aber vorher auch schon so verstanden wie dein Beispiel. Also nicht von den Devices her denken, sondern von den Informationen/Daten (Topics). Aber genau da spielt das doch dann eine Rolle. Wenn ich z.B. alle Temperaturen im Haus haben (abonnieren, subscriben) will, ist das doch wesentlich konfortabler, wenn alle Devices diese Information (Topic) gleich bezeichnen und dann z.B. "temperature" senden (veröffentlichen, publishen) und nicht ein Device das mit "temp" bezeichnet, das nächste mit "temperatur", das dritte mit "t" usw. und ich ev. sogar dem Device (Publisher) einen Struktubaum geben kann (z.B. myhome/innen/wohnen/boden/temperatur).

Das ist doch von den SHNG items nicht so weit weg. Da beziehe ich ja auch Informationen (z.B. Schalter an/aus, Temperatur). Es kommen da halt noch die Aktionen dazu (z.B. Schalten). Oder brauche ich da nochmal einen Werksreset oder sogar eine andere Firmware ;-)

Mit dem Plugin hat das nur am Rande zu tun, schadet aber doch auch nichts, wenn sich jemand, der das Plugin nutzen will (und vorher noch nicht an anderer Stelle schon mit MQTT was gemacht hat) dazu diese Gedanken macht, oder?

Viele Grüße
Andi

[Msinn]

Ich sehe beim Broker keine Abhängigkeit, das bezog sich auf das Tasmota Plugin.

Auch da verstehe ich nicht welche Abhängigkeit Du meinst. Die Tasmota Devices werden ja nicht anders konfiguriert, nur weil Du das Tasmota Plugin nutzt. Die Devices "sprechen" ja weiterhin mit allen anderen Devices unverändert über MQTT.

Mit dem Plugin ersparst Du Dir nur die Arbeit, die Nutzdaten und Stati mit Hilfe diverse eval Ausdrücke und/oder Logiken heraus zu operieren.

schadet aber doch auch nichts, wenn sich jemand, der das Plugin nutzen will (und vorher noch nicht an anderer Stelle schon mit MQTT was gemacht hat) dazu diese Gedanken macht, oder?

Nö

[gama]

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.

Das habe ich schon verstanden, dass MQTT kein Polling unterstützt und rein auf Events reagiert.
Jedoch habe ich einen konkreten Fall mit ebus von Vaillant. Der "sehr alte" ebus ist für manche Signale auf polling ausgelegt. Nicht schön, aber war damals halt so.
Der Deamon "ebusd" holt die Wert vom bus, sofern diese angefordert werden. Die neue Version unterstützt MQTT, was ziemlich cool ist - jedoch müssen über MQTT auch die Leseanforderungen aktiv angestossen werden. ebusd verlangt als work around hierzu den Signal-topic mit einem angehängten "/get". Analog kann der Wert mit angehängtem "/set" gesetzt werden.

Aktuell löse ich das so:

status01:
  name: HMU Status01
  type: dict
  visu_acl: ro
  mqtt_topic_in: "devices/ebusd/hmu/Status01"

  poll:
    type: bool
    cycle: 300 = true
    enforce_updates: true
    mqtt_topic_out: "devices/ebusd/hmu/Status01/get"

Wenn das Problem auch mit anderen MQTT Clients existiert, dann wäre hier vielleicht ein "mqtt_topic_poll" sinnvoll, um sich die vielen "poll-items" zu sparen.

[Msinn]

Wenn das Problem auch mit anderen MQTT Clients existiert, dann wäre hier vielleicht ein "mqtt_topic_poll" sinnvoll, um sich die vielen "poll-items" zu sparen.

Das kann man nicht verallgemeinern, jedes MQTT Device eine andere Topic Struktur hat und ausser Deinem ebus Device im Zweifelsfall kein Device das Sub-Topic get kennt. (Mir ist bisher zumindest kein Device über den Weg gelaufen, welches das unterstützen würde.

[gama]

Ok, verstanden. Dann lasse ich das so.

Jetzt ist mir noch was aufgefallen:
Ein item besitzt mqtt_topic_in und mqtt_topic_out zwei unterschiedliche topics. Wird auf mqtt_topic_out gesendet, wenn über mqtt_topic_in ein update reinkommt?

Also ich starte SHNG, das item steht auf 0, dann kommt über MQTT ein Wert und item wird auf 99 gesetzt. Wird dieser Wert dann auch auf mqtt_topic_out gesendet oder lässt sich das irgendwie unterbinden?

[Msinn]

Ein item besitzt mqtt_topic_in und mqtt_topic_out zwei unterschiedliche topics. Wird auf mqtt_topic_out gesendet, wenn über mqtt_topic_in ein update reinkommt?

Nein, wie kommst Du darauf? Für jedes Plugin gilt, dass es nicht auf Item Veränderungen die es selbst ausgelöst hat reagieren soll.

[loeserman]

Hallo zusammen,
irgendwie bekomme ich das Plugin mqtt nicht zum laufen. Beim Start von shNG kommt die Meldung

2021-02-13 15:55:22 ERROR plugins.mqtt Module MQTT could not be initialized. The plugin is not starting
2021-02-13 15:55:22 ERROR lib.plugin Plugins: Plugin 'mqtt' initialization failed, plugin not loaded

In der plugin.yaml steht

mqtt:
plugin_name: mqtt

Der broker läuft. Das sagt das WebInterface

Broker für die MQTT Unterstützung

mosquitto v1.5.7

● mosquitto.service - Mosquitto MQTT v3.1/v3.1.1 Broker
   Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2021-02-13 15:16:56 CET; 43min ago
     Docs: man:mosquitto.conf(5)
           man:mosquitto(8)
 Main PID: 1937 (mosquitto)
    Tasks: 1 (limit: 2346)
   Memory: 1.4M
   CGroup: /system.slice/mosquitto.service
           └─1937 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf

Bei einem Item habe ich einfach mal folgendes geschrieben

		[[[GLASSCHRANK]]]
			name = R16 Steckdose Glasschrank (G12 Sued)
			type = bool
			visu_acl = rw
			cache = True
			knx_dpt = 1
			knx_listen = 3/7/14
			knx_send = 3/0/14
			knx_init = 3/7/14
			sim = track
			mqtt_topic_in = 'IN_GLASSCHRANK'
			mqtt_topic_out = 'OUT_GLASSCHRANK'

Hat einer eine Idee?



SmartHomeNG Version:
1.8.0.master (1bee400c) in /usr/local/smarthome (tags/v1.8)

SmartHomeNG Plugins Version:
1.8.0.master (cd72128d) in /usr/local/smarthome/plugins (tags/v1.8)

[Onkelandy]

Hast du das modul aktiviert?
In module.yaml:

mqtt:
    module_name: mqtt

[loeserman]

Nein, das hatte ich nicht. Nun geht es.
Prima vielen Dank!

Eine Frage noch. Kann ich die topic_in / _out benennen wie ich will, oder gibt es da eine besondere Konvention, die ich besser berücksichtigen sollte?