Add a service to schedule based on an Octopus Target Rate time #47
Conversation
|
Added the option to add a backup schedule to the request. If no times are found in the tracker it will default to the backup. We can also append the backup to the schedule (maybe if you want to cover preheat or just want it to always set a certain period as a backup). Also merged the times if they are continuous... |
|
Wow, thanks for submitting this! In the meantime, feel free to commit any further updates and/or think about what could be added to the Readme |
|
Yeah Im expecting the 3.0 changes to potentially break scheduling as they will include the charging mode, but hopefully doesn't require too many changes. Added some readme changes. |
|
I believe it's off by 1h since the daylight saving time started (Octopus tracker still returns times in GMT e.g. |
|
If someone campaigned on removing daylight savings they'd probably get my vote 😅 |
|
So I think I've fixed the timezone by converting it into the local timezone that is set in the coordinator. Had to import Not sure if should use python-datetime instead, will give it a go using that and see if I can get it working... https://developers.home-assistant.io/blog/2021/05/07/switch-pytz-to-python-dateutil/ |
|
I'm not 100% sure what happens if schedules clash - e.g. if the backup schedule spans the other schedules. The app shows a warning... |
|
Seeing the following error tonight: d31a9decb appears to be the Put in some code to loop over the config_ids and they appear to bring back multiple ones: Eventually we hit a config_id that works... |
|
Updated with latest changes to main |
This reverts commit 5d1f03e.
…time using correct tz
|
Merged into the 2.0 changes and still seems to work with my HV2.0 but could use HV3.0 testing? @gndean |
|
Looks like it would work OK with the default values passed in for HV3.0: Calculating the DayOfTheWeek maybe annoying if we want to be more specific. |
|
I agree that it looks like this should work for HV 3.0 devices too. I will test this when I get chance. |
…volt-charger into schedule_octopus_agile
| for interval in intervals: | ||
| _LOGGER.info(f"{interval.start_time} -> {interval.end_time}") | ||
|
|
||
| _LOGGER.info("Merging continuous times:") |
There was a problem hiding this comment.
Annoyingly, the HV 3.0 charger does not allow times to span midnight. If trying to set that, the API returns an error like:
"schedule.set failed: assertion failed: Session startTime (HoursMinutes(12,0)) must be < endTime (HoursMinutes(3,30))"}}
When trying to do this in the HV app, two sessions are created:
startTime -> 24:00
00:00 -> endTime
So I think there needs to be logic for this too 😢
There was a problem hiding this comment.
We might have to do something like this for the merging and splitting, then I put a kludge in the API client code that converts 23:59:59 into 24:00 when it's passed to the HV API.
_LOGGER.info("Merging continuous times:")
if intervals:
merged_intervals.append(intervals[0])
for interval in intervals[1:]:
last_interval = merged_intervals[-1]
if last_interval.end_time == interval.start_time:
last_interval.end_time = interval.end_time
else:
merged_intervals.append(interval)
# Break up any interval spanning midnight
for interval in merged_intervals.copy():
if interval.start_time > interval.end_time:
_LOGGER.info(
f"Splitting interval {interval.start_time} -> {interval.end_time}"
)
end = interval.end_time
interval.end_time = datetime.time(hour=23, minute=59, second=59)
merged_intervals.append(
HypervoltScheduleInterval(datetime.time(hour=0, minute=0), end)
)
for interval in merged_intervals:
_LOGGER.info(f"{interval.start_time} -> {interval.end_time}")```
There was a problem hiding this comment.
Actually, re-thinking this. The splitting should probably happen with the hypervolt_api_client code, not in here. So then it works for anything that calls set_schedule.
So I've changed my mind - don't split intervals spanning midnight here.
|
The incoming changes to bottlecapdaves integration look like he's changing to timezones for everything instead of UTC. So probably need to double check when that's merged |
|
It seems quite happy with the new timezone changes in bottlecapdave's v11.0.0 |
This takes a Target Rate tracker from https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy and applies the schedule to Hypervolt. Tested OK on my HV2.0...
It also attempts to use
binary_sensor.octopus_energy_{{ACCOUNT_ID}}_intelligent_dispatchingentityplanned_dispatches- e.g. if HV was a second charger to a compatible unit or car. But I dont have intelligent so can't test...The reason I want to take this approach is due to cloud based nature of integration. We could just have HA wait for the target entity to come on, and then switch between plug and charge/schedule or stop/start charges, but this causes more API calls, and if any cloud is down it will fail (and likely overnight when you cant see it). By setting a schedule we can observe that this is set in HV before we goto bed and not have to worry about any internet outages 👍
Resolves: #44
It could possibly be improved by merging in any continuous timeslots (e.g. if the tracker has 00:30->01:00, 01:00->01:30 these should be merged into one schedule block). This is too much for my addled brain at the moment as it was painful enough just working out how to do HomeAssistant internals as the documentation is pretty poor 🤮Service:
The Hypervolt should be filtered under devices by
services.yaml, and target rates should be partially filtered to the Octopus integration - but can only constrain it tobinary_sensorsrather than target rate items specifically.Target Rate tested:
Resulting Hypervolt Schedule: