Neues MQTT Plugin

[Msinn]

Mir ist nicht klar was Du genau tun willst.

Ich habe Deienen Post so verstanden, dass Bei Dir SmartHomeNG über das helios Plugin mit dem Raspberry Pi kommuniziert. Du möchtest jetzt Werte von Items, die Du über das helios Plugin empfangen hast, über das mqtt Plugin versenden.

Um Dir helfen zu können, wie die Daten versendet werden müssen, muss ich etwas über den geplanten Empfänger der Information wissen.

Zum einen musst Du wissen, auf welches Topic der andere Client „lauscht“. Wenn Du nicht mit genau diesem Topic sendest, wird der Broker das Paket nie an den anderen Client ausliefern.

zum anderen musst Du wissen, wie der andere Client die Daten erwartet. Das MQTT Protocol kennt keine Datentypen. Die Payload des Paketes ist immer eine Folge von Bytes. Die beiden Clients die über MQTT kommunizieren (hier: SmartHomeNG und der andere Client über den Du nichts geschrieben hast), müssen sich einig sein, wie diese Bytefolge zu interpretieren ist (z.B. ein String, eine Integer, ein Float Wert, ...)

[msteffel]

Hallo zusammen,

ich scheitere jetzt schon seit längerem an der Herausforderung, dass ich gerne die Werte verschiedener Items per MQTT senden und empfangen möchte.
Leider komme ich mit allen Beispielen nicht weiter, vermutlich weil ich ein blutiger Anfänger bin, was das betrifft.

Mein Ziel:
Ich nutze einen Raspberrypi, der per RS485 mit einer Helios Lüftung verbunden ist. Der liest und schreibt verschiedene Parameter über das "helios" Plugin.
Zwei dieser Items heißen z.B.: ventilation.bypass.is_on und ventilation.rs485._incoming_temp
Das MQTT Plugin ist installiert und zeigt mir an, dass es den MQTT Broker sieht und auch, dass der Nachrichten schickt.

Kann mir bitte jemand einen Tipp geben, was ich tun muss, um z.B. den Wert des items ventilation.rs485._incoming_temp per MQTT zu senden oder den Wert des items ventilation.bypass.is_on durch eine empfangene MQTT Nachricht zu setzen?

Ich krieg das irgendwie nicht auf die Reihe und das frustriert mich schon langsam so sehr, dass ich daran denke, das ganze Projekt abzubrechen.
Schonmal vielen Dank für Eure Mühe und Tipps.

Viele Grüße

Martin.

[beckerth]

Kurze Rückmeldung: funktioniert. Danke! ;-)

[Msinn]

Ja, Du musst nur bedenken, dass in MQTT keine Datentypen kennt, sondern dass generell nur eine Folge von Bytes übermittelt wird. Damit Absender und Empfänger sich verstehen, müssen sie sich einig sein, wie die Payload des MQTT Telegramms zu interpretieren ist.

Um über json artige Strukturen zu kommunizieren, muss die json Struktur in einen String gewandelt werden, der dann als Payload übertragen wird. Dein Item muss als Wert also den kompletten Json String enthalten.

Nachtrag: Der Unterschied ist, dass Du im Moment über SmartHomeNG versuchst eine Python Datenstruktur zu versenden, während MQTT.fx einen String sendet. Das siehst Du auch an der Fehlermeldung die Du gepostet hast: Dort versucht java.io.StringReader einen String zu lesen und als Json zu interpretieren. Da kein String gesendet wurde, geht das natürlich daneben.

Eine Möglichkeit für Dich ist, gleich einen String in der Logik zu definierten, oder über json.dumps() die Json Struktur in einen String zu wandeln.

# rockrobo_ini.py
sh.Rockrobo( '{"command": "zoned_cleanup", "zone_ids": ["Bad"]}' )

sollte funktionieren, wenn Du das Item als type: str definierst.

[beckerth]

Servus Jungs,

um Valetudo, welches auf dem Xiaomi Gen. 1 Staubsaugerroboter läuft, anzusteuern müsste ich JSON Pakete per MQTT verschicken. Valetudo intern wird das ankommende MQTT Paket mittels JSON.parse() zerlegt. Deshalb sollte die Reihenfolge der übermittelten Parameter egal sein!? Sicher bin ich mir allerdings mit diesem Punkt nicht.
Zu meiner Implementierung:

Item erstellt:

Rockrobo:
    type: dict
    mqtt_topic_out: 'valetudo/rockrobo/custom_command'
    #eval: True if sh.ZigbeeSwitch.click.value() == 'left' else False
    enforce_updates: true

Logik erstellt:

#!/usr/bin/env python3
# rockrobo_ini.py
sh.Rockrobo({
    "command": "zoned_cleanup",
    "zone_ids":[
        "Bad"
    ]
    })

Logik manuell gefeuert und mit MQTT.fx die Topics beobachtet:

mqtt_shng.PNGmqtt_json_decode.PNG

--> Paket wird gesendet. Wird aber leider nicht von Valetudo erkannt. "Double Quotes" werden in ' umgesetzt. Siehe JSON Dekoder von MQTT.fx.



Wie es ausschaut wenn ich das Paket über MQTT.fx absetzt (funktioniert!)

mqtt_mqttfx.PNG

--> So funktioniert es. Reihenfolge der Parameter ist wie original angegeben und die double quotes bleiben erhalten.

Kann ich irgendwie JSON Kompatible Pakete per MQTT absetzen?

Danke.

Tommi

[SMarcus]

Da hatte ich auch schon rumprobiert. Habs nochmal versucht und die Zeile auskommentiert - aber er hat sich wieder abgemeldet:

Mär 15 20:38:41 smarthome mosquitto[1659]: New connection from 127.0.0.1 on port 1883.
Mär 15 20:38:41 smarthome mosquitto[1659]: New client connected from 127.0.0.1 as smarthome (c1, k60).
Mär 15 20:40:19 smarthome mosquitto[1659]: Client smarthome has exceeded timeout, disconnecting.
Mär 15 20:40:19 smarthome mosquitto[1659]: Socket error on client smarthome, disconnecting.

Ich hab mal das SHNG log angehängt. Interessant ist, dass er sich 2x anmeldet, nur das erste Mal wird vom Broker bestätigt:

2019-03-15  20:38:41 INFO     plugins.mqtt      Connecting to broker '127.0.0.1:1883'. Starting mqtt client 'smarthome'
.......
2019-03-15  20:38:50 INFO     plugins.mqtt      Connection returned result 'Connection Accepted.' (userdata=None)
.......
2019-03-15  20:38:50 INFO     plugins.mqtt      Connected to broker 'mosquitto version 1.4.10' at address 127.0.0.1:1883

EDIT: Blödsinn - Die letzte Zeile gehört zur Bestätigung. Er meldet sich nicht 2x an.


Noch eine Idee?

Gruss
Marcus

[Msinn]

Nimm mal das localhost aus der Config. Das sieht da seltsam aus. Wenn Du nichts einträgst, wird 127.0.0.1 verwendet (was localhost entspricht). Du kannst auch host: 127.0.0.1 schreiben. localhost ist da nicht vorgesehen.

[SMarcus]

Hallo, ich versuche grade das Gigaset-Elements System über MQTT einzubinden.

Eigendlich läuft MQTT auf dem SHNG schon für den Landroid Mäher (eigendlich, weil der Mäher grade Winterschlaf macht) - aber als ich mich grade an die Erweiterung für das Gigaset-Elements System machen wollte, viel mir auf dass sich das MQTT Plugin immer nach 90 Sekunden vom MQTT Broker abmeldet:

smarthome@smarthome:~$ sudo systemctl status mosquitto.service
● mosquitto.service - LSB: mosquitto MQTT v3.1 message broker
   Loaded: loaded (/etc/init.d/mosquitto; generated; vendor preset: enabled)
   Active: active (running) since Fri 2019-03-15 12:44:47 CET; 6h ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1648 ExecStop=/etc/init.d/mosquitto stop (code=exited, status=0/SUCCESS)
  Process: 1654 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/mosquitto.service
           └─1659 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf


Mär 15 18:44:58 smarthome mosquitto[1659]: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.
Mär 15 19:00:17 smarthome mosquitto[1659]: New connection from 127.0.0.1 on port 1883.
Mär 15 19:00:17 smarthome mosquitto[1659]: New client connected from 127.0.0.1 as smarthome (c1, k60).
[MARKIEREN]Mär 15 19:01:55 smarthome mosquitto[1659]: Client smarthome has exceeded timeout, disconnecting.
Mär 15 19:01:55 smarthome mosquitto[1659]: Socket error on client smarthome, disconnecting.[/MARKIEREN]

SHNG auf Master 1.5.1.

mqtt:
    class_name: Mqtt
    class_path: plugins.mqtt
    host: 'localhost'
    port: 1883
    qos: 0

Habs auch schon mit der Develop-Version vom MQTT-Plugin probiert, macht keinen Unterschied.

Nach 4 Stunden Ursachenforschung bin ich jetzt planlos.

Hat jemand Ideen?

Gruss
Marcus

[Msinn]

Da denke ich noch drauf rum.

[henfri]

Hallo,

was sagst du denn hierzu:

Ich bin nicht sicher, ob das eine gute Idee ist....

Es wird z.b. nicht funktionieren, wenn man ein Item hat, welches in zwei Plugins verwendet wird:
Plugin1: True=Wahr
Plugin2: True=open
core: True=True
Vielleicht ist der Fall auch zu sehr konstruiert...
Außerdem hielte ich es für verwirrend, wenn ein Item mit True beschrieben und dann den Wert Wahr annimmt.

Gruß,
Hendrik

[Msinn]

Ansonsten halte ich die Lösung mit dem Dictionary für das Mapping für eine gute Lösung. Was mir daran noch nicht gefällt ist, dass nicht definiert ist, was passieren soll wenn im Dictionary kein Key mit dem aktuellen Wert gefunden wird:
item_mapping: "{2: 'Wahr', 1: 'Falsch'}"
Was ist, wenn jetzt das Item den Wert 0 erhält?

Genau: Das ist noch nicht definiert. Man könnte z.B. definieren, dass der Wert dann unverändert übernommen wird oder man könnte definieren, dass dann ein definierter Standardwert verwendet wird...

Das Zweite ist wahrscheinlich im Betrieb weniger fehlerträchtig. Aslo etwa so:

item:
    mapping: "{2: 'Wahr', 1: 'Falsch', 'default': 'Falsch'}"

Zu definieren wäre auch ob das Mapping unidirektional oder bidirektional sein soll. Im zweiten Fall müsste shNG wohl beim Startup prüfen, ob die Mapping-Tabelle (abgesehen vom Default Wert) eineindeutig ist.

[henfri]

Hallo nochmal,

ich mache mir gerade Gedanken zum Mapping auf Item-Ebene.
Ich bin nicht sicher, ob das eine gute Idee ist....

Es wird z.b. nicht funktionieren, wenn man ein Item hat, welches in zwei Plugins verwendet wird:
Plugin1: True=Wahr
Plugin2: True=open
core: True=True

Vielleicht ist der Fall auch zu sehr konstruiert...
Außerdem hielte ich es für verwirrend, wenn ein Item mit True beschrieben und dann den Wert Wahr annimmt.

Ansonsten halte ich die Lösung mit dem Dictionary für das Mapping für eine gute Lösung. Was mir daran noch nicht gefällt ist, dass nicht definiert ist, was passieren soll wenn im Dictionary kein Key mit dem aktuellen Wert gefunden wird:
item_mapping: "{2: 'Wahr', 1: 'Falsch'}"
Was ist, wenn jetzt das Item den Wert 0 erhält?

Gruß,
hendrik

[henfri]

Hallo,

ich verstehe das.
Wo -außer bei MQTT- besteht das Problem denn noch? Wenn es nur wenige Plugins betrifft, hielte ich den Weg im Plugin (=in den Plugins) für praktikabel.

dass man einfach Device Protokolle als Plugins implementieren kann ist ein Punkt den ich selber dringend umsetzen möchte.

Das ist mir ein zu schweres Geschütz -wenn es die einzige Lösung ist. Das können die Wenigsten.
Ich denke, dass viele Device-Protokolle über ein einfaches Mapping möglich sind. Und das geht über ein Dictionary -ob nun im Item oder im MQTT-Plugin.
Somit würde ich mir wünschen, dass beides möglich ist (Plugin, welches das Device-Protokoll implementiert und Mapping).

Gruß,
Hendrik

[Msinn]

Ich verstehe schon, dass Du einen Beitrag leisten möchtest. Du hattest die Frage gestellt, was "wir" davon halten. Ich als Teil von "wir" habe meine Meinung dazu geäußert. Meine Einschätzung ist für Dich vielleicht nicht motivierend, aber Du hattest danach gefragt .

Bei solchen Features, wie das von Dir beschriebene, ist es wichtig zu schauen ob das Feature an der richtigen Stelle implementiert wird. Setzt man zu tief an, ist so ein Feature an schlimmstenfalls in diversen Plugins zu implementieren und wird dann (wie die Realität zeigt) häufig leicht unterschiedlich implementiert (was für den Anwender auch nicht übersichtlich ist). Setzt man zu hoch an, kommt man vielleicht be genauerem durchdenken zu keiner praktikablen allgemeinen Lösung und muss gedanklich tiefer ansetze (wobei trotzdem gilt, dass es sinnvoll ist möglichst hoch anzusetzen).

Im konkreten Fall ist MQTT nur das Transport-Protokoll. Das eigentliche Device Protokoll ist auf MQTT aufsetzend in den Topics bzw. Payloads implementiert.

Daher sehe ich 3 verschiedene Ebenen auf denen man prinzipiell ansetzen könnte:

• SmartHomeNG Core
• Device Protokoll
• MQTT Protokoll

Für mich wäre der Ansatz im Device Protokoll die richtige Ebene, wobei für SmartHomeNG dann immer darauf zu achten ist, dass analoge Problemstellungen mit anderen Devices analog implementiert werden.

• Eine Implementierung im Core ist vermutlich für Dich nicht praktikabel. Da ist der Ansatz mit einem Hilfs-Item vermutlich der beste. Allerdings wäre es auch denkbar, dass man die Funktionalität als zusätzliches Feature zu einem Item implementiert. Denkbar wäre eine Mapping Funktionalität für Items. Quasi eine Tabelle die festlegt bei welchem Eingangswert das Item auf welchen Ausgangswert gesetzt wird. Diese Funktionalität kann man zwar auch über eval abbilden, es geht aber sicherlich übersichtlicher.
• Eine Implementierung im MQTT Plugin setzt zu tief an, da das MQTT Protokoll als Transport-Protokoll nicht weiss welche Informationen es transportiert.

Eine Ebene "Device Protokoll" gibt es aktuell nicht. Aktuell ist das Device Protokoll in der Konfiguration von MQTT-Attributen von Items und von Hilfs-Items implementiert.


Die von mir skizzierte Re-Implementierung von MQTT in einer Art, dass man einfach Device Protokolle als Plugins implementieren kann ist ein Punkt den ich selber dringend umsetzen möchte. Es macht jedoch keinen Sinn, dieses zu tun wenn die Version des MQTT Protokoll direkt vor der Tür steht. Dafür ist es jedoch notwendig, dass sowohl mosquitto, als auch der eclipse paho Client für Python in einer MQTT v5 kompatiblen Version zur Verfügung stehen. Beides ist bisher nicht der Fall, auch wenn nach der Verabschiedung des Standards damit gerechnet wurde, dass in Q3/Q4 2018 die entsprechende Software zur Verfügung stehen würde.

Eine Unterstützung von MQTT v5 ist für mosquitto v1.6 (das kommende Release) angekündigt. Ein geplantes Release Datum für den Paho Python Client kenne ich noch nicht.

Wenn Du eine Lösung zum jetzigen Zeitpunkt implementieren möchtest bleibt also nur eine Beschreibung über Hilfs-Items oder die Implementierung im MQTT Plugin. Wobei die Implementierung im MQTT Plugin das Risiko birgt, dass das bai der Weiterentwicklung so nicht mehr reinpasst, da es eben keine MQTT Funktionalität ist. Darauf wollte ich mit meinen Antworten hinweisen.

Du könntest auch überlegen, ob/wie eine Mapping Funktionalität für Items aussehen könnte und diese Beschreibung ls Feature Request einstellen. Der Vorteil wäre, dass bei der Umsetzung alle profitieren, und nicht nur Nutzer des MQTT Plugins.

[henfri]

Hallo,

sorry....
Aber ich versuche hier einen Beitrag zu leisten. Ich sitze hier ja nicht und fordere, sondern mache einen Vorschlag mit Code.
Ich verstehe, wenn du wenig Zeit hast, aber es ist nicht motivierend.

Das Problem mag nicht MQTT spezifisch sein. Aber ich sehe auch keine zentrale Stelle, an der es besser gelöst werden kann.
Und die Variante mit Hilfsitems ist einfach unübersichtlich. Vielleicht nicht für den Profi, aber für den Anwender.

Gruß,
Hendrik