Opinion on next state and physical only switches

Trying to get a handle on how people feel about these things. The “next state” is used to give an immediate feedback in the app that you are changing the switch. So if it’s on, it immediately changes to “Turning Off” and then once the switch actually processes the action and sends back the reply, the app will get updated to reflect the new state, which would be “Off”. It’s an aesthetic thing, really, and in my local testing it fills the gap of something around .8 seconds. With next state, I know something’s happening, etc. Without it, I don’t see my action “acknowledged” for almost a second. So my first question is - does that matter to anyone? Does anyone care for that nuance or is it kind of a “meh” thing, as long as the switch works?

The corollary to that is what if there was a preference in a switch handler to disable digital control of the switch? In other words, you couldn’t turn it on or off in the app, but if you physically went to the switch, it would still work. I guess the use case on this one is people using smart bulbs where they don’t want the power to ever get cut to the bulb. I really don’t understand this scenario, but I’m asking in general to get an idea. And, also, with this type of operation, if the next state isn’t disabled, it’s a bit of a mess.

A lot of this comes from an old study on UI design back in the 1980s called “the conversational pause.”

It has to do with how long will most people be comfortable waiting before they feel that they are supposed to do something, which back when the study was done meant hit another key on the keyboard.

It turned out that the length of time people were willing to wait was pretty much the same amount of time they would remain quiet during a conversation with one other person before they begin speaking themselves. Hence “the conversational pause.“

And it turned out that in the United States, A good average for that was right around half a second. It did vary from subculture to subculture, and of course for some individuals as well, but in general people did not feel it was rude if the second person started speaking after the first person had been quiet for half a second. But they did feel it was rude if the person started speaking earlier than that. And you did get into the “awkward pause“ situation if both people were silent for more than about two seconds.

I know it seems like that would be really short, but try it when you were talking to someone. The full second can start to feel really long.

So a lot of computer UI’s started showing people something within a half second of the initiating action, even if the action itself was going to take considerably longer.

You can do that with “next state” Or any kind of “request received” indicator. But its main purpose is to keep the person from hitting the icon a second time, which can be particularly problematic if it’s set up as a toggle.


As far as locking out the action from the app, that’s actually very common use case for “kiosk mode“ or some other control panel apps where it’s OK for a person to see state but not to change it. Like not letting the kids disarm the security system, but letting them know that it is armed. Or not letting the eight-year-old turn off the light in the six-year-old’s room. :wink:

In fact, there’s nothing in SmartThings specs that “allow” transitory States for enumerated Attributes.

“turnug on” / “turning off” are not used by most Switch Handlers. Like ActionTiles, the UI changes immediately to the expected Statr (on/off) and eventually may correct itself depending if it checks the Device.

Why not just use a dumb switch then?..
I presume you still want Automations to be able to digitally control the Switch and/or you want to use the Switch as a “Sensor” to control non-physically connected Things?

The UI portion (definition block or in New API - “plug-in”) of a DH is distinct from the rest of the DH. You can absolutely write a DH such that the UI is view-only.

But if you want to allow any Automation, then you can’t block Scenes and Light Groups, which would thus grant App users access to the Switch control.

Yeah, I guess that’s an affectation I picked up because I’d rather the app follow the switch than vice versa. The intermediate status tells me an action is pending but hasn’t been acknowledged yet. Otherwise, the app might think the switch is off when it’s not and won’t change until something comes along to update it. If I see turning off for more than a second or two, I know something is awry.

The catch is having it be able to go back and forth between being smart and dumb. Making a dumb UI is easy, but making one that can toggle is where I get stuck.

And, for the record, this isn’t my idea - it was something someone asked me for. :slight_smile:

The most popular API (“legacy Groovy”) for DH development has some significant limitations. You can possibly implement the desired functionality, but it might be inelegant, quirky, or unreliable.

For example, you could add an extra Attribute(s) to set whether or not you are in “smart” or “dumb” mode for the Switch. This Attribute might be controlled only by a SmartApp (perhaps linked to a Virtual Switch, or controlled by WebCoRE, etc.).

The "on() / off()" methods of this special Switch would check the status of the smart-dumb mode Attribute as a condition to determine whether or not to issue actual messages to the physical device.