May be some slowdowns on the new C-7 hub (I saw some on my unloaded C-7 last month. Try editing the app driver, line 554
From: timeout: 5,
To: timeout: 10,
This may correct the problem.
Dave
I found the line at 551, it was set to 3, changed to 10.. same issue..
Depending on how new the device is. I would not update a HS100. Very old devices have the same issue. Updating may be to "improve security" and disable LAN comms for the device.
1 Like
Just a note - I am having trouble finding devices and noticed that the app code assumes the local LAN is a /24 range. My local IoT LAN is a /16 range.
I can understand why you did it this way, but I'll put in a feature request for native support for other LAN configs than just /24 subnets. 
Thanks!
And, I just realized that's what the alternate lan segment thing is for. Sorry!
That is ok. Next version of app will likely be out soon. It allows entry of MULTIPLE LAN segments simultaneously - and it has been tested and works. There are some other improvements to account for recent Hubitat changes to the discovery. If you are missing devices in discovery, get with me and I will make a beta app available for you.
Dave
1 Like
I have the issue where none of my devices on different lan segments are detected. I tried putting in various forms of an alternate Lan segments such as 192.168.1.1, 192.168.1.102 (actual IP), 192.168.1., and 192.168.1.0/24 and none of them detect my devices. Would be happy to try the beta version.
Thanks
I recently discovered something new about my Kasa devices, some of which are in my workshop and some in my home.
The two places are connected by wifi (router/access point server/access point client/router/wifi, There is a hub in each location.
I initially had all the devices connected via the app in the home hub. The devices all worked as they should but I kept getting error messages for some of them. The other day I realized that the troublesome devices were all in the workshop.
I resolved the problem by running the app separately on each hub and selecting for inclusion only the devices co-located with the hub. No more error messages!
But I can't say for sure whether the problem itself was a router/wifi issue or a hub issue.
Mike M.
I'm getting notifications that 20-ish tp link devices are offline each day but I should only have a handful of devices on the other leg so I'm not sure what's causing the issue or maybe if it's just a time in reporting. I have re-ran the app multiple times thinking maybe I got some IPs out of whack or something but I keep getting the 'false' device offline notifications.
The other weird thing is the devices don't really seem to be offline (they are able to be controlled remotely).
I'm not sure how to go about DXing what could be causing my device monitoring to flag these tp link devices each day.
Sure, these notifications started appearing about the time the code for dual segments was added, but so was my monitoring. My query is looking for anything that's not in active or online $status. I'm not sure if maybe that query is too vague and there's nother status the tp link devices COULD be in that's causing them to be flagged.
An alternate Lan segemt would be the form 192.168.1. You added the device element.
What is the explicit message and where is it appearing???
Yeah that segment string doesn't return devices. I have a switch, smart plug, and light strip and none of them show up. They work on the same segment as theb hubitat though, then I removed them and tried adding on the new network.
First, some confusion here.
- 192.168.1 is not one of the segment listed in your original message. So you retried?
- By separate network, do you mean a separate segment on the same LAN?
Should work; however, a new app version is coming out next week to account for some Hubitat infrastructure changes, That may solve the problem. Until then, try putting them back on the same segment.
It's wherever webcore is looking for the $status of the devices. I did some digging to try to find you whatever information I could:
Webcore is looking for any that are not in online or active status
Here is a list of devices it captured today:
I cant validate if every single one of these has been on the list every day but I know several of them have appeared multiple days in a row.
For instance, fountain pump and fountain light keep hitting my query but when I tried to control via voice, it worked flawlessly.
Then I noticed a trend in the devices I had not yet noticed. All of these devices are ones that I don't use regularly and/or not tied to any automations.
I realized it when I saw this:
It's saying the last activity was a couple days ago which is probably accurate but the polling is still 30 minutes.
In looking at the device page, there's no $status so I'm not sure what value it's using but its definitely detecting the device hasn't been touched and its saying its inactive.
I think given this information, I should adjust my webcore query unless you have a more elegant way of saying "this device is offline, pay attention to me" that I should be looking for.
Currently, I'm not 100% sure what webcore is using to make this determination 
Water supply valve is not tp link. All other devices are tp link.
Well, embarrassingly enough - it's not the app! I spent all night trying to figure out why the hubitat couldn't reach the devices even though I could with kasa-python, and ended up doing a full packet capture on the interface, realizing that no traffic was being sent out with the 'discover' button. I ended up removing the app entirely along with the one working device, rebooting the hubitat, and reinstalling the app. Now discovery and adding works on additional network segments. No idea what went wrong there.
First, I have nothing in my design to accommodate webCoRE; so I can not say what is happening. If there are instructions, I will be glad to look at them to see if it is feasible.
Health for my devices is expressed in commsError. When this is set, the device is not reachable from Hubitat and my app (for many possible reasons). Once set it will stay true until a successful communications is completed. The code will try to correct this once by polling all devices and changing any modified IP addresses.
commsError being true does not stop Hubitat from completing refresh/poll intervals at 30 minute intervals. Again, if it corrects the problem the errror will be cleared. If you want to track, you could poll every 1 hour for the state of commsError.
Thanks for the info. I will look for trends for this.
That is true. I block sending events if a change has not occurred in the attribute value. This was because the Hubitat system (at one time) was not filter out no-change events and therefore causing rules to fire even though the event had not changed.
Based on this information, I think I want to change webcore to match the comms error section in the tp link devices and then leave as is for everything non tp. I'm not beholden to any particular configuration of searching for offline devices as long as it's accurate (the one im using is just one I copied off the internet).
I'll take a look at this tomorrow and see what I can work up. Thanks for the feedback.
