Is there a neutral door status so a routine open/close option will always fire?

devicetype

(Brian) #1

I’ve got a device handler with garage door capability. My limitation is I don’t always know what the door’s true status is (open vs. closed). However, this shouldn’t really matter as all I need to do is call the open() method or closed() method whenever I want that action taken, regardless of the door’s current status.

My problem is that Routines in SmartThings are too aggressive in checking the door’s status before performing an action. If the routine thinks the door is already closed, it will simply say “I confirmed the door is closed” and will do nothing. I have tried setting the door’s status to “unknown” but the routine still does nothing.

Is there any way to set a door’s status to some neutral value so that a routine will always open or close the door regardless of current status?


(John) #2

Change it to a momentary switch so it’s just triggered (state should be ignored). Then do whatever you need to do.


(Brian) #3

I still need to differentiate between an open and closed command to know what the user wants the door to do because I’m specifically sending either an “open” or “closed” command to the door’s API.


(John) #4

If a DH is to do it automatically (as in choose which one), then it’s state must be known. If a user is required to determine state, then automating may not be the best choice. What if two handlers were created (one for open and one for close)? For example, the away routine could call the close button.


(Brian) #5

My current alternative is creating 2 momentary buttons - one for open and one for close that essentially does the same thing you suggest with two handlers. But that’s just really clunky. I just want a user to be able to select “open garage door” in a routine and have that always hit my open() method regardless of whether or not the routine thinks the door is already open.


(John) #6

Agreed, but without knowing state, that’s how I would do it. Can a contact sensor be added to provide state? You could tie them together creatively (with a SmartApp), and then the problem is solved.


(Robin) #7

If you use the CoRE smart app there is an option to disable command optimisations:

You can setup a CoRE Piston (rule) to trigger when a routine runs. With optimisation disabled it will send your chosen command regardless of the perceived state of the door.


(Brian) #8

Yes, and in many cases users have contact sensors tied to the door. But a lot of people don’t want to have buy a separate sensor if it can be avoided.[quote=“RobinWinbourne, post:7, topic:72202”]
If you use the CoRE smart app there is an option to disable command optimisations
[/quote]

I suspected CoRE could do this. Thanks for confirming. I wish there was a way I could do that same thing with the stock Routines, but I’ll just have to recommend people go that route if they don’t have a sensor on the door.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #9

On Garage Doors and Locks, a contact sensor (or Tilt Sensor) is highly recommended.

In the case of a Lock, for example, without a Contact Sensor first verifying that the door is closed, SmartThings could easily throw the bolt into empty air (ie, outside of the jamb) and thus give a highly inaccurate impression that the door was locked.

In the case of a Garage Door, it could also be jammed partially open or stuck closed and a Sensor is invaluable.


(Brian) #10

That makes sense for most doors and locks. In my case, however, my open/close methods just make an API call and the door vendor has code that handles the actual mechanics of controlling the door and making sure it only executes a valid and safe command.


(Robin) #11

I think the point @tgauchat was making is that if the mechanism fails, the door could be left open and you wouldn’t know about it.