This is weird. The gaph data is wrong but changing.
I now notice the time on this particular feed is wrong!
The feed is from a solar thermal collector showing the temperature in the collector.
My graph show it has been rising in temperature at midnight last night, which seems not right
The strange thing is, it seems to be only this feed! The new feed i created is correct!
But how can the data come arrive in the feed with a delay?
I’m sending the data using node-red with the emoncms node’s.
The node-red time is correct.
It has been working for a few years, it’s only recently starting this behaviour.
On the dashboard you can see the dial showing the temperature from this very feed! Notice the different value.
I don’t understand how the feed graph can show value’s from a few hours ago?
I’m sure that tonight i’ll be seeing the same data as on the newly created feed on the old feed.
There is a dial, just not showing any more when not logged in.
Anyway, it seems ALL data is showing in delay on the graphs.
The heatpump data is also off…(because it is off now, and still showing energy usage on the gaph…) but why not this newly created feed?
Yes I have updated the node recently BUT no not all data is coming from this node-red instance. Some users with dashboards also affected have nodes that were not updated in a while.
It must be server related.
These feeds are phpfiwa and phpfina. What do you mean next to each other?
They are from different users also.
Timezone is set. The date command shows correct timezone and date. Also the administration page shows correct date and time.
The time does line up correctly on the right edge.
Now you’ve thrown me, why would comparing the data from 2 separate users have any meaning?
This statement suggests (to me) you have set up another feed on the same data and that is reading correcly
You are telling me feed A is wrong, but new feed B is correct using the same data, to rule out any possibility of differences caused by other input processes I ask to confirm they are next to each other in the same input process list, of the same input, belonging to the same user. eg
input xyz
log to feed “Feed A”
log to feed “Feed B”
must be the same data where as
input xyz
log to feed “Feed A”
some other process(es)
log to feed “Feed B”
Sorry if I’m not clear, English isn’t my native language.
I’m not comparing the data of 2 seperate users. Just saying the data from other users and their graphs is also shifted in time.
I did set up e next feed on the same input to test. You can see this in the solar graph. And that one is reading correctly.
Both log to feed lines are next to each other on the input setting, no process between them.
No problem, your English is good, this isn’t easy stuff to discuss even between users of the same native language.
Some or all users?
Are they the same feed type and spec? Or
are you saying the original feed is phpfiwa and the new test feed is phpfina?
By any chance are all the users with issues using phpfiwa and those that are ok using phpfina?
phpfiwa is no longer supported and not many users still use phpfiwa. So if there was a recent change in emoncms that effected phpfiwa differently, we might not know about it yet. But that’s just a guess based on what you’ve told me this far, I have not heard of any such issue previously.
Can you open the 2 feeds in the graphs module and try scrolling right to see “into the future” does the faulty feed show data beyond now?
Can you confirm that the timezone setting for each of the troubled accounts is set? To do that please try to set it again even it you think it is correct. There was a change in the way emoncms uses the timezone data quite some time ago which resulted in errors if you had the correct timezone set using the old method.
you can see they are identical so I suspect it can only be 1 of 2 things, either it’s a display only issue, ie good data with the correct time is being saved but displayed incorrectly, but I fail to see how that would only affect some feeds and not others on the same multigraph OR there was an error that resulted in some data being written in the future, and now the data arriving is correct, but it cannot overwrite what is already there, but in this scenario I wonder why the last value and time would be reported “correctly” perhaps it returns the last “received” rather than the last “on file”.
Ok so I think it’s definitely the latter having looked closer
That url returns 10s data from the “faulty feed” from 12:00 (midday) GMT 31/03/18 to 12:00 (midday) GMT 01/04/18.
The last data point in that returned data is [1522532130000,65] which is a timestamp of 21:35:30 31/03/18 and it doesn’t change.
So something went wrong to cause the data to be posted with the wrong timestamp and normal service will most likely resume after that final datapoint has been passed with new data at 21:35:40 GMT.
Belgium is 1 hour ahead of the UK so, your current time is 2hrs ahead of GMT. The actual timestamp of the end of the data you see is 1522532130 (or 1522532130000 unixmillis) which is 21:35:30 31/03/18 GMT so 23:35:30 31/03/18 localtime in Belgium