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) :
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)
BEGIN and END messages, it should have exactly the number of characters as advised in the END message.map file, with the name of your choice; for example:BLURAY_ON=2600bc017239100d0e2b0e0f100c107f55747be51a3e1d4ff4...0145447f55747be51a3e1d4ff4b
command channel and try it outAs 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
Fantastic and great work. Since it can all be done automated without external tools, is it possible to do it this way?
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.02installThat 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.
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?
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 
, 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:
That makes sense. Confusion solved!
It does. To complicate it further, you can control them individually or as a pair. You can also set a “max working time” that will switch the socket off a fixed time after it was switched on manually or by the app.
That would be fantastic. I’d rather it was in the official binding than have to run another version.
Understand completely. There is a workaround through controlling the socket with Alexa and sending commands to Alexa from OpenHAB so it is usable, just not ideal. Whenever it gets integrated into the binding it will be appreciated. - Thanks
Version 3.1.M5.4 now exposes Remote Learning Control channel for RM4Mini. Following your manual some posts above (##1-4), Learn Mode can be triggered - but RM4Mini doesn’t get there. No LED change to solid (#5) + no code learned. String item state, originally NULL, stays on “Enter infrared learn mode”.
IR-Commands can be sent, sensors are read.
Although log looks promising, no activity on the learn mode:
2021-07-01 11:09:26.463 [TRACE] [handler.BroadlinkRemoteModel4Handler] - Sending learning-channel command LEARN
2021-07-01 11:09:26.466 [TRACE] [handler.BroadlinkRemoteModel4Handler] - Sending enter remote code learning mode to <IP>:80
2021-07-01 11:09:26.467 [TRACE] [handler.BroadlinkRemoteModel4Handler] - Sending enter remote code learning mode complete
2021-07-01 11:09:26.469 [TRACE] [handler.BroadlinkRemoteModel4Handler] - Awaiting enter remote code learning mode response
2021-07-01 11:09:26.492 [TRACE] [handler.BroadlinkRemoteModel4Handler] - Received enter remote code learning mode (72 bytes)
When choosing Check last learnt code, this is the result, maybe because of no code learned yet:
2021-07-01 11:19:44.610 [WARN ] [handler.BroadlinkRemoteModel4Handler] - Exception while attempting to check learnt code
java.net.ProtocolException: Response from device is not valid. (0x22=0xFB,0x23=0xFF)
at org.openhab.binding.broadlink.internal.BroadlinkProtocol.decodePacket(BroadlinkProtocol.java:192) ~[bundleFile:?]
at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler.decodeDevicePacket(BroadlinkBaseThingHandler.java:183) ~[bundleFile:?]
at org.openhab.binding.broadlink.handler.BroadlinkRemoteHandler.sendCheckDataCommandAndLog(BroadlinkRemoteHandler.java:100) [bundleFile:?]
at org.openhab.binding.broadlink.handler.BroadlinkRemoteHandler.handleLearningCommand(BroadlinkRemoteHandler.java:120) [bundleFile:?]
at org.openhab.binding.broadlink.handler.BroadlinkRemoteHandler.handleCommand(BroadlinkRemoteHandler.java:158) [bundleFile:?]
at jdk.internal.reflect.GeneratedMethodAccessor168.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy58613.handleCommand(Unknown Source) [?:?]
at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Did you check the oh-input system widget? There are also oh-input-card and oh-input-item widgets for card and use in list items. You should be able to just enter text. I use it with the upnpcontrol binding to give names to new favorites I define.