Archived Forum

 By way of update...

I have added....

//-----------------------------------------------------------------------------------
// Ethernet callback
// recieve reply and decode
//-----------------------------------------------------------------------------------
int request_attempt = 0;
char line_buf[50];

static void my_callback (byte status, word off, word len) {
get_header_line(2,off);      // Get the date and time from the header
Serial.println(line_buf);    // Print out the date and time

get_reply_data(off);
if (strcmp(line_buf,"ok")) {Serial.println("ok recieved"); request_attempt = 0;} 
//-----------------------------------------------------------------------------------

...just before 'void setup ()', and added the decode_reply library, and 'request_attempt ++;' in the send loop but the request_attempt variable increments with every send, despite them being successful. i.e. the code above does not serial print "ok received" nor returns the request_attempt back to zero. 

The code above appears to contained in the Global Variables section of the sketch, but there is no call to it in the loop....

I can't get my head around this Glyn!!
 

Hello Paul, the function static void my_callback (byte status, word off, word len) {

is a callback and is called here:

ether.browseUrl(PSTR("/emoncms3/api/post.json?apikey=2d177d7311daf401d054948ce29efe74&json="),str.buf, website, my_callback);

Its not actually looking for the 200 OK status code but for an ok sent by the server in the message body, this is given by emoncms. So maybe that would be why its not working with pachube.

Do you know what the in body responce is from pachube?

Try adding the lines at the top of the function:

get_header_line(1,off);

Serial.print(line_buff);

Then it might be possible too do something like this:

if (strcmp(line_buf,"HTTP/1.1 200 OK")) {ethernet_requests = 0; ethernet_error = 0;}

 Hi Trystan.

The reply body from Pachube is 'HTTP/1.1 200 OK'  (you were correct).
I have tried this code in the Global section;

//-----------------------------------------------------------------------------------
// Ethernet callback
// recieve reply and decode
//-----------------------------------------------------------------------------------
int request_attempt = 0;
char line_buf[50];
static void my_callback (byte status, word off, word len) {
get_header_line(1,off);      // Get the date and time from the header
Serial.println(line_buf);    // Print out the date and time
get_reply_data(off);
if (strcmp(line_buf,"HTTP/1.1 200 OK")) {Serial.println("ok recieved"); request_attempt = 0;}
}
//-----------------------------------------------------------------------------------

and this in the loop;

Hello Paul, does the Serial.println(line_buf);  print out: "HTTP/1.1 200 OK" to the serial window?

 No it doesn't, and it doesnt reset the request_attempt either.

 ...also, just found out that the Nanode 5 doesn't support the avr.wdt.h library anyway, so perhaps I need a different approach to this problem.

It's not the Nanode5 that doesn't support the watchdog its the arduino duemilanove bootloader.  It's not too difficult to re-flash the ATmegs with the Uno (optiboot) bootloader. The isp_repair sketch included in the JeeLib library work well for this. See here for wiring instructions:

http://jeelabs.org/2011/05/29/summary-of-isp-options/

 Thanks Glyn, I have just re-flashed the Nanode as per above, and all went well. It's now running the Uno optiboot bootloader, and the avr/wdt.h library now loads and runs.  :-)

Have you any thoughts pls as to why I can't parse the HTTP reply from Pachube using your library? Trystan made a suggestion above but that didn't seem to work either.  Watching the serial monitor, I get no reponse at all from the Serial.println(line_buf); section.

I have found though that the existing ethercard library does serial print the HTTP reponse, so it is being called from somewhere in the ethercard library. I havn't managed to find where, or to capture the response though.

Paul.

Thanks for raising this problem and trying to find a solution, guys.

I'm also suffering with the problem of a Nanode initially linking to Pachube then for no reason ceasing to get the 200 code after hours or days. I know its a work-around, but It would be great to get a way to detect this dropout and do a reset.

I'm not knowledgeable enough to develop / modify the code myself so hoping you will get a solution.

Gordon

I'll try to make the callback function works this week. I'm not a real coder but will give it a try and share once I manage to get it working. Any help would be appreciated :) 

Thats good news Igor. I hope that youre successful. I have to keep restarting mine because Pachubes server keeps going down, and like smithgor above, Im new to this and unable to code it myself.

Thank you for trying.

There have been many discussions lately regarding emonBase Nanode/NanodeRF instability.

To constructively try and move forward, lets create a knowledge base of setups that are stable Vs. setups which are not. Hopefully this will help us to debug this issue and give us a framework in which to discuss problems.

See forum thread: http://openenergymonitor.org/emon/emonbase/stability

 The main problem (from my perpective) is that Pachube's servers over the past few weeks have become problematic.

Pachube are aware of this problem, and are in the process of moving to a dedicated server which should provide a more stable service, but no timeline has been given.

Whenever the Pachube servers stop responding, Arduinos and Nanodes across the globe lose their connection, and do not reconnect when the server is restored. If I compare when my Nanode has frozen with a feed search for 'frozen feeds' via Pachube's search engine, I can find hundreds of devices which have frozen at the exact time as mine.  ( https://pachube.com/feeds )

This suggests that once disconnected, the ethercard library struggles to reconnect, and hence why a watchdog is desirable.

My current sketch (thanks re the bootloader Glyn!) now restarts every hour due to a watchdog timer, but although it's only been in use for 2 days, it's already recovered from one such server outage - about 2.15am 30/01/2012.

I haven't had time to work on the proper fix for the pachube sketch yet however I've done something very simple that so far is keeping my Nanode (duemilanove) sending data for over a day. Basically I reboot the board every 200 cycles (about every 20-30 minutes) using the following line:

if (request_attempt > 200) asm volatile ("  jmp 0");  

Working for 13 days now. I have it working by resetting error flags if too many attempts. Didn't have to reset the NanodeRF once since.

if (request_attempt > 100) {
#ifdef UNO

    #endif
}

Mine just frozen now after about 24 hours :( I'll try your suggestion above and let it running over the weekend.

Thanks!

----

Ops, just realised mine hasn't frozen. It was only waiting the end of the loop to reboot...

 My 'UNO bootloaded' Nanode reboots every hour using the avr/wdt watchdog library routine, and so far it has recovered from several 'server down - feed frozen' incidents over the past 3 or 4 days. One of which was at 7am this morning, and the Nanode rebooted and reconnected succesfully by itself as shown below about 30 minutes later. 

2012-02-03T07:00:23.022890Z,190
2012-02-03T07:31:46.028208Z,197

It's not an elegent solution, but it works!

Paul

I believe the UNO bootloader would be a better long term solution, at least the watchdog works properly... However as Glyn pointed out other day it would be good to have a duemilanove sketch working since it's the bootloader that comes as standard on Nanodes.

I'm doing pretty much the same here, rebooting every hour but instead of using the watchdog I'm using asm volatile. So far it's been working well but I've just added the code to reset the error flags as suggested by fjhug. I'll keep monitoring it over the weekend. If it doesn't work I'll go back to the previous solution.

On the other hand the other Nanode/UNO has been posting data to emoncms for about 2 days without a single problem...

Once I get it working I'll simply use UNO bootloaders on all my Nanodes :)

 only a WDT reset is a true reset. the asm hack only restarts the software, not the hardware.

 BTW is a Software reset possible for the ENC28J60 ? I read it is possible to issue SPI reset command, but no concrete code.

 Thanks, I didn't know that.

I am using the EtherCard library.

@fjhug - Using your reset error flags code for 3 days now and not a single need to reboot the Nanode manually so far.

@mharizanov - Asm hack worked for me for a couple days until I decided to test @fjhug's code. Tested it for 24 hours only and it was still (soft) rebooting at regular intervals. But @fjhug's code is probably a better solution! So I'll stick with it for a couple more days to see how it goes.

Nanode/Duemilanove stopped posting data today using fjhug's code, after 4 days. I'll try it on UNO to see how it goes.

---

5 days on UNO and no issues so far...

fjhug,

When resetting the flags, why do you have #ifdef UNO? Will this not work with duemilanove?

 Yes it will on any version, I actually commented out the lines around the UNO. I was initially using Duemilanove to fix the issue. Moved to Uno a couple of weeks ago.

In my latest code, I removed the UNO lines, so the code will work on UNO and Duemilanove.

According to this post on JeeLabs the HTTP response is sent to the serial monitor by tcpip.cpp.

I'm having the same issue about not having access to the HTTP response with the ethercard.h library on my Nanode v5.  I'm not an advanced coder, so I can't really figure this out myself.  I hope someine comes up with a solution to detect errors when sending data to pachube.

 Using the code in this post gives you control of what to do with the reply from the server.

You could check the returned HTTP code. It should be a good starting point.

Good luck

Has anyone tried the recent improvement to Ethercard on the Jeelabs site?

They have made an addition to get an Ethernet reply back after you call tcpSend() in the EtherCard library, which looks promising.

Paul