jxlarrea/kiosk-satellite 2026.8.79

on GitHub

What's new in Kiosk Satellite 2026.8.79

Face detection wakes the screen only when someone actually looks at the kiosk, the Wi-Fi MAC address can be typed in where Android refuses to reveal it, and old GPUs that crash-looped the app the moment the dashboard appeared now draw it another way.

Added: Face detection for the screensaver (#304)

• A new Dismiss on face switch, on its own Face Detection page under Screensaver, wakes the screen only when someone looks at the kiosk: a person walking through the room leaves the screensaver up, and the dashboard appears when they turn to the screen, the feature Fully Kiosk calls face detection.
• It is detection, not recognition: a small on-device model notices that a face is looking at the camera and nothing more, nothing is identified, stored or sent anywhere, and the camera runs only during the screensaver, exactly like Dismiss on motion.
• A Face sensitivity slider sets how close the face has to be, from right at the screen to as far as the camera can make one out, and Postpone screensaver on face extends it the way the motion one does: someone looking at the kiosk keeps resetting the idle timer, at the cost of the camera and the detector running permanently.
• The detector is built for the low-powered devices most kiosks are: the motion analyzer's grid decides when there is anything to look at, so the model runs only while something moved, a face was recently in view or the camera just opened, at most twice a second on a single core and slower where a run costs more, and an empty room costs no inference at all.
• Two rules apply: Dismiss on motion takes precedence, so with both on the motion switch owns the wake-up and the page says so; and faces need light, which is why the screensaver schedule gains a Dismiss on face override next to the motion one, so a daytime entry can wake on faces while an evening entry switches to motion for the dark hours.
• The switch is exposed to Home Assistant as Screensaver face detection over MQTT and ESPHome, the remote admin's Device page reports whether face detection is active, and pages get a kiosksatellite:face event and a getFaceEnabled() read next to the motion ones.

Added: Type in the Wi-Fi MAC address where Android hides it (#300)

• Use real Wi-Fi MAC address only works where the app can read the address, Android 9 and older or a device-owner install, and everywhere else the switch could only say so and leave the generated identity in place, keeping the kiosk apart from the entries the router and network integrations hold for the same hardware.
• The status row under the switch now offers a Spoof Wi-Fi MAC address field whenever the hardware read fails: type in the address from Android's About > Status page or the router's client list and the kiosk reports it to Home Assistant over ESPHome and MQTT alike, the same as a read one, so the device entries merge as intended.
• The field accepts the usual spellings and refuses anything that could not be an interface address, a working hardware read always wins over a typed one, and the same caveat as the switch applies: a new address is a new device to Home Assistant. Both rows live on a new Advanced settings page at the end of the ESPHome settings.
• In the remote admin UI the status row now appears the moment the switch is flipped, instead of after a page reload, and goes away when it is flipped off.

Fixed: Launch loop on old GPUs (#302)

• On Android 9 and older the app hands the dashboard to Android and takes its own frames back through a buffer that asks for one pixel format without being able to tell the driver what to produce, so a GPU that answers in a different one (the Mali in the 2014 Galaxy Note 10.1) makes that read fail and takes the whole app down. The result was a launch loop that started right after the setup wizard, seconds into every launch, with no way back into the app.
• The app now puts the question to the GPU once, before it draws anything: it repeats the exact frame the renderer would draw, reads it back the same way, and a driver that refuses gets the dashboard drawn into a texture instead, which every GPU handles.
• Hardware the native path works on is untouched, since that path is the faster of the two, and the choice is visible and reversible as a new Legacy WebView renderer switch in the Device settings, next to Legacy renderer; it takes effect on the next app start.

Fixed: Screen on that left the panel dark (#305)

• The command had one route, a wake lock flagged to wake the device, which some devices accept and then leave the display dark (reported on a Galaxy Tab S7+), while the app logged "screen on" over a black panel and every mirror of the screen state, the remote admin's tile and the Home Assistant entities, said lit.
• The app now looks at the panel a moment after the wake lock and, when it stayed dark, wakes it the way alarm and call screens do, through an Activity the system lights the panel for; that route needs the Display over other apps permission on Android 10 and newer.
• Both attempts are logged, so a device where neither works says so in the Logs instead of claiming success, and the reported screen state follows what the panel actually did. To tell the two routes apart, screenOn over the remote API accepts {"path": "activity"} to try the second one on its own.

Changed: Remote admin quick controls that follow the device (#298)

• The screen, screensaver and camera view controls used to be a fixed row of buttons, two of them for the screen and none to start the screensaver from there; each is now one tile that reads by what the device is doing: Screen off while the panel is lit and Screen on once it is dark, Start screensaver or Dismiss screensaver, and Show camera view or Dismiss camera view.
• The tiles are seeded from the device's state when the page connects and flip live as the device reports changes, whether the change came from this page, a person at the panel, motion, an automation or the idle timer, so a tile never offers an action that no longer applies, and the dashboard screenshot refreshes a second after each such change so the picture keeps up with the tiles.
• Show camera view shows the only configured view outright, offers a pick when there are several, and says where to add cameras when no view has any. The remote API gains the matching reads, isScreensaverActive and getCameraViewState, and the state snapshot (GET /api/info and the WebSocket state message) now carries screenOn, screensaverActive and cameraView.

Fixed: Hardware sensor detail missing over ESPHome (#213)

• The Device, IPv4 address and IPv6 address sensors exist on both integrations, but the ESPHome protocol has no attributes at all, so over ESPHome the Android version, the OEM build and the per-interface address lists were simply not there.
• Each is now an entity of its own: Android version and Android build next to Device, and IPv4 addresses by interface and IPv6 addresses by interface next to the address sensors, each reading wlan0: 192.168.1.5; eth0: 10.0.3.2, so an automation can tell whether the kiosk is on its wired or its wireless NIC.
• The ESPHome address sensors also gained the two habits their MQTT twins already had: a routable IPv6 address leads over the link-local fe80:: one, and both are re-checked moments after a network change instead of waiting for the minute poll.