Devolo Thermostate - Verlieren die Verbindung

[Hash99]

Hallo zusammen,
ich bin nun seit über einem mit FHEM zu Gange. Seit 2-3 Monaten habe ich nun Probleme mit den Devolo Thermostaten. Ich habe mittlerweile 8 Thermostate. Bis Ende letzten Jahres waren es 6. Ich hatte schon immer Probleme damit, dass die Thermosstate in den E5 ode ES Modus gingen. Aber normalerweise haben diese dann trotzdem die setpointHeating-Befehle entgegengenommen. Inzwischen klappt das nicht mehr. Alle Versuche scheiterten. (Dies sieht man sehr schön an dem Parameter cmdsPending).
Ein neu aufgesetztes FHEM hat leider nichts gebracht. Auch die Nutzung von Aeotec AEOEZW090-C Aeon Labs USB Stick hat keine Änderung gebracht.
Testweise habe ich nun mal andere Produkte ausprobiert. Sowohl bei Openhab, als auch bei IOBroker oder und home assistant waren diese Ausfälle nicht zu verzeichnen. Auch hatte ich dort nie bei meinen Tests kein E5 oder ES bekommen.
Da mir aber FHEM ans Herz gewachsen ist, möchte ich nicht auf ein anderes Produkt umsteigen müssen. Scheinbar macht nur Devolo Probleme. Da aber die anderen open source auch Openzwave als Basis nutzen (soweit ich das verstanden habe), verstehe ich nicht, dass dort die Thermostate laufen und auch die korrekte Temperatur auf den Displays anzeigen, nicht aber unter FHEM.
Ich bin kein Perl-Spezialist und auch kein z-Wave Spezialist. Möchte aber helfen, zugegeben auch im Eingenen Interesse, den Fehler mit den Devolo-Thermostaten zu beseitigen. Da ich zwei RASP im Einsatz habe und die Thermostate inzwischen auf einem Alternativprodukt laufen, könnte ich anbieten, den Traffic zwischen den Thermostaten zu loggen. Dann könnte jemand mit Erfahrung sicher sehen, wo die Connection bei Fhem verloren geht.
Daraus ergeben sich einige Fragen:
1. Gibt es ein Produkt, dass den Traffic zwischen dem USB und den Applikationen loggen kann und kann man das ohne Probleme einsetzen?
2. Gibt es eine Beschreibung dessen, was in Fhem im Bezug auf ZWave-Anbindung realisiert wurde und wäre diese zugänglich?

Gruß

[rudolfkoenig]

Mit USB-Sniffing unter Linux habe ich keine Erfahrung, es gibt aber diverse Aneitungen im Internet.

Eine Programmierdokumentation zu den FHEM-Modulen gibt es nicht, nur die Module selber, die sind ja im Quelltext verfuegbar.

Bei der ZWave Anbindung gibt es zwei Protokolle: zwischen FHEM und USB-Controller (ist in 00_ZWDongle.pm implementiert), und ZWave Nachrichten an die Endgeraete, die ueber den Controller versendet werden (ist in 10_ZWave.pm implementiert). Zum Ersteren gibt es  mW keine dokumentation, zum Letzteren gibt es eine inzwischen oeffentlich Verfuegbare. In Deinem Fall ist auch nur das im 10_ZWave.pm implementierte Protokoll relevant.

[krikan]

1. Gibt es ein Produkt, dass den Traffic zwischen dem USB und den Applikationen loggen kann und kann man das ohne Probleme einsetzen?

USB-Sniffen halte ich für unnötig kompliziert. Sowohl IOBroker als auch home assistant nutzen zur ZWave-Anbindung afaik openzwave. Wenn man den Log-Level in openzwave hochsetzt, dann kann man anhand des Logs die komplette Kommunikation zwischen Endgerät und Controller mit den Rohnachrichten nachvollziehen. Das müsste man analysieren und mit FHEM vergleichen.

Mit openhab geht das vermutlich auch; habe ich nur noch nie selbst probiert.

[Hash99]

Hi,
danke für die prompte Antwort.

Das hier habe ich aus der OZW_Log.txt für eine Node mal extrahiert.

Code Auswählen Erweitern

2018-06-06 20:39:02.645 Detail, Node002,   Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x02, 0x03, 0x80, 0x03, 0x45, 0x35
2018-06-06 20:39:02.645 Detail,
2018-06-06 20:39:02.645 Info, Node002, Received Battery report from node 2: level=69
2018-06-06 20:39:02.645 Detail, Node002, Refreshed Value: old value=69, new value=69, type=byte
2018-06-06 20:39:02.645 Detail, Node002, Changes to this value are not verified
2018-06-06 20:39:02.645 Detail, Node002, Notification: ValueChanged
2018-06-06 20:39:02.704 Detail, Node002,   Received: 0x01, 0x0c, 0x00, 0x04, 0x00, 0x02, 0x06, 0x43, 0x03, 0x01, 0x42, 0x05, 0xdc, 0x29
2018-06-06 20:39:02.704 Detail,
2018-06-06 20:39:02.705 Detail, Node002, Refreshed Value: old value=15.00, new value=15.00, type=decimal
2018-06-06 20:39:02.705 Detail, Node002, Changes to this value are not verified
2018-06-06 20:39:02.705 Info, Node002, Received thermostat setpoint report: Setpoint Heating 1 = 15.00C
2018-06-06 20:39:02.705 Detail, Node002, Notification: ValueChanged
2018-06-06 20:39:02.761 Detail, Node002,   Received: 0x01, 0x0a, 0x00, 0x04, 0x00, 0x02, 0x04, 0x46, 0x08, 0x00, 0x7f, 0xc6
2018-06-06 20:39:02.761 Detail,
2018-06-06 20:39:02.761 Info, Node002, Received climate control schedule override report:
2018-06-06 20:39:02.761 Info, Node002,   Override State: None:
2018-06-06 20:39:02.761 Detail, Node002, Refreshed Value: old value=0, new value=0, type=list
2018-06-06 20:39:02.762 Detail, Node002, Changes to this value are not verified
2018-06-06 20:39:02.762 Detail, Node002, Refreshed Value: old value=127, new value=127, type=byte
2018-06-06 20:39:02.762 Detail, Node002, Changes to this value are not verified
2018-06-06 20:39:02.762 Detail, Node002, Notification: ValueChanged
2018-06-06 20:39:02.762 Detail, Node002, Notification: ValueChanged
2018-06-06 20:39:02.820 Detail, Node002,   Received: 0x01, 0x0c, 0x00, 0x04, 0x00, 0x02, 0x06, 0x31, 0x05, 0x01, 0x42, 0x0a, 0x8e, 0x00
2018-06-06 20:39:02.820 Detail,
2018-06-06 20:39:02.820 Info, Node002, Received SensorMultiLevel report from node 2, instance 1, Temperature: value=27.02C
2018-06-06 20:39:02.821 Detail, Node002, Refreshed Value: old value=27.13, new value=27.02, type=decimal
2018-06-06 20:39:02.821 Detail, Node002, Changes to this value are not verified
2018-06-06 20:39:02.821 Detail, Node002, Notification: ValueChanged
2018-06-06 20:39:02.875 Detail, Node002,   Received: 0x01, 0x08, 0x00, 0x04, 0x00, 0x02, 0x02, 0x84, 0x07, 0x70
2018-06-06 20:39:02.876 Detail,
2018-06-06 20:39:02.876 Info, Node002, Received Wakeup Notification from node 2
2018-06-06 20:39:02.876 Info, Node002,   Node 2 has been marked as awake
2018-06-06 20:39:02.876 Detail, Node002, Queuing (WakeUp) WakeUpCmd_NoMoreInformation (Node=2): 0x01, 0x09, 0x00, 0x13, 0x02, 0x02, 0x84, 0x08, 0x25, 0x5d, 0x11
2018-06-06 20:39:02.876 Detail, Node002, Notification: Notification - Node Awake
2018-06-06 20:39:02.876 Detail,
2018-06-06 20:39:02.876 Info, Node002, Sending (WakeUp) message (Callback ID=0x5d, Expected Reply=0x13) - WakeUpCmd_NoMoreInformation (Node=2): 0x01, 0x09, 0x00, 0x13, 0x02, 0x02, 0x84, 0x08, 0x25, 0x5d, 0x11
2018-06-06 20:39:02.884 Detail, Node002,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2018-06-06 20:39:02.885 Detail, Node002,   ZW_SEND_DATA delivered to Z-Wave stack
2018-06-06 20:39:02.948 Detail, Node002,   Received: 0x01, 0x07, 0x00, 0x13, 0x5d, 0x00, 0x00, 0x07, 0xb1
2018-06-06 20:39:02.949 Detail, Node002,   ZW_SEND_DATA Request with callback ID 0x5d received (expected 0x5d)
2018-06-06 20:39:02.949 Info, Node002, Request RTT 72 Average Request RTT 82
2018-06-06 20:39:02.949 Info, Node002,   Node 2 has been marked as asleep
2018-06-06 20:39:02.949 Detail,   Expected callbackId was received
2018-06-06 20:39:02.949 Detail,   Expected reply was received
2018-06-06 20:39:02.949 Detail,   Message transaction complete
2018-06-06 20:39:02.949 Detail,
2018-06-06 20:39:02.949 Detail, Node002, Removing current message
2018-06-06 20:39:02.949 Detail, Node002, Notification: Notification - Node Asleep

Eigentlich habe ich mir vorgestellt, die Basis-Daten zu sehen. So what. Kann man damit etwas anfangen?
Wenn ich das richtig verstanden habe, muss ich ein Thermostat auf verbose 5 setzen. Soll ich das für den ZWdongle auch tun?
Gruß

[krikan]

Wenn ich das richtig verstanden habe, muss ich ein Thermostat auf verbose 5 setzen. Soll ich das für den ZWdongle auch tun?

Auf jedern Fall für ZWDongle, damit man die FHEm-Rohnachrichten sieht. Dann muss man die Logs von FHEM und openzwave hinsichtlich Unterschieden untersuchen und hoffen, dass man die Ursache/einen Unterschied findet. Du wirst aber sicherlich einen längeren Zeitraum loggen/beobachten müssen, als im ozw-Log gezeigt.

[rudolfkoenig]

Du wirst aber sicherlich einen längeren Zeitraum loggen/beobachten müssen, als im ozw-Log gezeigt.

Bitte wenigstens eine Stunde, mehr waere mir aber lieber.
Wenn ich mich recht erinnere, tritt das Problem nach einer halben Stunde nach der letzten Aktivitaet auf, insofern vermute ich, dass das System regelmaessig eine Nachricht erwartet, was FHEM nicht sendet, oder eine Antwort auf eine "Frage", was FHEM falsch beantwortet.

[Hash99]

Hi,
okay läuft.
Ich habe sicherheitshalber auf dem Stick ein Factory Reset gemacht und nur ein Thermostat eingegangen. Das Registrieren des Thermostates habe ich schon mal weggesichert
Anschliessend habe ich das WakeupInterval auf 120 s gesetzt und eine Update auf die Temperatur gemacht. Dies habe ich mit dem Aktivierungsbutton auf dem Devolo erfolgreich übertragen. Auch das Log habe ich gesichert. Nun warte ich auf ein Awake vom Thermostat (mindestens eine Stunde).

[Hash99]

Hi,
ich bin seit einem Tag am Testen und kann für ein einzelnes Thermostat es nicht hinbekommen, dass er die Verbindung verliert. Egal ob ich viele Commands sendete oder das Wakeup Intervall änderte oder den WNMI_DELAY anders setzte.
Meine Vermutung geht nun dahin, dass die "schiere" Anzahl von 8 Thermostaten (plus sonstige Schalter) zu dem Problem führt. Dann kann ich aber kein Log mehr schreiben. Auch ist dies dann nicht mehr lesbar.
So kommen wir nicht weiter. 
Ich mache nun einen letzten Test indem ich Sender und Empfänger möglichst weit auseinander platziere. Bisher war dies aber auch kein Problem.
Gruß

[krikan]

Meine Vermutung geht nun dahin, dass die "schiere" Anzahl von 8 Thermostaten (plus sonstige Schalter) zu dem Problem führt. Dann kann ich aber kein Log mehr schreiben. Auch ist dies dann nicht mehr lesbar.

Wenn Du das Log schreiben kannst, dann hänge es ruhig komprimiert hier an oder melde Dich per PM. Das Thema "Lesbarkeit" sollte lösbar sein.

Gruß, Christian