However you like. I'm running for a while with DEBUG_LOOPTIME and DEBUG_WATCHDOG enabled WATCHDOG ON. See as much of what's going on as I can.

The other way to do this is to put a watchdog reset inside the webserver code and set it back to 10s. I don't like the OCS being blocked for 10s though so I went with a 4s timeout which isn't so bad.

So... Update to OCS 2.3c and kick it around a bit.

Ok, it's in the webserver. A hung socket and a timeout that's too long I suspect. I shortened that timeout from 10s to 4s. I also added better connection check code... The connection check needs to fa

The code for the first phase of this is in the OCS on GitHub now. Run just like you did for the first test again and it should allow me to identify the general area of the OCS that caused the ~10 seco

You can run the second test if you like, but it is not really necessary now. We have confirmed my suspicion, something is blocking the main-loop for >8 seconds and triggering a reset. Now we just need

Good to know. I removed the extra watchdog resets in the OCS, they are obviously not solving this problem and are not needed. I added a new debug option though: #define DEBUG_LOOPTIME ON // OFF, ON to

There's actually a bunch of little refinements in the update too. I coded the momentary button press timer to work in 0.1s intervals instead of 1s so the length of the press is more tightly controlled

I did this update. Much of how it behaves depends on the options selected. For an situation where ROR_MOTOR_OPEN_RELAY == ROR_MOTOR_CLOSE_RELAY == ROR_MOTOR_STOP_RELAY and there is no ROR_POWER_RELAY:

The next option would be to turn the WATCHDOG OFF and see if you still have stability.

I've added those fixes, thank you for review and testing. I'm thinking about another possible issue with your proposed setup. The OCS shows a Stop button but it really doesn't do anything to stop the

Not if the signal levels are within spec. (0-5V) I know of no way that option should effect the website beyond it's ability to reboot/reset everything (once an hour with your former settings) if that

Have you tried turning OFF the WATCHDOG_CHECK_HOURS and see if the reboot still occurs?

A connection attempt. If there's no response the watchdog-reset is blocked which causes the watchdog timer to reach its full count (8 seconds without a watchdog-reset) and trigger a reset of the Mega2

Here's a Roof.ino with the interlock changes. If you could test/report back that would be great. I implemented this so the roof power relay can be used to power up the interlock system (a design goal.

I figured close only would be sufficient. Ok, as above. Agree with the concept and it's a good enhancement to the functionality. Also, the idea here is the ROR_POWER_RELAY will "unplug" the garage doo

Perhaps you should move that from pin 53? AFAIK it's not in use unless you hook up the DS3234 though so I don't have a good reason why that should matter.

This is with your Config.h I changed only the network addresses and set the W5100 reset to the Mega2560 pin 8 where I have it wired in:

So what is different? Post the Config.h file.

Check to see if 2.2e resolves the problem. If not I'd go back to defaults for Thermostat.ino and Weather.ino (no sensors.) Lets get it working without resets first, then go from there.