Sendstack: sendackget

[ToKa]

Hallo zusammen,

ich habe mal wieder eine Frage zum sendstack. Seit dem Umbau meiner Notifys hat sich das Verhalten meiner COMET Z zwar stark gebessert und es bleiben kaum noch Nachrichten auf dem sendstack "liegen" oder diese werden dann in Folge verspätet abgearbeitet. Was mir aber auffält ist, dass sobald ein sendackget auf dem sendstack liegen bleibt, die Wahrscheinlichkeit groß ist, dass sich dann der betroffene COMET Z aufhängt.

Was sollte denn eigentlich mit so einem sendackget passieren, wenn das Gerät wieder aufwacht? Kann das die Ursache sein, dass es dann zu Problemen kommt? Gibt es eine Möglichkeit den sendstack zu überwachen und so eine einzelne Nachricht  oder ggf. den kompletten sendstack für ein Gerät zu löschen? Bislang behelfe ich mir immer mit einem restart von fhem.

Code Auswählen Erweitern

Internals:
   DEF        d14c12e6 13
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     242
   NAME       ST.sz.HR.Heizung
   NR         75
   STATE      <strong>Ist: </strong>18.0 °C<strong> / Soll: </strong>19.5 C heating °C</br><strong>Ventil: </strong>0 %
   STILLDONETIME 0
   TYPE       ZWave
   ZWAVE1_MSGCNT 242
   ZWAVE1_RAWMSG 0004000d028407
   ZWAVE1_TIME 2017-01-17 06:42:28
   ZWaveSubDevice no
   homeId     d14c12e6
   isWakeUp   1
   lastMsgSent 1484631748.59421
   nodeIdHex  0d
   Helper:
     Dblog:
       Reportedstate:
         Logdb:
           TIME       1484630842.60509
           VALUE      0
       Setpointtemp:
         Logdb:
           TIME       1484630842.41853
           VALUE      19.5
       Temperature:
         Logdb:
           TIME       1484630841.02272
           VALUE      18.0
       Wakeup:
         Logdb:
           TIME       1484631748.59789
           VALUE      notification
   Readings:
     2017-01-16 13:17:57   SEND_DATA       failed:00
     2017-01-17 04:25:56   UNPARSED        SENSOR_MULTILEVEL 023105
     2017-01-14 07:56:43   battery         100 %
     2017-01-17 06:52:21   desired-new     00
     2017-01-17 06:52:22   desired-temp    20
     2016-07-01 10:19:52   model           EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
     2016-07-01 10:19:52   modelConfig     eurotronic/eur_cometz.xml
     2016-07-01 10:19:52   modelId         0148-0002-0001
     2016-12-30 19:54:32   neighborList    EG.ga.ZS.Glasbausteine ST.sz.ZS.WakeUpLight
     2016-12-30 19:54:20   neighborUpdate  done
     2017-01-17 06:27:22   reportedState   0
     2017-01-17 06:27:24   setpointTemp    19.5 C heating
     2017-01-17 06:27:22   state           off
     2017-01-17 06:27:21   temperature     18.0
     2016-11-10 19:49:00   thermostatMode  heating
     2017-01-17 06:42:28   timeToAck       0.149
     2017-01-17 06:42:28   transmit        OK
     2016-10-22 15:59:02   userCode        id 1 status 2 code 00c3
     2017-01-17 06:42:28   wakeup          notification
     2016-10-08 09:27:21   wakeupReport    interval 600 target 1
   SendStack:
     sentackget:130d023104258b
     set:130d064301012200c8259c
Attributes:
   DbLogInclude temperature,setpointTemp,reportedState,thermostatMode,battery,wakeup
   IODev      ZWAVE1
   alias      Schlafzimmer
   classes    BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
   event-min-interval temperature:60,setpointTemp:60,reportedState:60,thermostatMode:60,battery:60
   event-on-change-reading desired-temp,desired-new
   event-on-update-reading desired-temp,desired-new,temperature,setpointTemp,reportedState,thermostatMode,battery,wakeup,WunschTemp
   group      Heizung
   icon       sani_heating
   room       Übersicht
   sortby     6
   stateFormat {"<strong>Ist: </strong>".ReadingsVal('ST.sz.HR.Heizung','temperature','')." °C<strong> / Soll: </strong>".ReadingsVal('ST.sz.HR.Heizung','setpointTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('ST.sz.HR.Heizung','reportedState','')." %"}
   userReadings desired-temp,desired-new
   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     ::

Gruß
Torsten

[rudolfkoenig]

Statt Neustart kannst du auch

Code Auswählen Erweitern

{ delete $defs{"ST.sz.HR.Heizung"}{SendStack} }

ausfuehren. Eigentlich gehoert das gefixt, aber dazu brauche ich etwas weniger Hektik, d.h. es kann noch dauern.

[ToKa]

Danke, dann kann ich mir ja erst mal mit dem delete behelfen.

Gruß
Torsten

[ToKa]

Hallo zusammen,

das Löschen des sendstacks über

Code Auswählen Erweitern

{ delete $defs{"ST.sz.HR.Heizung"}{SendStack} } nutze ich bislang über die fhem Benutzeroberfläche. Jetzt habe ich ausprobiert, ob ich den Befehl nicht im wakeup notify als letzten Befehl nach den get-Abfragen nutzen kann.

Das hat allerdings dazu geführt, dass in der Regel nur noch die erste get-Abfrage funktioniert hat. Selbst ein sleep Befehl vor dem delete hat daran nichts geändert. Ich vermute, dass das delete schneller abgearbeitet wurde, als die  Kommunikation zwischen dem Controller und dem abgefragten Gerät für die 4 gets im notify.

Ich suche jetzt nach einer anderen Möglichkeit, das delete zu automatisieren, sobald die Kommunikation abgeschlossen ist. Soweit ich weiß, löst aber timetoACK und transmit kein event aus, auf dem ich ein weiteres notify aufbauen könnte.

Wie kann ich den Abschluss der Kommunikation mit dem z-wave Gerät ansonsten noch erkennen? Für Ideen und Anregungen wäre ich sehr dankbar.

Beste Grüße
Torsten

[rudolfkoenig]

Ich suche jetzt nach einer anderen Möglichkeit, das delete zu automatisieren, sobald die Kommunikation abgeschlossen ist.

Tja, definiere "abgeschlossen". Mit ZWave_isWakeUp($defs{geraet}) kann man abfragen, ob FHEM der Ansicht ist, ob die Gegenstelle schlaeft. Eigentlich ist das aber die Sache vom ZWave-Modul und nicht vom Benutzer.

Da eine Erweiterung/Rewrite des Sendstacks wg. Security-Integration ansteht (siehe https://forum.fhem.de/index.php/topic,68111.msg597803.html#msg597803), ist eine Loesung gar nicht unwahrscheinlich.

[ToKa]

Den Thread verfolge ich schon ganz gespannt, klingt aber komplex und nicht nach einer baldigen Umsetzung. Bis dahin hätte ich gerne eine Lösung für mich.

Abgeschlossen hätte ich für mich am Empfang des ACK oder NO_ACK festgemacht. Idealerweise durch ein event getriggert, das ich in einem notify oder doif verwenden könnte. Vielleicht stelle ich mir aber das "abgeschlossen" zu simpel vor.

Wenn ich das mit ZWave_isWakeUp($defs{geraet}) richtig verstehe, könnte ich das als Bedingung in ein doif einbauen. Fehlt mir aber immer noch das auslösende Ereignis oder macht es Sinn auf das wakeup mit einem wait im doif zu reagieren?

Beste Grüße
Torsten

[rudolfkoenig]

Fehlt mir aber immer noch das auslösende Ereignis oder macht es Sinn auf das wakeup mit einem wait im doif zu reagieren?

Stimmt, und das gibt es mW zur Zeit auch nicht immer. Wenn es gaebe, dann koennte das ZWave-Modul das Problem einfach loesen. Es ist ein Teil des Problems beim SendStack Neubau alle solchen Faelle zu identifizieren.

[ToKa]

Ok, dann werde ich mal den Umbau abwarten.