Performance issue with lots of System Events?

I'm wondering if having lots of Location System Events could cause a performance issue. I'm asking because I see an event there every 5 minutes from the Konnected (Connect) app:

|Name|Description|Value|Event Type|Date|
|ssdpTerm||urn:schemas-konnected-io:device:Security:1||2020-04-09 08:34:05.941 PM EDT|
|ssdpTerm||urn:schemas-konnected-io:device:Security:1||2020-04-09 08:09:07.530 PM EDT|
|ssdpTerm||urn:schemas-konnected-io:device:Security:1||2020-04-09 07:59:07.403 PM EDT|
|ssdpTerm||urn:schemas-konnected-io:device:Security:1||2020-04-09 07:54:06.330 PM EDT|
|sunsetTime||2020-04-10T23:43:00.000Z|API|2020-04-09 07:42:00.233 PM EDT|
|sunset||true|API|2020-04-09 07:42:00.088 PM EDT|
|ssdpTerm||urn:schemas-konnected-io:device:Security:1||2020-04-09 07:29:07.127 PM EDT|
|ssdpTerm||urn:schemas-konnected-io:device:Security:1||2020-04-09 07:19:08.091 PM EDT|
|ssdpTerm||urn:schemas-konnected-io:device:Security:1||2020-04-09 07:14:07.029 PM EDT|
|ssdpTerm||urn:schemas-konnected-io:device:Security:1||2020-04-09 07:09:05.973 PM EDT|

I know this shows up because of this in the Konnected (Connect) app:

def initialize() {
  runEvery5Minutes(discoverySearch)
}

// Device Discovery : Send M-Search to multicast
def discoverySearch() {
  logDebug "Discovering Konnected devices on the network via SSDP"
  sendHubCommand(new hubitat.device.HubAction("lan discovery ${discoveryDeviceType()}", hubitat.device.Protocol.LAN))
}

def discoveryDeviceType() {
  return "urn:schemas-konnected-io:device:Security:1"
}

Most of my System Events are "urn:schemas-konnected-io:device:Security:1" because it runs every 5 minutes. I'm just wondering, how much load does this put on the hub?

Overall, while some overhead, it is nothing to be worried about (at every 5 mins)

There are several devices in HE that always log and don't follow the norm of being able to disable logs (except for warnings or errors). Use of ssdp is one of them, as is garage door openers.

If it was happening many time a minute, bigger issue. Events are in the db, so the overhead here is not only logging, but db accesses, which are in general a weak point for HE.

1 Like

Agree with this statement completely. I have around 80 Zigbee devices and that hub has a tons of logs from temps, humidity, power, etc. One of the devices is an integration with my wired alarm panel, not via connected. For every door, window, and 3 wired motions events are generated. With kids home 24x7 now there is a ton of traffic. That hub has been performing just fine though will admit I am in the multi-hub club. I have my split by protocol: Zwave, Zigbee, LAN, and coordinator.

1 Like

Thanks, both of you!

I didn't notice any slowdowns, but I do want to keep my one hub responsive and I'm not planning on adding more. I reduced the spammy log entries from the Konnected app (which also allows me to see potential problems over a longer period), but the ssdp events kept coming. I'm going to ignore them...

Boy, the community members here are fantastic! I just installed my konnected.io boards and noticed the exact same issue. Thanks for the information. Is it possible to put a // in front of the log debug line so I don't have to see them, they seem to just clutter the stuff I ready care about. Thanks in advance.

There is a pending pull request for Konnected on GitHub that reduces log spamminess. When that's merged, you'll get fewer log entries if you disable the debugging log (which was also a missing setting). I did those modifications, and they work well for me. I just don't think it's been merged yet.

That said, yes, absolutely, you can comment the logging and it will stop.

Thanks Brian for the information and the promt response.