Neues MQTT Plugin

[Sisamiwe]

siehe hier

[Energiezwerg]

Ich habe den Zugriff auf die KNX Szenen mit einem Hilfs-item umgesetzt.

# Wohnung.OG.Hobby.PCRGBWScene
Hobby:
   PCRGBWScene:
   name: PC RGBW
   type: scene
   knx_dpt: 5
   knx_listen: 11/0/6
   knx_send: 11/0/6
   mqtt_in:
      type: num
      mqtt_topic_in: Hobby/RGBPC/in
      on_change: .. = value
   mqtt_out:
      type: num
      mqtt_topic_out: Hobby/RGBPC/out
      eval_trigger: ..
      eval: sh...()

[Energiezwerg]

Zur shng Steuerung vom esp32 nutze ich das mqtt plugin. Bei items mit dem Datentyp: num und bool funktioniert das auch sehr gut.
Verwende ich es f. Szenen, werden alle integer Werte als false interpretiert. Offensichtlich wird der Datentyp f. Szenen nicht richtig interpretiert.

Jetzt habe ich gesehen, dass für Szenen das

subscribe_topic()

verwendet werden kann.

1. muss ich das dafür nutzen?
2. kann ich das auch in item Definitionen nutzen?
Oder was mache ich falsch?

item mit Scenen Definition

# Wohnung.OG.Hobby.PCRGBWScene
Hobby:
   PCRGBWScene:
      name: PC RGBW
      type: scene
      knx_dpt: 5
      knx_listen: 11/0/6
      knx_send: 11/0/6
      mqtt_topic_in: Hobby/RGBPC
      mqtt_topic_out: Hobby/RGBPC

Schon mal vielen Dank für Eure Hilfe!
Andreas

[Onkelandy]

Kannst benennen wie du willst. Ich mach das nach der Hierarchie der Items, zB duw/status/temperatur

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

[Onkelandy]

Hast du das modul aktiviert?
In module.yaml:

mqtt:
    module_name: mqtt

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

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

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

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]

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]

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ö

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

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