CDEF effects entire timeline

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CDEF effects entire timeline

SolarMan
I have a simple application to determine the power generated by a water heater. One sensor (TEMPIN) measures the in-flowing cold water temperature while a second sensor (TEMPOUT) does the same for the hot water exiting the heater. The flow rate is constant and samples are stored in an rrd database.
Using rrdgraph I want to display the time series of the temperatures plus the generated power in Watt. I planned to use a CDEF to calculate the power by multiplying the temperature difference by the flowrate and a constant and divide that by the time between two successive samples. A python script does it all for me. Samples come in nominally - but not exactly - at a one-second interval, therefore the CDEF does the division using a value calculated in python using rrdtool.last() just before every rrdtool.update() call and NOW in the CDEF as you might guess. Seems not all too complex you would say....
BUT: I noticed that the entire Power graph (PWR) jumps up and down over the entire time range when the time-interval (hence the division) changes and that is clearly not what I want.
Here is the CDEF (as a python snippet):          
 "CDEF:PWR=TMPOUT,TMPIN,-," + str(flowrate) + ",*,0.06978,*,NOW," + str(prevtime) + ",-,/",
I spent many hours reading all the available material on CDEF, VDEF etc. but this fenomenon apparently has never come up - or this is a feature "by design".
How can I accomplish that the power is calculated and displayed truly momentary per step even when the measuring interval varies?
Thanks everyone!

Reply | Threaded
Open this post in threaded view
|

Re: CDEF effects entire timeline

Jacques du Toit
Hi

If I understand you correctly….I think you’re having issues trying to use NOW because rrdtool will snap to the 1 second grid skewing your calculations ever so slightly. I don’t think it’s really designed for that. It would probably expect DEF like ( TMPOUT, TMPIN, AMOUNT_OF_WATER) and then just graph the values with something like:

CDEF:PWR=TMPOUT,TMPIN,-,AMOUNT_OF_WATER,*,0.06978,*

And then let rrdtool calculate the value per second (which is what you have with your 1 second step).

But I can see that unless you measure at precisely 1 second intervals down to the millisecond your values will be slightly erratic as the amount of water will vary for each 1-second RRA.

Something I would try to do is to compensate for this using python to store the millisecond value since the last measurement (period = time_now - last_measured_time). Then do something like:

DEF:TMPOUT=…
DEF:TMPIN=…
DEF:FLOWRT=…
DEF:PERIOD=…
CDEF:PWR=TMPOUT,TMPIN,-,FLOWRT,*,0.06978,*,PERIOD,1000,/,/

But it’s a bit counter rrdtool to save the “step” in an rrd in this way. You might actually just be better off doing all the maths in python and just writing the PWR as a GAUGE value in rrdtool…that’s probably what I’d do, but I’m lazy with RPN that way… :)

Cheers,
  Jacques

On 14 Feb 2017, at 20:31, SolarMan <[hidden email]> wrote:

I have a simple application to determine the power generated by a water
heater. One sensor (TEMPIN) measures the in-flowing cold water temperature
while a second sensor (TEMPOUT) does the same for the hot water exiting the
heater. The flow rate is constant and samples are stored in an rrd database.
Using rrdgraph I want to display the time series of the temperatures plus
the generated power in Watt. I planned to use a CDEF to calculate the power
by multiplying the temperature difference by the flowrate and a constant and
divide that by the time between two successive samples. A python script does
it all for me. Samples come in nominally - but not exactly - at a one-second
interval, therefore the CDEF does the division using a value calculated in
python using rrdtool.last() just before every rrdtool.update() call and NOW
in the CDEF as you might guess. Seems not all too complex you would say....
BUT: I noticed that the entire Power graph (PWR) jumps up and down over the
entire time range when the time-interval (hence the division) changes and
that is clearly not what I want.
Here is the CDEF (as a python snippet):           
"CDEF:PWR=TMPOUT,TMPIN,-," + str(flowrate) + ",*,0.06978,*,NOW," +
str(prevtime) + ",-,/",
I spent many hours reading all the available material on CDEF, VDEF etc. but
this fenomenon apparently has never come up - or this is a feature "by
design".
How can I accomplish that the power is calculated and displayed truly
momentary per step even when the measuring interval varies?
Thanks everyone!





--
View this message in context: http://rrd-mailinglists.937164.n2.nabble.com/CDEF-effects-entire-timeline-tp7583504.html
Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com.

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users


_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: CDEF effects entire timeline

SolarMan
Hi Jacques,
Merci, yes I have been considering something like you suggest, using
python to calculate the delta-time more accurately than using NOW in
the CDEF or storing the power in the rrd database at data capture time.
Finally I ended up improving the data capturing timing (on an Arduino)
to provide the samples nearly exactly at a one-second interval so I can
discard the division.
Remains the question why rrdgraph does what it does, since it seems so
awkward...
Thanks anyway!
Regard,
hans

On di, 2017-02-14 at 12:49 -0700, Jacques du Toit [via RRD
Mailinglists] wrote:

> Hi
>
> If I understand you correctly….I think you’re having issues trying to
> use NOW because rrdtool will snap to the 1 second grid skewing your
> calculations ever so slightly. I don’t think it’s really designed for
> that. It would probably expect DEF like ( TMPOUT, TMPIN,
> AMOUNT_OF_WATER) and then just graph the values with something like:
>
> CDEF:PWR=TMPOUT,TMPIN,-,AMOUNT_OF_WATER,*,0.06978,*
>
> And then let rrdtool calculate the value per second (which is what
> you have with your 1 second step).
>
> But I can see that unless you measure at precisely 1 second intervals
> down to the millisecond your values will be slightly erratic as the
> amount of water will vary for each 1-second RRA.
>
> Something I would try to do is to compensate for this using python to
> store the millisecond value since the last measurement (period =
> time_now - last_measured_time). Then do something like:
>
> DEF:TMPOUT=…
> DEF:TMPIN=…
> DEF:FLOWRT=…
> DEF:PERIOD=…
> CDEF:PWR=TMPOUT,TMPIN,-,FLOWRT,*,0.06978,*,PERIOD,1000,/,/
>
> But it’s a bit counter rrdtool to save the “step” in an rrd in this
> way. You might actually just be better off doing all the maths in
> python and just writing the PWR as a GAUGE value in rrdtool…that’s
> probably what I’d do, but I’m lazy with RPN that way… :)
>
> Cheers,
>   Jacques
>
> > On 14 Feb 2017, at 20:31, SolarMan <[hidden email]> wrote:
> >
> > I have a simple application to determine the power generated by a
> > water
> > heater. One sensor (TEMPIN) measures the in-flowing cold water
> > temperature
> > while a second sensor (TEMPOUT) does the same for the hot water
> > exiting the
> > heater. The flow rate is constant and samples are stored in an rrd
> > database.
> > Using rrdgraph I want to display the time series of the
> > temperatures plus
> > the generated power in Watt. I planned to use a CDEF to calculate
> > the power
> > by multiplying the temperature difference by the flowrate and a
> > constant and
> > divide that by the time between two successive samples. A python
> > script does
> > it all for me. Samples come in nominally - but not exactly - at a
> > one-second
> > interval, therefore the CDEF does the division using a value
> > calculated in
> > python using rrdtool.last() just before every rrdtool.update() call
> > and NOW
> > in the CDEF as you might guess. Seems not all too complex you would
> > say....
> > BUT: I noticed that the entire Power graph (PWR) jumps up and down
> > over the
> > entire time range when the time-interval (hence the division)
> > changes and
> > that is clearly not what I want.
> > Here is the CDEF (as a python snippet):           
> > "CDEF:PWR=TMPOUT,TMPIN,-," + str(flowrate) + ",*,0.06978,*,NOW," +
> > str(prevtime) + ",-,/",
> > I spent many hours reading all the available material on CDEF, VDEF
> > etc. but
> > this fenomenon apparently has never come up - or this is a feature
> > "by
> > design".
> > How can I accomplish that the power is calculated and displayed
> > truly
> > momentary per step even when the measuring interval varies?
> > Thanks everyone!
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://rrd-mailinglists.937164.n2.nab
> > ble.com/CDEF-effects-entire-timeline-tp7583504.html
> > Sent from the RRDtool Users Mailinglist mailing list archive at
> > Nabble.com.
> >
> > _______________________________________________
> > rrd-users mailing list
> > [hidden email]
> > https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
>
> _______________________________________________ 
> rrd-users mailing list 
> [hidden email] 
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
>
>
> If you reply to this email, your message will be added to the
> discussion below:
> http://rrd-mailinglists.937164.n2.nabble.com/CDEF-effects-entire-time
> line-tp7583504p7583509.html
> To unsubscribe from CDEF effects entire timeline, click here.
> NAML