Request desired state

[adriangibbons]

Hi @andrewshilliday - thanks for sharing this project :+1: I have it up and running as designed!

I'd like to adapt it to take into account the current state e.g. if I tell it to open the garage door and it's already open (or opening) then don't do anything.

It's so I can introduce it into my home automation and use a webhook like: http://192.168.0.100:8081/clk?id=left&desired_state=open or similar

Any pointers you can provide or ideas how this may be done? I'm happy to take a crack at the code but I'm not that familiar with it (or Python in general).

For example if I arrive home in my car, I would like it to be triggered to open if it isn't open already.

Cheers, Adrian.

[adriangibbons]

Played about with it this weekend and got something working, even though the UI hasn't been updated to reflect the new code.

[andrewshilliday]

Hi again. I responded to your pull request, but for better tracking I'll repeat my comment here.

My concern with this feature (and the reason why it wasn't originally included) was that the sensors do not provide perfect information about the state of the garage doors and as such, we can't know whether toggling the relay will result in the door opening or closing. For example, if the door is halfway open, the sensor will show the door as open, but if we toggle it again, it might open, or it might close.

The only way I could think of to implement a desired state, then, was to push the button, wait some specified amount of time and then see whether we hit our desired state, if not, push the button again and wait again. I was a bit uncomfortable with this approach so I abandoned the feature.

If you have a better approach or a reason why you think this is acceptable behavior, please respond.

[adriangibbons]

Hi @andrewshilliday - isn't there actually four states? Open - Closing - Closed - Opening ? At least I see these in the syslog...

Therefore, if the door is halfway open, we would know whether it's Opening or Closing and perform the right action?

Rather than waiting a specified amount of time, my initial approach was to just to ignore the toggle when doors are in the state 'opening' or 'closing' if state == 'opening' or state == 'closing':

Though I think that it could be made to be a little more sophisticated. I.e.:

• Still fire if desired_state is "toggle" regardless of whether opening or closing.
• Still fire if opening and desired_state is "closed"
• Still fire if closing and desired_state is "open"

What do you think of that?

[andrewshilliday]

Yes and no. The opening and closing states are transitional states, in that the controller isn't being told that the garage door is "opening" or "closing", but rather knows that it pushed the button and is assuming that the garage door is changing. That's why there is a config setting for "time until open" or "time until closed". Those settings are simply used to decide when it should be considered safe to reevaluate the physical state of the garage door to infer a new state of the controller.

In your suggested approach, your second bullet is a good example of where the code could go wrong. If the door is closed and you toggle the button, the controller will go into the opening state. The controller doesn't know when the door is actually open, only that it expects it to be opening for a given amount of time and then be finished (after which point it transitions to "open", assuming the sensor doesn't detect it as closed). So let's say it's opening and you want it closed. Well, if it's opening and the door is in fact still opening, then you actually would need to toggle the button twice in order to get it to shut. If, on the other hand, the door is finished opening, but the controller still has it marked as "opening" because the assumed time-to-open setting hasn't elapsed yet, then you'd only need to push the button once to close the door. The controller, however, has no way of knowing which to do, and has no way to know what result the button press is actually having on the doors. Edit: The reason for this was that without the *ing states, you would have an "open" door, and press the button, but it would still show as "open". How would you know if it was open because your button press never made it through, or because it's actually closing.

That was basically my reasoning for omitting the feature. Every time you push the button on the app, you could know reasonably well what the garage door is doing. Even as it stands, you can't guarantee it to be the case (i.e., if the doors are half way up, it's not known whether pushing the button will open or close them).

[adriangibbons]

Fair enough, I understand your points. I think I'll stick with my approach of ignoring toggles when doors are opening or closing. It's not perfect but has been working OK for me. As I mentioned, I implemented this because I'm using the IFTTT service for home automation and I need to be able to request desired state so that I don't accidentally close the door when I want it open.

Great project, if I have any other contributions then I'll share them back to your master branch!

Cheers, Adrian.

[andrewshilliday]

Oh, I get it now. If all you’re doing is ignoring commands when you’re already in the desired state, then you should be good to go. And I completely misunderstood that you’re using this with ifttt, so now I understand a bit better what you’re trying to do I think your approach makes sense. If you code it up as a separate endpoint (so that it doesn’t interfere with the current operation) it’d probably be fine to merge. Thanks for your contributions. On Fri, Mar 2, 2018 at 7:04 PM Adrian Gibbons notifications@github.com wrote:

Fair enough, I understand your points. I think I'll stick with my approach of ignoring toggles when doors are opening or closing. It's not perfect but has been working OK for me. As I mentioned, I implemented this because I'm using the IFTTT service for home automation and I need to be able to request desired state so that I don't accidentally close the door when I want it open.

Great project, if I have any other contributions then I'll share them back to your master branch!

Cheers, Adrian.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/andrewshilliday/garage-door-controller/issues/82#issuecomment-370093116, or mute the thread https://github.com/notifications/unsubscribe-auth/AAS2wsOoxgylDPxUpFtohcoGb1iX9xIaks5tad4egaJpZM4SQVcn .