Add support for Broadlink RM Max (0xAF8B) - #838
Open
amasolov wants to merge 1 commit into
Open
Conversation
|
This really is a one liner, can someone please hit merge? |
|
I tested this change and it detects the device but wants me to unlock it from the manufacturer's app but there is no option to do that in the app. |
|
Same. I couldn't find a way to unlock it. Even blocking the device's access to internet didn't work, I guess it locks itself immediately. |
amasolov
force-pushed
the
add-rm-max-support
branch
from
July 15, 2026 22:25
7aeb3c7 to
02796c8
Compare
|
Hi! I've been testing an RM Max extensively and noticed something that may help. My device: PID: 0x8baf0000 Discovery works correctly, but device.auth() immediately fails. The device responds with a short error packet and never returns a session ID or AES key. I noticed your PR only changes the device mapping (rm4pro → rmpro) and doesn't modify auth(). Did device.auth() succeed on your RM Max without any local modifications? If so, could you share: firmware version, |
Place in the rmpro class which uses <I framing for IR learn/send commands, matching the device's actual protocol. The rm4pro class uses <HI framing which causes "device is locked" errors on this hardware. Co-authored-by: Cursor <cursoragent@cursor.com>
amasolov
force-pushed
the
add-rm-max-support
branch
from
July 26, 2026 23:37
02796c8 to
de95700
Compare
This was referenced Sep 4, 2026
DAB-LABS
added a commit
to DAB-LABS/python-broadlink
that referenced
this pull request
Sep 6, 2026
A fifth review, of 1.0.4, found one more place where the connected socket could surface an error the original library never raised, and made a fair case that the capture window claim was more machinery than the job needed. This fixes the first, simplifies the second, and takes two small items along. No change to the wire format or the public API. Tested on 3.13 and 3.14, 272 tests under -X dev with ResourceWarning as an error, oracle fixtures unchanged, and live against an RM4 Pro. Technical details: - EHOSTUNREACH and Windows's ConnectionResetError are treated as silence in _exchange, as ECONNREFUSED already was: logged, the timeout decides, the socket is dropped afterwards. Home Assistant tolerates a timeout for a few polls but marks a device unavailable on the first OSError, and the original's unconnected socket never saw any of these. Measured on the bench before changing anything: neither an on-link address with no host nor an off-subnet one produced the ICMP here, so this is insurance for networks that do. - The window claim is a flag set on first iteration and cleared in the generator's finally (so asyncio's finalizer releases a dropped window), replacing the weakref and ag_frame inspection. Same behaviour, same tests; CaptureInProgressError now always comes from the first iteration. - discover() closes the xdiscover() generator it drains. - A comment explains why the RM Max sits in rmpro (upstream mjg59#838). - README: a device belongs to the event loop it first talks on. - Version 1.0.5.
DAB-LABS
added a commit
to DAB-LABS/python-broadlink
that referenced
this pull request
Sep 6, 2026
A sixth review, of 1.0.5, found no defect in the code. This takes its small
items. No change to the wire format or the public API. Tested on 3.13 and
3.14, 274 tests under -X dev with ResourceWarning as an error, oracle
fixtures unchanged, and live against an RM4 Pro.
Technical details:
- A NetworkTimeoutError or EndpointClosedError during the library's own
re-authentication propagates instead of being swallowed in favour of
the device's original expired-key reply, so a network failure is
reported as one.
- _open_endpoint binds to ("0.0.0.0", 0) when neither address is given
(discovery, ping, setup), for the proactor loop on Windows.
- The RM Max comment and the 1.0.0 changelog entry say only what upstream
mjg59#838 showed: mapping per its diff, testers reported "locked" on auth,
listed as reported rather than confirmed.
- The undecodable-capture message is debug, not warning.
- _capture_rf_loop closes its inner generator with aclosing.
- Version 1.0.6.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Context
The Broadlink RM Max is the successor to the RM4 Pro, featuring IR and RF 433MHz capabilities. It is currently not recognized by the library, reporting as "Unsupported device: 0xAF8B" in Home Assistant.
This is a highly requested addition — see #829 with 20+ community members requesting support.
Proposed change
Add device type
0xAF8Bto therm4proclass mapping. The RM Max uses the same protocol as the RM4 Pro (confirmed by testing IR learning and sending on a physical device).Type of change
Additional information
Checklist