First of all - I am very happy with my setup (C8 Pro + C7 + HA). And I am very happy with near 100% Local Controls (still have 1 cloud-based Withing Pad intergation, 2 pads are used as a Bed Presense Sensors).
And of course, adding extra features is very wellcome but this must/should not be done in expence for system performance degradation. Over time I am notithing gradual permormance degradation in many places. And this observation is done on the today's most powerfull C8 Pro Hub. For examplee: GUI becomes less responsive, more random delays in RM Rules, etc.
Unfortunately (at least in my case) switching to the ZWaveJS immidietly introduces a disaster. RM Rules delays becomes enormous and random. I think this is due to compromized ZWave Devices responsivness.
Suggestion and advice for the HE developers:
PLEASE PAY MORE ATTENTION TO THE HUB STABILITY
This should/must be a Number-1 priority.
And please keep in mind - Hardware Resource is not infinit, it does have a limit. After reaching certain threshold performance may drop down significanly.
(I am EE with huge experience in the embedded system design, I know what I am talking about.)
To be fair, can you be sure that your issues, ZWaveJS aside, are down to either the introduction of new features or a lack of attention to detail by the Hubitat development team? To me it feels like it would be worthwhile looking more closely at where your issues are coming from, then reflecting on the outcome.
Happy to be proven wrong, but I feel that blanket statement like that feels a little disingenuous, at least without pointing to any prior topics. I can understand it may feel like the recent expansion of features have included some "hefty", network intensive additions, but I do feel these are being made still with a strong focus on their impact, if any, on hub performance.
I would add that it can be difficult to assess the likely performance for everyone's setup, particularly given the vast array of devices available and permutations of those being used together in each system, not to mention external factors of networks and alike. Participating in the beta program can be one possible option, but I can understand that would not work for everyone.
I'm not going to claim any expertise in this space, I'll leave that to others, but I do feel we should be offering up examples in situations like this.
ZWaveJS clearly creates a lot of instability. I tryed to switch to the ZWaveJS many times (basically after every new release which claimed a significant chage to the ZWaveJS) and (unfortunately) always noticed a lot of problems (Random Delays, missing Commands and Status Reporting, etc.).
Otherwise my system is near 100% reliable and stable. Once in while something is failing for many different reasons. But my system is very complex and ocasional random failures are accepted. BTW, my setup does not need periodic reboots for cleaning low memory or whatever else. It runs flawlesly for many days and reboot happens only when new update is applied.
My comments about overal system degradation is based on the 5+ years observation (yes, hubs were differen) plus my huge experience in the embedded system design. Yes, every setup is very differen. My could be the most complicated. It is a combination of C7 + C8 Pro + HA hubs and huge number of ZWave, Zigbee, BT, WiFi Devices including number of DIY WiFi Hubduino Devices. So, my setup could be very sensitive to all that added features and capabilities. But my point is/was - hw resource has a limit. After reaching certain threshold system simply may fall appart. Something like at some point cup becomes completely full and cannot take any extra drop of water. Unfortunately I saw cases like this in my practice.
Because my system handles many automations (everything is hands free, driven by sensors) I cannot use it for beta testing. But i can provide any details of my setup (if this will have any value). Also I am not planing and have no desire to do some sort of performance bench marking. But I do trust my observations and experience.
As far as Zwave JS goes it should be noted your experience may not line up with everyone.
I have 56 zwave devices and have had no issues with ZwaveJS. I did have to exclude and include a few devices when it was first released and I switched over. But since then it has been great.
I have also noticed that most posts like this are because of bad habits by the user. That said your description of your usage is very complex and you are right the resources are limited. Being someone that has worked in technology and for a time in sales of said technology this seems like the age old issue of use outgrowing hardware. Ofcourse if we don't change anything it will run the same forever, but nothing stays static wheter it is the development by hubitat or our usage.
I got suprised recently by HA demanding more memory. Its VM has been running fine on 2GB of ram. Recently i had to bump it to 4 because it wouldn't run. Everything is susceptible to this trend
That's a bold statement. Perhaps you perceive ZWaveJS creates a lot of instability on your use case. I switched one of my hubs to ZWaveJS and it helped resolve a problem with Ghost devices I couldn't resolve with Zip gateway. That's not to say you aren't having problems but to project them to all other users is unfair and in my case, untrue.
Given the EOL status of Zip gateway what would you have Hubitat do? Ignore the reality and just use Zip gateway into the future knowing full well that each day that passes it becomes more out of date? Not a strong suggestion is it?
I doubt the folks at Hubitat went around asking to have to change out the ZWave subsystem but Silicon Labs forced their hand. I am sure the way Hubitat has allowed the system to switch back and forth between ZWave subsystems added complexity to the design in, but they did it anyway. So from what I can see Hubitat has done a great job moving us forward.
With three to five firmware releases a week you can't say Hubitat is sleeping on known problems. The prior hub I was on put out one release every 5-7 months.
..."*The Z/IP gateway is a free reference design intended for development and demonstration purposes only. It is provided as is, with no warranties.....
Z/IP Gateway from Silicon Labs is in maintenance mode and is no longer the recommended solution for new Z-Wave gateway development. While older versions have release notes available, they no longer support the latest protocol features. "...
Yes, this absolutely true statement.
I am simply shearing my not very pleasant experience with the ZWaveJS. I have no idea how mny users have a problem with ZWaveJS but unfortunately I am not alone. I know, many usears are very happy with the ZWaveJS. So what? Beeing experienced EE I could close my eyes on a single random failure. But as soon failure was reported more than once it always was a trigger for deep investigation on what is going on. Yes, hunting for a random problems is very time consuming and takes a lot of effort. But sure, in many cases it was a real problem very well hidden in a forest. My setup could be a very unique and speciffic case but, YES switching to the ZWaveJS defininitely introduces a lot of problems. It is upto developers to ignore messages like this or pay attention (I hope this is a case).
And what these bad habits are? I would like to heare few examples, please.
And waht was the reason for this effort?
Maybe I am missing something and REALLY will be happy to fix a potential problem(s).
But with Legacy ZIP the ZWave Mesh seems to be happy. However it could be a whatever masked problem and sure, will be happy to fix it ASAP.
This is a perfect example but I am not surprised. Starting embedded system design back in mid 80th I always silently bumped up a sw demand for cpu speed and memory size. And gues what? Very soon the sw was screaming about not enogh memory and slow cpu speed. Absolutely nothing new in this area.
First of all - I am not projecting my problems with ZWaveJS to entire HE comunity. My apology if this fills like this. However I am not a single user who have a problem with ZWaveJS (I have no idea how many users facing about the same problem).
This is reason why I am trying to switch to the ZWaveJS. Unfortunately so far all attempts was not successful.
I'm fairly certain staff would feel insulted by you implying that hub stability isn't a priority. Perhaps it's just how you feel you need to air your grievances. Setting a narrative that the company doesn't care. I think you need to re-evaluate how you approach your issues.
I wasn't trying to deny your experience, just pointing out many more may be having a good experience. You dont normally hear from folks that haven't had issues.
The one that stands out to me the most is when people create rules in RM to do a task every lets say 10 seconds. When within the rule the execution is based on a status change. You do that so many times and yes you will have performance issues.
I had a couple devices that simply refused to complete the re-interview process that is required during the switch to ZwaveJS. So i had to for it. Then i had about 5 devices that were battery powered that never came online. They were all Zen34 Remote switches. Thise i excluded abd repaired and have worked fine since.
Not sure of your point. If you agreed with my comment then you agree as time passes and things are upgraded improved you will like out grow hardware.
Maybe this is language/culture related issue but your interpretation is 180 degree oposite from what my intention was. Once again, I am sorry if my message is/was not 100% clear.
1000+% correct statemnet.
All my rules are triggered by device status change. I am not using any periodic triggers. However few rules have a WHILE loops with about 1 sec repetition. This is a work around for the devices which are not reporting a correct status. And BTW, this work around was introduced in a few critical rules to "fix" a non-responcive device issue, introduced by ZWaveJS. One of this Device is a Ultraloq Zwave Lock. This one is a first to fail with ZWaveJS.
Always after attemting to switch to the ZWaveJS I have few devices with no route. But surpisingly they are still working just fine. I tried to exclude/re-include one but the result was exatly the same. I.e Device is working just fine but on the ZWave Page has no route. I have no idea what does it mean if anything.
I do have few Zen34 but these seems to be happy regardles which Zwave Stack is used.
My point is - SW is always underestimate the demand for HW. These days thing are much better but still sonner or later become a case. This is kind of normal evolving process.
I have also wondered if bad data in thr Zwave Radio DB is causing some folks problems. I ended up clearing the zwave radio and pairing every zwave device again after a issue with a hub migration.
Maybe that helped in my case though i don't think that should be needed.
This is an excellent point! I keep forgeting about potential problem could be burried inside bad Zwave Radio DB. Unfortunately I cannot go throug the same process (i.e excluding and re-including every Zwave Device). But I wonder if I buy a brand new C8 Pro hub just for clearing potential bad Zwave Radio DB and migrate my current C8 Pro to a new one will it clear a Zwave Radio DB or all garbage will be simply transfered to a new hub? (@bobbyD)
Migrating isn't magic -- it's just going to restore the same database you backed up. If you have problems related to that database, they will follow you to any controller. (Of course, just because you have some problem doesn't mean it's this problem.)
Somehow Backup/Restore for the Hub DB clears all bad DB related problems. I was wondering if the same magic will work for the bad Zwave Radio DB. Unfortunately this is not a case according to your message.
And this is a BIG question. How am I suppose to know if Zwave Radio DB has a problem?
Somehow everything is working just fine with ZIP and immediely becomes problematic as soon as I am attempting to switch to the ZWaveJS. I went through this switching proces number of times (3-4 times) and the result always was the same. This was very clear "one variable at a time" approch to test ZWaveJS.
I re read your first post. Yup, most certainly does come across as a criticism suggesting you need to tell the product owners to care more about stability.
Again, I don't see how you have methodically addressed your issues prior to launching a broad criticism.
You are a frequent poster here. Very particular to your solutions. The approach you took in your first post is unlike you. Perhaps you are taking things personally this week. Doing ok?
Then your best path is to stick with ZIP until the Z-Wave JS firmware catches up with whatever conflict you may be experiencing related to the mix of devices on your network. There is a new firmware build currently undergoing internal testing to ensure it doesn’t introduce regressions or breaks what already works today. Hopefully, the upcoming release addresses the issues you’ve encountered.
As previously mentioned, we are aware that certain edge cases exist, and some device combinations can surface unexpected behavior that isn’t visible in more common setups. The good news is that Z-Wave JS development is active and moving quickly, and the majority of users have a better experience than using ZIP.
These issues are not hardware related or even DB. They are software related, so whatever you do, if you use the same firmware, your problems will follow you.
Thank you very much for the very valuable update and clear explanation on what is going on. Unfortunately I cannot do a beta testing. My wife initially said she didn't care about all automations but right now she likes a lot everything what was done and immidietly complains if something did not work. As a result I have a hard time to find a good time frame (which is only around 5-7min) for the updating my hubs. Gladly my system is very stable and reliable so WAF is really very high.
However I can provide a whatever info which could be valuable for the HE team. I can email you (pm) hub ids if this has any value. Please let me know if you want hub ids.
Yes, I am OK.
And again, I am very sorry if my message was not very clear and sounded insulting. Clearly this was not a goal.
I am always happy to help anybody if I can. And I am really happy to share all my DIY prjects and whatever else I was done. Currently everything is automated. The goal is hands free automations but without any cloud-based integrations. So far so good and I am running out of ideas what else could/should be automated next.
It doesn't concern me. It should continue to function the same for all my existing Z-wave devices, and for those currently on the market (that it already supports).
Hopefully, the upcoming release addresses the issues you’ve encountered.
