-
Notifications
You must be signed in to change notification settings - Fork 478
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for 0x5f36 devices and RM4 series #317
Conversation
This type of device requires a header in the payload. The rest is the same.
Please do not merge yet. I'm gonna do a final test. |
I just found out that this device uses a different header for sending codes. This update addresses this issue.
Everything is working now. This PR has been tested and is waiting to be merged. |
Use the error code to check if the authentication was successful.
ok but wich is the header? |
@marcol79 The header is here. But you don't have to worry about that. Once this PR is merged, your device will work out-of-the-box. |
ok so you advise me to wait? |
@marcol79 If you don't want to wait you can use this. |
I also wait because I have the bridge in openhab and I don't know which file to modify ;) |
FWIW I verified that this works, and I can now use the command-line tool's |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Danielhiversen This is something you might want to check out. How about we implement the discover function within our integration? We could do a single discover and share the results among our platforms.
I just realized that RM4 devices use the same header. I will take the opportunity to extend support to these devices as well.
@mjg59 @Danielhiversen Would you mind taking a quick look here? This PR solves all problems with the RM Mini3 0x5f36 and extends support to the entire RM4 series. |
Ah, an important information that we are missing is the last byte of HELLO_RESPONSE. If this byte is defined, the user will have to remove the device from Broadlink App and perform a procedure to disable the cloud. So I think it would be interesting to save this byte in some way so that the automation platforms can display an alert to the user with a link to a tutorial on how to perform the procedure. @mjg59 @Danielhiversen What do you think about saving this byte? I can do this. |
python-broadlink/broadlink/__init__.py Lines 143 to 145 in 5daf12c
If we yield the devices instead of returning a list I can reduce our start up time in Home Assistant to less than 1 sec. But as we've changed a lot here, I'll leave that to a separate PR. |
The rm4 class will improve code scalability. Just add the RM4 type to this class and it will just work.
Hello @felipediel Great work hehhehehehehe How can i adopt your solution? Best regards |
@ArchGalileu - you could do the following before it is merged:
|
@ArchGalileu You can also use: If you are using Home Assistant, you also need to update the files I've changed in this PR. Download the files to your Detailed instructions here. |
Hi @felipediel, I just want to let you know that I quickly tried your branch and it solved my issues with my RM 3 Mini (0x5f36). Awesome work! Hope it gets merged fast! Thanks a lot!! |
Unfortunately I haven't been paying much attention to Broadlink stuff in a while - what's the backstory here? If the device sends this byte, it's enrolled in the cloud and can't be used locally, so the user needs to disable that? If so, setting that as a property in the device and letting the higher layers check that and prompt the user sounds like a good plan. |
This looks pretty good to me - thank you for working on this! I'll wait to see if @Danielhiversen has any further feedback, but if not ping me in a week and I'll merge this. |
Awesome, working perfectly |
Thanks for approving! 👍 |
Anyone can help me with 5f36 on Homebridge?.. I am having the same issue with the 5f36 RM Mini 3 as well.. |
@felipediel is there any chance that you can apply your magic as well to the homebridge plugin https://github.com/lprhodes/homebridge-broadlink-rm |
@felipediel please lend us your magic 🥺🙏 |
@felipediel would also appreciate if you could help on the homebdrige-broadlink-rm would also pay for it :) |
@torbenrockstar have you checked here lprhodes/homebridge-broadlink-rm#600 it works like a charm |
@Spanishu wow thank you very much, why havent i seen this. Spent the whole day implementing the changes from here by myself (actually just got the sendcode to work when your wrote this comment) |
Hi guys. I'm sorry I couldn't help you in time. I'm glad to know that @rafaelncarvalho managed to adapt the code. Now you can extend support to the entire RM4 series using those same headers. |
Hi. I added support for the RM4 series in the plugin homebdrige-broadlink-rm, but RM4c Mini does not learn or send code. // RM Devices (without RF support) Did I add correctly? |
@Dmitriy-sc It's not that simple. Follow this thread. |
I did as indicated in this thread:
However, the learn code functionality doesn't seem to be working. Вut RM4c Mini does not learn or send code... Maybe part of the code is missing in the index.js ? |
@Dmitriy-sc Did you copy all the file? Did you disconnect your device from the cloud? Did you adapt lines 245 and 246? |
@felipediel, thank you very much. I did not know about the adaptation of lines 245-246. It works now. |
@Dmitriy-sc I think the best approach is to use inheritance and interface segregation as we did in this library. If you adopt these design patterns your library will become more flexible to integrate new devices in the future. |
Hi, Thanks a lot for your work. Hoping RM4 will work soon. |
These devices require a special header in the payload. The rest is the same.
Related issues:
RM 3 Mini (0x5f36)
#307
#308
home-assistant/core#30215
home-assistant/core#23566
lprhodes/homebridge-broadlink-rm#551
RM4 series
#301
#312