Announcing Pre-Release Octopus Energy Plugin

Jon (and all),
I have done the same comparison as you and I haven't had any "null" values during the period I have been testing. I hadn't been using the sql logger and so had to recreate the database so I only have data since I started looking into your report. I will keep checking, and will now output the new rate to the event log when it updates so I can also cross reference in the next version. My database knowledge is a little weak so possible I am missing something but I do see the rates changing at the correct time for each period. Have you seen any more occurrences ? I will also see if I can make sure an error is thrown to the log and to validate the rate more rigorously in case it relates to unexpected (and untapped by me) responses from the API as it looks like the period updates correctly and they are all pushed to indigo in the same dict at once so the update itself is happening.

On the max, min, average issue, on reflection my approach was lazy and inelegant (if you need to explain what a day is, then it is counter intuitive). I would welcome your (and others) feedback on the approaches I have in mind.

1) Keep the approach I have today but correct it to reflect the DST adjusted time and remove the 1 hour mismatch during BST. This would update at local time midnight, and again sometime after 16:00 Local when the remaining rates are published (22:30 until midnight). This does mean that the values will/may change at that point (my thought was as these values are indicative it may not be an issue for a use case on a control page for example, and if you wish to graph it take care to capture the values after the refresh time each day)

2) Remove the midnight update and only update once a day when the full 48 periods are available, Downside being until the refresh early evening it will actually be yesterdays figures

3) Some smart approach I have not thought of

Thanks,
Neil

I am still getting Null values, the latest one at 13:00 DST (12::00 GMT). I have had three today so far.

I am unclear as to how dynamic the data is. I realise it is changing every half-hour but is that because you are fetching it via the API or are you getting all the rates for the next 24 hours and then just updating the device state every half-hour?

Apologies, I have sent you on a wild-goose chase.

The Null values are caused by the rate not changing when compared to the previous half-hour period. If the field doesn't change, then Indigo doesn't write it to the log

I'll put it down to my harassment with my Mac firmware password issue.

So all is looking good as far as the Nulls are concerned.

Jon,
No worries on that, It was something I should have thought of with the testing and it got my SQL logger working again which I had forgotten was not running so a useful exercise.
Thanks,
Neil

I am unclear as to how dynamic the data is. I realise it is changing every half-hour but is that because you are fetching it via the API or are you getting all the rates for the next 24 hours and then just updating the device state every half-hour?

On that point I am pulling the data from the API every 30 mins which I don't actually need to do, but during testing I found some variance as to what the API returned depending on the time of day and I didn't need to maintain the result or worry about restart behaviour too much. It is on my list to enhance as I look to add in the consumption functionality but the overhead is not huge pulling 5k of JSON every 30 mins. I have noticed that the daily rates are not always available by 16:00, yesterday for example was 16:18 hence I pick an arbitrary time to be consistent each day when I refresh and to make sure the new day rates have been pushed out.

OK - I think I am getting a better understanding.

So are the minimum / maximum and average your calculations based on rates available?

If so, I am not sure what value the average gives us. It would be meaningful if the consumption every half-hour was the same. maybe I am missing something - always possible.

I would base all figures on local time i.e. GMT or BST - as this is UK based only (I assume).

Again, assuming you are calculating the maximum and minimum, then I would zero them at midnight.

Assuming you have got the figures up to 16:00, then you could set the Daily_Min_Rate. You could set the Daily_Max_Rate once you get the ~16:00 readings and correct the Daily_Min_Rate if necessary. You could also have three additional states (if you still need the average) to show the previous days Max/min/average.

Another idea would be to add 48 custom states - one for each half-hour = Rate_0000, Rate_0030, Rate_0100, Rate 0130, Rate_0200 ...
Again, these could be zero'd at midnight and left at zero if unknown.

btw - please keep in mind that I haven't got a smart meter and am just using the plugin out of interest and potential future use.

Jon,
Thanks, on the average it doesn't really serve a great purpose, I think the max and min rate are interesting data points. My thinking was you could compare to your existing fixed rate, but in reality it is not a good data point unless you have a high resting load, and do not consume much more in the peak as you need more granular data to model the savings.

I did look at the idea of 48 device states, but I thought that may be a little cumbersome (not so much to write but to consume) and thought a single device with associated metrics (and some of the states will not have data available at different times which gets messy). I can easily accommodate the changes to make it current day, and previous day may be interesting but suspect the real value will be using one of the plotting plugins, Grafana or consuming the csv I generate, which gives much greater flexibility if you want to slice and dice the rate information.

Like you I have yet to switch, but think I may be able to now as it seems my meter is now working. As soon as I do that I will get the Gas and Electricity consumption data published to new devices, electricity will have 96 states as it will have consumption and the calculated cost (using the previous days rates), gas 48 as the cost is fixed price per cubic metre. As I do that I will make sure I make a more efficient use of the API calls and persist the data.

Thanks,
Neil

Jon,
Latest pre-release version corrects the odd daily behaviour and improves the API handling significantly. Thanks again for the pointers, and as soon as I am happy with the testing I will push to the plugin store.
Neil

Now locking this topic, so new threads apply to the published versions.