core: Broadlink RM Mini 3: Failed to connect to device
Home Assistant release with the issue: 0.97.2
Last working Home Assistant release (if known): Potentially whatever release contained python-broadlink 0.10 (but perhaps not, see below)
Operating environment (Hass.io/Docker/Windows/etc.): Docker
Component/platform: Broadlink
Description of problem:
When calling the broadlink.learn service, the service does not appear to be called. The message “Failed to connect to device” is posted in the logs. The Broadlink device LED does not go white (for learning mode).
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
switch:
- platform: broadlink
host: '<my rm ip>'
mac: '<my rm mac>'
type: rm_mini
I’ve double checked both the IP and MAC and they are working elsewhere (see below).
Traceback (if applicable): None, just the error message above.
Additional information: From looking at the code, the message appears when the device fails the auth method. I tried the command line tool from the python-broadlink library and it failed in a similar way with the latest version (see mjg59/python-broadlink#274). I fixed the issue in the library by going back to initialising the AES objects on every call as per the last working version (see mjg59/python-broadlink#276).
The problem is that the issue persists in HASS even if I use my fixed version of the library. I installed my version inside my Docker container with:
pip install -U git+https://github.com/webworxshop/python-broadlink.git@fix-pyaes
…and then restarted HASS. Trying the broadlink.learn service results in the same message. A visual inspection of the broadlink module inside the container confirms it is the right code. I even added a print statement to it to make sure!
A tcpdump yields the following initial packet sent by HASS (MAC address redacted):
0x0000: 4500 00b4 0d24 4000 4011 1408 0a00 0282 E....$@.@.......
0x0010: 0a00 028c daa7 0050 00a0 19bf 5aa5 aa55 .......P....Z..U
0x0020: 5aa5 aa55 0000 0000 0000 0000 0000 0000 Z..U............
0x0030: 0000 0000 0000 0000 0000 0000 92f4 0000 ................
0x0040: 2a27 6500 2820 xxxx xxxx xxxx 0100 0000 *'e.(.p}.B......
0x0050: a1c3 0000 3764 6e3c bfbc 2a28 89fa d367 ....7dn<..*(...g
0x0060: 4314 02b3 9cb0 0bbc 5c6d 2b62 1a35 0a8e C.......\m+b.5..
0x0070: bad7 999a 641c 85e6 7612 e0e7 c23e a66f ....d...v....>.o
0x0080: 2615 1c64 d7c4 ad27 3486 8125 617e 2c34 &..d...'4..%a~,4
0x0090: fba6 a728 76a3 3669 46cf 871c e413 e51c ...(v.6iF.......
0x00a0: 1d6c 1596 d8a8 f96e 622b 9fa8 159f ba02 .l.....nb+......
0x00b0: f8ce 9778
The broadlink_cli tool with the working library version yields this initial packet:
0x0000: 4500 00b4 2976 4000 4011 f7b5 0a00 0282 E...)v@.@.......
0x0010: 0a00 028c b3db 0050 00a0 19bf 5aa5 aa55 .......P....Z..U
0x0020: 5aa5 aa55 0000 0000 0000 0000 0000 0000 Z..U............
0x0030: 0000 0000 0000 0000 0000 0000 f9f7 0000 ................
0x0040: 2a27 6500 5df2 xxxx xxxx xxxx 0000 0000 *'e.].p}.B......
0x0050: a1c3 0000 4534 52e7 f92e da95 8344 9308 ....E4R......D..
0x0060: 35ef 9a6d fb69 2dc3 70b9 0443 ac5c d63f 5..m.i-.p..C.\.?
0x0070: bb53 adfa 0881 4ca7 f8cf 4171 0032 8e57 .S....L...Aq.2.W
0x0080: 0c3b 86c9 4d05 7084 49a3 89e2 9ae1 0454 .;..M.p.I......T
0x0090: 36a0 5bdd dc02 c161 af13 25e8 7e19 b0f7 6.[....a..%.~...
0x00a0: d1ce 068d e51b 6191 5687 6d33 8cff 3b99 ......a.V.m3..;.
0x00b0: 1e40 cdb1
As you can see the encrypted payload part of the packet is completely different! For some reason HASS is still sending a mangled packet. I’m completely stumped as to why, since it is using the fixed library version.
Hopefully someone else has more idea than me! Please let me know if I can provide any more information.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 7
- Comments: 20 (3 by maintainers)
I figured out how to fix this and hoping will be helpful for you all: env: HomeAssistant installed in
venv, Rpi 1, RM mini3 latest FW.I have manually installed
openssl-1.1.1, linkedlibssl.so.1.1andlibcrypto.so.1.1files in/usr/lib/arm-linux-gnueabihf/ReinstalledcryptographyEdited
lib/python3.7/site-packages/homeassistant/components/broadlink/__init__.pyas specified in PR made by @bmfurtado https://github.com/home-assistant/home-assistant/pull/27341And after a full restart I got everything working: learn, send and other features.
@brianpierson2020 Thanks for the suggestion.
We are using python-broadlink. It is written in Python and supports a wider range of devices.
But I found the broadlinkgo an interesting project. I can contribute by adding support for the RM Mini 3 0x5f36 and RM4 series, as long as @rob121 adopts the MIT license.
Not sure if it’s of any value here as I am unaware of the current HA implementation but I implemented a custom switch that sends a simple request to an local API that supports Broadlink IR devices very well. I just made a Docker image available to easily deploy it:
https://github.com/brianpierson2020/broadlinkgo-docker
Since it’s an API and in Docker now, it should make it really easy to integrate with HA for other users.
I use this in combination with my TP link Energy Monitoring where I determine the current Watt usage of the IR controlled devices so see if they are on or off. This way I can use triggers and toggle switches for an otherwise dumb IR. 😃 If you want I can publish those custom switches and sensors later too.
Many different problems are being mentioned in this issue.
@webworxshop Here is a detailed view of your packets. Make sure to disable line wrap to get a good view of it. The packets are exactly the same, except for the device IDs. I couldn’t decrypt the first packet because I don’t have the key, but look at the payload checksum. Same size, same content. Even so, the information you sent is incomplete. To understand the problem, I need you to run this script, learn a code and send me the file debug.txt.
Related issues: RM Mini 3 0x5f36 and RM4 series are solved and waiting to be merged.