Fibaro FGS-222 not updating status....help

hm, strange…
so for you it works that the switch is turned on/off via openhab gui…and also you can turn on/off via real switch…and it will update openhab gui in parallel? right.

First thing works fine, but the second part not at all…in my case I have one intermediate hop in between…so the controller is not directly connected with the fibaro switch…maybe that is the problem…tried many things like assicoation groups…

hi all,
I think I have the same problem with a fgs-222 on OH 1.8.1, I haven’t debugged it so much but it seems the same issue, one switch is correctly updated and the other not. The relay is directly connected to the controller so I don’t think it’s a routing problem.

hi,
thanks for your reply…

Do you mean that the second relay works like normal and the first does not update? That would be interesting and I never checked that as (shame on me) i only have use for 1 relay and I simply took the first one…

Again, in my case…I can easily turn ON OFF the light via GUI and of course you see the right status…but if you press the light button light goes ON and OFF but does not forward this status update to OPENHAB…

Regards Norbert

yes, I think that in this topic we are talking about the same issue:


I think that you could easily solve the issue simply using the second relay but it could be useful to solve the issue with the first as it seems to be a common problem

Valerio, thanks.
So - Relay2 works just fine? OK, in my special case this would help…but generally its a true issue for all FGS-222 users.

hi, I had 5-10 minutes yesterday to debug this issue and I found what is causing the issue, here are the logs for the two switches when switched from the wall:
switch 1:

> 2016-03-29 20:09:24.430 [DEBUG] [eController$ZWaveReceiveThread:1481]- Receive Message = 01 09 00 04 00 07 03 25 03 FF 2F 
> 2016-03-29 20:09:24.434 [DEBUG] [eController$ZWaveReceiveThread:1405]- Receive queue ADD: Length=1
> 2016-03-29 20:09:24.434 [DEBUG] [b.z.i.protocol.ZWaveController:1163]- Receive queue TAKE: Length=0
> 2016-03-29 20:09:24.437 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 09 00 04 00 07 03 25 03 FF 2F 
> 2016-03-29 20:09:24.440 [DEBUG] [b.z.i.protocol.ZWaveController:1164]- Process Message = 01 09 00 04 00 07 03 25 03 FF 2F 
> 2016-03-29 20:09:24.441 [DEBUG] [b.z.i.protocol.ZWaveController:192 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 07 03 25 03 FF 
> 2016-03-29 20:09:24.442 [DEBUG] [ApplicationCommandMessageClass:38  ]- NODE 7: Application Command Request (ALIVE:DONE)
> 2016-03-29 20:09:24.443 [DEBUG] [ApplicationCommandMessageClass:56  ]- NODE 7: Incoming command class SWITCH_BINARY
> 2016-03-29 20:09:24.444 [DEBUG] [.ZWaveBinarySwitchCommandClass:79  ]- Received Switch Binary Request for Node ID = 7
> 2016-03-29 20:09:24.446 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 7: Switch Binary report, value = 0xFF
> 2016-03-29 20:09:24.448 [DEBUG] [b.z.i.protocol.ZWaveController:635 ]- Notifying event listeners: ZWaveCommandClassValueEvent
> 2016-03-29 20:09:24.449 [DEBUG] [.z.internal.ZWaveActiveBinding:433 ]- ZwaveIncomingEvent
> 2016-03-29 20:09:24.450 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 7: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 255
> 2016-03-29 20:09:24.451 [WARN ] [.z.internal.ZWaveActiveBinding:467 ]- NODE 7: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 255, ignoring.
> 2016-03-29 20:09:24.453 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63  ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 07 01 00 
> 2016-03-29 20:09:24.455 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:64  ]- Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 07 03 25 03 FF 
> 2016-03-29 20:09:24.456 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:65  ]- Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false

switch 2:

2016-03-29 20:11:04.622 [DEBUG] [eController$ZWaveReceiveThread:1481]- Receive Message = 01 0D 00 04 00 07 07 60 0D 02 02 25 03 FF 42 
2016-03-29 20:11:04.627 [DEBUG] [eController$ZWaveReceiveThread:1405]- Receive queue ADD: Length=1
2016-03-29 20:11:04.627 [DEBUG] [b.z.i.protocol.ZWaveController:1163]- Receive queue TAKE: Length=0
2016-03-29 20:11:04.631 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 0D 00 04 00 07 07 60 0D 02 02 25 03 FF 42 
2016-03-29 20:11:04.633 [DEBUG] [b.z.i.protocol.ZWaveController:1164]- Process Message = 01 0D 00 04 00 07 07 60 0D 02 02 25 03 FF 42 
2016-03-29 20:11:04.636 [DEBUG] [b.z.i.protocol.ZWaveController:192 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 07 07 60 0D 02 02 25 03 FF 
2016-03-29 20:11:04.637 [DEBUG] [ApplicationCommandMessageClass:38  ]- NODE 7: Application Command Request (ALIVE:DONE)
2016-03-29 20:11:04.638 [DEBUG] [ApplicationCommandMessageClass:56  ]- NODE 7: Incoming command class MULTI_INSTANCE
2016-03-29 20:11:04.638 [DEBUG] [ZWaveMultiInstanceCommandClass:145 ]- NODE 7: Received Multi-instance/Multi-channel Request
2016-03-29 20:11:04.639 [DEBUG] [ZWaveMultiInstanceCommandClass:452 ]- NODE 7: Requested Command Class = SWITCH_BINARY (0x25)
2016-03-29 20:11:04.640 [DEBUG] [ZWaveMultiInstanceCommandClass:472 ]- NODE 7: Endpoint = 2, calling handleApplicationCommandRequest.
2016-03-29 20:11:04.641 [DEBUG] [.ZWaveBinarySwitchCommandClass:79  ]- Received Switch Binary Request for Node ID = 7
2016-03-29 20:11:04.642 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 7: Switch Binary report, value = 0xFF
2016-03-29 20:11:04.643 [DEBUG] [b.z.i.protocol.ZWaveController:635 ]- Notifying event listeners: ZWaveCommandClassValueEvent
2016-03-29 20:11:04.644 [DEBUG] [.z.internal.ZWaveActiveBinding:433 ]- ZwaveIncomingEvent
2016-03-29 20:11:04.645 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 7: Got a value event from Z-Wave network, endpoint = 2, command class = SWITCH_BINARY, value = 255
2016-03-29 20:11:04.646 [DEBUG] [ApplicationCommandMessageClass:85  ]- Transaction not completed: node address inconsistent.

so it seems that the FGS-222 is sending the wrong endpoint as when switching switch 1 endpoint = 0 is received instead of endpoint = 1:
NODE 7: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 255
when switch 2 is switched the expected endpoint = 2 is received:
NODE 7: Got a value event from Z-Wave network, endpoint = 2, command class = SWITCH_BINARY, value = 255
I don’t know if this could be an issue due from a wrong configuration param or it’s a fibaro software issue but I think it is surely a strange behaviour.

This is something that has been known for a long time (looking back in the old Google groups we looked at this about two years ago :wink:). The problem is also an issue on some versions of the FGS221 (new versions from memory).

The issue is that the device is not using multi-instance messages for switch 1 - only switch 2. Based on this, I think all you should need to do is add the respond_to_basic to the endpoint 1, and then use endpoint 2 normally…

so it should work fine configuring the item this way?
{ zwave=“7:1:command=SWITCH_BINARY,respond_to_basic=TRUE” }

I believe so (but maybe you’re about to tell me it doesn’t :wink:). This should (I think!) cause the multi_instance class to be used to send frames (since I think the device will respond fine to this), but should mean if the device responds without the multi_instance message, it’s still detected by OH…

If that doesn’t work, you could try -:

{ zwave="7:command=SWITCH_BINARY,respond_to_basic=TRUE" }

I tried to find what we used before when we discussed this… @ben_jones12 I think you also have this issue in you FGS221 devices?

I am using a few of these, but they are all a couple of years old so maybe an older firmware version?

Here is an example on my config for one;

Switch      GF_Hallway_Light_Floor      "Hallway Floor"     <light>         (GP_Hallway_Light)      { zwave="16" }
Switch      GF_Hallway_Light_Ceiling    "Hallway Ceiling"   <light>         (GP_Hallway_Light)      { zwave="16:2" }

yes, I think it’s right, for me it’s working with this configuration:
{ zwave=“7:command=SWITCH_BINARY” }
I don’t know if command=SWITCH_BINARY is needed as I have not tried without but it seems that respond_to_basic=TRUE is not needed to make the sw1 work.

Here is my working config.

Switch SW_Kitchen_1 “” (gDashboard) { zwave=“5:command=switch_binary,respond_to_basic=true” }
Switch SW_Kitchen_2 “” (gDashboard) { zwave=“5:2:command=switch_binary,respond_to_basic=true” }

Hello, I am experiencing a similar issue with Fibaro FGS-222 relay not updating its status to the controller when operated manually. I have set up the main controller in association group responsible for report state of device and even tried using the config similar to that of the user" alexander_romanov_pv" but nothing has helped so far. I am using OH2,

Here is how I have setup my configs.

Switch AR_Light1 “Aashini Room Light” [Switchable] {channel=“zwave:device:f8148779:node8:switch_binary1”}
Switch AR_Fan1 “Aashini Room Fan” [Switchable] {channel=“zwave:device:f8148779:node8:switch_binary2”}

The status of the switch_binary2 (i.e. Switch 2) )is updated to the controller when it is operated manually. However when switch_binary1 (i.e. Switch 1) is operated manually (turned on or off from the panel) its state is not updated on OH2’s PAPERUI or BASICUI.

Thanks,
Amar

Use switch_binary instead:

Switch AR_Light1 "Aashini Room Light" [Switchable] {channel="zwave:device:f8148779:node8:switch_binary"}

Thanks sihui, i tried your suggestion and all the relays are working just as expected.

Cheers,
Amar

1 Like

Just following up on this post, I’m getting same issue - manual flick of switch does not report status back to openhab 2.1. if I change to ‘switch_binary’ it works. however the fibaro has 2 x switches in the one unit, for the first I use ‘switch_binary’ (originally had switch_binary1 but had no feedback) so then what would i set the 2nd one too? because switch_binary2 works in terms of turning on/off from openhab gui, but does not report back to gui on a manual flick of the switch?

Or is this more likely a bug in the binding? On latest binding as at today.

If a switch is not reporting back it is most likely a problem of the association group for controller updates, this needs to be set to the controller.
Unfortunately on both of my FGS222 I’m using only one relay, so can’t tell you the settings to make the second one work.
Try all three of the switch_binary channels and see which one works.

Seems you maybe partially right, if I go to properties of the zwave device habmin, then scroll down to association groups, it shows “switch 1 = openHAB Controller” and "switch 2 = " (nothing set) I changed “switch 2” to the openhab controller then saved the changes, however this still does not solve the actual issue - turning on the light connected to switch 2 does not update status in OH GUI.

Interestingly though, if I click “refresh items” under the description section of the zwave item in habmin, it updates the 2nd switches status correctly - but ONLY if the 1st switch is set to “switch”. If the 1st switch is set to “switch1”, it will update the 1st switches status but not the 2nd!!! It does look very much like a bug?

Also discussed here. FGS223 has the same problem.

Cannot confirm that:

Manual switching the attached momentary switches gives me:

2017-09-08 19:02:54.820 [vent.ItemStateChangedEvent] - FibFGS223_1_Sw_2 changed from ON to OFF
2017-09-08 19:02:54.859 [vent.ItemStateChangedEvent] - FibFGS223_1_Scenes changed from 1.1 to 2.0
2017-09-08 19:02:57.759 [vent.ItemStateChangedEvent] - FibFGS223_1_Sw_1 changed from ON to OFF
2017-09-08 19:02:57.800 [vent.ItemStateChangedEvent] - FibFGS223_1_Scenes changed from 2.0 to 1.0
2017-09-08 19:03:02.173 [vent.ItemStateChangedEvent] - FibFGS223_1_Sw_2 changed from OFF to ON
2017-09-08 19:03:02.610 [vent.ItemStateChangedEvent] - FibFGS223_1_Sw_1 changed from OFF to ON

items:

Switch FibFGS223_1_Sw_1 (gRestore) { channel="zwave:device:15ca6a108b9:node30:switch_binary1" }
Switch FibFGS223_1_Sw_2 (gRestore) { channel="zwave:device:15ca6a108b9:node30:switch_binary2" }
Number FibFGS223_1_Scenes { channel="zwave:device:15ca6a108b9:node30:scene_number" }
Switch FibFGS223_2_Sw_1 (gRestore) { channel="zwave:device:15ca6a108b9:node31:switch_binary1" }
Switch FibFGS223_2_Sw_2 (gRestore) { channel="zwave:device:15ca6a108b9:node31:switch_binary2" }
Number FibFGS223_2_Scenes { channel="zwave:device:15ca6a108b9:node31:scene_number" }