[OBSOLETE] Fibaro Single Switch 2 FGS-213 & Double Switch 2 FGS-223

Devices & Integrations Community Created Device Types
1

Update: I have pushed an update to the FGS-223 handler that uses SmartThings new composite device type. This allows both switch endpoints to be used without the “Virtual Device Sync” app to be installed. If you update to this version you need to remove virtual device sync and the virtual devices it creates. If you are not updating but installing a new device, you do not need to take that stop.

This is a handler that I made some time ago and have had a few people have to hunt for it. They are both great devices that I highly recommend. The handler has the following configuration options (Those that are “second channel” settings are for the FGS-223 only):

9 Restore state after power failure
10 First channel - operating mode
11 First channel - reaction to switch for delay/auto ON/OFF modes
12 First channel - time parameter for delay/auto ON/OFF modes
13 First channel - pulse time for flashing mode
15 Second channel - operating mode
16 Second channel - reaction to switch for delay/auto ON/OFF modes
17 Second channel - time parameter for delay/auto ON/OFF modes
18 Second channel - pulse time for flashing mode
20 Switch type
28 S1 switch - scenes sent
29 S2 switch - scenes sent
50 First channel - power reports
51 First channel - minimal time between power reports
53 First channel - energy reports
54 Second channel - power reports
55 Second channel - minimal time between power reports
57 Second channel - energy reports
58 Periodic power reports
59 Periodic energy reports

Button Mappings for scene functionality:

Toggle Mode
1 pushed - S1 1x toggle
4 pushed - S1 2x toggle
5 pushed - S1 3x toggle

1 held - S2 1x toggle
4 held - S2 2x toggle
5 held - S2 3x toggle

Momentary Mode
1 pushed - S1 1x click
2 pushed - S1 release
3 pushed - S1 hold
4 pushed - S1 2x click
5 pushed - S1 3x click

1 held - S2 1x click
2 held - S2 release
3 held - S2 hold
4 held - S2 2x click
5 held - S2 3x click

452×914 69.7 KB
225×914 66.1 KB

225×914 64.9 KB
225×914 67.1 KB
230×914 65.6 KB

Install the single handler below for the Single Switch 2 FGS-213

Install BOTH Handlers Below for the Double Switch 2 FGS-223

9 Likes
2

I just dont get it…

I have everthing installal, working fine exppt i want the double switches working separtly.

Switch 1: goes to my hallway light - Manual control
Switch 2: goes to porch light - This i want to att to my “turn on att sunset”

So can i make it two separate switches in any way?

3

Try the virtual device sync app that is mentioned in the post.

4

@erocm1231 first, thanks for this code and for all your hard work.

I’m having trouble using your code with my Fibaro 223. Controlling the switches via Smartthings works, however, I’m having issues when toggling the physical switches. One of the switches seems to work fine, but whenever I toggle the second I see this in the logs:

12:07:18 PM: error groovy.lang.MissingMethodException: No signature of method: script1493071460799176112215.zwaveEvent() is applicable for argument types: (physicalgraph.zwave.commands.basicv1.BasicSet, java.lang.Integer) values: [BasicSet(value: 255), 2] Possible solutions: zwaveEvent(physicalgraph.zwave.commands.basicv1.BasicSet), zwaveEvent(physicalgraph.zwave.Command), zwaveEvent(physicalgraph.zwave.commands.associationv2.AssociationReport), zwaveEvent(physicalgraph.zwave.commands.basicv1.BasicReport), zwaveEvent(physicalgraph.zwave.commands.centralscenev1.CentralSceneNotification), zwaveEvent(physicalgraph.zwave.commands.configurationv2.ConfigurationReport) @ line 198 12:07:18 PM: debug MultiChannelCmdEncap MultiChannelCmdEncap(bitAddress: false, command: 1, commandClass: 32, destinationEndPoint: 0, parameter: [255], sourceEndPoint: 2)

Any ideas?

5

It seems to work if I modify line 110 to add a second parameter like this:

def zwaveEvent(physicalgraph.zwave.commands.basicv1.BasicSet cmd, ep=null) {

Does that seem right?

6

Alright, I just released an update that should have everything working. You were right about the change mentioned and a lot of other updates needed to be made. SmartThings seems to be really sluggish lately or maybe it is just me. Commands are taking a lot of time to get from device to being processed and it is throwing off testing.

7

@erocm1231 i updated to the latest handler and while things have improved, I still experience an issue with energy reporting where sometimes the energy report is missed. These images below were taken 5 mins after turning off switch 2. If I hit the refresh button everything syncs up again.

fullsizeoutput_58df.jpeg750×1334 75.8 KB
fullsizeoutput_58e0.jpeg750×1334 92.6 KB

Here is one 2 mins after turning switch 2 on via the switch 2 button on the parent handler.

fullsizeoutput_58e1.jpeg750×1334 103 KB

This is a segment of the log for that event.

56517ed3-130a-4e2e-8bc3-12582633abf9 08:58:44: debug SwitchBinaryReport: SwitchBinaryReport(value: 255) : Endpoint: 2
56517ed3-130a-4e2e-8bc3-12582633abf9 08:58:43: debug childOn(0C-ep2)
56517ed3-130a-4e2e-8bc3-12582633abf9 08:58:36: debug MeterReport: MeterReport(deltaTime: 0, meterType: 1, meterValue: [0, 0], precision: 1, previousMeterValue: [0, 0], rateType: 1, scale: 2, scale2: false, scaledMeterValue: 0.0, scaledPreviousMeterValue: 0.0, size: 2) : Endpoint: 2
56517ed3-130a-4e2e-8bc3-12582633abf9 08:58:36: debug SwitchBinaryReport: SwitchBinaryReport(value: 0) : Endpoint: 2
56517ed3-130a-4e2e-8bc3-12582633abf9 08:58:36: debug MeterReport: MeterReport(deltaTime: 0, meterType: 1, meterValue: [0, 0], precision: 1, previousMeterValue: [0, 0], rateType: 1, scale: 2, scale2: false, scaledMeterValue: 0.0, scaledPreviousMeterValue: 0.0, size: 2) : Endpoint: 1
56517ed3-130a-4e2e-8bc3-12582633abf9 08:58:35: debug MeterReport: MeterReport(deltaTime: 0, meterType: 1, meterValue: [0, 0, 13, 146], precision: 2, previousMeterValue: [0, 0, 0, 0], rateType: 1, scale: 0, scale2: false, scaledMeterValue: 34.74, scaledPreviousMeterValue: 0.00, size: 4) : Endpoint: 1
56517ed3-130a-4e2e-8bc3-12582633abf9 08:58:35: debug MeterReport: MeterReport(deltaTime: 0, meterType: 1, meterValue: [0, 0], precision: 1, previousMeterValue: [0, 0], rateType: 1, scale: 2, scale2: false, scaledMeterValue: 0.0, scaledPreviousMeterValue: 0.0, size: 2) : Endpoint: null
56517ed3-130a-4e2e-8bc3-12582633abf9 08:58:34: debug SwitchBinaryReport: SwitchBinaryReport(value: 0) : Endpoint: 2

8

When you say the energy report is missed, are you seeing it in the log, but it is not updating the child device?

What are your reporting intervals for channel 1 and channel 2?

Also, what is your reporting interval for the last two power / energy options? I really don’t understand the difference between the last two and the channel options. The controller sends channel 1 power / energy stats twice (once as a multichannel command and once as a meter command) and channel 2 power / energy once (as a multichannel command). I believe the last two options are regarding the meter commands for channel 1, but that is totally redundant so I changed them back to the default of 3600 and have the channel reports coming much more often. I expected the controller to send cumulative reports as a meter report, but it never does. I have to tally the cumulative manually in the handler.

I also believe that this device does respond well when sending multiple commands to it while it is sending commands to the hub. The device was not responding to several commands so I added a delay between some of them which seems to have helped.

9

No, the power/energy reports do not appear in the log on switch change, only on a refresh. Reporting intervals are all default. If I reduce the periodic energy and power reports for 3600 (1hr) to 10 seconds I do get regular updates. What doesn’t seem to be happening is the power/energy reports based on power level change.

10

I’m reading through the manual and I think ultimately I need clarification on what the power / energy parameters do. My theory right now is that 58 & 59 set an interval for both channels. The CH1 and CH2 specific parameters set conditions that must be met in order for 58 & 59 to actually send a report. It kind of makes sense and seems like it is how it is working, but clarification would be great.

11

I had a play with the parameters this morning. 58 and 59 do set the interval for both channels as each time it reports I see endpoint null, endpoint 1 and endpoint 2. This except is a power report with switch 1 on and switch 2 off. the load is around 206W.

56517ed3-130a-4e2e-8bc3-12582633abf9 08:38:24: debug MeterReport: MeterReport(deltaTime: 0, meterType: 1, meterValue: [0, 0], precision: 1, previousMeterValue: [0, 0], rateType: 1, scale: 2, scale2: false, scaledMeterValue: 0.0, scaledPreviousMeterValue: 0.0, size: 2) : Endpoint: 2
56517ed3-130a-4e2e-8bc3-12582633abf9 08:38:22: debug MeterReport: MeterReport(deltaTime: 0, meterType: 1, meterValue: [0, 0, 21, 189], precision: 2, previousMeterValue: [0, 0, 0, 0], rateType: 1, scale: 0, scale2: false, scaledMeterValue: 55.65, scaledPreviousMeterValue: 0.00, size: 4) : Endpoint: 2
56517ed3-130a-4e2e-8bc3-12582633abf9 08:38:21: debug MeterReport: MeterReport(deltaTime: 0, meterType: 1, meterValue: [8, 7], precision: 1, previousMeterValue: [0, 0], rateType: 1, scale: 2, scale2: false, scaledMeterValue: 205.5, scaledPreviousMeterValue: 0.0, size: 2) : Endpoint: 1
56517ed3-130a-4e2e-8bc3-12582633abf9 08:38:19: debug MeterReport: MeterReport(deltaTime: 0, meterType: 1, meterValue: [0, 0, 13, 214], precision: 2, previousMeterValue: [0, 0, 0, 0], rateType: 1, scale: 0, scale2: false, scaledMeterValue: 35.42, scaledPreviousMeterValue: 0.00, size: 4) : Endpoint: 1
56517ed3-130a-4e2e-8bc3-12582633abf9 08:38:17: debug MeterReport: MeterReport(deltaTime: 0, meterType: 1, meterValue: [8, 12], precision: 1, previousMeterValue: [0, 0], rateType: 1, scale: 2, scale2: false, scaledMeterValue: 206.0, scaledPreviousMeterValue: 0.0, size: 2) : Endpoint: null

However, parameter 51 and 55 (minimum time between reports) are channel dependent and override the regular reporting intervals. If you have 58/59 set for 30 seconds and 51/55 set for 10 mins you only get a report every 10 mins. If you trigger a power report as a result of a power change (light on/off) then this restarts the clock and your next timed report will be 10 mins later. This seems to work as documented.

What I have noticed is that changing switch 1 will most of the time result in an update to the power/energy showing on the tile. Changing switch 2 almost never results in a change to the power/energy showing on the tile. It doesn’t seem to matter if you use the parent device or the child device.

There is also some unreliability when setting parameters. If I change a parameter in the app and then hit “done” I aways get a line like the following for each change.

56517ed3-130a-4e2e-8bc3-12582633abf9 09:03:10: debug Parameter 51 will be updated to 10
56517ed3-130a-4e2e-8bc3-12582633abf9 09:03:10: debug updated() is being called

I don’t always see the following ‘confirmation’ that the parameter has been set.

56517ed3-130a-4e2e-8bc3-12582633abf9 09:03:12: debug T - Lounge Dining Main parameter ‘51’ with a byte size of ‘1’ is set to ‘10’

Here is some logging I did while testing this.

12

So, I was observing similar behavior for my FGS-223 units (no reports on power changes on channel 2 no matter the configuration) it sends both reports for ch1 and ch2 on changes on ch1.

Was unable to find solution on my own (i tried messing with associations including multichannel ones, parameters, removing device from network, resetting to factory and readding) - looks like a firmware bug. :frowning:

I found few threads for other z-wave HUBs about this issue, some reporting they solved it but I don’t think they tested the specific conditions correctly.

Fibaro is a Polish company so as a Polish person I wrote them an email in Polish, asking for solution and reporting the issue. I hope there will be someone technical on the other side willing to talk. I didn’t mention what HUB i’m using on purpose :stuck_out_tongue_winking_eye:

In Poland we have a holiday on 1st nad 3rd (and most business are closed on 2nd) so I wouldn’t expect answer until 4th of May.

PS. My proposed workaround for now: add Get commands few secs after “on” and “off” commands (few secs so any inrush currents etc have chance to stabilize) and then set periodic reporting to every 30sec to a minute or something like that (depending on time resolution you want for second channel, this shouldn’t affect ch1 resolution). just don’t set it too short so it doesn’t create to much traffic…

13

I was so bothered by this bug (which is not a bug - read on! ) that I had trouble sleeping (I tend to lie in bed thinking about code before sleep when I have something to solve). So in the morning I sat down and some time later I think I have a solution that is simpler then I could expect.

All thanks to this post: How to set Multichannel Associations to endpoints of a device and information I found somewhere online that normal association for this device is a “no no” and you have to set a multi channel one.

We have to do 2 things during device initialization and/or update:

  • remove current single point association to the hub (this is critical, I didn’t do that yesterday so I though that the next step isn’t working):
    zwave.associationV2.associationRemove(groupingIdentifier: 1, nodeId: zwaveHubNodeId)
  • add a multi channel one:
    zwave.multiChannelAssociationV2.multiChannelAssociationSet(groupingIdentifier: 1, nodeId: [0,zwaveHubNodeId,1])

After that you can check with:

zwave.associationV2.associationGet(groupingIdentifier: 1)
zwave.multiChannelAssociationV2.multiChannelAssociationGet(groupingIdentifier: 1)

You should Receive:
AssociationReport(groupingIdentifier: 1, maxNodesSupported: 1, nodeId: [], reportsToFollow: 0)
MultiInstanceAssociationReport(groupingIdentifier: 1, maxNodesSupported: 1, nodeId: [0, 1, 1], reportsToFollow: 0)

Notice empty nodeID for normal association.

After this I’m getting SwitchBinaryReport and MeterReport events with specified endpoints superatlety for both channels (no need to use any other association group to get the state for 2nd switch)

PS. @erocm1231 - I’ve also read that Qubino relays behave similarly and I noticed that you have DTH for them so maybe they are worth a look.

1 Like
14

Wow, great information. I will definitely check this out. Thanks!

1 Like
15

@ClassicGOD So I have tried out your recommendations and they work exactly how you have described. I am confused about how one thing is working though. I cross referenced what you posted as the multiChannelAssociationSet nodeId with the link you posted. You list nodeId: [0,zwavehubNodeId,1]. The link mentions an initial nodeId, followed by a zero (0) marker, followed by pairs of nodeId & endpoints. So I am guessing that by ommiting the initial nodeId you are specifying not to send non-endpoint reports (since we are only concerned about the endpoints). Then you are telling the device to associate the SmartThings hub with endpoint 1 which tells the device to send SwitchBinaryReport and MeterReports encapsulated from endpoint 1. But shouldn’t endpoint 2 be in there as well? i.e. [0,zwavehubNodeId,1,zwavehubNodeId,2] It is sending reports from endpoint 2, so I guess there must be something I am missing.

Also, why is it required to remove the initial association with the hub? If there is a regular association for the group does it take precedence over the MutliChannel one?

16

I was also confused by this to the point I started experimenting with raw commands I saw somewhere on the internet and look what device returned after I set them.

My understanding is:

  • the nodes before the ‘0’ marker are “non multi channel nodes” (functionality is probably there for backwards compatibility)
  • after the ‘0’ marker comes the list of multi channel nodes in pairs with endpoints
  • the endpoints in mentioned pairs are not endpoints of the device but endpoins of the target node to which the data should be sent. so [0, 1, 2] is not “send the data from my endpoint 2 to node 1” it is “send my data from this association group to endpoint 2 of node 1”
  • association group 1 is a Life Line that sends all the device data and accepts only one node, [0,zwavehubNodeId,1,zwavehubNodeId,2] would try o set 2 nodes for this group and would be ether rejected or second node would be ignored
  • for the same reason my early experiments with [zwavehubNodeId,0,zwavehubNodeId,1] failed (it’s setting 1 ‘legacy’ association and 1 multi channel association for association group that accepts only 1)
  • removing the initial association for group 1 is required because setting it forces multi channel association for group 1 to [1] (1 non multi channel node) and will not allow us to add second one for [1,1]

You can test it sending the association for one of the groups that accept more than 1 node

zwave.multiChannelAssociationV2.multiChannelAssociationSet(groupingIdentifier: 2, nodeId: [1,0,2,1])

Would set 1 “legacy association” for node 1 and 1 multi channel one for node 2 endpoint 1
so AssociationReport would return:

AssociationReport(groupingIdentifier: 2, maxNodesSupported: 5, nodeId: [1], reportsToFollow: 0)
(one node)

MultiInstanceAssociationReport would return:

MultiInstanceAssociationReport(groupingIdentifier: 2, maxNodesSupported: 5, nodeId: [1, 0, 2, 1], reportsToFollow: 0)
(both nodes)

1 Like
17

Also, why is it required to remove the initial association with the hub? If there is a regular association for the group does it take precedence over the MutliChannel one?

This is a requirement in the Z-Wave specs if i recall correctly. The Lifeline group can have only 1 member at a time. So in case a singlechannel Lifeline association was created during inclusion (ST does this automatically for all included devices without a custom handler) the nodeId 1 needs to be removed from the group before a multichannel Lifeline association can be set.

In regards to the MC and non-MC Association Set commands; In case the non-MC nodeId is present in the MC Association Set command (the values before the 0x00 mark) it takes precedence over the MC nodeId/endpoint combinations, so the following ones get ignored when creating Lifeline groups. This is specific for the Lifeline group though, on MC association groups >1 all the non-MC nodeId’s and the MC nodeId/endpoint combination are taken into account and stored by the device, as long as you’r not exceeding the allowed members limit.

18

Hi there people, how are you?

I’m thinking to change my vera home for Smarthings and I have some doubts with issues you talk here, I bought a lot of Fibaro Double Switch 223 in order to command 2 switches in some places at home so, Is this issue solved completely? is it possible in some way to have this module running with both switches independently?
I will waiting for an answer to make my decision changing vera for Smarthings Hub.
Thanks in advance.

19

The issue being discussed above only affects the energy and power updates. For just switching on an off, the new parent and child device handler Eric has created work perfectly. I am very happy with them.

2 Likes
20

I did finally push the updates that @ClassicGOD recommended. I have found them to be a more efficient way to communicate with the device and most likely how Fibaro meant for the device to be programmed. If you do update to this version, hit the “configure” button afterwards to make sure the proper associations get set.

2 Likes