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

I am also using textual configuration. If I use macAddress, I get a blank MAC in the Thing in the UI and I get an “awaiting configuration” error. With mac the MAC address appears correctly in the UI.

Even with the correct config, I am still getting “cannot authenticate” on my BG1 socket. Do I need to supply any more config details?

(Openhab 3.1.0.M5 with latest version of the binding from the link above)

@barneyd I suggest to temporarily find your device by autodetect, to confirm it working properly with the binding, and move to textual config only after that:

  • Comment your thing in .things file (or rename .things to e.g. .thing);
  • check it is removed from things list; if not stop openhab, do openhab-cli clean-cache and restart
  • go to Main UI / Things, add new thing by “+” and proper binding; detect your device
  • Give it a temporary name
  • Find it in things list, open it
  • in “Thing” tab configure to your needs (IP, mac, etc) and then change to “Code” tab. This should present the defined parameters with required parameter names.
  • modify your textural .thing(s) file with different thing name, change back to .things file name; thing should appear in parallel to autodetected thing
  • Remove the autodetected thing

To check binding version, open openhab’s console in shell, list bindings by bundle:list | grep "Broadlink" and see timestamp at version info. I have 3.1.0.202106150948.

Thanks for the clear and comprehensive advice.

I have checked the version and I have 3.1.0.202106071326, downloaded from the link in the post above.

I can discover the socket and the thing goes “online” so looks good. I can link items to channels but when I change the state of the items, nothing happens at the socket.

I can try with the latest version of the binding but I always have the problem of where to find latest snapshot versions. Do you have a link to the version you have installed please?

I can see a difference between the discovered thing and the textual thing in the UI: the discovered thing has 3 thing properties. If I replicate these in the .thing file, they do not appear as thing properties in the UI. Although they do appear in the code, I still get a “could not authenticate” error.

See here: Releases · themillhousegroup/openhab2-addons · GitHub

Thanks. I’ve successfully installed the new binding but it seems less functional than the 07/06/2021 version.

When I scan, it doesn’t find the socket and when I try to add manually, there is no “BG1” thing type.

I’ve raised an issue on the repo in case the latest changes accidentally broke something.

Hi Barny,
That’s a weird one, from what I can tell the BG Electrical BG1 has its own device code that shouldn’t ever have worked. (The python-broadlink library that I frequently and shamelessly copy from has unique codes for a couple of BG Electrical products, and it treats them as special compared to the Broadlink devices they must be based off…)

Anyway, I’ve gone and added a lot of new codes based on that library, that should improve compatibility, but I can’t say for sure that it will fix your case, because I think your device must be reporting as some other device code which happened to just work before.

More interestingly for the wider Broadlink audience, the binding is edging closer to getting into the openHAB 3.1 codebase, and the latest release that I’ve just published (3.1.M5.2) has a new feature suggested by @matt1 that you might like.

By implementing the DynamicCommandDescriptionProvider interface and watching the .map file you have configured for your Broadlink remote thing (e.g. RM2, RM3, RM4) you can now trigger remote codes to be sent from the openHAB web GUI, and updating the .map file will update the GUI instantly.

Navigate to Things → [Your Broadlink remote Thing] → Channels → Command:

Click the Item you should see there that represents the command channel of the Thing:

Now you’ll see the name of the last command you sent down this channel. It’s not super-obvious, but if you click this text, you’ll get a pop-up appear with all of the available commands - click one and it will be sent by the Broadlink device!

If you add/modify/remove anything from broadlink.map (or whatever you’ve called it) this pop-up list will update to stay in sync.

Cheers,
John

2 Likes

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 ?