Yes, thanks, it all caught up later that evening. Node 29 was something I was testing and not running 24/7 so I can’t say whether it would have remained that way or not. But as odd as it might seem, the node 29 and node 30 frames were delivered to emoncms.org via the same single bulk upload with timestamps within a couple of seconds of each other. That’s how I came to conclude it was at the server end, I was watching the emonhub.logs and could see the frames arrive, get processed with similar timestamps and dispatched as 2 identical bulk upload requests to 2 emoncms targets and got “ok” replies from each.
The emoncms.org target showing this delay whilst the other showing correctly.
If not the queuing, the only other thing I could speculate towards might be IF during my tests I might of accidentally sent a frame with an incorrect timestamp in the future, perhaps the different servers handled the subsequent inputs differently??? I’ve no evidence or suspicion of using incorrect timestamps, but I did change from untimestamped to timestamped data at some point in writing the script. I had also checked the clocks on all the devices and found them ok during debugging this.
The other server is running older v9.??? emoncms without any queue management.
It isn’t a problem for me, but the delayed input times displayed at emoncms.org were definitely incorrect for node 29 whilst correct for 30. node 29 was being updated alongside 30 so the update times should have been the same (within a couple of seconds).
In fact, the fact it slowly caught up would suggest a queuing issue too, if the timestamps were to blame it would correct instantly, either immediately the correction was made or after passing the future timestamp if the inputs do now function like a low-write phpfina feeds in some way.
Oh well, not a problem for me, so don’t spend any time on it.