Last updates breaks device reporting on one hub (does not break hub mesh)

If you re-downgraded to 2.3.5, you will not see this, as it is a new feature in 2.3.6. If you are on 2.3.6, you should see it as shown in the documentation:

1 Like

Then this is not a hub mesh issue. The title of this thread is misleading. And the suggestions to fix it will not work.

Are your devices zigbee or z-wave devices? There is an issue with your zigbee or z-wave mesh that needs to be addressed.

1 Like

all devices from that hub are z wave, I don't think is a high cpu usage problem as I can control devices manually with no delay.
Anyway i disabled hub mesh and changed name on lan now and see if helps.

1 Like

That's good to know. There are many z-wave experts in the community. I'll tag them for them to step in (in addition to @bertabcd1234 who is already following this issue):

Tagging @jtp10181, @csteele, @JasonJoel.

I'll also tag the Hubitat SMEs for Z-devices - @mike.maxwell, @bcopeland

Can you do a soft reset on both your hubs? And then update to the latest platform?

already did soft reset on the hub with the problem but after upgrade to 2.3.6 not before, do you think it makes any difference if i reset on 2.3.5?

Yes. I think you should downgrade to 2.3.5, then do a soft-reset. Then update to 2.3.6 and see if the issue persists.

soft reseted on 2.3.5 ,upgraded to 2.3.6 ,problem persists i'm going crazy

  1. Can you provide details on what types of devices you have on this hub? Is it only battery powered motion sensors?
  2. When you say "control devices manually", can you provide more details on what you are doing and observing for this part of the test?

Most devices are main powered, aeotec multi sensor 6, aotec and fibaro switches etc
Manually I mean turning on/off lights from dashbord or from hub's device menu.

I have received the signal.

I will need to take some time later to review this entire thread.

1 Like

so definitely not a mesh problem, I have disabled mesh and turned off the main hub entirely.
The bug persists on my 2ndary hub.
So basically I have two identical hubs, when running 2.3.5 both work great, as soon as I update to 2.3.6 one hub works normally, devices on 2nd hub stop reporting their state in less than 1 hour after the upgrade.
Is there any better way of debugging this? maybe like some tool that gathers all info and can pinpoint the exact changes that happen when devices stop reporting?
Is there something that 2.3.6 makes the hub do after 30-60 mins of running that could cause this?
Is very strange that it doesn't happen right away.
I really hope I'm not stuck on 2.3.5 firmware forever on that hub to avoid this bug.

Not a hub mesh problem. But it is probably a z-wave mesh problem.

Can you post a screenshot of your entire z-wave settings page?

if the problem was z wave then why I can still control the devices manually? and why it happens only on 2.3.6 but never on 2.3.5

Is that all your zwave devices? How long was the hub running when you took that screenshot?

Is your zwave firmware up to date? If you have an update firmware button on the zwave details page there is a pending update, otherwise the button is hidden.

What sort of reporting intervals do you have set on the AEON sensors? Are they powered by battery or USB? For any powered by battery, are you 100% you paired them on battery power (it matters).

Someone who is familiar with those sensors.... haven't there been problems with those things spamming the zwave mesh and causing issues?

Also are these z-wave (below)? Seems like a lot of events for 18 minutes of uptime

1 Like

it didin't ran for longtime since i was keep changing firmware update back and forth.
Zwave is up do date.
As i said 95% of devices are main powered, all battery powered devices show their battery percentage so they should be paired on battery power.
Those fibaro switches with lots of events have a firmware bug that doesn't allow me to disable their power reports, they are one of the reason I went with 2 hubs instead of 1 in my house.
But this is NOT a z wave traffic problem, I repeat, controlling lights manually works instantly there is no lag, if there was lag then it was a traffic problem.
And again, on 2.3.5 version everything works fine and devices don't stop reporting so the problem is clearly in the hub update not zwave or anywhere else.
Unless someone can replicate the problem the only solution I see is getting a personalized hub update with suspecting features that were added in 2.3.6 removed and keep testing until It's fixed.

If the devices stop reporting then that’s on them, has nothing to do with the hub. I also don’t think they really changed anything with zwave in this update.

It seems like you don’t really want any more help.

1 Like

I phrased it slightly differently, but my conclusion is similar to yours:

wow, i'm not even sure how to answer to this ignorant answer.
So after days of following all instructions here and the problem persisting your best conclusion is that ALL DEVICES from that hub stop reporting because of their own fault, same devices that work perfectly fine on 2.3.5??
Just say you are left out of ideas to fix and devs won't dig deep enough into the problem to actually compare code changes from 2.3.5 to 2.3.6.
Well, then let's just call it a day, I'm stuck on 2.3.5 update for my rest of my hubitat usage with a biter taste in my mouth.

i provided everything i was asked here.
If you really are trying to help me pm me and I'll provide you vpn access to my router to access the hub and you can gather information all day long and watch the bug happening live.
Same access I can provide to @jtp10181 jtp10181