Hallo zusammen,
obwohl ich in der letzten Zeit keine Veränderungen bzgl. der Positionierung meiner ZWave Komponenten gemacht habe, finden sich im Log immer mal wieder Meldungen mit
2016.11.27 13:01:19.137 3: ZWave get E2.ez.HR.Bodenheizung setpoint
2016.11.27 13:01:23.515 2: ERROR: cannot SEND_DATA to E2.ez.HR.Bodenheizung: transmit queue overflow
2016.11.27 13:01:29.287 2: ZWAVE1 transmit NO_ACK for CB 60, target E2.ez.HR.Bodenheizung
2016.11.27 13:01:30.307 2: ZWAVE1 transmit NO_ACK for CB 60, target E2.ez.HR.Bodenheizung
2016.11.27 13:01:30.602 2: ZWAVE1 transmit NO_ACK for CB 60, target E2.ez.HR.Bodenheizung
20
und die Zeiten für timeToAck schwanken für das ein und selbe Gerät (auch Zwischenstecker) auf bis zu 7.542s.
Internals:
DEF d14c12e6 23
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 14
NAME E2.ku.ZS.Tischleuchte
NR 135
STATE neighborUpdate
TYPE ZWave
ZWAVE1_MSGCNT 14
ZWAVE1_RAWMSG 00489a22
ZWAVE1_TIME 2016-11-27 13:22:27
ZWaveSubDevice no
homeId d14c12e6
isWakeUp
lastMsgSent 1480249344.29863
nodeIdHex 17
Readings:
2016-11-22 19:04:42 assocGroup_1 Max 1 Nodes ZWAVE1
2016-11-22 19:04:42 assocGroup_2 Max 1 Nodes
2016-11-22 19:04:42 assocGroup_3 Max 1 Nodes ZWAVE1
2016-11-22 19:04:43 assocGroup_4 Max 1 Nodes
2016-11-22 19:04:41 assocGroups 4
2016-11-21 22:09:51 indState off
2016-11-08 20:01:52 model GreenWave PowerNode 1 port
2016-11-08 20:01:52 modelConfig greenwave/powernode1.xml
2016-11-08 20:01:52 modelId 0099-0002-0002
2016-11-27 12:43:49 neighborList ZWAVE1 E2.ez.HR.Bodenheizung E4.az.ZS.Stereoanlage
2016-11-27 13:22:27 neighborUpdate done
2016-11-27 09:49:51 power 0 W previous: 0.3 delta_time: 1 s
2016-11-08 20:25:09 reportedState on
2016-11-27 13:22:24 state neighborUpdate
2016-11-27 00:23:07 timeToAck 7.542
2016-11-27 00:23:07 transmit OK
Attributes:
IODev ZWAVE1
alias Tischleuchte Küche
classes SWITCH_BINARY METER MANUFACTURER_SPECIFIC VERSION BASIC ALARM CONFIGURATION SWITCH_ALL ASSOCIATION INDICATOR PROTECTION CRC_16_ENCAP
group Licht
icon light_light
room Küche,Übersicht
sortby 2
struc_Tischleuchten Tischleuchten
userattr E1.wz.ZS.Tischleuchte E1.wz.ZS.Tischleuchte_map struc_Tischleuchten struc_Tischleuchten_map structexclude
vclasses ALARM:1 ASSOCIATION:1 BASIC:1 CONFIGURATION:1 CRC_16_ENCAP:1 MANUFACTURER_SPECIFIC:2 METER:2 PROTECTION:2 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:1
Macht es Sinn per at einmal am Tag mit set TYPE=ZWave:FILTER=ZWaveSubDevice=no neighborUpdate für alle Geräte die NeigborList aktualisieren zu lassen? Oder was gibt es noch für Möglichkeiten?
Beste Grüße
Torsten
Zitat von: ToKa am 27 November 2016, 13:41:36
Macht es Sinn per at einmal am Tag mit set TYPE=ZWave:FILTER=ZWaveSubDevice=no neighborUpdate für alle Geräte die NeigborList aktualisieren zu lassen?
Wenn man nicht die Positionen der Geraete veraendert hat oder Geraete hinzugekommen bzw. entfernt wurden, dann ist das neighborUpdate mMn überflüssig und führt eher zu mehr Problemen als zu weniger.
Hast Du mal mit perfmon/apptime nachgeschaut, ob etwas FHEM blockiert? Solche timeToAck darf es eigentlich nicht geben.
Ansonsten schau Dir mal die Kommunikation FHEM mit E2.ez.HR.Bodenheizung naeher an (vebose 5), warum und wann es zu diesen NO_ACK kommt. "ERROR: cannot SEND_DATA" habe ich im Realbetrieb bisher nicht erzeugen können und dazu braeuchte man weitere Infos/Logs.
Gruß, Christian
Hallo Christian,
hatte eben jetzt wieder im Log ein "ERROR: cannot SEND_DATA to ST.sz.HR.Wandheizung: transmit queue overflow". Allerdings für einen anderen COMET Z. Anbei das Log, allerdings nur für den Controller mit Verbose=5. Insgesamt habe ich 368 solcher Fehlermeldungen im LOG November. Hoffe, das hilft Dir schon mal für eine weitere Analyse:
2016.11.27 23:16:34.021 3: ZWave set GH.gt.ZS.Gartenbeleuchtung on
2016.11.27 23:16:34.022 5: ZWDongle_Write 001318032501FF25db (d14c12e6)
2016.11.27 23:16:34.023 5: SW: 010a001318032501FF25dbd8
2016.11.27 23:16:34.060 5: ACK received, WaitForAck=>2 for 010a001318032501FF25dbd8
2016.11.27 23:16:34.060 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.27 23:16:34.060 5: SW: 06
2016.11.27 23:16:34.062 5: ZWAVE1 dispatch 011301
2016.11.27 23:16:34.154 4: ZWDongle_Read ZWAVE1: rcvd 0013db00000c (request ZW_SEND_DATA), sending ACK
2016.11.27 23:16:34.155 5: SW: 06
2016.11.27 23:16:34.156 5: device ack reveived, removing 010a001318032501FF25dbd8 from dongle sendstack
2016.11.27 23:16:34.156 5: ZWAVE1 dispatch 0013db00000c
2016.11.27 23:16:34.157 4: CMD:ZW_SEND_DATA ID:00 ARG:000c CB:db
2016.11.27 23:16:34.157 4: ZWAVE1 transmit OK for CB db, target GH.gt.ZS.Gartenbeleuchtung
2016.11.27 23:16:34.488 4: ZWDongle_Read ZWAVE1: rcvd 00040018032503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:16:34.489 5: SW: 06
2016.11.27 23:16:34.490 5: ZWAVE1 dispatch 00040018032503ff
2016.11.27 23:16:34.491 4: CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:032503ff CB:00
2016.11.27 23:16:34.645 4: ZWDongle_Read ZWAVE1: rcvd 000400180832022112003c0000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:16:34.646 5: SW: 06
2016.11.27 23:16:34.648 5: ZWAVE1 dispatch 000400180832022112003c0000
2016.11.27 23:16:34.648 4: CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:0832022112003c0000 CB:00
2016.11.27 23:22:02.771 4: ZWDongle_Read ZWAVE1: rcvd 0004000d028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:02.772 5: SW: 06
2016.11.27 23:22:02.774 5: ZWAVE1 dispatch 0004000d028407
2016.11.27 23:22:02.775 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:028407 CB:00
2016.11.27 23:22:02.971 3: ZWave get ST.sz.HR.Wandheizung smStatus
2016.11.27 23:22:02.972 5: ZWDongle_Write 00130d02310425dc (d14c12e6)
2016.11.27 23:22:02.973 5: SW: 010900130d02310425dc26
2016.11.27 23:22:02.978 3: ZWave get ST.sz.HR.Wandheizung swmStatus
2016.11.27 23:22:02.982 3: ZWave get ST.sz.HR.Wandheizung setpoint
2016.11.27 23:22:02.985 5: ACK received, WaitForAck=>2 for 010900130d02310425dc26
2016.11.27 23:22:02.985 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.27 23:22:02.986 5: SW: 06
2016.11.27 23:22:02.988 5: ZWAVE1 dispatch 011301
2016.11.27 23:22:03.040 4: ZWDongle_Read ZWAVE1: rcvd 0013dc000006 (request ZW_SEND_DATA), sending ACK
2016.11.27 23:22:03.040 5: SW: 06
2016.11.27 23:22:03.042 5: device ack reveived, removing 010900130d02310425dc26 from dongle sendstack
2016.11.27 23:22:03.043 5: ZWAVE1 dispatch 0013dc000006
2016.11.27 23:22:03.043 4: CMD:ZW_SEND_DATA ID:00 ARG:0006 CB:dc
2016.11.27 23:22:03.044 4: ZWAVE1 transmit OK for CB dc, target ST.sz.HR.Wandheizung
2016.11.27 23:22:03.093 4: ZWDongle_Read ZWAVE1: rcvd 0004000d063105012200e1 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:03.093 5: SW: 06
2016.11.27 23:22:03.095 5: ZWAVE1 dispatch 0004000d063105012200e1
2016.11.27 23:22:03.096 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:063105012200e1 CB:00
2016.11.27 23:22:03.099 5: ZWDongle_Write 00130d02260225dd (d14c12e6)
2016.11.27 23:22:03.100 5: SW: 010900130d02260225dd36
2016.11.27 23:22:03.122 5: ACK received, WaitForAck=>2 for 010900130d02260225dd36
2016.11.27 23:22:03.123 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.27 23:22:03.124 5: SW: 06
2016.11.27 23:22:03.125 5: ZWAVE1 dispatch 011301
2016.11.27 23:22:03.225 4: ZWDongle_Read ZWAVE1: rcvd 0013dd00000c (request ZW_SEND_DATA), sending ACK
2016.11.27 23:22:03.226 5: SW: 06
2016.11.27 23:22:03.227 5: device ack reveived, removing 010900130d02260225dd36 from dongle sendstack
2016.11.27 23:22:03.228 5: ZWAVE1 dispatch 0013dd00000c
2016.11.27 23:22:03.229 4: CMD:ZW_SEND_DATA ID:00 ARG:000c CB:dd
2016.11.27 23:22:03.229 4: ZWAVE1 transmit OK for CB dd, target ST.sz.HR.Wandheizung
2016.11.27 23:22:03.273 4: ZWDongle_Read ZWAVE1: rcvd 0004000d0326030d (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:03.274 5: SW: 06
2016.11.27 23:22:03.276 5: ZWAVE1 dispatch 0004000d0326030d
2016.11.27 23:22:03.276 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:0326030d CB:00
2016.11.27 23:22:03.279 5: ZWDongle_Write 00130d0343020125de (d14c12e6)
2016.11.27 23:22:03.280 5: SW: 010a00130d0343020125de53
2016.11.27 23:22:03.305 5: ACK received, WaitForAck=>2 for 010a00130d0343020125de53
2016.11.27 23:22:03.306 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.11.27 23:22:03.306 5: SW: 06
2016.11.27 23:22:03.308 5: ZWAVE1 dispatch 011301
2016.11.27 23:22:03.582 4: ZWDongle_Read ZWAVE1: rcvd 0004001803250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:03.583 5: SW: 06
2016.11.27 23:22:03.584 5: ZWAVE1 dispatch 0004001803250300
2016.11.27 23:22:03.585 4: CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:03250300 CB:00
2016.11.27 23:22:04.507 4: ZWDongle_Read ZWAVE1: rcvd 0004000d064303012200dc (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:04.508 5: SW: 06
2016.11.27 23:22:04.510 5: ZWAVE1 dispatch 0004000d064303012200dc
2016.11.27 23:22:04.510 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:064303012200dc CB:00
2016.11.27 23:22:05.344 5: ZWDongle_Write 00130d02840825df (d14c12e6)
2016.11.27 23:22:05.345 4: no response from device, removing 010a00130d0343020125de53 from dongle sendstack
2016.11.27 23:22:05.345 5: SW: 010900130d02840825df9c
2016.11.27 23:22:06.285 5: ACK received, WaitForAck=>2 for 010900130d02840825df9c
2016.11.27 23:22:06.291 4: ZWDongle_Read ZWAVE1: rcvd 011300 (answer ZW_SEND_DATA), sending ACK
2016.11.27 23:22:06.291 5: SW: 06
2016.11.27 23:22:06.293 5: ZWAVE1 dispatch 011300
2016.11.27 23:22:06.296 2: ERROR: cannot SEND_DATA to ST.sz.HR.Wandheizung: transmit queue overflow
2016.11.27 23:22:06.298 4: ZWDongle_Read ZWAVE1: rcvd 00040018083202211200000000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:06.298 5: SW: 06
2016.11.27 23:22:06.300 5: ZWAVE1 dispatch 00040018083202211200000000
2016.11.27 23:22:06.301 4: CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:083202211200000000 CB:00
2016.11.27 23:22:06.916 4: ZWDongle_Read ZWAVE1: rcvd 000400180a32022144000012e60000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:06.917 5: SW: 06
2016.11.27 23:22:06.919 5: ZWAVE1 dispatch 000400180a32022144000012e60000
2016.11.27 23:22:06.920 4: CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:0a32022144000012e60000 CB:00
2016.11.27 23:22:07.940 4: no response from device, removing 010900130d02840825df9c from dongle sendstack
2016.11.27 23:22:08.601 4: ZWDongle_Read ZWAVE1: rcvd 0004000d064303012200dc (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:08.601 5: SW: 06
2016.11.27 23:22:08.603 5: ZWAVE1 dispatch 0004000d064303012200dc
2016.11.27 23:22:08.604 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:064303012200dc CB:00
2016.11.27 23:22:08.750 4: ZWDongle_Read ZWAVE1: rcvd 0004000d064303012200dc (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:08.751 5: SW: 06
2016.11.27 23:22:08.753 5: ZWAVE1 dispatch 0004000d064303012200dc
2016.11.27 23:22:08.753 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:064303012200dc CB:00
2016.11.27 23:22:08.890 4: ZWDongle_Read ZWAVE1: rcvd 0004000d064303012200dc (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:08.891 5: SW: 06
2016.11.27 23:22:08.893 5: ZWAVE1 dispatch 0004000d064303012200dc
2016.11.27 23:22:08.893 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:064303012200dc CB:00
2016.11.27 23:22:10.078 4: ZWDongle_Read ZWAVE1: rcvd 0004100d064303012200dc (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:10.079 5: SW: 06
2016.11.27 23:22:10.080 5: ZWAVE1 dispatch 0004100d064303012200dc
2016.11.27 23:22:10.081 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:064303012200dc CB:10
2016.11.27 23:22:10.547 4: ZWDongle_Read ZWAVE1: rcvd 0013df0101aa (request ZW_SEND_DATA), sending ACK
2016.11.27 23:22:10.548 5: SW: 06
2016.11.27 23:22:10.549 5: ZWAVE1 dispatch 0013df0101aa
2016.11.27 23:22:10.550 4: CMD:ZW_SEND_DATA ID:01 ARG:01aa CB:df
2016.11.27 23:22:10.551 2: ZWAVE1 transmit NO_ACK for CB df, target ST.sz.HR.Wandheizung
2016.11.27 23:22:10.712 4: ZWDongle_Read ZWAVE1: rcvd 00041009064303052200dc (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.27 23:22:10.713 5: SW: 06
2016.11.27 23:22:10.714 5: ZWAVE1 dispatch 00041009064303052200dc
2016.11.27 23:22:10.715 4: CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:064303052200dc CB:10
jump to the top
Hier noch das List vom betroffenen Gerät:
Internals:
DEF d14c12e6 13
IMAGE /fhem/deviceimages/zwave/ZC08-15110002
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 619
NAME ST.sz.HR.Wandheizung
NR 92
STATE <strong>Ist-Temperatur: </strong>22.5 °C<strong> / Soll-Temperatur: </strong>22.0 °C</br><strong>Ventil: </strong>13 %
STILLDONETIME 0
TYPE ZWave
ZWAVE1_MSGCNT 619
ZWAVE1_RAWMSG 0013df0101aa
ZWAVE1_TIME 2016-11-27 23:22:10
ZWaveSubDevice no
homeId d14c12e6
isWakeUp 1
lastMsgSent 1480285325.34404
nodeIdHex 0d
Readings:
2016-11-27 23:22:03 ActValve 13
2016-11-27 23:22:03 IstTemp 22.5
2016-11-27 23:22:06 SEND_DATA failed:00
2016-11-27 23:22:10 SollTemp 22.0
2016-11-22 03:24:06 UNPARSED SWITCH_MULTILEVEL 022603
2016-11-26 21:57:04 WunschTemp 00
2016-11-27 04:58:35 battery 100 %
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-11-12 20:53:22 neighborList EG.ga.ZS.Glasbausteine ST.sz.ZS.WakeUpLight
2016-11-27 13:32:38 neighborUpdate done
2016-11-27 23:22:03 reportedState dim 13
2016-11-27 23:22:10 setpointTemp 22.0 C heating
2016-11-27 23:22:03 state dim 13
2016-11-27 23:22:03 temperature 22.5 C
2016-11-10 19:49:00 thermostatMode heating
2016-11-27 23:22:03 timeToAck 0.133
2016-11-27 23:22:10 transmit NO_ACK
2016-10-22 15:59:02 userCode id 1 status 2 code 00c3
2016-11-27 23:22:02 wakeup notification
2016-10-08 09:27:21 wakeupReport interval 600 target 1
Attributes:
IODev ZWAVE1
alias Heizkörper Schlafzimmer
classes BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
group Heizung
icon sani_heating
room Übersicht
sortby 5
stateFormat {"<strong>Ist-Temperatur: </strong>".ReadingsVal('ST.sz.HR.Wandheizung','IstTemp','')." °C<strong> / Soll-Temperatur: </strong>".ReadingsVal('ST.sz.HR.Wandheizung','SollTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('ST.sz.HR.Wandheizung','ActValve','')." %"}
userReadings IstTemp:temperature.* { my @a = split(" ",ReadingsVal("ST.sz.HR.Wandheizung","temperature",0));; $a[0] }, SollTemp:setpointTemp.* { my @a = split(" ",ReadingsVal("ST.sz.HR.Wandheizung","setpointTemp",0));; $a[0] }, ActValve:reportedState.* { if (ReadingsVal("ST.sz.HR.Wandheizung","reportedState",0) eq "off") { "0" } else { my @a = split (" ", ReadingsVal("ST.sz.HR.Wandheizung","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
Die Probleme beginnen im Log damit, dass auf die verschickte Nachricht "get ST.sz.HR.Wandheizung setpoint" keine Empfangsbestätigung des Stellantriebs (0013de00) bei FHEM/Controller eingeht. An der Stelle, wo die Empfangsbestätigung kommen sollte, wird die laufende Kommunikation Controller/Stellantrieb durch eine SWITCH_BINARY Nachricht von hexNodeId 18 unterbrochen. Eigentlich kein Problem für ZWave. Jedoch kommt bei Dir auch danach keine Empfangsbestätigung des Stellantriebs (0013de00) noch die Info des Controllers über eine ausbleibende Empfangsbestätigung für den Befehl (0013de01). Stattdessen über eine Sekunde nach "get ST.sz.HR.Wandheizung setpoint" direkt die Antwort auf die Abfrage und weitere 4 Sekunden später noch 3x. Also hat wohl der Stellantrieb den Abfragebefehl mehrfach auf Protokollebene erhalten, weil der Controller kein ACK vom Stellantrieb empfangen hat.
Die "ERROR: Cannot SEND_DATA" und "NO_ACK" sind mMn nur Folgeerscheinungen der Kommunikationsprobleme bei der Abfrage des Stellantriebs.
Tritt das Problem nur bei StellaZ-Antrieben auf?
Wenn das erst seit kurzem in der Regelmäßigkeit auftritt und vorher problemlos lief, musst Du an Deinem System etwas verändert haben. Was?
Weniger get-Abfragen auf wakeupNotification-Event: Warum fragst (pollst) Du so viele Werte des Stella-Z ab? Sind die alle notwendig? Was passiert, wenn Du die herausnimmst oder per FHEM-sleep den Versand verzögert anstößt?
Gibt es Zusammenhänge zwischen hexNodeId 18 und Stellantrieb?
Hallo Christian,
vielen Dank für die Entschlüsselung des Logs. Beim hexNodeId 18 handelt es sich mal wieder um den POPP 9105 für die Gartenbeleuchtung, der sich ja anfänglich beim Inkludieren merkwürdig verhalten hat (secure ja/nein???). Es besteht allenfalls die Möglichkeit, dass der COMET Z und der POPP im Netz als "Nachbarn" vorhanden sind, da sie räumlich nicht weit auseinander sind.
Im WakeUp für den COMET Z frage ich nur alle 15 Minuten die Temperatur, den Sollwert und das Ventil ab. Sofern hier mehrere Anfragen liefen, liegt das mMn an den noch nicht abgearbeiteten Abfragen auf dem Sendstack, was leider auch immer mal wieder vorkommt.
Werde den POPP mal exkludieren, neu inkludieren und das Log weiter beobachten.
Beste Grüße
Torsten
EDIT: Nachdem ich den POPP neu inkludiert habe, lässt er sich zwar per ZWAVE an- und ausschalten, aber die angeschlossene Lampe bleibt aus (höre auch kein klackern, wie früher...). Ich gehe davon aus, dass das Ding nun ganz hinüber ist. Werde es mal aus dem Verkehr ziehen und schauen, wie sich das Netz jetzt verhält.
Hallo Christian,
seitdem der POPP nicht mehr im Netz ist, hat sich die Sache etwas beruhigt. Aber heute sind wieder ein Einträge im Log mit
ERROR: cannot SEND_DATA to E4.az.HR.Wandheizung: transmit queue overflow
Leider war zu diesem Zeitpunkt kein verbose 5 eingeschaltet. Es sind wieder mehrfache Abfragen an das gleiche Gerät gegangen. Ich vermute, dass sich die Abfragen wieder auf dem Sendstack gesammelt hatten. Der Heizungsregler hatte noch nie was mit dem POPP "zu tun". Im gleichen Raum befindet sich eine Greenwave Funksteckdose, die als Repeater dient.
Ich scheue etwas davor zurück, permanent verbose 5 eingeschaltet zu lassen, da ich befürchte die SD Karte im Raspi verkraftet das nicht.
2016.11.30 17:29:39.889 3: ZWave get E4.az.HR.Wandheizung smStatus
2016.11.30 17:29:39.896 3: ZWave get E4.az.HR.Wandheizung swmStatus
2016.11.30 17:29:39.900 3: ZWave get E4.az.HR.Wandheizung setpoint
2016.11.30 17:29:40.014 3: ZWave get E4.az.HR.Wandheizung smStatus
2016.11.30 17:29:40.018 3: ZWave get E4.az.HR.Wandheizung swmStatus
2016.11.30 17:29:40.022 3: ZWave get E4.az.HR.Wandheizung setpoint
2016.11.30 17:29:40.691 3: ZWave get E4.az.HR.Wandheizung smStatus
2016.11.30 17:29:40.695 3: ZWave get E4.az.HR.Wandheizung swmStatus
2016.11.30 17:29:40.699 3: ZWave get E4.az.HR.Wandheizung setpoint
2016.11.30 17:29:41.672 3: ZWave get E4.az.HR.Wandheizung smStatus
2016.11.30 17:29:41.676 3: ZWave get E4.az.HR.Wandheizung swmStatus
2016.11.30 17:29:41.680 3: ZWave get E4.az.HR.Wandheizung setpoint
2016.11.30 17:29:41.772 3: ZWave get E4.az.HR.Wandheizung smStatus
2016.11.30 17:29:41.776 3: ZWave get E4.az.HR.Wandheizung swmStatus
2016.11.30 17:29:41.781 3: ZWave get E4.az.HR.Wandheizung setpoint
2016.11.30 17:29:44.742 2: ERROR: cannot SEND_DATA to E4.az.HR.Wandheizung: transmit queue overflow
2016.11.30 17:29:46.758 2: ERROR: cannot SEND_DATA to E4.az.HR.Wandheizung: transmit queue overflow
2016.11.30 17:29:51.179 2: ZWAVE1 transmit NO_ACK for CB 48, target E4.az.HR.Wandheizung
2016.11.30 17:29:51.669 2: ZWAVE1 transmit NO_ACK for CB 48, target E4.az.HR.Wandheizung
2016.11.30 17:32:18.938 3: ZWave get E4.az.HR.Wandheizung smStatus
2016.11.30 17:32:18.942 3: ZWave get E4.az.HR.Wandheizung swmStatus
2016.11.30 17:32:18.946 3: ZWave get E4.az.HR.Wandheizung setpoint
2016.11.30 17:32:27.112 2: ERROR: cannot SEND_DATA to E4.az.HR.Wandheizung: transmit queue overflow
2016.11.30 17:32:32.801 2: ZWAVE1 transmit NO_ACK for CB 57, target E4.az.HR.Wandheizung
2016.11.30 17:32:37.350 2: ZWAVE1 transmit NO_ACK for CB 57, target E4.az.HR.Wandheizung
Hast Du noch eine Idee, was ich tun kann? Deinen Vorschlag mit dem sleep zwischen den gets im notify kann ich gerne mal ausprobieren. Was wäre dann der "richtige" Wert für das sleep?
Beste Grüße
Torsten
Nachdem ich jetzt mal noch ein neighbor update angestoßen habe, sind auf dem stack wieder einige gets nach dem wakeup stehe geblieben:
Internals:
DEF d14c12e6 20
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 19
NAME E4.az.HR.Wandheizung
NR 110
STATE <strong>Ist-Temperatur: </strong>23.0 °C<strong> / Soll-Temperatur: </strong>22 °C</br><strong>Ventil: </strong>0 %
TYPE ZWave
ZWAVE1_MSGCNT 19
ZWAVE1_RAWMSG 00485222
ZWAVE1_TIME 2016-11-30 19:16:22
ZWaveSubDevice no
homeId d14c12e6
isWakeUp 1
lastMsgSent 1480529779.04102
nodeIdHex 14
Readings:
2016-11-30 19:01:12 ActValve 0
2016-10-22 20:40:31 CMD ZW_APPLICATION_UPDATE
2016-11-30 19:01:12 IstTemp 23.0
2016-11-30 17:32:27 SEND_DATA failed:00
2016-11-30 19:06:11 SollTemp 22
2016-11-29 01:25:25 UNPARSED SENSOR_MULTILEVEL 023105
2016-11-30 19:06:11 WunschTemp 00
2016-11-30 04:53:43 battery 100 %
2016-10-22 12:27:27 model EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
2016-10-22 12:27:27 modelConfig eurotronic/eur_cometz.xml
2016-10-22 12:27:27 modelId 0148-0002-0001
2016-11-15 21:17:09 neighborList E4.az.ZS.Stereoanlage
2016-11-30 19:16:22 neighborUpdate done
2016-11-30 19:01:12 reportedState off
2016-11-30 19:01:12 setpointTemp 19.5 C heating
2016-11-30 19:01:12 state off
2016-11-30 19:01:12 temperature 23.0 C
2016-11-10 19:30:24 thermostatMode heating
2016-11-30 19:16:19 timeToAck 0.132
2016-11-30 19:16:19 transmit OK
2016-11-30 19:16:18 wakeup notification
2016-11-04 19:58:24 wakeupReport interval 900 target 1
SendStack:
sentset:481452
get:13140231042568
get:13140226022569
get:131403430201256a
Attributes:
IODev ZWAVE1
alias Heizkörper Arbeitszimmer
classes BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
group Heizung
icon sani_heating
room Übersicht
sortby 1
stateFormat {"<strong>Ist-Temperatur: </strong>".ReadingsVal('E4.az.HR.Wandheizung','IstTemp','')." °C<strong> / Soll-Temperatur: </strong>".ReadingsVal('E4.az.HR.Wandheizung','SollTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('E4.az.HR.Wandheizung','ActValve','')." %"}
userReadings IstTemp:temperature.* { my @a = split(" ",ReadingsVal("E4.az.HR.Wandheizung","temperature",0));; $a[0] }, SollTemp:setpointTemp.* { my @a = split(" ",ReadingsVal("E4.az.HR.Wandheizung","setpointTemp",0));; $a[0] }, ActValve:reportedState.* { if (ReadingsVal("E4.az.HR.Wandheizung","reportedState",0) eq "off") { "0" } else { my @a = split (" ", ReadingsVal("E4.az.HR.Wandheizung","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
Werde mal verbose 5 einstellen, vielleicht lässt sich der Fall ja provozieren / reproduzieren.
Gruß
Torsten
Ohne verbose 5-Log ist eine Analyse "schwierig"; mit zugegebenermaßen auch bei Unkenntnis der Systemdetails auch oft Raterei. :)
Wenn es wirklich immer nur bei den Stella-Z und auch noch bei verschiedenen auftritt, dann vergiss FHEM-sleep-
Stell doch einmal die get-Abfragen in einzelne notifys um:
1. notify triggert auf wakeupNotification und setzt "get E4.az.HR.Wandheizung smStatus" ab. 2. notify triggert auf Event der Antwort und setzt "get E4.az.HR.Wandheizung swmStatus" usw.
Ob das wirklich Besserung bringt, kann ich nicht versprechen. Anhand der Angaben habe ich momentan keine anderen Ideen.
Nachdem heute Nacht im Log wieder etliche mal der Fehler "ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow" zu finden war und auf dem sendstack über zehn messages hingen, habe ich nach einem restart von fhem mit verbose 5 eine Logdatei erstellt. Das Gerät hat laut Protokoll 3 wakeup notofications ausgelöst...
Der Fehler ähnelt m.E. auch sehr dem von tomspatz in https://forum.fhem.de/index.php/topic,59026.msg534117.html#msg534117 geschilderten verhalten.
Eventmonitor:
2016-12-09 09:35:51.116 ZWave E4.az.HR.Heizung wakeup: notification
2016-12-09 09:35:51.903 ZWave E4.az.HR.Heizung wakeup: notification
2016-12-09 09:35:53.056 ZWave E4.az.HR.Heizung wakeup: notification
2016-12-09 09:35:53.389 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.IstTemp: 20.5 °C
2016-12-09 09:35:53.412 readingsGroup Raumtemperatur E4.az.HR.Heizung.temperature: 20.5 °C
2016-12-09 09:35:53.417 ZWave E4.az.HR.Heizung temperature: 20.5 C
2016-12-09 09:35:53.417 ZWave E4.az.HR.Heizung IstTemp: 20.5
2016-12-09 09:35:53.921 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.IstTemp: 20.5 °C
2016-12-09 09:35:53.943 readingsGroup Raumtemperatur E4.az.HR.Heizung.temperature: 20.5 °C
2016-12-09 09:35:53.947 ZWave E4.az.HR.Heizung temperature: 20.5 C
2016-12-09 09:35:53.947 ZWave E4.az.HR.Heizung IstTemp: 20.5
2016-12-09 09:35:54.276 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.IstTemp: 20.5 °C
2016-12-09 09:35:54.298 readingsGroup Raumtemperatur E4.az.HR.Heizung.temperature: 20.5 °C
2016-12-09 09:35:54.302 ZWave E4.az.HR.Heizung temperature: 20.5 C
2016-12-09 09:35:54.302 ZWave E4.az.HR.Heizung IstTemp: 20.5
2016-12-09 09:35:54.460 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.IstTemp: 20.5 °C
2016-12-09 09:35:54.482 readingsGroup Raumtemperatur E4.az.HR.Heizung.temperature: 20.5 °C
2016-12-09 09:35:54.487 ZWave E4.az.HR.Heizung temperature: 20.5 C
2016-12-09 09:35:54.487 ZWave E4.az.HR.Heizung IstTemp: 20.5
2016-12-09 09:35:54.965 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.ActValve: 6 %
2016-12-09 09:35:54.980 ZWave E4.az.HR.Heizung dim 6
2016-12-09 09:35:54.980 ZWave E4.az.HR.Heizung reportedState: dim 6
2016-12-09 09:35:54.980 ZWave E4.az.HR.Heizung ActValve: 6
2016-12-09 09:35:56.827 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.ActValve: 6 %
2016-12-09 09:35:56.843 ZWave E4.az.HR.Heizung dim 6
2016-12-09 09:35:56.843 ZWave E4.az.HR.Heizung reportedState: dim 6
2016-12-09 09:35:56.843 ZWave E4.az.HR.Heizung ActValve: 6
2016-12-09 09:36:06.088 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.ActValve: 6 %
2016-12-09 09:36:06.113 ZWave E4.az.HR.Heizung SEND_DATA: failed:00
2016-12-09 09:36:06.113 ZWave E4.az.HR.Heizung SEND_DATA: failed:00
2016-12-09 09:36:06.113 ZWave E4.az.HR.Heizung SEND_DATA: failed:00
2016-12-09 09:36:06.113 ZWave E4.az.HR.Heizung dim 6
2016-12-09 09:36:06.113 ZWave E4.az.HR.Heizung reportedState: dim 6
2016-12-09 09:36:06.113 ZWave E4.az.HR.Heizung ActValve: 6
2016-12-09 09:36:06.494 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.ActValve: 6 %
2016-12-09 09:36:06.509 ZWave E4.az.HR.Heizung dim 6
2016-12-09 09:36:06.509 ZWave E4.az.HR.Heizung reportedState: dim 6
2016-12-09 09:36:06.509 ZWave E4.az.HR.Heizung ActValve: 6
2016-12-09 09:36:06.570 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.SollTemp: 19.5 °C
2016-12-09 09:36:06.585 ZWave E4.az.HR.Heizung setpointTemp: 19.5 C heating
2016-12-09 09:36:06.585 ZWave E4.az.HR.Heizung SollTemp: 19.5
2016-12-09 09:36:06.643 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.IstTemp: 20.5 °C
2016-12-09 09:36:06.665 readingsGroup Raumtemperatur E4.az.HR.Heizung.temperature: 20.5 °C
2016-12-09 09:36:06.670 ZWave E4.az.HR.Heizung temperature: 20.5 C
2016-12-09 09:36:06.670 ZWave E4.az.HR.Heizung IstTemp: 20.5
2016-12-09 09:36:06.712 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.ActValve: 6 %
2016-12-09 09:36:06.728 ZWave E4.az.HR.Heizung dim 6
2016-12-09 09:36:06.728 ZWave E4.az.HR.Heizung reportedState: dim 6
2016-12-09 09:36:06.728 ZWave E4.az.HR.Heizung ActValve: 6
2016-12-09 09:36:07.595 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.SollTemp: 19.5 °C
2016-12-09 09:36:07.615 ZWave E4.az.HR.Heizung setpointTemp: 19.5 C heating
2016-12-09 09:36:07.615 ZWave E4.az.HR.Heizung SollTemp: 19.5
2016-12-09 09:36:07.690 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.SollTemp: 19.5 °C
2016-12-09 09:36:07.704 ZWave E4.az.HR.Heizung setpointTemp: 19.5 C heating
2016-12-09 09:36:07.704 ZWave E4.az.HR.Heizung SollTemp: 19.5
2016-12-09 09:36:07.984 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.SollTemp: 19.5 °C
2016-12-09 09:36:07.998 ZWave E4.az.HR.Heizung setpointTemp: 19.5 C heating
2016-12-09 09:36:07.998 ZWave E4.az.HR.Heizung SollTemp: 19.5
2016-12-09 09:36:08.084 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.SollTemp: 19.5 °C
2016-12-09 09:36:08.098 ZWave E4.az.HR.Heizung setpointTemp: 19.5 C heating
2016-12-09 09:36:08.098 ZWave E4.az.HR.Heizung SollTemp: 19.5
2016-12-09 09:36:08.486 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.SollTemp: 19.5 °C
2016-12-09 09:36:08.500 ZWave E4.az.HR.Heizung setpointTemp: 19.5 C heating
2016-12-09 09:36:08.500 ZWave E4.az.HR.Heizung SollTemp: 19.5
2016-12-09 09:36:08.774 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.SollTemp: 19.5 °C
2016-12-09 09:36:08.788 ZWave E4.az.HR.Heizung setpointTemp: 19.5 C heating
2016-12-09 09:36:08.788 ZWave E4.az.HR.Heizung SollTemp: 19.5
2016-12-09 09:36:08.890 readingsGroup E4.az.HZ.Wandheizung.ctl E4.az.HR.Heizung.SollTemp: 19.5 °C
2016-12-09 09:36:08.904 ZWave E4.az.HR.Heizung setpointTemp: 19.5 C heating
2016-12-09 09:36:08.904 ZWave E4.az.HR.Heizung SollTemp: 19.5
2016-12-09 09:36:09.201 ZWave E4.az.HR.Heizung transmit: NO_ACK
2016-12-09 09:36:30.638 readingsGroup Raumtemperatur EG.fl.RM.Decke.temperature: 21.4 °C
2016-12-09 09:36:30.643 ZWave EG.fl.RM.Decke temperature: 21.4 C
Logdatei:
2016.12.09 09:35:51.096 3: ZS.zs.HR.wakeUpAll.nfy: E4.az.HR.Heizung wakeup: notification
2016.12.09 09:35:51.100 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 09:35:51.101 5: ZWDongle_Write 0013140231042520 (d14c12e6)
2016.12.09 09:35:51.103 5: SW: 01090013140231042520c3
2016.12.09 09:35:51.107 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 09:35:51.112 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 09:35:51.118 5: ACK received, WaitForAck=>2 for 01090013140231042520c3
2016.12.09 09:35:51.119 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:35:51.119 5: SW: 06
2016.12.09 09:35:51.121 5: ZWAVE1: dispatch 011301
2016.12.09 09:35:51.858 4: ZWDongle_Read ZWAVE1: rcvd 00040014028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:35:51.859 5: SW: 06
2016.12.09 09:35:51.861 5: ZWAVE1: dispatch 00040014028407
2016.12.09 09:35:51.862 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:028407 CB:00
2016.12.09 09:35:51.863 5: ZWDongle_Write 0013140226022521 (d14c12e6)
2016.12.09 09:35:51.889 3: ZS.zs.HR.wakeUpAll.nfy: E4.az.HR.Heizung wakeup: notification
2016.12.09 09:35:51.892 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 09:35:51.896 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 09:35:51.900 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 09:35:53.011 4: ZWDongle_Read ZWAVE1: rcvd 00041014028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:35:53.012 5: SW: 06
2016.12.09 09:35:53.014 5: ZWAVE1: dispatch 00041014028407
2016.12.09 09:35:53.015 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:028407 CB:10
2016.12.09 09:35:53.017 5: ZWDongle_Write 001314034302012522 (d14c12e6)
2016.12.09 09:35:53.041 3: ZS.zs.HR.wakeUpAll.nfy: E4.az.HR.Heizung wakeup: notification
2016.12.09 09:35:53.045 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 09:35:53.048 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 09:35:53.052 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 09:35:53.085 4: ZWDongle_Read ZWAVE1: rcvd 0013200000c6 (request ZW_SEND_DATA), sending ACK
2016.12.09 09:35:53.086 5: SW: 06
2016.12.09 09:35:53.088 5: device ack reveived, removing 01090013140231042520c3 from dongle sendstack
2016.12.09 09:35:53.089 5: ZWAVE1: dispatch 0013200000c6
2016.12.09 09:35:53.089 4: CMD:ZW_SEND_DATA ID:00 ARG:00c6 CB:20
2016.12.09 09:35:53.090 4: ZWAVE1 transmit OK for CB 20, target E4.az.HR.Heizung
2016.12.09 09:35:53.093 5: SW: 01090013140226022521d3
2016.12.09 09:35:53.096 5: ACK received, WaitForAck=>2 for 01090013140226022521d3
2016.12.09 09:35:53.100 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:35:53.100 5: SW: 06
2016.12.09 09:35:53.103 5: ZWAVE1: dispatch 011301
2016.12.09 09:35:53.364 4: ZWDongle_Read ZWAVE1: rcvd 00040014063105012200cd (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:35:53.364 5: SW: 06
2016.12.09 09:35:53.366 5: ZWAVE1: dispatch 00040014063105012200cd
2016.12.09 09:35:53.367 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:063105012200cd CB:00
2016.12.09 09:35:53.369 5: ZWDongle_Write 0013140231042523 (d14c12e6)
2016.12.09 09:35:53.896 4: ZWDongle_Read ZWAVE1: rcvd 00041014063105012200cd (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:35:53.896 5: SW: 06
2016.12.09 09:35:53.898 5: ZWAVE1: dispatch 00041014063105012200cd
2016.12.09 09:35:53.899 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:063105012200cd CB:10
2016.12.09 09:35:53.901 5: ZWDongle_Write 0013140226022524 (d14c12e6)
2016.12.09 09:35:53.957 4: ZWDongle_Read ZWAVE1: rcvd 001321000056 (request ZW_SEND_DATA), sending ACK
2016.12.09 09:35:53.958 5: SW: 06
2016.12.09 09:35:53.959 5: device ack reveived, removing 01090013140226022521d3 from dongle sendstack
2016.12.09 09:35:53.960 5: ZWAVE1: dispatch 001321000056
2016.12.09 09:35:53.961 4: CMD:ZW_SEND_DATA ID:00 ARG:0056 CB:21
2016.12.09 09:35:53.961 4: ZWAVE1 transmit OK for CB 21, target E4.az.HR.Heizung
2016.12.09 09:35:53.963 5: SW: 010a001314034302012522b6
2016.12.09 09:35:53.965 5: ACK received, WaitForAck=>2 for 010a001314034302012522b6
2016.12.09 09:35:53.971 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:35:53.971 5: SW: 06
2016.12.09 09:35:53.973 5: ZWAVE1: dispatch 011301
2016.12.09 09:35:54.251 4: ZWDongle_Read ZWAVE1: rcvd 00041014063105012200cd (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:35:54.251 5: SW: 06
2016.12.09 09:35:54.253 5: ZWAVE1: dispatch 00041014063105012200cd
2016.12.09 09:35:54.254 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:063105012200cd CB:10
2016.12.09 09:35:54.256 5: ZWDongle_Write 001314034302012525 (d14c12e6)
2016.12.09 09:35:54.435 4: ZWDongle_Read ZWAVE1: rcvd 00041014063105012200cd (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:35:54.436 5: SW: 06
2016.12.09 09:35:54.438 5: ZWAVE1: dispatch 00041014063105012200cd
2016.12.09 09:35:54.439 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:063105012200cd CB:10
2016.12.09 09:35:54.441 5: ZWDongle_Write 0013140231042526 (d14c12e6)
2016.12.09 09:35:54.876 4: ZWDongle_Read ZWAVE1: rcvd 00132200005b (request ZW_SEND_DATA), sending ACK
2016.12.09 09:35:54.876 5: SW: 06
2016.12.09 09:35:54.878 5: device ack reveived, removing 010a001314034302012522b6 from dongle sendstack
2016.12.09 09:35:54.879 5: ZWAVE1: dispatch 00132200005b
2016.12.09 09:35:54.879 4: CMD:ZW_SEND_DATA ID:00 ARG:005b CB:22
2016.12.09 09:35:54.879 4: ZWAVE1 transmit OK for CB 22, target E4.az.HR.Heizung
2016.12.09 09:35:54.882 5: SW: 01090013140231042523c0
2016.12.09 09:35:54.884 5: ACK received, WaitForAck=>2 for 01090013140231042523c0
2016.12.09 09:35:54.888 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:35:54.889 5: SW: 06
2016.12.09 09:35:54.890 5: ZWAVE1: dispatch 011301
2016.12.09 09:35:54.939 4: ZWDongle_Read ZWAVE1: rcvd 0004001403260306 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:35:54.940 5: SW: 06
2016.12.09 09:35:54.942 5: ZWAVE1: dispatch 0004001403260306
2016.12.09 09:35:54.942 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:03260306 CB:00
2016.12.09 09:35:54.944 5: ZWDongle_Write 0013140226022527 (d14c12e6)
2016.12.09 09:35:55.218 4: ZWDongle_Read ZWAVE1: rcvd 001323000021 (request ZW_SEND_DATA), sending ACK
2016.12.09 09:35:55.218 5: SW: 06
2016.12.09 09:35:55.219 5: device ack reveived, removing 01090013140231042523c0 from dongle sendstack
2016.12.09 09:35:55.220 5: ZWAVE1: dispatch 001323000021
2016.12.09 09:35:55.221 4: CMD:ZW_SEND_DATA ID:00 ARG:0021 CB:23
2016.12.09 09:35:55.221 4: ZWAVE1 transmit OK for CB 23, target E4.az.HR.Heizung
2016.12.09 09:35:55.223 5: SW: 01090013140226022524d6
2016.12.09 09:35:55.226 5: ACK received, WaitForAck=>2 for 01090013140226022524d6
2016.12.09 09:35:55.230 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:35:55.230 5: SW: 06
2016.12.09 09:35:55.232 5: ZWAVE1: dispatch 011301
2016.12.09 09:35:56.802 4: ZWDongle_Read ZWAVE1: rcvd 0004101403260306 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:35:56.803 5: SW: 06
2016.12.09 09:35:56.805 5: ZWAVE1: dispatch 0004101403260306
2016.12.09 09:35:56.805 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:03260306 CB:10
2016.12.09 09:35:56.807 5: ZWDongle_Write 001314034302012528 (d14c12e6)
2016.12.09 09:35:57.846 4: no response from device, removing 01090013140226022524d6 from dongle sendstack
2016.12.09 09:35:57.847 5: SW: 010a001314034302012525b1
2016.12.09 09:35:58.438 5: ACK received, WaitForAck=>2 for 010a001314034302012525b1
2016.12.09 09:35:58.440 4: ZWDongle_Read ZWAVE1: rcvd 011300 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:35:58.441 5: SW: 06
2016.12.09 09:35:58.443 5: ZWAVE1: dispatch 011300
2016.12.09 09:35:58.446 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
2016.12.09 09:36:00.453 4: no response from device, removing 010a001314034302012525b1 from dongle sendstack
2016.12.09 09:36:00.454 5: SW: 01090013140231042526c5
2016.12.09 09:36:01.456 2: ZWDongle_ProcessSendStack: no ACK, resending message 01090013140231042526c5
2016.12.09 09:36:01.457 5: SW: 01090013140231042526c5
2016.12.09 09:36:02.459 2: ZWDongle_ProcessSendStack: no ACK, resending message 01090013140231042526c5
2016.12.09 09:36:02.460 5: SW: 01090013140231042526c5
2016.12.09 09:36:03.463 2: ZWDongle_ProcessSendStack: no ACK, resending message 01090013140231042526c5
2016.12.09 09:36:03.463 5: SW: 01090013140231042526c5
2016.12.09 09:36:04.466 2: ZWDongle_ProcessSendStack: no ACK, resending message 01090013140231042526c5
2016.12.09 09:36:04.466 1: ERROR: max send retries reached, removing 01090013140231042526c5 from dongle sendstack
2016.12.09 09:36:04.467 5: SW: 01090013140226022527d5
2016.12.09 09:36:05.049 5: ACK received, WaitForAck=>2 for 01090013140226022527d5
2016.12.09 09:36:05.051 4: ZWDongle_Read ZWAVE1: rcvd 011300 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:36:05.051 5: SW: 06
2016.12.09 09:36:05.054 5: ZWAVE1: dispatch 011300
2016.12.09 09:36:05.057 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
2016.12.09 09:36:05.059 4: ZWDongle_Read ZWAVE1: CAN received
2016.12.09 09:36:05.059 4: ZWDongle_Read ZWAVE1: CAN received
2016.12.09 09:36:06.042 4: ZWDongle_Read ZWAVE1: rcvd 011300 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:36:06.042 5: SW: 06
2016.12.09 09:36:06.045 5: ZWAVE1: dispatch 011300
2016.12.09 09:36:06.048 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
2016.12.09 09:36:06.050 4: ZWDongle_Read ZWAVE1: rcvd 0004001403260306 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:06.051 5: SW: 06
2016.12.09 09:36:06.053 5: ZWAVE1: dispatch 0004001403260306
2016.12.09 09:36:06.054 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:03260306 CB:00
2016.12.09 09:36:06.114 4: no response from device, removing 01090013140226022527d5 from dongle sendstack
2016.12.09 09:36:06.115 5: SW: 010a001314034302012528bc
2016.12.09 09:36:06.118 5: ACK received, WaitForAck=>2 for 010a001314034302012528bc
2016.12.09 09:36:06.121 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:36:06.122 5: SW: 06
2016.12.09 09:36:06.124 5: ZWAVE1: dispatch 011301
2016.12.09 09:36:06.470 4: ZWDongle_Read ZWAVE1: rcvd 0004001403260306 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:06.470 5: SW: 06
2016.12.09 09:36:06.472 5: ZWAVE1: dispatch 0004001403260306
2016.12.09 09:36:06.473 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:03260306 CB:00
2016.12.09 09:36:06.548 4: ZWDongle_Read ZWAVE1: rcvd 00040014064303012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:06.548 5: SW: 06
2016.12.09 09:36:06.550 5: ZWAVE1: dispatch 00040014064303012200c3
2016.12.09 09:36:06.551 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:064303012200c3 CB:00
2016.12.09 09:36:06.620 4: ZWDongle_Read ZWAVE1: rcvd 00040014063105012200cd (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:06.620 5: SW: 06
2016.12.09 09:36:06.622 5: ZWAVE1: dispatch 00040014063105012200cd
2016.12.09 09:36:06.622 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:063105012200cd CB:00
2016.12.09 09:36:06.688 4: ZWDongle_Read ZWAVE1: rcvd 0004001403260306 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:06.689 5: SW: 06
2016.12.09 09:36:06.690 5: ZWAVE1: dispatch 0004001403260306
2016.12.09 09:36:06.691 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:03260306 CB:00
2016.12.09 09:36:06.823 4: ZWDongle_Read ZWAVE1: rcvd 001328000047 (request ZW_SEND_DATA), sending ACK
2016.12.09 09:36:06.823 5: SW: 06
2016.12.09 09:36:06.825 5: device ack reveived, removing 010a001314034302012528bc from dongle sendstack
2016.12.09 09:36:06.825 5: ZWAVE1: dispatch 001328000047
2016.12.09 09:36:06.826 4: CMD:ZW_SEND_DATA ID:00 ARG:0047 CB:28
2016.12.09 09:36:06.826 4: ZWAVE1 transmit OK for CB 28, target E4.az.HR.Heizung
2016.12.09 09:36:06.828 5: ZWDongle_Write 001314034302012528 (d14c12e6)
2016.12.09 09:36:06.829 5: SW: 010a001314034302012528bc
2016.12.09 09:36:06.832 5: ACK received, WaitForAck=>2 for 010a001314034302012528bc
2016.12.09 09:36:06.835 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.09 09:36:06.836 5: SW: 06
2016.12.09 09:36:06.838 5: ZWAVE1: dispatch 011301
2016.12.09 09:36:07.560 4: ZWDongle_Read ZWAVE1: rcvd 00041014064303012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:07.563 5: SW: 06
2016.12.09 09:36:07.565 5: ZWAVE1: dispatch 00041014064303012200c3
2016.12.09 09:36:07.566 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:064303012200c3 CB:10
2016.12.09 09:36:07.621 4: ZWDongle_Read ZWAVE1: rcvd 00132800004e (request ZW_SEND_DATA), sending ACK
2016.12.09 09:36:07.621 5: SW: 06
2016.12.09 09:36:07.623 5: device ack reveived, removing 010a001314034302012528bc from dongle sendstack
2016.12.09 09:36:07.624 5: ZWAVE1: dispatch 00132800004e
2016.12.09 09:36:07.625 4: CMD:ZW_SEND_DATA ID:00 ARG:004e CB:28
2016.12.09 09:36:07.625 4: ZWAVE1 transmit OK for CB 28, target E4.az.HR.Heizung
2016.12.09 09:36:07.668 4: ZWDongle_Read ZWAVE1: rcvd 00040014064303012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:07.668 5: SW: 06
2016.12.09 09:36:07.670 5: ZWAVE1: dispatch 00040014064303012200c3
2016.12.09 09:36:07.671 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:064303012200c3 CB:00
2016.12.09 09:36:07.961 4: ZWDongle_Read ZWAVE1: rcvd 00041014064303012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:07.962 5: SW: 06
2016.12.09 09:36:07.964 5: ZWAVE1: dispatch 00041014064303012200c3
2016.12.09 09:36:07.964 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:064303012200c3 CB:10
2016.12.09 09:36:08.061 4: ZWDongle_Read ZWAVE1: rcvd 00041014064303012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:08.062 5: SW: 06
2016.12.09 09:36:08.064 5: ZWAVE1: dispatch 00041014064303012200c3
2016.12.09 09:36:08.064 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:064303012200c3 CB:10
2016.12.09 09:36:08.463 4: ZWDongle_Read ZWAVE1: rcvd 00041014064303012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:08.464 5: SW: 06
2016.12.09 09:36:08.466 5: ZWAVE1: dispatch 00041014064303012200c3
2016.12.09 09:36:08.466 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:064303012200c3 CB:10
2016.12.09 09:36:08.751 4: ZWDongle_Read ZWAVE1: rcvd 00041014064303012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:08.752 5: SW: 06
2016.12.09 09:36:08.754 5: ZWAVE1: dispatch 00041014064303012200c3
2016.12.09 09:36:08.754 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:064303012200c3 CB:10
2016.12.09 09:36:08.867 4: ZWDongle_Read ZWAVE1: rcvd 00041014064303012200c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:08.868 5: SW: 06
2016.12.09 09:36:08.870 5: ZWAVE1: dispatch 00041014064303012200c3
2016.12.09 09:36:08.870 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:064303012200c3 CB:10
2016.12.09 09:36:09.181 4: ZWDongle_Read ZWAVE1: rcvd 0013280100ea (request ZW_SEND_DATA), sending ACK
2016.12.09 09:36:09.182 5: SW: 06
2016.12.09 09:36:09.184 5: ZWAVE1: dispatch 0013280100ea
2016.12.09 09:36:09.185 4: CMD:ZW_SEND_DATA ID:01 ARG:00ea CB:28
2016.12.09 09:36:09.185 2: ZWAVE1 transmit NO_ACK for CB 28, target E4.az.HR.Heizung
2016.12.09 09:36:30.596 4: ZWDongle_Read ZWAVE1: rcvd 00040006063105012200d6 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 09:36:30.596 5: SW: 06
2016.12.09 09:36:30.598 5: ZWAVE1: dispatch 00040006063105012200d6
2016.12.09 09:36:30.599 4: CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:063105012200d6 CB:00
List device:
Internals:
DEF d14c12e6 20
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 22
NAME E4.az.HR.Heizung
NR 91
STATE <strong>Ist-Temperatur: </strong>20.5 °C<strong> / Soll-Temperatur: </strong>19.5 °C</br><strong>Ventil: </strong>6 %
TYPE ZWave
ZWAVE1_MSGCNT 22
ZWAVE1_RAWMSG 0013280100ea
ZWAVE1_TIME 2016-12-09 09:36:09
ZWaveSubDevice no
homeId d14c12e6
isWakeUp 1
lastMsgSent 1481272566.82839
nodeIdHex 14
Readings:
2016-12-09 09:36:06 ActValve 6
2016-10-22 20:40:31 CMD ZW_APPLICATION_UPDATE
2016-12-09 09:36:06 IstTemp 20.5
2016-12-09 09:36:06 SEND_DATA failed:00
2016-12-09 09:36:08 SollTemp 19.5
2016-12-09 07:18:52 UNPARSED SENSOR_MULTILEVEL 023105
2016-12-06 13:16:22 WunschTemp 00
2016-12-09 04:47:14 battery 100 %
2016-10-22 12:27:27 model EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
2016-10-22 12:27:27 modelConfig eurotronic/eur_cometz.xml
2016-10-22 12:27:27 modelId 0148-0002-0001
2016-11-30 19:21:42 neighborList E4.az.ZS.Stereoanlage
2016-11-30 19:16:22 neighborUpdate done
2016-12-09 09:36:06 reportedState dim 6
2016-12-09 09:36:08 setpointTemp 19.5 C heating
2016-12-09 09:36:06 state dim 6
2016-12-09 09:36:06 temperature 20.5 C
2016-11-10 19:30:24 thermostatMode heating
2016-12-09 09:36:07 timeToAck 0.800
2016-12-09 09:36:09 transmit NO_ACK
2016-12-09 09:35:53 wakeup notification
2016-11-04 19:58:24 wakeupReport interval 900 target 1
SendStack:
sentackget:1314034302012528
Attributes:
IODev ZWAVE1
alias Arbeitszimmer
classes BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
group Heizung
icon sani_heating
room Übersicht
sortby 1
stateFormat {"<strong>Ist-Temperatur: </strong>".ReadingsVal('E4.az.HR.Heizung','IstTemp','')." °C<strong> / Soll-Temperatur: </strong>".ReadingsVal('E4.az.HR.Heizung','SollTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('E4.az.HR.Heizung','ActValve','')." %"}
userReadings IstTemp:temperature.* { my @a = split(" ",ReadingsVal("E4.az.HR.Heizung","temperature",0));; $a[0] }, SollTemp:setpointTemp.* { my @a = split(" ",ReadingsVal("E4.az.HR.Heizung","setpointTemp",0));; $a[0] }, ActValve:reportedState.* { if (ReadingsVal("E4.az.HR.Heizung","reportedState",0) eq "off") { "0" } else { my @a = split (" ", ReadingsVal("E4.az.HR.Heizung","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
verbose 5
webCmd ::
Beste Grüße
Torsten
Stella-Z wiederholt die WUN vermutlich mehrfach, da es ACK des Controllers nicht empfangen hat. Gleiches Spiel gibt es wohl auch bei der ersten "get E4.az.HR.Heizung smStatus"-Abfrage: Antwort von Stella-Z trifft mehrfach ein. Das Chaos steigert sich bis zum Ausstieg im ERROR.
Eigentlich dürfte wohl zur Verhinderung des Problems der Befehl
2016.12.09 09:35:53.093 5: SW: 01090013140226022521d3
nicht an den Controller geschickt werden, bevor die Antwort auf den letzten Befehl "get E4.az.HR.Heizung smStatus" beim Controller angekommen ist.
Ich würde es bei seltenem Auftreten so akzeptieren, wenn es zu keinen funktionalen Einschränkungen führt.
Erstmal vielen Dank für die Analyse. Das Spiel geht heute den ganzen Tag so weiter...
2016.12.09 19:54:21.094 3: ZS.zs.HR.wakeUpAll.nfy: E4.az.HR.Heizung wakeup: notification
2016.12.09 19:54:21.250 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 19:54:21.254 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 19:54:21.258 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 19:54:21.409 3: ZS.zs.HR.wakeUpAll.nfy: E4.az.HR.Heizung wakeup: notification
2016.12.09 19:54:21.565 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 19:54:21.569 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 19:54:21.573 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 19:54:22.569 3: ZS.zs.HR.wakeUpAll.nfy: E4.az.HR.Heizung wakeup: notification
2016.12.09 19:54:22.725 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 19:54:22.729 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 19:54:22.733 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 19:54:22.803 3: ZS.zs.HR.wakeUpAll.nfy: E4.az.HR.Heizung wakeup: notification
2016.12.09 19:54:22.959 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 19:54:22.963 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 19:54:22.967 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 19:54:23.001 3: ZS.zs.HR.wakeUpAll.nfy: E4.az.HR.Heizung wakeup: notification
2016.12.09 19:54:23.157 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 19:54:23.161 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 19:54:23.165 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 19:54:26.903 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
2016.12.09 19:54:28.909 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
Funktional sehe ich schon ein Problem, da ja der sendstack nicht mehr sauber abgearbeitet wird und somit auch set Befehle nicht mehr oder nach Stunden erst beim Regler ankommen. So ist im Moment der sendstack aus...
Internals:
DEF d14c12e6 20
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 196
NAME E4.az.HR.Heizung
NR 91
STATE <strong>Ist-Temperatur: </strong>20.5 °C<strong> / Soll-Temperatur: </strong>19.5 °C</br><strong>Ventil: </strong>6 %
TYPE ZWave
ZWAVE1_MSGCNT 196
ZWAVE1_RAWMSG 00041014028407
ZWAVE1_TIME 2016-12-09 19:54:22
ZWaveSubDevice no
homeId d14c12e6
isWakeUp 1
lastMsgSent 1481309662.97947
nodeIdHex 14
CHANGED:
SEND_DATA: failed:00
SEND_DATA: failed:00
Readings:
2016-12-09 19:23:56 ActValve 6
2016-10-22 20:40:31 CMD ZW_APPLICATION_UPDATE
2016-12-09 19:39:16 IstTemp 20.5
2016-12-09 19:54:28 SEND_DATA failed:00
2016-12-09 19:39:17 SollTemp 19.5
2016-12-09 19:23:44 UNPARSED SWITCH_MULTILEVEL 022603
2016-12-06 13:16:22 WunschTemp 00
2016-12-09 12:52:09 battery 100 %
2016-10-22 12:27:27 model EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
2016-10-22 12:27:27 modelConfig eurotronic/eur_cometz.xml
2016-10-22 12:27:27 modelId 0148-0002-0001
2016-12-09 12:50:25 neighborList E4.az.ZS.Stereoanlage
2016-12-09 12:48:42 neighborUpdate done
2016-12-09 19:23:56 reportedState dim 6
2016-12-09 19:39:17 setpointTemp 19.5 C heating
2016-12-09 19:23:56 state dim 6
2016-12-09 19:39:16 temperature 20.5 C
2016-11-10 19:30:24 thermostatMode heating
2016-12-09 16:06:47 timeToAck 0.052
2016-12-09 18:38:29 transmit NO_ACK
2016-12-09 19:54:22 wakeup notification
2016-11-04 19:58:24 wakeupReport interval 900 target 1
SendStack:
get:131403430201256b
get:1314023104256c
get:1314022602256d
get:131403430201256e
get:1314023104258a
get:1314022602258b
get:131403430201258c
get:1314023104258d
get:1314022602258e
get:131403430201258f
get:13140231042590
get:13140226022591
get:1314034302012592
get:13140231042593
get:13140226022594
get:1314034302012595
get:131402310425af
get:131402260225b0
get:13140343020125b1
get:131402310425b2
get:131402260225b3
get:13140343020125b4
get:131402310425b5
get:131402260225b6
get:13140343020125b7
get:131402310425d5
get:131402260225d6
get:13140343020125d7
get:131402310425d8
get:131402260225d9
get:13140343020125da
get:131402310425db
get:131402260225dc
get:13140343020125dd
get:131402310425f9
get:131402260225fa
get:13140343020125fb
get:1314023104251b
get:1314022602251c
get:131403430201251d
get:13140231042537
get:13140226022538
get:1314034302012539
get:1314023104253a
get:1314022602253b
get:131403430201253c
get:1314023104253d
get:1314022602253e
get:131403430201253f
get:13140231042540
get:13140226022541
get:1314034302012542
get:1314023104255a
get:1314022602255b
get:131403430201255c
get:1314023104255d
get:1314022602255e
get:131403430201255f
get:13140231042560
get:13140226022561
get:1314034302012562
get:13140231042583
get:13140226022584
get:1314034302012585
get:13140231042586
get:13140226022587
get:1314034302012588
get:131402310425af
get:131402260225b0
get:13140343020125b1
get:131402310425cb
get:131402260225cc
get:13140343020125cd
get:131402310425ce
get:131402260225cf
get:13140343020125d0
get:131402310425d1
get:131402260225d2
get:13140343020125d3
get:131402310425d4
get:131402260225d5
get:13140343020125d6
get:131402310425d7
get:131402260225d8
get:13140343020125d9
Attributes:
IODev ZWAVE1
alias Arbeitszimmer
classes BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
group Heizung
icon sani_heating
room Übersicht
sortby 1
stateFormat {"<strong>Ist-Temperatur: </strong>".ReadingsVal('E4.az.HR.Heizung','IstTemp','')." °C<strong> / Soll-Temperatur: </strong>".ReadingsVal('E4.az.HR.Heizung','SollTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('E4.az.HR.Heizung','ActValve','')." %"}
userReadings IstTemp:temperature.* { my @a = split(" ",ReadingsVal("E4.az.HR.Heizung","temperature",0));; $a[0] }, SollTemp:setpointTemp.* { my @a = split(" ",ReadingsVal("E4.az.HR.Heizung","setpointTemp",0));; $a[0] }, ActValve:reportedState.* { if (ReadingsVal("E4.az.HR.Heizung","reportedState",0) eq "off") { "0" } else { my @a = split (" ", ReadingsVal("E4.az.HR.Heizung","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
verbose 5
webCmd ::
Ich kann es jetzt gerne mal mit 3 einzelnen notifys probieren oder welche Möglichkeiten habe ich noch?
Gruß
Torsten
Bitte starte FHEM neu, damit der wakeup-Sendstack geleert wird.
ZitatIch kann es jetzt gerne mal mit 3 einzelnen notifys probieren
Probiere es einmal aus. Aber komplett wird es das Problem vermutlich nicht beheben, wenn 3 WUN oder 3 Antworten auf gleiche Abfragen kommen.
Zitatoder welche Möglichkeiten habe ich noch?
Mir faellt dazu nichts wirklich Sinnvolles ein, was ohne Veraenderung an den ZWave-Modulen funktionieren kann.
So nun das Ergebnis mit 3 einzelnen notifys nach einem Neustart von fhem und leerem sendstack. Leider auch nicht wirklich besser...
2016.12.09 20:39:46.641 3: E4.az.HR.1.nfy smStatus: E4.az.HR.Heizung wakeup: notification
2016.12.09 20:39:46.645 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 20:39:46.647 5: ZWDongle_Write 0013140231042514 (d14c12e6)
2016.12.09 20:39:46.648 5: SW: 01090013140231042514f7
2016.12.09 20:39:46.652 3: E4.az.HR.2.nfy swmStatus: E4.az.HR.Heizung wakeup: notification
2016.12.09 20:39:46.656 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 20:39:46.659 3: E4.az.HR.3.nfy setpoint: E4.az.HR.Heizung wakeup: notification
2016.12.09 20:39:46.663 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 20:39:46.685 5: ACK received, WaitForAck=>2 for 01090013140231042514f7
2016.12.09 20:39:46.686 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.09 20:39:46.686 5: SW: 06
2016.12.09 20:39:46.688 5: ZWAVE1: dispatch 011301
2016.12.09 20:39:48.694 4: no response from device, removing 01090013140231042514f7 from dongle sendstack
2016.12.09 20:39:49.929 4: ZWDongle_Read ZWAVE1: rcvd 00041014028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 20:39:49.930 5: SW: 06
2016.12.09 20:39:49.932 5: ZWAVE1: dispatch 00041014028407
2016.12.09 20:39:49.933 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:028407 CB:10
2016.12.09 20:39:49.934 5: ZWDongle_Write 0013140226022515 (d14c12e6)
2016.12.09 20:39:49.935 5: SW: 01090013140226022515e7
2016.12.09 20:39:49.970 3: E4.az.HR.1.nfy smStatus: E4.az.HR.Heizung wakeup: notification
2016.12.09 20:39:49.973 3: ZWave get E4.az.HR.Heizung smStatus
2016.12.09 20:39:49.977 3: E4.az.HR.2.nfy swmStatus: E4.az.HR.Heizung wakeup: notification
2016.12.09 20:39:49.980 3: ZWave get E4.az.HR.Heizung swmStatus
2016.12.09 20:39:49.983 3: E4.az.HR.3.nfy setpoint: E4.az.HR.Heizung wakeup: notification
2016.12.09 20:39:49.987 3: ZWave get E4.az.HR.Heizung setpoint
2016.12.09 20:39:50.008 5: ACK received, WaitForAck=>2 for 01090013140226022515e7
2016.12.09 20:39:50.008 4: ZWDongle_Read ZWAVE1: rcvd 011300 (answer ZW_SEND_DATA), sending ACK
2016.12.09 20:39:50.009 5: SW: 06
2016.12.09 20:39:50.011 5: ZWAVE1: dispatch 011300
2016.12.09 20:39:50.013 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
2016.12.09 20:39:52.016 4: no response from device, removing 01090013140226022515e7 from dongle sendstack
2016.12.09 20:40:00.063 4: ZWDongle_Read ZWAVE1: rcvd 0013150103f4 (request ZW_SEND_DATA), sending ACK
2016.12.09 20:40:00.064 5: SW: 06
2016.12.09 20:40:00.066 5: ZWAVE1: dispatch 0013150103f4
2016.12.09 20:40:00.067 4: CMD:ZW_SEND_DATA ID:01 ARG:03f4 CB:15
2016.12.09 20:40:00.068 2: ZWAVE1 transmit NO_ACK for CB 15, target E4.az.HR.Heizung
2016.12.09 20:40:32.753 4: ZWDongle_Read ZWAVE1: rcvd 0004001e028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.09 20:40:32.754 5: SW: 06
2016.12.09 20:40:32.757 5: ZWAVE1: dispatch 0004001e028407
2016.12.09 20:40:32.758 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:028407 CB:00
2016.12.09 20:40:32.782 3: ZS.zs.HR.wakeUpAll.nfy: EG.fl.HR.Wandheizung wakeup: notification
Und auf dem sendstack sammeln sich wieder die gets:
Internals:
DEF d14c12e6 20
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 3
NAME E4.az.HR.Heizung
NR 91
STATE <strong>Ist-Temperatur: </strong>20.5 °C<strong> / Soll-Temperatur: </strong>19.5 °C</br><strong>Ventil: </strong>6 %
TYPE ZWave
ZWAVE1_MSGCNT 3
ZWAVE1_RAWMSG 0013150103f4
ZWAVE1_TIME 2016-12-09 20:40:00
ZWaveSubDevice no
homeId d14c12e6
isWakeUp 1
lastMsgSent 1481312389.9346
nodeIdHex 14
Readings:
2016-12-09 19:23:56 ActValve 6
2016-10-22 20:40:31 CMD ZW_APPLICATION_UPDATE
2016-12-09 20:09:27 IstTemp 20.5
2016-12-09 20:39:50 SEND_DATA failed:00
2016-12-09 19:39:17 SollTemp 19.5
2016-12-09 19:23:44 UNPARSED SWITCH_MULTILEVEL 022603
2016-12-06 13:16:22 WunschTemp 00
2016-12-09 12:52:09 battery 100 %
2016-10-22 12:27:27 model EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
2016-10-22 12:27:27 modelConfig eurotronic/eur_cometz.xml
2016-10-22 12:27:27 modelId 0148-0002-0001
2016-12-09 12:50:25 neighborList E4.az.ZS.Stereoanlage
2016-12-09 12:48:42 neighborUpdate done
2016-12-09 19:23:56 reportedState dim 6
2016-12-09 19:39:17 setpointTemp 19.5 C heating
2016-12-09 19:23:56 state dim 6
2016-12-09 20:09:27 temperature 20.5 C
2016-11-10 19:30:24 thermostatMode heating
2016-12-09 16:06:47 timeToAck 0.052
2016-12-09 20:40:00 transmit NO_ACK
2016-12-09 20:39:49 wakeup notification
2016-11-04 19:58:24 wakeupReport interval 900 target 1
SendStack:
get:13140226022515
get:1314034302012516
get:13140231042517
get:13140226022518
get:1314034302012519
Attributes:
IODev ZWAVE1
alias Arbeitszimmer
classes BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
group Heizung
icon sani_heating
room Übersicht
sortby 1
stateFormat {"<strong>Ist-Temperatur: </strong>".ReadingsVal('E4.az.HR.Heizung','IstTemp','')." °C<strong> / Soll-Temperatur: </strong>".ReadingsVal('E4.az.HR.Heizung','SollTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('E4.az.HR.Heizung','ActValve','')." %"}
userReadings IstTemp:temperature.* { my @a = split(" ",ReadingsVal("E4.az.HR.Heizung","temperature",0));; $a[0] }, SollTemp:setpointTemp.* { my @a = split(" ",ReadingsVal("E4.az.HR.Heizung","setpointTemp",0));; $a[0] }, ActValve:reportedState.* { if (ReadingsVal("E4.az.HR.Heizung","reportedState",0) eq "off") { "0" } else { my @a = split (" ", ReadingsVal("E4.az.HR.Heizung","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
verbose 5
webCmd ::
Kann es sein, dass der Regler defekt ist oder doch mein zwave-Netzwerk spinnt? Wenn es natürlich eine Möglichkeit gäbe das "Chaos" in den z-wave Modulen abzufangen, wäre das genial.
Beste Grüße
Torsten
Die notify triggern aber alle auf WUN, oder?
Ich meinte aber: 1. auf WUN, 2. auf Ergebnis von 1. und 3. auf Ergebnis vom 2.
ZitatKann es sein, dass der Regler defekt ist oder doch mein zwave-Netzwerk spinnt?
Ja. Mich wundern die mehrfachen WUN oder hast Du das so kurz eingestellt?
Tritt das nur bei dem einen Regler auf?
Wie sieht die Route zum Controller aus?
Achso, das werde ich gleich mal noch umstellen.
Das Wakeupintervall steht auf 15 Minuten. Die Route zum Controller läuft über eine Funksteckdose, die wiederum über eine andere Funksteckdose mit dem Controller kommuniziert. Das mit den mehrfachen wakeups passiert nur bei diesem Regler. Bei anderen kommt es sporadisch zu den NO_ACK Meldungen und falls dabei mal was auf dem sendstack hängen bleibt, dann reguliert sich das nach kurzer Zeit wieder.
Macht es Sinn mit dem WNMI_Delay zu experimentieren? Wenn ja, mit welchem Wert?
Gruß
Torsten
ZitatDas Wakeupintervall steht auf 15 Minuten. Die Route zum Controller läuft über eine Funksteckdose, die wiederum über eine andere Funksteckdose mit dem Controller kommuniziert. Das mit den mehrfachen wakeups passiert nur bei diesem Regler. Bei anderen kommt es sporadisch zu den NO_ACK Meldungen und falls dabei mal was auf dem sendstack hängen bleibt, dann reguliert sich das nach kurzer Zeit wieder.
Dann tippe ich auf Defekt oder nicht optimale Funkverbindung.
ZitatMacht es Sinn mit dem WNMI_Delay zu experimentieren? Wenn ja, mit welchem Wert?
Da kann ich bei dem merkwürdigen Regler keinen Zusammenhang erkennen.
Bei den anderen könnten NO_ACK minimiert werden, wenn die zu schnell schlafen gehen. 1s sollte ungefaehrlich sein.
Wie Du merkst, ist das alles leider sehr viel Raterei...
So seit 1,5 h ist Ruhe im Log!!!!
Ich habe die 3 einzelnen notifys für den störrischen Regler so wie von Dir vorgeschlagen eingerichtet und seither ist kein Fehler mehr aufgetreten. Für die anderen Regler läuft weiterhin das notify, das alle 3 Werte abfrägt. Ich beobachte das Log mal weiter und falls bei den anderen auch wieder Fehler auftreten, baue ich das generelle notify auf 3 Stück um.
Vielen Dank für Deine Unterstützung und den Tipp!
(Verstehen muss ich das jetzt aber nicht... wäre aber trotzdem beruhigter, wenn das alles etwas stabiler laufen würde)
Gruß
Torsten
Wenn aufgrund von Netzstörungen der hier festgestellte https://forum.fhem.de/index.php/topic,65055.msg568121.html#msg568121 bzw. hier bereits befürchtete
Zitat von: krikan am 09 Dezember 2016, 20:19:54
Probiere es einmal aus. Aber komplett wird es das Problem vermutlich nicht beheben, wenn 3 WUN oder 3 Antworten auf gleiche Abfragen kommen.
Effekt durch mehrfache Antworten auf Protokollebene eintritt, faellt mir als Notbehelf bei weiterhin bestehenden Poll-Wunsch nur die Verhinderung der mehrfachen Ablage des gleichen Befehls im Sendstack ein. (Duplikatserkennung)
Also vor Ablage eines get-Befehls im Sendstack prüfen, ob der gleiche Befehl nicht schon im Sendstack liegt.
-> ja, get-Befehl nicht ablegen
-> nein, get-Befehl ablegen
Betone, dass das auch wieder nur ein dummes Hilfskonstrukt für dieses "kaputte" Geraet/Netz ist.
Oder Du gehst auf ein at mit dem alle Befehle regelmaeßig in den Sendstack gelegt werden, statt notify. Aber auch das wird vermutlich nicht die Lösung bringen, da die Kommunikation mit den Geraeten sehr fragil zu sein scheint.
Gruß, Christian
Ich habe das Thema nochmal durchgelesen, und versuche den Stand (auch aus den anderen Themen) zusammenzufassen:
- In diesem Netz gibt es mehrere Heizungsregler (9+ Stueck), die alle 15 Minuten 3 Werte melden sollen. Das sind mit der aktuellen Implementation unter idealen Verbindungen+Funkverhaeltnisse 9*(WUN+3*(get+Antwort))*2 = 126 Nachrichten, grob 8 pro Minute.
- Einer der Regler macht (mehr?) Probleme, er sollte ueber 2 Steckdosen geroutet sein.
- Falls eine Nachricht ueber mehrere Router geschickt wird, dann gibt es bei jeden Hop ein Ack an den Vorherigen+1 "Overall-Ack". D.h. eine Nachricht ueber 2 Hops bedeutet 3*2+1=7 Funktelegramme. Das koennte man (nur?) mit einem ZWCUL verifizieren, ich habe das aber bei mir so schon gesehen.
- In diesem Netz gehen Acks in beide Richtungen verloren, was zu Wiederholen der Meldungen fuehrt.
- Wenn an dem WUN FHEM-Notifies haengen, die ihrerseits 3 Werte abfragen, fuehrt das bestenfalls zu: 1*WUN => 3*Get => 3*Antwort => 7*7=49 Funknachrichten, schlimmstenfalls zu 3*WUN => 9*Get => 27*Antwort => 39*7=283 Funknachrichten.
- notify jeweils an dem naechsten Antwort zu koppeln scheint das Problem zu entschaerfen, was ich nicht erklaeren kann.
-> Ich wundere mich nicht, dass diese Kommunikation (Geraet ueber 2 Hops regelmaessig abzufragen) problematisch ist.
Loesungsansaetze:
- Organisatorisch: Geraet nicht abfragen :)
- Hardware:
- ein RPi+ZWDongle per LAN in der Naehe des Reglers platzieren, und es via socat an FHEM anbinden.
- bessere (nicht mehr!) Repeater verwenden.
- Software:
- WUN ignorieren, falls das Geraet intern als "wach" gekennzeichnet ist
- Antworten auf nicht ausstehende gets ignorieren. Eine Antwort kann man von einer spontenen Nachricht anhand der CallbackId unterscheiden.
- mehrere gets auf dem Sendstack zu einem MULTI_CMD zusammenfassen.
@Christian: siehst du ein Problem mit den Software-Ansaetzen?
Zitatsiehst du ein Problem mit den Software-Ansaetzen?
Nein. Wenn sich jemand findet, der das in ZWave/ZWDongle einbaut, wäre das wohl die optimale Lösung für solche Störungen. ;)
Insbesondere 2. und 3. sind mMn gefahrlos.
Bei 1. habe ich noch ein unbestimmtes Störgefühl.
Bei 2. aber bitte mit Angabe in Reading(?), dass Duplikate aussortiert wurden, um Analyse zu erleichtern und nicht "Kaputtes" durch FHEM zu verschleiern.
Zitat von: krikan am 24 Januar 2017, 10:31:01
Bei 1. habe ich noch ein unbestimmtes Störgefühl.
Wenn eine erneute WUN bei einem als "wach" markiertem Gerät zur Verlängerung des Wachzeitraums führt, aber nicht zu einem Event, halte ich es für OK. Wobei die "Duplikatserkennung" mMn zeitlich begrenzt sein sollte.
Ich versteh noch nicht dein Bauchgefuehl bei 1. Hast du sowas schon beobachtet oder darueber gelesen?
Will alle 3 Optionen erstmal per Attribut aktivierbar machen, faellt mir nur kein Name ein.
Zitat von: rudolfkoenig am 24 Januar 2017, 14:05:27
Ich versteh noch nicht dein Bauchgefuehl bei 1. Hast du sowas schon beobachtet oder darueber gelesen?
Kann mich nicht erinnern, darum unbestimmt. Mache es einfach; unbestimmte Gefühle gehören hier eigentlich nicht hin.
ZitatWill alle 3 Optionen erstmal per Attribut aktivierbar machen, faellt mir nur kein Name ein.
Aber hoffentlich 3 Stück oder zumindest für 3. ein separates!? Eines fände ich nicht ideal.
Hallo Ihr Beiden,
vielen Dank, dass Ihr Euch so sehr den Kopf wegen meines Problems zerbrecht und nach Lösungen sucht.
Zu den Lösungsansätzen, die ich selbst angehen kann:
- Gerät nicht abfragen, würde halt Blindflug bedeuten...
- Zweiter PI mit RazBerry steht hier rum. Hatte ja auf PI3 und RazBerry2 umgestellt mit der Hoffnung, der RazBerry2 hätte mehr Reichweite (kann ich aktuell nicht bestätigen). Bin aber am Überlegen, ob ich den zweiten PI nicht mit Homematic ausstatten soll, um damit mal Erfahrung bzgl. Reichweite zu sammeln.
- welche Repeater sind denn am besten?
Wäre es noch eine Idee, nach dem letzten notify/get den sendstack des entsprechenden Geräts über das letzte notify zu löschen? set Befehle sind ja von der Reihenfolge zuerst da, bevor die gets kommen (Ausnahme genau zwischen den gets kommt ein set, das nicht gleich verarbeitet wird und auf dem stack liegen bleibt/gelöscht wird).
Kann ich im notify selbst prüfen, ob ein get auf dem sendstack liegt? Eine list Funktion, die nur den sendstack anzeigt gibt es nicht oder?
Beste Grüße
Torsten
ZitatWenn eine erneute WUN bei einem als "wach" markiertem Gerät zur Verlängerung des Wachzeitraums führt, aber nicht zu einem Event, halte ich es für OK.
Mehrfache WUNs haben auch bisher nicht zu eine Verlaengerung gefuehrt. Das neue Attribut heisst ignoreDupMsg, ist per default aus, und implementiert #1und #2. Es wird auf loglevel 3 eine Meldung ausgegeben (Log3 $name, 3, "$name: ignore duplicate answer $event[0]" ;) falls was "verworfen" wird, bei WUN aehnlich. Eigentlich gehoert es per default aktiviert, aber erst nach ausgiebigen Tests. #3. ist aufwendiger, kommt spaeter.
@ToKa: Gedulde dich etwas. Bitte mit der neuen Version (morgen ab 8 per update, usw) das Attribut ignoreDupMsg fuer alle problematischen ZWave Geraete setzen (siehe auch devspec), und berichten. Sollte de-facto das Gleiche bewirken wie event-min-interval (was nicht mehr notwendig ist), mit dem Unterschied das readingsChange jetzt funktioniert :)
Zitat von: rudolfkoenig am 24 Januar 2017, 20:25:35
Mehrfache WUNs haben auch bisher nicht zu eine Verlaengerung gefuehrt.
Das stelle ich nicht in Abrede und ist für den Normalfall vollkommen ok.
Mein Gedankengang: bei WUN-Wiederholungen, die -wie oben im Log- noch 2 Sekunden spaeter (=Ende Wachphase) den Aktor beschaeftigen, haben die eigentlichen Abfragen keine Chance durchzukommen, wenn die Wachphase sich nicht verlaengert. Schauen wir, was die Praxis zeigt. :)
Hi Rudi,
den Teil des neuen Codes verstehe ich nicht...
if($hash->{ignoreDupMsg} && $callbackid ne "00") {
my $hp = hex($callbackid);
if($zwave_cbid2dev{$hp}) {
delete $zwave_cbid2dev{$hp};
} else {
Log3 $name, 3, "$name: ignore duplicate answer $event[0]";
return "";
}
}Das soll ja wohl diesen Teil hier implementieren:
Zitat- Antworten auf nicht ausstehende gets ignorieren. Eine Antwort kann man von einer spontenen Nachricht anhand der CallbackId unterscheiden.
1.) was versteckt sich eigentlich hinter "$zwave_cbid2dev{$hp}" und was macht dann das delete?
2.) der obere Teil wird ausgeführt wenn ignoreDupMsg gesetzt ist UND die CB nicht "00" ist, d.h. im Umkehrschluss wird der untere Teil mit dem "ignore" ausgeführt wenn
a.) ignoreDupMsg NICHT gesetzt ist ODER
b.) CB = "00" ist
Bei 2.) hätte ich die Logik genau anders herum erwartet...
Gruß,
Andreas.
Ich meine immer noch, dass es so richtig ist, und kurz getestet habe ich es auch.
1. in zwave_cbid2dev wird abgelegt, zu welchem Hash die letzte Callbackid gehoert. Wird geloescht, um zu zeigen, dass dafuer ein event generiert wurde. Ich gehe davon aus, dass auf eine Frage nicht mehrere Antwort-Telegramme mit gesetzten CB kommen koennen.
2. ich weiss nicht, was du mit "unteren" Teil meinst, ich sehe kein else fuer das aussere if.
Hi Rudi,
ok, mein Fehler, ich hatte das else tatsächlich dem äußeren if zugeordnet...
Gruß,
Andreas.
Hallo zusammen,
ich habe nach dem Update heute Abend für 3 meiner COMET Problemkinder das Attribut ignoreDupMsg gesetzt. Dies führt einerseits zu der entsprechenden Meldung "ignore duplicate answer", andererseits auch immer noch zu mehrfachen Einträgen in den Gerätelogs z.B. für temperature. Bei einem Gerät (E2.ez.HR.Heizung) sieht man um 20:33 Uhr ein mehrfaches WUN und dann keine weiteren Einträge im log, die get-Befehle sind wieder auf dem sendstack stehen geblieben (siehe list).
Für mich sieht das immer noch nach Chaos aus, aber ich hoffe, Euch sagt es mehr. Wenn Ihr verbose 5 logs benötigt, sagt Bescheid.
Beste Grüße
Torsten
Ja, ich fuerchte sowas brauche ich.
Ich habe jetzt eine Version mit dem neuen Attribut useMultiCmd eingecheckt:
ZitatExperimental: if a device supports MULTI_CMD and WAKE_UP, then pack
multiple get messages on the SendStack into a single MULTI_CMD to save
radio transmissions.
Hallo,
ist diese Änderung schon über das normale Update verfügbar? Wie erkenne ich, ob ein Gerät MULTI_CMD unterstützt? Sollen dann beide neuen Attribute gesetzt werden?
Für das Erstellen der log was wäre Dir da lieber
1. Drei getrennte notifys, die jeweils auf wakeup reagieren?
2. Drei getrennte notifys, die auf einander aufbauen, also jeweils auf das event des vorher abgefragen Werts reagieren?
3. Ein notify, in dem alle 3 Werte abgefragt werden?
Gruß
Torsten
update ist immer ein Tag verspaetet (warst nicht du, der die update-Doku lesen wollte?)
Sonst sind mir die notifies egal, Hauptsache ich sehe dein Problem.
Und bitte erst ohne das useMultiCmd Attribut, damit ich dein Problem fixen kann.
Das neue Attribut unterstuetzt Geraete, die im classes Attribut MULTI_CMD und WAKE_UP haben.
Nein, war ich nicht, aber danke für den Wink mit dem Zaunpfahl ;)
OK, dann werde ich morgen abend oder am WE testen. Die COMET haben kein MULTI_CMD.
Gruß
Torsten
Anbei eine Datei mit fhem log Auszügen (zwave dongle verbose 5) und den entsprechenden log Auszügen der Geräte bzw. für eines auch ein list, bei dem man wieder erkennt, dass Nachrichten auf dem sendstack hängen. In den aufgezeichneten Fällen sind wieder doppelte / mehrfache Einträge vom gleichen event / reading im Log, teilweise sind auch duplicate Meldungen im fhem log.
ignoreDupMsg ist bei allen Geräten gesetzt und aktuell wird ein notify mit 3 get Befehlen verwendet.
Ich hoffe, die logs reichen schon für eine weitere Anaylse.
Beste Grüße
Torsten
Ich habe useMultiCmd mit meinem ZWave.me KFOB getestet, es funktioniert: 3 gets wurden zu eine Funknachricht verpackt, worauf das kfob auch nur einmal geantwortet hat. FHEM packt die Antwort aus, und generiert 3 Events, fuer den Benutzer sollte sich also nichts aendern. Ich musste den Code leicht anpassen, damit auch die nicht per WUN-Notify, sondern die vorher, manuell ausgeloesten Gets zusammengepackt werden. Da noch keine Grenze eingebaut ist, kann das noch bei vielen gets zu einem Problem werden.
Ob das zusammenpacken aktiv ist sieht man in "list kfob": auf dem SendStack ist nur ein laengeres get: vorhanden.
Bemerkenswert: mit einer alten Batterie hat das KFOB zwar einzelne Knopfdruecke gemeldet, eine Antwort auf get kam nur sporadisch an, neu anlernen ging auch nur halb. get battery hat (wenn es geklappt hat) 60% gemeldet. Mit der neuen Batterie gibt es keine Probleme. Die alte CR2032 Batterie war 20 Monate alt, und ich verwende das KFOB nur zum Entwickeln, d.h. seltene, dann aber ueberdurchschnittliche Benutzung. Mit der alten Batterie hat das Druecken von #2 im Management Mode nur ein WUN gesendet, jetzt wird freiwillig 2xWUN + battery geschickt. ignoreDupMsg meldet jetzt brav "kfob: ignore duplicate WUN".
Merke: im Zweifel eine neue Batterie probieren.
@ToKa
- im ersten Abschnitt sieht man ein WUN vom ST.sz.HR.Heizung (0d), daraufhin ein generieren von 3* get, und Versenden des Ersten. Dann kommen noch 2 WUN (in 0.11s und 0.17s Abstand), die jeweils ignoriert werden. Mehr sehe ich nicht, vermutlich kommt auch nix, sonst wuerde dein SendStack anders aussehen.
- im Zweiten sendet E1.wz.HR.Heizung.Wand, da laufen die 3 gets durch, es wird ein duplicate setpointTemp anhand Callback-ID (CB:10) erkannt und ignoriert.
- im Dritten sendet E1.wz.HR.Heizung.Fenster, hier kommen mehrere setpointTemps, die nicht als Duplikate entdeckt werden, weil der Controller diese nicht mit dem gesendeten CB:02 versieht, sondern mit CB:00, als ob das Geraet was spontan gesendet haette. Ich meine das ist ein Controller-Bug, und fuehrt die Idee des Callback-IDs ad-absurdum. Wie man das abfaengt, weis ich im Moment noch nicht.
Controller-Bug im Gerät oder im RaZBerry2?
event-min-interval mit 60s hat ja eigentlich "geholfen", wenn das mit dem readingsChange nicht wäre. Könnte man nicht über ein weiteres Attribut was ähnliches einstellen?
Etwas versehe ich nicht, am nachfolgenden Beispiel. Im FHEM Log wurde protokolliert, dass doppelte Anworten zu setpointTemp ignoriert wurden, im List des Geräts sieht man dann, dass für setpointTemp aber gar kein aktueller Wert um 21:26:05 Uhr gespeichert wurde. Es stehen aber auch noch Befehle auf dem sendstack... u.a. mal wieder das "sentackget".
2017.01.29 21:26:05.215 3: ZWave get E2.ku.HR.Heizung smStatus
2017.01.29 21:26:05.220 3: ZWave get E2.ku.HR.Heizung setpoint
2017.01.29 21:26:05.222 3: ZWave get E2.ku.HR.Heizung swmStatus
2017.01.29 21:26:05.224 3: ZWave get E2.ku.HR.Heizung thermostatMode
2017.01.29 21:26:06.241 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating
2017.01.29 21:26:06.285 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating
2017.01.29 21:26:06.479 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating
2017.01.29 21:26:06.725 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating
2017.01.29 21:26:06.795 3: E2.ku.HR.Heizung: ignore duplicate answer setpointTemp:20.5 C heating
Internals:
DEF d14c12e6 31
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 69
NAME E2.ku.HR.Heizung
NR 132
STATE <strong>Ist: </strong>21.0 °C<strong> / Soll: </strong>20.5 °C</br><strong>Ventil: </strong>19 %
STILLDONETIME 0
TYPE ZWave
ZWAVE1_MSGCNT 69
ZWAVE1_RAWMSG 0004001f063105012200d2
ZWAVE1_TIME 2017-01-29 21:26:05
ZWaveSubDevice no
homeId d14c12e6
ignoreDupMsg 1
isWakeUp 1
lastMsgSent 1485721565.48161
nodeIdHex 1f
Helper:
Dblog:
Reportedstate:
Logdb:
TIME 1485720659.29974
VALUE 19
Setpointtemp:
Logdb:
TIME 1485720659.0075
VALUE 20.5
Temperature:
Logdb:
TIME 1485721565.52128
VALUE 21.0
Wakeup:
Logdb:
TIME 1485721565.22637
VALUE notification
Readings:
2017-01-29 13:37:02 SEND_DATA failed:00
2017-01-28 08:39:00 UNPARSED SENSOR_MULTILEVEL 023105
2017-01-28 04:52:20 battery 100 %
2017-01-17 07:57:20 desired-new 00
2017-01-29 08:00:00 desired-temp 20.5
2016-12-08 12:42:23 model EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
2016-12-08 12:42:23 modelConfig eurotronic/eur_cometz.xml
2016-12-08 12:42:23 modelId 0148-0002-0001
2017-01-29 14:53:09 neighborList EG.ga.SD.Glasbausteine E2.fl.SD.LEDLampe E2.ku.SD.Tischleuchte
2017-01-29 14:52:31 neighborUpdate done
2017-01-29 21:10:59 reportedState 19
2017-01-29 21:10:58 setpointTemp 20.5
2017-01-29 21:10:59 state dim 19
2017-01-29 21:26:05 temperature 21.0
2017-01-29 21:10:59 thermostatMode heating
2017-01-29 21:26:05 timeToAck 0.139
2017-01-29 21:26:05 transmit OK
2017-01-29 21:26:05 wakeup notification
SendStack:
sentackget:131f03430201258a
get:131f022602258b
get:131f024002258c
Attributes:
DbLogInclude desired-temp,temperature,setpointTemp,reportedState,thermostatMode,battery,wakeup
IODev ZWAVE1
alias Küche
classes BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
event-on-change-reading .*
event-on-update-reading wakeup,temperature,setpointTemp
group Heizung
icon sani_heating
ignoreDupMsg 1
room Übersicht
sortby 3
stateFormat {"<strong>Ist: </strong>".ReadingsVal('E2.ku.HR.Heizung','temperature','')." °C<strong> / Soll: </strong>".ReadingsVal('E2.ku.HR.Heizung','setpointTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('E2.ku.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
ZitatEtwas versehe ich nicht, am nachfolgenden Beispiel. Im FHEM Log wurde protokolliert, dass doppelte Anworten zu setpointTemp ignoriert wurden, im List des Geräts sieht man dann, dass für setpointTemp aber gar kein aktueller Wert um 21:26:05 Uhr gespeichert wurde. Es stehen aber auch noch Befehle auf dem sendstack... u.a. mal wieder das "sentackget".
Ohne "ZWDongle verbose 5" log kann ich nur raten: der Controller hat die Callbackids durcheinandergebracht. 5 setpointTemp Nachrichten ist Novum fuer mich: ich war bisher ueberzeugt, dass es hoechstens 3 werden koennen.
Eine Zeitstempelbasierte Pruefung analog zu event-* in ZWave Modul ist komplizierter/aufwendiger in der Wartung, und ich zoegere noch sie einzubauen. Sie wird benoetigt, wenn:
- Abfragen benoetigt werden
- die Verbindung sehr wackelig ist, und Acks verlorengehen
- der Controller weder Doppelte filtert, noch das richtige CallbackId dem Paket zuordnet.
Wenn jetzt wieder jemand behauptet, nur Protokolle mit ACK seien sinnvoll, den werde ich zum debuggen dieses Falls zwingen.
Ich schlage vor, auf event-* umzustellen und das etwas aufwendigere stateFormat zu verwenden. Oder noch besser: fuer eine fehlerfreie Funkstrecke durch Hardware zu sorgen.
Guten Abend,
ich würde ja gerne für eine fehlerfreie Funkstrecke sorgen, aber wie? Du hattest geschrieben: Nicht noch mehr Repeater , sondern bessere... aber welche sind besser? Ich habe schon auf einen RazBerry2 umgestellt, da der ja angeblich mehr Reichweite hat und nutze Fibaro und Greenwave als Zwischenstecker.
Kannst Du mir noch sagen, wie Du das mit dem Controller Bug gemeinst hast? Ich kann auch meinen alten RazBerry noch einmal ausprobieren. Falls der Bug in der COMET Z Hardware liegt, kann ich gerne mal Eurotronic kontaktieren. Ich habe hier auch noch einen COMET Z rumliegen, da ich bei einer Heizung gar keine Verbindung zum Server erhalte und ich nicht noch einen überflüssigen Zwischenstecker kaufen wollte. Den könnte ich Dir schicken, falls es Dir irgenwie helfen würde.
Ansonsten bleibt mir nur Deinen Vorschlag umzusetzen und wieder event-min... zu nutzen. Würde dann wohl entsprechende UserReadings verwenden, um die Werte zu formatieren. Oder spricht etwas gegen UserReadings?
Beste Grüße
Torsten
Bei Verbindungsprobemen versuche ich zuerst an der relativen Ausrichtung der Komponenten (bzw. deren Antennen) was zu aendern, oder eine bessere Antenne zu besorgen. Wobei laenger nicht besser, sondern staerker ausgerichtet ist.
Gegen UserReadings spricht nichts.
Ausrichten bei den Heizungsventilen wird etwas schwierig. Ob die im inneren eine Antenne habe, kann ich nicht sagen - habe noch keinen zerlegt.
Es geht übrigens noch "besser.".. gleich 3 duplicate WUN, 4 duplicate UNPARSED und 14 duplicate temperature Meldungen. Die UNPARSED Meldung wurde nicht ins reeading übernommen.
Die einzige Änderung, die ich gemacht habe, ist nur noch den Temperaturwert im notify abzufragen. Ich wollte wissen, ob die Anzahl der abgefragten Werte eine Rolle für das Verhalten spielt. Das scheint aber nicht der Fall zu sein. Physikalisch hat sich nichts geändert, außer dass hier 2 Personen und 2 Katzen durchs Haus laufen...
2017.01.30 19:51:07.991 3: ZWave get E2.ku.HR.Heizung smStatus
2017.01.30 19:51:08.633 3: E2.ku.HR.Heizung: ignore duplicate WUN
2017.01.30 19:51:08.706 3: E2.ku.HR.Heizung: ignore duplicate WUN
2017.01.30 19:51:08.907 3: E2.ku.HR.Heizung: ignore duplicate WUN
2017.01.30 19:51:09.333 3: E2.ku.HR.Heizung: ignore duplicate answer UNPARSED:SENSOR_MULTILEVEL 023105
2017.01.30 19:51:09.723 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:09.917 3: E2.ku.HR.Heizung: ignore duplicate answer UNPARSED:SENSOR_MULTILEVEL 023105
2017.01.30 19:51:09.992 3: E2.ku.HR.Heizung: ignore duplicate answer UNPARSED:SENSOR_MULTILEVEL 023105
2017.01.30 19:51:10.526 3: E2.ku.HR.Heizung: ignore duplicate answer UNPARSED:SENSOR_MULTILEVEL 023105
2017.01.30 19:51:10.754 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:10.897 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:10.940 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.024 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.162 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.325 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.390 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.520 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:11.660 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:12.154 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:12.429 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:12.495 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
2017.01.30 19:51:12.778 3: E2.ku.HR.Heizung: ignore duplicate answer temperature:21.0 C
Internals:
DEF d14c12e6 31
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 15
NAME E2.ku.HR.Heizung
NR 131
STATE <strong>Ist: </strong>21.0 °C<strong> / Soll: </strong>20.5 °C</br><strong>Ventil: </strong>13 %
STILLDONETIME 0
TYPE ZWave
ZWAVE1_MSGCNT 15
ZWAVE1_RAWMSG 0004001f063105012200d2
ZWAVE1_TIME 2017-01-30 19:51:09
ZWaveSubDevice no
homeId d14c12e6
ignoreDupMsg 1
isWakeUp 1
lastMsgSent 1485802269.99647
nodeIdHex 1f
Helper:
Dblog:
Reportedstate:
Logdb:
TIME 1485797737.27128
VALUE 13
Setpointtemp:
Logdb:
TIME 1485797736.99946
VALUE 20.5
Temperature:
Logdb:
TIME 1485802269.58896
VALUE 21.0
Wakeup:
Logdb:
TIME 1485802267.99618
VALUE notification
Readings:
2017-01-29 13:37:02 SEND_DATA failed:00
2017-01-30 06:15:07 UNPARSED SENSOR_MULTILEVEL 023105
2017-01-28 04:52:20 battery 100 %
2017-01-17 07:57:20 desired-new 00
2017-01-30 15:30:00 desired-temp 20.5
2016-12-08 12:42:23 model EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
2016-12-08 12:42:23 modelConfig eurotronic/eur_cometz.xml
2016-12-08 12:42:23 modelId 0148-0002-0001
2017-01-29 14:53:09 neighborList EG.ga.SD.Glasbausteine E2.fl.SD.LEDLampe E2.ku.SD.Tischleuchte
2017-01-29 14:52:31 neighborUpdate done
2017-01-30 18:35:37 reportedState 13
2017-01-30 18:35:36 setpointTemp 20.5
2017-01-30 18:35:37 state dim 13
2017-01-30 19:51:09 temperature 21.0
2017-01-30 18:35:37 thermostatMode heating
2017-01-30 19:51:10 timeToAck 0.577
2017-01-30 19:51:10 transmit OK
2017-01-30 19:51:07 wakeup notification
Attributes:
DbLogInclude desired-temp,temperature,setpointTemp,reportedState,thermostatMode,battery,wakeup
IODev ZWAVE1
alias Küche
classes BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
event-on-change-reading .*
event-on-update-reading wakeup,temperature,setpointTemp
group Heizung
icon sani_heating
ignoreDupMsg 1
room Übersicht
sortby 3
stateFormat {"<strong>Ist: </strong>".ReadingsVal('E2.ku.HR.Heizung','temperature','')." °C<strong> / Soll: </strong>".ReadingsVal('E2.ku.HR.Heizung','setpointTemp','')." °C</br><strong>Ventil: </strong>".ReadingsVal('E2.ku.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
Hallo Rudi,
wie kann es denn sein das 023105 als UNPARSED erscheint? Da stimmt doch was ganz gewaltig mit der Kommunikation nicht, bzw. ich würde da sogar auf einen Firmwarebug des Geräte tippen...
0x3105 ist der normale MultiSensor Report, die RegExp sieht so aus:
"..3105(..)(..)(.*)
D.h. wir erwarten da im Normalfall drei oder mehr Bytes als Parameter, der Befehlt wird aber anscheinend OHNE Parameter mit Länge 2 geschickt... Oder die Länge ist durch Übertragungsfehler falsch empfangen UND die CS stimmt wieder?? Eher unwahrscheinlich...
@Torsten: Wie sieht denn deine neighbor map aus? Sind da alle gegenseitig so eingetragen wie es physikalisch auch sinnvoll ist?
Ich bereue es jedenfalls nicht das ich mich bei den Heizungssachen für Homematic entschieden habe.
Gruß,
Andreas.
Hallo Andreas,
ich nehme an Du meinst die neighbor map, die man beim ZWAVE Dongle (bei mir RazBerry2) in fhem abrufen kann. Ich habe mal einen Screenshot angehängt.
Wie erkenne ich denn, dass die Einträge physikalisch sinnvoll sind?
Gruß
Torsten
Hi,
ja, die meine ich.
Ich meine damit mal schauen ob die physikalisch "nah" benachbarten auch in der Map (in beiden Richtungen) Nachbarn sind und ob z.B. ein möglicher Router auf dem Weg dahin auch bei beiden Geräten als Nachbar auftaucht.
Auf den ersten Blick erscheint mir Deine Map aber sehr dicht. Hast Du die Geräte an ihrem Einsatzort angelernt oder auf dem Schreibtisch und dann dorthin gebracht? Im zweiten Fall müsstest Du die Neighbor List mal komplett neu aufbauen, das ist nicht ganz so einfach wie es sich anhört wenn da auch WakeUp Geräte dabei sind. Hier ist es schwierig die in die Neighborlist von einem Router zu kriegen, man muss dann dem potentiellen Router den Befehl zum Updaten der Nachbarn schicken während GLEICHZEITG das WakeUp-Gerät auch wach ist...
@Rudi, Christian: Könnten die mehrfachen Nachrichten evtl. auch durch Routing entstehen? Woran ist denn bei einem Paket zu erkennen das es geroutet wurde?
Gruß,
Andreas.
ZitatKönnten die mehrfachen Nachrichten evtl. auch durch Routing entstehen?
Ich meine nicht direkt durch Routing, sondern durch nicht angekommene ACKs.
Andererseits kenne ich nur das statische Routing, nicht das mit ExplorerFrames.
ZitatWoran ist denn bei einem Paket zu erkennen das es geroutet wurde?
Ich meine ZWDongle verraet das nicht. Im Funktelegramm / ZWCUL gibt es beim statischen Routing entsprechende Felder/bits.
Siehe auch meine Antwort #18. Es geht hier um Heizungsregler (und ich habe noch nie einen "vernuenftigen" mit ZWave gesehen), die ueber 2 Steckdosen geroutet werden. Wobei das ist nur angenommen, und nicht beobachtet. Bei mir wird ein mAn direkt erreichbares Geraet ueber 2 andere geroutet: der erste "Router" steht total abseits, der andere direkt neben dem eigentlichen Ziel.
Zitat von: rudolfkoenig am 30 Januar 2017, 09:53:11
5 setpointTemp Nachrichten ist Novum fuer mich: ich war bisher ueberzeugt, dass es hoechstens 3 werden koennen.
Nach dem ZWCul-Log https://forum.fhem.de/index.php/topic,44905.msg369521.html#msg369521 gehe ich von deutlich mehr doppelten Nachrichten aus, wenn der Controller nicht anhand der Sequenznummer irgendetwas ausfiltert. Das Log ist auch nur auf einer Frequenz, so dass Umschaltung 100k auf 40k gar nicht berücksichtigt wird.
ZitatWie erkenne ich denn, dass die Einträge physikalisch sinnvoll sind?
Achtung: neighborMap ungleich routingMap.
Der Controller speichert fuer jeden der Knoten maximal 4 Nachbarn, und verwendet sie nach einem mir unbekannten Algorithmus beim statischen Routing. MW hat der Kontroller ausser die Eigenschaft "Nachbar" nichts Weiteres, insb. sowas wie Qualitaet der Uebertragung nicht. Wie die neuere Variante mit Explorer Frames funktioniert, weiss ich nicht.
Heißt das also, aus der neighborMap kann man nicht wirklich etwas über das zwave Netz sagen? Ich meine beim z-way Server gibt es eine Anzeige über die Verbindungen und die Qualität der Übertragung. Ich werde gleich mal von der zweiten Partition starten, auf der der z-way Server installiert ist und nachschauen, ob ich mich recht erinnere.
Mein Popp / Duwi ZW ZS 3500 Plugin Switch unterstützt soweit ich weiß keine explorer frames (SDK 5x). Laut neigborlist ist er aber so gut wie mit allen anderen Geräten verbunden.
ZWAVE1 ST.fl.SD.WakeUpLight ST.sz.RM.Decke KG.hw.RM.Decke KG.kr.RM.Decke E1.wz.SD.Tischleuchte E3.hk.ZS.unused E2.fl.SD.LEDLampe ST.sz.HR.Heizung E2.ez.HR.Heizung E4.az.HR.Heizung KG.hz.ZS.Zirkulationspumpe E2.ku.SD.Tischleuchte E1.wz.HR.Heizung.Wand EG.fl.HR.Heizung E2.ku.HR.Heizung ST.bz.HR.Heizung
Macht es Sinn beim POPP oder allen Geräten das attribut NoExplorerFrames zu setzen?
Gruß
Torsten
Zitat von: ToKa am 31 Januar 2017, 19:25:20
Ich meine beim z-way Server gibt es eine Anzeige über die Verbindungen und die Qualität der Übertragung.
Wenn sich das nicht geaendert hat, enthaelt die Routing-Info von z-way nicht mehr Infos als unsere/Rudis Grafikvariante.
http://razberry.z-wave.me/docs/RaZberryEndUserManual20.pdf S. 13f
Ich wüsste auch nicht, wie z-way wirkliche Übertragungsqualitaeten ermitteln kann. Die Möglichkeit soll erst in einem neuen SDK kommen.
ZitatMacht es Sinn beim POPP oder allen Geräten das attribut NoExplorerFrames zu setzen?
Probiere es aus. Glauben kann ich es nicht. Der Popp ignoriert die ExplorerFrames, weil er nicht damit umgehen kann. Die Geraete nutzen EF nur, wenn sie auf normalen Weg keine Verbindung bekommen. Und dann gab es schon einige Versuche.
Gruß, Christian
ZitatIch werde gleich mal von der zweiten Partition starten, auf der der z-way Server installiert ist und nachschauen, ob ich mich recht erinnere.
Wenn ja, dann hast Du die Ehre per USB-/Sonstwas-Sniffer die Kommunikation zum Stick zu dokumentieren :)
Hi Rudi,
Zitat von: rudolfkoenig am 31 Januar 2017, 08:40:29
Ich meine nicht direkt durch Routing, sondern durch nicht angekommene ACKs.
Andererseits kenne ich nur das statische Routing, nicht das mit ExplorerFrames.
schon klar, meinte das auch so.
Das würde dann aber doch eigentlich so ablaufen:
- Gerät schickt Nachricht, die kommt an, aber das ACK nicht mehr beim Gerät
- Gerät schickt Nachricht nochmal, kommt wahrscheinlich wieder an, ACK wieder nicht mehr beim Geräte
Jetzt meine ich mal gelesen zu haben das der dritte Versuch jetzt geroutet wird falls möglich
- Gerät schickt Nachricht an Router
und jetzt könnte man das weiterspinnen ob der ACK vom Router auch nicht beim Gerät ankommt oder ob dann später erst der ACK vom Controller an den Router nicht mehr ankommt...
In dem Fall müsste man aber eigentlich ab der dritten Nachricht eigentlich das Routing erkennen können, oder?
Zitat von: rudolfkoenig am 31 Januar 2017, 08:40:29
Ich meine ZWDongle verraet das nicht. Im Funktelegramm / ZWCUL gibt es beim statischen Routing entsprechende Felder/bits.
D.h. man müsste sowas noch mal mit einem CUL sniffen um das herauszufinden.
Bei den Explorerframes habe ich irgendwie abgespeichert das die "wild" verschickt werden aber irgendwie Ihren "Pfad" aufzeichnen und der erste der Ankommt hat gewonnen und wird als default route eingetragen, die übrigen werden ignoriert. Das gilt auch für die Router, die sollen nur auf das erste Paket reagieren und weitere ignorieren um das Schneeball->Lawinen Problem zu verhindern.
Könnte es evtl. sein. das hier so eine "Suche" per Explorerframes losgetreten wurde der Dongle aber alle davon empfängt?
Zitat von: rudolfkoenig am 31 Januar 2017, 08:40:29
Siehe auch meine Antwort #18. Es geht hier um Heizungsregler (und ich habe noch nie einen "vernuenftigen" mit ZWave gesehen), die ueber 2 Steckdosen geroutet werden. Wobei das ist nur angenommen, und nicht beobachtet. Bei mir wird ein mAn direkt erreichbares Geraet ueber 2 andere geroutet: der erste "Router" steht total abseits, der andere direkt neben dem eigentlichen Ziel.
Ich bin mit meinen Homematic auch ganz zufrieden, allerdings spinnt der USB-Adapter auch manchmal ganz fürchterlich, dann gibt es diese schönen disappeared / reappeared die nicht mehr aufhören, das log explodieren lassen und nichts geht mehr bis man es merkt und den Stick mal trennt und wieder ansteckt.
Gruß,
Andreas.
ZitatKönnte es evtl. sein. das hier so eine "Suche" per Explorerframes losgetreten wurde der Dongle aber alle davon empfängt?
Finde ich plausibel. Dafuer muesste aber Controller "dumm" sein, und keine Ahnung vom EF haben.
Christian, kannst du bitte nachschauen? :)
Zitat von: rudolfkoenig am 31 Januar 2017, 20:53:24
Wenn ja, dann hast Du die Ehre per USB-/Sonstwas-Sniffer die Kommunikation zum Stick zu dokumentieren :)
Wenn Du mir sagst, wie und was ich genau machen soll gerne. Gibt es eine Anleitung dafür? Ist aber kein Stick sondern der GPIO RazBerry2.
Anbei mal die Infos, die ich z-way entlocken konnte.
Gruß
Torsten
Bin genügsamer als Rudi für den Du wireshark, ZWCul o.ae. benötigst. ;)
Was sagt das z-way-server Log, wenn Du bei Routing Table auf Update klickst (1 Node genügt)?
Ich sehe in den z-way Screenshots nichts, wofuer sich sniffen lohnen wuerde.
Wenn ueberhaupt, dann ist hier nur ein ZWCUL Mitschnitt interessant.
Zitat von: rudolfkoenig am 31 Januar 2017, 21:36:34
Finde ich plausibel. Dafuer muesste aber Controller "dumm" sein, und keine Ahnung vom EF haben.
Christian, kannst du bitte nachschauen?
Relativ erfolglos: Keine genaue Info gefunden, außer allgemeine Aussage, dass Duplikate per statemachine ausgefiltert werden müssen. Bei spontanen Nachrichten ohne CallbackId fällt mir kein vernünftiger Weg zur Duplikatserkennung ein. Kann mich auch nicht erinnern jemals konkrete Infos gelesen zu haben.
Was für dumme Controller sprechen könnte:
Die "professionellen" Systeme nutzen EF nur beim Start. Es werden mehrere Wert mit EF-TRANSMIT_OPTION 25 von den einzelnen Geräte abgefragt, die zwangsweise CallbackId enthalten. Nach Erhalt der Antworten wird im laufenden Betrieb nur noch mit TRANSMIT_OPTION 05 verschickt. Damit würde die Gefahr von wiederholenden Nachrichten, die den Controller fluten, verhindert/vermindert.
Eigentlich wollte ich wissen, ob der Controller EF kann, ich gehe von einem JA aus.
ZitatDie "professionellen" Systeme nutzen EF nur beim Start.
Ich ziehe "kommerziell" vor :)
Jungs: koennt ihr bei den problematischen Geraeten "noExplorerFrames" setzen, und berichten?
Zitat von: rudolfkoenig am 01 Februar 2017, 14:08:03
Eigentlich wollte ich wissen, ob der Controller EF kann, ich gehe von einem JA aus.
Dann verstehe ich Deine Frage und vermutlich das Problem jetzt immer noch nicht. :-\
Ja, der Controller kann EF verschicken und empfangen.
Hallo zusammen,
hatte heute morgen noch schnell für zwei Geräte (E4.az.HR.Heizung und ST.sz.HR.Heizung) noExplorerFrames aktiviert und im ersten Moment, sah es gut aus. Als ich heute Abend aber in die Logs der beiden Geräte geschaut habe, sind wieder viele Einträge bei verschiedenen Werten mehrfach vorhanden.
Im list taucht dann auf dem sendstack wieder mal ein sendackget auf und auch SEND_DATA failed:00 bzw. UNPARSED Einträge.
Internals:
DEF d14c12e6 13
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 472
NAME ST.sz.HR.Heizung
NR 72
STATE <strong>Ist: </strong>20.5 °C<strong> / Soll: </strong>19.5 °C</br><strong>Ventil: </strong>10 %
STILLDONETIME 0
TYPE ZWave
ZWAVE1_MSGCNT 472
ZWAVE1_RAWMSG 0004000d0326030a
ZWAVE1_TIME 2017-02-01 19:07:28
ZWaveSubDevice no
homeId d14c12e6
ignoreDupMsg 1
isWakeUp 1
lastMsgSent 1485972444.29546
nodeIdHex 0d
Helper:
Dblog:
Desired-temp:
Logdb:
TIME 1485926100.06054
VALUE 19.5
Reportedstate:
Logdb:
TIME 1485972448.4222
VALUE 10
Setpointtemp:
Logdb:
TIME 1485972444.33633
VALUE 19.5
Temperature:
Logdb:
TIME 1485972444.1936
VALUE 20.5
Wakeup:
Logdb:
TIME 1485972443.77906
VALUE notification
Readings:
2017-02-01 09:31:10 SEND_DATA failed:00
2017-02-01 17:36:12 UNPARSED THERMOSTAT_MODE 024003
2017-02-01 04:43:18 battery 100 %
2017-01-28 08:15:30 desired-new 00
2017-02-01 06:15:00 desired-temp 19.5
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
2017-02-01 07:02:12 neighborList ST.fl.SD.WakeUpLight EG.ga.SD.Glasbausteine E3.hk.ZS.unused
2017-01-29 14:49:55 neighborUpdate done
2017-02-01 19:07:28 reportedState 10
2017-02-01 19:07:24 setpointTemp 19.5
2017-02-01 19:07:28 state dim 10
2017-02-01 19:07:24 temperature 20.5
2017-02-01 19:07:23 thermostatMode heating
2017-02-01 19:07:24 timeToAck 0.145
2017-02-01 19:07:24 transmit OK
2016-10-22 15:59:02 userCode id 1 status 2 code 00c3
2017-02-01 19:07:23 wakeup notification
2016-10-08 09:27:21 wakeupReport interval 600 target 1
SendStack:
sentackget:130d02260205ae
get:130d02400205af
Attributes:
DbLogInclude desired-temp,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-on-change-reading .*
event-on-update-reading wakeup
group Heizung
icon sani_heating
ignoreDupMsg 1
noExplorerFrames 1
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 ::
Das FHEM log enthält über den Tag verteilt Einträge wie:
2017.02.01 12:40:23.798 3: ZWave get E4.az.HR.Heizung smStatus
2017.02.01 12:40:23.803 3: ZWave get E4.az.HR.Heizung setpoint
2017.02.01 12:40:23.805 3: ZWave get E4.az.HR.Heizung swmStatus
2017.02.01 12:40:23.807 3: ZWave get E4.az.HR.Heizung thermostatMode
2017.02.01 12:40:25.431 3: E4.az.HR.Heizung: ignore duplicate answer setpointTemp:19.5 C heating
2017.02.01 12:40:25.700 3: E4.az.HR.Heizung: ignore duplicate answer setpointTemp:19.5 C heating
2017.02.01 12:40:26.826 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
2017.02.01 12:40:29.639 2: ZWAVE1 transmit NO_ACK for CB ef, target E4.az.HR.Heizung
2017.02.01 12:50:29.692 3: ZWave get E4.az.HR.Heizung smStatus
2017.02.01 12:50:29.694 3: ZWave get E4.az.HR.Heizung setpoint
2017.02.01 12:50:29.695 3: ZWave get E4.az.HR.Heizung swmStatus
2017.02.01 12:50:29.697 3: ZWave get E4.az.HR.Heizung thermostatMode
2017.02.01 12:50:30.268 3: E4.az.HR.Heizung: ignore duplicate WUN
2017.02.01 12:50:31.196 3: E4.az.HR.Heizung: ignore duplicate answer UNPARSED:SWITCH_MULTILEVEL 022603
2017.02.01 12:50:31.235 3: E4.az.HR.Heizung: ignore duplicate answer UNPARSED:SWITCH_MULTILEVEL 022603
2017.02.01 12:50:32.096 3: E4.az.HR.Heizung: ignore duplicate answer UNPARSED:SWITCH_MULTILEVEL 022603
2017.02.01 12:50:32.385 3: E2.ez.HR.Heizung: ignore duplicate answer thermostatMode:heating
2017.02.01 12:50:33.722 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:33.873 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:34.180 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:36.384 2: ERROR: cannot SEND_DATA to E4.az.HR.Heizung: transmit queue overflow
2017.02.01 12:50:38.728 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:38.836 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:39.142 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:39.407 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 12
2017.02.01 12:50:41.219 2: ZWAVE1 transmit NO_ACK for CB 16, target E4.az.HR.Heizung
2017.02.01 17:03:25.908 2: ZWAVE1 transmit NO_ACK for CB 38, target E1.wz.HR.Heizung.Fenster
2017.02.01 18:03:39.988 3: E4.az.HR.Heizung: ignore duplicate answer state:dim 10
2017.02.01 17:53:30.166 3: E4.az.HR.Heizung: ignore duplicate WUN
2017.02.01 19:19:18.927 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900131202260225cd39
Das Log vom z-way Server habe ich als Datei angehängt.
Etwas ist mir gerade noch aufgefallen. Warum werden eigentlich die mehrfachen Log Einträge überhaupt erzeugt? Ich habe nämlich bei den Geräten "event-on-change-reading .*" eingestellt.
Gruß
Torsten
ZitatWarum werden eigentlich die mehrfachen Log Einträge überhaupt erzeugt? Ich habe nämlich bei den Geräten "event-on-change-reading .*" eingestellt.
event-on-change-reading ist kompliziert. Fuer eine sinvolle Antwort brauche ich die zum Geraet passenden Debugdaten, Logs und Geraetedefinitionen.
z-way scheint auch sein Spass mit dem Geraet zu haben. Ich habe nach Kommunikation mit ID 13/0D gesucht (ST.sz.HR.Heizung), und bin bei versionClassAll gelandet (Frage: 0D .. 86 13 <classId>, Antwort: 0D .. 86 14 <classId>).
- es werden 10 Fragen abgeschickt, in etwa 0.1-0.2s Abstand, fuer die Klassen 20 26 31 40 43 72 77 80 84 86
- auf die erste Frage kommt sofort eine Antwort, danach erstmal keine. z-way sendet munter weiter.
- 3 Sekunden spaeter kommen die Antworten fuer die Klassen: 20 26 31 40 40 43 40 40 40.
- eine Minute spaeter versucht z-way nochmal, mit vergleichbar lustigen Ergebnis.
Noch unerklaerbar fuer mich:
- wieso macht z-way nach ca 0.2s weiter, obwohl keine Antwort auf die Frage kommt.
- wer Puffert 3s lang die Fragen oder die Antworten
Ich sehe nur den Einsatz eines ZWCULs an strategischer Stelle, wenn wir die Probleme genauer verstehen wollen. Ob wir danach eine Loesung bauen koenne, ist was anderes.
Ich will nicht ausschließen, dass ich am Verhalten von z-way Schuld bin. Da ich nicht wirklich weiß, wie z-way funktioniert, habe ich teilweise mehrfach auf die "buttons" z.B. SendNIF geklickt. Was man aber im Job Queue Monitor von z-way beobachten kann, ist dass jede ausgehende Nachricht mit einem eigenen, meist unterschiedlichen Timer versehen ist. Erst nach Erhalt der Antwort oder Ablauf des Timers wird die Nachricht aus der Queue gelöscht.
Habe mal zum weitern Testen all event-on* attribute entfernt und habe gefühlt weniger Mehrfacheinträge im Log. Könnte das auf ein Timingproblem hindeuten, ich habe bei den beiden vorwiegend betroffenen Geräten auch immer mal wieder extrem schwankende, hohe TimeToACK Werte? Kann man TimeToACK ins Filelog mitprotokollieren lassen (hab es bislang nicht hinbekommen)?
Ich weiß für eine Analyse benötigt Ihr ein verbose 5 log. Wenn allerdings nur ich das Problem habe, will ich nicht länger Eure Zeit in Anspruch nehmen. Ansonsten investiere ich auch gerne noch Zeit. Wenn ein ZWCUL keine Rieseninvestition bedeutet und Ihr mir sagt, was ich machen muss, gerne auch das.
Beste Grüße
Torsten
ZitatKann man TimeToACK ins Filelog mitprotokollieren lassen (hab es bislang nicht hinbekommen)?
Nur mit Bastelei, indem man per notify+trigger timetoack als Event zur Verfuegung stellt.
ZitatWenn ein ZWCUL keine Rieseninvestition bedeutet und Ihr mir sagt, was ich machen muss, gerne auch das.
Wenn du nicht basteln willst, kostet ein CUL 50 EUR+Lieferung von busware.de
Das irgendwo an USB anschliessen, und ein FHEM ueber das ZWCUL Modul darauf zugreifen lassen. Wenn man bei der ZWCUL Definition homeId 00000000 setzt, dann werden alle ZWave Funknachrichten protokolliert, aber das CUL antwortet nie. Da das CUL nur auf einer der drei moeglichen Datenraten (9.6k, 40k, 100k) eingestellt werden kann, ein ZWave-Chips aber auf allen 3, muss man rausfinden, was bei dir verwendet wird. Neue Chips versuchen 100k, aeltere koennen nur 40k. 9.6k wird mWn nur noch bei NIF-Senden verwendet.
Das CUL kann man spaeter auch fuer andere Sachen verwenden.
Hallo zusammen,
naja 50€ ist nicht gerade wenig... Mein Controller und die Geräte geben mit nodeinfo maxBaud 40k und die zwavplus Geräte zusätzlich noch SpeedExt:100k an. Wenn ich routeFor ausgeben lasse, tauchen verschiedene Geschwindigkeiten 9.6k, 40k und 100k zwischen den Geräten auf.
Habe mal nach "zwave duplicate messages" gegooglet und siehe da, das Problem kommt nicht nur bei mir bzw. mit FHEM vor, aber immer in Kombination mit RPi :o
https://github.com/openhab/openhab1-addons/issues/1564 (https://github.com/openhab/openhab1-addons/issues/1564)
https://github.com/openhab/openhab1-addons/wiki/Z-Wave-Binding (https://github.com/openhab/openhab1-addons/wiki/Z-Wave-Binding)
Known Issues
ARM Compatibility issue (fixed - updated Dec. 11, 2016 see below): There seems to be an issue with the binding running on the latest oracle VM Beta, on ARM based architectures (e.g. raspberry PI). It manifests itself as messages being received multiple times and causes considerable problems with the operation of the binding. In large networks, the queue can get extremely long, which can delay initialisation considerably and cause potentially long delays in sending messages. Some time has been spent investigating this issue and a solution has not been found - the issue doesn't appear to be with the binding itself as the problem doesn't manifest itself on an other platform. If anyone with the hardware and programming experience can help with this it would be useful (add information to https://github.com/openhab/openhab/issues/1564).
(Update Dec. 11, 2016): This issue is no longer affecting "all" ARM processors. The above issue report has been closed as the problem has vanished in newer Java JRE versions.
I recently built a successful setup with no duplication problems with these versions of software and hardware:
Raspberry Pi 3 (ARM v7l) Aeon Zstick Gen5 Raspbian - November 2016 - Kernel 4.4 Openhab 1.8.3 Z-wave binding version 1.8.3 Java Runtime SE: build 1.8.0_65-b17
The original issue (1564) has been closed and the symptoms have vanished since an update to Java JRE's serial library that is now standard in the new versions of Raspbian. I have not tested with original Raspberry pi (ARM v5) nor a Raspberry pi 2 (ARM v6). Assuming it was fixed in Java those should work now too. But maybe it is only fixed based on Raspberry pi 3 being ARM v7l.
You should no longer fear using OpenHAB with raspberry pi 3 and Z-wave! For my install it is very successful and zero errors.
Unter Openhab scheint das Problem gelöst zu sein.
Beste Grüße und ein schönes Wochenende
Torsten
Wenn ich den Text richtig deute, handelt es sich um ein JRE Bug auf ARM. Ich gehe davon aus, dass bei dem perl Interpreter dieses Problem nicht besteht. Du kannst natuerlich einen anderen Perl-Interpreter versuchen, oder (z.Bsp. mit strace) die Hypothese direkt beweisen.
ZitatUnter Openhab scheint das Problem gelöst zu sein.
Kannst du das auch fuer deinen Fall testen? Wuerde mich wirklich interessieren.
Das war keine gute Idee oder ich habe mich zu blöd angestellt. Habe mir die Nacht um die Ohren geschlagen und versucht die perl Version (5.20) zu aktualisieren. Auf der raspbian Seite gibt es eine 5.24, aber die lässt sich auf Grund der Abhängigkeiten nicht installieren. Der Versuch mit cpan auf 5.24 zu aktualisieren funktionierte zwar, aber danach war im FHEM der ZWAVE Dongle nicht mehr ansprechbar.
Habe dann alles mühsam zurück "gedreht" und auch mit der 5.20 war dann der Dongel erst mal nicht ansprechbar. In der fhem.cfg war er weg... Erst nach dem Einspielen einer Sicherung von fhem.cfg lief dann wieder alles. Jetzt weiß ich natürlich nicht, ob es auch mit der 5.24 gegangen wäre, wenn ich die Sicherung der cfg eingespielt hätte. Durch die Aktualisierung mit cpan sind jetzt auch die meisten perl Module auf dem aktuellsten Stand. Am Verhalten der Kommunikation und der mehrfachen Antworten hat sich leider nichts geändert. An OpenHab wage ich mich jetzt erst gar nicht ran, da würde ich bei Null anfangen.
Im Beitrag https://forum.fhem.de/index.php/topic,64973.msg576709.html#msg576709 (https://forum.fhem.de/index.php/topic,64973.msg576709.html#msg576709) sind im log ja auch mehrfache Antworten enthalten. Haben die Fälle miteinander zu tun?
Gruß
Torsten