Garage Door/ Gate controller with Ethernet - Web server hangs after ~ hour

Hello folks,

I was hoping someone might be able to help direct me in the correct direction. I have one of the Xboards I picked up a while back instead of buying an ethernet shield for my Uno and because of the size and needed the small form factor.

At any rate, what I’m trying to do is have a simple web page with 3 radio buttons: Door/gate open, door/gate close, door/gate stop. These effectively turn on one of the digital pins for 2 seconds which activates a relay. Pretty straightforward.
I also have another button that is labeled “refresh” which allows me to read the status of a digital PIN (HIGH or LOW) which is connected to a magnetic switch.

This was the easy part :slight_smile:

The issue I’m having is everything works for about an hour and then the web server dies. I can still ping the interface (IP) but if I do an nmap on the IP I see that TCP port 80 stops responding. So something is causing the web server to hang.

I initially was doing an auto-refresh of the web page every few seconds (so I’d get gate/door status automatically)…but this seemed to cause the ‘hung’ state sooner (like 20minutes). But putting the refresh as a button to push, seemed to push out the ‘hung’ state to about an hour.

If you any ideas of what I might be doing wrong or could change in order to make the web server robust, please let me know. At this point, I’m at a loss because it works for a short period of time.

Attached is the current sketch.

Thanks in advance.

gate_control_v01.ino (8.75 KB)

Likely a memory issue. First would be to use the F() macro on all of your string constants to help free up some memory for the String class to run rampant on. If you’re still having issues, re-write the code using c style strings instead of String objects.

String readString = String(30);

This is very likely to be the problem. The current heap management library has a flaw that causes memory leaks, and String uses it. It is not a good idea to use the String class in any script where stability is important. Use old fashioned 'C' strings (null terminated char arrays) instead. Most of the operations of the String class can be done just as easily using 'C' strings and the functions in the string library.

thanks. I'll give this a try and re-test.

Sounds a bit like my problem on a thermal control/data logging/data access via the web project but my web server stops after days rather than hours. At the moment I'm chasing the possibility of Brownouts being the cause. See Arduino Forum.

There used to be a problem with the ethernet library that could cause this sort of thing but that was supposedly fixed in the 1.0.1 release if the IDE

How big is your sketch? mine's massive at 29600 bytes and 360bytes of ram free (iand its still missing a bit of functionality). I consiously used only null terminated Cstring arrays and the (F("bla bla bla")) form for fixed strings.

I'd be interested in how you get on.

There used to be a problem with the ethernet library that could cause this sort of thing but that was supposedly fixed in the 1.0.1 release if the IDE

What was this issue? I've had problems in the past with large broadcast packets - the async labs version of the library I was using didn't bounds check the receive buffer and from time to time, my ISP sends 1400 character packets, resulting inevitably in a crash within 24 hours or so.

Another thought: are you using static IP address for the Ardunio? If you are then even setting your router for this static address may not be enough as on some routers DCHP routine will still run. It should just give the required address and extend the the lease but this is not always the case.

Fixed or static what you could try is to put an Ethernet.maintain(); in the loop part of the script. If your router gives 1 hour leases then the maintain call should be on a 50 min cycle to get ther first. I'll admit I've not tried this on the current project as it put about 5K! in hte sketch and would blow the 32K available.

For 'wildbill' from memory the previous problem with the ethernet library was something to do with not closing the connection properly.