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

Disconnect logic between dispatch sensor and rate information #891

Open
2 tasks done
BottlecapDave opened this issue May 31, 2024 · 4 comments
Open
2 tasks done

Disconnect logic between dispatch sensor and rate information #891

BottlecapDave opened this issue May 31, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@BottlecapDave
Copy link
Owner

Describe the feature

The logic used to determine if the dispatch sensor is turned on/off should be detached from the rate information in event of failure to retrieve this information.

Expected behaviour

The dispatch sensor should work as it does today.

Use Case

There have been a few cases where rate information hasn't been available due to API errors which has caused the sensor to not turn on/off. It would be ideal if sensors that don't need the information are uneffected.

Confirmation

  • By submitting this feature request, you agree that you have read the documentation and confirmed it does not already exist
  • I am willing/able to help contribute to the solution of this feature
@fourmonks
Copy link

Perhaps an optional start/end off-peak time pair of values in configuration that forces and overrides "Is Dispatching"?

@BottlecapDave
Copy link
Owner Author

BottlecapDave commented May 31, 2024

I would rather the integration be powered by the data provided by OE as much as possible. I've added overrides in the past, and the issue is when those overrides change people forget they've set them and then raise bug reports (see configurable price caps).

HA entities also don't really support configuring individual entities, so it would have to be exposed in the account configuration or as separate entities. I don't want to jump the gun on something that has been stable up until a few weeks ago.

@fourmonks
Copy link

Yes, completely agree OE driven is the right direction if possible. In the interim, people will no-doubt be building in their own backstops / workarounds which may also in turn lead to false positives on the bug / issue reports; hopefully to a lesser extent. Keep up the great work, much appreciated.

@BottlecapDave
Copy link
Owner Author

I think for any cloud based automations, backups should always be built in as anything could happen (internet goes out, invalid data, etc). I personally feel it's better to build it in yourself as it can be tailored to your needs (some people will be fine with nothing happen as they can't guarantee, some will want to build elaborate custom sensors). The integration would never be able to cover everyone's needs in this instance. It will also be easier to debug as the automation trace information provided by HA would easily highlight why something turned on/off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants