(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

cnkru

Alle Thermostate gestorben  :(

Setze erst einmal zurück auf 9041,
Morgen ist auch noch ein Tag  ...

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

cnkru

Noch ein Versuch für diese Nacht  ;)

Version 9094 eingespielt und Zeile 1610 auskommentiert
#    IOWrite($hash, "00", "13${nodeId}02840805");

Ich werde morgen berichten ...

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

cnkru

#17
Ein schöner Morgen hat begonnen und siehe da alle Themostate verrichten ordnungsgemäß ihren Job  :D
Die letzte Version mit oben auskommentierter Zeile funktioniert.

Aber weiterhin regelmäßig Errors oder Telegrammverluste ...

Die Logs, wie gewohnt anbei

@Christian bzgl. Danfoss und  wakeupnoinformation wurde ich nicht fündig, Informationen sind spärlich
                 Das Themostat unterstützt die  Wake Up Klasse Version 2 
                 Implementiert ist SDK 4.55, alle TH auf dem selben Stand
                 Der Beipackzettel gibt auch nicht viel her.
CUL8R
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

krikan

Zitatbzgl. Danfoss und  wakeupnoinformation wurde ich nicht fündig, Informationen sind spärlich
Das ist leider normal. So wirklich verstehen würde ich das Fehlen von WU-NMI auch nicht. Aber es wäre schön einfach gewesen.
Das Danfoss E5 ist allgemein wohl recht zickig, wenn man sich durch die verschiedenen Foren liest.
Dann geht das Rätselraten wohl ein wenig weiter. Insgesamt sind die Logs mMn sehr von Problemen geprägt...

Es wäre prima, wenn auch noch andere Danfoss-User mit aktuellem Fhem hier Infos hätten, ob sie das Problem auch haben.

cnkru

#19
Ich bin mir nicht ganz sicher, ob wir auf der richtigen Spur sind.
Ich werde die 9094 heute Abend ohne kommentierte IOWrite Zeile starten, also den Kommentar entfernen
                         #    IOWrite($hash, "00", "13${nodeId}02840805");
um auszuschließen, daß WU-NMI der Störenfried ist
Mal sehen was die THs dazu sagen ...
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

cnkru

So bin wieder am Start
Version 9094 mit aktiven WU-NMI seit über 2 Stunden stabil

9102 führt zu Fehler E5 - der Übertäter scheint identifiziert

Irgendeine Idee?

ggf. lass ich 9102 noch mal eine Stunde laufen bis E5 auftaucht

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

A.Harrenberg

Hi,

ich habe mir die Logs jetzt noch nicht angesehen, aber die Änderungen zwischen den beiden Revisionen 9094 und 9102 betreffen natürlich wie von Rudi beschrieben den WU-Sendstack.

Eine ganz dumme Idee hierzu, die Umstellung beeinhaltet auch eine Umstellung der verwendeten Systemzeiten von time() auf gettimeofday(), Grund hierfür war soweit ich das verstanden habe die Auflösung zu verbessern.

Wäre es evtl. möglich das bei Dir das gettimeofday() aus irgendwelchen Gründen (sehr alte oder sehr neue PERL Version, fehlendes Modul, ...) nicht funktioniert und das dadurch die neuen Timer, die jetzt das Versenden der WU-NoMoreInformation steuern Amok laufen?

@Rudi: vielleicht an der Stelle mal ein paar Logmessages für die Timer einbauen?

Gruß,
Andreas.

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hallo Rudi,

In ZWave_wakupTimer wird das Senden der WU-NMI ausgelöst wenn der Zeitstempel älter als 1 Sekunde ist, falls nicht wird per Timer darauf gewartet das er älter als 1 Sekunde ist, zumindest wenn ich den Code richtig verstanden habe.

2015.09.01 19:00:30.178 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040006028407
2015.09.01 19:00:30.178 5: SW: 06
2015.09.01 19:00:30.180 5: ZWAVE1 dispatch 00040006028407
2015.09.01 19:00:30.181 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407
2015.09.01 19:00:30.182 5: ZWDongle_Write 00 13060280022506
2015.09.01 19:00:30.183 5: SW: 0109001306028002250640
2015.09.01 19:00:30.185 4: Sending stored command: 13060280022506
2015.09.01 19:00:30.185 5: ZWDongle_Write 00 130605430101011b2506
2015.09.01 19:00:30.186 4: Sending stored command: 130605430101011b2506
2015.09.01 19:00:30.187 4: Sending wakeupNoMoreInformation to node: 06
2015.09.01 19:00:30.187 5: ZWDongle_Write 00 130602840805
2015.09.01 19:00:30.193 5: ACK received, removing 0109001306028002250640 from sendstack
2015.09.01 19:00:30.194 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.09.01 19:00:30.194 5: SW: 06
2015.09.01 19:00:30.196 5: ZWAVE1 dispatch 011301
2015.09.01 19:00:30.198 5: SW: 010c00130605430101011b250699
2015.09.01 19:00:30.200 5: ACK received, removing 010c00130605430101011b250699 from sendstack
2015.09.01 19:00:30.201 5: SW: 01080013060284080569
2015.09.01 19:00:30.205 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.09.01 19:00:30.205 5: SW: 06
2015.09.01 19:00:30.207 5: ZWAVE1 dispatch 011301
2015.09.01 19:00:30.208 4: ZWDongle_Read ZWAVE1: CAN received
2015.09.01 19:00:30.209 5: SW: 01080013060284080569

Das Eintreffen der 8407 WU-Notification sollte ja den Zeitstempel in ZWave_Parse setzen
2015.09.01 19:00:30.181 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407

Das Senden der WU-NMI wird aber bereits nach 0.06 sekunden ausgelöst
2015.09.01 19:00:30.187 4: Sending wakeupNoMoreInformation to node: 06

und nach 0.19s bereits gesendet
2015.09.01 19:00:30.201 5: SW: 01080013060284080569

Abgesehen davon das hier gesendet wird bevor die RM von dem letzten Befehl da ist, kann hier irgendwas mit den Timer nicht in Ordnung sein.

Gruß,
Andreas.

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

Hallo Andreas,

anbei meine  Version

perl -v

This is perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 89 registered patches, see perl -V for more detail)

Copyright 1987-2011, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

A.Harrenberg

Hi cnkru,

sorry, aber mit der Versionsnummer kann ich nichts anfangen, ich bin auch kein PERL Guru der da was dran erkennen könnte.

Mir ist nur aufgefallen das die Änderung den Timer betrifft und das die WakeUp-NoMoreInformation Nachrichten viel zu schnell freigeben werden.

Im Listing aus Deinem ersten Post ist
Internals:
   ... einiges gelöscht ...
   lastMsgTimestamp 1440929696

der Zeitstempel bei Dir auch ohne "Punkt" und Nachkommastelle.

Bei mir ist das z.B. lastMsgTimestamp 1441313295.57628

Ich habe mal "offline" eine Version mit ein paar Logmessages für die Timer beim WakeUpStack gemacht und angehängt. Das kann ich aber momentan nicht probieren da ich hier momentan eine andere "Baustelle" habe ,-)

Vielleicht sieht man dadurch ja schon was. Vielleicht bin ich auch völlig auf dem Holzweg, dann musst Du auf Rudi warten.

Gruß,
Andreas.

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

Hallo Andreas,

guter Tipp, das bringt mich auf eine Idee ...
Ich werde heute prüfen, ob das high-resolution Paket von Perl installiert ist
und ggf. updaten ( ... install Time::HiRes )

Deine Logs aus der aktuellen 10_ZWave.pm werde ich erst mal in der lauffähigen Version 9094 implementieren.
Ich wünsche uns viel Erfolg.

Werde später berichten

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

Hab die Daten nicht naeher angeschaut, aber:
Das Time::HiRes muss da sein, sonst kann fhem.pl nicht starten. Die Log Ausgaben mit msec und InternalTimer verwenden die gleiche Funktion.

A.Harrenberg

Hallo,
Zitat von: rudolfkoenig am 04 September 2015, 12:14:33
Hab die Daten nicht naeher angeschaut, aber:
Das Time::HiRes muss da sein, sonst kann fhem.pl nicht starten. Die Log Ausgaben mit msec und InternalTimer verwenden die gleiche Funktion.
das wird ja mit use eingebunden und müsste auch einen Fehler werfen wenn nicht installiert. Soweit sehe ich das auch so, allerdings finde ich es auffällig das lastMsgTimestamp 1440929696 bei cnkru keine Nachkommastellen ausweist und die WU-NMI früher ausgelöst wird als man anhand des Codes und des Timers erwarten würde. Es sieht so aus als ob der immer der Meinung ist das der Timestamp immer älter als eine Sekunde ist.

Wäre es vielleicht noch denkbar das verschiede Versionen mal in sekunden und mal in millisekunden ausgeben?

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

Hallo Andreas

habe doch die ZWave.pm 9176 eingespielt seit 20:40 Uhr
habe mir erlaubt in Zeile 1773 noch ein Dezimalpunkt zu spendieren
anbei ein erster Log, warte gespannt auf E5

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

A.Harrenberg

Hi cnkru,
Zitat von: cnkru am 04 September 2015, 21:01:55
habe doch die ZWave.pm 9176 eingespielt seit 20:40 Uhr
habe mir erlaubt in Zeile 1773 noch ein Dezimalpunkt zu spendieren
anbei ein erster Log, warte gespannt auf E5
Log schaue ich mir gleich an, ob da in Zeile 1773 nun 1 oder 0.1 drin steht sollte keinen wirklichen Unterschied machen, das ist "nur " die Stelle an der die Abfrage das erst mal kommt.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

Die Thermostate leben noch  :D
Telegrammverluste sind jedoch vorhanden

anbei noch ein LOG vom Thermostat_Test

werde mich morgen wieder melden


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

A.Harrenberg

#31
Hi cnkru,

alter Schwede, da geht ja der Punk ab in dem Log...
In nicht mal 15 Minuten 208 CAN Messages, und 61 mal "ERROR: cannot SEND_DATA: 00"
Am Timer scheint das aber schon mal nicht zu liegen, im Log gibt es Nachkommastellen und der Aufruf für das Versenden WU-NMI wartet auch bis mind. 1 Sekunde vergangen ist.

Ich würde mal tippen das Du hier auch sehr bald E5-Fehler bekommst...

Im Log geht es ja gleich mit einem Cancel los, Ich hab' mir hier mal ein Stück vom Anfang des Logfile rausgesucht nachdem sich das System das erste Mal etwas beruhigt hatte... (BTW, Du hast Freeze-Warnings im Log...)

Ich "schnippel" den Teil hier mal auseinander und schreibe mal meine Erkenntnisse dazu:
2015.09.04 20:40:30.800 2: ZWave get Thermostat_Bad battery
2015.09.04 20:40:30.801 3: zAt1: Scheduled for sending after WAKEUP
2015.09.04 20:40:30.890 2: ZWave get Thermostat_Flur battery
2015.09.04 20:40:30.891 3: zAt9: Scheduled for sending after WAKEUP
2015.09.04 20:40:30.961 2: ZWave get Thermostat_Treppe battery
2015.09.04 20:40:30.962 3: zAt15: Scheduled for sending after WAKEUP
2015.09.04 20:40:31.178 3: ZWave reading config for unknown
2015.09.04 20:40:32.295 2: ZWave get KFOB battery
2015.09.04 20:40:32.296 3: kfobAt1: Scheduled for sending after WAKEUP

Hier werden einige Befehle auf den WakeUp-Stack gelegt. Das "ZWave reading config for unknown" verstehe ich aber nicht...
Zu diesem Zeitpunkt ist das Device 0x19 "sleeping", das ist weiter unten wichtig...


2015.09.04 20:40:44.749 1: Perfmon: possible freeze starting at 20:40:41, delay is 3.748
2015.09.04 20:41:23.592 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004001903800353
2015.09.04 20:41:23.593 5: SW: 06
2015.09.04 20:41:23.594 5: ZWAVE1 dispatch 0004001903800353
2015.09.04 20:41:23.595 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:19 ARG:03800353
2015.09.04 20:41:23.609 2: ZWave set Thermostat_Haustuer setpointHeating 20
2015.09.04 20:41:23.610 5: ZWDongle_Write 00 131905430101011405
2015.09.04 20:41:23.611 5: SW: 010b00131905430101011405a8

Hier beginnt dann das Chaos: Ein BatteryReport von 0x19 (Thermostat_Haustuer) wird empfangen, direkt danach wird der Befehl set-setpointHeating an 0x19 verschickt (per Notifiy ?)


2015.09.04 20:41:23.625 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040019064303014207d0
2015.09.04 20:41:23.626 5: SW: 06
2015.09.04 20:41:23.627 5: ZWAVE1 dispatch 00040019064303014207d0
2015.09.04 20:41:23.628 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:19 ARG:064303014207d0
2015.09.04 20:41:23.638 2: ZWave set Thermostat_Haustuer setpointHeating 20
2015.09.04 20:41:23.639 5: ZWDongle_Write 00 131905430101011405
2015.09.04 20:41:23.641 4: ZWDongle_Read ZWAVE1: CAN received
2015.09.04 20:41:23.742 5: SW: 010b00131905430101011405a8

Direkt nach dem Versenden dieses Befehls kommt jedoch eine weitere "Meldung" mit einem SetpointReport von 0x19, noch bevor der Empfang des set-setpointHeating von 0x19 bestätigt wird.
Dadurch kommt es zum CAN und dem erneuten verschicken des set-setpointHeating Befehls.


2015.09.04 20:41:23.745 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040019044608007f
2015.09.04 20:41:23.745 5: SW: 06
2015.09.04 20:41:23.747 5: ZWAVE1 dispatch 00040019044608007f
2015.09.04 20:41:23.747 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:19 ARG:044608007f
2015.09.04 20:41:23.757 2: ZWave set Thermostat_Haustuer setpointHeating 20
2015.09.04 20:41:23.758 5: ZWDongle_Write 00 131905430101011405
2015.09.04 20:41:23.760 4: ZWDongle_Read ZWAVE1: CAN received
2015.09.04 20:41:23.861 5: SW: 010b00131905430101011405a8

Und täglich grüßt das Murmeltier: nach dem erneuten Versenden des Befehls kommt erneut eine weitere Meldung von 0x19 (irgendwas mit Climate_Control_Schedule) bevor der Empfang der Nachricht bestätigt wird. Hierdurch kommt es wieder zum CAN und dem erneuten versenden der Nachricht.


2015.09.04 20:41:23.864 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040019028407
2015.09.04 20:41:23.864 5: SW: 06
2015.09.04 20:41:23.866 5: ZWAVE1 dispatch 00040019028407
2015.09.04 20:41:23.867 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:19 ARG:028407

Tada, die WakeUp-Notifikation trifft ein... Das ist Teil des Problems, dazu mehr weiter unten


2015.09.04 20:41:23.868 0: Thermostat_Haustuer: WakeUpStack abgearbeitet, Starte Timer f�r ZWave_wakupTimer
2015.09.04 20:41:23.877 2: ZWave set Thermostat_Haustuer setpointHeating 20
2015.09.04 20:41:23.877 5: ZWDongle_Write 00 131905430101011405
2015.09.04 20:41:23.880 4: ZWDongle_Read ZWAVE1: CAN received
2015.09.04 20:41:23.981 5: SW: 010b00131905430101011405a8

Noch mal Phil, das Murmeltier, das Eintreffen der WakeUp-Notification war natürlich auch wieder bevor der Empfang bestätigt wurde, daher wieder CAN und erneutes Versenden.
Hier wird allerdings auch noch mal der Befehl NEU erzeugt (wodurch? Noch mal ein Notify? Auf was triggerst Du alles?)


2015.09.04 20:41:23.984 0: Thermostat_Haustuer: now=1441392083.98405 lastMsgTimestamp=1441392083.86756
2015.09.04 20:41:23.984 0: Thermostat_Haustuer: weniger als 1 Sekunde Zeitdifferenz erkannt, Timer=1441392084.08405

Hier kann man sehen das die Timer richtig funktionieren. Da noch keine 1 Sekunde vergangen ist wird die Routine noch mal per Timer gestartet


2015.09.04 20:41:23.986 5: ACK received, removing 010b00131905430101011405a8 from sendstack
2015.09.04 20:41:23.987 5: SW: 010b00131905430101011405a8
2015.09.04 20:41:23.989 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.09.04 20:41:23.990 5: SW: 06
2015.09.04 20:41:23.991 5: ZWAVE1 dispatch 011301
2015.09.04 20:41:23.992 4: ZWDongle_Read ZWAVE1: CAN received
2015.09.04 20:41:24.093 5: SW: 010b00131905430101011405a8

Ok, ab hier wird es schwieriger, es kommt jetzt zumindest mal eine 011301, aber dennoch eine CAN Message. Das kann ich jetzt nicht erklären...


2015.09.04 20:41:24.096 0: Thermostat_Haustuer: now=1441392084.09675 lastMsgTimestamp=1441392083.86756
2015.09.04 20:41:24.097 0: Thermostat_Haustuer: weniger als 1 Sekunde Zeitdifferenz erkannt, Timer=1441392084.19675
2015.09.04 20:41:24.098 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131c000002
2015.09.04 20:41:24.099 5: SW: 06
2015.09.04 20:41:24.100 5: ZWAVE1 dispatch 00131c000002
2015.09.04 20:41:24.101 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.09.04 20:41:24.101 4: ZWAVE1 transmit OK for 1c

Ab hier wird es dann sehr merkwürdig, hier wird eine Übertragung der Node 0x1c bestätigt, ich kann jedoch keine dazugehörige Nachricht finden. Das letzte Mal taucht hier dies hier "2015.09.04 20:40:17.334 4: ZWAVE1 transmit OK for 1c" auf


2015.09.04 20:41:24.102 4: ZWDongle_Read ZWAVE1: CAN received
2015.09.04 20:41:24.203 5: SW: 010b00131905430101011405a8
2015.09.04 20:41:24.206 0: Thermostat_Haustuer: now=1441392084.20643 lastMsgTimestamp=1441392083.86756
2015.09.04 20:41:24.206 0: Thermostat_Haustuer: weniger als 1 Sekunde Zeitdifferenz erkannt, Timer=1441392084.30643
2015.09.04 20:41:24.208 5: ACK received, removing 010b00131905430101011405a8 from sendstack
2015.09.04 20:41:24.209 5: SW: 010b00131905430101011405a8
2015.09.04 20:41:24.211 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.09.04 20:41:24.212 5: SW: 06
2015.09.04 20:41:24.213 5: ZWAVE1 dispatch 011301
2015.09.04 20:41:24.214 4: ZWDongle_Read ZWAVE1: CAN received
2015.09.04 20:41:24.315 5: SW: 010b00131905430101011405a8

Ab hier geht es dann vollkommen durcheinander, das CAN triggert das erneute Versenden der Nachricht, kurz danach wird die gleiche Nachricht (der Befehl wurde etwas weiter oben ja auch noch mal identisch erzeugt) verschickt, natürlich bevor die Empfangsbestätigung da ist -> CAN...

Das geht noch eine ganze Weile so, letztendlich kommt irgendwann mal eine Nachricht durch...

Meiner Meinung nach kommen hier mehrere Probleme zusammen:

WakeUp-Stack: Momentan wird geschaut ob der TimeStamp älter als 3 Sekunden ist, falls ja wird angenommen das die Node schläft und die Befehle werden auf den Stack gelegt. Der TimeStamp wird aber in ZWave_Parse, also nach dem Eintreffen eine Nachricht aktualisiert. Der Report vom Gerät trifft ein, das Parsen der Nachricht aktualisiert den TimeStamp. Ein Notify reagiert auf die Nachricht und verschickt eine neue Nachricht. Das Gerät schläft "offiziell" noch, der TimeStamp ist aber jünger als 3 Sekunden und es wird direkt versendet anstatt die Nachricht auf den Stack zu legen.

Timing der reSends nach CAN: Irgendwie ist hier das Timing denkbar ungünstig. Die CAN Nachricht und der ReSend der Nachricht kommen irgendwie immer kurz bevor das Geräte gerade seine weiteren Stati sendet.

Generell das Versenden während eine andere Kommunikation läuft: Hier müsste mit dem ReSend gewartet werden bis die von der Node gesendete Nachricht beendet ist und dann gesendet werden.

Die CAN Messages könnten jetzt mMn zwei Gründe haben, einmal die Tatsache das hier vom Controller gesendet wird, zeitgleich das Gerät aber etwas sendet, oder einfach die Tatsache das das Gerät "offiziell" noch schläft und deswegen kategorisch CAN Messages verschickt. (Ich halte aber den ersten Grund für warscheinlicher).

Ich verstehe aber die Nachrichten für die Node 0x1c die da am Ende auftauchen auch nicht, werden die Nachrichten für 0x19 vielleicht über 0x1c geroutet?

Falls ich richtig geraten habe und Du per Notify auf die Nachrichten von dem Thermostat reagierst und da Werte hinschickst, könntest Du mal versuchen dort erst ein "sleep" mit 0.8 sekunden zu nutzen (auf die Syntax achten, sonst blockierst Du FHEM), damit hätte das Thermostat etwas mehr Zeit seine Nachrichten loszuwerden bevor Du antwortest.

Das Problem mit dem WakeUp-Stack muss im Code gelöst werden, ich bin mir aber nicht sicher ob dies viel Einfluss auf das Verhalten Deines Systems hätte.
Das Problem mit dem Timing der ReSends müsste ebenfalls im Code gelöst werden, allerdings dachte ich das Rudi da bereits etwas eingebaut hätte das nach jedem CAN etwas länger gewartet wird.

Rudi mag diesen langen Postings nicht, ich hoffe aber das er ihn dennoch liest... ,-)

Allerdings kann ich jetzt gerade keinen direkten Zusammenhang dieses Verhaltens mit den Änderungen aus 9102 ggü. 9094 erkennen. Auslöser ist mMn das Versenden einer Nachricht per Notify direkt nach Eintreffen eines "unsolicited" Reports vom Gerät. Und in dem Umfeld ist mir jetzt keine Änderung aufgefallen.

Ich hoffe das hilft etwas bei der Lösung des Problems, wobei ich wie gesagt den Zusammenhang mit der 9102 nicht erkenne.

Gruß,
Andreas.

P.S.: Hast Du ein Gerät mit ID 0x19? Wenn ja, was ist das? [EDIT: Ich meine natürlich 0x1c]
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

Guten Morgen Andreas,

erstaunlicherweise leben noch alle Thermostate  :)
um Deine Fragen zu beantworten, hier Folgendes

Die notify's habe ich vorgestern eingebaut, in der Hoffnung das die Telegrammverluste geringer werden
zuvor wurde ein Thermostat setpointHeating und ein Temperatur_Soll_Haustuer jeweils in der Routine "heizkurve" alle 10 Minuten gesetzt

jetzt erfolgt setpointHeating beim Aufwachen des Thermostates (Code der heizkurve unter auf der 1.Seite)
Hier das Beispiel der Haustuer, übrigens Gerät 0x19:

#
# Danfoss Heiungsthermostat Haustuer 25 entspricht 0x19
#
   
define Thermostat_Haustuer ZWave da271298 25
attr Thermostat_Haustuer IODev ZWAVE1
attr Thermostat_Haustuer classes BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
attr Thermostat_Haustuer noExplorerFrames 1
attr Thermostat_Haustuer room ZWave
attr Thermostat_Haustuer verbose 5

define FileLog_Thermostat_Haustuer FileLog %L/Thermostat_Haustuer-%Y-%m.log Thermostat_Haustuer
attr FileLog_Thermostat_Haustuer logtype text
attr FileLog_Thermostat_Haustuer room Logs

define Temperatur_Soll_Haustuer dummy
attr Temperatur_Soll_Haustuer group Heizung_Soll_Temperatur
attr Temperatur_Soll_Haustuer room ZWave,Heizung
define zAt13 at +*00:10:30 get Thermostat_Haustuer battery
define zAt14 notify  Thermostat_Haustuer {my $WertTT=ReadingsVal("Temperatur_Soll_Haustuer","state",0);; fhem("set Thermostat_Haustuer setpointHeating $WertTT");;}
#
# Heizkurve benutzen wenn Automatik an
#
define CheckHeizwert6 at +*00:15:00 {heizkurve($we,"Temperatur_Soll_Haustuer",Value("d_Ferien"),0) if(Value("d_Hand") eq "Automatisch")}
attr CheckHeizwert6 alignTime 00:01:10 //# wurde genutzt um setpoint in der heizkurve bei 9 Thermostaten etwas auseinander zu ziehen


Das Geräte 0x1c ist mein Test_Thermostat
Deine Vermutung ist richtig, da get battery im stack alle 10 Minuten abgelegt wird, wird dieses vor setpoitHeating behandelt...
Deine Empfehlung ein Sleep 0.8 einzubauen, werde ich probieren..

define zAt14 notify  Thermostat_Haustuer {my $WertTT=ReadingsVal("Temperatur_Soll_Haustuer","state",0);; sleep 0.8;; fhem("set Thermostat_Haustuer setpointHeating $WertTT");;}


Ein Routing von 0x19 über 0x1c dürfte eigentlich erfolgen, das können die Thermostate nicht.

Vorschlag:
1. Ich bau ein sleep ein damit der Stack erst abgearbeitet wird bevor ein setpoint Heating erfolgt
und lass das mal 1 Stunde laufen

2. Ich nehme das notify raus und überlass meine Routine "heizkurve" das setpoint Heating dann wird der Stack der Reihenfolge abgearbeit, wie gehabt

Gruß
Carsten



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

cnkru

anbei ein Log mit sleep bei den Geräten 0x19 und 0x1c

Ich baue jetzt  bei allen Thermostaten ein sleep im notify ein

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

A.Harrenberg

Guten Morgen cnkru,
Zitat von: cnkru am 05 September 2015, 07:44:18
erstaunlicherweise leben noch alle Thermostate  :)
wundert mich... Bei den vielen Kollisionen und Paketverlusten...

Zitat von: cnkru am 05 September 2015, 07:44:18
Die notify's habe ich vorgestern eingebaut, in der Hoffnung das die Telegrammverluste geringer werden
define zAt14 notify  Thermostat_Haustuer {my $WertTT=ReadingsVal("Temperatur_Soll_Haustuer","state",0);; fhem("set Thermostat_Haustuer setpointHeating $WertTT");;}
Ich bin jetzt nicht der Experte für notify, aber Thermostat_Haustuer ist ja direkt das Device, ohne irgendwelche regex, wird das jetzt bei JEDEM Event getriggert? Das wäre dann auch nicht so geschickt, da das zu sehr vielen Nachrichten führen würde. Geschickter wäre es hier auf die WakeUp-Events zu triggern, das würde auch verhindern das unnötigerweise mehrere gleiche Befehle auf dem WakeUp-Stack landen.

Zitat von: cnkru am 05 September 2015, 07:44:18
Das Geräte 0x1c ist mein Test_Thermostat
Deine Vermutung ist richtig, da get battery im stack alle 10 Minuten abgelegt wird, wird dieses vor setpoitHeating behandelt...
Deine Empfehlung ein Sleep 0.8 einzubauen, werde ich probieren..
Und wenn meine Theorie mit dem Notify stimmt wird das Eintreffen der Battery-Reports noch mal setpointHeating triggern...
Das mit den 0.8 Sekunden ist ja auch erst mal nur ein Workaround um dem Gerät mehr Zeit zu geben was zu senden.

Zitat von: cnkru am 05 September 2015, 07:44:18
Ein Routing von 0x19 über 0x1c dürfte eigentlich erfolgen, das können die Thermostate nicht.
Ich gehe davon aus dort ein "nicht" fehlt...

Zitat von: cnkru am 05 September 2015, 07:44:18
Vorschlag:
1. Ich bau ein sleep ein damit der Stack erst abgearbeitet wird bevor ein setpoint Heating erfolgt
und lass das mal 1 Stunde laufen

2. Ich nehme das notify raus und überlass meine Routine "heizkurve" das setpoint Heating dann wird der Stack der Reihenfolge abgearbeit, wie gehabt
Mehr Ideen hätte ich kurzffristig auch nicht.

Im Code für Security habe ich angefangen die Abarbeitung des WakeUp-Stacks, das "Schlafenlegen" des Geräts per "WU-NMI" (WakeUp-NoMoreInformation) und das Aktivieren des WakeUp-Stacks über eine Statusvariable zu steuern, das ist aber noch nicht fertig und ich muss Rudi noch davon überzeugen ,-)

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi cnkru,
Zitat von: cnkru am 05 September 2015, 08:15:28
anbei ein Log mit sleep bei den Geräten 0x19 und 0x1c

Ich baue jetzt  bei allen Thermostaten ein sleep im notify ein
habe jetzt nur mal kurz in das Log reingeschaut, das ist immer noch Kraut und Rüben durcheinander. Auf die Schnelle konnte ich jetzt auch erst mal nicht erkennen das die Geräte 0x19 und 0x1c da irgendwie deutlich besser geworden wären.

Ich denke das Hauptproblem ist das Nachrichten gesendet werden bevor überhaupt die WU-Notifiication kommt und das anscheinend Dein Notify auf jede Nachricht reagiert, was dann für jeden Report erneut eine Nachricht mit set setpoint auslöst. Das hat einen gewissen Lawineneffekt.

Könntest Du mal versuchen die Notifies auf die WU-Notification, also die 0x8407 Nachricht, zu triggern?

define zAt14 notify  Thermostat_Haustuer:wakeup:.* {my $WertTT=ReadingsVal("Temperatur_Soll_Haustuer","state",0);; fhem("set Thermostat_Haustuer setpointHeating $WertTT");;}

Ich HOFFE das die Syntax für das notify so richtig ist, bitte noch mal selbst prüfen, damit stehe ich immer auf dem Kriegsfuß...

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

Habs eingebaut und sleep wieder entfernt

define zAt14 notify  Thermostat_Haustuer:wakeup:.*  {fhem("my $WertTT=ReadingsVal("Temperatur_Soll_Haustuer","state",0);; set Thermostat_Haustuer setpointHeating $WertTT");;}

Lass das mal ne Weile laufen und schick dann den Log
CU
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

A.Harrenberg

Hi,
Zitat von: cnkru am 05 September 2015, 09:44:42
Habs eingebaut und sleep wieder entfernt
lass den Sleep ruhig mal drin, das Notify kommt sonst nach wie vor mit der Abarbeitung des WakeUp-Stacks in Konflikt.

Ich bastel gerade mal an einer Version die das vorzeitige Senden während des Abarbeitens des WakeUp-Stacks verhindern sollte, das dauert aber noch ein wenig...

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

#38
Hi cnkru,
Zitat von: A.Harrenberg am 05 September 2015, 09:51:47
Ich bastel gerade mal an einer Version die das vorzeitige Senden während des Abarbeitens des WakeUp-Stacks verhindern sollte, das dauert aber noch ein wenig...
wie Risikofreundlich bist Du eigentlich? ;-)

Ich hätte eine erste Version der 10_ZWave.pm anzubieten in der neue Nachrichten während des Abarbeitens des WakeUp-Stacks an das Ende des WakeUp-Stacks anhängt werden. Damit sollte eigentlich keine Nachricht mehr gesendet werden bis der Stack leer ist. Danach ist das Gerät dann 1 Sekunde "wach", anschliessend wird die WU-NMI gesendet und der WU-Stack wird wieder aktiv.

So zumindest die Theorie, denn ich habe hier kein WU-Gerät zum testen und kann das nur ein wenig händisch simulieren und testen.

Das ist die Version für Security, könnte sein das da ein paar Fehlermeldung im Log ausgegeben werden weil Du höchstwahrscheinlich das Crypt Modul nicht installiert hast, es sollte aber dennoch funktionieren.

Falls Du das testest wäre ich auch an einem Test mit der ursprünglichen Form der Notifies interessiert, das wäre ja genau der Fall der hier unterbunden werden soll.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

Hallo Andreas,

erstmal vielen Dank für Deine Ideen,  Du kennst ja den Spruch - no risk - no fun -

also step by step :
zunächst habe hier ein LOG mit notify wakeup anzubieten.

Habe 6 Thermostate so eingerichtet außer Kueche 31/0x1f, WZ 32/0x20 und Bad 06/0x06
übrigens alle Thermostate laufen stabil


Deine neue Version 10_ZWave.pm spiele gleich ein, gibt ja immer noch ein Fallback
Bis in einer Stunde - mit oder ohne E5

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

cnkru

Hallo Andreas,

noch läuft alle wie gehabt, Deine Version mit dem WU-Stack ist eingespielt
anbei ein LOG in zwei Detailansichten, wenn NO_ACK auftritt

Ich lasse die Version weiter laufen, bin gleich außer Haus, wenn heute Abend die Bude kalt ist, ist zwar der WAF im Eimer,
aber das lässt sich wieder heilen.

Gemäß Murphy's Gesetz des Backups
Ein Sicherungsmedium funktioniert immer dann nicht, wenn man es braucht :D

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

cnkru

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

A.Harrenberg

Hallo cnkru,
Zitat von: cnkru am 05 September 2015, 12:45:48
noch läuft alle wie gehabt, Deine Version mit dem WU-Stack ist eingespielt
anbei ein LOG in zwei Detailansichten, wenn NO_ACK auftritt

Ich lasse die Version weiter laufen, bin gleich außer Haus, wenn heute Abend die Bude kalt ist, ist zwar der WAF im Eimer,
aber das lässt sich wieder heilen.
Uff, jetzt bist Du deutlich schneller als ich mir die Logs anschauen kann...

Erst mal zu dem vorherigen Log einige Anmerkungen:

  • Läuft schon mal deutlich besser durch, Probleme treten (hauptsächlich) bei den Thermostaten auf die nicht umgestellt waren. -> Triggern der Notify auf wakeup ist richtig(er) und hilft auf jeden Fall.
  • Durch Trigger auf Notify statt auf "irgendein" Device-Event verringert sich die Funklast entscheidend. Das nicht umgestellte Thermostat 0x1f (Küche) sendet an einer Stelle z.B. drei Werte (Batterie, ...), hierdurch wird unnötigerweise drei mal die Nachricht mit dem Setpoint getriggert.
  • Was ist Device 0x08? Hier kommen sporadisch Batteriewerte aber ich habe KEINE WakeUp-Notification gefunden, ist eventuell das WakeUp-Interval nicht konfiguriert?
  • Auch beim umgestellten Thermostat 0x1c (Test) kommt es noch zu CAN Messages, hier scheint die letzte Nachricht vom WakeUp-Stack mit der Notifikation zu kollidieren
  • Für mich unerklärliche "ZWAVE1 transmit OK for 1f" tauchen auch an Stellen auf an denen ich keine Kommunikation mit der Node 0x1f erkenne
  • (Teilweise) funktioniert auch die Kommunikation der nicht umgestellten Thermostate, anscheinend ist dann das Timing zwischen den Nachrichten von der Node und den gesendeten Nachrichten zufällig besser

2015.09.05 10:49:28.592 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131f000002
2015.09.05 10:49:28.593 5: SW: 06
2015.09.05 10:49:28.595 5: ZWAVE1 dispatch 00131f000002
2015.09.05 10:49:28.595 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.09.05 10:49:28.596 4: ZWAVE1 transmit OK for 1f


NO_ACK hatte ich mir bisher noch nicht angesehen, da ich aber auch noch nicht verstanden habe wann/warum ein NO_ACK generiert werden soll nutzt das auch wenig ,-) Ich lass mal was für Rudi und Krikan übrig.

Was für eine Heilmethode für beschädigte WAF hast Du denn? Daran sind hier sicherlich noch mehr interessiert?

Ich werfe noch mal einen kurzen Blick in die neuen Logs, bin dann aber auch weg und dann erst morgen wieder da.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

Bin schon auf dem Sprung ...
Das Device 0x08 ist ein FIB_WALL_PLUG sendet power: und energy: Werte im Abstand von 30 Minuten oder wenn es deutliche Veränderungen im Verbrauchverhalten gibt
notify auf wakeup zu triggern macht schon Sinn, das "Prellen" (mehrfaches triggern) könnte ich, wenn gewollt durch eine Logik true/false mit timestamp entschärfen

notify .... {if(last_notify_wake_up("Thermostat_Test",sec)) {fhem("set Thermostat_Test setpointHeating ...")}

Dann aber erst heute Abend wieder ...

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

A.Harrenberg

Hi,

auch nur ganz kurz,

soweit ich das im Log sehe läuft das halbwegs, aber der Time mit 0.05 sekunden scheint etwas zu optimistisch zu sein...

Kannst Du evtl. noch in Zeile 2481 und Zeile 2491 aus der 0.05 mal eine 0.15 machen?

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

ZitatRudi mag diesen langen Postings nicht, ich hoffe aber das er ihn dennoch liest... ,-)

Ja, weil je laenger, desto mehr Zeit muss man ins Nachdenken investieren.

Was ich mitgenommen habe: ihr seid freudig an Experimentieren, harte Fakten sind aber noch nicht rausgekommen, nur "wenn ich alles aendere, dann ist es etwas weniger komisch".

Ich habe vor diesen Vorschlag zu imlementieren, und dann sehen wir mal weiter.
Wahrscheinlich werde dabei das Setzen von lastMsgTimestamp auch anpassen.

krikan

Zitat von: rudolfkoenig am 05 September 2015, 17:22:32
harte Fakten sind aber noch nicht rausgekommen,
Folgendes Problem in der Verarbeitung des Wakeup-Sendstacks haben Andreas und Carsten mMn festgestellt, das ich auch bestätigen kann:
Sobald vom Node eine Nachricht (nicht nur WU-N) empfangen wird, wird der Timestamp, der der awake-Prüfung zugrunde liegt, aktualisiert. Dadurch werden alle Nachrichten 3 Sek danach an den Node verschickt, obwohl er eventuell gar nicht wach ist, da es keine WU-N sondern irgendeine andere Nachricht war. Es kommt zum Telegrammverlust mit NO_ACK (0013xx01). Habe es gerade noch mal nachgestellt. Bei "unscharfen" regexp im notify oder unglücklichen at-Zeiten ist das unter Umständen fatal.

Oder hattest Du das bereits als harte Fakten auf Deiner Liste!?:
ZitatWahrscheinlich werde dabei das Setzen von lastMsgTimestamp auch anpassen.

rudolfkoenig


cnkru

#48
Hallo Andreas,
Zitat
soweit ich das im Log sehe läuft das halbwegs, aber der Time mit 0.05 sekunden scheint etwas zu optimistisch zu sein...

Kannst Du evtl. noch in Zeile 2481 und Zeile 2491 aus der 0.05 mal eine 0.15 machen?

Habe ich jetzt geändert und nehme notify...wakeup wieder mit rein
Alle Thermostate sind gestorben (E5) außer Thermostat_Jule

Vermutlich ein schrittweises Ableben gegen 16:00 oder 17:00
Anbei der LOG und Auszug vom LOG TH_Test (jede Menge TRANSMIT_NO_ACK ab 16:00)
LOG TH_Kueche sind ganz schlimm aus, ab und zu kam ein setpoint durch   :(

anbei die LOGS

Gruß
Carsten

Nachtrag 20:00 Uhr wieder alle Thermostate mit E5 - außer Thermostat_Jule
Gehe zurück auf die Vormittags-Version um den Abend ruhiger zu begehen

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

cnkru

#49
Noch eine Idee zum sogenannten mehrfachen notify innerhalb weniger Millisekungen (sogenanntes "Prellen").

habe ein wenig gebastelt - könnte behilflich sein.

Idee ist erstes notify:wakeup durchlassen und dann 1 oder 2 Sekunden nicht mehr, wenn dieses hintereinander erfolgt
Die Prozedur soll also das notify-Signal nur einmal durchlassen und in der gewählten Zeit kein weiteres zulassen (also solange abwarten)
D.h. es wird geprüft, ob der Thermostat in der angegebenen Zeit bereits ein Notify gesendet hat

In myUtils_Initialize($$) die Notify Gruppe einfügen
  our $one_notify_signal_gruppe;
sub
one_notify($$)
{
    my($device, $delay_time) = @_;
# Übergabe-Parameter Device und Zeit (sec.)
    my $cur_time = time();
    my $old_time = $main::one_notify_signal_gruppe->{$device};
   
    if(!defined($old_time)) {
# wenn Geraet nicht vorhanden neues device und timestamp in notify-Geraete-Gruppe anlegen
        $main::one_notify_signal_gruppe->{$device}=$cur_time;
        return 1;
    }   
# Wiederholungsfall überprüfen
    my $delta_t = $old_time-$cur_time+$delay_time;
    if($delta_t gt 0) {
# delay_time noch nicht erreicht
        return 0;
    }
# delay_time abgelaufen, timestamp neu anlegen mit cur_time
    $main::one_notify_signal_gruppe->{$device}=$cur_time;
    return 1;
}



Aufruf mit:
define zAt14 notify  Thermostat_Haustuer:wakeup:.*  {if(one_notify("Thermostat_Haustuer",2))\
{my $WertTT=ReadingsVal("Temperatur_Soll_Haustuer","state",0);; fhem("set Thermostat_Haustuer setpointHeating $WertTT");;}}

Füge ich in TH_Haustuer und TH_Test ein

mal sehen ob es klappt ...

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

Carsten: falls du noch Geduld zum Experimentieren hast: ich habe gerade eine neue Version von 10_ZWave.pm und 00_ZWDongle.pm eingecheckt, siehe mein Kommentar.

cnkru

Hallo Rudolf,

kein Problem lade ich morgen früh runter...
wo zu finden, auf Thema msg329852nicht fündig -  auf sourceforge.net oder klassisches Update?

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

Auf sourceforge bzw. SVN jetzt, und ab morgen 08:00 per update.

cnkru

Zitat von: rudolfkoenig am 05 September 2015, 22:56:20
Auf sourceforge bzw. SVN jetzt, und ab morgen 08:00 per update.
Eingespielt ...
Melde mich morgen früh

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

A.Harrenberg

Hallo cnkru,

habe mir die neuen Logs noch nicht angesehen, aber das die Testversion nicht richtig lief konnte ich an dem ersten Log bereits sehen. Da waren noch ein paar Fehler drin, ich habe den WakeUp-Stack einen Befehl zu früh freigegeben, dadruch kam es wieder zu Kollisionen, durch NO_ACK wurde mein Ablauf mit dem Status zur Steuerung des WakeUp-Stacks völlig außer Kraft gesetzt, da es eine Abfrage auf den NO_ACK gibt die ich nicht beachtet hatte, deswegen ist bei mindestens einem Thermostat der WakeUp-Stack vollkommen deaktiviert worden.

Ich hatte da auch schon was dran geändert, da Rudi aber eine neue Version gemacht hat, sollten die Tests erst mal damit weiterlaufen. Die Notify (für die WakeUp-Geräte auf jedenfall auf die Wakup-Notification umstellen, das verringert auf jeden Fall die Funklast.

Ich muss mir jetzt erst mal ansehen was Rudi da alles geändert hat.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

#55
Guten Morgen Jungs :D,

Diese Version lief erst einmal durch - alle Thermostate leben und tun was sie sollen
Die LOGS haben ihre bekannten Errors, jedoch nach einer kurzen Serie zwischendurch eine Stunde Pause

@ Andreas: Gern stehe ich zur Verfügung und teste fleißig mit  :),

anbei - wie gewohnt die LOGS und wenn gewünscht noch von einem anderen Geräte

P.S. "wakeup:.* " wurde bei allen Geräten eingerichtet, TH: WZ Test Haustuer und Flur
       haben noch die Routine  "onenotify(device,time)" nach dem wakeup bekommen.
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

A.Harrenberg

Guten Morgen,

muss mich erst mal durch den Code der neuen Version arbeiten. Die Logs kann ich mir erst anschauen wenn ich Rudis Änderungen verstanden habe damit ich begreife was da im Hintergrund passiert / passieren sollte ,-)

Wenn Dein System soweit erst mal lebt ist es da ja auc h erst mal nicht mehr so dringend.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

Was mir auffaellt:
- im Durchschnitt alle 35 Sekunden ein burst von 5 Nachrichten. 5 Nachrichten erfordern mind. 12 Funktelegramme (5*2 wg. Ack + wakeup:noMoreInformation+Ack) -> relativ viel los
- die Geraete senden alle 5 Minuten battery,setpointTemp,ccs*,wakeup:notification
- manche der Nachrichten (wakeup:notification/battery) werden wiederholt, keine Ahnung, wieso.
- das zum Schluss erfolgte WU_NMI wird manchmal doppelt gesendet, in einer Sekunde Abstand. Ich vermute da noch einen Fehler im Programm, habe aber nach Code-Studium keine Idee, wo. Es scheint keine Auswirkungen zu haben.
- CANs gibts relativ wenige (5 Faelle bei ca 1300 versendeten Nachrichten) meist gehaeuft: 3,7,2,1,6. Wenn ich es richtig sehe, passiert es immer mitten im Funkverkehr, vmtl. ist das aktuelle Verhalten (bei CAN 0.1s schlafen, dann nochmal versuchen) falsch, da der Dongle mit dem Empfang/ACK der Nachrichten beschaeftigt ist. Vorschlag (eingecheckt): bei CAN wird nicht sofort gesendet, sondern so getan, als ob kein ACK gekommen waere, und erst nach eine Sekunde wieder gesendet. Ich hoffe, dass in dieser Zeit die Luft wieder rein ist. Koennte mit WU_NMI kollidieren, das muessen wir evtl. anpassen.

Falls ich was wesentliches uebersehen habe, bitte melden.

cnkru

Hallo Rudolf,

ich lasse seit 9:55 alle wakeup:notify's der Thermosate nur einmal durch (Entprellung, one_notify(...)),
die Errors halten sich in Grenzen (9:56,10:39,10:53,11:03,11:19,12:09 Uhr)
betrifft ggw. 4 Thermostate (0x0b, 0x19,0x20, 0x18)
LOG anbei ...

Ggf. kann ich die "Entprellung" rausnehmen - um das Verhalten ohne zu testen

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

cnkru

So Jungs ...

habe das "Entprellen" (one_notify) komplett rausgenommen ...
... und keine bedeutende Veränderung erreicht.
13:08 bis 14:07 6 Errors an 3 Thermostaten

nehme jetzt alle notify's komplett raus und überlasse das setzen des Befehles (set Thermostat setpointHeating xx) der Routine heizkurve(),
in dem sie dieses nach dem Aufruf (alle 15 Minuten) in den Stack schreibt (war die Ursprungs-Version der letzten Wochen).

So funkt kein notify mehr dazwischen, wenn die Geraete aufwachen und der Dongle seinen Stack abarbeitet.

Melde mich in einer Stunde wieder

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

A.Harrenberg

Hi cnkru,

Du musst Dir mal überlegen in welchen Intervallen Du die Temperatur verändern können möchtest und passend dazu dann das Intervall der WakeUp-Notification an den Thermostaten einstellen.

Dadurch das du unnötigerweise auch Updates machst wenn die Temperatur sich gar nicht ändert erzeugst Du eine Menge Funklast. Eine Version die a) auf den Notify triggert und b) nur dann eine Nachricht erzeugt wenn sich die Solltemperatur auch geändert hat wäre der optimale Zustand.

Die Abarbeitung des WU-Stacks und die Bearbeitung der Notify sollten sich in der neuen Version von Rudi eigentlich nicht gegenseitig stören.

Das in größeren Funknetzen noch einzelne CAN Messages auftreten ist wahrscheinlich gar nicht zu vermeiden und solange das nicht in Nachrichtenverlust oder extremen Ansteigen der Funklast ausartet auch nicht weiter schlimm.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

cnkru

#61
Hallo Andreas,

die Intervalle  waren früher bei 900 Sekunden, analog wie auch der Aufruf der Prozedure heizkurve.
Als das Fehlerbild bei mir auftauchte - ständig E5, vermutete ich erst einmal Verbindungsfehler oder Empfangsprobleme und nicht
Probleme in den FHEM Modulen.
Ich hatte daher Intervalle verkürzt - geht obendrein auf die Batterie-Lebensdauer - um den Fehler einzugrenzen.
Wenn wir hier durch sind stelle ich die Raster wieder auf eine Viertelstunde  - das reicht aus.

Wohl gemerkt eine Umstellung auf Handbetrieb oder Boost-Modus, würde im ungünstigsten Fall 15 Minuten später einsetzen.

Gruß
Carsten

Nachtrag:

So Jungs und nun mal was Erfreuliches ...

Ich habe seit 14:16 Uhr die notify's wieder entfernt. Also den Urzustand meiner fhem.cfg wie vor einer Woche eingespielt.
Bis jetzt kein Error oder Telegrammverlust
In diesem Sinne erst einmal - toi, toi, toi - melde mich morgen mit einem Status wieder

CU8L

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

Chlorex

Ahoi,

habe eine Woche lang versucht mit den Tipps, Ideen und Erklärungen von hier versucht den Danfoss Stellantrieb LC-13 ohne Fehler E5 zum laufen zubringen.
Nach 1-3 Stunden kam immer wieder Fehler E5, egal was ich versucht habe.
Habe ihn gestern zurück geschickt.

Gibt es alternativen?
StellaZ ?
oder Rademacher Heizkörperstellantrieb ¿

cnkru

Hallo Chlorex,

ich habe keine Erfahrungen mit dem StellaZ.
Unsere Wahl in der Familie fiel auf das Danfoss aufgrund des WAF.
Leider ist wie überall, nicht alles Gute beisammen.

Meine Thermostate laufen seit heute wieder stabil - Dank Rudis letzter 10_ZWave.pm-Version.

Dennoch ist einiges zu beachten bei der Inbetriebnahme.
1. Nach Include ist der Befaehl "set Thermostat wakeupInterval  600 1" abzusetzen
    Sonst wacht dieses nicht auf und nimmt  keinen Kontakt mit dem FHEM-Server auf.
2. Im Wiki steht der Hinweis mit einem "define AT-Thermostat at +*00:30:00 get Thermostat battery" alle 30 Minuten
    eine Abfrage an das Gerät zu senden, sonst droht hier auch E5.

Einfach gesagt - das Thermostat muss aufwachen und der Dongle muss diesem auch eine Abfrage senden, nur dann läuft es.

Leider klappt das nicht so gut mit dem Notify-wakeup (wie hier im Post beschrieben viele Telegrammverluste),
daher muss man sich für das Steuern der Thermostate (den Heizplan) etwas einfallen lassen.

Entweder in 99_MyUtils.pm eine Heiz-Subfunktion etablieren, die nach Zeitplan ein "set Device setpointHeating Wert" an das Thermostat schickt oder
in der fhem.cfg mit dem AT-Befaehl zu bestimmten Zeiten dieses erledigen lässt.

Insgesamt bin ich mit diesem Thermostat so lala zufrieden.
Einen Zeitplan im Thermostat (ccs) abzulegen - wie in der Doku beschrieben  - klappt sogut wie nie.
Dazu scheitert obendrein oft das setzen der Uhrzeit im Gerät (set device clock).
Das notify-Problem ist hier ausführlich geschildert worden und das Gerät gibt keine IST-Temperaturwerte aus.

Alles im Allem ein dummes Thermostat - am besten fremdgesteuert durch das FHEM System - dann klappts am besten.

Gruß
Carsten

P.S. Falls gewünscht schreib ich mal ne ausführliche Bedienanleitung für das Forum

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

Chlorex

Der
Zitat von: cnkru am 06 September 2015, 22:24:11
Dennoch ist einiges zu beachten bei der Inbetriebnahme.
1. Nach Include ist der Befaehl "set Thermostat wakeupInterval  600 1" abzusetzen
    Sonst wacht dieses nicht auf und nimmt  keinen Kontakt mit dem FHEM-Server auf.
2. Im Wiki steht der Hinweis mit einem "define AT-Thermostat at +*00:30:00 get Thermostat battery" alle 30 Minuten
    eine Abfrage an das Gerät zu senden, sonst droht hier auch E5.
Beides gemacht... läuft nen Weilchen und dann nach wenigen Stunden ist Ende...
Werde mir Alternativen überlegen.

Aber ein ToDo für künftige Interessenten wäre vielleicht eine Idee. :-)

cnkru

Hallo Andreas, Christian und Rudi,

erst einmal vielen Dank für eure Unterstützung, war ne klasse Zusammenarbeit  :D

Zum aktuellen Stand meines Systems nun folgender Sachstand:
Alle 9 Thermostate laufen stabil - gestern von 14:15 bis 24:00 Uhr mit 4 Errors im LOG - das läßt sich aushalten...

Heute waren es bis 19:00 Uhr in Summe 21 Errors in 14 Blöcken  (Abstände von 1 -3 Stunden) - damit kann ich erstmal leben.

Ich ziehe die jetzt die wakeupIntervalle der Thermostate auseinander, so daß der Funkverkehr nicht gleichzeit auftreten kann.

Hoffe damit auf weitere Besserung.
Melde mich morgen nochmals wieder und berichte erneut.
Danach schlage ich vor, den Forum-Eintrag zu schließen.

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

Carsten: was genau meinst du mit Errors?
Und welche Version von 10_ZWave.pm bzw. 00_ZWDongle.pm hast du verwendet?

cnkru

#67
Update habe ich durchgeführt
9204 und 9205 sind im Einsatz
Hier ein Beispiel vom Gerät Thermostat_WZ ==  0x20

2015.09.07 18:18:21.637 5: ZWAVE1 dispatch 011301
2015.09.07 18:18:21.655 4: ZWDongle_Read ZWAVE1: sending ACK, processing 001302000004
2015.09.07 18:18:21.656 5: SW: 06
2015.09.07 18:18:21.658 5: ZWAVE1 dispatch 001302000004
2015.09.07 18:18:21.658 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0004
2015.09.07 18:18:21.659 4: ZWAVE1 transmit OK for 02
2015.09.07 18:18:22.989 2: ZWave get Thermostat_Jule battery
2015.09.07 18:18:22.990 3: zAt7: Scheduled for sending after WAKEUP
2015.09.07 18:21:06.867 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040008063105042200c3
2015.09.07 18:21:06.868 5: SW: 06
2015.09.07 18:21:06.870 5: ZWAVE1 dispatch 00040008063105042200c3
2015.09.07 18:21:06.870 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:063105042200c3
2015.09.07 18:22:13.332 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004002003800346
2015.09.07 18:22:13.333 5: SW: 06
2015.09.07 18:22:13.334 5: ZWAVE1 dispatch 0004002003800346
2015.09.07 18:22:13.335 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:03800346
2015.09.07 18:22:13.395 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040020064303014209c4
2015.09.07 18:22:13.396 5: SW: 06
2015.09.07 18:22:13.397 5: ZWAVE1 dispatch 00040020064303014209c4
2015.09.07 18:22:13.398 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:064303014209c4
2015.09.07 18:22:13.464 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040020044608007f
2015.09.07 18:22:13.464 5: SW: 06
2015.09.07 18:22:13.466 5: ZWAVE1 dispatch 00040020044608007f
2015.09.07 18:22:13.467 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:044608007f
2015.09.07 18:22:13.770 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040020044608007f
2015.09.07 18:22:13.771 5: SW: 06
2015.09.07 18:22:13.772 5: ZWAVE1 dispatch 00040020044608007f
2015.09.07 18:22:13.773 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:044608007f
2015.09.07 18:22:13.830 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040020028407
2015.09.07 18:22:13.831 5: SW: 06
2015.09.07 18:22:13.833 5: ZWAVE1 dispatch 00040020028407
2015.09.07 18:22:13.833 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:028407
2015.09.07 18:22:13.835 5: ZWDongle_Write 00 13200280022520
2015.09.07 18:22:13.836 5: SW: 0109001320028002252040
2015.09.07 18:22:13.843 5: ACK received, removing 0109001320028002252040 from dongle sendstack
2015.09.07 18:22:13.844 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.09.07 18:22:13.844 5: SW: 06
2015.09.07 18:22:13.846 5: ZWAVE1 dispatch 011301
2015.09.07 18:22:14.160 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040020028407
2015.09.07 18:22:14.160 5: SW: 06
2015.09.07 18:22:14.162 5: ZWAVE1 dispatch 00040020028407
2015.09.07 18:22:14.163 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:028407
2015.09.07 18:22:14.164 5: ZWDongle_Write 00 13200543010101192520
2015.09.07 18:22:14.165 5: SW: 010c00132005430101011925209b
2015.09.07 18:22:14.172 5: ACK received, removing 010c00132005430101011925209b from dongle sendstack
2015.09.07 18:22:14.173 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011300
2015.09.07 18:22:14.174 5: SW: 06
2015.09.07 18:22:14.175 5: ZWAVE1 dispatch 011300
2015.09.07 18:22:14.176 2: ERROR: cannot SEND_DATA to Thermostat_WZ: 00
2015.09.07 18:22:14.558 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040020028407
2015.09.07 18:22:14.559 5: SW: 06
2015.09.07 18:22:14.560 5: ZWAVE1 dispatch 00040020028407
2015.09.07 18:22:14.561 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:028407
2015.09.07 18:22:14.943 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00041020028407
2015.09.07 18:22:14.944 5: SW: 06
2015.09.07 18:22:14.946 5: ZWAVE1 dispatch 00041020028407
2015.09.07 18:22:14.946 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:028407
2015.09.07 18:22:15.036 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00041020028407
2015.09.07 18:22:15.036 5: SW: 06
2015.09.07 18:22:15.038 5: ZWAVE1 dispatch 00041020028407
2015.09.07 18:22:15.039 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:028407
2015.09.07 18:22:15.173 5: ZWDongle_Write 00 13200284082520
2015.09.07 18:22:15.174 5: SW: 010900132002840825204e
2015.09.07 18:22:15.225 5: ACK received, removing 010900132002840825204e from dongle sendstack
2015.09.07 18:22:15.227 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011300
2015.09.07 18:22:15.227 5: SW: 06
2015.09.07 18:22:15.229 5: ZWAVE1 dispatch 011300
2015.09.07 18:22:15.230 2: ERROR: cannot SEND_DATA to Thermostat_WZ: 00
2015.09.07 18:22:16.193 5: ZWDongle_Write 00 13200284082520
2015.09.07 18:22:16.194 5: SW: 010900132002840825204e
2015.09.07 18:22:16.197 5: ACK received, removing 010900132002840825204e from dongle sendstack
2015.09.07 18:22:16.201 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.09.07 18:22:16.201 5: SW: 06
2015.09.07 18:22:16.203 5: ZWAVE1 dispatch 011301
2015.09.07 18:22:17.278 5: ZWDongle_Write 00 13200284082520
2015.09.07 18:22:17.279 5: SW: 010900132002840825204e
2015.09.07 18:22:17.283 5: ACK received, removing 010900132002840825204e from dongle sendstack
2015.09.07 18:22:17.283 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011300
2015.09.07 18:22:17.284 5: SW: 06
2015.09.07 18:22:17.285 5: ZWAVE1 dispatch 011300
2015.09.07 18:22:17.286 2: ERROR: cannot SEND_DATA to Thermostat_WZ: 00
2015.09.07 18:22:18.298 5: ZWDongle_Write 00 13200284082520
2015.09.07 18:22:18.300 5: SW: 010900132002840825204e
2015.09.07 18:22:18.303 5: ACK received, removing 010900132002840825204e from dongle sendstack
2015.09.07 18:22:18.304 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011300
2015.09.07 18:22:18.304 5: SW: 06
2015.09.07 18:22:18.306 5: ZWAVE1 dispatch 011300
2015.09.07 18:22:18.307 2: ERROR: cannot SEND_DATA to Thermostat_WZ: 00
2015.09.07 18:22:19.319 5: ZWDongle_Write 00 13200284082520
2015.09.07 18:22:19.320 5: SW: 010900132002840825204e
2015.09.07 18:22:19.324 5: ACK received, removing 010900132002840825204e from dongle sendstack
2015.09.07 18:22:19.329 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.09.07 18:22:19.329 5: SW: 06
2015.09.07 18:22:19.331 5: ZWAVE1 dispatch 011301
2015.09.07 18:22:21.058 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0013200100ad
2015.09.07 18:22:21.059 5: SW: 06
2015.09.07 18:22:21.061 5: ZWAVE1 dispatch 0013200100ad
2015.09.07 18:22:21.061 4: ZWAVE1 CMD:ZW_SEND_DATA ID:01 ARG:00ad
2015.09.07 18:22:21.062 2: ZWAVE1 transmit NO_ACK for 20
2015.09.07 18:22:21.069 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0013200100ad
2015.09.07 18:22:21.069 5: SW: 06
2015.09.07 18:22:21.071 5: ZWAVE1 dispatch 0013200100ad
2015.09.07 18:22:21.072 4: ZWAVE1 CMD:ZW_SEND_DATA ID:01 ARG:00ad
2015.09.07 18:22:21.072 2: ZWAVE1 transmit NO_ACK for 20
2015.09.07 18:22:21.127 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0013200100b4
2015.09.07 18:22:21.128 5: SW: 06
2015.09.07 18:22:21.129 5: ZWAVE1 dispatch 0013200100b4
2015.09.07 18:22:21.130 4: ZWAVE1 CMD:ZW_SEND_DATA ID:01 ARG:00b4
2015.09.07 18:22:21.131 2: ZWAVE1 transmit NO_ACK for 20


Wenn gewünscht ein etwas längerer LOG

CU

Upps - sehe gerade 9208 und 9210 als neuste Versionen - update nachträglich durchgeführt.
Sorry ....
RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

rudolfkoenig

An diesem ERROR wird die neue Version nichts aendern.

Die Meldung verstehe ich so: der Dongle meint, er kann diese Nachricht nicht wegschicken.

Bin unsicher, was man hier tun sollte, z.Zt. wird die "nicht versendbare" Nachricht vergessen, und weitergemacht. Alternativ-Vorschlaege sind willkommen. Ich gehe davon aus, dass der Dongle schon selbst retransmits versucht, es kann auch ein grundsaetzliches Problem mit der Nachricht sein.

cnkru

Danke für die Info Rudi und mach Dir keinen Stress ;)

ich lass das Ganze mal in Ruhe laufen und versuche die Errors zu minimieren.

Habe die WakeupIntervalle auseinander gezogen als "set wakeupInterval 900 1" , 910,  920 ... usw.
damit der Doungle in Ruhe den Stack für das jeweilige aufgewachte Gerät abarbeiten kann.
So funkt keiner weiterer Thermostat dazwischen.

Der Heizplan wird morgen dahingehend angepasst, indem nur ein "setpointHeating" dann durchgeführt wird,
wenn wirklich eine neue Temperatur eingestellt werden soll (vorher alle 15 Minuten setpointHeating egal welcher TemperaturWert )

Ich werde berichten ....

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

krikan

ZitatBin unsicher, was man hier tun sollte, z.Zt. wird die "nicht versendbare" Nachricht vergessen, und weitergemacht. Alternativ-Vorschlaege sind willkommen. Ich gehe davon aus, dass der Dongle schon selbst retransmits versucht, es kann auch ein grundsaetzliches Problem mit der Nachricht sein.
Bei den 0013xx01-Fehlern bin ich für Beibehaltung des "Vergessens": Das Gateway hat doch schon mehrfach probiert ein ACK zu bekommen: 3x Standardrouten und dann noch ExplorerFrames. Mehr kann man nicht machen und sollte das Problem irgendwo anders suchen. Genauso macht das ozw nach Analyse von mehreren Millionen Logzeilen über Log-Analyzer auch. Vorher hatten die auch 3x Wiederholungen, so wie Gero es vorgeschlagen hatte.
Frage mich hier auch, ob der 0013xx01-Fehler eine Nachricht betrifft oder für verschiedene Nachrichten kommt. Das kann man wegen einheitlicher CallbackId nicht erkennen ;).

Bei 011300-Fehlern sollten wir überlegen, ob nicht wiederholt wird (oder wird das schon? Meine nicht...). Wenn ich das richtig verstehe, bedeutet das, dass die Controller-Warteschlange übergelaufen ist und die Nachricht deshalb nicht rausging. Keine Ahnung, was die anderen machen.

cnkru

#71
So nun wieder ein Lebenszeichen von meiner Seite - Jungs  :D

Ich habe, wie weiter oben angekündigt:

1. die wakeupIntervalle der Themostate verlängert und auseinander gezogen
2. die Heizkurve so angepasst, dass die Temperatur je Thermostat nur einmal je Stunde mit setpointHeating geändert wird, wenn der Heizplan es vorsieht.

Ingesamt waren heute nur 2 Fehler bis 17:30 Uhr im LOG aufgelaufen (LOG verbose 3):

2015.09.09 00:05:00 2: ZWave set FIB_WALL_PLUG_TV off
2015.09.09 00:05:00 2: ERROR: FIB_WALL_PLUG_TV: cleaning commands without ack after 10s


2015.09.09 06:07:50 2: ZWave get Thermostat_WZ battery
2015.09.09 06:07:50 3: zAt5: Scheduled for sending after WAKEUP >>> WZ
2015.09.09 06:08:29 2: ERROR: cannot SEND_DATA to Thermostat_WZ: 00
2015.09.09 06:08:31 2: ZWAVE1 transmit NO_ACK for 20


Warum die Fibaro Steckdose sich mit Fehler meldet ist mir unklar, aber auch nicht so dramatisch ;)

Alles im Allem ist das Verhalten meines Systems deutlich besser als in der Vorwoche

Daher nochmals Danke an Euch.

Lessons learned:
Schalte nur die Thermostate, wenn wirklich Temperaturänderungen (Heizplan) erwünscht
- set Thermostat wakeupIntervall 900 1 und
- define zAtThermostat at +*00:30:00 get Thermostat battery
sind außreichend

Gruß
Carsten


In den letzten 5 Wochen inklusive aktueller Heizperiode läuft alle stabil.

Daher nochmals
Danke

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

buzzdeebuzz

#72
Hallo, ich habe mir auch ein Danfoss LC-13 und ein Z-Wave ZME_UZB1 Me USB Stick gekauft. Ich habe das Thermostat in das Z-Wave Netzwerk inkludiert. Am Anfang sehe ich bei den "Readings" zu dem Thermostat, noch:

Zitat

state ???
transmit OK


Nach einer Weile sehe ich dann:

Zitat

state TRANSMIT_NO_ACK
transmit NO_ACK


Auf dem Thermostat erscheint auch kein Symbol für die Funk- / Netzwerkverbindung. Ich habe nun auch mehrmals die Fehlermeldung "E5" im Display des Thermostats gesehen. Ich habe dann die Batterien entfernt und wieder eingesetzt. Es scheint als ob FHEM nicht mehr mit dem Thermostat "sprechen" kann. Alle "get" Befehle, die ich an das Thermostat sende, scheinen für mich ins Nirvana zu laufen, selbst wenn ich das Thermostat mit Druck auf den mittleren Knopf aufwecke und direkt danach das "get"-Kommando absende. Nach dem Inkludieren, habe ich auch die folgenden 2 Einstellungen in FHEM / auf dem Thermostat vorgenommen.:


define Atdanfoss at +*00:30 get ZWave_THERMOSTAT_7 battery
set ZWave_THERMOSTAT_7 wakeupIntervall 300 7


Habe ich etwas falsch eingestellt bzw. was muss ich noch tun, damit das Thermostat mit FHEM funktioniert? Ist der Fehler "E5" auf einen Fehler im FHEM Z-Wave Modul zurückzuführen? Wie kann ich unterstützen, um das Problem zu identifizieren?

Hier noch der Log, den ich in FHEM zu dem Thermostat sehen kann.:

Zitat

2015-10-29_15:29:09 ZWave_THERMOSTAT_7 modelConfig: danfoss/z.xml
2015-10-29_15:29:09 ZWave_THERMOSTAT_7 modelId: 0002-0005-0004
2015-10-29_15:29:09 ZWave_THERMOSTAT_7 model: Danfoss Z Thermostat 014G0013
2015-10-29_15:30:38 ZWave_THERMOSTAT_7 CMD: ZW_APPLICATION_UPDATE
2015-10-29_16:19:45 ZWave_THERMOSTAT_7 CMD: ZW_APPLICATION_UPDATE
2015-10-29_16:19:45 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_16:19:50 ZWave_THERMOSTAT_7 TRANSMIT_NO_ACK
2015-10-29_16:19:50 ZWave_THERMOSTAT_7 transmit: NO_ACK
2015-10-29_16:20:25 ZWave_THERMOSTAT_7 CMD: ZW_APPLICATION_UPDATE
2015-10-29_16:20:26 ZWave_THERMOSTAT_7 wakeupReport: interval 60 target 7
2015-10-29_16:20:26 ZWave_THERMOSTAT_7 wakeupReport: interval 60 target 7
2015-10-29_16:35:55 ZWave_THERMOSTAT_7 CMD: ZW_APPLICATION_UPDATE
2015-10-29_16:35:55 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:07 ZWave_THERMOSTAT_7 CMD: ZW_APPLICATION_UPDATE
2015-10-29_21:19:07 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:08 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:08 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:08 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:09 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:09 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:09 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:10 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:10 ZWave_THERMOSTAT_7 battery: 81 %
2015-10-29_21:19:16 ZWave_THERMOSTAT_7 TRANSMIT_NO_ACK
2015-10-29_21:19:16 ZWave_THERMOSTAT_7 transmit: NO_ACK


Außerdem, wenn ich:


get ZWDongle_1 isFailedNode 7


eingebe, dann bekomme ich:


ZWDongle_1 isFailedNode_7 => yes


zurück.

buzzdeebuzz

Oh, ein Fehler ist mir gerade selbst aufgefallen. Das Wake-Up Kommando siehe oben:


set ZWave_THERMOSTAT_7 wakeupIntervall 300 7


ist natürlich falsch. Es lautet korrekt:


set ZWave_THERMOSTAT_7 wakeupIntervall 300 1


weil das ZWave_THERMOSTAT_7 seine Wake-Up Notification an den Z-Wave Controller senden soll und der Controller ist in der Regel Node 1.

Kein Wunder, dass die Nachrichten ins Nirvana gehen. Mal sehen, wie es nun aussieht.

krikan

Zitat von: buzzdeebuzz am 29 Oktober 2015, 23:47:32
Außerdem, wenn ich:

get ZWDongle_1 isFailedNode 7

eingebe, dann bekomme ich:

ZWDongle_1 isFailedNode_7 => yes

zurück.
Das ist normal, da Du den Node mit Deinen Befehlen manuell auf die failedNodeList verschoben hast (state TRANSMIT_NO_ACK transmit NO_ACK). Ist aber unerheblich, da bei der nächsten korrekten Kommunikation zw. Controller und Node der Controller den Node wieder von der failedNodeList herunternimmt. Die Abfrage isFailedNode sollte dann "no" zurückliefern.

buzzdeebuzz

Zitat von: krikan am 30 Oktober 2015, 07:26:41
Das ist normal, da Du den Node mit Deinen Befehlen manuell auf die failedNodeList verschoben hast (state TRANSMIT_NO_ACK transmit NO_ACK).
Du meinst mit den "get"-Anfragen? Der Controller hat keine Antwort bekommen, deswegen laden die auf der "failed"-Liste.

Zitat von: krikan am 30 Oktober 2015, 07:26:41
Ist aber unerheblich, da bei der nächsten korrekten Kommunikation zw. Controller und Node der Controller den Node wieder von der failedNodeList herunternimmt. Die Abfrage isFailedNode sollte dann "no" zurückliefern.
Achso, gut zu wissen.

m8ichael

Hallo zusammen!

Kurze Frage: Wie bekommt ihr hier den set-Clock-Befehl erfolgreich ausgeführt? Irgendwie schaffe ich es nicht, get clock bringt stets "none" + die Laufzeit...  >:(

Viele Grüße

Michael

cnkru

Hallo Michael

Ich habe mich am Anfang mit dem setzen der Clock und Einspeichern des Heizungsplanes direkt im Thermostat herumgeschlagen.
Hatte dabei wenig Erfolg und am Ende die Thermostate in den Ursprungszustand versetzt.

Das Setzen von clock klappt 10mal nicht und dann zufällig 1mal. Also sehr unzuverlässig.
Siehe auch: http://forum.fhem.de/index.php?topic=32145.30

Insofern steuere ich jetzt die Thermostate von außen via perl-Scripte.

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

m8ichael

Hallo Carsten,

vielen Dank für die Rückmeldung.

Wenn die clock wenigstens beim 10. Versuch gesetzt werden würde...ich habe bisher noch keinen Erfolg verzeichnen können (habe insgesamt 3 Geräte). Der Befehl wird jeweils ohne Fehler angenommen, das war's dann aber auch. Beim anschließenden "Get" bekomme ich stets nur die Zeit seit Inbetriebnahme als Rückmeldung.

Ja, per Script wäre natürlich eine Alternative, wobei für mich die wohl integrierte Heizkurve sehr interessant wäre (wann muss eingeschaltet werden, damit zum Zeitpunkt x die Temperatur erreicht wird?). Und je nach gesetztem Wakeup hat man dann schon gewisse "Unschärfen" hinsichtlich des Heizzeitpunkts (entweder im Zweifel 15 Minuten warten, bis ein Befehl ausgeführt wird oder alle paar Wochen Batterien tauschen) - gerade auch, wenn "spontan" geheizt werden soll. Da kann man dann nicht der Partnerin erklären, dass die Heizung "spätestens in 15 Minuten" startet. Klar, man könnte die Temperatur direkt an den Stellantrieben einstellen, dies stellte dann aber das ganze Konzept in Frage...

Ich bin derzeit ernsthaft am Überlegen, ob ich die Dinger - die für mich zurzeit nur eine "Frickellösung" darstellen (relativ starker Stromverbrauch, keine ordentliche Dokumentation der z-wave-Funktionen) - nicht wieder umtausche. Da erscheinen mir dann meine bisherigen FS20-Stellantriebe - trotz älterer Technik - in der Praxis besser.

Viele Grüße
Michael

cnkru

Hallo Michael

ja mit dem WAF ist nicht zu Spaßen. Habe den Floorplan genutzt und die Ventile/Heizkörper per Auswahllisten platziert
Dazu die Betriebsart auswählbar gestaltet (Auto, Hand, Boost, ...) ... Siehe Heizung.png und Wohnung.png

Am Ende hat der Floorplan die Situation gerettet ...

Gruß
Carsten

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