Community
OpenEnergyMonitor

Community

My Electric Time Of Use App For Economy 10

emoncms
Tags: #<Tag:0x00007f1fdfca3040>

(Westerner) #1

Has anyone tried to adapt the My Electric Time Of Use app to work for Economy 10 in the United Kingdom?
Economy 10 provides 3 off-peak periods of varying length in a 24-hour period, in contrast to Economy 7 which provides just one off-peak period.


V1.1.0 App module stable release: New Time-of-use app
(Greebo) #2

I’ve just started using EmonCMS and tonight started looking through the App code for something like this.

Here I’m billed TOU with 3 tiers over 5 periods on weekdays:
T3: midnight - 7am
T2: 7am - 2pm
T1: 2pm - 8pm
T2: 8pm - 10pm
T3: 10pm - midnight

Weekends and public holidays are the lower two tiers over 3 periods:
T3: midnight -7am
T2: 7am - 10pm
T3: 10pm - midnight

The “Development: Time of use” App on my EmonSD version of emoncms contains a total of six comments so its a bit daunting to jump straight in.

If the author(s) of these apps can add any pointers to kick start me, that would great!


(Chaveiro) #3

Why not use schedules and virtual feeds instead?
See: https://openenergymonitor.org/forum-archive/node/10019.html


(Greebo) #4

Thanks for the link, I had gone looking but obviously used the wrong search terms as I hadn’t seen those archived posts.

After reading through them (and to answer your question “why not use schedules and virtual feeds instead?”), as I understand what I’ve read, that means I have to create (and store) the feeds for the different tiers individually. If I have the schedules etc setup and I forget to add a public holiday, how do I go and “reset” just that day of data to correct it?

I’m already accumulating kWh and I know what times/dates those kWh accumulated at, so I should be able to post-process that (as is being done in the Time of Use app). That means I don’t need to ensure my schedule is correct before collecting the data.

If I’ve misunderstood how the schedules and virtual feeds work, please let me know!


(Chaveiro) #5

Hi,
If the objective is to accumulate each schedule on it’s own kw/h feed, then you have to do put the logic on the input processlist ahead of posting the data, to write to each ‘period’ feed based on schedule conditions

But if you want to have a W feed for each schedule, then you can write a single ‘all’ feed on the db with all the data and than create a virtual feed for each schedule that consumes the ‘all’ feed.


(Jon Murphy) #6

@nchaveiro - virtual feeds are not behaving with lots of error messages. Trystan is looking for guidance with a possible fix:


(Greebo) #7

I’ve had more of a play around with the virtual feeds and now I understand what is being suggested. I am now confused why the TOU app that was the initial subject of this topic doesn’t use them if that is the most appropriate mechanism.

There still seems to be the same drawbacks I was originally concerned with of the fixed schedule. Maybe I’m just not “getting” the thinking behind this yet.

EDIT: I’ve also just found and read through: https://openenergymonitor.org/forum-archive/node/10977.html and I’m still not really any clearer :slight_smile:


(Trystan Lea) #8

@greebo without wishing to confuse things further, the time of use implementation used by the app can be used with any PHPFina cumulative kWh feed without needing to setup any schedules. But you may find that to get the additional breakdown that you’re after that its easier to build schedules as @nchaveiro suggests?

For an insight into the underlying API used to create the time of use app graph, you can specify any number of split points like this:

https://emoncms.org/feed/data.json?apikey=APIKEY&id=FEEDID&start=1497571200000&end=1500249600000&mode=daily&split=[0,7,14,20,22]

Of course at the moment the app is only designed for a single split point - but that’s more to do with the time I had available to build the app and the visual interface implementation than the underlying data request itself which is flexible. The UI could be adapted for a more flexible solution.


(Greebo) #9

Thanks @TrystanLea, I was certainly intending to have a go at modifying the UI to make it more flexible and that was the purpose of my first post in this thread - to see if I could get some pointers on what the code is doing without having to step through it all line by line to work it all out myself. Normally, I’d read over the comments to get a general idea of what I need to look at and what I can ignore but there wasn’t enough comments for me to do that :slight_smile:

Knowing that the API is doing a lot of heavy lifting already is very helpful, I’ll take another walk through the code, maybe comment it as I work out what each bit is doing and see how I go.


(Trystan Lea) #10

Great! The line at which the data is requested is L566.

The data returned is of the form:

[[timestamp,[splitpoint1,splitpoint2,splitpoint3]],[timestamp,[splitpoint1,splitpoint2,splitpoint3]],[...

The code itterates over the first dimension of the data array which is each set of timestamp and values L596

Because we want the ability to set an economy7 period that doesnt start at midnight, splitpoint1 will be at midnight, splitpoint2 might be at 1am (start of economy7), splitpoint3 might be 7am (end of economy7).

We then calculate the economy7 period as splitpoint2 (index: 2) - splitpoint1 (index: 1):

var economy7 = (elec_data[z][1][2]-elec_data[z][1][1]);

The standard tariff period might then span the time period midnight to 1am and then 7am to midnight of the next day, hence these lines:

var standard = elec_data[z][1][1] - elec_data[z][1][0];
if ((z+1)<elec_data.length) standard += elec_data[z+1][1][0] - elec_data[z][1][2];

The first line gets the period before the economy7 period and the second line the consumption after and up to the next day.

Once you have built each series you then add them to the bargraph series array e.g: https://github.com/emoncms/app/blob/9.0/apps/timeofuse.php#L619

Good luck! :slight_smile:


(Greebo) #11

Thanks, that’s exactly the sort of pointers I was hoping for!
I can now see clearly what is being done and where.

If I come up with something useful, should I fork the Github repo and then submit a PR or is there another mechanism?


(Trystan Lea) #12

Yes a github pull request would be great!

Trystan


(Greebo) #13

For the purposes of others who might come across this thread in future, one small correction to the example provided by @TrystanLea:

Should actually be:

(EDIT: added code tags once I figured out the right way to do it!)


(Robert Wall) #14

or should that be "split2" in each case?


(Greebo) #15

Thanks Robert, yes it should have been and I’ve now corrected my post…
Variable names aside, the significant difference was there is an additional array in the returned results that wasn’t in TrystanLea’s example. That had me confused until I manually ran the FEED API call based on his example in the previous post. The code referred to a 3 dimensional array and I initially couldn’t work out where the third dimension came from.
The documentation for that particular FEED API doesn’t exist on my local emoncms instance so it took a little while to figure this all out.

No disrespect to the great work you guys have done, I just thought I’d correct the details here to save someone else having to work it out the same way I did.

IMHO, The only thing worse than no information is incorrect information.


(Robert Wall) #16

Don’t get me wrong - I was pointing it out only so that somebody who copied and pasted and didn’t spot the typo wouldn’t call you all the names under the sun.

Funny you should say that. Only earlier today (or maybe late yesterday for you), this post appeared.

I’ve been saying (privately) for a long while that good and complete documentation would dramatically reduce the numbers of repetitive questions on this forum, but unfortunately, documentation isn’t ‘cool’, it’s a good chunk of the 99% perspiration that follows the 1% inspiration.


(Trystan Lea) #17

Hello @Greebo @Robert.Wall I dont think we will ever achieve perfect documentation, we have worked really hard on this over the years and in particular the last year. We do think documentation is important and certainly don’t view it as ‘uncool’.


(Trystan Lea) #18

@greebo sorry about the mistake with the array brackets, thanks for adding the clarification, I will amend my post too


(Greebo) #19

@TrystanLea, all good! I don’t want anyone to think I don’t really appreciate the assistance so far. I really do!

I’ve got an updated app working showing me my three different tiers. I’m using hard-coded splits at the moment (baby steps!). The next step is to add in the weekend/public holiday handling, then dig into how the config settings are determined/stored/requested.

I’ve still got some way to go on this before you’ll be seeing a PR for the new App, but while I’m going through adding comments and changing things, I’ll see if I can retrofit those comments back into your “Development: Time of use” App and PR those if you think that is worth doing.

Your handful of pointers above really gave me the jump-start I was after.


(Trystan Lea) #20

Thanks @Greebo, I’ve just spotted this pull request from Stuart Pittaway from last night, it sounds like your working on similar goals and might be worth comparing notes?: https://github.com/emoncms/app/pull/32