CON: A fully automatic migration of legacy/current ZWave in HA to this new implementation will be hard if not impossible because of the fact that the internals are handled.
In that respect I was wondering whether one of the existing solutions to have z-wave in Home assistant could have an advantage over any of the others in terms of migration path to such a future Zwave JS integration?
I assume zwavejs2mttq doesnāt hold an advantage over for example the existing native integration or z-wave2mttq or qt-openzwave, because despite it being based on zwavejs, it relies on MTTQ as communication layer?
In that respect I was wondering whether one of the existing solutions to have z-wave in Home assistant could have an advantage over any of the others in terms of migration path to such a future Zwave JS integration?
I assume zwavejs2mttq doesnāt hold an advantage over for example the existing native integration or z-wave2mttq or qt-openzwave, because despite it being based on zwavejs, it relies on MTTQ as communication layer?
If weāre able to write a migration it would only be for the existing Z-Wave integrations in core (zwave/ozw), it would be up to the larger community to contribute a possible migration path for zwave2mqtt/zwavejs2mqtt as theyāve never had an actual core integration.
That said, at this time I wouldnāt hold my breath for a migration toolā¦ though that could change.
Thank you, so I deduct that people who are looking at starting to use Home Assistant are best advised to use the current (albeit outdated) native z-wave integration because at least the steps to migrate ā even if likely not (fully) automatic ā will be described for that migration path.
Out of curiosity, what is the difficulty with a tool that does at least automatic naming of entities? Iāve done this somewhat in the past using python to load core_devices, matching the node to a device id, then going to core_entities, matching the device id to entities, then opening the new ones and applying those same friendly names based on the node/device id and writing out the core_device/core_entity. Obviously that breaks down where zwavejs2mqtt provides more/less entities or different kinds of entities than zwave/ozw provided. Is it just matching up the right entity to the right sensor where multiple are provided, as an example?
Iām not challenging that it is possible, Iām genuinely curious in where the difficulty lies.
To be fair he didnāt state it was impossible, I believe heās referring to a migration tool to go from zwave2mqtt/zwavejs2mqtt -> the new zwave system.
This is also the same thing that Iām wondering about. Iāve been watching this issue request for a while and havenāt seen any movement on it. Iād like to know if this project will be using the migrated OZW config files as that will greatly increase support with my devices. Iām worried that starting over from scratch in regards to device configuration will take this project a lot longer to attain the same level of support.
Presently they are using the current openHAB device files, but they are setup to import the ozw 1.6 device configuration files as well. So far the current directory seems as complete or more complete than the ozw one. I think only one of mine was missing and there were a few that were only recently added to qt-ozw.
It is. They were trying to be polite but at the end of the day it is an LGPL license. The project has a fairly complete set of device files as it is so I donāt think it has been a pressing issue. The maintainer asked me to ask him to respond to the issue in the vent he was still following the thread.
There have to be more people like me that have the right skillset but donāt have the time to help. Iāve got dev projects that Iāve been working on for years that are still in progress. Iāve been meaning to write what should be a simple integration for my solar inverters for the last year that I havenāt even started on yet. I have more money than time so I pay for a subscription even though I donāt really need it.
Z-wave should be considered important enough to be handled by paid devs. Iāll pay more than $5/mo. Maybe others will too. Consider adding a āsupport our developmentā package or something. Berating people for not contributing code or having time to contribute code doesnāt help either. Single maintainer projects often start out strong, but as time goes on selfish end users kick you down, life happens, and development slows or stops. Sending money or donations to an individual dev is a nice gesture of appreciation, but if the sole dev has a full time job elsewhere needed to pay the bills itās just that, a gesture.
Indeed. Contributing to a code base like OZW is a serious time investment, especially the upfront costs. Iām a developer myself, a C++ developer at that. I did take a detailed look at the OZW code. And honestly, my first instinctive reaction was - no way in hell Iām getting involved in that. Not because it wouldnāt be interesting, it certainly would. And fishwaldo has certainly done a great job developing all that on his own. But I do this stuff all day at work, when I get home Iād rather pursue my own pet projects.
Getting up to speed with a legacy code base with parts that date back almost a decade and that was never designed in a way to facilitate team development (documentation !) is really hard. Add to that learning the inside outās of the low level ZWave protocol. And on top of that all, a much more modern implementation of the ZWave stack already exists elsewhere (zwave-js), so contributing to OZW feels like youāre needlessly duplicating efforts.
Thatās a general problem with open source and not limited to OZW though. It starts as a pet project done for your own personal use, it grows, progressively becomes unmaintainable and feels more like an unpaid job than a hobby - and then you (understandably) lose interest.
It sounds like we are in very similar situations. I couldnāt agree any more fully with nearly every single point youāve made. I will put my money where my mouth is, I just want Z-Wave to work.
100%. The use of QT is a bit odd and is a heavy dependency for what it is doing. I have dug into the code base but itās not very clear on how to get started. Even setting up a dev environment is non-trivial.
Yeah QT and C++ are, how should I say, less weekend project friendly. I did use QT for my senior project in school back in '05, but that was the last time Iāve touched it.
I āfixedā it by running a separate mqtt server for the ozw container. Linked both mqtt containers to each other. Now my ozw and 2nd mqtt server are on the same machine/ip. I didnt use the addon for ozw.
I saw this solution as a post somewhere on the forum. This works stable for weeks. While before the change i was loosing my devices every few days. It looks like ozw crashes when there is a glitch in the communication between ozw and mqtt.
I dont expect a fix soon. Since the developer of ozw unfortunately isnāt very active anymore.
Can someone please enlighten me as to why all this is actually necessary? My Z-Wave setup has been working perfectly for years using the default inbuilt HA Integration. What am I missing here?
Maybe because you only have devices which donāt have issues with OpenZwave 1.4
For instance, Iām pretty sure you donāt have Fibaro FGR-223 āRoller Shutter 3ā. I have 17 of them and I have to use ugly workarounds to get them almost work normally. After each of them report a change of its power consumption back to 0W, I have to poll them twice for their global status in order to get their actual position. It works 95% of the time.
But Iāve made my decision 3 weeks ago. Iāve bought a small Fibaro HC Light box for 100ā¬. I will use it as my ZWave gateway instead of my ZWave USB stick plugged on HA, at least for a while.
Fibaro ZWave implementation works perfectly out of the box with the 5 different kinds of ZWave modules that Iāve tested and it does not take 10 minutes to load each time I restart Home Assistant (which I do a lot these days).
HA Fibaro integration looks to work great.
