erweiterung von PRESENCE/(le)presenced/collectord um rssi werte

[justme1968]

ich würde gerne diesen thread nutzen um die bluetooth presence erkennung um eine optionale auswertung der rssi werte zu ergänzen. der hintergrund ist unter anderem der das der g-tag den ich verwende so weit empfangbar ist das er sich nicht mit dem collectord verträgt bzw. die dortige raumerkennung nicht nutzbar ist weil die signalstarke nicht berücksichtig wird.

für bluetooth le tags habe ich hier: https://forum.fhem.de/index.php/topic,28753.msg460340.html#msg460340 eine program zum scannen gepostet das auch den rssi wert ausliest.

um das ganze dann in fhem weiter zu verwenden müsste man vermutlich:
- den rssi wert mit in den presenced/lepresenced/collectord meldungen vorsehen
- im PRESENCE modul mit anzeigen
- den rssi wert erst mal etwas mitteln/filtern -> das gehört vermutlich in den lepresenced
- im collectord die raumzuordnung unter berücksichtigung des stärksten rssi machen

was man dann damit auch machen kann wäre vielleicht das erkennen ob ein tag näher kommt oder sich entfernt oder ob es sich zwischen zimmern bewegt.

das ganze sollte nur optional und rückwärts kompatibel passieren. d.h. ob wie bisher hcitool lescan oder das neue binary verwendet wird sollte konfigurierbar sein da es erst mal jeder interessent selber kompilieren muss.

langfristig könne man auch drüber nachdenken ob man nicht versucht die tags tatsächlich durch triangulation genauer zu lokalisieren. es gibt diverse paper die das inzwischen scheinbar recht erfolgreich beschreiben. das wäre dann aber ein ganz andere baustelle.

gruss
  andre

[betateilchen]

- im collectord die Traumzuordnung unter berücksichtigung des stärksten rssi machen

das fehlt mir grade noch, dass mir Bluetooth-Tags in meine Träume pfuschen...

[justme1968]

arg...  das einzige was hier pfuscht ist die autokorrektur.

[betateilchen]

Die offenbar weder Groß-/Kleinschreibung noch Kommas kennt. Was Deine Texte manchmal ohnehin ziemlich schwer lesbar macht.

[CoolTux]

Ich melde mich hier mal an wegen dem Batteriestatus und dem rssi

[HoTi]

Wäre schon toll. Würde ich auch gerne Testen.

[PatrickR]

Mahlzeit!

Hatte ja schon angemerkt, dass die Features für lepresenced auf der Liste stehen, obwohl ich meine Zweifel habe, dass man wirklich mit rssi-Werten für Distanzbestimmungen im Innenbereich glücklich werden kann. Aber wenn es hilft um so besser.

Für die konkrete Implementierung wollte ich mich allerdings erst entscheiden wenn ich es mir näher angesehen habe. Mein Ziel wäre eine, die möglichst gut supportbar ist. Das ist m. E. mit der aktuellen Version der Fall auch wenn die binaryjonglierende Perlkrake sicherlich aus informatischer Sicht nicht die schickste Lösung ist. Dazu: Falls jemand eine Idee hat, wie ich mit Perl-Bordmitteln ohne stdbuf das ungepatchte hcitool zur Kooperation bewegen kann, kann er sich beim nächsten Usertreffen in Berlin ein Bier abholen

Habe momentan noch das Paket auf der Liste (bitte fleißig testen) und die commandref.

@Markus: (Gehe davon aus, dass Du noch mitliest):
Wie wäre es mit der Implementierung als völlig neuer Befehl für collectord/PRESENCE, der möglichst flexibel ist
bspw. der Form

Code Auswählen Erweitern

reading <readingname> <readingwert ggf. mit Leerzeichen bis Zeilenende>
Das sollte gut abwärtskompatibel sein. Für rssi müssten wir uns dann auf einen Readingnamen einigen, damit der Collectord den wahrscheinlichsten Raum ermitteln kann.

Patrick

[justme1968]

was den rssi wert angeht: ohne den rssi mit einzubeziehen ist das raum feature komplett nutzlos. mit rssi kann ich schon beim einem einzigen enpfänger  eindeutig entscheiden in welchem stockwerk der gtag liegt. es ist also schon mal deutlich besser.

wieviel aufwand man rein steckt und wie man die genauigkeit gegen die ansprechgescheindigkeit abwägt bleibt noch zu sehen.


ohne stdbuf kommt man mit umgemachtem nicht hin. wenn man in die quelltexte schaut wird hier auf sehr tiefem level mit ldpreload gearbeitet. auch rssi geht mit hcitool nicht. meine vorschlag von oben könnte beides und ist wirklich einfach zu kompilieren. ich würde die aktuelle version auf jeden fall als default/fallback drin lassen. ein anderer weg wäre sich mit btmon in die komplette kommunikation einzuklinken. man braucht aber auch dann noch ein binary mit dem das scannen ausgelöst wird.


das aufteilen auf mehrere zeilen hat den nachteil das die readings nicht mehr in einem event aktualisiert werden.

ich würde als format

Code Auswählen Erweitern

<reading1>=<wert1> <reading2>=<wert2> ... vorschlagen. wenn leerzeichen wirklich vorkommen wie im namen kann man den wert in anführungszeichen setzen. in FHEM gibt es schon eine parseParams routine die dieses format versteht. statt dem leerzeichen kann man auch ein anderes trennzeichen verwenden. eventuell ;

das würde man vermutlich sogar zumindest in eine richtung rückwärts kompatibel zum aktuellen format hin bekommen.

gruss
  andre

[PatrickR]

Hi!

das aufteilen auf mehrere zeilen hat den nachteil das die readings nicht mehr in einem event aktualisiert werden.

Guter Punkt mit dem BulkUpdate.

ich würde als format

Code Auswählen Erweitern

<reading1>=<wert1> <reading2>=<wert2> ... vorschlagen. wenn leerzeichen wirklich vorkommen wie im namen kann man den wert in anführungszeichen setzen. in FHEM gibt es schon eine parseParams routine die dieses format versteht. statt dem leerzeichen kann man auch ein anderes trennzeichen verwenden. eventuell ;

das würde man vermutlich sogar zumindest in eine richtung rückwärts kompatibel zum aktuellen format hin bekommen.
  andre

D. h. nicht nur mehrere Readings (z. B. Battery und rssi) in eine Zeile sondern auch noch present/absent?

Patrick

[justme1968]

ja. wäre kein problem. die routine kommt damit klar.

[Markus Bloch]

Hallo zusammen,

ja ich lese mit, keine Sorge. Find die Ideen, die ihr habt, echt gut. Leider fehlt mir aktuell die Zeit diese selber umzusetzen.

Soweit ich das sehe müssten folgende Sachen getan werden:

• PRESENCE erweitern, so dass Readings durch collectord/presenced erkannt und direkt rausgegeben werden. Ich würde hierbei das folgende Format bevorzugen:
  
  absent;reading1=foo;reading2=bar
  present;reading1=foo;reading2=bar;rssi=-79;name=iPhone
  present;room=Wohnzimmer;name=iPhone
  
  Dieses Format ähnelt dem originalen und würde den Aufwand zur Verarbeitung in PRESENCE recht gering halten.
  
  Nachteil der Sache ist jedoch, dass ich in PRESENCE keine Kontrolle über die erzeugten Readings habe und in der Commandref irgendwie klar machen muss, dass diese Readings nicht direkt durch PRESENCE sondern presenced/collectord/lepresenced/... erzeugt werden.
  
• collectord müsste erweitert werden um RSSI-Berechnung
• lepresenced müsste erweitert werden um RSSI Erkennung und evtl. Batterie-Level

Wie man Punkt 3 umsetzen könnte, würde ich euch bzw. Patrick überlassen. Eine richtige Idee wie man das besser machen kann, habe ich jetzt auch nicht parat.

Prinzipiell könnte ich Punkt 1 und 2 umsetzen, befinde mich aber gerade in der Vorbereitung meiner ersten großen Motorrad-Reise mit Zelten usw. (ja ich bin noch jung und unerfahren ) und hab daher aktuell leider nicht so die Zeit für größere Änderungen. Patches sind daher immer gerne gesehen.

Gruß
Markus

[justme1968]

ja. das format kann man auch direkt mir parseParams verarbeiten.

und noch etwas: rssi ist nicht nur mit le möglich. wenn man statt hcitool name hcitool cc <mac> && hcitool rssi <mac> verwendet bekommt man auch für die 'normalen' geräte wie handys einen rssi wert. beim testen eben lässt sich dieser genau so sinnvoll mit zur raum erkennung einsetzen.

gruss
  andre

[Markus Bloch]

Das Problem an hcitool cc <mac> && hcitool rssi <mac> ist jedoch die erhöhte Funk-Last und dadurch Akku-Belastung, da hier eine vollständige Verbindung hergestellt wird und anschließend der RSSI abgefragt wird. Bei hcitool name <mac> erfolgt nur ein Paging, welches sehr Akku-schonend ist. Wenn man jetzt alle bspw. 30 Sekunden eine Bluetooth-Verbindung aufbaut, den RSSI ermittelt, wieder abbaut usw, wird das denke ich deutlich mehr Leistung benötigen.

Gruß
Markus

[justme1968]

hat schon mal jemand getestet wie groß der unterschied im batterieverbrauch ist?

gruss
  andre

[Markus Bloch]

Explizite Tests habe ich noch nicht gemacht. Ich hab mich aber zu dem Thema mit einem Arbeitskollegen unterhalten der früher an der Bluetooth-Entwicklung beteiligt war. Er riet mir zum Paging um Energie zu sparen.

Gruß
Markus