Can you fix the release version, please?
Done, created a tag 2.2.2 not a release at this point
1 Like
Excellent.
Could you add an average to this tooltip? Text could easily be smaller - see size relative to scale text size.
Still getting invalid time period for since Midnight 1st.
I happened to notice this when the data downloaded
Current date and time : 2020-10-26 21:23:57
Using emoncms feed: 35
Feed meta data: {"interval":1800,"start_time":1598916600,"npoints":2592}
Request from: 2020-10-25T00:30:00+01:00
Number of data points: 48
2020-10-25T00:30:00+01:00 0.218
2020-10-25T01:00:00+01:00 0.188
2020-10-25T01:30:00+01:00 0.188
2020-10-25T01:00:00Z 0.181
2020-10-25T01:30:00Z 0.231
2020-10-25T02:00:00Z 0.843
2020-10-25T02:30:00Z 3.698
Not pretty and not good to change formats! I should say this is Octopus problem and the reason my Node-RED node stopped working earlier in the year I suspect.
Fortunately PHP does parse the Z correctly! It is also fortunate that for us Brits, Z is local at this time!
1 Like
I believe that Octopus use (correctly) ISO-8601 spec for times and dates. ISO 8601 - Wikipedia
As such, what you see is quite legitimate.
<time>Z
<time>±hh:mm
<time>±hhmm
<time>±hh
…are all perfectly fine, and the parser should handle them without trouble. Javascript’s date handler does manage them fine in Node-RED, in my experience.
What problems did you run into, and what code was doing the parsing?
And I didn’t say otherwise. What I said was that it was inconsistent and should use +00:00 for consistency.
Assume nothing.
As I have said before, Python does not translate the Z correctly and always uses it as local time. It is a feature not a bug.
OK, I’m sensing some upset there, and I’m not intending to be awkward, or accuse you of saying anything you didn’t say. Just trying to help.
The point I am trying to make is that the changed offset layout is perfectly standard and acceptable for ISO-8601, was probably automatic, and technically the format has not changed (in terms of breaching standard), though the manner of representation may have. It has properly reflected a change from +01:00 (i.e. BST) to Zulu time (GMT) in a way that is accurate for the standard, and clearly signals the local timezone offset in which those datestamps were recorded, at the the time of record. It’s entirely on-spec to record +00:00 as Z - in fact, it’s the preferred way (but “+0000”, or “+00” are also possible).
When I said the parser SHOULD handle them, it was meant in an RFC way, not as a general ‘maybe it will’ way. If the parser is ISO-8601 compliant, then it WILL handle them, and it SHOULD handle them if it wishes to be standards-compliant. That’s all I meant - I wasn’t assuming anything.
I also wasn’t referring to Python; you mentioned Node-RED in your post, and that uses Javascript, so I was following that line of enquiry. As you suggest, PHP’s parser also eats ISO-8601 dates/times properly, so is also standards-compliant. I have no idea about Python; I rarely use it, don’t like it much (precisely because of ‘issues’ like this sort) and my Octopus API fetches are done using Node-RED, not Python.
Apologies if you thought I was being argumentative - absolutely not intended at all. Was just pointing out that the behaviour, as observed, is perfectly acceptable for ISO-8601, in case it wasn’t immediately obvious. I make no assumptions as to your level of knowledge about it, I assure you, and did not mean to offend, if I did.
1 Like
Not at all and I know it meets the standard. My point was it wasn’t consistent and it would be much better practice to make the output consistent.
According to the standard, email addresses are case sensitive. Fortunately most implementations ignore case. Just because a standard says you can, doesn’t mean you should.
Does that help at all?
I know all about that but it is not a builtin module so those that don’t will try and parse an ISO date with Z and wonder why it doesn’t work properly.
@TrystanLea, I came across this work Octopus Smart Energy forum today. 7 day forecast is pretty interesting.
Now available as a JSON output…
1 Like
Brilliant, that will be useful! Thanks
1 Like
@TrystanLea - I have just invested in a QHD monitor and the Agile graphs do not adjust correctly.
Seems there is no maximum height for the chart, it just uses a % of the available area and always hides the bit at the bottom therefore. The width seems to be fixed as well.
Could you also investigate a means of exporting the half hour totals as CSV please?
New feature: Custom date range entry and CSV download
As requested by @borpin
Available in the latest version of the app’s module (v2.2.4) via standard emoncms update procedure.
-
Click on Download CSV button to download all data in the selected window, including half hourly consumption, agile price, half hourly cost etc.
-
Enter a custom date range in the timepickers below the graph to select a custom period. Useful for lining up the view with your bill. Be sure to add +1 day to the end time, as it is otherwise 00:00:00 midnight, the start of the day entered. E.g my bill states 5th Nov to 10th of Dec, but I needed to select 11th of Dec 00:00:00 = end of the day on the 10th… for the bill to match… which it did exactly.
1 Like
New feature: Half hourly grid carbon analysis
I’ve added an option to show UK grid carbon intensity and calculate the average intensity of the consumption in the window (based on the time of use). This is optional and turned off by default.
The data is based on the intensity imported from Carbon Intensity API
There’s also a script in usefulscripts that can be used to import this data onto a local emoncms installation: usefulscripts/carbonintensity at master · emoncms/usefulscripts · GitHub
I would like to caveat this feature though that whilst I find it interesting, this kind of carbon intensity analysis is far from perfect. It doesn’t really capture what the aggregate effect would be if everyone consumed electricity at what are currently times of low demand and low intensity, nor does it capture a more complex view of long term electricity system decarbonisation and adoption curves of measures like switching to heat pumps or EV’s. Octopus agile is also a renewable tariff. Views differ of course on how these factors should be accounted for 
I’ve added this feature as a point of interest more than anything.
1 Like
Nice feature.
Could the price (and Crabon intensity) data please be downloaded locally. As discussed, if the API suddenly limits historical information, the historical consumption data would not be very useful (as you’d lose the cost). It’ll also reduce the load on the remote server.
Could you fix the graph scaling? On UHD monitors the graph is terrible (fills the page) and you always have to scroll to get the detail at the bottom.
[edit]
I also think a table with monthly / annual data would be really useful.
Thanks @borpin
Emoncms apps are not really setup to handle the process of importing data locally in that way, but I agree it would be nice. It’s just not particularly easy to do unfortunately in a way that doesnt require command line. Perhaps some kind of extention of the sync module to allow local download of a range of datasets could work, but thats a fair bit of development. There’s a reason I haven’t done this yet.
Ok, and yes Id like to do the longer term views including daily and monthly.
I put the following chart together in a spreadsheet using the new range selector to get the monthly average values, one month at a time:
1 Like
This may be the wrong place to post but…
I have a house battery and I would like to exclude the power from this in the Agile graphs. I tried this by creating a Virtual Feed but it is not selectable in the app.
Any help would be great!
Do you have a single feed for the battery charge power and another for discharge or a combined feed?
Can you subtract the battery power from the house import using input processing? That’s how I calculated my lighting and appliances feed for the last graph I posted above…
The feeds are separate but created from different nodes.
I was trying to create the feed by subtracting but I couldn’t work it out!