TP-Link binding and refresh interval

Hello fellow OpenHAB users.

I have a situation that I have been fighting with for some time and just can’t figure out the solution. First a summary of my setup. I am using OpenHAB2.5 running on a Windows 10 workstation. I have several Things/Items configured from various vendors. One of those vendors is TP-Link. Everything works as I would expect with one exception. The refresh time set for TP-Link Things is not being used. I have some rules created that do different things when a light turns on. for example, if I turn on the Chandelier, then the potlights turn on. Ideally, I would like this to happen within a few seconds but it is taking several minutes. At first I thought it was the potlights were not updating timely as they are Tradfri potlights, but recently figured out that it is actually TP-Link that is not getting refreshed.

When I turn on the chandelier within PaperUI, the potlights immediately turn on. However, when I turn on the chandelier via the wall switch, the item in control panel for the chandelier doesn’t update for several minutes. I have tried different refresh values in the thing with no change. I have tried clearing the cache and TMP files with no change. I have tried both the official TP-Link 2.5 binding as well as the Eclipse Markeplace binding. No change.

If I had to pinpoint a time when this stopped working as expected, I would say it was when I upgraded from 2.4 to 2.5. Does anyone have any thoughts as to how this can be fixed? The above example is one of a few rules that I have that work along the same lines and all are not refreshing timely. Any suggestions would be appreciated.

Thank you,
J…

I would first look in your events.log , so that you can see what happens when, rather than guessing cause from effect. In particular, you would be interested in timestamps of changes to whatever your chandelier Item is. We’d be interested in what actual device is involved - a TP-Link something or other?

Have you looked in your openhab.log for general error messages, that might slow things down?

There is nothing unusual in the log files. The only error I get when I start the openhab service is below and I don’t see it being the culprit. Thanks for the suggestion though.

2020-04-21 09:54:08.495 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.ArrayIndexOutOfBoundsException: 1
at org.openhab.binding.wifiled.internal.discovery.WiFiLEDDiscoveryService.discover(WiFiLEDDiscoveryService.java:107) ~[?:?]
at org.openhab.binding.wifiled.internal.discovery.WiFiLEDDiscoveryService.lambda$0(WiFiLEDDiscoveryService.java:64) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_201]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_201]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_201]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_201]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_201]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_201]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]

Looking in events.log was not about expecting to see anything unusual, rather to see the sequence and timing of events that matter to openHAB. Show us what you describe.

True. I will take a close look to exact timings and see what happens.

Thank you,
J.

After much trial and error and upgrading to 2.5.4, I think I have narrowed down what is causing this. Why it is happening is still a mystery but it appears that the chromecast binding is causing some issues. When the chromecase binding is installed, there is a large delay in my TP-Link items updating when a change is physically done from the switch. Uninstall the chromecast binding and TP-Link items update almost immediately. Any thoughts on why?

Thank you,
Jason…

I think chromecast binding has been implicated in weird before. The only example I could find quickly -

That is unfortunate. I like the chromecast binding. I use it for various different things like sending messages to individual Google Home Devices. Hmm. Will have to think that one over a bit.

Thank you,
J…

Odd. I have lots of TP-Link and Chromecast devices, and they’ve never caused problems for each other. I’m only on 2.5.2, but I’m not aware of any changes in those bindings in 2.5.4.

Something else you might try is putting the binding back, removing all of your Chromecast devices, and then adding them back in one by one to see if the culprit is actually an item as opposed to the binding.

1 Like

That is one of the first things I tried was just adding items back one by one. Have you verified that when you manually turn on/off a light from the switch that the item in Openhab updates in an appropriate time? Everything works fine except that.

Thank you,
J…

I can verify similar issues with tp-link devices. The ones that I have that trigger rules work within 1-2 seconds most of the time but every once and a while can take a 1+ minutes to trigger. It’s not consistent, but it’s been observed. Similarly, something is strange enough with the tp-link refreshes that mutual “follow” profiles with tp-devices, which apparently should not create loops

do, in fact, create loops resulting in some truly bizarre lighting displays.

It’s never been a priority for me to track down, so I’ve never implicated my chromecast binding, but I might be able to do some testing in the near future and see.

Yep, I manually trigger switches all of the time and there’s no significant lag.

So, new question: do you have the problem if you have the Chromecast binding installed, but no active cast things or items?

I have two home minis which are always on and connected to the chromecast binding and I rarely see the issue. But, my two actual chromecast devices are rarely on, which may explain why I rarely see the issue.

@JustinG, that question was for @killarneygetaway. :wink:

It appears to only be an issue once I add things/items. Just having the binding installed doesn’t seem to have the same effect. However, I have not tested this longer term. Usually just a few minutes. I will try leaving the binding installed for a few days and see what happens.

J…

What cast devices do you have? I’ve got:

  • Google Home Mini (v1)
  • Google Nest Hub
  • Chromecast (v1)
  • Chromecast (v2)
  • Chromecast Audio

Also, do you reserve IP addresses for devices on your network? It shouldn’t matter, but I assign IPs to any network devices connected to openHAB. I started doing that for an automation app I was using a long time ago, so I just continued the practice when I moved to OH.

Google home, google home mini’s, nest hub display along with a Lenovo display. I have chromecast devices as well but removed them as part of my troubleshooting and haven’t added them back. Yes, I too use static IP’s for all my devices.

J…

Darn, I was hoping for an outside chance that it was an IP issue.

At this point, the only thing I could think to try would be backing up your system and then clearing the cache to see if that wipes out a weird conflict you can’t see.

I am willing to try. Would someone be kind enough to provide instructions on clearing the cache on a windows 10 system? I can only seem to find details for linux systems.

Thank you,
J…

I’m on an RPi, so I can’t help you in this regard. I suspect that there’s a cache folder that you can delete, but I wouldn’t know where to find it.