agittins / agittins/bermuda

How about room mapping instead of trilateration?

Aberta
#402 14 comentários 2 reações 0 responsáveis Ver no GitHub
Linguagem predominante
Python
Estrelas
2k
Forks
71
Métricas de merge de PRs
Nenhum PR com merge em 30d

Descrição

**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.

Guia de contribuição

Abrir o guia de contribuição

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.