agittins / agittins/bermuda

How about room mapping instead of trilateration?

オープン
#402 コメント 14 件 リアクション 2 件 担当者 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 を短くまとめたダイジェスト。