Coding cont.

Flow rate input is provide for in code, but the original flow rate meter in the main 50DN line is not operating correctly (probably an installed impeller requiring dismantling and rectification) and will require attention. (It turns out that real-time on-line flow rate monitoring is not as important as originally supposed . The current manual flow meter confirms that flow rates are pretty stable, and thus predicable and the tank water-level sensor provides the crucial information of how much water remains. However, the code provides for the flow pulse counters are read and cleared by briefly disabling interrupts, preventing race conditions where a pulse might arrive during the counter read. The accumulated pulse counts convert to liters per minute as described earlier. If resulting flow rates are below 0.05 liters per minute, they are forced to exactly zero to eliminate noise from false pulses.

This packet is broadcast to IP address 255.255.255.255 on port 5000, reaching all devices on the local WiFi network.

AR3, connected to AR2's WiFi access point as a client, listens on port 5000 for incoming UDP packets. When a packet arrives, AR3 parses it by searching for each expected key string followed by a colon, extracting the substring up to the next pipe character, and converting it to the appropriate data type. These parsed values are stored in volatile global variables where they can be accessed by the autonomous control algorithms. The entire sensor acquisition, broadcast, reception, and parsing cycle completes in well under 100 milliseconds, providing effectively real-time environmental data to the decision-making code.

Testing the AR1–AR3 Backup Communications Path

Two communication links are provided from the House (Arduino AR1) and the Pump Shed (Arduino AR3) both going over separate wires of the underground multicore cable. The primary link is over two wires connected to Gravity RS485 Transceiver Modules at each end, which in turn connect to the TX and RX pins of the AR1 and AR2 Arduinos. This RS-485 link to AR3 will automatically switch to a backup SoftwareSerial path over two other wires if the primary link fails. The following procedure tests this failover without disconnecting any cables.

Proceed with: HA dashboard open at System Health page - testing using AR3 Comms Path Test control.

  (Optionally also have serial monitor on AR1 open)

Procedure

Confirm normal operation — the Active path card shows primary and Alert active shows 0.
Set the Force path dropdown to backup. AR1 immediately switches to the SoftwareSerial path. Within a few seconds:

* Active path changes to backup

* Alert active changes to 1

* An alert email and SMS are sent (if master alerts are enabled)

* AR1 Serial monitor shows [PATH TEST] Forced → BACKUP path

Verify AR3 still responds — issue a pump or peripheral command from the dashboard and confirm the relay state updates. AR3 is receiving on D9 and responding on D10.
Set the Force path dropdown to auto to release. AR1 returns to watchdog control. Within 10 seconds it detects telemetry on the primary RS-485 path and switches back — Active path returns to primary and Alert active clears to 0.

Notes

The backup state resets the AR3-ready gate. Allow a few seconds after forcing backup for AR3 telemetry to arrive on the backup path before relay commands will flow.
Setting Force path to primary is available if you need to confirm the RS-485 path specifically, without triggering the watchdog.
If HA restarts, the dropdown resets to auto and no force command is re-sent to AR1.
This test exercises the full path: path switching, HA sensor update, alert dispatch, AR3 command response, and watchdog recovery. It does not test the physical RS-485 hardware fault scenario — for that, power off the Gravity module on AR1 and wait 10 seconds without forcing anything.

For more detail on coding see the Coding Technical Appendix

<< Coding | | Autonomous Fire Defence Algorithms >> |Table of Contents>

Page last modified on May 08, 2026, at 12:39 am