Anyone know if on ZWave2JS if long press works?
Using that and single toggle presses in my automations for this and looking to make the switch away from OZW
Late reply here, I’m sure you already figured this out, but I just got one of these the other day and am using ZWaveJS. The long press and single press actions on each quadrant work just fine out of the box with ZWaveJS. You have to subscribe to the zwave_js_value_notification event in order to capture both single presses and long presses. In NodeRed the event is structured like below, the KeyPressed part will change depending on whether you single or long press. The options are KeyPressed, KeyHeldDown, and KeyReleased. The KeyReleased event is only fired after you release from a long press. The below event is for the 4th quadrant as indicated by a few of the event properties.
{
"payload": {
"event_type": "zwave_js_value_notification",
"event": {
"domain": "zwave_js",
"node_id": 6,
"home_id": xxxxxx,
"endpoint": 0,
"device_id": "xxxxxxx",
"command_class": 91,
"command_class_name": "Central Scene",
"label": "Scene 004",
"property": "scene",
"property_name": "scene",
"property_key": "004",
"property_key_name": "004",
"value": "KeyPressed",
"value_raw": 0
},
"origin": "LOCAL",
"time_fired": "xxxxx",
"context": {
"id": "xxxxx",
"parent_id": null,
"user_id": null
}
},
"topic": "zwave_js_value_notification",
"_msgid": "dea9a023.fdf67"
}
Thanks, I did make the swap a few weeks ago and used the blueprint available. Took all the work out of it.
I don’t use NodeRed, do everything in yaml or gui native to HA.
This will be helpful for someone though.
1 Like
Do you you have a link to the blueprint you used? Any chance you have found a way to get the slide up and down working?
Links to Blueprint I used.
About the sliding, nah haven’t got it working, but tbh I havent tried.
Tried to get the swipe working with zwavejs2mqtt but I couldn’t figure it out. Looking at zwave logs, I can’t see any of the data related to parameter #9 or #10.
I do see raw 16 byte hex strings from each key press. I can see the button number and press type (short vs long) encoded there, but nothing there which indicates anything related to swipe, or the raw data that I could scrape to make any kind of determination related to swipe events.
2022-07-24T01:29:51.371Z SERIAL .. 0x010e00a8000109055b03e6000100cd26 (16 bytes)
2022-07-24T01:29:51.372Z SERIAL .. [ACK] (0x06)
2022-07-24T01:29:51.372Z DRIVER .. [Node 009] [REQ] [BridgeApplicationCommand]
... RSSI: -51 dBm
......[CentralSceneCCNotification]
sequence number: 230
key attribute: KeyPressed
scene number: 1
2022-07-24T01:29:51.373Z CNTRLR [Node 009] [!] [Central Scene] scene[001]: 0
2022-07-24T01:29:51.374Z CNTRLR .. [Node 009] received CentralScene notification {
"nodeId": 9,
"ccId": "Central Scene",
"ccCommand": "0x03",
"payload": "0xe60001"
}
2022-07-24T01:29:52.487Z SERIAL .. 0x010e00a8000109055b03e7020100cd25 (16 bytes)
2022-07-24T01:29:52.488Z SERIAL .. [ACK] (0x06)
2022-07-24T01:29:52.488Z DRIVER .. [Node 009] [REQ] [BridgeApplicationCommand]
... RSSI: -51 dBm
......[CentralSceneCCNotification]
sequence number: 231
key attribute: KeyHeldDown
scene number: 1
2022-07-24T01:29:52.489Z CNTRLR [Node 009] [!] [Central Scene] scene[001]: 2
2022-07-24T01:29:52.490Z CNTRLR .. [Node 009] received CentralScene notification {
"nodeId": 9,
"ccId": "Central Scene",
"ccCommand": "0x03",
"payload": "0xe70201"
}
I’m able to get parameter 9 and 10 to show up and also they seem to update quite smoothly. The only issue is the values don’t seem to make any sense. Does anyone know how to make sense of these large numbers?
The massive jumps you see are when I use one side swipe vs using the other side’s swipe on the Duo
(this is with the Duo ZW129. But should be the same for the quad)
I am using Z-WaveJS
I got swipe fully working!
For this setup, you dont need to use any external python, it can all be done within HomeAssistant!
in your configuration.yaml you need to add this (replacing the sensor with the name of your wallmote sensor)
sensor:
- platform: template
sensors:
wallmote_duo_scene_id:
friendly_name: "Wallmote Duo Scene ID"
value_template: "{{ (states('number.wallmote_duo_param010') | int /2**24) | int | bitwise_and(0xff) }}"
wallmote_duo_scene_direction:
friendly_name: "Wallmote Duo Scene Direction"
value_template: "{{ (states('number.wallmote_duo_param010') | int /2**16) | int | bitwise_and(0xff) }}"
wallmote_duo_scene_value:
friendly_name: "Wallmote Duo Scene Value"
value_template: "{{ ((states('number.wallmote_duo_param010') | int /2**8) | int | bitwise_and(0xff) | float / 200) * 100 }}"
wallmote_quad_scene_id:
friendly_name: "Wallmote Quad Scene ID"
value_template: "{{ (states('number.wallmote_quad_param010') | int /2**24) | int | bitwise_and(0xff) }}"
wallmote_quad_scene_direction:
friendly_name: "Wallmote Quad Scene Direction"
value_template: "{{ (states('number.wallmote_quad_param010') | int /2**16) | int | bitwise_and(0xff) }}"
wallmote_quad_scene_value:
friendly_name: "Wallmote Quad Scene Value"
value_template: "{{ ((states('number.wallmote_quad_param010') | int /2**8) | int | bitwise_and(0xff) | float / 200) * 100 }}"
Now mine is setup for both the Wallmote Duo and the Wallmote Quad.
Now for instance if you want to use it to control the brightness of a light, you can do it this way using an automation:
alias: Change light brightness
description: "Uses the Wallmote to change the brightness of the light"
trigger:
- platform: state
entity_id:
- sensor.wallmote_quad_scene_value
condition: []
action:
- service: light.turn_on
data:
brightness_pct: "{{ states('sensor.wallmote_quad_scene_value') | float }}"
target:
device_id: 4ead6cd7cfe810b04518097ef7f2b1d3
mode: single
If you want to do 4 swipe zones, then you can do it based off of the Wallmote Quad Scene ID as its a value 1-4.
3 Likes
Where did you get these number.xxx entities? I have 3 wallmote quads and none of them exposes something like that to HA… Neither the sensor.xxx_scene_value. What Z-wave integration do you use?
I am using Z-Wave JS. sensor.wallmote_quad_scene_value is what we are creating here. To get this to work, you first need to expose param010
If you don’t see it there at all, you need to hold the button on the back for 3 seconds or so to wake it up (something like that, look further up this thread for other uses telling you how to do it if my instructions here are slightly incorrect). Once the device is worked up, you then need to slide up and down a few times so that the param will register in HA. Once it’s registered you need to expose it as I showed above. Once you are at that state, then you can follow the original instructions I posted.
Well, I tried to follow, but somehow my configuration in Z-Wave JS looks different than yours. So indeed I started from having most of additional entities disabled:
Then, to be on safe side I enabled everyhing:
In meantime I kept Wallmote awaken and tried to slide several times to get Param 10 showing up, but nothing was added to my configuration. No trials of Param 10 in neither Z-Wave JS or Z-Wave JS UI. I also tried sliding after enabling Button Slide Function and with awake mode disabled… Same result. The only number.xxx new entity that was created is number.wallmote_light_controller_low_battery_threshold
Your problem is the Central scene CC Report Type. Set that to “… and Configuration CC” and try again.
1 Like
This did the trick! Now I see param10 and can move forward 
1 Like
Hi, Where does the device_id value come from?
That is the ID of some lights in my house. You can just update that as you usually would. You can do to automations and add a new action and click service. Search “Turn on” and follow the rest of the prompts from therr. Then switch to yaml view and you should see a ID similar to mine
Thanks for all these pointers. Took me restarting zwavejs for the params to show up, but did get them.
Curious, where’d you get all the bitmath to suss out these values?
For anyone who’s looking to use the left/right side as sliders, here’s an example I did where the two sides control a light that can dim and change color temp:
alias: Change light brightness
description: Uses the Wallmote to change the brightness/colortemp of the light
trigger:
- platform: state
entity_id: sensor.wallmote_quad_scene_value
condition: []
action:
- choose:
# left side slider, brightness
- conditions:
- condition: template
value_template: "{{ states('sensor.wallmote_quad_scene_id') in ['1', '3'] }}"
sequence:
- service: light.turn_on
data:
brightness_pct: "{{ states('sensor.wallmote_quad_scene_value') | float }}"
target:
entity_id: light.white_lights_ceiling_light
# right side slider, color temp
- conditions:
- condition: template
value_template: "{{ states('sensor.wallmote_quad_scene_id') in ['2', '4'] }}"
sequence:
- service: light.turn_on
target:
entity_id: light.white_lights_ceiling_light
data:
# kelvin is in 3000-6000 range, so just use the percentage to shift it along
kelvin: "{{ 3000 + (3000 * (states('sensor.wallmote_quad_scene_value') | float) / 100) }}"
mode: single
2 Likes
Hello there
This is pretty awesome and it works as expected
Creating dedicated (templated) sensors for all the sliding actions is quite straight forward. However, having multiple WallMote Quad’s at home, this can be a bit «tricky» and «annoying».
I tried to improve it even further, resp. found an alternative solution. Instead of having dedicated template-based sensors, I created a single script which «extracts» the slide infos from a passed entity, and then returns the extracted informations in a variable:
Script (needs to be defined only once):
alias: WallMote Slide Info
sequence:
- variables:
slide:
scene: >-
{{ (states(entity_id) | int /2**24) | int |
bitwise_and(0xff) }}
direction: >-
{% if (states(entity_id) | int /2**16) |
int | bitwise_and(0xff) == 1 %}up{% else %}down{% endif %}
value: >-
{{ ((states(entity_id) | int /2**8) | int |
bitwise_and(0xff) | float / 200) * 100 }}
- stop: ""
response_variable: slide
mode: parallel
icon: mdi:swap-vertical
fields:
entity_id:
selector:
entity: {}
name: Entity
description: The (param010) entity ID to fetch the informations from.
required: true
For those familiar with programming, it works like a function, accepting an entity ID as an input parameter, and returns the slide infos as dict:
- Input: Entity ID of a
param010entity - Output: Dict (w/ keys
scene,direction&value)
Having the script in place, you can easily call it from your concrete automation, store the response in a variable and then do magic based on it. For example:
Example Automation:
alias: WallMote Slide Demo
trigger:
- platform: state
entity_id:
- number.wallmote_quad_param010
id: slide
condition: []
action:
# This is where we get the slide info and store it in the `slide` variable :)
- service: script.wallmote_slide_info
data:
entity_id: "{{ trigger.entity_id }}"
response_variable: slide
- if:
- condition: template
value_template: "{{ slide.scene == 1 and slide.direction == 'up' }}"
then:
- service: script.open_shutters
- if:
- condition: template
value_template: "{{ slide.scene == 1 and slide.direction == 'down' }}"
then:
- service: script.close_shutters
- if:
- condition: template
value_template: "{{ slide.scene == 2 }}"
then:
- service: light.turn_on
target:
entity_id:
- light.example
device_id: []
area_id: []
data:
brightness_pct: "{{ slide.value }}"
You basically have an automation which…
- triggers on the
param010change, - sends the
param010entity to the WallMote Slide Info script to get the slide action / infos, - executes the action based on the returned slide infos
It’s not perfect and I’m sure its not suitable for all use cases, but I thought it might be helpful to someone else The community (esp. you guys in this thread) helped me to enable Wallmote slide actions in HA, so I thought I’ll share this in return. Let me know if this can be improved, or what you think.