Yea it sounds like you’re missing data, the octopus page doesn’t let you move through days that don’t have data.
If you put your details in Here it will tell you which slots are missing.
According to that link it looks as though no meter readings from the 26th has been collected , which is a little surprising. However since there is nothing I can do about that is there anything I can do about supressing the calculation of consumption figures by the integration ? Since rebooting yesterday at approx 1600 it has dropped over 14000 errors into the logfile so far.
If you comment out lines 377-380 in custom_components/octopusagile/OctopusAgile/Agile.py the error should stop. Long term I will find a better way to handle it.
1 Like
Thanks for getting back so quickly , I’ll give it a go.
2 Likes
I’m trying to project my costs using the REST sensor posted on the first page, I have incorrectly made a sensor which calculates current rate * total energy which gives me the wrong as its calculating the daily kwh consumed by whatever the current rate is.
How do I instead create a sensor for the day that accumulates the current rates * live wattage?
1 Like
I was looking around the Add-Ons in HA this morning and saw an official one called ‘Check Home Assistant Configuration’ , anadd-on that is intended to tell you if your current setup is compatible with a new release version. I’m currently running 2021.2.1 , the addon-on ran and tells me the following about upgrading to 2021.2.3.
[10:08:26] INFO: Please be patient, this might take a few minutes...
ERROR: After October 2020 you may experience errors when installing or updating packages. This is because pip will change the way that it resolves dependency conflicts.
We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default.
requests 2.25.1 requires idna<3,>=2.5, but you'll have idna 3.1 which is incompatible.
aiohttp 3.7.3 requires chardet<4.0,>=2.0, but you'll have chardet 4.0.0 which is incompatible.
[10:08:52] INFO: Installed Home Assistant 2021.2.3
[10:08:52] INFO: Making a copy of your configuration for checking...
[10:08:54] INFO: Checking your configuration against this version...
[10:09:56] ERROR: The configuration check did not pass!
[10:09:56] ERROR: See the output below for more details.
Testing configuration at /tmp/config
Failed config
General Errors:
- Platform error sensor.octopusagile - No module named 'dateutil'
- Component error: octopusagile - No module named 'dateutil'
Successful config (partial)
The section about the ‘use-feature’ thing seems to be directed to people who install package updates via pip from a terminal window - at least as far as I can see - I’m no expert. This is someting I don’t do , I only go through the HA UI to install package updates so I’m not sure if this applies to me. This question is more about the ‘General Errors’ section relating to OctopusAgile - is this a false positive in some way - has anyone else had an issue upgrading to the core version 2012.2.3 ? Any guidance appreciated.
hi all - n00b into this thread
I have powerwal2, octopus go tariff. Have been not that impressed with tesla’s software calculating how much to charge up by in the off-peak period, it frequently gets it wrong. sometimes it discharges during the offpeak period into my EV which charging at that time, which is infuriating.
i have working via a docker install of HA on a synology NAS
- solcast custom-component - only just setup today so it has only polled once, but I can see some data in solcast.history.
- “tesla powerwall” integration which pulls the data from the local web interface of my gateway and is giving me the SOC, power levels in the various directions. I suspect I need a different integration to be able to set the powerwall into its different modes, but I can’t find a clear document on that.
can someone help me with a n00b’s guide:
- what integration do I need to be able to make config changes to the powerwall and how do I control it
- how and where to I build the logic for “if expected sun tomorrow <X then charge Powerwall during night offpeak” , or some variant of that, I am sure that must be what most on here are doing.
I can cope with changing the numbers that might be in such code to suit my own personal usage, but I have no real clue where to start - I am not a coder.
so if someone has done this already and can even just post all their relevant configs, that would be great
many thanks
Ian
I’ve setup your integration. Is there an easy way to get the time (in a nice format) for when the cheapest rate occurs.
It’s great having a value but I don’t know when it is without looking at the rates card which I’ve not configured yet.
@eximo84, that’s a really good point, I always go and look at the rates card if I’m looking for the min rate, it would be good to have a quick glance way to see the time. It’s not currently implemented but it wouldn’t be too much work to add it as an attribute to the entity, would that be useful?
Yes indeed it would. Thanks Mark.
I have a rest sensor now as part of an api call but this integration is better so want to drop that sensor. Current I display min rate with From and Until times so I can see when the cheapest 30 minutes is.
Could even expand this out to more than 30 minutes, maybe cheapest blocks? I don’t know how easy to determine those are though.
1 Like
I currently have an OWL monitor, using the utility_meter integration (hourly, daily, weekly, monthly sensors) and can roughly calculate my current cost based on the fixed rates - is there a way to use the data for this addon, to predict potential costs/savings on Agile?
I see @Markg is/was doing something similar, I’m just not quite sure if/how he/you feed the usage data to this without being an active Agile customer.
So presumably I need to use the statistics/history sensor, to calculate/store kwh from my OWL sensor or utility_meter (hh:mm:ss):
xx:00:00 -> xx:29:59
xx:30:00 -> xx:59:59
Then multiply by the respective rate (before it expires from the addon data) and store the total value per hour, day, week, month, etc
… anyone have anything ‘pre-baked’? 
EDIT: Ok, this seems to work for calculating estimated/potential Octopus Agile costs, when you have kWh from a source such as an OWL.
Using a template sensor didn’t work too well, as the state changes between current_rates and previous_rates can be a few seconds between (and you can no longer specify entity_id for the entities that should cause a state recalculation) causing the template sensor to update too frequently. So, moving to use automation to capture the required data every 15 minutes, with a delay.
Quarter Hourly utlity_meter, using your kWh source:
utility_meter:
electricity_quarter_hourly_kwh:
source: sensor.electricity_usage_kwh
cycle: quarter-hourly
Create an input_text to hold the incrementing cost:
input_text:
octopus_agile_incrementing_cost:
Automation to take values from the utility meter and process with the appropriate rate (current / previous) depending on the time period and update the above input_text (adding to the previous value for a running total). Delayed by 15 seconds ensure that both the curren_rate and previous_rate have updated.
- id: 'Update Octopus Agile Estimate Costs'
alias: Update Octopus Agile Estimate Costs
trigger:
- platform: time_pattern
minutes: /15
action:
- delay:
seconds: 15
- service: input_text.set_value
data_template:
entity_id: input_text.octopus_agile_incrementing_cost
value: >
{% set quarterly_last_reset_minutes = as_timestamp(states.sensor.electricity_quarter_hourly_kwh.attributes.last_reset) | timestamp_custom('%M') %}
{% if quarterly_last_reset_minutes == "15" or quarterly_last_reset_minutes == "45" %}
{{ ((state_attr('sensor.electricity_quarter_hourly_kwh', 'last_period') |float) * ((states('sensor.octopus_agile_current_rate')|float) /100)) + states('input_text.octopus_agile_incrementing_cost')|float }}
{% elif quarterly_last_reset_minutes == "00" or quarterly_last_reset_minutes == "30" %}
{{ ((state_attr('sensor.electricity_quarter_hourly_kwh', 'last_period')|float) * ((states('sensor.octopus_agile_previous_rate')|float) /100)) + states('input_text.octopus_agile_incrementing_cost')|float }}
{% endif %}
A sensor based on the input_text:
sensor:
platform: template
sensors:
octopus_agile_incrementing_cost:
friendly_name: Octopus Agile Incrementing Cost
value_template: "{{ states('input_text.octopus_agile_incrementing_cost') | float }}"
unit_of_measurement: £
Assign this template sensor to a new utility_meter, offset by 30 seconds to ensure that the previous quarter hour is assigned to the correct hour:
utility_meter:
octopus_agile_estimated_cost_quarter_hourly:
source: sensor.octopus_agile_incrementing_cost
cycle: quarter-hourly
offset: "00:00:30"
octopus_agile_estimated_cost_hourly:
source: sensor.octopus_agile_incrementing_cost
cycle: hourly
offset: "00:00:30"
octopus_agile_estimated_cost_daily:
source: sensor.octopus_agile_incrementing_cost
cycle: daily
offset: "00:00:30"
octopus_agile_estimated_cost_weekly:
source: sensor.octopus_agile_incrementing_cost
cycle: weekly
offset: "00:00:30"
octopus_agile_estimated_cost_monthly:
source: sensor.octopus_agile_incrementing_cost
cycle: monthly
offset: "00:00:30"
octopus_agile_estimated_cost_quarterly:
source: sensor.octopus_agile_incrementing_cost
cycle: quarterly
offset: "00:00:30"
octopus_agile_estimated_cost_yearly:
source: sensor.octopus_agile_incrementing_cost
cycle: yearly
offset: "00:00:30"
Then rounded template sensors, for use with a gauge:
sensor:
- platform: template
sensors:
octopus_agile_estimated_rounded_cost_hourly:
friendly_name: Octopus Agile Estimated Rounded Cost Hourly
unit_of_measurement: '£'
value_template: "{{ states('sensor.octopus_agile_estimated_cost_hourly') | float | round(2) }}"
- platform: template
sensors:
octopus_agile_estimated_rounded_cost_daily:
friendly_name: Octopus Agile Estimated Rounded Cost Daily
unit_of_measurement: '£'
value_template: "{{ states('sensor.octopus_agile_estimated_cost_daily') | float | round(2) }}"
- platform: template
sensors:
octopus_agile_estimated_rounded_cost_weekly:
friendly_name: Octopus Agile Estimated Rounded Cost Weekly
unit_of_measurement: '£'
value_template: "{{ states('sensor.octopus_agile_estimated_cost_weekly') | float | round(2) }}"
- platform: template
sensors:
octopus_agile_estimated_rounded_cost_monthly:
friendly_name: Octopus Agile Estimated Rounded Cost Monthly
unit_of_measurement: '£'
value_template: "{{ states('sensor.octopus_agile_estimated_cost_monthly') | float | round(2) }}"
@iMiMx, This looks really cool! Sorry I didn’t reply on the owl thread, I’ve had it open for a while to remind me to look through my old config but haven’t got back to it. My owl transmitter died shortly after I got it working with HA to any degree. I never managed to get a good so,union, just a whole load of automations that ran every 30 mins. Your solution looks pretty elegant, I will try and have a play with one of my tasmota devices sometime, could be a good use of a blueprint maybe?
1 Like
For anybody that is interested, my Agile integration is now available in HACS by default 
I’ve also started tagging releases so it’ll be clearer what’s going on in each update.
If anybody has time to test it out without having to add the custom repo that’d be awesome!
2 Likes
Already been using it via hacs Great work, keep it up
2 Likes
Managed to get the dishwasher alerting when a suitable window approaches (if Auto-Start is not enabled, door is open, etc) and/or reminds before going to bed, to start in the early hours, easily enough via the Bosch HomeConnect component.
… but the aspect I’m struggling with is the Washing Machine, unfortunately it has no ‘smart’ control. I’ve tried using a SwitchBot and a Microbot Push, to push the ‘start’ button, however I’m pretty sure the ‘on’ button on the Washing Machine needs to mimic a fingers heat-touch.
I was hoping the Microbot Push might work, as it has a larger rubber pad that comes into contact with the button… but alas, no. So, I’m sure the on button is heat sensitive.
Anyone got any ideas? To potentially fool the button?
The only other option I think I’ve got, is that if the Washing Machine power draw is over X, i.e it has been started, turn off the socket, then turn it on again in a suitable window. I’m pretty sure the Washing Machine picks up where it left off, in the case of a power outage.
I have a “dumb” washing machine and dishwasher but they remember their “state” when power is “lost” and comes back on so have setup a Push Button (Xiaomi button) that turns on/off a smart plug for each unit
When the washing machine/Dishwasher is loaded it is turned on as normal and starts its cycle so when the button on the wall is pressed the smart plug is turned off the so that at the given best time slot HA turns on the smart plug
As an extra, I use a power monitor plug so can also monitor the power usage and based on “W” and time idle etc can ping a notification of status
Best I could come up with
I had thought about opening up each unit and putting in a wemos with a relay attached direct to the switch etc and “push” the button that way bit not sure the misses would like that idea, however it does then allow it to be controlled or run manaully
Yeah, I was trying to avoid that 
Power monitoring is perhaps my best option. I already have the washing machine state guessed/determined based on the power draw from a ZWave plug, so I can just tie the Agile best time automation into that - i.e if it goes from ‘Powered Down’ or ‘Idle’ to ‘Wash’ or ‘Rinse’, and it’s not in an ideal window, turn off the socket… then turn on again in the next window.
I gave up with the individual cycle and just have Washing/Clean or Cleaning/Drying now
So are you taking this information from the integration and making the utility meter do the daily, weekly calculations?
I’m at the moment the integration just gives total incrementing. I’m using an apex chart to group it daily with an offset but I don’t know it it’s right or not.
If I could take the integration value and split it daily and weekly etc that would be awesome.