Yes, you understand correct: 8081 works, UI/main platform unresponsive.
Will do for the PS and cable. The C7 original PS and cable are still in use. These I can test soon to rule out.
As to the CPU temp, I can confirm the temp is in the "green". I can also confirm the CPU usage does start spiking, even significantly. It was observed above .9, to even 1,8+. All per hub-a-dashery.
I can also confirm your idea to restore pistons from a backup works. It was used to convert ecobee and airthings from C7 to C8; it is a lot of work. So, the remaining complete test to downgrade to 2.3.6 again is being put off for a bit due to the light/motion pistons to restore.
For what it is worth, I have consider attempting to shape the IP tx/rx traffic to the C7. My suspicion is there is some change after 2.3.6 in this area. This past weekend while installing a new switch there was a significant load observed on the C7 CPU (UI was not responsive, but the zwave devices were still sluggish) , which it recovered from, yet memory did not recover. Additionally, I noticed before moving airthings off the C7, that CPU load on the C7 increased when Airthing's IP connection was being converted.
Interesting... Two hue C7 bulbs were mesh shared to the C8 for use in a piston. The piston uses an ecoBee temperature sensor's motion on the C8 to turn the bulbs on and off.
The C7 did not stay up 3 hours when this was implemented. ecoBee is on C8, and not shared to the C7. Crazy...
The C7 has other hue bulbs tied into its on webcore piston and stays up.
I might try the other was - ecoBee sensor shared to C7 and C7 runs the piston.
So... should two C7 Hue bulbs mesh shared to a C8 create high RAM usage: 304MB? In attempt to fix the above the bulbs were removed, and available the C7 RAM improved to 441MB.
Otherwise, the morning will hopefully result with C7 up and responsible
RAM went from 304mb to 441Mb, or it increased by 304Mb, meaning it was at 137 prior?
304mb vs 441mb free ram wont make any difference. Technically 137 should be fine as well but sometimes when you get to that point (below ~150ish) the hub starts to get sluggish.
The remaining RAM has typically stayed about 290 on the C7 before all this started. Removing ecoBee and Air Things from the C7 improved RAM to 304MB; not as much as hoped yet it is what it is.
Then, with the removal of the shared bulbs the free RAM jumped to 441 for several hours. It seems the shared hue bulbs to the C8 piston were using more RAM than ecoBee and Airthings on the C7.
FWIW, the morning did not result well. So, more pistons are disabled to see if the C7 can stay up longer than a few hours.
Aside... my wife and I love what Hubitat does and offers. So, we are getting a C8 Pro in hopes of migrating the C7 to the C8 Pro. It will be interesting to see if the problem follows or remains on the C7.
Some good news, ecoBee and Airthings on the C8 are working amazingly well. Yay.
Just FYI there is a potential fix for the unexplained hub crashes that is being beta tested right now. So if you wait it out a short while longer, it might fix it.
C8 Pro does not have same symptom of unpredictable unresponsiveness, it functions fine.
C8 Pro may have some Homekit Migration issues… working on it.
C8 has been running ecoBee and Airthings functions fine: been up for days, until it was rebooted to install 2.3.138.
I may shutdown C8 Pro to put C7 back on line to see if the new 2.3.138. Not sure if it will be done. For now, enjoying the relaxation of not having to monitor things.
It has been a bit. The title should change; however, it is kept the same to share these observations in the case it helps. The C7 was replaced with C8 Pro. Effectively all remains same, as a migration backup was used to move to the C8 Pro. Still running 2.3.8.
The C8 Pro has been working and last days which is great. The observations, after about 5 days:
no change in CPU usage
no change in memory usage
zwave Zooz SE11 devices tied to a webcore piston starts to become slower in response to motion: motion, or its lack of, turns on and off a Meross switch
zwave Zooz SE11 devices tied to a webcore piston starts to become slower in response to motion: motion, or its lack of, turns on and off a Lutron switch
If the C8 Pro is not rebooted, then eventually zwave seems to become not responsive with webcore pistons.
Question: is there a metric that can be watched other than memory, and cpu. There is obviously something that is not working, and it would be great to monitor and at least automatically reboot when performance reduces.
Aside, if things go right I plan to have grafana and influx setup with concept to capture data.
I can create a new topic in a bit... I think I have influxdb and grafana working in a docker-compose file. If it works out I can start the post with that and seek items to monitor,
Please find the ZWave details. I do not see anything suggestion a ghost. Please let me know. Thank you for the guidance.
0x1a and 0x2b seem to be switching routes more often than the rest of your mesh, but not in the extreme, and nothing that looks to be an issue. Might check the device tab under logs to see if you have a device that seems particularly chatty.
Yeah, things look relatively boring...the two devices that are switching routes more frequently aren't going crazy or anything, but there is some route jumping around going on.
I have found Z-Wave locks will route change almost every time you use them. I have one of the Alfred locks and it does this along with my Yale. Seems to be mostly harmless, typically locks do not get tons of actions on them.
I don't have that issue, w/my Schlage Z-Wave (S0) lock...use it several times a day and it sits there happily w/no route changes. So its quieter for some reason...
Yours has no RTT value which is odd, if it has been used since reboot the RTT should be populated.
Below is what mine look like after rebooting this morning.
Office and Service doors rarely get used so the route changes are probably from sending battery reports.
It was done with docker-compose. If it becomes repeatable this weekend, a new post will be created with it. Steps were basically docker-compose up, do initial Influxdb setup (uid/pwd/create bucket/optional app token), initial grafana setup (uid/pwd/influxdb connection), hub info v3 driver (was already installed), install InfluxLogger, and import dash board.
Yeah I started working on a compose file that would bring up both Influx and Grafana together already configured to talk to each other, but never finished it. There are ways to do it, was just getting to be a pain. That would be the ultimate easy setup.
Put the docker-compose.yml and other files right in the post
create a GitHub respoitory and point to it
Or attach the files to the post
Effectively there are four files, three empty directories, and only one file needs to be edited for the specifics: uid, pwd, token...
The docker-compose environment can come up with InfluxDB and Grafana is already connected, as well as HubInfo dashboard deployed.
This can mean once docker-compose is up, a user points HE's InfluxdbLogger to docker-compose's InfluxDB, goes to grafana and "instant" dashboard(s)... or at least that is the promise as tested on macOS and sinology NAS.
Please let me know your preferences.
PS. Telegraf for influxDB is also added in the case other data collection is desired
