(gelöst) Fehler E5 - Danfoss Thermostate - nach Update 23.08.2015

Begonnen von cnkru, 30 August 2015, 12:18:47

Vorheriges Thema - Nächstes Thema

cnkru

Hallo liebe Forumgemeinde

Ich habe einen Raspi mit Razberry-Modul in Betrieb auf dem bisher neun ZWave-Thermostate Danfoss 0013 stabil liefen.
Nach einem Update am 23.08. meldeten diese jedoch ständig den Fehler E5 - Zentrale nicht erreichbar.
Ein Batteriewechsel (25.08.) brachte kein positives Ergebnis. Nach Restart FHEM oder Reanimieren der Thermostate
(Batterie rein - raus) laufen diese zunächst wieder. Aber nach ca. 1 bis 2 Stunden erschien wieder der Fehler E5 bei allen Thermostaten.
Auch ein Standortwechsel des Raspi sowie mehrfachen Excludieren und Includieren der Geräte brachten keinen Erfolg.

Gestern, 29.08 5:44 Uhr, habe ich von einer Datensicherung (stabile Version vom 18.6.) die Module 00_ZWDongle.pm und 10_ZWave.pm
eingespielt, seit diesen Zeitpunkt laufen alle Thermostate wie gewohnt stabil.
Heute habe ich ein Update durchgeführt aber 10_ZWave.pm (alt) belassen. Ergebnie: die Thermostate laufen stabil.

Der Fehler liegt somit vermutlich im ZWave.pm Modul.

Auffällig beim "fehlerhaften" ZWave.pm ist, dass die Readings (batterie, Setpoint, transmit) trotz des Fehlers E5 regelmäßig
ein wakeup notification, setpointTemp, etc. melden und so tun als ob alles in Ordnung wäre.

Logs sind verfügbar ...

Anbei ein List vom Thermostat_Test

Internals:
   DEF        da271298 28
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     165
   NAME       Thermostat_Test
   NR         616
   STATE      setpointHeating 18
   TYPE       ZWave
   ZWAVE1_MSGCNT 165
   ZWAVE1_RAWMSG 0004001c03800353
   ZWAVE1_TIME 2015-08-30 12:14:56
   homeId     da271298
   id         1c
   lastMsgTimestamp 1440929696
   Readings:
     2015-08-30 11:14:05   CMD             ZW_APPLICATION_UPDATE
     2015-08-27 03:54:12   UNPARSED        UNKNOWN_C0 03c00318
     2015-08-30 12:14:56   battery         83 %
     2015-08-26 21:42:29   ccs             UNKNOWN 04
     2015-08-30 12:14:56   ccsOverride     no, unused
     2015-08-26 21:42:29   clock           get
     2015-08-28 22:33:13   model           Danfoss Z Thermostat 014G0013
     2015-08-28 22:33:13   modelConfig     danfoss/z.xml
     2015-08-28 22:33:13   modelId         0002-0005-0004
     2015-08-30 12:14:56   setpointTemp    18.0 C heating
     2015-08-30 11:16:30   state           setpointHeating 18
     2015-08-30 12:14:57   transmit        OK
     2015-08-30 12:14:56   wakeup          notification
     2015-08-28 21:10:48   wakeupReport    interval 430 target 1
   WakeUp:
     131c054301010112051c
Attributes:
   IODev      ZWAVE1
   classes    BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
   genericDeviceType thermostat
   room       ZWave
   verbose    5

Momentan läuft alles stabil, 10_ZWave.pm habe ich vom Update ausgeschlossen.

Gruß Carsten
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

rudolfkoenig

Leider sind die Unterschiede zwischen den beiden Versionen (8749:9106) doch erheblich:
- Umstellung auf ExplorerFrames
- Umstellung der Wakeup-Abarbeitung
- Callback-Id auch bei get
- ACK/NACK Handling Umbau
Es sind auch ein paar Klassen/Befehle dazugekommen, die sollten aber hier keine Auswirkung haben.

Die Logs (sind wohl Event-Logs) haben mir bisher keine Idee geleifert. Was ich sehe:
- in der neuen Version kommt wakeup:notification alle 6-8 Minuten bis Mitternacht, danach nur alle 30 Minuten. In der Alten sind es konstant 04:53
- in der Alten Version kommt die battery Meldung fast immer doppelt, in der Neuen bis zu 5-mal
Leider kann ich daraus keine Schluesse ziehen.

Um das Problem zu fixen sehe ich mehrere Wege, die Reihenfolge gibt meine Praeferenz wieder.
- die Version genau eingrenzen. Hier kann man die Versionen einzeln herunterladen, mit binaerer Suche sollten 4 Versuche reichen.
- "attr XX verbose 5" fuer einen der Geraete und fuer ZWAVE1 anlegen, und mit der aktuellen und der funktionierenden Version ein Log (damit meine ich FHEM-Log, nicht Event-Log) erstellen. Die Funktionierende muss nicht lang sein, die Aktuelle muss aber bis zum Anzeigen von E5 reichen. Fuer beide Logs bitte "attr global mseclog" setzen.
- Herumexperimentieren: Attribut noExplorerFrames setzen, Zeit-Differenz in ZWave_wakeupTimer() von 1 Sekunde auf 2 aendern, usw.

Weiterhin wuesste ich gerne, welche notifies an den Events der Geraete haengen.

cnkru

Habe bereits gestern aus dem Archiv : 10_ZWave.pm 9094 (19.08) und 10_ZWave.pm 9102 (20.08) runtergeladen
Werde diese erstmal  testen und dann berichten ...
Schließlich lief vor einer Woche noch alles problemlos.
Scripts aus cfg und myUtils folgen heute Abend.
CUL8R
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

cnkru

Heute 19.51 Uhr 10_ZWave.pm 9102 2015-08-20 20:45:54Z  eingespielt
Shutdown Restart durchgeführt, nun heißt es abwarten ...

anbei test.cfg für Thermostat und 99_myUtlis.pm für Steuerung der Heizkurve

RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

rudolfkoenig

Wenn ich recht sehe, es gibt keine notifys, die abhaengig von ZWave-wakeup irgendetwas machen wollen, nur Programme, die beim Setzen von dummy-Werten abgespult werden. Ich vermute, dass diese notifys keinen Einfluss auf das Problem haben.

cnkru

War aus so gewollt, da die Thermostate keine Ist-Temperatur ausgeben.
Somit setzte ich Soll-Werte gemäß Heizplan und hinterfrage regelmäßig ein get battery.
Zuvor hatte ich auch - get setpointTemp, clock, transmit aktiv.
Dafür gibt es jetzt die readingsGroups ...

Übrigens die Thermostate sind gerade alle gestorben ...

Die Readings melden weiter Erfolg als ob alles i.O. wäre (PDF)
Anbei: Logfile fhem, Thermostat und ZWAVE1
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

krikan

@Rudi: 24 Telegrammverluste wegen 011300 im Log ; erinnert mich an mein Problem mit "configRequestAll"

cnkru

Da steckst Du schon etwas tiefer im Detail ;).

Habe jetzt 3 Thermostate reanimiert und zuvor Attribut noExplorerFrames 1 gesetzt (21:40 Uhr).
Logs laufen weiter ...

Nächster Schritt  im Modul  10_ZWave.pm -Version 9102 Zeile 1658,
  if($now - $hash->{lastMsgTimestamp} > 1) { # wakeupNoMoreInformation  die 1auf 2 setzen (korrekt?)

danach ist 10_ZWave.pm Vorläufer 9094 an der Reihe

okay?
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

rudolfkoenig

Ich wuerde erst die Versionen durchprobieren. Und bei der binaerer Suche bleiben (9102 -> 8955 -> je nach Ergebnis 9041 oder 8917, usw.), es sei denn, du hast mehr Info als ich.

cnkru

Guten Morgen,

NoExplorerFrames ausprobiert ...
2 der 3 Thermostate (tot) - eines am Leben, heute Nacht wiederholt - gleiches Ergebnis.

Habe jetzt Version 9041 eingespielt, alle Thermostate reanimiert, Ergebnis heute Abend  ...

Readingsgropus melden brav weiter, ob alle prima funktioniert.

CUL8R
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

cnkru

Habe wieder nach den Sorgenkindern geschaut  ...
Hurra sie leben noch!
Also unter dieser 9041er ZWave.pm scheinen sie stabil zu laufen (zuvor 9102)
Wechsel der Version war heute Morgen kurz nach 06:00 Uhr
Nachts um 1:50Uhr hatte ich jene 2 Thermostate nochmals reanimiert - ist im Log zu sehen
Logs sind dabei ..., falls mehr gewünscht, z.B. 9094 testen,  kurz zurück posten

CU Carsten
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

cnkru

Hier noch Auszug aus fhem-log 19:00 - 19:26 Uhr
mit attr global verbose 5 ab 19:15 Uhr
Sorry nach Neustart wieder verbose 3 nur Dongle mit 5 geloggt
Vielleicht werden hier die Telegrammverluste erklärbar

Jedes notify wird über Milight.pm getriggert siehe ab 19:15
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

rudolfkoenig

Zwischen den beiden Versionen habe ich das Senden der wakeupNoMoreInformation umgestellt.
Ich habe zwar keine plausible Theorie, was da schiefgeht, aber wir koennen versuchen sie zu verifizieren(?)  :)

Kannst du bitte die aktuelle Version einspielen, die Zeile
      IOWrite($hash, "00", "13${nodeId}02840805");
auskommentieren, und einen erneuten Versuch wagen?

krikan

Wenn ich mir das Log vom 01.09. ansehe, gibt es über 400 wegen Fehlern nicht versandte Telegramme und das sind im Wesentlichen die WU-NMI Nachrichten. Also müsste das auskommentieren doch helfen. Danfoss E5 mag kein WU-NMI??

cnkru

Version 9176 eingespielt und Zeile 1745 auskommentiert
#     IOWrite($hash, "00", "13${nodeId}028408${cmdEf}$nodeId");

Jetzt heißt es eine Stunde warten

@Christian ich suche mal in den Manuals bzgl. wakeupnoinformation
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC