At the beginning of that log there is already over 9500 buffered entries so this log doesn’t show where that particular fault actually occurs, but the url being passed to your emoncms server shows “[1522490634.268513,28,23514.5,Infinity,0.0,-60]” which suggests that on Saturday, 31 March 2018 at 10:03:54.268 node “28” passed an “infinity” as the second value in it’s payload.
That will have caused emoncms to reject that payload and because of the way emonhub buffers and resends data in chronological order, so it has become stuck because until that payload in the buffer is accepted by emoncms it cannot move on. Unless the buffer gets full and starts deleting the oldest data to make room for the newest data, at that point when that particular frame gets discarded emoncms will accept that payload and things can carry on after the buffer is completely uploaded, assuming of course, that is the only occurrence of “infinity”.
After you restarted emonhub it seems to occur again at 2018-03-31 17:20:24,972 (Line 553)
2018-03-31 17:20:24,969 DEBUG RFM2Pi 10 NEW FRAME : OK 28 51 74 184 70 0 0 128 127 0 0 0 0 (-61)
2018-03-31 17:20:24,971 DEBUG RFM2Pi 10 Timestamp : 1522516824.97
2018-03-31 17:20:24,972 DEBUG RFM2Pi 10 From Node : 28
2018-03-31 17:20:24,972 DEBUG RFM2Pi 10 Values : [23589.099609375, inf, 0.0]
2018-03-31 17:20:24,973 DEBUG RFM2Pi 10 RSSI : -61
bytes 5 - 8 are “0 0 128 127” which is the float representation of infinity. I do not know what node 28 is but that seems to be the source of the problem. Infinity is not a valid value, emonhub has passed that faithfully to emoncms and emoncms isn’t happy about it.
we can see in line 596 that the url containing the new “infinity” value does not return “ok” instead it returns “Format error, json string supplied is not valid” as “infinity” is not a valid JSON value.
emoncms already accepts “null” despite that not being valid JSON and I have suggested it accepts “NaN” as well but that hasn’t happened as yet. I do not think emoncms is likely to be changed any time soon, if and when it does, I do not know if it will handle this particular case as it’s really rare (possibly the first time I’ve seen it). I have mentioned to @TrystanLea that a mechanism that emoncms can discard and continue would be very useful for the bulk upload methods.
I think the quickest way for you to get this remedied is to ensure your node is sending valid data. The most common cause is usually divide by zero errors.
 I suspect the reason behind the change is because the emonpi version of emonhub had the buffering removed for 2 years and @TrystanLea has not that long ago, re introduced the buffering. Prior to that the emonpi variant of emonhub was just firing the data off in a url and discarding the local copy rather than waiting for a confirmation of receipt before deleting the local copy. This is to reduce/eliminate data loss due to a flaky network etc.
I suspect the invalid data from node 28 just hasn’t been spotted before as emoncms would have still rejected it, but no one knew that all the data in the same payload was being silently discarded.