I’ll keep you informed of whatever can be open - and I’ll try to make that as much as possible as it gives much better feedback.
For background, I owned the design of what’s now BG’s Hive Home system (Zigbee based) and spent some time trying to rescue the networking approaches used in Lowe’s old system. There are lots of these networking protocols (Aarhus University’s EPIC project identified 96 a number of years back), and they often look like they were designed by non-computer scientists. Your scenario analysis is correct - you don’t want flooding with false +ves of failure, and you certainly don’t want to confuse/bombard the user with excess stuff.
otoh, I found that consumer and industrial installation of mesh networks don’t conform to many of the design assumption that are often based on battlefield scenarios with very dense node availability, an expectation that some will fail. The battlefield mesh protocols deliberately avoid a central point of control, but they break when there’s not enough connection redundancy as there’s no node that understands what’s going on. This creates frequent network partitions and unexplained lags/lost messages, which really confuses and annoys the user
From an economic point of view, supporting the more complex installations can easily become the dominant costs of running a service - especially if the business over-promises what’s possible.
Everything’s fine while it’s working. But then something strange happens and it’s impossible to work out what it was and often impossible to automatically restore order.