[Neues Modul] Xiaomi Smart Home ohne Gateway direkt an FHEM

[rudolfkoenig]

Wie ist keepalive (list .* keepalive) gesetzt?

[sprudelverduenner]

Das Ergebnis von dem list lautet:

Code Auswählen Erweitern

HMRS485                  ok=1 retry=0

Das ist meine Homematic Wired Komponente.

Gerade ist meine Zigbee Bridge wieder offline gegangen - und der ehemals entfernte Sensor war nun ganz nah am Empfänger...

[rudolfkoenig]

list wurde in diesem Fall nach dem offline-Event ausgefuehrt, im Log zu sehen als:

Code Auswählen Erweitern

2019.12.26 03:24:18 3: MQTT2_SERVER: MQTT2_SERVER_127.0.0.1_35632/mqttjs_bbaa2a71 left us (keepalive check)

Gerade ist meine Zigbee Bridge wieder offline gegangen - und der ehemals entfernte Sensor war nun ganz nah am Empfänger...

Das Problem ist nicht die "Sensor<->Bridge" Kommunikation, sondern die "Bridge<->FHEM".

[sprudelverduenner]

Ah... ok.
Ich werde heute Abend die Bridge wieder starten und dann den List durchgeben.
Bis hierhin vielen Dank.

[sprudelverduenner]

Hallo Rudolf,

hier das LIST bei laufender MQTT_Bridge:

Code Auswählen Erweitern

HMRS485                  ok=1 retry=0
MQTT2_SERVER_127.0.0.1_42240     60

Ich hoffe das hilft ...

[rudolfkoenig]

MQTT2_SERVER_127.0.0.1_42240     60

Dh. die bridge verspricht, alle 60sec eine Nachricht zu senden, und der Server ist laut RFC verpflichtet die Verbindung nach 1.5*60 zu schliessen, falls nichts kommt.
In deinem Log sieht man: die letzte Nachricht kam um 03:22:40, und MQTT2_SERVER hat die Verbindung um 03:24:18 als tot gemeldet, also 98 Sekunden spaeter.
Da der Server nur alle 10 Sekunden die Verbindungen ueberprueft, ist das plausibel.

Irgendetwas ist mit der WLAN kaputt, und die bridge kriegt das nicht so recht mit.

[sprudelverduenner]

Schon mal danke für die Antwort.

Die Erklärung scheint mir plausibel aaaaaaaaaaber:

Irgendetwas ist mit der WLAN kaputt, und die bridge kriegt das nicht so recht mit.

bekomme ich nicht gedeutet.

der Raspberry Pi mir FHEM ist bei mir Kabel im LAN.
Der CC2531 STick sendet ja Ziggbee Protokoll.
Was hat das ganze mit WLAN zu tun??

Das verstehe ich nicht wirklich...

[rudolfkoenig]

Sorry, streiche WLAN, ich meinte die Verbindung zwischen bridge und FHEM.

[sprudelverduenner]

Mit was für LOGs könnte ich das denn noch weiter eingrenzen??

Bis vor 8 Monaten habe ich das mit dem aqara Cube betrieben und nie Probleme.
Dann kam eine Tradfri Fernbedienung dazu und ich musste den Stick und das koenkk Modul updaten.
Seitdem habe ich den Stress....

[sprudelverduenner]

Was mir gerade zu meinem Problem einfällt:

Ich habe im Zuge der Tradfri Fernbedienung damals auch mein Raspbian aktualisiert.
Danach hatte ich das Problem, dass FHEM erst mal gar nicht mehr lief.
Ich habe herausgefunden, dass in dem aktuellen Raspbian wohl auch ein MQTT-Server inkludiert war der ebenfalls auf dem Port 1883 lauschte.
Genau wie der MQTT2_SERVER den ich innerhalb vom FHEM am Laufen habe - dadurch kam es zu einer Kollision.

Ich habe darauf hin den im Raspbian enthaltenen MQTT-Server deinstalliert, so dass FHEM inkl. MQTT_SERVER wieder funktionierte.

Könnte es sein, dass irgendwelche Dateileichen oder etwas Ähnliches bei mir das Problem sein könnten, dass es nicht mehr sauber läuft, nach Laufzeit der Keep alive check fehlschlägt und die Bridge offline geht??

[matthias soll]

Hallo zusammen,
ich habe das Modul jetzt mit mqtt2 und einem maplecun über usb an einem raspberry laufen.
Neue Geräte werden auch angelegt, jedoch bekomme ich keinen STATE, das steht bei verschiedenen Geräten nur
Muss ich da noch etwas einstellen? die Hartbeat Readings kommen und auf bewegung reagiert der aqara bewegungsmelder auch:
2019-12-30 18:00:26 MQTT2_DEVICE Bewegungsmelder_Haustuer illuminance: 0
2019-12-30 18:00:26 MQTT2_DEVICE Bewegungsmelder_Haustuer battery: 100
2019-12-30 18:00:26 MQTT2_DEVICE Bewegungsmelder_Haustuer linkquality: 31
2019-12-30 18:00:26 MQTT2_DEVICE Bewegungsmelder_Haustuer occupancy: true
2019-12-30 18:00:26 MQTT2_DEVICE Bewegungsmelder_Haustuer voltage: 3025

[rudolfkoenig]

Muss ich da noch etwas einstellen?

Ja, attrTemplate setzen.

Generell geht das so:
- erst mit "set XXX attrTemplate ?" die Beschreibung holen, durchlesen, und entscheiden, was passen koennte.
- dann das passende attrTemplate auswaehlen, und entscheiden ob die angezeigten Befehle sinnvoll sind.
- zum Schluss auf "set" klicken.

[matthias soll]

Funktioniert DANKE für die schnelle Erklärung!!!
Mit den Templates kam ich bisher nicht zurecht aber jetzt klappts.
Gruß
Matthias

[sprudelverduenner]

Nabend zusammen,

meine Bridge geht weiterhin offline.
Ich habe nun MQTT2_SERVER gelöscht, bei Raspbian mosquitto installiert und bei FHEM MQTT2_CLIENT aktiviert.

Alle Devices funktionieren nach der Umstellung wieder - das Problem bleibt leider weiterhin.

Ich meine beobachtet zu haben dass der KEEP ALIVE CHECK immer dann zu einem Problem wird wenn MQTT Publish statt findet.
D.h. bin ich abwesend dann bleibt die Bridge online - bin ich zu Hause und benutze somit einen der Sensoren dann nach gefühlten 10 Aktionen schluss und die Bridge ist offline.

Ich weiss echt nicht mehr weiter ....

[OdfFhem]

@sprudelverduenner

Wenn Dein Problem tatsächlich an der Verbindung zwischen zigbee2mqtt und einem x-beliebigen MQTT-Server liegt, hast Du mit der neuen Konstellation das Problem nur in Richtung mosquitto verlagert; wenn, findet der keep-alive-check nun dort statt.

Ich benutze eine größere Zahl von zigbee-Geräten und habe noch nie Publish-Probleme festgestellt. Und auch, wenn man abwesend ist, sollte es ständig Publish-Aktionen geben - folglich müsste die bridge dann auch irgendwann offline gehen. Die Ursache liegt also vermutlich irgendwo ganz anders ...

Hast Du spezielle Einstellungen in der configuration.yaml?
Hast Du schon mal temporär das maximale log_level (debug) in configuration.yaml aktiviert?

Übrigens ist 1.8.0 die neueste, freigegebene zigbee2mqtt-Version - vielleicht handelt es sich um ein spezielles Problem mit dieser Version. Unter Umständen macht es Sinn, die ausgetestetere zigbee2mqtt-Version 1.7.1 auszuprobieren ...