OK , you were right , the timers entitiy is now populated. Thanks for your help. I’m new to HA and the learning curve is considerable 
I’m not sure I’m following your explanation of how the entities is activated though. I think what you are saying is that every half hour octopusagile will switch off the referenced entities unless the entity has a timers.times attribute for that half hour defined in which case it will switch it on. ( should I not see evidence of that switch off signal being sent in the Logbook then ? because I don’t )
Therefore if you want to modify that behaviour you have to run a separate automation that every half hour switches the entity on ( if you want to have the device on outside of the times defined in the timer entity ) or switch it off every half an hour if you want to have it switched off during the times defined in the timer entity - such as you might if you had a ‘Not at home’ boolean managed through the HA home page . Is that what you are saying ?
Glad you have it working! This probably wasn’t the easiest to start off with 
it started out serving a purpose for my setup and evolved from there, there are many things I’d do differently if I started from scratch seeing how everyone else uses it.
Yup, you have it right. What I have seen people do is use an input Boolean entity in the timers and then have an automation that triggers to turn the device on when that entity becomes true and the away switch isn’t set.
That’s getting more complex than you might need to be to start out though. Now you have your timers populated your sonoff devices should turn on/off at those times.
A couple of things, although the timers are set correctly now , I’ve noticed an error in the logs every half hour saying:
2021-01-01 22:30:00 ERROR (SyncWorker_3) [custom_components.octopusagile] 'NoneType' object is not iterable
as for your suggestion of using an input boolean I assume you mean:
- day_from: tomorrow
day_to: tomorrow
entity_id: input_boolean.recharge_timer_enabled
numHrs: 1
params: null
time_from: '05:00:00'
time_to: '08:00:00'
and then automating using the state transfer between off and on as the trigger? If so will this still raise a toggle in the status of the input_boolean even if the identified half hour time slots are contiguous i.e. using the above example I assume timer start slots calculated as say 0500 and 0700 would change input_boolean to ‘on’ at those times and ‘off’ at 0530 and 0730 but would that still happen if the timer slots happen to be calculated as 0500 and 0530 , or would the ‘on’ status be constantly on between 0500 and 0600 in that case ?
also what does the params option do ?
and finally, I hope, and this may be a stupid question but when I update the config yaml for octopusagile values do I need to restart HA or is it enough to call the octopusagile.half_hour service ?
Anyway , hopefully the timers will work otherwise I’ll be waking up to a cold house in the morning 
Nope didn’t work, I think it may be down to the run_devices being blank. So I’ll define something - even though I don’t need them - to see if it makes a difference. I’ll also change to useinput_boolean’s as my entities - if I see some evidence of their state changing in the logs I might then have some confidence I have an object I can create some automations around.
This has thrown me a bit, interestingly somebody over on the agile forum has hit a similar issue. Can you show me what the timers entity is populated with?
I’m assuming the “switch.sonoff_1000a27818” entity exists in home assistant?
It could be worth editing the octopusagile.timers entity under development tools to set a timer for the next timeslot and run the octopusagile.half_hour service through developer tools also. This will allow you to test the timers without having to wait for the next active timeslot.
I don’t have the same timers entity as I had when I was getting the ‘NoneType’ error ( which is what I assume you are referring to. But I had , as I said that error line (as sampled above) every 30 mins , so because of that regularity assumed it was caused by the half_hour service . So I called that explicitly as a service, only then did the logs identify a linenumber which I think was 176 in init.py ( from memory - I’ve since cleard the logs to bring them back to a manageable size , sorry) which led me to the conclusion it was the blank run_devices that was the problem.
I’ve since replaced the refernces to the sonoff devices with input_booleans , and I’ll see whether the history log shows them varying in value ( yes the sonoff devices definitely existed - still do in fact) as the current timers entity suggests they should. If that fails overnight I’ll try your suggestion to help troubeshoot it further.
The input_boolean values look they toggled successfully now that I have some run_devices defined. Unfortunately I had forgotten to include one of the input_booleans I wanted in the configuration.yaml file so, now that I have corrected that, I’ll restart the testing process to see if this integration performs as expected over the next few days before using it in earnest.
I’m sure it will , but it has been such a struggle getting to this point my confidence is a little low. Please don’t take offence at that as none is intended , I wouldn’t have even gotten to this point without your help and it is appreciated. 
The only thing I’m really curious about now is caused when I look at my pi-hole logs as it suggests my HA server is reaching out to the api.octopus.energy servers not every 30 mins but every 30 secs - not sure if that is expected behaviour or not.
Really glad you got them going, I’m not surprised you don’t have much faith, sorry it was such a pain to get going! I will have a look at the issue when there are no run devices specified, it’s not once I’ve come across before.
The 30 second thing is because I’m using standard home assistant sensors for so the current/previous/next pricing and they default to that. I have an issue open to get them changed to work how the rest of the integration does where it triggers itself every 30 mins but haven’t managed to get to it yet.
@Markg @db1964 Did some packet captures and yes it was reaching out to the API every 30 seconds which is a bit naughty (although I don’t think Octopus have a rate limit… yet )
You can workaround this easily by using the scan_interval attribute - I have appended this to both the sensor and component, e.g…
octopusagile:
region_code: "Z"
mpan: 1234567890
serial: ABC12345
auth: sk_live_longstring
startdate: "2020-12-01"
scan_interval: 300 <------------
moneymakers:
- input_boolean.testocto: null
etc...
Hope this helps.
This is an awesome little integration tho, I also installed via HACS (custom repo) and that all went fine. Been testing over the past few days, nearly ready to switch over to using this for full scheduling battery and hot water.
The only thing I would say about doing that is that if you’re using the price entities in automations, you can’t guarantee that you will switch too close to the half hour, my understanding is that the interval is from when home assistant started, so for example if it started at 4 mins past the hour, the entity will always be 4 minutes behind.
I will try and get it sorted soon so that it gets updated at the half hour point.
I’ve updated the sensors so they only update at the half hour points. Would anybody like to test for me and check that I haven’t missed any other repeated queries?
I’ve copied the code into the automations and configuration YAML files, as you explained further down in this conversation, but I’m struggling to get any value to populate this entity. I can see that the API is still working with this format, but I’m struggling to see what is going wrong and where in my HA setup.
Can you give me any tips on how to dig deeper and debug this. For example is there a log hidden away that would show the results that come back when the automation fires? I can see that the automation has fired, but not sure how to see what is happening between that and the empty sensor widget on my dashboard.
Sorry about the noob question, and thanks for any insights.
Been using the new sensor.py code for a few days now , certainly cuts down to every 30 mins accessing of the octopus servers. I have not noticed any ill effects. Thanks for the update.
Great, I’ve been using it for a few days too so merged it in at the weekend, along with a few other bug fixes and updates.
I’m struggling to get Timers and run_devices to work. the timer entities get created, but they do not actually fire the switches. I added a run device because it errors without one. if I manually fire the half hour service i get tracebacks, in the logs below. can any one advise me?
my YAML:
octopusagile:
region_code: "A"
mpan: 1234567890
serial: 23456789
auth: sk_live_some_stuff
startdate: "2020-05-08"
moneymakers:
- switch.immersion_heater: null
timers:
- day_from: tomorrow
day_to: tomorrow
entity_id: switch.immersion_heater
numHrs: 2
params: null
requirements:
- day_from: tomorrow
day_to: tomorrow
numHrs: 2
time_from: '02:00:00'
time_to: '07:00:00'
time_from: '19:00:00'
time_to: '19:00:00'
run_devices:
- energy_time: 0.5
entity_id: tv_strip
run_before: '17:00:00'
run_time: 0.5
sensor:
- platform: "octopusagile"
Logs show:
2021-01-12 14:30:01 ERROR (SyncWorker_0) [custom_components.octopusagile] 'NoneType' object is not iterable
2021-01-12 15:00:02 ERROR (SyncWorker_3) [custom_components.octopusagile] 'NoneType' object is not iterable
2021-01-12 15:30:01 ERROR (SyncWorker_6) [custom_components.octopusagile] 'NoneType' object is not iterable
2021-01-12 16:00:02 ERROR (SyncWorker_5) [custom_components.octopusagile] 'NoneType' object is not iterable
2021-01-12 16:11:06 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [1798048952] 'NoneType' object is not iterable
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 135, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1445, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1484, in _execute_service
await self._hass.async_add_executor_job(handler.job.target, service_call)
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/__init__.py", line 187, in handle_half_hour_timer
start_time = next(iter(best_time))
TypeError: 'NoneType' object is not iterable
2021-01-12 16:11:35 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [1798048952] 'NoneType' object is not iterable
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 135, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1445, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1484, in _execute_service
await self._hass.async_add_executor_job(handler.job.target, service_call)
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/__init__.py", line 187, in handle_half_hour_timer
start_time = next(iter(best_time))
TypeError: 'NoneType' object is not iterable
@Rjh001 If what you want to do is run your immersion timer for 2hrs between 2 and 7 in the morning then you ca try this:
octopusagile:
region_code: "A"
mpan: 1234567890
serial: 23456789
auth: sk_live_some_stuff
startdate: "2020-05-08"
moneymakers:
- switch.immersion_heater: null
timers:
- day_from: tomorrow
day_to: tomorrow
entity_id: switch.immersion_heater
numHrs: 2
time_from: '02:00:00'
time_to: '07:00:00'
run_devices:
- energy_time: 1.0
entity_id: tv_strip
run_before: '17:00:00'
run_time: 1.0
sensor:
- platform: "octopusagile"
I think you only need that inner time requirement if you are trying to force actions within the overall window you are allowing for your timer , but your overall timer window is 0 hours long since it starts and finishes at 1900 tomorrow - if that makes sense. Also I’ve never had success trying to define a requirement that is only 0.5 hours long , try 1 - see above
Thank you - that makes perfect sense. I’ve loaded that config again and update timers runs without error. Lets see if I wake up with hot water
So I thought I’d fixed the 0.5hr issue, it turns out I probably haven’t. I will take another look. If you want to test the timers switching on without risking no hot water in he morning, you can change the times on the timers entity to something sooner.
I’m wondering if anyone has any insight into the best ratio between the number of hours you are wishing to be active in a timer and the length of the time window you are allowing for it. For instance if you want to be active for two hours (NumHrs) in a two hour window (time_from to time_to ) there is zero point running the integration, with a ratio of 1:1 you may as well just set of a simple automation based on a start time. At the other end of the spectrum you have a 30 min active time that could run at any time in a 24 hour window, clearly this ratio 1:48 gives you the greatest potential benefit. Leaving aside any real world considerations etc. I’m wondering if any work has been done on identifying the minimum ratio which still returns a statistical benefit ?
For my own part I try to allow a ratio of at least 1:3 , but that is based on nothing but a feeling – I’m curious to know if anyone has any more solid an insight to offer.
Using the Custom Component markgdev/home-assistant_OctopusAgile
I’ve noticed the addition of the average price sensors.
I’ve updated my custom component, but they haven’t appeared.
Do they only get created once a day?
Or have I done something wrong?
Thanks,
Bruce.