I am aware of a few questions, observations, and issues about how there is a single websocket server for the HA core and that each client receives all state changes and this can be problematic on low bandwidth connections, slower hardware, very large, or high sensor rate systems.
I’m posting this in the development channel as I’d like to work on this, but I also want to make sure this is something that would be welcome, or understand why I may be wasting my time.
In my personal experience, I’ve seen BT scanners flood my system and I’ve also done a bit of low level hardware engineering where I have sensors with high update rates. These cause issues on most panels from my Samsung Fridge to NS Panel Pros and others. The amount of data I’ve seen HA push out is borderline obscene.
So as I’ve been hacking along, I tried messing with subscribe_events/state_changed, but this appears to be doing what it was designed to do and doesn’t provide any filtering. There appears to be an undocumented subscribe_entities command, which leads me to suspect some crucial work has been done here. And if that is true, then it would appear the front end just needs to be configured to use it in some form for fashion.
Is it practical to have the front end subscribe and unsubscribe to entities as needed? Leveraging the LovelaceConfig?
Or perhaps if an entity is hidden, it doesn’t show up on the websocket? Less than idea, but it would allow a user to filter out these offenders.
Or the devs have no interest in this capability I should get better hardware, create a shadow HA install to filter entities, or something else.
I would rather not naively implement something redundant, or start down a rabbit hole the experienced devs know this is and that is the reason this doesn’t exist already.
Thanks,
Gabriel