#Zooz 800 stick won't properly enter inclusion mode

1 messages · Page 1 of 1 (latest)

mossy linden
#

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?

mossy linden
#

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

long iris
#

Did you unplug the Aeotec?

mossy linden
#

I did

#

Only stick plugged in is the zooz

long iris
#

Using extension cable?

mossy linden
#

Tried with and without

long iris
#

Well keep it, basically required.

mossy linden
#

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?

long iris
#

No

#

You should use the original ones

mossy linden
#

Ok I figured well like I mentioned literally every other function works

long iris
#

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

mossy linden
long iris
#

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

mossy linden
#

I let the window at the inclusion process sit there for about 5 minutes before closing it, but that happens immediately

long iris
#

Where are you including from?

#

HA or ZUI?

mossy linden
#

both

#

this one was from ZUI

long iris
#

ZUI has a 30 second timeout by default, which could explain the above logs. I think HA waits forever.

mossy linden
#

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

long iris
#

Why aren't you using SmartStart?

mossy linden
#

well in this specific case because the item is already in my wall

long iris
#

Not that it shouldn't work, but SmartStart is infinitely easier.

mossy linden
#

but...I should be able to use this mode, no?

long iris
#

Sometimes the inclusion sequence is tricky.

mossy linden
#

well it's immediately stopping the process and timing out every single time, so I'd probably think my stick is wonky

long iris
#

You'll need to provide those logs at least. The above just show nothing happening and ZUI cancelling it (AFAIK)

mossy linden
#

which logs?

long iris
#

Those debug logs. The one posted above doesn't show any issue, except the inclusion was not started on the device.

mossy linden
#

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
long iris
#

Ok, maybe the controller is misbehaving and causes ZUI to cancel.

mossy linden
#

I did realize I have logs on info, I set to silly for now to see if it gives any more info

long iris
#

Debug, not silly

mossy linden
#

well that was ZUI, I set driver level to debug

long iris
#

But I think the ZUI debug wizard thing does it for you

#

What firmware is the controller?

mossy linden
#

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
long iris
#

I would also try excluding the node first, just in case, and try again

mossy linden
#

I haven't included anything

long iris
#

I know but sometimes they are included

mossy linden
#

wdym

long iris
#

It could be part of another network. Either in QA or return.

mossy linden
#

you mean exclude itself?

long iris
mossy linden
#

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

long iris
#

Probably but worth trying all avenues of troubleshooting

mossy linden
#

ok I'll try it

#

yeah no exclusion found

long iris
#

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

mossy linden
#

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

long iris
#

Could be, that might require examining a copy of the NVM backup. Generally that migration should work as it's a required SDK version.

mossy linden
#

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

long iris
#

You're on all the good versions

mossy linden
#

I posted in the discussions area, I'll see what info can be provided. thanks for your help so far

mossy linden
#

@long iris well zooz told me 500 to 800 isn’t supported, even thought ZJS will restore it

long iris
#

That's not true at all

mossy linden
#

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.```
long iris
#

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.

mossy linden
#

It does sound a little AI-y

#

I’ll see what their response is to me asking them to double check

long iris
#

There's nothing special with the ZWA-2 in this regards, any 700 or 800 (on the correct firmware) will support it

#

If there's a problem with the controller, it's probably not within Zooz's ability to troubleshoot.

mossy linden
#

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

long iris
#

Same zwave network?

mossy linden
#

I just took a backup and restored it to the other one

#

It’s only in use if the VM is migrated

long iris
#

You can't have both plugged in

mossy linden
#

Why not?

long iris
#

It's powered on

#

and can ack messages

mossy linden
#

Seriously?

long iris
#

That was why I asked if the Gen5 was unplugged. Has this second one been powered on the entire time?

mossy linden
#

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?

long iris
#

See if a Z-Wave JS restart does anything

#

The controller does it

#

If it's part of a network, it will ACK messages

mossy linden
#

Is there a way to put the controller into like a “sleep” mode where it won’t do that

long iris
#

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

mossy linden
#

Same issue

long iris
#

How about a unplug/plug?

mossy linden
#

Nope

long iris
#

Do you still get the ZW0200 error?

mossy linden
#

Yeah

long iris
#

Darn, that would have been a good explanation. At any rate, keep those other controllers unplugged to avoid network issues.

#

Step 3 also mentions unplugging the adapter

mossy linden
#

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?

long iris
#

I think that would have been OK, because the restore would have occurred when the second 800 was a different network.

mossy linden
#

restore isn't really doing any radio stuff anyway I'm guessing

long iris
#

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

mossy linden
#

yeah it's just writing data to an NVM

#

so idk. I feel like this is a zooz issue

long iris
#

(On the source and targets respectfully)

mossy linden
#

are there other 800 sticks to consider? I'm still within my return period (amazon)

long iris
#

I guess since we're in an HA Discord, the ZWA-2

mossy linden
#

or 700 if I don't really need 800, I was just looking to replace an EOL stick

long iris
#

More expensive, but has probably the best antenna

#

You can't buy 700 anymore unless you find old stock

mossy linden
#

ZWA-2 is 700 though isn't it?

long iris
#

Nope, 800

mossy linden
#

ah ok

#

is there a way I can configure a stick, somehow, to be accessible from multiple proxmox modes i.e. for migration?

long iris
#

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

mossy linden
#

looks like something like Z Wave over IP?

long iris
#

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.

mossy linden
#

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

long iris
#

The connection to ZUI (zwave-js-server technically) is already over a WebSocket connection

mossy linden
#

so just move the 800 stick over to this and it'd work

#

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

long iris
#

Haven't heard too much about that one, I know the 700 version was plagued with issues.

mossy linden
#

@long iris well zooz just said the network is in a bad state and I should restart it from scratch

long iris
#

Factory reset your spare zooz 800 and see if you can include it

mossy linden
#

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

mossy linden
#

@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

long iris
#

Unfortunately I don't know anything about the zwave proxy besides it exists

#

Did you move the physical location of the controller?

mossy linden
#

I have not, no

hexed crystal
#

Did you plug it in directly or with a USB extension?

mossy linden
#

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