Meshtastic Configuration
LIA runs on top of Meshtastic, configured as a tracker role node, with its own TrackerService replacing stock Meshtastic’s position broadcasting entirely (rather than just tuning stock settings). Everything LIA-specific — position broadcasts, charge-status notifications, and all CommandService commands/replies — is a direct message to a single predefined target node, never a channel broadcast.
Setting the node role
Section titled “Setting the node role”Go to Radio Configuration → Device → Role and select Tracker.
sh meshtastic --set device.role TRACKER This matters beyond just labeling: stock Meshtastic only skips its own competing light-sleep timers for tracker-family roles, on the assumption that “sleep will be initiated through the modules” instead — which is exactly what TrackerService’s own BMS-driven state machine does (see Power Management). Leaving the role at its default will fight the firmware’s own sleep behaviour.
Target node
Section titled “Target node”The destination for every LIA-specific message is a single NodeNum constant defined once in the firmware (firmware/services/MeshTargets.h, kLiaTargetNode) — derived from that node’s MAC address (the low 32 bits, matching how Meshtastic derives its own NodeNums). It’s currently a fixed value baked in at build time, not yet exposed as an app-configurable setting, so building your own copy of the firmware means editing that constant to your own target node’s NodeNum first.
This is deliberate: Meshtastic encrypts per-channel rather than per-recipient, and position/telemetry handling in stock Meshtastic is promiscuous (any node that can decrypt a packet updates its own map from it, regardless of who it was addressed to) — sending on a channel would let any node holding that channel’s PSK see this device’s position. A direct message to a specific NodeNum is commonly PKI-encrypted by the official app/firmware, so only that one node can read it, and it sidesteps channel/PSK provisioning entirely — nothing needs to be configured on the receiving side beyond pairing with the device. (An earlier design routed everything through a private channel found by name; this was replaced in favor of direct addressing, since PKI direct messages already bypass the channel/PSK system and report channel=0 regardless of which channel was open at the time.)
Text commands
Section titled “Text commands”Send these as a direct message to the device — replies come back the same way, as a DM to whoever sent the command. Commands are case-insensitive and tolerant of extra spacing (led off, Led Off, and LED OFF all work).
| Command | Reply / effect |
|---|---|
GPS | Current position, or “No GPS fix yet”. |
BATTERY | Current gauge charge percentage. |
IMU ON / IMU OFF | Arms/disarms motion detection — sends "Activity detected" on a real motion event (see Accelerometer). |
CHG ON / CHG OFF | Enables/disables the "Charging" notification. |
STB ON / STB OFF | Enables/disables the "Device charged" notification. |
LED ON / LED OFF | Manually overrides the status LED (see RGB LED). |
HELP | Lists all commands. |
IMU ON’s activity messages are unsolicited (not a reply to a command) and always go to the configured target node, same as position broadcasts and charge-status notifications.
Position broadcast interval
Section titled “Position broadcast interval”TrackerService doesn’t use stock Meshtastic’s position.position_broadcast_secs setting — it broadcasts on its own fixed cadence, which depends on the BMS switch position (see Power Management):
- Continuous mode (switch HIGH): every 30 seconds.
- Sleep-cycle mode (switch LOW): once per wake, roughly once a minute.
See also: LoRa, GPS, Power Management, and Building the Firmware.