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

**URL:** <https://forum.sienci.com/t/sender-edge-on-headless-pi-lessons-learned-wireless-control-safari-cache/26166>\
**Category:** 🐛 Bug\
**Created:** [April 14, 2026, 11:38am UTC](https://forum.sienci.com/t/sender-edge-on-headless-pi-lessons-learned-wireless-control-safari-cache/26166 "2026-04-14T11:38:30Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![rathbungs](https://forum.sienci.com/letter_avatar_proxy/v4/letter/r/839c29/32.png) [@rathbungs](https://forum.sienci.com/u/rathbungs)\
**Post date:** [April 14, 2026, 11:38am UTC](https://forum.sienci.com/t/sender-edge-on-headless-pi-lessons-learned-wireless-control-safari-cache/26166/1 "2026-04-14T11:38:30Z")

</div>

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**

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

3. **Launch method mattered (desktop vs systemd)**

**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:

**Suggestions / feedback**

- It might help to:

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.

---

<div class="post-metadata">

**Author:** ![DavidB](https://forum.sienci.com/letter_avatar_proxy/v4/letter/d/76d3ee/32.png) [@DavidB](https://forum.sienci.com/u/DavidB)\
**Post date:** [April 14, 2026, 1:35pm UTC](https://forum.sienci.com/t/sender-edge-on-headless-pi-lessons-learned-wireless-control-safari-cache/26166/2 "2026-04-14T13:35:01Z")

</div>

> [@rathbungs](#):
>
> 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.

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

Otherwise nice writeup!

---

<div class="post-metadata">

**Author:** ![rathbungs](https://forum.sienci.com/letter_avatar_proxy/v4/letter/r/839c29/32.png) [@rathbungs](https://forum.sienci.com/u/rathbungs)\
**Post date:** [April 15, 2026, 12:22am UTC](https://forum.sienci.com/t/sender-edge-on-headless-pi-lessons-learned-wireless-control-safari-cache/26166/3 "2026-04-15T00:22:43Z")

</div>

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.