How to use Z-Wave Remote control ZV9001K12-DIM-Z4 in OpenHAB 3.0

  • Platform information:
    • Hardware: x64 AMD /RAM/storage
    • OS: _Debian 11
    • Java Runtime Environment: _Azul Zulu Java 11
    • openHAB version: 3.0
  • Impacted item : remote control ZV9001K12-DIM-Z4
  • Issue of the topic: Z-Wave related I don’t know how to configure Openhab to use this remote. The remote only has “scene number” that can be used in the channels. There are a general on/off (or dim?), 4 device groups that can be dimmed and two scene buttons (S1 and S2). But all I get is “scene number”, what can I do ? There are 4 association groups available which I assume correspond to the 4 device groups that can be controlled. However, using association groups goes outside of OpenHAB, which I prefer not to do.

Many thanks !

There are lots of answers to this depending on whether you want individual item controls or multi-item scenes and how complex you want the system to get. They all boil down in one way or another to a simple underlying structure: a rule that responds to updates of an item linked to the scene channel and sends the appropriate command to your target item(s).

Here’s a setup so that a remote toggles several different items depending on button pushes:

Or you can read about setups that actually control many items at once.

Thank you for clarifying this a bit. I would like the remote to steer a set of dimmers, which means the buttons can both switch on and off as well as dim (I assume short press vs long press plays a role here). Should you have an example of that, that would be great!

I have no idea what the different scene numbers are that I can receive from that remote. How can I find out ? Or where ? I tried adding a rule, but nothing happened, I assume this is related to the fact I have no idea what values I can expect there and what their format is (I entered a value like you illustrated 1.0 ).

Btw, on association level, on/off (short press) and increase/decrease (long press) is automatically handled by the device itself.

Additionally, is there some way to evaluate/watch (like debugging) allowing you to see how your rule behaves and what values are received/handled ?

Kind regards,

David.

Some people here use association groups with their z-wave some do not. It’s a matter of preference. I happen to use a mixture depending on the specific use case. Unless you have a specific reason why you do not want to use the association groups (max group size is too small, more rule processing then simple direct commands, etc.) then this is certainly something you could consider. It has the advantage of typically being a slightly shorter latency than if OH is the middle man (often less than a second difference in my experience but sometimes more noticeable). It has the disadvantage of having slightly less control over the situation.

I do not use any of my remotes for direct dimming functions so I don’t have an example to share in this regard. But the basics are pretty simple. Many OH dimmer things respond to INCREASE and DECREASE commands by default, so something like your remote which when you long press the button presumably sends a series of the same state updates until you release the button could be linked via a simple rule to send the appropriate INCREASE or DECREASE command with each repeated state update.

If you already have the scene channel connected to an item, then you don’t even need a rule to see what the state it you should, if everything is working correctly, be able to see the state on the item’s detail page (or by clicking on the item in the semantic model if you’ve included it as a point in the model).

Each time the state changes you should see that on the page in real time.

Also, you can just watch the event log file. This way you’ll see state changes and state updates (all commands sent to the item even if they don’t change its state because its already in that state).

2021-03-23 19:13:05.143 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Switch_LibraryLight_Scene' changed from 2.0 to 1.0

It’s important to understand how the remote handles updates because you will probably, in the end, want rules that trigger on item updates and not just state changes (see increase/decrease above).

If you are handling state values in a rule and aren’t sure that they’re correct, then use logging in your rule. Use logging after every single line that you are not sure about! Use logging even after lines you are sure about just in case you’re wrong! When you’re developing a rule initially you can’t have too much logging. If you’re stuck on a rule and come to the forum for help, 4 of the first 5 questions are going to be “What logging have you tried?” Even after your rule works, it can’t hurt to leave some logging in there in order to check in on it occasionally. The log line I posted above also triggered a rule to run and that rule even though I haven’t changed it in months still registers some log lines every time it runs:

==> /log/openhab.log <==
2021-03-23 19:13:05.142 [INFO ] [org.openhab.rule.a034eb64fa         ] - {1.3={device=Switch_PlayRoomLight_OnOff, command=OFF}, 2.3={device=Switch_PlayRoomLight_OnOff, command=ON}}
2021-03-23 19:13:05.142 [INFO ] [org.openhab.rule.a034eb64fa         ] - Switch_LibraryLIght_Scene: No Scene configured for command 1.0
1 Like

Many thanks Justin ! Following your info, I notice that I don’t receive ANY value from the remote. Not when I press (any) key, not even the battery state is coming through (which should be sent once every 24h). The light on the remote turns on when I press a button, so I assume batteries are in good shape. This might point of course to a different problem: how can I get the thing to work, or conclude that the device (although new) is simply not working ?

The most common scenario in this circumstance is that the device is not yet fully installed. You may still have to wake your device up a few (or several) more times before initialization is complete. Refer to the device manual for the wake-up action as it’s different for different devices.

Also check that the first association group (which is usually labeled as “Lifeline”) is set to controller. Association group one defines the device that gets all the basic information from the remote and if it’s blank or not controller then the OH isn’t getting any of the remote’s signals.