Archived Forum

emoncms.org says that it;s being regularly updated from emonBase about every 8 seconds, however the Tx node data is not being updated on emoncms.org

I this likely to be collisions? W

hat if I alter the sleep time / interval on one of the Tx's ?

Narrowed it down a bit, though still not solved and would appreciate some pointers..

Looking at the MySQL dataase, emoncms is storing data from emonBase (Open Kontrol Gateway) usually every 10 seconds, there are occasional missed entries. (just the temperature)

If I only have one emonTx powered up, then data is being stored approximately every 6 seconds, with the occasional missed entries.

With two emonTx's powered up, then storing of data is exceedingly intermittent, sometimes over two hours between data entries.

emonGLCD is more than happily updated every 6 six seconds.

Any ideas?

I have emonCMS set up on a Raspberry Pi, I get the same data logging problems if I output emonBase to emoncms.org. (that's where I first set it up and noticed the problems - hence the implementation on the Pi to be able to analyze what was happening in more detail.

Have you turned off (or set a very fast baud rate - 115200) serial comms in your OKG base? As I understand it, serial comms costs processor cycles and could be blocking reception of the data from the emonTx's.

The GLCD receives the data direct from the Tx, it isn't (normally, as in the published sketch) relayed via the base, so that tends to suggest it's not a transmitter problem nor (especially if the GLCD is receiving from both) data collisions.

Is the GLCD within range of both and are signal strengths likely to be similar? Can you program it to display data from both?

Have you tried a slightly different delay in one of the Tx's (i.e add say 0.5 s extra delay) - so that if it is data collisions, they drift in and out of sync and a pattern will emerge?

Can you look at the raw data stream coming in to your R-Pi?  If there's missing data there, I think the prime suspect is the OKG base, if all is present and correct, it's the data handling inside emonCMS, and that's Trystan's area of expertise.

Are you providing the time on your R-Pi? The standard OKG Base sketch gets time from "http://emoncms.org/time/local.json?apikey= .....".  I haven't tried to understand the library so I don't know if retries and timeouts are involved. If they are, that could be costing you the time needed to handle the second channel.

[The following was cross-posted in a separate thread by Avontech on Sat, 13/10/2012 - 17:11]

I have emoncms available on both .org and a Raspberry Pi and the same things occurs on both, so it isn't emoncms.

I have the OKG emonBase and two emonTx , when only one Tx is powered up, emonBase happily transmits the data every 6 seconds to emoncms. (either one, both work fine)

When both Tx are powered up, after a few minutes, emonBase stops sending data, turn either one of the Tx off again and the emonBase resumes sending.

The Tx's are configured as node10 and node11, I have made no modifications to the NanodeRF_multinode sketch (save setting it to 868mHz). Interesting that the sketch says:

#define MYNODE 15    

and yet emoncms reports the temperature sensor on the base as node20_1

To try to resolve the data transmission problem, I configured the sleep interval on node11, it's better, however it sitll sometimes stops sending the emonTx data for up to 10 minutes.

emonGLCD is working just fine, and is regularly updated from the emonTx.

A question: Why are you using the Nanode sketch rather than the OKG sketches https://github.com/openenergymonitor/Open-Kontrol-Gateway ?

Having just ordered the second emontx for heat pump monitoring would like to know if this is a common issue or just related to a particular configuration setup ? ... I also have nanodeRF (not only fw but also hw) so interested to know how to hack this ...

Let's wait for a response from Avontech. He was apparently using the Nanode software in an OKG base. We don't know which Ethernet module he's using, but there a broad hints that the Wiznet is the better choice. I'm no expert on networking protocols, but I do know that the OKG and its Wiznet module has built-in what is accomplished in software in the Nanode. So it's possible that there was a conflict and therein lies the source of the problem.

I've got the standard OKG base from the shop with came with the ENC28J60 Ethernet board.

I didn't change the baud rate so I'll have a look at that.

I altered the delay on one of the Tx's - I changed sleep to 9 instead of 5.

Both are at or about the same distance, and I can swap them over, turn them on / off and the results are replicatable.

"Why are you using the Nanode sketch rather than the OKG sketches https://github.com/openenergymonitor/Open-Kontrol-Gateway ?"

Because that is the sketch that was linked to from the step by step guide for the OKG and this Ethernet board, also it had a mutinode option so I followed the instructions..

I actually need a third emonTx here as we've got one of these installed: http://www.microgenerationpowermanager.com (was a lot easier and safer that building one ! and at the price offered good value) and I want to monitor everything (three inverters) including using the Pi as a weather station hooked up to a Maplins N96GY (wait till they're on sale) these operate on 433 hence I'm using 868 for the openenrgymonitor bits.

Also worked out what node 20 is - it's actually the temp monitor from the emonGLCD not the base station, so that makes sense.

Will report back after

1) checking baud rates

2) Using the different sketch

OK, so

The only entry I could find for baud rate is:

Serial.begin(9600)

Tried the OKG_Wiz5200_RFM12B_emoncms_multinode script and it just froze complete;
( I edited the url's and IP info and api key - that's all

for info, when running with the NanodeRF_multinode sketch:

The two red led's on the front the right one is permanently on the left one never

the two internal leds both glow a very dim red

The ethernet port,
one green led (left) permanently on
one orange led (right)  flashes about once a second

I normally detach the programming header after I've uplaoded the sketch this time I left it attached and the following appeared in the bottom window of the Arduino sketch uploader application:

Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

Baud rate: You can change the (9600) to 115200 and select the same value in the serial monitor window of the IDE (Tools - Serial Monitor)  or if that gives problems choose any other value that the serial monitor window offers.

You're OK with the Nanode software - I rather hoped you had the Wiznet module as that's what I have and it's the one the shop website says is better / easier to use.

The front right LED is power, the left is Status and you can turn it on or off in software. Defined at line 90:

const int LEDpin=17;         //front status LED on OKG

Uncomment this and make line 89 the comment - the LED should then be controlled by lines like 158 (Ethernet error). I haven't traced what the Green LED does on the OKG PCB but as nobody has complained it probably isn't a problem. But for safety, you could comment it out wherever it appears.

The internal LEDs - you mean the two on the back edge of the PCB behind the Ethernet adapter? - they're monitoring the serial data lines (pins 2 & 3) of the Atmel Mega chip, so in essence there's data passing (which we knew!).

The error message is from the Arduino IDE, I can't tell you the exact meaning, but it seems to indicate a problem with not enough memory. We're looking for messages in the Serial Monitor window from the OKG.

Have you noted line 132 and included line 133?

If you enable serial output and leave the IDE connected (monitor the serial port with Tools - Serial Monitor) you should have line 210 print the data about to be sent via Ethernet - once for each message from each Tx. Is this continuous (every 6 s / 10 s however often your Tx's transmit) and correct?
The format should be  

[basedir - see line 79]/api/post.json?apikey=[your apikey]&node=[node]&csv=[byte values separated by commas]
e.g.
/api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,0,0,0,43,-12700
 

followed by an acknowledgement from emoncms (line 241) for each.
There should also be a message as it attempts to get the time from line 226, and the time if it is successful (line 245).

So are you able to check the incoming data stream on your R-Pi to see what is actually being received? (Can you run one of the packet sniffer programs that are available?) You should see the same string if you can display the serial data incoming before/as it's swallowed by emoncms.
(N.B. I don't agree that because emoncms.org and your R-Pi behave the same, the problem isn't emoncms!. That means it still could be emoncms - the software, not the eponymous website of course).

[Later...]

I've had two emonTx's running into a NanodeRF base with a slightly modified sketch (because there is only a router attached - no internet, no server and no emoncms - so all DHCP and DNS has gone together with the error traps for Ethernet.

So far (30 mins) there's no hint of a lock-up and few collisions, and when there has been it had the predictable outcome that both sets of data were lost (but only one transmission). 

@RobertWall

Many thanks for your comprehensive reply.

I've got a bunch of real work to do today :( , and then I am away for the week. If I get a chance later on tonight I'll work through your advice step by step.

So if you don't hear from me for a few days, I'm not ignoring it!.

Thanks

I've had the same setup running now for 1½ hours. It's still running, and no sign of a lock-up. I think that rules out an inherent problem in the Nanode base software, but it doesn't exclude a configuration problem with the OKG base. I'm not sending the data to a server, so it also doesn't rule out a problem with the Ethernet module, and it doesn't rule out a problem with the emoncms software.

Stats:
2060 messages in total,
994 from the one Tx, the remainder from the other.

One minutes' worth looks like this, monitored on the Nanode serial port (OK, I know they're both node 10, I didn't bother to change one but you can tell which is which <edit> from the content (one always starts 0,0,0...  and ends -12700). </edit>

Time request sent
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=8800,240,0,1,1,0,0,24123,1800
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,1,0,0,29,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=9020,270,0,1,1,0,0,24160,1800
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,0,1,0,0,30,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=9240,300,0,1,1,0,0,24148,1800
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=9460,330,0,1,1,0,0,24203,1800
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,2,0,0,0,31,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=9680,360,0,1,1,0,0,24155,1800
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,0,0,0,41,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=9900,390,0,1,1,0,0,24088,1806
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,1,0,0,31,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=10120,420,0,1,1,0,0,24155,1800
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,1,0,0,29,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=10340,450,0,1,1,0,0,24139,1806
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,0,0,0,31,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=10560,480,0,1,1,0,0,24169,1806
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,0,0,0,21,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=10780,510,0,1,1,0,0,24133,1806
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,1,0,0,20,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=11000,540,0,1,1,0,0,24058,1800
Time request sent

Update: Now 5 hours & 3 mins and still no sign of a lock-up. 6269 messages in total. I'm monitoring at 115200 baud still.

I spotted 1 minute where there were either collisions or blocking to an excessive degree (only two transmissions from the one emonTx got through), but it did not lock up:

Time request sent
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=4180,90,0,1,1,0,0,23897,1862
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=4400,120,0,1,1,0,0,23899,1856
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=4620,150,0,1,1,0,0,23922,1862
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,1,0,0,24,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=4840,180,0,1,1,0,0,23901,1862
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=5060,210,0,1,1,0,0,23870,1862
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=5280,240,0,1,1,0,0,23887,1856
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=5500,270,0,1,1,0,0,23841,1856
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=5720,300,0,1,0,0,0,23864,1862
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=0,0,0,1,1,0,0,21,-12700
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=5940,330,0,1,1,0,0,23889,1862
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=6160,360,0,1,1,0,0,23885,1862
Data sent: /api/post.json?apikey=YOURAPIKEY&node=10&csv=6380,390,0,1,1,0,0,23891,1862
Time request sent

 My best suggestion is to work through the list above.

I did a bit of checking up about "rf12_set_cs(9)" - it appears to be tied up with the rf transmission rate. I can't prove it is a problem, but if you have the wrong value it needs changing.

If that list does not throw up anything concrete (and in any case when you are ready to put the kit into service) comment out (or wrap in #ifdef .....  #endif  preprocessor directives) all the Serial.???? statements, because those do take up processing power and prevent the rf module from receiving transmissions.
(You'll need to be careful with line 241:

Serial.println("OK recieved"); ethernet_requests = 0; ethernet_error = 0; 

and split it first).

With the latest Jeelib, the tx collisions appear to be sorted, so know from the serial port monitor i am getting:

    [webClient]
    DHCP status: 1
    IP:  192.168.7.160
    GW:  192.168.7.1
    DNS: 8.8.8.8
    DNS status: 1
    SRV: 213.138.101.177
    Data sent: /input/post.json?apikey=MyAPIKey&json={rf_fail:1}
    Time request sent
    Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=1481,-9,0,23986
    Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=0,-10,-2,24052
    Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=1499,-8,0,23992
    Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=-11,-16,-2,23975
    Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=1494,-6,0,23941
    Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=-8,-14,-3,23986
    Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=1478,-10,0,24002
    Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=-2,-10,-2,24058
    Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=1506,-11,0,23998
    Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=-8,-17,0,23999

    [webClient]
    DHCP status: 1
    IP:  192.168.7.160
    GW:  192.168.7.1
    DNS: 8.8.8.8
    DNS status: 1
    SRV: 213.138.101.177
    Data sent: /input/post.json?apikey=MyAPIKey&json={rf_fail:1}
    Time request sent
    etc

However emoncms.org is oonly recieving a very small amount of the data - all the expected sensors gave an initial system set up, so I was able to set up feeds for this data

Having left the serial monitor running for a while, and viewing the data, the only times it has successfully communicated over the last 18 hours is:

Time: t08,26,25
Time: t08,27,25
Time: t11,07,40
Time: t11,08,40
Time: t13,58,30
Time: t13,59,29
Time: t14,13,45
Time: t14,14,45
Time: t21,27,31
Time: t21,28,31
Time: t23,36,21

and here's a copy of the serial monitor output around one of those times:

[webClient]
DHCP status: 1
IP:  192.168.7.160
GW:  192.168.7.1
DNS: 8.8.8.8
DNS status: 1
SRV: 213.138.101.177
Data sent: /input/post.json?apikey=MyAPIKey&json={rf_fail:1}
Time request sent
Time: t14,13,45
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3403,9121,0,24331
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2787,3304,2857,24630
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3963,9123,0,24253
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2790,3332,2837,24485
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3359,9096,0,24297
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2810,3303,2848,24583
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3076,9088,0,24314
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2787,3327,2828,24513
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3955,9082,0,24289
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2780,3314,2848,24591
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3827,9071,0,24279
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2785,3316,2826,24501
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3641,9069,0,24235
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2767,3287,2843,24525
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3233,9012,0,24326
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2756,3325,2831,24514
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3501,9133,0,24293
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2811,3316,2839,24606
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3645,9036,0,24286
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2795,3312,2825,24521
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3501,9053,0,24259
OK recieved
Time request sent
Time: t14,14,45
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2792,3303,2845,24526
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3514,9081,0,24261
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2817,3315,2835,24456
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3670,9023,0,24248
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2734,3270,2847,24469
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3306,9068,0,24254
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2769,3274,2849,24495
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3468,9076,0,24278
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2768,3296,2847,24489
OK recieved
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3160,9065,0,24278
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2774,3288,2835,24499
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3138,9068,0,24277
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2718,3275,2823,24477
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3760,9092,0,24255
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2769,3301,2840,24472
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3779,9069,0,24239
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2776,3306,2829,24448
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3763,9049,0,24251
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2780,3286,2841,24482
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3477,9029,0,24257
[webClient]
DHCP status: 1
IP:  192.168.7.160
GW:  192.168.7.1
DNS: 8.8.8.8
DNS status: 1
SRV: 213.138.101.177
Data sent: /input/post.json?apikey=MyAPIKey&json={rf_fail:1}
Time request sent
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3773,9022,0,24250
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2785,3270,2836,24488
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3589,9038,0,24198
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2789,3288,2826,24448
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3303,9019,0,24254
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2799,3278,2836,24549
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3446,9019,0,24250
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2750,3295,2826,24488
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3451,9020,0,24318
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2729,3263,2832,24532
[webClient]
DHCP status: 1
IP:  192.168.7.160
GW:  192.168.7.1
DNS: 8.8.8.8
DNS status: 1
SRV: 213.138.101.177
Data sent: /input/post.json?apikey=MyAPIKey&json={rf_fail:1}
Time request sent
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3667,9056,0,24281
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2800,3280,2844,24562
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3330,9082,0,24303
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2813,3286,2845,24551
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3131,9087,0,24339
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2802,3270,2724,24615
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3775,9058,0,24309
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2800,3272,2846,24610
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3916,9055,0,24296
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2795,3285,2845,24598
[webClient]
DHCP status: 1
IP:  192.168.7.160
GW:  192.168.7.1
DNS: 8.8.8.8
DNS status: 1
SRV: 213.138.101.177
Data sent: /input/post.json?apikey=MyAPIKey&json={rf_fail:1}
Time request sent
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3483,9064,0,24320
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2813,3273,2839,24605
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3635,9008,0,24325
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2757,3272,2842,24587
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3477,9084,0,24339
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2810,3273,2826,24624
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3304,9075,0,24293
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2753,3271,2839,24594
Data sent: /input/post.json?apikey=MyAPIKey&node=10&csv=3649,9061,0,24282
Data sent: /input/post.json?apikey=MyAPIKey&node=11&csv=2801,3265,2830,24563

Any ideas?

Didn't touch it or do anything spectacular!, Just left it running overnight and the data started to appear to be posted, seems quite happy now.

Perhaps it was fixed by the new Jeelib library as all the emonTX's, the emonGLCD and emonbase have now been reflashed with code compiled with the new library....