sensor fusion #882
Replies: 1 comment 2 replies
-
|
I love the concepts/ideas you raised, but I wonder if room-assistant is the correct place for this. As you mentioned, so far the philosophy has mostly been to expose the presence data for consumption in a home automation tool. Wouldn't it make more sense to build the sensor fusion in e.g. Home Assistant? That would also give you access to fuse sensors from other platforms in (e.g. Zigbee motion sensors with room-assistant Bluetooth sensors). |
Beta Was this translation helpful? Give feedback.
-
|
Well you can ask the opposite question as well. If room assistant is only functioning as a sensor platform, why add cluster behavior? What's the value add over ESPHome with a BLE sensor? I see the following alternatives: Integrate this behavior into home assistant's scripting layerIt's clearly possible to implement some of the simpler ideas. I found examples from home assistant forums:
Most of those do perform some kind of sensor fusion. None of them, AFAICT, do any sophisticated state estimation. Trying to fit more complex behavior into home assistant's automation is impossible in the yaml based scripting language, as far as I can tell. You have events, triggers, and the last event's state. That's it. Composability is limited (blueprints), reusability is not really there (there is talk of a module system in the forums, but a lot of complex issues are not addressed, like dependencies on state or sensor types). There is also no grouping or abstraction over several scripts so they become difficult to manage when their are a lot of them. One of the examples above uses node red. It does have a more functional programming model, and more efficient reuse model (though with some serious limitations for large scale things), but still none of the basics. No automated testing model, no version control system, etc. All of these things make it worrisome to manage a large scale project, or a project with non-trivial behavior. Manually running every test case gets time consuming fast. All of this leads to serious maintainability issues. What is the mechanism for collaboration on ideas? How do I fix things if I break them? Integrate this behavior into home assistant's architectureI didn't explore this one. I don't know if the maintainer would support it. I suspect it would be best to introduce a new concept into home assistant though. Would the most acceptable way of integrating this be functionally identical to a room assistant integration similar to the more complex integrations that run in a container? If that's the case, you end up in a similar place as today with complex behavior essentially implemented in a stack component provided by room assistant. Keeping that computation in the home assistant server or one one of the room-specific sensor platforms seems like a minor detail. The comparison here seems like the two zwavejs integrations, or the few backup integrations which are on the more complex side, behavior-wise. The zwavejs server components are placeable anywhere reachable on the network so in many ways the zwavejs integration is a lot like the next option. Integrate this behavior into room assistant's architecture.This is what I found compelling about room assistant in the first place. That in could be a more home oriented version of density.io and something more hackable and reusable than https://www.hiome.com/. Both those platforms are presence detection solutions with distributed behavior that are much more plug-and-play-and-get-occupancy. This is combined with a github/PR based flow for actually collaborating, and a programming language with a genuine toolset and community for reusing a broad range of ideas. There is also no practical reason that room assistant can't be both a raw sensor platform that directly exposes sensor behavior to home assistant, and a device that performs more complex presence detection. It's even possible to use webhooks from home assistant to seamlessly combine additional sensors (i.e. the zigbee you mentioned, or z-wave stuff, or media players or whatever). If you conceptually split room assistant into a "coordination node" and a "sensor platform" then there is a lot of similarity with such an architecture in other home automation products.
This option seems the most likely to be able to solve some of the more complex problems with occupancy tracking (i.e. global modeling of the entire house as an input to local room updates), the best option to collaborate on an easy-to-use solution accessible to less sophisticated home assistant users, and the one most likely to be reusable for other platforms. |
Beta Was this translation helpful? Give feedback.
-
|
I found another example. Home assistant has a few sensor systems that are specifically designed for sensor fusion:
I don't understand whether integrating with home assistant this way is better than the above option. It doesn't have any real reuse tools, but perhaps it can be made simple enough that it doesn't matter. |
Beta Was this translation helpful? Give feedback.
-
It would be nice if there was an option to provide sensor fusion for presence detection within a room. As far as I can tell room assistant mostly exposes sensors directly and does relatively little to combine multiple sensors into a composite metric.
One way to approach this would be a kalman filter to incorporate accuracy estimates based on the time since last detection. I.e bluetooth combined with motion sensing combined with thermopile sensors would allow really interesting deployments. You could estimate if a phone was likely abandoned or forgotten. Or rely on a lower quality sensor when guests arrive. Or automatically estimate when certain bluetooth devices are likely associated with person movement and automatically add them into presence detection.
deeper approaches would be to build bluetooth distance models based on something as correlation between a dead simple as a range sensor combined with the bluetooth sensor.
Beta Was this translation helpful? Give feedback.
All reactions