Ankündigung

**Msinn** · 28.12.2018, 20:22

Ich vermute, dass ich Dein Problem nocht nicht verstanden habe, ich sehe nämlich keines.

Wenn Du immer den gleichen Wert senden willst, musst Du diesen Wert dem Item zuweisen (mit value oder eval oder ...). Dann musst Du mit enforce_updates: True sicherstelln, dass gleichbleibende Werte auch gesendet werden. Auslösen kannst Du das Senden indem Du mit eval_trigger ein ander s Item überwachst.

Alternativ könntest Du auch eine Lösung mit on_update bauen.

Deine interpretation zum value Attribut ist übrigens richtig. Es setzt nur den Initialwert. Um das zu verdeutlichen kann man in der item Definition das Attribut auch initial_value nennen.

Aber das ist nichts MQTT spezifisches, sondern das allgemeine Problem, wenn man ein Decice nur per Toggle Command ansteuern kann. Die eigentliche Herausforderung dabei ist, sicherzustellen, dass die Steuerung (hier shNG) und das Decice sich immer einig sind, ob das Device ON oder OFF ist.

Zum MQTT Plugin: Da Dein Problem ein allgemeines ist, halte ich es nicht für sinnvoll das im Plugin zu lösen.

Losgelöst davon wird das MQTT Plugin eine Generalüberholung erfahren, wenn die benötigten Komponenten für die Protokoll-Version 5 vorliegen. Dabei wird vermutlich der eigentliche Protokoll Teil in den shNG Core wandern. Das schafft dann die Möglichkeit Plugins zu schreiben, die MQTT einfach nutzen und ein eigenes darauf basierendes Protokoll (in der Payload) implementieren, um spezifische Devices zu unterstützen.

**henfri** · 28.12.2018, 20:28

Hallo,

Ich vermute, dass ich Dein Problem nocht nicht verstanden habe, ich sehe nämlich keines.

Es gibt kein Problem. Lösbar ist das sicher auch über die von dir geschilderten Wege.

Zum MQTT Plugin: Da Dein Problem ein allgemeines ist, halte ich es nicht für sinnvoll das im Plugin zu lösen.

Den Satz verstehe ich nicht.
Gerade weil das Problem jeder haben sollte, der mqtt-Geräte nutzt, sollte das Plugin das lösen, ohne dass irgendwelche Hilfskonstrukte nötig sind.
Oder?

Gruß,
Hendrik

**henfri** · 28.12.2018, 21:11

Hallo,

so funktioniert es:

Code:

        if caller != 'Mqtt':
            if (self._connected) and (self.has_iattr(item.conf, 'mqtt_topic_out')):
                topic = self.get_iattr_value(item.conf, 'mqtt_topic_out')
                retain = self.get_iattr_value(item.conf, 'mqtt_retain')
                if retain == None:
                    retain = 'False'
                if (self.has_iattr(item.conf, 'mqtt_mapping')):
                    mapping= eval(self.get_iattr_value(item.conf, 'mqtt_mapping')) #maybe better use ast.literal_eval
                    self.logger.info('[mqtt_mapping] Mapping found {0}. Item is {1}'.format(mapping, item()))
                    try:
                        payload= str(mapping[item()])
                    except:
                        self.logger.info("Mapping unsuccessful. Fallback to Item Value")
                        payload= str(item())
                else:
                    payload= str(item())
                    self.logger.info('[mqtt_mapping] no Mapping found') 
                self.logger.info(self.get_loginstance()+"Item '{}': Publishing topic '{}', payload '{}', QoS '{}', retain '{}'".format( item.id(), topic, str(item()), str(self.get_qos_forTopic(item)), retain ))
                self._client.publish(topic=topic, payload=payload, qos=self.get_qos_forTopic(item), retain=(retain=='True'))

Das zugehörige Item funktioniert ohne irgendwelche Hilfsitems:

Code:

    Kueche:  
      Dunstabzugshaube:
         type: bool
         mqtt_topic_out: "cmnd/RfBridge/Backlog"
         mqtt_mapping: "{True: 'RfRaw AA B0 1D 04 04 0172 0122 02BB 3D22 00220022002200220022020200220020220203 55', False: 'RfRaw AA B0 1D 04 04 0172 0122 02BB 3D22 00220022002200220022020200220020220203 55'}"

Ich würde dafür gerne ein PR erstellen.
Spricht etwas dagegen?

Gruß,
Hendrik

**Msinn** · 29.12.2018, 10:32

Die Problemstellung ist trotzdem nicht MQTT spezifisch.

**henfri** · 29.12.2018, 11:25

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

**Msinn** · 29.12.2018, 12:38

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** · 29.12.2018, 13:52

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

**henfri** · 29.12.2018, 14:02

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

**Msinn** · 29.12.2018, 14:58

Zitat von henfri Beitrag anzeigen

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:

Code:

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** · 29.12.2018, 17:08

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** · 29.12.2018, 20:04

Da denke ich noch drauf rum.

**SMarcus** · 15.03.2019, 19:26

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:

Code:

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.

Code:

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** · 15.03.2019, 19:52

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** · 15.03.2019, 20:47

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

Code:

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:~~

Code:

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

**beckerth** · 18.07.2019, 21:54

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:

Code:

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:

Code:

#!/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.PNG mqtt_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

Ankündigung

Neues MQTT Plugin

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar