Archived Forum

If you could convert your pulse into watt hours, if your pulses are 100 pulses per kWh then for every 1 pulse you could sent the value 10.

You should be able to then use the input processor kwhinc_to_kwhd2, that should generate kwhd values.

To get the histogram to work you will need to calculate power in watts on the emontx itself and send that to emoncms which you can then use in the normal way to generate histogram data.

hope that helps

Hi.

Please allow me to hijack this thread, as I'm facing an issue that I think is similar.

I setup a sensor on my gas meter, to detect the turn of the least significant gear.

The TX increments a counter each time the gear gets to 0.

I don't want to send a frame only at each turn, because the RF link is not reliable enough. Hence the counter, that I send at least each minute, more if the wheel turns.

Example:

t val
7:12 29
7:13 29
7:14 29
7:15 30 <- if I miss this frame
7:16 30 <- I get this one a minute later, so the total is correct
7:17 30      only the power is a bit shifted in time
7:18 31
7:19 33
7:20 33
7:21 33
7:22 33

The issue with this is with the postprocessing.

The power calculation is the following: P = (val(n) - val (n-1)) / (t(n) - t(n-1))

This is wrong because the energy consumed during the whole last gear turn is attributed to the time interval between last frame and now, whereas it should be attributed to the time interval between last index change and now.

Two options:

- Only record input if the index actually changed. Keep post-processing as it is. This way, the power will be averaged on the whole period, which is the better precision we can have. I wanted to modify emoncms's code do this, but I'm realizing this might not be possible with timestore, right ?

- Record all inputs, then improve post-processing to be able to attribute the power to the whole time interval. This requires the capacity to go back in time to find the input time and value when the index last changed. Moreover, this means to be able to change the feed values a posteriori.

I don't think we can compute the power in the TX, because we don't know the power realtime. Only when the meter index increments do we get to know the power on the last time period.

I don't see a way to do this that does not break the code architecture of emoncms.

Trystan:

If you could convert your pulse into watt hours, if your pulses are 100 pulses per kWh then for every 1 pulse you could sent the value 10.

If you do this, for an input like

7:12 29
7:13 29
7:14 29
7:15 30
7:16 30
7:17 30
7:18 31
7:19 33
7:20 33
7:21 33
7:22 33

you'll get

7:12 ?
7:13 0
7:14 0
7:15 10
7:16 0
7:17 0
7:18 10
7:19 20
7:20 0
7:21 0
7:22 0

The power is not properly averaged. If the time interval is small, it can generate power peaks higher than the actual power of the boiler.

If viewed through a one hour period histogram, this may be averaged about correctly in real life use cases, but is thi satisfying ?

Just submitting my questions and doubts. I don't have a solution right now.

- Only record input if the index actually changed. Keep post-processing as it is. This way, the power will be averaged on the whole period, which is the better precision we can have. I wanted to modify emoncms's code do this, but I'm realizing this might not be possible with timestore, right ?

I just did a simple modification inspired from this. In fact, it should work with timestore. I just needed to get my head into the process model.

I modified the input() function to allow process functions to return NULL to stop the processing.

Then in pulse_diff function, I return NULL if the index has not changed. This way, the feed is modified only if the index is modified. The graphs are now going to look nice.

Here's the diff:

https://github.com/Jerome-github/emoncms_emoncms/commit/51644bc899c3e0fe...

As far as I understand it, this modification in input() should not affect any existing processing function, the merge should be safe.

We could modify kWh_to_power instead, but I don't think it would be a good idea. Consider a case where an index is sent on a regular basis, then you can expect to receive

1664 (One index every hour)
1664 <- No power during last hour
1664 <- No power during last hour
1678 <- Consumption of 14 units during last hour

In this case, losing the information that at time = 2h, nothing had been consumed would be a loss of information.

However, I believe the pulse_diff function is meant precisely for use cases where a pulse is sent each time a counter increases, not on a regular basis, so this should not be an issue, as an index will be sent for each pulse, which is the best resolution available.

I'll try it a bit then send a pull request when I'm happy with it.

One thing I don't like: the hardcoded "1" that stands for "if index increased by more than *1* times the number of seconds since last update, then there must have been a wraparound". It means that I assume my meter should not turn faster than *1* round per minute. This may depend on the meter and I'd like it to be an argument to the pulse_diff process, but unfortunately, it already has an argument, which is the feed to log the index to, and we need that too, to get the last value of the index and compute the power.

Edit: Actually, this approach is both complicated and wrong. I'll try to come back with a better one.

Hi, I have a gas meter and a KWh meter that send only a counter value ( i.e.  42 43 44 45 46 ...etc) every time the counter is incremented. I would like to convert those pulses to watts . Unfortunately the Arduino cannot send also a time information (since it is in low power mode and millis() does not work).

I thought also that I could send the counter value every 15 min, but then if a packet is loss I wouldn't have reliable watt hours.

I think that Emoncms has the time information about when the data has been received. I could do

(counter(1) - counter(0))*(time(1) - time(0)) and have the watt value 

is it possible to do such a thing?

Thanks 

Filippo