Ankündigung

Einklappen
Keine Ankündigung bisher.

Neues MQTT Plugin

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

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


    Viele Grüße
    Martin

    Stay away from negative people. They have a problem for every solution.

    Kommentar


      #92
      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

      Kommentar


        #93
        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

        Kommentar


          #94
          Die Problemstellung ist trotzdem nicht MQTT spezifisch.
          Viele Grüße
          Martin

          Stay away from negative people. They have a problem for every solution.

          Kommentar


            #95
            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

            Kommentar


              #96
              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.
              Viele Grüße
              Martin

              Stay away from negative people. They have a problem for every solution.

              Kommentar


                #97
                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
                Zuletzt geändert von henfri; 29.12.2018, 13:55.

                Kommentar


                  #98
                  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

                  Kommentar


                    #99
                    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.
                    Viele Grüße
                    Martin

                    Stay away from negative people. They have a problem for every solution.

                    Kommentar


                      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

                      Kommentar


                        Da denke ich noch drauf rum.
                        Viele Grüße
                        Martin

                        Stay away from negative people. They have a problem for every solution.

                        Kommentar


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

                          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
                          Zuletzt geändert von SMarcus; 15.03.2019, 19:35.

                          Kommentar


                            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.
                            Viele Grüße
                            Martin

                            Stay away from negative people. They have a problem for every solution.

                            Kommentar


                              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
                              Zuletzt geändert von SMarcus; 15.03.2019, 21:02.

                              Kommentar

                              Lädt...
                              X