The centercode doesn’t seem to make it clear how big the problem is under the current firmware
So post a list of devices that are reporting unavailable in the format below
Device Name:
Product:
Became Unavailable:
Still Function:
Battery/Mains:
Notes:
My List
Device Name: Stevens Presence
Product: SmartThings Presence Sensor
Time Unavailable: 3 Days
Still Function: Yes
Battery/Mains: Battery
Notes:
Device Name: Stevens Car
Product: SmartThings Presence Sensor
Time Unavailable: 3 Days
Still Function: Yes
Battery/Mains: Battery
Notes:
Device Name: Muiltsensor Kitchen
Product: Aeon Multisensor 6 (Running 1.11eu)
Time Unavailable: 2 Days
Still Function: Yes
Battery/Mains: Mains
Notes:
Device Name: Muiltsensor Office
Product: Aeon Multisensor 6 (Running 1.11eu)
Time Unavailable: 2 Days
Still Function: Yes
Battery/Mains: Mains
Notes:
Ok, 2 responses to this. 1) why limit it to devices that are reporting as unavailable but still functioning? What about devices that report as unavailable but not controllable? 2) why not just post in the existing beta firmware thread for 24.5? Why do we need another thread?
Just wanted to acknowledge we’ve seen this post and are investigating a few device health related issues. One of them that started late last night and is related to device control and reporting. This issue is mentioned on our public status page and is actively being worked on.
We’re also looking into the issue where devices are offline but controllable and reporting. At this time it doesn’t appear to be related to the beta firmware and our Device Health team is actively looking into it.
We’ve been looking into the other issues that have been reported and debugging them one by one. Thank you for the reports and assistance in tracking down issues.
@tpmanley
Is it possible that these issues are affecting zwave direct association?
I have 3 linear aux in wall dimmers that are master, that I use in 3 different places for 3 way lights.
The behavior is almost like the CPU in the master and slave are at 100% and commands and delayed and queued up.
I can click several times let’s say on and off, there might be a delay, and then can see by the status led on the switch that it then slowly sends that many commands to the slave switch.
I used to be able to use the master switch to dim the slave lights. Now the response is so slow I can only turn the slave on and off, because holding the master to dim up or down is delayed then sets the slave to either full on or most dim.
So again on the master side, I can click on the paddle, but if I click more than once it seems to queue up the commands which I can see later going out by the flash of the status led.
Okay, I just remembered a setting that might cause something like this.
But how did all three get their settings corrupted?
I just remembered that these switches have association groups, it sends to association group 1, then waits some amount of time, and then sends to association group 2, etc.
My direct zwave association issue might be fixed. I used zwave tweaker.
Each of the 3 master switches had extra devices listed as slaves.
All the extra devices’ IDs just happened to match “ghost” devices that appeared this week that I had to request support to remove.
Each master only ever controlled 1 and only 1 slave. So it is unclear why multiple devices where listed for each target association group in each switch.
back in 2015 I accidentally added 3 devices instead of just 1 into each switch. But for over 2 1/2 years it did not matter until this week, when suddenly something changed and those extra devices cause problems
those extra devices somehow got added this week, when The problem started.
I’ve been noticing similar behavior with Schlage locks. It hadn’t really been an issue until last night. Lock was " unavailable" when good night routine ran, so it didn’t lock. When lock came back online it ( correctly ) reported unlocked, so welcome home routine ran. Turning on lights, disarming SHM, etc.
Those zwave switches never go that long for Last Activity, typically it’s an hour, and then anything past that I’d typically see the erroneous offline message.
For the first time ever I see my dimmer show up. You can also see my lock as well. The lock was manually used much less than 13 hours ago (5:25am EST to be specific).
My water valve has also been rock solid for months, and now it’s gone wonky.
Something has to have very recently changed, but not for the good unless something else regarding last activity and offline/online status are going to be used/displayed differently than in the past.
So 5 hours later I’m trying to get the Foyer Lights working…
In the app (classic) I can turn it on, but not off because the state doesn’t update, BUT Alexa will turn it off - followed by the message “Foyer Lights isn’t responding. Please check network connection and power supply”. Once she turns it off, I can turn it on again via the app, but not off. This is easily repeatable.
I fixed this problem by using the air gap switch. Once I did that, it started working again:
All the other devices in the first pic above started working on their own, but now I have new offline devices down for a few hours I should track down…
EDIT: I just had to do the same process on another device, Steph’s Ceiling Fan:
Sorry to interject here, but with a good number of posts and complaints and confusion in the past week or so, this seems like the best thread to ask about this:
What is SmartThings stance on Device Health support for devices using custom device handler code?
This capability uses the state checkInterval to track the device’s health. In the device handler above, the device is checked every 12 minutes (60 * 12) which displays as 720 in the IDE. This device is polled every 5 minutes so 12 minutes allows for two missed checks and a small buffer.
and Jim added this:
In case you look at other Device Handlers, you might see that certain devices that support the “Health Check” capability (which defines the checkInterval attribute) don’t actually send a checkInterval event. There is currently inconsistency in how the device status is reported across devices, with some devices using checkInterval and others using a different event.
The plan is to consolidate and make the usage consistent, but in the meantime just don’t get too confused if you see different devices doing it differently
I’ve followed the above and some reverse engineering from the public GitHub and added device health to some of my more import custom handlers. Works well.
Okay, so does that mean Health Check is not yet supported for use in custom device handlers?
Without documentation, looking at official device handler code, it appears there are two elements: the checkInterval event that sets up the time interval for device health checks, and the ping function that uses some kind of read command (e.g., readAttribute if a ZigBee device) for performing the actual check. Is that correct?
Also, I’m wondering: If (for whatever reason) a device doesn’t support a read command as a polling method, then does that mean Health Check should not be used with it?
Well as Jimmy mentioned above, it is possible to incorporate it into custom device handlers. So I wouldn’t say it isn’t supported. It just isn’t documented so that it can be easily incorporated by community developers.
I spoke with a dev more familiar with device health and he said for Zigbee/Z-Wave DTHs, you should use the Health Check capability and a ping function. For cloud-to-cloud/LAN devices, there are some enrollment/status events that should be included in the initialize method. Similar to this:
