Kennt Ihr schon die G-Tags, die Bluetooth-Tags? (eigentlich nur eine Bluetooth-Bake). Ich habe mir davon ein paar bestellt und auch erfolgreich in Betrieb.
Die Anwesenheitskontrolle über Handy läuft bei mir schon eine Weile und hat leider auch ein paar Schwächen aufgezeigt. Zum Beispiel schalten die neueren Android-Versionen regelmäßig das WLAN aus um Strom zu sparen. Das bringt FHEM leider immer wieder dazu, die Temperatur abzusenken. Alle Versuche die Handys davon abzubringen haben nicht wirklich funktioniert.
Gigaset Bluetooth-Tags
Daher habe ich mir diese Gigaset Bluetooth-Tags besorgt. Diese senden einfach nur eine Bake. Mehr erst mal nicht. Die Tags sind klein genug für den Schlüsselbund, aber für einige von Euch vielleicht doch noch zu klobig. Ich hatte mir daher auch noch andere Tags bestellt, diese sind aber immer noch nicht angekommen.
Ich werde später , wenn die Tags aus China endlich angekommen sind, mal zum Vergleich ein Foto hochladen.
Zu den G-Tags. Obwohl Bluetooth nur eine geringe Reichweite haben soll, sind die G-Tags durchaus auch über eine Etage hinweg hörbar. Im Freien sogar auf 30 Meter und mehr. Je nachdem wie gut der Bluetooth-Empfänger ist. Dabei gilt zu Bedenken, dass die Tags Bluetooth-LE Geräte (low energy) sind.
Hier hat sich gezeigt, dass das eingebaute Modul vom Raspberry PI3 besser ist, als ein USB-Bluetooth-Dongle. Und der Empfänger in meinem Motorola G5 Plus ist noch mal eine Klasse für sich.
Vorbereitung
Um ein Tag in FHEM nutzen zu können, benötigen wir als erstes seine MAC-Adresse. Daher mein dringender Rat an Euch: Nicht alle Tags gleichzeitig aktivieren!
Am einfachsten bekommt Ihr die Mac mit einem Scanner ausgelesen. Ich habe dafür mein Handy genutzt. Dabei ist mir auch das Mi-Band (Fitness-Armband) aufgefallen. Auch das lässt sich perfekt nutzen. Zumindest solange es sich nicht am Handy angemeldet hat. Sowie Bluetooth am Handy aktive ist, und das Mi-Band verbunden ist, hört es auf die Bake zu senden. Das gilt übrigens auch für die G-Tags! Diese bitte nicht mit einem Gerät verbinden (Pairing)! Die Tags senden sonst keine Bake mehr.
natürlich kann man die MAC auch mit Linux-Bordmittel auslesen:
sudo hcitool lescan
Das funktioniert aber nur, solange kein anderer Dienst das Bluetooth-Device blockiert. Wie z.B. lepresenced. Und schon sind wir beim Thema:
Lepresenced
Den lepresenced-Dienst benötigen wir bei Low Energy Geräten. Die LE-Geräte können nicht mit “ local-bluetooth“ abgefragt werden. Wir brauchen hier immer den LE-Presence-Daemon.
Diesen laden wir uns hier herunter:
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/lepresenced-0.83-3.deb
und installieren ihn:
sudo dpkg -i lepresenced-0.83-3.deb
Jetzt läuft der Daemon bereits und wartet auf Port 5333 auf Anfragen.
Leider werden jetzt sekündlich Meldungen ins Syslog und Kernel-Log geschrieben :
Bluetooth: hci0 advertising data length corrected bt_err_ratelimited: 1 callbacks suppressed
da zur Zeit keine andere Möglichkeit bekannt ist, schalten wir die Log meldungen einfach ab. Dafür erzeugen wir eine Datei in: /etc/rsyslog.d/01-blocklist.confÂ
touch /etc/rsyslog.d/01-blocklist.conf
und tragen z.B mit Nano:
nano /etc/rsyslog.d/01-blocklist.conf
die dort die Meldungen ein, welche gefiltert werden sollen:
:msg,contains,"Bluetooth: hci0 advertising data length corrected" ~ :msg,contains,"bt_err_ratelimited:" ~
Dann noch den Dienst neu starten:
sudo service syslog restart
und kontrollieren anschließend das Syslog:
tail -f /var/log/syslog
Hier sollten jetzt keine neue Meldungen mehr erscheinen.
Der Daemon kann auch auf mehreren Geräten installiert werden. So kann man eine größere Fläche abdecken und die Erkennung zuverlässiger gestalten. Bei mir läuft der Daemon auf beiden Raspberry PIs.
Auf die Installation des collectored Daemons habe ich bewusst verzichtet, ich fasse die Geräte sowieso in einer structure zusammen. Wer ihn trotzdem installieren möchte, kann im FHEM-Wiki nachlesen, da ist das recht gut beschrieben.
Presence abfragen
Kommen wir nun zum eigentlichen Abfragen der Presence. Ich frage bei mir Jeden Tag zweimal ab. Einmal auf dem lokalen PI (127.0.0.1)
define oG-TAG PRESENCE lan-bluetooth 7C:2F:80:98:C0:E4 127.0.0.1:5333 120
und auf dem entfernten PI (192.168.1.21):
define ooG-TAG PRESENCE lan-bluetooth 7C:2F:80:98:C0:E4 192.168.1.21:5333 120
Ich frage hier alle 120 Sekunden den Daemon nach dem Status der MAC-Adresse. Ihr könnt die Zeit aber auch problemlos runter setzen.
In FHEM solltet Ihr jetzt in den Readings die Rückmeldungen den Daemons sehen. Wenn es in etwa so aussieht wie auf dem Bild, habt Ihr bis hierher alles richtig gemacht ;)
Geräte in zu einer Struktur zusammen fassen
Um meinen wirklichen Presencestatus zu ermitteln, fassen ich jetzt alle meine Geräte zu einem Dummy zusammen.
Dafür definiere ich mir einen Dummy: p_Max und weise diesem mein Handy und die beiden Bluetooth-Abfragen zu:
define p_Max dummy Handy_Max_LAN o_GTAG oo_GTAG
Damit der Dummy auch wirklich in den Status „present“ wechselt, auch wenn nur ein Gerät erkannt wurde, müssen wir noch ein paar Attribute setzen.
clientstate_behavior = relative clientstate_priority = present absent event-on-change-reading = state
Das wars eigentlich schon. Wer möchte kann auch die Structure-Dummys weiter verschachteln. Zum Beispiel zu einem Dummy p_Eltern (Presence der Eltern).
NOTIFY
Jetzt kann die Änderung des Presence-Status mit einem Notify abgefangen werden. Hier ein Beispiel aus meiner Installation:
define Max_ist_present notify p_Max:present {if (Value("HomeStatus")!=2) \
{fhem("set HM_5015F0_Clima controlManu 21")}; \
{Log 1, "Max ist nach Hause gekommen"} }
Wenn Max nach Hause kommt (p_Max:present) und FHEM befindet sich nicht im Nacht-Modus ( if (Value(„HomeStatus“)!=2) ) dann setze die Zimmertemperatur für sein Zimmer auf 21 Grad („set HM_5015F0_Clima controlManu 21“). Und für die Fehlersuche schreibe mir noch ein Eintrag in das Log.
Und für die Logik. Wenn Jemand zu Hause ist, soll der Home-Status natürlich auch entsprechend gesetzt werden:
define ALLE_present notify p_ALLE:present {if ((Value("HomeStatus"))==3) \
{fhem("set HomeStatus 1")}; \
{Log 1, "Irgendeiner ist zu Hause!"} }
Es wird nur der HomeStatus auf Tag (1)Â gesetzt, wenn vorher der HomeStatus Away (3) war.
Wenn also jemand Nachts nach Hause kommt, bleiben die Heizungen aus ;)
Watchdog – Heizung aus wenn keiner zu Hause
Der Vollständigkeit halber, zeige ich Euch noch den Fall der Abwesenheit. Hierfür nutze ich den Watchdog um eine zeitliche Verzögerung zu erreichen. Die Idee entstammt noch aus der Zeit, wo ich mich nur auf den LAN-Ping zum Handy verlassen hab.
Neu lässt sich das über das Attribut „absenceTimeout“ und „presenceTimeout“ regeln (Ist glaube noch nicht im Wiki zu finden). Damit kann man bereits direkt bei der Presence-Abfrage eine Verzögerung erreichen.
Die Variante mit dem Watchdog finde ich aber weiterhin sehr praktisch.
define watchdog_Max_ist_absent watchdog p_Max:absent 00:15:00 p_Max:present set HM_5015F0_Clima controlManu 17
Damit der Watchdog nach dem auslösen sich wieder aktiviert, benötigen wir mal wieder ein Attribut:
autoRestart 1
Ich warte also 15 Minuten bevor ich die Heizung auf 17 Grad stelle. Der Timer kann jederzeit mit p_Max:present wieder beendet werden. Ist Max also mal kurz nicht present (weil Brötchen holen), wird nicht sofort seine Heizung ausgemacht.
Damit werden natürlich auch Funk-Kommandos eingespart und damit auch die Batterien der Aktoren geschont.