Every now and then i try to add something to the openhab solution in our house. My wife is very satisfied, so am i
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.
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
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 ).
@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.
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.
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.
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.
).