agittins / agittins/bermuda

How about room mapping instead of trilateration?

未关闭
#402 14 条评论 2 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
Python
星标
2k
派生
70
PR 合并指标
30 天内没有已合并 PR

描述

**The main problems with trilateration are:**
1. there have to be as many proxies as there are areas to track
2. in practice proxy placement can't always be ideal and/or antenna gain can vary, causing areas to bleed over each other
3. there can't easily be any dead-space, e.g. a user being outside the home in the garden will get detected as being in a nearby room

**Mapping could solve these**

We'd do room calibration by walking around with a beacon e.g. into each corner of an area, capturing the RSSI to all proxies.
These points would effectively create a polygon corresponding to that area.
Doing this for each area would effectively create a map (in the proxy RSSI space).
And the beacon would be assigned a given location when it's within that polygon (likely with a bunch of heuristics fuzzing the edges).

**Side benefits**
Any overlap in the areas would quickly indicate problematic areas to the end user.
These could be handled by:
1. changing proxy placement or orientation (unfortunately requiring remapping)
2. prioritizing areas e.g. if it's better to be detected in one over another
3. manually adjusting the mapping

Any space between the areas most likely corresponds to wall attenuation.
We could allow marking which areas are touching, to eliminate these and always assign one or the other when a beacon ends up in between.

**Challenges**
The RSSI also depends on the beacon strength, so the math has to be normalized/relative.
In the sense that e.g. coordinates (50, 30, 10) from a strong beacon are the same as (5, 3, 1) from a weak beacon (grossly oversimplifying of course).

RSSI to far away proxies is likely going to be very variable, so there will have to be heuristics to either:
1. only use a few nearest proxies
2. have a wider margin of error depending on RSSI

The map effectively has as many dimensions as there are proxies, and various points will only have coordinates for some of them. This would make visualizing the data a bit difficult and may make debugging complex cases challenging.

In general there will likely have to be many heuristics to make this work well, which also implies many tunable parameters, which is both good and bad.

**P.S.**
I'm definitely willing to help with this, especially the math.
Unfortunately I'm not familiar with python, nor hass internals, so I'd be quite clumsy.
I'd expect the UI to be the main difficulty as this will involve a fair number of mapping interactions, visualization/debugging helpers.

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。