Can't get the zwave binding to update the S2 switch from a Fibaro FGD-212

Every now and then i try to add something to the openhab solution in our house. My wife is very satisfied, so am i :slight_smile:

Now i have this Fibaro FGD212 dimmer. This dimmer has two switches S1 and S2. The S1 is controlling the light and works as expected. I would like S2 to do something different. For that i need S2 to toggle a switch in openhab and can’t get it to work. It looks like openHAB does not respond to a state change of the S2 button when pressed.

my setup:

Dimmer	verd0_wc_verlichting_dimmer		        "Verlichting S1 [%d %%]"		<light>		(_grpVerd0,_grpVerlichting,_grpPersist)		["Lighting"]	{ channel="zwave:device:30c1ca56:node13:switch_dimmer" }
Switch	verd0_wc_verlichting_dimmer2		    "Verlichting S2 "	<light>		(_grpExtraSchakelaar)		                	            { channel="zwave:device:30c1ca56:node13:switch_binary2"}
Slider item=verd0_wc_verlichting_dimmer
Switch item=verd0_wc_verlichting_dimmer2

The regular S1 button shows this in the log:

The alternative S2 button shows this in the log:

Not sure how this works, but i think i should have expected the orange bar to be listing: node13:switch_dimmer2

I’m using the binding that is provided by openhab 2.4 snapshot 1302

long version:

short version: I think you have to manually add the s2 association group to openHab Controller via habmin. for this go to habmin -> configuration -> things -> your fibaro module -> association groups

Which version do you have?

Normally the Fibaro devices use MC command encapsulation, but from the log, this doesn’t seem to be the case. This means it’s not possible for the binding to know which channel is changing.

It may be that newer Fibaro devices use a new feature to configure this - can you post the XML for this node that OH creates (this is in the {userdata}/zwave folder).

Normally this is not a good idea as it will normally result in duplication of commands. The controller group should be all that is needed on such devices and I don’t think it’s the issue here since updates appear (from the logs anyway) to be being sent.

AFAIK you can only use S2 on FGDs to be scene switches, none of switch_binary type, so your channel definition would need to read { channel="zwave:device:30c1ca56:node13:scene_number" }.

According to the database, these endpoints support the SWITCH_BINARY command class, so it should be possible to use this. In fact, the database doesn’t show the SCENE classes at all.

There are often many different versions of these devices though, and the database is for an early version, so it may require a new definition if there newer versions (hence my original question about what the version is that we are looking at here :wink: ).

Do you both talk about the same device ? The thread title is bad, the dimmer is not FGS but FGD.

@DubZ that is what i thought. And i was wrong, it resulted in double messages exactly what @chris said. That is why you see double messages in the S2 log. I removed the group Association with the controller, and now the double messages are gone.

The node is a Fibaro FGD212 v2 dimmer with firmware 3.4. I have some firmware v3.5 nodes, but i don’t notice any difference.
The XML file:
node13.xml (38.0 KB)

I’m sorry i made a typo in the title, i just corrected it.

I was looking at the FGS212 - as per the title of the thread (although I see it’s changed now).

If that is true, what is the purpose of the channel switch_dimmer2

Looking at the XML, I suspect that this requires MC associations. It might be worth trying the development version -:

This has improved handling of the MC associations and would be worth trying as I think this probably needs enabling.

Don’t know, but that would refer to a 2nd output(-only) channel (that the FGD does not have).
Unlike S1 to directly affect the load, too, S2 is about input only.

I don’t think it’s correct that these devices only send scene commands on the second switch - they should work as dimmers as well.

Well there’s parameter #41 to enable scene commands on S2 input. Didn’t check what happens if you turn it off (I also think that behavior changed somewhat over FGD versions). Maybe S2 will then act just like S1, but that does not make much sense since if you want that, you can physically connect multiple multiple switches to S1 as well.

Of course it makes sense - it can be used as a controller - either to just send commands to the controller for use in rules etc, or to directly control other devices.

I’m not sure I understand your point - S2 is a controller, so it sends commands. The fact that it doesn’t have a physical dimmer/switch connected to it doesn’t matter - it’s otherwise the same.

Anyway, this is confirmed in the manual -:

Ok so you can use it to (usually directly) switch some other device. Possibly, coming back to the original request, if you enter the zwave controller to be the target of association #4 or #5 and set #41 to disable scenes, you might get to see S2 button presses as switch_binary2 events. The manual isn’t explicit about that, though, and I never tried.

Personally, I would suggest to try the development version. As I said above, I don’t think that adding the extra associations is a good idea - this will simply cause duplication.

The log presented above clearly shows that S2 is sending commands, so associations are working. The problem is that the data is not encapsulated so it’s not possible to differentiate the endpoints (so we can’t tell what switch it comes from). The development version handles this a lot better and should enable MCA.

Anyway, just my 2c worth…

You can also play with param #25 (it determines which actions will not result in sending frames to association groups). But it would still be a binary or multilevel switch, right ?
Anything wrong with enabling scenes instead ?
Gives you the opportunity to distinguish single-, double-, triple-clicks so more options to choose from.

That was exactly my way of thinking and the result was duplicate messages as Chris said.
But duplicate messages or not, the switch is not updated, not once not twice. So the binding does not recognize the command, maybe due to the binding not handling it ‘right’, maybe due to the fibaro doing crazy stuff.

With paramter 41 set to enable the scenes workaround is doing allright, but as with many workarounds they are hard to maintain. So i still want to look for the ‘native’ way.
So i just installed the dev zwave binding, and need to fix all my other devices first. Do i need to remove the XML or exclude/include the device to get the proper CM command stuff?

It depends on how you want to use the device. If you want to connect this to a dimmer, then scenes are not the way to go. If you want to use it with rules, then scenes would be a good option.

As above, this is caused by the device not sending the commands encapsulated with the endpoint so the binding doesn’t know what switch it came from. This is why you end up with switch 1 being updated in both cases.

No - the binding will actually create different XML files so you can swap back. Note that you will need to delete the things and add them back - this just ensures that the binding picks up the new thing definitions.

Please read the first 6 or so messages in the link I posted - this should help with the install.