I have not tried that!
And like I said, this is only the 3rd time this has happened in the 4-5 months I've had this particular C5 (my previous one was defective, so I don't blame Hubitat for that 
).
So it hasn't been a "big" problem or anything. I will flip it over when I get back home though, because - why not?
You need to do something about that subwoofer. Again, why do you have it reporting the same exact thing literally hundreds of times without even 0.01 Watt change? That shouldn't be happening. There is something grossly misconfigured with that device, or there is something wrong with it.
I will have to defer to @bobbyD or someone else about that damaged database warning, and those java.sql warnings.
Makes no difference. I turned mine over 2 days before this latest double reboot. Oh, maybe that's what caused it! See, we go round and round in circles with this...
Fix, replace, pull that energy reporting plug called "Subwoofer".
That is EXACTLY what happened to my C5 - it was sitting on top of a smooth plastic surface (Sonos Connect) and would get lockups.. flipped it over and issues went away. Have a similar setup like @JasonJoel - no ZB/ZW, some virtual devices, no rule apps, maker api and alexa.
edit: that hub is no longer sitting on the Connect (now Port) but beside it on my desk, still upside down and functioning normally.
Okay, its gone.
You don't want that temp stuff spamming your network anyways. Z-wave operates in the 800-900Mhz frequency range so the protocol doesn't have much bandwidth in the first place and it's just going to slow your stuff down. Zigbee is in the 2.4Ghz range operating in 2MHz channels and can have interference issues with other 2.4Ghz devices if you have a lot of them and a busy network. These channels aren't very wide either so it too is limited in the ammount of traffic it can handle. The lower the frequency the better it can penetrate but the less traffic it can handle.
The hub failed to trigger evening or night modes today. This is after rebooting the hub this morning and removing the questionable Aeotec smart outlet this afternoon that was reporting power often.
Here is an update and a copy of what I just emailed Bobby:
I am writing to follow up on this and provide updates on changes I have made.
I deleted the Aeotec "subwoofer" outlet.
I deleted the Leviton dining room dimmer switch. There were debug posts associated with it and I have no idea what they are about. I have four more of the exact same switch in the house and the others are working okay as far as I know.
The hub is not changing modes correctly. I manually changed to night mode the change from the web interface and it should have triggered lights to turn off, but that did not happen. So even if it does go into night mode, rules are not firing.
Right now it is 3:10 pm and the hub is still on night mode.
My Samsung zigbee buttons are not working as they should. The MBR Button (device) triggers through the MBR Lamp Button rule in RM. Last night I pressed the button one to turn the lamp off and the lamp dimmed, but then brightened again. It would never turn off with the button. The button has been working fine for months without issue until recently.
There is still a message on the web interface saying that the database is corrupted and was restored. It's been there for a day or two.
New debug issues from yesterday. Could they be related to a device I removed? None of the devices for force removed.
When I click on debug it takes me to this:
Thank you,
Hugh
Sounds like something is completely messed up with you set up. How many devices do you have and what are they (also include all cloud and virtual devices)? Did your setup ever work? If so do you have a back up from then?
Yes, the system has been working fine for some time now. And yes, it is completely messed up and extremely annoying. The oldest backup that I have is from the beginning of June.
Here are my devices:
What do you mean by offline and not used since 2019?
Did you exclude the device (proper removal) or did you delete and force remove? If you force removed you likely added to the problems.
The text is probably small and fuzzy, but I didn't say "offline and a bit used"
The recessed door sensor battery is probably dead and had last activity reported by Hubitat of January 2020.
The outdoor outlets are plug in outlets that were just used for holiday lights and are now unplugged.
The smart light bulb is in a lamp that had last activity reported by Hubitat of 12/2019.
Sorry very late and woke up so eyes are fuzzy. But it says one offline another "not used" the "bit" was a typo by me.
Mesh networking 101 this isn't a good idea and 100% causes issues to your mesh. You should remove them fully when not being used or just leave them plugging in throughout the year.
These are also your only plus devices so alot of stuff was probably trying to route through it.
As the lamp was ZigBee and your only ZigBee lamp with other stuff on your network, depending on what lamp it was this could also be your issue.
You have so much going on with this hub, I am surprised it works at all. Did you mention to support that you had unplugged these devices without removing them?
The zigbee lamp is still plugged in, just not in use. I can exclude if that might help.
The only things unplugged are the two outdoor plugs that were used during the holidays. I will plug them back in and exclude them.
The hub was working for several months, however, after unplugging the outdoor outlets. Maybe it just took some time for things to build up and cause trouble.
I was going to avoid commenting as this topic usually turns into an argument, but heck with it.
Having paired, but unplugged, zwave devices on a mesh is not that bad of a thing in and of itself.
All that matters in the end is how strong the mesh is without those devices in place, and whether you have run a repair (if you have non-plus devices). Having a device joined to the mesh, but powered down, is not a real problem if the remaining mesh is adequate and the remaining devices have functioning routes back to the hub.
If you have non-plus zwave devices you should always run a repair after changing the mesh/routes, for a mesh with all 'plus' devices you don't have to run a repair (as it will fix itself if the remaining mesh is adequate) but it is usually a good idea to run a repair anyway (certainly shouldn't hurt anything). This isn't speculation - this is how the protocol works, and it is well documented. If you really feel like boring yourself, feel free to read through the standard like many of us have.
All that said, for something that is seasonal, I would either leave it plugged in or if that isn't palatable then unpair it from the hub before putting it away for the season. Not that you technically have to (if the remaining mesh is adequate), but it isn't hard to do - so why not?
I am not one to do this but to say its not that hard really depends on the rules or integrations that exist for this device. I have some devices that replacing might take an hour or two of clicking through the UI to get in and out properly.
Fair point. Probably a good place to use virtual devices in the rules, tbough, so that removing the physical device would be less disruptive.
Download the Hubitat app
