Broadlink binding for RMx, A1, SPx and MP. Any interest?

If you want it more obvious then do this which only gets done once…

  1. Settings>Things> click on your rmx thing> goto CHANNELS tab> scroll to the bottom and click 'Add equipment to model"
  2. Complete adding the equipment as per the new V3 user guide, making sure to select the “SEMATIC CLASS” to ‘RemoteControl’.

Step by Step instructions on how to do this with the Semantic Model | openHAB

Then in the main UI just click on equipment, remote controls and click on the command line and the list appears.

How hard can it be? - YouTube

3 Likes

John
Could you please publish jar version of 3.1.M5.2 ?
Thanks

Ah apologies Igor, the JAR failed to attach on the link above. Fixed now:

1 Like

For RM4 mini (at least) this latest build 3.1.M5.2 reports temperature as UNDEF, while earlier build 3.1.M5 reports values. Commands work, humidity is reported well.

EDIT: My earlier post said that there is an issue on units of temperature in 3.1.M5 (202106150948) version. Was my fault in item config. So, .M5 version works well, while M5.2 reports UNDEF.

Really nice

Hi Carl,
You might need to remove your RM4 Thing and re-discover it. If that doesn’t resolve the temperature issue, we can make a new version that has some more debug logging in it to work out what has gone wrong.

Cheers,
John

I had a look last night and the code looks good, nice work. the issue is the item needs to be changed to match the new UOM that was added in the newer version. easy to fix just delete and recreate the item to match the channels number:temperature type.

The person above already edited to say they have it working.

Any issues changing to newer version just:

Delete and recreate thing
Same to the items
Lastly if still not fixed clean the cache.

@themillhousegroup @matt1 You were right, it behaves very well. While I tried earlier with resetting thing only, I had to actively remove/recreate items as well. My bad, I am sorry. You gave the helping hint.

To confirm binding working as expected, I used auto discovery first, which prove it working well for all 3 channels command, temp and hum. I could then safely delete the auto discovered + recreate thing and items through file definition.
As a side note, the removed thing from MainUI seems to continue querying, see very frequent log entries below. That thing isn’t listed in console’s things list for deeper manual deletion. Not really harmful, can be cleared by clean-cache:

2021-06-24 09:05:24.245 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BroadlinkRemoteModel4Handler of thing broadlink:rm4:<mac-removed-here> tried updating channel temperature although the handler was already disposed.
2021-06-24 09:05:24.248 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BroadlinkRemoteModel4Handler of thing broadlink:rm4:<mac-removed-here> tried updating channel humidity although the handler was already disposed.
2021-06-24 09:05:24.250 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BroadlinkRemoteModel4Handler tried updating the thing status although the handler was already disposed.

Hi Carl, and thanks for the bug report, you were correct, that version of the binding was not cleaning up after itself properly. That is now fixed in version M5.3

I recommend this version to all Broadlink users on openHAB 3.1, it’s got a great new feature that was prompted (again) by @matt1 reviewing the PR - he wanted me to document in the binding’s README how you actually add remote codes to your broadlink.map if you have an RMx device - and I realised that it is a really nasty and complex process that requires external tools.

So I looked into it and it turned out to be reasonably easy to do it all entirely within openHAB - so, as of this release, you can tell your RMx to go into “learn mode” and get it to dump out the code that it learns. Here are the steps (note it’s quite similar to the “send command” process I explained a few posts ago) :

  1. In the openHAB web UI, navigate to your RMx Thing, and click on its Channels tab
  2. Find the Remote Learning Control channel and create an Item for it if needed
  3. Click the item, and click the rectangular area that is marked NULL
  4. In the pop-up menu that appears, select “Enter infrared learn mode”
  5. The LED on your RM device will illuminate solidly
  6. Point your IR remote control at your RM device and press the button you’d like to learn
  7. The LED on your RM device will extinguish once it has learnt the command
  8. Now click the rectangular area again (which will now show “Enter infrared learn mode”)
  9. Select the “Check last captured IR code” menu option in the pop-up menu
  10. Inspect the openhab.log file on your openHAB server - you should see the following:
[BroadlinkRemoteHandler] - BEGIN LAST LEARNT CODE (972 bytes)
[BroadlinkRemoteHandler] - 2600bc017239100d0e2b0e0f100c107f55747be51a3e1d4ff4......f5be8b3d4ff4b
4d77c44d105fa530546becaa2bcfbd348b30145447f55747be51a3747be51a3e1d4ff4b3f4f4f......a3e1d4ff4b348
0145447f55747be51a3e1d4ff4b
[BroadlinkRemoteHandler] - END LAST LEARNT CODE (1944 characters)
  1. If you carefully copy the log line between the BEGIN and END messages, it should have exactly the number of characters as advised in the END message.
  2. You can now paste a new entry into your map file, with the name of your choice; for example:
BLURAY_ON=2600bc017239100d0e2b0e0f100c107f55747be51a3e1d4ff4...0145447f55747be51a3e1d4ff4b
  1. Now you can head over to the command channel and try it out

As usual with these 3.1.M5 builds, please be sure to remove all previously-added Broadlink Things and Items, and rediscover them with the new binding to avoid strange problems.

Cheers,
John

5 Likes

Fantastic and great work. Since it can all be done automated without external tools, is it possible to do it this way?

  1. Enter a String into a item/channel for what the command will be called ie “TvPowerOn”.
  2. Turn ON a switch channel to enter into LEARN MODE.
  3. Device waits for the key to be pressed.
  4. Switch from step 2 will auto turn OFF when the device has learnt and the string is cleared.
  5. Binding stores the data into the file for the user.

It wont be quite that simple to code as you would need to work out what to do if the command already has that named stored already and some special cases like that…

I’m trying to get OH3 to take string inputs in the new UI (as it was easy in OH2) so this may need a custom widget to really make it all come together unless I am missing something simple in the mainUI.

Edit: perhaps it would be easier to not use a string channel for the name and to just auto name it. User then opens the map file to edit the keyPress1 to whatever they want.

Hi @themillhousegroup, wow, that sounds promising. Tried to test this right away - but I failed. New version M5.3 doesn’t present a Remote Learning Control channel, but the known 3 others (RM4mini with Command, Temp, Hum).
I did the full cycle, with clean-cache, to remove all remainings of M5.2 version, console reports 3.1.0.202106260933 version active. No things nor items files, just used auto discovery. Found my device, added, but it came without Learning Control.

Interesting enough, I don’t see Broadlink binding in MainUI’s Bindings list although Thing + Items can be created.
log:set DEBUG org.openhab.binding.broadlink
results in Error executing command: Unable to set level for logger

I´m runnig OH 3.02
If i tried to install the new version from today, OH give me some errors at installing the jar file:

2021-06-27 02:15:28.410 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.broadlink-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.broadlink [291]
  Unresolved requirement: Import-Package: javax.measure; version="[2.1.0,3.0.0)"
	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]```


someone have a tippfor me? Or does the binding runs only under oh 3.1 5???
Because before it did also runs on my OH 3.02install

That is the issue. The units of measurement got upgraded in the milestone 5, so the jar you have needs a newer core than what you have.

@themillhousegroup
It is simple to create a jar that will run on the older cores if you compile with an extra option.
mvn clean install -Dohc.version=3.0.2

Probably the easiest thing to do is upgrade to the new 3.1 stable which is now just released.

do you have a tipp for me what is the last usable Binding version for 3.0.2 ?

From the list of releases at Releases · themillhousegroup/openhab2-addons · GitHub
try this one: Release 3.1 Beta 5: Non-blocking initialize() · themillhousegroup/openhab2-addons · GitHub
It is beta 5 from February, but surprisingly low in the list of versions.

1 Like

I test the last 3.1.M5.2 version, with SP3s now it shows this number 166772.32 in the power meter (the previous version of bunding shows null). In socket nothing contacted

Hi, I have a Broadlink RM2 Pro and I don’t see the Remote Learning Control channel. I deleted everything of my Broadlink thing, deleted the cache and the TMP and of course when I check the bundle in the console it gives me the right 20210626 version…
What am I missing?

1 Like

On the Release Candidate … same problem with rm4mini

Are there two forks of this binding floating around? The one that detected the socket was the one from earlier in the thread. Could this be a different, rather than just earlier, version since as you say, none of the versions installed from the repo have this device type?

That binding detected the socket with a device code of 51e3. It also detected a key, which if I reinstall that version of the binding, I could capture if that helps.

It would be great to have the BG1 socket working. At £15 for a double socket controllable from OH, it’s hard to beat.

I think you’ve hit the nail on the head @barneyd - the version created by @proyleg seems to have had some extra functionality compared to the ones I’ve been publishing.

The thing is, I could add device code 0x51E3 to the list and get it recognised by the binding as an SP2 (for example), but it’s not - it seems to have 2 controllable outlets and needs to be communicated-with using a very specific protocol that is unique to the BG devices:

So while it would appear in discovery, there’s no way it’ll work without further development to use this BG-specific protocol. Which I’m happy to do :slight_smile: , but unfortunately not right now while I’m trying to get the Broadlink binding into the main openHAB codebase (and keep a lid on the amount of “new stuff” I’m shoehorning in there)

On that subject, I’ve got a new release that should fix SPxS power consumption calculation (thanks @Zip_Zip ) and the Remote Learning channel being missing on some RMx devices (thanks @proyleg ) - please try it out: