Slow web interface

That is to be expected. Is it consistently as high as 45seconds?
Mine spikes every night at 2am but it rarely goes above 20 seconds.

Yeah I do expect it to be higher during the maintenance, it just seemed higher then most others that have posted their results.

Usually its around 25-30 seconds on average.

Yup.
I assume you are using the perfMon through node-red. Are you also collecting logs and events through NR and if so, are you using the Maker Api calls to fill in gaps?
I had to spread out my timers in NR so that the Maker Api calls didn't coincide with the Performance Monitor calls becasue it ended up creating huge spikes....especially if they occured during maintinence.

I have a flow setup to write the events to my InfluxDB and a flow that refreshes the devices. Both of these use websockets though, not the maker-api.

I am not collecting logs either.

How do you refresh the devices without maker api? Do you store the values in NR and resubmit to Influx?

Using the below flow.

1 Like

Thank you. I will check it out his afternoon. I would love to replace my maker apip calls as they puts quite a load on the hub when called.

Yeah I had the same issues when I tried the maker-api it created a lot of overhead. This flow has been working good for me for at least a couple weeks.

@raidflex, I get the following in my debug logs when query/update influx db flow runs (every 5mins)

Error: A 400 Bad Request error occurred: {"error":"unable to parse 'temperature,hub=HE1,deviceId=97,displayName=,unit=°F,synthetic=true value=74.02 1556917658433000000': missing tag value"}

Error: A 400 Bad Request error occurred: {"error":"unable to parse 'battery,hub=HE1,deviceId=145,displayName=,unit=%,synthetic=true value=98 1556917658441000000': missing tag value"}

Thoughts?

Edit:
Manually ran the db query and got a blank value for displayName at the front end. Not sure why and I doubt this is normal

Got it sorted out. Had to POST the following to the DB.
DROP SERIES FROM temperature WHERE displayName=''

Interesting.... Ever since applying the 2.0.9.133 hot fix yesterday my response time has improved. You can actually see right around 11:30pm when I applied the update yesterday it drops and stays lower. Not sure if this is just a fluke but I am not complaining. Also there seems to be less variances throughout the day. There have been no other changes to the hub or any new devices added/removed.

Looking at the changelog I do not see anything that could have affected the performance. Even the duration of maintenance seems to be shorter.

Yesterday:

Past 24 hours:

1 Like

Yes, I'm seeing a dramatic reduction as well. Since the update, I've not had any notifications, except for one that was during the maintenance window right after reboot (which the script doesnt cater for).

Mine showed the same since updating to 2.09. It's been a few days now and since swapping from Maker Api pulls to the Influxdb Refresh you shared, I no longer have any spike in the maintainence window. Smooth seas so far.

After having issues with my Zigbee radio dropping and support recommending a soft reset, there was another side affect. Not only has my Zigbee radio not gone offline, but my response times are even better!. Even the maintenance period seems to be shorter.

2 Likes

Out of curiosity, what steps does a ZigBee radio "soft reset" involve?

The soft reset actually erases the hub. Basically you go to the below URL and it will allow you to erase the hub and then you just restore from a backup. You do not need to erase the stick, which has all the device info on it.

http://hubip:8081/resetHub

So is it correct to say the backup will restore all devices and all rules, lighting and locks and the safety monitor?

It only restores the automations (including HSM), not devices. The devices are stored on the stick, at least on the C4 hub. Not sure about how it works on the C5, but I would imagine the same way other then the radio is internal now. So when you perform a soft wipe the devices are not touched.

1 Like

Fantastic, thank you!

I'm doing this tonight and I'm certain I need it because my ST hub has become the faster of the 2 hubs.

From when I left ST about 7 months ago, the speed has dramatically increased, but in no way should it be faster than HE.
I have all my shitty osram bulbs and Sylvania gardenspots on ST, since they are not mission critical. Oh and my Halo+ smokes are on the ST hub, since hubitat does not support the nws alerts on these devices. I digress....

There's plenty of discussion about bulbs and that it's a good idea to have their own Zigbee network so as to not interfere with everything else Zigbee. Using Hue, a 2nd Hubitat, or as you've done, a "spare" ST hub (although cloud) helps, I imagine.