Technically the key can be in 2 places, in your YAML and/or the core.config_entries file in .storage. If specified in the YAML that overrides anything in the core.config_entries.
I have a few Dragon Tech zwave dimmer switches that don’t update to off in HA when they are manually turned off. I saw some discussion about an issue with dimming that was supposed to be fixed in 0.114. Is this still an issue or could this be something specific to my switches?
Edit - Was able to resolve this help of firstof9 on the HA discord channel by enable polling for the switches
Could you share how you were able to enable polling? Or where to find that option? Is it “polling_intensity” or something similar in the zwave config?
In developer tools under Services you have to send an mqtt.publish with
topic: OpenZWave/1/command/enablepoll/
payload: ‘{“ValueIDKey”: xxxxxxxxx, “Intensity”: 1 }’
xxxxxxxxx is found under command class 38, it’s a unique number for the node. I used mqtt explorer and went to OpenZWave/1/node/10/instance/1/commandclass/38/value/172589073 <- this is xxxxxxxxx value you need.
Hit Call Service. It should then correctly show as off in HA although it does seem to take a couple of seconds but it does work.
This should be the link to the discussion in discord -> https://discord.com/channels/330944238910963714/332357267364249621/744386072804458628
2 Likes
I’m a new user coming off SmartThings. I installed HA on a Pi4 with the image, and then I installed OpenZWave as I didn’t realize there was another non-beta one. Overall I’m happy with it despite the clunky UI, but there’s 2 issues I encountered which really makes it tough to use with my devices:
I think ‘small’ issues like this will really turn users off if they’re coming from other platforms where these were working fine. I put small in quotes because it’s essentially rendered both devices unusable.
Look here: Z-Wave graph (without the python)
Although it looks like it is currently not working with qt-openzwave.
I am trying to switch over from the old integration to the new one and have a problem with sensative strips door sensors. In the old integration they were recognized well, but now I only see the node numbers without any info except for that if I open the door I see something changing in the OZW daemon (see picture). There is no entity however in HA
In the open zwave 1.6 I see that the sensative strips have a config:
Can I somehow add this configuration.xml to the nodes?
You either need to wait until the sensors wake up on their own, or manual wake them. A manual wake is usually pressing some kind of button on the device. When the device wakes up, OZW will refresh the node info and the QueryStage will proceed past Probe.
1 Like
What shows up under “Node Info” ?
Just started using QT-OPenZwave, and am pretty impressed so far.
However, I have one issue.
I have a lot of fibaro switches and dimmers that will send a “scene activated” when clicked,
I can see that I receve the events just fine:
{
"event_type": "ozw.scene_activated",
"data": {
"node_id": 31,
"scene_id": 0,
"scene_label": "Scene",
"scene_value_id": 16,
"scene_value_label": "Scene"
},
"origin": "LOCAL",
"time_fired": "2020-08-19T18:42:08.866167+00:00",
"context": {
"id": "afd5ac60e24b11eaa846c1552f0b02b8",
"parent_id": null,
"user_id": null
}
}
So I get the scene_value_id, which is fine, and the node_id.
But what I need is a way to go from node_id to entity_id for the actual light/switch-entity that was clicked.
Of course I can just write a manual map in jinja2 and use it all the automations, but that does not feel very comfortable or scalable…
Is there any function that can be used in templates to map an ozw node_id to a HA entity_id?
No, there is currently no such thing. A node may be associated with many entities though, which one would you pick?
In this case, it is pretty obvious that I’d pick the switch or light entity, but I dont known if that is universal.
With the old integration, I used to get a trigger.event.data.entity_id which pointed to the zwave-entity. And I just do a simple:
{% set light_entity = trigger.event.data.entity_id | replace('zwave', 'light') %}
in my automations (I have made sure to name them the same)
Sure, in many cases it will be obvious. Each node has a “primary” value, associated with an entity. Perhaps it could choose that one, but there would need to be a way to know which entity that is.
I dont think the new integration creates and entity for the device itself. But it could (should?) just like th old ne did with a zwave.entity. That way, it could send that entity_id and I would at least know what the device was named (and if I named it properly, I could use the same logic to get the light/switch entity_id from the device entity_id.
Thx that was it!
I think the original thought was to associate the event to the device instead, but I’m not sure if that’s possible or not. I don’t think the devs are interested in creating a new ozw entity, but who knows.
Nothing until I awoke the device, then the manufacturer (strips) was shown
1 Like
I made an ugly workaround with something like this:
{% for state in states.light %}
{% if state.attributes.node_id == trigger.event.data.node_id and "fibaro" in state.entity_id %}
{{ state.entity_id }}
{% endif %}
{% endfor %}
Not very pretty, but it gets the job done…
I noticed the docker container was being updated and not all updates where as stable as v150. I now use 150. But we are a few weeks further. What versions of the docker do you use that are (more) stable (than 150). Im using home Assistant 0.114.2