ZwaveJS is not stable and therefore not practical

OK, C8 Pro hub now is on the latest platform 2.4.3.164 and I tried ZWaveJS again cople weeks ago (I forgot what was the platform version but it was latest at that moment). And again, switching to the ZWaveJS instantly introdices a lot of random delays, sometime in a minute range. These delays are affecting near every RM rule but of course, they are more niticable on a lighting control rules. And what is the "best", the most affercted device is a ZWave Ultraloq lock. The Lock/Unlock commands are working more or less reliably. But the Status Update usually has a huge delay. This brakes a rule which physically opens a door because it waits fot the "Unlocked" status from the Lock.

Bottom line:
So far my experience with the ZWaveJS is not very good. I am not sure what should I do next. My hope of course , is to switch permanently to the ZWaveJS but the broken Lock?Door automations is a real show stopper (at least for now).

Any suggestions how to improve a ZWave Mesh are more than very welcome.

PS.
When hub is switched to the ZWaveJS near 70% of devices have a "Rebuild route" button. Cliking on this button does not change anything. Good number of Devices have an empty route entry in the table. However all the Devices are workink just fine from the Device Page and sure from the related Rules. I don't think, they are some sort og Ghosts because Ghost Device never will work at all. Plus everthing looks just right in the Legacy ZWave mode. Am I right? Only one device is added with S0 security (Fibaro Multisensor) but I was noy able to add this Device without security enabled. This was done long time ago, maybe (hopefully) this is not a case anymore.

UPDATE

  • Some ZWave Buttons must be pushed few times before HE sees a Trigger Command.
  • On/Off commands for the ZEN32 must be in a while loop, otherwise they could be missing.

I feel the same.

Had a recent bad experience with improper state reports on Zooz contact sensors. All 6 were not reporting state completely.

Went back to ZIP, which was not trivial for me, with some devices not making the transition and needing rework.

Everything reports properly now, and may I add, more 'snappily'.

2 Likes

The JS adventure has kept me from upgrading to the 8 Pro from my 8 & 7. At this point I intend to tread water until the next C-? iteration.

1 Like

Not upgrading!? We just don't know who you are any more... :wink:

1 Like

You can run ZIP perfectly fine on the 8-Pro. I'm currently back on ZIP on my 8-Pro due to showstopper device-level reporting issues that popped up relatively recently on JS, but for me, going back and forth between the 2 is painless enough.

4 Likes

Someone needs to test the betas on a C-8. My real problem is that there isn't anything I "need" to do that my C-8 doesn't do well and quickly. I only have a few hundred devices, endless developer apps and rules. I'm holding out for a built-in border router and maybe a thread radio. I know if I purchase a Pro it will trigger a C-NextGen release. Patience Grasshopper :wink:

1 Like

So just purchase the Pro so we can all get the next gen.... :wink:

3 Likes

If we can get Bobby and Mike to sign off I'd take one for the Community.

2 Likes

Probably won't be a c9 until there is a z-wave 900 series chip and no note of that in the alliances pipeline.

How about a “C8MatterPro”?

1 Like

Made of anti-matter? :wink:

2 Likes

Held together by a thread :roll_eyes:

5 Likes

C8Pro_OC_Ti

2 Likes

Other than adding a thread radio, I'm not sure what else would make it a "MatterPro" - It could become a TBR, in that case, but I'm not sure what exactly that would buy HE, other than a larger code base to support (eliminate requirements for Alexa, GH, or Apple TBR? - But they seem to have that fairly well covered)

Personally, I think additional matter functionality, like allowing a HE to be a Matter bridge, for all the devices connected to it (Z-Wave, Zigbee, LAN, Cloud, etc.) - That would be very helpful in terms of integration with other ecosystems, and shouldn't require additional HW.

On this larger thread (pun intended) topic, I personally find ZwaveJS very stable (I'm not running locks), and I'm using it on a C8 that's also running Matter - And it seems fine, running for about 1 month at a time before low memory requires a reboot.

That all said, alot of work of the recent Beta's has been re-writing the parse routines, for various command classes, and that seems to have improved alot of missed responses..

I think the next key milestone, is to get beyond the 800 SiLab FW of V7.18 - They tried, and pulled back from V7.23, which had a bunch of fixes for "Z-wave Jammed" issues that others are seeing in more active meshes. I believe SiLabs has V7.24.2 out since Sept 2025, and hopefully, a 800 ZWave radio update is coming soon. - That will enable EUR LR frequencies under ZwaveJS, as well (which are never going to happen under the ZIP/Gateway)

So I'm not sure overall agree that ZwaveJS is "not practical", but clearly it's been a focus area in recent Beta's, and I think getting the final SiLab radio FW releases out, will make a big difference in getting to ZIP/Gateway functional parity.

I don't see a imminent change in HW given the Pro was a somewhat "forced" CPU and RAM upgrade, and there is no new SiLab radio's on the horizon. And there are numerous Matter (V1.4 has lots of new EV and energy Command Classes), Visual Rules, NewDashboards, and ZwaveJS items could all use additional work. I see them paddling as fast as they can with lots of software work for the next 12-18 months.

Adding a Thread radio, and TBR functionality doesn't seem worth the effort, given what Apple, and the other majors are doing.

JM2C.

4 Likes

One can hope.

Could newer radio firmware builds break compatibility with Z/IP, which is, if I understand correctly, no longer maintained? That would be one explanation for HE holding back on those updates - to maintain Z/IP compatibility until Zwave-JS is « ready », whatever that means. Just spitballing here.

I've wondered about that too :person_shrugging:

From what we've been told Bryan is using the same database w/Zip & Z-WaveJS, so I believe that's under HE's control, and Z-WaveJS can't do somthing that would break compatibility on its own. No engineering genes in my DNA, but that seems to be the situation, AFAIK. Also never heard them mention concerns vis-a-vis FW updates breaking ZIp. :man_shrugging:

From what I've seen/heard they are cautious about Z-WaveJS FW and radio updates to avoid creating new problems and/or regressions. Lots of moving parts..."scary monkeys!!" as my son used to say. :wink:

2 Likes

Sure. I was referring to the radio firmware, which is separate from the radio sdk (Z/IP or ZWave-JS) and, obviously, distinct from the hub’s own firmware which embeds that sdk. The sdk has to know the radio’s language. If the radio firmware changes that a little bit, you might need the sdk to account for that change. If Z/IP is EOL and can’t be updated, then you see the problem.

Again, just an educated guess that could be totally wrong.

2 Likes

@johnwill1 I ordered it this morning just for you.

1 Like