Device Health for third party handlers?

Developer Programs Writing Device Types
1

First, I would like to thank the SmartThings team for developing this very important feature.
It helped me catch 2 sensors dropping off the network.

At the mean time, I wonder if there is a way to integrate this new feature into community supported device handlers?

1 Like
2

I believe some people have by reverse engineering the standard handlers, but there isn’t any official documentation yet akaik.

3

I’m looking at the official handler code repo already, but it would really be great if they can update their docs.

4

I think all that’s needed is

to add
capability "Health Check"
to metadata

and add ping() method

def ping() {
return zigbee.onOffRefresh() or zwave.switchMultilevelV2.switchMultilevelGet().format() or whatever makes sense for the device
}

5

I believe things there are still some internal issues with health check which is why they haven’t released the docs yet. @Jim can throw some light on this

1 Like
6

Basically the API is not stable/mature yet to support third-party development. As noted, you can reverse engineer it if you choose to. Doing so does mean taking the risk that if/when there are changes to the API, you may experience issues (there won’t be advance notification for any changes until it is supported/documented). Also with Device Health be aware that if a device should get into an OFFLINE state incorrectly, and can’t get back ONLINE, deleting and re-adding the device may be your only solution.

I really want/wish this could be documented and supported, but it’s not there yet. I have no timeline when it may be.

tl;dr - reverse engineer and use as long as you are OK assuming the risks with doing so.

3 Likes
7

Thank you for your detailed explanation.

For whomever interested, I concluded the following after my experimenting with a third party zigbee motion sensor(not officially supported device):

  1. Add capability "Health Check" in metadata

  2. Add

def installed() {
// Device wakes up every 1 hour, this interval allows us to miss one wakeup notification before marking offline
	log.debug "Configured health checkInterval when installed()"
	sendEvent(name: "checkInterval", value: 2 * 60 * 60 + 2 * 60, displayed: false, data: [protocol: "zigbee", hubHardwareId: device.hub.hardwareID])
}

def updated() {
// Device wakes up every 1 hours, this interval allows us to miss one wakeup notification before marking offline
	log.debug "Configured health checkInterval when updated()"
	sendEvent(name: "checkInterval", value: 2 * 60 * 60 + 2 * 60, displayed: false, data: [protocol: "zigbee", hubHardwareId: device.hub.hardwareID])
}
  1. Add Ping(Optional? My battery operated device cannot be pinged manually so I cannot tell, may will be called if check interval missed)
/**
 * PING is used by Device-Watch in attempt to reach the Device
 * */
def ping() {
	return zigbee.readAttribute(zigbee.POWER_CONFIGURATION_CLUSTER, 0x0020) // Read the Battery Level
}

My device report unavailable after 2 hours of silence(battery removed), exactly what I want.

3 Likes
8

I did realized why device health caused frustration and confused some people from time to time.

So the delay in monitoring device events or execution of commands for devices can both cause device being reported as unavailable, which is interesting enough, can sometimes caused by Smartthings cloud.

Since devices events are processed by cloud you may see false alarms, not because your device is actually not responsive in certain period of time, but due to the fact messages from device haven’t been processed by Smartthings.

Besides it seemed hard to use fixed time period as check interval. Not all devices are designed to report at same frequency.

9

I think @Jim said that in in post, you may want to re read the whole post. Once you go offline (even if due to ST cloud issues), most likely you’ll have to exclude and repair to get back online again.

10

@Jim - So its been over a year. Surely something is documented about this by now? Any info you can provide?

11

@RBoy @Jim

RBoy, I do not think this is what he meant. I think he was saying that a third party device handler developer could write buggy code that may be written as to disable the device. I do not think he is saying that any device that is offline cannot be gotten online again without an exclude and re-include.

@Jim is this what you meant?

If this is what he meant, then for example, suppose I have a plugin outlet that is included and has smart things automations.

If I decide to move it to another part of the house, if I take too long to plug it back in, I lose all automations and need to exclude and re-include again.