cgarwood/homeassistant-zwave_mqtt

Limited Pre-Release of the new OZW1.6 Z-Wave component. Currently has limited platform support. Check the README for more details.

homeassistant-zwave_mqtt's Issues

Complete light platform

Need to add light platform. Discovery schemas were copied from the existing zwave component.

More consistent logging

• Home Assistant version: 0.108.4
• ozwdaemon version or add-on version: build-80
• homeassistant-zwave_mqtt version: 0.0.9

This is minor, but just a though for some improvement, would it be possible to have more of a consistent format for the logging? Looking through the logs, I see node id being formatted in different ways.

2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] NODE ADDED: <OZWNode 1> - node id 1
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt] VALUE ADDED: node 1 - value label Loaded Config Revision - value 0 -- id 31227923 -- cc CommandClass.MANUFACTURER_SPECIFIC
2020-04-15 11:16:45 DEBUG (MainThread) [custom_components.zwave_mqtt.entity] Adding Node_id=2 Generic_command_class=7, Specific_command_class=1, Command_class=CommandClass.SENSOR_BINARY, Index=0, Value type=ValueType.BOOL, Genre=ValueGenre.USER as binary_sensor

Maybe something like:

NODE ADDED: node 1 - <OZWNode 1>
VALUE ADDED: node 1 - value label Loaded Config Revision - value 0 -- id 31227923 -- cc CommandClass.MANUFACTURER_SPECIFIC
ENTITY ADDED: node 2 - Generic_command_class=7, Specific_command_class=1, Command_class=CommandClass.SENSOR_BINARY, Index=0, Value type=ValueType.BOOL, Genre=ValueGenre.USER as binary_sensor

or prepend node id to the front:

[node 1] NODE ADDED: <OZWNode 1>
[node 1] VALUE ADDED: value label Loaded Config Revision - value 0 -- id 31227923 -- cc CommandClass.MANUFACTURER_SPECIFIC
[node 1] ENTITY ADDED: Generic_command_class=7, Specific_command_class=1, Command_class=CommandClass.SENSOR_BINARY, Index=0, Value type=ValueType.BOOL, Genre=ValueGenre.USER as binary_sensor

It would make it easier to filter the log messages to a single node if needed.

Otherwise, to filter on a specific node like 11 I'm using a regex node(\s|_id=)?11.

Battery powered node shows as unavailable even after a wakeup event

I have a battery powered door sensor. After restarting OZW and HA it shows as unavailable. Sometimes it eventually becomes available. However, even when an actual event appears for the device via the mqtt channel is may stay unavailable. Here is a specific example from monitoring the mqtt traffic related to the node:

OpenZWave/1/node/22/instance/1/commandclass/32/value/369623057/

{
    "Label": "Basic",
    "Value": 255,
    "Units": "",
    "Min": 0,
    "Max": 255,
    "Type": "Byte",
    "Instance": 1,
    "CommandClass": "COMMAND_CLASS_BASIC",
    "Index": 0,
    "Node": 22,
    "Genre": "Basic",
    "Help": "Basic status of the node",
    "ValueIDKey": 369623057,
    "ReadOnly": false,
    "WriteOnly": false,
    "ValueSet": false,
    "ValuePolled": false,
    "ChangeVerified": false,
    "Event": "valueChanged",
    "TimeStamp": 1584037978
}

OpenZWave/1/node/22/instance/1/commandclass/32/value/369623057/

{
    "Label": "Basic",
    "Value": 0,
    "Units": "",
    "Min": 0,
    "Max": 255,
    "Type": "Byte",
    "Instance": 1,
    "CommandClass": "COMMAND_CLASS_BASIC",
    "Index": 0,
    "Node": 22,
    "Genre": "Basic",
    "Help": "Basic status of the node",
    "ValueIDKey": 369623057,
    "ReadOnly": false,
    "WriteOnly": false,
    "ValueSet": false,
    "ValuePolled": false,
    "ChangeVerified": false,
    "Event": "valueChanged",
    "TimeStamp": 1584037995
}

This is a sequence of basic messages indicating a door open followed by a door closed for the entitiy. After this sequence the device still shows as unavailable in HA. This is running 0.106.2 with the latest versions of the zwave_mqtt (via HACS) integration and OZW.

Issue calling zwave_set_config_parameter

Home Assistant version: 0.106.4

ozwdaemon version or add-on version: 1.0.13

homeassistant-zwave_mqtt version:0.0.7

Can't get zwave_mqtt.set_config_parameter to work

If i go to the service call window and do

I see this in the logs.

[20200225 7:18:28.916 EST] [qt.mqtt.connection.verbose] [debug]: Finalize PUBLISH: topic: QMqttTopicName("OpenZWave/1/command/setvalue/") payloadLength: 48
[20200225 7:18:28.916 EST] [ozw.mqtt.commands] [debug]: Got "OpenZWave/1/command/setvalue/" Message: "{"ValueIDKey": 5910974621810708, "Value": "Red"}"
[20200225 7:18:28.917 EST] [qt.mqtt.connection] [debug]: qint32 QMqttConnection::sendControlPublish(const QMqttTopicName&, const QByteArray&, quint8, bool, const QMqttPublishProperties&) QMqttTopicName("OpenZWave/1/event/setvalue/") Size: 123 bytes. QoS: 0 Retain: false
[20200225 7:18:28.917 EST] [qt.mqtt.connection.verbose] [debug]: bool QMqttConnection::writePacketToTransport(const QMqttControlPacket&) DataSize: 155
[20200225 7:18:28.917 EST] [ozw.mqtt.commands.setValue] [warning]: Incorrect Field Type (Integer) for "SetValue" : Value: 5
[20200225 7:18:28.917 EST] [ozw.mqtt.commands] [warning]: Message Processing for "SetValue" failed: "{"ValueIDKey": 5910974621810708, "Value": "Red"}"
[20200225 7:18:28.918 EST] [qt.mqtt.connection.verbose] [debug]: void QMqttConnection::transportReadReady()
[20200225 7:18:28.918 EST] [qt.mqtt.connection.verbose] [debug]: Received PUBLISH
[20200225 7:18:28.918 EST] [qt.mqtt.connection.verbose] [debug]: Finalize PUBLISH: topic: QMqttTopicName("OpenZWave/1/event/setvalue/") payloadLength: 123

This is the values to set the bottom status light to red is found here.

I've tried both the value Red and 1.

Include doesn't seem to work properly

• Home Assistant version: 0.105.5
• ozwdaemon version or add-on version: 1.0.12
• homeassistant-zwave_mqtt version: 0.0.7

I'm having trouble with including sensors. I can see in the mqtt that something has happened, but I can't see any information about the recently included node (3). It's a Aeotec door sensor (same as node 2). The mqtt dump is from a restart after including. I can dump more info it you tell me what you need.
dump_mqtt2.txt

Add support for scene events

From what I can see on the commit comments and other issues it does not look like there is a "reminder" to add scene events and central scene events. This is rather important for me as my setup heavily depend on this.

Not able to switch on/off fibaro lights "migrated" from old integration.

• Home Assistant version: 106.2 (HA Core via docker-compose)
• ozwdaemon version or add-on version: Latest version of ozwdeamon via docker (not compose)
• homeassistant-zwave_mqtt version: v0.0.7 (newest)
  My Zwave network:
  Around 20 pcs of Fibaro Dimmer 2 and 2 pcs of Fibaro double switch

I've previously used integrated Zwave of HA and now migrated according to guides.

I have done following:

• Removed Zwave-integrationen in HA
• Installed MQTT server via docker-compose (toke/mosquitto)
• Installed MQTT integrationen i HA and configured succesfully.
• Started OZWDeamon via docker (and also added Network Key for Zwave (and added fine according to logs)).
• Installed HACS
• Installed Z-wave over MQTT (Pre-release) via HACS
• Added Zwave-over-MQTT integration in HA.

The old devices are registered and shows up, and the OZW deamon are outputting data that looks good, what I can see.

When I start up no states of the lights are updated (except for one light). This one light, I can turn on and off without any issue. But no other lights are reacting to turning on/off via HA.

When I switch the light on via the wall switch the state is updated in HA. But still not able to control them via HA.

When I try to turn on a light following is outputted to the OZWdeamon:

[20200301 20:55:02.896 UTC] [qt.mqtt.connection.verbose] [debug]: void QMqttConnection::transportReadReady()
[20200301 20:55:02.896 UTC] [qt.mqtt.connection.verbose] [debug]: Received PUBLISH
[20200301 20:55:02.897 UTC] [qt.mqtt.connection.verbose] [debug]: Finalize PUBLISH: topic: QMqttTopicName("OpenZWave/1/command/setvalue/")  payloadLength: 39
[20200301 20:55:02.897 UTC] [ozw.mqtt.commands] [debug]: Got  "OpenZWave/1/command/setvalue/"  Message:  "{\"ValueIDKey\": 172589073, \"Value\": 255}"
[20200301 20:55:02.898 UTC] [ozw.mqtt.commands.setValue] [info]: Setting  172589073  to Value  QVariant(uint, 255)
[20200301 20:55:02.899 UTC] [ozw.values] [debug]: setData Called for Row 754  With Value QVariant(uint, 255)
[20200301 20:55:02.900 UTC] [ozw.values] [debug]: valueModel Changed! QTOZW_ValueIds::Value - 754 :  QVariant(uint, 255)
[20200301 20:55:02.900 UTC] [ozw.values] [debug]: valueModel Changed! vidKey: 172589073 QVariant(uint, 255)
[20200301 20:55:02.900 UTC] [ozw.library] [info]: Info - Node: 10 Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - 255
[20200301 20:55:02.901 UTC] [ozw.library] [info]: Info - Node: 10 SwitchMultilevel::Set - Setting to level 255
[20200301 20:55:02.901 UTC] [ozw.library] [info]: Info - Node: 10   Duration: Default
[20200301 20:55:02.902 UTC] [ozw.library] [debug]: Detail - Node: 10 Queuing (Send) SwitchMultilevelCmd_Set (Node=10): 0x01, 0x0b, 0x00, 0x13, 0x0a, 0x04, 0x26, 0x01, 0xff, 0xff, 0x25, 0xef, 0x04
[20200301 20:55:02.902 UTC] [ozw.library] [debug]: Detail - Node: 10 Queuing (Send) SwitchMultilevelCmd_Get (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x26, 0x02, 0x25, 0xf0, 0x1c
[20200301 20:55:02.903 UTC] [ozw.library] [debug]: Detail - Node: 0
[20200301 20:55:02.903 UTC] [ozw.library] [info]: Info - Node: 10 Sending (Send) message (Callback ID=0xef, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=10): 0x01, 0x0b, 0x00, 0x13, 0x0a, 0x04, 0x26, 0x01, 0xff, 0xff, 0x25, 0xef, 0x04
[20200301 20:55:02.903 UTC] [ozw.library] [info]: Info - Node: 10 Encrypted Flag is 0
[20200301 20:55:02.904 UTC] [qt.mqtt.connection] [debug]: qint32 QMqttConnection::sendControlPublish(const QMqttTopicName&, const QByteArray&, quint8, bool, const QMqttPublishProperties&) QMqttTopicName("OpenZWave/1/event/setvalue/")  Size: 51  bytes. QoS: 0  Retain: false
[20200301 20:55:02.904 UTC] [qt.mqtt.connection.verbose] [debug]: bool QMqttConnection::writePacketToTransport(const QMqttControlPacket&)  DataSize: 82
[20200301 20:55:02.905 UTC] [ozw.mqtt.commands] [info]: Processed Message for  "SetValue" :  "{\"ValueIDKey\": 172589073, \"Value\": 255}"
[20200301 20:55:02.906 UTC] [qt.mqtt.connection.verbose] [debug]: void QMqttConnection::transportReadReady()
[20200301 20:55:02.906 UTC] [qt.mqtt.connection.verbose] [debug]: Received PUBLISH
[20200301 20:55:02.907 UTC] [qt.mqtt.connection.verbose] [debug]: Finalize PUBLISH: topic: QMqttTopicName("OpenZWave/1/event/setvalue/")  payloadLength: 51
[20200301 20:55:02.933 UTC] [ozw.library] [debug]: Detail - Node: 10   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
[20200301 20:55:02.934 UTC] [ozw.library] [debug]: Detail - Node: 10   ZW_SEND_DATA delivered to Z-Wave stack
[20200301 20:55:02.949 UTC] [ozw.library] [debug]: Detail - Node: 10   Received: 0x01, 0x07, 0x00, 0x13, 0xef, 0x00, 0x00, 0x02, 0x06
[20200301 20:55:02.951 UTC] [ozw.library] [debug]: Detail - Node: 10   ZW_SEND_DATA Request with callback ID 0xef received (expected 0xef)
[20200301 20:55:02.952 UTC] [ozw.library] [info]: Info - Node: 10 Request RTT 48 Average Request RTT 47
[20200301 20:55:02.954 UTC] [ozw.library] [debug]: Detail - Node: 10   Expected callbackId was received
[20200301 20:55:02.955 UTC] [ozw.library] [debug]: Detail - Node: 10   Expected reply was received
[20200301 20:55:02.955 UTC] [ozw.library] [debug]: Detail - Node: 10   Message transaction complete
[20200301 20:55:02.956 UTC] [ozw.library] [debug]: Detail - Node: 0
[20200301 20:55:02.956 UTC] [ozw.library] [debug]: Detail - Node: 10 Removing current message
[20200301 20:55:02.956 UTC] [ozw.library] [debug]: Detail - Node: 0
[20200301 20:55:02.957 UTC] [ozw.library] [info]: Info - Node: 10 Sending (Send) message (Callback ID=0xf0, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x26, 0x02, 0x25, 0xf0, 0x1c
[20200301 20:55:02.957 UTC] [ozw.library] [info]: Info - Node: 10 Encrypted Flag is 0
[20200301 20:55:02.968 UTC] [ozw.library] [debug]: Detail - Node: 10   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
[20200301 20:55:02.969 UTC] [ozw.library] [debug]: Detail - Node: 10   ZW_SEND_DATA delivered to Z-Wave stack
[20200301 20:55:02.985 UTC] [ozw.library] [debug]: Detail - Node: 10   Received: 0x01, 0x07, 0x00, 0x13, 0xf0, 0x00, 0x00, 0x02, 0x19
[20200301 20:55:02.987 UTC] [ozw.library] [debug]: Detail - Node: 10   ZW_SEND_DATA Request with callback ID 0xf0 received (expected 0xf0)
[20200301 20:55:02.988 UTC] [ozw.library] [info]: Info - Node: 10 Request RTT 30 Average Request RTT 38
[20200301 20:55:02.989 UTC] [ozw.library] [debug]: Detail - Node: 10   Expected callbackId was received

mqtt_dump.txt

Entity state not updated properly (especially for dimmers)

With the existing integration you can specify a refresh delay and this handles the case of dimmers that respond to a light.on with their current state which still shows "off". With this new version I don't see this capability or an alternative. For human interactions you just notice that the visual toggle in HA is still showing off and turn it on again and now, of course, it works. However, for scripts it is a more serious issue. I thought homeassistant.update_entity might do the trick but that doesn't seem to do anything for zwave. What I currently do is reissue the light.on after a short delay which causes HA to again try to turn on the light since it thinks it is still off but now the response indeed shows it is on. Ok work-around but needs a real solution at some point.

Add services

Add services for various OpenZWave functions.

• add_node #35
• add_node_secure #35
• remove_node #35
• cancel_command #35
• heal_network
• set_config_parameter
• remove_failed_node #35
• replace_failed_node #35
• refresh_node_value
• refresh_node
• set_wakeup
• reset_node_meters
• heal_node
• test_node
• set_poll_intensity
  others?

Unlike the current zwave component implementation of these services, we'll need to also allow specifying an OZW Instance number since multiple OZW instances can be running and reporting to MQTT. We should default the OZW Instance to be instance 1 though, for compatibility.

May require upstream modifications to the python-openzwave-mqtt library

Add cover platform

Need to add cover platform. Discovery schemas were copied from the existing zwave component.

Some cover devices need to be added securely, so this may need to wait until qt-openzwave supports specifying a network key.

Add node statistics sensors

Add a sensor for each node with attributes containing the node statistics. This will replace the zwave.xyz entities produced by the existing zwave component.

Functionally it should operate similar to the existing zwave.xyz entities, but should be a member of the sensor domain.

Unable to call Zwave Services

Don't want to hijack the other thread...

Environment:

Homeassistant: 0.105.1
Ozwdaemon: ozwdaemon (latest via add-on store)
homeassistant-zwave_mqtt via HACS

Zwave modules:

Aeotec Z-stick Gen5
Aeotec Multisensor 6

I'm unable to call the zwave services, i.e unable to include or exclude devices

Also there are multiple message in the logs:

2020-02-06 11:35:17 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/13: {'Name': 'Retransmit', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988546}
2020-02-06 11:35:17 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/13: {'Name': 'Control Key1', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988546}
2020-02-06 11:35:17 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/13: {'Name': 'Control Key2', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988547}
2020-02-06 11:35:17 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/16: {'Name': 'Lifeline', 'Help': '', 'MaxAssociations': 5, 'Members': ['1.0', '2.0'], 'TimeStamp': 1580988525}
2020-02-06 11:35:17 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/16: {'Name': 'Retransmit', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988525}
2020-02-06 11:35:17 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/16: {'Name': 'Control Key1', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988525}
2020-02-06 11:35:17 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/16: {'Name': 'Control Key2', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988525}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/20: {'Name': 'LifeLine', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988525}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/20: {'Name': 'Retransmit Switch CC', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988525}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/21: {'Name': 'LifeLine', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988525}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/21: {'Name': 'Retransmit Switch CC', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988525}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/23: {'Name': 'LifeLine', 'Help': '', 'MaxAssociations': 5, 'Members': ['1.0'], 'TimeStamp': 1580988525}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/24: {'Name': 'LifeLine', 'Help': '', 'MaxAssociations': 5, 'Members': ['1.0'], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/26: {'Name': 'Lifeline', 'Help': '', 'MaxAssociations': 5, 'Members': ['1.0', '1.1'], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/26: {'Name': 'Browse', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/26: {'Name': 'Tampering', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/26: {'Name': 'Doorbell 1', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/26: {'Name': 'Doorbell 2', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/26: {'Name': 'Doorbell 3', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/26: {'Name': 'Environment', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/26: {'Name': 'Security', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWNode cannot process message OpenZWave/1/node/26: {'Name': 'Emergency', 'Help': '', 'MaxAssociations': 5, 'Members': [], 'TimeStamp': 1580988526}
2020-02-06 11:35:18 WARNING (MainThread) [openzwavemqtt] OZWInstance cannot process message OpenZWave/1: {'Node': 20, 'Event': 'Notification_Code_MsgTimeout', 'TimeStamp': 1580988913}```

Add support for scene events

From what I can see on the commit comments and other issues it does not look like there is a "reminder" to add scene events and central scene events. This is rather important for me as my setup heavily depend on this.

scene_activated service require actual node id rather than implied entity

In setting up an automation based on service.scene_activated you seem to need to supply the actual node id that the zwave system supplies. This has already been mapped in setup to the HA entity corresponding to it so it would be nicer to be able to specify the entity_id for the device. It would avoid having 2 references to the same thing that can get out of sync.

Central scene different buttons not shown in

• Home Assistant version: 0.105.4

• ozwdaemon version or add-on version: 1.0.10

• homeassistant-zwave_mqtt version:0.0.5

  when i listen to the zwave_mqtt.scene_activated i get only the following:

{
    "event_type": "zwave_mqtt.scene_activated",
    "data": {
        "node_id": 7,
        "scene_id": 1,
        "scene_label": "Pressed 1 Time"
    },
    "origin": "LOCAL",
    "time_fired": "2020-02-16T14:28:30.198427+00:00",
    "context": {
        "id": "d7ca6f4a3c5641cb8b86adbe543836d1",
        "parent_id": null,
        "user_id": null
    }
}

i'm not able to see the different buttons ( 8 in my case)

mqtt_dump.txt

Add migration path from zwave2mqtt

It seems like a lot of people (myself included) use the zwave2mqtt tool instead of the built-in component, so it may be a good idea to also see if a migration from that is feasible.

Add-on problem

Didn't know if you wanted add-on issues here as well, point me in another direction if not.
My add-on seems to start at first but this is the log:

2020-02-05 14:36:20,617 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
2020-02-05 14:36:20,637 INFO supervisord started with pid 6
2020-02-05 14:36:21,646 INFO spawned: 'websockify' with pid 31
2020-02-05 14:36:21,655 INFO spawned: 'ozwadmin' with pid 32
2020-02-05 14:36:21,661 INFO spawned: 'xvfb' with pid 33
2020-02-05 14:36:21,666 INFO spawned: 'mosquitto' with pid 34
2020-02-05 14:36:21,673 INFO spawned: 'x11vnc' with pid 35
2020-02-05 14:36:21,679 INFO spawned: 'ozwdaemon' with pid 36
2020-02-05 14:36:21,697 INFO exited: ozwadmin (exit status 127; not expected)
2020-02-05 14:36:22,889 INFO success: websockify entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-02-05 14:36:22,895 INFO spawned: 'ozwadmin' with pid 39
2020-02-05 14:36:22,896 INFO success: xvfb entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-02-05 14:36:22,896 INFO success: mosquitto entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-02-05 14:36:22,896 INFO success: x11vnc entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-02-05 14:36:22,897 INFO success: ozwdaemon entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-02-05 14:36:22,919 INFO exited: ozwadmin (exit status 127; not expected)
2020-02-05 14:36:25,871 INFO spawned: 'ozwadmin' with pid 46
2020-02-05 14:36:25,895 INFO exited: ozwadmin (exit status 127; not expected)
2020-02-05 14:36:28,942 INFO spawned: 'ozwadmin' with pid 52
2020-02-05 14:36:28,969 INFO exited: ozwadmin (exit status 127; not expected)
2020-02-05 14:36:29,971 INFO gave up: ozwadmin entered FATAL state, too many start retries too quickly

I have tried rebuilding, restarting add-on and restarting hass. The add-on keeps on running and I can open web ui but it's only black.

Automatic creation of binary sensors from Notification command class

I mainly only have one gripe with the OZW 1.4 implementation of Z-Wave in HA, which is that for simple devices like door/window or motion sensors, etc., all HA users are required to create their own binary template sensors, for example. It's a necessity because OZW 1.4 doesn't provide any mechanism to know which events are supported.

Now with OZW 1.6, it provides values and labels for the supported events (I'm not actually sure how it creates them, some devices support getting the supported values, for others maybe it creates the values on the fly when it sees them?). It seems entirely possible that from the set of notification values, HA could create a binary sensor for each. Here is sample mqtt data for some of my nodes:

{
    "Label": "Access Control",
    "Value": {
        "List": [
            {
                "Value": 0,
                "Label": "Clear"
            },
            {
                "Value": 22,
                "Label": "Door/Window Open"
            },
            {
                "Value": 23,
                "Label": "Door/Window Closed"
            }
        ],
        "Selected": "Door/Window Closed",
        "Selected_id": 23
    },
...
}

{
    "Label": "Home Security",
    "Value": {
        "List": [
            {
                "Value": 0,
                "Label": "Clear"
            },
            {
                "Value": 3,
                "Label": "Tampering -  Cover Removed"
            },
            {
                "Value": 8,
                "Label": "Motion Detected at Unknown Location"
            }
        ],
        "Selected": "Clear",
        "Selected_id": 0
    },
...
}

In this integration, and with the native 1.4 integration, all I get is the "home_security" and "access_control" entities with the raw numbers. These sensors are generally confusing to new users.

Instead, it seems like now it would be possible (?) to create a binary sensor for each Value in the List, which would be "on" when it is selected. The downside would be the number of new entities created (there are already a lot, and N-times more in case of multi-channel devices). There would be some entities that perform the same function, such as the "Door/Window Closed" and "Door/Window Opened".

It's very easy to disable entities with the entity registry now though, and it would no longer be necessary to create manual template sensors.

UnboundLocalError

I'm testing MQTT Zwave, and reporting my first bug :)

homeassistant-zwave_mqtt/custom_components/zwave_mqtt/sensor.py

Line 33 in 08fc96f

async_add_entities([sensor])

Exception in async_add_sensor when dispatching 'zwave_new_sensor': (<custom_components.zwave_mqtt.entity.ZWaveDeviceEntityValues object at 0xae7575d0>,)
Traceback (most recent call last):
File "/config/custom_components/zwave_mqtt/sensor.py", line 33, in async_add_sensor
async_add_entities([sensor])
UnboundLocalError: local variable 'sensor' referenced before assignment

Parallel install with existing native z-wave integration

Hi,

I've been trying to test this on a dev platform and wanted to see if I can run it in parallel with the existing native z-wave integration. The aim is to see if I can migrate compatible devices to the new integration and leave incompatible devices on the native platform for the moment. I suspect that the native integration locks the usb port for comms to the z-wave stick and the new integration cannot pull down the list of devices on the stick.

Any advice appreciated.

Add battery sensors

COMMAND_CLASS_BATTERY - needs discovery schema updated

Add LICENSE

Hello,

please add/specify a LICENSE to make it clear that we are legally allowed to use and modify the code in this repository.

Thanks!

How to enable this integration?

So, I've installed zwave_mqtt via HACS but the readme has no instructions on how to actually enable it. I added zwave_mqtt:` to my configuration.yaml and that worked, but it should be documented.

Cheers,

Light platform: All service calls to turn on or off lights fail.

Environment:

• Homeassistant 0.104.3 (docker)
• Ozwdaemon 'openzwave/ozwdaemon:latest' (docker)
• homeassistant-zwave_mqtt (main branch) via HACS

Zwave modules:

• Linear (Nortek Security Control LLC) PD300Z-2 Plug-in Dimmer Module
• Leviton DZPD3-1BW Dimmer Module

Issue:

Cannot turn on or off any lights. Doesn't work with any of the 2 different zwave modules listed above. I have tried via the UI and manually calling a service. Doesn't matter if a transition: value is passed in the service data. Also fails with homeassistant.turn_on/off service calls.

Error code below is produced by trying to turn off a light via the UI.

2020-02-01 12:43:51 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.140579229614544] 'NoneType' object has no attribute 'value'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 134, in handle_call_service
    connection.context(msg),
  File "/usr/src/homeassistant/homeassistant/core.py", line 1226, in async_call
    await asyncio.shield(self._execute_service(handler, service_call))
  File "/usr/src/homeassistant/homeassistant/core.py", line 1251, in _execute_service
    await handler.func(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 201, in handle_service
    self._platforms.values(), func, call, service_name, required_features
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 335, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 357, in _handle_service_platform_call
    await getattr(entity, func)(**data)
  File "/config/custom_components/zwave_mqtt/light.py", line 124, in async_turn_off
    await self.async_set_duration(**kwargs)
  File "/config/custom_components/zwave_mqtt/light.py", line 86, in async_set_duration
    if self.values.dimming_duration.value is None:
AttributeError: 'NoneType' object has no attribute 'value'

Re-work discovery process

The discovery (mapping node values/CCs to HA entities) process was mostly copied from the existing zwave component as I was trying to re-use as much code as possible. However, its difficult to follow and I'm hitting issues now with devices that have multiple values/CCs per entity (RGB lights, etc).

Currently the zwave_mqtt component receives a value_added notification for every value for every node. These values then get run through a discovery process and matched against a schema to see what kind of entity (if any) should be created. If there's a schema match it gets shipped off to a ZWaveDeviceEntityValues class for processing and actually creating the entity. ZWaveDeviceEntityValues is supposed to then update an entity if it gets additional values after its created. For example, we create a light entity based off of COMMAND_CLASS_SWITCH_MULTILEVEL, if the ZWaveDeviceEntityValues object for that class then receives a COMMAND_CLASS_COLOR, it should update the capabilities of the light entity to support RGB mixing.

The problem I'm seeing is, we create the light based off COMMAND_CLASS_SWITCH_MULTILEVEL, and we see the value_added notification for a COMMAND_CLASS_COLOR value in the time between dispatching the entity creation but before the entity has actually been created.

---

I think we may be better off re-writing the entire process. My hope is that it can be simplified to make it easier to follow and easier to maintain.

Temperature Not Accurately reporting

• Home Assistant version: 108.0, was also occurring on 107
• ozwdaemon version or add-on version: latest docker image, I'm not able to find the actual number anywhere.
• homeassistant-zwave_mqtt version: v0.0.9

mqtt_dump.txt

I have a Zooz Zwave 4 in 1 sensors model zse40. The temperature reports when manually triggering an update by pressing a button on the sensor and reports an accurate temp of 73 degress F, however within 30-120 seconds of the device going into sleep mode the temperature reverts to 166.44 degrees F. The device will report other attributes without a button update but no the temp. This was not happening with the old Home Assistant Zwave integrations. I understand this is pre-realease and there will be bugs but I wanted to bring it to your attention.

Separate instances to multiple Hass devices

• Home Assistant version: 0.105.5
• ozwdaemon version or add-on version: 0.1
• homeassistant-zwave_mqtt version: 0.0.5

The native zwave integration represents multi-channel zwave devices as multiple Home Assistant Devices, where the root endpoint (if applicable) and each endpoint are individual Devices. I am assuming you want to duplicate this behavior.

Attached is a dump with a thermostat that has two instances. Topics are, for example:

OpenZWave/1/node/9/instance/1
OpenZWave/1/node/9/instance/2

mqtt_dump.txt

Which Zwave sticks are supported?

The readme states "Supported Z-wave dongle compatible with OpenZWave 1.6" Which are supported?

Is any zwave dongle running 1.6 supported?

Mark entities unavailable if ozwdaemon goes offline

If an ozwdaemon instance goes offline we should mark the entities belonging to that instance as unavailable

Abort config flow if MQTT integration isn't already configured

This component requires the MQTT component in Home Assistant to be set up already. We should abort the config flow if MQTT isn't already setup.

[question] Setting up the MQTT Integration to work with this plugin

I am trying to setup the integration. Is there some guide on how to configure MQTT integration to make it work?

I suspect I am doing something wrong with the prefix. I do see my broker filling in with topics from qt-openzwave.

After adding node, Device and Entities list are confused until restart

• Home Assistant version: 0.106.1
• ozwdaemon version or add-on version: 0.1
• homeassistant-zwave_mqtt version: 0.0.7

I added a new node using the zwave_mqtt.add_node service. The node and its entities are detected immediately, but almost none of them are associated with the "ZWave over MQTT" integration, and instead the "sensor" integration. They are marked as read-only because they do not have a unique ID.

But if I click on an entity and go to settings, it seems to realize that it is part of the device and integration, so something is confused.

I then checked the device entity registry files and they seem to be correct, each entity has a unique ID and is associated with the device. So, I'm not sure if this is an integration bug or HA bug. After restarting HA, everything looks normal, but I would hope a restart is unnecessary. I've attached files from before the restart.

files.zip

Cleanup entities/registries when a node is removed

When a node is removed we should remove the entities from Home Assistant, clear them from the entity registry, and clear the node from the device registry.

May require upstream python-openzwave-mqtt updates to fire node removed events.

Add climate platform

Need to add climate platform. Discovery schemas were copied from the existing zwave component.

Should at some point decide/document best practice for fielding central scene events

Central scene events seem to have been standardized to some degree in openwave. The return a label and a value label as well as string versions of these. It isn't clear which of these (any? all?) can be assumed standardized across devices but they do get used in automations testing for things like multiple button clicks. We should have at least a "best practice" regarding how to catch these events. I.e. whether to use the string or the code or whether there is intent to further integrate them in the HA support in some way.

Issue setting zwave_mqtt.set_config_parameter

• Home Assistant version: 108.2
• ozwdaemon version or add-on version: 1.0.14
• homeassistant-zwave_mqtt version: v0.0.9

Blew away Z-Wave network and configuring from scratch in homeassistant_zwave_mqtt. Devices added fine via add_node.

I have been trying to use set_config_parameter from the HomeAssistant Services page, however it is not working. Warnings in log are along the lines of:

WARNING (MainThread) [custom_components.zwave_mqtt.services] Unknown config parameter 22799473241227284 on Node 7 with selection 1

I can change parameters via MQTT and publish as described by Isa: #45 (comment) but was trying to accomplish via Services tab.

I am doing something wrong, but cant figure it out. Solution not explicitly indicated in #67 (comment) .

Also adding dump file: mqtt_dump.txt

Enable turn_on/turn_off functions for switch

Waiting on upstream qt-openzwave fixes, currently trying to set a value through MQTT is crashing the qt-openzwave daemon.

Add migration path from existing zwave component

There's plenty more that needs done first, but I wanted to create an issue so it doesn't get lost...

We need to figure out some sort of migration path for users using the existing zwave component. Ideally we'd be able to migrate all of the entity_ids and device registry entries from the old zwave component to the new, so people don't have to rename/reconfigure them all.

---

• Migrate devices in device registry
• Migrate entities in entity registry
• Cleanup node entity

In case of normal Home Assistant including the supervisor:

• Offer user to migrate
• Auto initialise OZW Daemon add-on
• Auto initialise MQTT Broker add-on if needed
• Migrate Network key from config to OZW Daemon

In case of core-only Home Assistant:

• Offer user to migrate
• Show manual steps, like installing the OZW Daemon

GE switches. Scenes.

• Home Assistant version: 0.108.3
• ozwdaemon version or add-on version: latest
• homeassistant-zwave_mqtt version: 0.0.9

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.

OpenZWave/1/node/16/instance/1/commandclass/43/,{    "Instance": 1,    "CommandClassId": 43,    "CommandClass": "COMMAND_CLASS_SCENE_ACTIVATION",    "TimeStamp": 1586732254}
OpenZWave/1/node/16/instance/1/commandclass/43/value/273334291/,{    "Label": "Scene",    "Value": 0,    "Units": "",    "Min": -2147483648,    "Max": 2147483647,    "Type": "Int",    "Instance": 1,    "CommandClass": "COMMAND_CLASS_SCENE_ACTIVATION",    "Index": 0,    "Node": 16,    "Genre": "User",    "Help": "",    "ValueIDKey": 273334291,    "ReadOnly": false,    "WriteOnly": false,    "ValueSet": false,    "ValuePolled": false,    "ChangeVerified": false,    "Event": "valueAdded",    "TimeStamp": 1586732254}
OpenZWave/1/node/16/instance/1/commandclass/43/value/281475250044947/,{    "Label": "Duration",    "Value": 0,    "Units": "",    "Min": -2147483648,    "Max": 2147483647,    "Type": "Int",    "Instance": 1,    "CommandClass": "COMMAND_CLASS_SCENE_ACTIVATION",    "Index": 1,    "Node": 16,    "Genre": "User",    "Help": "",    "ValueIDKey": 281475250044947,    "ReadOnly": false,    "WriteOnly": false,    "ValueSet": false,    "ValuePolled": false,    "ChangeVerified": false,    "Event": "valueAdded",    "TimeStamp": 1586732254}

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.

Entity state not correctly reflected in Home Assistant

• Home Assistant version: 0.108.3
• ozwdaemon version or add-on version: 1.0.14
• homeassistant-zwave_mqtt version: v0.0.9

To control a light I have a Fibaro Dimmer 2 installed. All seems to be recognized well with zwave over mqtt, all relevant enitities are there. To turn on and turn off the light the entity "FIBARO System FGD212 Dimmer 2: Instance 1: Level" needs to be used.

However, when I click the button from Off to On, the light does turn on, but directly after the button turns Off again while the light still remains on. Each time I click the button again to On it just goes to Off again while the light remains on. Only a quick succession from Off to On to Off again eventually turns the light off.

So, I've made a quick screenrecording as it probably explains better what I mean than just describing in: https://youtu.be/fb4K9kvy7vw
I tried to describe in the comments what seems to be happening:
As you can see the initial state in hass is turned off and in MQTT Explorer you can see that the relevant entities value is 0.
When I turn the entity On you can see that the state indeed changes to value 99 and stays on it, but that the button in Home Assistant updates and shows it as turned off.
Each time you turn it on again the value in MQTT Explorer does not changed and each time the button turns off again.
Only when you quickly click the button on and off again the value is updated to 0 and the light indeed turns off.

I couldn't find this as a known issue so thought I'd log it. If there's something I can check then please let me know.

zwave_mqtt does not generate unique IDs

• Home Assistant version: 0.108.3
• ozwdaemon version or add-on version: latest
• homeassistant-zwave_mqtt version: 0.0.9

Getting these errors for every entity after restarting qt-ozw while Home Assistant is running.

Log Details (ERROR)
Logger: homeassistant.components.light
Source: helpers/entity_platform.py:437 
Integration: Light (documentation, issues) 
First occurred: 8:25:15 PM (5 occurrences) 
Last logged: 8:25:19 PM

Entity id already exists - ignoring: light.porch_lights_dimmer. Platform zwave_mqtt does not generate unique IDs
Entity id already exists - ignoring: light.driveway_lights_dimmer. Platform zwave_mqtt does not generate unique IDs
Entity id already exists - ignoring: light.great_room_lights_dimmer. Platform zwave_mqtt does not generate unique IDs
Entity id already exists - ignoring: light.kitchen_lights_dimmer. Platform zwave_mqtt does not generate unique IDs
Entity id already exists - ignoring: light.master_bedroom_lights_dimmer. Platform zwave_mqtt does not generate unique IDs

This might be related to #24 but reporting just in case.

Implement device registry support

https://developers.home-assistant.io/docs/en/device_registry_index.html

Can’t decrypt packet

• Home Assistant version: .106
• ozwdaemon version or add-on version:
• homeassistant-zwave_mqtt version: 0.0.7

I set this up to help test but I’m getting a ‘can’t decrypt packet’ error in the ozwdaemon logs for my securely paired devices. Did I miss a step to import the existing encryption key?

Cleanup registries when removing integration

Removing the integration should remove all associated entries from the entity registry and device registry.

Add fan platform

Need to add fan platform. Discovery schemas were copied from the existing zwave component.

Handle ozwdaemon restart while HA is running

If Home Assistant is currently running and the OZWDaemon restarts, we'll get a bunch of NODE_ADDED and VALUE_ADDED etc events fired, and the component will try to recreate all of the entities instead of simply updating them.

Need to add checks for if the entity already exists and fire an update instead of trying to recreate.

add doorbell / alarm siren support

the z-wave 1.6 specification supports a doorbell/alarm device.

Usecases:

• Possibility to trigger the chime/sound from Homeassistant.
• If supported by device: differentiate between alarm siren and doorbell/notification chime.
• Configure volume, ringtone etc.
• In case of a doorbell (like Aeotec Doorbell 6), event in hass that the doorbell is pressed so you can attach your own automations in hass.

I own the Aeotec Doorbell 6 myself and a couple of NEO Coolcam sirens.
Looking for feedback how people like to see this implemented.

Add lock platform

Need to add lock platform. Discovery schemas were copied from the existing zwave component.

Multiple zwave mqtt possible?

Not an issue right now as you're still in the build phase of just getting things working but thought I'd ask the question now considering this is designed to replace zwave in home assistant. Right now you can only have one zwave network in home assistant (I think)

With the move of this outside of HA and HA just seeing this via MQTT, could there be multiples of these running - think a big estate with buildings that aren't next to one another and you can't form a strong mesh of the whole network but you could have 2 -> many networks running separately as strong stable independent networks. With the other zwave to mqtt project you could have multiples of those running because the sensors/devices end up as mqtt sensors/devices. In this one, ultimately they end up on HA as zwave devices (if I understand correctly). Should this be thought about now, would it require any changes to this project, would need changes to HA no doubt? Some might say you'd want multiple HA installs per building in that estate but I'm not sure I agree and this could allow for that flexibility.

Looking forward to this project and not needing to restart my zwave network so many times

Just food for thought.

Home Assistant not responding to switch presses

mqtt_dump.txt

• Home Assistant version: 0.105.3
• ozwdaemon version or add-on version: 1.0.10
• homeassistant-zwave_mqtt version: 0.0.5

I have 3 Steinel IS 140-2 PIR / Floodlights and about 15 Fibaro dimmer 2's, all connected in secure mode. Each of the Fibaro modules presents 2 switches to Home Assistant, when I try to toggle any switch the lights don't change, and the switch immediately resets itself back in Home Assistant. For the Steinel PIRs the switch resets itself, but the light does toggle

Attached is a dump (taken over 60 seconds)