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
Zitat von: justme1968 am 10 Juni 2016, 17:36:24
- 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...
arg... das einzige was hier pfuscht ist die autokorrektur.
Die offenbar weder Groß-/Kleinschreibung noch Kommas kennt. Was Deine Texte manchmal ohnehin ziemlich schwer lesbar macht.
Ich melde mich hier mal an wegen dem Batteriestatus und dem rssi
Wäre schon toll. Würde ich auch gerne Testen.
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
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
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 <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
Hi!
Zitat von: justme1968 am 10 Juni 2016, 22:05:13
das aufteilen auf mehrere zeilen hat den nachteil das die readings nicht mehr in einem event aktualisiert werden.
Guter Punkt mit dem BulkUpdate.
Zitat von: justme1968 am 10 Juni 2016, 22:05:13
ich würde als format <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
ja. wäre kein problem. die routine kommt damit klar.
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 :P ) und hab daher aktuell leider nicht so die Zeit für größere Änderungen. Patches sind daher immer gerne gesehen.
Gruß
Markus
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
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
hat schon mal jemand getestet wie groß der unterschied im batterieverbrauch ist?
gruss
andre
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
Mahlzeit!
Ich habe mal etwas an lepresenced herumgebaut, die rssi-Messung eingebaut und mit Thresholds für die rssi-Änderung gespielt:
Jul 2 22:58:01 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -54/-78, difference: 24, affected clients: 1.
Jul 2 22:58:09 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -78/-54, difference: 24, affected clients: 1.
Jul 2 22:58:12 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -54/-76, difference: 22, affected clients: 1.
Jul 2 22:58:29 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -76/-54, difference: 22, affected clients: 1.
Jul 2 22:58:32 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -54/-75, difference: 21, affected clients: 1.
Jul 2 22:58:39 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -75/-54, difference: 21, affected clients: 1.
Jul 2 22:58:40 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -54/-78, difference: 24, affected clients: 1.
Jul 2 22:58:41 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -78/-54, difference: 24, affected clients: 1.
Jul 2 22:58:42 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -54/-77, difference: 23, affected clients: 1.
Jul 2 22:58:55 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -77/-55, difference: 22, affected clients: 1.
Jul 2 22:58:58 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -55/-76, difference: 21, affected clients: 1.
Jul 2 22:59:03 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -76/-55, difference: 21, affected clients: 1.
Jul 2 22:59:06 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -55/-78, difference: 23, affected clients: 1.
Jul 2 22:59:07 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -78/-54, difference: 24, affected clients: 1.
Jul 2 22:59:08 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -54/-75, difference: 21, affected clients: 1.
Jul 2 22:59:13 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -75/-54, difference: 21, affected clients: 1.
Jul 2 22:59:17 rpi-test lepresenced[22213]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -54/-78, difference: 24, affected clients: 1.
Aktuelle Mindestabweichung für ein Update ist 20 dB. Das Log entstand mit dem G-Tag am Schlüsselbrett ohne jegliche Bewegung.
Stelle ich die Threshold auf 25dB kann ich 6m in den nächsten Raum gehen, ohne dass es ein einziges Update gibt. Ich fürchte, wenn es da noch etwas zu retten gibt muss ich die Werte über einen noch festzulegenden Zeitraum mitteln. In Anbetracht der Häufigkeit der Beacons ist das aber ein nicht zu vernachlässigender Bookkeepingaufwand...
Patrick
/Edit: Wenn ich über die letzten 10 Werte mittle und die Threshold auf 10 dB setze, wird es deutlich ruhiger.
Mahlzeit!
Zitat von: Markus Bloch am 11 Juni 2016, 14:26:27
- 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.
Habe das Format mal testweise in einer Entwicklungsversion eingebaut. Was mich etwas ärgert ist, dass sich das Ganze nur mit einem Big Bang (d. h. Update für PRESENCE, presenced, collectord und lepresenced) umstellen lässt, d. h. der gleichzeitige Support von altem und erweitertem (wie oben) Format mindestens zu Anzeigefehlern führt:
Readings
device_name name=Gigaset G-tag 2016-10-03 14:56:15
room rssi=-66 2016-10-03 15:00:15
Setup war PRESENCE <-> lepresenced (ohne collectord).
Was collectord mit dem neuen Format anstellt, müsste man sich nochmal ansehen.
Patrick
Hallo Patrick,
ja, dass stimmt. Das "neue" Format lässt sich nur realisieren durch eine initiale Änderung in PRESENCE um das ganze rückwärtskompatibel zu gestalten.
Ich will nicht behaupten, dass dieses Format am geeignetsten ist. Vielleicht hat hier jemand noch einen besseren Vorschlag. Das "alte" Format kam damals mir so als erstes in Sinn. Für meinen Zweck hat es gereicht.
Ich werd mal schauen, dass ich das in den nächsten Tagen angehe.
Gruß
Markus
Hallo Patrick,
ich habe in PRESENCE heute das neue Format rückwärtskompatibel integriert.
Man kann also nun folgendermaßen zusätzliche Readings an PRESENCE übergeben:
absent;reading1=foo;reading2=bar
present;reading1=foo;reading2=bar;rssi=-79;name=iPhone
present;room=Wohnzimmer;name=iPhone
Das ganze funktioniert momentan nur in Zusammenarbeit mit PRESENCE direkt (also ohne collectord).
Als nächstes müsste ich den collectord dafür fit machen, damit er sowohl eingehende Information mit diesem Format verarbeiten kann und seine Ergebnisse ebenfalls in diesem Format an FHEM weitergibt.
Viele Grüße
Markus
Hallo Markus!
Sieht wirklich gut aus (Siehe Anhang). Mit dem offiziellen Release warte ich allerdings noch, um das etwas zu beobachten. Wäre auch nicht wirklich vernünftig, bevor der collectord so weit ist.
Übrigens sehr nett, dass Du die "AddonData" offen für zukünftige Erweiterungen gelassen hast.
Patrick
Mahlzeit!
Ein Update: Wegen der Konsistenz sende ich mit lepresenced jetzt device_name statt name. Habe außerdem noch das Reading daemon hinzugefügt. Das sollte bei Forenfragen die Fehlersuche erleichtern.
Patrick
Hallo zusammen,
bin grade dabei meine BT Anwesenheitserkennung auszubauen. Wann wird das regulär via Update verfügbar sein und auch mit collectord funktionieren?
Dann würde ich das Projekt bei mir etwas zurückstellen.
Das steht noch auf meiner TODO Liste. Einen Termin kann ich dir leider nicht nennen.
Gruß
Markus
Im Anhang mal der erste Wurf. Sofern alle Räume als Addon-Data "rssi=<Zahl>" bereitstellen und mehrere Räume "present" melden, wird anhand des RSSI-Werts der tatsächliche Raum ausgewählt.
Ich kann es leider nicht ausreichend testen, da ich keine BT-Tags habe.
Gruß
Markus
Hallo Markus,
Der Jörg ist gerade dabei ein BT Framwork zu schaffen. Darin enthalten soll meines Wissens dann auch BT Presenceerkennung sein. Ob jetzt nur BT LE oder auch normales BT weiß ich leider nicht. Aber auf alle Fälle BT LE (G-Tags z.B.) und damit verbunden auch rssi.
Grüße
Leon
Hallo Leon,
hast du da gerade mal ein Link zur Hand? Muss ich mal im Auge behalten.
Vielen Dank
Gruß
Markus
Nein leider nicht. Jörg und ich arbeiten da zusammen dran. Naja Jörg macht die Hauptarbeit mit dem Framework und ich passe dann meine BT Module (Pflanzensensor und Playbulb) an.
Es geht im Grunde darum eine einheitliche Möglichkeit zu haben um BT Geräte abzufragen und Befehle an sie zu schicken.
Das leidige Thema hcitool lescan wird beendet wenn gatttool läuft hat dann ein Ende. Ausserdem werden auf Basis der BT Characteristics automatisch Devices angelegt sofern Module diese Unterstützen. Da arbeiten Jörg und ich dann zusammen. Aber erstmal muß das Framework stehen. Es geht auch darum gatttool nonBlocking und Interactiv auf zu rufen so das man auch BT Notifications verwenden kann.
Also verbundenen BT Geräte melden an FHEM Ihren aktuellen Status nach einer Änderung.
Ist alles ein ziemlich großes Projekt. Aber wir haben vor es im ersten Quartal 2017 ab zu schließen so das es ein einheitliches BT Framework für FHEM gibt.
Und Teil dieses Frameworks wird dann auch presence Abfrage von G-Tags beinhalten.
Wenn nicht frage doch einfach mal Jörg Hermann an. Dann kann er Dir schon mal mehr erzählen.
Grüße
Danke Leute! Hat ja Zeit...
Funktioniert das Beta Modul auch mit Handys?
Würde gern auf weitere Gadgets verzichten.
Mahlzeit!
Damit Ihr Markus' collectord testen könnt, poste ich mal die aktuelle Version von lepresenced. Ist aber Alpha, d. h. der Supportvertrag gilt nicht :)
Bitte beachtet, dass es eine neue Abhängigkeit gibt:
bluez-hcidump
Ansonsten könnt Ihr Euch mal die neuen Kommandozeilenoptionen ansehen:
--legacymode
Sollte hier keinem helfen. In diesem Modus funktioniert lepresenced wie vorher, d. h. ohne hcidump aber es gibt auch keine rssi-Werte...
--rssithreshold <Zahl>
Hiermit könnt Ihr experimentieren. Das ist die rssi-Abweichung, ab der ein Update an FHEM gesendet wird. Vernünftige Werte für einen Default werden dankend angenommen, aktuell 10dB.
Patrick
Mahlzeit!
Ich finde es ehrlich gesagt etwas schade, dass die Resonanz so gering ist. Das Problem ist, dass ohne Rückmeldungen zu Markus' collectord bzw. zum lepresenced kein Release erfolgen kann. Das wäre aber die Grundvoraussetzung dafür, dass der vorhandene Knoten gelöst und lepresenced weiterentwickelt werden kann. Letzteres halte ich gerade im Hinblick auf die Batterieabfrage für sinnvoll, um das In-den-Fuß-Schieß-Potenzial der Batterieskripte zu reduzieren.
Patrick
Bin zwar interessiert, aber imo weder Zeit noch genug Wissen. Will ja auch aus weiter entfernten Räumen meine LE-Tags auslesen.
Hallo
Habe beide Module bei mir installiert RSSI Werte 2Gtag + ein HM10 werden erkannt RSSI sind nahzu indentisch gtag etwas stärkeres Signal (Wohnzimmer)
Im oberen stockwerk wo ich noch 2 HM10 habe erfolgt keine Erkennung vorher mit alten lepresenced wurde es ohne Probleme erkannt.
Diese Devices melden allerdings als Name (unknown) vielleicht liegt es ja daran.
Gestartet über rc.local /home/pi/lepresenced -a 0.0.0.0 -d
RSSI werte bleiben wenn gtag abwesend auf letzten Wert eingefroren denke mal so gewollt.
Hi!
Danke erstmal fürs Testen!
Zitat von: inesa394 am 16 Januar 2017, 14:27:58
Habe beide Module bei mir installiert RSSI Werte 2Gtag + ein HM10 werden erkannt RSSI sind nahzu indentisch gtag etwas stärkeres Signal (Wohnzimmer)
Im oberen stockwerk wo ich noch 2 HM10 habe erfolgt keine Erkennung vorher mit alten lepresenced wurde es ohne Probleme erkannt.
Diese Devices melden allerdings als Name (unknown) vielleicht liegt es ja daran.
Sieht so aus, als würde sich meine G-Tag-Monokultur nun rächen. Kannst Du mal lepresenced stoppen und in zwei Shells folgende Befehle parallel laufen lassen, bis mindestens ein HM10-Beacon empfangen wurde:
hcitool -i hci0 lescan --duplicatesund
hcidump -i hci0und die Ausgabe des 2. Befehls posten oder mir per PN schicken?
Falls der Scan nicht funktioniert vorher folgendes ausführen:
hciconfig hci0 reset
Zitat von: inesa394 am 16 Januar 2017, 14:27:58
RSSI werte bleiben wenn gtag abwesend auf letzten Wert eingefroren denke mal so gewollt.
Das ist ein Bug, da irreführend. Ist in einer Zwischenversion schon korrigiert.
Patrick
Ok wenn ich zu hause bin Abends dann
@inesa394:
Probiere doch bitte mal die angehängte Version (0.7dev4).
Patrick
funktioniert jetzt mit der letzten Version alle HM10 Beacons werden erkannt.
Welcher RSSI wird angezeigt da einige Beacons von zwei Räumen gefunden
werden?
ternals:
ADDRESS 74:DA:EA:B1:DD:xx
CHANGED
DEF lan-bluetooth 74:DA:EA:B1:DD:xx 127.0.0.1:5222 120
DeviceName 127.0.0.1:5222
FD 110
MODE lan-bluetooth
NAME hm10flur
NOTIFYDEV global
NR 585
NTFY_ORDER 50-hm10flur
PARTIAL
STATE present
TIMEOUT_NORMAL 120
TIMEOUT_PRESENT 120
TYPE PRESENCE
Readings:
2016-12-16 21:23:07 command_accepted yes
2017-01-18 20:48:40 daemon lepresenced V0.7dev4
2017-01-18 20:48:40 device_name HMSOFT.G-tag
2017-01-18 20:48:40 presence present
2017-01-16 13:43:12 room ibeacondach,ibeaconwz
2017-01-18 20:48:40 rooms ibeacondach,ibeaconwz
2017-01-18 20:48:40 rssi -78
2017-01-18 20:48:40 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
Attributes:
devStateIcon present:dim75% absent:off@red
event-on-change-reading state
icon it_smartphone
room Status
Ines
Ich habe bei mir den presenced installiert. (min 1 Jahr alt)
Kann auch mit dem neuen lepresenced testen? Oder erkennt der meine Handys nicht?
Würde gerne sehen, ob ich auch RSSI Werte bekomme.
Kann man da nicht ein script draus machen was beides kann?
presenced kann nur Bluetooth, lepresenced nur Bluetooth LE. D. h. Dein Handy wird lepresenced nicht erkennen.
Du kannst einfach presenced und lepresenced laufen lassen. Die sind auf friedliche Koexistenz getrimmt. Eine Zusammenfassung halte ich aus mehreren Gründen für ungünstig (Verschiedene Ansätze, verschiedene Maintainer etc.)
Von unterwegs gesendet.
Es wäre schade, wenn das Thema nicht weitergeführt wird, ich kann mich zum testen anbieten.
Ich habe 3 GTags, und benutzte collectord and lepresenced um meine BT Tags und mein iPhone (also BT and BT LE) von 3 verschiedenen RaspPi 3 mit lepresenced instanzen aufzusammeln.
Ich würde den lepresenced mit RSSI gerne testen, wenn mir einer erklärt wie ich den lepresenced von PatrickR kompiliere/installiere :-(
Sonst habe ich immer mit "sudo wget https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/lepresenced-0.6-1.deb && sudo dpkg -i lepresenced-0.6-1.deb" das lepresenced package installiert.
Beste Grüsse
Hi!
Zitat von: inoma am 05 Februar 2017, 17:20:15
Ich würde den lepresenced mit RSSI gerne testen, wenn mir einer erklärt wie ich den lepresenced von PatrickR kompiliere/installiere :-(
Wichtig für den Test ist, dass Du
sowohl den collectord hier aus dem Thread als auch den letzten lepresenced hier aus dem Thread installierst.
Für den lepresenced sind das folgende Schritte (aus dem Kopf, daher evtl. nicht 100% fehlerfrei.) Da der Download aus dem Forum nur eingeloggt geht, ist es sinnvoll, wenn Du zuerst den letzten lepresenced hier aus dem Thread (#34) herunterlädst und dann z. B. per WinSCP auf den Pi kopierst. Nehmen wir mal an, das hast Du getan und er liegt jetzt unter /root/lepresenced. Dann:
sudo -i
/etc/init.d/lepresenced stop
apt-get install bluez-hcidump
cd /usr/local/sbin
cp lepresenced lepresenced.old
cp /root/lepresenced .
chmod 744 lepresenced
/etc/init.d/lepresenced start
Wenn irgendetwas nicht klappt kannst Du einfach den alten lepresenced zurückkopieren oder einfach das Paket wieder drüberinstallieren.
Zitat von: inoma am 05 Februar 2017, 17:20:15
Sonst habe ich immer mit "sudo wget https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/lepresenced-0.6-1.deb && sudo dpkg -i lepresenced-0.6-1.deb" das lepresenced package installiert.
Sehr gut! Endlich mal jemand, der sich nicht unnötig das Leben schwer macht und einfach das Paket installiert.
Patrick
Also das lepresenced läuft soweit, unten das listing.
Ich habe das neue lepresenced auf allen drei Raspberry Pi installiert (Schlaf/Flur/Wohn).
Der RSSI hat sich auch brav geändert zwischen -85 und -81, wenn ich Ihn dann in die Mikrowelle stecke, bleibt er auf -86 stehen (also klemmt er auf dem letzten gemessenen RSSI Wert fest).
Allerdings scheint der collectord aus post #23 nicht zu funktionieren:
Ich habe den collectord aus post #23 nach /usr/sbin/ kopiert, danach ein
pi@jessie ~ $ sudo update-rc.d collectord remove
pi@jessie ~ $ sudo update-rc.d collectord defaults
und/etc/collectord.conf um rssi=90 erweitert
und den Raspberry 3 (Jessie) neu gestartet.
-> jedoch bekomme ich danach ein für alle Devices, also für die BT und BT-LE:
PRESENCE Definition "Presence_GTag_RED_collect" is not connected to 127.0.0.1:5222
im list sieht das dann so aus:
Readings:
2017-02-07 23:47:45 Batterie 56
2017-02-08 01:53:10 Battery ok
2017-02-08 08:04:53 command_accepted yes
2017-02-08 01:50:00 daemon lepresenced V0.7dev4
2017-02-08 01:50:00 device_name Gigaset G-tag
2017-02-08 01:50:00 presence present
2017-02-04 16:55:50 room SchlafLE,flurLE,wohnLE
2017-02-08 01:50:00 rooms SchlafLE,flurLE
2017-02-08 01:50:00 rssi -83
2017-02-08 08:19:01 state disconnected
sudo hcitool -i hci0 lescan --duplicates
LE Scan ...
7C:2F:80:98:C2:2A (unknown)
7C:2F:80:98:C2:2A Gigaset G-tag
pi@jessie ~ $ sudo hciconfig hci0 reset
pi@jessie ~ $ sudo hcidump -i hci0
pi@jessie ~ $ sudo hcidump -i hci0
HCI sniffer - Bluetooth packet analyzer ver 5.42
device: hci0 snap_len: 1500 filter: 0xffffffff
HCI sniffer - Bluetooth packet analyzer ver 5.42
device: hci0 snap_len: 1500 filter: 0xffffffff
> HCI Event: LE Meta Event (0x3e) plen 42
LE Advertising Report
ADV_IND - Connectable undirected advertising (0)
bdaddr 7C:2F:80:98:C2:2A (Public)
Flags: 0x06
Unknown type 0xff with 12 bytes data
Shortened service classes: 0x180f
RSSI: -80
> HCI Event: LE Meta Event (0x3e) plen 27
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr 7C:2F:80:98:C2:2A (Public)
Complete local name: 'Gigaset G-tag'
RSSI: -80
Aber auch:
pi@wohny ~ $ sudo hcidump -i hci0
HCI sniffer - Bluetooth packet analyzer ver 5.42
device: hci0 snap_len: 1500 filter: 0xffffffff
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 7C:2F:80:98:C2:2A mode 2 clkoffset 0x0000
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x04 bdaddr 7C:2F:80:98:C2:2A name ''
Error: Page Timeout
Internals:
ADDRESS 7C:2F:80:98:C2:2A
CHANGED
DEF lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 120 120
DeviceName 127.0.0.1:5222
FD 26
MODE lan-bluetooth
NAME Presence_GTag_RED_collect
NOTIFYDEV global
NR 3052
NTFY_ORDER 50-Presence_GTag_RED_collect
PARTIAL
STATE present SchlafLE,flurLE,wohnLE
TIMEOUT_NORMAL 120
TIMEOUT_PRESENT 120
TYPE PRESENCE
Readings:
2017-02-07 23:47:45 Batterie 56
2017-02-08 00:34:39 Battery ok
2017-02-08 00:36:00 command_accepted yes
2017-02-08 00:15:07 daemon lepresenced V0.7dev4
2017-02-08 00:37:02 device_name Gigaset G-tag
2017-02-08 00:37:02 presence present
2017-02-04 16:55:50 room SchlafLE,flurLE,wohnLE
2017-02-08 00:37:02 rooms SchlafLE,flurLE,wohnLE
2017-02-08 00:15:07 rssi -86
2017-02-08 00:37:02 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
Attributes:
comment lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 120 120
event-on-change-reading state,Battery,Batterie,presence
group PRESENCE
room Presence
sortby 12
stateFormat state room
userReadings Batterie,Battery
Danke fürs Testen. Die rssi-Geschichte sehe ich mir mal an.
Von unterwegs gesendet.
Mahlzeit!
Danke für's Testen!
Habe gerade nochmal nachgesehen. Ich setze bei Nichterreichbarkeit den rssi explizit auf "unreachable", um keine irreführenden Werte zu liefern. D. h. das "Festklemmen" muss im collectord passieren. Ich hatte das tatsächlich in einer alten Version mal als Bug drin aber schon gefixt.
@Markus: Wenn ich bei Nichterreichbarkeit einen anderen Wert liefern soll, z. B. eine Zahl, gerne.
Patrick
Hallo Markus,
der lepresenced scheint ja zu funktionieren, aber sobald ich im /etc/collectord.conf die rssi=<> einfüge, bekomme ich für alle devices den state "disconnect".
Sobald ich das im /etc/collectord.conf rssi=<> weglasse, funktionieren die Presence-devices 'normal', dann bekomme ich auch einen rssi-wert im reading, und der Wert ist entweder 'present' oder 'absent'. Ich dachte das hätte ich oben auch so beschrieben.
MIT RSSI im .conf (hier nur für einen Raum):
# room definition
[SchlafBT] # name of the room
address=127.0.0.1 # ip-address or hostname
port=5111 # tcp port which should be used (5111 is default)
presence_timeout=60 # timeout in seconds for each check when devices are present
absence_timeout=60 # timeout in secondsfor each check when devices are absent
rssi=80
[SchlafLE]
address=127.0.0.1
port=5333
presence_timeout=60
absence_timeout=60
rssi=80
Internals:
ADDRESS 7C:2F:80:98:C2:2A
DEF lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 120 120
DeviceName 127.0.0.1:5222
MODE lan-bluetooth
NAME Presence_GTag_RED_collect
NEXT_OPEN 1486589736.01148
NOTIFYDEV global
NR 3052
NTFY_ORDER 50-Presence_GTag_RED_collect
PARTIAL
STATE disconnected
TIMEOUT_NORMAL 120
TIMEOUT_PRESENT 120
TYPE PRESENCE
Readings:
2017-02-07 23:47:45 Batterie 56
2017-02-08 22:03:54 Battery ok
2017-02-08 08:04:53 command_accepted yes
2017-02-08 22:04:44 daemon lepresenced V0.7dev4
2017-02-08 22:04:44 device_name Gigaset G-tag
2017-02-08 22:07:52 presence absent
2017-02-04 16:55:50 room SchlafLE,flurLE,wohnLE
2017-02-08 22:04:44 rooms SchlafLE
2017-02-08 22:04:44 rssi -82
2017-02-08 22:34:36 state disconnected
Helper:
ABSENT_COUNT 0
PRESENT_COUNT 0
Attributes:
comment lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 120 120
event-on-change-reading state,Battery,Batterie,presence
group PRESENCE
room Presence
sortby 12
stateFormat state room
userReadings Batterie,Battery
OHNE RSSI im .conf (hier nur für einen Raum):
# room definition
[SchlafBT] # name of the room
address=127.0.0.1 # ip-address or hostname
port=5111 # tcp port which should be used (5111 is default)
presence_timeout=60 # timeout in seconds for each check when devices are present
absence_timeout=60 # timeout in secondsfor each check when devices are absent
[SchlafLE]
address=127.0.0.1
port=5333
presence_timeout=60
absence_timeout=60
Internals:
ADDRESS 7C:2F:80:98:C2:2A
DEF lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 120 120
DeviceName 127.0.0.1:5222
FD 26
MODE lan-bluetooth
NAME Presence_GTag_RED_collect
NOTIFYDEV global
NR 3052
NTFY_ORDER 50-Presence_GTag_RED_collect
PARTIAL
STATE present SchlafLE,flurLE,wohnLE
TIMEOUT_NORMAL 120
TIMEOUT_PRESENT 120
TYPE PRESENCE
Readings:
2017-02-08 22:40:19 Batterie 56
2017-02-08 22:40:17 Battery ok
2017-02-08 08:04:53 command_accepted yes
2017-02-08 22:40:28 daemon lepresenced V0.7dev4
2017-02-08 22:40:28 device_name Gigaset G-tag
2017-02-08 22:40:28 presence present
2017-02-04 16:55:50 room SchlafLE,flurLE,wohnLE
2017-02-08 22:40:28 rooms SchlafLE
2017-02-08 22:40:28 rssi -79
2017-02-08 22:40:28 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
PRESENT_COUNT 0
Attributes:
comment lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 120 120
event-on-change-reading state,Battery,Batterie,presence
group PRESENCE
room Presence
sortby 12
stateFormat state room
userReadings Batterie,Battery
Hallo inoma,
im collectord gibt es keinen rssi-Konfigparameter. Was ich geändert habe ist lediglich, das ermitteln des Raumes bei mehrfachen "present"-Räumen auf Basis des rssi-Wertes. Nur wenn alle Räume, welche "present" melden einen rssi-Wert liefern wird der Raum mit dem besten RSSI als der Raum ausgewählt in dem sich der Tag befindet.
Woher hast du die Info mit dem Konfigparameter?
Gruß
Markus
Hallo Markus,
danke für die Erklärung, ich hatte das wohl in deinem Thread #23 missverstanden.
ZitatSofern alle Räume als Addon-Data "rssi=<Zahl>" bereitstellen . . .
ich dachte das gehört ins collectord config :-(
Dann lösche ich das wieder.
Gruss, Ingolf
Damit war eher die Bereitstellung des RSSI als Zusatzdaten gemeint. ;) Wenn alle Räume die "present" melden und als Zusatzdaten ein Wert "rssi=..." bereitstellen, dann wird der Raum mit dem besten RSSI ausgewählt.
Wenn mehrere Räume "present" melden und einer keinen RSSI zur Verfügung stellt, dann werden alle Räume als Liste wie bisher gemeldet.
Gruß
Markus
Hallo Markus, danke.
Kann / soll ich noch was testen, oder macht Patrick / Du jetzt erst ein update?
Zitat
aus thread #42
@Markus: Wenn ich bei Nichterreichbarkeit einen anderen Wert liefern soll, z. B. eine Zahl, gerne.
Hallo inoma,
konntest du denn die beschriebene Änderung feststellen? Also dass bei multiplen "present" der collectord den richtigen Raum auswählt?
Ich kann das bei mir leider nicht testen, da ich keine LE-Tags habe.
@Patrick: Wenn du kein RSSI ermitteln kannst, dann schicke kein "rssi=...;" mit. Der collectord prüft bei multiplen "present"-Meldungen der verschiedenen Räume, ob alle "present"-Räume einen RSSI-Wert bereitstellen und selektiert dann den besten Raum, ansonsten wird wie bisher die Liste der meldenden Räume mitgegeben.
Da der collectord sonst soweit problemlos lief, habe ich den bereits released.
Gruß
Markus
Hallo Markus,
das mit dem richtigen Raum probiere ich heute Abend aus, das habe ich in der Tat noch nicht gemacht.
Heisst das, ich kann auch den collectord aus dem FHEM release tree über update FHEM nehmen, anstelle deinem collectord aus diesem Thread?
Gruss, Ingolf
Ja genau, ist derselbe ;)
Hi Markus!
Zitat von: Markus Bloch am 09 Februar 2017, 13:59:03
@Patrick: Wenn du kein RSSI ermitteln kannst, dann schicke kein "rssi=...;" mit. Der collectord prüft bei multiplen "present"-Meldungen der verschiedenen Räume, ob alle "present"-Räume einen RSSI-Wert bereitstellen und selektiert dann den besten Raum, ansonsten wird wie bisher die Liste der meldenden Räume mitgegeben.
Ich glaube, wir reden möglicherweise aneinander vorbei. Wenn ich die rssi nicht feststellen kann, z. B. weil der Legacy-Modus von lepresenced benutzt wird, schicke ich auch keine Werte.
Wenn lepresenced aber bei present schon rssi-Werte geschickt hat, das Device aber nun absent ist, dann schicke ich
rssi=unreachable. Sonst bliebe der letzte rssi-Wert stehen (insb. auch in FHEM wenn man lepresenced direkt anspricht) und der wäre dann schlichtweg falsch.
So wie ich Dich verstehe ist aber die rssi nur bei present relevant, d. h. es sollte keine Probleme geben.
Patrick
Hallo Markus, hallo Patrick,
nun habe ich den ganzen Abend meine G-Tags von einem der 3 Raspberry's zum anderen getragen. Im Prinzip funktionierts!!! :-)
Allerdings senden die GTag so stark, das es mit dem testen schwierig war.
Meine 'Feststellungen' / Fragen:
1) Wenn ein GTag zum Beispiel von 2 meiner 3 lepresenced Räume empfangen wird (wie unten im listing), woher weiss ich welcher Raum den 'stärkeren' Empfang hat? Unten im Listing sehe ich zwei Räume, also SchlafLE und flurLE. Ist der erste der stärkere oder der zweite? Also werden die Räume nach rssi geordnet (z. B. der stärkste zuerst) oder ist das 'random'? Mein Eindruck ist das die Reihenfolge immer die gleiche ist.
2) Was muss die minimale rssi differenz zwischen 2 Räumen sein, damit nur der stärkste Raum angezeigt wird? Weil die GTags so stark senden, habe ich teilweise immer 2 oder 3 Räume 'present', ich kann also gar nicht erkennen, ob das das 'normale' collectord/presence Verhalten ist, oder ob eine Selektion aufgrund des rssi erfolgt.
3) Im Prinzip fände ich es besser, wenn für alle Räume der rssi ausgegeben wird (also ein rssi reading pro Raum). Dann kann man viel besser debuggen und auch erkennen ob sich ein GTag zwischen 2 Räumen bewegt.
Gruss, Ingolf
Internals:
ADDRESS 7C:2F:80:98:C2:2A
CHANGED
DEF lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 60 60
DeviceName 127.0.0.1:5222
FD 29
MODE lan-bluetooth
NAME Presence_GTag_RED_collect
NOTIFYDEV global
NR 3052
NTFY_ORDER 50-Presence_GTag_RED_collect
PARTIAL
STATE present schlafLE,flurLE
TIMEOUT_NORMAL 60
TIMEOUT_PRESENT 60
TYPE PRESENCE
Readings:
2017-02-09 08:28:40 Batterie 56
2017-02-09 22:41:45 Battery ok
2017-02-09 21:34:27 command_accepted yes
2017-02-09 22:40:43 daemon lepresenced V0.7dev4
2017-02-09 22:40:43 device_name Gigaset G-tag
2017-02-09 22:40:43 presence present
2017-02-09 22:40:43 rooms schlafLE,flurLE
2017-02-09 22:40:43 rssi -81
2017-02-09 22:40:43 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
Attributes:
comment lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 120 120
event-on-change-reading state,Battery,Batterie,presence
group PRESENCE
room Presence
sortby 12
stateFormat state rooms
userReadings Batterie,Battery
Hallo Markus, hallo Patrick,
mag einer von euch noch meine Fragen beantworten?
Danke und beste Grüsse, Ingolf
Sorry, da muss Markus ran. lepresenced ist nur der Lieferant, der collectord ist der Entscheider ;)
Von unterwegs gesendet.
Ich habe leider wenig Zeit um das umfassend zu beantworten. Hole ich nach, wahrscheinlich erst nächste Woche.
Gruß
Markus
Hallo Ingolf,
tut mir Leid, dass ich erst so spät antworte. Leider habe ich momentan privat sehr wenig Zeit um mich um Modul-/FHEM-Entwicklung zu kümmern. Hier nun meine Antwort zu deinen Fragen:
Zitat von: inoma am 09 Februar 2017, 22:43:39
1) Wenn ein GTag zum Beispiel von 2 meiner 3 lepresenced Räume empfangen wird (wie unten im listing), woher weiss ich welcher Raum den 'stärkeren' Empfang hat? Unten im Listing sehe ich zwei Räume, also SchlafLE und flurLE. Ist der erste der stärkere oder der zweite? Also werden die Räume nach rssi geordnet (z. B. der stärkste zuerst) oder ist das 'random'? Mein Eindruck ist das die Reihenfolge immer die gleiche ist.
In diesem Fall konnte keine Prüfung basierend auf den RSSI durchgeführt werden, da offenbar einer der beiden Räume keinen RSSI liefert. Hast du in allen Räumen den lepresenced von Patrick, der den RSSI als "Addon-Data" mitgibt? Es ist natürlich nicht auszuschließen, dass mir hier noch ein Fehler unterlaufen ist, daher muss das getestet werden. Eine Selektion basierend auf RSSI würde zu einem einzelnen Raum führen im Reading "rooms" führen.
Zitat von: inoma am 09 Februar 2017, 22:43:39
2) Was muss die minimale rssi differenz zwischen 2 Räumen sein, damit nur der stärkste Raum angezeigt wird? Weil die GTags so stark senden, habe ich teilweise immer 2 oder 3 Räume 'present', ich kann also gar nicht erkennen, ob das das 'normale' collectord/presence Verhalten ist, oder ob eine Selektion aufgrund des rssi erfolgt.
Es gibt keine minimale Differenz. Es geht hier reinweg um das mathematische Maximum. Bedingung dabei ist, dass alle Räume die ein "present" melden auch einen RSSI liefern.
Zitat von: inoma am 09 Februar 2017, 22:43:39
3) Im Prinzip fände ich es besser, wenn für alle Räume der rssi ausgegeben wird (also ein rssi reading pro Raum). Dann kann man viel besser debuggen und auch erkennen ob sich ein GTag zwischen 2 Räumen bewegt.
Ist eine gute Idee, werde ich am Wochenende mal testweise einbauen und hier posten.
Viele Grüße
Markus
Hallo Markus,
1)
Zitat
Zitat von: inoma am 09 Februar 2017, 22:43:39
1) Wenn ein GTag zum Beispiel von 2 meiner 3 lepresenced Räume empfangen wird (wie unten im listing), woher weiss ich welcher Raum den 'stärkeren' Empfang hat? Unten im Listing sehe ich zwei Räume, also SchlafLE und flurLE. Ist der erste der stärkere oder der zweite? Also werden die Räume nach rssi geordnet (z. B. der stärkste zuerst) oder ist das 'random'? Mein Eindruck ist das die Reihenfolge immer die gleiche ist.
Markus Bloch
« am: 23 Februar um 11:00:08
In diesem Fall konnte keine Prüfung basierend auf den RSSI durchgeführt werden, da offenbar einer der beiden Räume keinen RSSI liefert. Hast du in allen Räumen den lepresenced von Patrick, der den RSSI als "Addon-Data" mitgibt? Es ist natürlich nicht auszuschließen, dass mir hier noch ein Fehler unterlaufen ist, daher muss das getestet werden. Eine Selektion basierend auf RSSI würde zu einem einzelnen Raum führen im Reading "rooms" führen.
Ja, ich habe in allen 3 Räumen den lepresenced von Patrick, der den RSSI als "Addon-Data" mitgibt. Allerdings hatte ich den G-Tag absichtlich so positioniert, das er nur von zwei-en empfangen wurde. Dann ist es vielleicht in der Tat so, das die Selektion nicht funktioniert, sonst wäre ja nur ein einziger Raum angezeigt worden.
Aber die Selektion würde ja überflüssig, wenn ür alle Räume der rssi ausgegeben wird (also ein rssi reading pro Raum).
Die Selektion kann dann der user machen, und damit auch eine eigene Triangulation / andere Berechnungen.
2)
Zitat
... Für alle Räume den RSSI .... Ist eine gute Idee, werde ich am Wochenende mal testweise einbauen und hier posten.
Ich kann es ab Montag abend gerne testen.
@Markus: Kannst Du die Einzel-rssi-Anzeige evtl. auf alle Addon-Data ausweiten, z. B. als Einzel-Readings der Art
$Raum-$Reading
?
Von unterwegs gesendet.
Mahlzeit!
Habe mal für Version 0.8 (identisch 0.7dev4) ein Paket gebaut. Werde das bei Gelegenheit mal ins SVN hochladen.
Patrick
So, Paket ist im SVN.
Patrick
Mahlzeit!
Kurze Frage: Im anderen Thread gab es eine etwas unspezifische Rückmeldung über Probleme mit dem 0.8-Paket aus Posting #59. Funktioniert das bei Euch?
Patrick
Hi Patrick,
weiß zwar jetzt nicht genau welchen anderen Thread du meinst. Aber nein scheint keine Probleme mit dem .deb Paket zu geben.
Raspi 2 mit Wheezy, Raspi 3 mit Jessie. Läuft.
Danke!
Hallo Patrick,
ja geht bei mir, ich habe das aus dem SYN genommen was Du eingecheckt hast.
So, ich hab im angehangenen collectord die RSSI-Lieferung als Reading eingebaut für alle Räume, die einen RSSI melden.
Wenn man den collectord im Loglevel 2 startet (Argument -vv) sieht man auch eine entsprechende Logmeldung, sobald eine RSSI-Prüfung durchgeführt wird (mehrere Räume "present" mit RSSI-Daten).
Freue mich über Feedback, da ich es wiegesagt nur blind entwickle ohne Testmöglichkeit.
Gruß
Markus
Hallo Markus,
danke vielmals, super, das funktioniert soweit wie gewünscht. Hier ein Listing von meinem Siemens GTAG. Wenn ich den GTAG durch die Wohnung trage, wird das rssi_*** entsprechend ge-updated, und der Raum mit dem kleinsten rssi als "Present" gesetzt.
Danke nochmal für die super Arbeit!
Internals:
ADDRESS 7C:2F:80:98:C2:2A
CHANGED
DEF lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 60 60
DeviceName 127.0.0.1:5222
FD 26
MODE lan-bluetooth
NAME Presence_GTag_RED_collect
NOTIFYDEV global
NR 3057
NTFY_ORDER 50-Presence_GTag_RED_collect
PARTIAL
STATE present flurLE
TIMEOUT_NORMAL 60
TIMEOUT_PRESENT 60
TYPE PRESENCE
Readings:
2017-03-10 08:59:16 Batterie 47
2017-03-11 18:56:42 Battery ok
2017-03-11 18:56:40 command_accepted yes
2017-03-11 19:11:04 daemon lepresenced V0.7dev4
2017-03-11 19:11:04 device_name Gigaset G-tag
2017-03-11 19:11:04 presence present
2017-03-11 19:11:04 rooms flurLE
2017-03-11 19:11:04 rssi -67
2017-03-11 19:11:04 rssi_SchlafLE -75
2017-03-11 19:11:04 rssi_flurLE -67
2017-03-11 19:11:04 rssi_wohnLE -76
2017-03-11 19:11:04 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
PRESENT_COUNT 0
@Markus: Welchen Daemon-Wert reichst Du denn durch?
Von unterwegs gesendet.
Den des anwesenden Raums flurLE.
Gruß
Markus
Hallo zusammen,
ersteinmal, tolle Arbeit! Ich habe eben einmal mit der Bluetooth-LE Anwesenheitserkennung begonnen und gleich mal das Multi-Room-Feature getestet. Bei mir wird nun mein test-tag allerdings in allen Räumen angezeigt, obwohl alle lepresenced einen rssi-Wert liefern:
2017-04-04 15:37:03 - (Main Thread) - =================================================
2017-04-04 15:37:03 - (Main Thread) - started with PID 8158
2017-04-04 15:37:03 - (Main Thread) - reading configuration file
2017-04-04 15:37:03 - (Main Thread) - no config errors found
2017-04-04 15:37:03 - (Main Thread) - forked with PID 8159
2017-04-04 15:37:03 - (Main Thread) - created socket on 0.0.0.0 with port 5222
2017-04-04 15:37:03 - (Main Thread) - finished initialization. entering main loop
2017-04-04 15:37:18 - (Main Thread) - new connection from 127.0.0.1:36568
2017-04-04 15:37:18 - (Main Thread) - received new command from 127.0.0.1:36568 - 20:cd:39:9e:d1:1c|30
2017-04-04 15:37:18 - (Main Thread) - generating new UUID for client 127.0.0.1 - d8ee0ad8eae5409675b78497d89e7351
2017-04-04 15:37:18 - (Main Thread) - created thread 1 for processing device 20:cd:39:9e:d1:1c in room Mitte for peer 127.0.0.1 (UUID: d8ee0ad8eae5409675b78497d89e7351)
2017-04-04 15:37:18 - (Main Thread) - created thread 2 for processing device 20:cd:39:9e:d1:1c in room Oben for peer 127.0.0.1 (UUID: d8ee0ad8eae5409675b78497d89e7351)
2017-04-04 15:37:18 - (Main Thread) - created thread 3 for processing device 20:cd:39:9e:d1:1c in room Büro for peer 127.0.0.1 (UUID: d8ee0ad8eae5409675b78497d89e7351)
2017-04-04 15:37:18 - (Main Thread) - created thread 4 for processing device 20:cd:39:9e:d1:1c in room Unten for peer 127.0.0.1 (UUID: d8ee0ad8eae5409675b78497d89e7351)
2017-04-04 15:37:19 - (Main Thread) - processing state message for device in room Büro (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: absence
2017-04-04 15:37:19 - (Main Thread) - processing state message for device in room Oben (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: present - data: device_name=(unknown);rssi=-90;daemon=lepresenced V0.8
2017-04-04 15:37:19 - (Main Thread) - processing state message for device in room Unten (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: present - data: device_name=Elgato Smart Key;rssi=-61;daemon=lepresenced V0.8
2017-04-04 15:37:19 - (Main Thread) - processing state message for device in room Mitte (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: present - data: device_name=Elgato Smart Key;rssi=-81;daemon=lepresenced V0.8
2017-04-04 15:37:19 - (Main Thread) - processing state message for device in room Oben (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: present - data: device_name=(unknown);rssi=-90;daemon=lepresenced V0.8
2017-04-04 15:37:19 - (Main Thread) - processing state message for device in room Unten (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: present - data: device_name=Elgato Smart Key;rssi=-61;daemon=lepresenced V0.8
2017-04-04 15:37:19 - (Main Thread) - processing state message for device in room Mitte (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: present - data: device_name=Elgato Smart Key;rssi=-81;daemon=lepresenced V0.8
2017-04-04 15:37:19 - (Thread 3) - Büro accepted command for 20:cd:39:9e:d1:1c
2017-04-04 15:37:19 - (Thread 2) - Oben accepted command for 20:cd:39:9e:d1:1c
2017-04-04 15:37:19 - (Thread 2) - Oben changing to presence timeout (180) for device 20:cd:39:9e:d1:1c
2017-04-04 15:37:19 - (Thread 4) - Unten accepted command for 20:cd:39:9e:d1:1c
2017-04-04 15:37:19 - (Thread 4) - Unten changing to presence timeout (180) for device 20:cd:39:9e:d1:1c
2017-04-04 15:37:19 - (Thread 1) - Mitte accepted command for 20:cd:39:9e:d1:1c
2017-04-04 15:37:19 - (Thread 1) - Mitte changing to presence timeout (180) for device 20:cd:39:9e:d1:1c
2017-04-04 15:37:19 - (Thread 2) - Oben accepted command for 20:cd:39:9e:d1:1c
2017-04-04 15:37:19 - (Thread 4) - Unten accepted command for 20:cd:39:9e:d1:1c
2017-04-04 15:37:19 - (Thread 1) - Mitte accepted command for 20:cd:39:9e:d1:1c
2017-04-04 15:37:38 - (Main Thread) - processing state message for device in room Büro (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: absence
2017-04-04 15:37:58 - (Main Thread) - processing state message for device in room Büro (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: absence
2017-04-04 15:38:18 - (Main Thread) - processing state message for device in room Büro (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: absence
2017-04-04 15:38:38 - (Main Thread) - processing state message for device in room Büro (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: absence
2017-04-04 15:38:58 - (Main Thread) - processing state message for device in room Büro (UUID: d8ee0ad8eae5409675b78497d89e7351) - value: absence
NR 533115
NTFY_ORDER 50-wohnung.schluessel.peter
PARTIAL
STATE present / Mitte,Oben,Unten
TIMEOUT_NORMAL 30
TIMEOUT_PRESENT 30
TYPE PRESENCE
Helper:
Dblog:
[....]
Readings:
Heute um 15:37 Uhr command_accepted yes
Heute um 15:42 Uhr daemon lepresenced V0.8
Heute um 15:42 Uhr device_name (unknown)
Heute um 15:42 Uhr presence present
Heute um 15:42 Uhr rooms Mitte,Oben,Unten
Heute um 15:42 Uhr rssi -92
Heute um 15:42 Uhr state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
Attributes:
[...]
Hab ich da noch etwas übersehen? Versionen collectord-1.7.deb und lepresenced-0.8-1.deb
LG Peter
EDIT: OK fehler gefunden, der collectord hier im Thread ist wohl noch neuer, sorry!
Ja, tut mir Leid. Ich bin nachwievor dauerhaft unterwegs und noch nicht dazu gekommen die Änderungen einzuchecken.
Werde ich erst in den nächsten Wochen schaffen.
Viele Grüße
Markus
Ich habe das jetzt mit der letzten Version hier aus dem Thread prinzipiell prima am Laufen. Aktuell collectord mit 6 lepresenced - Roomnodes, einer davon extern per VPN und nciht im selben Funkbereich. Das ist m.E. vollkommen eincheck-würdig - installiert und läuft wie beschrieben und problemfrei.
Die Raumerkennung funktioniert prinzipiell auch, inkl. rssi-Werten je Raum, springt aber leider ziemlich oft hin- und her. Ich habe zum Test 3 Tags (Elgato Smart Keys, hatte ich zwischenzeitlich schon eingemottet) über nacht auf 3 Etagen verteilt und die Zuordnung zum Raum war leider eher zufällig und hat alle paar Minuten u.A. auch über 2 Stockwerke gewechselt. Das war aber eigentlich zu erwarten, da ich dank vieler Nachbarn eine hohe Funklast im 2,4GHz Band durch WLAN-Geräte und Handys rundherum habe.
2 kleine Bugs sind mir aufgefallen:
- Raumnamen mit Leerzeichen produzieren Unfug (der Teil nach dem Leerzeichen wandert zum Value des Readings), das müsste man ggf. aber nur mal irgendwo vermerken (hiermit quasi ja getan ;)
- Von einem der Tags wurden komischerweise seit irgendwann heute Nacht die Readings nicht mehr aktualisiert. Bei den 2 anderen schon, was ein wenig merkwürdig ist. Kann aber sein, dass ich hier zu viel rumgespielt habe (Tags in FHEM umbenennen, collectord neustartet etc.) und beobachte ich erstmal genauer.
Jedenfalls schonmal vielen Dank für das tolle Werk :)
Zitat von: peterk_de am 05 April 2017, 09:54:39
- Raumnamen mit Leerzeichen produzieren Unfug (der Teil nach dem Leerzeichen wandert zum Value des Readings), das müsste man ggf. aber nur mal irgendwo vermerken (hiermit quasi ja getan ;)
Oder besser:
Es FHEM gleichziehen: Dort sind Leerstellen im Raumnamen sehr wohl erlaubt und wird auch von mir seit vielen, vielen Jahren ohne irgendwelche "Nebenwirkungen" genutzt. Ausnahme: ROOMMATE und PRESENCE.
Ich würde es begrüssen, wenn das Verhalten an FHEM angepaßt wird und Leerstellen im Raumnamen erlaubt sind.
Gruß Martin
Zitat von: peterk_de am 05 April 2017, 09:54:39
- Raumnamen mit Leerzeichen produzieren Unfug (der Teil nach dem Leerzeichen wandert zum Value des Readings), das müsste man ggf. aber nur mal irgendwo vermerken (hiermit quasi ja getan ;)
Hab das Leerzeichenproblem in der angehangenen Version behoben. Bitte nochmals testen. Wenn dann alles soweit passt, würde ich die Version einchecken und neue Pakete bauen.
Zitat von: Martin Fischer am 05 April 2017, 21:17:41
Es FHEM gleichziehen: Dort sind Leerstellen im Raumnamen sehr wohl erlaubt und wird auch von mir seit vielen, vielen Jahren ohne irgendwelche "Nebenwirkungen" genutzt. Ausnahme: ROOMMATE und PRESENCE.
Das Modul PRESENCE hat an sich keine Probleme mit Leerzeichen im Raumnamen. In diesem Fall war der collectord schuld, der die Leerzeichen nicht entsprechend im Readingnamen maskiert hat. Das habe ich nun mit der anhängenden Version beseitigt. Sollten dir darüber hinaus weitere Probleme bekannt sein, bin ich natürlich bereit diese zu beseitigen.
Viele Grüße
Markus
Zitat von: Markus Bloch am 08 April 2017, 13:08:01
Das Modul PRESENCE hat an sich keine Probleme mit Leerzeichen im Raumnamen. In diesem Fall war der collectord schuld, der die Leerzeichen nicht entsprechend im Readingnamen maskiert hat. Das habe ich nun mit der anhängenden Version beseitigt. Sollten dir darüber hinaus weitere Probleme bekannt sein, bin ich natürlich bereit diese zu beseitigen.
Danke Markus...
Es scheint so, als wenn durch die Leerstellen die Readings verloren gehen...
muss ich mal beobachten..
Internals:
ADDRESS xx:xx:xx:xx:xx:xx
CFGFN /etc/fhem/conf.d/60_presence.cfg
CHANGED
DEF lan-bluetooth xx:xx:xx:xx:xx:xx 127.0.0.1:5223 10 30
DeviceName 127.0.0.1:5223
FD 67
MODE lan-bluetooth
NAME user.martin.gtag.01.bluetooth
NOTIFYDEV global
NR 2146
NTFY_ORDER 50-user.martin.gtag.01.bluetooth
PARTIAL
STATE present
TIMEOUT_NORMAL 10
TIMEOUT_PRESENT 30
TYPE PRESENCE
Readings:
2017-03-24 17:14:30 batterylevel 21
2017-04-08 13:28:01 command_accepted yes
2017-04-08 13:28:32 daemon lepresenced V0.8
2017-04-08 13:28:32 device_name Gigaset G-tag
2017-04-08 13:28:32 presence present
2017-04-08 13:28:32 room EG Flur
2017-04-08 13:26:44 rooms EG_Flur
2017-04-08 13:28:32 rssi -73
2017-04-08 13:28:32 rssi_1
2017-04-08 13:26:44 rssi_EG_Flur -75
2017-04-08 12:29:44 rssi_KG_Keller_2 -82
2017-04-02 15:14:52 rssi_KG_Serverraum -87
2017-03-31 14:50:17 rssi_OG_Flur -67
2017-04-08 13:26:44 rssi_OG_Wohnzimmer -80
2017-04-08 13:28:32 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT present
Attributes:
absenceThreshold 10
alias G-Tag Martin (schwarz)
attendance user.martin.presence.01.grp
devStateIcon present:HM-OU-LED16.green absent:HM-OU-LED16.off .*:HM-OU-LED16.orange
event-on-change-reading state
room Bewohner
userattr attendance attendance_map structexclude
Hat noch jemand mit der neuesten collectord-Version folgenden Fehler im collectord.log ?
PERL WARN: Use of uninitialized value in concatenation (.) or string at /usr/sbin/collectord line 948, <GEN5> line 1.
Lässt sich meines Erachtens nach leicht beheben, will aber sicher gehen das es nicht nur mir so geht.
Danke und schöne Ostern!
Kommt die RSSI Erweiterung auch in den presenced?
Ich tracke meine Bewohner hier über unsere Apple Watches, was über den presenced gut funktioniert. Für ein genaueres Raum-Tracking überlappt sich aber das Signal zu oft, so dass im room Reading öfter mal 2 Räume gleichzeitig auftauchen.
Daher wäre es praktisch, wenn der presenced hier ebenfalls die RSSI Werte melden und über den Collectord dann entscheiden lassen würde, in welchem Raum die Anwesenheit wahrscheinlicher ist.
Hallo Markus,
der collectord aus Antwort #72 funktioniert nicht richtig,
es wird nur ein rssi_ erzeugt
Readings:
2017-04-20 22:59:10 Battery low
2017-04-20 22:58:13 command_accepted yes
2017-04-20 23:01:44 daemon lepresenced V0.81
2017-04-20 23:01:44 device_name Gigaset G-tag
2017-04-20 23:01:44 presence present
2017-04-20 23:01:44 rooms wohnLE
2017-04-20 23:01:44 rssi -66
2017-04-20 23:01:44 rssi_
2017-04-20 23:01:44 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
PRESENT_COUNT 0
Sollte mit angehangener Version behoben sein.
Viele Grüße
Markus
Ich wollte mal nachfragen, ob jemand die Beseitung des Problems mit dem collectord aus dem letzten Beitrag bestätigen kann? Dann würde ich dieses einchecken und verteilen.
Danke
Gruß
Markus
Ich habe es mal probiert.
Meldung:
2017-05-29 19:36:12 - (Main Thread) - PERL WARN: Use of uninitialized value in concatenation (.) or string at ./collectord line 950, <GEN4> line 1.
Habe den Code zwar mal wieder nicht ganz verstanden (wozu das grep?), aber nach Änderung in
my $rssi_data = join(";", map("rssi_".$_."='".$rssi_results{$_}."'", (keys %rssi_results)));
hat $rssi_data den Wert
rssi_esp2='-82';rssi_esp1='-69';rssi_esp3='-81'
und die 3 Werte werden auch als Readings in FHEM angezeigt.
$_ sollte man in map nicht per regex verändern, da man nicht das veränderte $_ zurück bekommt, sondern den Returncode des regex, wie in
if ($_ =~ /x/) {
Gruß
Micky
Was mir gerade noch aufgefallen ist:
Ich habe die Readings room, rooms, rssi, rssi_raum1, rssi_raum2, rssi_raum3
Wenn die Funktion aggregateRooms erfolgreich ist, wird der Raum mit dem besten RSSI in rooms geschrieben, room bleibt aber unverändert.
Ausserdem wird rssi immer auf den ersten Raum aus dem Array $rooms[0] gesetzt.
Ich habe das bei mir jetzt so geändert, dass room der Raum mit dem besten RSSI ist und rooms eine Liste aller Räume enthält.
rssi wird auf den Wert von "room" gesetzt.
Anbei ein Screenshot
Micky
Hallo Micky,
würdest Du die Version mit dem 'room' mal dranhängen? Das finde ich schick mit der rooms übersicht für alle devices, und room für das mit dem besten RSSI.
Danke!
Gerne doch
Hallo Markus,
zu deiner Frage ob dein letzter collectord aus #78 'OK' ist - Nein, es erscheint nur ein "2017-05-30 22:49:10 rssi_ " und die einzelnen Daemons werden nicht mehr ge-updated, siehe listing unten.
Siehe auch die Analyse von Mickey in Antwort #80
Internals:
ADDRESS 7C:2F:80:98:C2:2A
CHANGED
DEF lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 63 63
DeviceName 127.0.0.1:5222
FD 27
MODE lan-bluetooth
NAME Presence_GTag_RED_collect
NOTIFYDEV global
NR 2944
NTFY_ORDER 50-Presence_GTag_RED_collect
PARTIAL
STATE present wohnLE
TIMEOUT_NORMAL 63
TIMEOUT_PRESENT 63
TYPE PRESENCE
Readings:
2017-05-30 22:48:21 Batterie 94
2017-05-30 22:48:13 Battery ok
2017-05-30 22:48:11 command_accepted yes
2017-05-30 22:49:10 daemon lepresenced V0.81
2017-05-30 22:49:10 device_name Gigaset G-tag
2017-05-30 22:49:10 presence present
2017-05-30 22:49:10 room wohnLE
2017-05-30 22:49:10 rssi -71
2017-05-30 22:49:10 rssi_
2017-05-30 22:47:28 rssi_SchlafLE -86
2017-05-30 22:47:28 rssi_flurLE -80
2017-05-30 22:47:28 rssi_wohnLE -70
2017-05-30 22:47:28 rssi_zeroLE -82
2017-05-30 22:49:10 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
PRESENT_COUNT 0
Attributes:
comment lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 120 120
event-on-change-reading state,Battery,Batterie,presence
group PRESENCE
room Presence
sortby 12
stateFormat state room
userReadings Batterie,Battery
Hallo Mickey,
danke nochmal fürs posten, dein collectord aus Antwort #83 funktioniert:
Internals:
ADDRESS 7C:2F:80:98:C2:2A
CHANGED
DEF lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 63 63
DeviceName 127.0.0.1:5222
FD 27
MODE lan-bluetooth
NAME Presence_GTag_RED_collect
NOTIFYDEV global
NR 2944
NTFY_ORDER 50-Presence_GTag_RED_collect
PARTIAL
STATE present wohnLE
TIMEOUT_NORMAL 63
TIMEOUT_PRESENT 63
TYPE PRESENCE
Readings:
2017-05-30 22:55:29 Batterie 94
2017-05-30 22:55:21 Battery ok
2017-05-30 22:55:40 command_accepted yes
2017-05-30 22:56:41 daemon lepresenced V0.81
2017-05-30 22:56:41 device_name Gigaset G-tag
2017-05-30 22:56:41 presence present
2017-05-30 22:56:41 room wohnLE
2017-05-30 22:56:41 rooms SchlafLE,flurLE,wohnLE,zeroLE
2017-05-30 22:56:41 rssi -70
2017-05-30 22:56:41 rssi_SchlafLE -83
2017-05-30 22:56:41 rssi_flurLE -80
2017-05-30 22:56:41 rssi_wohnLE -70
2017-05-30 22:56:41 rssi_zeroLE -80
2017-05-30 22:56:41 state present
Helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
PRESENT_COUNT 0
Attributes:
comment lan-bluetooth 7C:2F:80:98:C2:2A 127.0.0.1:5222 120 120
event-on-change-reading state,Battery,Batterie,presence
group PRESENCE
room Presence
sortby 12
stateFormat state room
userReadings Batterie,Battery
Vielen Dank euch beiden. Dann würde ich den collectord von Mickey heute abend einchecken und neue Pakete bauen.
Danke für die Unterstützung.
Markus
Zitat von: Phiolin am 20 April 2017, 17:03:17
Kommt die RSSI Erweiterung auch in den presenced?
Ich tracke meine Bewohner hier über unsere Apple Watches, was über den presenced gut funktioniert. Für ein genaueres Raum-Tracking überlappt sich aber das Signal zu oft, so dass im room Reading öfter mal 2 Räume gleichzeitig auftauchen.
Daher wäre es praktisch, wenn der presenced hier ebenfalls die RSSI Werte melden und über den Collectord dann entscheiden lassen würde, in welchem Raum die Anwesenheit wahrscheinlicher ist.
Gibt es schon was neues, in Sachen RSSI für den "normalen" presenced?
Theoretisch sollte das ja gehen, über hcitool rssi... eventuell muss dazu vorher gepaired werden.
Übrigens, der collectord im SVN ist nicht identisch mit dem aus Mickeys Post #83. Stattdessen ist im SVN noch die Version mit dem Concatenation error in Zeile 948, was daran liegt, dass
map { s/\s+/_/g }
korrekt eigentlich
map { s/\s+/_/rg }
heißen müsste. Ohne die /r Option gibt der Befehl nämlich ansonsten nur die Anzahl der Änderungen zurück. /r sorgt dafür, dass die geänderten Werte zurückgegeben werden.
Hat mich einiges an Kopfzerbrechen gekostet.
Markus, vielleicht kannst du noch mal prüfen, warum im SVN noch die alte Version drin ist, vermute mal, dass ist so nicht gewollt?
Ich bastle gerade die RSSI Erkennung in den normalen presenced rein, was aktuell zumindest schon mal so halbwegs bei mir funktioniert. Kann sicher noch etwas Optimierung vertragen, deshalb teste ich mal noch ein paar Tage...
Hallo Phiolin,
Zitat von: Phiolin am 25 Juli 2017, 09:23:56
Markus, vielleicht kannst du noch mal prüfen, warum im SVN noch die alte Version drin ist, vermute mal, dass ist so nicht gewollt?
Ja, da hast Du Recht. Das habe ich ganz vergessen ::) Ich habe nun eine modifizierte Version von Mickey eingecheckt. Bitte prüft diesen collectord nochmal, dann würde ich neue DEB-Pakete bauen.
Zitat von: Phiolin am 25 Juli 2017, 09:23:56
Ich bastle gerade die RSSI Erkennung in den normalen presenced rein, was aktuell zumindest schon mal so halbwegs bei mir funktioniert. Kann sicher noch etwas Optimierung vertragen, deshalb teste ich mal noch ein paar Tage...
Da bin ich mal gespannt. Ich habe das damals bewusst nicht gemacht, da es zu viel Akku ziehen könnte (getestet habe ich das nicht). Mir reichte die Aussage "anwesend/abwesend". Ich lasse mich überraschen, wie Du das ganze löst.
Viele Grüße
Markus
im Skript ist ein ) in der Zeile 949 zu viel
syntax error at ./collectord line 949, near "))"
Global symbol "$rssi_data" requires explicit package name at ./collectord line 954.
Global symbol "$rssi_data" requires explicit package name at ./collectord line 954.
Habe es jetzt am laufen. Kann mir noch jemand sagen warum bei mir keine Batteryinfos angezeigt werden?
Internals:
ADDRESS xxxx
CFGFN
DEF lan-bluetooth xxxx 10.10.0.232:5222
DeviceName 10.10.0.232:5222
FD 25
MODE lan-bluetooth
NAME Niklas.blue
NOTIFYDEV global
NR 7461
NTFY_ORDER 50-Niklas.blue
PARTIAL
STATE present
TIMEOUT_NORMAL 30
TIMEOUT_PRESENT 30
TYPE PRESENCE
READINGS:
2017-07-27 11:55:43 command_accepted yes
2017-07-27 12:07:44 daemon lepresenced V0.81
2017-07-27 12:07:44 device_name Gigaset G-tag
2017-07-27 09:34:01 model lan-bluetooth
2017-07-27 12:07:44 presence present
2017-07-27 12:07:44 room Haus LE
2017-07-27 12:07:44 rooms Haus LE
2017-07-27 12:07:44 rssi -85
2017-07-27 12:07:44 rssi_Haus LE -85
2017-07-27 12:07:44 state present
helper:
CURRENT_STATE present
CURRENT_TIMEOUT normal
DISABLED 0
Attributes:
userReadings Batterie,Battery
Zitat von: Markus Bloch am 26 Juli 2017, 23:51:20
Da bin ich mal gespannt. Ich habe das damals bewusst nicht gemacht, da es zu viel Akku ziehen könnte (getestet habe ich das nicht). Mir reichte die Aussage "anwesend/abwesend". Ich lasse mich überraschen, wie Du das ganze löst.
Bisher funktioniert das bei mir mit unseren iPhones (6 und 7 Plus) und Apple Watches relativ problemlos.
Aktuell verwende ich eine Kombi aus
hcitool name <address>
und wenn der Name zurückgegeben wird und das Device demnach anwesend ist, bestimme ich die RSSI über
hcitool cc <address> && hcitool rssi <address>
Mit "cc" kann eine Verbindung ohne vorher notwendige Koppelung aufgebaut werden, die vom Device aber schon nach wenigen Sekunden wieder abgebaut wird. Es reicht aber um über das nachgelagerte "rssi" den RSSI Wert der Verbindung auszulesen.
Beim Akku-Verbrauch habe ich bisher keine spürbare Mehrbelastung festgestellt. Bluetooth ist an den Geräten sowieso an, da sich iPhone und Apple Watch sonst nicht miteinander unterhalten könnten. Die Belastung dürfte bei aktuellen Geräten daher zu verschmerzen sein.
Das einzige Problem das ich habe ist, dass sich bei mir manchmal das Bluetooth Device am Raspberry (und auch am Synology NAS) weghängt und nur noch mit Timeouts reagiert, bis man entweder rebooted oder den Bluetooth Stack neu startet. Das scheint mir aber eher ein Stabilitätsproblem des Treibers zu sein. Das Grenze ich momentan ein, indem ich die Intervalle und Pausen zwischen den Checks erhöhe um das Device nicht zu überlasten. Das Synology NAS scheint da noch empfindlicher zu sein, verwendet aber auch eine viel ältere Version von bluez, die ich jetzt erst mal via debian-chroot durch eine aktuelle ersetzt habe. Das scheint hier schon zu helfen.
Eine Variante die ich gerade parallel teste, ist das Monitoring der Bluetooth Schnittstelle über den System-Dbus anstelle von hcitool, u.a. auch da hcitool in neuen Versionen von bluez nicht mehr enthalten sein wird, da es deprecated ist. Hierzu verwende ich ein recht kurzes und einfaches Python Script. Da muss ich noch schauen, wie ich die RSSI Daten vom Python Script an den presenced bekomme, oder ob ich das direkt an den Collectord schicken kann. Da ich weder Python noch Perl Experte bin, kämpfe ich da noch ein wenig. Wenn das alles mit PHP funktionieren würde, wäre ich wahrscheinlich schon fertig. ;)
Da hcitool Deprecated ist und in aktuellen bluez Versionen nicht mehr standardmäßig enthalten ist, müssen wir uns meines Erachtens mittelfristig eh eine andere Lösung überlegen, wie wir an die Bluetooth Daten kommen. Das wird auch den lepresenced treffen.
Die passende Variante scheint mir die bluez API für Dbus zu sein, um darüber die Daten direkt vom System-Dbus abzugreifen. Dafür gibt es vermutlich auch ein Perl Modul im CPAN, aber da ich mich weder mit Perl noch mit Python noch mit Dbus tiefgreifend auskenne, für Python aber einen Beispielcode gefunden habe, der beinahe schon das macht, was ich eh brauche, habe ich das jetzt erst mal in Python getestet.
Vermutlich wird sich das entweder in Perl adaptieren lassen, oder man schreibt den (le)presenced halt einfach in Python neu, so kompliziert ist der Code ja nicht.
Im heutigen Update des collectord sind ein paar Fehler beim Zusammenbauen der Strings für die Räume.
Neben der oben schon erwähnten zusätzlichen Klammer ')' in Zeile 949, sind in der nächsten Zeile auch noch ein paar ' und ; fehlerhaft. Der ganze Block sollte besser so aussehen, ansonsten kommen falsche Readings zurück:
if(@rooms > 0)
{
my $rssi_data = join(";", map("rssi_".$_."='".$rssi_results{$_}."'", map {s/\s+/_/rg } keys %rssi_results));
my $ret = "present".
(defined($hroom) ? ";room='".$hroom."';" : "").
"rooms='".join(",",sort @rooms)."'".
(defined($hroom) ? ";".$hash->{$hroom}{data} : (defined($hash->{$rooms[0]}{data}) ? ";".$hash->{$rooms[0]}{data} : "")).
(defined($rssi_data) ? ";".$rssi_data : "");
}
Ansonsten läuft er aber bisher problemlos. :)
Hallo zusammen,
vielen Dank für die Hinweise. Habe ich soeben korrigiert. Nun sollte alles passen.
Funktioniert auch der RSSI-Vergleich bei mehr als einem Raum?
Viele Grüße
Markus
Ja, bisher funktioniert der Vergleich hier problemlos. :)
Würde sagen, morgen noch mal abwarten und dann können neue Pakete her.
Kurze Rückmeldung: Bisher keine weiteren Probleme mit dem collectord. Kann dann also wohl gepackt werden. :)
Hoi Ihr,
ich habe mir ebenfalls ein bt-tracking nach Eurem Vorbild zusammen gebastelt.
BT via raspi3 (produktives System) ist Mist, das hat mich so Nerven gekostet...
Letztendlich zum Testen: USB Dongle via passthrough und KVM an virt. Host (lab-system) und siehe da, alles hübsch :)
All die Probleme gibt es mit dem Dongle tatsächlich nicht, wollte es ja nicht glauben - geschweige BT und WiFi gleichzeitig auf dem rapsi3. Zum Haare raufen...
Das könnte man eigentlich erwähnen oder darauf hinweisen:
https://wiki.fhem.de/wiki/Anwesenheitserkennung
Freut mich, die rssi-Werte wollte ich schon irgendwie abfragen. Schön dass Ihr das mit einbaut!
Damit ist es dann bestimmt möglich eine Art Abfrage zu erstellen, damit im Presence-Modul nicht mehrere Räume unter "rooms" auftauchen?
habe Testweise 2 Systeme laufen, Werkstatt und Wohnzimmer. In der Werkstatt ist der Empfang echt mies, daher taucht nur Werkstatt unter rooms auf.
Sobald ich in den Flur gehe, steht schon Werkstatt,Wohnzimmer unter rooms. Bin ich nur im Wohnzimmer, stehen trotzdem noch beide Räume unter rooms.
Danke Euch für die tolle Arbeit!
Grüsse,
dtavb
rooms ist doch der Plural. room der Singular. Wenn das Tag von mehreren Räumen empfangen wird, wird das in rooms abgebildet. room ist der Raum mit dem besten rssi
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Hoi micky, ooook, unter readings habe ich room nicht als Einzahl, nur rooms.
Muss ich das reading room manuell hervorholen?
Hallo.
Danke für diesen tollen thread.
Habe derzeit noch local-bluetooth Erkennung auf einem RPI laufen, würde aber gerne meinen zweiten mit collectord & presenced in Betrieb nehmen.
Wollte schon immer eine genauere Erkennung unserer Phones machen, nun geht dies mittels dem rssi Wert :D
Wo ich mir noch nicht ganz sicher bin ist, dass das deb Paket des presenced ca. 1 Jahr alt ist?
Auch wenn ich den code aufmache finde ich nichts im hinblick auf rssi.
Oder versteh ich da was falsch?
Nach der Installation lt. dem WIki mit den neuesten Paketen finde ich kein RSSI reading?
Siehe Anhang.
Freue mich über jede Hilfe ;)
Danke
pOpY
Zitat von: Phiolin am 29 Juli 2017, 22:23:13
Kurze Rückmeldung: Bisher keine weiteren Probleme mit dem collectord. Kann dann also wohl gepackt werden. :)
Hallo @Phiolin.
Wo bekomme ich deine aktuellste modifizierte presenced version inkl. rssi Unterstützung her?
Werde da nicht ganz schlau aus dem WIki: https://wiki.fhem.de/wiki/PRESENCE
Habe mir die Versionen installiert, presenced/collectord Erkennung funktioniert soweit, aber weit und breit kein rssi Wert ersichtlich.
Danke
Tobias
rssi gibts nur beim lepresenced, nicht beim presenced.
Oben ist die rede davon dass es in presenced auch (testweise) implementiert wurde, mit:
hcitool name <address>
und wenn der Name zurückgegeben wird und das Device demnach anwesend ist, bestimme ich die RSSI über
hcitool cc <address> && hcitool rssi <address>
Mit "cc" kann eine Verbindung ohne vorher notwendige Koppelung aufgebaut werden, die vom Device aber schon nach wenigen Sekunden wieder abgebaut wird. Es reicht aber um über das nachgelagerte "rssi" den RSSI Wert der Verbindung auszulesen.
Habe das manuell per SSH getestet, funktioniert wirklich, ohne zu koppeln bekommt man einen RSSI Wert ;)
Wäre toll wenn die erweiterte Version von "Phiolin" hier zur Verfügung gestellt werden könnte ::)
Danke
pOpY
Kann ich nachher machen, ist aber etwas experimentell. Bei mir funktioniert es aber weitestgehend problemlos seit vielen Wochen. :)
Mittlerweile benutze ich anstatt hcitool cc aber l2ping. Das sollte aber auch auf den meisten Systemen standardmäßig verfügbar sein.
Suche ich später raus, wenn ich wieder Zuhause bin.
Zitat von: Phiolin am 30 Oktober 2017, 08:28:00
Kann ich nachher machen, ist aber etwas experimentell. Bei mir funktioniert es aber weitestgehend problemlos seit vielen Wochen. :)
Mittlerweile benutze ich anstatt hcitool cc aber l2ping. Das sollte aber auch auf den meisten Systemen standardmäßig verfügbar sein.
Suche ich später raus, wenn ich wieder Zuhause bin.
Das wäre echt toll wenn du die hcitool version hochladen könntest.
Nur das ich es richtig verstehe, hattest du die "hcitool cc" Version Wochen problemlos im Einsatz oder die l2ping?
Ist mit l2ping auch eine rssi Messung und somit eine Raum Einstufung möglich?
Danke schon mal im Voraus
Tobias
hcitool cc und/oder l2ping werden nur verwendet, um eine lockere, nicht authentifizierte, Verbindung zum Gerät aufzubauen. Dabei bestimmt der Bluetooth Daemon dann auch gleich die RSSI, die man dann über hcitool rssi auslesen kann.
Es funktioniert beides, bei mir lief das l2ping aber stabiler. Ich hatte beides längere Zeit im Einsatz.
Die Stabilität hängt aber meines Erachtens auch weniger von der verwendeten Methode, sondern mehr von der Bluetooth Hardware und den Treibern ab. Meine presenced laufen alle auf Raspberry Pi Model B mit Raspbian und bluez Version 5.23. Damit habe ich aktuell keine Probleme mit dieser Methode. :)
Im Anhang meine presenced Version. Damit die Erweiterung mit den RSSI Werten läuft, muss diese Version explizit mit dem Parameter -r gestartet werden.
Daher muss gegebenenfalls auch noch das entsprechende Init-Script, z.B. in /etc/init.d/presenced, angepasst werden, beispielsweise indem dort in der Zeile DAEMON_ARGS das -r hinzugefügt wird:
DAEMON_ARGS="-v -r -d -l /var/log/$NAME.log"
Ursprünglich hatte ich dies für unsere iPhone und Apple Watches am Laufen. Erwähnenswert ist wahrscheinlich, dass es seit dem neuen WatchOS mit den Apple Watches nicht mehr funktioniert. Apple hat unterbunden, dass irgendwelche anderen Geräte Bluetooth Verbindungen zu den Uhren aufbauen können, daher wird eine Apple Watch aktuell mit keiner mir bekannten Linux-Methode mehr via Bluetooth gefunden. Für die iPhones funktioniert das aber immer noch sehr gut.
Wie ursprünglich geschrieben, ist die RSSI Erweiterung im presenced noch experimentell zu betrachten und auch aus diesem Grund nicht offiziell verfügbar. Da die Funktion auch stark von eurer verwendeten Hardware abhängen kann, ist hier ein Support im Fehlerfall wahrscheinlich schwierig. Man muss halt ein bisschen rumprobieren. :)
Danke für den neuen presenced, läuft soweit und liefert rssi werte.
Habe ihn auf 2x RPIs laufen in verschiedenen Räumen und einen collectord am main FHEM rpi.
Die presence wird in beiden Räumen erkannt wenn ich mich in der Mitte der beiden befinde.
Auch wenn ich nur in einem bin, wird nur dieser bei rooms angezeigt.
Jetzt meine Frage, Sollte nicht anhand des rssi entschieden werden in welchem Raum ich mich aufhalte(oder näher bin)?
Finde aber leider kein reading dazu, z.B.: "room" oder so ähnlich.
Siehe Anhang.
@Phiolin: Wie ist das gedacht?
Danke
pOpY
Vergesst es ;D Habs, einfach die neueste SVN Version von collectord und schon wird das reading room zur Verfügung gestellt.
Hätte aber eine andere Frage, vorher hatte ich es so:
- Einen RPI im Wohnzimmer mit mehreren local-bluetooth PRESENCE
- absenceThreshold bei jedem PRESENCE auf 20, damit einfach ein bisschen Zeit vergeht bis absent gesetzt wird
- Diese zusammengefasst mit einer structure
- Auf das Zusammengefasste structure einen watchdog: DEF P_WZ__BT_All:absent 00:05 P_WZ__BT_All:present {evtWZBTAbsentHandler()} ; setstate watchdog_Niemand_im_WZ defined
Dies funktionierte ganz gut sobald keiner mehr im WZ war wurde nach 5 min der evtWZBTAbsentHandler() ausgeführt, was dann alles abschaltete.
Jetzt wo ich 2 RPIs habe werden die Clients ja nicht mehr absent gesetzt sondern z.B.: nur der room geändert.
Wie realisiere ich das gleiche wie vorher?
Wie kann ich dem Watchdog mitgeben dass er nicht state sondern room von allen liest?
Dann sollte ev. sowas ähnliches wie (symbolisch, syntax ist sicher falsch):
DEF P_BT_.*:room:Wohnzimmer 00:05 P_BT_.*:room:andere {evtWZBTAbsentHandler()} ; setstate watchdog_Niemand_im_WZ definedfunktionieren.
room ist ja nicht mehr gesetzt bzw. ein leerer String sobald das Gerät niergends mehr gesetzt ist, wie kann ich das event "room != Wohnzimmer" mit dem WDT abfangen?
Danke
pOpY
Hm, also ich benutze für die Raumerkennung und Schaltung von Geräten bei Verlassen oder Betreten von Räumen ein DOIF.
Da verwende ich dann als Bedingung einfach eine Regexp mit Counter, wie hier:
[#"^rr_.*":location:$_ eq "Wohnzimmer"] > 0
^rr_.* matched auf meine Residents Devices und zählt dann wie viele davon im Location Reading gerade "Wohnzimmer" stehen haben.
Diese spezielle Art der Bedingung klappt so aber meines Wissens nur im DOIF. Bei Watchdogs bin ich daher leider raus, da bei mir zu 95% nur DOIF im Einsatz ist.
Zitat von: Phiolin am 30 Oktober 2017, 22:51:18
Hm, also ich benutze für die Raumerkennung und Schaltung von Geräten bei Verlassen oder Betreten von Räumen ein DOIF.
Da verwende ich dann als Bedingung einfach eine Regexp mit Counter, wie hier:
[#"^rr_.*":location:$_ eq "Wohnzimmer"] > 0
^rr_.* matched auf meine Residents Devices und zählt dann wie viele davon im Location Reading gerade "Wohnzimmer" stehen haben.
Diese spezielle Art der Bedingung klappt so aber meines Wissens nur im DOIF. Bei Watchdogs bin ich daher leider raus, da bei mir zu 95% nur DOIF im Einsatz ist.
Danke für die Info.
Ist mir soweit klar, muss mich aber erst mal mit residents usw. spielen.
Wie machst du eine Verzögerung bei verlassen? oder schaltest du immer gleich beim Event vom PRESENCE?
Wie gesagt jetzt hatte ich absenceThreshold in Kombination mit einem Watchdog verwendet.
absenceThreshold kann ich ja nicht mehr verwenden, da der User nicht mehr absent geht, sondern nur mehr den "room" wechselt.
Danke
pOpY
Vielleicht mal als Beispiel ein Eindruck von der DOIF Steuerung meiner Sonos Box im Wohnzimmer. Habe das mal teilweise mit Kommentaren versehen. Ein wenig DOIF Kenntnisse sind beim Verständnis sicherlich hilfreich, aber ich hoffe, man versteht es auch so. :)
(
## CMD 1: Morgens Radio anschalten
([#"^rr_.*":location:$_ eq "Wohnzimmer"] > 0 # Wenn mindestens ein Bewohner im Wohnzimmer ist
or [EG.wz.MS.Motion] eq "motion" # oder der Bewegungsmelder im Wohnzimmer Bewegung feststellt
or [EG.fl.MS.Motion] eq "motion") # oder der Bewegungsmelder im Flur Bewegung feststellt
and ([Haus] eq "morning" # (HOMESTATE Modul): Die Daytime auf "morning" steht
or [06:15-08:30]) # oder es generell zwischen 6:15 und 8:30 ist
and [DG.az.NE.FritzBoxCallMonitor:event] eq "disconnect" # und gerade kein Telefonanruf läuft
and [rgr_Bewohner] eq "home" # überhaupt nur dann, wenn jemand Zuhause ist
and [Sonos_Wohnzimmer:transportState] ne "PLAYING" # und im Wohnzimmer nicht schon irgendwas anderes auf der Sonos Box läuft
and [EG.wz.TV.SonyBravia:power] eq "off" # und der Fernseher aus ist
and [EG.wz.FB.Harmony:currentActivity] eq "PowerOff" # und die Harmony Fernbedienung auf "Alles aus" steht
) (
set Sonos_Wohnzimmer RemoveMember Sonos_Wohnzimmer, # Dann entferne den Wohnzimmer Lautsprecher aus allen Gruppen
(sleep 2; set Sonos_Wohnzimmer:FILTER=Volume!=25 Volume 25), # Setze die Lautstärke auf einen normalen Level
(sleep 5; set Sonos_Wohnzimmer LoadRadio /WDR.2/), # Lade den WDR 2 Stream
(sleep 10; set Sonos_Wohnzimmer Play) # und los gehts :-)
) DOELSEIF (
## CMD 2: Wenn irgendwo im Haus ein Sonos Lautsprecher läuft und dann jemand ins Wohnzimmer kommt,
## füge den Wohnzimmer Lautsprecher der Gruppe hinzu und nehme damit quasi die Musik mit ins Wohnzimmer (Follow-Me)
[?Sonos:MasterPlayerPlayingCount] == 1
and ([#"^rr_.*":location:$_ eq "Wohnzimmer"] > 0
or [EG.wz.MS.Motion] eq "motion"
or [EG.fl.MS.Motion] eq "motion")
and [?Sonos_Wohnzimmer:transportState] ne "PLAYING"
and [?Sonos_Wohnzimmer:IsMaster] == 1
and [rgr_Bewohner] eq "home"
and [EG.wz.TV.SonyBravia:power] eq "off"
and [EG.wz.FB.Harmony:currentActivity] eq "PowerOff"
) (
set Sonos_Wohnzimmer:FILTER=Volume>25 Volume 25,
set [Sonos:MasterPlayerPlaying:"([a-zA-Z_]+)"] AddMember Sonos_Wohnzimmer
) DOELSEIF (
## CMD 3: Wenn keiner im Raum ist, stoppe die Wiedergabe im Wohnzimmer
[#"^rr_.*":location:$_ eq "Wohnzimmer"] == 0
and [EG.wz.MS.Motion] eq "nomotion"
and [EG.fl.MS.Motion] eq "nomotion"
) (
set Sonos_Wohnzimmer RemoveMember Sonos_Wohnzimmer,
(sleep 5; set Sonos_Wohnzimmer:FILTER=IsMaster=1 Stop)
) DOELSEIF (
## CMD 4: Wenn jemand anruft, pausiere die Wiedergabe im Wohnzimmer
([DG.az.NE.FritzBoxCallMonitor:event] eq "ring"
or [DG.az.NE.FritzBoxCallMonitor:event] eq "call")
and [?Sonos_Wohnzimmer:IsMaster] == 1
and [?Sonos_Wohnzimmer:transportState] eq "PLAYING"
) (
set Sonos_Wohnzimmer Pause
) DOELSEIF (
## CMD 5: Wenn der Telefonanruf beendet ist, setze die Wiedergabe fort
[DG.az.NE.FritzBoxCallMonitor:event] eq "disconnect"
and [?$SELF:cmd_nr] == 4
and [?Sonos_Wohnzimmer:IsMaster] == 1
and ([?Sonos_Wohnzimmer:transportState] eq "PAUSED_PLAYBACK"
or [?Sonos_Wohnzimme:transportState] eq "STOPPED")
) (
set Sonos_Wohnzimmer Play
) DOELSEIF (
## CMD 6: Wenn der Fernseher an ist, stoppe die Wiedergabe im Wohnzimmer
([EG.wz.TV.SonyBravia:power] eq "on"
or [EG.wz.FB.Harmony:currentActivity] ne "PowerOff")
and [?Sonos_Wohnzimmer:transportState] eq "PLAYING"
) (
set Sonos_Wohnzimmer RemoveMember Sonos_Wohnzimmer,
(sleep 5; set Sonos_Wohnzimmer Stop)
) DOELSEIF (
## CMD 7: Wenn ansonsten nichts zutrifft und eine Wiedergabe im Wohnzimmer läuft, dann springe hierhin und tue einfach gar nichts
## Dann kann später wieder einer der anderen Zweige angesprungen werden, da hier kein "do always" verwendet wird.
([#"^rr_.*":location:$_ eq "Wohnzimmer"] > 0
or [EG.wz.MS.Motion] eq "motion"
or [EG.fl.MS.Motion] eq "motion")
and [?Sonos_Wohnzimmer:transportState] eq "PLAYING"
) (
## Do nothing
)
Damit die Wiedergabe noch etwas weiter läuft, wenn man den Raum verlässt, verwende ich für den Zweig CMD 3 eine Verzögerung (wait) von 180 Sekunden.
Danke für das Beispiel.
Sorry für die vielen OT Fragen, das es mehr das RESIDENTS Modul betrifft habe ich meine Fragen hier gepostet: https://forum.fhem.de/index.php/topic,19040.msg707270.html#msg707270
Wäre toll wenn du mal drüber lesen könntest und ev. die eine oder andere Antwort hättest.
Danke
pOpY
@Phiolin: Eine Frage noch zu deiner Erweiterung. Was hast du bei den DEF Zeiten für absence und presence in Sekunden eingestellt (Also bei dem PRESENCE Objekt und im collectord)?
Hab das Problem dass wenn ich Raum wechsle geht dass Licht erst ca. 1,5 minuten später an, sprich der room wird gewechselt anhand dem rssi.
Da habe ich aber schon fast keinen Emofang mehr im "alten" raum und stehe fast neben dem RPI im neuen Raum.
Ich vermute es hat damit zu tun dass der presenced den rssi erst nach einem mal erkennen mittels hcitool misst.
Somit hat der alte Raum noch einen höheren rssi wert und der neue gar keinen.
Kann das sein?
Meine Zeiten sind derzeit auf 10 wenn absent und 45 wenn present.
Welche Zeiten hast du konfiguriert, ohne den Akku des Smartphones zu viel zu belasten?
Würde 10,10 gehen (in den PRESENCES & collectord)?
Oder hast du ev. noch einen Einfall was man im Code ändern kann?
Eine Idee von mir wäre gewesen mein notify zum einschalten des lichts nicht auf ROOMMATE (location, was von PRESENCE room kommt) zu machen sondern auf PRESENCE (rooms)...?
Freue mich auf Deine Antwort
Danke
pOpY
Ich habe für PRESENCE 45 und für ABSENCE 60 Sekunden eingestellt.
Zugegebenermaßen ist das bei mir kein so großes Problem, da ich die Räume primär nur für hin- und wieder kommende Sprachdurchsagen im Haus verwende. Sekundär sind sie zwar auch bei der Sonos Steuerung in Verwendung, aber da ich in jedem Raum auch Bewegungsmelder (Lichtsteuerung Philips Hue) habe, die ohnehin alle 20 Sekunden ausgelesen werden, kann ich die meisten Sachen bei denen es nicht unbedingt darauf ankommt WER im Raum ist, sondern nur OB jemand im Raum ist, sowohl über die Bewegungsmelder als auch über die Presence Devices abfragen und habe damit eher schneller Reaktionszeiten.
Vor allem für eine Lichtsteuerung sind die Reaktionszeiten über Presence Devices zu langsam. Hier wirst du wohl um Bewegungsmelder nicht drumherum kommen. Die Presence Devices eignen sich eher für nicht ganz so zeitkritische Dinge.
Danke für deine Einschätzung, werde mir BM besorgen.
Gibt es aus deiner Sicht noch eine Möglichkeit das Erkennen im presenced zu beschleunigen bzw. was ist deine Einschätzung wenn ich es auf 10,10 stelle bzgl. Smartphone Akku?
Danke
pOpY
Hallo.
Habe eine andere Möglichkeit gefunden die Sendestärke (TX Power) des Bluetooth Dongles zu reduzieren (= Reichweite zu reduzieren).
Leider lief bei mir kein Script mit hcitool cc oder l2ping auf meinem rpi2 stabil. Hatte sogar Kernel Crashes.
Mit "hcitool name" stattdessen lief alles super stabil.
Durch das reduzieren der Sendereichweite des USB Bluetooth Dongles kann ich so auch gut zwischen Räumen abgrenzen.
Weiterer Vorteil, es muss nur ein Befehl pro Benutzer abgesetzt werden (hcitool name), dadurch kann der Intervall verkürzt werden und die
Ansprechzeit beim Betreten von Räumen ist schnell (habs auf 15 Sekunden gestellt).
Es läuft bei mir mit folgenden USB Bluetooth Sticks "CSL - USB nano Bluetooth-Adapter V4.0": https://www.amazon.de/gp/product/B00C68IQ3C/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
Der "inolink Bluetooth 4.0 Class 1 USB Adapter" sollte auch gehen.
Wichtig ist der Chipsatz: CSR8510 A10 !
Um hcitool ohne sudo ausführen zu können, folgendes eingeben:
sudo setcap 'cap_net_raw,cap_net_admin+eip' `which hcitool`
Ab jetzt kann hcitool ohne sudo aufgerufen werden.
Wenn der Schritt ausgelassen wird, dann bei den nächsten Befehlen immer sudo voranstellen.,
Kompatibilität prüfen: sudo hciconfig hci0 inqtpl
Die letzte Meldung muss ein: Inquiry transmit power level: ...
Kommt diese nicht, unterstützt es der Stick nicht!
Habe einen älteren anderen v4.0 Stick mit anderem Chipsatz, da ging es nicht.
Mit obigen CSL Stick läuft es aber bei mir.
Zum setzten der TX Power: sudo bccmd psset -s 0x0000 0x0017 <POWER>
sudo bccmd coldreset
<POWER> ist der dBm Wert (kann auch negativ sein)!
Standard ist 4 bei dem CSL Stick was ungefähr 10m (Klasse 2 entspricht)
Ein Guter Wert für ca. 4m ist -8 dBm
Tests haben ergeben dass dieser Wert Fix gespeichert wird!
War auch nach einem Linux Reboot bzw. Stromlos Schalten noch auf den gesetzten Wert (-8)
Mit dem Wert muss natürlich experimentiert werden, da die Reichweite ja auch von der Umgebung abhängt (Wände, Aufstellort usw.)
Abfragen des Wertes: sudo hciconfig hci0 inqtpl
Verwende einfach das normale Presence Modul in FHEM mit den BT MAC Adressen und es läuft super & stabil!
Source ist das RPI Forum, danke an den Poster: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=155960#p1028789
pOpY
Ich wärm den hier noch mal auf...
Hat sich in der Entwicklung des Moduls mit RSSI noch etwas getan? Im offizellen Presenced ist es ja leider nicht enthalten.
Könnte mir jemand bitte eine kompilierte precenced.deb anhängen? Ich habe die hier angehängte Datei leider nicht zum Laufen bekommen :-(
Danke,
Sebastian
Zitat von: slor am 23 September 2018, 20:54:03
Ich wärm den hier noch mal auf...
Hat sich in der Entwicklung des Moduls mit RSSI noch etwas getan? Im offizellen Presenced ist es ja leider nicht enthalten.
Könnte mir jemand bitte eine kompilierte precenced.deb anhängen? Ich habe die hier angehängte Datei leider nicht zum Laufen bekommen :-(
Danke,
Sebastian
ich weiß nicht was Du nutzt, aber bei mir sind im normalen Modul die Werte enthalten.
Okay, der Tag ist grad nicht da, aber normal steht da eine Stärke.
Ich nutze den precenced (ohne le) mit Handys.
Laut einem Post von Phiolin sollte das mit einer weiter unten angehängten Variante gehen.
Ich nutze die neuste Version aus dem contrib. 1.5
so, grad noch mal die Versionen geprüft:
von hier hab ich die heruntergeladen: https://svn.fhem.de/fhem/trunk/fhem/contrib/PRESENCE/deb/ (https://svn.fhem.de/fhem/trunk/fhem/contrib/PRESENCE/deb/)
collectord - 1.8.1
precenced - 1.5
in der Kombi habe ich keine RSSI Werte.
Die RSSI Erkennung im presenced ist nicht Bestandteil der offiziellen Version. Sie funktioniert bei mir allerdings immer noch recht gut, auch wenn sich alle paar Tage vielleicht mal ein RasbPi verabschiedet und neu gestartet werden muss, meist wegen oben erwähnter Kernelfehler bei hcitool cc/ping abfragen.
Hm Interessant. Wie bekomme ich den deine Version zum Laufen?
Zitat von: slor am 24 September 2018, 17:41:13
Hm Interessant. Wie bekomme ich den deine Version zum Laufen?
Sorry für das LEPreseced Missverständnis.
In dem Du Sie hier aus dem Post runterlädst?
Zitat von: Phiolin am 30 Oktober 2017, 13:02:27
hcitool cc und/oder l2ping werden nur verwendet, um eine lockere, nicht authentifizierte, Verbindung zum Gerät aufzubauen. Dabei bestimmt der Bluetooth Daemon dann auch gleich die RSSI, die man dann über hcitool rssi auslesen kann.
Es funktioniert beides, bei mir lief das l2ping aber stabiler. Ich hatte beides längere Zeit im Einsatz.
Die Stabilität hängt aber meines Erachtens auch weniger von der verwendeten Methode, sondern mehr von der Bluetooth Hardware und den Treibern ab. Meine presenced laufen alle auf Raspberry Pi Model B mit Raspbian und bluez Version 5.23. Damit habe ich aktuell keine Probleme mit dieser Methode. :)
Im Anhang meine presenced Version. Damit die Erweiterung mit den RSSI Werten läuft, muss diese Version explizit mit dem Parameter -r gestartet werden.
Daher muss gegebenenfalls auch noch das entsprechende Init-Script, z.B. in /etc/init.d/presenced, angepasst werden, beispielsweise indem dort in der Zeile DAEMON_ARGS das -r hinzugefügt wird:
DAEMON_ARGS="-v -r -d -l /var/log/$NAME.log"
Ursprünglich hatte ich dies für unsere iPhone und Apple Watches am Laufen. Erwähnenswert ist wahrscheinlich, dass es seit dem neuen WatchOS mit den Apple Watches nicht mehr funktioniert. Apple hat unterbunden, dass irgendwelche anderen Geräte Bluetooth Verbindungen zu den Uhren aufbauen können, daher wird eine Apple Watch aktuell mit keiner mir bekannten Linux-Methode mehr via Bluetooth gefunden. Für die iPhones funktioniert das aber immer noch sehr gut.
Wie ursprünglich geschrieben, ist die RSSI Erweiterung im presenced noch experimentell zu betrachten und auch aus diesem Grund nicht offiziell verfügbar. Da die Funktion auch stark von eurer verwendeten Hardware abhängen kann, ist hier ein Support im Fehlerfall wahrscheinlich schwierig. Man muss halt ein bisschen rumprobieren. :)