In the SmartThings classic app, if you tried to force delete a device, the device would get deleted from the cloud record even if it was not removed from the radio. So maybe that is what happened?
Nope, I made 100% sure to properly remove that device from the app. I can try excluding and re-adding it, but I’ll do it later tonight. About to head out for the evening.
Just removed the device before leaving. I’ll work on this tomorrow. Thanks @Kianoosh_Karami.
I was able to exclude the device, and I was successfully able to include it; BUT, instead of being discovered as a “zwave switch”, it was just found as a “zwave device”. It is controllable, but somethiing still isn’t right.
EDIT: changed device name to Master Bathroom Shower Fan (images show old name)
Here’s more info:
So, I went ahead and changed the DTH to Zwave Switch and now it looks almost normal, except Raw Description. It also still works just fine:
I’m going to let this run for a couple days to see how this works out. I did do a zwave repair while we were out of the house, so maybe that helped?
I removed the device this morning (ID 51). Still too many issues after rejoining. It keeps thinking it’s already been there before, which it was before my hub removed it. Going to try cleaning up some ghost ID’s, especially the original ID the device had. I have no idea why it joins as a “zwave switch” on one attempt, but on another attempt it joins as a “zwave device”. Very odd and very frustrating since the device has been rock solid before this happened.
I have a suspicion about whether doing network wide inclusion (method used by default when adding devices) which basically prompts all the repeaters to do inclusion is perhaps causing this issue to occur. I am not 100% certain, it is very difficult to be sure about this without having over the air trace. My suspicion is if some of the repeaters are perhaps buggy (old firmware and what not) and is somehow the faulty party here, because the logs from hub radio is showing exactly as you described and I am not sure what the radio could do differently if it is receiving messages from Nodes that you do not expect.
Maybe I will work on a change to allow me/support team to disable network wide inclusion and only do inclusion by the hub radio to see if there is any issue. I will have to coordinate with our internal folks and see if I can get this change out in time for another release before we go to production.
The alternative is if you could place the device you are adding within close proximity of the hub, which maybe impossible using a V2 hub and a switch somewhere in your house.
Hi @Kianoosh_Karami, thanks for your reply on a Saturday night. Unfortunately the alternative won’t work well. The hub is literally on the exact opposite side of the house from the master bathroom where the switch is.
If you want any help testing your idea, I’ll gladly help out. It seems logical what you want to do considering the likelihood of this coming up again, especially as Lowes Iris customers start to come on board to SmartThings with older devices like the GE’s.
Personally, I’ve been making the change to Zigbee devices anywhere I can due to the reliability and performance I have with it. I’ll keep trying to include this switch in our bathroom because it’s important for us, but eventually I’ll change to GE’s Zigbee version.
Please keep me posted? Have a good night, and weekend, and as always - thank you for all your help!
I remember seeing this issue reported by some users some time ago on the Z-Wave DTH or Thermostat DTH topic.
@Kianoosh_Karami some users have been reporting an issue about devices pairing successfully (shows up in the live logging) but they don’t show up in the mobile app until the hub is rebooted. I don’t know if these are related. However those issues are happening with the 24.x firmwares.
I’m not sure how well network wide include works in ST’s Z-Wave implementation. I recently replaced a bunch of devices with their Plus counterparts. Starting from closest to the hub and moving out of course, and doing a repair each time. When I got to the periphery, I still had to move the hub to successfully replace. Whether this speaks to ST’s NWI or replaced devices not being updated in the DB I don’t know. It would be nice if repairs and replaces refreshed the device info.
Yeah, whatever is happening here doesn’t feel right. I woke up to find a zwave device offline that’s within a foot (inches) of that other device that will not rejoin that @Kianoosh_Karami and I are discussing. Typically I have to trip the airgap switch, but this time no matter what I do, it will not come back. All I see “Err 115: Z-Wave replacement timed out” in the event log. Now I’m down 2 zwave devices in a heavily used area, and one of them is quite important for an automation I use to exhaust humid air from an enclosed shower.
Interesting enough, I also have another zwave device offline this morning; but it’s within 15 feet of the hub. I did the airgap trick on that one, and it instantly rejoined.
Also to @swamplynx’s point, I’ve been trying to help a new Iris convert to ST on his implementation woes with zwave devices. When he was using Iris, he never had problems with his zwave devices, but now with ST he’s got several. He’s still bringing more zwave devices online into ST, but his experience has been rough so far.
I’m not actually a zwave fan, and prefer zigbee, and that’s just based on my experience with ST and a decent variety of devices over a very long period of time. Changes like this continue to reinforce my goal of replacing my zwave devices with an equivalent zigbee device, and/or doing away with the device altogether through consolidation (devices and automations). With these issues now, I think I’ll be accelerating my zwave to zigbee replacement timeline.
EDIT: I just kicked off 2 more Replaces on the offline device, and it looks to have rejoined (for now).
EDIT : I retract my previous edit. The device I found offline this morning, and brought back after several attempts, has gone offline again 3 hours ago. I’m not liking where this is going with the new zwave framework. Super stable devices (for years) start acting up and can’t rejoin is very concerning.
this looks similar to issues I had with exclusion and inclusion testing. I put my findings in bug report bug-0044 in center code. (My testing was with a battery device very close to the hub, and all of my zwave repeaters are ge zwave plus switches.)
At this point, I can’t continue wasting time on trying to get my zwave devices to rejoin or added back. I sure hope @Kianoosh_Karami can roll back whatever changed that caused this and come up with a better implementation of it.
EDIT: Found a fix. My Lowes Iris prepaid Visa just arrived, so off to Lowes I go to get 4 new GE Zigbee switches to replace all the switches in my master bath. Yay.
I’ve successfully replaced 3 zwave devices with 3 zigbee devices, all GE switches. One of the switches is a newer 12xxx series device, so I went to redeploy it (after it was excluded already), but I can’t again for the same reasons we’ve mentioned several times above. It joined once, but the LED’s were reversed again, and it wasn’t controllable.
It is probably the furthest from the hub, but I’ve never had problems joining devices at that distance until firmware 25.19. Looks like that switch will be replaced with a Zigbee version too.
Any word on your recommendation/thoughts from earlier?
EDIT: Tried again, and it joined just as a “zwave device”. This is getting annoying. It’s ID 67, and I just changed it to zwave switch.
Please use the new thread for any issues and comments regarding the 0.25.20 Release