I’ve managed to get my garage door integrated into Home Assistant okay, and I can actuate the door up and down, and also have a reed switch for the up and down position working fine. The only problem is I can’t work out how to feed the states from two reed switches into the garage door cover in my UI to make the the up and down arrows show where the door is. All examples I find use only a single reed switch, mine has one switch “on” when the door is up, and another go “on” when the door is down. In theory, they should never be able to both be on because there is only one magnet on the door. I should also mention that my garage door uses one switch for the up button, and another for down. I have used a sonoff dual and simply short the contacts with the relays.
I have the door up and door down binary sensors in the UI showing the door state fine. and the up and down arrows in the garage door cover work just fine. If anyone can just help me have the state of those up and down arrows reflect the actual position of the door, that would be amazing. I’ve been trying to follow the “position_template” instructions in the wiki but I find them very lacking of information for someone with my level of knowledge. Below is an image showing the garage section in my UI in case it helps.
It can represent the door’s position as a value between 0 and 100 but only if you supply it with that information. Based on your description, your system can’t provide positional informational in between fully-open and fully-closed. So the the door’s position expressed as a value would simply toggle between 0 and 100.
By position of the door, I simply mean “closed” “open” and ideally “half open”, which could be easily done with a simple form of logic/code that I can’t seem to work out/find.
Given that the two sensors can’t report intermediate positions, the ‘simple form of logic/code’ would be faking the ‘half-open’ position. It’s not hard to do but falls on its face should the door encounter a problem while opening/closing. The “I’m faking it” code wouldn’t be aware of the door’s problem and happily continue to lie to you about the door’s state.
If you’re OK with that possibility, then here’s the strategy. In this example, the door is being opened.
Let’s say the door takes 20 seconds to travel from closed to open.
The moment it begins to move, a 20-second timer is started.
For each timer-tick (1 second) it increments a counter (0-100) representing the door’s (assumed) position. That’s 100/20=5 units per second.
The counter’s value is supplied to the cover’s position option.
The moment the door’s ‘opened’ sensor is activated, it cancels the timer (and supplies 100 for position).
All bets are off if the door encounters excessive resistance, or an obstacle, while moving. Then the door will stop and (typically) reverse its direction of travel. None of this activity can be communicated to the ‘faked positional logic’ which will continue to report the door is still moving normally.
If door closed sensor is on, then 0
If door open sensor in on then 100
If neither, then 50.
If both, then also 50 (can’t happen as there’s only one magnet but two reed switches, but in case of MQTT error etc).
And I only want the up and down arrows in the cover to change with the actual position of the door, and showing half open in the icon or a binary switch is a bonus to detect faults. So full 0 to 100 position calculation is not only impossible with only 2 reed switches, but also not needed.
Sure but what’s the point? It reports one fake value, 50, and it’s self-evident the door is neither open or closed (and somewhere in between) because we just pushed the open/close button.
But if that’s what you want then it it can be done with a Template Sensor. It monitors the two sensor states and reports either 0, 50, or 100. This can be supplied to the cover’s position option.
But surely it’s not a fake value? We know for a fact the door is neither open nor closed, because neither the open or closed reed switch is “on”, which must mean it’s half open That is as certain as whether the door is open or closed.
Anyway, yes I’d love help to be able to take the states of my two reed switches and feed them into my garage door cover thanks. The main purpose of this is the have the up and down arrows change to which ever one is able to be used (if door is up, then only show the down arrow). And it would be amazing if I could have the garage icon show if door is open, closed, or half.
I’d love to actually understand the process, so if you can help and don’t mind, feel free to throw in some annotations into any code examples you give. But if not, I should be able to extract the basic logic by myself
Well, 50 is a fake positional value. in reality, the position is something other than 50 the moment you push the button. 50 is just something you picked that’s halfway between fully open and closed.
OK, but it does that already. After issuing the command, one arrow is gray and the other is black.
Why not just use the “closed” sensor like as the only sensor? Just ignore the “up” sensor - then your garage door cover would work just like the examples.
Because if the door doesn’t make it for some reason, the system thinks the door is up when it isn’t. I have deliberately installed two reed switches for this reason.
Here’s the algorithm I’ve chosen to use. I’ve assigned a numeric value to each one of the two sensor’s states (4 possible combinations in total). When you add the two numbers, it produces the position.
c is closed
o is open
c o c o position = c + o
off off 0 50 50
off on 0 100 100
on off -50 50 0
on on -50 100 50
Here’s the template sensor. it converts each sensor’s state to its appropriate numeric value (as per the table shown above) then simply adds the two values.
sensor:
- platform: template
sensors:
door_position:
entity_id:
- binary_sensor.closed
- binary_sensor.open
value_template: >-
{% set c = -50 if states('binary_sensor.closed') == 'on' else 0 %}
{% set o = 100 if states('binary_sensor.open') == 'on' else 50 %}
{{ c + o }}
I’m just starting work on it now. My current challenge is trying to work out what objects I need to change to things the names in my system. Things like “door_position” I’m assuming I need to change to “sensor.garage_door_right”?
Yeah the documentation was the reason I ended up here, it’s rather lacking, at least for me anyway.
I’m struggling to understand why the “entity_id” section is included.
entity_id:
- binary_sensor.closed
- binary_sensor.open
value_template: >-
{% set c = -50 if states('binary_sensor.closed') == 'on' else 0 %}
{% set o = 100 if states('binary_sensor.open') == 'on' else 50 %}
{{ c + o }}
I’d have thought the binary sensors have been already specified elsewhere as “binary_sensor.right_door_down” and “binary_sensor.right_door_down” because they show in my UI already as binary sensors?
Here is my code that works. In the end I deleted the extra section about entity IDs and changed the binary sensors to my current binary sensors showing the states of the two reed switches. I also changed the sensor name to “garage_door_right” which is what the garage door cover is looking for. Thought I’d post the working result and screenshot of UI to help others. Problem solving was helped by showing the “0, 50 or 100” value in the UI too.
- platform: template
sensors:
garage_door_right:
value_template: >-
{% set c = -50 if states('binary_sensor.right_door_down') == 'on' else 0 %}
{% set o = 100 if states('binary_sensor.right_door_up') == 'on' else 50 %}
{{ c + o }}
Now the only thing left to do is make the icon change with open, closed, and half open states. Anyway ideas?
The reason I included it is for completeness. For a Template Sensor, Home Assistant examines the value_template and attempts to identify the entities it should be monitoring for changes. If it is unable to identify them, the Template Sensor will be evaluated once, upon startup, and then never again (i.e. not until the next restart).
To avoid this possibility, you can explicitly list the entities (as I did). For the simple template I created, containing very obvious binary_sensors, listing them explicitly was not obligatory (and only done for completeness). Removing that section is immaterial to the sensor’s functionality (in this particular case).
I would appreciate it if you marked my post with the ‘Solution’ tag. Only you, the author of this thread, can do that. It will help others find it quickly because it will automatically place a link to my post under your first post.
That can be done using the Template Cover’s icon_template option.
When you say if it is unable to identify them, the template sensor will only be evaluated once, do you mean if on startup the sensor is unavailable once (MQTT database not loaded or something), then it will never work from that point until restart? Just wondering if I need to put those entities in or not.
And if anyone is interested, here’s the code to have a garage door icon that has a closed down door when the door is down, and an open door in any other state.
Actually, you marked your own post as the Solution. Your post quotes mine in its entirety … you marked the wrong post.
On more thing, the icon_template ought to use the int filter, as opposed to the float filter, because the position is expressed as an integer value; there’s no need to convert it to floating point number in order to check if it’s greater than zero.
Hi Dave, happy new year. I have the same issues that you have managed to solve and I wondered if you would mind helping me out? I have installed a momentary relay on each of my garage doors so I can emulate the push button, open/stop/close and I have installed a reed switch that lets me know when the door is closed. I’m going to install another one in the fully open position. I am struggling with the position_template because my reed switch is a binary sensor that just returns on or off. Would you consider sharing your cover template yaml please? I only have a small brain but I will be able to follow working code and implement it into my system. Thanks! Andrew.
