Closed towerhand closed 4 years ago
Someone on discord mentioned it should be CC 38 but both switches are not reporting it to mqtt.
The switches are a 14287 and 14294.
This looks like it might be an OZW bug. I have the same 14294, the controller is associated to Group 3 which is for double taps. ozwd does not seem to do anything with the Basic Set event, and there is no topic for the Basic command class. I've submitted an issue here https://github.com/OpenZWave/qt-openzwave/issues/60.
[20200413 22:45:30.530 PDT] [qt.mqtt.connection.verbose] [debug]: Finalize PUBLISH: topic: QMqttTopicName("OpenZWave/1/node/11/statistics/") payloadLength: 811
[20200413 22:45:38.623 PDT] [ozw.library] [debug]: Detail - Node: 11 Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x0b, 0x03, 0x20, 0x01, 0xff, 0xbc, 0x00, 0x9a
[20200413 22:45:38.623 PDT] [ozw.library] [debug]: Detail - Node: 0
[20200413 22:45:38.623 PDT] [ozw.library] [info]: Info - Node: 11 Received Basic set from node 11: level=255. Sending event notification.
[20200413 22:45:38.623 PDT] [ozw.library] [debug]: Detail - Node: 11 Notification: NodeEvent
[20200413 22:45:38.623 PDT] [ozw.notifications] [debug]: Notification pvt_nodeEvent 11 Event: 255
[20200413 22:46:00.528 PDT] [qt.mqtt.connection] [debug]: bool QMqttConnection::sendControlPingRequest()
Thanks for narrowing down the issue.
I'll leave this open, I'm assuming after qt-ozw fixes their side this component will need to be updated to send the zwave_mqtt.scene_activated event in HA.
Hi @kpine thanks for your research, that helps a lot. Have you also checked with an external MQTT client, like MQTT Explorer ? I did not yet check but it might be that generic node events are published to the event subtopic ?
I just checked with MQTT Explorer and didn't see any node events published to the event subtopic.
Hi @marcelveldt, yes I'm using MQTT Explorer along with the HA mqtt.dump
service. There are no node events being published. It doesn't look like the ozwd MQTT publisher implements node events.
void mqttpublisher::nodeEvent(quint8 node, quint8 event) {
Q_UNUSED(node);
Q_UNUSED(event);
/* we dont do anything here, as NodeEvent is just a BASIC message
* which should be handled via the normal ValueID/ValueChanged Events
*/
}
So it seems the bug is that no Basic command class topic is being published either.
OK great, thanks for confirming. In that case it indeed needs to be fixed upstream (OZW daemon)
There is also the question of how HA will implement it. Core HA Z-Wave uses the node_event
. Will this carry over to this implementation, or will there be a "basic" entity in its place with state changes?
If OZW does not use an event (as it says), and publishes the state with a Value, HA will either need to treat that as just another Value, or convert it to an event like it does with scene events.
Not sure yet, I was busy with the doorbell/siren implementation and these questions were popping up in my head too. Let's wait for for OZW first.
Should I leave this open or should I close this and open a new issue after qt-ozw get fixed?
This issue at https://github.com/OpenZWave/qt-openzwave/issues/60 has been fixed, and is available in the latest ozwdaemon Docker image. OZW will now publish topics for Command Class Basic events, when the right combination of compatibility flags are enabled for the device. For the GE switches, the IgnoreMapping and SetAsReport compat flags need to be enabled in order for value changes to be published.
Now it means zwave_mqtt needs to implement this behavior in some fashion. As mentioned in the linked issue, the "nodeEvent" API will be removed in the future from the OZW library, and will not be implemented in ozwd. This means that HA will need to deal with the Basic Value topic instead of looking at the events topic. It could treat the topic values like the Scene values are done and trigger something like the zwave.node_event
event when it sees the value change. Or it could expose the value as another sensor entity and let users configure automations based on the sensor values.
One complication might be during a restart of any of the components. HA would not want to trigger an event or state change unless the value has actually changed. For instance, I use this feature to set a light to full brightness when double tap on, and 25% brightness when double tap off. I wouldn't want that to activate during a restart, of either ozwd, the mqtt broker, or HA.
OK, that's great. I'll update the supervisor addon right away. As for the implementation in zwave_mqtt I will have a look within a few days if nobody beats me to it.
If it helps, here is the MQTT dump for the node, and here are the HA logs when it loads the node info.
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] NODE ADDED: <OZWNode 11> - node id 11
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Level - value 0 -- id 189366289 -- cc CommandClass.SWITCH_MULTILEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt.entity] Adding Node_id=11 Generic_command_class=17, Specific_command_class=1, Command_class=CommandClass.SWITCH_MULTILEVEL, Index=0, Value type=ValueType.BYTE, Genre=ValueGenre.USER as light
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Bright - value False -- id 281475166076952 -- cc CommandClass.SWITCH_MULTILEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Dim - value False -- id 562950142787608 -- cc CommandClass.SWITCH_MULTILEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Ignore Start Level - value True -- id 844425127886864 -- cc CommandClass.SWITCH_MULTILEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Start Level - value 0 -- id 1125900104597521 -- cc CommandClass.SWITCH_MULTILEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Dimming Duration - value 255 -- id 1407375081308177 -- cc CommandClass.SWITCH_MULTILEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Switch All - value {'List': [{'Value': 0, 'Label': 'Disabled'}, {'Value': 1, 'Label': 'Off Enabled'}, {'Value': 2, 'Label': 'On Enabled'}, {'Value': 255, 'Label': 'On a
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Scene - value 0 -- id 189448211 -- cc CommandClass.SCENE_ACTIVATION
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Duration - value 0 -- id 281475166158867 -- cc CommandClass.SCENE_ACTIVATION
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label ZWave+ Version - value 1 -- id 198672401 -- cc CommandClass.ZWAVEPLUS_INFO
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label InstallerIcon - value 1536 -- id 281475175383062 -- cc CommandClass.ZWAVEPLUS_INFO
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label UserIcon - value 1536 -- id 562950152093718 -- cc CommandClass.ZWAVEPLUS_INFO
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Loaded Config Revision - value 0 -- id 199000083 -- cc CommandClass.MANUFACTURER_SPECIFIC
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Config File Revision - value 5 -- id 281475175710739 -- cc CommandClass.MANUFACTURER_SPECIFIC
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Latest Available Config File Revision - value 5 -- id 562950152421395 -- cc CommandClass.MANUFACTURER_SPECIFIC
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Device ID - value -- id 844425129132055 -- cc CommandClass.MANUFACTURER_SPECIFIC
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Serial Number - value -- id 1125900105842711 -- cc CommandClass.MANUFACTURER_SPECIFIC
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Powerlevel - value {'List': [{'Value': 0, 'Label': 'Normal'}, {'Value': 1, 'Label': '-1dB'}, {'Value': 2, 'Label': '-2dB'}, {'Value': 3, 'Label': '-3dB'}, {'Value': 4,
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Timeout - value 0 -- id 281475175727121 -- cc CommandClass.POWERLEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Set Powerlevel - value False -- id 562950152437784 -- cc CommandClass.POWERLEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Test Node - value 0 -- id 844425129148433 -- cc CommandClass.POWERLEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Test Powerlevel - value {'List': [{'Value': 0, 'Label': 'Normal'}, {'Value': 1, 'Label': '-1dB'}, {'Value': 2, 'Label': '-2dB'}, {'Value': 3, 'Label': '-3dB'}, {'Value'
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Frame Count - value 0 -- id 1407375082569750 -- cc CommandClass.POWERLEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Test - value False -- id 1688850059280408 -- cc CommandClass.POWERLEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Report - value False -- id 1970325035991064 -- cc CommandClass.POWERLEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Test Status - value {'List': [{'Value': 0, 'Label': 'Failed'}, {'Value': 1, 'Label': 'Success'}, {'Value': 2, 'Label': 'In Progress'}], 'Selected': 'Failed', 'Selected_
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Acked Frames - value 0 -- id 2533274989412374 -- cc CommandClass.POWERLEVEL
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 11 - value label Basic - value 0 -- id 185073681 -- cc CommandClass.BASIC
Nice work @kpine, Thank you for getting this going.
Both is possible, an event and an additional sensor. Extra sensor is most versatile and userfriendly I guess, so you can do whatever you want and user can easily hide entities.
Awesome @marcelveldt. Thanks for the fix. Dumb question but I'm assuming I still gotta edit the ozwcache file for this to work.
Awesome @marcelveldt. Thanks for the fix. Dumb question but I'm assuming I still gotta edit the ozwcache file for this to work.
Yes, correct. As per instructions in https://github.com/OpenZWave/qt-openzwave/issues/60
Closed by #90
@marcelveldt thanks for the reply and the fix.
I have 2 GE switches (1 dimmer, 1 fan) and I'm trying to set up the automations for the double clicks (up and down) with the association scene command. Listening to zwave_mqtt.scene_activated doesn't show anything and can't see the payload getting published with mqtt explorer on CC# 43.
With the old integration I used to get a value of 255 for ON (up) and 0 for OFF (down) for the double clicks with the zwave.node_event service.
This is all I get with the mqtt dump using 'OpenZWave/1/node/16/instance/1/commandclass/43/#' and clicking the double up and down alternatively a few times.
I'm wondering if I should be looking for the payload on a different topic or if somethings broken. I figured I would see it in Home Assistant using zwave_mqtt.scene_activated.