Kaj SchittecatandClaude Opus 5
a6c447e7d7
There was no way for anyone but me to put a self-built wadamesh on a Tanmatsu. The repo carried tanmatsu/build.sh and nothing that could install what it built: the AppFS writer lived only on my machine, so a fresh clone produced a binary and no path onto the device. Anyone trying would land on `idf.py flash`, which replaces the launcher OS. tanmatsu/tools/ now carries the loop, generalised out of my local copy: fetch-appfs.sh one-time, clones badge.team's esp32-component-appfs dump-pristine.sh one-time, dumps YOUR device's AppFS partition as the baseline tan_deploy.py builds the write-images and works out the changed sectors tan_flash.sh detects the P4, writes app then metadata, verifies the commit sermon.py non-resetting serial monitor Three things had to change before this could work for anybody else. Absolute paths to my checkout are gone. The hardcoded MAC of MY Tanmatsu is replaced by detecting whichever port answers as an ESP32-P4, which is also more robust since the board exposes two ports whose names move between replugs. And tan_flash.sh no longer invokes tan_deploy.py twice: the second run would have read the metadata the first had just written and bumped the version an extra time. appfs.py is deliberately NOT vendored. It is badge.team's and the copy in circulation has no licence header, so it is cloned instead. dev_appfs.bin is not committed either: it is 8 MB and device-specific, and using someone else's dump risks overwriting apps you have, since the deploy writes only what differs from it. Both are gitignored. Written up in TANMATSU_SIDELOAD.md and as a page on the site, linked from the user guide, the homepage resources section and the README. The guide leads with the model rather than the commands, because the failure that matters is not a typo, it is not knowing that this board runs wadamesh as an app under a launcher and that flashing it normally destroys that launcher. Not re-verified on hardware: the tooling is the same loop that has been deploying to my Tanmatsu, with the paths and device detection generalised. The first person to run it on another machine is the real test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
wadamesh.com infrastructure
Distribution stack for wadamesh: a VPS nginx origin behind Cloudflare.
tiles.wadamesh.com →CF (HTTP, edge-cached) → nginx → OpenStreetMap / OpenTopoMap
firmware.wadamesh.com →CF (cache bins) → nginx → /srv/wadamesh/firmware
flasher.wadamesh.com →CF (HTTPS) → web flasher (TODO — see below)
wadamesh.com →CF (HTTPS) → landing page (later)
Map tile styles. The default /{z}/{x}/{y}.jpg route serves OpenStreetMap
(the firmware default). An opt-in OpenTopoMap topographic style is served from
/opentopo/{z}/{x}/{y}.jpg (explicit OSM alias at /osm/...); the device requests
it only when the user enables Map → Options → Topographic map. Legal: OpenTopoMap
map tiles are © OpenTopoMap (CC-BY-SA) over © OpenStreetMap contributors
(ODbL) + SRTM — the touch UI shows that attribution when topo is active, and the
14-day disk cache keeps each tile hitting OpenTopoMap at most once per fortnight
(their tile-usage policy asks for a contactable UA + caching, both of which the
transcode service provides). Deploying the topo routes = update
tiles.wadamesh.com.conf + tile-transcode.py, then
systemctl restart wadamesh-tile-transcode && nginx -t && systemctl reload nginx
and purge the Cloudflare cache for tiles.wadamesh.com/opentopo/*.
The firmware fetches tiles + the update-check over plain HTTP (on-device HTTPS isn't viable — mbedTLS needs ~30 KB heap, only ~5 KB is free post-Wi-Fi), so the tile + firmware hosts must stay reachable over HTTP. Cloudflare provides the edge cache, HTTPS for the flasher, and hides the origin IP (so no IP lives in this repo or the firmware).
1. VPS (origin)
sudo apt install nginx
sudo mkdir -p /srv/wadamesh/firmware/releases/TOUCH /var/cache/nginx/wadamesh-tiles
sudo cp deploy/nginx/tiles.wadamesh.com.conf /etc/nginx/sites-available/
sudo cp deploy/nginx/firmware.wadamesh.com.conf /etc/nginx/sites-available/
sudo ln -s /etc/nginx/sites-available/tiles.wadamesh.com.conf /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/firmware.wadamesh.com.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
2. Cloudflare
- DNS:
A/AAAArecords fortiles,firmware,flasher,@→ the VPS IP, all Proxied (orange cloud). - SSL/TLS: mode Flexible (CF↔origin HTTP) is enough since the origin is
HTTP-only. Do NOT enable "Always Use HTTPS" on
tiles.orfirmware.— the firmware needs plain HTTP there. - Cache Rules:
tiles.wadamesh.com/*→ Eligible for cache, Edge TTL ~14d.firmware.wadamesh.com/releases/*/*.bin→ cache, Edge TTL ~1d.firmware.wadamesh.com/releases/TOUCH(the listing) → short TTL (~60s) or Bypass, so new releases appear promptly.
3. Publishing a release
From a wadamesh checkout (builds both boards, refreshes the listing, rsyncs up):
WADAMESH_VPS=user@your-vps scripts/release.sh beta_2
The on-device check GETs http://firmware.wadamesh.com/releases/TOUCH, finds the
highest beta_<N>, and (once OTA-over-Wi-Fi is re-enabled) pulls
…/releases/TOUCH/beta_<N>/<board>.bin.
Done
- Web flasher ✅ at
flasher.wadamesh.com—deploy/flasher/(esp-web-tools / Web Serial, board picker, manifests pointing at the rolling/latest/merged bins;release.shrefreshes/latest/each publish). - Apex
wadamesh.com301-redirects to the flasher — activate by pointing thewadamesh.comA record at the VPS in Cloudflare (it's still on the parking IP).
TODO before public launch
- Re-enable OTA-over-Wi-Fi in the firmware (currently it version-checks then defers to manual flashing).
- Flip
wadameshrepo public = launch. - Decide tile-proxy sharing: dedicated
tiles.wadamesh.com(this config) vs reusing the meshcomod proxy.
Never commit the VPS IP, SSH keys, or
WADAMESH_VPS. Cloudflare fronts the origin; the deploy target is supplied via the environment at publish time.