Releases: TheFes/cheapest-energy-hours
v5.0.0b5
✨ IMPROVEMENTS
- The check on matching
no_weight_points
and datapoints in source data is now done before the data is processed any further
🐛 BUG FIXES
lowers=false
now also works whensplit=true
is set- fix split data if there is only one datapoint in the selected values
- fix split data if there are multiple hours with the same lowest or highest price
What's Changed
Full Changelog: v5.0.0b4...v5.0.0b5
v5.0.0b4
✨ IMPROVEMENTS
- New error messages based on the
start
andend
time are added. There will now be a clear error if thestart
is after theend
and if thehours
setting is higher than the difference betweenstart
andend
🐛 BUG FIXES
- when a datetime or datetime string was used the microseconds were not removed from
start
andend
which made the selection not working properly
What's Changed
- Add additional error messages by @TheFes in #89
- Remove microseconds from start and end by @TheFes in #90
Full Changelog: v5.0.0b3...v5.0.0b4
v5.0.0b3
v50.0b2
v5.0.0b1
✨ IMPROVEMENTS
- hours based on
weight
setting can also have decimal points now - datapoints per hour are aligned (based on
end
,start
andhours
input) and the same setting is used to recalculate all 3.
🐛 BUG FIXES
- fix check if input for
program
was correct
What's Changed
Full Changelog: v5.0.0b0...v5.0.0b1
v5.0.0b0
BETA RELEASE
Version 4.2 needed a lot of bug fixes, sorry about that. In the last days a made a lot of changes based on the feedback of users. So many thanks for that. Keep sending in issues and questions, it will help to improve the macro even more!
Initially I've created the macro with only full hours in mind. The price data I worked with (Nordpool) only had hourly data, and the macro only did not really take minutes into account for the setting for the start and end period of the prices to check. In v3.0.0 support for sensors with more than one price per hour was added, and in 4.0.0 support for decimals in the hour setting was added.
Version brings the same support to the start
and end
parameters. You always could enter data which wasn't a whole hour, but now the data will be converted to actually use that input.
🚨 BREAKING CHANGES
- Refactor of
look_ahead
- The way
look_ahead
works has been reworked.look_ahead_minutes
is no longer used, and therefor marked as depreciated in the macro. For now the parameter will be left in, so it will not break you current templates. In v5.0.0 the current time is checked, and converted to a start time shortly before it. To support this, the data in your source sensor is split into smaller parts (minimum of 5 minutes, so 12 parts per hour). So if you enablelook_ahead
and the current time is eg 11:06, the start time for the price selection will be11:05
and there will be 12 data points per hour. If the current time is 12:18, the start time will be12:15
and there will be 4 data points per hour. - One of the big advantages of this, is that it will correctly work with
mode='is_now'
. In previous version that would only betrue
in the minutes set inlook_ahead_minutes
(so by default in the first 5 minutes of the hour), after that the current hour would no longer be taken into account for the price data, so it would no longer be one of the cheapest hours.
- The way
✨ IMPROVEMENTS
- Both
start
andend
will be used to split the data, andstart
andend
will be adjusted accordingly.start
will be set to the closed time before it, andend
to the closed time after. In the end the data will be split according to the highest data points per hour value calculated forstart
,end
andhours
- Refactor of
look_ahead
as described above. mode='split
is now a parametersplit
which can be set totrue
orfalse
. So you can now eg usemode='is_now', split=true
to immediately see if the current time is in one of the cheapest blocks. Not all modes work the same as forsplit=false
all
: the same data as in the previous version. This will also still be returned if you setmode='split'
start
: the start time of the first blockend
: the end time of the last blockmin
andmax
: the lowest and highest price in the prices foundtime_min
andtime_max
: the start time of the block with the lowest or highest priceaverage
andweighted_average
: both give the average of all prices found, as weights are not taken into account for the split setting, this will be the same for both modes
- a debug parameter is aded, if set to
true
it will return a dictionary with a lot of data which can be helpful for debugging, including the output based on the other parameters. - if no input for the sensor is provided, the macro will try to find a sensor with the attributes as set for
attr_today
andattr_tomorrow
. So basically if you use the Nordpool integration, or an integration with the same attributes it wil give the start time of the cheapest hour today if you only set usecheapes_energy_hours()
. This can be helpful if for some reason the entity_id changes. Do note that it's most resource friendly to set the sensor data yourself if it not matches the defaults, so the macro doesn't have to search for it.
Again, if there are any bugs, questions, feature request, please let me know!
What's Changed
- Refactor start and end conversion to datetime by @TheFes in #77
- Add debug setting by @TheFes in #78
- Add sensor finder by @TheFes in #80
- Refactor time calculations and look_ahead by @TheFes in #81
- Refactor mode split to separate setting by @TheFes in #82
- Depreciate datapoints per hour by @TheFes in #84
Full Changelog: v4.2.3...v5.0.0b0
v4.2.3
v4.2.2
v4.2.1
v4.2.0
✨ IMPROVEMENTS
- added an additional parameter
look_ahead_minutes
to determine how many minutes can be passed in the current hour to still take it into account. This defaults to5
. So eg at 13:04 the current hour will be still taken into account, but not anymore after13:05
. Set to60
to have it the same as it currently was, set0
to never take the current hour into account. - Added an additional parameter
datapoints_per_hour
. This is only needed when your source sensor provides more than one price per hour (eg prices per 30 minutes) and the input forhours
is not a whole number (eg 2.4). If not set in such cases, it could be that the macro will give an error about a mismatch between the datapoints per hour and the weight points per hour. - Added some important notes to the README
🐛 BUG FIXES
- Fxed a bug in how the hours were split when the input for
hours
wasn't a whole number - Fixed a bug where the last datapoitn would not be taken into account when the input for
hours
was not a whole number.
What's Changed
Full Changelog: v4.1.0...v4.2.0