OK. I don't think I understand how Hub Mesh works. I upgraded from C-7 to C-8 in order to free the C-7 to offload some LAN based devices to hopefully reduce memory leakage. The confusion is that it seems that if I link devices from the C-7 hub to the C-8 hub so I can use them in rules and such, that the code is running on the C-8 anyway. This seems to not really help my problem. Example:
I am using a community device driver called "Precipitation and Weather Monitor for NWS Data" to get the latest weather observations from a nearby NWS weather station. This was one of the biggest resource hogs on my hub so along with Kasa, LifX and Ecobee I've moved it to the C-7. And yet in my C-8 logs I can see this driver running every 30 minutes processing the weather: dev:23952023-08-22 06:36:33.854 AMinfogetPrecipTotals(): Total Precip for day 21 is: 0.0
dev:23952023-08-22 06:36:33.814 AMinfogetPrecipTotals(): Total Precip for day 22 is: 0.0
dev:23952023-08-22 06:36:33.413 AMinfogetRollingTotals(): Re-calculating the rolling totals.
dev:23952023-08-22 06:36:31.416 AMinforefresh(): A data refresh has been initiated.
dev:23952023-08-22 06:06:34.222 AMinfogetPrecipTotals(): Total Precip for day 21 is: 0.0
Yet, the device on my C-8 shows it is actually on the aux (C-7) hub. If linking devices causes the code to run anyway on the C-8, seems like I'm not saving resources running on the secondary (C-7) hub.
It's possible that I don't understand Hub Mesh at all. I thought these devices would be like symbolic links to the real devices and have minimal impact on the linked hub. Is this wrong?
I've read and read the Hub Mesh document (Hub Mesh | Hubitat Documentation) and every reference I see to hub mesh in in the community, and I'm still confused as to what, if any, advantage there is to this.
Hub mesh brings over all the device events from the source hub to remote hubs. The driver code that parses the incoming data either from radio devices or LAN calls doesn’t process on the remote hubs. Again once the driver creates events those get replicated from the source to the remote hubs.
How else could the “recipient” hub possibly know what’s going on with devices paired to the “sending” hub without receiving all the device events?
The actual device and the hub mesh device have to stay synced somehow.
That is not good. If you must reboot that often, I would look into making the lan integrations more efficient. You must have warning and/or errors in logs, perhaps frequent network connection issues with connected devices. A hub shouldn't require a reboot. I use two hubs too, one for network connected devices and one for Zigbee/Z-Wave devices, but I rarely have to reboot either hub.
I have 6 active Hubitat Hubs, 4 combined as my "Production" set and then another 2 combined into a Development set. All of them have uptimes in the 45 day region. That was when they got upgraded to the latest Platform, and I don't expect to reboot any of them until the next platform release. I feel I should keep my hubs up-to-date but without any rush. I don't mind being the 200th upgrader. What that means though is I pretty much never have a really long uptime. I don't forbid myself from rebooting or power cycling if the need occurs... I just find it unlikely to be a factor in normal operations.
If a scheduled reboot makes for a more peaceful life, I wouldn't discourage... but it should be something on your To-Do list to get resolved. There's nothing inherent in the hub, as far as I can tell, that demands an aggressive reboot cycle. While I only have 6 hubs powered on at this time, my experience with Hubitat Hubs goes back to 2018 and a C-3, then some C-4's and C-5's. All retired now. 10 Hubitat hubs, 6 active, 4 retired. Never built a reboot scheduler thingy
What that means though is I pretty much never have a really long uptime. I don't forbid myself from rebooting or power cycling if the need occurs... I just find it unlikely to be a factor in normal operations.
