Skip to content
Boaz Feldboim edited this page Aug 29, 2023 · 23 revisions

Arduino Internet Watchdog Device

This project is intended to run on ESP32 with SD card reader and optionally a wired ethernet adapter. The code is developed using PlatformIO in visual studio code. The project is designed so that it is possible to connect to the LAN either using the ESP32's WiFi, or using a wired Ethernet adapter (USR-ES1, or other W5500 based adapter).

What it does is basically periodically ping a server on the internet and optionally a local address on the LAN. If ping fails, it switches the router power to off and then on after several seconds. Then it waits for internet connectivity to resume. If internet connectivity is not resumed after some time, it switches the modem power to off and then on after several seconds. Then it waits for internet connectivity to resume. If internet connectivity is not resume, it goes again through the recovery attempt cycles until internet connectivity resumes, or maximum recovery cycles exceeded.

There are quite a few configurable parameters to this software, like name of server on the internet to ping, an optional alternative internet server to ping if the ping to the first server failed. Also the time for power disconnect and waiting time for connection to resume are configurable and more.

There is also an implementation of a web (HTML) site that is used as a human interface for monitoring, controlling and configuring the software. The web site also has a page for reporting recoveries history.

The code should be compiled using either the wifi or the wired environments, depending on the chosen configuration. That is whether the LAN connection is done using the ESP32's WiFi, or a wired ethernet adapter. Then the code should be uploaded to the ESP32. The files in the SD directory should be (tree) copied to an SD card and be placed in the SD card reader.

Edit the content of file config.txt on the SD card. The content is pretty much self-explanatory. The TimeServer parameter is used for setting the server name used for getting the current GMT time using NTP protocol. The TimeZone parameter is used to set the local time. The value is in minutes and can also be negative. DST is number of minutes to add to the time during daylight saving time. Then there are parameters for setting Ethernet. The code uses static IP address so the site address is always the same. Then you can also set the pin numbers for switching the router and modem power using relays. In case WiFi is used, then the configuration file should also contain the SSID and password to connect to the LAN. For more elaborated information see CONFIG.TXT wiki page.

There are also four pushbuttons with an LED in each of them. the pushbuttons are used to initiate connectivity checks and recovery cycles manually. The LEDs are used to report the status of the device, such as normal status when internet is available, or whether a recovery cycle is on-going.

The application is running a state machine that starts in a state where it tests the connectivity by sending ping messages to configurable addresses. If it finds that the connectivity is OK it waits a configurable time an then test connectivity again and so on. If connectivity is lost, it starts a recovery cycle. First it turns off the power to the router waits a configurable time and turns on the router power. Then it waits a configurable time for the connectivity to resume. While it waits for the connectivity to resume it continuously sends ping messages to the configured addresses. If connectivity is resumed within the configured time, it returns to the first state. If connectivity was not resumed, it turns off the modem power waits a configurable time and turns on the modem power. Then it waits a configurable time for the connectivity to resume. If connectivity was resumed, it goes to the first state. Else it starts a new router recovery. This can go on forever, until connectivity is resumed, or a configurable maximum number of recovery cycles.

The recovery control module that is internally implemented by a state machine (described above) that exports observer objects that triggers events upon changes in recovery states. One observer is updating the HTML user interface. A second observer is triggering another state machine that generate history information about previous recoveries. A third observer is updating the LEDs on the device panel.

The HTML pages are using bootsrap 3 libraries in order to produce nice looking responsive pages. The bootstrap libraries were renamed to names the conform to 8.3 file names (e.g., bstrap.js). This was done because the project started on a mega2560 board and the only SD library that I had there supported only 8.3 file names. After transferring to ESP32, I could use longer file names, but I left it as it was. Also jquery libraries are used by the JavaScript code. All required jquery libraries were merged to one single library (jqcombo.js) in order to reduce page load time and sockets consumption.

In order to load code to the ESP32 processor, you need to have some sort of serial COM port connected to the TX/RX lines in the Program connector (6 pins). Then you need to press the reset and boot microswitches in order for the code to get loaded. Same as with ESP-32S board. I use the ESP-Prog board, it also sets the IO0 and EN lines. So you don't need to fiddle with the boot and reset microswitches every time you want to load new code. Also the ESP-Prog board enables you do inline debugging. For that you'll need to use the 10 pins Debug connector.

The box contains hardware watchdog. For more information about it see Hardware Watchdog.