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.
Hey Ken,
I more I go on the more I am thinking this as well. I have 4 power plugs/sockets I use for bulbs/fans/etc and about 14 yeelight bulbs (wifi). The yeelights are always having telnet issues and support have said that "something" is causing the connection to stop/close the telnet socket.
Problem is the yeelight app is a stock HE one and ive been having this problem for months.
1 Like
To update this i've moved my wemos off HE and set them on the own schedule / iOS. next will be to move the Tp link plugs off HE and just have to control them manually with the iOS app (maybe replace them with zigbee/zwave ones). And maybe I need to move my sensibos back off HE as well and use the Alexa plugin.
Just annoying as these are "smart devices" but without offical support I cant have them on my hub without issues.
I've seen exactly the same thing with my custom LAN/Cloud drivers so you are not alone. I reduced the events the same way with a simple conditional check.
1 Like
Fast polling is off and the refresh rate is 30mins. I don’t anticipate that causing any issues.
Yep - didnt think it would/could
1 Like
I am in the process of updating the Drivers for the plugs. It will check the received state versus the current system state and then update only if there is a change. It will increase processing.
Suggestion: Fast polling should only be used IF you need the fidelity. I did this reluctantly but with the realization that YOU own the hub, not me. I can not guarantee the performance for rapid polling in all circumstances and the HUBITAT team should not have to either. It is stressing the system beyond intent.
Dave
I said I wasnt going to do this, but bloody hell when this hub runs without issue for a few weeks its bliss. Also got myself two of the HGZB-FS fan controllers and so keen to tie them in and give them a run (I need about 7 in total) they look a lot nicer in person than the listing.
1 Like
This is actually a very confusing issue, for the Ikea documentation, itself, both online and included with the product, claims that their Trådfri Zigbee lamps require an Ikea hub, but also that they are Zigbee certified. As a test, I ordered one of their 1,000 lumen A19 CT lamps and two of their candelabra base lamps (the only such lamps I can locate on the market). The former paired immediately as a generic Zigbee CT lamp, but, at first, the candelabra base lamps wouldn't pair and, apparently, I couldn't reset them according to supplied instructions. I did a little research and found that the lamps do reset, but they don't flash as advertised when this is done, and that they must be close to the hub when pairing. I found an old candelabra table lamp, set it next to my Hubitat Elevation C-5, and they paired immediately. I then moved them to wall sconces in another room, and they continue to work perfectly. So, Ikea is just trying to sell their hubs though they're not necessary. I do have a minor issue with the 1,000 lumen CT lamp in that, in the normal warm white color temperature range, they appear a bit greenish, but that's just a nit. Good luck, Jeff.
Hello Steve:
I see that you're getting Nue (Zigbee) equipment.
I recently got two of their outlets, to replace 2 Orvibo (Livingwise) Zigbee outlets.
First of all, I must admit that I'm writing this from a North American perspective - your mileage may vary!
They are very unusual (i.e. different) because:
- the electrical box part is VERY large - almost didn't fit into a standard NA metal outlet box
- there is a thick glass plate on the outside(customer facing) part of the outlet (just like your switch) which makes it stick out from the wall! (And, is very obvious!)
- they didn't have 2 outlets - just one, with 2 USB slots
They are also one of the very few sources of outlets that are Zigbee.
(Sinope is coming out with one in the new year).
1 Like
cheers for that info - very keen to get it installed and see how it all fits up.
Ok, pretty much the largest piece of my puzzle left is Presence.
It has confused and frustrated me to no end and I need it nailed down.
I currently have:
My iphone
- HE app running high battery accuracy option
- Life360 free version
- static IP wifi presence driver
My wifes iphone
- HE app running high battery accuracy option
- Life360 free version
- static IP wifi presence driver
Then I have combined presence, that if HE, L360 or wifi see someones home, set to correct mode, if either HE or L360 leave, set mode to away
but the problem is they keep bouncing between home and away as per the example.
How can I fix this, I want Perfect Presence.
I think I’m combining Life360 AND HE App AND WiFi presence into a single virtual Combined Presence Device then using that to change Modes.
I’m currently unable to confirm that but am pretty sure that’s how it works.
It’s been working very well for me.
I have one of these virtual Combined devices for every person.
