Ich weis doif hat ein eigenen Teil, da ich es aber mit zwave einsetzte probiere ich es erst hier.
Das doif geht so:
define LichtKammerAutomatik DOIF ([TuerKammer] eq "offen") (set LichtBad_30.02 on) DOELSEIF ([TuerKammer] eq "geschlossen") (set LichtBad_30.02 off)
Wobei TuerKammer ein Fibaro FGK101 ist.
Internals:
DEF c9cc092a 32
IMAGE /fhem/deviceimages/zwave/8a77269b55c554d5a690c03b82b6bbdcda07c164.jpg
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 213
NAME TuerKammer
NR 297
STATE geschlossen
TYPE ZWave
ZWDongle_0_MSGCNT 213
ZWDongle_0_RAWMSG 0004002003200100
ZWDongle_0_TIME 2016-08-11 09:37:43
ZWaveSubDevice no
homeId c9cc092a
isWakeUp 1
lastMsgSent 1470900675.30409
nodeIdHex 20
Readings:
2016-08-11 09:31:13 CMD ZW_APPLICATION_UPDATE
2016-08-11 09:11:43 UNPARSED SENSOR_BINARY 03300102
2016-08-11 09:37:43 basicSet 00
2016-08-09 19:38:04 battery 97 %
2016-08-09 19:35:39 model FIBARO System FGK101 Door Opening Sensor
2016-08-09 19:35:39 modelConfig fibaro/fgk001.xml
2016-08-09 19:35:39 modelId 010f-0700-1000
2016-08-11 09:31:14 neighborList ZWDongle_0 FunkDose1 LichtWohnzimmerSchrank1A LichtWohnzimmerSchrank2A FunkDose2 LichtBuero1A LichtKueche LichtFlurSpiegel DimmerWohnzimmer LichtFlur LichtBad
2016-08-11 09:37:43 reportedState closed
2016-08-11 09:37:43 state closed
2016-08-11 09:31:15 timeToAck 0.029
2016-08-11 09:31:15 transmit OK
2016-08-11 08:31:04 wakeup notification
2016-08-09 19:37:44 wakeupReport interval 4000 target 1
Attributes:
IODev ZWDongle_0
alias Tür Kammer
classes SENSOR_BINARY SENSOR_ALARM ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION BASIC
devStateIcon offen:fts_door_right_open@red .*:fts_door_right
eventMap open:offen closed:geschlossen
group Fenster und Türen
icon fts_door_right
neighborListPos 257.2181420672305,72.11792404213035
room Flur,System
vclasses ASSOCIATION:2 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 FIRMWARE_UPDATE_MD:1 MANUFACTURER_SPECIFIC:1 SCENE_ACTIVATION:1 SENSOR_ALARM:1 SENSOR_BINARY:1 VERSION:1 WAKE_UP:1
und LichtBad_30.02 der zweite Teil eines Fibaro FGS222.
Internals:
DEF c9cc092a 7682
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 21
NAME LichtBad_30.02
NR 207
STATE aus
TYPE ZWave
ZWDongle_0_MSGCNT 21
ZWDongle_0_RAWMSG 0004001e07600d0202250300
ZWDongle_0_TIME 2016-08-11 09:15:47
ZWaveSubDevice yes
homeId c9cc092a
isWakeUp
nodeIdHex 1e02
Readings:
2016-08-11 09:15:47 reportedState off
2016-08-11 09:37:43 state off
Attributes:
IODev ZWDongle_0
alias Licht Kammer
classes SWITCH_BINARY
devStateIcon .*an:on-for-timer
eventMap on:an off:aus
group Licht
icon light_ceiling
room Flur,System,ZWave
webCmd :
hier der "Master" davon.
Internals:
DEF c9cc092a 30
IMAGE /fhem/deviceimages/zwave/271.514.4098_fgs222.double.relay.switch.jpg
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 11
NAME LichtBad
NR 203
STATE aus
TYPE ZWave
ZWDongle_0_MSGCNT 11
ZWDongle_0_RAWMSG 0004001e03250300
ZWDongle_0_TIME 2016-08-11 09:24:47
ZWaveSubDevice no
homeId c9cc092a
isWakeUp
lastMsgSent 1470901063.35206
nodeIdHex 1e
Readings:
2016-03-20 19:34:17 assocGroup_1 Max 5 Nodes ZWDongle_0
2016-03-20 19:34:17 assocGroup_2 Max 5 Nodes
2016-03-20 19:34:23 assocGroup_3 Max 1 Nodes ZWDongle_0
2016-03-20 19:34:17 assocGroups 3
2016-03-20 18:15:05 basicSet 00
2016-03-28 16:44:19 configALARMFLASHINGAlarmTime 600
2016-03-28 16:44:19 configAutoOffForRelay1 0
2016-03-28 16:44:19 configAutoOffForRelay2 0
2016-03-28 16:44:19 configAutoOffRelayAfterSpecifiedTime ManualOverrideDisabled
2016-03-28 16:44:19 configControlKey2Behaviour DeviceStatusIsNotChecked
2016-03-28 16:44:19 configDimmerRollerShutterControl DisableDimmerRollerShutter0
2016-03-28 16:44:19 configEnableDisableALLONOFF ALLONActiveALLOFFActive
2016-03-28 16:44:19 configInputsBehaviour Toggle
2016-03-28 16:44:19 configInputsButtonSwitchConfiguration MonoStableInputButton
2016-03-28 16:44:19 configRelay1ResponseToGeneralAlarm ALARMFLASHINGRelayWillTurnONAndO3
2016-03-28 16:44:19 configRelay1ResponseToSmokeCOCO2Alarm ALARMFLASHINGRelayWillTurnONAndO3
2016-03-28 16:44:19 configRelay1ResponseToTemperatureAlarm ALARMRELAYONRelayWillTurnONUpon1
2016-03-28 16:44:19 configRelay1ResponseToWaterFloodAlarm ALARMRELAYOFFRelayWillTurnOFF2
2016-03-28 16:44:19 configRelay2ResponseToGeneralAlarm ALARMFLASHINGRelayWillTurnONAndO3
2016-03-28 16:44:19 configRelay2ResponseToSmokeCOCO2Alarm ALARMFLASHINGRelayWillTurnONAndO3
2016-03-28 16:44:19 configRelay2ResponseToTemperatureAlarm ALARMRELAYONRelayWillTurnONUpon1
2016-03-28 16:44:19 configRelay2ResponseToWaterFloodAlarm ALARMRELAYOFFRelayWillTurnOFF2
2016-03-28 16:44:19 configSavingStateBeforePowerFaillure StateSavedAtPowerFailureAll1
2016-03-28 16:44:19 configSeparationOfAssociationSending6 MapStatusToAllDevicesInGroup10
2016-03-20 18:08:07 mcCapability_01 SWITCH_BINARY
2016-03-20 18:12:16 mcCapability_02 SWITCH_BINARY
2016-03-20 18:08:07 mcEndpoints total 2, identical
2016-03-20 18:08:07 model FIBARO System FGS222 Double Relay Switch 2x1.5kW
2016-03-20 18:08:07 modelConfig fibaro/fgs222.xml
2016-03-20 18:08:07 modelId 010f-0202-1002
2016-03-28 16:06:25 neighborList ZWDongle_0 FunkDose1 HeizungSchlafzimmer HeizungWohnzimmer LichtWohnzimmerSchrank1A LichtWohnzimmerSchrank2A HeizungBad HeizungKueche FunkDose2 LichtBuero1A LichtKueche LichtFlurSpiegel LichtWohnzimmer LichtFlur
2016-08-11 09:24:47 reportedState off
2016-08-11 09:24:47 state off
2016-08-11 09:37:44 timeToAck 1.059
2016-08-11 09:37:44 transmit OK
Attributes:
IODev ZWDongle_0
alias Licht Bad
classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL SWITCH_BINARY SWITCH_ALL FIRMWARE_UPDATE_MD POWERLEVEL MARK SWITCH_BINARY MULTI_CHANNEL
eventMap on:an off:aus
group Licht
icon light_ceiling
neighborListPos 131.39791710649686,545.6925446450147
room Bad,System,ZWave
webCmd :
Wenn ich den Lichtschalter betätige, geht logischerweise das Licht an. Kein Eintrag im Log.
Schalte ich das selbe Licht per fhem web.
2016.08.11 09:56:46 3: ZWave set LichtBad_30.02 on
bzw.
2016.08.11 09:57:24 3: ZWave set LichtBad_30.02 off
Das soweit OK, wenn allerdings das ganze per DOIF ausgelöst wird.... was auch einwandfrei funktioniert. Passiert das:
2016.08.11 09:58:41 3: ZWave set LichtBad_30.02 on
2016.08.11 09:58:41 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00131e07600d01022501FF257e15
bzw. beim schliessen:
2016.08.11 09:59:23 3: ZWave set LichtBad_30.02 off
2016.08.11 09:59:24 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00131e07600d0102250100258014
Der Fibaro FGK101 sollte eigentlich OK sein den der Status, Batterie etc. wird alles übertragen ohne das ich etwas fehlerhaftes finde.
Bitte nicht böse aufnehmen wenn das doch ins doif Forum gehört.
Zitat von: tomspatz am 11 August 2016, 09:45:01
Ich weis doif hat ein eigenen Teil, da ich es aber mit zwave einsetzte probiere ich es erst hier.
Das doif geht so:
define LichtKammerAutomatik DOIF ([TuerKammer] eq "offen") (set LichtBad_30.02 on) DOELSEIF ([TuerKammer] eq "geschlossen") (set LichtBad_30.02 off)
Verstehe das Problem nicht ganz aber warum nicht so:
define LichtKammerAutomatik DOIF ([TuerKammer:state] eq "offen") (set LichtBad_30.02 on) DOELSEIF (set LichtBad_30.02 off)Grüße, Josef
Hallo Josef
weil
define LichtKammerAutomatik DOIF ([TuerKammer:state] eq "offen") (set LichtBad_30.02 on) DOELSEIF (set LichtBad_30.02 off)
beim Speicher bringt:
LichtKammerAutomatik DOIF: no trigger in condition: set LichtBad_30.02 off
und so wie ich es definiert habe steht es auch in der Commandref.
Bringt uns aber bei dem eigentlichen nicht weiter.
Danke trotzdem
Tom
Hi Michael,
schau mal im EventMonitor, dort müsstest Du sehen was der FGK101 triggert. Ich benutze das gleiche DOIF mit einem FGK101 und einem Wallplug. Keine Probleme damit.
Grüße, Josef
Zitat von: tomspatz am 11 August 2016, 13:32:09
Hallo Josef
weil
define LichtKammerAutomatik DOIF ([TuerKammer:state] eq "offen") (set LichtBad_30.02 on) DOELSEIF (set LichtBad_30.02 off)
beim Speicher bringt:
LichtKammerAutomatik DOIF: no trigger in condition: set LichtBad_30.02 off
und so wie ich es definiert habe steht es auch in der Commandref.
Bringt uns aber bei dem eigentlichen nicht weiter.
Danke trotzdem
Tom
Verwende DOELSE, DOELSEIF erwartet eine Bedingung, DOELSE nicht.
Zitat von: Ellert am 11 August 2016, 15:30:38
Verwende DOELSE, DOELSEIF erwartet eine Bedingung, DOELSE nicht.
Wie recht Du hast, habe ich leider übersehen.
Grüße, Josef
DOELSE statt DOELSEIF ist in diesem Falle tatsächlich OK.
Doch ihr lieben ;) mein eigentliches Problem
2016.08.11 16:40:29 3: ZWave set LichtBad_30.02 on
2016.08.11 16:40:30 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00131e07600d01022501FF257d16
bzw.
2016.08.11 16:40:44 3: ZWave set LichtBad_30.02 off
2016.08.11 16:40:45 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00131e07600d0102250100257eea
ist allerdings damit nicht behoben und hängt auch me nach nicht an dem DOIF.
Ich kenne ZWave nicht, aber der Titel Deines Beitrags scheint das Problem nicht zu treffen, daher bekommst Du Ratschläge zu DOIF.
Zitat von: tomspatz am 11 August 2016, 16:44:30
ist allerdings damit nicht behoben und hängt auch me nach nicht an dem DOIF.
Dann zeige bitte mal ein Log der Schaltvorgänge mit verbose 5 bei ZWDongle. Einmal normal geschaltet und einmal mit DOIF. Vielleicht kommen dann Ideen zu ZWave..
So sieht es bei ZWave nach einer Wiederholung aus, die aber immer zum Erfolg führt. Also nicht tragisch, aber wenn es reproduzierbar ist, trotzdem komisch und interessant. :)
probiers mit:
define LichtKammerAutomatik DOIF ([TuerKammer:state] eq "offen") (sleep 0.15; set LichtBad_30.02 on) DOELSE (sleep 0.15; set LichtBad_30.02 off)
ich glaub, daß die Kommunikation mit dem Türkontakt noch nicht abgeschlossen ist wenn der Controller schon den "on" Befehl ans Licht schickt -> die auslösende und die ausgelöste Funkkommunikation behindern sich!
Zitat von: gamauf am 11 August 2016, 19:08:43
probiers mit:
define LichtKammerAutomatik DOIF ([TuerKammer:state] eq "offen") (sleep 0.15; set LichtBad_30.02 on) DOELSE (sleep 0.15; set LichtBad_30.02 off)
ich glaub, daß die Kommunikation mit dem Türkontakt noch nicht abgeschlossen ist wenn der Controller schon den "on" Befehl ans Licht schickt -> die auslösende und die ausgelöste Funkkommunikation behindern sich!
Nebenbei, statt "sleep" sollte im DOIF "wait" verwendet werden, also so:
define LichtKammerAutomatik DOIF ([TuerKammer:state] eq "offen") (set LichtBad_30.02 on) DOELSE (set LichtBad_30.02 off)
attr LichtKammerAutomatik wait .15:.15 siehe http://fhem.de/commandref_DE.html#DOIF_wait
Zitat von: Ellert am 11 August 2016, 19:15:22
Nebenbei, statt "sleep" sollte im DOIF "wait" verwendet werden...
...ist natürlich viel eleganter und leichter lesbar! Danke!
Hab das auch ab und zu bei DOIFs die auf die Multisensoren von Fibaro reagieren (Bewegung).
Die Sensoren schicken manchmal auch noch Temperatur oder Helligkeit mit.
Die weiteren Nachrichten kommen dann wohl teils zeitgleich mit der Ausführung des DOIFs und es kommt zu dem beobachteten ZWAVE-"Schluckauf".
Ist an sich nicht weiter schlimm, da ZWAVE ja Nachrichten ohne ACK wiederholt.
Wenn die Nachrichten im Log stören (oder die Verzögerung durch das Wiederholen spürbar ist), hilft wie erwähnt eine kurze Verzögerung über das wait Attribut.
Zur Funklastreduzierung und damit auch zur Reduzierung der Gefahr von Telegrammkollisionen würde ich vor wait/sleep-Konstrukten erst einmal beim FGK den Controller aus der Assogroup 1 herausnehmen. Controller in Assogroup 3 sollte doch reichen oder wofür werden die zusätzlichen Befehle aus CC Basic an Controller in Assogroup 1 gebraucht?
OK ich komme im Moment nicht viel dazu, aber hier schon mal etwas Futter.
Das mit dem wait attr habe ich noch nicht probiert.
Hier der Log vom ZWDongle_0 mit Verbose 5 ausgelöst durch das DOIF:
2016.08.16 20:34:39 4: ZWDongle_Read ZWDongle_0: rcvd 00040020033003ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.08.16 20:34:39 5: SW: 06
2016.08.16 20:34:39 5: ZWDongle_0 dispatch 00040020033003ff
2016.08.16 20:34:39 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:033003ff CB:00
2016.08.16 20:34:39 3: ZWave set LichtBad_30.02 on
2016.08.16 20:34:39 5: ZWDongle_Write 00131e07600d01022501FF25e9 (c9cc092a)
2016.08.16 20:34:39 5: SW: 010e00131e07600d01022501FF25e982
2016.08.16 20:34:39 4: ZWDongle_Read ZWDongle_0: rcvd 00040020032001ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.08.16 20:34:39 5: SW: 06
2016.08.16 20:34:39 5: ZWDongle_0 dispatch 00040020032001ff
2016.08.16 20:34:39 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:032001ff CB:00
2016.08.16 20:34:39 4: ZWDongle_Read ZWDongle_0: CAN received
2016.08.16 20:34:40 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00131e07600d01022501FF25e982
2016.08.16 20:34:40 5: SW: 010e00131e07600d01022501FF25e982
2016.08.16 20:34:40 5: ACK received, WaitForAck=>2 for 010e00131e07600d01022501FF25e982
2016.08.16 20:34:40 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.08.16 20:34:40 5: SW: 06
2016.08.16 20:34:40 5: ZWDongle_0 dispatch 011301
2016.08.16 20:34:40 4: ZWDongle_Read ZWDongle_0: rcvd 0013e9000003 (request ZW_SEND_DATA), sending ACK
2016.08.16 20:34:40 5: SW: 06
2016.08.16 20:34:40 5: device ack reveived, removing 010e00131e07600d01022501FF25e982 from dongle sendstack
2016.08.16 20:34:40 5: ZWDongle_0 dispatch 0013e9000003
2016.08.16 20:34:40 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:e9
2016.08.16 20:34:40 4: ZWDongle_0 transmit OK for CB e9, target LichtBad
2016.08.16 20:34:42 4: ZWDongle_Read ZWDongle_0: rcvd 0004002003300300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.08.16 20:34:42 5: SW: 06
2016.08.16 20:34:42 5: ZWDongle_0 dispatch 0004002003300300
2016.08.16 20:34:42 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:03300300 CB:00
2016.08.16 20:34:42 3: ZWave set LichtBad_30.02 off
2016.08.16 20:34:42 5: ZWDongle_Write 00131e07600d010225010025ea (c9cc092a)
2016.08.16 20:34:42 5: SW: 010e00131e07600d010225010025ea7e
2016.08.16 20:34:42 4: ZWDongle_Read ZWDongle_0: rcvd 0004002003200100 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.08.16 20:34:42 5: SW: 06
2016.08.16 20:34:42 5: ZWDongle_0 dispatch 0004002003200100
2016.08.16 20:34:42 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:03200100 CB:00
2016.08.16 20:34:42 4: ZWDongle_Read ZWDongle_0: CAN received
2016.08.16 20:34:43 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00131e07600d010225010025ea7e
2016.08.16 20:34:43 5: SW: 010e00131e07600d010225010025ea7e
2016.08.16 20:34:43 5: ACK received, WaitForAck=>2 for 010e00131e07600d010225010025ea7e
2016.08.16 20:34:43 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.08.16 20:34:43 5: SW: 06
2016.08.16 20:34:43 5: ZWDongle_0 dispatch 011301
2016.08.16 20:34:43 4: ZWDongle_Read ZWDongle_0: rcvd 0013ea000002 (request ZW_SEND_DATA), sending ACK
2016.08.16 20:34:43 5: SW: 06
2016.08.16 20:34:43 5: device ack reveived, removing 010e00131e07600d010225010025ea7e from dongle sendstack
2016.08.16 20:34:43 5: ZWDongle_0 dispatch 0013ea000002
2016.08.16 20:34:43 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:ea
2016.08.16 20:34:43 4: ZWDongle_0 transmit OK for CB ea, target LichtBad
2016.08.16 20:34:45 4: ZWDongle_Read ZWDongle_0: rcvd 000400180c600d02023105014400000953 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.08.16 20:34:45 5: SW: 06
2016.08.16 20:34:45 5: ZWDongle_0 dispatch 000400180c600d02023105014400000953
2016.08.16 20:34:45 4: CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:0c600d02023105014400000953 CB:00
So und hier der Log vom ZWDongle_0 mit Verbose 5 ausgelöst durch fhem web:
2016.08.16 20:40:18 3: ZWave set LichtBad_30.02 on
2016.08.16 20:40:18 5: ZWDongle_Write 00131e07600d01022501FF25f6 (c9cc092a)
2016.08.16 20:40:18 5: SW: 010e00131e07600d01022501FF25f69d
2016.08.16 20:40:18 5: ACK received, WaitForAck=>2 for 010e00131e07600d01022501FF25f69d
2016.08.16 20:40:18 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.08.16 20:40:18 5: SW: 06
2016.08.16 20:40:18 5: ZWDongle_0 dispatch 011301
2016.08.16 20:40:18 4: ZWDongle_Read ZWDongle_0: rcvd 0013f6000003 (request ZW_SEND_DATA), sending ACK
2016.08.16 20:40:18 5: SW: 06
2016.08.16 20:40:18 5: device ack reveived, removing 010e00131e07600d01022501FF25f69d from dongle sendstack
2016.08.16 20:40:18 5: ZWDongle_0 dispatch 0013f6000003
2016.08.16 20:40:18 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:f6
2016.08.16 20:40:18 4: ZWDongle_0 transmit OK for CB f6, target LichtBad
2016.08.16 20:40:22 3: ZWave set LichtBad_30.02 off
2016.08.16 20:40:22 5: ZWDongle_Write 00131e07600d010225010025f7 (c9cc092a)
2016.08.16 20:40:22 5: SW: 010e00131e07600d010225010025f763
2016.08.16 20:40:22 5: ACK received, WaitForAck=>2 for 010e00131e07600d010225010025f763
2016.08.16 20:40:22 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.08.16 20:40:22 5: SW: 06
2016.08.16 20:40:22 5: ZWDongle_0 dispatch 011301
2016.08.16 20:40:22 4: ZWDongle_Read ZWDongle_0: rcvd 0013f7000002 (request ZW_SEND_DATA), sending ACK
2016.08.16 20:40:22 5: SW: 06
2016.08.16 20:40:22 5: device ack reveived, removing 010e00131e07600d010225010025f763 from dongle sendstack
2016.08.16 20:40:22 5: ZWDongle_0 dispatch 0013f7000002
2016.08.16 20:40:22 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:f7
2016.08.16 20:40:22 4: ZWDongle_0 transmit OK for CB f7, target LichtBad
2016.08.16 20:40:34 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0c600d02023105014400000915 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.08.16 20:40:34 5: SW: 06
2016.08.16 20:40:34 5: ZWDongle_0 dispatch 0004001a0c600d02023105014400000915
2016.08.16 20:40:34 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0c600d02023105014400000915 CB:00
Anmerkungen zum Log mit DOIF:
2016.08.16 20:34:39 4: ZWDongle_Read ZWDongle_0: rcvd 00040020033003ff (request APPLICATION_COMMAND_HANDLER), sending ACK
FHEM erhält Telegramm vom Dongle und verarbeitet Info vom Sensor per CC SENSOR_BINARY, dass das Fenster geöffnet wurde (->Assogroup 3). Das löst das DOIF aus.
2016.08.16 20:34:39 5: SW: 010e00131e07600d01022501FF25e982
Das DOIF setzt den Einschaltbefehl für das Licht ab und FHEM schickt den Befehl an das Dongle
2016.08.16 20:34:39 4: ZWDongle_Read ZWDongle_0: rcvd 00040020032001ff (request APPLICATION_COMMAND_HANDLER), sending ACK
FHEM erhält Telegramm vom Dongle und verarbeitet Info vom Sensor per CC BASIC, dass das Fenster geöffnet wurde (->Assogroup 1).
2016.08.16 20:34:39 4: ZWDongle_Read ZWDongle_0: CAN received
Dongle informiert FHEM, dass der letzte an das Dongle geschickte Befehl (Einschaltbefehl Licht) nicht verarbeitet werden konnte, weil das Dongle mit einer anderen Nachricht (Empfang Telegramm CC BASIC) beschäftigt war. Das ist gleichzeitig Hinweis für FHEM den Befehl noch einmal zu schicken.
2016.08.16 20:34:40 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00131e07600d01022501FF25e982
FHEM loggt das normale Ereignis von Kollisionen durch CAN
2016.08.16 20:34:40 5: SW: 010e00131e07600d01022501FF25e982
FHEM schickt den Befehl noch mal und er wird korrekt verarbeitet.
Grundsätzlich passiert hier nichts ungewöhnliches oder falsches. Die Kollision (CAN) ist aber vermutlich vermeidbar, indem man die doppelte Benachrichtigung an FHEM über die FGK-Zustandsänderung beseitigt. Für die gibt es mMn keinen Grund.
Also Abhilfe:
ZWDongle_0 aus der Assoziationsgruppe 1 des Sensors entfernen (-> associationDel) und testen.
Wenn das wirklich nicht reichen sollte, dann erst mit wait/sleep-Konstrukten arbeiten.
Hallo Christian
dank für die ausführliche Erklärung. Nun beide Wege führen zum Ziel.
Ich habe es mit
attr LichtKammerAutomatik wait .15:.15
funktioniert einwandfrei.
Jetzt soeben das attr gelöscht und ZWDongle_0 aus der Assoziationsgruppe 1 des Sensors entfernt, das funktioniert auch.
Vielen dank.
btw.
habe ich mir Gedanken gemacht ob man die Funklast nicht reduzieren könnte, sollte.
Es ist zwar NUR ein Befehl der vermutlich nicht zigfach pro Sekunde ausgelöst wird, aber dennoch.
Könnte mann oder sollte man ggf. bevor das Licht eingeschaltet wird prüfen ob es nicht schon an ist.
Im Umkehrschluss warum ein Befehl zum ausschalten schicken wenn es gar nich leuchtet.
Ist da was dran?
Zitat von: tomspatz am 17 August 2016, 17:08:41
Nun beide Wege führen zum Ziel.
Klar funktioniert auch die Verzögerung zur Vermeidung eines Logeintrages, aber die eigentliche Ursache bleibt mMn eine überflüssige Assoziierung des Controllers mit Group 1 des Sensors. :)
Zitathabe ich mir Gedanken gemacht ob man die Funklast nicht reduzieren könnte, sollte.
Es ist zwar NUR ein Befehl der vermutlich nicht zigfach pro Sekunde ausgelöst wird, aber dennoch.
Könnte mann oder sollte man ggf. bevor das Licht eingeschaltet wird prüfen ob es nicht schon an ist.
Im Umkehrschluss warum ein Befehl zum ausschalten schicken wenn es gar nich leuchtet.
Ist da was dran?
Persönlich sehe ich das so. Unnötige Funknachrichten bringen manchmal -wie bei Deinem Ausgangsthema- unnötige Probleme.
Beim notify kann man für diesen Zweck alternativ zu if-Konstrukten im set-Befehl devspec verwenden, um den Schaltvorgang nur auszulösen, wenn der Schaltzustand noch nicht vorliegt.