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 
).
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.
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?
