I have an input process that looks something like this:
log to feed -> feed1
rate-of-change -> feed2
x 60
log to feed -> feed3
The raw number posted to the input ends up in feed1 ok, and it's delta from the previous reading ends up in feed2 nicely, but feed3 always remains 0. It's as if rate-of-change doesn't pass its result on down the chain. Is it supposed to?
Re: rate-of-change process....
I don't recognise this logic. What is the context?
Re: rate-of-change process....
What is the context?What is the context? What is the context? What is the context?What is the context?What is the context? emoncms inputs to the dashboard (eventually).
Re: rate-of-change process....
OK, thanks (says he, none the wiser).
Mental note to self - stay well clear of the Software forum 'cos you won't understand a word of it!
Re: rate-of-change process....
Sorry, I should have included more context with my original posting.
The feed is the number of pulses counted in the last 60 seconds. Each pulse represents 1Wh of consumption. The rate-of-change process gives me the delta since the last posting, which represents Wh/min. Multiply that by 60 to get Wh/hr, or Watts.
To further confuse you, I had a typo in my original posting (x6 instead of x60) which I'll correct once I post this reply.
I've got feed2 going to a dial, where I can specify a x60 scale to get it in watts. But I also want to be able to store the x60 value for graphing. So at the moment, my dial represents watts (well strictly average watts over the last 60 seconds), but my graph remains a plot of "pulses per min" which is not so user friendly:
http://emoncms.org/dBCC/tled
Re: rate-of-change process....
While I understand what you are trying to do, I'd like to suggest a (better) approach.
Since 1 pulse = 1 watt hour, then if you only calculate the number of pulses over 60 seconds you don't get an idea of power spikes within a short period (say, 30 seconds) - instead, only the overall level will go up for that minute.
A better way to do this would be to time the pulses. Here's some Arduino code that I use:
void onPulse()
{
//used to measure time between pulses.
lastTime = pulseTime;
pulseTime = micros();
// ignore first pulse
if (lastTime > 0) {
//Calculate power
power = (3600000000.0 / (pulseTime - lastTime));
//Print the values.
Serial.print("PulsePower: ");
Serial.println(power,4);
}
}
Basically you time how many seconds (or in this case microseconds) between pulses and divide that by the number of (micro)seconds in one hour * 1000. Then, for each pulse, you log it to emoncms. (I use a python program to read the serial port of the Arduino then send it to the API). It's better to log per-pulse so you get a better idea on "transient" power spikes (ones that happen very quickly) rather than only doing it on a per-minute feed.
Hope this helps!
Re: rate-of-change process....
Logging the occurrence of every individual meter pulse sounds like an awful lot of data.
What happens when micros() overflows every 70 mins? Maybe you could use millis() which is good for 50 days.
Re: rate-of-change process....
Yeh, I'm fast coming to the conclusion that pulse-based stuff is good for tracking what the meter is saying without having to go out and read it, but problematic for any kind of "instantaneous" consumption calculation.
This is particularly true of my water meter that pulses every 5L consumed.
When it ticks at 7am say, there's no way of distinguishing between someone just drawing out 5L in a rush, or the dishwasher using 4.9L the night before and someone just having a glass of water the next morning, or a slow leak somewhere that finally ticked over at 7am
If you attribute the entire 5L consumption to the 7am sample, you get a spike and it looks like a very big glass of water. If you attribute it to the entire interval since the last tick the night before, then it looks like you've got a slow overnight leak. Any of these scenarios are possible and indistinguishable. I guess the best you can get from it is gross usage figures like L/day and then keep any eye out for unusual behaviour.
Re: rate-of-change process....
Recording each individual pulse is fine, it's what you then do with all that information that really matters.
I think it's important to decide up-front what the system needs to do before starting to build it. System design is everything.
(not that I always follow my own advice!)
Re: rate-of-change process....
You're probably right about the micros at least. But it's not that much data - 1 row per data point, at 8 bytes per row (4 bytes for a int and 4 for a float) isn't that much. Even the index is only another 4 bytes or so. Plus this is only talking about the realtime data - personally I only want to store that for at most 30 days, so I just prune the mysql table using a cronjob once a month. :)
Edit: I totally agree about the point that you have to know up front what you want to do and how much data you want to store! I knew that I only wanted a certain resolution for a certain number of days so for my situation registering per-pulse data is perfectly fine. Your situation could be different. :)
Re: rate-of-change process....
Your situation could be different. :)
Yes, I want my PV Router to work as effectively as possible - and record nothing!
Re: rate-of-change process....
Here's some code I've been working on for my pulse counting: https://github.com/oscarcarlsson/sensors/tree/master/PulsesEnergyMeter
It tries to do some preemptive lowering of power measurements when power is declining.
This is particularly true of my water meter that pulses every 5L consumed.
I've seen water meters with 85 pulses/liter.
Re: rate-of-change process....
I've seen water meters with 85 pulses/liter.
Wow... with a reed switch? If everyone hits the showers at the same time I've seen up to about 100L/min flows. That would get that meter chattering away at 142 Hz! I think my pulse counting h/w is only good for about 12Hz on each of 4 channels. Anything faster than that gets sucked up by the debouncing logic.
Your time-decaying averaging code looks good, thanks for the pointer.