Én nem az Arduinora gyanakodnék, hanem az Ethernet shieldre. Ebből lehetne olyat csinálni - a legtöbb bolti nem ilyen - hogy tudjon hard resetet csinálni, tehát az Arduino újra tudja indíŧani az Etnernet shieldet, de úgy, hogy teljesen elveszi a tápot egy kis időre.
Nagyon nehéz ilyet debuggolni, mert a mikrovezérlőt eleve nem tudod live debuggolni. Elvben lehetséges volna rácsattintani egy debuggert amikor előjön a hiba, de az Arduino rendszer nem arról híres, hogy ezt a szcenáriót támogatná... Plusz egy rendszert eleve úgy kell tervezni, hogy debuggolható legyen, ha azt akarod, hogy ne essen szét az egész egy breakpoint után az időzítések miatt. Talán egy core dump-ot lehetne elemezni. De debuggolás eleve ott indul, hogy érteni kell az összes libet, hogy mit csinál és miért. Gyakorlatilag ezen a szinten esélytelen.
Tehát abban sem lehetsz biztos, hogy az Arduino a rossz, vagy az Ethernet shield firmware-je tévedt-e el?
Én azt csinálnám, hogy a libektől minimálisat várnék el: például http szerver helyett csak sima TCP-t használnék. Vagy UDP-t ahogy lejjebb javasolták. Hátha ezzel kizárod a hibát.
Én is csináltam egyébként hasonló rendszert. Két UNO van Ethernet shielddel helyi hálózatra kötve és ezek a hőmérők. A szoftver nálam csak sima TCP szerver, ami http-nek is elmenő választ ad, ami böngészőből is csekkolható, de program is tudja egzaktul parszolni. Ezekkel semmi gond nem volt, 100%-ban működnek. Remélem ez megnyugtat :-)
Van egy másik UNO, ami egy relé boardod vezérel: ez elszállt egyszer. Az első egy klón volt, a helyére tettem egy valódi Arduino-t, remélem ez tovább fogja bírni.
A vicc az, hogy egy PC+GSM router kombót tudott volna ez az Arduino reszetelni, ha ők nem működtek volna helyesen. És a vége az lett, hogy az őrző lett a hibás előbb. Szerencsére úgy ment hibába, hogy hagyta működni a PC-t. A hálózat is hibátlanul működött megbízhatóan reszet nélkül.