OK, forget about all Devices, Automations, Environment, etc ...
How about GUI responciveness and navigation across GUI pages?
In a past opening say, a Devices page was balasing fast, near instant. Right now it takes very noticable delay for opening basically every page.
What is this about? How do you explain this phenomena?
Or this just happens only in my specific setup?
That one I can confirm as a step change in performance. We'd have to as @gopher.ny what changed in 2.4.4.x, as I saw an immediate change in how quickly the hub's "Apps" web page loads.
While I did see this change, I never bothered to report it as it really did not impact my ability to do work on the hub.
I have a Node-RED flow that I have been running for years that measures how quickly the "http://192.168.1.144/app/list" URL responds. After upgrading to 2.4.4, I noticed the step change in my InfluxDB/Grafana hub monitoring tools.
1 Like
That's interesting. I'll check it out.
5 Likes
I am on 2.4.4.135, I haven't noticed any difference.
I have noticed it has just gotten slower over time as I add devices, going back before that update. I currently have 437 devices total, and it is taking about 4-5 seconds. About 60 apps load in 2-3 seconds.
What model hub?
My "Prod-C8" shown in the graph above is actually a C8 Pro. The Dev-C8 is a regular C8.
I have 126 Apps (expanded all apps, so child apps are also shown) on my C8-Pro, and that page loads in under 1s.
I have 265 Devices, and that page loads within about 1.5s.
The only way I knew there was a step change in performance was from the Grafana chart above, which is why I did not report this as an issue during the beta process. I could not perceive a step change, but the data does not lie.
2 Likes
Little comment: This is not just a Browser Load Times problem.
The Browser Load Times is just nothing motre than a very well visible and noticable indicator for all that underlying delays.
Which underlying delays are you referring to? If they affect one protocol more than others, then it's the specific protocol. If delays impact more than one protocol, then you have to start the investigation with what is more widely reported, like browser loading times, and go from there.
I started that ZWave Performance topic yesterday from which you created this one.
I am not sure why this is not clear.
I have 285 devices and it takes around 2 seconds to load my device page on my desktop. If going through the iPhone app and connecting to the hub that way the device list comes up almost instantaneously. When I was on android using the android app it took about 4 seconds. So depending on the connection media the time does vary but like you on my desktop I have not really seen much of change on load time. The biggest impact to load time was adding all the devices.
Apps page loads in around a second with well over 200 rules/applications.
I have a C8 hub
Well, if you don't believe the problem reported on the other thread is strictly related to the Z-Wave Performance, but rather the overall performance of your hub, then you may want to clarify that in your first post.
Folks are trying to help you improve the Z-Wave experience based on the feedback you asked in your opening statement.
3 Likes
OK, let me make it clear.
Yes, the hole discustion is about hub performance, not just a ZWave. This is my mistake. It happens to be the ZWave is very sensitive to sotmething hub-internal and I used it as an indicator for degraded performance. Than when I pointed to a slow GUI this was interpreted as only GUI related problem but it is not. The GUI is another indicator for the degraded hub performance.
Now, plase correct the original topic header to what ever you think is appropriate or forget about it all together. Frankly, I don't want to continue a non-constructive conversation just spiroling aronund the same things. The good news is - finally the attention was paid. I hope looking what is going on with GUI will reveal an deeper underlying problems and they will be addressed. Better late than never. I guess my goal was (partially) achieved - finally the attention was paid.
1 Like
Depending on the platform version your hub is running, the overall performance degradation may be resolved by something as simple as disabling a specific integration—like the chatbot, for example.
We recently identified a bug that could contribute to performance issues under certain conditions, and fixes are already in place.
This is exactly why it’s so important to provide feedback based on concrete observations and details, rather than inferred assumptions. The more specific information we have—logs, steps to reproduce, timing patterns—the faster we can isolate the root cause and get you a reliable solution.
Implying that the issue is inherent to one protocol or another doesn’t help move things forward, can be misleading, and may end up wasting everyone’s time.
6 Likes
I did not enable a chat bot.
And what it is (I hope this is not a BIG secret)?
I really cannot understand how enormous amout of logs can help in this case. Before making this noise I did try to enable logs and analyze them. Unlike logical problem (easy catch and fix) this random behavior is imposible to pinpoint with just the logs. But there is no other debugging tools available for the end user. Maybe I am spoiled with my EE experience when I can add instrumentation around the problem (extra HW and/or SW just for the degugging reason), catch it and fix it.
I was just noticing the opposite on mine. After the update that disabled the background chat if it had not been user enabled (not sure if it is related or not). I even made a post about it. (C7)
Loads faster in a browser and in the mobile app for me. (Still not "instant." But, before it was literally 10-20 seconds, now just a few)
2 Likes
Not at all:
....
Then describe the efforts you made to troubleshoot and state the symptoms rather than making an assumption of what it could be, or overly narrow the problem without facts. It would help everyone a lot.
3 Likes
The effort was to enable all possible logs for few devices wich failed more often. I looked for the time stamps when hub recorded a Trigger and when the command was send to the device. Most of the time the dalays were resonably small (near instant). Once in a while the dalays were notisably long (around a second). But I could see this with my eyes. And I rushed to analize a related logs as soon as I was seen a delay by eyes. So what? I can see a delay and hub recorded a delay as well. But who nows why this delay was happening? Is it anything somewhere in whatever system logs (or so) which will tell what hub was doing in between Trigger event ans sending a command? Please let me know if I am missing something? It definitely will be helpfull if I (or somebody else) can see what hub was doing in between these two simple events (.e. recording a Trigger event and sending a command). Because I cannot see these details I consider these logs usless.
The hub is waiting for device to confirm. If the trigger was not delayed, then the hub is working properly and the issue is likely with your device itself, not the hub. Again, I am interpreting the log based on your description. If you could share one such example, you could further narrow it down.
To make sense of logs, look at time spent between A. event to trigger and B. trigger to action. If A. is not delayed, then it is likely the device. If A. is delayed, then the problem is in the hub.
1 Like
I am not sure what I described incorrectly.
In your example A is a Trigger event and B is an Action. There is no way to figure out if A was somewat delayed vs actual Device Event. Say, I can see a LED Blink on a Motion Sensor. This eventually will generate an event A (i.e. hub recorded a Trigger). There is no way without very specifc instrumentation to find out what was a delay between LED Blink and a recorded Trigger event. There are definitely some delays but in this case it dies not matter. Now hub got a Trigger and in responce will generates an Action (event B in your example).
And YES, the delay recorded in a log is between events A and B.
This is clearly pointed to the hub induced delay(s).
Now the question is - what exactly hub was doing in between A and B events?
Obviously there are many things is going on inside the OS.
But the OS is nor a RTOS!
This means there is no garanteed responce time between Trigger (event A) and Action (event B). BTW, Bruce mentioned many times that RM cannot guarantee any timing in the mS range. (Timing over few seconds is resonably stable.)
Software gurus please tell something or convince me if I am wrong.
The delays are naturally random. Sometime they are long because hub (the OS) is processing some sort of higer priority task(s). And this behavior is clearly observed (at least in my case).
(I hope, now I made it clear.)
