Bug (I think?) with Fibaro FGS 223 - driver or device?

🛎️ Get Help Devices
1

Hi,
I've got a bunch of Fibaro FGS 223 double switches, and I'm using @ericm 's driver which is great (this and Eric's driver for the Fibaro Dimmer 2 are the ones to use I think).
However, I've just discovered some very weird behaviour.

They switch on OK, but they then need two off commands to actually switch off.
This is true whether pressing the physical switch), or sending the command from HE.
If it happens from the physical switch, does this suggest it's an issue in the firmware? (though I don't remember this happening when these were running under ST, but I had much bigger problems with ST, so this level of issue would likely have gone un-noticed)
The fact that it happens from HE as well as the switch suggests to me that it's not an issue with the definition with the switch type - I've flicked the driver to "Z wave tweaker" and checked that param 20 is zero.

Weirder still, after sending the 1st "off" from HE, (which does not switch the lights off), if I then send an "on", the lights switch off (this results in motion lighting routines switching the lights off as you walk in to the room!).

I have 7 of these, and I think it's happening on all of them. I've checked the log behaviour on two, and it's identical.

And so to the logs:
Driving from HE, this is one "on" followed by two "off"s:

image
image1534×464 102 KB

The event log for the metering child device only shows the succesfull command, though it does seem to trigger a further power report:

image
image1897×412 28 KB

Now the same, using the physical switch:

image
image1523×520 119 KB

And on to the SUPER weird behaviour - from HE, "on", then "off", then "on":

image
image1579×466 103 KB

The return value of SwitchBinaryReport seems to be pointing to something....

Has anyone spotted this before or got any ideas?

It's annoying, but liveable with the switches, but it makes the motion lighting routines unusable - I could code round the issue and write my own routines for these, but I'd like to fix the root cause if I can.

Eric - if you spot this, and think it might be a driver issue, or fixable within the driver, I'm happy to have a go at tweaking the code with any guidance, or to test any alterations (I can code, though have not (yet) got in to Groovy, or writing drivers)

Cheers,

James

2

Sorry if this is a silly question, but what is the type of switch connected to it. You mention it is set to 0 (momentary), but those aren't very common in the US. It for sure isn't a toggle switch?

3

Hi Eric,
They've all got momentary switches connected - I installed the FIbaros and the switches when I built the house - they're not common here in the UK either!
I've read a fair bit about the switch settings - they seem to be flaky, however I can't really see how the behaviour I'm seeing should have anything to do with parameter 20, as it happens when controlling the Fibaro programmatically, which ought not reference the switch sett up you'd think..
I could try using z wave tweaker to force a change of it and back, or even for a while to change the param to toggle, to see if the module then behaves programmatically at least (though that won't be any good long term!)

4

@ericm - a quick update - I've tried changing the switch type (parameter 20) which seems to need Z wave tweaker to change it.
Whichever setting I use, 0,1 or 2, the behaviour from the Fibaro Double Switch 2 FGS-223 child switch driver on and offs is the same, and as before - the first off does not switch off, but puts it in to a state that the next command, on or off, switches it off.

Looking at the logs for the command sent, and response from the device:
Starting with the light off, clicking "on" shows in the logs:
childOn(C3-ep1)
SwitchBinaryReport: SwitchBinaryReport(value:255) : Endpoint: 1

With the light now on, clicking "off" shows:
childOff(C3-ep1)
SwitchBinaryReport: SwitchBinaryReport(value:255) : Endpoint: 1

from there, clicking "off" again
childOff(C3-ep1)
SwitchBinaryReport: SwitchBinaryReport(value:0) : Endpoint: 1

Alternatively, from the same position (light just turned on, then one "off" sent) you get:
childOn(C3-ep1)
SwitchBinaryReport: SwitchBinaryReport(value:0) : Endpoint: 1

This feels to me like the device is not responding correctly to the command sent, so either the command being sent is wrong in some way or the device is faulty or I've mis-configured the device. I have checked this on three devices, all show this issue. These same devices were previously used on SmartThings for 3 years, and I didn't spot this issue - I think I would have done, though I can't be certain.

Interestingly, if I set the switch to "1", ("Toggle, open = on closed = off") it responds nicely to the momentary switch attached to it - every press causes two events - an off request followed by an on request. If the light was on, the "off" then "on" switches it off. If the light was off, the first "off" is ignored, and the following "on" switches it on.
I'm considering hacking your driver code to emulate this in there.... I've not written any drivers, or Groovy for that matter, but it ought to be possible to add extra commands, possibly with a small time delay.

thoughts?

Best,

James

5

Hmmm, I'm afraid I really don't know what is going on. It seems like a configuration issue, but I haven't seen it happen before.

Like you said, you can code around what you are seeing by sending multiple commands. If you check the childOn & childOff methods you should be able to find what you need.

6

I'm in the UK and have a couple of the Fibaro Double Switch 2's and am using the same driver, also with retractive (momentary) MK grid switches. Mine have worked as intended without issue since installation both from the physical switch and via digital command.

On the other hand I did have a nightmare with Fibaro Dimmer 2's with the same switches. Whichever driver I used for those the switch type would not save (light permanently on unless switch held in) For those I set all parameters via Basic Z Wave Tool and note them in a spreadsheet (I've about 14)

7

Thanks both. @ericm - I've tried doing this in the code:

def childOn(String dni) {
    logging("childOn($dni)")
    def cmds = []
    //JH adding a hack here to work with seemingly faulty units. see post: https://community.hubitat.com/t/bug-i-think-with-fibaro-fgs-223-driver-or-device/88123/4
    //need to send an off then an on
    cmds << new hubitat.device.HubAction(command(encap(zwave.basicV1.basicSet(value: 0x00), channelNumber(dni))), hubitat.device.Protocol.ZWAVE)
	cmds
    pauseExecution(1000)
    logging("childOn($dni) 2nd command")
    cmds << new hubitat.device.HubAction(command(encap(zwave.basicV1.basicSet(value: 0xFF), channelNumber(dni))), hubitat.device.Protocol.ZWAVE)
	cmds
}

but it doesn't work sadly. (with or without the Pause)
I also tried this in the child driver:

void off() {
	parent.childOff(device.deviceNetworkId)
	pauseExecution(1000)
	parent.childOff(device.deviceNetworkId)
}

but that didn't work either.

With your feedback and @johnwill1 I'm beginning to think that something I've done in the configs is tripping them up. I've got associations set up on most of them, driving other devices, and I've wound reporting levels right down to reduce Z wave chatter.
They are also paired as non secure rather than S0, again in order to improve Z wave network performance.

Thanks both - James

8

Trying to decide whether I'm happy that I've finally got to the bottom of this, or whether my fury with Fibaro for their shonky firmware is justified.
I have seven of these installed.
I tested all of them for the issue. One of them doesn't display it.
A comparison of configs found the culprit.

If you set the "First Channel - Operating Mode" param to "delay off", which I had done on all barring one of these (as my daughter is incapable of turning lights off), it causes the switching issue, for both the physical switch and virtual calls.

This is completely inexcusable, and yet somehow not that surprising. Thank you @ericm for all your assistance, and apologies for ever doubting your driver (once I got in to the code I realised it had to be at the device level).
How can Fibaro have let that get through testing? If anyone uses the built in off timer, they'll have to click the switch twice to make it switch off. Just rubbish.

Sorry, I'll stop ranting now (I will quietly seethe for little while longer).

Cheers,

James

3 Likes
9

Well, I'm glad you figured it out! :slight_smile:

1 Like