Know when a power socket has tripped, thoughts?

SmartApps & Automations Automation Ideas
#1

Scenario, In my utility room i have a power socket with a built in circuit breaker. Connected to this is a HVAC condensate pump which I just so happened to have issues with and it tripping my socket (meaning it was no longer available to pump).

I want to ideally connect a smartthings power outlet into this socket and the pump into the smartthings power outlet. I think want to basically monitor the last time ST heard from the socket and if it was say greater than 5 minutes send a notification.

Sounds simple but doesn’t seem so easy.

My thoughts were as follows, modify the STs outlet device handler to self ping itself and store the ‘last updated time’ in a state variable.
I can then create a custom smartapp to monitor this last updated time state and pop a notification if greater than a given time.

I would be interested in peoples thoughts? Is there an easier way?

I had tried adding runEvery5Minutes(handler) into the device handler but it seems this function is only available in the SmartApps.

I am just exploring zigbee.configureReporting() as a possibility right now.

#2

Zigbee devices don’t ping themselves or any other device except the coordinator. So that approach isn’t going to work.

But there are several “wellness check” smart apps that would probably give you what you want. Most of them just look for the most recent event in the logs, which reduces traffic on the network and is usually sufficient.

Here are a couple to look at.


.

.

#3

Really appreciate the response.
The problem is this socket only really reports on state change and that should never happen so there is very little noise raised.

Is there no way I can send a zigbee device a ‘refresh’ command and just log that inside the device handler?

#4

First, I think you’ll find zigbee devices report a little more often than you think. There’s typically a check in process with the Coordinator.

Another option would be to get a power socket which reports on energy usage. You can set how often those report, and so you could easily create an event that way that could be tracked in the log.

In general, if you force reporting often enough to be useful for what you’re envisioning, you’re going to flood your network with polling messages. That could result in problems all over the mesh. The usual rule of thumb is to limit polling to 5% of total traffic.

An entirely different approach, of course, would be to use a WeMo pocket socket or another Wi-Fi device. Those have constant connection and device monitoring is much simpler.

#5

interesting. The socket i have is a Smartthings power outlet, it has energy usage built it but I cannot seem to trigger it to report more often.

I am only asking for say polling every 5 minutes, nothing killer in terms of the total traffic.

#6

I don’t suppose you know what

capability “Health Check”

is? It is listen in various device handlers but no documentation on it.

#7

It’s an undocumented capability.

@Jim

1 Like
#8

That capability is under development; it’s not supported, hence not documented :slight_smile:

#9

replace the pump or the circuit breaker - sounds like it’s failing. A residential intermittent pump should not be drawing enough to trip a circuit unless the circuit is already overloaded.

1 Like
#10

I’m pretty sure that’s the purpose of configureReporting.

I’ve never worked with a Zigbee device that I wasn’t able to make it report on a regular interval. Although if you turn off a Cree Connect Bulb and then turn it back on, it won’t start reporting again on its own.

There doesn’t appear to be a way to do this with Z-Wave devices unless they support the wakeup command class.

The example below will make the Zigbee device report the switch state every 10 minutes.

configureReporting(0x0006, 0x0000, 0x10, 0, 600, null)

#11

That’s reporting to the coordinator, as I mentioned. From that link:

The last part of the message contains the hub’s ZigBee id which is set as the location for the device to send callback messages to.

#12

I’m not seeing anything about this “coordinator”, but if I set it to report every 10 minutes, are you saying that it will still report even if the device stops responding?

#13

The SmartThings v2 hub is a white plastic box that contains four network devices: an ethernet connector, a Bluetooth radio (currently not enabled), a zwave controller, and a zigbee coordinator.

In most of the documentation, it will just say “the hub” when it means either the zwave controller or the zigbee coordinator depending on the context.

http://community.silabs.com/t5/Wireless-Knowledge-Base/What-is-the-difference-between-an-end-device-a-router-and-a/ta-p/113449

In ZigBee, there are three different types of devices: end device, router, and coordinator. The key difference between these is that an end device can not route traffic, routers can route traffic, and the coordinator, in addition to routing traffic, is responsible for forming the network in the first place. Every network must have one and only one coordinator. These differences dictate the different features of each type of device.

So in this sense, the ST hub is the coordinator. :sunglasses:

#14

That explains why I’ve never heard of the term “coordinator” before.

You didn’t answer my question…

#15

I was just trying to answer the question precisely, sorry if it came across wrong. Since it is a multiprotocol platform, Smartthings makes up its own terminology. (it makes me crazy that they say zwave has “clusters” since it doesn’t, that’s A zigbee term, but so it goes.).

“Coordinator” is the standard zigbee term, but SmartThings doesn’t usually use it, they just say “hub” for everything.

And if the end device is down, it doesn’t report. It’s reporting to the coordinator inside of the SmartThings hub.

As far as exactly how SmartThings implements all of this in its abstraction layer, maybe some of the smartthings/zigbee experts like @johnr or @sticks18 can do a better job of explaining with ST examples. Since I can no longer read code (I depend on text-to-speech), I can’t really help with those. :sunglasses:

#16

I agree, already done that of course but this got me interested and thinking how would I go about monitoring something like that.

1 Like
#17

I realized that after re-reading what you wrote.

Wouldn’t that mean that configureReporting is a viable solution to the original problem that was posted?

1 Like
#18

See I wondered about configurereporting, I gave it a shot also but couldn’t get it to do what I wanted.

#19

I have an initial solution all be it a horrible one but it works.
I took the template device handler from the Smartthings socket and modified it to have a ‘estimatedTimeToArrival’ capability (it takes a date) and then I send an event that is the time of the last update. This is the only way I could see to communicate between the two.

Then I have a custom SmartApp which sends a ‘switch.on’ every 5 minutes to the device, the socket is on and I always want it on anyway! So this just forces the device handler to send a date back to the app, at which point I store this as the last update time.

Then obviously in the app I can compare the last update time vs the current time on a timer and push a notification if it is larger than I would like.

#20

Assuming that the device supports reporting, if you turned the reporting on, you should be able to use a SmartApp like the Simple Device Viewer to send you notifications.

The Simple Device Viewer checks the device for last event, like most of the other monitoring SmartApps, but it also checks all the attributes for the last state change so it will detect the activity even if the events not displayed.

The simple device viewer can also poll the device at a regular interval.

1 Like
© 2020 SmartThings, Inc. All Rights Reserved.