Monitoring

3 Mechanisms for Remote Device Reboot

In principle, there are 3 mechanisms for rebooting a remote device. Manual reboot by human operator or 2 different mechanisms of automatic reboot.

• Automatic reboot - Failure detection

 The automatic failure detection mechanism works without modifying the controlled system. You simply set up failure detection based on an existing parameter that is easy to monitor. For example, a web page request or PING detection can check the LAN connectivity of a specific device.

• Automatic reboot - Heartbeat

Heartbeat mechanism reboots the device if no heartbeat signal is received within a defined time. The IP WatchDog can receive a PING request, a web page request, or a defined string in the serial port data stream.
This is a reliable WatchDog process, but you must ensure that the monitored system sends the heartbeat signal.

• Manual reboot (device interface)

 A human operator can manually reboot the device using the web interface.

5 + 1 Failure detection Methods / 3 rebooting Mechanisms

	Manual Reboot	Outgoing Ping	Incoming Ping	WWW Page (server)	WWW Page request (client)	RS-232 string (Rx)
Manual reboot	Yes	-	-	-	-	-
Automatic reboot - Failure detection	-	Yes	-	-	Yes	-
Automatic reboot - Heartbeat	-	-	Yes	Yes	Yes	Yes

Manual reboot

Manual reboot is useful when a single device or a complex system stops working, and you need to restart (power cycle) it remotely. This is typically done via the web GUI of the IP WatchDog device (using its IP address) or via the Portal (HWg-cloud or SensDesk).

Automatic reboot - Failure detection

Automatic reboot based on failure detection is an ideal solution. The issue is fixed automatically without user intervention.

• Outgoing Ping

 Failure detection works by checking for a PING reply (ICMP service) from the monitored device.
A common example of Automatic Reboot – Failure Detection is Outgoing Ping (Ping Out). If the monitored device responds to a PING within the defined time, the IP connection is considered OK. If no response is received, the connection is considered down, and the system can trigger a reboot.

• WWW page request (client)

 Failure detection works by checking if the defined web page exists. The web page content is not analyzed.

Failure Detection limits without Heartbeat signal

Automatic failure detection works even without a heartbeat signal from the system. It’s easier to set up.
In some cases, a device may still respond to PING or WEB requests but remain frozen. A typical example can be the video codec of an IP camera that freezes, but the camera's web page works fine. The advantage of failure detection without a heartbeat signal is that you do not need to implement a heartbeat signal process in the monitored system.

Automatic reboot - Heartbeat

Heartbeat signal detection is a reliable WatchDog solution. However, the monitored system must be modified to send periodic heartbeat signals at critical points.

• Incoming Ping

 The monitored system periodically sends a PING request to the IP WatchDog2 device. If no request is received within the defined time frame, a failure is detected.

• WWW page (server)

 The monitored system periodically requests a specific web page from the IP WatchDog2 device. If the request is missing within the defined time frame, a failure is detected.

• WWW page request (client)

 The heartbeat signal is generated by activating or deactivating a specific web page on the monitored system’s web server.

• RS-232 string (Rx)

 The heartbeat signal is monitored in the serial port data stream. The IP WatchDog2 Industrial searches for a predefined string in the data stream at set intervals. If the string is missing within the defined time frame, a failure is detected.

Alerting for Reboot

When an automatic reboot is triggered by the IP WatchDog device, it can send an email alert via SMTP server or an external portal (HWg-cloud / SensDesk).
However, public SMTP servers are often unreliable in the long term. A better option is to use the HW group portal. The HWg-cloud.com service is free of charge, but only supports email alerts.

SMS alerts

To send SMS or call alerts when an event (such as a reboot) occurs, there are two options:

1. Local SMS Gateway – The IP WatchDog can be connected to a physical SMS gateway at the same location.
2. SensDesk.com Portal – With a paid account, SensDesk provides reliable SMS and call notifications without requiring additional hardware or software.

Typical Use Cases for IP WatchDog

Automatic Failure Detection of an IP Camera

The WatchDog continuously monitors system conditions and triggers a reboot when a failure is detected. A practical example is the monitoring of an IP camera. The WatchDog periodically checks the camera’s web server. If the server does not respond or returns an error, the WatchDog automatically power cycles the camera via a relay to restore functionality. This ensures continuous operation without human intervention.

Automatic Reboot of a Kiosk System Based on Heartbeat Outage

Public kiosks require continuous operation. The IP WatchDog monitors the computer by receiving periodic heartbeat signals that confirm the system is running.
If these "I'm alive" signals stop (due to a software crash or system freeze), the WatchDog automatically restarts the computer. This ensures 24/7 uptime without requiring manual intervention.

Other Common Use Cases

• Remote Server Reboot – If a server unexpectedly freezes, the IP WatchDog2 allows remote power restart without the need for a technician on-site.
• Kiosk Monitoring – The WatchDog automatically monitors and restarts kiosks when they stop functioning.
• IP Camera Monitoring – The WatchDog checks security system cameras and reboots them if they stop working.
• Network Equipment Restart – The WatchDog can restart a switch, router, or WiFi access point during communication failures to ensure continuous network connectivity.
• Electric Vehicle Charging Stations – The WatchDog monitors and restarts charging stations if operational issues occur.
• Backup Internet Activation – If the monitored device primary Internet connection fails, the WatchDog can automatically switch it to a backup LTE connection if available.
• Smart Home Device Recovery – Thermostats or other smart devices may lose connectivity. Restarting them often resolves network issues.
• POS System Reliability – Point-of-sale (POS) systems may freeze during high transaction loads or software errors. Restarting them resolves issues, ensuring smooth sales transactions.

Watch the IP WatchDog2 product presentation video:

Do you have any questions?
Contact us.

In addition to improving the hardware, we wanted the new sensors to correctly align with the change in our philosophy established for the Perseus platform - each external data source acting as a single “Meter”, with one or more “Variables” available.

In the past, most of our monitoring units, whether it was Poseidon2, Damocles2, Ares 12 or any other, operated with the “Sensor Values” licenses, so all the sensors supported this line of reasoning. There was a maximum number of “Sensor Values” available for each device, not the number of connected physical or virtual data sources.

With the introduction of the Perseus platform, the “Sensor Values” and the licenses for the respective monitoring units no longer exist, because in Perseus units we only work with the “Meter”, which represents a connected data source, either a sensor, a detector, another device connected via XML, SNMP, MQTT or Modbus/RTU, and its “Variables”, similar to the former “Sensor Values”.

With all Perseus units supporting up to 100 meters and 1000 variables, we needed to find a way to capitalize on this number. With the first generation of sensors connected to a Perseus unit, you would get a separate “Meter” for each “Sensor Value”. 

Because so many sensors have more than one measured value, starting with the popular combined Temperature and Humidity sensors, which are the most commonly used sensors in any environment - with such combined sensors you would have to work with two separate “Meters”, and their respective “Variables”. In the case of the 1-st generation THPVoC sensor, you would have 4 separate “Meters” in the Perseus device, in one physical box with four hardware probes.

This will change with the next generation of 1-Wire UNI sensors, which have been upgraded specifically to accommodate the change in the Perseus platform. With the new generation of 1-Wire sensors, those that have more than one measured value will be represented in the Perseus’s GUI as a single “Meter”, with multiple Variables (formerly “Sensor Values”).

This may seem like a small change, but for the HW group it is important and essential, as we want to give our users the full ability to use all the 100 Meters available to them from a hardware perspective. In addition, Perseus views Meters differently than the older monitoring devices we produced in the past, and the real work in the new Perseus units is at the Variable level. This means that this change will help Perseus users organize and manage their monitoring setups much more efficiently.

And nothing changes for the older HW group devices with the newer sensors - they are backwards compatible with everything we’ve produced in our 20-year history.