Neues MQTT Plugin

[Msinn]

In YAML Dateien macht es einen Unterschied, ob Du einen String in Single-Quotes oder in Double-Quotes einschließt. Wenn Du Double-Quotes verwendest, musst Du zumindest die im String verwendeten Double Quotes escapen. Probiere mal

"{\"segment_ids\": [\"8\"],\"iterations\": 1}"

Dass Du beim anderen Versuch die YAML Datei nicht speichern konntest, liegt daran, dass das dann kein gültiges YAML war. Vermutlich wurden die geschweiften Klammern interpretiert. In dem Fall müsstest Du die auch escapen.

Das hat aber im engeren Sinne nichts mit MQTT zu tun, sondern damit, wie Du die Daten in die YAML Datei schreibst.

[mayrjohannes]

Hat jemand einen Tipp wie ich es schaffe ein MQTT in JSON Format abzusetzten. Hintergrund: mein valetudo will für das reinigen eines Segments ein JSON (siehe auch https://valetudo.cloud/pages/integra...tioncapability).

Ich hätte das jetzt folgendermaßen probiert:

                cleanwintergarten:
                    type: bool
                    visu_acl: rw
                    on_update:
                     - .cleanwintergartenhelper = 'temp'
                    cleanwintergartenhelper:  
                        type: str
                        mqtt_topic: 'robots/Z10/MapSegmentationCapability/clean/set'
                        #id 8 .. wintergarten
                        eval: '{"segment_ids": ["8"],"iterations": 1}'
                        enforce_updates: true        ​

Also ein bool item welches ich später per knx triggern kann. Dieses setzt bei einer Änderung das cleanwintergartenhelper item auf einen temporären Wert und eval überschreibt diesen mit dem String der den Roboter starten würde.

Leider bekomme ich dann nur diese Meldung "Item glob.robots.vacuum.segments.cleanwintergarten.clea nwintergartenhelper: value "{'segment_ids': ['8'], 'iterations': 1}" does not match type str. Via mqtt None".

Wie könnte man das korrekt lösen?

Ich hätte auch versucht den String bereits bei on_update des items cleanwintergarten zu übergeben. Da konnte ich das yaml file im Backend aber nicht mal mehr speichern.

Besten Dank

[Msinn]

Aber wenn in der SHNG Dokumentation erklärt wäre, wie die Broker Architektur implementiert ist und funktioniert,

Das ist genau das Problem.

Ich muss davon ausgehen können, dass jemand der MQTT einsetzt und SmartHomeNG daran anschließen will, auch weiss wie MQTT funktioniert. Wir haben im SmartHomeNG Team einfach nicht die Kapazitäten, um so etwas für die Technologien zu dokumentieren, die an SmartHomeNG angeschlossen werden können.

Mit Deiner Begründung müssten wir in SmartHomeNG analog zu Deinem Wunsch MQTT zu dokumentieren, das gleiche für für weitere Technologien (KNX, Homematic, Hue, Modbus, Homeconnect, 1-Wire, EnOcean und ähnliches) tun. Du sieht hoffentlich, welchen Aufwand das generieren würde. So wünschenswert das ist, sehe ich nicht, dass das leistbar ist.

Ist das so sinnvoll, wie ich es realisiert habe? oder macht man das anders:

Nein, das ist so nicht sinnvoll. Dafür gibt es das MQTT Plugin. In Deinem Beispiel würdest Du einfach ein Item anlegen. Bei Wertänderung des Items wird dann der Wert unter dem angegebenen Topic publiziert:

myitem:
    type: str
    mqtt_topic_out: <hier gehört das Topic rein, dass Du der Funktion in 'typeOfValue' übergibst)

Insgesamt gibt es mehrere Plugins, die über MQTT kommunizieren. Das mqtt Modul implementiert den Transport Layer, während die Plugins sich um den Inhalt der Payload kümmern. Bisher sind das die Plugins mqtt, tasmota und shelly. mqtt ist ein Plugin zur generischen Implementierung von beliebigen Payloads.

[whe]

ja Doku ist ein grundsätzliches Problem in der Software Branche.
ich denke aber bei SHNG müssen wir mehr an die Anwender als an die Code-Freaks denken.
Praktische Tipps und how-too guides helfen mehr als die Dokumentation von Parametern.

Aber das hier war ganz klar mein Fehler, dass ich nicht mehr wusste und nicht kontrolliert habe, was läuft.

Aber wenn in der SHNG Dokumentation erklärt wäre, wie die Broker Architektur implementiert ist und funktioniert, würde ich als Laie damit besser zurecht kommen.
z.B. habe ich vor über einem Jahr schon mit dem plugin gekämpft und weiß auch heute immer noch nicht, wie man eine Anwendung sinnvoll anbindet.

Meine Heizung z.B. liefert einen Sack voll Parameter, die ich an SHNG übergebe.
Ist das so sinnvoll, wie ich es realisiert habe? oder macht man das anders:

    # Write state to SmartHomeNG
    def StateToMQTT (self,typeOfValue,value):
        client = mqtt.Client()
        client.connect("localhost", 1883)
        client.publish(typeOfValue, str(value))
        client.disconnect()
        # print (typeOfValue, ":", str(value))

Mein Wechselrichter liefert über SBFSpot ein JSON Dokument, was ich dann in einer LOGIK parse.

[Msinn]

Da Du bereits der Zweite bist, der über die Änderung bei der Default-Konfiguration von mosquitto stolpert, könnte ich das evtl. in die Doku aufnehmen.

Insgesamt bin ich eher auf der sparsamen Seite, wenn es darum geht Drittsoftware in der SmartHomeNG Doku zu dokumentieren. Für so etwas ist die Doku der Drittsoftware ausführlicher und sicherlich auch aktueller.

Bei MQTT gibt es mehr als eine Hand voll verschiedene Broker und deren Spezialitäten in der SmartHomeNG Doku aufzuführen würde sicherlich zu weit führen. Hier geht es ja sogar um Unterschiede zwischen verschiedenen Versionen eins Brokers.

[whe]

Die neueren Mosquitto Versionen müssen explizit konfiguriert werden, um Messages von anderen Hosts zu empfangen. Die älteren Mosquitto Versionen waren da in der Default Konfiguration offener.

kaum macht mans richtig schon geht's.
auf dem Rechner läuft ein Mosquitto Broker; der Service war auch aktiv.
sonst könnte ja auch meine neue Anwendung nicht funktionieren.
es liegt tatsächlich an der Version:
auf dem alten Rechner läuft ein mosquitto 1.5.7 und auf dem Neuen mosquitto 2.0.11
ab der version 2.0 benötigt man in der .conf 2 zusätzliche Angaben für einen remote Zugriff:

listener 1883
allow_anonymous true​

damit geht jetzt beides, die Daten meiner alten Anwendung kommen an.
mein Windows MQTT Explorer kann sich connecten und sieht die Daten.

Vielleicht ein Hinweis für die Doku.

[Msinn]

ich dachte der Broker steckt im SHNG drin.

Nein, SmartHomeNG ist nur ein Client, wie die IoT Devices auch. Deshalb musst Du in SmartHomeNG auch konfigurieren, wie Du auf den Broker zugreifen willst.

weil ja meine neue lokale Anwendung ohne funktioniert.

Das kann sie nicht. Da muss ein Broker installiert und konfiguriert sein, wie auch in der Anleitung beschrieben ist: Installation und Konfiguration

verstehe jetzt aber nicht, wieso meine neue Anwendung mit dem Plugin ohne Mosquitto funktioniert.

Wie schon beschrieben, kann sie das nicht.

Wie hast Du den Rechner und SmartHomeNG denn installiert?

[whe]

ich dachte der Broker steckt im SHNG drin.
ich habe auf dem neuen Rechner keinen Broker installiert, weil ja meine neue lokale Anwendung ohne funktioniert.
dann wird es wohl gehe, wenn ich den Mosquitto da auch aufsetze.

verstehe jetzt aber nicht, wieso meine neue Anwendung mit dem Plugin ohne Mosquitto funktioniert.

danke für die Aufklärung.

[Msinn]

Bei SmartHomeNG ist nichts besonderes zu beachten. Welchen MQTT Broker nutzt Du denn? Mosquitto? Falls ja, welche Version?

Die neueren Mosquitto Versionen müssen explizit konfiguriert werden, um Messages von anderen Hosts zu empfangen. Die älteren Mosquitto Versionen waren da in der Default Konfiguration offener.

[whe]

zu #264

muss ich in der 1.9.3 Implementierung (mqtt 2.0.3) etwas besonderes definieren um requests von außerhalb zu empfangen.
meine Implementierung mit einem Client auf dem Host von SHNG läuft einwandfrei.
meine Client von einem anderen raspi aber nicht; das geht weiterhin einwandfrei in SHNG 1.9.1 (mqtt 2.0.2)
auch kann sich mein MQTT Explorer vom Windows Rechner nicht mit dem Broker in SHNG verbinden.
das Ding steckt doch da drin, das geht doch auch in meiner alten 1.9.1 Implementierung.

Kann mich nicht mehr erinnern, ob ich damals da etwas besonderes gemacht habe.

[Msinn]

Nein, eine allgemeine Möglichkeit json zu parsen gibt es nicht.

Wenn die Json Payload des mqtt Telegramms eine reine Liste ist, kannst Du das Item allerdings als type: list definieren und dann auf dieses Item in evals oder on_change zugreifen. Das gleiche gilt, wenn die Payload ein reines dict ergibt. Dann kannst Du das Item als type: dict definieren.

Komplexere Json Strukturen musst Du wirklich in einer Logik parsen.

[whe]

Eine meiner Anwendungen liefert ein JSON document an das mqtt plugin.
heute parse ich das mit einer Logic; es gibt auch irgendwo hier einen Thread vom letzten Jahr.
Gibt es eine Möglichkeit JSON auch im plugin zu parsen und den Inhalt auf mehrere Items zu verteilen ?

[whe]

Danke,

jetzt werden auch im webif des Plugins die Item Werte angezeigt und nicht die gelieferten Werte.

dann hat mein "Infinity" Problem auch nichts mit dem Plugin zu tun.

[Msinn]

stelle jetzt fest, dass aus irgendeinem Grund (vielleicht Neustart) der errechnete Wert auch im mqTT webif angezeigt wird.
das sollte doch nicht so sein.

Doch das soll so sein. Im Webinterface wird der Item Wert angezeigt und den hast Du über eval berechnet.

Zu Deinem infinity Problem kann ich nichts sagen. eval: sum habe ich noch nie benutzt.

[whe]

ich habe in einem Item ein "eval" programmiert:

       Laufzeit_3:
            type: num
            cache: True
            eval: (value * 65536)
            mqtt_topic_in: Brenner_Laufzeit_3

stelle jetzt fest, dass aus irgendeinem Grund (vielleicht Neustart) der errechnete Wert auch im mqTT webif angezeigt wird.
das sollte doch nicht so sein.
Ein zweites Problem habe ich, wenn 2 von den 3 Laufzeiten gleichzeitig geupdated werden, dass dann ein Item "Infinity" anzeigt.
kann man da einen verzögerten eval machen ?
Meine Alte Buderus Heizung liefert die Laufzeit leider in 3 Bytes, die ich nur separat abfragen kann.
Beim Überlauf/Wechsel ensteht dann das Problem und die Summenbildung liefert dann natürlich auch "Infinity".

        Laufzeit:
            name: Brennerlaufzeit
            type: num
            cache: True
            sv_widget: |
                <h1>{{ basic.print('', 'item', '', 'VAR / 60 | 0') }} Stunden <br>
                {{ basic.print('', 'item', '', 'VAR % 60') }} Minuten</h1><br>
                {{ basic.symbol('', 'Buderus.Brenner.Stufe', '', 'sani_cogeneration.svg', '', '', 'icon1') }}
            eval: sum
            eval_trigger:
              - Buderus.Brenner.Laufzeit_1
              - Buderus.Brenner.Laufzeit_2
              - Buderus.Brenner.Laufzeit_3