C4 hub running 2.2.8.151 but this has been occuring with a few of the previous releases as well..
Simply put this is a dev C4 that doesn't do much. Really all it does is run Ecobee Suite, Chromecast integrations, and maker API with 3 devices. It has been running fine for probably a month and even early initial 2.2.8 releases.
Recently I added a new flow to Node Red and created a Virtual UPS driver to the hub. The flow is designed to only send updates when needed, but a few items on the device do update frequently. Also the data provider for Node red requires a 10 sec Inject. The flow is adjusted to prevent repeat updates to Hubitat as much as possible. Most items that don't update have a deduplication step to prevent multiple submits to Hubitat. The 3 items that change frequently have been updated to run from a single stream submited the change once every 10 seconds.
Well the point of all this though is to ask the question why the C4 is getting hammered with CPU Load when this flow is running. The device driver doesn't show any high CPU in runtime stats. All it does is post the change from the command via maker api calls. But the hub shows sever CPU Load. This is clearly related to this UPS data from Node-Red via Maker API because if i disable the updates from Node-Red it the CPU issues seem to go away.
Does the system really struggle with 3 updates to 1 device every 10 seconds.
If configured wrong, this could be the issue. There are multiple recent threads about this. This thread has some suggested settings that might help mitigate the issue.
Though I understand why you would go there I am pretty sure that isn't the problem. I have been following that thread actually and made the configuration change he suggested. I am also 100% sure that this didn't start until i started using this virtual device for the UPS and sending updates from Node red after getting updates for the UPS.
Yea. I have. Here are some graphs from Grafana that show my C4 hub usage. The peaks are were i have found it maxed out a few times. The yellow brace shows time where i turned it off. The green arrow shows were i turned it on last time and it gradually built up until it suddenly ramped to near 100%.
The flow has evolved a few times. At first created the driver with a command for each status it had. Then the flow submitted each command on each call every 10 seconds. That was chatty but didn't seem to kill it the hub to bad ans was moatly POC. Then I added a command to the driver to do all the updates at one time in one command. That seemed to be when this all started. This update passes like 10 parms with some numbers and some strings. Since then now the flow has a combination of both where the single command updates address items that infrequently change and i use a node to prevent it from continuing if the value doesn't change. The values that change pretty regularly i left consolidatedin the single uupdate command.
The last thing I did was to add a new inject node for the command that passes multiple parms to break it out so that would only process every min instead of every 10 seconds.
You could also consider sticking a delay node(s) configured as a rate limiter right before any command node(s), too. I've done that a few times when there were flows I couldn't figure out why they would get "bursty" or spammed commands on occasion.
