I assume you mean z-wave nodes, not child sensors? That is not normal. It is probably because you had it enabled in SmartStart, excluded and then yanked the plug while it was trying to automatically pair again, thus creating a partial/broken pairing. That could be the reason for your issues as well (not having a clean exclude / include).
Yes, what I meant was that the zwave nodes were the child sensors. A few of them have "regrouped" themselves and restored them as a "Generic Z-Wave DT Binary Switch" device but they won't go away. I'll wait for beta to close and then start a new thread to try and get them removed.
I moved all our posts on this matter to a new topic since it is getting quite lengthy.
Zwave nodes are for an entire device, not child endpoints.
Yes I have seen that happen before on ghost nodes, not sure why exactly. The false devices can be force removed again.
Also, you can roll back to the production build using the diagnostic tool if you want, you just lose any new features. Just click Download Latest which gets production builds only, then install from the Restore Previous version button.
Recommendations:
- Go back to production platform if possible.
- Use SS Manager app to disable/enable SS to prevent accidental inclusion [APP] SmartStart Manager for Z-Wave (Long Range support)
- Clean up all ghost nodes and devices (or as many as possible for now anyway) How To Remove Ghosts using hub tools or a UZB Stick
- Exclude ZEN16
- Factory reset ZEN16
- Include device
- Adjust only the Input Type settings [contact sensor recommended]
- Do not change input control setting yet
- Verify SS is disabled / removed
- Exclude device
- Power cycle device.
- Include device again
- Verify that the Input settings you set before came back through the same, it should sync from device and show the settings you selected before the exclude.
1 Like
Zooz sent me a new firmware to try. I updated the firmware just fine. But after excluding the device and re-including it, I had another 6 zwave objects I can't get rid of.
This makes about 21 now. So I just restored my hub from a few days ago before I started with this project...They wouldn't go away and since they are LR (from what I've read) I won't be able to get rid of them through the second controller/USB stick method (?). So I restored the zwave radio from a couple of days ago. Zwave looks good right now.
So I want to go on with this, but I think I will dig out my old C7 hub and use that to test.
No problem nowadays
Does C7 do LR?
No, but I have an older Zen16 I never used before. I want to see how it behaves with input sensors vs. having to use the relay itself for status changes.
So the UZB stick solution for cleaning up ghosts will work with non-mesh (LR) devices?
Not sure the non LR ZEN16 does sensor inputs. The old ZEN17 does.
Sorry, misread. I thought you were pairing as LR. Not sure about ghosts created while pairing LR devices as mesh, sorry.
If it's a v2 Zen16 (700-series / released mid-2023), then it can separate the sensors from relays. The v3 800-series also can, of course.
The v1 Z16 cannot seperate them.
You need to show screenshots because these statements are not clear.
Is this zwave nodes? Devices in the hubs device list??? What?
So you are trying to pair as LR using SmartStart?
Have you tried deleting the SS and pairing manually?
You can pair a LR device in mesh mode, either manually pairing or by changing the mode in SS before you power it up. You can also pair the 800LR device to the C7 by doing manual pairing.
None of what you have described is normal (and some does not make sense), so you just need to slow down a little, ask questions, provide screenshots, and figure things out instead of banging on it over and over again.
As I had mentioned before, these were zwave LR nodes--I presumed one for each relay child device--but I didn't know child devices didn't show up here until you educated me...but three unattached zwave nodes would appear each and every time I excluded the Zen16 from the hub.
The first time I paired the device was on the app via SmartStart. After switching the default hub driver to the advanced driver, configure, power off/on the Zen16 and then trying to change the sensor parameters to 10 then excluding, SmartStart automatically reconnected and created the device and three [new] child relay devices.
After coming here for help I then followed the instruction to remove the device from smartstart to keep this from happening while I tested. But, each time the device was excluded and re-included 3 more zwave nodes were added.
Zwave was healthy before starting with this Zen16. I have had the older Zen16 added and removed to my hub in the past several times over the last year with no issues.
Understood. Thanks for all your help.
This is definitely not normal and I have never seen that before with mesh nodes. Sometimes with LR / SmartStart pairing it goes bonkers and fails a bunch of times creating a bunch of ghost nodes. Some people had dozens made trying to pair one device during beta testing I recall. I would suspect it is either due to a range issue, or some other communication problem with the hub, the pair fails and repeats a few times before it finally works. This is just due to the way SmartStart is setup, if the device is trying to pair then SS picks it up and just tries again over and over as long as the device is still trying to pair. Often time if you just shut down the hub and reboot the extra LR nodes clear out.
Again, screenshots would be very helpful, of zwave details and of the system logs. The system logs would show each time SS pairing starts and may have some errors when it fails.
Also worth noting, LR ghost nodes in theory should not cause any issues, other than being annoying. No devices will try to route through them so they just sit there. It will say on the details page if its a Long Range node. Anything < 0x100 (256) is mesh and over that is LR.
Are you purposefully wanting this device in LR mode for range or would it maybe be better as a mesh device? Might be worth trying to pair it in mesh mode, either change it in SS or just pair it manually (with S2 security if its for anything critical).
Jeff, I think we are good to go. I am running firmware 3.12 and followed your instructions except using the Hubitat web gui, I did leave SmartStart enabled so that it would join as an LR node (not mesh). This is for a seasonal outdoor fountain and it will be turned off in the winter. What little I know (I know that shows here) the LR is a direct to hub connection and when it goes offline it won't "mess with the mesh".
This is how a sensor looked before in the logs:
Note that whenever the contact switch was triggered how the logs looked.
Today, as soon as I changed the parameter to only report (parameter 12 = 0), immediately the child input sensor device was created. As soon as the relay was physically changed the Current State variable "switch" appeared and in the logs:
Thanks for all your help!
1 Like
So it just started working fine after you resolved the other issues with the hub?
Or otherwise what was the trick?
I wasn't having hub problems until I attempted to include/exclude the relay 20 times and had 15 or so LR zwave nodes to deal with. The hub problems started when I went to start over and did a soft reset on the hub and restored my zwave radio back to where it was a couple of days ago--before the Zen16 entered my life.
This caused the cron logs on the hub to have scheduled events in the past, basically putting a halt on any other background schedules since I did the restore. Deleting the device scheduled events from the past fixed that (and HPM).
I had a clean Zwave environment, all Zen relay devices were gone (thanks to the restore).
I think one of the issues causing the phantom zwave nodes (that I incorrectly thought were related to the child relay devices because there were always seemed to be THREE of them) was because I was attempting to re-include the Zen16 when smartstart was already adding it back into the system. So when I physically initiated the include process, it was at the same time in the background SS was already adding it.
I did mostly what you told me to do except I did not have to go to the inclusion process, smartstart added the device back for me with the changes I made as noted above.
- The relay was factory reset.
- The hub was stable (zwave, and the result from the soft reset/restore from last night)
- I installed your advanced Zen16 driver
- I included the relay via SmartStart. I left SmartStart enabled (so the LR would be in play)
- I edited the device and changed to the advanced driver, saved changes, and refreshed the page.
- I then edited the device and just changed the parameters as noted (2,3) to value of 10 for dry contact. Saved. Exited the device page.
- I excluded the Zen16--the device was removed from the hub (Zwave environment is clean--no phantoms)
- I turned off/on the device and waited for SmartStart to bring the device back.
- I edited the newly restored device and checked if params 2 and 3 were still 10. Yes!
- I changed the input sensor types to 0 (report only) and as soon as I saved the device and it was synced, two child sensor input devices were created immediately.
- When I went to test the physical contacts, the Current State was updated on the screen instantly with the variable "switch" and value of off/on
The only time I turned off the Relay was when I excluded it from the hub after assigning your driver and changing sensor 1 &2 to dry contact.
Yesterday I was incorrectly interpreting to toggle the power after I changed the sensor params AND then excluding/including which required another power on/off. I was making things messier because I was manually including the relay when I just needed to let SS do its thing.
You don't have to start the include process at all if using SmartStart. You literally just power the device up and wait. Which I think you already know now.
SS is only needed for pairing, for LR or otherwise. Once paired you can remove or disable the SS entry if you want, to avoid accidental re-pairing if you later exclude the device.
Glad you got it sorted out finally.
Couldn't have done it without you. Learned a bunch. Sending you beer money for the drivers (I think I'm using a couple other of yours now that see and familiar with your jtp10181 handle!)
2 Likes
Did your sensor status keep working reliably? Mine seems to work fine after I initially include the relay, and will work fine until the relay is power cycled. I then have to exclude, and include the relay again to get it to work. I even upgraded the firmware to 3.20 on it and its still acting the same. It kind of looks like after the relay is power cycled it just quits sending the status updates.
What input type settings are you using? What driver? If you use any of the sensor inputs you have to adjust those settings, then exclude (do NOT factory reset) and reinclude the device for the events to get reported correctly. This is due to something with the 800 series zwave certifications, Zooz had to make it like this to pass. The device retains it settings through an exclude and my custom driver is setup to handle this by syncing the settings from the device when you pair it, [DRIVER] Zooz Relays Advanced (ZEN16, ZEN17, ZEN51, ZEN52)
If you change the input types and then do not exclude, results can be inconsistent. I found on some models when you power cycle the device in this case it can also change how the reporting is sent but still may not be 100% correct. Also, if you exclude AND factory reset, then you have to start over because the settings get wiped.
