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

Weighting on target rate sensors #733

Closed
2 tasks done
BottlecapDave opened this issue Feb 1, 2024 · 3 comments
Closed
2 tasks done

Weighting on target rate sensors #733

BottlecapDave opened this issue Feb 1, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request external contributions welcome The feature has been accepted and the criteria has been defined

Comments

@BottlecapDave
Copy link
Owner

Describe the feature

As mentioned in #721

For space heating, when I first switch the HP on it ramps up power to heat the large volume of water (typically around 2 to 3kW) and after 30 minutes to 1hr it gets to a stable state and will run at somewhere between 0.7 and 2kW depending on demand.
So in an ideal world the start window would recognise the power demand profile and use a weighting to seek the optimum start time based on cost.
Other use cases would be around washing machine (~70% of energy in first 30 minutes of a 3hr cycle) or dishwasher (~50% of energy in first 30 mins, then ~30% 2 hours later).

Expected behaviour

  1. The config sensor should support a new optional field where weightings can be specified
  2. The weightings should be comma separated and be decimals
  3. The number of items should match the number of required 30 minute chunks (e.g. if 2 hours is required, the weighting field should be 1,1.5,1.5,1 which would put additional weighting in the middle of the target times)
  4. The weighting field should error if not enough chunks are specified (e.g. if 2 hours is required, 1, 1,1,1,1,1, etc would fail)
  5. This should be unit tested

Use Case

For space heating, when I first switch the HP on it ramps up power to heat the large volume of water (typically around 2 to 3kW) and after 30 minutes to 1hr it gets to a stable state and will run at somewhere between 0.7 and 2kW depending on demand.
So in an ideal world the start window would recognise the power demand profile and use a weighting to seek the optimum start time based on cost.
Other use cases would be around washing machine (~70% of energy in first 30 minutes of a 3hr cycle) or dishwasher (~50% of energy in first 30 mins, then ~30% 2 hours later).

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
@BottlecapDave BottlecapDave added the enhancement New feature or request label Feb 1, 2024
@BottlecapDave BottlecapDave self-assigned this Feb 1, 2024
@ragg987
Copy link

ragg987 commented Feb 1, 2024

Thanks for considering this request. If you ever get round to it I'd be happy to test.

@BottlecapDave BottlecapDave added the external contributions welcome The feature has been accepted and the criteria has been defined label Feb 23, 2024
@rozza-m
Copy link

rozza-m commented Apr 9, 2024

I raised an almost identical issue over at #807.

The only suggestion I'd make is that the integration has the awesome ability to modify existing target rates, which is great for things that change duration. It would be great to have a way to support (or rather: not break this) with weighting, so I suggest an ability to weight either the end or the beginning and have the rest filled as 1s. More explanation in #807 .

@BottlecapDave
Copy link
Owner Author

Weighting within target rates are now supported with v11.0.0. Please see the docs for how this can be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request external contributions welcome The feature has been accepted and the criteria has been defined
Projects
None yet
Development

No branches or pull requests

3 participants