-
-
Notifications
You must be signed in to change notification settings - Fork 65
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
Comments
Perhaps an optional start/end off-peak time pair of values in configuration that forces and overrides "Is Dispatching"? |
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. |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: