 |
From: "Jon Bartlett" <J...@TheBartletts.org>
Date: Thu, 19 Apr 2012 18:37:08 +0100
Local: Thurs, Apr 19 2012 1:37 pm
Subject: RE: Nanode /Pachube not very stable... - Ether.Stash issue...
As per the other thread around Virgin routers, the stash running out of space is whats corrupting my (simple Pachube with one-wire temp) sketch too. I added this code to the end of the main loop Serial.print("Stash:freeCount :"); Serial.println(Stash::freeCount()); You can see the stash free gets lower and lower (although its not linear - and does occasionally go up - the trend is down to zero), at which point you can see the packet text is corrupted... I've just spotted the HTTP response isn't being received - I need to look into that too... Jon. Heres the Serial out from the code at the beginning... Requesting temperatures... Timer:0 Millis:7370 Stash:freeCount :54 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 temperature,20.50 Requesting temperatures... Timer:17386 Millis:17485 Stash:freeCount :54 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 temperature,20.44 Requesting temperatures... Timer:27500 Millis:27599 And when the stash is showing zero... Requesting temperatures... Timer:9110473 Millis:9110573 Stash:freeCount :9 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 temperature,20.31 Requesting temperatures... Timer:9120588 Millis:9120688 Stash:freeCount :9 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 temperature,20.31 Requesting temperatures... Timer:36054643 Millis:36054743 Stash:freeCount :0 Requesting temperatures... Timer:36064757 Millis:36064857 Stash:freeCount :0 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 L2oXVl X-PachubeRe Requesting temperatures... Timer:36074871 Millis:36074971 Stash:freeCount :0 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 L2oXVl X-PachubeRe From: nanode-users@googlegroups.com [mailto:nanode-users@googlegroups.com] On Behalf Of Jon Bartlett This is a bit off-topic, but at the moment, I'm trying to figure out why I can't get the Simple Pachube Sketch - with one-wire temp sensor code to be stable. My code is a combination of Pachube Simple (Arduino v1.0) and one-wire temp sensing, and uses the Ethercard, one-wire, and DallasTemp libraries (all latest versions I rekon). The code (main loop is below) - but fairly straight forward - and the error is that the payload gets corrupted after a period of time - generally between a few hours and a few days (it varies). Heres the serial output (and you'll see where it gets corrupted) : Requesting temperatures... Timer:6460447 Millis:6460547 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 temperature,19.87 REPLY: HTTP/1.1 200 OK Date: Sun, 15 Apr 2012 13:10:25 GMT Content-Type: text/plain; charset=utf-8 Connection: close X-Pachube-Logging-Key: logging.0Vg8PrlBARnpBmL2oXVl X-PachubeRequestId: 1d80f9d2d5bc88a2e2e74aef17347fce689febda Cache-Control: max-age=0 Content-Length: 1 Age: 0 Vary: Accept-Encoding Requesting temperatures... Timer:6470562 Millis:6470662 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 temperature,19.94 REPLY: HTTP/1.1 200 OK Date: Sun, 15 Apr 2012 13:10:35 GMT Content-Type: text/plain; charset=utf-8 Connection: close X-Pachube-Logging-Key: logging.0Vg8PrlBARnpBmL2oXVl X-PachubeRequestId: e7c101a11a588c85ce3ca089e4919db67578218c Cache-Control: max-age=0 Content-Length: 1 Age: 0 Vary: Accept-Encoding Requesting temperatures... Timer:6480677 Millis:6480777 Requesting temperatures... Timer:6490792 Millis:6490892 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 -PachubeRequestId: REPLY: HTTP/1.1 400 Bad Request Date: Sun, 15 Apr 2012 13:10:55 GMT Content-Type: text/plain; charset=utf-8 Connection: close X-Pachube-Logging-Key: logging.0Vg8PrlBARnpBmL2oXVl X-PachubeRequestId: 744459b23eb14f39511ad62ce5453d521915eea7 Cache-Control: no-cache Content-Length: 61 Age: 0 CSV Parser Error: CSV is invalid. Incorrect number of fields. Requesting temperatures... Timer:6500907 Millis:6501006 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 L2oXVl X-PachubeRe REPLY: HTTP/1.1 400 Bad Request Date: Sun, 15 Apr 2012 13:11:05 GMT Content-Type: text/plain; charset=utf-8 Connection: close X-Pachube-Logging-Key: logging.0Vg8PrlBARnpBmL2oXVl X-PachubeRequestId: 5ffc2d4f8915ae91d5537449e2a8ca9e3502f969 Cache-Control: no-cache Content-Length: 61 Age: 0 CSV Parser Error: CSV is invalid. Incorrect number of fields. Requesting temperatures... Timer:6511021 Millis:6511120 Requesting temperatures... Timer:6521135 Millis:6521234 REQUEST: 187 PUT http://api.pachube.com/v2/feeds/48208.csv HTTP/1.0 Host: api.pachube.com X-PachubeApiKey: yjR4WMzFzWGWu4bf_tFifyuJh43hjk£J4ltcDlpaz0g Content-Length: 19 L2oXVl X-PachubeRe REPLY: HTTP/1.1 400 Bad Request Date: Sun, 15 Apr 2012 13:11:26 GMT Content-Type: text/plain; charset=utf-8 Connection: close X-Pachube-Logging-Key: logging.0Vg8PrlBARnpBmL2oXVl X-PachubeRequestId: a493b9c148de1c807bf24b421367f18da8db2193 Cache-Control: no-cache Content-Length: 61 Age: 0 CSV Parser Error: CSV is invalid. Incorrect number of fields. Requesting temperatures... Timer:6531249 Millis:6531348 And heres the main loop code : void loop () { ether.packetLoop(ether.packetReceive()); if (millis() > timer) { //Read temperature first //Read temp now, so we get a delay for the query Serial.println("Requesting temperatures..."); sensors.requestTemperatures(); // Send the command to get temperatures Serial.print("Timer:"); Serial.print(timer); Serial.print(" Millis:"); Serial.println( millis()); delay(700); // Payload is ID, data pairs.... // we can determine the size of the generated message ahead of time byte sd = stash.create(); stash.print("temperature,"); stash.println(sensors.getTempC(insideThermometer)); //stash.print("1,"); //stash.println((word) micros() / 456); stash.save(); // generate the header with payload - note that the stash size is used, // and that a "stash descriptor" is passed in as argument using "$H" Stash::prepare(PSTR("PUT http://$F/v2/feeds/$F.csv HTTP/1.0" "\r\n" "Host: $F" "\r\n" "X-PachubeApiKey: $F" "\r\n" "Content-Length: $D" "\r\n" "\r\n" "$H"), website, PSTR(FEED), website, PSTR(APIKEY), stash.size(), sd); // send the packet - this also releases all stash buffers once done ether.tcpSend(); timer= millis() + 9300; } } Theres clearly something interrupting the main loop occasionally (see where the output shows multiple 'requesting temps' - and I suspect corruption is happening during the stash creation - but why that corrupts all future execution of the loop from then on, I dont know. Am i running out of Stack ? Interrupts not being handled ? Any other ideas ? Jon. From: nanode-users@googlegroups.com [mailto:nanode-users@googlegroups.com] On Behalf Of SomeRandomBloke Hi, I've been having a look at the EtherCard library today after experiencing issues with DNS and DHCP now that I have a BT HomeHub3. I've also got it working successfully with Pachube. The DNS issue is a funny one and not sure of a solution other than a quick hack. Basically there is a bit in the response that should be set, however the BTHH3 seems to set this sometimes and not other times. I'm thinking this is to do with the response being cached in the router or not. However if this bit is not set then the library will not recognise the response. A work around is to temporarily remove the check for this bit in the function checkForDnsAnswer in dns.cpp. The current check is: if (plen < 70 || gPB[UDP_SRC_PORT_L_P] != 53 || // OK gPB[UDP_DST_PORT_H_P] != DNSCLIENT_SRC_PORT_H || // OK gPB[UDP_DST_PORT_L_P] != dnstid_l || p[1] != dnstid_l || (p[3] & 0x8F) != 0x80 ) { I changed mine to: if (plen < 70 || gPB[UDP_SRC_PORT_L_P] != 53 || // OK gPB[UDP_DST_PORT_H_P] != DNSCLIENT_SRC_PORT_H || // OK gPB[UDP_DST_PORT_L_P] != dnstid_l || p[1] != dnstid_l ) { This gets round the problem temporarily for my setup. Hope this helps. SRB On Tuesday, 20 March 2012 13:52:34 UTC, Mike wrote: Hi guys. I wonder if anyone can help me? I have built 2 Nanode RFs, one for me and one for my friend. I have no problem whatsoever connecting either of them to my Pachbe account or to my friends Pachbe account via my Virgin router. If however we try and connect either unit to either Pachbe account via My friend and I are complete novices when it comes to setting up The sketch that we have used to connect successfully to Pachube via my http://blog.wickeddevice.com/?p=260 with the Pachube key and feed number being changed to suit. We did also experiment with using the nanodes to serve a webpage I did have a brief conversation with another colleague who is much I would be very grateful for any suggestions of what we could try in thanks Mike You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||