FHEMWiki - Benutzerbeiträge [de]

HomeMatic Templates

2018-12-04T16:07:35Z

Der-PW: kleine Rechtschreibkorrekturen

{{Infobox Modul
|ModPurpose=templates bedienen und verwalten
|ModType=h
|ModCmdRef=HMtemplate
|ModForumArea=HomeMatic
|ModTechName=98_HMtemplate.pm
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])
}}
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt.
= Warum Templates =
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wir alle Spezialisten...
Die Wahrheit allerdings bildet das nicht ab. Denn auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum denn, was bieten Templates? Hierzu muss man verstehen wie FHEM, HM, Devices, Kanäle und peers zusammenhängen.

Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register, welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.
;soll-Register Verwaltung
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:
* Reset des Device
* Batteriefehler
* inkorrektes Schreiben und Übertragungsfehler
* Austausch eines Device
:Nach Lesen der Device Register hat FHEM eine neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.
;Funktionen für Einsteiger
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templates kann man einfach austauschen und dann anwenden.
;Verwalten von Funktionen statt Registern
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen, ... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.
; Lernen aus Templates
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde.
;Globales Anpassen aller Devices
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Template ändern und diese Änderungen allen Devices zu Gute kommen lassen. Auf einmal.

= Grundsätzliches zum Template =
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können.

== Template Granularität ==
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn.

*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.
*Die Implementierung erlaubt es, Templates für jedes Register einzeln zu erstellen. 
*Weniger Templates erhöhen die Übersichtlichkeit
Die technische Lösung legt folgende Templates nahe:
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register
#Alle Register eines Kanals eines Peers für short oder long
#Alle Register eines Kanals eines Peers nur für short
#Alle Register eines Kanals eines Peers nur für long
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. 
Ein typischer Einsatz sind Schalter und Dimmer bei denen man die Aktionen der Peers festlegen will.
;usecase Template Granularität Dimmer
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.

== Template Flexibilität ==
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. 
Beispiele sind:
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen.
*MotionDetector Clients: Bei den Peers des Motiondetector (also den Schaltern) stellt man ein, wann diese reagieren sollen und wie lange diese brennen sollen.

== Template Verwaltung==
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Templatedefinition als auch die Templatezuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.

== Template Editieren==
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt.

=Das eigenen Konzept=
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.
==Architektur==
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann.
==Verhalten==
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.
===Welchen templateTyp brauche ich===
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long. 
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities.

===Welche Parameter muss ich einstellen===
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. 
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken.
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. 
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. 
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. 
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. 
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.
===Register Werte setzen===
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. 
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. 
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut. 
 
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw 
tpl_params timeOn:rampTime 
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.

=Getting started=
Was muss man also tun? Wenn man noch nichts eingerichtet hat:
define hm HMinfo
attr hm autoArchive 1
attr hm autoLoadArchive 1_load
attr hm configFilename regConfig.cfg
define ht HMtemplate

==Template erstellen und bearbeiten==
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.
===Template aus Device===
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben
device ''myDev''
Channel ''myChan''
Channel gepeert mit ''myChanPeer''. 
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long.
set ht define my1stTmpl
attr ht tpl_param timeOn # name des Parameters - hier nur einer
attr ht tpl_description "mein erstes Template"
attr ht tpl_type peer-both
<refresh browser> # select liste der attribute wird neu eingelesen
attr ht tpl_source myChan
<refresh browser> # select liste der attribute wird neu eingelesen
attr ht tpl_peer myChanPeer
<refresh browser> # select liste der attribute wird neu eingelesen
attr ht Reg_shOnTime timeOn # setzen des parameters

nun können weitere Register verändert werde.
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht.
set ht save
set ht dismiss
===Template Varianten speichern===
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern.
===Template editieren===
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.
===Template kopieren===
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.
===Template export-import===
Will man Templates exportieren nutzt man 
get ht <templatename>
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist. 
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen. 
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.

==Template einem Kanal zuweisen==
Jetzt haben wir ein Template welches long UND short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache).
set ht select my1stTmpl
attr ht entity sw1
<refresh browser>
attr ht ePeer peer1
attr ht tpl_param_timeOn 30
set ht apply
attr ht ePeer peer2
attr ht tpl_param_timeOn 180
set ht apply

attr ht entity sw2
<refresh browser>
attr ht ePeer peer1
attr ht tpl_param_timeOn 70
set ht apply

attr ht ePeer peer3
attr ht tpl_param_timeOn 1000
set ht apply

set ht dismiss
Die Register der Entities werden passend in das Device geschrieben.

==Template editieren==
Nun soll das Template grundsätzlich modfiziert werden.

set ht edit my1stTmpl
attr ht Reg_<name> <value>
attr ht Reg_<name2> <value2>
attr ht Reg_<name3> <value3>
set ht save
==Template kopieren und editieren==
Nun soll das Template grundsätzlich modfiziert werden.

set ht select my1stTmpl
attr ht Reg_<name> <value>
attr ht Reg_<name2> <value2>
attr ht Reg_<name3> <value3>
set ht saveAs my2ndTmpl
==Template weitergeben==
Will man Templates weitergeben geht das mit
get ht my1stTmpl
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.
=Verwaltung und Überblick=
Nun hat man Templates definiert und Instanziiert. Wie soll man den Überblick behalten? HMtemplate ist ein Editor - also nicht wirklich hierfür geeignet. HMinfo macht die Verwaltung.
==Template Überblick==
Will man sehen, was man so an Templates nutzt kann man eine Überscht unterschedliche sortiert ausgeben lassen - in HMinfo (hm).
get hm templateUsgG sortTemplate
get hm templateUsgG sortPeer
get hm templateUsgG all
Sowie eine Liste von Regiserlisten, welche noch kein Template nutzen (noch in Bau!!)
get hm templateUsgG noTmpl
Eine Liste der Verfügbaren Templates erhält man mit
get hm templateList all
und die Register eines Templates mit
get hm templateList <templateName>
oder
set ht select <templateName>
==Template prüfen==
Templates werden auf korrekte Implementierung in der Entity anhand eines Vergleichs der gelesenen Registern mit den gewünschten Regitern geprüft. Es ist also notwendig, dass die Registerwerte in der FHEM Kopie aktuell sind. Dann reicht ein
get hm configCheck
Sollte es zu Unstimmigkeiten kommen werden mit
set hm templateExe
alle Unstimmigkeiten überschrieben. Klar, wie immer, muss FHEM warten, bis ein Device angesprochen werden kann (Übertragungsmode) und dass die IOs nicht überlastet werden. Die Gefahr einer Überlast ist gering wenn man nicht gleich alles überschreiben will. 
Wie immer ist es hilfreich den Status der Übertragung im Blick zu haben:
get hm protoEvents
Wenn zu viel passiert ist und man protoEvents aufräumen muss dann (Achtung: es werden alle ausstehenden Kommandos gelöscht und müssen neu aktiviert werden!)
set hm clearG msgEvents
==Template löschen==
set ht delete <tempateName>
Achtung: vorher müssen alle Referenzen des Templates entfernt worden sein.

=Templates in den Entites=
Ist eine Entity mit einem Template verknüpft wird dies in den Readings angezeigt. Dies kann man sichtbar machen - und eine Anzeige von Registern in den Readings sollte dann nicht mehr notwendig sein. Empfohlen wird, den expoer mode auf rein Templates umzustellen
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 12_templOnly
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert

=Beispiele und Ideen=

Neben den typischen Templates für Schalter kann (sollte) man auch bspw für RTs einsetzen. Temperaturlisten sind nicht im Angebot. Hier gibt es bereits andere Verfahren die besser passen. Allerdings experimentire ich bei meinen RTs mit den Regelparametern und will diese dann generell setzen. Alle RTs (bei mir) sollen die gleiche Regelung haben. Ich nutze 3 Templates für meine RTs
* '''HeatDefDev''': Das Device des RT wird auf Standartwerte gesetzt. Hier nutze ich einen Parameter um die Tasten zu sperren. Dies brauche ich nicht bei allen RTs sondern nur bei denen, welche ich mit einem TC gepeert habe. Hier ist eine Lokale Änderung am TC vorzunehmen.
* '''HeatDefault''':Die Standart-Regelung. Auch hier habe ich Parameter vorgesehen. Die Devices sind identisch... bis auf die Boostzeit und die maximals Ventilöffnung. Je nach Hk begrenze ich ValveMax - hängt von den baulichen Gegebenheiten ab. Boost nutze ich im Bad zum entfeuchten.
* '''HeatRemote''': mein ''guteNacht'' Knopf macht auch vor RTs nicht halt. Ich haben an einer Remote einen Button mit allen Lichtern und RTs im Wohnbereich gekoppelt. Beim Drücken wird das Licht abgeschaltet und dieHeizung gedrosselt - bspw wenn ich als letzter ins Bett gehe. Daher brauche ich einen Parameter ''Temperatur'' um das induviduell je RT einzustellen.
set hm templateDef HeatDefDev BtnLock "Default RT Device register" globalBtnLock:off localResDis:off modusBtnLock:off backOnTime:10 cyclicInfoMsg:on lowBatLimitRT:2.1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0
set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" regAdaptive:offDeter reguIntI:20 nightTemp:17 tempOffset:0.0K dayTemp:21 reguIntPstart:5 reguExtI:20 showWeekday:off reguExtP:25 reguIntP:25 tempMax:30.5 tempMin:4.5 valveMaxPos:p1 valveOffsetRt:0 modePrioManu:all daylightSaveTime:on boostPos:30 decalcWeekday:Sat showInfo:time decalcTime:11:00 btnNoBckLight:off reguExtPstart:5 noMinMax4Manu:off modePrioParty:all valveErrPos:15 boostPeriod:p0
set hm templateDef HeatRemote temp "heatRemote set temperature" CtrlRc:autoAndTemp TempRC:p0
 
In der Übersicht für 2 RTs ergibt ein get hm templateUsg
haEss |0 |HeatDefDev|BtnLock:off
haEss_Clima |0 |HeatDefault|boost:5 valveMax:15
haEss_remote |FB8_1:short |HeatRemote|temp:13
haEss_remote |FB8_5:long |HeatRemote|temp:13
haEss_remote |FB8_5:short |HeatRemote|temp:19
haLnge |0 |HeatDefDev|BtnLock:off
haLnge_Clima |0 |HeatDefault|boost:5 valveMax:15
haLnge_remote |FB8_1:short |HeatRemote|temp:13
haLnge_remote |FB8_5:long |HeatRemote|temp:13
haLnge_remote |FB8_5:short |HeatRemote|temp:19

[[Kategorie:HomeMatic supportDevice]]
[[Kategorie:HOWTOS]]

PRESENCE

2018-11-05T18:23:23Z

Der-PW: /* Problemlösungen */ kleine Rechtschreibkorrekturen und Änderungen im Wording

{{Infobox Modul
|ModPurpose=Anwesenheitserkennung
|ModType=h

|ModTechName=73_PRESENCE.pm
|ModOwner=markusbloch
}}

Das [[PRESENCE]] Modul bietet für die Anwesenheitserkennung mehrere Varianten an:

* '''lan-ping''' - Das Überwachen via PING Checks, die durch den FHEM Server versandt werden.
* '''fritzbox''' - Das Überwachen von Geräten auf einer FritzBox via ctlmgr_ctl (Nur auf einer FritzBox möglich)
* ''' Bluetooth'''
:- '''local-bluetooth''' - Das Überwachen via Bluetooth Checks, die vom FHEM Server direkt durchgeführt werden (angeschlossener Bluetooth-Stick und die Software bluez voraussgesetzt)
:- '''lan-bluetooth''' - Das Überwachen von Bluetoothgeräten, über Netzwerk. Auf einer oder mehreren Maschinen im Netzwerk (z.B. [[:Kategorie:Raspberry Pi|Raspberry Pi]]) läuft ein Presence-Daemon, der nach Bluetooth-Geräten sucht. Um mehrere Presence-Daemon mit FHEM zu verbinden, gibt es den Collector-Daemon, der sich zu allen Presence-Damons im Netzwerk verbindet und das Ergebnis von allen zusammenfasst.
* '''function''' - Das Überwachen mithilfe einer selbst geschrieben Perl-Funktion, die den Anwesenheitsstatus zurückgibt (0 oder 1)
* '''shell-script''' - Das Überwachen mithilfe eines selbst geschriebenen Shell-Programms/Skript, das eine 0 oder 1 ausgibt, um den Anwesenheitsstatus mitzuteilen.

= Überwachen mittels Ping im WLAN/LAN =
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Um ein Gerät via Ping zu überwachen, muss folgende Definition durchgeführt werden:
:<code>define Handy PRESENCE lan-ping 192.168.0.30</code>

Dadurch wird die IP-Addresse 192.168.0.30 alle 30 Sekunden geprüft, ob sie erreichbar ist. Wenn sie erreichbar ist, ist der Status "present" (anwesend), ansonsten "absent" (abwesend).

Der Timeout kann verändert werden, indem ein Wert (in Sekunden) an das Define anhängt wird:
:<code>define Handy PRESENCE lan-ping 192.168.0.30 '''60'''</code>

Nun würde das Handy alle 60 Sekunden geprüft werden.

Nur wenn bei einem iPhone/iPad die Funktion "über WLAN synchronisieren" aktiviert ist, ist es auch im Standby zuverlässig pingbar. Standardmäßig deaktivieren Apple-Geräte ihr WLAN im Standby-Betrieb um die Akkulaufzeit zu verlängern.

Sollte die Fehlermeldung
:<code> PRESENCE (Handy) - ping command returned with output: ping: icmp open socket: Operation not permitted </code>
im Log auftauchen und lan-ping dadurch nicht funktionieren, liegt ein Berechtigungsproblem vor. Kein Grund den User fhem zu root zu machen!
Prüfe zu erst als User root ob die Capabilities gesetzt sind.
:<code>getcap /bin/ping</code>
Sollte folgendes Ergeben zu Tage fördern.
:<code>/bin/ping = cap_net_raw+ep</code>
Ist dem nicht so, setzen wir die benötigten Capabilities
:<code>setcap cap_net_raw+ep /bin/ping</code>
Mehr Informationen zum Thema Capabilities [https://manpages.debian.org/jessie/manpages-de/capabilities.7.de.html].

= FritzBox: direktes Abfragen der Aktivität via ctlmgr_ctl =
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Eine sehr häufige und auch zuverlässige Methode ist auf einer FritzBox die Abfrage mittels ctlmgr_ctl Befehl. Über diesen lassen sich alle Geräte abfragen ob sie aktiv sind. Ist ein Gerät aktiv, so gilt es als anwesend.

Dieser Modus kann allerdings nur in FHEM Installationen direkt auf einer FritzBox verwendet werden. Des weiteren muss FHEM unter dem User root laufen. Um ein Gerät zu überwachen, wird lediglich der Gerätename benötigt, so wie er unter dem Menüpunkt "Heimnetz" auftaucht.

Die erforderliche Definition:
:<code>define Handy PRESENCE fritzbox iPhone-4S</code>

= Überwachung mittels Perl-Code =
Es ist möglich zum Überwachen von Geräten eine eigene Perl-Funktion zu verwenden die dann vom PRESENCE Modul im Hintergrund aufgerufen wird.

define <name> PRESENCE function {...} [ <check-interval> [ <present-check-interval> ] ]

Sobald die Funktion den Rückgabewert 1 hat, ist das Gerät anwesend, bei 0 abwesend.

== Beispiel DHCP Überwachung auf Airport Basestation ==
Die hier vorgestellte Überwachung der DHCP Lease auf Airport Basestations per SNMP ist absolut robust gegenüber dem Ruhezustand von iOS und setzt keine weitere Konfiguration auf dem iPhone voraus. Das Abmelden beim Verlassen des Empfangsbereiches der Basestation geschieht mit etwa 5-10 Minuten Verzögerung und ist somit auch vor kurzzeitigen Empfangsproblemen sicher. Das nebenstehende Bild (???) verdeutlicht noch mal die Unterschiede zwischen einer IP-Basierten Ping-Überwachung und der Überwachung auf Ebene der Basestation oder FritzBox.

Bevor der folgende Code verwendet werden kann ist das Perl Modul Net:SNMP zu installieren (z. B. mit: <code>cpan install use Net::SNMP</code>).

Zuerst ist folgender Code in 99_myUtils.pm einzufügen, sollte diese noch nicht vorhanden sein muss diese aus dem Template welches unter Edit Files zu finden ist erzeugt werden.
'''Achtung, das ist nicht der komplette Inhalt der 99_myUtils!''' Das ist nur die einzelne Routine

<pre>
use Net::SNMP;
sub
snmpCheck($$)
{
my ($airport,$client)= @_;

my $community = "public";
my $host = $airport;
my $oid = ".1.3.6.1.2.1.3.1.1.2";
#my $oid = ".1.3.6.1.2.1.3.1.1.2.25.1.10.0.1";

my ( $session, $error ) = Net::SNMP->session(
-hostname => $host,
-community => $community,
-port => 161,
-version => 1
);

if( !defined($session) ) {
return 0;
return "Can't connect to host $host.";
}

my @snmpoids = ();

my $response = $session->get_next_request($oid);
my @nextid = keys %$response;
while ( @nextid && $nextid[0] && $nextid[0] =~ m/^$oid/ ) {
push( @snmpoids, $nextid[0] );

$response = $session->get_next_request( $nextid[0] );
@nextid = keys %$response;
}

if( !defined($response = $session->get_request( @snmpoids ) ) ) {
return 0;
}

foreach my $value (values %$response) {
return 1 if( $value eq $client )
}

return 0;
}
</pre>

Danach lässt sich das Mobilgerät so überwachen:
:<code>define iPhone PRESENCE function {snmpCheck("10.0.1.1","0x44d77429f35c")} 30 30</code>

wobei 10.0.1.1 durch die IP-Adresse der Basestation und 0x44d77429f35c durch die MAC Adresse des Geräts als HEX-Zahl ersetzt werden muss.

== Beispiel Anwesenheitserkennung mittels UniFi Controller ==

Die Anwesenheitserkennung bei Geräten in Verbindung mit UniFi-Produkten funktioniert selbst dann, wenn sich die Geräte im PowerSave-Modus befinden.

Beachte: Die Geräte werden erst ungefähr nach 5 Minuten, nachdem das Gerät das WLAN verlassen hat als disconnected angezeigt.

<code>define <NAME> PRESENCE function {ReadingsVal("<UniFi>","<NamedDevice>","") eq "connected" ? 1:0}</code>

= Überwachen mittels Events =
Der Vorteil gegenüber der Function-Variante ist, dass diese Variante ohne Blocking.pm-Overhead direkt ausgeführt werden kann und in "Echtzeit" abläuft (siehe {{Link2Forum|Topic=40287|Message=562823}}).

<code>define <NAME> PRESENCE event UniFi:NamedDevice:.disconnected UniFi:NamedDevice:.connected</code>

= Überwachen mittels Bluetooth =
== Vorbereitung und Informationen ==
=== Getestete Hardware/Software ===
* '''Raspbian System''' - wheezy, Jessie (interner BT-Controller)
* '''BT-Dongle''' - CSL NET BT USB2.0 Stick, Bluetooth V4.0, Nano '''Achtung''': Es muss ein BT V4.0 oder höher verwendet werden. Nur dieser unterstützt ''LowEnergy''
* '''BT-TAG''' - Gtag von Gigaset, TrackR, UDOO Neo, PebbleBee, iTag von Unitec, X4-LIFE Multifunkti BL-Anhänger, iTag Wireless Anti, Trackr bravo, GhostyuBeacon iBc41

=== BT-Dongle am RaspberryPI installieren ===
Um den BT-Dongle ''(hier: CSL NET BT USB2.0)'' am RaspberryPI verwenden zu können, müssen die notwendigen Pakete über die Paketverwaltung von debian nachinstalliert werden.
Wer bereits ein BT-Dongle installiert hat, kann diesen Schritt überspringen.
<pre>
apt-get install bluetooth
</pre>
Nach erfolgreicher Installation der Pakete sollte der RaspberryPI neu gestartet werden.
<pre>
sudo reboot
</pre>

Nach dem erfolgten Reboot bitte das Log des RaspberryPI auf folgende Einträge prüfen:
<pre>
Feb 12 19:52:55 fhem kernel: [ 4.773600] Bluetooth: Core ver 2.20
Feb 12 19:52:55 fhem kernel: [ 4.773748] NET: Registered protocol family 31
Feb 12 19:52:55 fhem kernel: [ 4.773765] Bluetooth: HCI device and connection manager initialized
Feb 12 19:52:55 fhem kernel: [ 4.773797] Bluetooth: HCI socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773821] Bluetooth: L2CAP socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773890] Bluetooth: SCO socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.797531] usbcore: registered new interface driver btusb
</pre>
Sobald der BT-Dongle erkannt wurde ''leuchtet'' (wenn vorhanden) auch die ''blaue/gelbe'' LED am Dongle auf.

=== BT-Tags aktivieren ===
Jetzt kann der BT-Tag aktiviert werden. Bei einigen BT-Tags muss dafür die '''Batteriesicherung''' gezogen werden.

Ein BT-Tag wird mit folgendem Befehl auf der Konsole gesucht:
<syntaxhighlight lang="bash">
sudo hcitool lescan

Ausgabe z.B.:
LE Scan ...
7C:2F:80:A1:XA:XD (unknown)
7C:2F:80:A1:XA:XD Gigaset G-tag
7C:2F:80:A1:X4:X1 (unknown)</syntaxhighlight>
Eine Übersicht über die möglichen Befehle von hcitool gibt es mit der Eingabe von:
<pre>
sudo hcitool

Ausgabe z.B.:
hcitool - HCI Tool ver 5.23
Usage:
hcitool [options] <command> [command parameters]
Options:
--help Display help
-i dev HCI device
Commands:
dev Display local devices
inq Inquire remote devices
scan Scan for remote devices
name Get name from remote device
info Get information from remote device
spinq Start periodic inquiry
epinq Exit periodic inquiry
cmd Submit arbitrary HCI commands
con Display active connections
cc Create connection to remote device
dc Disconnect from remote device
sr Switch master/slave role
cpt Change connection packet type
rssi Display connection RSSI
lq Display link quality
tpl Display transmit power level
afh Display AFH channel map
lp Set/display link policy settings
lst Set/display link supervision timeout
auth Request authentication
enc Set connection encryption
key Change connection link key
clkoff Read clock offset
clock Read local or remote clock
lescan Start LE scan
lewladd Add device to LE White List
lewlrm Remove device from LE White List
lewlsz Read size of LE White List
lewlclr Clear LE White list
lecc Create a LE Connection
ledc Disconnect a LE Connection
lecup LE Connection Update
</pre>

Falls beim SCAN kein BT-Tag gefunden wird, sollte das BT Interface neu gestartet werden. Dazu ist kein Reboot des RaspBerryPI notwendig.
<syntaxhighlight lang="bash">
sudo hciconfig hci0 down
sudo hciconfig hci0 up
sudo hcitool dev
</syntaxhighlight>

== Überwachung durch den FHEM Server direkt ==
[[Datei:Bluetooth-Adresse-iPhone.png|thumb|Bluetooth-Adresse eines iPhones]]
Jenach Aufstellungsort des FHEM Servers kann es sinnvoll sein, eine Bluetooth-Überwachung direkt durch den FHEM Server durchzuführen. Hierbei gilt allerdings zu beachten, dass Bluetooth nicht für große Reichweiten gedacht ist und in den meisten Fällen keine Wände überwinden kann. Das heisst, dass in den meisten Fällen damit nur ein Raum überwacht werden kann.

Je nach Einsatzzweck kann das auch so gewollt sein. Bluetooth USB Sticks, die bereits Bluetooth 4.0 unterstützen, können höhere Reichweiten über Zimmerwände hinaus erreichen. Vorausgesetzt, das Mobilgerät unterstützt Bluetooth 4.0.

Um eine Überwachung per Bluetooth durchführen zu können, benötigt man die Bluetooth-Adresse eines Gerätes. Diese ähnelt vom Aufbau einer MAC-Adresse. Generell wird die Adresse in den Telefon-Informationen bei Smartphones angezeigt.

Um eine Anwesenheitserkennung via Bluetooth durchzuführen, wird folgende Definition in der [[Konfiguration]] benötigt:
:<code>define Handy PRESENCE local-bluetooth XX:XX:XX:XX:XX:XX</code>

== Überwachung durch verteilte Agenten in der Wohnung (presenced/lepresenced/collectord) ==
[[Datei:Raspberry-Pi-mit-WLAN-und-Bluetooth-Stick.jpg|thumb|left|Raspberry Pi mit Bluetooth- und WLAN-USB-Stick]]
Um eine zuverlässige und flächendeckende Bluetooth-Anwesenheitserkennung durchzuführen, ist es unerlässlich, mehrere Bluetooth-Empfänger zu verwenden, die auf mehrere oder alle Räume verteilt sind.

Hierfür bietet sich zum Beispiel ein [[Raspberry Pi]] mit einem Mini-Bluetooth-USB-Stick und evtl. einem WLAN-USB-Stick an. Jeder Raum wird mit solch einem Raspberry ausgestattet und ist im WLAN Netz verfügbar.

Dieses Netz aus Raspberrys wird mit dem presenced / lepresenced Programm ausgestattet. Beide Programme sind Perl-Skripte, die als Daemon im Hintergrund laufen und auf Anfragen via Netzwerk warten. Es wird lediglich eine vollständige Perl-Grundinstallation mit Standardmodulen benötigt.

=== Unterschied presenced / lepresenced / collectord ===
presenced und lepresenced sind Programme, welche in regelmäßigen Abständen nach Bluetooth-Geräten suchen. Sobald ein Gerät, welches vorab definiert wurde, gefunden wird, wechselt der Status des Geräts in FHEM auf Anwesend. Der Unterschied zwischen presenced und lepresenced ist, dass lepresenced insbesondere für [https://de.wikipedia.org/wiki/Bluetooth_Low_Energy Bluetooth-LE-Devices] ist und presenced für "normale" Bluetooth-Geräte.

collectord wiederum ist ein Programm, welches mehrere Pis verbindet und auf allen den aktuellen Status von presenced/lepresenced abfragt. Ist das gesuchte Bluetooth-Gerät auf einem der Pi anwesend, so wird es auch in der definierten Hauptinstanz auf anwesend gesetzt. Zusätzlich wird der Pi auf dem das Gerät gefunden wurde als Reading angegeben. Sofern alle Räume einen Empfangspegel (RSSI) ermitteln können, wird bei mehreren anwesenden Räumen der Raum mit dem besten Empfangspegel selektiert (siehe {{Link2Forum|Topic=54482}}).

=== Installation von (le)presenced ===
Diese Anleitung ist sowohl für presenced, als auch für lepresenced gültig. Einfachheitshalber wird nur lepresenced erwähnt, sämtliche Schritte gehen jedoch auch mit presenced, wobei einfach die genannten Daten durch presenced ersetzt werden müssen.

Die Software lepresenced kann aktuell über drei Varianten installiert werden. Dabei ist die bevorzugte Variante (Variante 1) die Installation über das bereitgestellte .deb-Paket.
Die Variante 2 setzt voraus, dass im FHEM contrib Verzeichnis (/opt/fhem/contrib) die aktuelle Version des .deb-Pakets liegt. Die Variante 3 ist dafür gedacht, wenn man keine .deb-Pakete installieren kann/will oder es aus anderen Gründen nicht funktioniert. Es wird davon abgeraten die Variante 3 zu verwenden. Vollständigkeitshalber wird sie aber aufgeführt.

===== Installation per .deb-Paket =====

Die bevorzugte Variante ist die Installation von lepresenced durch die passenden .deb Pakete.
{{Randnotiz|RNText=Bei einem Upgrade einer älteren Version reicht es, das neue .deb Paket mit
:<code>sudo dpkg -i lepresenced-X.XX-X.deb</code>
zu aktualisieren}}

'''1.Variante:'''
Herunterladen der aktuellen lepresenced-0.83-3.deb (Stand August 2017) Datei über den Webbrowser
[https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/ SVN-Repository]. Im SVN die passende Datei auswählen und in der folgende Webseite den Link unter:
<pre>
Download in other formats:
Original Format
</pre>
anklicken und die Datei herunterladen.
Die Datei kann jetzt auf den RPi kopiert und mit folgenden Befehlen ausgeführt werden (ggf. Berechtigungen anpassen).

Alternativ per wget Befehl direkt auf den RPi (aktuelle Versionsnummer beachten)
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/lepresenced-0.83-3.deb

'''2.Variante:''' (zu Verwenden, wenn es Probleme bei Variante 1 gibt)
Herunterladen aus dem fhem contrib Verzeichnis:
Hierzu muss das contrib auf dem aktuellen Stand sein. Dazu wird die Installation von subversion (normal bereits vorhanden) benötigt.

sudo apt-get install subversion

Danach kann per
sudo svn checkout https://svn.fhem.de/fhem/trunk/fhem/contrib svnrepo

Das aktuelle Repository auf den Pi heruntergeladen werden. Danach sollte im gewählten Verzeichnis die eingecheckten Dateien verfügbar sein.
/opt/fhem/svnrepo/PRESENCE/deb

''' Installation der Variante 1 oder 2 '''

Egal welche Variante gewählt wurde, nun kann mit folgenden Befehlen das Paket installiert werden. Bitte Pfade ggf. anpassen.

'''Wichtig''': Das '''Paket''' hat eine ca. Größe von '''6,5Kb'''. Ab und an gibt es wohl Probleme mit der Installation, wodurch die Datei 11,5kb groß wird.
Diese Datei lässt sich nicht Installieren. In diesem Fall das Paket bitte mit der Variante 1 und dem Bereich "Download in other formats" herunterladen.

sudo dpkg -i lepresenced-0.83-3.deb

sudo apt-get -f install

Die Ausgabe der Installation sollte am Ende ein [ ok ] Starting lepresenced (via systemctl): lepresenced.service. ausgeben.

<pre>
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Abhängigkeiten werden korrigiert ... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
bluez-hcidump
Die folgenden NEUEN Pakete werden installiert:
bluez-hcidump
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Es müssen 157 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 490 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]
Holen: 1 http://archive.raspberrypi.org/debian/ jessie/main bluez-hcidump armhf 5.23-2+rpi2 [157 kB]
Es wurden 157 kB in 0 s geholt (921 kB/s).
Vormals nicht ausgewähltes Paket bluez-hcidump wird gewählt.
(Lese Datenbank ... 42033 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../bluez-hcidump_5.23-2+rpi2_armhf.deb ...
Entpacken von bluez-hcidump (5.23-2+rpi2) ...
Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
bluez-hcidump (5.23-2+rpi2) wird eingerichtet ...
lepresenced (0.82-1) wird eingerichtet ...
[ ok ] Starting lepresenced (via systemctl): lepresenced.service.
</pre>

'''3.Variante:'''

Bei dieser Variante wird das aktuellste lepresenced Skript aus github heruntergeladen. Das bedeutet, dass jegliche Konfiguration wie automatischer Start, Berechtigungen etc.
manuell konfiguriert werden muss. Diese Variante eignet sich nur für diejenigen, die keine .deb-Pakete installieren wollen/können oder die genau Wissen, was sie tun!
<pre>
https://github.com/mhop/fhem-mirror/blob/master/fhem/contrib/PRESENCE/lepresenced
</pre>

Zur "Installation" des Skripts folgendermaßen vorgehen:
Unter /fhem manuell den Ordner „script“ anlegen:
<pre>
mkdir script
</pre>
Datei lepresenced reinkopieren und ausführbar machen:
<pre>
sudo chmod +x /opt/fhem/script/lepresenced
sudo chgrp -cR dialout lepresenced
</pre>
Skript erstmalig starten:
<pre>
sudo ./lepresenced --loglevel LOG_EMERG -d
</pre>
Kommt beim Starten des Skript eine Fehlermeldung, müssen die Abhängigkeiten aufgelöst werden.
<pre>
Can't locate Net/Server/Daemonize.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 / usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /opt/fhem/lepresenced line 17.
BEGIN failed--compilation aborted at /opt/fhem/lepresenced line 17.
</pre>
Um die Abhängigkeiten aufzulösen muss folgendes nachinstalliert werden und anschließend ein Reboot durchgeführt werden.
<pre>
sudo apt-get install libnet-server-*
</pre>

===== Einrichtung eines Bluetooth-Geräts über FHEM =====

Nach dem letzten Schritt sind alle Bedingungen für eine abschließende Konfiguration eines BT-Geräts in FHEM abgeschlossen worden.
Jetzt kann der zum Beispiel ein G-Tag dem FHEM-Server bekannt gemacht werden:
<pre>
-- Name Modul Modus MAC vom Gtag IP vom PI Port Abfragezeit in Sekunden
define MeinGtAG PRESENCE lan-bluetooth xx:xx:xx:xx:xx:xx 127.0.0.1:5333 120
</pre>

'''Wichtig ist den angegeben Port zu unterscheiden. Für presenced muss der Port 5111 genommen werden, für lepresenced der Port 5333.'''
Den absent und present Mode kann man einfach testen, in dem man den Gtag mit Alufolie einwickelt.

Diese Variante sollte eingesetzt werden, wenn nur ein Pi nach Bluetooth-Geräten sucht. Möchte man mehr als ein Gerät nutzen um zum Beispiel eine größere Fläche abzudecken so muss mit collectored gearbeitet werden.

=== Alle Räume gemeinsam ansprechen mittels collectord ===
Um zwei presenced- oder lepresenced Installationen zu verbinden wird der collectord Daemon von Markus Bloch benötigt. Dieser kennt alle presenced-Installationen im Netzwerk und führt eine koordinierte Suche nach den gewünschten Geräten durch. Sobald ein Gerät in einem Raum erkannt wurde, meldet der collectord den Status einschließlich der Angabe des Raumes, in dem das Gerät erkannt wurde.

[[Datei:Presence_Collectord_Uebersicht.jpg|200px|thumb|left|Schematische Darstellung Presence und Collectord, Danke an dtavb]]
Auf Basis folgender Skizze wird die Einrichtung und der Betrieb der Anwesenheitserkennung und Überwachung 
mit dem PRESENCE-Modul sowie dem Skript (.deb-Paket) lepresenced beschrieben. Zusätzlich wird für die Verbindung 
mehrere lepresenced Instanzen der collectord verwendet.
Diese Skizze dient als Basis für alle genannten Konfigurationen innerhalb dieses Artikels.
{{NeuerTextBlock}}

==== Aufbau ====
; RPi1 (Hauptinstanz):
: FHEM Installation
: presence/lepresenced Installation
: collectord installation
: Sämtliche Bluetooth-Geräte in FHEM definiert
; RPi2 (Zweitsystem):
: FHEM installation
: presence/lepresenced Installation
: Sämtliche Bluetooth-Geräte in FHEM definiert

==== Installation per .deb-Paket ====
collectord wird heruntergeladen und installiert:
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/collectord-1.8.deb (Stand Januar 2018)
<pre>
sudo dpkg -i collectord-1.8.deb
</pre>

Nach der Installation befindet sich im Verzeichnis: /etc/collectord.conf die Konfigurationsdatei für das collectord. Weitere Einstellungen können unter /etc/default/collectord vorgenommen werden.

==== Konfiguration auf Shellebene ====
<pre>
sudo vi /etc/collectord.conf
</pre>

Diese Datei muss jetzt nach folgender Vorlage angepasst werden.
<pre>
# room definition
#[room-name] # name of the room
#address=192.168.0.10 # ip-address or hostname
#port=5111 # tcp port which should be used (5111 is default)
#presence_timeout=120 # timeout in seconds for each check when devices are present
#absence_timeout=20 # timeout in secondsfor each check when devices are absent

[RPi1] # Name (wird als Reading room bei den BT-Tags angezeigt) der presence Instanze
address=127.0.0.1 # Lokale Adresse RPi1 , da hier das Collectord später laufen soll!
port=5333 # Port der Presence Installation
presence_timeout=60 # Selbstgewaelte Pruefintervalle
absence_timeout=60 # Selbstgewaelte Pruefintervalle

[RPi2] # Name (wird als Reading room bei den BT-Tags angezeigt) der presence Instanze
address=192.168.178.127 # IP-Adresse der Instanz, wo nur das Presence laueft, also RPi2
port=5333 # Port der Presence Installation
presence_timeout=60 # Selbstgewaelte Pruefintervalle
absence_timeout=60 # Selbstgewaelte Pruefintervalle
</pre>

Hinweis:
* Es dürfen keine [Namen] mit Leerzeichen verwendet werden
* Der angegebene Port richtet sich danach, ob auf dem Pi presenced (Port 5111) oder lepresenced (Port 5333) nach dem Bluetooth-Gerät sucht

==== Konfiguration in FHEM ====
;RPi1
define Gtag PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222 60 ''Hinweis: (Der Port ist der, des collectord!! Standard 5222)''
;RPi2
define Gtag PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 192.168.178.127:5222 60 ''Hinweis: (Der Port ist der, des collectord!! Standard 5222 - die IP-Adresse von die von RPi1)''

Nach der Konfiguration kann der Daemon gestartet werden.
Sobald das Bluetoothgerät irgendwo in der Wohnung erkannt wurde, meldet der Collectord dies sofort
an FHEM und teilt den Raum mit in dem es erkannt worden ist. Diese Information wird im Reading "rooms" des jeweiligen BT-Gerätes dargestellt.

Zum testen sollte collectord einmalig manuell gestartet werden. Dies hat den Vorteil, dass man nochmal den Port des collectord prüfen kann, dieser steht in der Zeile <pre>created socket on 0.0.0.0 with port 5222</pre> und man sehen kann, ob der collectord richtig startet, oder Fehler auswirft. Gestartet wird mit folgendem Kommando:
<pre>
sudo collectord -vv -c /etc/collectord.conf
</pre>
Die Ausgabe sieht wie folgt aus:
<pre>
2017-04-02 17:52:55 - =================================================
2017-04-02 17:52:55 - started with PID 15554
2017-04-02 17:52:55 - reading configuration file
2017-04-02 17:52:55 - no config errors found
2017-04-02 17:52:56 - created socket on 0.0.0.0 with port 5222
2017-04-02 17:53:20 - new connection from 127.0.0.1:48656
2017-04-02 17:53:20 - created thread 1 for processing device 7C:2F:80:E1:14:31 in room RPi2 for peer 127.0.0.1 (UUID: d0beb79dd4771532eb5e207c7bf31788)
2017-04-02 17:53:20 - created thread 2 for processing device 7C:2F:80:E1:14:31 in room RPi1 for peer 127.0.0.1 (UUID: d0beb79dd4771532eb5e207c7bf31788)
2017-04-02 17:53:20 - new connection from 127.0.0.1:48662
2017-04-02 17:53:20 - new connection from 127.0.0.1:48664
2017-04-02 17:53:20 - created thread 3 for processing device 7C:2F:80:ED:BC:F7 in room RPi2 for peer 127.0.0.1 (UUID: 7495a112063d5db45e6335d3fe305e36)
2017-04-02 17:53:20 - created thread 4 for processing device 7C:2F:80:ED:BC:F7 in room RPi1 for peer 127.0.0.1 (UUID: 7495a112063d5db45e6335d3fe305e36)
2017-04-02 17:53:20 - created thread 5 for processing device 7C:2F:80:E1:2A:4D in room RPi2 for peer 127.0.0.1 (UUID: c228f8d4d33b06787f995c7903c02760)
2017-04-02 17:53:20 - created thread 6 for processing device 7C:2F:80:E1:2A:4D in room RPi1 for peer 127.0.0.1 (UUID: c228f8d4d33b06787f995c7903c02760)
2017-04-02 17:53:22 - new connection from 192.168.xxx.xxx:51638
2017-04-02 17:53:22 - created thread 7 for processing device 7C:2F:80:E1:14:31 in room RPi2 for peer 192.168.xxx.xxx (UUID: 5db7012e709d6dc2fcd8159fc0344e40)
2017-04-02 17:53:22 - created thread 8 for processing device 7C:2F:80:E1:14:31 in room RPi1 for peer 192.168.xxx.xxx (UUID: 5db7012e709d6dc2fcd8159fc0344e40)
2017-04-02 17:53:22 - new connection from 192.168.xxx.xxx:51640
2017-04-02 17:53:22 - created thread 9 for processing device 7C:2F:80:ED:BC:F7 in room RPi2 for peer 192.168.xxx.xxx (UUID: c4b4d7c654132cf88e8c1fec3a956d3d)
2017-04-02 17:53:23 - created thread 10 for processing device 7C:2F:80:ED:BC:F7 in room RPi1 for peer 192.168.xxx.xxx (UUID: c4b4d7c654132cf88e8c1fec3a956d3d)
2017-04-02 17:53:29 - new connection from 192.168.xxx.xxx:51642
2017-04-02 17:53:29 - created thread 11 for processing device 7C:2F:80:E1:2A:4D in room RPi2 for peer 192.168.xxx.xxx (UUID: ecd7081e5ae3a0d8e735c8750cb116a1)
2017-04-02 17:53:29 - created thread 12 for processing device 7C:2F:80:E1:2A:4D in room RPi1 for peer 192.168.xxx.xxx (UUID: ecd7081e5ae3a0d8e735c8750cb116a1)
</pre>

Wenn das Log wie oben abgebildet aussieht wurde alles richtig gemacht und unter dem Device in FHEM erscheint ein neues Reading "rooms" mit dem Wert der erkannten PRESENCE-Installation.

'''Verhalten presence timeout im zusammenhang mit dem Attribut "absenceThreshold" der PRESENCE Konfiguration in FHEM'''
 
In der collectord.conf sind <code>presence_timeout</code> und <code>absence_timeout</code> für den jeweiligen Raum konfiguriert.
Das bedeutet, sobald irgendein Gerät in diesem jeweiligen Raum anwesend/abwesend ist, wird das jeweilige Timeout an den verbundenen presenced/lepresenced geschickt um damit das Check-Interval entsprechend zu ändern.

In der PRESENCE-Definition kann man ebenfalls ein <code>absence_timeout</code>/<code>presence_timeout</code> setzen. Sobald sich der Zustand ändert, wird auch das jeweilige Timeout an den collectord gesandt. Dies hat aber auf die Checks in den jeweiligen Räumen und damit der collectord.conf keinen Einfluss. Der collectord schickt ein Statusupdate an PRESENCE nur, wenn das vorgegebene Timeout (von PRESENCE) erreicht ist und keine Statusänderung stattfand. Sobald eine Änderung des Status erfolgt wird natürlich sofort der Status an PRESENCE geschickt.

Das Attribut absenceThreshold/presenceThreshold funktioniert nachwievor. Hier ist nur wichtig wie man die Timeouts sowohl in PRESENCE als auch collectord.conf setzt.

'''Das Reading "room" bei einer PRESENCE Definition und der Zusammenhang zu collectord'''
 
Wenn ein BT LE Empfänger in mehr als einem Raum detektiert wird, führt der collectord (ab Version 1.8) eine RSSI-Erkennung durch. Sofern alle Räume den Empfangspegel (RSSI) ermitteln können, wird der Raum mit dem besten Empfangspegel als Raum für das "room"-Reading ausgewählt. Der lepresenced in aktueller Version von PatrickR gibt immer den Empfangspegel aus.

==== Automatischer Start ====
Wenn der collectord per .deb Paket installiert wurde, startet er automatisch bei einem Reboot mit (via systemd/init-Skript).
 

Der Collectord wird standardmäßig mit dem Port 5222 gestartet. Um diese anzupassen sind zwei Schritte notwendig: 
'''1.)''' Anpassen der /usr/bin/collectord
Hier bitte den Parameter my $opt_p von 5222 auf 5XXX abändern.

Da der collectord mittlerweile per systemd beim reboot des RPi gestarte wird muss auch diese Konfiguration auf den neuen Port angepasst werden. 
'''2.)''' Anpassen der /etc/default/collectord
<pre>
# collectord startup defaults:
# The TCP port collectord will listen for incoming connections (default: 5222)
PORT=5111
# The location of the configuration file (default: /etc/collectord.conf
CFGFILE=/etc/collectord.conf
</pre>

Manuell starten als Daemon (Parameter <code>-d</code>) mit:
<pre>
sudo collectord -c /etc/collectord.conf -d -v -l /var/log/collectord.log
</pre>

== Batterieüberwachung ==

=== Batterieüberwachung mit dem Modul BleTagBattery ===
{{Infobox Modul
|ModPurpose=Anwesenheitserkennung
|ModType=h

|ModTechName=74_BleTagBattery
|ModOwner=mumpitzstuff
}}
Mit dem Modul BleTagBattery - können die Batteriestati aller BT-LE Devices gelesen werden.
Es wird das batteryLevel und battery angelegt welches als BT-LE Tags an einer PRESENCE-Installation registriert wurden.

Vorraussetzung und Installation:

Bluez und Gattool
sudo apt-get install bluez

Das Gattool ist in den Installationen von Bluez inbegriffen.

Hinzufügen des githup für das Modul
update add http://raw.githubusercontent.com/mumpitzstuff/fhem-BleTagBattery/master/controls_bletagbattery.txt
update all
restart fhem: shutdown restart
BT-LE tags muss an einer PRESENCE-Installation des type "lan-bluetooth" registriert sein.

Nach dem Neustart von FHEM kann das Modul definiert werden:
define a new device: define <name of device> BleTagBattery

Das Modul versucht in der Standardkonfiguration alle 6 Stunden die BT-LE Devices zu erreichen und das Reading batteryLevel und battery zu aktualisieren.
Das Update kann auch manuell mit dem folgenden Befehl erzwungen werden

set <name of device> statusRequest.

Weiter Informationen und Disskussionen können dem eigentlichen [https://forum.fhem.de/index.php?topic=68104.0 Forumsbeitrag] entnommen werden,

=== Batterieüberwachung (aktuell nur G-Tags) ===

Leider überträgt der G-Tag nach der Einrichtung als Device in FHEM kein Reading mit seinem aktuellen Batteriestatus.
Dem wurde mit Hilfe des Forum Abhilfe geschaffen.
Im Folgenden wird erläutert wie die Batterieüberwachung eingerichtet werden kann.

'''Voraussetzung:'''

bc - Basiscalculator [https://packages.debian.org/de/sid/bc Bc-Paket]
<pre> sudo apt-get install bc </pre>

Anlegen eines Shellskript auf dem Raspberry System.
Die Parameter <<MAC-Adresse>> und <<TagName>> müssen durch die Werte des auszulesenden G-Tags ersetzt werden.
<pre>
#!/bin/bash
stringZ=$(sudo gatttool -b 5C:2B:80:C1:14:41 --char-read --handle=0x001b)
stringZ=${stringZ:33:2}
stringZ=$(echo "$stringZ" | tr a-f A-F)
decimal=$(echo "ibase=16; $stringZ" | bc)
perl /opt/fhem/fhem.pl 7072 "setreading MeinGtag Batterie $decimal"
</pre>

Dem Device in FHEM (hier MeinGtag) ein userReading mit dem Namen '''Batterie''' hinzufügen.
Das Shellskript mit folgendem Befehl starten:
<pre>
./GtagBatterie.sh
</pre>
'''Wichtig ist hierbei,''' dass Skript mit "./" und nicht mit "sh" aufzurufen. Beim Aufruf mit "sh GtagBatterie.sh" produziert es einen Fehler
<pre>GtagBatterie.sh: 3: GtagBatterie.sh: Bad substitution </pre>

Das Reading wird auf den ausgelesenen Wert der Batterie gesetzt.

Hinweis: Es sollte für jeden G-Tag ein eigenes Skript abgelegt werden. Das Skript kann per crontab oder fhem Kommando (system) regelmäßig aufgerufen werden.

=== Batterieüberwachung (alle Devices vom Typ "MODE=lan-bluetooth") ===

Es gibt eine weitere Möglichkeit um den Batteriestatus von LE Devices abzurufen und in FHEM als Reading darzustellen.
Dabei wird der Batteriezustand für alle LE Devices, die bereits in FHEM konfiguriert sind und per lepresenced überwacht werden, automatisch in einem shell-Script ermittelt.
Näheres dazu im Forumartikel {{Link2Forum|Topic=56960|LinkText=Erweiterung: Anwesenheitserkennung/Batterieüberwachung}}.

Vorteile:
* Automatische Ermittlung aller in FHEM konfigurierten LE Devices
* Möglichkeit, diese Devices alternativ manuell im Script einzutragen
* Es werden nur Devices abgefragt, die im Status "present" sind, also mit ziemlicher Sicherheit auch verfügbar sind
* Ein eventuell auf dem FHEM telnet-Port gesetztes Passwort kann im Script hinterlegt werden

'''Voraussetzung:'''

'''Funktionierendes lepresenced''' - siehe [[Anwesenheitserkennung#Anleitung_f.C3.BCr_ein_LE_Device_.28z.B._Gtags.2CPebbles_etc..29|Anleitung für ein LE Device (z.B. Gtags,Pebbles etc.)]]

'''socat''' - TCP port forwarder
<pre>
sudo apt-get update && sudo apt-get install socat
</pre>

'''gawk''' - Zum extrahieren der Daten
<pre>
sudo apt-get update && sudo apt-get install gawk
</pre>

'''gatttool''' - Bestandteil von bluez

gatttool ist auf den meisten Distributionen im bluez-Paket, allerdings nicht bei Opensuse. Dort muss man das Sourcepaket von bluez installieren und selbst kompilieren.
gatttool sollte dann nach /usr/bin oder /usr/local/bin kopiert werden,

Zusätzlich zu den notwendigen Erweiterungen werden für die Ausführung von gatttool '''Root-Rechte benötigt'''!

Das Script selbst gibt es hier: [https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery lebattery]

Am Besten unter /opt/fhem/script/lebattery speichern und ausführbar machen:
<syntaxhighlight lang="bash">
sudo su -
mkdir /opt/fhem/script
cd /opt/fhem/script
wget https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery
chmod 755 lebattery
</syntaxhighlight>

Je nach Bedarf können im Script noch die folgenden 3 Parameter angepasst werden:
<syntaxhighlight lang="bash">
# If allowed_telnetPort is protected by a password, add the password here
TELNETPASSWORD=""
# Attribute for batterylevel in FHEM
ATTRIBUT="batterylevel"
# Use this, if you dont want the script to determine the tags on its own
LETAGS=""
</syntaxhighlight>

Das Skript wird dann unter root folgendermaßen gestartet:
<pre>
/opt/fhem/script/lebattery -v
</pre>

Ausgabe des Skripts, wenn es mit dem Verbose Parameter -v gestartet wird.

Beide Devices sind vom Typ NUT mini, das Device mit dem FHEM-Namen '''nut_Micky''' ist im Status '''absent'''. Das zweite Device ist im Status '''present'''.
<pre>
Determining address for nut_Micky ...
nut_Micky is in state absent, no further action required

Determining address for nut_Test ...
Fetching batterylevel for nut_Test (F3:44:04:81:54:89) ...
Setting batterylevel for nut_Test to 100%
</pre>

Mein crontab-Eintrag (User root) sieht so aus:
<pre>
3 3 * * * /opt/fhem/script/lebattery -v >/opt/fhem/script/lebattery.log 2>&1
</pre>
Damit wird jeden Morgen um 3 Minuten nach 3 Uhr der Zustand der Batterien aller Devices ermittelt und in FHEM abgespeichert. 
Bevor man das mit crontab macht, sollte man allerdings zunächst sicher stellen, dass es auch ohne crontab funktioniert....

Bei Problemen kann man auch erstmal schauen, ob das mit dem gattool überhaupt funktioniert:
<pre>
gatttool -t <Typ> -b <MAC-Adresse> --char-read --uuid 0x2a19

handle: 0x0017 value: 64
</pre>
In diesem Fall hat die Batterie noch 100% (hex 64). 
Der Typ ist abhängig vom Hersteller und kann public (G-Tags) bzw. random (Nut) sein. Im Zweifelsfall beides ausprobieren.

= Beispiele =
== Anwesenheitserkennung / Anwesenheitsbenachrichtigung mit G-Tags ==
Ein Skript zur Nutzung der Gigaset G-TAGs zur Alarmierung bei öffnen und schließen von Türen und zur Anwesenheitserkennung, um die Alarmierung zu aktivieren bzw. deaktivieren.
Es kann verwendet werden um die Anwesenheit von mehrern Personen im Haushalt zu erkennen. Dabei wird eingeschränkt, dass nur bestimmte Personen die Alarmierung aktivieren können ( Eltern/Kind -Beziehung ).
Des Weiteren werden im Beispiel die Eltern benachrichtigt wenn eins der Kinder das Haus verlässt und die Eltern nicht anwesend sind.

{{Randnotiz|RNText=Namen der G-Tags in den Skripten bitte anpassen!}}

Für die ''Notify'' und die ''RESIDENTS-Erweiterung'' wird ein Dummy benötigt.
<pre>
define Alarm dummy
attr Alarm devStateIcon aktiv:secur_locked@red inaktiv:secur_open@lightgreen
attr Alarm eventMap on:aktiv off:inaktiv
attr Alarm setList on off
attr Alarm webCmd aktiv:inaktiv
attr Alarm room Alarm
</pre>

=== Mit Notify ===
<pre>
gtag.*.presence:.* {Anwesenheit_check("$EVTPART1", "$NAME")}
</pre>

Code für die 99_myUtils.pm
<pre>
### GTAG ANWESENHEITS CHECK
sub Anwesenheit_check($$) {
my ($EVENT, $NAME) = @_;

# gtag_rot - Alias Marco
# gtag_schwarz - Alias Ulli
# gtag_gruen - Alias Frida
# gtag_orange - Alias Hannah

my $RESIDENT = "rr_"; # Alle GTAGs sind Standardmäßig Residents Roommate
# $RESIDENT = "rg_" if (($NAME eq "gtag_orange") xor ($NAME eq "gtag_weis")); # Hier nur Gäste (Roomguest) Auskommentiert, da ich es so nicht brauche
my $ROOMMATE = ("$RESIDENT" . "$NAME"); # Residentsname zusammenbauen
my $ALIASNAME = AttrVal($ROOMMATE,'alias',$ROOMMATE); # ALIAS des Roommates auslesen

my $GTAG1 = Value('gtag_rot'); # ELTERN
my $GTAG2 = Value('gtag_schwarz'); # ELTERN

my $STATUS = "wahrscheinlich gerade los";
$STATUS = "anwesend" if ($EVENT eq "present"); # Status: anwesend
$STATUS = "unterwegs" if ($EVENT eq "absent"); # Status: unterwegs

Log 1, "$ALIASNAME ist $STATUS."; # LOG Eintrag erzeugen

if (($EVENT eq "present" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_gruen" xor $NAME eq "gtag_orange")) {
fhem("set teleBot send ALARMIERUNG BLEIBT AKTIV: $ALIASNAME ist da..."); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG BLEIBT AKTIV' '$ALIASNAME ist da...'"); # Pushover
}
elsif (($EVENT eq "present" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_rot" xor $NAME eq "gtag_schwarz")) {
fhem("set teleBot send ALARMIERUNG INAKTIV: $ALIASNAME ist da...; set Alarm inaktiv"); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG INAKTIV' '$ALIASNAME ist da...'; set Alarm inaktiv"); # Pushover
}
elsif (($EVENT eq "absent" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_gruen" xor $NAME eq "gtag_orange")) {
fhem("set teleBot send ALARMIERUNG BLEIBT AKTIV: $ALIASNAME hat das Haus verlassen."); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG BLEIBT AKTIV' '$ALIASNAME hat das Haus verlassen.'"); # Pushover
}
elsif (($EVENT eq "absent" && Value("Alarm") eq "inaktiv") && ($GTAG1 eq "absent" && $GTAG2 eq "absent")) {
fhem("set Alarm aktiv; set teleBot send ALARMIERUNG AKTIV: $ALIASNAME hat das Haus verlassen."); # Telegram
# fhem("set Alarm aktiv; set Infopush msg 'ALARMIERUNG AKTIV' '$ALIASNAME hat das Haus verlassen.' '' 0 ''"); # Pushover
}
}
</pre>

 

=== Mit Notify und Integration des RESIDENTS-MODUL ===

Der hier beschriebene Code erweitert die Funktionen unter dem Punkt 5.93.
Das Notify muss daher mit der folgenden Zeile erweitert werden.

<pre>
define Alarm_AnwesenheitCheck notify gtag.*.presence:.* { Anwesenheit_check("$EVTPART1", "$NAME"), Anwesenheit_check_resi("$NAME") }
</pre>

Zusätzlicher Code für die 99_myUtils.pm um die RESIDENTS Funktion nutzen zu können:
<pre>
### RESIDENTS
sub Anwesenheit_check_resi($) {
my ($NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME); # ALIASNAME des GTAGs auslesen

my $RESIDENT = "rr_"; # Als Standard sind alle GTAGs Roommates
$RESIDENT = "rg_" if (($NAME eq "gtag_orange") xor ($NAME eq "gtag_weis")); # Hier nur GTAG Namen der Gäste (Roomguest)
my $ROOMMATE = ("$RESIDENT" . "$ALIASNAME"); # Residentsname zusammenbauen

if (ReadingsVal($NAME,'presence',$NAME) eq "absent") {
fhem("set $ROOMMATE absent"); # Resisents Status von Roommates setzen
}
elsif(ReadingsVal($NAME,'presence',$NAME) eq "present") {
fhem("set $ROOMMATE home"); # Resisents Status von Roommates setzen
}
}
</pre>
 

=== Mit Notify und Fenster/Tür. -Kontakt Überwachung ===

Erweiterung für die Überwachung von Fenster/Tür. -Kontakten. Dazu sind zwei weitere Notifys notwendig die auf die Trigger der Kontakte regagieren
und so eine weitere Funktion in der 99_myUtils.pm ansprechen. Die Notifys triggern auf Kontakte die mit dem Namen Kontakt* beginnen.
Sollten die eigenen Fenster/Tür. -Kontakt anderen Namen besitzen, müssen die Skripte dementsprechend angepasst werden.
<pre>
define Alarm_Kontaktmeldung notify Kontakt.*:contact:.* {Kontakt_Meldung("$EVTPART1", "$NAME")}
</pre>
<pre>
define Alarm_Sabotagealarm notify Kontakt.*.sabotageError:.on {Kontakt_Sabotage("$EVTPART1", "$NAME")}
</pre>

Zusätzlicher Code für die 99_myUtils.pm um die TÜRKONTAKTE-Meldung nutzen zu können:
<pre>
### TÜRKONTAKTE-Meldung/Zustand
sub Kontakt_Meldung($$) {
my ($EVENT, $NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME);
Log 1, "$ALIASNAME wurde $EVENT";
if (ReadingsVal("Alarm", "state", "on") eq "on") {
fhem("set teleBot send $ALIASNAME wurde $EVENT"); # Nachricht über Telegram
# fhem("set Infopush msg '$ALIASNAME' '$ALIASNAME wurde $EVENT'"); # Nachricht über Pushover
}
}

### TÜRKONTAKTE-Sabotagealarm

sub Kontakt_Sabotage($$) {
my ($EVENT, $NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME);
Log 1, "$ALIASNAME meldet Sabotagealarm";
fhem("set teleBot send Alarm: $ALIASNAME meldet Sabotagealarm"); # Nachricht über Telegram
# fhem("set Infopush msg 'Alarmanlage' '$ALIASNAME meldet Sabotagealarm' '' 2 ' ' 60 600 "); # Nachricht über Pushover
}
</pre>
 

=== Hinweis zur Benutzung / Fehlerhandling ===

Der Alarm dummy hat den Zustand on:off. Die Bezeichnungen und Namen müssen 1:1 übernommen werden damit das Script funktioniert.
Andernfalls müssen die Bezeichnungen für z.B. absent:unterwegs und present:anwesend - angepasst werden.
Die Benachrichtigung kann aktuell per ''Telegram'' sowie ''Pushover'' ('''Achtung mit zweiterem sind Abokosten verbunden!''') realisiert werden.
Diskussion zum Thema im Forum unter: {{Link2Forum|Topic=64080}}
 

= Problemlösungen =
Falls es '''Probleme beim Starten des Skripts''' gibt bzw. man das Skript ohne Reboot des Systems neustarten möchte, kann man dies per kill Befehl erledigen.
<syntaxhighlight lang="bash">
ps -ef | grep lepresenced
sudo kill <pid>
</syntaxhighlight>

Debuglevel lepresenced setzen:
{{Randnotiz|RNText=Um Debug-Meldungen zu bekommen (Vorsicht bei SD-Karten-Systemen wie dem RPi) - Hierbei werden die Schreibzyklen auf die SD-Karte erhöht.}}

Der Log Level muss im lepresenced-Skript selbst verändert werden. Um den Log-Level auf INFO/WARNING/DEBUG zu setzen, das Skript lepresenced mit einem Editor öffnen und die Stellen, wo LOG_WARNING zu finden ist, durch den nötigen LOG-Eintrag ersetzen.

<pre>
lepresenced --loglevel LOG_DEBUG
</pre>
Nur das wichtigste Loggen:
<pre>
lepresenced --loglevel LOG_WARNING
</pre>
Keinerlei LOG-Einträge
<pre>
lepresenced --loglevel LOG_EMERG
</pre>

Bei '''Problemen mit der Batterieüberwachung''' der Tags kann die Pi Firmware mit folgenden Befehl auf eine ältere Version zurückgesetzt werden.
Fehlermeldung beim Aufruf des lebattery oder anderen Batterietestskripten:
<pre>connect: Connection refused (111)</pre>

Lösung (vorübergehend)
<pre>
sudo rpi-update 8521fd34c8f66b6d109acce943f6e25ec93ec005
</pre>

Mehr dazu unter: {{Link2Forum|Topic=56960|Message=589165}}

'''Das BT-Device ist ständig "absent"''' 
Eine Mögliche Lösung kann sein, das Paket bluez-hcidump zu installieren. Das Werkzeug hcidump erlaubt die Beobachtung von Bluetooth-Aktivitäten.
Dies ist nicht notwendig, wenn bereits bluez installiert ist, da dies Teil des bluez Paketes ist
<pre>
sudo apt-get install bluez-hcidump
</pre>

'''Fehler in Logdateien /var/log/syslog und /var/log/kernel'''
Jul 29 15:08:11 raspberrypi kernel: [ 4905.634211] bt_err_ratelimited: 1 callbacks suppressed
Jul 29 15:08:11 raspberrypi kernel: [ 4905.634231] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:12 raspberrypi kernel: [ 4906.647350] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.532081] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.655564] Bluetooth: hci0 advertising data length corrected

Die Ursache des Problems ist noch nicht ergründet, allerdings betrifft dies aktuell nur den RPi3. Die Fehlermeldungen werden in verschiedene Logs geschrieben. Darunter maßgeblich "syslog" und "kern.log".

Lösung (vorübergehend):
Unterbinden der Einträge durch Anlage eines blocklist Eintrag:

1. Unter "/etc/rsyslog.d" eine Datei erzeugen mit dem Namen "01-blocklist.conf"
2. Inhalt: (Die Ausdrücke in den "" sind diejenigen, die aus dem log verschwinden sollen. - bei mir waren es die untenstehenden")
:msg,contains,"Bluetooth: hci0 advertising data length corrected" stop
:msg,contains,"bt_err_ratelimited:" stop
3. Dienst neu starten "sudo service rsyslog restart"

Weiter Infos werden im offiziellen Thema {{Link2Forum|Topic=28753|Message=499184|LinkText=hier}} diskutiert.

Seit Version 0.82 kann es beim Start zu folgenden Meldungen im Log kommen.
Sep 06 16:13:45 raspberrypi systemd[1]: Started lepresenced.
Sep 06 16:13:45 raspberrypi lepresenced[16010]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', ...tting...
Sep 06 16:13:46 raspberrypi lepresenced[16010]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...

Diese Meldungen können ignoriert werden. Abhilfe schafft sich lepresenced selbst, indem es sich resettet.

'''Moderne iPhones und Android Geräte wechseln in den Schlaf-Modus''', um Energie zu sparen. Somit sind die Geräte zur Anwesenheitserkennung nicht per Ping zu erreichen.
Durch das Programm hping3, lassen sich zyklisch Pakete an die Geräte senden, um sie wieder "aufzuwecken".

Mehr im Forum [https://forum.fhem.de/index.php/topic,76342.0.html]

= Versionsänderungen lepresenced =
<pre>
--Version 0.81 (BasisVersion)
--Version 0.82 (stable 08/2017)
-Neue Kommandozeilenoption "--debug": Startet lepresenced im Vordergrund und gibt ausführliche Debug-Informationen auf STDOUT aus.
-Sanity Check: lepresenced prüft beim Starten die Verfügbarkeit von hciconfig, hcitool und hcidump.
-Model: lepresenced übermittelt das Reading model nun als lan-lepresenced. Das erlaubt die Erkennung von lepresenced in der FHEM-Statistik (sofern aktiviert).
--Version 0.83 (stable 09/2017)
- Behebung von Systemstart Fehlern
- Weitere Debug-Möglichkeiten. U. a. wird nun mitgezählt, ob hcitool lescan ("legacy") und hcidump eine identische Zahl an Beacons empfangen
</pre>

= Ansprechpartner =
# {{Link2FU|117|markusbloch }} (Markus) für das PRESENCE-Modul und collectord
# {{Link2FU|5068|PatrikR}} (Patrick) für lepresenced
# [[Benutzer Diskussion:Devender|Devender]] ({{Link2FU|20043|Dirk}}) für Wiki und Doku

Homebridge User Configs

2018-11-04T15:34:47Z

Der-PW: Homebridgemapping um das Anlegen eines wichtigen userReadings ergänzt.

Dieser Eintrag dient zur Sammlung funktionsfähiger Homebridge Configs.

Bitte immer die FHEM Version und Homebridge Version angegeben.

Sehr gute Hinweise gibt es hier: http://www.meintechblog.de/2015/10/mit-siri-und-fhem-das-gesamte-smart-home-per-stimme-steuern/
== Mögliche Mappings ==
Die Möglichen Mappings können hier nachgelesen werden https://github.com/KhaosT/HAP-NodeJS/blob/master/lib/gen/HomeKitTypes.js

Hier ein Beispiel:
Characteristic.Brightness = function() {
Characteristic.call(this, 'Brightness', '00000008-0000-1000-8000-0026BB765291');
this.setProps({
format: Characteristic.Formats.INT,
unit: Characteristic.Units.PERCENTAGE,
maxValue: 100,
minValue: 0,
minStep: 1,
perms: [Characteristic.Perms.READ, Characteristic.Perms.WRITE, Characteristic.Perms.NOTIFY]
});
this.value = this.getDefaultValue();
};

Das Mapping in diesem Fall, hat den Titel Brightness.

Die Werte können in 1er Schritten zwischen 0 und 100 liegen (max und min Value)
== Feuchtesensor ==
Zum Einstieg etwas leicht nachvollziehbares.

Feuchtesensoren haben in der Regel ein "humidity" Reading, im Falle des Opus XT300 Bodenfeuchtesensors auch Temperatur und Batterie Level. Homekit unterstützt einen "HumiditySensor" Service. Dieser ist in homebridge-fhem nicht standardmäßig vorhanden (kann also nicht aus dem dropdown ausgewählt werden, sondern muss über das Befehlsfeld zugewiesen werden):

<code>attr meinSensor genericDeviceType HumiditySensor</code>

Im nächsten Schritt werden die Readings gemappt:

<code>attr meinSensor homebridgeMapping clear CurrentRelativeHumidity=humidity StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;;/^.*/:BATTERY_LEVEL_LOW CurrentTemperature=temperature</code>

<code>clear</code>löscht default mappings - das wird in der Regel nicht notwendig sein, schadet aber nicht

<code>CurrentRelativeHumidity</code> ist die relevante Homekit Characteristic - wird mit dem entsprechenden Reading des Sensors gemappt.

<code>StatusLowBattery</code> erwartet entweder BATTERY_LEVEL_NORMAL oder _LOW. Mein Sensor liefert ok zurück, wenn alles gut ist, also wird "ok" auf _NORMAL gemappt, alles andere auf _LOW.

Der Opus XT300 Bodenfeuchtesensors liefert auch noch die Temperatur - der HumiditySensor Service sieht das eigentlich nicht vor, daher wird die Temperatur auch nicht in der Apple "Home" App angezeigt. Bei Eve wird die Temperatur hingegen berücksichtigt.

== EnOcean STM 250 Tür-/Fensterkontakt ==
Der STM 250 liefert als Status in FHEM <code>open</code>, wenn das Fenster offen und damit der Kontakt "offen" ist. Analog liefert er <code>closed</code> wenn das Fenster geschlossen und damit auch der Kontakt geschlossen ist. Diese Statusangaben sind sehr intuitiv zu verstehen und zu interpretieren.

Die characteristic <code>ContactSensorState</code> von HomeKit liefert entweder den Wert <code>CONTACT_DETECTED=0</code> oder <code>CONTACT_NOT_DETECTED=1</code> zurück. Wobei <code>CONTACT_DETECTED</code> bedeutet, dass der Kontakt geschlossen ist. Je nach Darstellung in der HomeKit-fähigen App muss dieses Verhalten bei der Interpretation berücksichtigt werden. Die App Eve von Elgato zum Beispiel liefert für Kontaktsensoren "JA" oder "NEIN" mit der Bedeutung <code>CONTACT_DETECTED=0=JA</code> bzw. <code>CONTACT_NOT_DETECTED=1=NEIN</code> zurück.

Noch ein wichtiger Punkt: Um einen Sensorkontakt sinnvoll einzurichten sollte als zusätzlicher Wert für das Attribut <code>genericdeviceType</code> der Wert <code>ContactSensor</code> hinzugefügt werden. Wie das geht ist im Eintrag [[Homebridge_einrichten#FHEM_konfigurieren | Homebridge einrichten]] ausführlicher beschrieben.

Folgende Attribute dann hinzufügen:
attr STM250 genericDeviceType ContactSensor
attr STM250 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED

Getestet mit
FHEM 5.7 Rev. 9893
Homebridge 0.2.16
homebridge-fhem Vorschauversion aus {{Link2Forum|Topic=48558|Message=402024|LinkText=homebridge/homekit}}

== Modul RESIDENTS für Anwesenheitserkennung und Steuerung der Anwesenheit benutzen ==
[[Datei:Homebridge_bewohner_zu_szene.jpeg|mini|Schaltzustand eines Bewohners zu einer Szene hinzufügen]]
Aus den einzelnen Komponenten des Moduls RESIDENTS, homebridge sowie der characteristic <code>On</code> und der Szenensteuerung lässt sich eine gleichzeitige Steuerung der Anwesenheit und Anwesenheitserkennung basteln.

Dazu müssen folgende Schritte unternommen werden:
* einem Bewohner aus dem Modul ROOMMATE die Steuerung über homebridgeMapping hinzufügen
* Szene für "Ich bin zu Hause" und "Ich gehe jetzt" in einer HomeKit-fähigen App wie z.B. Eve einrichten

Man kann einen beliebigen Bewohner aus dem Modul ROOMMATE nehmen und ihn über die characteristic <code>On</code> in Form eines Schalters sozusagen schaltbar machen. Nur wird das Ein- und Ausschalten des Bewohners über HomeKit in FHEM auf den Status home bzw. absent gemappt. Seit dem 06.02.2016 werden RESIDENTS automatisch als Occupancy Sensor für HomeKit annonciert. Nun noch die Attribute des ROOMMATE wie folgt setzen:
attr <ROOMMATE> genericDeviceType switch
attr <ROOMMATE> homebridgeMapping On=state,valueOn=/home|awoken|asleep|gotosleep/,valueOff=/gone|absent/,cmdOn=home,cmdOff=absent

Natürlich muss der Bewohner noch dem Filter von homebridge hinzugefügt und homebridge neu gestartet werden.

Anschließend geht es in der HomeKit-fähigen App Deiner Wahl weiter. In Eve von Elgato ist von vornherein zum Beispiel vorgesehen, dass man zwei Szenen "Ich bin zuhause" und "Ich verlasse das Haus" hat. Zu diesen Szenen wird eine Aktion hinzugefügt indem der Bewohner, den das ROOMMATE-Modul meldet zur Szene hinzugefügt wird und beim Nachhausekommen "eingeschaltet" wird. Genauso wird mit der Szene "Ich verlasse das Haus" verfahren: Bewohner zur Szene hinzufügen und den Schaltvorgang auf "ausschalten" setzen.

Mit den Sprachbefehlen "Ich bin zuhause" oder "Ich verlasse das Haus" wird die entsprechende Szene eingeschaltet, homebridge schaltet über das <code>homebridgeMapping</code> Attribut dann den Bewohner auf "home" oder "absent".

Getestet mit
FHEM 5.7 Rev. 9893
Homebridge 0.2.16
homebridge-fhem Vorschauversion aus {{Link2Forum|Topic=48558|Message=402024|LinkText=homebridge/homekit}}

Eine noch etwas bessere Schaltmöglichkeit bietet '''genericDeviceType security'''.
Das Mapping für ROOMMATE sieht wie folgt aus:
attr TYPE=ROOMMATE genericDeviceType security
attr TYPE=ROOMMATE homebridgeMapping SecuritySystemCurrentState=state,values=/home|awoken/:0;;absent:1;;/asleep|gotosleep/:2;;gone:3 SecuritySystemTargetState=SecuritySystemCurrentState,cmds=0:state+home;;1:state+absent;;2:state+gotosleep;;3:state+gone,delay=1
für GUEST:
attr TYPE=GUEST genericDeviceType security
attr TYPE=GUEST homebridgeMapping SecuritySystemCurrentState=state,values=/home|awoken/:0;;absent:1;;/asleep|gotosleep/:2;;none:3 SecuritySystemTargetState=SecuritySystemCurrentState,cmds=0:state+home;;1:state+absent;;2:state+gotosleep;;3:state+none,delay=1

== ZWave Türschloss Vision ZM1701 einbinden ==
Das ZWave Türschloss ZM1701 von der Firma Vision sendet seinen aktuellen Schließstatus in ein einzelnes Reading wie "lock", sondern schickt eine ganze Reihe von Informationen über den Zustand in das Reading <code>doorLockOperation</code>. Das Schließen und Öffnen der Türschlosses wird auch nicht mit einem Setzen des <code>state</code> erreicht, sondern mit dem Setzen von <code>doorLockOperation</code>. Das macht das Einbinden in homebridge nicht trivial, funktioniert aber über folgendes Homebridge-Mapping:
attr <ZM1701> genericDeviceType lock
attr <ZM1701> homebridgeMapping LockCurrentState=doorLockOperation,values=/\ssecured/:SECURED;/unsecured/:UNSECURED LockTargetState=doorLockOperation,values=/\ssecured/:SECURED;/unsecured/:UNSECURED,cmds=SECURED:doorLockOperation+close;UNSECURED:doorLockOperation+open

Kurz zur Erklärung: Um ein Schloss über HomeKit steuern zu können braucht es zwei characteristics. LockCurrentState zeigt an, ob das Schloss geöffnet oder geschlossen ist. Und mit LockTargetState wird das Schloss geöffnet oder geschlossen. Damit der aktuelle Status des Schlosses ausgelesen werden kann, muss aus dem FHEM-Reading <code>doorLockOperation</code> die Zeichenfolge <code> secured</code> oder <code>unsecured</code> extrahiert werden, daher die beiden regulären Ausdrücke <code>/\ssecured/</code> und <code>/unsecured/</code>. In der characteristic <code>LockTargetState</code> muss sowohl der aktuelle Status des Schlosses als auch das Kommando angegeben werden, schließlich möchte man ein geschlossenes Schloss nicht nochmal schließen. Daher wird erst aus dem Reading <code>doorLockOperation</code> der aktuelle Status des Schlosses ausgelesen und die damit korrespondierenden Befehle über <code>cmds=SECURED:doorLockOperation+close;UNSECURED:doorLockOperation+open</code> generiert.

Wer es in FHEM über ein webCmd einfacher zu bedienen haben möchte, fügt bitte noch die dafür notwendigen Attribute und die leicht geänderten homebridgeMappings wie folgt ein:
attr <ZM1701> genericDeviceType lock
attr <ZM1701> homebridgeMapping LockCurrentState=doorLockOperation,values=/\ssecured/:SECURED;/unsecured/:UNSECURED LockTargetState=doorLockOperation,values=/\ssecured/:SECURED;/unsecured/:UNSECURED,cmds=SECURED:close;UNSECURED:open
attr <ZM1701> /doorLockOperation open:open/doorLockOperation close:close
attr <ZM1701> webCmd open:close

Getestet mit
FHEM 5.7 Rev. 12191
homebridge 0.4.6
homebridge-fhem 0.2.48

== Roomba über THINKINGCLEANER Modul ==
attr <THINKINGCLEANER> genericDeviceType switch
attr <THINKINGCLEANER> homebridgeMapping clear On=state,valueOn=/^(on|dock)/,cmdOn=on,cmdOff=off,nocache=1 ChargingState=deviceStatus,values=/(_recon|_full|_trickle)$/:CHARGING;/^.*/:NOT_CHARGING
attr <THINKINGCLEANER> siriName Robby

Getestet mit
FHEM 5.7 Rev. 12680
homebridge 0.4.11
homebridge-fhem 0.2.66

== Homematic HM-CC-RT-DN Funk-Heizkörperthermostat ==
[[Datei:HM-CC-RT-DN-Eve.PNG|mini|Darstellung des HM-CC-RT-DN in der iOS App Eve]]
attr <HMCCRTDN_Channel2_Clima> homebridgeMapping TargetTemperature=desired-temp::desired-temp,minValue=5,maxValue=35,minStep=0.5,nocache=1
CurrentTemperature=BU_Heizung_01_Clima:measured-temp,nocache=1
StatusLowBattery=BU_Heizung_01:battery,values=ok:BATTERY_LEVEL_NORMAL;;/^.*/:BATTERY_LEVEL_LOW
TargetHeatingCoolingState=heatingState,values=OFF:0;;HEAT:1;;COOL:2;;AUTO:3,cmds=OFF:controlManu+off;;HEAT:controlMode+boost;;AUTO:controlMode+auto;;COOL:controlManu+17.0
CurrentHeatingCoolingState=heatingState,values=OFF:0;;HEAT:1;;COOL:2;;AUTO:0,valud=OFF
attr <HMCCRTDN_Channel2_Clima> siriName Robby
Dieses Mapping bezieht sich auf ein vorhandenes ''userReading'' mit dem Namen <code>heatingState</code>, womit Homekit die einzelnen Status nachher unterscheidet.
attr <HM-CC-RT-DN_Clima> userReadings heatingState {(ReadingsVal($NAME,"ValvePosition",0) > 0 || ReadingsVal($NAME,"desired-temp","-") eq "on") ? "HEAT" : ReadingsVal($NAME,"desired-temp","-") eq "off" ? "OFF" : ReadingsVal($NAME,"controlMode","auto") eq "auto" ? "AUTO" : (ReadingsVal($NAME,"measured-temp",20) > ReadingsVal($NAME,"desired-temp",20)) ? "COOL" : "AUTO"}
Global auf alle in FHEM angelegten HM-CC-RT-DN, lässt sich mit folgendem Befehl das ''userReading'' anlegen.
Siehe [https://forum.fhem.de/index.php/topic,59211.msg505986.html#msg505986 Forumsthread].

attr TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=chanNo=04 userReadings heatingState {(ReadingsVal($NAME,"ValvePosition",0) > 0 || ReadingsVal($NAME,"desired-temp","-") eq "on") ? "HEAT" : ReadingsVal($NAME,"desired-temp","-") eq "off" ? "OFF" : ReadingsVal($NAME,"controlMode","auto") eq "auto" ? "AUTO" : (ReadingsVal($NAME,"measured-temp",20) > ReadingsVal($NAME,"desired-temp",20)) ? "COOL" : "AUTO"}

== Xiaomi Vacuum Cleaner 1. Generation ==
[[Datei:XIAOMI_VACUUM_CLEANER-Gen1.jpg|mini|XIAOMI VACUUM 1. GEN in EVE]]
Voraussetzung zur Verwendung der Mappings, ist ein Eingebundener Staubsauger mit dem Modul 72_XiaomiDevice.

Siehe [https://forum.fhem.de/index.php/topic,73052.0.html Forumsthread]
Das Modul muss manuell installiert werden.

Getestet wurden die Mappings nur mit 1. Generation des Xiaomi Vacuum Staubsauger.
Ob genau die gleiche Mappings auch bei der 2. Generation funktioniert kann ich leider nicht testen, mangels 2. Generation von Staubsaugern.

attr <XIAOMI> genericDeviceType switch
attr <XIAOMI> homebridgeMapping On=state,valueOn=Cleaning,cmdOn=start,cmdOff=charge
RotationSpeed=fan_power,minValue=0,maxValue=90,cmd=fan_power,delay=1
BatteryLevel=batteryLevel,maxValue=100,minValue=0,minStep=1
StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;;low:BATTERY_LEVEL_LOW
ChargingState=state,values=Docked:NOT_CHARGING;;Charging:CHARGING;;/.*/:NOT_CHARGEABLE
OccupancyDetected=state,values=/Docked|Charging/:OCCUPANCY_DETECTED;;/.*/:OCCUPANCY_NOT_DETECTED
FilterLifeLevel=consumables_filter,minValue=0,maxValue=100
FilterChangeIndication=consumables_filter,values=0:CHANGE_FILTER

== Homematic SmokeDetector ==
[[Datei:Homebridge-Homematic-Smokedetector-Gen1.jpg|mini|Homebridge-Homematic-Smokedetector-Gen1 in EVE]]
Es sind keine Homebridge Mappings für die Rauch Meldung erforderlich.

Allerdings ist ein Mapping für den Batterie Zustand nötig, dieses wird zu einen späteren Zeitpunkt nachgereicht.

attr <XIAOMI> genericDeviceType SmokeSensor
attr <XIAOMI> subType smokeDetector

[[Kategorie:HOWTOS]]
[[Kategorie:Code Snippets]]