C-7 and S0

That won’t work. That only disables it in the UI, but not the radio’s internal tables.


I'm getting a mixed message... :wink:

1 Like

Either exclude it, or leaved it powered (plugged in).

NB: You do not have to continue running PC Controller. As long as it is powered, the stick will respond on the Z-Wave network.


That's nice! I might just plug it in a USB Power Supply then. Good to know!

1 Like

FWIW I leave mine paired when not in use and have no problems. Same with a holiday lights outlet that is in the closet for most of the year.

I have a Zooz USB stick and I do exclude it after each use. Yes it chews up another # in the zwave device table every time but what the hell.

Re: leaving a zwave radio included and powered off, well I tried that and it took 24 hours for the sky to fall.


So I was wondering about that... Does anyone know why the numbers don't just get reused? I find it very odd that they are just left blank...

It will wrap back around and use them eventually if you add enough nodes. My guess is that it's easier in some sense to just use the numbers sequentially, and there is no practical concern (one's obsession with uninterrupted sequential numbers doesn't count :grin:) so no reason to do anything else.


I am now converting my devices from Security S0 to None. I find it odd that I can't just use my secondary controller to set already paired devices to S0... I tried, but no luck.

In case anyone is interested, here is how I proceed:

  1. Using the "Z-Wave PC Controller" software on my PC with a UZB dongle, select "Remove" to exclude the device
  2. Using the software, select "Add" and then put the device into inclusion mode to include it again. This sometimes takes a couple of tries depending on the device...
  3. Once the device is included, select it from the list on the software, click on the "Security Scheme" button and select "None".
  4. Convert the device number into hexadecimal
  5. Go to the device in Hubitat and Edit the "Device Network ID"
  6. Enter the hexadecimal value under the "Device Network ID" (Not doing this will create a new device in Hubitat using the "Type"/Driver name once Hubitat finds it...
  7. Repeat for all devices
  8. Power off the hub, unplug it for 1 minute, plug it in again
  9. Go to "Z-Wave Details" and see that the device(s) are now in the list of devices at the end of the list. (Rebooting seems to be the only way to get the new device(s) to appear... Unfortunately, as far as I can tell, there isn't some sort of refresh button for this...)
  10. If the device shows "NOT_RESPONDING" or "FAILED" at that point, press "Refresh" or "Repair" while also pressing the button that makes it join the network over and over and over and over again until it is finally "OK" again... (Maybe there's a better way to do this... If so, I don't know it yet...)
  11. In Hubitat, do a "Repair Z-Wave". Not sure if this is required or not, but I suppose it can't hurt...

It is very difficult to accept this non-sequenionalism... very difficult... :crazy_face:



I was just about to ask what happens when you hit 0xFF

You won’t. In the current spec, nodes wrap at at 0xE8 (232), which is also the max # of nodes. 0xE9 - 0xFE are reserved node numbers. 0xFF is the broadcast address.

There is a new Z-Wave standard coming, which allows 2k+ nodes in a network. Haven’t seen the encoding for that... perhaps someone else has?


I'm seeing a problem with some of the sensors that I have setup at security "None" with the secondary controller. Even thought their address is correct under the device property page and they initially seemed to register activities, they no longer do. The devices seem to be stuck at an earlier state.

Does anyone have any idea how to reconnect them to Hubitat? I have confirmed that they are active on the Z-Wave mesh - when I send a pair command, I can see it in the secondary controller's logs.

I don't see any errors in the Hubitat log for the devices in question.

Update: Well, it appears pestering the device with a bunch of "Configure" commands in Hubitat or poking the pair button a bunch of times eventually restores the connection... It worked on one device at least! :slight_smile:

1 Like

This is what I was going to suggest. I think I had a similar issue.

1 Like

@bcopeland, tagging you in case you are not aware of this issue... Seems that when devices (sensors for sure) are paired with a secondary controller at Security « None », they lose connectivity to Hubitat after a short period of time. It is possible to restore the connectivity, but difficult/awkward.

This is likely due to initial setup of associations and wakeup is not configured properly..

1 Like


I didn’t setup a wake up - What would Hubitat set it to? 5 minutes? I think I can set this up from the PC’s UZB stick, right?

I’m not sure what this means... Is this something that needs to be done in Hubitat, or can I do it on my PC’s UZB stick?

I’ll add this information to my steps above once I have it confirmed... :slight_smile:

Devices go through an interrogation process when included by the hub.. Some initial values for wakeup and lifeline association are set.. Then it goes to the driver which may make changes to associations and wakeup for device specific things.

Thanks again! If I understand correctly, I don’t have anything to setup on the PC’s UZB stick as doing a “Configure” from the driver will set it up correctly.

(I’m not very versed on the intricacies of Z-Wave unfortunately... I have learned a lot in the last couple of days through experience, tech documentation (which can be hard to understand without the proper background/context) and community input!)

Oh, and I have my fingers crossed that you will have the time and be able to add functionality directly in the Hub to pair at Security “None”!!! :smiley:

1 Like

Is this why sometimes if having pairing issues in the logs it asks us to save the device again - needs the driver updates or something?

I've gotten in the habit of doing this after a troublesome install anyway.

Does the system recognize a new wakeup value set by the driver? I know the command is sent to the device--I'm referring to the hub declaring the device as failed because it's missed N wakeup intervals.