Fix Linptech ES3 sensor motion clear delay (#1481) #1482
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The ES3 sensor sends two types of frames when motion clears: 1. An immediate data-only frame (currently ignored) 2. A delayed frame with explicit motion: 0 (~2 min later) This fix treats ES3 data-only frames (with data: True but no motion or illuminance data) as implicit motion clear events, allowing the motion sensor to clear immediately instead of waiting 2 minutes. Fixes custom-components#1481
ES3 sends object type 0x484e with occupancy=0 for immediate motion clear,
but this was being ignored (returning empty dict). Now it returns
{"motion": 0} specifically for ES3 devices to enable immediate motion
clear instead of waiting 2 minutes.
- Modified obj484e to accept device_type parameter
- Added 0x484e to the list of objects that receive device_type
- ES3 now gets motion=0 when occupancy=0, other devices unchanged
Fixes custom-components#1481
|
Thanks for this PR. Some test seem to fail, these need to be fixed first. |
Update test_linptech_ES3_data_only_motion_clear to use actual BLE advertisement data from a real ES3 device instead of simulated data. This ensures the test properly validates the motion=0 behavior when the ES3 sends encrypted frames with occupancy status 0. - Use real MAC address: A4:C1:38:A4:88:8A - Use real encryption key from the device - Use actual BLE packet captured from device logs - Update expected packet ID to match real data 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Correct the expected RSSI value from -58 to -83 to match the actual signal strength in the test data. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This reverts commit cccec03.
|
Apologies, the test file was created with an inconsistent data set. Could you run the test again with the latest commit? |
Minor formatting fix to remove unnecessary blank line in parse_xiaomi function.
Set default reset_timer to 0 for ES3 devices to prevent motion state from being incorrectly cleared by the timer. ES3 devices handle motion clear through their own occupancy status messages.
Ernst79
approved these changes
Jul 11, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the 2-minute delay for Linptech ES3 motion sensors to report motion clear status.
Problem
The Linptech ES3 sensor sends two different frames when motion clears:
0x484e(occupancy=0)motion: 0(~2 minutes later)The immediate frame was being ignored because
obj484ereturned an empty dict for occupancy=0,causing the motion sensor to remain in "detected" state for ~2 minutes until the second frame
arrived.
Solution
Modified the
obj484ehandler to return{"motion": 0}specifically for ES3 devices whenoccupancy=0, while preserving the original behavior (empty dict) for other devices that rely on
Home Assistant's motion timer.
Changes
device_typeparameter toobj484efunction0x484eto the list of object type codes that receive device_typeTesting
0x484eare unaffectedFixes #1481