so right!
Hi John,
The same issue as before, paper UI lost after installing the BETA-14.
Returned back to BETA-13.
Just for the update.
Thanks Really! @themillhousegroup
unfortunately, it’s still the changes statuses to offline.
do the" retry" work automatically even for things with textual definition?
(Broadlink binding for RMx, A1, SPx and MP. Any interest? - #796 by themillhousegroup)
nakh_Home:
BETA-14 is now available over on Bintray:
https://dl.bintray.com/themillhousegroup/generic/org.openhab.binding.broadlink-2.4.0-BETA-14.jar
I looked over your log files and there is no apparent reason for the Broadlink devices going offline. They just fail to respond every so often.
In an attempt to improve their reliability, I’ve added a simple retry function - so rather than immediately declaring a device “offline” when we don’t get an answer after 5 seconds, I resend the request again.
Hopefully this will fix whatever is causing your packets to get lost. If you really don’t want that retry behaviour you can go into the Thing configuration page in Paper UI; under Advanced you can set the “Retries” value back to 0.Hope it helps!
Log issue with BETA-14 i :
2019-05-27 23:01:46.070 [DEBUG] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: No further RM2 device status response received for device
2019-05-27 23:01:46.072 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Could not get status: {}
java.net.ProtocolException: Incoming packet from device is null.
at org.openhab.binding.broadlink.internal.BroadlinkProtocol.decodePacket(BroadlinkProtocol.java:193) ~[290:org.openhab.binding.broadlink:2.4.0.201905262356]
at org.openhab.binding.broadlink.handler.BroadlinkRemoteModel2Handler.getStatusFromDevice(BroadlinkRemoteModel2Handler.java:39) [290:org.openhab.binding.broadlink:2.4.0.201905262356]
at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler.updateItemStatus(BroadlinkBaseThingHandler.java:204) [290:org.openhab.binding.broadlink:2.4.0.201905262356]
at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler$1.run(BroadlinkBaseThingHandler.java:77) [290:org.openhab.binding.broadlink:2.4.0.201905262356]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2019-05-27 23:01:46.076 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Problem getting status. Marking as offline ...
Hey @ciscomike and @nakh_Home,
Thanks for trying out the new binding. Can you just confirm for me that you are seeing the retries property in the Thing config is definitely set to 1?
e.g.:
I just had a thought and if it’s an existing Thing it might not necessarily take the new default value when you load the new binding. If it’s not, please set it to 1 and see what happens. Otherwise, please make sure you’ve got your logs set to TRACE and keep sending me dumps of what happens when a device goes offline. You should see a message at TRACE level like this:
Retrying sendAndReceive ONE time before giving up...
We’ll work this out! 
Thanks! really appreciate!
What is the recommended pollingInterval?
yes, the setting Retries is visible. (my things are defined by text)
The Retrying sendAndReceive ONE time before giving up is well triggered but it do not help
019-05-28 04:08:58.117 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: updateItemStatus; checking host availability at 192.168.1.101
2019-05-28 04:08:58.523 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: building message with count: 39552, id: 03000000, key: D6B8D103D6B8D1030D2C4873439FBE62
2019-05-28 04:08:58.527 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Sending RM2 device status to 192.168.1.101:80
2019-05-28 04:08:58.529 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Sending RM2 device status complete
2019-05-28 04:08:58.531 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Receiving RM2 device status
2019-05-28 04:09:03.538 [DEBUG] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: No further RM2 device status response received for device
2019-05-28 04:09:03.540 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Retrying sendAndReceive ONE time before giving up...
2019-05-28 04:09:03.542 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Sending RM2 device status to 192.168.1.101:80
2019-05-28 04:09:03.543 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Sending RM2 device status complete
2019-05-28 04:09:03.545 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Receiving RM2 device status
2019-05-28 04:09:08.552 [DEBUG] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: No further RM2 device status response received for device
2019-05-28 04:09:08.554 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Could not get status: {}
java.net.ProtocolException: Incoming packet from device is null.
at org.openhab.binding.broadlink.internal.BroadlinkProtocol.decodePacket(BroadlinkProtocol.java:193) ~[290:org.openhab.binding.broadlink:2.4.0.201905262356]
at org.openhab.binding.broadlink.handler.BroadlinkRemoteModel2Handler.getStatusFromDevice(BroadlinkRemoteModel2Handler.java:39) [290:org.openhab.binding.broadlink:2.4.0.201905262356]
at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler.updateItemStatus(BroadlinkBaseThingHandler.java:204) [290:org.openhab.binding.broadlink:2.4.0.201905262356]
at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler$1.run(BroadlinkBaseThingHandler.java:77) [290:org.openhab.binding.broadlink:2.4.0.201905262356]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2019-05-28 04:09:08.558 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Problem getting status. Marking as offline ...
2019-05-28 04:09:08.561 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: updateItemStatus: Online -> Offline
the full logs
Below the offline per device on the last 10 hours
Pay attention that the 4 mini are more stable !
in comparison to the rm2
the offline state is because the thing do not receive update from the device.
i think that the approach should be more permissive.
a “failed Receive” from device should not change the things to offline.
for example,The update for RM is temperature.
i mean its more critical to turn on the AC than knowing the current temperature (the last temperature since 10 minutes is acceptable).
The Same for SP2, MP1 . it’s more important to turn it on or off than knowing the current status and consumption
For A1, the max offline state is 10 minutes, we should also skip it. the items will be updated according to the last successful update. it’s good enough:)
So, i think the parameter should be a boolean ignore Failed updates
Interesting points @nakh_Home.
I will implement the ignore failed updates option (it’s a really good idea!) but will default it to false - so that the existing behaviour is unchanged.
I’m still really concerned that you see so much “flapping” of your devices though. I’ve got an A1, an SP3 and an RM mini 3 and looking through the logs of the last week, the only time I’ve seen them go offline once, and that was when I explicitly turned off my wifi.
Seeing your A1 go offline 69 times in 10 hours is very concerning, to say the least!
I wish there was a way to understand more about what is happening on your network.
Re: polling intervals, I have my A1 polling every 2 minutes.
1 Like
@themillhousegroup Thanks John
I think that by default, a failed received update should throw only warning.
the most important for the users is to have a 100% reliable solution to send RF or IR.
Each day, at 8:00 AM 4 mini are turning off the 4 AC and my RM2 is turning off all the TC2.
a such critical use case should NOT be blocked by the fact that the rm2 temperature is not sent .
I had doubts about network but once again, i have double check several times, in spite that the device is offline, the device is accessible from e-control app. due to this, i assume that’s not a network issue.
the A1 is one meter far from the router:)
The last 12 hours with a polling interval of 120
Reducing the polling interval has reduced meaningfully the offline events
Once again, the mini are stable . o errors on 3 mini and only one.
since the mini are mostly stable, it’s not about network
the ignore failed updates option will improve the reliability solution.
And obviously, i will be glad (and already impatient) to test it:)
Hello John,
I just added the MP1 with USB to the IHC app (took some attempts, but works fine via the App now) and I got this in my log:
2019-05-31 19:44:31.864 [ERROR] [nding.broadlink.internal.ModelMapper] - Device identifying itself as ‘20325’ is not currently supported. Please report this to the developer!
2019-05-31 19:44:31.866 [ERROR] [nding.broadlink.internal.ModelMapper] - Join the discussion at Broadlink binding for RMx, A1, SPx and MP. Any interest?
2019-05-31 19:44:31.868 [INFO ] [nal.protocol.MilightV6SessionManager] - Confirmation received for unsend command. Sequence number: 21
2019-05-31 19:44:31.867 [INFO ] [.discovery.BroadlinkDiscoveryService] - Data received during Broadlink device discovery: from 192.168.1.64:80[78:0f:77:50:03:ec]
Hey Ray,
Thanks for that, I’ve just added the “MP1 3K2U” device with that code.
Obviously with this being a brand-new device I’ve had to take an educated guess at how it will be controlled, so I’ve taken the MP1 device (which had 4 AC sockets) and modified it assuming that the Broadlink engineers would have done the minimal amount of changes to support the new USB ports!
So there are AC control channels: s1powerOn, s2powerOn, s3powerOn
and USB control channels: u1powerOn, u2powerOn
We’ll see if I’m right. Let me know if they work, do nothing, or control the wrong physical outlets!
New version (BETA 15) is here: https://dl.bintray.com/themillhousegroup/generic/org.openhab.binding.broadlink-2.4.0-BETA-15.jar
Hello John,
Thanks for all the good work your doing! it is much appreciated: 
I will test the new beta today and report back, one thing I know already by testing with the App: there is only one channel for the Two USB ports, so it is on/off for the two ports together
Ray
This maybe usefull:
The device code is according to the IHC App: MP1-1K3S2U
The bar code to add the device in the IHC app (If scanning doesn’t work as with me) is 6924826701788
(The IHC App is still mostly in Chinese, Broadlink still has a lot to do there!)
Just added the binding, restarted OH, made sure that its the right beta:
- It was found in Inbox, however when I try to Add it I get error 409: conflict and this in my log:
2019-06-01 08:54:08.309 [ERROR] [home.core.thing.binding.ThingFactory] - Thing factory (class org.openhab.binding.broadlink.internal.BroadlinkHandlerFactory) returned null on create thing when it reports to support the thing type (broadlink:mp1_3k2u).
2019-06-01 08:54:08.315 [WARN ] [g.discovery.internal.PersistentInbox] - Cannot create thing. No binding found that supports creating a thing of type broadlink:mp1_3k2u
How did you integrate your s1 with openhab?
Cool thanks @X-Ray181 - I will adjust the control channels to just have a usbPowerOn channel and try to track down what’s causing that error on discovery
BETA 16 is now available; the new device is now called an MP1 1K3S2U as per the IHC app. One USB channel, 3 AC channels; let’s see how it goes now @X-Ray181:
https://dl.bintray.com/themillhousegroup/generic/org.openhab.binding.broadlink-2.4.0-BETA-16.jar
Next up I’ll see about doing that ignore failed updates feature @nakh_Home
1 Like
Hello nakh_Home,
I worked with Cato on it and he got most of it working (door/window sensors, remote and the motion sensor) in a beta version, but that had other problems, with my MP1’s, who all went Off and than back On with a reboot (Not what you want when you have 6 off them 
) , so it never got to a “Production” version.
Than our friend John made the RM’s stable and @Dmytro_Sorochynskyi fixed the MP1 problem, so here we are!
I’m hoping we can pursuade @themillhousegroup John to pick this up and also add support for this good working security center.
I have the BETA’s from Cato that maybe can help, but they are JAR files, and I don’t know if that would help (if you can re- open them)
Maybe we can sponsor John ? so he can order a S1C kit from Ali, the kit is around 36$
Ray
Thanks for your answer
it could be nice to get it integrated with the add on
to be honest, more than year, that i have an integration through node-red between S1 and MQTT. it works perfectly
i can share more details if you are interested
1 Like
Hello John,
Getting there!, just testid with Beta 16, and I can report that I get 3 power sockets who work! 
But there is no USB channel:
In the log I found:
2019-06-02 11:05:59.939 [WARN ] [ore.internal.thing.ThingTypeResource] - Cannot find channel type: broadlink:usbPowerOn
also using NR to MQTT the RM2
NR is great for doing complex IR flows
@themillhousegroup all my things have a textual definition. Will it be possible to include this parameter in the thing definition?