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.
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
Statt Neustart kannst du auch
{ 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.
Danke, dann kann ich mir ja erst mal mit dem delete behelfen.
Gruß
Torsten
Hallo zusammen,
das Löschen des sendstacks über { 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
ZitatIch 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.
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
ZitatFehlt 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.
Ok, dann werde ich mal den Umbau abwarten.