-
Notifications
You must be signed in to change notification settings - Fork 479
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 ability to RF scan a specific frequency #613
Conversation
This adds an optional parameter to find_rf_packet(), along with a corresponding --rflearn parameter (defaulting to 433.92) to broadlink_cli that specifies the frequency to tune to, rather than requiring the frequency be found via sweeping. This is almost mandatory for certain types of remotes that do not repeat their signals while the button is held, and saves significant time when the frequency is known in advance or when many buttons are to be captured in a row. Additionally: - A get_frequency() API is added to return the current frequency the device is tuned to. - A check_frequency_ex() API is added to perform functions of both check_frequency() and get_frequency() in a single call. - broadlink_cli --rfscanlearn will now report the current frequency at 1 second intervals during sweeping, and will report the frequency it finally locks on to.
Just amended the commit to fix a typo in the commit message specifying the wrong default frequency. Code is unchanged. |
Just tested this PR because who needs to scan the whole spectrum right? And it just worked. Nice job and thanks. |
On I get Device tuned to 0.0MHz And |
I am using RM pro, type ID: 0x2712, does python-broadlink support RF on this model? I found LED never turn red when I start learnRF and when I use app e-broadlink, led turn red immediately after I press learn |
Can we get this merged? Anything that is still blocking this? As outlined this is super useful for remotes that don't repeat their code when holding the button. It's virtually impossible to read codes from those remotes using python-broadlink without this change. |
Hi. Much better, thanks a lot! I just came to say that I have not forgotten this PR, it will be included as soon as I find time to give it some treatment and prepare an update for Home Assistant 👍 |
Currently HA is a bit broken for learning, at least for remotes like @DarkStarSword mentioned that don't repeat the signal. I can't find a way to work around it. |
Hi @DarkStarSword. I made some changes. My remote works a bit different so I can't test. Still works for you? |
I'm not @DarkStarSword but successfully tested it with an A-OK remote for a roller shutter. |
@felipediel are there still plans to add this functionality? After doing a few hours of research online, it seems like remotes with the ~433 frequency won't work until something like this is implemented. I think this frequency is especially common for ceiling fan remotes (at least that's my use case). Appreciate any insight you can provide! |
Anything I can do to help here? |
I've tested this PR via the cli, and it's working well for my RM4Pro, For anyone else looking to quickstart on the PR: Checkout the branch or download the cli file Get your broadlink devices details for the --device flag with: Run a specific frequency learn with the above device details, and your frequency: I'm rusty on my python/pip, so apologies if this is a roundabout way of testing the PR, but it seems to work for me on mac. |
Thank you! I'll merge as soon as I have time to create a PR in Home Assistant. |
I tried the steps above but command complains that arguments --frequency and --rflearn are unrecognized. dev branch, yes. What am I missing? |
Are you sure you're trying the correct repo's dev branch? |
You are right. I was actually using the wrong repo. Fixed.
|
Amazing. Thank you!! |
I still get the same error. Not working. |
I'm seeing the same error Press the button you want to learn, a short press... |
Sounds to me like you either didn't update broadlink/remote.py or are invoking an unpatched version. The patched version implements the frequency parameter. In my case I manually applied the changes to broadlink_cli in my home directory and the changes to remote.py in .local/lib/python3.9/site-packages/broadlink Works great for me. |
I had the same problem, eventually i figured out that my RM4 Pro is newer model than those in init.py, so i just added mine and it worked. Check the ID of your RM against those listed in _init.py. This was what i added: |
Hello. Please merge this PR into the main branch. This feature works and otherwise does not change any existing functionality (the change is backwards compatible). If you do not implement this change I will fork this repo and actually maintain it. |
if its any help , i've already forked this and merged it, also added some new devices.. Feel free to start from there. |
Awesome! Do you have this in PyPi? |
Sorry, no, i just needed a quick fix to be able to capture couple of RF remotes for my homeassistant, didnt bother any further :) But it works perfectly, no idea why this was abandoned... |
Ok no worries. Curious if you want to make me a contributor on your repo or if I should make my own? |
Sure thing, i've added you just now. |
Thanks, I'll try to contribute there soon. I plan on adding a more advanced interface for creating custom devices, which are cached and available for use later and can also be edited later. |
What is the hold up here? More testing needed? I need to bring this into Anyone fork these yet with this? all my remotes are 433.92 and none learn with the rm40 pro unless I set freq with the app first, maybe Ill just have it not actually sweep... |
See here: https://github.com/brentleeper/python-broadlink |
Thanks @DarkStarSword! 🎉 |
Ok guys, now to implement this in Home Assistant we need to create a new service to sweep the frequency separately, and this involves discussing with the core team why these changes are important. If anyone can join the discussion and share the experience with the current interface, explaining why it is problematic I would appreciate that: home-assistant/architecture#1076 |
This adds an optional parameter to find_rf_packet(), along with a
corresponding --rflearn parameter (defaulting to 433.92) to
broadlink_cli that specifies the frequency to tune to, rather than
requiring the frequency be found via sweeping. This is almost mandatory
for certain types of remotes that do not repeat their signals while the
button is held, and saves significant time when the frequency is known
in advance or when many buttons are to be captured in a row.
Fixes #459