FHEMWiki - Benutzerbeiträge [de]

ZigBee

2018-12-20T14:37:58Z

Connaisseur: /* Firmware updates */ Rächschreibfühler korrigiert.

== Allgemeines ==
[[ZigBee]] ist eine Spezifikation für drahtlose Netzwerke mit geringem Datenaufkommen, wie beispielsweise Hausautomation, Sensornetzwerke, Lichttechnik. Der Schwerpunkt von ZigBee liegt in kurzreichweitigen Netzwerken (bis 100 Meter). Es sind via vermaschtem Netz aber auch Reichweiten von mehreren Kilometern möglich.

Die Spezifikation ist eine Entwicklung der ZigBee-Allianz, die Ende 2002 gegründet wurde. Sie ist ein Zusammenschluss von derzeit mehr als 230 Unternehmen, welche die weltweite Entwicklung dieser Technologie vorantreiben.

== Gerätetypen ==
=== Endgerät (ZigBee End Device, ZED) ===
Geräte, wie zum Beispiel Steuerungs- oder Sensormodule, werden meist mit Batterien betrieben. Diese können als ZigBee-Endgeräte implementiert werden und benötigen nur einen Teil der Funktionen der ZigBee-Spezifikation. Sie nehmen nicht am Routing im Netzwerk teil und können in einen Schlafmodus gehen. Sie melden sich an einem Router ihrer Wahl an und treten so dem ZigBee-Netzwerk bei. Sie können ausschließlich mit dem Router kommunizieren, über den sie dem Netzwerk beigetreten sind. Werden Daten an ein solches Endgerät geschickt und dieses befindet sich im Schlafmodus, speichert der Router diese Pakete, bis das Endgerät sie abruft.

=== Router (ZigBee-Router, ZR) ===
ZigBee-Router nehmen am Routing der Pakete durch das Netzwerk teil. Sie benötigen einen größeren Funktionsumfang und damit auch etwas mehr Hardwareressourcen. ZigBee-Router treten einem Netzwerk bei, indem sie sich an einem im Netzwerk befindlichen Router anmelden. Das Routing im Netzwerk erfolgt entweder entlang eines sich so bildenden Baumes (Stackprofil ZigBee) oder durch dynamisches Routing als Meshnetzwerk.

'''Ein ZigBee Router hat so ungefähr die Funktion wie ein WLAN Repeater...'''

=== Koordinator (ZigBee coordinator, ZC) ===
Ein ZigBee-Koordinator startet das Netzwerk mit festgelegten Parametern. Nach dem Start übernimmt er dieselben Aufgaben wie ein ZigBee-Router.
Es kann nur einen Koordinator in einem ZigBee Netz geben.
'''In FHEM wird ein solches Gerät Gateway genannt.'''

== Mischen von Komponenten unterschiedlicher Hersteller ==
Prinzipiell ist es möglich, die Komponenten unterschiedlicher Hersteller zu mischen. Dies kann interessant sein, da jeder Hersteller andere Schwerpunkte in der Modellpalette hat, nicht jeder Hersteller alle Leuchtmittel-Typen vertreibt und sich auch die Eigenschaften und Preise für vergleichbare Leuchtmittel unterscheiden. Auch der in FHEM verfügbare Funktionsumfang unterscheidet sich je nach Bridge.

Leuchtmittel sind in der Regel am unproblematischsten. Taster auch wenn sie direkt die Leuchtmittel steuern. Über die Bridge sind in der Regel aber oft nur die Taster des jeweiligen Herstellers direkt abfragbar bzw. in FHEM einzubinden. Dies gilt auch für Bewegungsmelder und sonstige sensoren.

Im einzelnen sollte man sich also vor dem Kauf informieren welche Komponenten tatsächlich problemlos zusammen arbeiten.

Beim vergleich der Kosten muss aber die jeweilige Bridge des Herstellers zusätzlich mit berücksichtigt werden (siehe [[#Firmware updates]]).

=== Firmware updates ===
Es ist sinnvoll oder sogar zwingend nötig, neue Leuchtmittel zumindest einmal bei der Inbetriebnahme auf den aktuellen Firmwarestand zu bringen. Gerade wenn Komponenten herstellerübergreifend verwendet werden sollen, ist sonst oft mit Einschränkungen oder sogar Problemen zu rechnen.

Hierzu ist aktuell in der Regel<ref>Der Diskussionsstand 11/2018 hierzu ist diesem {{Link2Forum|Topic=93836|LinkText=Forenthread}} zu entnehmen.</ref> die zugehörige original Bridge (und oft auch die App) des jeweiligen Herstellers nötig, d.h., auch wenn man z.B. Osram LIGHTIFY oder IKEA Trådfri Leuchtmittel an einer Hue Bridge betreiben möchte, braucht man zumindest am Anfang einmal auch noch die Osram und IKEA Bridge und muss das Leuchtmittel jeweils an- und ab- und wieder anlernen.

Aktualisierungen der Hue Bridge und Hue Leuchtmittel lassen sich auch aus FHEM heraus anstoßen.

== Einbindung in FHEM ==
Prinzipiell lässt sich hier vorwegschicken, dass die FHEM Hue-Module (ob mit einer Phillips Hue Bridge oder mit der Dresden Elektronik Software) den größten Funktionsumfang ermöglicht.

=== Hersteller-Bridges ===
Wir benötigen also zur Einbindung ein Gateway. Manche Nutzer haben sich gleich ein Starterkit wie Philips Hue oder IKEA Trådfri gekauft.
Diese Lösungen haben den Vorteil, dass Alexa-Integration etc. sowie die Smartphone-App gleich mitkommen, und das Einbinden der Endgeräte, aber vor allem aber Softwareupdates i.d.R. herstellerproprietär gelöst wurden.

Der Nachteil ist, dass die Lösungen, bis hin zum gut dokumentierten Hue-System mit API, in anderer Hinsicht geschlossene Systeme sind. So ist z.B. über die Hue-Bridge die Abfrage von Hue Bewegungssensoren oder Tastern nur per Polling durch FHEM möglich - es gibt keinen Event-Mechanismus, der FHEM notifizieren könnte (siehe [[#Freie Lösungen]]). Alle 5 Minuten die Bridge fragen (= Pollen), ob der Bewegungsmelder jemanden gesehen hat und ggf. das Licht ausschalten, ist also per Polling machbar, auf einen ZigBee-Tasterdruck oder Bewegung hin via FHEM die Wifi-Steckdose schalten hingegen eher zu verzögert.

Außerdem ist unser Ziel ja, die Steckerleiste der Steuergeräte kurz zu halten.

Auch die native HomeKit- (Siri) oder Alexa-Integration ist mit kleinen oder größeren Problemen und Einschränkungen behaftet, diese sind unter anderem:
* nur Steuerung der herstellereigenen Leuchtmittel
* Verzögerung der Statusaktualisierung in FHEM, wenn an FHEM vorbei geschaltet wird
* Eventuell 'Cloud-Zwang' des jeweiligen Herstellers
* Eventuell erhöhter Ressourcenverbrauch auf der jeweiligen Bridge durch zusätzliche Verbindungen
Diese Nachteile gibt es bei einer Integration über FHEM nicht.

==== Hue Bridge von Philips ====
Siehe [[Hue]]. Eine gute Dokumentation kompatibler Geräte findet sich [https://iconnecthue.com/supported-devices/ hier]. Hue ist wohl die meist verbreitete Bridge und hat auch ein dokumentiertes Rest-API. Jedoch ist die Anzahl der Endgeräte (offiziell: 50) und Regeln (ca. 200) stärker als bei anderen Lösungen begrenzt und Events können nicht zu FHEM weitergeleitet werden.

==== Trådfri von IKEA ====
Siehe {{Link2Forum|Topic=70653}}.

==== Lightify von Osram ====
Siehe {{Link2Forum|Topic=28339}}. Auch hier geht nur Polling von Events, ebenfalls max. 50 Geräte, und der Nutzerkreis ist kleiner.

=== Andere Lösungen ===
Die Alternative sind Lösungen, die spezielle Hardware erfordern, wie den RaspBee (Aufsteckmodul für Raspberry) oder Conbee (USB-Gateway) von Dresden Elektronik oder manche Module mit Chips des Herstellers [https://github.com/Koenkk/zigbee2mqtt/wiki/Supported-sniffer-devices Texas Instruments], und die zusätzlich nötige Software auf dem Raspberry etc. mitlaufen lassen. Eine reine Hardware-Lösung ohne Zusatzsoftware, in der FHEM die Software-Funktionen des Gateway vollständig abbildet, gibt es nicht - FHEM kommuniziert lediglich mit einer Software, die ebenfalls auf dem - ggf. gleichen - Computer mitläuft.

==== Dresden Elektronik ====
Das Dresden Elektronik System ermöglicht aktuell als einziges der 'fertigen' Systeme auch das aktive Senden von Events und somit eine 'fast Echtzeit' Reaktion auf Taster, Bewegungsmelder oder Ähnliches. Realisiert ist das über eine Push Erweiterung im ansonsten weitgehend Hue kompatiblen API. Auch die Integration von Tastern und anderen Sensoren unterschiedlichster Hersteller ist mit der DE Software gut möglich. Die Anbindung an FHEM (inklusive Push) erfolgt über die HUE-Module.

==== Direkt per MQTT ====
Siehe [[MQTT2-Module - Praxisbeispiele#zigbee2mqtt]]

==== Das Modul von Neumann ====
Siehe diesen Forenbeitrag: {{Link2Forum|Topic=84790}}

== Funkübertragung ==

=== Reichweite erhöhen ===
* Eine brauchbare WLAN Antenne (2,4GHz) an einen CC2531 "Stick" oder ein anderes Gateway anbauen (eher für Experten)
* ein CC2530 als Gateway oder in der Mitte als Repeater (Achtung verschiedene Firmwares erforderlich. Gute Antenne muss meist gesondert gekauft werden, anstatt der beigelegten)
* ZigBee ist ein Mesh-Netz, daher irgendwo auf dem Weg ein ZigBee-Gerät verbauen, welches immer eingeschaltet ist (z.B. ZigBee Funksteckdose)

== Sicherheit ==
=== Sicherheitsrelevante Geräte ===
Welche Geräte sicherheitsrelevant sind, ist eine sehr schwierige Frage. Beim Türschloss ist das klar. Wenn ein Temperatursensor dafür sorgt, dass ein Raum nicht mehr beheizt wird, und daraufhin wegen geplatzem Heizkörper die Wohnung geflutet wird, so ist dies schon etwas schwerer zu erkennen...

=== Bekannte Sicherheitslücken ===
==== Insecure Rejoin ====
Insecure Rejoin ist eine der Schwachstellen im Protokoll. ZigBee 3.0 wurde 2015 freigegeben und soll das Problem lösen. Allerdings ist ZigBee 3.0 (Stand Ende 2018) noch immer recht wenig verbreitet.

Ablauf des Insecure Rejoin aus Angreifersicht:
* einen Node aus dem Netz werfen, um nicht auf die Aktivierung neuer Geräte warten zu müssen
* der Node versucht erneut Mitglied im Netz zu werden. Schlüsselaustausch erfolgt mittels dem Key "ZigBeeAlliance09"
* Mitsniffen des neuen Schlüssels

Quelle: Link zu Golem.de über die Forschung von Tobias Zillner

==== DDOS ====
* manipulierte Counter (können sogar manche HW zerstören)
* Jamming (einfach die Frequenz belegen mit beliebigem Signal)
* Flutung mit ZigBee Messages

Quelle: https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3/

== Links ==
* https://www.golem.de/news/smart-home-sicherheitsluecken-im-zigbee-protokoll-demonstriert-1511-117657-2.html

[[Kategorie:ZigBee|!]]

HM-Sec-SCo Tür-Fensterkontakt, optisch

2018-11-22T12:51:57Z

Connaisseur: /* Anzeige des Zeitpunkts der letzten Öffnung im STATE */ - Tippfehler repariert.

{{Infobox Hardware
|Bild=HM-SEC-SCo.jpg
|Bildbeschreibung=HomeMatic Tür-Fensterkontakt, optisch
|HWProtocol=HomeMatic
|HWType=Sensor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=1
|HWVoltage=1,5 V DC
|HWPowerConsumption=max. 100 mA
|HWPoweredBy=Batterie (1x 1,5V LR03/Micro/AAA)
|HWSize=15x100x18mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

== Features ==
[[HomeMatic]] Funk-Tür-/Fensterkontakt zur optischen Erkennung von Tür- bzw. Fensteröffnungen oder -schließungen, z.B. zur Sicherheit oder um automatisch, bei vorhandenem [[HM-CC-RT-DN]], die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird.

== HM-SEC-SC und HM-SEC-SCo ==
Das meiste zum [[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] Beschriebene zur Nutzung gilt auch für den HM-Sec-SCo.

Wird mit aktiviertem [[AES Encryption|AES]] ausgeliefert und kann nur mit Gateways, die AES unterstützen, gepaired werden ([[HM-CFG-USB USB Konfigurations-Adapter|HM-LAN-CFG]], [[HM-CFG-LAN LAN Konfigurations-Adapter|HM-USB-CFG]] und [[CUL]] (seit Juli 2015)).

Mindestens bei Benutzung mit einem CUL (vermutlich auch via HM-CFG-USB und HM-CFG-LAN) muss FHEM auf das Perl-Modul Crypt::Rijndael zugreifen können. Wenn es nicht zur Verfügung steht, bleibt das Pairing unvollständig. Siehe auch [[AES_Encryption#IO <-> Gerät|den Abschnitt über AES-Encryption zwischen IO-Device und Gerät]].

== Aufbau ==
Das Gerät ist sowohl nutzungsbereit (ca. € 30) als auch als Bausatz (ca. € 20) verfügbar, letzterer muss selbst gelötet werden. Die Arbeitszeit sollte für erfahrende Personen unter 15 Minuten liegen.
[[Datei:Ansicht1.jpg|200px|thumb|left|Bestückung beider Platinen]]
[[Datei:Ansicht2.png|200px|thumb|right|Bestückung beider Platinen aus anderer Perspektive]]
Es sind nur
* das Funkmodul mit einer 8-poligen Stiftleiste
* der Batteriekontakt (Minuspol) mit einem kurzen Drahtstück
[[Datei:HM-Sec-SCo_Basisplatine.jpg|mini|250px|Markiert: Antennendurchführung (1), Batterieanschluss (2), sehr schmaler Platinensteg (3)]]
an der Basisplatine anzulöten.

Zu beachten ist noch, dass die Antenne '''vor''' dem Auflöten des Funkmoduls durch das markierte Loch der Basisplatine geführt werden muss.

Die fertig montierte Platine muss sich leicht in das Gehäuse einsetzen lassen, anderenfalls wird der schmale Platinensteg u.U. zu stark belastet und kann brechen!

== Betrieb mit FHEM ==
=== Event-Monitor ===
Wird z. B. das Fenster geöffnet, wird Folgendes vom Gerät übermittelt:
<pre>
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 11
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG battery: ok
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG open
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG contact: open (to MyHMLAN)
</pre>

Beim Schließen wird Folgendes übermittelt:
<pre>
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 12
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG battery: ok
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG closed
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG contact: closed (to MyHMLAN)
</pre>

=== Konfiguration ===
Bei eingeschaltetem [[autocreate]] werden die erforderlichen Definitionen beim Pairen selbstständig erstellt.

<pre>
define HM_Fensterstatus_BadEG CUL_HM 35E390
attr HM_Fensterstatus_BadEG IODev MyHMLAN
attr HM_Fensterstatus_BadEG actCycle 000:50
attr HM_Fensterstatus_BadEG actStatus dead
attr HM_Fensterstatus_BadEG autoReadReg 4_reqStatus
attr HM_Fensterstatus_BadEG expert 2_full
attr HM_Fensterstatus_BadEG firmware 1.0
attr HM_Fensterstatus_BadEG model HM-SEC-SCo
attr HM_Fensterstatus_BadEG peerIDs 00000000,
attr HM_Fensterstatus_BadEG room CUL_HM
attr HM_Fensterstatus_BadEG serialNr LEQxxxxxxx
attr HM_Fensterstatus_BadEG subType threeStateSensor
</pre>

== Beispiele ==
=== Aktionen durchführen, wenn Fenster zu lange geöffnet ist ===
==== DOIF-Variante ====
Mit der nachfolgenden [[DOIF]]-Definition wird ein [[FileLog|Log]]-Eintrag erzeugt, eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und eine Nachricht per Prowl (funktioniert vermutlich nur unter Linux) verschickt.

Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann. Das DOIF ist vorab zu definieren, zum Beispiel mit:
:<code>def DOIF_FensterOffenMsg DOIF ([HM_Fensterstatus_BadEG])</code>
und kann dann anschließend in den Device-Details vervollständigt werden:
<syntaxhighlight lang="perl">
([HM_Fensterstatus_BadEG] eq "open") ({
Log 1, "Fenster seit mehr als 2 Stunden (7200 Sekunden) offen";;
system( "/path/to/prowl.pl -apikeyfile=/path/to/prowl-apikey -event=Info -notification='Fenster ist noch offen' &" );;
fhem( "set E2_Dreambox showText Fenster ist noch offen" ) if ReadingsVal("E2_Dreambox","state","") eq "on";;
})
DOELSE
</syntaxhighlight>

Damit der Code-Block erst nach 7200 Sekunden getriggert wird, ist noch Folgendes auszuführen:

:<code>attr DOIF_FensterOffenMsg wait 7200:0</code>
==== Watchdog-Variante ====
Alternativ zu der DOIF-Lösung gibt es auch eine einfache Lösung mit [[Watchdog]]. Dazu legt ihr einen Watchdog an:
:<code>define watchdogBadEG watchdog HM_Fenster_BadEG:open 00:15 HM_Fenster_BadEG:closed set myTelegram message Das Fenster ist seit 15 min offen!</code>
Der Watchdog besagt, dass er beim Status "open" des Gerätes/Devices "HM_Fenster_BadEG" (also dem Fenstersensor) aktiviert wird. Nach 15 Minuten schickt er eine Nachricht über [[Telegram]], es sei denn es kommt zwischenzeitlich der Statu "closed".

=== Anzeige des Zeitpunkts der letzten Öffnung im STATE ===
Das Reading ''contact'' beinhaltet die Zustände ''open'' und ''closed''. Und der Zeitstempel der Änderung wird regelmäßig aktualisiert. Aus diesem Grund fällt die Nutzung des Attributs ''showtime'' hier weg. Wenigstens, wenn man nicht den Zeitpunkt des letzten Auslesens wissen will, sondern den der letzten Öffnung.

Folgende Schreibweise ermöglicht es, dass im STATE-Internal der Zeitpunkt des letzten ''open'' verbleibt (zum Übernehmen als Einzeiler kopieren):
:<code><nowiki>attr Sensor stateFormat {if (ReadingsVal("Sensor","contact","") =~ "open.*") {"open " . ReadingsTimestamp("Sensor","contact","")} else {InternalVal("Sensor","STATE","")}}</nowiki></code>

Ein Thread zu diesem Thema findet sich im Forum unter dem Titel {{Link2Forum|Topic=41347|LinkText=HM-SEC-SCo: Letzte Türöffnung im State anzeigen}}.

== Bekannte Probleme ==
Bei (direkter) Sonneneinstrahlung kann es zu Fehlfunktionen kommen, die sich in schnell wechselnden Statusänderungen äußern.

Teilweise (siehe Diskussion im {{Link2Forum|Topic=33264|LinkText=Forum}}) werden die Fensterkontakte regelmäßig wiederkehrend als "dead" angezeigt. Grund ist, dass beim Anlernen ein actCycle von 50 Minuten eingetragen wird, während die Kontakte auch gerne mal länger brauchen, um sich bei der Zentrale zu melden.
<pre style="width:500px;">
2015-01-31_17:57:39 Fstr_AusgTerrasse alive: yes
2015-01-31_17:57:39 Fstr_AusgTerrasse battery: ok
2015-01-31_17:57:39 Fstr_AusgTerrasse sabotageError: off
2015-01-31_17:57:39 Fstr_AusgTerrasse closed
2015-01-31_17:57:39 Fstr_AusgTerrasse contact: closed (to HMLAN1)
2015-01-31_18:54:09 Fstr_AusgTerrasse Activity: dead
2015-01-31_18:58:03 Fstr_AusgTerrasse alive: yes
2015-01-31_18:58:03 Fstr_AusgTerrasse battery: ok
2015-01-31_18:58:03 Fstr_AusgTerrasse sabotageError: off
2015-01-31_18:58:03 Fstr_AusgTerrasse closed
2015-01-31_18:58:03 Fstr_AusgTerrasse contact: closed (to HMUSB)
2015-01-31_19:04:09 Fstr_AusgTerrasse Activity: alive
</pre>

Um Abhilfe zu schaffen, den actCycle auf 01:05 setzen:
:<code>attr <HM-SEC-SCo> actCycle 001:05</code>

Save config nicht vergessen.

== Links ==
* Anleitung [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SCo_UM_GE_eQ-3_web.pdf PDF]
* Datenblatt [http://www.eq-3.de/service/downloads.html?id=235&download=produkt&pid=1947 PDF] (der direkte Link auf das PDF klappt nicht, vermutlich wegen der Codierung des Umlautes :-( )
[[Kategorie:HomeMatic Components]]
[[Kategorie:Kontaktsensor (optisch)]]