Hallo zusammen,
ich weiß das Thema gabs schon ein paar Mal aber ich habe heute etwas komisch festgestellt.
Wenn ich per FHEM einen Aktor einschalte (FGS-222) wird reportedstate nicht gesetzt. Das soll wohl auch so sein?
Anbei ein List:
Internals:
DEF f7aac8f1 11
IODev zwstick1
LASTInputDev zwstick1
MSGCNT 72
NAME wz.licht.98
NR 69
STATE off
TYPE ZWave
ZWaveSubDevice no
cmdsPending 0
endpointChildren ZWave_SWITCH_BINARY_11.01,wz.licht.1
homeId f7aac8f1
isWakeUp
lastMsgSent 1516981811.77487
nodeIdHex 0b
zwstick1_MSGCNT 72
zwstick1_RAWMSG 0004000b057006060100
zwstick1_TIME 2018-01-26 16:44:52
READINGS:
2016-09-03 04:09:31 CMD ZW_APPLICATION_UPDATE
2018-01-26 16:38:07 assocGroup_1 Max 5 Nodes
2018-01-26 16:38:07 assocGroup_2 Max 5 Nodes
2018-01-26 16:38:08 assocGroup_3 Max 1 Nodes zwstick1
2018-01-26 16:38:07 assocGroups 3
2018-01-26 16:44:45 configALARMFLASHINGAlarmTime 600
2018-01-26 16:44:45 configAutoOffForRelay1 0
2018-01-26 16:44:45 configAutoOffForRelay2 0
2018-01-26 16:44:46 configAutoOffRelayAfterSpecifiedTime ManualOverrideDisabled
2018-01-26 16:44:46 configControlKey2Behaviour DeviceStatusIsNotChecked
2018-01-26 16:44:46 configDimmerRollerShutterControl DisableDimmerRollerShutter0
2018-01-26 16:44:46 configEnableDisableALLONOFF ALLONActiveALLOFFActive
2018-01-26 16:44:47 configInputsBehaviour Toggle
2018-01-26 16:44:47 configInputsButtonSwitchConfiguration BiStableInputSwitch
2018-01-26 16:44:47 configRelay1ResponseToGeneralAlarm ALARMFLASHINGRelayWillTurnONAndO3
2018-01-26 16:44:47 configRelay1ResponseToSmokeCOCO2Alarm ALARMFLASHINGRelayWillTurnONAndO3
2018-01-26 16:44:48 configRelay1ResponseToTemperatureAlarm ALARMRELAYONRelayWillTurnONUpon1
2018-01-26 16:44:49 configRelay1ResponseToWaterFloodAlarm ALARMRELAYOFFRelayWillTurnOFF2
2018-01-26 16:44:49 configRelay2ResponseToGeneralAlarm ALARMFLASHINGRelayWillTurnONAndO3
2018-01-26 16:44:50 configRelay2ResponseToSmokeCOCO2Alarm ALARMFLASHINGRelayWillTurnONAndO3
2018-01-26 16:44:51 configRelay2ResponseToTemperatureAlarm ALARMRELAYONRelayWillTurnONUpon1
2018-01-26 15:53:56 configRelay2ResponseToWaterFloodAlarm ALARMRELAYOFFRelayWillTurnOFF2
2018-01-26 16:44:52 configSavingStateBeforePowerFailure StateSavedAtPowerFailureAll1
2018-01-26 16:44:52 configSeparationOfAssociationSending6 MapStatusToAllDevicesInGroup10
2017-03-03 07:54:14 energy 0.49 kWh
2018-01-26 15:55:59 mcCapability_01 SWITCH_BINARY
2018-01-26 15:55:59 mcCapability_02 SWITCH_BINARY
2018-01-26 15:55:59 mcEndpoints total 2, identical
2018-01-26 16:36:17 mcaGroups 2
2018-01-26 16:36:18 mca_1 Max 5 Nodes zwstick1:1
2018-01-26 16:36:18 mca_2 Max 5
2016-09-03 04:09:39 model FIBARO System FGS222 Double Relay Switch 2x1.5kW
2016-09-03 04:09:39 modelConfig fibaro/fgs222.xml
2016-09-03 04:09:39 modelId 010f-0202-1002
2018-01-26 16:45:19 state off
2018-01-26 16:50:11 timeToAck 0.069
2018-01-26 16:50:11 transmit OK
Attributes:
IODev zwstick1
classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL SWITCH_BINARY SWITCH_ALL FIRMWARE_UPDATE_MD POWERLEVEL MARK SWITCH_BINARY MULTI_CHANNEL
room zzz_unused
struc gesamt.licht
userattr struc struc_map structexclude
vclasses ASSOCIATION:2 FIRMWARE_UPDATE_MD:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL:2 MULTI_CHANNEL_ASSOCIATION:1 POWERLEVEL:1 SWITCH_ALL:1 VERSION:1
Ich benutze aber noch einen Zwave Switch. Dort habe ich meinem Aktor in eine AssocGroup aufgenommen. Das funktioniert auch und der reportedState wird gesetzt, wenn ich den Schalter nutze
Schalter list:
Internals:
DEF f7aac8f1 30
IODev zwstick1
LASTInputDev zwstick1
MSGCNT 22
NAME wz.switch.a
NR 405
STATE wakeupInterval 86400 1
TYPE ZWave
ZWaveSubDevice no
cmdsPending 0
endpointChildren wz.switch.1,wz.switch.2,wz.switch.3,wz.switch.4
homeId f7aac8f1
isWakeUp 1
lastMsgSent 1516979804.36604
nodeIdHex 1e
zwstick1_MSGCNT 22
zwstick1_RAWMSG 0049841e150412025e858e705b595586725a7380989f846cef26
zwstick1_TIME 2018-01-26 16:16:42
READINGS:
2018-01-26 16:16:42 CMD ZW_APPLICATION_UPDATE
2017-10-12 17:25:05 alarm HomeSecurity: Event cleared: Motion Detection - Unknown Location, arg 0108
2018-01-26 16:15:17 battery 0 %
2018-01-26 16:15:15 mcaGroups 5
2018-01-26 16:15:29 mca_1 Max 5 Nodes zwstick1
2018-01-26 16:15:29 mca_2 Max 5 Nodes zwstick1:1 wz.licht.98:2
2018-01-26 16:15:30 mca_3 Max 5 Nodes zwstick1:2 wz.licht.2:1
2018-01-26 16:15:30 mca_4 Max 5 Nodes zwstick1:3
2018-01-26 16:15:30 mca_5 Max 5 Nodes zwstick1:4
2017-09-03 18:30:31 model 0x0330 0x0003 0xa305
2017-09-03 18:30:31 modelId 0330-0003-a305
2017-09-03 18:30:29 state wakeupInterval 86400 1
2018-01-26 16:16:44 timeToAck 0.143
2018-01-26 16:16:44 transmit OK
2018-01-25 17:03:40 wakeup notification
Attributes:
IODev zwstick1
classes ZWAVEPLUS_INFO ASSOCIATION MULTI_CHANNEL_ASSOCIATION CONFIGURATION CENTRAL_SCENE ASSOCIATION_GRP_INFO TRANSPORT_SERVICE VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL BATTERY SECURITY SECURITY_S2 WAKE_UP SUPERVISION MARK SWITCH_MULTILEVEL
room Wohnzimmer
vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CENTRAL_SCENE:3 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SECURITY:0 SECURITY_S2:0 SUPERVISION:1 SWITCH_MULTILEVEL:0 TRANSPORT_SERVICE:2 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2
Aber wenn ich dann den Aktor über FHEM ausschalte, bleibt reportedState leider auf "on" und wenn ich das nächste Mal mit dem Schalter den Aktor wieder auf "on" setze, bekommt FHEM das nicht mit. Also STATE und state bleiben daher auf "off". Nur ein "get swbstatus" hilft da.
Ist das aktuell normal so?
Muss man das mit Workarounds lösen?
Danke für eure Hilfe
mfg
Marcel
Ich kenne nicht diese Geraete, kann nur sagen, dass ein AN158 eine von FHEM ausgeloeste Zustandsaenderung(!) mit reportedState meldet.
Irritierend finde ich, dass beim Aktor FGS-222 sowohl einen normale Assoziation als auch einen Mulit-Channel-Assoziation mit dem zwstick1 existiert:
Zitat2018-01-26 16:38:08 assocGroup_3 Max 1 Nodes zwstick1
2018-01-26 16:36:18 mca_1 Max 5 Nodes zwstick1:1
Hat das einen tieferen Grund? Ansonsten bitte eine Löschen und testen.
Bei normaler Assoziation meldet der FGS-222 so: https://wiki.fhem.de/wiki/Z-Wave#FGS-222_Relais_Unterputzeinsatz
Es kommt wohl darauf an, in welchem Device (Haupt-, Endpoint) man nachschaut und womit man schaltet.
Hey Danke schon mal für die schnellen Antworten ;-)
Hab die mca_1 gelöscht. Das listing war ja auch vom "Hauptdevice". Da sieht man ja z.B. das das überhaupt kein reportedState hat. Bei diesem FGS-222 nutze ich jedoch nur das Device für Endpoint 2.
Hier das list. Da sieht man reportedState "off" und state "on", weil ich das eben über FHEM eingeschaltet habe.
Ein get swbStatus hilft dann aber.
Internals:
DEF f7aac8f1 2818
IODev zwstick1
LASTInputDev zwstick1
MSGCNT 38
NAME wz.licht.1
NR 72
STATE on
TYPE ZWave
ZWaveSubDevice yes
endpointParent wz.licht.98
homeId f7aac8f1
isWakeUp
nodeIdHex 0b02
zwstick1_MSGCNT 38
zwstick1_RAWMSG 0004000b07600d0202250300
zwstick1_TIME 2018-01-26 16:50:10
READINGS:
2018-01-26 16:50:10 reportedState off
2018-01-26 19:15:30 state on
Attributes:
IODev zwstick1
classes SWITCH_BINARY
room Wohnzimmer
struc gesamt.licht
userattr struc struc_map structexclude
Für diesen wz.licht.1 habe ich eine Association zu wz.switch.a, das ist mein Lichtschalter an der Wand, der wird in dem Thread https://forum.fhem.de/index.php/topic,72330.0.html behandelt. Den list vom Schalter habe ich ja schon gepostet. Sieht ja bei dem Schalter so aus:
mca_2 Max 5 Nodes zwstick1:1 wz.licht.98:2
Wenn ich den Schalter benutze, wird auch reportedState auf "on" gesetzt. Wenn ich dann über FHEM wieder aus mache, wird das aber leider nicht auf "off" gesetzt...
Und noch ein log mit verbose 5 wenn ich in FHEM für wz.licht.1 auf "on" drücke:
2018.01.26 19:23:15 3: ZWave set wz.licht.1 on
2018.01.26 19:23:15 5: ZWDongle_Write 00130b07600d00022501FF25c1 (f7aac8f1)
2018.01.26 19:23:15 5: SW: 010e00130b07600d00022501FF25c1be
2018.01.26 19:23:16 5: ACK received, WaitForAck=>2 for 010e00130b07600d00022501FF25c1be
2018.01.26 19:23:16 4: ZWDongle_Read zwstick1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2018.01.26 19:23:16 5: SW: 06
2018.01.26 19:23:16 5: zwstick1: dispatch 011301
2018.01.26 19:23:16 4: ZWDongle_Read zwstick1: rcvd 0013c1000008 (request ZW_SEND_DATA), sending ACK
2018.01.26 19:23:16 5: SW: 06
2018.01.26 19:23:16 5: device ack reveived, removing 010e00130b07600d00022501FF25c1be from dongle sendstack
2018.01.26 19:23:16 5: zwstick1: dispatch 0013c1000008
2018.01.26 19:23:16 4: CMD:ZW_SEND_DATA ID:00 ARG:0008 CB:c1
2018.01.26 19:23:16 4: zwstick1 transmit OK for CB c1, target wz.licht.98
2018.01.26 19:23:22 4: ZWDongle_Read zwstick1: rcvd 00040020063105030a0000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.01.26 19:23:22 5: SW: 06
2018.01.26 19:23:22 5: zwstick1: dispatch 00040020063105030a0000
2018.01.26 19:23:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:20 ARG:063105030a0000 CB:00
Edit: Ich habe mittlerweile das Gefühl es kommt darauf an, ob das Fibaro Gerät ein zw plus device ist oder nicht. Ich habe z.b. zwei Fibaro Wall Plugs, sind vermutlich ähnlich zum AN158. Das zw-plus device meldet einen sauberen reportedState, das ander nicht...
mfg
Marcel
Ich hab mal im "verbose 5" ein Gerät mit zwplus und eins ohne eingeschaltet. Hier dazu die Logs:
ohne zwplus
2018.01.29 09:15:20 3: ZWave set ku.licht.3 on
2018.01.29 09:15:20 5: ZWDongle_Write 001304032501FF25d1 (f7aac8f1)
2018.01.29 09:15:20 5: SW: 010a001304032501FF25d1ce
2018.01.29 09:15:20 5: ACK received, WaitForAck=>2 for 010a001304032501FF25d1ce
2018.01.29 09:15:20 4: ZWDongle_Read zwstick1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2018.01.29 09:15:20 5: SW: 06
2018.01.29 09:15:20 5: zwstick1: dispatch 011301
2018.01.29 09:15:20 4: ZWDongle_Read zwstick1: rcvd 0013d1000002 (request ZW_SEND_DATA), sending ACK
2018.01.29 09:15:20 5: SW: 06
2018.01.29 09:15:20 5: device ack reveived, removing 010a001304032501FF25d1ce from dongle sendstack
2018.01.29 09:15:20 5: zwstick1: dispatch 0013d1000002
2018.01.29 09:15:20 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:d1
2018.01.29 09:15:20 4: zwstick1 transmit OK for CB d1, target ku.licht.3
2018.01.29 09:15:20 4: ZWDongle_Read zwstick1: rcvd 000400040631050422013e (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.01.29 09:15:20 5: SW: 06
2018.01.29 09:15:20 5: zwstick1: dispatch 000400040631050422013e
2018.01.29 09:15:20 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0631050422013e CB:00
mit zwplus:
2018.01.29 09:16:15 3: ZWave set sz.power.3 on
2018.01.29 09:16:15 5: ZWDongle_Write 001321032501FF25d3 (f7aac8f1)
2018.01.29 09:16:15 5: SW: 010a001321032501FF25d3e9
2018.01.29 09:16:16 5: ACK received, WaitForAck=>2 for 010a001321032501FF25d3e9
2018.01.29 09:16:16 4: ZWDongle_Read zwstick1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2018.01.29 09:16:16 5: SW: 06
2018.01.29 09:16:16 5: zwstick1: dispatch 011301
2018.01.29 09:16:16 4: ZWDongle_Read zwstick1: rcvd 0013d3000006 (request ZW_SEND_DATA), sending ACK
2018.01.29 09:16:16 5: SW: 06
2018.01.29 09:16:16 5: device ack reveived, removing 010a001321032501FF25d3e9 from dongle sendstack
2018.01.29 09:16:16 5: zwstick1: dispatch 0013d3000006
2018.01.29 09:16:16 4: CMD:ZW_SEND_DATA ID:00 ARG:0006 CB:d3
2018.01.29 09:16:16 4: zwstick1 transmit OK for CB d3, target sz.power.3
2018.01.29 09:16:16 4: ZWDongle_Read zwstick1: rcvd 00040021032503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.01.29 09:16:16 5: SW: 06
2018.01.29 09:16:16 5: zwstick1: dispatch 00040021032503ff
2018.01.29 09:16:16 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:032503ff CB:00
2018.01.29 09:16:16 4: ZWDongle_Read zwstick1: rcvd 000400210631050422004b (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.01.29 09:16:16 5: SW: 06
2018.01.29 09:16:16 5: zwstick1: dispatch 000400210631050422004b
2018.01.29 09:16:16 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:0631050422004b CB:00
Da ist ein Unterschied. Aber woher der kommt, weiß ich leider nicht. Hilft das evtl.?
Hallo zusammen,
ich aktiviere den Thread hier nochmal. Das mit dem fehlenden reportedState lies mir keine Ruhe ;-)
Also der Code in der 10_ZWave.pm ist der hier oder?
Ab Zeile 4973
...
my ($vn, $vv) = split(":", $event[$i], 2);
readingsBulkUpdate($hash, $vn, $vv);
readingsBulkUpdate($hash, "reportedState", $vv)
if($vn eq "state"); # different from set
}
...
Wenn ich ein set on über FHEM an den Fibaro Aktor sende, komme ich aber gar nicht zu diesem Code, sondern lande hier:
Ab Zeile 4705
...
if($id eq "00") {
my $name="";
if($hash) {
ZWave_processSendStack($hash, "ack", $callbackid);
readingsSingleUpdate($hash, "transmit", $lmsg, 0);
if($iodev->{showSetInState}) {
my $lCU = $hash->{lastChannelUsed};
my $lname = $lCU ? $lCU : $hash->{NAME};
my $state = ReadingsVal($lname, "state", "");
if($state =~ m/^set_(.*)$/) {
readingsSingleUpdate($defs{$lname}, "state", $1, 1);
$name = $lname;
}
}
}
delete($hash->{lastChannelUsed});
return $name;
...
In $name steht dann nichts drin.
Meine Kenntnisse über ZWave sind natürlich eher eingeschränkt, aber ein Buch habe ich schon hier. Und die 6700 Zeilen muss man auch erstmal überblicken und mit zwave know how verknüpfen ;-)
Hilft meine Analyse irgendwie?
mfg
Marcel
Schau mal in https://forum.fhem.de/index.php/topic,74509.msg663636.html#msg663636, unter welchen Bedingungen reportedState gesetzt wird.
Ob reportedstate gesetzt wird, haengt unter anderem vom Aktor und Assoziation/Konfiguration ab. ZWave ohne oder mit Plus ist unbedeutend.