I donât know if this problem will be solved ot not, or if it is already in OpenZwave 1.6 or not. And whenâŠ
Thatâs one of the reason of my move to use Fibaro box as my ZWave gateway. It just works. And it confirm that it is a ZWave controler issue, and not an issue of the module itself.
The second reason is that my Zwave network become independant of HA, and especially independant of HA restart. My Zwave network is not big (35 devices) and very fast (all nodes have only 1 or 2 jumps to get to the ZWave controller) but when I restart HA it usually takes longggg minutes to be ready.
The third reason is that it will be way more easy to handle HA VM redundancy in case of failure. Currently my ZWave controller is an Aeotec Gen5 USB stick. I duplicate it on another one. So I have a ZWave controller plugged in on both my proxmox servers. When my proxmox VM switch from one server to another, my ZWave network can switch. With an external ZWave gateway this will be much easier.
Working with manual workarounds is not clean. I have 17 of them and it takes a complete Node Red flow just to manage this bug.
Plus, it does not work if I set a small movement and that power consumption does not have time to change from 0 to something else and back to 0.
So I had to add another workaround and to poll their status every 15 minutes, juste to be sure.
There is also another issue identified when the stop function is used on one of the roller shutters. The ZWave network sometimes becomes very slow.
It may works OK for you, I undesrtand, but I donât consider that my ZWave network is fine for the moment. It has not been since I have added all these FGR-223.
I also use the old builtin integration at this time and it works fine. The main issue is really new devices that use features and command classes that arenât supported by OZW 1.4 (and some neither by 1.6). Things like the newer Sirens (Aeotec Siren 6) or Fibaros smart implant come to mind. Thereâs also issues with many dimmers. Some devices can be made partially functional by manually editing the config files, but some canât or need complicated work arounds.
Other important missing features are multicast support (if you want to control multiple lights at once without delays) and S2 support. None of those are supported by OZW 1.6 either, but it seems like zwave-js supports multicast and is actively working on S2.
The infamous âdeepsleep 254 issueâ with devices like motion and door sensors is also a pain in the rear to manage reliably. I originally was under the impression that this was a limitation of the zwave protocol until later on I realized that it is not. Itâs a bug in OpenZWave.
Thanks for providing an actual reason why there is a look to change from the current in-built z-wave as apposed to just saying âmine doesnât work properlyâ.
This entire post was predicated on the fact that a bunch of people are having massive issues with the current official path for Z-Wave integration, not only that the fact that the path chosen has the highest risk factor with regards to depending on a single person and being developed in languages that very few people write in anymore, hence why no one was volunteering to help.
A bunch of people saying âmine doesnât work properlyâ with increasing volume is an âactual reasonâ. Just saying âmine works perfectlyâ, isnât.
Interesting. At the moment Iâm interfacing my zwave devices on my old home automation system with home Assistant using mqtt. I used the mosquito add-on but had to restart it every couple of days because it stopped receiving all messages. Now Iâve installed mosquito on my Synology NAS and it is running 100% stable. Perhaps the issue is then with the mosquito add-on and not OZW
Coming from Hubitat and SmartThings its very clear between the native Z-Wave and the Beta Add-OnâŠ
Home Assistant is way off the mark.
I mean that lovingly and I think this thread has come a long way in everybody taking a step back and realizing that there are a good amount of people coming over from SmartThings, Hubitat and other mostly Z-Wave hubs that have a ton of devices.
I have about 17 and Open Z-Wave beta is verrrrry slow.
My friend experiences the same lag with only a 2-3 dimmers and a much more powerful setup.
The lock support is better than native for sure but user management is not really functioning from what I can see.
I think the answer is there are a bunch of reasons and Z-Wave wasnât getting the love a lot of users felt it deserved. All respect to @Fishwaldo , I have a job that gets extremely demanding too, so I completely understand why things get put on the shelf when theyâre being done for essentially free.
I think the decision to find something more sustainable and maintained or HA needs to hire somebody full time to knock the dust off the shelves is needed to stay viable for people looking to move over.
Weâll see what happens with the first option for now, is what Iâm gathering.
I wasnât saying that mine working meant everything is fine either. I was asking for the root cause of issues. Saying âitâs brokenâ explains nothing.
I have been considering changing z-wave integration for a while as I was under the impression it was going to essentially be the only way forward.
I think what is needed is a proper review of the proâs / conâs of each z-wave integration method in a formal way that allows the devs to know which one to use for core HA.
Did you purchase the Home Center 2 or Home Center Lite? I assume itâs Lite since you said âLightâ but wanted to verify.
Iâm curious as to this because the one major complaint I have is that Z-Wave takes forever to load and is extremely slow using the built-in Z-Wave integration. Otherwise I havenât had any actual problems getting my 125 or so Z-Wave devices to work in HA, but the time to fire off a scene of even five or six devices is a bit painful.
I wonder if using the Vera for all Z-Wave would be equally as much of an upgrade. I actually have a spare here because I considered moving over to Vera completely before I went the HA route.
I would advise not to use this box for 125 devices however. It works perfect for me so far, but I think Iâve read somewhere that it is designed to handle like 25 or 30 devices, not much more.
@Balloob@Frenck & @Fishwaldo yâall are awesome and my HA + OpenZWave works amazingly. It brings me joy every single day. Thank you for all the work that you do.
I have exactly 2 Z-Wave devices (2 Inovelli NZW31 Dimmers paired to a Aeotec ZW090 Z-Stick Gen5).
With the native ZWave integration things work fine and lights turn on reasonably fast (100-750ms from being told to do so). Not as fast as any of my WiFi devices, but âfast enoughâ.
With the OpenZWave addon & integration, the same 2 lights take between 1-10 seconds to turn on after being commanded to (typically 2-3s). The delay is seemingly random, but sometimes itâs long enough for me to walk across the room and manually turn them on.
Whatâs the root cause? I have no idea. I never unpaired them from my Aeotec stick. Just moved integrations. HA is running as HAOS in a VM of a very powerful server, so itâs not a resource issue. Thereâs no logs that indicate any sort of problem either.
Itâs just one of those things that, for me, is impossible to define a root cause of the issue; All I know is itâs unacceptably slow and the built-in integration works much better.
It may work âmuch betterâ, but even that built-in performance is slower than I think is normal. Whatever the root cause is, I suspect it is affecting both integrations.
I have to say that I am not seeing any delays in my QT OpenZwave network of 30 devices. Turning lights on and off has no perceptible delay at all here.
I have the same hardware and no issues. How did you integrate the addon? Are you using an MQTT broker as an in between?
That might be the root cause, OZW holds configurations, if you didnât refresh the nodes when inside the new container, it doesnât store device specific info about the devices.
Did you ever ask this question on the zwave channel in discord or on the forums?
EDIT: For what itâs worth a migration tool is being built and would have solved these types of issues. But for the most part, migrating from the built in to the addon is not a simple feat. You basically need to refresh every node after startup or exclude/reinclude to populate the ozw_xxxx.cfg file with the right information.
And itâs looking like Zwave JS may have to do the same thing when itâs complete. We need more dumps though. Hopefully in the coming weeks we will have a container for Zwave JS and people can provide zwave configuration dumps so that we can properly answer that question.
This is my only real gripe about the native Z-Wave integration is that it is slow compared to my last system that was easily 5x faster than this. I was used to nearly instant response and was dismayed at waiting so long in HA. I know some of that (maybe most of it) has to do with the fact that the current implementations of Z-Wave donât multicast, but Iâm looking forward to the new Z-Wave JS that supposedly has multicast.
Iâm not looking forward to switching my HA to any new platform because with so many devices it is going to take forever to migrate. If it was just the devices, great, but itâs not, its also all the scripts, automations and the like that will be a pain.
One thing my last system did wonderfully is account for migrations or replacing equipment, it would let you instantly change all your various related items over if you replaced a device. I realize that so long as I name the new device the exact same entity id that some of this would be resolved, but that means I have to rename all the âdead devicesâ first.
