I just set this device up and I guess I need to RTFM as it doesn’t make sense to me out of the box.
I assumed that when you pressed the button within SmartThings that it would automatically transition between the states. Eg. if it was currently closed → opening → open
But when I pressed it, it went Unknown → Closed → Closing → Unknown
Those same states were reported to SharpTools as expected, so at least that parts working. That being said, the really quick change to closed before it went to closing is concerning. If two events happen nearly instantaneously, there’s potential for a race condition depending on how it’s implemented. The door, lock, and contact attributes are attributes that we handle specially and enforce ordering based on their event timestamps, but SmartThings has been a bit wonky with timestamps on certain devices so I suspect that could be in play here.
The bottom line is that quick change to ‘closed’ before going to ‘closing’ is concerning… as is the oddities I’m experiencing with the driver with a fresh setup.
You can add it to the thread. I tried to explain yesterday, but the developer has a different idea about it…
It kinda drives me mad, what is more logical than a button to operate the door, a contact sensor to show the state of the door, and in my case, another sensor to be sure of an open or closed state. In between those states, depending on which sensor last opened, I get closing or opening. For the normal time it should take for the other sensor to close. It’s perfect…
No, you operate the door by changing the state of it, then it guesses if it’s fully open after x seconds and all the contact sensor does is show if the door is closed.
I for one, think it’s quite handy to see that when it’s not closed, if it’s fully open or not. Then at least you know it’s not stuck halfway and you can try to operate it again.
I’m assuming you’re using this with corresponding rules (the example is in this forum link)? I don’t have that behavior as long as I have rules that have set the “door” open or closed according to a contact sensor.
It does this out of the box until the corresponding rules have set the status correctly (or at least to something).
That being said, I have gone ahead and made a fairly usable super tile using a variable set by a new “Garage door status” rule to get the effect I want. Took some work, but works for now
Would be good to get the right actions/status along the road…
The “partially open” status using two sensors is not part of this driver, but I completely understand your use case. RboyApps used to have a DTH Garage handler that did this, I was looking for that as well, but decided “partially open” was basically the same as “open” and would require the same action for any security threats I could think of.
I was thinking about this, and I think with a super tile you could get the effect you want with a “GarageStatus” variable, and some rules which set the status based on your door sensors.
For the rules, something like this:
When any of the door sensors change
If OPEN sensor is open, set “GarageStatus” to “Opening”
Wait (x seconds, whatever your door opening time is), then if CLOSED sensor is closed, set “GarageStatus” to “Open”
If CLOSED sensor is closed for (more than your door opening time is), set “GarageStatus” to “Closing”
Wait (x seconds, time for door to close), then if OPEN sensor is closed, set “GarageStatus” to “Closed”
And probably some other “if” clause for “unknown” or “Partially Open” as well.
Hopefully, that makes some sense, this is something I just did, but I only have one sensor, and I have a garage motor relay that is “on” for open, and “off” for close so that helps with reporting status a bit better.
I’m sure some tweaking might be needed, but it should get you closer to your goal.
Then you can go ahead and make a nice supertile based on those variables.
I was interested in the button, since it would run it all local, less variables, just a cleaner solution.
Ps: I tried and the “open” and “close” command in Sharptools, seem to be connected to the opening and closing in Smartthings. It runs my door with those commands.
Is your SmartThings routine triggering your relay with “Door: Open” or “Door: Opening” - I could only get the SharpTools tile to work with “Door: Open” but that’s not how the driver is designed to work, it would just set the door status to “open”, but my trigger for the relay in SmartThigns is for “Door: Opening”. If I use “Door: Open” for the trigger I will run into the issue where the relay is triggered as soon as the door opens, and when the status changes, thus twice, and thus it stops before even moving a few centimeters
After reading the linked thread, I understand using a physical relay to actuate the door and a separate physical sensor to mark the real status of the door… but the implementation is really weird to me. There’s only commands exposed for controlling the door but they aren’t mentioned in the example. In the examples provided, there’s some unique implementation being used that exposes setting the door / contact sensor state directly within routines. I find it quite odd that it’s being done that way rather than through a custom command (eg. closeContact() / openContact() or something like that).
A rule or using the tile? I didn’t try a rule, I just used the “thing” tile default options using the “door control” layout. Toggling the tile doesn’t do anything since it toggles only “open” and “close” status rather than “opening” and “closing” as the routine and driver require…
Nonetheless, I got a good work around with a Super Tile… so I’m happy now.
That’s what bothers me, you’re setting states instead of logical consequences of certain events.
But my head is stuck in that “opening” is a state in which the door is busy opening. Apparently that’s not a state, but the action that opens the door.
Ps: I’m not fluent enough in abbilities and states to say for certain whom of us is right
Yes the wording is strange. Really “Open” and “Close” should be “commands” while “opening” and “closing” should be states. At least in my opinion. However this driver implementation does solve the problem of a double-relay activation, which was my main concern and issue from before. Although I’m sure there’s a better way to word it and to confirm “closed” and “opened” (based on contact sensor status) as additional states, and leave “open” and “close” as commands only.
In other words, I imagine something like this:
Open - Command to do something (if open then activate relay) Close - Command to do something (if close then activate relay)
Opening - State of the door after moving from “opened” state for X time or until 2nd contact sensor is closed. Closing - State of the door after moving from “closed” (if using a contact sensor) or “Close” command is issued for X time or until 1st contact sensor is closed.
Opened - State of door is opened based on 1st contact sensor open (and if available 2nd contact closed). Closed - State of door is closed based on 1st contact sensor closed (and if available, 2nd contact sensor open). Unknown/Partially open - State of contact 1st sensor is open when door was “closing” and never closed (or if available both contact sensors are open).
I feel the developer is more interested in a label maker than an actual garage door replacement device.
Oh well, in Dutch it’s even worse btw. Instead of opening and open, I have “openen…” and “openen”.
Which doesn’t even need translation to see what’s wrong
That’s loosely how a device should be implemented and from the developer’s description, it sounds like it’s loosely how things should work.
If you check the SmartThings doorControl capability documentation I linked in the other thread, you’ll see this as well.
In general, the concepts of command and status are separate from each other, but have a natural linkage. You send the open() command to a device and it sends the relevant command to the device (eg. sending a z-wave or zigbee signal to the device telling it to actuate the relay to open the door). With doors, they’ll often immediately go into a opening or closing state as long as the command went through. Then its not until the sensor on the device physically changes state and sends a signal back from the device to the hub, that the state changes to it’s final position of ‘open’ or ‘closed’.
Commands:
open()
close()
Attribute States
door
closing, closed, opening, open
And an unknown state as many devices want to have a fallback state if the device doesn’t change from opening or closing to the next state after a period of time.
I’ve played with the driver a bit more and it seems to work as the developer intended (and as I briefly described above).
For my initial test, I setup a single rule to manually actuate the garage in a specific direction. Basically send the open() command to the door, wait 3 seconds, then update the state of the contact as open using the sync() command which internally updates the door status accordingly.
Of course, the contact sensor side of things should actually be getting updated by a real sensor… and the door itself needs to be opened which is why they suggest reacting to the interim opening or closing status to activate the relay attached to your garage.
–
And for my case, I wanted it to be a completely virtual garage door not attached to any real sensors or relays in which case I removed the previous test rule and then handled everything directly within a rule:
The enum values don’t seem to be reported correctly for the sync() command, but the developer indicated that they should be open or closed, so I used an inline expression to keep the rule short and sweet and send the relevant next status based on the triggering opening or closing status that started the rule.
That all works as expected for me. I just add the tile to my dashboard, change the Tile Layout to Door Control Tile then I can actuate the garage door directly from my dashboard:
On my example dashboard is the same Virtual Garage device with (left to right) Lock Tile, Door Control Tile, and Contact Sensor Tile layouts. I added each of them as I was trying to better understand how each attribute/capability worked and how the developer intended things to work.
Of course my particular rule would not be used for someone who wants to control a physical garage door - eg. someone who wants to combine their physical relay and physical sensor into a virtual garage device.
I just set that rule up so I could simulate the whole process end-to-end virtually. The device author’s originally suggested routines should work.
