GE Switches and Dimmers do not reflect double-up or double-down because they use the BasicCC for those events

[blhoward2]

Describe the bug

GE dimmer/switches are capable of double tap events, but those are not captured here and result in the current value going out of sync with the device.

These are the steps to make it work under qt-openzwave: https://community.home-assistant.io/t/howto-add-double-tap-support-for-ge-switches-and-dimmers-in-ozw-beta/228871/16.

The original qt-openzwave issue which has more detailed info is at: OpenZWave/qt-openzwave#60.

This appears to result from this because the devices use BasicCC for these events despite supporting the Multi-Level Command Class: #388

Non-compliant or not, it is how they work... Is there a way to IgnoreMapping here like in ozw 1.6?

Note: If possible, these devices should also auto-associate the controller into group 3 so that it receives the double-tap events.

To Reproduce Steps to reproduce the behavior:

1. Pair switches in zwavejs2mqtt.
2. Double tap up or down

Device information Which device(s) is/are affected? Various GE switches and dimmers (confirmed on 14294, 14291) What are the node IDs?

Logfile:

Note: I have a script that resets the light to the default levels upon turning on. That accounts for the 50 --> 50 messages.

Double-tap up (from a prior double-tap up state, hence 255-->255):

Double-tap up from off, just in case being in a former double-tap state affects it (note this one is out of order on the console log):

(The current value goes to 255 and HA thinks the device is now at 100%, but the physical dim has not changed. They are now out of sync. The currentValue is 255, the target Value is 50.)

Double-tap down:

For comparison, off to normal on:

For comparison, on to normal off:

Console log:

[blhoward2]

@jcam posted this in slack last night if it can’t be changed, as a workaround: https://www.home-assistant.io/integrations/device_trigger.mqtt/

A trigger could be setup through MQTT discovery that works off the basic set value. I’m not sure that anyone has tried this...it is a theory.

[towerhand]

I’m using the mqtt trigger for the double taps with z2m and it works well, could never get it to work with qtozw due to the persistent values.

[kpine]

By "z2m" you mean "zwavejs2mqtt" right? Is the topic retained? I assume it's not.

I'll be using the HA integration so I don't want the same problem to show up there.

[blhoward2]

I’m using the mqtt trigger for the double taps with z2m and it works well, could never get it to work with qtozw due to the persistent values.

Did you add this as a custom sensor or whatever yourself in z2m? Could you share the code?

[AlCalzone]

Sorry, I don't follow here. Can somebody break it down for me?

[blhoward2]

After this fix, a double-tap sends a value update, not a notification (event). The result is that HA makes this persistent and doesn’t see a subsequent double-up or double-down if it is already in the 0/255 state. Under ozw 1.4 doing this generated an event (not a value) that came across as a zwave_event. Central Scene has a similar problem. If the device was last used to activate scene 1, it won’t see a second scene 1 to automate off of. (@jcam described this problem in the slack channel last night)

If the node level cannot be changed to do that, it may be possible for a change at the js level to send out discovery for an mqtt trigger that acts like a button. This is a second-tier option as it won’t fix it for the HA integration or other projects.

Related but central scene: https://github.com/zwave-js/zwavejs2mqtt/issues/198

[towerhand]

I meant Zwave2mqtt, I would be ok if zwavejs2mqtt behaves the same which reading the issue seems like it’s heading that way.

i can share the automation in a couple hours and test the new version of zjs2m this weekend.

[kpine]

Sorry, I don't follow here. Can somebody break it down for me?

Here's how OZW 1.4 (and 1.6 non-ozwd) dealt with Basic Set:

1. Device sends Basic Set to controller
2. In OZW this goes gets propagated through the NodeEvent API
3. In HA (which consumes the C++ API via Python) handles this as an event, and you can write automations to trigger on the event.

At no time in the above is the state of the Basic Set value stored anywhere. When I restart HA there is no risk of my automation ever being triggered. If I send duplicate events, such as two on double taps sequentially, the event is triggered because it doesn't care about previous state. You can compare this to the use case to a Central Scene notification if you want.

In ozwdaemon (and some future OZW version) the path forward is to get rid of the Node Event API entirely, and treat Basic Set just like a Basic Report, as a value (it also does this with Central Scene values). There are multiple problems with this:

1. By default, OZW was masking value refreshes, which means two double-tap on events (basic set 0xff) would not be reported. This was changed to emit a duplicate MQTT topic with a new timestamp. It looks like you've already solved this problem.
2. Sometimes applications also mask state values that are received, but don't change value. HA disables this for certain values. It's not clear yet if HA would detect duplicate value updates and emit a state trigger w/o change.
3. Depending on the design of the application, at startup when it processes all the existing values, it may or may not emit state changes when values are added. It does for Basic values, which means an automation based on this will get triggered, unless some precautions are taken. It remains to be determined how HA would handle this value for the zwave-js integration, but based on past implementation it would be state trigger.

In my ideal world, for these devices a Basic Set would be treated as a notification, like Central Scene, because that's what they are. I could then ask HA to add an event trigger to achieve the same behavior as OZW 1.4.

[kpine]

I meant Zwave2mqtt, I would be ok if zwavejs2mqtt behaves the same which reading the issue seems like it’s heading that way.

Ah, zwave2mqtt is using OZW 1.6 and uses the "deprecated" Node Event API. That explains the difference from ozwd. Although, if you picked up any of the recent XML changes it might not be working the same way.

[blhoward2]

@robertsLando apparently made changes in zwavejs2mqtt that drops the retain flag. I think we have two different potential fixes going on here. Does that fix this concern? Though it wouldn’t apply to the HA integration. From discussion in slack.

[AlCalzone]

I see. I think the use cases for treating Set as Report are more common. So this requires a compat flag to treat the Basic Set for this device as non-stateful.

[kpine]

That very well may be true. OZW has the SetAsReport compat flag which is enabled in 87 config files, quite a few devices.

[towerhand]

I’m using the mqtt trigger for the double taps with z2m and it works well, could never get it to work with qtozw due to the persistent values.

Did you add this as a custom sensor or whatever yourself in z2m? Could you share the code?

@blhoward2 This is what I'm using with z2m, I remember having to ask robertlando when first started using z2m (a long time ago) to remove the retain flag from the events so the automation didn't trigger unexpectedly (HA restarts and automation reloads). Reading the comments in this issue looks like that's fixed in zjs2m recently too.

• id: 'master_bed_doubletap' alias: "Master Bedroom Lights Double Tap" initial_state: true trigger:
  • platform: mqtt topic: "zwave2mqtt/master_bedroom_lights/event" action:
  • service: > {% if trigger.payload_json.value == 255 %} homeassistant.turn_on {% elif trigger.payload_json.value == 0 %} homeassistant.turn_off {% endif %} entity_id:
    • light.master_bedroom_lights_dimmer
    • light.right_bedside_lamp
    • switch.left_bedside_lamp

@kpine I just redid my rp3 from scratch a couple weeks ago and the GE switches worked with z2m right away, didn't have to mess with XML files or anything.

[kpine]

@kpine I just redid my rp3 from scratch a couple weeks ago and the GE switches worked with z2m right away, didn't have to mess with XML files or anything.

It will depend on the switch model. The switches using these configs I would expect to behave differently with the latest versions:

$ pwd
/src/zwave/open-zwave/config/ge
$ git grep --all-match -e IgnoreMapping -e SetAsReport -l
12724-dimmer.xml
14291-switch.xml
14292-toggle-switch.xml
14294-dimmer.xml
46201-switch.xml

[blhoward2]

And generation. Nearly all of the GE models support double tap, and those now have compat flags. (All that I could readily identify, which is more than those.) More recent models have Central Scene too. You can’t go by model number though. There are at least four generations of 14294 ranging from not zwave plus to the new ones with central scene, as an example. And central scene ones don’t need the change there or here to work that way.

[towerhand]

Thanks for the info @blhoward2, they really made things complicated. Not on that list but 14287 fan switch shares the same behavior.

[AlCalzone]

There are at least four generations of 14294 ranging from not zwave plus to the new ones with central scene, as an example. And central scene ones don’t need the change there or here to work that way.

Do those at least have a different device id or firmware version or is it just the same from outside?

[blhoward2]

There are at least four generations of 14294 ranging from not zwave plus to the new ones with central scene, as an example. And central scene ones don’t need the change there or here to work that way.

Do those at least have a different device id or firmware version or is it just the same from outside?

They look the same. They are spread over two product IDs I think, at least for the one, but have different firmware.

[AlCalzone]

but have different firmware.

Also a different firmware version? Cause that's one of the things we use to distinguish devices.

[blhoward2]

Right, some of them appear to have different firmware versions. Going through the zwave alliance xmls the manufacturers are all over the place how they deal with this. Some change product ids. Some only firmware versions. Some have the same for both but change HardwarePlatform. As such it’s going to be impossible to be 100% accurate to ensure we don’t end up with two device files for different generations of the same device when they could have been combined when merging automatically. I’m thinking through the different amounts of trust to place in the changes where the config parameters are the same (so we don’t mis-name a device), but I see we do have different files for different generations in some places as it is so I’m taking an as best we can do approach at the moment as I play with them.

Basically same product type/product id and identical parameters = same (increment firmware version if necessary to include)

Same type/I’d but with different parameters = two device files, distinguish with firmware version

Different product id but exact same identifier and parameters (e.g. Leviton DZPA1) = same, add to device section, change firmware version to include

Then the harder ones like some of the GEs. Same type, different ids, same parameters, but the identifiers aren’t exact. One may be 14291/46202, another 14292/46202/zw100 (made up). Or for another brand may be PAT-01-A or PAT-01-B. These may have to be reconciled manually or two device files used. I’m working to figure out how big this pool is before I go crazy trying to figure out a degree of similarity in identifier that’s acceptable if they have the same parameters.

[AlCalzone]

I’m taking an as best we can do approach

👍🏻

[AlCalzone]

@blhoward2 can you tell me which device files exactly need this compat flag and auto-assignment?

[blhoward2]

The auto-assignment we took care of when we added the other compat flags. Those should all get this one too (from my PR last week).

[AlCalzone]

please try #1379

[blhoward2]

please try #1379

==> zwavejs_1.log <==
21:38:08.788 DRIVER « [Node 003] [REQ] [ApplicationCommand]
                      └─[BasicCCSet]
                          target value: 255

==> zwavejs2mqtt.log <==
2021-01-13 21:38:08.791 INFO ZWAVE: Node 3: value notification: 32-0-value undefined => 255

==> zwavejs_1.log <==
21:38:08.790 CNTRLR   [Node 003] treating BasicCC Set as a value event

It looks like an event is now sent, but that zwaevjs2mqtt doesn't know what to do with it? Is the "undefined" normal? I do see it under node_value_updated in mqtt.

@jcam Thoughts? How are you handling this with central scene? Or is this now on par with what needs fixed there?

[jcam]

Central scene currently works because zwavejs2mqtt creates fake sensors and when it gets the value notifications, it sends state changes for those sensors. To get this to work, zwavejs2mqtt would have to be updated to create fake sensors for these basicCC sets too. Or, triggers, but i digress.

[kpine]

zwave2mqtt used an event topic. Is that gone?

[jcam]

taking back what i just wrote, I do see this in the handle value notification function, which appears to be making an event... is that in MQTT?

this.emit( 'event', eventEmitter.node, 'node value updated', this.nodes[zwaveNode.id], args )

[blhoward2]

{"data":[{"id":3,"deviceId":"99-12344-18756","manufacturer":"Jasco Products","manufacturerId":99,"productType":18756,"productId":12344,"name":"","loc":"","values":{"38-0-targetValue":{"id":"3-38-0-targetValue","nodeId":3,"commandClass":38,"commandClassName":"Multilevel Switch","endpoint":0,"property":"targetValue","propertyName":"targetValue","type":"number","readable":true,"writeable":true,"label":"Target value","stateless":false,"min":0,"max":99,"list":false,"lastUpdate":1610588592805},"38-0-duration":{"id":"3-38-0-duration","nodeId":3,"commandClass":38,"commandClassName":"Multilevel Switch","endpoint":0,"property":"duration","propertyName":"duration","type":"duration","readable":true,"writeable":true,"label":"Transition duration","stateless":false,"list":false,"lastUpdate":1610588592808},"38-0-currentValue":{"id":"3-38-0-currentValue","nodeId":3,"commandClass":38,"commandClassName":"Multilevel Switch","endpoint":0,"property":"currentValue","propertyName":"currentValue","type":"number","readable":true,"writeable":false,"label":"Current value","stateless":false,"min":0,"max":99,"list":false,"value":50,"isCurrentValue":true,"targetValue":"38-0-targetValue","lastUpdate":1610588593016},"38-0-Up":{"id":"3-38-0-Up","nodeId":3,"commandClass":38,"commandClassName":"Multilevel Switch","endpoint":0,"property":"Up","propertyName":"Up","type":"boolean","readable":true,"writeable":true,"label":"Perform a level change (Up)","stateless":false,"ccSpecific":{"switchType":2},"list":false,"lastUpdate":1610588593017},"38-0-Down":{"id":"3-38-0-Down","nodeId":3,"commandClass":38,"commandClassName":"Multilevel Switch","endpoint":0,"property":"Down","propertyName":"Down","type":"boolean","readable":true,"writeable":true,"label":"Perform a level change (Down)","stateless":false,"ccSpecific":{"switchType":2},"list":false,"lastUpdate":1610588593019},"43-0-sceneId":{"id":"3-43-0-sceneId","nodeId":3,"commandClass":43,"commandClassName":"Scene Activation","endpoint":0,"property":"sceneId","propertyName":"sceneId","type":"number","readable":true,"writeable":true,"label":"Scene ID","stateless":false,"min":1,"max":255,"list":false,"lastUpdate":1610588593020},"43-0-dimmingDuration":{"id":"3-43-0-dimmingDuration","nodeId":3,"commandClass":43,"commandClassName":"Scene Activation","endpoint":0,"property":"dimmingDuration","propertyName":"dimmingDuration","type":"any","readable":true,"writeable":true,"label":"Dimming duration","stateless":false,"list":false,"lastUpdate":1610588593021},"112-0-3":{"id":"3-112-0-3","nodeId":3,"commandClass":112,"commandClassName":"Configuration","property":3,"propertyName":"Night Light","type":"number","readable":true,"writeable":true,"description":"Defines the behavior of the blue LED. Default is on when switch is off.","label":"Night Light","default":0,"stateless":false,"min":0,"max":2,"list":true,"states":[{"text":"LED on when switch is OFF","value":0},{"text":"LED on when switch is ON","value":1},{"text":"LED always off","value":2}],"value":0,"lastUpdate":1610588617030},"112-0-4":{"id":"3-112-0-4","nodeId":3,"commandClass":112,"commandClassName":"Configuration","property":4,"propertyName":"Invert Switch","type":"number","readable":true,"writeable":true,"description":"Invert the ON/OFF Switch State.","label":"Invert Switch","default":0,"stateless":false,"min":0,"max":1,"list":true,"states":[{"text":"No","value":0},{"text":"Yes","value":1}],"value":0,"lastUpdate":1610588625966},"112-0-5":{"id":"3-112-0-5","nodeId":3,"commandClass":112,"commandClassName":"Configuration","property":5,"propertyName":"Ignore Start-Level (Receiving)","type":"number","readable":true,"writeable":true,"description":"This dimmer will start dimming from its current level.","label":"Ignore Start-Level (Receiving)","default":0,"stateless":false,"min":0,"max":1,"list":true,"states":[{"text":"No","value":0},{"text":"Yes","value":1}],"value":0,"lastUpdate":1610588634680},"112-0-7":{"id":"3-112-0-7","nodeId":3,"commandClass":112,"commandClassName":"Configuration","property":7,"propertyName":"On/Off Command Dim Step","type":"number","readable":true,"writeable":true,"description":"Indicates how many levels the dimmer will change per step.","label":"On/Off Command Dim Step","default":3,"stateless":false,"min":1,"max":99,"list":false,"value":20,"lastUpdate":1610588642131},"112-0-8":{"id":"3-112-0-8","nodeId":3,"commandClass":112,"commandClassName":"Configuration","property":8,"propertyName":"On/Off Command Dim Rate","type":"number","readable":true,"writeable":true,"description":"This sets how often the dim level will change.","label":"On/Off Command Dim Rate","default":3,"stateless":false,"min":1,"max":255,"list":false,"value":1,"lastUpdate":1610588669498},"112-0-9":{"id":"3-112-0-9","nodeId":3,"commandClass":112,"commandClassName":"Configuration","property":9,"propertyName":"Local Control Dim Step","type":"number","readable":true,"writeable":true,"description":"How many levels the dimmer will change for each step.","label":"Local Control Dim Step","default":3,"stateless":false,"min":1,"max":99,"list":false,"value":20,"lastUpdate":1610588676664},"112-0-10":{"id":"3-112-0-10","nodeId":3,"commandClass":112,"commandClassName":"Configuration","property":10,"propertyName":"Local Control Dim Rate","type":"number","readable":true,"writeable":true,"description":"This sets how often the dim level will change.","label":"Local Control Dim Rate","default":3,"stateless":false,"min":1,"max":255,"list":false,"value":1,"lastUpdate":1610588681444},"112-0-11":{"id":"3-112-0-11","nodeId":3,"commandClass":112,"commandClassName":"Configuration","property":11,"propertyName":"ALL ON/ALL OFF Dim Step","type":"number","readable":true,"writeable":true,"description":"How many levels the dimmer will change per step.","label":"ALL ON/ALL OFF Dim Step","default":1,"stateless":false,"min":1,"max":99,"list":false,"value":20,"lastUpdate":1610588685664},"112-0-12":{"id":"3-112-0-12","nodeId":3,"commandClass":112,"commandClassName":"Configuration","property":12,"propertyName":"ALL ON/ALL OFF Dim Rate","type":"number","readable":true,"writeable":true,"description":"This sets how often the dim level will change.","label":"ALL ON/ALL OFF Dim Rate","default":1,"stateless":false,"min":1,"max":255,"list":false,"value":1,"lastUpdate":1610588710194},"114-0-manufacturerId":{"id":"3-114-0-manufacturerId","nodeId":3,"commandClass":114,"commandClassName":"Manufacturer Specific","endpoint":0,"property":"manufacturerId","propertyName":"manufacturerId","type":"number","readable":true,"writeable":false,"label":"Manufacturer ID","stateless":false,"min":0,"max":65535,"list":false,"value":99,"lastUpdate":1610588593034},"114-0-productType":{"id":"3-114-0-productType","nodeId":3,"commandClass":114,"commandClassName":"Manufacturer Specific","endpoint":0,"property":"productType","propertyName":"productType","type":"number","readable":true,"writeable":false,"label":"Product type","stateless":false,"min":0,"max":65535,"list":false,"value":18756,"lastUpdate":1610588593035},"114-0-productId":{"id":"3-114-0-productId","nodeId":3,"commandClass":114,"commandClassName":"Manufacturer Specific","endpoint":0,"property":"productId","propertyName":"productId","type":"number","readable":true,"writeable":false,"label":"Product ID","stateless":false,"min":0,"max":65535,"list":false,"value":12344,"lastUpdate":1610588593036},"134-0-libraryType":{"id":"3-134-0-libraryType","nodeId":3,"commandClass":134,"commandClassName":"Version","endpoint":0,"property":"libraryType","propertyName":"libraryType","type":"any","readable":true,"writeable":false,"label":"Library type","stateless":false,"list":false,"value":3,"lastUpdate":1610588593037},"134-0-protocolVersion":{"id":"3-134-0-protocolVersion","nodeId":3,"commandClass":134,"commandClassName":"Version","endpoint":0,"property":"protocolVersion","propertyName":"protocolVersion","type":"any","readable":true,"writeable":false,"label":"Z-Wave protocol version","stateless":false,"list":false,"value":"4.34","lastUpdate":1610588593038},"134-0-firmwareVersions":{"id":"3-134-0-firmwareVersions","nodeId":3,"commandClass":134,"commandClassName":"Version","endpoint":0,"property":"firmwareVersions","propertyName":"firmwareVersions","type":"any","readable":true,"writeable":false,"label":"Z-Wave chip firmware versions","stateless":false,"list":false,"value":["5.29"],"lastUpdate":1610588593040},"134-0-hardwareVersion":{"id":"3-134-0-hardwareVersion","nodeId":3,"commandClass":134,"commandClassName":"Version","endpoint":0,"property":"hardwareVersion","propertyName":"hardwareVersion","type":"any","readable":true,"writeable":false,"label":"Z-Wave chip hardware version","stateless":false,"list":false,"lastUpdate":1610588593041}},"groups":[{"text":"Lifeline","value":1,"maxNodes":5,"isLifeline":true,"multiChannel":false},{"text":"On/Off control","value":2,"maxNodes":5,"isLifeline":false,"multiChannel":false},{"text":"On/Off control","value":3,"maxNodes":5,"isLifeline":false,"multiChannel":false}],"neighbors":[5,6,7,8,9,10,11,15,19,27,36,39,53,54,55,58,60,65,73,75,76,77,80,102,103,104,105,107,110,111,112,113,114,117,118,121,122,124,125,126,128,130],"ready":true,"available":true,"hassDevices":{"light_dimmer":{"type":"light","object_id":"dimmer","discovery_payload":{"schema":"template","brightness_template":"{{ (value_json.value / 99 255) | round(0) }}","state_topic":"homeassistant/3/38/0/currentValue","state_template":"{{ \"off\" if value_json.value == 0 else \"on\" }}","command_topic":"homeassistant/3/38/0/targetValue/set","command_on_template":"{{ ((brightness / 255 99) | round(0)) if brightness is defined else 255 }}","command_off_template":"0","device":{"identifiers":["zwavejs2mqtt_0xeb87ad4a_node3"],"manufacturer":"Jasco Products","model":"In-Wall Dimmer Switch (GE 14294 (ZW3005))","name":"nodeID_3","sw_version":"5.29"},"name":"nodeID_3_dimmer","unique_id":"zwavejs2mqtt_0xeb87ad4a_3-38-0-currentValue"},"discoveryTopic":"light/nodeID_3/dimmer/config","values":["38-0-currentValue","38-0-targetValue"],"persistent":false,"ignoreDiscovery":false},"sensor_scene_state_sceneid":{"type":"sensor","object_id":"scene_state_sceneid","discovery_payload":{"state_topic":"homeassistant/3/43/0/sceneId","value_template":"{{ value_json.value}}","json_attributes_topic":"homeassistant/3/43/0/sceneId","device":{"identifiers":["zwavejs2mqtt_0xeb87ad4a_node3"],"manufacturer":"Jasco Products","model":"In-Wall Dimmer Switch (GE 14294 (ZW3005))","name":"nodeID_3","sw_version":"5.29"},"name":"nodeID_3_scene_state_sceneid","unique_id":"zwavejs2mqtt_0xeb87ad4a_3-43-0-sceneId"},"discoveryTopic":"sensor/nodeID_3/scene_state_sceneid/config","values":["43-0-sceneId"],"persistent":false,"ignoreDiscovery":false},"sensor_scene_state_dimmingduration":{"type":"sensor","object_id":"scene_state_dimmingduration","discovery_payload":{"state_topic":"homeassistant/3/43/0/dimmingDuration","value_template":"{{ value_json.value}}","json_attributes_topic":"homeassistant/3/43/0/dimmingDuration","device":{"identifiers":["zwavejs2mqtt_0xeb87ad4a_node3"],"manufacturer":"Jasco Products","model":"In-Wall Dimmer Switch (GE 14294 (ZW3005))","name":"nodeID_3","sw_version":"5.29"},"name":"nodeID_3_scene_state_dimmingduration","unique_id":"zwavejs2mqtt_0xeb87ad4a_3-43-0-dimmingDuration"},"discoveryTopic":"sensor/nodeID_3/scene_state_dimmingduration/config","values":["43-0-dimmingDuration"],"persistent":false,"ignoreDiscovery":false}},"failed":false,"lastActive":1610595625208,"interviewCompleted":true,"firmwareVersion":"5.29","isBeaming":true,"isSecure":false,"keepAwake":false,"maxBaudRate":null,"isRouting":true,"isFrequentListening":false,"isListening":true,"status":"Alive","interviewStage":"Complete","productLabel":"GE 14294 (ZW3005)","productDescription":"In-Wall Dimmer Switch","zwaveVersion":4,"deviceClass":{"basic":4,"generic":17,"specific":1},"hexId":"0x0063-0x3038-0x4944"},{"commandClassName":"Basic","commandClass":32,"endpoint":0,"property":"value","value":255,"propertyName":"value","newValue":255,"stateless":true}]}

Mine is set to send the full thing, but it is in node_value_updated at the end.

[robertsLando]

taking back what i just wrote, I do see this in the handle value notification function, which appears to be making an event... is that in MQTT?

If you enable the flag publiush events in gateway all zwavejs events are published to mqtt: https://zwave-js.github.io/zwavejs2mqtt/#/guide/mqtt?id=zwave-events

[AlCalzone]

Is the "undefined" normal

I recycled the log from "value added" and forgot to delete the part describing the change.

[blhoward2]

taking back what i just wrote, I do see this in the handle value notification function, which appears to be making an event... is that in MQTT?

If you enable the flag publiush events in gateway all zwavejs events are published to mqtt: https://zwave-js.github.io/zwavejs2mqtt/#/guide/mqtt?id=zwave-events

Yeah, I did that intentionally, but HA doesn’t see those and it would be difficult to define a new sensor under the device watching all events.

We need a value under the node that works like the scene one now does where it resets to 0. We tried to figure out last night why we aren’t getting a 32 command class under the node at all now (we did when sending value events), and I posted in the PR itself.

[AlCalzone]

Like I wrote in the PR, we might also have to create metadata for the value, which isn't done currently. But I need @robertsLando to confirm

[towerhand]

Wow thanks for adding support for this. Really appreciate it.