Adding First Z-Wave Devices (using Aeotec Z-Stick 7)

First, I am still really new to using HA and finding my way around, so I’m sure I’m missing things and not finding the stuff I need. It’s quite possible I’m missing some obvious steps. I’m including whatever I can because I don’t know what’s significant and I’d rather have too much than not enough, so feel free to scan the parts that give needed info.

I’m running into trouble adding my first Z-Wave device. (I have some others that are currently hooked up to an ISY-994i. I don’t want to remove them from that network until I know I have things working and can replace the events I have setup for them on the ISY.)

I put the HAOS image on a USB drive and plugged that and an Aeotec Z-Stick 7 into a Pi4 and started it up, went through configuration, and when I added the Z-Stick (it wasn’t under the name Aeotec, but I can’t remember the name it was under), Z Wave JS got added, too. I think I have the Z-Stick set up:

So did I get that right and get the Z-Stick behaving and is there anything else I need to do to make sure I can add Z-Wave devices?

My first Z-Wave device is a Schlage lock. I’ve tried to add it several times. I go to Configuration->Integrations, find Z Wave JS, and click on Configure. On both the web interface and on my iPhone, I get:

From there, I click or touch “ADD NODE” and proceed without Secure Inclusion and touch/click on Start Inclusion. At that point I see a change on the “Start Inclusion” button, but that’s it, so I don’t know if there’s another step or if something is supposed to come up telling me it’s waiting for a device. That’s when I did what I needed to on the Schlage lock. I got the “Interviewing” dialog, but not long after that, the lock flashed the X, showing it failed.

I tried it again and got the same thing. HA was still interviewing the lock when the lock reported failure.

I may have tried it more times, I’m not sure. I now have a node_2 and node_3 listed under Z Wave JS and both are unavailable. I tried to remove node_2 and I see no result. I later tried to remove node_3 and got a message that it couldn’t be removed while something else was being removed. I found a switch to enable node_2, but HA now sees it as dead and there’s nothing I can do with it.

I can’t help but say, “What we have here is a failure to communicate.” It looks like HA/Z-Stick 7 see there’s something there, but are still “interviewing” it when the lock is saying, “Haven’t received the info I need to join the network, so it failed.”

I’m not sure whether to keep trying to remove the lock or to do something with it now. I did try re-interviewing it, and that’s done no good at all.

I don’t use Zwave JS (yet) but did you make sure to do a remove node command on the Schlage lock before trying to include it with the new Zwave network? Whenever I add a new device, the first thing I do is a remove node command, the wake the device or press the pairing button on the device. This makes the device forgot any previous connections to a Zwave controller (the remove node command is a broadcast/global command and any node whether it is actually paired with that controller or not will respond to a remove node command and perform the exclusion process). Then I do an add node.

The lock probably requires secure adding. Try a different device such as a window or door sensor that does not require secure adding. You will need to make sure you have a key generated to allow secure inclusion.

This set of locks (Schlage) replaced the crappy Kwikset Z-Wave locks that were on the ISY’s Z-Wave network. I had not yet added them, so I never thought of that, but it’s a good point and I’ll try that.

I’ll try that. Since the warning said that too many secure devices would slow things down, I didn’t want to try that unless I had to. This door is to an upstairs screen porch. While we have a lock on that door, anyone breaking in would be nuts to try to enter through there instead of breaking a downstairs door window and reaching around. I was thinking of adding the ground floor doors (5 in the house, 2 in the barn) as secure.

Right now my other devices (until I start pulling wall plates and adding more of them) are on my ISY’s network. I did think of that, but the other devices I could drop from that network are on timed programs. (Like turning the lights on and off or adjusting the thermostat throughout the day.) I was really hoping not to pull those off the old network until I was sure I could add them quickly.

Thanks for the warning! Googling for that info now!

I checked on the unenroll process on the lock. Basically you press the Schlage button, then the 6 digit code for that lock, then 0. That enrolls or unenrolls it.

I tried to remove one note and HA acts like it’s about to remove it, then says it can’t because it can’t interrupt the removal process. I don’t know if the background removal process it interrupted was from earlier, trying to remove the other instance of the lock, or what. I rebooted HA and tried again. Same message.

Since this is at the beginning over the overall process, I’m thinking of resetting the lock to factory defaults - that should do the removal from the lock end. On the HA end, I’m thinking of removing the Z-Stick, then re-installing it. Would that wipe out any Z-Wave devices added through the Z-Stick?

My Zooz Z-sticks got here today. (Long story, but the Aeotec ones were taking so long, I didn’t think they were going to show up, so I ordered 2 from Zooz. I know I’ll need one in the house and one in the barn.) I’m thinking of removing the Aeotec and seeing how the Zooz works - or just trying to restart with the Aeotec.

Resetting to factory defaults does not necessarily reset the enrollment status of the lock. I had a Kwikset that would not unenroll with a reset. I cannot remember if my Schlage is the same way because it’s been a while since I had to deal with it in the sense of the Zwave network.

As stated above, locks require secure inclusion which requires having a network key set. I may be wrong but I believe Zwave JS automatically sets a key if one is not present already. Unplugging the Zwave stick and plugging it back in does not reset the stick or the network. You have to remove all nodes or use a separate service to reset everything. Then before adding the nodes back in, you’ll have to make sure to do an exclude on the device first, then include because the device may still think it’s paired to the old network.

Okay, that makes sense and I can do that. I’ll check on what I need to do for the key.

I don’t think the lock even thinks it’s enrolled. If it requires secure inclusion, that would make sense - and it would also most likely mean the lock doesn’t even think it’s enrolled or otherwise related to that instance of HA.

I didn’t expect that to, but I did unplug the Z-Stick for another reason: I can’t unenroll a darn thing! I can’t unenroll the two instances HA and the Z-Stick created when I tried to enroll the lock. I thought maybe if I unenrolled the Z-Stick, it would drop the whole network - but I couldn’t unenroll the Z-Stick because HA could still ping it. So I pulled the Z-Stick out and tried again. HA could still ping the Z-Stick at that point. (So there must be a battery in it or something - a backup or standby system?)

The problem is I can’t remove ANYTHING from the Z-Wave network. It can’t unenroll the two instances of the lock, node_2 and node_3. I get an error message when I try to remove either one (mentioned it upthread) and I can’t remove the Z-Stick.

I’ve created a new HAOS image on a new USB drive and I’m going to see what happens there. I’ve looked for other threads on removing Z-Wave devices that wouldn’t remove and it looks like it’s a mess. I’m just glad I ran into this NOW, before I had 20 items on that network! If this works, I’m still going to want to know how to remove a healthy node or an unresponsive one.

And it just hit me - I don’t think the lock has any info on the Z-Stick or my HA instance. If it were at all enrolled as node_2, I don’t think it would have created a node_3.

If it’s like the Gen5 stick then yes it does have a battery in it. With ZWave the node list is actually stored on the stick / controller. All Home Assistant or any other control system you use is doing is grabbing the node list from the stick, and then interviewing each node to find out about it’s capabilities etc - which it saves to cache so that future startups are quicker. The chances are that the node is in a weird state where the stick thinks it is included but the node does not. I would suggest a factory restore of the Stick. It doesn’t look like the ZWaveJS Server addon currently does generate a S2 key so you will need to do this and restart the addon.

Edit to add: The reason the stick has a battery in it - is so that you can unplug it, walk right up to the device you want to include and press the button on the stick for a few seconds. Now you can put the node in to inclusion mode and with the stick right next to it, that will happen quite quickly. You can then put the stick back in to the USB port, (probably) restart the add-on and let the interviewing process finish. You will need to wake up battery powered devices in order for the interview to complete.

Overall: Fixed it the hard way - and I wouldn’t have done this if I had more devices or automations or scenes set up. I made a new image and put it in a different Pi (which was convenience more than anything - I have a Pi in my Elecrow laptop I use for testing, so I just pulled stuff out of there and put it in the other Pi). It started up okay and I went through the beginning configuration. When it came to Z-Wave, I went in and manually added Z Wave JS. It wanted to add the Z-Stick at the same time, so I let it. During that process it asked for the Z-Wave network key. So I spent time Googling, found the terminal/ssh app, found that the key was not yet generated, so just let it add the Z-Stick without it.

(Note: This is something I’m putting in some setup notes as suggestions for setup issues in general.)

It installed the stick, but I found that three devices for Z Wave JS were’t enabled and I enabled them personally. When done, I checked the files again and the network key was generated and in place. Also, at this point, the node_2 and node_3 were seen as part of the network, but this time I was easily able to remove them from the network. First part of problem (removing the bad nodes) solved!

I had problems getting the mobile app to connect with HA again (and some notes on that, too). I did get it to connect, so I took it to the door with the lock and this time I used Secure Inclusion. It took time, but it worked. So second and last part of the problem solved!

Also another note I’m going to add for HA devs: The Schlage lock manual says NOTHING about secure integration. It would be nice if HA could somehow detect if a device requires it, or maybe if it can recognize a failure and ask to try again with secure inclusion if there’s a chance that’s the reason for failure.

That’s what I was thinking. I had read up on how the Gen5+ worked when I was looking for a stick. It took me a while to compare the two and I wondered why the Gen5+ had the button for easy inclusion like that and the 7 didn’t - until I read more about it. The Z-Stick 7 definitely has a battery in it, or at least some kind of non-volatile RAM.

Yeah according to the official comparison guide on their own site - it doesn’t have a battery: https://aeotec.com/z-wave-usb-stick/z-stick-7-vs-z-stick-gen5.html

It will definitely have flash memory though, because it needs to remember the nodes it knows. As you have already established, you can take the USB stick and plug it in to any device and with the right software, talk to the ZWave network (though it won’t do a lot, if you don’t have the same network key, that you added devices with).

When I first read that, this afternoon, I thought, “That makes sense. All it needs is flash memory to keep track of the devices.” But I’ve been thinking about it. When I had tried almost everything else - other than starting fresh, I had no luck. As an almost last-ditch attempt, I shut down HA, pulled the Z-Stick, then restarted it and tried to remove the Z-Stick as a device. HA wouldn’t let me, saying it could still ping the Z-Stick. At that point, it (the Z-Stick) was out of the Pi and not hooked up to anything.

So somehow, when disconnected from everything, it was still responding to a ping. I don’t know what was going on - just reporting what I saw.

Yeah, that’s some sort of glitch on the ZWaveJS software. Whether the Gen7 or the Gen5, it won’t respond to a ping when it is unplugged - no ZWave battery device will respond to a ping while it is asleep, otherwise the battery wouldn’t last very long at all.

One of the biggest problems with ZWave, is that the stick is in control, and the software talking to the stick - is left to the mercy of the stick. So for example, if you have a busy network, and communication fails with a node on the network a number of times, the STICK will mark the node as dead, at this point it doesn’t matter how many times the software tries to revive the node, the STICK will simply drop any attempts to communicate with what it considers to be a dead node. If the node is woken up, or made to transmit a ZWave message (for example turning a wall switch on) the stick, will temporarily mark the device as alive again, until the next time it misses a communication. The only reliable way to recover from this state, is to pull the stick out for a few seconds so it loses power, and then plug it back in (just rebooting the machine does not work, because the USB device stays powered)

So ZWave is a more complicated beast to troubleshoot than say Zigbee.

We built our house in 2017. I was on the site almost every single day, watching the contractors and doing a lot of site work. (The driveway is 1/3 of a mile to the house and 1/2 mile total, including going to the barn, and there was a lot of landscaping and other work to do with a tractor, chainsaw, and other outdoor tools!) Also, the new house is 45 minutes away from my old house, so those were long days.

That’s when I was researching home automation and, at the time, Z-Wave looked pretty good for several reasons. One was that it was not a protocol just one company was using. (Insteon, at the time, was all Insteon. If any other companies were making Insteon compatible devices, it was just a very, very few. Z-Wave was pretty well established and used by a number of companies.) There were other factors and I don’t remember why I didn’t start using Zigbee. I got an ISY-994i hub from Universal Devices, which works, but their Admin interface is kludgy. It does work with Z-Wave and with Insteon (if you buy a PLM to connect to it). At this point, due to Z-Wave upgrades, if I keep it working, I need to put in an upgraded Z-Wave board. (And, sadly, I realized that I had many more Insteon devices than I thought - Insteon seems stubborn sometimes!)

I was thinking of keeping that (the ISY) going, but once I started with Raspberry Pis for other uses, people told me about how well it worked for home automation and Home Assistant seems to leave Universal Devices way behind. I can use one HA instance to control wifi, Z-Wave, Insteon, Zigbee, and more. HA is much more versatile - it’s just taking me time to learn a new system.

I’m going to re-evalute some of my choices. I still have a lot of dimmers I haven’t installed yet that I’m going to use, but I still need fan controls for my ceiling fans and other devices. With something like HA, I’m glad I can use a lot of different systems with one hub.

I’m in much the same position. My entry in to home automation started with 433MHz sockets and a remote control. Then I discovered that with the USB tellstick I could send the on and off commands to the sockets without the remote control. Next came domoticz and the RFXTRX433 usb stick from RFXComm which allowed us to control the sockets and also receive data (the tellstick didn’t receive it was transmit only). Suddenly we could get data from our weather sensors and the electric meter for example. This was great but there was one downside… The 433MHz sockets, are receive only - so there is no confirmation that the command was actually received - and depending on humidity, air pressure, time of day, what direction the wind was blowing, how many fingers you had crossed etc sometimes the command did not get received.

So it was fine to look at how to fix the problem, and ZigBee didn’t really seem to be on the scene that I remember. So ZWave was the only way to go.

Initially, it was rubbish. Nodes kept being marked as dead. Heals weren’t working. Restarts took about 30 minutes to get the network talking again. But some well timed offers online for ZWave lightbulbs and ZWave sockets helped to stabilise the mesh (which I have to admit, given it is spanning 2 buildings, is rock steady reliable) - but yeah, it took putting a lot of mains powered devices in to make the system reliable.

Now that ZigBee is good, and much much cheaper, I was lucky that another well timed offer of packs of 2 ZigBee lightbulbs helped to jumpstart the ZigBee mesh :yum:

@mobile.andrew.jones : I remember in one thread you mentioned using GoControl thermostats. While I’m rather miffed I couldn’t get help from them to find out if I could replace parts on mine, I still have some working thermostats of theirs that are going flakey. I go into what’s wrong in another post I just put up. I’m having serious problems getting anything to work.

Could you look at this post and see if you have any insight into dealing with the GoControl thermostats? At this point, only two locks are working for me and I’m trying to find some way to get HA working at any basic level.

Sorry, I think you have the wrong person. I don’t have GoControl thermostats. I use Schedy in AppDaemon to automatically control my heating target, and Zigbee temperature sensors with a min_max sensor to get the average temperature of the house.

Also had a quick look at the thread - I see you say you are using the Gen 7 stick with a Pi4, this is a known bad combination. The Pi4 and the Gen 7 apparently don’t get on well. It’s something to do with interference from the Pi4’s USB port.

Wow. That’s the first response to anything I’ve had in a few days and it’s right on target for what I’m doing. I wonder if that could be causing problems with the Insteon stick as well. But immediately, that gives me several things to try:

  1. Plug it in a USB hub - that might distance it enough or it might mean a signal without the issues that get in the way.
  2. Change over to a Pi 3 for HA. (Have to check if that’s doable.)
  3. Switch to a Zooz Z-Stick, since I have some on hand. (Only problem - their size! Can’t plug it in with something in the port beside it.)

You may be the wrong person for the GoControl issue, but I’m glad I tagged you - you’ve given me something to work with. Also, I may end up looking at Zigbee and I’ll remember Schedy. I’m not thrilled with GoControl at this point.

This is the recommended first step, getting the stick a reasonable distance away from the PI, say 30cm - 1 meter. It is known to make a massive difference.

As for your general ZWave issues, my ZWave was always unreliable, until I took advantage of some offers on ZWave lightbulbs and sockets. This seriously stabilised the mesh and it’s been rock solid for nearly 2 years now.

As for Schedy - it’s YAML so you should be able to read what is going on here - but have a quick look at my config and you will see why I love it:

schedy_heating:  # This is our app instance name.
  module: hass_apps_loader
  class: SchedyApp

  actor_type: thermostat

  rooms:

    house:
      actors:
        climate.house:
      rescheduling_delay: 120
      watched_entities:
        - "input_boolean.heating_night_mode"
        - "input_boolean.home_state_home"
        - "sensor.cc_outside_temperature"
#        - "sensor.cc_30_min_gust"
        - "sensor.cc_rain_rate"
        - "input_boolean.heating_eco_mode"
        - "input_boolean.andy_is_sleeping"
        - "sensor.zigbee_bedroom_temperature_temperature"
        - "sensor.livingroom_temperature_temperature"
      friendly_name: House
      schedule:
        - v: 18.5
          rules:
            - x: "Add(-0.2) if is_on('input_boolean.heating_eco_mode') else Next()"
            - x: "Add(-0.2) if is_on('input_boolean.heating_night_mode') else Next()"
            - x: "Add(-0.1) if is_off('input_boolean.home_state_home') else Next()"
#            - x: "Add(+0.1) if float(state('sensor.cc_30_min_gust')) > 35 else Next()"
            - x: "Add(+0.025) if (float(state('sensor.cc_outside_temperature')) < 15.1 and float(state('sensor.cc_rain_rate')) > 0) else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < -9.9 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < -4.9 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < 0.1 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < 5.1 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < 10.1 else Next()"
            - x: "Add(+0.025) if float(state('sensor.cc_outside_temperature')) < 14.1 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 30.1 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 24.9 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 22.9 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 21.9 else Next()"
            - x: "Add(-0.2) if float(state('sensor.cc_outside_temperature')) > 20.9 else Next()"
            - x: "Add(-0.1) if float(state('sensor.cc_outside_temperature')) > 16.8 else Next()"
            - x: "Add(+0.2) if float(state('sensor.livingroom_temperature_temperature')) < 17.5 and (time.hour < 23 and time.hour > 11) else Next()"
            - x: "Add(+0.2) if float(state('sensor.zigbee_bedroom_temperature_temperature')) < 17.4 and (time.hour < 9 or time.hour > 21) else Next()"
            - x: "Postprocess(lambda result: round(result, 1))"
            - { v: 18.4, start: "00:00", end: "01:00" }
            - { v: 18.2, start: "01:00", end: "02:00" }
            - { v: 18.0, start: "02:00", end: "03:00" }
            - { v: 17.8, start: "03:00", end: "04:00" }
            - { v: 17.7, start: "04:00", end: "05:00" }
            - { v: 17.6, start: "05:00", end: "06:00" }
            - { v: 17.7, start: "06:00", end: "07:00" }
            - { v: 17.8, start: "07:00", end: "08:00" }
            - { v: 17.9, start: "09:00", end: "10:00" }
            - { v: 18.0, start: "10:00", end: "10:30" }
            - { v: 18.1, start: "10:30", end: "11:00" }
            - { v: 18.2, start: "11:30", end: "12:00" }
            - { v: 18.3, start: "12:00", end: "12:30" }
            - { v: 18.4, start: "12:30", end: "13:00" }
            - { v: 18.5, start: "13:00", end: "14:00" }
            - { v: 18.6, start: "14:00", end: "15:00" }
            - { v: 18.7, start: "15:00", end: "16:00" }
            - { v: 18.8, start: "16:00", end: "18:00" }
            - { v: 18.9, start: "18:00", end: "20:00" }
            - { v: 18.8, start: "20:00", end: "21:00" }
            - { v: 18.7, start: "21:00", end: "22:00" }
            - { v: 18.6, start: "22:00", end: "23:00" }
            - { v: 18.5, start: "23:00", end: "00:00" }

    attic:
      actors:
        climate.attic_fans:
          hvac_mode_on: cool
      schedule:
        - v: 17.5
          start: "08:00"
          end: "22:00"
        - v: "OFF"
      friendly_name: Attic

The heating target is changed automatically based on time of day, but also other conditions, like the outside temperature.