Lotato is the firmware-only Potato Mesh ingestor for MeshCore*.
- Meshtastic coming soon!
It runs directly on a WiFi-capable device and posts mesh data to a Potato Mesh instance without a sidecar.
MeshCore
- Flash the latest Lotato firmware: https://meshforge.org/MeshEnvy/MeshCore-lotato
- Run initial repeater setup at https://config.meshcore.dev and set an admin password.
- From remote admin CLI, configure WiFi and ingest:
wifi scan
wifi connect <n|ssid> [pwd]
lotato endpoint <https://your-potato-mesh-instance>
lotato auth <api-token>
lotato status
- Validate settings (shortcut + config alias):
lotato status
Three CLI roots are dispatched first (lotato, wifi, config); bare help / ? lists them. Legacy MeshCore CLI still handles other lines.
| Command | Description |
|---|---|
lotato |
Show lotato subcommand help (same as lotato help) |
lotato status |
WiFi, IP, node count, Due (visible + refresh-due), paused, last HTTP code, URL/token state, debug |
lotato pause |
Pause ingest (shortcut for config set lotato.ingest.paused on) |
lotato resume |
Resume ingest (shortcut for config set lotato.ingest.paused off) |
lotato ingest [n] |
Show recent ingest POST attempts (newest first) |
lotato endpoint <url> |
Set ingest URL (same as config set lotato.ingest.url <url>) |
lotato auth <token> |
Set API token (same as config set lotato.ingest.token <token>) |
wifi status |
Current WiFi / saved SSID snapshot |
wifi scan |
Scan for nearby APs (async — full list when scan completes) |
wifi connect <n|ssid> [pwd] |
Connect by scan index (1-based) or raw SSID |
wifi forget <ssid> |
Remove an SSID from the known list |
config ls |
List registered keys with effective values (secrets redacted) |
config get <ns.key> |
Print one value (e.g. lotato.ingest.url) |
config set <ns.key> <value> |
Set a value (validators + ranges apply) |
config unset <ns.key> |
Remove saved value (revert to default) |
help / ? |
Router lists each root (name + brief); use help <root> or <root> help for that root’s commands |
help lotato |
Same as lotato help |
lotato help |
Flat lotato command list |
Lotato releases use annotated git tags of the form lotato-v<lotato>-repeater-v<meshcore>, for example lotato-v0.1.0-repeater-v1.14.1, where the repeater-v… suffix is the upstream MeshCore repeater release that revision was based on.
- No changes yet.
- Composable CLI:
locommand::Routerwith rootslotato,wifi, andconfig. Endpoint/token setup is vialotato endpointandlotato auth(plusconfigaliases), and WiFi commands are on thewifiroot.locommand::ArgSpecimproves leaf help. - ConfigHub /
configCLI: typedlotato.*andlofi.*keys in LoSettings withconfig ls|get|set|unset. - Ingest: visibility (
lotato.ingest.visibility_secs) and GC (ingest.gc_stale_secs) controls; LoDBingest_ttlpersists last-post unix per node;lotato statusshows Due. - Rename MeshForge-facing naming and unify Lotato branding in CLI, configuration, and source (follow-up to the Potato Mesh ingestor naming used in earlier tags).
- Debug logging: no compile-time
LOTATO_DEBUG; useconfig set lolog.verbose on|off(LoSettings, via the newlolog+loseriallibraries that back all lo* logging across ESP32 and nRF52).lotato statusshowsDebug: on|offfromLoLog::isVerbose(). - CLI: bare
lotatoprints the same help aslotato help(uselotato statusfor the WiFi / ingest snapshot). locommand+lomessage:Engine/Router/ArgSpec;Buffer+Queuefor chunked replies. Breaking: WiFi commands arewifi …(notlotato wifi …); scan iswifi scan.- Long Lotato replies: oversized replies go through the mesh FIFO or drip on USB serial;
wifi scanreturns one full list.
- Documentation refresh for Lotato usage and setup.
- MeshForge / flasher-oriented project configuration updates.
- Lotato branding (project and user-facing naming).
First tagged Lotato release, based on MeshCore repeater v1.14.1.
- Initial Potato Mesh / MeshEnvy ingestor firmware path (WiFi repeater ingest to a remote HTTP endpoint).
- Batch posting fixes for the ingest pipeline.
- Fix MeshCore platform reporting for this build.
- ESP32 CLI improvements: chunked serial replies to reduce blocking, larger reply buffer, WiFi failover with rotation across known networks, and related serial output handling.
- Asynchronous handling for certain CLI command responses.
- HTTPS / TLS certificate handling fixes for outbound ingest.
