New Fibaro Switch FGS-223 is driving me nuts

Hi guys,

so far after creating a new database entry for the first time for the new Fibaro Double Switch 2 - FGS 223 (which took hours, so many parameters…) I succesfully included the device and so far, it’s “nearly” working. What is missing is that the states in OpenHAB get updated when using the hardware switches.

The device has 5 association groups and 2 additional endpoints 1&2. Endpoint 1 is for the first switch, Endpoint 2 is for the second. The assoc groups 2&3 are used to report switch updates for switch 1, assoc groups 4&5 are used to report switch 2 updates.

As the manual states that switch updates are reported as BASIC, I added respond_to_basic=true, but still it doesn’t work. What is working though is, when I add a refresh_interval=xxx so that OH polls the status, but that is unfortunately not an option as I want to control other devices with the second switch without waiting minutes or spamming the Z-Wave network with polling messages.

I assume that I just made a stupid mistake setting up the DB entry or the items or something. Or the device is defect. Actually what I don’t understand yet is how the binding matches an association group to and endpoint, or is this handlet by the protocol?

I added all relevant files while switching the hardware buttons, each button 4-5 times. The only thing I can get out of the log is that the binding receives - or detects - endpoint 0 but it should be 1 or 2.

My current association is that groups 1&3 are assigned to the controller, no other associations are set. Assigning lifeline to the controller only results in more reports for endpoint 0.

My Items File:

Switch			OG_MX_Light				"Max Licht"						<light>			(gLightOG)				{ zwave="31:1:command=SWITCH_BINARY,respond_to_basic=true,refresh_interval=300" }
Number			OG_MX_Light_Power		"Max Licht - Watt [%.1f W]"		<energy>		(gWatts)				{ zwave="31:1:command=METER,meter_scale=E_W" } 
Number			OG_MX_Light_Energy		"Max Licht - KWh [%.2f KWh]"	<energy>		(gEnergy)				{ zwave="31:1:command=METER,meter_scale=E_KWh" } 
Switch			OG_MX_Switch			"Max Schalter"					<wallswitch>	(gSwitch)				{ zwave="31:2:command=SWITCH_BINARY,respond_to_basic=true,refresh_interval=300" }

The device entry that I added to the DB:

http://cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/416

The resulting node XML from OpenHAB:

http://nilsschneider.de/temp/node31.xml

Z-Wave log while I toggle the switches.

http://nilsschneider.de/temp/zwave.log

The device manual:

Would be awesome if someone could shed some light in what I did wrong. Thank you very much!

Nils

I would try and just use the lifeline association group. Normally, this should be all that is needed when linking to a controller.

I would also check your log - put it into debug mode and make sure that you’re receiving something when you press the button. If not, the association is incorrect. If you are, and it’s not updating the item, then the item definition is probably incorrect.

You can use the log viewer on my website to view the log -: http://www.cd-jackson.com/index.php/openhab/zwave-log-viewer

You shouldn’t need polling at all once you get associations working.

So far I did that, I see log entries that are “item not bound to event, endpoint 0, xxx”. That’s totally clear because I don’t have endpoint 0 but only 1 and 2.

The manual states that lifeline is only useful if only one of the switches is used

Please get a debug log and see what is logged when you press a button.

That would be very strange - the lifeline normally sends all information as its designed to connect to a controller.

Do you mean this statement -:

1st association group – “Lifeline” reports the device status and allows for assigning single device only (main controller by default).

If so, this doesn’t mean that only one switch is reported. It means that only one device can be added into this group - ie the controller. This group is designed to report all device status to a main controller - I would definitely try it - it’s what I use on all my Fibaro devices.

Indeed, I totally got the sentence wrong.

Just changed it to what you recommended. Attached is the log with only Lifeline assigned to the controller & no other assignments set. I constantly toggle a switch for about 30 seconds.

As far as I see it, the received endpoint is 0 and therefore doesn’t match an item but it should be 1 or 2

Binding is 1.9.0 snapshot by the way.

Log: http://nilsschneider.de/temp/zwave_lifeline.log

Best,

Nils

Node is 31, search string:

NODE 31: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY

Yes, the device isn’t sending multi_instance messages. I suspect that this is the same issue as the Qubino devices which require the multi_instance_association class. Unfortunately, this is a lot of work to implement - it requires quite a large change to the binding structure so probably won’t be included into OH1.

That’s just a guess of course - there might be something else behind it, but I think I read somewhere that this was the recommended approach for new devices.

This most likely works in OH2 by the way (assuming it is the same as the Qubino devices).

Oh…

Will try OH2 again then, previously what forced me not using it were the missing channels for switches that send scenes, but as you said you added them to the DB I’ll give it another try…

Hopefull my new DB entry works in OH2 also.

Yes. but it’s not in the current version. I’ll add it tonight (and thanks for your work adding that - it’s appreciated).

If it doesn’t work on OH2, then well work this through in more detail to make sure we get it working, but I’m hopeful that it will be solved with the multi_instance_associations… (I was just looking at buying one, but my usual store doesn’t have this device yet).

Good to hear that, thank you. I fixed some copy-paste/typos parameter errors after your review.

I have a small suggestion for the editor with a huge benefit: After adding something, scroll to the actual parameter that has been added, not to the start of the configuration list :smile: This’d save hours.

It’s a huge device with so many parameters, I kept scrolling all the time. After adding a parameter X, I had to scroll all the way down to add the options, and again after every option etc. Last hack was to ctrl+click on the “Add Option” as many time as there were options available, so I had a new browser tab for each option.

Not sure if that is doable, I’m no web developer. Just a suggestion :slight_smile: That editor is highly appreciated, awesome that I can just use a button to export an XML for each OH version.

Back to topic: I’ll try tomorrow after you added the device and keep this thread updated.

I see there is no new build available yet (not sure what is ‘tonight’ in your timezone), but still I already set up OH2 again and played around with it.

Biggest problem for the moment is, that all Z-Wave switches don’t update their state, regardless of the device. Thing says it’s “Online”, detected correctly and I have valid items assigned. If I toggle switches in the classic UI or HABmin my lamps react correctly, if I do the same in the Paper UI, nothing happens.

But if I toggle using hardware buttons, the state is not displayed in either UI. Also a smarthome:items still lists the item as state OFF although I turned on the light.

Item:

DG_Light (Type=SwitchItem, State=OFF, Label=Dachboden Licht, Category=Light)

Link:

DG_Light -> zwave:device:5b3f5e57:node29:switch_binary1

So far, OH2 doesn’t seem to be very stable in general. PaperUI has a lot of refresh problems, may also crash completely but a reload of website helps most of the time.

What I’d love to see is an integrated “update binding xy” mechanism to have an easy way to update the Z-Wave Binding with the latest DB entries.

I guess I should probably spawn a new thread for this stuff :slight_smile:

I definitely need more time, would love to get a dev environment running to contribute.

Hmmm - it looks like the build is broken. There were some changes to the repository structure during the week, and as it’s been 6 days since the last build I’m guessing it’s associated with that.

UK… The build normally happens around 3AM UTC.

Normally this is associated with associations not being configured - you should make sure that they are configured. Obviously for the FGS223 we know this needs further investigation, but if this is for other switches as well, then you need to look at the associations.

Sure there is. It’s very easy to update the binding - just go the Extensions menu in either PaperUI or HABmin. Find ZWave binding and uninstall it, then install it again and it will pick up the latest version.

This will pull a new binding version? Awesome :slight_smile:

As for the associations, I expected these to be stored on the devices itself, so if I shutdown OH1, won’t I have the same associations in OH2 after startup? If not, that would explain the state update issue of course.

Yes - it will grab the latest snapshot build. At the moment it seems that builds are disabled for some reason, so it won’t do too much…

Yes - that’s correct. Once they are configured, then it is set in the device and will survive OH restarts and power cuts…

Hi,
I have some problems with FGS223. I’m trying to include it in the network and i cant finish the process. The relay is grey in Habbmin and i think the including process is not completed because the device name is: Fibaro System [ID:1000,Type:203] so i don’t see his name like Fibaro FGS223 double relay switch 2x1,5 kw as i see for my old FGS222!
I tried pressing 3 times quickly the button connected to S1 as it says in the specs, i did this process near the aeon stick but the same, the devices stays in grey color in Habmin. I can use it to turn the light on/off from OH but if i turn it on/off from the wall switch it doesn’t update the status in OH and also the watts and kwh functions don’t work (i think) they don’t report the values.
Can someone please help?
PS: i have OH 1.8.3 and the zwave 1.8.3 binding.
Thanks.

For newer hardware you need to use the 1.9 snapshot binding…

Hi,

since my update to OH 2 and the 2.0 binding I have the same problem with my Fibaro Switches. I have FGS211 and FGS222 devices and now with all that switches the same problem that the status won’t be reported to the controller when switched by the hardware switch.
I have associated key 1 with the controller as well as settings for the controller updates to the opehHAB controller.
Status updates for key 2 still work perfectly. In OH 1 I set respond_to_basic=true and with that setting the status updates worked well for key 1.
Is there a similar parameter in OH 2 or is there another solution for that problem?

If you need further information (logs etc.) please let me know.

Best regards,
Jens

Yes - the database has a tickbox for this -:

I would suggest checking the logs to see what is happening - otherwise it’s hard to know what the problem actually is…

Where can I set that? I can’t find that setting…

Here’s the log, when I use the wall switch manually. Node 27 is the device in question.

2016-12-24 21:51:52.866 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 27: Transaction not completed: node address inconsistent.  lastSent=27, incoming=255
2016-12-24 21:52:00.435 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 1B 03 25 03 FF 33
2016-12-24 21:52:00.440 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-12-24 21:52:00.444 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 1B 03 25 03 FF 33
2016-12-24 21:52:00.447 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 1B 03 25 03 FF 33
2016-12-24 21:52:00.449 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 1B 03 25 03 FF
2016-12-24 21:52:00.451 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 27: Application Command Request (ALIVE:DONE)
2016-12-24 21:52:00.452 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 27: Starting initialisation from DONE
2016-12-24 21:52:00.455 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1d05a04 already registered
2016-12-24 21:52:00.457 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 27: Incoming command class SWITCH_BINARY
2016-12-24 21:52:00.458 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - Received Switch Binary Request for Node ID = 27
2016-12-24 21:52:00.460 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 27: Switch Binary report, value = 255
2016-12-24 21:52:00.461 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-12-24 21:52:00.463 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-12-24 21:52:00.465 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 255
2016-12-24 21:52:00.468 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Updating channel state zwave:device:22160db1:node27:switch_binary to ON [OnOffType]
2016-12-24 21:52:00.474 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=27, callback=206, payload=1B 07 60 0D 01 01 25 01 FF
2016-12-24 21:52:00.477 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 1B 03 25 03 FF
2016-12-24 21:52:00.479 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=206, expected=SendData, cancelled=false      MISMATCH
2016-12-24 21:52:05.965 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 1B 03 25 03 00 CC
2016-12-24 21:52:05.970 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-12-24 21:52:05.973 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 1B 03 25 03 00 CC
2016-12-24 21:52:05.976 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 1B 03 25 03 00 CC
2016-12-24 21:52:05.978 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 1B 03 25 03 00
2016-12-24 21:52:05.980 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 27: Application Command Request (ALIVE:DONE)
2016-12-24 21:52:05.981 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 27: Starting initialisation from DONE
2016-12-24 21:52:05.983 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1d05a04 already registered
2016-12-24 21:52:05.984 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 27: Incoming command class SWITCH_BINARY
2016-12-24 21:52:05.986 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - Received Switch Binary Request for Node ID = 27
2016-12-24 21:52:05.987 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 27: Switch Binary report, value = 0
2016-12-24 21:52:05.988 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-12-24 21:52:05.989 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-12-24 21:52:05.991 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 0
2016-12-24 21:52:05.993 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Updating channel state zwave:device:22160db1:node27:switch_binary to OFF [OnOffType]
2016-12-24 21:52:05.999 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=27, callback=206, payload=1B 07 60 0D 01 01 25 01 FF
2016-12-24 21:52:06.002 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 1B 03 25 03 00
2016-12-24 21:52:06.003 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=206, expected=SendData, cancelled=false      MISMATCH
2016-12-24 21:52:09.291 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Command received zwave:device:22160db1:node27:switch_binary1 --> OFF
2016-12-24 21:52:09.293 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 27: Creating new message for application command SWITCH_BINARY_SET
2016-12-24 21:52:09.295 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: Encapsulating message, instance / endpoint 1
2016-12-24 21:52:09.297 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 27: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 1
2016-12-24 21:52:09.308 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2016-12-24 21:52:09.308 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2016-12-24 21:52:09.312 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0E 00 13 1B 07 60 0D 01 01 25 01 00 25 CF 5D
2016-12-24 21:52:09.315 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 27: Sending REQUEST Message = 01 0E 00 13 1B 07 60 0D 01 01 25 01 00 25 CF 5D
2016-12-24 21:52:09.442 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2016-12-24 21:52:09.449 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-12-24 21:52:09.452 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
2016-12-24 21:52:09.456 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
2016-12-24 21:52:09.457 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 CF 00 00 0D 29
2016-12-24 21:52:09.459 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
2016-12-24 21:52:09.460 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 27: Sent Data successfully placed on stack.
2016-12-24 21:52:09.464 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-12-24 21:52:09.467 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 CF 00 00 0D 00 00 27
2016-12-24 21:52:09.470 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 CF 00 00 0D 00 00 27
2016-12-24 21:52:09.472 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=CF 00 00 0D
2016-12-24 21:52:09.474 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 27: SendData Request. CallBack ID = 207, Status = Transmission complete and ACK received(0)
2016-12-24 21:52:09.476 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 27: Starting initialisation from DONE
2016-12-24 21:52:09.478 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1d05a04 already registered
2016-12-24 21:52:09.481 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=27, callback=207, payload=1B 07 60 0D 01 01 25 01 00
2016-12-24 21:52:09.484 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=CF 00 00 0D
2016-12-24 21:52:09.486 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=207, expected=SendData, cancelled=false        transaction complete!
2016-12-24 21:52:09.487 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2016-12-24 21:52:09.488 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2016-12-24 21:52:09.490 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 27: Response processed after 61ms/4272ms.