It looks like HA 0.110 mentions a release of a new openZWave Beta integration:
Does anyone know how/if this changes the install procedure for openZWave for HA and Inovelli equipment?
Thanks!
It looks like HA 0.110 mentions a release of a new openZWave Beta integration:
Does anyone know how/if this changes the install procedure for openZWave for HA and Inovelli equipment?
Thanks!
In theory, since the OZW beta leverages 1.6 instead of 1.4, everything would just “work.” The whole reason we have to go through the customized xml files is because 1.4 is no longer maintained, so anything new since the cut-off date is not implemented. I haven’t made the change, and probably will wait until they have a migration process set up to save myself the work of rebuilding the network and all my automatons.
@jtronicus uses OpenZWave2MQTT which also leverages 1.6 so I suspect he’d have more insight.
Thanks! I am worried about the upgrade as well. I have been holding off going to 110 because I am not sure how the existing custom config files will act.
Would love to hear if someone has already running switches/bulbs and has move to 110 already.
(I might just do it with a backup file later… who knows. )
Ah, to clarify, 0.110 doesn’t actually affect your z-wave system, so you can make that upgrade now. It makes the OZW Beta available as an add-on instead of having to get the custom component route to add the beta. I am already running 0.110 but haven’t transitioned to OZW Beta.
Oh, great! Good to know, thank you!
Just FYI - I have been running the beta of the new Zwave integration with one Inovelli in my configuration (rest are older existing Homeseer switches and dimmers). For the most part it is fine. With the new integration the zwave side of things doesn’t restart if you restart HA which is really nice since restarting the zwave net can take a while. Not all device classes are in it yet so check that before you switch. The biggest issue I have seen is that dimmers are a problem for recognizing their new state because the new integration doesn’t support a refresh value. It is supposed to handle this correctly instead by using the target value of a device rather than its instantaneous state but there seems to be a bug in the OZW side that doesn’t provide this correctly all the time. I haven’t seen any indication that the OZW side is seriously looking into that yet. In the meantime a work around is to reissue the turn on after a second or two to pick up the change. Not really perfect but I’ve done it where scripts have needed it. One nice side benefit is that you can see all the zwave command traffic by watching the MQTT stream and can issue commands from MQTT as well if you need to.
Interesting - great to know! I think I might wait before I switch over for a little while. I have 13 dimmers and don’t really want to run in to a dimming bug.
@kevink From what you have seen, is anyone in the community looking at OTA firmware updates for OpenZwave or HA?
I haven’t seen any on OTA updates. I’d guess it would be pretty low on the priority list given that it isn’t a common operation.
I’m running the OpenZWave (beta) as well. At this point there’s a lot to come but if you’re handy with mqtt, most can already be used. There is also an additional desktop application available called ozw-admin. ozw-admin is not required for Home Assistant but it is extremely helpful for setting some config parameters to your device and figuring out the ValueIDKey
which can be used over mqtt from Home Assistant
For example this test automation that will change the status light on my LZW31-SN
to red when I press the config button 1x
automation:
- alias: 'LZW31-SN Scene Test'
trigger:
- event_type: ozw.scene_activated
platform: event
event_data:
node_id: 2
scene_id: 3
scene_value_id: 1
action:
- service: mqtt.publish
data:
qos: 1
retain: false
topic: OpenZWave/1/command/setvalue/
payload: >-
{
"ValueIDKey": 3659174741016598,
"Value": 1
}
I hope another helpful example of using mqtt directly can be shown to associate an Ilumin bulb with the Red Series Dimmer switch – Using Home Assistant > Developer Tools > MQTT
node:
- 2
is the node_id
of the dimmer switch
target:
- 14
is the node id
of the Ilumin bulb
As shown here - I did this for each group 2
3
and 4
Topic - OpenZWave/1/command/addassociation/
payload
{
"node": 2,
"group": 2,
"target": "14"
}
So far it seems I do not need to refresh_value
for any of my Red Series Dimmers or Ilumin bulbs.
I have this problem with older dimmer bulbs from another brand. I’m using an automation to simulate the missing refresh value. (The ValueIDKey
would be unique to your deice )
automation:
- alias: 'refresh closet level'
trigger:
platform: state
entity_id: light.toy_room_closet_level
action:
- delay: 2
- service: mqtt.publish
data:
topic: OpenZWave/1/command/refreshvalue/
payload: >-
{
"ValueIDKey": 139034641
}
Issuing the refresh also works. It isn’t really any different in effect from reissuing the original command. I do the latter but either should work. You just need to make sure you put in a bit of a delay. The annoying thing is that you need such an automation for any place such a dimmer gets set, and I don’t think there is a way to trigger on any dimmer state getting the entity id back as a parameter so that a single automation could work for any dimmer that needs it. As I said, OZW is supposed to support a target value and I had a long interaction with the HA guys and Justin a while back including some pretty detailed debug analysis about this having issues. I hope at some point it gets looked at.
Thought this might come in handy for others. After a ton of fiddling around with scene support on my own/Googling over the past week, I finally managed to get it working using the OpenZWave (beta) integration within node red. I don’t take credit for the beginning work, but using the node someone created for use with the native zwave support via node red, I’ve updated it to now work with the new scene data. I unfortunately forgot who the original creator of the node was/where it was posted, but credit is due to them.
The above node needs to follow an “events: all” node, set it to listen to event type “ozw.scene_activated”. From there, link it to a switch node, set it to listen for property msg.payload.event.node_id and list your switch node ID. Example is as follows:
If you hover over the gray dots at the end, you’ll get a description of what all they correspond to. 1 tap down, 2 taps down, etc. Then just build out your automation as you normally would.
Nice! Thanks for the info! Great to see that node works with the ozw drivers!