Archived Forum

would be useful.

Might be worth looking at a previous discussion about splitting the night and day usage http://openenergymonitor.org/emon/node/677

Eamonn

Thanks EnergyRnR , that is a firmware implementation.

I'm more into the emoncms having some Input process rules that deliver data to specific feeds configured by time schedule.

It should be very simple to implement, but i'm no javascript guy.

Hi, I'm looking for exactly the same thing, a dual bar graph.

- one for day

- the other for night

In fact after one night of reflection, we didn't need to change the Bar Graph.

We just need to adapt the feeds.

- Daily Power Feed : Power since 6AM to 9PM (for exemple)

- Night Power Feed : Power since 9PM to 6AM (...)

It's just a part of the 'normal' power feed !

I think it has to be done inside : emoncms/Modules/input/process_model.php

A new fonction like : kwh_to_kwhd (but for day night).

Right, nomad. Assuming the server data is reliable (and timezones are accounted for), it shouldn't be too difficult in a processing function with the time periods hardcoded.

However, I wonder how the parameters can be passed through the GUI.

emoncms is limited to one processing chain by input (not such a problem here) and one parameter per function (this, however, is an issue here, IMHO).

We could get around that by using a bitmask as the input (a long with the first 24 bits representing each hour), at least for hourly granularity.

Then you could have two processes on the same input - one a daily accumulator for hours 20 through 06 and the other for 07 through 19, or whatever.

One issue is that the accumulator processes return the new total value, not the input value, so the processing chain can't easily run through two accumulators even if they were set up with different values.

In addition to daisy-chaining processes so that the return of each step is passed as the value to the next, you'd need to be able to access the actual input value at the same time. (Or just allow multiple processing chains for each input, which would be much cleaner).

[edit: you could simply modify the sketch to submit the energy input variable twice, thus allowing two processing chains. Ugly, but works out of the box)

Good point about the bit mask.

Multiple processing chains would definitely be something nice. I think it has already been asked for, and it wasn't that easy.

We may open an issue on github about this.

Meter is in charge of tariff selection and recording usage registers, if we follow traditional system. And it should be easy to implement in node side and feeding  is also could be Energy_T1, Energy_T2, Energy_T3 and could plot on the dashboard.

I don't understand everything for the moment !

The emonTX does not know the time. I suppose we could try to synchronize it, but this is not trivial.

Hi Jerome

The EmonGLCD receives time from the emoncms server so would it not be possible to do something similar on the emonTX?

Regards

Ian

Possibly, yes. I don't know the emonGLCD, but I suppose this would imply having the RF permanently receiving, hence no sleep mode.

Some like their TX on battery, so sleep mode is nice.

There may be other issues, I don't know.

Hi,
I'm very interested in any progress in multiple tariff support and also multiple processing chains or at least the ability to use a feed in a process the same way we can currently use an input.

I have set up a temporary workaround to support multiple tariffs until a better solution is available, currently I'm able to log  current use, daily totals, running totals(equal to meter readings), costs per hour and costs per day separately for peak, off-peak and all day periods.

Cost calculations use a tariff rate to 3 decimal places (0.001p). All the calculations are done in emoncms from the basic emontx node data plus an additional tariff node which consists of three inputs.

This additional node is currently just 2 python scripts on my windows machine, task scheduler runs onPeak.py to switch to Peak period and offPeak.py switches to off-peak period, each one is run just once a day. The scripts are basically Jeromes example script for using sockets with oem_gateway, each one has static variables for the next periods tariff.

The string transmited is "nodeid" "currentrate" "onpeak" "offpeak" . 

currentrate is the next periods rate in pence multiplied by 1000 (like voltage is x100), onpeak and offpeak are either 1 or 0 for the incoming period.

All the processing has to be done on the emontx inputs as the tariff nodes inputs are only updated twice in 24hrs. This can be done by "zeroing" an inputs process list after it's last process using "allow positive" followed by "allow negative", then using +input you can reuse that input for another process list.

As I previously said this is a workaround its a bit mucky but it seems to work ok. I want to change the "tariff node" source but have not yet worked out the best route. I was thinking of moving the scripts to the pi as thats always on, but I'm not sure how to use time/clock/scheduling etc in linux yet, maybe I need a rtc or something.

Maybe somebody has a better solution or knowledge of how to change that.

Should anyone be interested I can explain the calculation processes I've used a bit more but this post is getting rather long and to be honest if your comfortable using emoncms its quite straight forward once you have the inputs and have "zero'd" a couple of inputs to reuse.

Paul

Hi,

Quick update on the multi-tariff work-around, I just sat down this evening to "work-out" how to automate running the tariff scripts on a pi. it took all of 3mins to learn about and implement a cron, so now I have the scripts to change the tariff period running from the same pi as the oem_gateway, much tidier :-)

I'm new to linux and was quite surprised how easy it was (and kinda embarrassed I previously stated I didn't know how to)

Paul

Hi,

Just to make people aware, I have a time-of-day filtering process pushed to Git. It's discussed in this parallel topic.

Combined with the reset process you should be able to easily chain together multi-rate billing.

FYI, watch out for / modify the use of UTC in the process function - changing gmdate to date may give better results. I had emoncms.org in mind when I wrote this, but for a local install, using the Pi's local time is probably better.

The ideal solution is to have emoncms record your actual timezone and use this to interpret the filtering, so I'm going to try and look at that next, rather than fiddling with this single function.

Your link doesn't seems to work ... 'this parallel topic'.

Good catch. The forum software put http:// on the front of my already fully-qualified URL...

Check this: http://openenergymonitor.org/emon/node/10019

Hi Paul - Would you mind posting a screenshot of your input processing please?

On my emoncms.org account I have managed to create a working multi graph showing the total kWh per day, and overlaid on it I have the separated components of this total, detailing the Day/Peak kWh/d and the Night/Off-Peak kWh/d. I have been attempting to multiply my night and day kWh/d totals by the relevant cost rate but its not working for me, the kWh/d does not seem to pass on its daily total to the next line which is my multiplier. The instantaneous power vale from my CT seems to be 'passed through' the kWh/d processor to the next line...at least I think that what's happening...

If you get time to post your working processing chain it might be clearer to me what I should be doing.

Failing this, I can probably create a separate zoom visualizations for day and night kwh/d totals and provide the correct cost rate directly to each zoom chart. I'd love to get it working at the input level however as that wold allow further calcs to be done for hours, days weeks etc..

Here's mine if it helps. Steps 1-4 are legacy and just there to capture a total count until I remove them later. The schedule "Economy 7 Night Rate" for me is just a single "00:30-07:30" as per my meter.

(not sure how to inline image, attached)

[Read the last line of Site Map - Moderator (RW)]

Hi - Thanks for helping. I guess we are using different versions on Emon as my Input config looks to have different options (I am using emon.org for this)...Anyways, I have included a screenshot of my config to help explain my problem.

I would like to multiply line item 9 x line 10. Emon seems to be actually multiplying line 7 x line 9.

I have tried some other options and ordering over the last few days but just cant seem to get it correct...

Any suggestions appreciated 

I'm no expert on emoncms, but I think I've seen that the behaviour you're seeing is in fact correct, i.e. the result from power to kWh/d is not passed forwards. See http://openenergymonitor.org/emon/node/10938#comment-32031

Peter is using emoncms v9.0 which has some new processing stuff developed by Chaveiro, hopefully this will become available on emoncms in due course, in the meantime...

Robert is correct the power to kWh/d does not effect the value passed through it to the next process, it just uses the data to calculate the kWh/d without altering it.

"I would like to multiply line item 9 x line 10. Emon seems to be actually multiplying line 7 x line 9." 

line 10 is the result, I assume you mean you want line 8 x line 9?

currently line 10 is a running tally of the cost per hour at any given time, if you now log that using a "power to kWh" and or "power to kWh/d" you will by accumulating the cost rather than kWh's (just think of them as units not pence or watts) you might need to apply some scaling as the "power to" processors use a x0.001 scaling to output kW's from an input of W's eg

11) x1000 (you can use a different value to incorporate pence to pounds scaling etc)

12) power to kWh  (total cost to date)

13) power to kWh/d (cost to day)

Paul

Thanks Paul, I did indeed mean 8 x 9. Neat trick with the kw accumulators, I should have realised they really just accumulate numbers, the actual 'units' of measure don't matter. I have now set up my input as u suggested and it seems to do what I needed. I will let it accumulate for a week or so and then I will know for sure. Assuming it does work, I will post back with a screen shot of my processing chain so other people can use it - this does seem to confound a lot of people getting started off..

Many thanks

Hi,

i get a signal when the rate is low (0) and the rate is high (1).

Anyone have an idea how can i use this to log the power for one rate and the other. I see that with schetuler you can't use input values.

Tnx for the help.