Quite often platform changes seem to precede hub fw updates. And quite often the result is devices freezing/locking. Happens to me every few months and aligns with ST side changes every time. Both Zigbee and Z-wave can be impacted which leads me to believe some changes are not deployed in a nondestructive manner.
Any chance this has fixed the buffer overflow issue from a large picture causing the hub to disconnect
as reported by @RBoy and me?
I assume that based on the first post that this is now rolling out and so far there has been no screaming. This is a good sign.
There is no improvement for me with this firmware release. still many devices (Fibaro double switches and dimmers) randomly unresponsive, and showing prolonged delays while remotely operated and also many errors in the Z wave repair. I had many interactions with the smartthings team, some of them helped for a short period but nothing last for more than few days. I belive there are major problems with the smartthings hub firmware and cloud causing this instability. It’s not device related because the problems are random and can be relieved temporarily.
I wish I could hope for a solution but i’m starting to give up on this platform.
very dissapointed.
I think my Schlage lock is not really communicating with smart things anymore and it’s worked for about a year. I changed the batteries and it’s really glitchy, I lock and unlock the door and half the time it updates in smartthings app and sometimes it doesn’t. I also now have zero control to lock and unlock the door with smartthings app. Would hate to factory reset the lock and go through the mess of setting it up if it is because of this update. Very frustrating >:frowning:
Did you try adding a repeater close to your lock? It makes a big difference in the quality of the mesh and reliability of your lock communications. What you’re describing sounds like it can benefit from having one. Also as a temp measure try to reboot the hub and do a Z-Wave repair.
It happens when a DTH works with the classic app but not the V3 app. But then you can still control it with the classic V2 app.
I did reboot the hub last night (I forgot the remove the batteries wooops do I need to try again?) but I am unsure how to do z-wave repair, can you describe how to do that? I am also using your multi lock smart app. I’m wondering if hub location and device smart lock have not changed location ever why are these problems starting now.
Ok I figured out where the repair button is and I did that and I could see it run and finish in live logging but the Schlage lock still shows as offline
Also the door is near a wall and on the other side of the wall is the hub, I guess if you think a repeater would help I could get a long cat6 cable and move the hub to the other side of the wall which would put it right next to the lock almost?
I forgot the remove the batteries wooops do I need to try again
Yes, need to power down or you can do it remotely from the IDE.
My Hub → List Utilities → Reboot hub
You can also do a Z-Wave repair from the same utilities page (wait for about a minute after the hub reboots before starting a repair)
Also the door is near a wall and on the other side of the wall is the hub, I guess if you think a repeater would help I could get a long cat6 cable and move the hub to the other side of the wall which would put it right next to the lock almost
Helps to have a repeater ideally, see this topic: FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?
Ok I did the reboot hub option still shows offline. So now I have to buy something else lovely, is there anything you recommend? The smartthings door sensor directly above the lock works just fine
I still cannot add Fibaro Heat Controller device, I have to do it manually via Developer Workspace. And for good measure, now it won’t even work in new SmartThings app. So I guess after two months this issue is still not solved?
makes sure you don’t have any custom device handlers installed for the fibaro heat controller.
Why, they changed API again? Or they removed support for custom DTH?
Anyway I tried it, same result. I had to manually add device and since I deleted custom DTH, I had to use general Z-Wave thermostat, which is in new ST app, but obviously do not work at all, because it needs custom implementation.
I would recommend adding a repeater and checking the batteries.
Showing offline could be an issue with the health check features, if you can’t control it means the lock has either lock connection with the hub (it happens, exclude and re-pair the lock) or it’s having trouble with the mesh (add repeater and change batteries).
While the topic title talks about locks, this issue affects any device which appears to pair but doesn’t complete pairing. If you’re having trouble pairing your device and you’re using custom DTH’s see this FAQ: Symptoms When you try to pair a device using the ST app or the Classic ST app it may appear to pair successfully, i.e.: the device will provide feedback that it has paired. e.g. Devices/locks flash green lights or other lights to indicate successful pairing Device may successful sounds/beeps But the ST mobile app won’t show any new devices, it’ll continue saying Looking for devices There are no new devices showing up in the IDE under My Devices You are able to successfully manually exclude the device using the General Exclusion process Cause This is caused by custom DTH’s …
Open the thread you just linked, you’ll see my two months old comments.
There was a bug in ST firmware, which was also acknowledged by ST team – which I linked in this thread already. And it looks like it wasn’t fixed.
I’m facing the same issues as Toka.
Why, they changed API again? Or they removed support for custom DTH?
There’s a bug with custom handlers where they become stale. The sympton is you will pair the device, the device acts like it paired, but a device is never created in SmartThings. Deleting or re-publishing the device handler fixes the issue.
There was a bug in ST firmware, which was also acknowledged by ST team – which I linked in this thread already. And it looks like it wasn’t fixed.
It’s true that the issue resulted from a FW change, but we don’t consider it a bug in the FW. The change we made was to report all the supported command classes to the cloud which is something we must do. The issue causing the problems with pairing certain devices is on the cloud side and unfortunately has been non-trivial to fix. We’re investigating workarounds that we can deploy cloud side to get things working again. I can’t commit to a timeline but I think we have a reasonable workaround identified.
I know in some sense it’s not important where the bug exists but I just wanted to clarify why it’s not something you see fixed in this FW release.
But then you can still control it with the classic V2 app.
Ah, yeah. I keep forgetting about the v3 mobile app. I don’t use it, but I noticed that after last update (mobile app update) some devices show unavailable and cannot be controlled even though the show online and can be controlled with v2 app.