Feature Request: Device State Affector

Maybe this is going too far, but…

Could you please add a device state Affector property? This would be the initiator of the current state of the device.

Use-case: I want to know whether a switch was turned on by a manual action (Physical Switch, Voice Command, app UI Button Tap) or via some remote trigger/routine/scheduler (IFTTT, Smartapp, Routine, etc), and be able to make decisions based upon that when defining Routines.

1 Like

This is partially already available via the Event object.

Refer to the “isDigital()” vs “isPhysical()” properties.

As for the other various definitions of “manual” vs “SmartApp/Routine” … I think that is expecting a lot and is violating a fundamental abstraction of the platform.

i.e., I can’t think of good reasons why that information should be needed or used.

1 Like

Having a differentiation between the Physical actuation of a device vs Digital actuation is insufficient. We also need to know whether there is direct (non-Routine, non-scheduler, etc) actuation of a device via digital means that equates to manual actuation.

I don’t care if I hit a physical switch on my wall, press a UI toggle or press a button/momentary switch, my INTENT is what is significant. In all these cases my intent is to manually toggle a switch outside of a non-manual trigger. It may satisfy isDigital(), but that does not cover my intent. We need an isManual() property as well (which could very well overlap isPhysical() or isDigital()).

In my opinion, that is a very good reason to provide an additional property that would not violate abstraction. Identifying the source (Affector) is not as significant as more comprehensively providing means to identify intent.

Does that make more sense?

It makes a little more sense, but I think a lot of people will be lost here without 3 or 4 real world examples.

I hesitate to even guess at an example, but here goes:

  • a lightswitch that is turned on by a schedule (sunset) or by a motion sensor is a candidate to be turned off by a similar automation, such as sunrise or motion stopped.

  • the same lightswitch, if turned on “manually” via a physical switch (isPhysical) or manually triggered SmartApp (Alexa, ActionTiles), may perhaps no longer be considered “automated”, temporarily, so that the scheduled or motion stop does not override the Intended Manual Override.

If I understand correctly, then I agree there’s potential value, but the complexity likely outweighs the value by far. The concept needs to be extremely closely examined and various ways of implementation (or alternative solutions) evaluated.

It would be wise to not hold your breath… But it doesn’t hurt to discuss & brainstorm.

LOL. I hear ya.

And, yes, that was a perfect example. Currently the platform does not support ad-hoc manual overrides for schedulers and other forms of automation. Most manual toggles by default/definition carry some override intent. It would also normalize how manual overrides are determined outside of physical switches for the purpose of Smartapps and DTH’s.