Input time in emonhub and emoncms

Submitted by Eric_AMANN on Fri, 26/06/2015 - 07:54

I realized that the input time in Emoncms is not the time when a RF frame is received by Emonhub. In fact , it is more or less the time when the acknowledgment is received by emonhub from emoncms. It's an issue because one can't calculate the exact time between two inputs in emoncms. Is it the normal behaviour ?

Emonhub send :

http://xxxxx/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1435304330.37,10,86,214,-2691,2]]&sentat=1435304330

In emoncms, the request is processed as bellow (input_controller.php)

// Sent at mode: input/bulk.json?data=[[45,16,1137],[50,17,1437,3164],[55,19,1412,3077]]&sentat=60
    if (isset($_GET['sentat'])) {
        $time_ref = time() - (int) $_GET['sentat'];
    }  elseif (isset($_POST['sentat'])) {
        $time_ref = time() - (int) $_POST['sentat'];
    }

and few lines after

$itemtime = (int) $item[0];
$time = $time_ref + (int) $itemtime;

I do not understand why one needs to add $time_ref to $itemtime which is already the input time.
I looks like emonhub and emoncms are not using the input api in the same way.

Eric

EDIT : I'm using EmonHub Pre-Release Development Version (rc1.2) and EmonCMS 8.5.1 XT on a shared linux hosting server

Re: Input time in emonhub and emoncms

Submitted by pb66 on Fri, 26/06/2015 - 09:07.

Hi Eric,

The send format in emonhub hasn't changed and does use the individual frame timestamps as well as the trailing "sent at" timestamp as defined in the API and they are all absolute unixtimes there are no timezone adjustments so I believe all is present and correct coming out of emonhub.

Is the actual input timestamp incorrect or are you going by the displayed update time on the inputs page?

The code does look odd though,

$time_ref = time() - (int) $_GET['sentat'];

So $time_ref is the current time minus the time frame sent by emonhub, which means "time in transit from emonhub to emoncms" seems an odd thing to calculate as emonhub will set "sent at" at the time sent so any successful frame will have a sentat of now minus a few milliseconds.

$time = $time_ref + (int) $itemtime;

So $time becomes the original frame timestamp plus "time in transit" which is even odder,

I suspect these calc's maybe part of a larger calculation, possibly the "updated" column??? and as a result just look odd on thier own perhaps.But as a side note the "updated" column wouldn't be accurate either because if emonhub buffered data for 10 mins due to a network issue, the "updated" column time would show a time 10mins before it actually arrived.

Paul

Re: Input time in emonhub and emoncms

Submitted by Eric_AMANN on Fri, 26/06/2015 - 12:27.

Hi Paul,

Thank you for your quick reply.

Is the actual input timestamp incorrect or are you going by the displayed update time on the inputs page?

As of now, I didn't have a look on the displayed update time on the inputs page. Here I'm talking about the time stored in the input mysql database.

note the "updated" column wouldn't be accurate either because if emonhub buffered data for 10 mins due to a network issue, the "updated" column time would show a time 10mins before it actually arrived.

This is exactly what happens now. I do not consider it's a problem from a user point of view.

Considering that emonhub explicitly send the input timestamp (first value) using absolute unixtimes, I think there no point adding $time_ref to $itemtime.

These calc's seems useful only when the first value is a relative time value (offset mode, time mode and legacy mode).

Eric

Archived Forum