Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for equipment interlocks #10

Open
cryptk opened this issue May 25, 2023 · 2 comments
Open

Add support for equipment interlocks #10

cryptk opened this issue May 25, 2023 · 2 comments
Labels
enhancement New feature or request needs api support Functionality needs to be added to the underlying API library to support this

Comments

@cryptk
Copy link
Owner

cryptk commented May 25, 2023

Currently, if there is an interlock in place, home assistant will still allow toggling the entity on, but the next time the integration polls it will go back to off.

An example of this is a relay for a water feature that is interlocked with a pool cover sensor/switch so that the water feature cannot be turned on while the cover is closed.

We should detect this scenario in the configuration so that we can surface a message to the user if they attempt to toggle a device while it is interlocked.

@cryptk cryptk added the enhancement New feature or request label May 25, 2023
@Paulbhyo
Copy link

Paulbhyo commented Jun 7, 2023

I think we can close this, or put it under "needs API support"?.

  • Work arounds would be using the whyon status of the affected interlocked equipment and creating a new binary sensor in HA. (eg. whyon =10 when the valve is forced off by external interlock, if whyon = 10, interlock is on)
  • Or a more backwards way about it would be to setup the Omni to control a new relay, force the relay on or off depending on the status of the interlock. Relay entities show up in existing integration as a controllable device.

@cryptk
Copy link
Owner Author

cryptk commented Jun 7, 2023

That's a slightly different issue (but both related to interlocks). The whyOn issue was to allow inferring the state of a sensor that wasn't reported in telemetry (because it is only used as a source for an interlock). This issue is to surface a useful error to the frontend if someone does something like attempt to turn on a water feature that currently cannot turn on due to an interlock.

You are correct though that we need some API support for this to surface that interlock data, I'll mark it appropriately.

@cryptk cryptk added the needs api support Functionality needs to be added to the underlying API library to support this label Jun 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs api support Functionality needs to be added to the underlying API library to support this
Projects
None yet
Development

No branches or pull requests

2 participants