I'm trying to include a new ZEN35 scene controller, but the zooz 800 (ZST39) stick never properly enters inclusion mode. When I start it, it immediately says "inclusion stopped. checking for changes" with "inclusion starting" underneath. after a few seconds I get a pop up that says "Timeout while waiting for a callback from the controller (ZW0200) startInclusion undefined" and it just sits there until it times out a bit later any ideas?
#Zooz 800 stick won't properly enter inclusion mode
1 messages · Page 1 of 1 (latest)
For more details, this was an NVM restore of a backup I took from an older Aeotec 500 stick. However it was upgraded to FW 1.02 which is SDK 6.81. My understanding is the migration should be compatible after 6.61 SDK version
Did you unplug the Aeotec?
Using extension cable?
Tried with and without
Well keep it, basically required.
The stick completely works in all other ways. No devices have issues communicating, rebuilding routes, interviewing, etc
Even exclusion seems to work
Do I need to like “regenerate” the security keys or something?
Ok I figured well like I mentioned literally every other function works
You can try the "Start Debug Capture" feature in Z-Wave JS UI and try the inclusion, then post the logs
Magnifying glass icon in the web UI header
@long iris here you go
Not seeing any errors in between Starting inclusion process with strategy Default... and stopping inclusion process.... Did you close any window before it could complete?
The ZW0200 error is not shown
I let the window at the inclusion process sit there for about 5 minutes before closing it, but that happens immediately
ZUI has a 30 second timeout by default, which could explain the above logs. I think HA waits forever.
well this is my latest one 2026-04-05 21:19:04.923 INFO Z-WAVE: Calling api startInclusion with args: [ 0, { forceSecurity: true, name: '', location: '' }, [length]: 2 ]
so that was...5 minutes ago
and it's still trying
2026-04-05 21:20:09.928 INFO Z-WAVE: Timeout while waiting for a callback from the controller (ZW0200) startInclusion undefined
but it already timed out
Why aren't you using SmartStart?
well in this specific case because the item is already in my wall
Not that it shouldn't work, but SmartStart is infinitely easier.
but...I should be able to use this mode, no?
Sometimes the inclusion sequence is tricky.
well it's immediately stopping the process and timing out every single time, so I'd probably think my stick is wonky
You'll need to provide those logs at least. The above just show nothing happening and ZUI cancelling it (AFAIK)
which logs?
Those debug logs. The one posted above doesn't show any issue, except the inclusion was not started on the device.
I'm not sure why it doesn't show it timing out, but I did get the red pop up
21:28:10.033 DRIVER one or more queues busy
21:28:10.034 DRIVER » [REQ] [AddNodeToNetwork]
node type: Any
high power: true
network wide: true
callback id: 217
21:28:10.034 SERIAL » 0x0105004ac1d9a8 (7 bytes)
21:28:10.036 SERIAL « [ACK] (0x06)
21:28:40.034 CNTRLR stopping inclusion process...
21:29:15.037 DRIVER » [REQ] [AddNodeToNetwork]
action: Stop
high power: true
network wide: true
callback id: 218
21:29:15.037 SERIAL » 0x0105004ac5daaf (7 bytes)
21:29:15.040 SERIAL « [ACK] (0x06)
21:29:15.042 SERIAL « 0x0108004ada0600000061 (10 bytes)
21:29:15.042 SERIAL » [ACK] (0x06)
21:29:15.043 DRIVER « [REQ] [AddNodeToNetwork]
status: Done
callback id: 218
21:29:15.043 CNTRLR The inclusion process was stopped
21:29:15.044 DRIVER all queues idle
21:29:20.045 DRIVER one or more queues busy
21:29:20.045 DRIVER » [REQ] [GetBackgroundRSSI]
21:29:20.045 SERIAL » 0x0103003bc7 (5 bytes)
21:29:20.048 SERIAL « [ACK] (0x06)
21:29:20.049 SERIAL « 0x0107013b9a9a9aa8f0 (9 bytes)
21:29:20.050 SERIAL » [ACK] (0x06)
21:29:20.050 DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -102 dBm
channel 1: -102 dBm
channel 2: -102 dBm
channel 3: -88 dBm
21:29:20.051 DRIVER all queues idle
Ok, maybe the controller is misbehaving and causes ZUI to cancel.
I did realize I have logs on info, I set to silly for now to see if it gives any more info
Debug, not silly
well that was ZUI, I set driver level to debug
But I think the ZUI debug wizard thing does it for you
What firmware is the controller?
1.6 SDK 7.23.2
21:33:14.924 DRIVER » [REQ] [GetBackgroundRSSI]
21:33:14.924 SERIAL » 0x0103003bc7 (5 bytes)
21:33:14.926 SERIAL « [ACK] (0x06)
21:33:14.928 SERIAL « 0x0107013b9a9898a7ff (9 bytes)
21:33:14.928 SERIAL » [ACK] (0x06)
21:33:14.929 DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -102 dBm
channel 1: -104 dBm
channel 2: -104 dBm
channel 3: -89 dBm
21:33:14.929 DRIVER all queues idle
21:33:17.997 CNTRLR Starting inclusion process with strategy Default...
21:33:17.998 DRIVER one or more queues busy
21:33:17.998 DRIVER » [REQ] [AddNodeToNetwork]
node type: Any
high power: true
network wide: true
callback id: 80
21:33:17.998 SERIAL » 0x0105004ac15021 (7 bytes)
21:33:18.000 SERIAL « [ACK] (0x06)
21:33:47.996 CNTRLR stopping inclusion process...
21:34:23.002 DRIVER » [REQ] [AddNodeToNetwork]
action: Stop
high power: true
network wide: true
callback id: 81
21:34:23.002 SERIAL » 0x0105004ac55124 (7 bytes)
21:34:23.005 SERIAL « [ACK] (0x06)
21:34:23.006 SERIAL « 0x0108004a5106000000ea (10 bytes)
21:34:23.007 SERIAL » [ACK] (0x06)
21:34:23.007 DRIVER « [REQ] [AddNodeToNetwork]
status: Done
callback id: 81
21:34:23.007 CNTRLR The inclusion process was stopped
21:34:23.008 DRIVER all queues idle
21:34:28.008 DRIVER one or more queues busy
21:34:28.009 DRIVER » [REQ] [GetBackgroundRSSI]
21:34:28.009 SERIAL » 0x0103003bc7 (5 bytes)
21:34:28.011 SERIAL « [ACK] (0x06)
21:34:28.012 SERIAL « 0x0107013b9b9a9aa6ff (9 bytes)
21:34:28.013 SERIAL » [ACK] (0x06)
21:34:28.013 DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -101 dBm
channel 1: -102 dBm
channel 2: -102 dBm
channel 3: -90 dBm
21:34:28.013 DRIVER all queues idle``` doesn't really show any more
You'll probably have to wait for AlCalzone's help on this, and/or you can create a discussion and attach the logs. https://github.com/zwave-js/zwave-js/discussions/new/choose
I would also try excluding the node first, just in case, and try again
I haven't included anything
I know but sometimes they are included
wdym
It could be part of another network. Either in QA or return.
you mean exclude itself?
Put the controller in exclusion mode and do the inclusion/exclusion sequence. Or try a factory reset. https://www.support.getzooz.com/kb/article/1678-how-do-i-perform-a-factory-reset-on-my-zen35-scene-dimmer/?section_id=449
oh you mean the ZEN35, well I stopped trying to include it a bit ago, I figured it was a problem with the controller since it's timing out on the "startInclusion" API call
Probably but worth trying all avenues of troubleshooting
Since you've already try unplugging/re-plugging, using a USB extension cable, and the background RSSI looks good, I'm out of ideas.
I think that would be a normal log if it was excluded
only thing I can think of is something went wrong with the migration, since it might be a bit finicky coming from such an old stick?
but it was upgraded past the required SDK version
Could be, that might require examining a copy of the NVM backup. Generally that migration should work as it's a required SDK version.
I did see something that was only for 700, if you wanted to go to 800, you needed to be on 7.19 or something, but I couldn't find any other info, and the NVM restore function did go through when I tried it, so I figured it was compatible
You're on all the good versions
I posted in the discussions area, I'll see what info can be provided. thanks for your help so far
@long iris well zooz told me 500 to 800 isn’t supported, even thought ZJS will restore it
That's not true at all
This is what they sent:
What you’re running into here is a hard limitation of how NVM backups are handled between different Z-Wave chip generations. We reached out directly to the Z-Wave JS team to confirm, and they verified that restoring an NVM backup from a 500 series controller to an 800 series controller is not supported and will not work.
The key point is that the NVM backup and restore process is entirely managed by the hub software, not the USB stick itself. The controller is essentially just accepting raw memory data being written to it. Because of that, compatibility depends on whether the software can correctly interpret and translate the data between chip generations.
In this case, the issue comes down to fundamental differences in the NVM structure between 500 series and 800 series chips. The layouts are not compatible, and there isn’t a direct mapping between them. Even in tools that don’t validate compatibility, like PC Controller, writing a mismatched NVM (for example 700 to 800) results in a corrupted or unreadable memory layout. With 500 to 800, the gap is even larger and cannot be reconciled at all.
Z-Wave JS does attempt to handle migrations more intelligently by detecting the target controller’s NVM layout and rewriting the backup into the appropriate format when possible. However, they’ve confirmed that this translation layer does not and cannot support 500 to 800 series migration due to the structural differences in how the data is stored.
That’s why you’re seeing the failure to include after the restore. The controller ends up with invalid or incomplete network data, so it can’t function as a proper primary controller.
At this time, the only reliable path when moving from a 500 series stick to an 800 series stick is to rebuild the network and re-include devices. We understand that’s not ideal, but it’s currently the only supported approach given the chipset limitations.
If your goal is to avoid a full rebuild, the only potential workaround would be staying within the same chip generation (for example 500 to 500 or 700 to 800 where supported translation exists), but 500 to 800 specifically is not something the platform can handle.```
There are many HA users that have migrated from Gen5 to 800
That's 100% incorrect. Z-Wave JS manages the conversion of the NVM to the correct formats.
They did not reach out to the Z-Wave JS team, or they are acting on information that is very old
Sounds like an AI response, honestly.
It does sound a little AI-y
I’ll see what their response is to me asking them to double check
There's nothing special with the ZWA-2 in this regards, any 700 or 800 (on the correct firmware) will support it
This HA user migrated their Gen5 -> Zooz 800 almost a year ago: https://community.home-assistant.io/t/z-wave-js-nvm-restore-to-zooz-800/712442/8?u=freshcoast
If there's a problem with the controller, it's probably not within Zooz's ability to troubleshoot.
Well to throw a wrench in this I actually have a second one that I’m using for HA VM migrations (so I don’t need to move the stick physically) and both exhibit the same behavior
So it’s either an issue with Z Wave JS or their controller itself fundamentally
Same zwave network?
I just took a backup and restored it to the other one
It’s only in use if the VM is migrated
You can't have both plugged in
Why not?
Seriously?
That was why I asked if the Gen5 was unplugged. Has this second one been powered on the entire time?
Yes…
Well I just unplugged the second one and I’m still having the same issue
Shouldn’t HA/ZJS only be accepting messages from the USB TTY device it’s assigned to though?
See if a Z-Wave JS restart does anything
The controller does it
If it's part of a network, it will ACK messages
Is there a way to put the controller into like a “sleep” mode where it won’t do that
You can disable the radio
Don't think there's a way in ZUI w/o writing driver code, at least not that I can find
Same issue
How about a unplug/plug?
Nope
Do you still get the ZW0200 error?
Yeah
Darn, that would have been a good explanation. At any rate, keep those other controllers unplugged to avoid network issues.
FWIW, here are the official HA docs for doing a controller network migration. There's a special section for Aeotec Gen5, and no limitations on going to 800 at all https://www.home-assistant.io/integrations/zwave_js/#migrating-a-z-wave-network-to-a-new-adapter
Step 3 also mentions unplugging the adapter
hmm..
I'm pretty sure I restored the backup with only one 800 stick plugged in
I feel like....
would it be worth trying to factory reset the stick and restore it now that I only have 1 plugged in?
I think that would have been OK, because the restore would have occurred when the second 800 was a different network.
restore isn't really doing any radio stuff anyway I'm guessing
Also the 500 and 800 are duplicates until the 500 is unplugged, so it's just a temporary situuation
Right, during a backup and restore the radios are disabled
(On the source and targets respectfully)
are there other 800 sticks to consider? I'm still within my return period (amazon)
I guess since we're in an HA Discord, the ZWA-2
or 700 if I don't really need 800, I was just looking to replace an EOL stick
More expensive, but has probably the best antenna
You can't buy 700 anymore unless you find old stock
ZWA-2 is 700 though isn't it?
Nope, 800
ah ok
is there a way I can configure a stick, somehow, to be accessible from multiple proxmox modes i.e. for migration?
There's a newer Aeotec that's a combo Zigbee/Z-Wave, I tend to avoid those though.
Probably the best way to do that is the Z-Wave Proxy. Works on Wifi with the ZWA-2, or you can buy a POE board
looks like something like Z Wave over IP?
Sort of, it's an ESP Home bridge basically
Alternative to ser2net/serial TCP
Or just run ZUI on some SBC/Mini PC. Depends on what kind of failure you're trying to handle.
running something over IP would be fine, trying to avoid having downtime during proxmox node updates
looks like doing this with an esp32 w/ PoE is probably what I'm looking for
https://toolbox.openhomefoundation.org/home-assistant-connect-zwa-2/use-poe/ but you should be able to use any USB controller
The connection to ZUI (zwave-js-server technically) is already over a WebSocket connection
so just move the 800 stick over to this and it'd work
and any esp32 w/ ethernet/wifi should work? was looking at this https://www.amazon.com/Waveshare-ESP32-S3-Development-Ethernet-Processor/dp/B0DKJ5VXC9/
ah yep, I see it's listed in that page
ok, got an esp32-s3 eth ordered. I did also order thatn aeotec 800 just to see if a different stick will help, but I may just switch completely to the ZWA-2 when I get this all settled just for robustness
Haven't heard too much about that one, I know the 700 version was plagued with issues.
@long iris well zooz just said the network is in a bad state and I should restart it from scratch
Factory reset your spare zooz 800 and see if you can include it
yeah inclusion works if I factory reset it. I just ended up going through and excluding everything, reset, and including it now. I restored the backup to the new aeotec and that also wasn't working properly with inclusion, so I think something went wrong during the backup process
just going through setting everything up now, I appreciate the help though, thanks again
@long iris so I have this esp32-s3 board set up, zst39 plugged in and everything is noticeably more laggy compared to usb. I expected some more latency, but my locks are often going dead not responding to pings, and I'm getting a ton of "dropping message with invalid payload" when doing things like a re-interview. anything to look for? I can paste my yaml as well if that helps
Unfortunately I don't know anything about the zwave proxy besides it exists
Did you move the physical location of the controller?
I have not, no
Did you plug it in directly or with a USB extension?
it's plugged into a small extension that's going into a waveshare esp32 clone
normally I have it plugged into a hub that's extended out from the server, it works perfectly good there
this esp32 board is located physically very close to that
extended out via ethernet from a patch panel