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.
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:
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]
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?
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.
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.
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.
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.
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.
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.