Skip to content

Conversation

@breakingspell
Copy link
Contributor

@breakingspell breakingspell commented Apr 2, 2025

This PR:

  • Sets the cover state to OPEN after STOP action at a target position
    • This closes the OPENING state loop present in the drycontact logic
    • Other protocols poll status from the opener and don't have that issue
      • This needs tested to confirm nothing has regressed on the other protocols
  • Reports back the cover position rather than 1.0 value in the OPEN state, visible in Home Assistant

image

Fixes:


Dependencies for Dry Contact firmware:

The other protocols shouldn't require additional changes, testing needs to ensure nothing is regressed. 🤠


TODO:

  • Timeout to OPEN state if door is manually stopped partially with wall button/remote (this currently does not time out and stays OPENING|CLOSING)
  • Review the value returned once door stopped, perhaps "round up" to return the target value instead, assuming the door is correctly calibrated+positioned.

@breakingspell
Copy link
Contributor Author

Not sure if the latest commit encroaches on other protocols, but I moved the OPEN position override to the STOP/TOGGLE action handler.

@breakingspell
Copy link
Contributor Author

breakingspell commented Apr 11, 2025

This has been working very well for a few weeks, with two outstanding issues:

  • The percentage returned is sometimes behind the door state

    • Requesting 15% can return 15, 14, 12, 10, etc. The door is actually open in the proper position but the counter is rounded down.
    • Rounding the output to multiples of 5/10% may present better and correct for this, but masks the actual returned position. This may also require modifying the cover/position calculations, unnecessarily.
  • (Dry-contact-specific) Bypassing ratgdo and using the wall button or RF remote to stop the door partially will replicate the original issue.

    • The Opening status and counter are triggered by the Closed limit sensor turning off, not by the wall button/remote. The other sensor is not encountered, so the status stays in Opening and counts up to 97%. Same with Closing inversely.
    • Haven't dug in yet, but not sure if this can be accounted for without substantial work regarding dry contact wall buttons, if it's physically possible for ratgdo to monitor button presses. The remotes/paired cars operate entirely within the GDO controller and would be inaccessible to ratgdo..
      • If not, this could be accounted for with a timeout to the unknown position state, using a 50% best guess to indicate the door was last stopped manually and could be in any position.
      • ratgdo's next operation would need to be Toggle in order to encounter a sensor and reorient.

Edit: brainstorm on the second issue, we could potentially handle the Opening/Closing state timeout based on if it were invoked by external sensor change (limit switch), versus a firmware button/function call. Probably a lot simpler than I had initially thought. This could also be handled in a separate merge.

@azilberbaum
Copy link

Edit: brainstorm on the second issue, we could potentially handle the Opening/Closing state timeout based on if it were invoked by external sensor change (limit switch), versus a firmware button/function call. Probably a lot simpler than I had initially thought. This could also be handled in a separate merge.

I think this is a good approach, if ever the limit sensors see the door is open or closed it should update the position.

@breakingspell
Copy link
Contributor Author

breakingspell commented Aug 6, 2025

Edit: brainstorm on the second issue, we could potentially handle the Opening/Closing state timeout based on if it were invoked by external sensor change (limit switch), versus a firmware button/function call. Probably a lot simpler than I had initially thought. This could also be handled in a separate merge.

I think this is a good approach, if ever the limit sensors see the door is open or closed it should update the position.

Yes, subscribing to the Limit Switch's states and handling the external state change as an OPEN/CLOSE would resolve this.
As it is, that issue is the only one I encounter in day-to-day, housemates use the GDO wall button to partially open instead of scene switch in other room, so the usual position reporting is not handled.

Use position float instead of 1.0 for open state
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants