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.

I have a ton of these logs. 8 Konnected boards. Any way to disable this?

You can comment the log like @jricard212 said

"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."

1 Like

Thanks

Is this the correct line? So this is what it is like after the change

def discoverySearch() {
  //logDebug "Discovering Konnected devices on the network via SSDP"
  sendHubCommand(new hubitat.device.HubAction("lan discovery ${discoveryDeviceType()}", hubitat.device.Protocol.LAN))
}

UPDATE: still have the logs @jricard212 can you please provide the line that you commented out

Yes, that was the line, but it did not stop the messages in the system event log. I have just been living with it, it does not seem to affect performance.

Yes, the other logs are from the Hubitat system. You can't get rid of those.

if you're referring to the ssdpTerm messages in the system logs, this is actually an issue with the konnected app leaving the location subscription active after device discovery is complete.
If the konnected app calls unschedule() when discovery is finished, these will go away...

so i we already have it running where can we update the app and put an unschedule in to fix it or do we have to remove and reinstall. thanks

add unsubscribe() to the apps updated method should do it, updated fires when done is clicked in the app..

I remember this now.

Go to the Konnected child app(s) and disable device discovery. I'm pretty sure that will stop the ssdpTerm events.

1 Like

weired i went to go do that but it seems like its designed to do that every 5 minutes? and it already has an unschedule() in the fx.

ie

def updated() {
log.info "updated(): Updating Konnected SmartApp"
unschedule()
if (debugOutput) runIn(1800,logsOff)
initialize()
}

def uninstalled() {
log.info "uninstall(): Uninstalling Konnected SmartApp"
}

def initialize() {
runEvery5Minutes(discoverySearch)
}

unless this app is actually capable of tracking device ip changes, there's no point in scheduling
discoverySearch every 5 minutes...
and honestly even if it is, the konnected device should have a static dhcp reservation or fixed ip address...

Mine has a static IP, but lots of people don't do that, so it may move around. They're trying to prevent support issues from the device moving on the network. People is dumb...