Sender Edge on headless Pi – lessons learned (Wireless Control + Safari cache)

gSender 🐛 Bug
1

I wanted to share a recent experience getting gSender Edge 1.6.0‑5 running reliably on a Raspberry Pi in a headless configuration, in case it helps others or informs future docs.

Setup

  • Raspberry Pi running 64‑bit OS

  • Initially used the AppImage, later switched to the .deb installed under /opt/gSender_Edge

  • Remote access from macOS via Safari to http://cncpi.local:8000

  • GRBL controller on USB

What I saw

  • With a monitor/keyboard on the Pi, gSender could see and connect to the USB GRBL device without issues.

  • From Safari on my Mac, the gSender web UI would load, but it showed no USB devices and could not connect, even though the Pi itself was talking to the controller just fine.

  • At one point, the Pi behaved correctly headless in the past, which added to the confusion.

Root causes I eventually uncovered

  1. Wireless Control was disabled in the new /opt install

    • The original AppImage instance had Wireless Control enabled, so cncpi.local:8000 was serving a live backend.

    • After switching to the .deb install, Wireless Control was off by default, so the new gSender instance wasn’t exposing a remote endpoint even though the local GUI worked.

  2. Safari was serving a cached copy of the old gSender page

    • Safari happily showed a cached version of the remote UI for cncpi.local:8000 even when the backend had changed or wasn’t actually reachable.

    • That produced a very misleading state: the UI “looked” fine, but underneath there was no real backend, so no devices appeared.

    • A hard reload (Command‑R) would have forced Safari to revalidate and would have exposed the real connectivity problem much earlier.

  3. Launch method mattered (desktop vs systemd)

    • I ended up standardizing on a systemd service that runs /opt/gSender_Edge/gsender -H 0.0.0.0 -p 8000 --remote true at boot as my Pi user, with no need for a desktop login.

    • Once that was in place and Wireless Control was enabled, the behavior became predictable and survives reboots.

Current working configuration

  • gSender installed from the .deb in /opt/gSender_Edge

  • gsender.service systemd unit launches it at boot (headless)

  • Wireless Control enabled; remote access via http://<Pi-IP>:8000

  • Logs:

    • Service: journalctl -u gsender.service -b

    • App: ~/.config/gSender/logs/main.log

Suggestions / feedback

  • It might help to:

    • Make it very obvious in the UI when Wireless Control is disabled or when there is no active backend for the page the browser has loaded.

    • Add an explicit headless Pi + systemd example to the docs for the .deb install.

    • Maybe note in the docs that browser caching (especially Safari) can show a stale gSender page; a hard reload can save a lot of debugging time.

I don’t think any of this is a “bug” in gSender per se; most of the confusion came from switching install methods, Wireless Control defaults, and browser caching. But having a canonical headless‑Pi recipe and a bit more feedback in the UI would help folks avoid the rabbit hole I went down.

2

That’s an issue with gSender not to indicate the page needs reloaded or to tell browsers not to cache it.

Otherwise nice writeup!

3

One additional UX note: when the backend at cncpi.local:8000 isn’t actually running, both Safari and Chrome still show a cached copy of the gSender UI. The page “looks” normal but silently fails all API calls, which is very confusing in a headless setup. It would help a lot if the remote UI surfaced a clear “backend not reachable / using cached UI only” message whenever initial API calls or WebSocket connections fail, perhaps with a hint to refresh the page or check that Wireless Control is enabled.