Homebridge User Configs: Unterschied zwischen den Versionen
Zeile 177: | Zeile 177: | ||
Es sind keine Homebridge Mappings für die Rauch Meldung erforderlich. | Es sind keine Homebridge Mappings für die Rauch Meldung erforderlich. | ||
Allerdings ist ein Mapping für den Batterie Zustand nötig, | Allerdings ist ein Mapping für den Batterie Zustand nötig, siehe Unten. | ||
Version vom 15. November 2018, 13:59 Uhr
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):
attr meinSensor genericDeviceType HumiditySensor
Im nächsten Schritt werden die Readings gemappt:
attr meinSensor homebridgeMapping clear CurrentRelativeHumidity=humidity StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;;/^.*/:BATTERY_LEVEL_LOW CurrentTemperature=temperature
clear
löscht default mappings - das wird in der Regel nicht notwendig sein, schadet aber nicht
CurrentRelativeHumidity
ist die relevante Homekit Characteristic - wird mit dem entsprechenden Reading des Sensors gemappt.
StatusLowBattery
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 open
, wenn das Fenster offen und damit der Kontakt "offen" ist. Analog liefert er closed
wenn das Fenster geschlossen und damit auch der Kontakt geschlossen ist. Diese Statusangaben sind sehr intuitiv zu verstehen und zu interpretieren.
Die characteristic ContactSensorState
von HomeKit liefert entweder den Wert CONTACT_DETECTED=0
oder CONTACT_NOT_DETECTED=1
zurück. Wobei CONTACT_DETECTED
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 CONTACT_DETECTED=0=JA
bzw. CONTACT_NOT_DETECTED=1=NEIN
zurück.
Noch ein wichtiger Punkt: Um einen Sensorkontakt sinnvoll einzurichten sollte als zusätzlicher Wert für das Attribut genericdeviceType
der Wert ContactSensor
hinzugefügt werden. Wie das geht ist im Eintrag 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 homebridge/homekit
Modul RESIDENTS für Anwesenheitserkennung und Steuerung der Anwesenheit benutzen
Aus den einzelnen Komponenten des Moduls RESIDENTS, homebridge sowie der characteristic On
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 On
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 homebridgeMapping
Attribut dann den Bewohner auf "home" oder "absent".
Getestet mit
FHEM 5.7 Rev. 9893 Homebridge 0.2.16 homebridge-fhem Vorschauversion aus 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 doorLockOperation
. Das Schließen und Öffnen der Türschlosses wird auch nicht mit einem Setzen des state
erreicht, sondern mit dem Setzen von doorLockOperation
. 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 doorLockOperation
die Zeichenfolge secured
oder unsecured
extrahiert werden, daher die beiden regulären Ausdrücke /\ssecured/
und /unsecured/
. In der characteristic LockTargetState
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 doorLockOperation
der aktuelle Status des Schlosses ausgelesen und die damit korrespondierenden Befehle über cmds=SECURED:doorLockOperation+close;UNSECURED:doorLockOperation+open
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
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 heatingState
, 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 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
Voraussetzung zur Verwendung der Mappings, ist ein Eingebundener Staubsauger mit dem Modul 72_XiaomiDevice.
Siehe 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
Es sind keine Homebridge Mappings für die Rauch Meldung erforderlich.
Allerdings ist ein Mapping für den Batterie Zustand nötig, siehe Unten.
attr <XIAOMI> genericDeviceType SmokeSensor attr <XIAOMI> subType smokeDetector
attr <XIAOMI> homebridgeMapping StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;;/^.*/:BATTERY_LEVEL_LOW