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.
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.
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 - 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.
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.
- the data is not available in these frames.