MeshAutoResponder (MAR)
Systron, LLC · Firmware 1.1.1

Quick start

1. Join MeshAutoResponder-Setup with password ESP32MESH.
2. Open http://192.168.4.1/wifi. Web login: admin / ESP32MESH on a new unit, or your saved password.
3. Save your 2.4 GHz Wi-Fi network. Rejoin that network and open the OLED IP or http://meshautoresponder.local/. mDNS may not work on every network; the IP remains available.
4. Change the web password and configure your commands. Keep MAR and the radio node in matching serial modes.

Primary-channel responses are restricted by default in PROTO mode. MAR responds to DMs and private/secondary channels without enabling Primary. Dedicated infrastructure-node operators can enable Primary responses in the firmware dashboard by confirming the infrastructure-node checkbox and turning on the Primary option. This safer default reduces unwanted automated traffic from general-purpose nodes.

Wi-Fi and weather location start blank. Fresh installs contain four disabled command examples. Configure and enable only the commands you want to answer. Existing saved commands (including an intentionally empty list) are preserved by updates; Load example rows restores a preview for review and saving.

iOS blank captive window

The automatic login window can fail to show the browser authentication prompt. This does not mean Wi-Fi or the clock has failed.

1. Stay connected to MeshAutoResponder-Setup. Choose Without Internet if offered. Simply cancelling may disconnect you.
2. Open Safari and type http://192.168.4.1/wifi (not HTTPS).
3. Sign in as admin with your current web password and save your network.

No erase is needed. See Apple captive Wi-Fi guidance.

PROTO versus TEXTMSG

PROTO is recommended for dedicated infrastructure nodes. It exposes structured packets and supports advanced actions, but uses the client API and can compete with another phone/client for API data depending on node firmware. It does not inherently turn off Bluetooth, but simultaneous phone use is not guaranteed. Test your node/firmware combination. The radio continues normal mesh relaying according to its configured role; choosing a serial mode does not itself set a router role.

TEXTMSG is simpler and does not use MAR's protobuf client polling. It is useful for basic public keyword replies, but loses addresses, channel IDs, hop metadata and telemetry. Sender short names are not verified identities; rate limits group matching short names together.

PROTO response policy: the safe default accepts DMs and private/secondary channels while ignoring Primary. Replies return by DM or on the same private channel. Primary commands and replies require both an explicit infrastructure-node confirmation and the Primary opt-in. TEXTMSG cannot enforce this policy because destination and channel identity are unavailable.

TEXTMSG may expose incoming DM text on UART. MAR cannot identify that it was private: an automatic reply is public on the default channel. Do not use sensitive replies in this mode. Incoming behavior varies with node firmware. Keep Echo off to avoid loops.

1. In the dashboard expand Protocol and choose the mode.
2. Save mode & restart. MAR saves the choice without deleting commands or credentials.
3. Separately change the node's Serial module to the same mode at 38400 baud. The dashboard switch does not reconfigure the radio.
4. Test a known command from another node. If the link fails, return to the portal and select the former mode.

Reference: Meshtastic Serial implementation and client API implementation.

Commands and actions

Choose unique names such as !myrelay, *myweather, or %mystatus. Avoid common words and do not use #. Names: 2–16 characters; prefix !, * or %, then lowercase letters, digits or underscore. Text: 1–200 UTF-8 bytes. Up to 12 commands. Matching ignores letter case and surrounding spaces, not extra words. Unknown/disabled commands are silent.

Editing does not save until Save changes is pressed. Load example rows replaces the editor preview only after confirmation; no automatic overwrite of saved commands occurs. Telemetry actions remain saved but inactive in TEXTMSG.

PROTO telemetry actions use the latest received device, PowerMetrics CH1/CH2/CH3, or environment report; these can come from a remote node and the reply identifies its node ID. CH1–CH3 are telemetry fields, not extra MAR GPIOs or mesh channels. INA219 mapping depends on node firmware; do not assume CH3 on every board. Cached data can be stale; these are not safety-critical readings.

Rate limits: one accepted command per sender per 15 seconds, at least 3 seconds globally, and 10 per minute. Manual sends also have a 15-second limit. All outgoing text shares a 3-second/10-per-minute limit. A pending weather request blocks more commands and manual sends. Lost UART data or radio delivery is not automatically retried by MAR.

Dashboard terminal, counters and clock

The Primary terminal sends broadcasts only, never manual DMs. In PROTO it shows only channel 0 broadcasts. In TEXTMSG, received lines cannot be filtered by channel or destination and are explicitly labeled as unknown. Last 24 messages are kept in RAM and cleared on reboot. It is not a raw serial or debug terminal.

“Handed to node” means the serial write succeeded, not that another node received the transmission. Session counters reset on reboot. Lifetime text RX/TX is saved roughly once per minute; sudden power loss can lose the last minute. It excludes non-text LoRa traffic and other transmissions the node sends independently. The internet clock displays local browser time after NTP synchronization. Waiting for time during setup/offline operation is normal.

Heard Nodes (PROTO only)

MAR records up to 1,000 packet senders actually observed through the attached node, newest first. It shows identity when NodeInfo is available, last-heard time, packet count, signal metadata, channel, hops and reported battery. Relayed reception is not direct RF range; MQTT and unknown hops are labeled instead of guessed. Records save about every ten minutes, so sudden power loss can lose the latest interval. The oldest entry is replaced at capacity. Clear history permanently removes this database but does not erase commands or Wi-Fi.

Meshtastic node setup

1. Connect your phone/client to the node and open Settings → Module Configuration → Serial (menu names vary).
2. Enabled: on. Mode: PROTO or Text Message, matching MAR. Baud: 38400. Echo: off. Override Console Serial Port: off.
3. Choose unused node RX/TX GPIOs based on its exact schematic. Save, allow reboot and read back settings.
4. Power down before wiring. Cross TX and RX and connect ground. Test from another mesh node.

Do not use GPS, radio, display, flash, USB or boot-strapping pins without verifying conflicts. There is no universal node GPIO pair.

Station G2 example only

Node RX=17, TX=18: G2 IO18 → MAR GPIO17/RX; G2 IO17 ← MAR GPIO18/TX; ground to ground. Use IO17/IO18 connector positions—not TXD0/RXD0. Verify board revision before wiring.

Hardware reference and used pins

This schematic identifies only the connections MAR uses; it is not a physical header-position drawing.

“VCC” is not a voltage specification. Do not connect an unverified node VCC or a raw battery to MAR. If the node cannot supply sufficient power, use a separate regulated supply and common ground. Use one power source at a time; disconnect node power while USB powers MAR unless the board's power-isolation design is verified. Power off before continuity testing or rewiring.

Espressif documents mutually exclusive USB, 5V-header and 3V3-header supply options; third-party boards require their own schematic check.

Errors, LEDs and troubleshooting

Updates and saved settings

After this update, use http://meshautoresponder.local/ or the display IP. If setup is needed, join MeshAutoResponder-Setup. Saved home Wi-Fi credentials and other settings are unchanged.

Use MeshAutoResponder-update.bin in the portal to retain commands, Wi-Fi, web password, weather, protocol mode and counters. For an older portal that rejects the new name, rename a copy of the application/update BIN to MAutoSponder-update.bin or the exact update filename that portal expects. Never rename a full image as an update image.

The new updater accepts current and previous filename aliases. The full image belongs at USB address 0x0 with flash mode Keep or DIO, not QIO. Application QIO/OPI configuration is separate. Existing working devices need only the portal update. To make a previously configured unit genuinely virgin, both NVS and recovery filesystem must be erased; normal updates intentionally preserve them.

Settings use nonvolatile storage with recovery copies. Command JSON backups contain commands only. Keep power on during upload/restart; source modifications must be rebuilt into a new application.

Security: HTTP on a trusted LAN only; never port-forward. Shared hotspot password is not a strong access boundary. Weather TLS certificate verification remains disabled. Images are checked for board/project/layout, not publisher signatures.