Abarbeitung des WakeUp-Sendstacks wird in Einzelfällen unterbrochen

[krikan]

AMS6 sich nach 0.1 Sekunden Schlafen legt

0.1 ist nicht notwendig.
WNMI_delay von 0.2 reichte sicher -> keine NO_ACK
WNMI_delay von 0.3 führte sporadisch zu NO_ACK
Möchte nicht grundsätzlich 0.1 einführen. Sowohl ozw als auch z-way führen Telegrammlaufzeitmessungen durch. Ich habe keine Ahnung, ob sich dadurch unter Umständen die 0.1 Sek. erhöhen. Hab zwar bei ozw und zway keine höheren Werte gesehen, aber ausschließen kann ich es nicht.

Nach nochmaligem Überdenken:
Keine Abschaffung von "noWakeupForApplicationUpdate". Ich kann bei manuellem Wakeup des AMS6 nicht ausschließen das ZW_APPLICATION_UPDATE und folgende empfangene Nachrichten vom Sensor mehr als 0.2 Sekunden brauchen und dann die WNMI verschickt, obwohl Sensor bereits schläft. -> NO_ACK wäre zwangsläufige Folge. Habe ich gestern zwar nicht festgestellt, würde aber gerne noch mal probieren. Oder kann ich das bereits anhand des Programmablaufs ausschließen (mMn nicht) ?

Fest steht aber für mich noWakeupForApplicationUpdate ist für den normalen Betrieb des AMS6 nicht notwendig.
WNMI_delay müsste entscheidend sein.

Das irritierende für mich ist auch, dass der AMS6 nach einem Empfang irgendeiner Nachricht nach wakeup notification den Wachzustand laut Log deutlich verlängert.

[rudolfkoenig]

Sowohl ozw als auch z-way führen Telegrammlaufzeitmessungen durch.

Wir ab sofort auch , nennt sich timeToAck und ist ein Internal (nicht Reading/kein Event).
ZME zu 1m entfernten ASS6: 25ms
Goodway zu 8m entfernten AN158: 19ms
Goodway zu verrueckt (ueber 2 Ecken) angebundenen Sensor: 57ms.

[krikan]

Wir ab sofort auch , nennt sich timeToAck und ist ein Internal (nicht Reading/kein Event).

Na, da hast Du Dir wieder etwas angetan  ; mich verwundern (besser verwirren) die Werte:

Bei den netzgebundenen Geräten habe ich ähnliche Werte bei timeToAck; höchster festgestellter Wert war bis jetzt 50ms.

Aber: die Wakeup-Geräte haben fast immer Werte um 250-300ms. Das habe ich sowohl am Raspi mit Vision zu 3 verschiedenen getesteten Wakeup-Geräten als auch unter Win mit ZME zu einem getesteten WakeUp-Gerät. Sieht so als wäre es immer so.

Die Hauptzeit wird immer zwischen den Log-Eintragen "SW.." und "ACK reveived.." verbraucht. Interessanterweise bei allen SW außer bei SW für WNMI. Muss das so sein? Bei den netzbetriebenen Geräten gibt es diese "Pausen" generell gar nicht.

Erkennbar im nachfolgenden Log:

Code Auswählen Erweitern

2016.03.22 21:01:32.086 5: ZWDongle_0 dispatch 0004041f028407
2016.03.22 21:01:32.089 4: CMD:APPLICATION_COMMAND_HANDLER ID:1f ARG:028407 CB:04
2016.03.22 21:01:32.097 5: ZWDongle_Write 00131f0280022583 (e345c452)
2016.03.22 21:01:32.101 5: SW: 010900131f0280022583dc
2016.03.22 21:01:32.384 5: ACK received, WaitForAck=>2 for 010900131f0280022583dc
2016.03.22 21:01:32.387 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.03.22 21:01:32.389 5: SW: 06
2016.03.22 21:01:32.394 5: ZWDongle_0 dispatch 011301
2016.03.22 21:01:32.410 4: ZWDongle_Read ZWDongle_0: rcvd 00138300 (request ZW_SEND_DATA), sending ACK
2016.03.22 21:01:32.412 5: SW: 06
2016.03.22 21:01:32.416 5: device ack reveived, removing 010900131f0280022583dc from dongle sendstack
2016.03.22 21:01:32.419 5: ZWDongle_0 dispatch 00138300
2016.03.22 21:01:32.422 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:83
2016.03.22 21:01:32.424 4: ZWDongle_0 transmit OK for CB 83, target ZWave_GARAGE_DOOR_31
2016.03.22 21:01:32.442 4: ZWDongle_Read ZWDongle_0: rcvd 0004001f03800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.03.22 21:01:32.444 5: SW: 06
2016.03.22 21:01:32.449 5: ZWDongle_0 dispatch 0004001f03800364
2016.03.22 21:01:32.452 4: CMD:APPLICATION_COMMAND_HANDLER ID:1f ARG:03800364 CB:00
2016.03.22 21:01:34.160 5: ZWDongle_Write 00131f0284082584 (e345c452)
2016.03.22 21:01:34.163 5: SW: 010900131f0284082584d5
2016.03.22 21:01:34.174 5: ACK received, WaitForAck=>2 for 010900131f0284082584d5
2016.03.22 21:01:34.177 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.03.22 21:01:34.179 5: SW: 06
2016.03.22 21:01:34.184 5: ZWDongle_0 dispatch 011301
2016.03.22 21:01:34.197 4: ZWDongle_Read ZWDongle_0: rcvd 00138400 (request ZW_SEND_DATA), sending ACK
2016.03.22 21:01:34.199 5: SW: 06
2016.03.22 21:01:34.202 5: device ack reveived, removing 010900131f0284082584d5 from dongle sendstack
2016.03.22 21:01:34.206 5: ZWDongle_0 dispatch 00138400
2016.03.22 21:01:34.209 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:84
2016.03.22 21:01:34.211 4: ZWDongle_0 transmit OK for CB 84, target ZWave_GARAGE_DOOR_31

[krikan]

Interessanterweise bei allen SW außer bei SW für WNMI.

Info vergessen:
Wenn ich einen Befehl per notify auf wakeup notification in den Wakeup-Sendstack lege, gibt es die "Pause" bei SW dafür auch nicht. Scheint nur für die bereits im Wakeup-Sendstack wartenden Nachrichten zu gelten.

[tomspatz]

Ich würde gerne hier noch mein Senf dazugeben.

Code Auswählen Erweitern

transmit NO_ACK
beobachte ich schon länger in Verbindung mit meinen Danfoss LC13-014G0013.
Da allerdings die Routen stabil sind und im Moment alles Top läuft kümmere ich mich nicht drum.
Kristian du hast geschrieben:

Das Attribut "WNMI_delay" ist mMn eine Lösung zur Vermeidung des NO_ACK des Sensors. Mein Sensor schläft rund 0.2 Sek. nach erhalt der automatischen wakeup notification wieder ein, wenn er bis dahin keine Nachricht vom Controller erhalten hat. Die WNMI-Nachricht, die erst 2(?) Sekunden nach der wakeup notification von FHEM bei leerem Wakeup-Sendstack verschickt wird, endet daher immer mit NO_ACK. Wird von FHEM direkt nach der wakeup notification eine Nachricht (bspw. get <device> battery per notify) an den Sensor verschickt, ist er länger wach. Auch ein WMNI-Nachricht nach ca. 1 Sekunde wird vom Sensor noch mit einem ACK bestätigt. Also sollten die NO_ACK verschwinden, wenn man WMNI_DELAY auf 0.2 setzt oder eine andere Nachricht per notify/DOIF,.. bei einer wakeup notification verschickt. Laut einem Z-Way-Log, das ich habe, schickt Z-way Wakeup-Geräte bereits 0.1 Sekunden nach wakeup notification in den Schlaf zurück, wenn keine Nachricht im Wakeup-Sendstack liegt. (leider habe ich auf die Schnelle nur ein Log mit Wakeup-Gerät von Z-Way gefunden)

Ich interpretiere das so das bei mehreren Befehlen nacheinander es keinen NO-ACK gibt.

Könnte man dann nicht z.B.

Code Auswählen Erweitern

define Atdanfoss at +*00:30 get <name> battery,setpointTemp

Zwei Anfragen losschicken.
Zumal in der Bedienungsanleitung des LC13 steht:

Obwohl living connect Z auf einzelne Befehle reagiert, müssen immer mehrfache Befehle verwendet werden, um die zweijährige Batterielebensdauer zu gewährleisten

[krikan]

Ich würde gerne hier noch mein Senf dazugeben.

Gerne doch.  Nur die Warnung, dass hier im Thread mittlerweile Ausnahmesitutationen und Ausnahme-Geräte, aber Danfoss gehört mMn auch dazu, betrachtet werden.

Ich interpretiere das so das bei mehreren Befehlen nacheinander es keinen NO-ACK gibt.

Bin mir nicht sicher, ob wir vom Gleichen schreiben.
Versuche meine zitierte Aussage einmal anders zu formulieren:
Wenn der MS6 die wakeup notification schickt und nicht innerhalb kürzester Zeit (0,1-0,4 Sek) eine Nachricht von FHEM bekommt, schläft er automatisch wieder ein. Da FHEM bei leerem Wakeup-Sendstack nach 2 Sek. als erste Nachricht die WNMI-Nachricht verschickt, endet diese beim bereits wieder schlafenden MS6 zwangsläufig im NO_ACK. Um dies zu verhindern, kann man mit dem Attribut  "WNMI_delay" den Zeitraum von 2 Sek. verkürzen.
Sendet FHEM nach der wakeup notification direkt eine Nachricht an den MS6 (bspw. get battery), schläft dieser danach nicht nach 0,1-0,4 Sekunden wieder ein, sondern bleibt länger wach. Wie lange genau habe ich nicht ermittelt, sondern nur bis 1 Sekunde Pause zwischen erste und nächster Nachricht getestet. Dies lief sauber ohne NO_ACK durch.

Bei Danfoss könnte das gleiche Problem des schnellem Einschlafens nach wakeup notification wie beim MS6 vorliegen. Das NO_ACK spricht in Verbindung mit wartender Nachricht im Wakeup-Sendstack dafür:

Da allerdings die Routen stabil sind und im Moment alles Top läuft kümmere ich mich nicht drum.

NO_ACK könnte nur auf WNMI-Nachricht kommen.
Das könnte man testen, indem man WNMI_delay mit niedrigen Werten setzt und probiert, ob die NO_ACK dann verschwinden und eventuell dann sogar die "Danfass-at"-Lösung überflüssig wird. Das hängt aber mVn nicht mit mehreren Befehlen nacheinander zusammen und NO_ACK kann es auch bei mehreren Befehlen hintereinander geben. Den Auszug aus der Bedienungsanleitung begreife ich nicht.

Im Allgemeinen habe ich aufgrund meiner Feststellungen überlegt, ob wir nicht das WNMI-Delay bei allen Wakeup-Geräten im Standard deutlich heruntersetzen. Das ist bei den bisher selten gemeldeten Problemen mit dem 2 Sek. Standard natürlich gefährlich.

[ToKa]

Hallo zusammen,

hat sich zum ursprünglichen Topic noch etwas ergeben? Seit ein paar Tagen beobachte ich bei meinen EUROtronic COMET Z Ventilen auf dem Sendstack nämlich das gleiche Problem. Es häufen sich die nicht verarbeiteten get's aus dem wakeup-Notify und die set Befehle für die Temperatur an.

Irgendwann endet das dann damit, dass dann gar keine Kommunikation mehr zwischen fhem und den Ventilen stattfindet. Bislang habe ich mir damit beholfen, dass ich dann den Raspi neugestartet habe bzw. auch die Batterien der Ventile rausgenommen habe. Das ist aber kein befriedigender Dauerzustand.

Welche Möglichkeiten bieten sich denn noch an? WNMI_delay, aber mit welchem Wert? sleep Befehl im notify zwischen den einzelnen gets? Ich bin ratlos...

Gerne kann ich auch mal ein ausführliches LOG protokollieren lassen und zur Verfügung stellen.

Beste Grüße
Torsten

[A.Harrenberg]

Hi,

ich habe bisher keine prinzipiellen Probleme mit dem WakeUp-Stack festgestellt. Wenn das Problem bei Dir durch Neustarten des Raspi oder "Reset" der Ventile behoben wird, würde ich ja eher auf das Ventil oder den Raspi tippen...

WNMI_delay hilft in dem Zusammenhang nicht, das ist nur dazu da die "schlaf wieder ein, ich habe keine Nachrichten für Dich" Nachricht FRÜHER an das Gerät zu verschicken, falls dieses schneller einschläft als die 2 sekunden Default. In dem Fall würde dieser "schlaf ein" Befehl nicht beantwortet werden da das Gerät ja bereits schläft und es würde ein NO_ACK gemeldet werden.

Falls da Befehle auf dem Stack liegenbleiben sendet entweder das Gerät keine WakeUP-Notification mehr oder es klemmt irgendwo anders in der Kommunikation.

Hier würde ein Log mit verbose 5 und vor allem dem globalen attribut mseclog = 1 helfen das zu verstehen. Ich gehe aber davon aus das es sich hier um ein Problem mit diesem Thermostaten handelt, die Firmware dieser Dinger ist anscheinend nicht wirklich gut programmiert...

Gruß,
Andreas.

[ToKa]

Hallo Andreas,

danke für Deine Antwort, dann muss ich mir wegen WNMI_delay keine Gedanken machen. Es wundert mich nur, da ich mit den Ventilen in den ersten Tagen keine Probleme hatte. Es gab aber auf dem Raspi in den letzten Tagen viele Updates, vielleicht hat es ja damit zu tun.

Habe jetzt mal das log mit verbose 5 und mseclog = 1 zugeschaltet. Das Ventil sendet schon ein wakeup und fhem startet dann auch das notify. Aber es bleiben dennoch sent und get Befehle auf dem stack "hängen". Vielleicht wirst Du oder die anderen Experten ja aus den log / dem list schlau.

Beste Grüße
Torsten

Log:

Code Auswählen Erweitern

2016.10.16 21:12:15.941 5: Triggering E3.hk.HR.Bodenheizung (1 changes)
2016.10.16 21:12:15.942 5: Starting notify loop for E3.hk.HR.Bodenheizung, first event wakeup: notification
2016.10.16 21:12:15.959 5: Triggering E3.hk.HR.wakeup.nfy
2016.10.16 21:12:15.960 4: E3.hk.HR.wakeup.nfy exec get E3.hk.HR.Bodenheizung smStatus; get E3.hk.HR.Bodenheizung swmStatus; get E3.hk.HR.Bodenheizung setpoint 1; get E3.hk.HR.Bodenheizung thermostatMode; get E3.hk.HR.Bodenheizung battery
2016.10.16 21:12:15.961 5: Cmd: >get E3.hk.HR.Bodenheizung smStatus<
2016.10.16 21:12:15.964 3: ZWave get E3.hk.HR.Bodenheizung smStatus
2016.10.16 21:12:15.966 5: Cmd: >get E3.hk.HR.Bodenheizung swmStatus<
2016.10.16 21:12:15.968 3: ZWave get E3.hk.HR.Bodenheizung swmStatus
2016.10.16 21:12:15.969 5: Cmd: >get E3.hk.HR.Bodenheizung setpoint 1<
2016.10.16 21:12:15.973 3: ZWave get E3.hk.HR.Bodenheizung setpoint 1
2016.10.16 21:12:15.974 5: Cmd: >get E3.hk.HR.Bodenheizung thermostatMode<
2016.10.16 21:12:15.977 3: ZWave get E3.hk.HR.Bodenheizung thermostatMode
2016.10.16 21:12:15.978 5: Cmd: >get E3.hk.HR.Bodenheizung battery<
2016.10.16 21:12:15.981 3: ZWave get E3.hk.HR.Bodenheizung battery
2016.10.16 21:12:15.986 5: Heizungssteuerung: not on any display, ignoring notify
2016.10.16 21:12:16.100 5: Triggering E3.hk.HR.Bodenheizung (1 changes)
2016.10.16 21:12:16.101 5: Starting notify loop for E3.hk.HR.Bodenheizung, first event thermostatMode: heating
2016.10.16 21:12:16.104 5: Heizungssteuerung: not on any display, ignoring notify
2016.10.16 21:12:16.275 4: FRITZBOX StarGateAP2: Readout_Start.674 Skip fork process FRITZBOX_API_Check_Run
2016.10.16 21:12:26.285 4: FRITZBOX StarGateAP2: Readout_Start.674 Skip fork process FRITZBOX_API_Check_Run
2016.10.16 21:12:36.297 4: FRITZBOX StarGateAP2: Readout_Start.674 Skip fork process FRITZBOX_API_Check_Run
2016.10.16 21:12:40.006 4: Closing inactive connection WEB_192.168.6.11_49398
2016.10.16 21:12:40.007 4: Closing inactive connection WEB_192.168.6.11_49368


List des Ventils:

Code Auswählen Erweitern

Internals:
   DEF        d14c12e6 14
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     17
   NAME       E3.hk.HR.Bodenheizung
   NR         105
   STATE      Status: <strong>heating</strong> / Ventil: <strong>42 %</strong></br>Temperatur: <strong>23.0 °C</strong></br>Solltemperatur: <strong> 19.5 °C</strong></br>Batterie: <strong>100 %</strong>
   TYPE       ZWave
   ZWAVE1_MSGCNT 17
   ZWAVE1_RAWMSG 0004000e064303012200c3
   ZWAVE1_TIME 2016-10-16 21:09:49
   ZWaveSubDevice no
   homeId     d14c12e6
   isWakeUp   1
   lastMsgSent 1476644978.02325
   nodeIdHex  0e
   Readings:
     2016-10-16 20:19:13   ActValve        42
     2016-10-16 20:49:29   IstTemp         23.0
     2016-10-16 14:03:31   SEND_DATA       failed:00
     2016-10-16 21:09:49   SollTemp        19.5
     2016-10-15 20:42:45   UNPARSED        UNKNOWN_C4 02c407
     2016-10-16 20:35:26   WunschTemp      00
     2016-10-16 20:19:14   battery         100 %
     2016-09-03 18:45:19   cmdGet          wakeupInterval
     2016-10-07 22:33:26   model           EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
     2016-10-07 22:33:26   modelConfig     eurotronic/eur_cometz.xml
     2016-10-07 22:33:26   modelId         0148-0002-0001
     2016-07-10 19:00:27   neighborList    GH.gt.ZS.Gartenbeleuchtung E1.wz.ZS.Tischleuchte E3.hk.ZS.Subwoofer
     2016-07-10 19:02:50   neighborUpdate  done
     2016-10-16 20:19:13   reportedState   dim 42
     2016-10-16 21:09:49   setpointTemp    19.5 C heating
     2016-10-16 20:19:13   state           dim 42
     2016-10-16 20:49:29   temperature     23.0 C
     2016-10-16 20:19:14   thermostatMode  heating
     2016-07-03 16:39:46   thermostatSetpointSupported heating energySaveHeating
     2016-10-16 20:49:30   timeToAck       0.449
     2016-10-16 21:09:49   transmit        NO_ACK
     2016-10-16 21:09:38   wakeup          notification
     2016-07-03 16:39:46   wakeupIntervalCapabilitiesReport min 240 max 15728400 default 604672 step 240
     2016-10-08 09:01:12   wakeupReport    interval 600 target 1
   SendStack:
     sentget:130e03430201256c
     get:130e024002256d
     get:130e028002256e
     get:130e0231042576
     get:130e0226022577
     get:130e034302012578
     get:130e0240022579
     get:130e028002257a
     get:130e0286112580
     get:130e0231042581
     get:130e0226022582
     get:130e034302012583
     get:130e0240022584
     get:130e0280022585
Attributes:
   IODev      ZWAVE1
   alias      Heizkörper Heimkino
   classes    BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
   cmdIcon    tmOff:general_aus@red tmHeating:general_an@green
   group      Heizung
   icon       sani_heating
   room       Heimkino,Übersicht
   stateFormat Status: <strong>thermostatMode</strong> / Ventil: <strong>ActValve %</strong></br>Temperatur: <strong>IstTemp °C</strong></br>Solltemperatur: <strong> SollTemp °C</strong></br>Batterie: <strong>battery</strong>
   userReadings IstTemp:temperature.* { sprintf ("%.1f", ReadingsVal("E3.hk.HR.Bodenheizung","temperature",0)) }, SollTemp:setpointTemp.* { sprintf ("%.1f", ReadingsVal("E3.hk.HR.Bodenheizung","setpointTemp",0)) }, ActValve:reportedState.* { if (ReadingsVal("E3.hk.HR.Bodenheizung","reportedState",0) eq "off") { "0" } else { my @a = split (" ", ReadingsVal("E3.hk.HR.Bodenheizung","reportedState",0));; $a[1] }}
   vclasses   BASIC:1 BATTERY:1 MANUFACTURER_SPECIFIC:1 NODE_NAMING:1 SENSOR_MULTILEVEL:4 SWITCH_MULTILEVEL:3 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 VERSION:1 WAKE_UP:2
   webCmd     tmOff:tmHeating

[A.Harrenberg]

Hi,

kannst Du bitte bei dem ZWave_Dongle und dem Thermostat das verbose auch auf 5 setzen, so ist da zu wenig Info für mich drin...

Aber es gibt auf jeden Fall einen SEND_DATA failed Eintrag... Das ist schon mal nicht gut.

Gruß,
Andreas.