Short answer
Publication date: August 21, 2026
A small failure at a remote cabinet is much more expensive than the same failure in a city office. A frozen modem, offline NVR, lost inverter communication, or high cabinet temperature may require a long journey for a few minutes of work. If detected late, camera recording, production data, or communication services may remain unavailable for hours.
NetRelay provides a local IoT layer for monitoring network availability, environmental conditions, door contacts, and auxiliary equipment. Four digital inputs can monitor cabinet doors, power, UPS alarms, or communication relays. Supported external sensors can measure temperature and other conditions. Four relay outputs can provide controlled intervention for modems, routers, NVRs, or auxiliary fans through an appropriate power circuit.
Automatic restart with Ping Watchdog
NetRelay can monitor up to four IP addresses. If a modem, router, NVR, recording server, or field computer remains unavailable for a configured duration, a predefined relay action can run.
One failed ping should not cause a restart. Consecutive failures, waiting time, retries, power-off duration, and post-restart validation must be configured. Maximum retry and alarm-escalation rules prevent endless restart loops.
NetRelay must remain powered while restarting another device. A suitable PoE switch or separate DC supply may be necessary. If load current or inrush exceeds relay capacity, an appropriate contactor must be used.
Telecom auxiliary cabinets
Telecom sites require monitoring of temperature, doors, power, fans, and auxiliary alarm contacts. NetRelay can read permitted signals and send them centrally through MQTT. A high-temperature condition can trigger an auxiliary fan or alarm relay.
It should not replace certified telecom alarm or power systems. It belongs in auxiliary monitoring, local automation, and software integration. EMC, grounding, surge protection, enclosure, and operating temperature must be evaluated.
Solar and remote energy sites
At a solar plant, communication health may be as important as inverter production. The inverter or data logger can be pinged, while a communication alarm contact is read through a digital input. Cabinet doors, temperature, and power presence can be collected by the same device.
NetRelay does not replace an energy meter or protection relay. It can provide early communication-loss detection, auxiliary environmental control, and custom-software integration. Optional MicroSD may support local event recording, while MQTT or HTTP provides central telemetry.
Camera and NVR continuity
An offline NVR or camera network creates a security gap. Ping Watchdog can monitor connectivity. If the NVR provides a general or disk-fault contact, it can be connected to a digital input. Controlled power cycling must respect manufacturer procedures and data integrity.
NetRelay does not process video. It monitors network and dry-contact status. License-plate or video-analytics software can send HTTP or MQTT commands to trigger an auxiliary barrier, light, or alarm.
Central monitoring without inbound ports
Devices in different cities can make outbound MQTT connections to a central broker, reducing the need for inbound port forwarding at every site. VPN, TLS, user authorization, ACLs, strong passwords, and network segmentation should still be implemented.
Device naming should include location, panel, and function. “Device 1001 unavailable” is less useful than “Solar Plant 2 inverter communication cabinet unavailable.” Alarm start, continuation, and recovery events should be stored.
How is ROI calculated?
Remote-site ROI is driven mainly by avoided visits and shorter outages:
Monthly benefit = remotely resolved incidents × average visit cost + reduced downtime × service or production loss + damage prevented through earlier detection.
Visit cost should include technician time, vehicle, travel, security access, and opportunity cost. Since not every incident can be solved remotely, use the real resolution rate.
Select a site with a known fault history for a 30–60 day pilot. Measure availability, successful automated recovery, false alarms, remote resolutions, and physical visits. If value is verified, use a standard panel and MQTT profile for rollout.
When is NetRelay the right choice?
NetRelay is suitable when four inputs and four outputs are enough, several network devices and alarms must be monitored, and local rules should work independently of the internet. Projects requiring large I/O, certified protection, redundant telecom control, or critical process safety need a different primary controller; NetRelay may support auxiliary automation.
Prepare the site count, equipment power data, alarm contacts, network architecture, power supply, and central-software requirements. Evaluate NetRelay as a complete remote-site solution including panel, sensors, communications, software, and maintenance rather than only as a relay board.
Field-ready panel design
Enclosure and electrical design are as important as the controller. Evaluate IP rating, internal temperature, condensation, dust, solar load, and pests. NetRelay supports DIN-rail installation but should not remain exposed outdoors.
Select DC power quality, fusing, reverse-polarity, surge, lightning, and grounding measures for the site. Outdoor Ethernet may require network surge protection and equipotential grounding. Fan control should consider fan failure or airflow confirmation, not only temperature.
Incident and service workflow
Document the response to each alarm. First review connectivity, power, and target IP. If appropriate, attempt a controlled restart. If recovery fails, create a field work order containing the latest state, actions already taken, and suggested spare parts.
This improves technician preparation. Remote resolutions should be marked separately to calculate ROI.
Communication redundancy
If NetRelay and monitored equipment depend on one modem, complete modem failure removes central visibility. Critical sites may require cellular backup, a second modem, or an independent alarm channel.
Local restart can work without central communication, but physical line cuts, operator outages, and power failures cannot be fixed by repeated restarts. Use maximum attempts and escalation.
Cybersecurity and command safety
Remote relay control requires strong authorization. Internet-facing MQTT brokers need TLS, unique users, strong passwords, topic ACLs, connection limits, and logging. Devices should publish only to their telemetry topics and subscribe only to permitted command topics.
Command software should verify device identity, current relay state, and last connection time. Critical power commands may require two-person approval or a maintenance window. Never expose the web interface directly; use VPN or a secure management network.
Local records and accurate time
Define which events remain locally available during communication loss. An optional MicroSD may record events, but format, retention, card endurance, and transfer procedures must be planned.
An optional RTC can preserve time where NTP is unavailable. Time synchronization and timezone standards are essential for incident analysis.
Scaling and device management
Manual unique configurations are not sustainable across many sites. Maintain device ID, hostname, IP plan, MQTT topics, firmware, and panel diagrams in central inventory. Use the same commissioning checklist.
Validate firmware in a lab or pilot site before phased rollout. Keep configuration backups and rollback plans, and never update every critical site simultaneously.
Solution package and service model
Selling only the board does not guarantee the expected result. A complete package includes discovery, panel, protection, sensors, modem integration, MQTT infrastructure, dashboard, alarm workflow, commissioning, and maintenance.
Periodic connectivity tests, health reports, alarm-rule updates, and firmware management can form an annual support service. Customers should understand which incidents can be automated and which require a visit.
Frequently asked questions
Can every fault be solved remotely?
No. It helps with controlled recovery from software freezes. Physical damage, cable breaks, power loss, and hardware failure still require site intervention.
Why is PoE useful?
It can carry power and data over one cable, reducing adapters. PoE switch UPS and power budget must be included.
Does it process camera video?
No. It can monitor camera or NVR connectivity and alarm contacts, or receive commands from analytics software.
How should a pilot site be selected?
Choose a high-visit-cost site with known faults and safe restart conditions. Measure remote resolution, downtime, and avoided visits.
A 60-day field validation plan
During the first 15 days, monitor only. Record normal ping behavior, brief outages, and power conditions. Test restart rules in a lab or controlled maintenance window. Two people should verify relay and outlet labels to prevent switching the wrong equipment.
Then simulate or observe a failure: the target becomes unavailable, retry conditions complete, the relay runs for the correct duration, and the event closes after recovery. If restart fails, verify field escalation. Finish with 30 days of stable operation and a remote-resolution report.
Continuity and spare parts
The dashboard should show last communication, power, and uptime, not only alarms. Repeated restarts may indicate a failing adapter, modem, or line. Technicians can travel with the correct spares.
Critical operations may keep a configured spare NetRelay. Replacement should restore identity, network, and MQTT settings under change control. Keep spare firmware consistent with inventory.
Buying-decision summary
NetRelay cannot repair physical damage remotely. Its value is earlier detection, controlled recovery, better technician information, and measurable incidents. The business case is stronger where travel cost is high and fault history is known.
Before quotation, list equipment power, restart safety, network addresses, alarm contacts, panel conditions, communications, and central software. Buying only a “remote reset device” without this design may not deliver the expected result.
Acceptance testing
During handover, trigger door, alarm, and power inputs individually. Two people should verify that every relay controls the intended equipment. Test Ping Watchdog delay and maximum retries through a controlled outage. The dashboard should show event start, intervention, and recovery.
The acceptance record should include site contacts, panel diagram, power source, device identity, IP plan, MQTT topics, alarm recipients, and manual procedures. This preserves installation knowledge for future service.
A successful acceptance test should also record normal current, restart duration, communication recovery time, and the maximum number of automatic attempts. These values provide a baseline for detecting future deterioration and prevent repeated recovery actions from hiding a developing hardware fault.