Moin
das o.g. passiert immer mal zwischendurch.
Auch bei Devices die kein zweites, drittes device haben sollten.
Aktuell ein Danfoss LC-13 der auf einmal ein Kind hat.
Internals:
CFGFN
DEF c9cc092a 4098
IODev ZWDongle_0
NAME ZWave_Node_16.2
NR 3046
STATE ???
TYPE ZWave
ZWaveSubDevice yes
endpointParent ThermostatKueche
homeId c9cc092a
nodeIdHex 1002
Attributes:
IODev ZWDongle_0
room ZWave
Das ist Der "Vater" ;)
Internals:
DEF c9cc092a 16
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 4905
NAME ThermostatKueche
NR 217
STATE 19.0 °C
TYPE ZWave
ZWDongle_0_MSGCNT 4905
ZWDongle_0_RAWMSG 00040010028407
ZWDongle_0_TIME 2016-10-15 11:48:41
ZWaveSubDevice no
endpointChildren ZWave_Node_16.2
homeId c9cc092a
isWakeUp 1
lastMsgSent 1476524923.34193
nodeIdHex 10
Readings:
2016-02-13 12:40:17 CMD ZW_APPLICATION_UPDATE
2016-10-15 11:48:41 battery 72 %
2016-10-15 11:48:41 ccsOverride no, unused
2015-12-28 14:46:54 model Danfoss Z Thermostat 014G0013
2015-12-28 14:46:54 modelConfig danfoss/z.xml
2015-12-28 14:46:54 modelId 0002-0005-0004
2016-09-26 17:22:15 neighborList ZWDongle_0 FunkDose1 LichtWohnzimmerSchrank1A LichtWohnzimmerSchrank2A FunkDose2 LichtBuero1A LichtKueche LichtFlurSpiegel DimmerWohnzimmer LichtFlur LichtBad DimmerSchlafzimmer
2016-09-23 07:29:39 neighborUpdate done
2016-10-15 11:48:41 setpointTemp 19.00 C heating
2016-10-15 11:48:43 timeToAck 0.028
2016-10-15 11:48:43 transmit OK
2016-10-15 11:48:41 wakeup notification
2016-01-02 22:55:42 wakeupReport interval 300 target 1
Attributes:
IODev ZWDongle_0
alias Thermostat Küche
classes BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
group Heizung und Temperatur
icon hc_wht_regler
neighborListPos 196.93650717675953,685.8774617168359
room Küche,System,ZWave
stateFormat {sprintf(" %.1f °C",(ReadingsNum("ThermostatKueche","setpointTemp",0)))}
Warum passiert so etwas ?
Habe auch noch andere devices die so ein Quatch anstellen. FGK101, (nicht Temperatur, der ist belegt)
ZitatWarum passiert so etwas ?
Programmierfehler ? :)
Wuerde mir sehr helfen, wenn du mit "attr zwdongle verbose 5" die ausloesende Roh-Nachricht hier posten koenntest.
Sonst muss ich gruebeln, und das habe ich schon einmal hinter mir :)
hmmm
Ich kann das leider gar nicht nachvollziehen. Plötzlich sehe ich im webfrontend das neue device.
So wurde es scheinbar angelegt:
2016.10.15 04:04:19 3: UNDEFINED ZWave_Node_16.2 ZWave c9cc092a 4098, please define it
2016.10.15 04:04:19 2: autocreate: define ZWave_Node_16.2 ZWave c9cc092a 4098
2016.10.15 04:04:20 2: autocreate: define FileLog_ZWave_Node_16.2 FileLog ./log/ZWave_Node_16.2-%Y.log ZWave_Node_16.2
Wobei der USB zwave Stick ja nicht im inklusionsmodus ist, bzw. war. (und ich zu diesem Zeitpunkt sicher im Bettchen war) Dieser beendet sich doch selbstständig nach einer Inklusion.
Und das Parent davon gibt es schon sein 28.12.2015 also auch nichts neues.
Auch ein Fibaro FGK101 hat sich ein, bzw. noch ein "Kind" geholt.
Aber ich habe leider keinerlei Ansatz zum Zeitpunkt etc.
Gerne helfe ich hierbei aus aber verbose 5 setzten und ein Paar Wochen warten, das bringt es nicht.
LG
Tom
Mit diesen "Endpoints" habe ich sonderbare Erlebnisse. Mir ist übrigens auch nicht ganz klar wozu die gut sein sollen (habe auch nichts dazu gefunden).
Hier kurz was passiert ist (oder was nicht passiert ist):
Ich hatte ZWave mit dem Aeon Labs Stick 2 angefangen. Das war "nicht-ZWave+". Als ich den Fibaro Dimmer 2 (FIBARO System FGD212 Dimmer 2, modelId: 010f-0102-1000) aufgenommen hatte, waren 2 Endpoints vorhanden. Soweit so gut.
Jetzt Umstellung auf Aeon Labs Stick Gen5 (ZWave+). Erst alle alten Devices excludiert, Stick ausgewechselt, neu gestarted, Devices neu Includiert. Hat funktioniert. Nur gibt es jetzt keine dieser Endpoints mehr. Korrekt oder nicht? In den Readings sehe ich als "mcEndpoints" jetzt "total 2, different". Aber sie sind nicht da, und ich kann sie auch nicht erzeugen lassen.
FHEM habe ich laufend aktualisiert, zuletzt heute. Den Dimmer rausnehmen und nochmal aufnehmen - ok, wenn es sein muss ... kann ich machen sobald es die Zeit erlaubt.
Es gibt noch mehr Ungereimtheiten: Jetzt habe ich immer wieder, z.B. nach einem get configALL, aber auch sonst solche Meldungen im Log:
ZWDongle_ProcessSendStack: no ACK, resending message .... (numerischer Wert).
Die kommen haufenweise, obwohl alles funktioniert. Gesehen nach dem Update von heute. Das ist sicher eine andere Baustelle, hier nur als Anmerkung. Wichtiger sind mir diese Endpoints und die Frage wie das denn nach aktuellem Stand das korrekte Systemverhalten wäre.
Gruß, Klaus
"Endpoints" werden erzeugt, wenn zu einem bekannten Geraet Nachrichten der Klasse MULTI_CHANNEL empfangen werden, und das angesprochene Kanal (aka Endpoint) nicht bekannt ist.
Ich habe die "please define it" Zeile mit der empfangenen Roh-Nachricht erweitert, update kommt ab morgen. Wenn damit ein Geraet angelegt wird, bitte die Roh-Nachricht hier zeigen.
@rudolfkoenig
wird das denn auch in verbose 3 geloggt?
Ab dem morgigen update ja.
So da habe ich jetzt etwas
2016.11.12 16:55:25 3: UNDEFINED ZWave_Node_14 ZWave c9cc092a 3584, please define it. Triggered by 0004000e0c600d0000310501440000084d.
2016.11.12 16:55:25 2: autocreate: define ZWave_Node_14 ZWave c9cc092a 3584
2016.11.12 16:55:25 2: autocreate: define FileLog_ZWave_Node_14 FileLog ./log/ZWave_Node_14-%Y.log ZWave_Node_14
endpointParent davon ist:
defmod FensterBuero ZWave c9cc092a 14
attr FensterBuero IODev ZWDongle_0
attr FensterBuero alias Fenster Büro
attr FensterBuero classes SENSOR_BINARY SENSOR_ALARM MULTI_CHANNEL ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION BASIC
attr FensterBuero devStateIcon open:fts_window_1w_tilt@red .*:fts_window_1w
attr FensterBuero group Fenster und Türen
attr FensterBuero icon fts_window_1w
attr FensterBuero neighborListPos 201.40439360109053,946.8894173875736
attr FensterBuero room Büro,System,ZWave
setstate FensterBuero closed
setstate FensterBuero 2016-11-14 00:55:07 UNPARSED BASIC 0c200d02023105014400000772
setstate FensterBuero 2015-12-26 08:11:10 assocGroups 3
setstate FensterBuero 2015-12-26 08:11:07 basicReport ff
setstate FensterBuero 2016-11-13 19:49:14 basicSet 0
setstate FensterBuero 2016-11-14 11:03:39 battery 74 %
setstate FensterBuero 2016-04-03 22:56:59 configInsensitivenessToTemperature12 0
setstate FensterBuero 2016-10-23 18:20:57 configStatusChangeSignalledByLED LEDTurnedOff
setstate FensterBuero 2016-01-09 15:29:45 config_15 0
setstate FensterBuero 2015-12-26 08:11:06 mcCapability_02 SENSOR_MULTILEVEL
setstate FensterBuero 2015-12-25 08:04:40 model FIBARO System FGK101 Door Opening Sensor
setstate FensterBuero 2015-12-25 08:04:40 modelConfig fibaro/fgk001.xml
setstate FensterBuero 2015-12-25 08:04:40 modelId 010f-0700-1000
setstate FensterBuero 2016-10-22 13:19:13 neighborList ZWDongle_0 FunkDose1 LichtWohnzimmerSchrank2A FunkDose2 LichtBuero1A LichtKueche LichtFlurSpiegel DimmerWohnzimmer LichtFlur LichtBad DimmerSchlafzimmer LichtSchlafzimmerSchrank1A LichtBueroGabi
setstate FensterBuero 2016-10-22 12:44:28 neighborUpdate done
setstate FensterBuero 2016-11-13 19:49:14 reportedState closed
setstate FensterBuero 2016-11-13 19:49:14 state closed
setstate FensterBuero 2016-07-22 02:26:34 temperature 27.12 C
setstate FensterBuero 2016-11-14 15:44:24 timeToAck 0.052
setstate FensterBuero 2016-11-14 15:44:24 transmit OK
setstate FensterBuero 2016-11-14 15:44:21 wakeup notification
setstate FensterBuero 2016-01-11 08:27:36 wakeupReport interval 4000 target 1
und noch einen
2016.11.14 03:54:14 3: UNDEFINED ZWave_Node_6.2 ZWave c9cc092a 1538, please define it. Triggered by 000410060c600d02023905014400000746.
2016.11.14 03:54:14 2: autocreate: define ZWave_Node_6.2 ZWave c9cc092a 1538
2016.11.14 03:54:14 2: autocreate: define FileLog_ZWave_Node_6.2 FileLog ./log/ZWave_Node_6.2-%Y.log ZWave_Node_6.2
endpointParent davon ist:
defmod FunkDose1 ZWave c9cc092a 6
attr FunkDose1 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 room_map structexclude
attr FunkDose1 IODev ZWDongle_0
attr FunkDose1 alias Tannenbaum Büro
attr FunkDose1 classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION SWITCH_BINARY POWERLEVEL METER SENSOR_MULTILEVEL FIRMWARE_UPDATE_MD MARK SWITCH_BINARY METER SENSOR_MULTILEVEL
attr FunkDose1 devStateIcon on:ios-on-green off:ios-off
attr FunkDose1 group Steckdosen & Funksteckdosen
attr FunkDose1 icon message_socket
attr FunkDose1 neighborListPos 689.6143230671229,1001.2561315978934
attr FunkDose1 room Büro,System,ZWave
attr FunkDose1 webCmd :
setstate FunkDose1 off
setstate FunkDose1 2016-11-05 22:11:37 UNPARSED SENSOR_MULTILEVEL 06310704220000
setstate FunkDose1 2016-07-05 22:15:04 alarm_type_04 level 22
setstate FunkDose1 2015-12-19 16:48:16 assocGroup_1 Max 5 Nodes ZWDongle_0
setstate FunkDose1 2015-12-19 16:48:16 assocGroup_2 Max 5 Nodes
setstate FunkDose1 2015-12-19 16:48:16 assocGroup_3 Max 1 Nodes ZWDongle_0
setstate FunkDose1 2015-12-19 16:48:16 assocGroups 3
setstate FunkDose1 2015-12-19 16:48:52 configActionInCaseOfExceedingDefined52 and3Combined
setstate FunkDose1 2015-12-19 16:48:52 configAlarmDuration 600
setstate FunkDose1 2015-12-19 16:48:52 configAlwaysOnFunction functionInactive
setstate FunkDose1 2015-12-19 16:48:53 configDOWNValue 300
setstate FunkDose1 2015-12-19 16:48:53 configImmediatePowerReport 80
setstate FunkDose1 2015-12-19 16:48:53 configLEDRingIlluminationColourAtTheZ63 LEDRingFlashesRedBlueWhite
setstate FunkDose1 2016-10-17 17:05:36 configLEDRingIlluminationColourWhen61 illuminationTurnedOffCompletely
setstate FunkDose1 2015-12-19 16:48:53 configLEDRingIlluminationColourWhen62 illuminationTurnedOffCompletely
setstate FunkDose1 2015-12-19 16:48:53 configMeteringEnergyConsumedByTheWall49 functionInactive
setstate FunkDose1 2015-12-19 16:48:53 configOveloadSafetySwitch 65535
setstate FunkDose1 2015-12-19 16:48:53 configPowerLoadWhichWhenExceededMakes60 25000
setstate FunkDose1 2015-12-19 16:48:53 configPowerReportingFrequency 30
setstate FunkDose1 2015-12-19 16:48:53 configReactionToAlarms ALARMALL
setstate FunkDose1 2015-12-19 16:48:53 configRememberDeviceStatusAfterPower16 WallPlugMemorizesItsStateAfterA1
setstate FunkDose1 2015-12-19 16:48:53 configReportingChangesInEnergyConsumed45 10
setstate FunkDose1 2015-12-19 16:48:53 configStandardPowerLoadReporting 15
setstate FunkDose1 2015-12-19 16:48:53 configTimePeriodBetweenReportsOnPower47 3600
setstate FunkDose1 2015-12-19 16:48:53 configUPValue 500
setstate FunkDose1 2015-12-19 16:48:53 configWallPlugSResponseToAlarmFrames NoReaction
setstate FunkDose1 2016-09-05 11:13:48 distance 0.0 m
setstate FunkDose1 2016-11-14 16:11:20 energy 3.55 kWh
setstate FunkDose1 2016-09-02 08:13:48 formaldehydeLevel 0.3 mol/m3
setstate FunkDose1 2015-12-19 16:44:15 model FIBARO System FGWPE Wall Plug
setstate FunkDose1 2015-12-19 16:44:15 modelConfig fibaro/fgwpe.xml
setstate FunkDose1 2015-12-19 16:44:15 modelId 010f-0600-1000
setstate FunkDose1 2016-10-22 13:19:13 neighborList ZWDongle_0 ThermostatBuero ThermostatSchlafzimmer ThermostatWohnzimmer LichtWohnzimmerSchrank2A FensterBuero UNKNOWN_15 ThermostatKueche FunkDose2 FensterSchlafzimmerLinks LichtBuero1A LichtKueche LichtFlurSpiegel FensterKueche FensterSchlafzimmerRechts FensterBad DimmerWohnzimmer LichtFlur LichtBad BalkontuerWohnzimmer TuerKammer DimmerSchlafzimmer LichtSchlafzimmerSchrank1A LichtBueroGabi SchalterGabi ThermostatBad Multisensor_02
setstate FunkDose1 2016-10-22 12:59:08 neighborUpdate done
setstate FunkDose1 2016-11-14 16:11:19 power 0.0 W
setstate FunkDose1 2016-03-14 09:03:24 powerlvl current 0 remain 0
setstate FunkDose1 2016-10-18 09:12:17 reportedState on
setstate FunkDose1 2016-10-22 12:59:37 state off
setstate FunkDose1 2016-10-22 12:59:37 timeToAck 0.042
setstate FunkDose1 2016-10-22 12:59:37 transmit OK
setstate FunkDose1 2016-09-04 05:40:39 velocity 0.0 m/s
hoffe das man damit etwas anfangen kann
LG
Tom
Die erste Anlage eines Endpoint-Devices aus der Nachricht
2016.11.12 16:55:25 3: UNDEFINED ZWave_Node_14 ZWave c9cc092a 3584, please define it. Triggered by 0004000e0c600d0000310501440000084d.
ist mMn ein Schönheitsfehler von FHEM. Die Nachricht müsste, da sie vom Endpoint 0 kommt, dem endpointParent-Device FensterBuero zugeordnet werden und es dürfte kein neues Device angelegt werden.
Auf der anderen Seite verstehe ich aber nicht, warum der Sensor so eine MultiChannel-Nachricht (Endpoint 0 an Endpoint 0=Hauptdevice an Hauptdevice) verschickt. Das ist nach meiner Lesart der zwapi nicht wirklich zwapi-konform.
Die zweite Anlage eines Endpoint-Devices aus der Nachricht
2016.11.14 03:54:14 3: UNDEFINED ZWave_Node_6.2 ZWave c9cc092a 1538, please define it. Triggered by 000410060c600d02023905014400000746.
ist ok. Der Aktor schickt von Endpoint 2 eine Nachricht an den Endpoint 2 und es gibt bisher kein entsprechendes Device.
Entweder handelt es sich um eine kaputte Nachricht (mein Tipp) oder man/Du musst herausfinden, warum der Aktor diese Nachricht verschickt.
Ich habe das Zuordnen der Nachricht fuer EndPoint 00 geaendert aus das Hauptgeraet, kann aber immer noch nicht einchecken.
Eingecheckt.
ZitatEntweder handelt es sich um eine kaputte Nachricht (mein Tipp) oder man/Du musst herausfinden, warum der Aktor diese Nachricht verschickt.
Für mich sehen die beiden Nachrichten identisch aus. Aber der Aktor hat ja gar kein zweiten Kanal.
Wahrscheinlich Müll
LG
Tom
Ehrlicherweise vermute ich auch bei der ersten Endpoint-Device-Anlage eine kaputte Nachricht, die aber zufaelligerweise halbwegs Sinn macht. Anhand der Readings der Devices sehe ich, dass kaputte Nachrichten in Deinem Netz kein Einzelfall sind. Ursache=?
Reduzieren könnte man es vielleicht, indem man nach Telegrammkollisionen sucht und diese vermeidet. Eventuell würde auch der Einbau der Command Class CRC16 etwas helfen. Bei direkt abgefragten Werten könnte man mit Sicherheit fehlerhafte Nachrichten besser erkennen. Bei den spontanen Nachrichten bin ich mir unsicher, da ich nicht herausgefunden habe, wie man einen Aktor/Sensor dazu bewegt, spontane Nachrichten mit CRC16 zu schicken. Die Haeufigkeit von spontanen Nachrichten würde ich als haeufiger als abgefragte Werte einschaetzen; außer Du arbeitest sehr viel mit get/set.
Zitatkaputte Nachrichten in Deinem Netz kein Einzelfall sind.
Woran kann man das du das erkennen.
Das Z-Wave Netzwerk ist hier auf knapp 90 m² schon sehr eng vermascht. Die einzigen Kameraden die mEn "Müll" produzieren sind die LC-13.
Diese liefern des Öfteren "transmit NO_ACK" bzw steht es ja im Log seitens des Dongles.
Damit experimentiere ich im Moment noch was das wakeupInterwal angeht. Diese "Fehler" werden immer öfters umso kürzer das Interwal ist.
Da probiere ich ein Optimum raus zu holen, aber ob das hierhin gehört.
Interessanter wäre es deine etwaige Vermutung nachzuvollziehen.
ZitatReduzieren könnte man es vielleicht, indem man nach Telegrammkollisionen sucht und diese vermeidet.
Gerne, wie?
Zitataußer Du arbeitest sehr viel mit get/set.
Jeder Aktor wird doch so angesteuert.
Zum LC-13 fällt mir noch ein das es in der Doku steht:
ZitatObwohl living connect® Z auf einzelne Befehle reagiert, müssen immer mehrfache Befehle verwendet werden, um die zweijährige Batterielebensdauer zu gewährleisten.
Was soll das denn bedeuten? Die Befehle gehen doch alle seriell raus, nacheinander.
Ich schweife aber sehr ab.
ZitatWoran kann man das du das erkennen.
Vermute ich aus:
2016.11.12 16:55:25 3: UNDEFINED ZWave_Node_14 ZWave c9cc092a 3584, please define it. Triggered by 0004000e0c600d0000310501440000084d.
2016.11.12 16:55:25 3: UNDEFINED ZWave_Node_14 ZWave c9cc092a 3584, please define it. Triggered by 0004000e0c600d0000310501440000084d.
FensterBuero 2016-11-14 00:55:07 UNPARSED BASIC 0c200d02023105014400000772
FunkDose1 2016-11-05 22:11:37 UNPARSED SENSOR_MULTILEVEL 06310704220000
FunkDose1 2016-09-05 11:13:48 distance 0.0 m
FunkDose1 2016-09-02 08:13:48 formaldehydeLevel 0.3 mol/m3
FunkDose1 2016-09-04 05:40:39 velocity 0.0 m/sHalte diese Nachrichten alle für "merkwürdig"; und das ist alles relativ aktuell.
ZitatGerne, wie?
Experimentieren und Suchen :) :
CANs, TRANSMIT_NO_ACK, resend suchen, auf den Grund gehen und abstellen.
-> Gibt es notify/DOIF, die auf Funknachrichten triggern und neue Funknachrichten absetzen, die regelmäßig Probleme machen?
Nur benötigte Assoziationen zum Controller setzen (sind bspw. bei FunkDose1 Assoziationen des Controllers mit Asso 1 und 3 wirklich notwendig?)
...
Zitat
Jeder Aktor wird doch so angesteuert.
Ja, aber man kann sich auch Probleme schaffen, indem man bspw. zuviel pollt und damit Kollisionen auslöst. Oder an falschen Zeitpunkten Nachrichten absetzt.
Hi,
ZitatObwohl living connect® Z auf einzelne Befehle reagiert, müssen immer mehrfache Befehle verwendet werden, um die zweijährige Batterielebensdauer zu gewährleisten.
Zitat von: tomspatz am 16 November 2016, 21:13:02
Was soll das denn bedeuten? Die Befehle gehen doch alle seriell raus, nacheinander.
Ich schweife aber sehr ab.
das ist eine sehr schlechte Übersetzung von jemandem der keine Ahnung von der Technik dahinter hat...
Hiermit ist die Klasse MULTI_COMMAND gemeint. Die kann mehrere Befehle in EINE Nachricht packen und "spart" damit Sendezeit und dadurch Batterien. Die Beschreibung "mehrfache Befehle" ist hier einfach sau-blöd...
Gruß,
Andreas.
Zitat von: A.Harrenberg am 17 November 2016, 10:06:49
Klasse MULTI_COMMAND gemeint.
Bin überrascht, dass die beim LC-13 schon unterstützt wird. Nachdem, was ich gestern im zwapi gelesen habe (Multi Command steht nahe bei Multi_channel), könnte die Class zur Batterieschonung beitragen.
Hi,
Zitat von: krikan am 17 November 2016, 10:20:19
Bin überrascht, dass die beim LC-13 schon unterstützt wird. Nachdem, was ich gestern im zwapi gelesen habe (Multi Command steht nahe bei Multi_channel), könnte die Class zur Batterieschonung beitragen.
wird sie, siehe listing im Post #1. In Fhem heißt die Klasse allerdings MULIT_CMD ,-)
Die Klasse wird von vielen Sensoren unterstützt, was für mich etwas ärgerlich ist wenn ich mir Rohnachrichten anschaue, dann muss man da immer in die Packete reinschauen und kann nicht einfach nur nach den Klassen schauen... B-)
Gruß,
Andreas.
Habe gestern mal probiert den Wakeup-Sendstack nach WUN in ein MULTI_CMD zu packen; war aber noch nicht erfolgreich. SECURITY habe ich dabei aber überhaupt noch nicht betrachtet und mich irritiert noch das man die WNMI mit in das Command packt, so daß andere Geräte mit direkten Assoziationen, wenn es denn so etwas geben sollte, keine Chance zur Kommunikation haben.
Hi,
Zitat von: krikan am 17 November 2016, 10:45:13
Habe gestern mal probiert den Wakeup-Sendstack nach WUN in ein MULTI_CMD zu packen; war aber noch nicht erfolgreich. SECURITY habe ich dabei aber überhaupt noch nicht betrachtet und mich irritiert noch das man die WNMI mit in das Command packt, so daß andere Geräte mit direkten Assoziationen, wenn es denn so etwas geben sollte, keine Chance zur Kommunikation haben.
kann Dir hier nicht ganz folgen...
Hast Du versucht die Nachrichten auf dem WU-Stack in eine Multi_CMD zu verpacken damit das dann bei der WU-Notification mit einem Befehl gemacht ist?
Und wer packt das WNMI mit darein? Das wird doch erst "dynamisch" erzeugt nachdem die WUN angekommen ist?
Bin verwirrt...
Andreas.
Zitat von: A.Harrenberg am 17 November 2016, 10:50:26
Hast Du versucht die Nachrichten auf dem WU-Stack in eine Multi_CMD zu verpacken damit das dann bei der WU-Notification mit einem Befehl gemacht ist?
Korrekt. Letztes von mir (angehängtes) Command war WNMI. Habe ich aus dem Beispiel der zwapi.
ZitatDas wird doch erst "dynamisch" erzeugt nachdem die WUN angekommen ist?
Ja, das macht FHEM derzeit so und ist eines meiner (vielen) Probleme bei dem Thema. Die dynamische WNMI von FHEM ist durch das Anhängen von WNMI im Multi_cmd überflüssig und landet im NOACK. Das ist aber eigentlich schon Feinheit.
Unklar ist mir, wie ich verhindern kann, dass die Befehle aus triggern von WUN in notify/DOIF abgesetzt werden, im Multi_Cmd nicht berücksichtigt werden.
Hi,
ok, "halb" verstanden. Ich würde das WNMI nicht mit in das "vorgefertigte" Paket aufnehmen. Das kriegst Du mit den Notify nicht hin...
WANN genau erzeugst Du den das MultiCMD? Macht das der WU-Stack? So lange "anhängen" bis die maximale Länge erreicht ist?
Security könnte dabei ein Problem darstellen, habe gerade noch mal nachgeschaut, die dürfen nicht in MultiCmd gekapselt werden, nur andersherum ,-)
Gruß,
Andreas.
Zitat von: A.Harrenberg am 17 November 2016, 11:28:46
Ich würde das WNMI nicht mit in das "vorgefertigte" Paket aufnehmen.
Dann hat man aber wieder die unnötige Wachzeit (und es passt nicht zu zwapi-Bsp. ;) ) Was bringt MULTI_CMD dann tatsächlich noch an Batterieschonung!?
ZitatWANN genau erzeugst Du den das MultiCMD? Macht das der WU-Stack? So lange "anhängen" bis die maximale Länge erreicht ist?
Bin doch noch ganz am Anfang des Experimentier- und Überlegungsprozesses und sehr sehr weit vom richtigen Einbau weg: Ich hatte es in der parse-Routine direkt nach Erkennung "28407" vor dem Timerstart eingebastelt. Längenprüfung, Stackanpassung und Co. habe ich nicht gemacht.
Ich wuerde in ZWave_processSendStack, zwei Zeilen vor dem IOWrite, eine Funktion ZWave_packMultiCmd() einbauen, der den Stack (falls machbar) zusammenpackt. Ist dann auch relativ einfach zum ein/auskommentieren.
Danke für den Hinweis, werde ich probieren.
Hi Christian,
Zitat von: krikan am 17 November 2016, 16:32:33
Dann hat man aber wieder die unnötige Wachzeit (und es passt nicht zu zwapi-Bsp. ;) ) Was bringt MULTI_CMD dann tatsächlich noch an Batterieschonung!?
die Wartezeit kann man ja über WNMI_delay "tunen" und an sein System anpassen, je nachdem ob man Notifies auf der WUN triggert oder nicht. Mulit_CMD verringert ja auf jeden Fall die Anzahl der Nachrichtenpakete und das macht sich auf Dauer schon bemerkbar.
Zitat von: krikan am 17 November 2016, 16:32:33
Bin doch noch ganz am Anfang des Experimentier- und Überlegungsprozesses und sehr sehr weit vom richtigen Einbau weg: Ich hatte es in der parse-Routine direkt nach Erkennung "28407" vor dem Timerstart eingebastelt. Längenprüfung, Stackanpassung und Co. habe ich nicht gemacht.
Ah, ok, Du machst es also erst wenn die WUN ankommt. Ich muss mir den Ablauf wohl noch mal anschauen, auch um zu sehen an welcher Stelle Rudis Vorschlag ansetzt.
So langsam gehen wir aber an die Feinheiten der Implementierung ,-)
Gruß,
Andreas.
Zitat von: A.Harrenberg am 17 November 2016, 21:07:36
die Wartezeit kann man ja über WNMI_delay "tunen" und an sein System anpassen, je nachdem ob man Notifies auf der WUN triggert oder nicht.
Ok, das waere dann der manuelle Weg, der mir eigentlich nicht gefaellt.
ZitatMulit_CMD verringert ja auf jeden Fall die Anzahl der Nachrichtenpakete und das macht sich auf Dauer schon bemerkbar.
Irgendwo gab es mal ein Übersicht, wieviel eine Nachricht an Energie verbraucht. Der Erinnerung nach war das nach Chipsaetzen getrennt ausgewiesen. Finde das aber nicht mehr.
Hi,
Zitat von: krikan am 17 November 2016, 21:23:42
Ok, das waere dann der manuelle Weg, der mir eigentlich nicht gefaellt.
aber wie willst Du denn eventuelle Notify abfangen wenn Du das Gerät sofort wieder schlafen schickst?
Man könnte mal darüber nachdenken die Default-Wartezeit (sind das momentan eigentlich 2 oder 2.5 sekunden??) auf z.B. 0.5 sekunden abzusenken, das sollte im Normalfall eigentlich immer für die Kommunikation reichen. Wer längere Notify hat muss dann die Zeit über WNMI_delay halt wieder hochsetzen.
Das meiste Sparpotenzial dürfte nach wir vor das WU-Intervall darstellen. Ob man alle möglichen Werte wirklich immer alle 15 Minuten benötigt sollte man immer in Frage stellen.
Gruß,
Andreas.
Zitat von: A.Harrenberg am 17 November 2016, 21:48:43
Hi,aber wie willst Du denn eventuelle Notify abfangen wenn Du das Gerät sofort wieder schlafen schickst?
Eines der vielen Probleme. Hatte schon mal darüber nachgedacht 0,5 Sek auf notifys zu warten und erst dann überhaupt Nachrichten per MULTI_CMD zu verschicken. Das dann aber wieder verworfen.
Je mehr ich über das Thema nachdenke, desto mehr Vorbehalte gegen MULTI_CMD bekomme ich.
Grundproblem: Komplexität erhöht sich für mich deutlich für eine unbekannte Batterieschonung und eventuelle Reduzierung der Funktelegramme.
Hi,
Zitat von: krikan am 18 November 2016, 11:07:17
Eines der vielen Probleme. Hatte schon mal darüber nachgedacht 0,5 Sek auf notifys zu warten und erst dann überhaupt Nachrichten per MULTI_CMD zu verschicken. Das dann aber wieder verworfen.
Ich würde die Probleme ja trennen und die WNMI da nicht mit reinnehmen.
Zitat von: krikan am 18 November 2016, 11:07:17
Je mehr ich über das Thema nachdenke, desto mehr Vorbehalte gegen MULTI_CMD bekomme ich.
Grundproblem: Komplexität erhöht sich für mich deutlich für eine unbekannte Batterieschonung und eventuelle Reduzierung der Funktelegramme.
Komplexität erhöht sich definitiv, Hauptersparnis liegt wohl auch eher beim Senden des Sensors. Wenn der z.B. alle 6 Sensorwerte in eine Nachricht reinbekommt das 6 einzelne Nachrichten zu verschicken dann hat das einen großen Einfluß. Im allgemeinen sollte sich bei Batteriegeräte (hoffentlich) nie viel im WU-Stack ansammeln, falls doch stimmt das Konzept nicht...
Aber an die Kapselung CRC16, MULTI_CMD, SECURITY, TRANSPORT_SERVICE müssen wir früher oder später trotzdem mal ran. Aber wie ich schon ganz zu Anfang mal schrieb, das sind mittlerweile echt Feinheiten, insgesamt haben wir hier schon ein recht gut laufendes System hingestellt!
Gruß,
Andreas.
ZitatIm allgemeinen sollte sich bei Batteriegeräte (hoffentlich) nie viel im WU-Stack ansammeln
Sehe ich anders: alles was der Benutzer absetzt, wenn ein Geraet "schlaeft", sammelt sich da. Auch wenn notifies auf WUN reagieren, landen die Befehle auf dem Stack. Ob eine Zusammenfassung viel bringt, kann ich pauschal nicht beurteilen, und haengt vmtl. auch vom Geraet ab.
Die anderen Kapselungen koennte man auch an dieser Stelle erledigen.
CRC16 sehe ich kritisch: da das CRC nicht auf der unteren Ebene geprueft wird, muss eine Wiederholung (wenn ueberhaupt) auf der oberen Ebene zusaetzlich implementiert werden, und hier gibt es keine Moeglichkeit einer Wiederholungs- oder "Kam falsch an"-Erkennung. Man kann also die Nachricht nur wegschmeissen, dafuer ist der Nutzwert mAn nicht besonders hoch.
Fuer CRC und MULTI_CMD gilt: wie "motiviere" ich die Gegenseite, diese Klassen fuer die gesendeten Nachrichten zu verwenden?
Hi,
Zitat von: rudolfkoenig am 18 November 2016, 12:18:12
Sehe ich anders: alles was der Benutzer absetzt, wenn ein Geraet "schlaeft", sammelt sich da. Auch wenn notifies auf WUN reagieren, landen die Befehle auf dem Stack. Ob eine Zusammenfassung viel bringt, kann ich pauschal nicht beurteilen, und haengt vmtl. auch vom Geraet ab.
natürlich landet das alles auf dem Stack, aber wer alle 15 Minuten alle Werte von allen Sensoren abfragt macht da vielleicht auch was falsch... WENN das natürlich jemand so macht, dann loht sich die Zusammenfassung sicherlich.
Zitat von: rudolfkoenig am 18 November 2016, 12:18:12
CRC16 sehe ich kritisch: da das CRC nicht auf der unteren Ebene geprueft wird, muss eine Wiederholung (wenn ueberhaupt) auf der oberen Ebene zusaetzlich implementiert werden, und hier gibt es keine Moeglichkeit einer Wiederholungs- oder "Kam falsch an"-Erkennung. Man kann also die Nachricht nur wegschmeissen, dafuer ist der Nutzwert mAn nicht besonders hoch.
Hmm, das ist unschön, da müsste man also schon low-level prüfen, was ja so nicht vorgesehen ist.
Zitat von: rudolfkoenig am 18 November 2016, 12:18:12
Fuer CRC und MULTI_CMD gilt: wie "motiviere" ich die Gegenseite, diese Klassen fuer die gesendeten Nachrichten zu verwenden?
Einfach hinschicken... :)
Devices supporting CRC-16 Encapsulation Command Class
A device that supports the CRC-16 Encapsulation Command Class MAY receive a combination of encapsulated and normal non-encapsulated requests and the response MUST be as follows:
a) If the request is sent encapsulated, the response MUST be returned encapsulated.
b) If the request is sent non-encapsulated, the response MUST be sent non-encapsulated.A device that supports the Multi Command Command Class MAY receive a combination of encapsulated and normal non-encapsulated requests over time. The response MUST be as follows:
a) If the request is sent encapsulated, the response MUST be returned encapsulated.
b) If the request is sent non-encapsulated, the response MUST also be sent non-encapsulated.Gruß,
Andreas.
Zitat von: rudolfkoenig am 18 November 2016, 12:18:12
CRC16 sehe ich kritisch: da das CRC nicht auf der unteren Ebene geprueft wird, muss eine Wiederholung (wenn ueberhaupt) auf der oberen Ebene zusaetzlich implementiert werden, und hier gibt es keine Moeglichkeit einer Wiederholungs- oder "Kam falsch an"-Erkennung. Man kann also die Nachricht nur wegschmeissen, dafuer ist der Nutzwert mAn nicht besonders hoch.
CRC16 fände ich recht nützlich:
Wenn die "kaputten" Nachrichten aussortiert, geloggt und nicht verarbeitet würden, dann gäbe es u.a. keine merkwürdigen Events und Readings sowie keine unnötige Device-Anlage durch autocreate. Damit auch keine negative Beeinflußung im Frontend und Verwirrung beim User. Zudem kann man "kaputte" Nachrichten eindeutig identifizieren und braucht nicht mehr nur vermuten, wie hier im Thread. Eine Möglichkeit der Wiederholung finde ich nicht so wichtig. Das wäre erst der zweite Schritt.
Zitat von: A.Harrenberg am 18 November 2016, 12:51:57
Einfach hinschicken... :)
Wenn das mal so einfach ist: Was passiert bei den spontanen Nachrichten der Geräte; wann werden die CRC16 geschützt?
Beim Fibaro FGMS mit der alten Firmware war meine Beobachtung beim ZWCul-Test:
HC empfängt spontane Nachrichten, die CRC16 geschützt waren.
FHEM empfängt gleiche spontane Nachricht ohne CRC16 Schutz.
Habe es nicht intensiv betrachtet, da meine Zielrichtung damals eine andere war, aber:
Ist das ein Zufall, Geräte-Besonderheit, habe ich falsch analysiert oder gibt es ein unbekanntes System, das ich nicht kenne? In zwapi finde ich nichts dazu.
Auch wenn das hier leider mein Wissens Level überschreitet....
Meine Erfahrung, und jetzt bleibe ich bei dem "leidigen" Gerät, sagt auch mit 3-4 Meter Sichtweite vom UZB zum LC-13 gibt es immer wieder
ZWDongle_0 transmit NO_ACK for CB 08, target ThermostatWohnzimmerDas Ganze läuft hier jetzt fast ein Jahr, eigentlich stabil. Die anderen LC-13 die durch mehrere Wände teils erst zu erreichen sind, genauso. Mal mehr mal weniger.
Eine Lokale umsetztung des Controllers in ca. 2 Meter höhe über einen Zeitraum von gut 4 Wochen im Sommer hat nicht besser funktioniert. Was das angeht.
Die Thermostate werden alle 30 Minuten nach Batterie abgefragt. Ob das wirklich so muss sei dahingestellt. Allerdings werden NUR so wirklich regelmäßig die Battery Readings aktualisiert.
Mit 300 Sekunden wakupInterwal gibt es "etwas" weniger NO_ACK's, im Moment probiere ich mich an die untere Grenze des wakupInterwals zu tasten, einfach nur so.
Batterie Spielt jetzt keine Rolle. Bei 60 Sekunden läuft der Log voll damit, bei 150 Momentan ist es deutlich weniger. Aber ganz ohne NIE.
Die Fibaro Jungs lassen die z.T. mit 60 Sekunden laufen, es gibt so in dem UI des HC2 immer wieder "rote" Fehlermeldungen zu dem Thermostaten, leider weiss ich den Wortlaut nich mehr.
Das stört die aber gar nicht.
Anderseits wenn ich immer mehrerer Befehle zugleich absetzten soll frage ich wie das dann funktionieren soll.
Beispiel der Batt Abfrage liegt doch auf dem Sendstack, wass soll da noch mit rein wenn nur das gewollt wird.
@A.Harrenberg
Zitatnatürlich landet das alles auf dem Stack, aber wer alle 15 Minuten alle Werte von allen Sensoren abfragt macht da vielleicht auch was falsch...
Sorry aber das finde ich Quatsch, allerdings ohne des hintergrundwissens zu fhem.
Die Meisten Sensoren senden ihre Werte doch selbstätig. Darf mann da nicht noch eine Abfrage dazu starten?
ZWDongle_0 transmit NO_ACK for CB 08, target ThermostatWohnzimmer
Ist Dir bekannt, auf welche Nachricht von FHEM die LC-13 die NO_ACK liefern?
Wenn es die "WakeupNoMoreInformation"-Nachricht (=Gehe schlafen LC-13) ist, dann experimentiere mal mit einer Verkürzung der Wachzeit mit dem Attribut WNMI_delay. Oder hast Du das schon gemacht?
Die Batterieabfrage ist vielleicht nicht notwendig, wenn WNMI_delay kurz genug ist:
Es gibt Sensoren, die sich ohne Nachricht von FHEM nach einem Wakeup und vor Versand der WNMI durch FHEM nach 2 Sekunden schon wieder schlafen gelegt haben. Die WNMI-Nachricht von FHEM endet dann zwangsläufig mit NO_ACK.
Erhalten diese Sensoren aber nach dem Wakeup unverzüglich eine Nachricht (hier battery-Abfrage) verlängert sich deren Wachzeit deutlich und die WNMI-Nachricht von FHEM kommt zumeist vor dem automatischen "Schlafen gehen" an.
Den Einfluss einer Verkürzung des wakeUpIntervals auf NO_ACK erkenne ich nicht. Ausschließen kann ich es aber auch nicht.
Anderseits wenn ich immer mehrerer Befehle zugleich absetzten soll frage ich wie das dann funktionieren soll.
Beispiel der Batt Abfrage liegt doch auf dem Sendstack, wass soll da noch mit rein wenn nur das gewollt wird.
Gleichzeitig mit der Batterieabfrage kann man in einer Nachricht mit MULTI_CMD noch den WNMI-Befehl verschicken = kurzestmögliche Wachzeit. Entfernt ähnlicher Effekt wie Verkürzung WNMI_delay.
Hi,
Zitat von: tomspatz am 18 November 2016, 14:36:26
Meine Erfahrung, und jetzt bleibe ich bei dem "leidigen" Gerät, sagt auch mit 3-4 Meter Sichtweite vom UZB zum LC-13 gibt es immer wieder ZWDongle_0 transmit NO_ACK for CB 08, target ThermostatWohnzimmer
irgendwie scheinen einige Geräte empfindlicher gegen Störungen zu sein als andere, und der LC-13 scheint ein solcher Kandidat zu sein, der verhält sich ja schon im Normalzustand merkwürdig.
Zitat von: tomspatz am 18 November 2016, 14:36:26
Die Thermostate werden alle 30 Minuten nach Batterie abgefragt. Ob das wirklich so muss sei dahingestellt. Allerdings werden NUR so wirklich regelmäßig die Battery Readings aktualisiert.
Mit 300 Sekunden wakupInterwal gibt es "etwas" weniger NO_ACK's, im Moment probiere ich mich an die untere Grenze des wakupInterwals zu tasten, einfach nur so.
Batterie Spielt jetzt keine Rolle. Bei 60 Sekunden läuft der Log voll damit, bei 150 Momentan ist es deutlich weniger. Aber ganz ohne NIE.
Die Fibaro Jungs lassen die z.T. mit 60 Sekunden laufen, es gibt so in dem UI des HC2 immer wieder "rote" Fehlermeldungen zu dem Thermostaten, leider weiss ich den Wortlaut nich mehr.
Das stört die aber gar nicht.
Anderseits wenn ich immer mehrerer Befehle zugleich absetzten soll frage ich wie das dann funktionieren soll.
Beispiel der Batt Abfrage liegt doch auf dem Sendstack, wass soll da noch mit rein wenn nur das gewollt wird.
@A.HarrenbergSorry aber das finde ich Quatsch, allerdings ohne des hintergrundwissens zu fhem.
Die Meisten Sensoren senden ihre Werte doch selbstätig. Darf mann da nicht noch eine Abfrage dazu starten?
Was ich damit nur sagen wollte:
Die meisten Leute "übertreiben" es mit Ihren Logs/Abfragen an Sensoren. Wenn Du alle 30 Minuten die Batterie abfragst ist das eigentlich völlig übertrieben und auch kontraproduktiv, da dies ja den Batterieverbrauch in die Höhe treibt. Wenn das beim LC-13 in diesem kurzen Abstand sein muss damit er intern nicht abstürzt, dann hat das in diesem Fall zwar einen wichtigen Grund, sollte aber eigentlich nicht so sein wenn das dumme Ding richtig funktionieren würde. Eine Abfrage der Batterie einmal pro Tag oder vielleicht sogar nur einmal pro Woche sollte dann ja eigentlich reichen, die geben ja nicht urplötzlich auf.
Ein WakeUp-Interval von 300 Sekunden ist auch sehr kurz, bei den üblichen Trägheiten einer Heizung sollten z.B. auch 15 Minuten reichen, solange man den normalen Temperaturverlauf "autark" im Thermostaten laufen lässt. Meine Thermostate sind von Homematic, die können mit einem Funk-Burst aufgeweckt werden, das ist für so eine Anwendung natürlich ideal. Bei ZWave könnte man das mit sogenannten FLIRS (Frequent Listening) machen, das gibt es wohl schon bei Rauchmeldern, bei Thermostaten habe ich das aber bisher noch nicht gesehen.
Das dies beim LC-13 nicht alles umzusetzen ist weil das Ding einfach "speziell" ist, stellt sicherlich einen Sonderfall dar. Natürlich darfst man auch noch Abfragen wie z.B. Batterie machen, mein "falsch machen" bezog sich darauf die meisten Leute dazu tendieren zu häufig und zu viele Werte abzufragen. Ich habe hier so einen AEOTEC 6 Multisensor, der kann z.B. Luminance und ultraviolet Werte senden. Nur für sehr wenig Leute ist das WIRKLICH wichtig, also nicht abfragen und so konfigurieren das es gar nicht erst gesendet wird. Wenn man den Bewegungsmelder abhängig von der aktuellen Helligkeit z.B. zur Steuerung einer Gehweglampe nutzen möchte, dann benötigt man den Wert natürlich.
Gruß,
Andreas.
@krikan
ZitatIst Dir bekannt, auf welche Nachricht von FHEM die LC-13 die NO_ACK liefern?
Wie finde ich das raus?
Zitat von: tomspatz am 21 November 2016, 16:45:50
Wie finde ich das raus?
Setze das Attribut verbose beim ZWDongle-Device auf 5 und warte bis NO_ACK kommt. Dann im Log die zugehörige Stelle bzw. die abgesetzte Nachricht suchen. Oder den betreffenden Logauszug am Besten mit mehreren NO_ACK-Vorkommnissen hier in einem Post anhängen. Normalerweise hilft schon jemand.
Moin, habe nun etwas gesammelt, bitte auf "ThermostatBuero" achten.
Das ist einer von fünfen der vorhandenen LC-13.
2016.12.01 07:15:42 5: device ack reveived, removing 010900130702840825256c from dongle sendstack
2016.12.01 07:15:42 5: ZWDongle_0 dispatch 001325000006
2016.12.01 07:15:42 4: CMD:ZW_SEND_DATA ID:00 ARG:0006 CB:25
2016.12.01 07:15:42 4: ZWDongle_0 transmit OK for CB 25, target ThermostatBuero
2016.12.01 07:15:52 4: ZWDongle_Read ZWDongle_0: rcvd 00040021063105012200b7 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:52 5: SW: 06
2016.12.01 07:15:52 5: ZWDongle_0 dispatch 00040021063105012200b7
2016.12.01 07:15:52 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:063105012200b7 CB:00
2016.12.01 07:15:53 4: ZWDongle_Read ZWDongle_0: rcvd 0004002105310505013c (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:53 5: SW: 06
2016.12.01 07:15:53 5: ZWDongle_0 dispatch 0004002105310505013c
2016.12.01 07:15:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:05310505013c CB:00
2016.12.01 07:15:54 4: ZWDongle_Read ZWDongle_0: rcvd 0004002103800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:54 5: SW: 06
2016.12.01 07:15:54 5: ZWDongle_0 dispatch 0004002103800364
2016.12.01 07:15:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:03800364 CB:00
2016.12.01 07:15:58 4: ZWDongle_Read ZWDongle_0: rcvd 00040021063105030a0000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:58 5: SW: 06
2016.12.01 07:15:58 5: ZWDongle_0 dispatch 00040021063105030a0000
2016.12.01 07:15:58 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:063105030a0000 CB:00
2016.12.01 07:15:58 4: ZWDongle_Read ZWDongle_0: rcvd 00040021028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:58 5: SW: 06
2016.12.01 07:15:58 5: ZWDongle_0 dispatch 00040021028407
2016.12.01 07:15:58 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:028407 CB:00
2016.12.01 07:16:00 5: ZWDongle_Write 0013210284082526 (c9cc092a)
2016.12.01 07:16:00 5: SW: 0109001321028408252649
2016.12.01 07:16:00 5: ACK received, WaitForAck=>2 for 0109001321028408252649
2016.12.01 07:16:00 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:16:00 5: SW: 06
2016.12.01 07:16:00 5: ZWDongle_0 dispatch 011301
2016.12.01 07:16:00 4: ZWDongle_Read ZWDongle_0: rcvd 001326000002 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:16:00 5: SW: 06
2016.12.01 07:16:00 5: device ack reveived, removing 0109001321028408252649 from dongle sendstack
2016.12.01 07:16:00 5: ZWDongle_0 dispatch 001326000002
2016.12.01 07:16:00 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:26
2016.12.01 07:16:00 4: ZWDongle_0 transmit OK for CB 26, target Multisensor_01
2016.12.01 07:16:14 4: ZWDongle_Read ZWDongle_0: rcvd 0004002d0e3202216400000780007800000780 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:14 5: SW: 06
2016.12.01 07:16:14 5: ZWDongle_0 dispatch 0004002d0e3202216400000780007800000780
2016.12.01 07:16:14 4: CMD:APPLICATION_COMMAND_HANDLER ID:2d ARG:0e3202216400000780007800000780 CB:00
2016.12.01 07:16:28 4: ZWDongle_Read ZWDongle_0: rcvd 000400100380033c (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:28 5: SW: 06
2016.12.01 07:16:28 5: ZWDongle_0 dispatch 000400100380033c
2016.12.01 07:16:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0380033c CB:00
2016.12.01 07:16:28 4: ZWDongle_Read ZWDongle_0: rcvd 000400100643030142079e (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:28 5: SW: 06
2016.12.01 07:16:28 5: ZWDongle_0 dispatch 000400100643030142079e
2016.12.01 07:16:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0643030142079e CB:00
2016.12.01 07:16:28 4: ZWDongle_Read ZWDongle_0: rcvd 00040010044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:28 5: SW: 06
2016.12.01 07:16:28 5: ZWDongle_0 dispatch 00040010044608007f
2016.12.01 07:16:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:044608007f CB:00
2016.12.01 07:16:28 4: ZWDongle_Read ZWDongle_0: rcvd 00040010028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:28 5: SW: 06
2016.12.01 07:16:28 5: ZWDongle_0 dispatch 00040010028407
2016.12.01 07:16:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:028407 CB:00
2016.12.01 07:16:30 5: ZWDongle_Write 0013100284082527 (c9cc092a)
2016.12.01 07:16:30 5: SW: 0109001310028408252779
2016.12.01 07:16:30 5: ACK received, WaitForAck=>2 for 0109001310028408252779
2016.12.01 07:16:30 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:16:30 5: SW: 06
2016.12.01 07:16:30 5: ZWDongle_0 dispatch 011301
2016.12.01 07:16:30 4: ZWDongle_Read ZWDongle_0: rcvd 001327000002 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:16:30 5: SW: 06
2016.12.01 07:16:30 5: device ack reveived, removing 0109001310028408252779 from dongle sendstack
2016.12.01 07:16:30 5: ZWDongle_0 dispatch 001327000002
2016.12.01 07:16:30 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:27
2016.12.01 07:16:30 4: ZWDongle_0 transmit OK for CB 27, target ThermostatKueche
2016.12.01 07:16:41 4: ZWDongle_Read ZWDongle_0: rcvd 0004001f0c600d020231050144000007b7 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:41 5: SW: 06
2016.12.01 07:16:41 5: ZWDongle_0 dispatch 0004001f0c600d020231050144000007b7
2016.12.01 07:16:41 4: CMD:APPLICATION_COMMAND_HANDLER ID:1f ARG:0c600d020231050144000007b7 CB:00
2016.12.01 07:16:57 4: ZWDongle_Read ZWDongle_0: rcvd 0004000e0c600d020231050144000007d6 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:57 5: SW: 06
2016.12.01 07:16:57 5: ZWDongle_0 dispatch 0004000e0c600d020231050144000007d6
2016.12.01 07:16:57 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:0c600d020231050144000007d6 CB:00
2016.12.01 07:17:03 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0c600d02023105014400000a15 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:03 5: SW: 06
2016.12.01 07:17:03 5: ZWDongle_0 dispatch 0004001a0c600d02023105014400000a15
2016.12.01 07:17:03 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0c600d02023105014400000a15 CB:00
2016.12.01 07:17:18 4: ZWDongle_Read ZWDongle_0: rcvd 000400190c600d0202310501440000070e (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:18 5: SW: 06
2016.12.01 07:17:18 5: ZWDongle_0 dispatch 000400190c600d0202310501440000070e
2016.12.01 07:17:19 4: CMD:APPLICATION_COMMAND_HANDLER ID:19 ARG:0c600d0202310501440000070e CB:00
2016.12.01 07:17:22 4: ZWDongle_Read ZWDongle_0: rcvd 0004000903800333 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:22 5: SW: 06
2016.12.01 07:17:22 5: ZWDongle_0 dispatch 0004000903800333
2016.12.01 07:17:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:03800333 CB:00
2016.12.01 07:17:22 4: ZWDongle_Read ZWDongle_0: rcvd 0004000906430301420834 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:22 5: SW: 06
2016.12.01 07:17:22 5: ZWDongle_0 dispatch 0004000906430301420834
2016.12.01 07:17:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:06430301420834 CB:00
2016.12.01 07:17:22 4: ZWDongle_Read ZWDongle_0: rcvd 00040009044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:22 5: SW: 06
2016.12.01 07:17:22 5: ZWDongle_0 dispatch 00040009044608007f
2016.12.01 07:17:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:044608007f CB:00
2016.12.01 07:17:22 4: ZWDongle_Read ZWDongle_0: rcvd 00040009028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:22 5: SW: 06
2016.12.01 07:17:22 5: ZWDongle_0 dispatch 00040009028407
2016.12.01 07:17:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407 CB:00
2016.12.01 07:17:24 5: ZWDongle_Write 0013090284082528 (c9cc092a)
2016.12.01 07:17:25 5: SW: 010900130902840825286f
2016.12.01 07:17:25 5: ACK received, WaitForAck=>2 for 010900130902840825286f
2016.12.01 07:17:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:17:25 5: SW: 06
2016.12.01 07:17:25 5: ZWDongle_0 dispatch 011301
2016.12.01 07:17:25 4: ZWDongle_Read ZWDongle_0: rcvd 001328000002 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:17:25 5: SW: 06
2016.12.01 07:17:25 5: device ack reveived, removing 010900130902840825286f from dongle sendstack
2016.12.01 07:17:25 5: ZWDongle_0 dispatch 001328000002
2016.12.01 07:17:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:28
2016.12.01 07:17:25 4: ZWDongle_0 transmit OK for CB 28, target ThermostatWohnzimmer
2016.12.01 07:17:37 4: ZWDongle_Read ZWDongle_0: rcvd 0004000803800336 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:37 5: SW: 06
2016.12.01 07:17:37 5: ZWDongle_0 dispatch 0004000803800336
2016.12.01 07:17:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:03800336 CB:00
2016.12.01 07:17:37 4: ZWDongle_Read ZWDongle_0: rcvd 0004000806430301420708 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:37 5: SW: 06
2016.12.01 07:17:37 5: ZWDongle_0 dispatch 0004000806430301420708
2016.12.01 07:17:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:06430301420708 CB:00
2016.12.01 07:17:37 4: ZWDongle_Read ZWDongle_0: rcvd 00040008044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:37 5: SW: 06
2016.12.01 07:17:37 5: ZWDongle_0 dispatch 00040008044608007f
2016.12.01 07:17:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:044608007f CB:00
2016.12.01 07:17:37 4: ZWDongle_Read ZWDongle_0: rcvd 00040008028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:37 5: SW: 06
2016.12.01 07:17:37 5: ZWDongle_0 dispatch 00040008028407
2016.12.01 07:17:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:028407 CB:00
2016.12.01 07:17:38 4: ZWDongle_Read ZWDongle_0: rcvd 00040029063105012200cf (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:38 5: SW: 06
2016.12.01 07:17:38 5: ZWDongle_0 dispatch 00040029063105012200cf
2016.12.01 07:17:38 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:063105012200cf CB:00
2016.12.01 07:17:39 5: ZWDongle_Write 0013080284082529 (c9cc092a)
2016.12.01 07:17:39 5: SW: 010900130802840825296f
2016.12.01 07:17:39 5: ACK received, WaitForAck=>2 for 010900130802840825296f
2016.12.01 07:17:39 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:17:39 5: SW: 06
2016.12.01 07:17:39 5: ZWDongle_0 dispatch 011301
2016.12.01 07:17:39 4: ZWDongle_Read ZWDongle_0: rcvd 001329000008 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:17:39 5: SW: 06
2016.12.01 07:17:39 5: device ack reveived, removing 010900130802840825296f from dongle sendstack
2016.12.01 07:17:39 5: ZWDongle_0 dispatch 001329000008
2016.12.01 07:17:39 4: CMD:ZW_SEND_DATA ID:00 ARG:0008 CB:29
2016.12.01 07:17:39 4: ZWDongle_0 transmit OK for CB 29, target ThermostatSchlafzimmer
2016.12.01 07:17:39 4: ZWDongle_Read ZWDongle_0: rcvd 00040029053105050132 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:39 5: SW: 06
2016.12.01 07:17:39 5: ZWDongle_0 dispatch 00040029053105050132
2016.12.01 07:17:39 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:053105050132 CB:00
2016.12.01 07:17:41 4: ZWDongle_Read ZWDongle_0: rcvd 0004002903800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:41 5: SW: 06
2016.12.01 07:17:41 5: ZWDongle_0 dispatch 0004002903800364
2016.12.01 07:17:41 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:03800364 CB:00
2016.12.01 07:17:45 4: ZWDongle_Read ZWDongle_0: rcvd 00040029063105030a0000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:45 5: SW: 06
2016.12.01 07:17:45 5: ZWDongle_0 dispatch 00040029063105030a0000
2016.12.01 07:17:45 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:063105030a0000 CB:00
2016.12.01 07:17:45 4: ZWDongle_Read ZWDongle_0: rcvd 00040029028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:45 5: SW: 06
2016.12.01 07:17:45 5: ZWDongle_0 dispatch 00040029028407
2016.12.01 07:17:45 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:028407 CB:00
2016.12.01 07:17:47 5: ZWDongle_Write 001329028408252a (c9cc092a)
2016.12.01 07:17:47 5: SW: 0109001329028408252a4d
2016.12.01 07:17:47 5: ACK received, WaitForAck=>2 for 0109001329028408252a4d
2016.12.01 07:17:47 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:17:47 5: SW: 06
2016.12.01 07:17:47 5: ZWDongle_0 dispatch 011301
2016.12.01 07:17:47 4: ZWDongle_Read ZWDongle_0: rcvd 00132a00000f (request ZW_SEND_DATA), sending ACK
2016.12.01 07:17:47 5: SW: 06
2016.12.01 07:17:47 5: device ack reveived, removing 0109001329028408252a4d from dongle sendstack
2016.12.01 07:17:47 5: ZWDongle_0 dispatch 00132a00000f
2016.12.01 07:17:47 4: CMD:ZW_SEND_DATA ID:00 ARG:000f CB:2a
2016.12.01 07:17:47 4: ZWDongle_0 transmit OK for CB 2a, target Multisensor_02
2016.12.01 07:18:11 4: ZWDongle_Read ZWDongle_0: rcvd 0004002e03250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:11 5: SW: 06
2016.12.01 07:18:11 5: ZWDongle_0 dispatch 0004002e03250300
2016.12.01 07:18:11 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:03250300 CB:00
2016.12.01 07:18:14 4: ZWDongle_Read ZWDongle_0: rcvd 0004002d0e3202216400000780007800000780 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:14 5: SW: 06
2016.12.01 07:18:14 5: ZWDongle_0 dispatch 0004002d0e3202216400000780007800000780
2016.12.01 07:18:14 4: CMD:APPLICATION_COMMAND_HANDLER ID:2d ARG:0e3202216400000780007800000780 CB:00
2016.12.01 07:18:15 4: ZWDongle_Read ZWDongle_0: rcvd 000400210a7105000000ff07000000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:15 5: SW: 06
2016.12.01 07:18:15 5: ZWDongle_0 dispatch 000400210a7105000000ff07000000
2016.12.01 07:18:15 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:0a7105000000ff07000000 CB:00
2016.12.01 07:18:16 4: ZWDongle_Read ZWDongle_0: rcvd 00040032097105000000ff070800 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:16 5: SW: 06
2016.12.01 07:18:16 5: ZWDongle_0 dispatch 00040032097105000000ff070800
2016.12.01 07:18:16 4: CMD:APPLICATION_COMMAND_HANDLER ID:32 ARG:097105000000ff070800 CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800336 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 0004002803800336
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800336 CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 0004002806430301420866 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 0004002806430301420866
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:06430301420866 CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 00040028044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 00040028044608007f
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:044608007f CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 00040028028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 00040028028407
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:028407 CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 0004002103200100 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 0004002103200100
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:03200100 CB:00
2016.12.01 07:18:19 5: ZWDongle_Write 001328028408252b (c9cc092a)
2016.12.01 07:18:19 5: SW: 0109001328028408252b4d
2016.12.01 07:18:19 5: ACK received, WaitForAck=>2 for 0109001328028408252b4d
2016.12.01 07:18:19 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:18:19 5: SW: 06
2016.12.01 07:18:19 5: ZWDongle_0 dispatch 011301
2016.12.01 07:18:19 4: ZWDongle_Read ZWDongle_0: rcvd 00132b000002 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:18:19 5: SW: 06
2016.12.01 07:18:19 5: device ack reveived, removing 0109001328028408252b4d from dongle sendstack
2016.12.01 07:18:19 5: ZWDongle_0 dispatch 00132b000002
2016.12.01 07:18:19 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:2b
2016.12.01 07:18:19 4: ZWDongle_0 transmit OK for CB 2b, target ThermostatBad
2016.12.01 07:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e032503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:25 5: SW: 06
2016.12.01 07:18:25 5: ZWDongle_0 dispatch 0004001e032503ff
2016.12.01 07:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:032503ff CB:00
2016.12.01 07:18:36 4: ZWDongle_Read ZWDongle_0: rcvd 0004000703800334 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:36 5: SW: 06
2016.12.01 07:18:36 5: ZWDongle_0 dispatch 0004000703800334
2016.12.01 07:18:36 4: CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:03800334 CB:00
2016.12.01 07:18:37 4: ZWDongle_Read ZWDongle_0: rcvd 0004000706430301420802 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:37 5: SW: 06
2016.12.01 07:18:37 5: ZWDongle_0 dispatch 0004000706430301420802
2016.12.01 07:18:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:06430301420802 CB:00
2016.12.01 07:18:37 4: ZWDongle_Read ZWDongle_0: rcvd 00040007044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:37 5: SW: 06
2016.12.01 07:18:37 5: ZWDongle_0 dispatch 00040007044608007f
2016.12.01 07:18:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:044608007f CB:00
2016.12.01 07:18:37 4: ZWDongle_Read ZWDongle_0: rcvd 00040007028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:37 5: SW: 06
2016.12.01 07:18:37 5: ZWDongle_0 dispatch 00040007028407
2016.12.01 07:18:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:028407 CB:00
2016.12.01 07:18:39 5: ZWDongle_Write 001307028408252c (c9cc092a)
2016.12.01 07:18:39 5: SW: 0109001307028408252c65
2016.12.01 07:18:39 5: ACK received, WaitForAck=>2 for 0109001307028408252c65
2016.12.01 07:18:39 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:18:39 5: SW: 06
2016.12.01 07:18:39 5: ZWDongle_0 dispatch 011301
2016.12.01 07:18:41 4: no response from device, removing 0109001307028408252c65 from dongle sendstack
2016.12.01 07:18:46 4: ZWDongle_Read ZWDongle_0: rcvd 00132c0102ac (request ZW_SEND_DATA), sending ACK
2016.12.01 07:18:46 5: SW: 06
2016.12.01 07:18:46 5: ZWDongle_0 dispatch 00132c0102ac
2016.12.01 07:18:46 4: CMD:ZW_SEND_DATA ID:01 ARG:02ac CB:2c
2016.12.01 07:18:46 2: ZWDongle_0 transmit NO_ACK for CB 2c, target ThermostatBuero
2016.12.01 07:18:46 4: ZWDongle_Read ZWDongle_0: rcvd 000400110a32022144000001050000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:46 5: SW: 06
2016.12.01 07:18:46 5: ZWDongle_0 dispatch 000400110a32022144000001050000
2016.12.01 07:18:46 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:0a32022144000001050000 CB:00
2016.12.01 07:18:46 4: ZWDongle_Read ZWDongle_0: rcvd 000400320a7105000000ff07000108 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:46 5: SW: 06
2016.12.01 07:18:46 5: ZWDongle_0 dispatch 000400320a7105000000ff07000108
2016.12.01 07:18:46 4: CMD:APPLICATION_COMMAND_HANDLER ID:32 ARG:0a7105000000ff07000108 CB:00
2016.12.01 07:18:53 4: ZWDongle_Read ZWDongle_0: rcvd 000400120c600d020231050144000001c2 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:53 5: SW: 06
2016.12.01 07:18:53 5: ZWDongle_0 dispatch 000400120c600d020231050144000001c2
2016.12.01 07:18:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:0c600d020231050144000001c2 CB:00
2016.12.01 07:18:56 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e03250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:56 5: SW: 06
2016.12.01 07:18:56 5: ZWDongle_0 dispatch 0004001e03250300
2016.12.01 07:18:56 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:03250300 CB:00
2016.12.01 07:19:01 4: ZWDongle_Read ZWDongle_0: rcvd 00040032097105000000ff070800 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:19:01 5: SW: 06
2016.12.01 07:19:01 5: ZWDongle_0 dispatch 00040032097105000000ff070800
2016.12.01 07:19:01 4: CMD:APPLICATION_COMMAND_HANDLER ID:32 ARG:097105000000ff070800 CB:00
Dort ist einmal NO_ACK auf die verschickte "WakeupNoMoreInformation"-Nachricht enthalten.
Wenn NO_ACK nur selten vorkommt, könnten das Funktelegrammverluste oder ander Besonderheiten sein.
Wenn das regelmäßig vorkommt würde ich, wie in #33 geschrieben:
Zitat
Wenn es die "WakeupNoMoreInformation"-Nachricht (=Gehe schlafen LC-13) ist, dann experimentiere mal mit einer Verkürzung der Wachzeit mit dem Attribut WNMI_delay.
Würde nach Deinem Log passen, da 2 Sek. nach WakeupNotification die WakeupNorMoreInformation-Nachricht mit NO_ACK-Antwort verschickt wird und sonst keine Kommunikation mit dem Gerät stattfindet. Also WNMI_delay bspw. auf 1 Sekunde setzen, beobachten und bitte berichten.
Wenn Verkürzung des WMNI_delay bei den LC-13 hilft, dann ist des allgemein interessant.
Ja moin
du bist ja fix :)
Vielen dank dafür erstmal.
Ich werde testen und berichten.
Grundsätzlich kommen die NO_ACK Nachrichten hier quer Beet alle Weile, doch fast ausschlieslich von Wakeup-Geräten.
Da möchte ich nicht unbedingt die LC-13 extrem schlecht tun. Die laufen wirklich gut mitlerweile.
Scheinbar auch ohne:
ZitatDas Danfoss Heizungsthermostat LC-13 muss derzeit zur korrekten Funktion mit FHEM regelmäßig mit folgendem at abgefragt werden (Beitrag):
define Atdanfoss at +*00:30 get <name> battery
Dafür habe ich jetzt allerdings ohne des at's weniger von den NO_ACK's.
Da ja Funkinformationen immer MAL verloren gehen könne sehe ich das nicht so sehr wenn sie sporadisch kommen, die devices allerdings funktionieren.
Doch kann man da ja sicherlich optimieren.
LG
Tom
Das lässt mir alles keine Ruhe.
Bin mit WNMI_delay am testen mit 1 bzw. jetzt mit 0.2 aber das sieht alles nicht viel anders aus.
Ist es evtl. möglich das die Nachrichten die hin und her gesendet werden irgendwie "andere" Wege nehmen?
Habe massig die NO_ACK oft mehrfach nacheinander dann wieder stundenlang gar nicht, trotzdem läuft das alles.
Teils auch :
ERROR: cannot SEND_DATA to ThermostatSchlafzimmer: transmit queue overflow
trotzdem läuft es ja. Das zeitgesteuerte setzten der jeweiligen Temperaturen checken die LC-13 fix, nachdem sie wach sin.
SORRY das nervt irgendwie komme ich nicht weiter.
LG
Tom
Zitat von: tomspatz am 05 Dezember 2016, 18:53:12
Ist es evtl. möglich das die Nachrichten die hin und her gesendet werden irgendwie "andere" Wege nehmen?
Grunsaetzlich möglich. Jedoch mMn nicht der Standardfall.
ZitatHabe massig die NO_ACK oft mehrfach nacheinander dann wieder stundenlang gar nicht, trotzdem läuft das alles.
Teils auch :
ERROR: cannot SEND_DATA to ThermostatSchlafzimmer: transmit queue overflow
trotzdem läuft es ja. Das zeitgesteuerte setzten der jeweiligen Temperaturen checken die LC-13 fix, nachdem sie wach sin.
SORRY das nervt irgendwie komme ich nicht weiter.
Du musst ein System der NO_ACK und ERROR suchen und finden. Erst dann kann man tatsaechlich Rückschlüsse ziehen und vielleicht Abhilfe schaffen. Wenn es keine Regelmaeßigkeit gibt, dann wird es sehr schwierig.
Wenn es laeuft, kann man es auch ignorieren. Dennoch interessiert mich aus reiner Neugierde die Ursache.
Guck mal bitte in diesen Abschnitt:
2016.12.05 16:31:39 2: ZWDongle_0 transmit NO_ACK for CB 8c, target ThermostatBuero
2016.12.05 17:46:20 3: ZWave set LichtFlurSpiegel on
2016.12.05 17:46:50 3: ZWave set LichtKueche on
2016.12.05 17:48:16 2: ZWDongle_0 transmit NO_ACK for CB 24, target ThermostatBuero
2016.12.05 17:48:35 3: ZWave set LichtBad_30.02 on
2016.12.05 17:48:40 3: ZWave set LichtBad_30.02 off
2016.12.05 17:54:09 2: ZWDongle_0 transmit NO_ACK for CB 30, target ThermostatBuero
2016.12.05 17:59:48 2: ROOMMATE set rr_Tom absent
2016.12.05 18:00:39 2: ROOMMATE set rr_Tom home
2016.12.05 18:02:57 2: ZWDongle_0 transmit NO_ACK for CB 41, target ThermostatBuero
2016.12.05 18:11:09 3: ZWave set LichtBad_30.02 on
2016.12.05 18:11:14 3: ZWave set LichtBad_30.02 off
2016.12.05 18:23:49 3: ZWave set LichtBad_30.02 on
2016.12.05 18:23:54 3: ZWave set LichtBad_30.02 off
2016.12.05 18:24:09 3: ZWave set LichtSchlafzimmerSchrank1A on
2016.12.05 18:26:28 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900130702840825743d
2016.12.05 18:26:35 2: ZWDongle_0 transmit NO_ACK for CB 75, target ThermostatBuero
2016.12.05 18:47:12 2: ZWDongle_0 transmit NO_ACK for CB 9d, target ThermostatBuero
2016.12.05 18:54:41 2: ZWDongle_0 transmit NO_ACK for CB ac, target FensterBuero
2016.12.05 19:01:56 2: ZWDongle_0 transmit NO_ACK for CB ba, target ThermostatBuero
2016.12.05 19:08:06 3: ZWave set ThermostatWohnzimmer thermostatSetpointSet 12.00
2016.12.05 19:08:06 3: set ThermostatWohnzimmer thermostatSetpointSet 12.00 : Scheduled for sending after WAKEUP
2016.12.05 19:08:06 3: HeizungReglerNotifyWohnzimmer return value: Scheduled for sending after WAKEUP
2016.12.05 19:08:25 3: ZWave set ThermostatWohnzimmer thermostatSetpointSet 22.50
2016.12.05 19:08:25 3: set ThermostatWohnzimmer thermostatSetpointSet 22.50 : Scheduled for sending after WAKEUP
2016.12.05 19:08:25 3: HeizungReglerNotifyWohnzimmer return value: Scheduled for sending after WAKEUP
2016.12.05 19:10:40 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900130702840825cb82
2016.12.05 19:10:47 2: ZWDongle_0 transmit NO_ACK for CB cc, target ThermostatBuero
2016.12.05 19:11:20 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900132802840825cdab
2016.12.05 19:11:21 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900132802840825cdab
2016.12.05 19:22:32 2: ZWDongle_0 transmit NO_ACK for CB e3, target ThermostatBuero
2016.12.05 19:57:53 2: ZWDongle_0 transmit NO_ACK for CB 28, target ThermostatBuero
2016.12.05 19:58:20 2: ZWDongle_0 transmit NO_ACK for CB 2a, target ThermostatKueche
2016.12.05 20:00:49 2: ZWDongle_0 transmit NO_ACK for CB 2f, target ThermostatBuero
2016.12.05 20:03:46 2: ZWDongle_0 transmit NO_ACK for CB 35, target ThermostatBuero
2016.12.05 20:21:26 2: ZWDongle_0 transmit NO_ACK for CB 57, target ThermostatBuero
2016.12.05 20:38:51 3: ZWave set LichtBueroGabi off
2016.12.05 20:39:16 3: ZWave set LichtBuero1A off
2016.12.05 20:39:18 3: ZWave set FunkDose1 off
ist willkürlich raus kopiert, da kannste mal gucken wie das so aussieht :-\
Aber dazu noch ne Frage, hier angefangen:
2016.12.05 19:08:06 3: set ThermostatWohnzimmer thermostatSetpointSet 12.00 : Scheduled for sending after WAKEUP
werden nacheinander zwei verschiedene Befehle in den WAKEUP SendStack gelegt.
Dann wird das ThermostatWohnzimmer ja irgendwann wach, haben die resending message etwas damit zu tun?
Wenn könnte man so etwas nicht vermeiden?
Was ich meine, es werden ja ggf. viele, viele Nachrichten auf einmal dann abgefeuert?
Ist das dann halt so, oder immer jede einzeln nach jedem aufwachen?
Zitat von: tomspatz am 05 Dezember 2016, 21:00:35
ist willkürlich raus kopiert, da kannste mal gucken wie das so aussieht :-\
Schlecht. Kenne ich so nicht. Problem: mangels verbose 5 Log kann ich über tatsaechlichen Ablauf nur Vermutungen anstellen. Wenn WNMI_delay auf 0.2 stand, dann bitte wieder hochsetzen und nicht unter 0.5 gehen.
Zitat
Aber dazu noch ne Frage, hier angefangen:
2016.12.05 19:08:06 3: set ThermostatWohnzimmer thermostatSetpointSet 12.00 : Scheduled for sending after WAKEUP
werden nacheinander zwei verschiedene Befehle in den WAKEUP SendStack gelegt.
Warum wird denn der gleiche Befehl mit so total unterschiedlichen Werten (12 versus 22.5) überhaupt abgesetzt? Kann das überhaupt funktionieren?
ZitatDann wird das ThermostatWohnzimmer ja irgendwann wach, haben die resending message etwas damit zu tun?
Vermutlich.
ZitatWenn könnte man so etwas nicht vermeiden?
Doppeltes Absetzen des gleichen Befehls zwischen zwei Wakeups vermeiden (es sei denn Du überzeugst mich von der Notwendigkeit). Da mir nicht bekannt ist, wie und warum das gemacht wird, kann ich Dir keine Alternative liefern.
Zitat
Was ich meine, es werden ja ggf. viele, viele Nachrichten auf einmal dann abgefeuert?
Ist das dann halt so, oder immer jede einzeln nach jedem aufwachen?
Die Nachrichten werden pro Geraet einzeln und nacheinander abgesetzt. Es kann aber dennoch zu Funkkollisionen kommen, die durch Antworten des Geraetes selbst oder anderer Geraete entstehen. Die gilt es zu minimieren, indem unnötige Befehle vermieden werden.
ZitatWarum wird denn der gleiche Befehl mit so total unterschiedlichen Werten (12 versus 22.5) überhaupt abgesetzt? Kann das überhaupt funktionieren?
hmm das gehört zur Lüftung, Fenster auf Erkennung Heizung runter, Fenster zu Heizung wieder rauf. Grundsätzlich funktioniert das, im Frontend, wobei es ggf. ja auch irgendwelche Schreinerei machen könnte die sich evtl. später auswirkt.
Wenn du Spaß dran hast poste ich gerne hier eine Gesamte Konfiguration dieser Geschichte für ein Fenster, vielleicht hast du da noch eine Idee dazu.
Verbose 5 möchte ich erstmals nachts setzen, da gibt es keinerlei andere Sachen die stören könnten.
Lässt sich ein attr auch per at setzen?
ZitatFenster auf Erkennung Heizung runter, Fenster zu Heizung wieder rauf
Ich behaupte das ist ohne FLiRS oder staendige Stromversorgung sinnlos.
Zitat von: tomspatz am 06 Dezember 2016, 08:58:49
hmm das gehört zur Lüftung, Fenster auf Erkennung Heizung runter, Fenster zu Heizung wieder rauf. Grundsätzlich funktioniert das, im Frontend, wobei es ggf. ja auch irgendwelche Schreinerei machen könnte die sich evtl. später auswirkt.
Wie Rudi schrieb, ist das vermutlich nicht sehr wirkungsvoll, wenn man kein FLIRS-Gerät hat oder ein sehr (zu kurzes) wakeupInterval setzt.
Befehle werden beim LC-13 nur bei Wakeup an das Gerät verschickt. Beide Befehle werden daher regelmäßig direkt hintereinander beim nächsten Wakeup an das Gerät verschickt. Wenn das beim Gerät keine "Verwirrung" auslösen sollte, wird nur der letzte Befehl verarbeitet und man produziert sich unnötige Funklast. Zudem wird es vermutlich immer zu spät sein.
ZitatWenn du Spaß dran hast poste ich gerne hier eine Gesamte Konfiguration dieser Geschichte für ein Fenster, vielleicht hast du da noch eine Idee dazu.
Danke, verzichte freiwillig ;)
Aber: Wenn Du Dein Vorgehen der Temperatureinstellung für sinnvoll erachtest, dann mache das Ganze mit einem notify, das auf die wakeupNotification triggert und per if den Befehl mit dem dann aktuellen Wert (12 oder 22.5) absetzt, statt auf den Event für die Fensteröffnung zu triggern.
ZitatLässt sich ein attr auch per at setzen?
Ja.
ZitatAber: Wenn Du Dein Vorgehen der Temperatureinstellung für sinnvoll erachtest, dann mache das Ganze mit einem notify, das auf die wakeupNotification triggert und per if den Befehl mit dem dann aktuellen Wert (12 oder 22.5) absetzt, statt auf den Event für die Fensteröffnung zu triggern.
Cool das ist schon mal ein Weg, das werde ich probieren.
wäre so etwas OK?
define verbose5 at *00:01 {fhem("set attr ZWDongle_0 verbose 5 till 06:00")}
Analog dem commandref-Beispiel (http://fhem.de/commandref_DE.html#at):
Zitat# Lampe von Sonnenuntergang bis 23:00 Uhr einschalten
define a9 at +*{sunset_rel()} set lamp on
define a10 at *23:00:00 set lamp off
eher so etwas:
define a9 at +*{sunset_rel()} attr ZWDongle_0 verbose 5
define a10 at *23:00:00 attr ZWDongle_0 verbose 3