None Interview status?

[GrizzlyAK]

Can someone please tell me what the following status means. I just added a new device and this has been the "status" for about 30 minutes on the UI, and no traffic. I can do a ping and it responds. Manufacturer, Product and Product Code are all "Unknown" following the add. I've had significant issues added new Zooz devices to my network after upgrading to the ZWA-2, with a myriad of results, from never-ending None statuses, to added with Unknown everything, to never-ending NodeInfo statuses, to requesting S2 security begin ignored in favor of no security, to sometimes asking for the PIN, other times not, to inconsistency between the HA UI add process and the zwave-js-ui add process, with the former seeming to work more reliably. This used to be so easy... :-/

[zwave-js-bot]

Beep, boop! 🤖

I've found existing posts that look similar to yours. If they don't help, please wait for a human to show up.

These existing posts look similar to yours and might be related — a maintainer will confirm:

• Feature: support air-gapped nodes (closed issue)
• Latest firmware updates not showing as available from the Z-Wave JS Firmware Update Service (answered discussion)
• Bug: After using Failed Nodes, Replace, Status icon does not update until you refresh (closed issue)

---

These suggestions were generated automatically. AI can make mistakes, always check important info.
Was this helpful? React with 👍 or 👎 to let us know.

[GrizzlyAK]

Unrelated issues. Browser refresh does not change status from None.

[robertsLando]

What "None" means: it is the driver's interview stage — InterviewStage.None, i.e. the interview has not started for this node. The ladder is None → ProtocolInfo → NodeInfo → CommandClasses → OverwriteConfig → Complete. Manufacturer / Product / Product Code showing Unknown is consistent with that: those come from Manufacturer Specific CC, which is queried in the CommandClasses stage.

Ping succeeding does not contradict it. A ping is a no-op at protocol level and needs nothing from the interview — it only proves the route works.

What to try, in order:

1. Control panel → node → Advanced → Re-interview node. If the device is battery powered, wake it manually right after (usually a button press).
2. Watch the log at debug level while it runs and note where it stalls.
3. Settings → Z-Wave → Send to sleep timeout — default 250 ms. On a busy network sleeping nodes get sent back to sleep partway through the interview and then need many wakeups to finish. Raising it to 2000–5000 ms fixes that. See Nodes sent to sleep during interview #4769, which is the same ZWA-2 + Zooz combination you have.
4. Check the node's Security field. If S2 bootstrapping failed, the node was included insecurely, and security cannot be added afterwards — it needs exclusion and re-inclusion.

On S2 being skipped: when bootstrapping fails, the driver reports a specific reason and the UI surfaces it at the end of the inclusion. That reason is the useful bit — it distinguishes "the node never requested S2" from "the DSK/PIN did not match" from "the node timed out mid-bootstrap". It is in the log at debug level too. Both HA and ZUI drive the same driver with the same default inclusion strategy, so the difference you are seeing is not in the inclusion logic itself; the log will say what it actually is.

Also make sure the ZWA-2 is on current firmware — ZUI can flash it from Control panel → controller node → firmware update (OTW).

Which ZUI and Z-Wave JS version are you on? (Bottom of the UI, or Settings → About.) And if it still will not interview after a re-interview, please attach a debug driver log covering a full inclusion attempt. Stuck-at-None and stuck-at-NodeInfo are driver/controller level, so with a log it can go straight to zwave-js/zwave-js.

[GrizzlyAK]

Hi Daniel. I understand.

1 - tried re-interview, did not work.
2 - I have logs set at debug now, and will go through the process again and pull the relevant logs,
3 - send to sleep is at default 250, will change that to 2000 or 5000. How badly will this affect battery life?
4 - I did see this boostrap error. I saw the following while trying to add one or two devices.

2026-08-25 11:04:17.331 CNTRLR [Node 164] Security S2 bootstrapping successful with these security classes:
2026-08-25 11:31:06.295 CNTRLR [Node 165] Security S2 bootstrapping failed: did not receive the node's desired security classes.
2026-08-25 11:31:06.304 CNTRLR [Node 165] has failed S2 bootstrapping and cannot be interviewed
2026-08-25 12:03:39.476 CNTRLR [Node 165] has failed S2 bootstrapping and cannot be interviewed
2026-08-25 12:11:03.328 CNTRLR [Node 165] has failed S2 bootstrapping and cannot be interviewed

This was trying several different times two different Zooz devices ZEN04 Smart Plug and the ZEN20 Power Strip (both brand new).

My ZWA-2 is on FW 1.2. I did the most recent update with no issues.

Not sure where you're telling me to look. Assume you are talking about the JS UI control panel Settings section. I see no About section. If you are talking about the HA Settings About, it doesn't report on ZW versions for me. At the top, however, the "i" gives me the following:

zwave-js-ui: 11.22.3
zwave-js: 15.27.1

I'll try again and follow up with logs if reinterview doesn't work or post on zwave-js the relevant logs it it sticks again.

BTW, just read the following in the new Docs. Is this true?

"What happened to the Z-Wave JS UI app?

The Z-Wave JS UI app is being phased out, as its feature-rich UI is now included in the Z-Wave JS app. The Z-Wave JS UI app will continue to be supported for a while, but users are encouraged to switch to the Z-Wave JS app."

[GrizzlyAK]

OK, I've been able to try this again with debugging on and have added the relevant server log. Note that I just updated ZW and am now on zwave-js-ui: 11.23.0
zwave-js: 15.28.0

I'm getting the same error as before:

and I'm stuck at the `None` stage again. Maybe the logs will help. Please let me know what else to try, as of now, I can't add any new devices to my network. Thanks.

Here is the log. Note at the top, before the enabling of debug and JS restart, you'll see the previous attempt at adding the device as Node 166. I excluded it before the debug and included it again with S2 security (not forced) which you'll find as Node 167. Note that I am 3 feet from the ZWA-2.

zwavejs_current.log

EDIT: I just reset the logging to Info and following the restart of JS, the Interview status now reads ProtocolInfo. In case the means anything. Before the reboot, after about 30-45 minutes, it was still stuck on 'None'.

EDIT 2: I just tried to add another of my recently purchased Zooz devices, the ZEN15 Power Cord, and it added without a problem. I'm doing an OTA FW update now. The other device (ZEN04 Smart Plug) is still in the `ProtocolInfo' stage. Re-interviewing seems to have no effect. I have another ZEN15 which I will try next, along with trying the ZEN20 Power Strip again.

EDIT 3: I was able to add the second ZEN15 with no issues. I also was able to add the ZEN20 with no issues this time as well. I tried unplugging the ZEN04 Smart Plug and telling the UI to Replace, then plugged it back it. That didn't work. Timed out. I then factory reset the device, and tried including it with no security, and it worked that time with no issues. I don't know if this is Zooz or Zwave, but it seems to be volatile and buggy. At any rate, I now only have one more new device to add, another Zooz. I'll let you know how it goes. I'd love to know what you find out, if anything, from the logs. If I need to submit them to the server git, let me know.

[AlCalzone]

You have a bunch of power meters that report very frequently, and that report zero or almost no changes. ~90 reports within the 4 minutes that your log spans. Some of these are being re-transmitted several times despite high RSSI, which hints at them using low speed that saturates the duty cycle.

Looks like they are interfering with the bootstrapping process.

Node 19 alone reports V, A and W every minute. A is constantly 0 (so useless reports). Same for W. And for V, it reports such insignificant changes as 124.211 => 124.132.

[AlCalzone]

Anyways, the interviews not happening is by design. Secure nodes that failed the bootstrapping cannot be interviewed - they do not expose any meaningful functionality.

[AlCalzone]

Here's the automated logfile analysis. I'd look into reducing the automatic reports:

The main source of unnecessary traffic is node 135, which sent 43 Meter reports within about three minutes. It repeatedly sent identical W/A/V values, sometimes more than ten times within a few seconds. Nodes 19, 26 and 66 also report V/A/W every minute and occasionally repeat identical values. Node 12 sends temperature every minute and duplicates motion state changes through Notification CC plus multiple Binary Sensor reports. Node 17 reports a nearly unchanged general-purpose value every 30 seconds, and node 95 reports an unchanged temperature every minute.

I would increase periodic sensor/meter intervals to at least 5–15 minutes, use change thresholds, disable unused V/A reports, and configure motion reporting through one CC only.

[GrizzlyAK]

Are you certain that this traffic is actually interfering with with bootstrapping, since that would seem to indicate a real handicap in ZWave, given what I'm experiencing on my network,

The reports you list are accurate and as intended. The following, if interested in why, describes my use of these reports. It is a mix of uses that might be of interest in seeing how ZWave is being by the community.

Nodes 19, 26, 66, and 135 are, one each, attached to 2 refrigerators and 2 freezers, and I use them purposefully in this configuration to warn me about multiple power/failure events. They've been in service like this since Dec 2021, when I first wrote about my usage here. In this post, I describe in detail how I use them, and why the V/A/W reports are important. Note that I have 11 of these ZEN15 devices on my network, but only these 4 report these parameters. With the exception of perhaps one or two other devices, I regularly disable any and all regular parameter reports that I don't actively use, and prioritize only those that show a state change over timed reports. I could, perhaps, increase the frequency a bit, but I'd have to weigh that against reliability.

When I watch the logs, I don't see a constant stream of data (at the INFO level). Although, I guess that doesn't mean the mesh of repeaters isn't saturated. Either way, I just checked my controller statistics at the top of the UI and found about 0.3% Dropped RX commands (808 out of 267325), and no dropped TX. I would consider that pretty robust, is it not? BTW, @robertsLando, is there a way to add (or find) the elapsed run time for these stats (like time since last restart)? I can look at the logs, but it would be a nice number to include in the statistics.

Regarding the other three nodes:

Node 12 is a Fibaro Multi-sensor in my office where I was working at the time, so it was constantly going off. That is normal. For those, I have the following parameters set:

After Motion Blind Time (Period of time through which the PIR sensor won't detect motion after detection motion): 15 sec (default)
Motion Pulses Required (# of moves require for the PIR to report motion): 2 (default)
Motion Window Time (The amount of time movements specified above need to take place in): 12 sec (default)
Motion Alarm Cancellation Delay (Period of time after which the motion alarm will be cancelled): 10 sec (default is 30)
And many more...

I don't know why there are duplicate reports, but I do report Lux and Temp as well (the Temp is used by my HA-controlled Thermostats. I see that the Basic Command Class Configuration is Default, (Basic on and Basic off). I don't know if that is redundant. There are also several enabled Send commands to Associated Groups, but I have none defined, so I don't think that generates traffic.

I have 5 of these Fibaro devices and they are all used similarly.

Node 17 is a Fortrezz MIMOlite which I use as a High Water Alarm. It is connected electrically to my septic system and reads the values off the alarm wire to determine if the Septic System's High Water Alarm is activated/sounding. The values on that wire changes constantly within a range of values. When it changes significantly, I trigger an alert to my phone and send a command to my Fortrezz ZWave water valve on my water main to turn it off. In other words, it is set up to prevent a septic system backup from flooding the house. I balance frequency of reporting for potential water damage here, which is why it is so frequent. It's all automatic and I get a persistent notification on all our devices. This has been in place since 2020 and I had much less traffic back then.

I also use the same water value device to turn off the water if any one of my EcoLink water/flood detectors activates. I have one at every toilet, by the boiler/hot water heater, and by the washing machine. Any activation will turn off the water main immediately.

Node 95 is an EcoLink Thermometer, and the only thing it should be reporting regularly is the Temperature, which is does every minute. I chose that frequency because I have functions on my thermostats to be able to temporarily "boost" the temp if I'm in a space for a little while and there is a chill. It boosts the temp by 2 deg and then resets it to the previous setting automatically after either a set time (configurable)or the +2 deg temp has been reached. I need the temp reports in order for this to work as intended.

Thanks for looking into this and the suggestions. I'm hoping, however, that there may be OTHER reasons the bootstrapping is failing and interviews stalling than just the presence excess traffic. If not, my ZWave network may have reached its limit at less than 100 devices.

Cheers.