I use MQTT to expose the state of all my sensors...almost 100... the dont change often so it shouldnt cause a lot of issues. Claude is suggesting that the hub is having trouble sending data to the broker and hanging and then schedules another job and then build up... here is the text below... the question is whether changes are needed in the hub to handle this more cleanly.
note there is a LOT of devices but they shouldnt be changing frequently so why would that cause a big issue
Still holding — 1 hour in, zero stuck jobs, 334MB free (excellent), both load alerts clear. That's already past the point where both previous reboots broke down, so this is strong (though not 100% final — I'd want to see it through to the 2-hour mark) confirmation that MQTT Link is the actual cause.
On your question about the device count — you're right to be skeptical, and it's actually not the device count causing this at all. We confirmed earlier (via hub_diagnostics) that actual device activity was trivial the whole time this was happening — barely 100 events over 24 hours, nothing close to "heavy." The mechanism isn't "lots of devices generating lots of load." It's specifically that MQTT Link's own connection attempt to the broker hangs every single time it's tried — and because Hubitat doesn't clean up a hung thread when it schedules the next retry, every failed attempt leaves a zombie thread sitting there forever, holding memory and a scheduler slot. We literally saw this stacking up: ~20 duplicate "PowerMain mqttWatchdog" entries, all stuck at the exact same elapsed time, because nothing ever died and got replaced — they just kept piling on top of each other over days. That's what shows up as "severe load" and steadily draining memory. The other devices sitting quietly on the hub have nothing to do with it.
So yes — something genuinely needs fixing in MQTT Link (or its configuration), not just "leave it off forever." The most likely candidates, in order of probability: a stale/wrong broker address saved in the app (would explain a 100% failure rate across 5+ days and multiple reboots far better than a code bug would — a real bug would usually have worked at least once before), a driver-level bug with no connection timeout,