How do you mean?
For reference I run a TP-Link Archer VR2600 as the modem but all the duties are run from an Orbi RBR50 and it's satellite repeater mesh network.
Yeah, Sorry but I’m not really sure, it was just something that popped out.
Your lights are wifi, communicating to the hub for life360 is WiFi. Etc
It just seemed to be something they all have in common as other users do not seem to be reporting the same combined symptoms.
life 360 is the stock HE app, could never get it to work.
lights are a combo but the Yeelights recently had a firmware update, but again, they are running on the stock HE app.
The issue with the unresponsiveness is really the core issue I want solved urgently, no idea where to start.
I’m thinking that it sounds like a communications issue.
If the signals don’t get through then is the gear going to work correctly ?
Sorry but I don’t think anything I can suggest is going to be quick. 
Could you maybe setup a guest WiFi network off the Archer and attach just the HE and the yeelights to it and test. Reducing the number of variables ?
Have you got conflicting WiFi signals from neighbors??
most of the yeelights are in groups, and it will typically be one light out of 3 that might not turn on.
But like i said, the yeelights are my last concern, it the hub crashes that I need to sort out first.
Can you elaborate on how it’s crashing? 500 error? The device turns to red-light (C4) or blue light (C5)?
when trying to view from the cloud link, i get the "no response from hub"
locally cant access via links ( i get the "no response from hub"), have to get to it via hubip:8081, log out, log in, then reboot.
Has happened every 3-4 weeks for the last 3 months. Pretty consistently between 830-1030am when it does happen.
Hub has a blue light, last time HE support said I had to do a soft reset after to clear the corrupt database due to telenet issues and ive been chasing them since to try and work on what/when/how to proceed / test to see whats causing it.
Sounds like a 500 error. I’m not at liberty to say if the staff is working on a fix or not, but the last I checked they have some ideas and had a possible game plan.
In the meantime, you might find my self-healing hubs thread to be useful. It can detect when this crash occurs and automatically reboot a hub.
hey @adamkempenich - I am running a one hub setup and very much doubt I am a power user. I have maybe 4 to 5 custom apps the rest are all HE ones.
Not sure even by reading your thread i'd know where to start.
Let me see if I can spin up a 1-hub version 
Sorry for the troubles, again. Unfortunately, you are running some community integrations that I have seen to bring hubs down. I suggest temporarily disabling the custom integrations to see if your problems go away. I would definitely start with Tp-Link and Wemo Integrations, and work down the list. Once you identified the custom code that's causing the problem, then you can escalate it here in the community. If your problem persists, then please let us know and we will further research.
If you don't know how to disable apps and drivers see "Disable Device Drivers" and "Disable Apps" sub-headings in the following documents:
What custom apps do you have. I didn’t see them listed. Maybe that’s the cause?
Hi a Steve,
From this photo you’ve posted in another thread
https://community.hubitat.com/uploads/default/original/3X/1/e/1e3d7168216a8b56395a41b5e408781017adb8dc.jpeg
I’d also suggest separating your hubs apart by at least 300mm. More is better and Getting them clear of power packs is also good advice. 
1 Like
They asked me to disable Wemo Connect and TP-Link 3rd party apps.
This is my current list:
- Combined Presence
- Life 360 with States
- Sensibo Integration
- Super Tile
- TP Link Integration
- Wemo Connect
Dave has done a great job with these drivers and I use them and they do work perfectly with a minor tweak. Out of the box the TP-Link drivers don't contain any event filtering and can be very chatty, especially if you set the status refresh period short (1-20 seconds). Because of this chatty behavior, I don't recommended use with HubConnect unless you keep the refresh period to 20 seconds or more.
The issue is that the driver will for example, send on/off events even when there is no change in state, if the device supports setLevel there will be another set of events sent every x seconds.
The tweak (for the Multiplug which I use) was to add a state check on the response coming back from the plug. If you use that driver, you can replace the commandResponse method with the one below. With the tweak, I was able to shorten the refresh period to 5 seconds with no adverse effects and no events being generated unless the on/off state actually changes.
// Device command parsing methods
def commandResponse(response) {
def cmdResponse = parseInput(response)
logDebug("commandResponse: status = ${cmdResponse}")
def status = cmdResponse.system.get_sysinfo
def relayState = status.relay_state
if (getDataValue("plugNo")) {
status = status.children.find { it.id == getDataValue("plugNo") }
relayState = status.state
}
def pwrState = "off"
if (relayState == 1) { pwrState = "on"}
// srwhite: Modification to reduce event load on hub, only send a switch event if anything has changed.
if (device.currentSwitch != pwrState)
{
sendEvent(name: "switch", value: "${pwrState}", isStateChange: true)
if (type() == "Dimming Switch")
{
sendEvent(name: "level", value: status.brightness)
}
logInfo("${device.label} is ${pwrState}")
}
// /srwhite
if (shortPoll.toInteger() > 0) { runIn(shortPoll.toInteger(), refresh) }
}
Tagging @djgutheinz
2 Likes
Interesting. I thought if there was not a state change in an event, the system would not forward it to subscribed applications
@mike.maxwell???
1 Like
It may be a bug...
But I have witnessed this behavior before and have adjusted some of my own code to deal with it.. Here's an example of it from the Multiplug driver, prior to my change. I was using a 3 second polling interval. You can see it was generating an event for each update and also writing it to the database.
| switch | off | DEVICE | 2019-11-10 12:27:05.117 PM EST | |||
|---|---|---|---|---|---|---|
| switch | off | DEVICE | 2019-11-10 12:27:01.725 PM EST | |||
| switch | off | DEVICE | 2019-11-10 12:26:58.331 PM EST | |||
| switch | off | DEVICE | 2019-11-10 12:26:54.904 PM EST | |||
| switch | off | DEVICE | 2019-11-10 12:26:51.522 PM EST | |||
| switch | off | DEVICE | 2019-11-10 12:26:15.004 PM EST | |||
| switch | off | DEVICE | 2019-11-10 12:26:11.538 PM EST | |||
| switch | off | DEVICE | 2019-11-10 12:26:08.235 PM EST | |||
| switch | off | DEVICE | 2019-11-10 12:26:04.939 PM EST | |||
| switch | off | DEVICE | 2019-11-10 12:26:01.649 PM EST |
1 Like
It has been my experience that integrating wifi devices with HE equals problems. I have slowly been phasing out my TP-link bulbs and plugs (down to just 3 bulbs now) and moved some cloud devices back to SmartThings with HubConnect relaying info back to HE. I would be suspicious of any device that relies on Lan or WiFi to communicate with the hub. For whatever reason, turning on a group that includes zigbee devices plus Hue or TP-Link results in either a delay, or the zigbee devices not responding to the command at all, which makes me think the command fails to get sent for some reason. This is just my experience though. BTW, I tried to connect the TP-Link devices to SmartThings a couple months ago and the SmartThings integration was unusable. It was so bad that I couldn’t believe they could advertise it as an option.
2 Likes
hey @srwhite,
currently I only have 2x HS100's, not running hub connect and have the refresh set to 30minutes - so im not sure if any of my setup falls under what you were describing.
