To summarize, in this google sheets, all the offline status are logged since 24 hours
the good news is that my 4 mini are working perfectly
Error for rm2
2019-05-23 05:31:16.113 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: updateItemStatus; checking host availability at 192.168.1.101
2019-05-23 05:31:16.177 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: building message with count: 18070, id: 03000000, key: D6B8D103D6B8D1030D2C4873439FBE62
2019-05-23 05:31:16.180 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Sending RM2 device status to 192.168.1.101:80
2019-05-23 05:31:16.182 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Sending RM2 device status complete
2019-05-23 05:31:16.184 [TRACE] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Receiving RM2 device status
2019-05-23 05:31:21.186 [DEBUG] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: No further RM2 device status response received for device
2019-05-23 05:31:21.187 [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) ~[191:org.openhab.binding.broadlink:2.4.0.201904152359]
at org.openhab.binding.broadlink.handler.BroadlinkRemoteModel2Handler.getStatusFromDevice(BroadlinkRemoteModel2Handler.java:39) [191:org.openhab.binding.broadlink:2.4.0.201904152359]
at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler.updateItemStatus(BroadlinkBaseThingHandler.java:204) [191:org.openhab.binding.broadlink:2.4.0.201904152359]
at org.openhab.binding.broadlink.handler.BroadlinkBaseThingHandler$1.run(BroadlinkBaseThingHandler.java:77) [191:org.openhab.binding.broadlink:2.4.0.201904152359]
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-23 05:31:21.190 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: Problem getting status. Marking as offline ...
2019-05-23 05:31:21.191 [ERROR] [handler.BroadlinkRemoteModel2Handler] - rm2:34-ea-34-c7-c9-15[^]: updateItemStatus: Online -> Offline
About the Rm2, i have seen something strange in the log. it’s changed twice from online to offline see below
I just ordered one off these on Ali:
Its an MP1 with 3x 220 sockets and 2 USB ports, you can also switch the USB ports on/off, hope they work with the binding, will report back!
Ray
Wow that is pretty cool. I can think of quite a few “novelty” USB-powered items (fans, lights etc) that are unswitched that can now be controlled.
It looks like this device will probably have a unique identifying code when the binding discovers it - make sure to check the OpenHAB logs when you first plug it in - the Broadlink binding will log a message to the effect of "I couldn't recognise this Broadlink device, please post the following ID to the forum: {xyz}" (!)
Once you let me know how it identifies itself I can spin up a new version of the binding to support it. Might need your help to debug it too
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.
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?
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...
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
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
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.
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:)
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.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!
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
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
nakh_Home:
