(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

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