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

Hi @themillhousegroup,

First of all thanks for the binding :slight_smile:

I’ve a Broadlink SP3, and the powerConsumption doesn’t work. Isn’t implemented yet?

Thanks,
Fernando Gomes

Hi Fernando,
It’s next on my list - I don’t have an SP3 myself, so would you mind being a test subject? :smiley:

Hi John,
Many thanks for the continued support of the binding :pray: :pray:
I’ve added the beta 8.1 jar file to a completely new OpenHAB 2.5.5 install on my mac and carefully copy-pasted the authentication key and IV.
Unfortunately, I’m still seeing the error message.

[EDIT] Looks like the Thing’s Configuration Parameters do not properly save the Authentication Key and IV I enter, even though I’m pressing the save button.
Each time I enter the values, press save, and then go back into Configuration Parameters, the values are not there anymore.

Okay @mjeshurun,
Take a look in your OpenHAB log file and see if you can see a line like:

constructed: resetting deviceKey to '097628343fe9e23765c1513accf8b02', length 31
(HINT: this should start '0976', end '8b02' and have length 32)

I’m very interested to see what you have after resetting deviceKey to

Looks like the Thing’s Configuration Parameters do not properly save the Authentication Key and IV I enter, even though I’m pressing the save button.
Each time I enter the values, press save, and then go back into Configuration Parameters, the values are not there anymore.

The log shows the devicekey as length 0.

2020-05-22 10:45:09.906 [INFO ] [handler.BroadlinkRemoteModel4Handler] - rm4:24-df-a7-b9-c6-89[?]: constructed: resetting deviceKey to '', length 0
2020-05-22 10:45:09.906 [INFO ] [handler.BroadlinkRemoteModel4Handler] - rm4:24-df-a7-b9-c6-89[?]: (HINT: this should start '0976', end '8b02' and have length 32)

Hi John,

Off course I will be happy to help!

Best Regards,
Fernando Gomes

Hello John,

Thanks for the great work on this binding!, The Broadlink SP3S with power meter is on sale at Ali now, you can buy 2 for under 15 euro for the EU version.


I have 2 of the old versions SP3 and they work fine with your binding and have more than enough power sockets, :crazy_face: but if it helps i’ll sponser 2 for you, do you have paypal?
And hope that when you have time you can fix the MP1 with the 2 USB sockets!
Ray

1 Like

Hi all,
i recently updated this great binding to the last version available (beta-8 i guess) and i saw a new option called DEVICE TYPE which was automagically compiled to 2737 (i own 7 RM MINI3).
In the option description is written that this value should be an integer, not an hexadecimal like now, so my (probably dumb) question is:
should i convert the value to integer or it’s ok like that and the description is deprecated?

Moreover in the openhab log i have tons of this warning:
Online -> Offline due to: Couldn't find statically-IP-addressed device
and little less error (let’s say 1 per hour):
Authentication failed: java.lang.NullPointerException: null

Could they depend on the wrong DEVICE TYPE value? Or maybe i have too many IR Sender on the same wireless network and the raspberryPI 3 is too “low powered” to handle them all?

EDIT:
Please note, i just tried the python-broadlink script, and it report my 7 broadlink ir senders as RM2 (2737)
RM2
# broadlink_cli --type 0x2737 --host 192.168.2.134 --mac XXXXX

While i’m pretty sure i bought the rm mini3 version, or at least this is what it was written on the RM boxes.

Thanks for you help

Hi all! Having some issues with my RM mini 3 (new version 0x5f36)- i managed to configure the device using python-broadlink and can learn and send back commands with the provided scripts (my test run was to turn on/off TV).

Having set everything up with openHAB2 binding (using latest 2.5.1 SNAPSHOT), i get the following log outputs:

2020-05-26 08:12:06.698 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:XXX[^]: Handling ir/rf command TV_POWER_ON on channel command of thing Broadlink RM3 [10.0.0.10]
2020-05-26 08:12:06.718 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:XXX[^]: Transformed command ‘TV_POWER_ON’ for thing Broadlink RM3 [10.0.0.10] with map file ‘broadlink.map’
2020-05-26 08:12:06.719 [TRACE] [dlink.handler.BroadlinkRemoteHandler] - rm3:XXX[^]: building message with count: 7065, deviceId: 01000000, deviceKey: 2164XXXXXXXXA2AD
2020-05-26 08:12:06.722 [TRACE] [dlink.handler.BroadlinkRemoteHandler] - rm3:XXX[^]: Sending remote code to 10.0.0.10:80
2020-05-26 08:12:06.724 [TRACE] [dlink.handler.BroadlinkRemoteHandler] - rm3:XXX[^]: Sending remote code complete
2020-05-26 08:12:06.725 [TRACE] [dlink.handler.BroadlinkRemoteHandler] - rm3:XXX[^]: Awaiting remote code response
2020-05-26 08:12:06.741 [TRACE] [dlink.handler.BroadlinkRemoteHandler] - rm3:XXX[^]: Received remote code (72 bytes)
~
TV is not turning on, from log messages i cannot tell what device is responding with.

Couple things:

  • I had to pad IR codes from python-broadlink to multiple of 16 (add 0000)
  • deviceKey looks wrong (was correct in the “constructed” statement), i have X’ed out the middle part, but length was correct at 32 digits

Anybody have any ideas? Maybe also related to deviceKey problems as reported here?

EDIT: One thing i have noted comparing the two 0x6a packages (py-broad and openhab-broad) with wireshark and looking at the protocol, is that the device type in the header (fields 0x24 and 0x25) is not set by openhab-broad, while py-broad sets the fields to 0x36 and 0x5f

Seems you are not using the latest snapshot of python-broadlink. They recently (couple weeks back) made some changes to add support for 0x5f36 as it was not supported prior.
Give it another try with current state of master, it worked for 0x5f36

Hi all,

resetting and setting the deviceType again through paperUi (i have set it to decimal 24374 = 0x5f36), i found the following exception in the log i previously missed regarding the missing device type:

 2020-05-26 11:03:56.441 [WARN ] [me.config.core.internal.ConfigMapper] - Could not set field value for field 'deviceType': For input string: "5f36"
java.lang.NumberFormatException: For input string: "5f36"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:1.8.0_252]
        at java.lang.Integer.parseInt(Integer.java:580) ~[?:1.8.0_252]
        at java.lang.Integer.valueOf(Integer.java:766) ~[?:1.8.0_252]
        at org.eclipse.smarthome.config.core.internal.ConfigMapper.objectConvert(ConfigMapper.java:159) ~[?:?]
        at org.eclipse.smarthome.config.core.internal.ConfigMapper.as(ConfigMapper.java:98) ~[?:?]
        at org.eclipse.smarthome.config.core.Configuration.as(Configuration.java:80) ~[?:?]
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.getConfigAs(BaseThingHandler.java:232) ~[?:?]
        at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler.<init>(BroadlinkBaseThingHandler.java:65) ~[?:?]
        at org.openhab.binding.broadlink.handler.BroadlinkRemoteHandler.<init>(BroadlinkRemoteHandler.java:46) ~[?:?]
        at org.openhab.binding.broadlink.internal.BroadlinkHandlerFactory.createHandler(BroadlinkHandlerFactory.java:56) ~[?:?]
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:126) ~[?:?]

something wrong … I can’t save configuration parameters through paper UI

2020-05-29 17:25:52.563 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/broadlink:rm3:24-df-a7-7a-a1-64/config'

java.lang.IllegalStateException: Thing with UID broadlink:rm3:24-df-a7-7a-a1-64 has no handler attached.

	at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.updateConfiguration(ThingRegistryImpl.java:95) ~[?:?]

	at org.eclipse.smarthome.io.rest.core.internal.thing.ThingResource.updateConfiguration(ThingResource.java:438) [bundleFile:?]

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_222]

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_222]

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]

	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]

	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) [bundleFile:?]

	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) [bundleFile:?]

	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) [bundleFile:?]

	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) [bundleFile:?]

	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) [bundleFile:?]

	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) [bundleFile:?]

	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) [bundleFile:?]

	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) [bundleFile:?]

	at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [bundleFile:?]

	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [bundleFile:?]

	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [bundleFile:?]

	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [bundleFile:?]

	at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [bundleFile:?]

	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [bundleFile:?]

	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [bundleFile:?]

	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [bundleFile:?]

	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [bundleFile:?]

	at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [bundleFile:?]

	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) [bundleFile:9.4.20.v20190813]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [bundleFile:?]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307) [bundleFile:9.4.20.v20190813]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [bundleFile:?]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [bundleFile:9.4.20.v20190813]

	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [bundleFile:?]

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.Server.handle(Server.java:494) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]

	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]

hi @themillhousegroup,
First thanks for all the good work!
Also tried the new version of the binding, after my previous version stopped working with the latest update to 2.5.5-1.
Followed the steps as explained, and get the same issue with the no handler attached.
Filled in both key’s, but they are gone after saving again. Also the device type discovery doesn’t seem to work, since it is empty. Manual set it to 24374 doesn’t help.

2020-05-30 22:44:56.325 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/broadlink:rm3:24-df-a7-7a-6a-87/config'

java.lang.IllegalStateException: Thing with UID broadlink:rm3:24-df-a7-7a-6a-87 has no handler attached.

	at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.updateConfiguration(ThingRegistryImpl.java:95) ~[?:?]

	at org.eclipse.smarthome.io.rest.core.internal.thing.ThingResource.updateConfiguration(ThingResource.java:438) [bundleFile:?]

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_252]

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_252]

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_252]

	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_252]

	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) [bundleFile:?]

	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) [bundleFile:?]

	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) [bundleFile:?]

	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) [bundleFile:?]

	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) [bundleFile:?]

	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) [bundleFile:?]

	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) [bundleFile:?]

	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) [bundleFile:?]

	at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [bundleFile:?]

	at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [bundleFile:?]

	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [bundleFile:?]

	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [bundleFile:?]

	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [bundleFile:?]

	at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [bundleFile:?]

	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [bundleFile:?]

	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [bundleFile:?]

	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [bundleFile:?]

	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [bundleFile:?]

	at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [bundleFile:?]

	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) [bundleFile:9.4.20.v20190813]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [bundleFile:?]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307) [bundleFile:9.4.20.v20190813]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [bundleFile:?]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [bundleFile:9.4.20.v20190813]

	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [bundleFile:?]

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.Server.handle(Server.java:494) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:426) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:320) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:158) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]

	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]

	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

Hi all,
Not sure if something has changed with the latest OpenHAB platform, PaperUI, or something else, but lots of reports coming in that are looking like a disconnect between the configuration params in the UI and the binding. I don’t have a great deal of time to go into the root cause at the moment, so I’m making a pretty major change to “solve” it in the simplest way I know how.

Beta 9, located here:
https://github.com/themillhousegroup/openhab2-addons/releases/download/BROADLINK_2.5.BETA_09/org.openhab.binding.broadlink-2.5.1-SNAPSHOT.jar

has the Authorization Key and Initial Vector now baked in. This has numerous benefits:

  • After confirming the name of a newly-discovered Thing, it should come directly online with no further data-entry needed
  • No more questions on this thread asking about those parameters / having trouble with them

For a long time (actually since before I even took over maintenance of this binding) these values have been a kind of poorly-guarded secret. Cato (the original maintainer) may well have been very justified in wanting to keep these secret values out of the binding code, but by now I think we can be pretty sure that Broadlink either don’t know or don’t care about people knowing/using them. The Python API on Github has had them baked-in forever and haven’t been taken down :man_shrugging:

I’ve tested this binding with my A1, SP2 and RM Mini 3 and it’s been very solid, although I have not updated my OpenHAB installation (I’m still on 2.5.0). Please let me know if you’re on the bleeding-edge and still having problems.

Cheers,
John

3 Likes

Thanks John for your continued support and effort.
I have updated the binding to beta 9 running on OpenHAB 2.5.3.
After the binding update I restarted my OpenHAB system to remove any remnants of beta 8.
Unfortunately, after OpenHAB restart the Broadlink binding beta 9 doesn’t automatically recognize my RM4 Pro device in the inbox, so I can’t add it to the system as a Thing.
I tried to manually add it, but OpenHAB won’t let me the save device, because the “checkmark” button is grayed out.

Thanks John! The system does recognize the binding and the RM3 well, but it won’t send a signal do the the error:

2020-05-31 09:39:01.770 [ERROR] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[^]: Will not send remote code because it has an incorrect length (94)

But I did not changed anything in the broadlink.map file and worked earlier fine. Nevertheless added the correct number of 00 until 96 characters where there. The error message disappeared, but the signal isn’t send. Did a restarted the device, binding, openhab and cleared cache with 3x reboot, but none helped.

To provide as much info as possible, here the log when I restart the binding:

2020-05-31 09:37:41.090 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: Broadlink RM3 [192.168.0.97] is being disposed

2020-05-31 09:37:41.095 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: Cancelling refresh task

2020-05-31 09:37:41.102 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: Cancellation successful: true

2020-05-31 09:37:41.305 [INFO ] [.discovery.BroadlinkDiscoveryService] - BroadlinkDiscoveryService - Constructed

2020-05-31 09:37:41.547 [DEBUG] [ink.internal.BroadlinkHandlerFactory] - Creating Thing handler for 'broadlink:rm3'

2020-05-31 09:37:41.549 [DEBUG] [ink.internal.BroadlinkHandlerFactory] - RM 3 handler requested created

2020-05-31 09:37:41.553 [INFO ] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: constructed: resetting deviceKey to '097628343fe99e23765c1513accf8b02', length 32

2020-05-31 09:37:41.556 [INFO ] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: (HINT: this should start '0976', end '8b02' and have length 32)

2020-05-31 09:37:41.592 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: initializing polling

2020-05-31 09:37:41.602 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: We've never actually successfully authenticated with this device in this session. Doing so now

2020-05-31 09:37:41.651 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: Authenticated with id '01000000' and key 'DC44AE3CC62483EC94BDFD0F02CB8EA8'

2020-05-31 09:37:41.656 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: Authenticated with newly-detected device, will now get its status

2020-05-31 09:37:41.658 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[?]: Offline -> Online

If I can provide more info let me know.
I am running on openHAB 2.5.5-1 (Release Build)

Thanks!

Hi, there where several Issues here in the Forum with the ‘save’ of configuration. In most cases the solution was simple. If there is an inputbox for a config value, press enter to finish input. In most cases the ‘save’ will become green.
A simple solution in this case.

The issue is about the length or your IR Code.


Please try with this for example to validate that the binding is working

led_blue=260068000001289512131213121312141213121312131114123811391138113911141237113912371115123711391213121312131214121312371214121312371139123811381238120005410001274c11000c530001274c12000c530001274b12000c530001274c12000d05

Thanks for the hint, but also the led_blue example unfortunately isn’t send (no LED blinking), although there are no errors:

2020-05-31 12:53:31.477 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[^]: Handling ir/rf command led_blue on channel command of thing Broadlink RM3 [192.168.0.97]

2020-05-31 12:53:31.494 [DEBUG] [dlink.handler.BroadlinkRemoteHandler] - rm3:24-df-a7-7a-6a-87[^]: Transformed command 'led_blue' for thing Broadlink RM3 [192.168.0.97] with map file 'broadlink.map'

My original codes did worked before, only not since the update to 2.5.5 and the update to the latter binding versions.
Not really in a rush solving the problem, I am controlling the ventilation with it and it has also manual operation possibilities. But of course would be nice if it did again :slight_smile:

@themillhousegroup : First of all, thanks for the update and your ongoing work on the binding!! I have also tried the new snapshot and get same result as @lampy described - commands to the device are ignored.
I have now decrypted the payloads of sniffed 0x6a command packets sent to my 0x5f36 (new RM mini 3) from the openhab binding and python-broadlink library respectively.

(as written in my previous posting, python-broadlink commands work, openhab do not not)

python-broadlink: d0000200000026004800000127…[TRUNC]
openhab-binding: 020000002600480000012793… [TRUNC]

So, also looking at the code python-broadlink is applying RM4 protocol
with 6-byte header for command packets to 0x5f36 (even though technically an RM mini 3), while openhab is using standard RM/RM2/old RM3 protocol with 4-byte header

The comment in the ModelMapper says the right thing, but it’s still mapped as an RM3 :wink:

Thank you!!