Howto: Add Double Tap Support for GE Switches and Dimmers in OZW-Beta

Tags: #<Tag:0x00007f73a53c03c8> #<Tag:0x00007f73a53c02d8>

GE dimmers and switches support double tap events, but these devices do not send scene_activated events when they are double tapped. In the old zwave integration you could intercept these as node_events, but ozw 1.6 does not support node_events and those will ultimately be removed. Its possible to re-add support by editing the qt-openzwave xml files for your devices. I’ve test this on 14291 switches and 14294 dimmers. It likely works on others.

Solution and discussion from:

All file references refer to the qt-openzwave docker, in the ozw folder.

In options.xml, add the following. Without it the sensor won’t be updated if it is already at state 0 or 255.

<Option name="SuppressValueRefresh" value="false" />

In the device xml file, e.g. ge/14291-switch.xml add:

<CommandClass id="32" name="COMMAND_CLASS_BASIC">
     <Instance index="1" />
           <Value type="byte" genre="basic" instance="1" index="0" label="Basic" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0">
           <Help>Basic status of the node</Help>
         <Value type="byte" genre="basic" instance="1" index="1" label="Basic Target" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0">
          <Value type="int" genre="basic" instance="1" index="2" label="Basic Duration" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-2147483648" max="2147483647" value="0">

You must add your zwave stick, node 1, into the Association Group 3. If you haven’t already done so, the following will do that automatically. Change the following in the device xml:


<Group index="3" label="Basic - Double Tap" max_associations="5"/>


<Group index=“3” label=“Basic - Double Tap” max_associations=“5” auto=“true”/>

Shutdown HA and qt-openzwave. Either nuke the ozwcache*.xml file or edit it and remove the node entry so it is rebuilt. Warning: Nuking the cache will undue your node naming if you did that within ozwadmin. Refreshing the node from within ozwadmin will not work.

After qt-openzwave is fully back online and has queried everything, start HA.

Under Configuration/Devices and the appropriate device, there will now be three disabled entities. Enable and rename the sensor.14291_in_wall_smart_switch_basic sensor as you like.

Upon double-tap down, that sensor will now show 0. Double-tap up will show 255.

1 Like

How do you access the container to remove the cache if the docker container is shut down? I’m not able to get the hidden devices to show up.

Running a Docker container within supervised, or installed via Docker? If installed via Docker the files are exposed regardless of whether it is running inside the ozw folder that your docker-compose.yaml points to. If on Supervised…I have no idea but this other guy got it to work over here: GE 14294 (and Jasco equivilant) ZWave dimmer double tap (Event on Associaton Group 3) - need config help

The issue is that qt-openzwave is continually writing to the cache when it is running.

That guy said he got the node events to show up in ozw. I got to that part as well. The issue I’m having now is removing the cache. I can’t remove it while it’s running, but I can’t access it when it’s down. I’ll keep digging around but I’ve been looking for a little while and can’t find anything.

You don’t want node_events, you want something like this:

Screen Shot 2020-09-23 at 10.13.30 PM

Try restarting on the off chance that it doesn’t overwrite it. Just nuke it and restart. It may rebuild it on the fly, or it may crash and rebuild it on the next startup. At worst you could try killing the docker container without doing so gracefully so it doesn’t trigger the save. (I’m not positive that it saves the cache on restart…the built-in zwave integration does so.)

You should also be able to, somehow, run something to shut the daemon down within the container:

sorry, thats what I am getting, just used the wrong phrase. Just did “docker kill addon_core_zwave” after removing the cache file. Didn’t seem to do the trick, those sensors are not created still.

Also, have you figured out a way to poll devices in the ozw beta? I want to use long transitions to turn off my lights in some cases but this would make the state be wrong in HA.

If you’re getting that then you’re beyond the cache file. Is your ozw integration set to discover?

Screen Shot 2020-09-23 at 10.27.49 PM

And to be clear, this is what it will look like when you go into the device, bottom left:

Screen Shot 2020-09-23 at 10.28.07 PM

I’m not using polling, sorry.

it is set to discover yes, and I just have the light, no disabled entities.


Also, I’m a Brian too!

Have you tried restarting HA? Because of the way I do it, shutting down, MQTT is always fully up with the new topics when I start HA.

many times yes

You’re using the most recent version of HA? If so…I’m not sure. This sort of stuff is why I don’t run Supervised. You could also try something like MQTT Explorer on your computer to see if the value exists and is changing.

Yep 0.115.2. I’ll keep messing with it, maybe I need to double tap before the entity is created? Not near the switch at the moment so that may be it.

Worth a try…I noticed that when I enable the entity it doesn’t actually show up with a value until I change the value on the device. It’s worth adding…seeing it in HA isn’t all that necessary. I’ve found that monitoring MQTT in Appdaemon (should work in Node-Red too) is better. HA doesn’t seem to pass on a state change if you were already at 0 as an example, and then double-tap down because the value hasn’t changed.

So I actually had my buddy make those changes, and he missed a few things. I didn’t double check his work until now. I went in, made the changes you listed and I have the sensors and they display correctly. The only thing now, which I saw was an issue in the github thread was if you turn them off, then turn them off again another event doesn’t trigger. I can work around this with an automation that will set the state of the sensor to say 100 either after it’s triggered or just every second. If you have a more elegant way of making it handle duplicate pushes please let me know, otherwise I can share my automation once it’s built.

I debated doing that very thing, but the value is read-only on the MQTT side so I wasn’t sure how it would work or if it would take in HA. I actually monitor for changes in MQTT using Appdaemon versus the sensor and an MQTT message will go out each time using the settings I posted (specifically, SuppressValueRefresh controls that) so there is no need to mess with it. I just monitor for messages on those topics and change based on the value in the payload.