No OFFLINE value? Why?

luisenriquereyes · August 22, 2019, 8:52pm

Hello everyone. Am I doing something wrong?

I have successfully created trigger events when a switch is On and Off and the Actions run without problems.

But I it looks like I don't have the option to create a trigger event when the switch goes OFFLINE as you see in the picture:

The switch is a Kasa HS110 smart wifi plug.

ogiewon · August 22, 2019, 8:54pm

Probably because "Offline" is not a valid state per the Standard Switch Device Capabilities documentation. Only 'on' and 'off' are valid.

Switch

Device Selector

capability.switch

Driver Definition

capability "Switch"

Attributes

switch - ENUM ["on", "off"]

Commands

off()

on()

JasonJoel · August 22, 2019, 8:55pm

Exactly. That custom driver shoves OFFLINE into a field it shouldn't - that's why other parts of hubitat don't recognize it, as that field should never have had that value in the first place...

luisenriquereyes · August 22, 2019, 9:08pm

Thanks. Any ideas on how I can trigger an action when this switch goes OFFLINE?

I thought of using the energy line but it always reads the same around 0 while on, off or OFFLINE.

bertabcd1234 · August 22, 2019, 9:17pm

I think the best, most "standard" solution would be to fix the driver so switch reports on or off as it should, then you could add a custom attribute to report the online/offline state however you want (not sure a standard capability fits with that, but one of those could certainly work too if there's one that's appropriate).

But I'm assuming you didn't write this driver, and perhaps you don't feel like (or know how to) modify it yourself. In the meantime, you could probably use "switch changed" as a trigger in RM and in the actions do a test for a custom attribute (it's an option--not the standard switch capability attribute) to see if "switch" is "OFFLINE", but that's just a guess. This driver is likely to cause problems other places, however (e.g., as a switch tile on a Dashboard), so I'd really recommend fixing it in the long term.

luisenriquereyes · August 22, 2019, 10:15pm

Thanks. I will try to contact who created the Kasa smart plug drivers to see if they can update.

djgutheinz · August 22, 2019, 10:25pm

Got the message. I will have an update out by the end of the month. Of course, if the device is off-line, then the state is not necessarily valid and a rule may do the wrong thing.

Changes coming:

Add attribute commsError (true/false).
Add routine to automatically recover comms (5 tries only) on commsError.
Clear comms error on successful receipt of message.

SoapBox: It seems it would be good to have a state of offline for a device switch. You can not set it to that state; however, in rules, such a state needs to be known.

djgutheinz · August 22, 2019, 10:55pm

I had an update with comms re-transmit on error already done. Just needed to change 3 lines and test on 3 different device types.

GitHub is now updated.

luisenriquereyes · August 23, 2019, 3:59am

I applied your updates and they worked. Thank you. But I did spend time trying to figure out why after selecting the commsError attribute I was not seeing the "Select enum value (text)" field to be able to type either false or true.

You have to first select the Switch attribute and then select again commsError so the "Select enum value (text)" field becomes available. Seems to be a bug.

For the Kasa HS110, can I set the Refresh Interval to be 30 seconds?

In the Devices settings page the smallest setRefreshInterval is 1 minute:

Ryan780 · August 23, 2019, 6:07am

The only way that you can know if a device is offline is if it doesn't perform a routine function. There is no other way for the system to know whether it is online or not. So, in the case of energy monitoring plugs, this might be possible if there is a load on the plug that varies enough to cause it to report. But you would have to build a custom driver to have a function like that. Do you understand that your devices don't routinely "check-in" with the hub that frequently, in the case of battery devices, in order to save power. Any type of forced polling is going to cause your batteries to drain much, MUCH quicker.

njanda · August 23, 2019, 10:02am

And load up the Hub. It’s no power house so whilst its busy polling, it might not be doing other things, monitoring other events.

djgutheinz · August 23, 2019, 12:45pm

You are incorrect. The comms error is AUTOMATIC. The Set Refresh Interval is for sub-1 minute refresh for devices that

will start a rule when activated, AND
are often controlled through non-Hubitat methods (i.e., wall switch, Kasa App
It should not be used otherwise.

luisenriquereyes · August 23, 2019, 2:43pm

What do you mean when you say the comms error is AUTOMATIC?

When I select it first as an options instead of selecting the Switch attribute first, null is how it appears as you see here:

With null the Action does not run. But it does with true or false.

djgutheinz · August 23, 2019, 3:35pm

Within the driver itself, the communications error is detected and handled automatically, as follows:

On initial installation, the attribute is null
Once a command is set, the attribute will be set (eventually) to true or false
1. if the command resulted in a valid response, it is set to false immediately
1. if the command fails, it will be set to true after (up to) five retries of the failed command.
Once the attribute is true, it will remain true until a command executes successfully and results in a valid response. It will then be set to false.
if the attribute is true, there is nothing you can do automatically to clear the error (other than try another refresh). Troubleshooting may be required.

I can't and won't address rule machine; My interface ends at the device driver. However, when the attribute is true, something is wrong, usually,

The device's IP has changed
The device is no longer powered
There is some intermittent error that may clear by itself.
(unusual) the hub is at fault and requires reboot.

The user will have to troubleshoot. Some checks:

Try to control the device in the Kasa App. If you can't, the device is unplugged or failed.
Check the IP address on the device's page and your router or run the hubitat application. (running the application install or list devices updates the IP on the existing devices.)
Go to the device's page, turn on debug logging. Open a logging page and try to control the device. If you do not see anything, then try rebooting Hubitat.

It is STRONGLY recommended that you use static IP addresses for devices.