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
150 is the most stable at this time. Later builds include changes related to refreshing dimmer level values which are not working properly.
1 Like
There was a discussion of this back in the spring where the conclusion seemed to be that they needed to add back the concept of device. The scene messages are actually a function of the device that generates them whereas the current system only generates the entities for the thing that is doing the controlling. This results in you having to track down the nodeid so that you match in a trigger on the scene being invoked (e.g., double tap). Iāve been away from the house that has zwave since then so havenāt been playing with the integration beta but it is definitely something that needs fixing - the non-expert user needs to easily be able to define a trigger based on a switch sending a particular scene command rather than having to figure out the nodeid associated with the (possibly irrelevant to the operation) switch or light entity that the switch primarily controls.
1 Like
Iām running OZW daemon separate from my HA installation so I can visualize HA. I have everything updated to the latest on the HA side but still canāt use Z-wave dimmers properly with OZW. Is this something that needs to be updated on the OZW side or just the HA side? I read some posts but donāt seem to be getting anywhere.
There was a ozw code change in versions higher than build 150 that changed the way dimmers worked. If you are having problems try swapping to build-150 instead of latest for your docker iamge.
Damn, tried the 150 build and itās still doing the same. For the most part itās more of an annoyance. I just wish I could continue to have my theater light dimmer turn on to a certain level when the PIR is activated.
With 150 dimming works fine here. I use Fibaro and qubino dimmers.
Can anyone provide an example of how to call the new ozw.set_config_parameter correctly?
For example, on the Inovelli switches there exist a valueIDKey which configures the LED color. In the MQTT tree there exists the command_class, valueIDKey, and the index value, but none of them work in setting the value.
The documentation calls for the node_id, parameter, and the value in which to set. The main question is what is the parameter supposed to identify??
Itās the same as zwave.set_config_parameter:
| Parameter | Description | Example |
|---|---|---|
| node_id | Node id of the device to set config parameter to (integer). | 10 |
| parameter | Parameter number to set (integer). | 8 |
| value | Value to set for parameter. (String value for list and bool parameters, integer for others). | 50268673 |
| instance_id | (Optional) The OZW Instance/Controller to use, defaults to 1. |
The parameter is referring to the index value if youāre looking at MQTT. For Inovelli on/off switches parameter 8 is the LED Notifications, 5&6 are the regular LED Color & Brightness.
See this amazing tool for help with setting your colors/notifications.
1 Like
Thanks for the confirmation. Looks like I am using the right syntax and parameter. The Red series dimmer switch uses parameter 13 to set the color:
This command yields no change in the color.
Donāt forget to set parm 14 for the brightness as well.
The LED is currently visible at the default color (170) with the switch on.
Or did you mean something else?
Does the LED color parameter exist in MQTT?
Type Short cannot be set in 0.114 or earlier. It is fixed in 0.115 or a current developer build.
It should be settable using ozw-admin.
2 Likes
Ah, so the data type was blocking me. Good to know, thanks