search

ratgdo / esphome-ratgdo

ratgdo for ESPHome
GNU General Public License v2.0
358 stars 108 forks source link

Auto detect obstruction sensors #298

Closed PaulWieland closed 4 months ago

PaulWieland commented 4 months ago

When no obstruction sensors are installed, sec+ 2 doors ignore the discrete close command (see #146). The MQTT firmware does not have this problem because it only uses toggle commands. The toggle command is skipped if the door is already in the desired state, which has the same end result as using discrete commands.

Since the toggle command is always accepted by the door, this PR is designed to detect a low pulse on the obstruction sensor input, and if one is found, assume that the sensor is present. If the sensor is present, use the discrete close command, and if not, use the toggle command instead.

It also will report the obstruction status from the status packet if no sensor is detected.

Much testing required before merge.

agoode commented 4 months ago

Is there any way to continue to read the obstruction from the status packet even with obstruction sensors connected? I prefer to report obstruction that way so that I have a clear idea of what the door opener thinks. (This was useful when I had a bad sensor that was triggering a door re-open but not being detected with the ratgdo obstruction input.)

In my yaml I currently have this to enable obstruction-from-status:

ratgdo:
  input_obst_pin: none
PaulWieland commented 4 months ago

Not really. The obstruction from status is really slow which is why I designed ratgdo to detect from the hardware sensors directly. It needs to be one or the other or you will get conflicting messages as the status update lags behind the actual sensor state.

agoode commented 4 months ago

Seems reasonable. It might be nice to (optionally) expose both obstruction sensors. But I'll assume for now it's one or the other.