Did it sort itself out? It should’ve only been the previous rate sensor that wasn’t populated on first startup. If they’re all still not populating check that octopusagile.all_rates is populated, if it’s not a call to the update_timers service should help with a bit of luck.
Not so far, unfortunately. all_rates is populated and I did try running the service call (and the half_hour, just in case).
Sadly I ran out of time in my ‘Patch Sunday’ maintenance window before people started waking up, so I’ll enable some logging next chance I get.
EDIT: Did eventually populate, at around 11:30 - few hours after playing, not entirely sure why 
Can I ask if you have anyprogress on the average rate sensors?
I use them to control my hybrid battery charge status and often loose them if I restart
Cheers
@iMiMx, that’s a strange one that I haven’t seen come up in tested, if it happens again can you let me know along with any errors from the log?
@matthewjporter, I’ve not had much time to work on this lately but have just pushed a beta v0.1.2 which stores the avg rate sensors to hopefully survive a restart. Can you test and let me know how you get on? I’ll push out a release if all goes well
Just updated to the beta version, sensor back now after
Will try a reboot or two later and tomorrow
1 Like
I’m trying to add back in the octopusagile integration but the configmenu does not advise what is required. Any assistance would be great, thank you.
You can leave that empty - I should work out how to disable it from popping up, all configuration is done through configuration.yaml 
Can someone give an example of how to use the start_time in a run_device , e.g. octopusagile.dryer to match against the current utc time and do something in an automation ? I have a sensor.date_time_utc but that formats as ‘2021-05-17, 20:08’ not ‘2021-05-18T02:30:00Z’ which is what octopusagile gives me .
I ended up using the start_in attribute:
- id: 'Auto-Start Dishwasher At Next Best Time'
alias: Auto-Start Dishwasher At Next Best Time
trigger:
- platform: template
value_template: >
{{ is_state_attr('octopusagile.dishwasher', 'start_in', 0) }}
condition:
- condition: state
entity_id: binary_sensor.dishwasher_auto_start_check
state: 'off'
- condition: or
conditions:
- condition: state
entity_id: sensor.dishwasher_operation_state
state: 'Inactive'
- condition: state
entity_id: sensor.dishwasher_operation_state
state: 'Ready'
action:
- service: switch.turn_on
data:
entity_id: switch.dishwasher_power
- delay:
seconds: 15
- service: switch.turn_on
data:
entity_id: switch.dishwasher_program_eco50
- service: notify.mobile_app_iphone
data_template:
message: "Dishwasher: Auto-Starting NOW."
- service: automation.turn_off
data:
entity_id: automation.auto_start_dishwasher_at_next_best_time
The auto_start_check template sensor checks that ‘Remote Start’ is enabled (requirement for my dishwasher) and that the door is shut:
- platform: template
sensors:
dishwasher_auto_start_check:
friendly_name: "Dishwasher Auto-Start Check"
device_class: problem
value_template: >-
{% if is_state('binary_sensor.dishwasher_door', 'on') or is_state('binary_sensor.dishwasher_remote_start', 'off') %}
on
{% else %}
off
{% endif %}
Thanks for that , I was too focussed on the start_time to see the value of start _in. Just for my curiosity what dishwasher are you using ?
Using start_in also makes it easy to send an alert, at say 1 hour before, that the best window is approaching but my ‘auto_start_check’ (door open, or remote start not enabled) is failing - so needs some manual intervention before it will run.
It’s a Bosch (SMV88TX26E), with Home Connect,
@badguy , just curious if anyone knows what the future is for octoblock. according to frencks community page for Appdaemon it is no longer maintained as of 2020 ( which is curiously not what it says in the HA add-on store ) . With octoblock having a dependency on Appdaemon should we still be using it , or planning to use it ?
I’m sure there was an Appdaemon update a couple of weeks ago, so that’s odd. But I was thinking of changing it to a full custom component anyway, so I’ll try and get that done in the next couple of weeks.
The Home Connect dishwashers are very nice - I have a Siemens one, and have an automation that will set the delayed start time automatically on it. I just turn it on, press remote start and close the door. The automation takes care of programming the delay offset automatically
service: home_connect.start_program
data:
entity_id: switch.dishwasher_power
program: Dishcare.Dishwasher.Program.Auto2
option_key: BSH.Common.Option.StartInRelative
option_value: >-
{{ (as_timestamp(states('sensor.octopus_3hour_time')[:-4]) -
as_timestamp(now())) | int }}
option_unit: seconds
Hi again, I figured it out. Somehow I had a second agile_octopus.yaml setup file so it must have been causing a conflict.
Is there anyway to include the export data from octopus from my solar production to them?
Thanx again
Chris
1 Like
I have been using the integration successfully for a good few months now, and it is fantastic. Everything seems to trigger at the optimum times (hot water etc) but… last night was the first night since installing that the price went sub-zero for us.
The ‘money maker’ trigger seemed to go off an hour early - I am assuming that has something to do with BST?
Odd since the other timers seem to work bang on the times that are best?
Any thoughts?
Cheers
Andy
@angusc glad you got sorted.
Not yet, but there is an open issue on GitHub and I have just had solar installed so it may well happen in the future.
I’m surprised by this, the moneymakers use the same code as everything else. The timeslots get added to the octopusagile.timers entity so you can see when they’re going to trigger, if we happen to get another plunge any time soon can you check that entity and let me know if the times are right in there?
1 Like
I will thanks!
@Markg I need some help. I seem to be hitting issues getting data from Octopus.
Errors range from:
Update for sensor.octopus_agile_current_rate fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 316, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 524, in async_device_update
raise exc
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/octopusagile/sensor.py", line 159, in update
current_rate = self.hass.states.get("octopusagile.all_rates").attributes.get(rounded_time_str)
AttributeError: 'NoneType' object has no attribute 'attributes'
and that happens for sensor.octopus_current_rate, sensor.octopus_next_rate, sensor.octopus_previous_rate to:
Logger: OctopusAgile
Source: custom_components/octopusagile/OctopusAgile/Agile.py:373
Integration: octopusagile (documentation, issues)
First occurred: 22:00:06 (240 occurrences)
Last logged: 22:00:06
UTC Unmatched consumption 2021-05-23T22:00:00+01:00 / cost 2021-05-08T21:00:00Z
UTC Unmatched consumption 2021-05-23T22:30:00+01:00 / cost 2021-05-08T21:30:00Z
UTC Unmatched consumption 2021-05-23T23:00:00+01:00 / cost 2021-05-08T22:00:00Z
UTC Unmatched consumption 2021-05-23T23:30:00+01:00 / cost 2021-05-08T22:30:00Z
UTC Unmatched consumption 2021-05-24T00:00:00+01:00 / cost 2021-05-08T23:00:00Z
My relevant configuration.yaml (installed via HACs):
octopusagile:
region_code: "A"
mpan: !secret octopus_mpan
serial: !secret octopus_serial
auth: !secret octopus_key
startdate: "2020-05-08"
run_devices:
- energy_time: 2
entity_id: dishwasher
run_before: "07:00:00"
run_time: 2.5
- energy_time: 2
entity_id: washing_machine
run_before: "07:00:00"
run_time: 2
and sensor.yaml:
- platform: "octopusagile"
Any ideas what I’m doing wrong?