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

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.

I meant to say:
if you wanted to attach a 2ndary physical switch to S2 and have it behave the same way as your S1-connected switch does, you don’t need this and should electrically attach that 2nd switch to S1 instead.

If you wanted to use S2 as a controller to directly switch some other device, you can do, but if I understood correctly, that’s not what the OP wants, he wants to decide and control inside OH first what to do on S2 button presses.
And now for that purpose, scenes are the better alternative since you need rules to process the button presses anyway and the scene functionality of the FGD allows for options you cannot have with a binary or multilevel switch such as double- and triple-click.

I don’t understand that, that’s not a “workaround” but an alternate system design. I’d even say it’s the primary intended use case while your S2 binary switching is rather not. What is “hard to maintain” in there ?
Scenes are not a global thing. You can setup rules to do whatever you like such as to switch on/off a specific item/light only if that FGD S2 sends a scene id 26 (single click). Another device to send that same scene ID won’t trigger that rule and can be processed independently.
I’m effectively using FGD w/ switches on S2 and scene commands to act as a binary switch-through-OH to switch on/off some of my lights and other loads.

Again, it depends. If you want to use a dimmer, then use the dimmer. If you use scenes, then you will need to keep track of the level yourself.

There are clearly different use cases but I think we’re off the point of this thread…

Hmm, you mean to interactively (dim-)control some other dimmer device but through OH instead of direct association ?
That would mean you press-and-hold the button with no light intensity changing, then if released it sends a message to contain a specific light level that other dimmer would then be set to. No immediate light level feedback as with a directly attached load, pretty unintuitive to use. You are right in that that is a different use case that scenes cannot be used for, but I haven’t heard of anyone to have such a setup to be content with it but of a number of people that own(ed) and dislike it, including myself.
Then again if it’s not about interactive dimming but just about setting a fixed light level (no matter if 100% or less), the level would need to be defined on the server (not by press duration) and the scene-based approach is as well suited as the switch_binary2 one is for that.

Agree, and sorry for insisting - but quite often it’s that people are desperately trying to get something specific to work instead of looking for alternative approaches to accomplish the same. About felt half of my posts on the forum are on this …

For my use case the switch is exactly what i need. And i do understand the scenes offer more options, i see this as a workaround for my use case. Keeping track of scene numbers and what they represent is in my case more difficult then a switch On/Off. But i understand your point, and i will use scenes whenever appropriate.

On topic:
The 19 june version of the dev binding is working. i’ll report the minor issues i have on the dev thread regarding this binding.

Here is the XML: network_fe411e7a__node_13.xml (43.2 KB)

And this is what the log displays:

Everything looks the same. I an only notice one difference; when i press the S2 button, the S1 channel (switch_dimmer) is updated, but the load is not turned on. So it looks like the binding doesn’t recognize the channel from the zwave frame yet. I’m not much into these frames and the protocol itself, but i’m pretty sure the fibaro home center deos recognize the diffent channels, so pure logic would say this information is available in the frame data. The big questio is, is it vendor specific, is it conform protocol and is it possible for the binding to get this channel information?

I would suggest to try excluding and re-including the device and provide the full debug log of what happens. The new binding may not reinitialise the associations if it thinks they were already set.

I wouldn’t have expected it to be. The load is not related to S2, only S1. You click on S2 on the device, it sends an S2 update which the binding is not able to decode properly and it sees it as an S1 update. The load should not change in this case.

There is no channel information being sent - this is the problem. Therefore the binding assumes that it is always switch 0, since these commands are all being sent from the root endpoint. The issue is not an error with decoding these frames - the device needs to be configured to send different frames.

Logic can be wrong :wink: - the data is not available in these frames.

ZWave have made this a very complex area as there are many different ways to configure associations now. There are 2 different command classes, and I think 5 different versions of these classes, and each one does things differently. On top of that, many devices aren’t totally compliant due to the ever changing definition of these classes, so really, it’s a bit messy.

Please try what I suggest above and let me know what happens (along with the full initialisation log).

I still don’t understand that claim. You do not have to track scene numbers. Trigger for updates of the item on “received update 26” and you should be set. Eventually toggle a virtual switch item (i.e. not associated to any binding) whenever that rule triggers if you want some item to show ON or OFF.

FWIW, using the dev version binding with my most-recent FGD-212 set to send scenes on S2 button presses, I’m seeing a) SCENE_ACTIVATION and b) SWITCH_MULTILEVEL from endpoint 2 both being sent one after the other. Only using lifeline association.
Then again, I’m having the problem that that currently does not generate any scene event, but see this thread for more details.

I can confirm that with the DEV binding from 19 juni and after excluding and including, the device channel handling is improved.

I do notice a minor change that could be a bug, depending on the point of view. Pressing physical switch S1 updates channel switch_dimmer1 and not both channels switch_dimmer1 and switch_dimmer as it used to be before.

1 Like

Thanks for the feedback.

I don’t think that this is a bug. The device will use the multi-channel encapsulation so will report the individual endpoints rather than the root device which is reported when not using MC encapsulation.

Fine by me, maybe good to pay attention to this regarding the documentation as it is a change to the current stable.

I’m really happy with this, i just found out that one of my other related questions is fixed too:


endpoints

As i’m working my way through this new binding and doing all this excluding/including stuff, i will report any issues in the other large thread.