OZW Author here - Just to add my piece:
I think the biggest advantage here is like has already been pointed out - The OZW side will be maintained by myself, and this interface is being used by the “new” ozwcp replacement, so I’d expect it to stay updated with the main library.
One of the other challenges with the zwave2mqtt project and HA, is that it has to “map” Z-Wave to the format that HA uses for discovery etc, which has some constraints.
the qt-openzwave and HA integration are “native” to Z-Wave, meaning the full power of OZW is available, as long as the HA integration supports it. There should be no artificial constraints or limits imposed. Only code is needed. Will the new integration support “everything” - Probably not to start with, but the core functionality will be there.
As far as zwave2mqtt, the work there is excellent though, and I think its a plus for users that they have a option between zwave2mqtt and the new qt-openzwave/HA integration (we will find a better name soon on the OZW side!). Both will have advantages/disadvantages so the user is given some freedom to choose.
The other “gain” for users (as already pointed out) is that users wanting to perform advanced functionality on their z-wave network (that HA might not support directly) can fire up the ozw-admin tool and make the changes without having to restart or shutdown the Z-Wave Network. (it allows multiple applications to talk to the Z-Wave network concurrently)
As far as migrations from the existing python integration - We spoke briefly about it. I think a portion can be migrated to the new integration, but there are several changes to OZW in 1.6 (in keeping up to date with the Z-Wave Spec) that have meant the way some CommandClasses or Devices work are changed. Off the top of my head the changes are around Notification CC (Renamed from Alarm CC), UserCode CC, and SensorMultiLevel CC. Unfortunately these are some of the most “used” command classes in Z-Wave Devices, so might mean some “manual” work to migrate to the new integration just due to the way we work with these devices.
(the upside to this - It should give you a lot more “insight” into what is going on with devices etc - which hopefully means easier or more powerful automatons are possible)
Thanks for words from the horses mouth. It brings us better clarity.
You mention that there’s likely to be advantages / disadvantages to both implementations.
Where can we bone up on this to help us decide ?
Given what you said about feature implementation, do you think that they will proceed somewhat evenly or will one be in advance of the other (from what you said I infer that mqtt ‘might’ be (initially at least) better supported) ?
My bias would be qt-openzwave, I think, but will hear arguments
Hi Fishwaldo. Great initiative for supporting the HA community. This will be a win win for both open zwave and HA. Any idea on the timeline for this to happen.
Really excited for this! Will this improve the UI responsiveness for dimmers? Right now, Lovelace doesn’t show the correct state when you turn on/off a dimmer. I haven’t found a reliable workaround yet.
Yes it all depends on how it’s implemented. The devs can do it in a way where it requires zero changes for users or in a way which requires a ton of changes for users… We will see which one they choose.
The goal is to implement the new z-wave component in a way that requires relatively few modifications for users of the stock zwave component, but there’s no plans to add a migration path for those using zwave2mqtt.
The challenge is up until recently the zwave specifications were not clear in how to report the “value” of a dimmer when its transitioning. Some vendors would send the “final” value (and GUI’s would “work”) while others send the “instant” value. (Which could be some value between the start value and end value). It’s these second group that cause this issue.
No clue on timing, but yes I’m planning to have beta pre-releases available as a custom component through HACS. Standard “may break everything” disclaimer will apply
@cgarwood - I have the Docker container running and added your early code to my environment; but i am failing to activate the component, can you share some basic configuration steps?
Thanks
Damian
MQTT will need set up in Home Assistant & then add the zwave mqtt component from the Integrations page. Should just work after that (or spit some errors out into the logs)
Sorry - I should have updated this thread - i figure out my silliness a week back. I have the container and integrations running SOLID for a week, updated to the newest integration during the week, and i can turn on and off power sockets, and get some climate related data in.
this is already more stable than the alternatives! - I am looking forward to the climate platform support
In the migration, would the entity_ids from the old zwave integration be able to transfer to the new one? I have around 40 zwave devices and having to manually delete the entity_ids from the entity registry from the old integration and then rename the new ones to match the old would be a very painstaking process.
Just watching this as I also want to know if we will need to reset and repair all Z-Wave devices to use the new integration.
Also, how does the new integration handle security enabled devices?
I understand it is currently in a testing state and not complete.
Thanks
The security key is specified by config in OpenZWave or random generated by HA. Are you sure the security key is on the stick /zwave controller?
I know paired devices are on the stick, but I thought OZW stored the security key elsewhere.
