For a while now I have noticed that when I load up Z-Wave JS to check on my devices, it takes an extraordinarily long time to load the device entries. Often I wind up rebooting ZUI (top right) and they eventually come in, no problems.
I decided to start looking into why Z-Wave JS does this and started checking the logs.
What I noticed is for all my in-wall GE (Enbright/Jabsco) devices, it seems to spend an extraordinary long time querying “dimmingDuration” going from level 0 to level 255 for each and every device.
When I check the device configuration and I check:
Scene Actuator Configuration v1
I see an entry for “dimmingDuration” and “Level” from 1 through 255…
(with 70 some odd devices, you can imagine how long this takes)
Is there a why to edit this and make it a bit more responsive?
Can I shut down Scene Activation entirely (I don’t really use it anyway)
To add…
Here is the YAML of one of my devices.
You can see the “Scene Actuator Configuration”
for “dimmingDuration”
for every device there are 255 entries:
id: “194-44-0-dimmingDuration-9 (1-255)”
So Z-Wave JS has to scan every single one of those CC44 configurations every time it loads.
Yes it’s normal. The values were added to support one or two other devices. 99% of people don’t need these.
Can you quantify “extraordinary long time”? For me this process takes about 100ms per device. When my installation of ZUI is running for nearly a month (no reason to upgrade to every new release), that time is inconsequential.
2025-10-17 12:35:44.306 INFO Z-WAVE: [Node 015] Is alive
...
2025-10-17 12:35:44.345 INFO Z-WAVE: [Node 015] Value added 15-44-0-level-1 => undefined
...
2025-10-17 12:35:44.422 INFO Z-WAVE: [Node 015] Value added 15-44-0-dimmingDuration-255 => NaNs
...
2025-10-17 12:35:44.431 INFO Z-WAVE: [Node 015] Ready: GE - 14292 / ZW4003 (In-Wall Toggle Switch, 500S
Querying/scanning as you call it is just the driver loading the values from a database on disk. It’s not reading from the device. Unless you have something else going on, you would need to provide logs to know that.
You can remove the CC by overriding the device files with a custom one.
I don’t like these values either as it also bloats the initial node dump HA receives when it connects, and I was previously removing them via the above device config file method, but got tired of maintaining it to keep up with upstream. I’ve considered submitting an issue to make this easier to disable, but since I haven’t noticed a significant performance problem I never bothered. Perhaps you are motivated enough. https://github.com/zwave-js/zwave-js/issues/new/choose
Thank you for the response.
This actually explains a lot of what I am seeing.
To answer your question, by delay I mean two thing…
If I initially open Z-Wave JS, if nothing is cached, it actually will not load at all. You are forced to do a “restart” and then it takes about 10-15 seconds to start displaying devices which is slowly start querying a little at a time. I’d say about 1-2 minutes before 88 devices are fully displayed and all attributes updated.
Once it is cached, it works alright, but if you make an admin update (route update, node requery) it may kick off another scan causing yet another bottle neck while all the devices get updated.
It just seems so unnecessary for something that isn’t even used (in my case)
You may need to provide more information then, e.g. logs of whatever you are referring to. The logs I showed will only occur during startup or after a node re-interview. Updating routes should not trigger it.
I can’t say if 1-2 mins of startup time is normal for 88 devices. My last restart took 14 seconds for 33 nodes.
2025-10-17 12:35:30.977 INFO APP: Version: 11.5.2.3234f82
...
2025-10-17 12:35:44.861 INFO Z-WAVE: Network scan complete. Found: 33 nodes
If I had 88 GE switches the overhead of the scene activation values would only be ~9 seconds, this is on not so powerful Dell Wyse mini pc with an SSD.
