@james_hiscott I’m hoping that is just a transient issue due to the way the apps restart and threading in appdaemon, as there is no way the new code should be able to get there if hours = 0.
yup, restart of appdaemon fixed it. Should of tired that first. 
PS. that 1.7 update is a very nice idea. Thanks for all the hard work on this, it is the backbone of lots of my automatons now
1 Like
Been reading this topic with interest because I’m thinking about getting an EV and I’m already with octopus (albeit a normal plan), I was wondering if there’s anyway to dynamically get the best n hours?
I’m thinking about the following potential scenario. I know my ev needs so much power to fill which I dynamically work out means today I need 3 hours charge, then I could query your component to find the cheapest 3 hour charge today. But tomorrow it could be 2 hours etc. Possible?
With the node I wrote, yes you can specify the window size. Just always request a number of windows, they are returned as an array.
However, one of the gotchas currently is that the assumption is the cheapest window will be overnight. Recently (in the UK) that has not been the case.
I really need to add some additional logic so you can specify the window within which you want the cheapest period window, so between 8pm and 8am when the car is home for instance. Currently with the cheapest in the afternoon, the car would not charge overnight!
That’s what my script a couple of posts up does. You can supply the from and to times (within “now” to the end of the available data), and it returns a list of 1–8 block (30m to 4h) cheapest periods within those times, assuming equal power consumption across the window. In reality, an EV will slow its charge down as it nears 100%.
1 Like
Hi all - relative new comer to HA - I’ve been gradually been migrating my domoticz setup and now i’m looking to add Octopus usage data to my new dashboard.
I’m currently pursuing the Octocost option but getting stuck right at the end.
Over the last few days I’ve installed the SSH module, HACS, APPDaemon and installed the Octocost app through HACS and configured my Octopus API settings in Apps.yaml all without issue. But for some reason, I’m not seeing any of the sensor entities show up.
There’s nothing obvious in the log.
Until now, all my integrations have shown up automatically, and that’s what I was expecting having added my API settings and restarted the server, but nothing - no Octopus entities in config/entities at all.
The last step in the Octocost readme shows the attached - as a newcomer I thought this was just a markdown way of illustrating what lovelace UI should be rendering automatically but am I supposed to do something manually? I tried it in configuration.yaml but from the error messages - that is obviously not the correct place for it.
Many thanks
Check the AppDaemon logs.
Hey @baz123 - thanks hadn’t thought to look into AppDaemon stuff at all
Logs themselves are empty but the ‘state’ column for the Octocost app shows initialize_error
1 Like
Can you restart AppDaemon, then refresh the AppDaemon logs and see if they have anything useful in. Also could you post your apps.yaml configuration for Octocost, with sensitive information (MPAN, Serial number, API auth key) redacted
1 Like
As @badguy says, if you restart AppDaemon and refresh the logs, you will probably see an error message (if there is one). Need to keep refreshing - doesn’t auto refresh.
getting somewhere now
Logs show this
2020-04-24 10:44:09.362206 WARNING octocost: ------------------------------------------------------------
2020-04-24 10:44:09.360828 WARNING octocost: Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/appdaemon/app_management.py", line 145, in initialize_app
await utils.run_in_executor(self, init)
File "/usr/lib/python3.8/site-packages/appdaemon/utils.py", line 276, in run_in_executor
response = future.result()
File "/usr/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/appdaemon/apps/octocost/octocost.py", line 25, in initialize
self.run_every(self.cost_and_usage_callback, time, 120 * 60)
File "/usr/lib/python3.8/site-packages/appdaemon/utils.py", line 191, in inner_sync_wrapper
f = run_coroutine_threadsafe(self, coro(self, *args, **kwargs))
File "/usr/lib/python3.8/site-packages/appdaemon/utils.py", line 285, in run_coroutine_threadsafe
result = future.result(self.AD.internal_function_timeout)
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 439, in result
return self.__get_result()
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 388, in __get_result
raise self._exception
File "/usr/lib/python3.8/site-packages/appdaemon/adapi.py", line 2476, in run_every
raise ValueError("start cannot be in the past")
ValueError: start cannot be in the past
2020-04-24 10:44:09.353797 WARNING octocost: ------------------------------------------------------------
2020-04-24 10:44:09.352734 WARNING octocost: Unexpected error running initialize() for octocost
2020-04-24 10:44:09.351262 WARNING octocost: ------------------------------------------------------------
and the apps.yaml
octocost:
module: octocost
class: OctoCost
region: J
mpan: <my mpan is here>
serial: <my serial is here>
auth: <my octo Api key is here>
startdate: 2020-05-05
Tried the start date in january and in may in case the error was about that.
1 Like
Interesting, your logs are saying it is 10:44, but it is only 10:06 as I write this.
So when this runs:
time = datetime.datetime.now()
time = time + datetime.timedelta(seconds=5)
self.run_every(self.cost_and_usage_callback, time, 120 * 60)
it is probably getting the correct time, 10:06(ish) adding 5 seconds, to account for delays, but finding that is still in the past, as your system thinks it is 10:44 when it tries to register the run_every… callbacks.
I’d suggest looking in to why your time shown in the logs is off.
As an aside, the apps.yaml looks ok, other than startdate, which should be when you switched to Agile Ocotopus, a date in the past.
I had this problem @mcon you may need to change your timezone (thats what i had to do) in appdaemon.yaml:
Thanks very much all - up and running now! Indeed it was the timezone that got Octocost initialising succesfully, and then the change to the start date in apps.yaml that got me there.
Interestingly, I’m not on Octopus agile but I have one of their smart meters and wanted to run this as a way to see if it was worth switching - I’ve just set the start date to Jan 1st for the moment.
It’s pulling in cost data and showing me entities as hoped - my monthly usage is accurate and is showing 650kwh which is accurate and the cost is showing as £50. £50 would be significantly less than I am paying at the moment. It’s so low in fact that I’m questioning the data. Has anyone else seen a big drop like this after switching to agile?
Any thoughts why I can no longer see the OctoBlock sensors?
Not sure when it started, but it was working, as I have only just switched to Octopus this week and no smart meter yet so have not been keeping an eye on the sensor or made any automations
Anyway, this is what I am getting and seems to be a time issue I think but cant see what it could be
My logs show the following:
2020-04-24 11:06:23.077952 INFO AppDaemon: Reading config
2020-04-24 11:06:23.353373 INFO AppDaemon: /conf/apps/octoblock.yaml added or modified
2020-04-24 11:06:23.353713 INFO AppDaemon: App 'octo_block_1hour' changed
2020-04-24 11:06:23.354171 INFO AppDaemon: Found 4 total apps
2020-04-24 11:06:23.359322 INFO AppDaemon: Terminating octo_block_1hour
2020-04-24 11:06:23.360870 INFO AppDaemon: Initializing app octo_block_1hour using class OctoBlock from module octoblock
2020-04-24 11:06:23.367558 WARNING octo_block_1hour: ------------------------------------------------------------
2020-04-24 11:06:23.367850 WARNING octo_block_1hour: Unexpected error running initialize() for octo_block_1hour
2020-04-24 11:06:23.368089 WARNING octo_block_1hour: ------------------------------------------------------------
2020-04-24 11:06:23.368608 WARNING octo_block_1hour: Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/appdaemon/app_management.py", line 145, in initialize_app
await utils.run_in_executor(self, init)
File "/usr/local/lib/python3.8/site-packages/appdaemon/utils.py", line 276, in run_in_executor
response = future.result()
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/conf/apps/octoblock/octoblock.py", line 10, in initialize
self.run_every(self.get_best_period_and_cost, time, 30 * 60)
File "/usr/local/lib/python3.8/site-packages/appdaemon/utils.py", line 191, in inner_sync_wrapper
f = run_coroutine_threadsafe(self, coro(self, *args, **kwargs))
File "/usr/local/lib/python3.8/site-packages/appdaemon/utils.py", line 285, in run_coroutine_threadsafe
result = future.result(self.AD.internal_function_timeout)
File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 439, in result
return self.__get_result()
File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 388, in __get_result
raise self._exception
File "/usr/local/lib/python3.8/site-packages/appdaemon/adapi.py", line 2476, in run_every
raise ValueError("start cannot be in the past")
ValueError: start cannot be in the past
2020-04-24 11:06:23.368852 WARNING octo_block_1hour: ------------------------------------------------------------
appdaemon.yamle
appdaemon:
latitude: lat
longitude: long
elevation: 2
time_zone: Europe/London
plugins:
HASS:
type: hass
ha_url: http://172.16.2.2:8123
token: token_code
http:
url: http://172.16.2.2:5050
hadashboard:
admin:
api:
octoblock.yaml has
octo_block_1hour:
module: octoblock
class: OctoBlock
region: H
hour: 1
use_timezone: False
start_period: now
I have tried use_timzone as false and true
I have tried start_period as now and today
I have removed both as I believe they are optional so should be “defaults” of now & false
I have checked my docker host date and time is correct and matches the log files
I am using the Open Energy Monitor’s emonCMS software at home. It has a means of using actual consumption with the Agile price. Over the last 3 months, my average price per kWh would be about 8p! that is half what I am paying.
Unfortunately, I was in the midst of moving to Octopus and waiting on new meters when lockdown occurred so I can only look at the data with envy.
If you have the meters, do the switch!
2 Likes
@matthewjporter hmm, that’s another odd one.
Could you update to the latest version of OctoBlock from the HACS page in Home Assistant, I’ve changed how the initialization code sets up the call backs in that version, so it shouldn’t have any issues (hopefully) with time being in the past.
1 Like