Dry contact wiring - Positional/Open state improvements

[breakingspell]

Hello, this is in addition to #344, and may be considered a duplicate if we include this state in the list.

Positional percentage setting DOES work on latest firmware for an uncommon (Sommer) dry-contact opener. However, once the target position is reached, the esp32 continues to log and report the OPENING/CLOSING operation, with the percentage continuing up/down the scale.

The garage DOES stop at the proper position, but the reported status de-syncs. The door will be at the desired "15% Open", while the device and HA integration report it at "97% Opening".

The hardware logs indicate that while it receives the 15% position command, and calculates the travel time properly:

19:25:45	[D]	[cover:076]	'Door' - Setting
19:25:45	[D]	[cover:084]	  Position: 15%
19:25:45	[D]	[ratgdo:624]	Moving to position 0.15 in 2.2s
19:25:46	[D]	[binary_sensor:036]	'Close limit switch': Sending state OFF
19:25:46	[D]	[ratgdo_dry_contact:053]	Set close_limit_reached to 0
19:25:46	[D]	[ratgdo:113]	Door state=OPENING
19:25:46	[D]	[cover:170]	'Door' - Publishing:
19:25:46	[D]	[cover:173]	  Position: 0%
19:25:46	[D]	[cover:186]	  Current Operation: OPENING
19:25:46	[D]	[cover:170]	'Door' - Publishing:
19:25:46	[D]	[cover:173]	  Position: 4%
19:25:46	[D]	[cover:186]	  Current Operation: OPENING
19:25:47	[D]	[cover:170]	'Door' - Publishing:
19:25:47	[D]	[cover:173]	  Position: 7%

It overshoots the target percentage and continues to climb, when the door is actually correctly stopped. It then hangs out in the OPENING status indefinitely, never publishing an OPEN, but it can be closed as expected via controls or automation.

19:25:59	[D]	[cover:173]	  Position: 90%
19:25:59	[D]	[cover:186]	  Current Operation: OPENING
19:25:59	[D]	[cover:170]	'Door' - Publishing:
19:25:59	[D]	[cover:173]	  Position: 94%
19:25:59	[D]	[cover:186]	  Current Operation: OPENING
19:26:00	[D]	[cover:170]	'Door' - Publishing:
19:26:00	[D]	[cover:173]	  Position: 97%
19:26:00	[D]	[cover:186]	  Current Operation: OPENING
19:26:41	[D]	[sensor:094]	'WiFi Signal': Sending state -74.00000 dBm with 0 decimals of accuracy
19:28:41	[D]	[sensor:094]	'WiFi Signal': Sending state -74.00000 dBm with 0 decimals of accuracy

A preliminary look shows we may just need a check in RATGDOComponent::door_move_to_position to catch once a custom percentage is reached and return the OPEN status and position %.

I'll start tweaking there Looks like i'm warm: adding a call to set the door state manually after the stop action at https://github.com/ratgdo/esphome-ratgdo/blob/main/components/ratgdo/ratgdo.cpp#L628 does work to report the OPEN state and exit to IDLE, albeit at an incorrect 100% position (looking into that next):

        set_timeout("move_to_position", operation_time, [=] {
            this->door_action(DoorAction::STOP);
+           this->received(DoorState::OPEN);
        });

[breakingspell]

I'm also thinking it may be useful to add a "direction" variable for the dry-contact protocol to keep track of the door's motor direction.

With my unit, the motor alternates between the two directions (up-stop-down-stop), and it would be useful to evaluate this direction to see whether the door can actually be moved in the desired direction without a full cycle.

[PaulWieland]

Thanks for digging into this. Please open a PR if you are able to fix the opening bug and I'll test.
I don't think an additional direction variable is necessary because we already have the door status of opening or closing.

[breakingspell]

Please open a PR if you are able to fix the opening bug and I'll test.

For sure 👍 Now that the door state exits the loop when position is reached, I'll focus on exposing that position in the return (this may be beneficial for all three protocols and might address #390).

I don't think an additional direction variable is necessary because we already have the door status of opening or closing.

There'll likely be a better approach to the root cause behind my idea:

The "Close" action will trigger an "Open" on my single-button GDO if the door was previously set to a position from the open state. The ratgdo controller's orientation/controls become reversed until it re-evaluates the limit switches or another request inverts the direction again.

The idea is that the STOP action would evaluate the last door state and set the directional variable to drive the next action transparently (still target cover position, if it's in the opposite direction than the motor is set, then do quick 1-2 second start-stop to reverse to the correct direction).

It also complicates if the door state is UNKNOWN (as on a reboot when partially open/no limit switches on), but I think that could be fixed by exposing the position to the dry wiring setup as a condition for OPEN state. I'll post a separate bug report/PR if I end up checking that out deeper.

[breakingspell]

I've collected a few PRs to address this and other Drycontact-specific position issues:
#396
#398
#401

All three are working but some have improvements we can make before considering the merge.