Serious issues [SOLVED]

Hi all

I NEED HELP! :smiley:

I've had my hub up and running very smoothly for a few months now. In the last week or so though, I'm having all kinds of issues. I can't be sure, but I think it all started after the most recent firmware update. Multiple devices started not responding, I think mainly z-wave devices.

My first troubleshooting step was to pull the plug on the hub - I realize now this was a mistake. After realizing this, I did a soft reset and restored my most-recent backup. That seemed to fix things somewhat, but not completely.

Most recently, I am finding that the hub web interface is very slow to load. So I reassigned the hub a new fixed IP address. Didn't fix things. I have also 'properly' rebooted the hub through the diagnostic tool at port 8081 multiple times but I'm still having issues with devices not responding and the hub web interface being very slow to load, or not loading at all.

Any suggestions please?

Platform Version: hub-2.2.4.158

Hardware Version: Rev C-7

Thanks.

Update: I tried rolling back to 2.2.4.148 but didn't fix things.

Also tried 2.2.3.148 but didn't fix things.

I also tried a z-wave repair earlier but didn't fix things.

Here is something interesting. ALL of the devices that are having problems seem to have the same 'Last Activity At' times (2020-12-19 3:29:03 PM EST). Don't know what that means.

Accessing the diagnostic tool at port 8081 loads immediately. But accessing the hub just hangs.....

@bobbyD Should be looking at this

3 Likes

For the slowness (what I believe is a temporary solution) Hubitat recommends making a backup (I save them all to my PC). Then restoring the same backup. I guess the theory is this somehow cleans up some database stuff.

Personally I've stopped posting issues because I believe there will be a new, perhaps major upgrade in the works. My belief stems partly from the quietness of the Hubitat folks.

1 Like

I just did another soft backup and restore and the hub was immediately responsive. However I then ran a WebCore piston and the hub immediately became unresponsive again! Webcore issue?

What did the piston do?

It executed successfully, but then the hub locked up again. The piston is my 'Good Evening' piston which basically turns on a lot of lights and sets the Mode to Evening.

I just did ANOTHER soft reset and restore and the hub came back to life briefly, but is now unresponsive again. This is very frustrating.

More likely an issue with one of devices or the mesh...

1 Like

I tried a z-wave repair already. And all the devices show as 'OK' on the z-wave settings page, at least when I can access it...

Any suggestions please @bobbyD?

Just tried ANOTHER reboot and the hub comes back up, but as soon as I click on anything (Devices, Apps, etc) it becomes unresponsive.

FWIW I see this 'hub unreachable' message:

Hi Dorian, in your description of the problem, you are being too broad. You need to narrow down the scope of your troubleshooting. You already mentioned that disabling webcore got you on a better situation. Try disabling one by one all of your routines and test the responsiveness. Don't try the shotgun approach. If you suspect that the problem is with zwave, then power down the battery ones one by one and see the behavior.

1 Like

Hub is unreachable/unresponsive. You think that could be due to an individual device or webcore piston?

BTW I never said "disabling webcore got you on a outcome."

That's something that no one can test but you, it is a possibility. If you suspect a piston, disable it and test behavior. May be disable webcore altogether. May be you messed up the thing after you changed the IP and now another problem was introduced.

1 Like

If that's true then the whole platform seems very flaky.

1 Like

If you mean WebCore is flaky. Remember that runs on a cloud that you or me can't control. Otherwise, if you suspect that a piston could be the culprit. Disable WebCore who is the 3rd party code that is not part of the Hubitat core. Maybe something changed on their servers and we dont know that. Try a more subtle method and disable things one at a time.

1 Like

Not on Hubitat. Runs locally. Which actually adds to your point. One badly written piston can cripple a Hubitat.