Congratulations on your promotion and thank you for all the work you did to help people to get started with home automation.
This is really sad. Reading this thread… it’s the first time since I began with Home Assistant in April 2020 - after adding 75 ZWave devices, with 541 entities, all renamed consistently, 28 well-tested automations and 7 supporting scripts, all working well under zwave 1.4 - that I truly am disillusioned with the project.
I pay Nabu Casa every month to support the core development team and, color me silly, but I would consider ZWave a pretty core component of HA, especially in keeping with HA’s philosophy of keeping things local, unless running wires is your thing. I’ve tried to keep things simple and chose to standardize on ZWave. I don’t use Zigbee, WiFi, or any other transport, nor MQTT, and I even went back to using YAML over NodeRED for automation. So this is pretty important to me and my entire HA installation. I’m hoping now that I didn’t choose the wrong horse.
This fiasco of announcing the ‘release’ of an unfinished product, deprecating the only stable version of zwave available for a majority of users, while continuing to push OZW (beta) when it was basically deemed unworthy of continued effort - hence the one-month development of a replacement - only to suggest yet another community add-on to use as the UI to control all your devices under the “new” solution, um, since it’s not yet finished, has been an eye-opener.
2 Likes
Agreed. But, honestly, I think the safe answer might be just to stick with the current baked-in zwave 1.4. 
You think that’s bad? I’m likely moving back to SmartThings for stability. I’m going to be giving the new Z-WaveJS a shot this weekend but if it doesn’t fix the fundamental issue I and several others are having with OZW, I literally have no choice.
Z-Wave and thus HA is completely unusable for several of us but that wasn’t the real kicker for me, I was the way we were treated for daring to bring up these issues, that’s actually soured the entire HA platform for me worse than the Z-Wave issues to be honest.
I enjoyed helping SmartThings devs were I could, I actively supported SmartThings devs with cold hard cash but the way things went down here, I have been serious put off the whole lot.
Your Post #104 nailed it. For me, without a reliable ZWave solution, HA isn’t an option. I researched the various transport methods prior to starting HA, before buying my first device. Everything I read led me to ZWave as the best solution for range, reliability, and privacy. ALL of my devices are ZWave, so this whole discussion has me pretty frustrated… and worried.
I was being serious in my last post, though. Other than only one or two devices (like my siren that uses the Sound Switch) all of my devices work flawlessly and consistently in the original zwave 1.4 integration. I periodically have to add XML data to the zwave config file from the alliance to get to the parameters when adding new devices, but once you’ve done it, it’s cake.
I can go weeks without a restart, and no issues, no errors. THAT’s why I remain on 1.4 and never tried OZW beta. And why would I want to incorporate MQTT into my system when I don’t need it now? All my battery devices are set to wake every 2 hours, so my entire network has checked in after a reboot in only a couple of hours max. It is fully operational, though, in only a couple of minutes from startup. You might give it another try before heading back to SmartThings.
I’m glad you are doing well and congratulations on your promotion! Thank you for all you’ve done for this community, and for providing some clarity around the uncertainty of what’s been going on. I hate that the environment became so toxic for you, and completely understand your desire to unplug, even if only for a while. We hope that you will choose to come back at some point and we can all remember how to be both civil and thankful for those who provide so much to all of us, selflessly. Take care, and thank you.
Allthough I never made the move to openzwave, I’ve moved to zwave js now, and I don’t see any delays in response there. My actively used ‘actionable’ entity is a Danalock 3 BTZW, it reacts within a second the first time it’s accessed, next action if performed reasonably soon after, is instantaneous, so I beleive the first delay is because it’s in hibernation internally.
Greetings @Fishwaldo
Big congratulations on your promotion! I hope the timezone differences will get easier to cope with, I mean, wow that is a BIG area.
Having had a very small project for over 10 years (compared to this) I completely feel your sentiments. I’ve also had very odd and unreasonable remarks from people around the world. Fortunately others have picked up the torch for me 
Keep up the spirits, and if I were you, I would put my efforts in the Z-Wave JS instead 
Let me say this is not an attempt to flame anyone or enrage anyone. I get the frustration, I was there with the OZW beta but never really said anything. I jumped on the first beta of zwave-js without zwavejs2mqtt. It was a rocky start but honestly even with the hiccups I had, it was much better than OZW. If you can wait a little longer some features like scene control and configuration of devices from within HA are bound to come. It’s been stated as such. The other thing that I’m excited about is firmware upgrades from within HA. The other thing I would consider waiting for is that there is a massive effort of config file imports being done by the node-zwave-js team from various sources that should be completed in the next few weeks. Keep in mind, this is just me saying this and not a guarantee of timelines and is based on what I’ve read. While I’m not you and you have to decide for yourself, so far for me, this is the best zwave integration I’ve had yet in HA (yes, I’ve used them all).
One thing I have to say after thinking about it. I laughed at the node-zwave-js teams comment about being “wicked fast” but to me it really shines at being just that. My devices communicate faster and my lights are almost instantaneous.
1 Like
Just a general question, but it seems like the ZWAVEJS2MQTT addon is quite well developed already with a good UI and configuration ability. What is the need to have another ZWAVEJS addon without the MQTT if the MQTT part can be disabled or not used in the ZwaveJS2MQTT addon?
It seems a bit redundant to have both when 1 is a superset of the other. Maybe I am missing something?
1 Like
I completely agree.
But I think that the devs think that the addition of MQTT might be too confusing to the target (i.e. non-techie) audience. Even if it can be turned off.
Also, the end goal from what I see is to have everything internal to HA’s interface and not another bolt-on solution with another interface to learn.
So is the end goal to not need to use an add-on at all (or any other external docker/server)?
No, the server is always needed. The endgoal is for users to perform all actions in HA. The integration will silently install the addon and use it. Then everything will else will be handled in the UI under the zwave_js integration.
Ok, so the add-on will allow the HA UI to control the zwave js server.
An add-on is a bolted on solution external to HA.
That was the point of the question.
What if people don’t use the add-on? as in the people who aren’t running a supervised flavor of HA and don’t have access to the add-on?
I haven’t really heard about any progress to make a stand-alone (non-add-on) version (in docker or whatever) of the server that doesn’t also include the ui & mqtt that zwavejs2mqtt already offers.
At that point we have competing UI’s? or will non-supervised HA users not be able to use the built-in UI because we don’t use the add-on?
I just don’t know how tightly integrated the UI will be with the add-on only.
You just answer no to the first question when installing the integration. Which is something like “Use Zwave JS addon”
It already exists:
If you use ZwaveJS2MQTT, both interfaces will work.
EDIT: Take a look at the overview and the flow charts I made. Maybe it’ll help you understand better:
I saw that but it wants you to install the server directly on the host.
I never install anything on the host unless I absolutely have to.
Containers are definitely the way to go.
So I guess I’ll just keep using that one then. Good to know so I don’t wait on a tentative stand-alone container sans mqtt & UI that might never come.
That’s funny. Those are pretty much a an exact graphical representation of the post where I respond to marius yesterday in text flow chart form.
definitely prettier than mine. 
I believe the goto docker container is ZwaveJS2MQTT, I don’t think there is any plans to make a replication of the ZwaveJS addon. But you never know, anything is possible. Hell, it may even exist already and I don’t know about it.
Too many people kept asking the same question, it was driving me bonkers!
3 Likes
That is utterly perfect, it finally helps me understand the whole system better and how it all bolts together, along with how each different integration path works, just perfect because I was now confused with which path to take with regards to ZWaveJS or ZWaveJSMQTT but it seems since the latter can work both ways, that’s the most sensible option.
So I’m going to try a migration of my current install first and if that doesn’t work I’ll do a fresh install starting from scratch and if Z-Wave still isn’t stable at that point, I’ll have to go back entirely to SmartThings.
1 Like