Your Broadlink binding 3.1.0.b5 runs well on my OH3.1.0M4. Now, with M5 being available and for future 3.1, I ask if you could help with a recompile due to changes in UoM dependencies (Upgrade Units of Measurement dependencies by wborn · Pull Request #2319 · openhab/openhab-core · GitHub)?
Looks like this is needed to be fixed… I was runnning OH3.0.2 without problems…
but by testing some features of M5 concerning openhab gooogle integration is was sturggeling with broadlink binding… At least broadlinks were not anymore recognized.
@moment returning to OH3.0.2 by etching the backup
Thank you, @proyleg. This works flawless with my RM4 Mini incl. cable sensors for temp/hum on OH3.1.M5.
Thank you very much!
It is also working very well with my RM4Mini and OH3.1.M5 after upgrading from M3 (it was not working with OH3.1.M3). I recorded the codes with the python-broadlink module (GitHub - mjg59/python-broadlink: Python module for controlling Broadlink RM2/3 (Pro) remote controls, A1 sensor platforms and SP2/3 smartplugs).
After struggling a bit with the broadlink-mqtt solution I was very happy to find this binding.
However, it was quite difficult to find this binding, as this thread is huge and also the topic is not suggesting a working binding.
Are there any plans to add it to the official openhab-addons repository?
Hi Guys
Im using 2.5.10 BETA and see this for my BEOK thermostat, is the a better version that supports this device?
17:39:56.252 [WARN ] [l.discovery.BroadlinkDiscoveryService] - BroadlinkDiscoveryService - Beginning Broadlink device scan...
17:39:56.254 [WARN ] [.internal.discovery.DiscoveryProtocol] - Beginning async Broadlink device scan; will wait 10000 ms for responses
17:39:56.258 [WARN ] [.internal.discovery.DiscoveryProtocol] - Broadlink device scan waiting for 10000 ms to complete ...
17:39:56.285 [INFO ] [l.discovery.BroadlinkDiscoveryService] - Data received during Broadlink device discovery: from 192.168.0.110:80 [78:0f:77:18:43:03]
17:39:56.293 [ERROR] [inding.broadlink.internal.ModelMapper] - Device identifying itself as '20141' (0x4ead) is not currently supported. Please report this to the developer!
See the second post here OH3 · Issue #13 · themillhousegroup/openhab2-addons (github.com)
A precompiled jar seems to have been posted around 5 posts above this one. Note that the build system changed at OH 3.1.M5 so you will need to use a JAR that was built for versions before or after this point in time.
Source code is found here
openhab2-addons/bundles/org.openhab.binding.broadlink at master · themillhousegroup/openhab2-addons (github.com)
It is waiting to be reviewed and merged, see
Hi,
You might want to try the broadlinkthermostat binding - it’s specifically designed for these OEMed thermostats (assuming it’s a Broadlink device underneath, which it looks like it is)
Thanks Matt,
I’ve rebuilt the binding with all the latest PR-recommended improvements for OH 3.1.M5 and later here.
Worth mentioning that due to renaming of some config parameter and channel names, you’ll probably want to delete any Broadlink Thing s in your system created by previous versions of this binding, and then re-add them once you’ve installed this one.
Cheers,
John
I am on the stable version of openhab:
openhab/stable,now 3.0.2-1 all [installed]
How do I install the binding for that version?
Is there a binding for that version?
Thanks
It should not be hard to get it working, however I really really encourage you to move to the milestone builds until 3.1 stable is released. Since the stable is the first one ever in the V3 lineup, it is missing a lot of stuff that has come out. The UI has a lot of new stuff.
Ok thanks. I will upgrade and see what breaks 
After changing parameter name
mac
to
macAddress
my textual thing configuration worked without issues with RM4 mini incl. cable sensors.
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-cacheand 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.
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