Yes, this is what I mean. I’ve also set BASIC SET and can see it in the logs. But it doesn’t work. Would be great if there is a fix, I’ve bought 4 of them and 300€ isn’t just a pence 
And for the RFX to controll somfy shutters I will setup a rule.
Please provide some information about what doesn’t (and does) work? The database has been configured as the CENTRAL_SCENE class. Please provide the debug logs to show what is happening.
The process of setting the association for one of the buttons to send a BASIC SET to a node shows up in the logs and looks ok to me.
The part where you press a button on the device and it’s supposed to send a BASIC SET to the associated node is the part that wouldn’t show up in the logs, because that doesn’t involve the binding. Isn’t that right?
It depends on how you configured it - it can involve the binding if you set the association to send to the binding. If you set the association to send directly to another device, then it will send directly without the binding being involved.
My assumption was that it was configured to send to the binding, but it’s up to you - you have here configured a direct association. However, the database has been set to say that CENTRAL_SCENE is sent in the BASIC_SET command - if this is correct, then I wouldn’t have expected too many devices to work properly (quite possibly the database is wrong though - normally BASIC command class is linked to something simpler).
Ok, so the way I did it above was to set node 72’s group 6 association to node 73. That should result in the node 72 sending a BASIC SET directly to node 73 when button 3 is pressed. Node 72 also sends a SCENE_ACTIVATION command to the controller. The logs would show the SCENE_ACTIVATION, but not the BASIC SET. Correct?
Hmm. I confused about how this is relevant for what I did above.
Wow - confusing…
BASIC command will be a single value with no context. See below for info on this.
No - the logs will show BASIC_SET if the device is sending BASIC_SET. There is no “context” with the BASIC command class - it’s simply a value. In the binding converter, we know from the database (ie the “BASIC” tickbox) that a BASIC command is the same as another command class, so we can process it with some knowledge of what it is, but if a device receives the BASIC command, it doesn’t have this context. This is why BASIC will usually only use simple command classes (normally just the BINARY_SWITCH and MULTILEVEL_SWITCH - and some use ALARM/NOTIFICATION for sensors).
It’s not directly. The point is that the database is marked to say that BASIC command class is the same as CENTRAL_SCENE. BASIC always replicates another class - so if it’s true that this is CENTRAL_SCENE, then it will send scene commands to your other device, and I expect that this may result in some strange things happening…
Eg, if the BASIC class was replicating MULTILEVEL, then it would send a value of 0 to 99 depending on the level. If it’s linked to SCENE, then it will likely be the scene number - and this won’t change if the level changes.
My guess is that the database is wrongly linked as it’s not normal for a device to use “more complex” commands with the BASIC command class since devices normally don’t expect this as there is no context. (I hope that makes at least some sense 
?!?).
Obviously I’m still confused. So by my reading of the docs, the device will send CENTRAL_SCENE to the controller (association group 1), will send BASIC to the nodes in association groups 2, 4, 6, 8, and will send MULTILEVEL_SWITCH to nodes in association groups 3, 5, 7, 9.
I definitely see it send CENTRAL_SCENE to the controller.
So, the database would appear to be correct?
Edit: I should add that I rarely (if ever) use associations to send from one node to another (i use rules for this). I was trying this as a test to see if I could recreate the OP’s issue.
Sorry - I didn’t pick up on the fact that you were referring to different association groups that are defined to send different things. I thought it was always sending the BASIC_SET - sorry.
No, it looks wrong. To me, BASIC is linked to MULTI_LEVEL_SWITCH based on what you have in the table above.
Ok, I’ll make that change to the DB. Thanks for helping me understand this. 
Nonetheless, it still doesn’t change the fact that in my test, where I set the Wallmote’s (node 72) group association 6 (Button 3 Basic Set) to node 73, it did not appear to send a BASIC SET to node 73 when I pressed button #3 on the Wallmote.
I have one of these devices and have had a big struggle. Just want to share my experiences so far. I have the new version of this controller with the 2.0 firmware. I do not know if these two versions behave differently, as Aeotec does not give it a new model number i expect that these behave identically, but the hardware is different, because old wallmotes will be bricked with the 2.0 firmware, and new wallmotes gets partially bricked with the old firmware.
It works as a dimmer via association group, directly controlling a Fibar dimmer 2. I can dim it up and down by holding a button, and turn it on and off by touching the button lightly. This means that the OH2 binding correctly configures the switch with the association group config when using multilevel.
However it does not work to when trying to use it as a controller for a basic on/off switch using association group. I have several Fibaro wall-plugs which are on/off, and as others here as well have tested this does not work.
I find it very strange, as association group is supposed to work directly between the switch and the control, with oh2 just as a configuration interface. If the z-wave plugin manages to configure multilevel associations correctly then it is strange that on/off associations does not work.
For me direct associations is essential for parts of my house, as it gives redundancy if the OH2 server is down.
Hi All
Has this controller for a basic on/off been resolved and are people able to use it to switch on/off dimmers, wall plugs and other zwave devices?
Regards
I am able to use it to controll a dimmer (fibaro) with direct association, and it can also turn the dimmer on / off, so as long as you are controlling a dimmer it works perfectly. However if you try to controll a pure on/off switch with direct associations it will not work at all unless you go through the hub and use rules.
Thanks Ole, I would want to direct use the dimmer of a fibaro also.
Dim to 0 switch off, dim to anything more than 1 would switch on. I assume this works?
I’m right in saying you cannot swipe to dim right? So how would you control the dimming value using the Wallmote?
You are correct about the swipe. For me the following work with the wallmote in direct association with the fibaro dimmer:
- Short touch to turn on / off (dimmer turns on to the last setpoint)
- Touch and hold to dim up or down
So except for the swipe I have full functionality when using it with the fibaro dimmer.
I have tried to associate an fibaro wallplug (only on/off device) as both dimmer and as a on /off switch to see if I can control it, since the on/ off action seems to work for dimmers, but no luck on on / off switches.
Thanks Ole
Sliding needs to be added to OH2. This is basic functionality in my view thats fundamental!
Click, Touch, Slide, Swipe etc etc etc all its all core of an IPhone which always wins in usability.
I want to use this device in a rule – is this possible. I have set up Items for each of the 4 buttons and the “scene” and tried to set a rule for “received command” event. But that doesn’t work. Any ideas?
Commands are sent from UIs and rules. Bindings update the state of linked Items… use ‘received update’.
Do I have to set the device association?
I want to use a rule like this:
when
Item QuadScene received update
where QuadScene is defined in items as:
Number QuadScene {channel=“zwave:device:a412db75:node13:scene_number”}
Your rule should look like this. Other than the Lifeline, you shouldn’t need to set any other associations.
ule "Wallmote"
when
Item QuadScene received update
then
var double sceneNumber = (QuadScene.state as Number).doubleValue
switch (sceneNumber) {
case 1.0 : { // Button 1 short press
}
case 1.1 : { // Button 1 long press
}
case 1.2 : { // Button 1 hold
}
case 2.0 : { // Button 2 short press
}
case 2.1 : { // Button 2 long press
}
case 2.2 : { // Button 2 hold
}
case 3.0 : { // Button 3 short press
}
case 3.1 : { // Button 3 long press
}
case 3.2 : { // Button 3 hold
}
case 4.0 : { // Button 4 short press
}
case 4.1 : { // Button 4 long press
}
case 4.2 : { // Button 4 hold
}
default : { // Unknown
}
}
end
Ohhhhh I got it! =) Thanks @mhilbush his rule works perfectly! Be sure to use 1.0 and not 1,0 or simply 1!
1 Like