Repository navigation
NSPanel Pro proximity sensor not reacting #980
Description
Prerequisites checklist
- I am running the latest Kiosk Satellite release (check Settings or the About tab of the remote admin against the latest GitHub release).
- I have searched the existing issues and this has not been reported already.
- If the issue is voice related, my Assist pipeline works on its own (e.g. via the Assist dialog in the HA sidebar).
Area affected
Screensaver (clock, photos, Immich, media)
Describe the bug
On NSPanel Pro the proximity sensor detection is not working - despite proximity detection being on, remote admin showing that in fact sensor named Proximity is available, it does not seem to work - no reaction whatsoever when hand is waved in front of screen during screensaver.
Expected behavior
Proximity sensor working on NSPanel pro as intended
Steps to reproduce
No response
Environment
- Kiosk Satellite version: latest
- Device (exact model, e.g. Fire HD 8 2020, Echo Show 5 2nd gen, Galaxy Tab A8): NSPanel Pro
- Android version (and OS flavor if not stock, e.g. Fire OS, LineageOS): Android 8.1.0 (SDK 27)
- Home Assistant version: 2026.10.1
- Voice Satellite integration version (only if you use it instead of the built-in Voice Satellite):
- Relevant settings (wake word on/off, WebSocket filter on/off, screensaver mode, Bluetooth devices in use):
- Screensaver ON
- Screensaver proximity detection ON
App logs
Nothing relevant in logs, after enabling proximity it just reports resting far
08:46:36 proximity: sensor on (Proximity sensor)
08:46:36 command: getBrightness [esphome]
08:46:36 proximity: resting far
08:46:37 command: screenshot [remote admin]
08:46:37 command: isScreenOn [browser]
08:46:42 command: screenOn [remote admin]
08:46:42 screen: screen on (app)
08:46:42 command: isScreenOn [esphome]
Web console logs (required for dashboard issues)
Logcat (required for crashes, freezes, white screens, or restarts)
Activity
jxlarrea commentedon Oct 14, 2026
Hello,
Please download a separate sensor app and verify that the Proximity sensor is actually working. In many devices the sensor is listed but is either only accessible by OEM apps or doesn't work at all.
pnaklicki commentedon Oct 14, 2026
@jxlarrea in fact it works in another app - NSPanel pro tools (https://github.com/seaky/nspanel_pro_tools_apk)
jxlarrea commentedon Oct 14, 2026
Kiosk Satellite reads proximity the way Android defines it: a distance where a lower number means closer. From what I can find, the NSPanel Pro reports it the other way around. Depending on the firmware, the value is either a raw number around 1000 to 4000 that rises as something gets closer, or a simple 0/1 where 1 means detected. NSPanel Pro Tools triggers when the value goes above a threshold, which is why it works there. In your log the panel's reading with nothing in front of it already counts as "far". Since the value only goes up as you get closer, it never crosses into "near".
To handle this properly I need to see the actual numbers your panel sends. Could you grab the following?
1. NSPanel Pro Tools sensor tab
Write down the live proximity value:
Please also include your panel's firmware version and whether it's the 86 or the 120 model.
2. What the sensor reports to Kiosk Satellite
Run this from any machine on your network, replacing the IP and admin password:
This returns the range and resolution the sensor driver advertises.
3. Optional, if you have adb
Turn on the screensaver so Kiosk Satellite is listening to the sensor. Walk up to the panel a few times from about 20 cm away, then run:
That shows the last readings Android delivered from the proximity sensor.
The next release will also include the sensor's range, resolution and raw readings in the log, so future reports like this will show this information on their own.
Log the proximity sensor's range, resolution and raw readings to diag…
pnaklicki commentedon Oct 14, 2026
@jxlarrea
Sensor reports about 50 (jumping 48-50) when nothing is in front of the panel. At about 10cm, sensor reports 150 and at 20cm it reports 70
Command returns following data:
{"ok":true,"data":{"supported":true,"name":"Proximity sensor","vendor":"The Android Open Source Project","maximumRange":9.0,"resolution":9.0}}
It was hard to capture sensor events since it updates often, but there are 10 events where I was waving at 20 cm, 10cm and closer
Recent Sensor events:
Light sensor: last 10 events
1 (ts=3779.864264175, wall=11:47:02.577) 23617.00, 0.00, 0.00,
2 (ts=3780.065929820, wall=11:47:02.778) 21865.00, 0.00, 0.00,
3 (ts=3780.264338132, wall=11:47:02.977) 22570.00, 0.00, 0.00,
4 (ts=3780.464765360, wall=11:47:03.177) 17964.00, 0.00, 0.00,
5 (ts=3780.666173172, wall=11:47:03.379) 24232.00, 0.00, 0.00,
6 (ts=3780.867839401, wall=11:47:03.580) 24411.00, 0.00, 0.00,
7 (ts=3781.067700504, wall=11:47:03.780) 24102.00, 0.00, 0.00,
8 (ts=3781.269211858, wall=11:47:03.982) 6416.00, 0.00, 0.00,
9 (ts=3781.468104628, wall=11:47:04.180) 3759.00, 0.00, 0.00,
10 (ts=3781.670503232, wall=11:47:04.383) 3334.00, 0.00, 0.00,
Proximity sensor: last 10 events
1 (ts=1791971223.600313187, wall=11:47:03.600) 53.00, 0.00, 0.00,
2 (ts=1791971223.690588951, wall=11:47:03.691) 63.00, 0.00, 0.00,
3 (ts=1791971223.814170837, wall=11:47:03.815) 92.00, 0.00, 0.00,
4 (ts=1791971223.907270908, wall=11:47:03.908) 150.00, 0.00, 0.00,
5 (ts=1791971224.031141996, wall=11:47:04.031) 272.00, 0.00, 0.00,
6 (ts=1791971224.120490074, wall=11:47:04.121) 463.00, 0.00, 0.00,
7 (ts=1791971224.210422039, wall=11:47:04.210) 668.00, 0.00, 0.00,
8 (ts=1791971224.331645966, wall=11:47:04.332) 789.00, 0.00, 0.00,
9 (ts=1791971224.420487881, wall=11:47:04.421) 675.00, 0.00, 0.00,
10 (ts=1791971224.540655136, wall=11:47:04.541) 531.00, 0.00, 0.00,
Active sensors:
Proximity sensor (handle=0x00000003, connections=1)
Light sensor (handle=0x00000004, connections=2)
Socket Buffer size = 39 events
WakeLock Status: not held
Mode : NORMAL
3 active connections
Connection Number: 0
Operating Mode: NORMAL
me.jxl.kiosk_satellite.LightSensor$attach$l$1 | WakeLockRefCount 0 | uid 10031 | cache size 0 | max cache size 0
Light sensor 0x00000004 | status: active | pending flush events 0
Connection Number: 1
Operating Mode: NORMAL
y0.a | WakeLockRefCount 0 | uid 10053 | cache size 0 | max cache size 0
Light sensor 0x00000004 | status: active | pending flush events 0
Connection Number: 2
Operating Mode: NORMAL
y0.c | WakeLockRefCount 0 | uid 10053 | cache size 0 | max cache size 0
Proximity sensor 0x00000003 | status: active | pending flush events 0
0 direct connections
Previous Registrations:
11:42:22 - 0x00000004 pid= 1370 uid=10053 package=y0.a
11:42:22 - 0x00000003 pid= 1370 uid=10053 package=y0.c
11:42:09 + 0x00000004 pid= 1370 uid=10053 package=y0.a samplingPeriod=200000us batchingPeriod=0us
11:42:09 + 0x00000003 pid= 1370 uid=10053 package=y0.c samplingPeriod=200000us batchingPeriod=0us
11:41:52 - 0x00000004 pid= 1370 uid=10053 package=y0.a
11:41:52 - 0x00000003 pid= 1370 uid=10053 package=y0.c
11:41:32 + 0x00000004 pid= 1370 uid=10053 package=y0.a samplingPeriod=200000us batchingPeriod=0us
11:41:32 + 0x00000003 pid= 1370 uid=10053 package=y0.c samplingPeriod=200000us batchingPeriod=0us
11:33:24 - 0x00000004 pid= 1370 uid=10053 package=y0.a
11:33:24 - 0x00000003 pid= 1370 uid=10053 package=y0.c
11:33:08 + 0x00000004 pid= 1370 uid=10053 package=y0.a samplingPeriod=200000us batchingPeriod=0us
11:33:08 + 0x00000003 pid= 1370 uid=10053 package=y0.c samplingPeriod=200000us batchingPeriod=0us
11:33:08 - 0x00000004 pid= 1370 uid=10053 package=y0.a
11:33:08 - 0x00000003 pid= 1370 uid=10053 package=y0.c
11:32:52 + 0x00000004 pid= 1370 uid=10053 package=y0.a samplingPeriod=200000us batchingPeriod=0us
11:32:52 + 0x00000003 pid= 1370 uid=10053 package=y0.c samplingPeriod=200000us batchingPeriod=0us
11:32:51 - 0x00000004 pid= 1370 uid=10053 package=y0.a
jxlarrea commentedon Oct 14, 2026
Could you please install this test version and let me know how it behaves? https://drive.google.com/file/d/1mCtfMdjs6zTnlOolaZHVPyyD6Vyy-367/view?usp=sharing
Read the NSPanel Pro's raw proximity counts, which rise as something …
pnaklicki commentedon Oct 14, 2026
@jxlarrea it seems to be working now - when screensaver is on it immediately dismisses it, but when screen turns off it needs a few seconds before starting working - the proximity does not register for some seconds (sometimes 3, sometimes 30)
jxlarrea commentedon Oct 14, 2026
Good to hear the screensaver dismisses now. The delay after the screen turns off is something I need to look at more closely, and the test build you're running already logs what I need to see it.
Could you grab the following?
1. The app log around the delay
The
proximity:lines now include the raw sensor reading and a timestamp. That shows whether the reading changes when the screen goes dark or the sensor stops reporting for a while.2. Two settings
pnaklicki commentedon Oct 14, 2026
Here are the logs around delay:
12:47:36 screensaver: start (plugin:robot-eyes:robot_eyes)
12:47:36 broadcasts: SCREENSAVER_STARTED
12:47:36 proximity: sensor on (Proximity sensor, range 9.0, resolution 9.0)
12:47:36 proximity: resting far (47.0)
12:47:36 proximity: near (552.0)
12:47:37 proximity: far (46.0)
12:47:37 plugin:proximity-wake: Event 49: approach detected. Waking screen...
12:47:37 command: stopScreensaver [plugin:proximity-wake]
12:47:37 screensaver: stop
12:47:37 command: unfreezeRendering [screensaver]
12:47:37 command: leaveScreensaver {nowPlaying: false} [screensaver]
12:47:37 command: screenOn [screensaver]
12:47:37 screen: screen on (app)
12:47:37 command: keepScreenAwake {enabled: false} [screensaver]
12:47:37 command: isScreenOn [esphome]
12:47:37 command: getBrightness [esphome]
12:47:37 proximity: near (624.0)
12:47:37 proximity: far (48.0)
12:47:37 command: screenOn [screensaver]
12:47:37 broadcasts: SCREENSAVER_STOPPED
12:47:37 plugin:proximity-wake: stopScreensaver ok. Sending screenOn...
12:47:37 command: screenOn [plugin:proximity-wake]
12:47:37 plugin:proximity-wake: Event 50: approach ignored by cooldown (4 s left)
12:47:37 plugin:proximity-wake: Approach handled: screen woken (event 50).
12:47:37 proximity: near (459.0)
12:47:37 proximity: far (48.0)
12:47:37 plugin:proximity-wake: Event 51: approach ignored by cooldown (4 s left)
12:47:38 proximity: near (244.0)
12:47:38 plugin:proximity-wake: Event 52: approach ignored by cooldown (3 s left)
12:47:38 proximity: far (50.0)
12:47:38 command: screenshot [remote admin]
12:47:38 command: isScreenOn [browser]
12:47:40 browser: HA socket answered the resume ping; leaving it be
The keep CPU awake switch is on and the only when screen off is on, but turning it off does not change anything - logs show similar information.
jxlarrea commentedon Oct 14, 2026
The sensor side looks good in this log. Each wave reads well above the resting level and shows up within a second.
This log doesn't include the delay itself, though. The screen never turned off: the screensaver started at 12:47:36 and closed a second later. It was also your
proximity-wakeplugin that closed it. With Only when screen is off on, Kiosk Satellite ignores approaches while the screensaver is visible and only wakes the panel once the screen is dark.The plugin also reacts to proximity and has its own cooldown. Once the screen is off, both would respond to the same wave, which could be what causes the delay. To rule that out, could you run one more test?
proximity-wakeplugin.screen: screen offline.pnaklicki commentedon Oct 14, 2026
The logs does not show any event on proximity when the delay is active, only after some time (as you can see on logs about 27 seconds) events are flowing in. Since screen off message I was constantly waving in front of screen. Whats more sometimes proximity sensor jumps and app reports near (60) and far (47) immediately after each other. Also I think one time the sensor "froze" and was showing near still despite nothing being in front of the panel (I cleaned the sensor but that did not help, only disabling and enabling proximity fixed it). Maybe a good idea (if thats possible) would be to allow users to configure the value from sensor that app treats as near (similar to NSPanel Tools), so users could manually decide if they want proximity to work only up close or far away. Here are the logs
13:30:21 screen: screen off (app)
13:30:21 proximity: sensor off
13:30:21 command: isScreenOn [esphome]
13:30:21 command: getBrightness [esphome]
13:30:22 command: isScreenOn [screensaver]
13:30:48 command: keepScreenAwake {enabled: true} [screensaver]
13:30:48 screensaver: start (plugin:robot-eyes:robot_eyes)
13:30:48 broadcasts: SCREENSAVER_STARTED
13:30:48 proximity: sensor on (Proximity sensor, range 9.0, resolution 9.0)
13:30:48 proximity: resting far (46.0)
13:30:48 proximity: near (372.0)
13:30:49 proximity: far (47.0)
13:30:49 command: screenshot [remote admin]
13:30:49 command: isScreenOn [browser]
13:30:50 proximity: near (1036.0)
13:30:50 proximity: far (46.0)
13:30:51 proximity: near (447.0)
13:30:51 proximity: far (46.0)
13:30:53 proximity: near (629.0)
13:30:53 proximity: far (48.0)
13:30:54 proximity: near (232.0)
13:30:54 proximity: far (48.0)
13:31:03 command: getDeviceDetails [esphome]
13:31:03 command: getUptime [esphome]
13:31:03 command: getLightLevel [esphome]
jxlarrea commentedon Oct 14, 2026
The log explained the delay. At 13:30:21 the screen turned off while the dashboard was showing, not from inside the screensaver. With no screensaver running and the screen off, proximity isn't watched. Motion and face detection work the same way. The screensaver started 27 seconds later, but it assumed the screen was lit. With Only when screen is off on, it then ignored every approach, so the panel stayed dark. Your
proximity-wakeplugin was covering for this before.I fixed that along with the two sensor quirks you noticed:
One thing stays as it is: if the screen turns off from the dashboard, waving won't turn it back on until the screensaver has started. Detection only wakes a dark panel while the screensaver is running.
I'm holding off on a threshold setting for now. The automatic rise over the resting level should cover your panel without manual tuning.
Here's a new test build with these changes: https://drive.google.com/file/d/1dVVBncemEupmxrVkSYnJCdw76XyIB4eB/view?usp=sharing
Please keep the
proximity-wakeplugin disabled while testing so we know it's Kiosk Satellite waking the panel. If anything still looks off, the log will show it.Treat a screensaver that starts with the screen already off as dark f…
pnaklicki commentedon Oct 14, 2026
@jxlarrea thank you, after some testing it now seems to be working perfectly! Thanks again for your help!
pnaklicki commentedon Oct 18, 2026
@jxlarrea I notoced tofay that some nspanels report 0 at proximity when ntohing is in front - it semestr like 0 is somehow treated as near, because I keep getting message about proximity near (0.0) and far(3.0) all the time. Looks like 0 is treated as near where for nspanel it should be far
pnaklicki commentedon Oct 21, 2026
@jxlarrea ping
jxlarrea commentedon Oct 21, 2026
On those panels, Kiosk Satellite reads the sensor the same way as your first panel. Both report a range of 9 and a resolution of 9. The difference is the resting value. Your first panel rests around 47, and any reading above 18 switches it to raw values, where only a clear rise over the resting level counts as near. These panels rest at 0, so that switch never happens. Until it does, the sensor is read as a simple on/off flag where 0 means near, and every jump from 3 back to 0 counts as a new approach.
I can fix this, but I need to know how high the reading climbs on these panels before picking where the switch happens. On one of the panels that rests at 0, could you open the NSPanel Pro Tools sensor tab and write down the proximity value:
Please also include the firmware version and whether it's the 86 or the 120 model, the same as your first panel or different.
jxlarrea commentedon Oct 21, 2026
I don't need those readings anymore. I went through the NSPanel Pro firmware and found the cause.
Those panels report raw counts like your first panel. They just rest at 0 instead of around 47. Kiosk Satellite only switched to reading raw counts after a reading went above 18, so until then it read the sensor as a simple on/off flag where 0 means near. Every drop from 3 back to 0 counted as a new approach.
The fix is in the next release. On an NSPanel Pro, Kiosk Satellite now reads the raw count directly from the sensor's driver from the start. A reading has to rise at least 15 over the resting level to count as near, so blips to 3 are ignored. Your first panel uses the same path, and the NSPanel Pro 120 is covered too, since its firmware reports proximity the other way around.
The log now has a
source:line when the sensor turns on, the resting level on each near and far line, and a summary of the readings after 30 seconds and every 5 minutes. If any of your panels still wake on their own after updating, please post theproximity:lines from the Logs tab in the remote admin.Read the NSPanel Pro proximity sensor's raw count from its Sensortek …