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

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.

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.

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.

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.

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…

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

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

1 Like

@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?

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

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.

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.

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

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

Nice work Eric! Very quick to update, including power/energy reporting in the child apps.

Thanks!

Hi Eric

I had your previous Version of the device handler installed and it always showed both of the two switches. Then I added the virtual device handler to be able to toggle only one of the switches instead of both from the main interface. Now I updated to your last version and I only see one switch in the app and I can not install any virtual device handlers anymore. It seams my Smartthings Hub does not detect the second switch of the double relay switch.

Could you please tell me how I can fix this?

Thank you very much and kind regards from Switzerland

Seems I figured it out. Had to change to a different device handler and then back to this one. Now I see both switches in the main list as well as in the details of the device…

Thank you Eric for another great DTH.

Edit: actually just updating it on the web interface is sufficient…

Yep, the “updated()” method just needs to run. This can be done a couple of ways, but the easiest is to just click on the little gear icon in the app and then by hitting “done”. If you were using the Virtual Device Sync app before, you technically don’t need it installed anymore to control both endpoints.

Hey Guys :slight_smile:

I’ve been using the new 223 for about a month without any issues and also a 213 (only using S1) on the same 223 device handler. Major thumbs up on the effort put into the DH’s!!

This weekend I installed another 213 which will be using both the S1 and S2 to control the same set of lights (seeing as it’s the Single 213 Switch). I managed to get it all set up, both the HW and SW, and managed to get everything but S2 to turn the lights on. S1 works fine, I get the status, the monitor reports and the update in the ST app however, S2 I can get a status update in the app when turning on from the switch and app but the lights won’t turn on.

I’m running the 213 off the 223 HD using Android, all settings/params are defaults. Logs when switching S2 shows the switch being triggered.

If anyone can hep it would be greatly appreciated. Originally I added the device via toggling S1 and not the button on the module, so I’m just wondering if this could be down to the module.

One suggestion (if possible) for the DH is to have a toggle between Single & Double Switches so various unused parameters and tiles are removed from the Single Switch UI.

I had a similar issue with the 2 dual switches. I was unable to figure out how they end up doing this, but I had to turn of the power at the mains to get them working. It is almost as if the ends up in a state with the second relay always on or off and not responding to commands. If I’m not mistaken, I had to reset one of mine to factory default before it would start working again. This was a month ago and since then, it has been working fine.

This handler actually wasn’t written for 213, but I could easily adapt it for it. Unfortunately, a toggle switch to change between the two layouts isn’t possible with SmartThings right now so it would have to be a separate handler. As for the second switch, this is from the manual:

“The switch connected to the S2 terminal turns on/of the second load in Double Switch 2, but is optional in Single Switch 2 and pushing it will not affect the status of the device.”

This surprises me as I thought I read that the S2 terminal could be used in a 3-way configuration with a 2nd switch. Maybe that was the Qubino. According to that it seems that S2 (on the FGS-213) is meant for associations and sending scene reports, but not for controlling the load of the light.