Controlling physical infrastructure over LoRa — no internet required at any point in the loop.
A bot node watches a mesh channel or DM for commands. When it sees one from a trusted source, it triggers an action on a connected device — a relay, a GPIO pin, a smart plug, anything controllable. These are called entities in Home Assistant (as opposed to sensors, which are read-only).
The path is: mesh node → repeaters → bot node → local action. No cloud, no internet, no external service in the loop.
Access control is pubkey-based — only whitelisted node hashes trigger automations. Private channel membership (shared key) is treated as implicit trust for that channel, so the channel key itself is the credential.
Sending !mantleon, !mantleoff, or mantle toggle over the mesh toggles a Hubspace smart outlet. Full loop proven: mesh radio → Home Assistant → physical device, no internet involved. No custom hardware on the device side — the outlet is a standard HA entity.
Hardware: PalBot 🤖 is an ESP32-based LoRa node running MeshCore firmware (v1.16.0), connected via USB serial (/dev/ttyACM0) to a home server running Pop!_OS Linux. Home Assistant runs in Docker on the same machine. The meshcore-ha integration holds the serial port directly — no intermediate broker in this configuration.
meshcore-ha: Community custom integration installed via HACS — not an official HA integration. Required a local patch for HA 2026 compatibility (send_ui_message was passing hass=None to an internal call that now requires it). That patch hasn't been upstreamed yet.
Depending on complexity needed, there are two ways to build this:
A Python script using meshcore-python (pyMC) watches the mesh directly on a Pi with a LoRa tophat. When a matching command arrives, it fires a GPIO pin to control a relay. No HA, no Zigbee, minimal resources — a Pi Zero 2W handles it easily.
pyMC exposes a subscribe API: meshcore.subscribe(EventType.CONTACT_MSG_RECV, handler) fires a callback on every incoming DM. Access control is built in — filter by sender pubkey prefix (attribute_filters={"pubkey_prefix": "…"}) or by channel index. GPIO from there is a few lines of Python.
The right choice when you need more than a trigger — scheduling, dashboards, Zigbee device integrations, complex automation logic. The meshcore-ha integration connects HA to the mesh. Zigbee adds ~$50 in hardware but is highly reliable with zero ongoing cost.
Sending a command over the mesh is one thing — knowing it was received and acted on is another. Right now there's no confirmation loop: you send !mantleon and hope it got there.
The next piece is annunciation — the receiving node sending back a confirmation message over the mesh once the action executes. Something like "Mantle light ON ✓" coming back as a channel reply would close the loop and make this genuinely reliable for infrastructure use.
Confirmed possible: the meshcore-ha integration exposes send_channel_message and send_message services that can be called from an automation after a command executes. Not yet built, but it's the next thing.
Internet outage detected by an HA ping sensor → HA sends a mesh message → a Raspberry Pi at the repeater site receives it → trips a relay switching the DMR repeater to a LoRa backup link. No internet required at either end of that chain.
The remote Pi will be serial-only — a MeshCore companion node connected via USB, no WiFi or network dependency beyond the mesh. The PoC confirmed the full loop works; this strips it down to serial + script + relay for a simpler, more resilient deployment at an unmanned site.
Deployment considerations
Getting firmware to repeaters on towers or hard-to-reach sites without a truck roll is an obvious problem. A few approaches are being explored across the MeshCore community:
Drone OTA — already being done
Attach a Xiao nRF52840 to a drone (DJI Neo2 — 7.5g total payload including a 250mAh Li-Ion), fly close enough to the repeater for signal, and push the firmware over the air. The transfer starts automatically once the updater detects the target device name at sufficient signal strength. LED confirms success or failure. Requires oltaco's OTAFIX bootloader (v2.1+) on the repeater and RAK3401/RAK4631 boards with RAK15001 external flash.
Static relay box — idea to explore
A small box at or near the site with an IoT SIM or WiFi receives firmware over the internet, then pushes it to the repeater via a longer or directional antenna pointed at the tower. No drone, no truck — the relay box just needs power and occasional cellular coverage. Range and antenna selection would need testing for each site.
MeshCore Remote Management — not truly remote
The app's Remote Management feature can send a start ota command over LoRa to an ESP32 repeater, which then spins up a WiFi hotspot named MeshCore OTA. You connect to that hotspot and upload the firmware via browser at http://192.168.4.1/update. So it's LoRa to trigger, WiFi to deliver — you still need to be physically close enough to join the hotspot. For nRF52 devices it's BLE DFU, same limitation. Neither approach works for a truly unmanned remote site, which is why the drone and relay box ideas exist.
The meshcore-python library opens the possibility of running a full MeshCore node directly on Linux hardware with a LoRa SPI hat — no separate ESP32 or radio dongle required. A Raspberry Pi with a LoRa pihat could act as both the mesh node and the relay controller in one device, simplifying remote deployments significantly.
Because Home Assistant supports thousands of integrations, any device it can control becomes mesh-reachable: garage doors, irrigation, HVAC, alarms, cameras. The private channel + pubkey auth model scales to multiple trusted operators — practical for small teams managing shared infrastructure over off-grid radio.