Ankündigung

Einklappen
Keine Ankündigung bisher.

Zigbee2MQTT Plugin legt MQTT lahm

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

    Zigbee2MQTT Plugin legt MQTT lahm

    Hallo,

    ich habe versucht, das (experimental) zigbee2mqtt Plugin zum Laufen zu bekommen. Leider legt es mir aber komplett die MQTT-Verbindung zwischen SmarthomeNG und Mosquitto, also auch das MQTT-Plugin, lahm. Den Grund konnte ich bisher leider nicht finden.

    Rahmenbedingungen:
    Ich habe SmarthomeNG 1.9.1 + Mosquitto 2.0.14 in einer VM (192.168.2.30) laufen. Das MQTT Plugin nutze ich bereits seit langem, ich habe u.a. Sonoff WIFI Devices darüber angebunden.

    Zigbee2MQTT läuft auf einem Raspberry Pi und schickt die MQTT-Nachrichten an 192.168.2.30.
    Diese kommen auch einwandfrei in Mosquitto an.

    Verwendung des MQTT Plugins und Parsen der Zigbee JSON Payload per Umweg "dict" in dem Items funktioniert einwandfrei und stabil.

    Sobald ich aber das Zigbee2MQTT-Plugin aktiviere - und unabhängig davon, ob und welche Items ich definiert habe - ist Schluss.
    Ich sehe ankommende Messages nach wie vor in Mosquitto. Im MQTT-Plugin kommt nichts mehr an.
    Meine MQTT-Steuerbefehle aus Smartvisu/SmarthomeNG gehen auch nicht mehr raus, Mosquitto sieht sie nicht.

    Das SmarthomeNG-Log mit Logging für MQTT- und Zigbee2MQTT-Plugin enabled:
    Code:
    2022-04-25 08:52:12 NOTICE lib.smarthome -------------------- Init SmartHomeNG v1.9.1-master (8133e714) --------------------
    2022-04-25 08:52:12 NOTICE lib.smarthome Running in Python interpreter 'v3.8.10 final', from directory /usr/local/smarthome
    2022-04-25 08:52:12 NOTICE lib.smarthome - on Linux-5.4.0-109-generic-x86_64-with-glibc2.29 (pid=101351)
    2022-04-25 08:52:12 NOTICE lib.smarthome - Loglevel NOTICE is set to value 31 because handler of root logger is set to level WARNING or higher - Set level of handler 'shng_warnings_file' to 'NOTICE'!
    2022-04-25 08:52:13 NOTICE lib.smarthome - Nutze Feiertage für Land 'DE', Provinz 'None', 1 benutzerdefinierte(r) Feiertag(e) definiert
    2022-04-25 08:52:19 DEBUG plugins.mqtt parsing item: eg.kueche.kaffeemaschine.write
    2022-04-25 08:52:19 DEBUG plugins.mqtt (parsing result): item.conf '{'mqtt_topic_out': 'cmnd/sonoffkaffee/POWER1'}'
    2022-04-25 08:52:19 INFO plugins.mqtt Publishing topic 'cmnd/sonoffkaffee/POWER1' (when needed) for item 'eg.kueche.kaffeemaschine.write'
    2022-04-25 08:52:19 DEBUG plugins.mqtt parsing item: eg.kueche.kaffeemaschine
    2022-04-25 08:52:19 DEBUG plugins.mqtt (parsing result): item.conf '{'mqtt_topic_in': 'stat/sonoffkaffee/POWER1'}'
    2022-04-25 08:52:20 DEBUG plugins.mqtt parsing item: zentral.lueftung.rg.write
    2022-04-25 08:52:20 DEBUG plugins.mqtt (parsing result): item.conf '{'mqtt_topic_out': 'cmnd/sonoff/POWER4'}'
    2022-04-25 08:52:20 INFO plugins.mqtt Publishing topic 'cmnd/sonoff/POWER4' (when needed) for item 'zentral.lueftung.rg.write'
    2022-04-25 08:52:20 DEBUG plugins.mqtt parsing item: zentral.lueftung.rg
    2022-04-25 08:52:20 DEBUG plugins.mqtt (parsing result): item.conf '{'mqtt_topic_in': 'stat/sonoff/POWER4'}'
    2022-04-25 08:52:20 DEBUG plugins.zigbee2mqtt parsing item: zigbee.th1.temp
    2022-04-25 10:52:20 DEBUG plugins.mqtt Run method called
    2022-04-25 10:52:20 INFO plugins.mqtt _start_subscription: Subscribing to topic stat/sonoffkaffee/POWER1, payload_type 'bool' for item eg.kueche.kaffeemaschine (callback=<bound method MqttPlugin._on_mqtt_message of <plugins.mqtt.Mqtt2 object at 0x7ff4982a4a90>>)
    2022-04-25 10:52:20 INFO plugins.mqtt _start_subscription: Subscribing to topic stat/sonoff/POWER4, payload_type 'bool' for item zentral.lueftung.rg (callback=<bound method MqttPlugin._on_mqtt_message of <plugins.mqtt.Mqtt2 object at 0x7ff4982a4a90>>)
    2022-04-25 10:52:20 DEBUG plugins.zigbee2mqtt Run method called
    2022-04-25 10:52:20 INFO plugins.zigbee2mqtt local ip adress is 192.168.2.30
    2022-04-25 10:52:20 INFO plugins.zigbee2mqtt _start_subscription: Subscribing to topic zigbee2mqtt/+, payload_type 'dict' for item *no_item* (callback=<bound method Zigbee2Mqtt.on_mqtt_announce of <plugins.zigbee2mqtt.Zigbee2Mqtt object at 0x7ff498119370>>)
    2022-04-25 10:52:21 NOTICE lib.smarthome -------------------- SmartHomeNG initialization finished --------------------
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt _start_subscription: Subscribing to topic zigbee2mqtt/+/state, payload_type 'bool' for item *no_item* (callback=<bound method Zigbee2Mqtt.on_mqtt_announce of <plugins.zigbee2mqtt.Zigbee2Mqtt object at 0x7ff498119370>>)
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt _start_subscription: Subscribing to topic zigbee2mqtt/+/config, payload_type 'dict' for item *no_item* (callback=<bound method Zigbee2Mqtt.on_mqtt_announce of <plugins.zigbee2mqtt.Zigbee2Mqtt object at 0x7ff498119370>>)
    2022-04-25 10:52:21 DEBUG plugins.zigbee2mqtt on_mqtt_announce: topic_level1=zigbee2mqtt, topic_level2=bridge, topic_level3=state, topic_level4=, topic_level5=, payload=False
    2022-04-25 10:52:21 DEBUG plugins.zigbee2mqtt LWT: detail: state datetime: 2022-04-25 10:52:21.136546 payload: False
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt _start_subscription: Subscribing to topic zigbee2mqtt/+/config/+, payload_type 'dict' for item *no_item* (callback=<bound method Zigbee2Mqtt.on_mqtt_announce of <plugins.zigbee2mqtt.Zigbee2Mqtt object at 0x7ff498119370>>)
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt _start_subscription: Subscribing to topic zigbee2mqtt/+/info, payload_type 'dict' for item *no_item* (callback=<bound method Zigbee2Mqtt.on_mqtt_announce of <plugins.zigbee2mqtt.Zigbee2Mqtt object at 0x7ff498119370>>)
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt _start_subscription: Subscribing to topic zigbee2mqtt/+/info/#, payload_type 'dict' for item *no_item* (callback=<bound method Zigbee2Mqtt.on_mqtt_announce of <plugins.zigbee2mqtt.Zigbee2Mqtt object at 0x7ff498119370>>)
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt _start_subscription: Subscribing to topic zigbee2mqtt/+/response, payload_type 'dict' for item *no_item* (callback=<bound method Zigbee2Mqtt.on_mqtt_announce of <plugins.zigbee2mqtt.Zigbee2Mqtt object at 0x7ff498119370>>)
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt _start_subscription: Subscribing to topic zigbee2mqtt/+/response/#, payload_type 'dict' for item *no_item* (callback=<bound method Zigbee2Mqtt.on_mqtt_announce of <plugins.zigbee2mqtt.Zigbee2Mqtt object at 0x7ff498119370>>)
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt _start_subscription: Subscribing to topic zigbee2mqtt/+/log, payload_type 'dict' for item *no_item* (callback=<bound method Zigbee2Mqtt.on_mqtt_announce of <plugins.zigbee2mqtt.Zigbee2Mqtt object at 0x7ff498119370>>)
    2022-04-25 10:52:21 DEBUG plugins.zigbee2mqtt scheduler_add: name = plugins.zigbee2mqtt.poll_bridge, parameters: prio=3, cycle=30
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt publish_topic: topic 'zigbee2mqtt/bridge/config/devices/get', payload '', QoS 'None', retain 'False'
    2022-04-25 10:52:21 INFO plugins.zigbee2mqtt publish_topic: topic 'zigbee2mqtt/TH1/get', payload '{"temperature" : ""}', QoS 'None', retain 'False'
    2022-04-25 10:52:36 INFO plugins.zigbee2mqtt poll_bridge: Checking online and health status of bridge
    2022-04-25 10:52:36 INFO plugins.zigbee2mqtt publish_topic: topic 'zigbee2mqtt/bridge/request/health_check', payload '', QoS 'None', retain 'False'
    2022-04-25 10:53:06 INFO plugins.zigbee2mqtt poll_bridge: Checking online and health status of bridge
    [....]
    2022-04-25 10:55:06 INFO plugins.zigbee2mqtt publish_topic: topic 'zigbee2mqtt/bridge/request/health_check', payload '', QoS 'None', retain 'False'
    2022-04-25 10:55:36 INFO plugins.zigbee2mqtt poll_bridge: Checking online and health status of bridge
    2022-04-25 10:55:36 INFO plugins.zigbee2mqtt publish_topic: topic 'zigbee2mqtt/bridge/request/health_check', payload '', QoS 'None', retain 'False'
    2022-04-25 10:55:44 INFO plugins.mqtt Update item: eg.kueche.kaffeemaschine.write, item has been changed outside this plugin
    2022-04-25 10:55:44 INFO plugins.mqtt publish_topic: Item 'eg.kueche.kaffeemaschine.write' -> topic 'cmnd/sonoffkaffee/POWER1', payload '2', QoS 'None', retain 'False'
    2022-04-25 10:55:46 INFO plugins.mqtt Update item: eg.kueche.kaffeemaschine.write, item has been changed outside this plugin
    2022-04-25 10:55:46 INFO plugins.mqtt publish_topic: Item 'eg.kueche.kaffeemaschine.write' -> topic 'cmnd/sonoffkaffee/POWER1', payload '2', QoS 'None', retain 'False'
    2022-04-25 10:56:06 INFO plugins.zigbee2mqtt poll_bridge: Checking online and health status of bridge
    2022-04-25 10:56:06 INFO plugins.zigbee2mqtt publish_topic: topic 'zigbee2mqtt/bridge/request/health_check', payload '', QoS 'None', retain 'False'
    2022-04-25 10:56:36 INFO plugins.zigbee2mqtt poll_bridge: Checking online and health status of bridge
    [....]
    Das o.g. publish_topic z.B. kommt auch nicht in Mosquitto an. Zigbee2MQTT-Plugin disabled, alles geht wieder.

    Gruß,
    Thomas

    Sisamiwe​​​​​​​

    #2
    Zitat von blobo Beitrag anzeigen
    kommt auch nicht in Mosquitto an. Zigbee2MQTT-Plugin disabled, alles geht wieder.
    Hallo,
    in meiner Umgebung läuft alles (shNG mit Pluign, Zigbee2MQTT etc) auf einem (dem selben) RPi. Daher kann es sein, dass andere Setups zu Fehlern führen. Aber die finden wir raus und beheben sie.

    Auch ich hatte bei der Entwicklung Probleme mit dem Debugging, da (zumindest habe ich es nicht anders hinbekommen) sowohl das Tasmota Plugin als auch das Zigbee2Mqtt Plugin bei Fehlern keine LogMessages mehr ausgeben. Das tritt vermutlich ich immer dann auf, wenn das MQTT Modul "dazwischen" ist. Vielleicht kann Msinn dazu was sagen?
    Das Plugin "stützt" ab und blockiert dann teilweise. Du könntest das prüfen, ob im WebIF des Plugins der Status noch auch "Aktive" steht.

    Wie kommst Du dem Fehler näher:
    • Idealerweise hast Du eine Testumgebung (also nicht im produktiven Einsatz).
    • Du beendest in der Konsole shNG
      sudo systemctl stop smarthome.service
      und deaktiviert den Dienst
      sudo systemctl disable smarthome.service
      vorübergehend.
    • Du startest shNG "manuell" im Debug Modus mit
      cd /usr/local/smarthome
      python3 bin/smarthome.py -d
      und bekommst die Fehlermeldung direkt auf dem Bildschirm. Dort sollte auch die Fehlermeldung sein, die das Problem verursacht. (zumindest war es bei mir so)
    • Für das manuelle Neustarten nutzt du
      python3 bin/smarthome.py -r
      und für das Beenden
      python3 bin/smarthome.py -s
      .
    • Wenn du mit der Session fertig bist, aktivierst Du den shNG Dienst wieder mit
      sudo systemctl enable smarthome.service
      und startest ihn mit
      sudo systemctl start smarthome.service
    • Eine andere Möglichkeit ist, den Lauf des PluginCodes anhand der Log nachzuvollziehen. Der Fehler lag bei mir dann meinst in dem Stück Code der als nächstes nach dem letzten erfolgreichen Debug-Log einer eingegangenen MQTT Message abgearbeitet worden wäre.
    Probier mal und melde dich wieder.
    Wie gut kennst Du dich mit shNG, Python, etc aus?
    Bist Du auch bei Gitter?

    Beste Grüße

    Kommentar


      #3
      Hi Sisamiwe,

      darauf, dass Smarthome direkt auf der Konsole mehr ausgibt als im Log, bin ich nicht gleich gekommen :-(

      Vielen Dank für deine äußerst ausführliche Anleitung.
      Ich selber bin schon ein paar Jährchen in der SW-Entwicklung aktiv, aber eher in Richtung C/Assembler und Treiber/Firmware. Python habe ich bisher nie wirklich gelernt, aber mir genug abgeschaut, um z.B. selber ein Plugin zu schreiben.

      Nun denn, auf der Konsole sieht man mehr:

      File "/usr/local/smarthome/plugins/zigbee2mqtt/__init__.py", line 383, in on_mqtt_announce
      self.zigbee2mqtt_plugin_devices[topic_level2]['online'] = bool(payload)
      KeyError: 'bridge'
      Im Übrigen zeigen sowohl das MQTT als auch zigbee2mqtt-Plugin im Fehlerfall einen aktiven Status in den Web-Interfaces - aber in der Broker-Information finden sich außer der Broker Version nichts mehr, d.h. Active Clients / Subscriptions etc. sind blank. Klingt logisch, wenn das Plugin hängt.

      Ich schau mir mal den Code etwas näher an. Ich hatte nur den "brain fart", nicht auf der Konsole nachzusehen, sondern nur per Webfrontend in die Logs zu schauen.
      Ich werde berichten ;-)

      Gruß aus der benachbarten Oberpfalz,
      Thomas

      Kommentar


        #4
        Zitat von blobo Beitrag anzeigen
        dass Smarthome direkt auf der Konsole mehr ausgibt als im Log, bin ich nicht gleich gekommen :-(
        Das kann shNG schon immer, ist aber deprecated und soll/ist im logging implementiert. Mir ist erging es bei der Entwicklung ebenso, so dass ich das mit der Konsole mal probiert habe. Zufallstreffer. Wo am Ende die Log "versacken", konnte ich bislang nicht rausfinden.

        Zitat von blobo Beitrag anzeigen
        Nun denn, auf der Konsole sieht man mehr:
        Scheinbar findet er "bridge" im dict nicht. Setz das doch mal in try/except.

        Zitat von blobo Beitrag anzeigen
        sondern nur per Webfrontend in die Logs zu schauen.
        Ich habe die log Dateien bei Entwicklung oder Debugging immer im Notepad++ offen. Die werden dort aktualisiert. Geht besser, finde ich.

        Dann viel Erfolg bei der Suche. Wir können das dann gemeinsam testen und ich stelle einen PR, damit das dann auch Einzug hält.

        Kommentar


          #5
          blobo

          Zitat von Sisamiwe Beitrag anzeigen
          Eine andere Möglichkeit ist, den Lauf des PluginCodes anhand der Log nachzuvollziehen. Der Fehler lag bei mir dann meinst in dem Stück Code der als nächstes nach dem letzten erfolgreichen Debug-Log einer eingegangenen MQTT Message abgearbeitet worden wäre.
          Das siehst Du in deinem Log vom ersten Post.
          Zitat von blobo Beitrag anzeigen
          2022-04-25 10:52:21 DEBUG plugins.zigbee2mqtt on_mqtt_announce: topic_level1=zigbee2mqtt, topic_level2=bridge, topic_level3=state, topic_level4=, topic_level5=, payload=False
          Die MQTT Message kommt noch an und dann ist "Feierabend". Also muss der Fehler in der Verarbeitung der Message liegen. (Tut er ja auch, hat ja die Konsolenausgabe gezeigt). So kann man den Fehler auch ohne Konsolenausgabe eingrenzen.

          Kommentar


            #6
            Zitat von Sisamiwe Beitrag anzeigen
            blobo
            Die MQTT Message kommt noch an und dann ist "Feierabend". Also muss der Fehler in der Verarbeitung der Message liegen. (Tut er ja auch, hat ja die Konsolenausgabe gezeigt). So kann man den Fehler auch ohne Konsolenausgabe eingrenzen.
            Der KeyError denke ich hilft weiter.
            In der zugehörigen MQTT-Message findet sich auch kein bridge im dict:
            zigbee2mqtt/bridge/state {"state":"online"}
            Ich packe das mal in try/except wie vorgeschlagen.

            Gruß,
            Thomas

            Kommentar


              #7
              Zitat von blobo Beitrag anzeigen
              Ich packe das mal in try/except wie vorgeschlagen.
              Das ist was anderes faul.

              Das ist der OriginalCode:
              Code:
                      # handle different received mqtt messages
                      if topic_level2 == 'bridge':
                          if topic_level3 == 'state':
                              # Payloads are 'online' and 'offline'; equal to LWT
                              self.logger.debug(f"LWT: detail: {topic_level3} datetime: {datetime.now()} payload: {payload}")
                              self.zigbee2mqtt_plugin_devices[topic_level2]['online'] = bool(payload)
              wenn der topic_level2 = 'bridge' ist -> das ist er
              wenn der topic_level3 = 'state' ist -> das ist er
              wird im Plugin-internen dict der Onlinestatus gesetzt. Scheinbar ist bei Dir aber das dict nicht entsprechend vorbereitet.

              Setze mal:
              Code:
              if not topic_level2 in self.zigbee2mqtt_plugin_devices:
                  self.zigbee2mqtt_plugin_devices[topic_level2] = {}
              vor die Zeile
              Code:
              self.zigbee2mqtt_plugin_devices[topic_level2]['online'] = bool(payload)

              Kommentar


                #8
                Zitat von blobo Beitrag anzeigen
                In der zugehörigen MQTT-Message findet sich auch kein bridge im dict:
                Das muss auch nicht im dict sein. Es gibt ein Plugin-internes Dict (also Datenspeicher). Hier werden die Inhalte der Messages abgelegt. Die Keys setzten sich aus der MQTT Topic zusammen. Das ist auch die 'bridge' als Level2.

                Kommentar


                  #9
                  OK, root cause gefunden.

                  Die Einträge für zigbee2mqtt_plugin_devices werden in parse_item() anhand der Items mit zigbee2mqtt_topic angelegt.
                  Da gab es bei mir keinen, da mich die Bridge bisher nicht interessiert hatte.

                  Der Code in on_mqtt_announce(), Zeile 385, geht aber davon aus, dass es diesen Index gibt. Dein Workaround, das an der Stelle zu initialisieren funktioniert genauso als ein entsprechendes Item anzulegen.

                  In der Folge stürzt das Plugin jetzt noch mit einem TypeError ab, sobald ein Payload-Update mit "last_seen" hereinkommt - das habe ich in zigbee2mqtt aktiviert.
                  File "/usr/local/smarthome/plugins/zigbee2mqtt/__init__.py", line 490, in on_mqtt_announce
                  payload.update({'last_seen': datetime.fromtimestamp(payload['last_seen'] / 1000)})
                  TypeError: unsupported operand type(s) for /: 'str' and 'int'
                  Das ist aber eine andere Baustelle, das ursprüngliche Problem ist identifiziert. Danke!

                  Gruß,
                  Thomas

                  Kommentar


                    #10
                    Zitat von blobo Beitrag anzeigen
                    darauf, dass Smarthome direkt auf der Konsole mehr ausgibt als im Log, bin ich nicht gleich gekommen :-(
                    Das gilt eigentlich nur für die Initialisierung. Fehler die auftreten bevor das logging initialisiert ist, können halt nur auf der Console ausgegeben werden.
                    Viele Grüße
                    Martin

                    There is no cloud. It's only someone else's computer.

                    Kommentar


                      #11
                      Zitat von blobo Beitrag anzeigen
                      In der Folge stürzt das Plugin jetzt noch mit einem TypeError ab, sobald ein Payload-Update mit "last_seen" hereinkommt - das habe ich in zigbee2mqtt aktiviert.
                      Das Problem hier liegt daran, dass in Zigbee2MQTT verschiedene Zeitformate einstellbar sind, ISO 8601 als auch Epoch. Das Plugin geht aber fix von Epoch aus und versucht zu konvertieren.
                      Auf Epoch umgestellt ist auch dieses Problem weg.

                      Dafür stürzt jetzt irgendwann später das Frontend des Plugins ab, so sieht es zumindest vom Log her aus. Ich hatte gestern keine Zeit mehr, mir das näher anzusehen.

                      Gruß,
                      Thomas

                      Kommentar


                        #12
                        Hallo nochmal Sisamiwe ,

                        zwei Probleme habe ich dann noch gefunden, bevor das Plugin jetzt soweit läuft.

                        1) Standardmäßig ist in Zigbee2Mqtt das Feld "Include device information" in der MQTT-Konfiguration disabled.
                        Das Plugin legt nur bei Erhalt des Device-Datensatzes "device" in der Payload 'meta' an (ab Zeile 473):

                        Code:
                        ## Korrekturen in der Payload
                        
                        # Umbenennen des Key 'friendlyName' in 'friendly_name', damit er identisch zu denen aus den Log und Config Topics ist
                        if 'device' in payload:
                            meta = payload['device']
                            if 'friendlyName' in meta:
                                meta['friendly_name'] = meta.pop('friendlyName')
                            del payload['device']
                        
                            if not self.zigbee2mqtt_devices[topic_level2].get('meta'):
                                self.zigbee2mqtt_devices[topic_level2]['meta'] = {}
                            self.zigbee2mqtt_devices[topic_level2]['meta'].update(meta)
                        Wenn diese Option also nicht explizit in Zigbee2MQTT aktiviert wird, stürzt das Web-Interface beim Erhalt der Payload ab, da 'meta' nicht im dict gefunden wird.

                        2) Dasselbe gilt mehr oder weniger für "lastSeen", das vom Web-Interface als Bestandteil von 'meta' erwartet wird - aber optional ist.
                        Bei meinen Devices zum Beispiel erhält der 'device'-Teil in der Payload kein "lastSeen", sondern "last_seen" gibt es je nach Einstellung in der regulären Payload, also eine Ebene höher.
                        D.h. auch hier stürzt das Web-Interface ab, weil 'lastSeen' nicht vorhanden ist.

                        Ich habe also als zwei schnelle Workarounds zum einen die Device-Details in Zigbee2MQTT aktiviert, als auch die Zeile mit "lastSeen" im Webinterface entfernt.
                        Damit scheint das Plugin jetzt grundlegend erst einmal zu laufen.

                        Für einen richtigen Fix müssen die dicts wohl vom Plugin entsprechend vorinitialisiert werden.

                        Gruß,
                        Thomas
                        Zuletzt geändert von blobo; 26.04.2022, 12:47.

                        Kommentar


                          #13
                          Zitat von Msinn Beitrag anzeigen
                          Das gilt eigentlich nur für die Initialisierung. Fehler die auftreten bevor das logging initialisiert ist, können halt nur auf der Console ausgegeben werden.
                          Für das Tasmota Plugin und das Zigbee2Mqtt Plugin kann ich das nicht bestätigen. Hier kommt bei bestimmten Fehlern keine Meldung im Log, auch nicht nach abgeschlossener Initialisierung. Das Plugin scheint "abgestützt" und verarbeitet eingehende Daten nicht mehr. Da das immer Plugins sind, die auf das MQTT Modul aufsetzen/verwenden, könnte es auch damit irgendwie zusammenhängen.
                          Deinem Statement entnehme ich aber, dass das so nicht sein soll. Ich hatte auch schon mal den LogLevel des MQTT Modules auf Debug gesetzt, aber da kam auch nicht mehr im Log an.

                          Zitat von blobo Beitrag anzeigen
                          Für einen richtigen Fix müssen die dicts wohl vom Plugin entsprechend vorinitialisiert werden.
                          Das schaue ich mir an. Bzgl. der notwendigen Einstellungen den Zigbee2Mqtt. Kann man die Config von Z2M per mqtt message ändern? Beim Tasmota Plugin konfiguriere ich per mqtt message das Tasmota-Gerät bzw. den Aufbau der mqtt messages.
                          Ich mache die Tage mal ein Update und gebe Bescheid.

                          Kommentar


                            #14

                            Zitat von Sisamiwe Beitrag anzeigen
                            Für das Tasmota Plugin und das Zigbee2Mqtt Plugin kann ich das nicht bestätigen
                            Benutzt Du vielleicht ein Python package, welches dann evtl. solche Ausgaben direkt per print() macht? Oder machst Du evtl. selber print() Ausgaben?
                            Viele Grüße
                            Martin

                            There is no cloud. It's only someone else's computer.

                            Kommentar


                              #15
                              blobo

                              Hallo,

                              ich habe die Fehler korrigiert und einen PR gestellt.

                              Beste Grüße

                              Kommentar

                              Lädt...
                              X