MQTT2-Module - Praxisbeispiele

2019-09-17T14:54:09Z

Reibuehl: /* Shelly */ Beispiel für Leistungsabhängige Statusmeldung beim Shelly Plug S

== Einführung: MQTT bzw. MQTT2 in FHEM ==
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT verwenden, beachten Sie bitte, dass der MQTT2_CLIENT die ursprüngliche Herkunft der über MQTT verteilten Informationen nicht kennt. Daher ergeben sich in der Anwendung kleinere Unterschiede, zu deren Verständnis die diesbezüglichen [[MQTT2_CLIENT#Anwendung|Hinweise zu MQTT2_CLIENT]] bekannt sein sollten.}}Zur Einbindung von Geräten, welche zur Nutzung des MQTT-Protokols konfiguriert werden können und darüber mit einem MQTT-Server (früher: Broker) kommunizieren, stehen unter FHEM verschiedene Optionen zur Verfügung, wobei nicht alle Module beliebig miteinander verwendet werden können. Details hierzu sind dieser [[MQTT|Übersicht]] zu entnehmen.

Im Rahmen dieses Artikels wird für die eigentlichen Geräte [[MQTT2 DEVICE|MQTT2_DEVICE]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] oder benötigt, mit einem IO-Device des Typs [[MQTT (Modul)|MQTT]] funktioniert die nachfolgende Darstellung dagegen nicht<ref>Allerdings können die Konfigurationen in der Regel recht einfach auf die bisherige MQTT-Implementierung übertragen werden</ref>. MQTT2_DEVICE unterstützt u.a. auch die ''setExtensions'' direkt, also z.B. ''on-for-timer<ref>Beachten Sie bei mehrkanaligen Geräten, dass jeweils nur ein Hauptkanal mittels setExtensions verwaltet werden kann! U.a. aus diesen Grund ist es meist sinnvoller, die ''split''-Varianten der attrTemplate-Einrichtung zu verwenden.</ref>'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt setExtensions, allerdings muß dies dort per Attribut eingeschaltet werden</ref>.

=== Allgemeine Einstellungen und Hinweise ===
{{Randnotiz|RNTyp=r|RNText=Beachten Sie, dass für autocreate in Verbindung mit MQTT2_SERVER '''zwingend''' jeder über MQTT kommunizierende Client eine ClientID angeben muß. Passen Sie daher ggf. die Einstellungen Ihres Geräts an. Manche Geräte verwenden auch "Wegwerf"-ClientID's. Für diese empfiehlt es sich, ggf. dann die durch autocreate erstellten Geräte nachzubearbeiten und die ClientID-Angabe v.a. aus den Inhalten des readingList-Attributs zu entfernen.}}Die nachfolgenden Beispiele gelingen am einfachsten mit '''MQTT2_SERVER als Server ("Broker")''', für diesen sollte dabei ''autocreate'' nicht deaktiviert sein, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') ebenfalls aktiv ist.</ref> .

Beispiel<ref>MQTT2_SERVER verwendet als default-Einstellung für ''autocreate'' ''simple'', ohne dass ein entsprechendes Attribut gesetzt werden müßte. Die Einstellung ''complex'' empfiehlt sich in der Regel nicht; diese ist jedoch dann zu empfehlen, wenn das Device entweder verschachtelte JSON-Array-Strukturen liefert oder bestimmte Readings nicht gefüllt werden sollen.</ref>:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muß ggf. die "\" entfernen!}}

=== MQTT-Einstellungen in den Geräten ===
Die Beispiele gehen davon aus, dass die einzubindenden Geräte '''''mit den default-Einstellungen''''' für MQTT betrieben werden, wenn man von den Angaben zum Server und ggf. der Gerätekennung absieht. Es sollten also insbesondere '''keine Veränderungen der topic-Pfade''' vorgenommen werden.

== zigbee2mqtt ==
[[Bild:MQTT2_zigbee2mqtt_Bulbs.png|400px|thumb|Darstellung in FHEMWEB]]
[https://github.com/Koenkk/zigbee2mqtt zigbee2mqtt] ist ein open-source Projekt, mit dem zigbee-Geräte über MQTT direkt angesprochen werden können, ohne dass hierfür eine Bridge eines Herstellers benötigt wird.
=== Installation von zigbee2mqtt ===
Die Installation des zigbee2mqtt-Diensts ist auf der Homepage des Projekts beschrieben. Ergänzend muß in der configuration.yaml eine ''client_id'' unter ''mqtt'' (z.B. zigbee_pi) vergeben werden<ref>Die Anführungszeichen sowie genau zwei Leerzeichen sind hier erforderlich!</ref>.
mqtt:
client_id: 'zigbee_pi'
Da der Dienst auch später in den Anlernmodus versetzt werden kann, kann man auch gleich <code>permit_join: false</code> setzen, um das versehentliche Einbinden neuer oder fremder Geräte zu unterbinden.
{{Hinweis|Wird ein CC2531 auf demselben Linux-Computer verwendet, auf dem auch FHEM installiert ist, kann es vorkommen, dass FHEM diesen mit einem CUL verwechselt und durch ''initialUsbCheck'' in FHEM einbindet, wodurch er für den zigbee2mqtt-Dienst nicht mehr verfügbar ist. Dann sollte ''initialUsbCheck'' deaktiviert und das automatisch angelegte CUL-Device wieder gelöscht werden. Weiter sollte der CC2531 auch in FHEM '''und''' zigbee2mqtt ''[[Mehrere USB-Geräte einbinden|by-id]]'' eingebunden werden, um Probleme beim gleichzeitigen Einsatz anderer Geräte, die ''/dev/ttyACMx'' belegen können, zu vermeiden (betrifft z.B. CUL/MapleCUL ).}}

=== Define eines MQTT2-Devices als "Bridge" ===
Dann kann eine Art "Grund-Device" angelegt werden, das für die Ansteuerung des eigentlichen Server-Dienstes genutzt wird, der bereits unmittelbar nach der erfolgreichen Konfiguration von zigbee2mqtt zur Verfügung steht. In der Regel sollte dieses automatisch erstellt werden, wenn der zigbee2mqtt-Dienst (oder der betreffende Rechner) neu gestartet wird (oder FHEM oder dort ein Sensor einen Messwert sendet). Beispiel<ref>Hier waren bereits zwei Zigbee-Geräte angelernt</ref>:

defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_pi readingList zigbee_pi:zigbee2mqtt/bridge/state:.* state\
zigbee_pi:zigbee2mqtt/0x90fd9ffffe65db16:.* { json2nameValue($EVENT, '') }\
zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT, '') }\
zigbee_pi:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT, 'log_') }
attr MQTT2_zigbee_pi room MQTT2_DEVICE

Für die Funktion einer zigbee2mqtt-Bridge steht ein {{Link2CmdRef|Anker=set|Lang=en|Label=template}} bereit, das direkt die passenden Attribute vergibt, um dem zigbee2mqtt-Dienst passende Anweisungen geben zu können und weitere Geräte für die eigentlichen Aktoren und Sensoren anzulegen:

set MQTT2_zigbee_pi attrTemplate L_01_zigbee2mqtt_bridge

Ist dieses angelegt, kann zigbee2mqtt mit <code>set MQTT2_zigbee_pi permit_join true</code> in den Anlernmodus versetzt werden, anzulernende Geräte müssen anschließend jeweils nach Bedienungsanleitung in den Anlernmodus gebracht werden.

=== Vereinzeln der eigentlichen Geräte ===

Über das mit dem template vergebene bridgeRegexp-Attribut
attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
werden anschließend neue MQTT2_DEVICE-Geräte automatisch angelegt, sobald ein bisher unbekanntes Zigbee-Gerät einen neuen Status (z.B. einen Meßwert) meldet. Um zu erfragen, welche Geräte dem zigbee-Deinst bekannt sind, kann via <code>get MQTT2_zigbee_pi devicelist true</code> eine Liste abgefragt werden, die weitere Informationen zu den bereits angelernten Geräten enthält.
Geräte, die nicht automatisch etwas senden, kann man mit Hilfe des MQTT2_SERVER-Geräts einmalig schalten, damit diese ihren Status bzw. das erfolgreiche Schalten zurückmelden, Beispiel<ref>Die mit 0x... beginnende Angabe entspricht dabei dem ''friendly_name''.</ref>:
set MQTT2_FHEM_Server publish zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON","brightness":60}

Für Gerätetypen, für die bereits templates vorhanden sind, ist es am einfachsten, diese einmalig auf die Geräte anzuwenden. Das Vorgehen entspricht dabei dem oben für die Bridge beschriebenen. Dafür wird immer vorausgesetzt, dass ein neues Device mit autocreate (ggf. über die bridgeRegexp) angelegt wurde<ref>Dieses befindet sich dann im Raum MQTT2_DEVICE. Um diesen sichtbar zu machen, muß ggf. die Browser-Seite neu geladen werden.</ref>

Beispiele:
==== IKEA-Tradfri-Birne ====
{{Randnotiz|RNTyp=g|RNText=Wie wähle ich nun das richtige Template für mein Leuchtmittel aus?
-> Es wird nicht zwischen einer Birne/Bulb/Lampe und einem LED-Controller unterschieden sondern anhand der möglichen Lichtdarstellung des Gerätes:

light_dimmer:
Das anzusteuernde Geräte besitzt ausschließlich eine feste Lichtfarbe welche gedimmt werden kann.

light_cct:
Das anzusteuernde Gerät besitzt eine warmweiße sowie kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann.

light_rgb_xxx:
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und kann gedimmt werden.

light_rgbw_xxx:
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße ODER kaltweiße Lichtfarbe welche eingestellt sowie gedimmt werden kann.

light_rgbcct_xxx:
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße UND kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann.

xxx:
hex: Farbänderung mit hex
rgb: Farbänderung mit r g b
xy: Farbänderung mit x sowie y
hue: Farbänderung mit hue und saturation

Warum diese Einteilung in "hex", "rgb", "xy" sowie "hue"?
-> Zigbee2MQTT unterstützt das Übermitteln aller dieser Werte, allerdings unterscheiden sich hier die Geräte. Manche "verstehen" nur z.B. Hex-Farbänderungen, andere halt nur eine Farbänderung mit rgb-Werten.
-> Aus diesem Grund muss an dieser Stelle probiert werden mit welchem der 4 Templates sich die Farbveränderung des Gerätes steuern lässt!

HINWEIS: Templates für Farbänderungen mithilfe von XY- sowie HUE-Werten wurden bis heute nicht angelegt!
}}
Beispiel eines dimmbaren Tradfri-Leuchtmittels
defmod IKEA_Bulb2 MQTT2_DEVICE
attr IKEA_Bulb2 IODev MQTT2_FHEM_Server
attr IKEA_Bulb2 icon light_control
attr IKEA_Bulb2 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr IKEA_Bulb2 readingList zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT) }
attr IKEA_Bulb2 setList on:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON"}\
off:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"OFF"}\
brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"on","$EVTPART0":"$EVTPART1"}
attr IKEA_Bulb2 webCmd toggle:on:off:brightness
attr IKEA_Bulb2 model L_02a_zigbee2mqtt_bulb

Kann man auch die Farbtemperatur einstellen, wird die setList wie folgt erweitert oder das entsprechende template<ref>Durch die ''model''-Angabe kann nachvollzogen werden, welches template angewendet wurde.</ref> anwendet:
...
color_temp:colorpicker,CT,250,1,454 zigbee2mqtt/0x90fd9ffffe0bcd51/set {"$EVTPART0":"$EVTPART1"}

Die templates sind dabei in der Regel so gestaltet, dass eventuell mehr Optionen in FHEMWEB erscheinen, als tatsächlich vorhanden oder erwünscht sind.
Da sich obige einfarbige dimmbare Lampe durch Klicken auf das devStateIcon schalten läßt, ist für die vollständige Ansteuerung bereits dieses webCmd hinreichend:
attr IKEA_Bulb2 webCmd brightness

==== Temp/Hum. Sensor ====
tbd

==== Motion Sensor ====
Als MQTT-Server wird hier ''mosquitto'' verwendet, als IO-Device wird daher ein {{Link2CmdRef|Anker=MQTT2_CLIENT|Lang=en|Label=MQTT2_CLIENT}}-Gerät definiert:

defmod mqtt2_client MQTT2_CLIENT 192.168.2.4:1883
attr mqtt2_client autocreate 1
attr mqtt2_client rawEvents zigbee2mqtt/GB_Bewegungsmelder:.*
attr mqtt2_client room test
attr mqtt2_client subscriptions #

Das eigentliche Device sieht dann so aus:
defmod GB_Bewegungsmelder_MQTT2 MQTT2_DEVICE zigbee_158d0001f9d030
attr GB_Bewegungsmelder_MQTT2 IODev mqtt2_client
attr GB_Bewegungsmelder_MQTT2 devStateIcon motion:motion_detector@red off:motion_detector@green no_motion:motion_detector@green
attr GB_Bewegungsmelder_MQTT2 icon motion_detector@blue
attr GB_Bewegungsmelder_MQTT2 readingList mqtt2client:zigbee2mqtt/GB_Bewegungsmelder:.* { json2nameValue($EVENT) }
attr GB_Bewegungsmelder_MQTT2 room MQTT2_DEVICE
attr GB_Bewegungsmelder_MQTT2 stateFormat {\
if(ReadingsVal("$name","occupancy",0) eq "true") {\
sprintf("motion");;\
} else {\
sprintf("no_motion");; \
}\
}
==== Anlegen von Zigbee2MQTT-Gruppen in FHEM ====
{{Hinweis|Die nachfolgende Darstellung ist vorläufig!}}
{{Hinweis|Bevor man eine Gruppe mithilfe von Zigbee2MQTT anlegen kann, sollte man sicherstellen, dass man über die aktuelleste Version von Zigbee2MQTT verfügt (min. vom 15. Februar 2019). Außerdem sollte auch der Koordinator (zumeist CC2531) die aktuellste Firmware besitzen (min. vom 15. Februar 2019). Falls ein flashen des Koordinators mit der neusten Firmware erfolgen soll, ist darauf zu achten, dass nach einem flashen alle Geräte neu angelernt werden müssen! (Hinweise zum flashen ohne erneutem anlernen sind hier zu finden: https://www.zigbee2mqtt.io/information/flashing_without_re-pairing.html)}}

=====Erstellen einer Zigbee2MQTT-Gruppe=====
Bevor das Ganze in FHEM funktioniert, muss eine Gruppe in der "configuration.yaml" angelegt werden, dieser Vorgang ist auf folgender Seite beschrieben: https://www.zigbee2mqtt.io/information/groups.html
Wenn die Geräte anschließend über den FHEM MQTT2-Server der Gruppe hinzugefügen werden sollen, kann dies mit folgendem Befehl erfolgen:
set <MQTT2-Server> publish zigbee2mqtt/bridge/group/<Zigbee2MQTT Friendly-Gruppenname>/add <Zigbee2MQTT Friendly-Gerätename>

Beispiel:
set MQTT2_FHEM_Server publish zigbee2mqtt/bridge/group/Wohnzimmer/add Stehlampe

Dieser Befehl kann so oft verwendet werden, wie man Geräte zu einer Gruppe hinzufügen möchte.

Zum Entfernen eines Gerätes aus einer Gruppe kann folgender Befehl verwendet werden:
set <MQTT2-Server> publish zigbee2mqtt/bridge/group/<Zigbee2MQTT Friendly-Gruppenname>/remove <Zigbee2MQTT Friendly-Gerätename>
Beispiel:
set MQTT2_FHEM_Server publish zigbee2mqtt/bridge/group/Wohnzimmer/remove Kuechenlampe

=====Anlegen der Gruppe in FHEM=====
Da Gruppen in Zigbee2MQTT aktuell keine Rückmeldung über ihren Status geben, wird auch beim einmaligen Schalten kein Gerät automatisch in FHEM angelegt. Aus diesem Grund muss dies mit folgendem Befehl noch manuell erfolgen:
defmod <FHEM NAME> MQTT2_DEVICE
Beispiel
defmod lichtWohnzimmer MQTT2_DEVICE
Anschließend wird auch für dieses Gerät wieder ein passendes template ausgewählt, wie als wäre es ein normales Zigbee2MQTT-Gerät.
Im anschließenden Dialog-Fenster welches sich nach dem Setzen des templates öffnet, müssen die folgenden Werte durch passendes ersetzt werden:
BASE_TOPIC -> zigbee2mqtt
DEV_ID -> <Zigbee2MQTT Friendly-Gruppenname>

Danach sollte sich die Gruppe wie ein normales Zigbee2MQTT Gerät steuern lassen.

== Tasmota ==
{{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}[https://github.com/arendst/Sonoff-Tasmota Tasmota] ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) ist eine open-source Software für ESP8266-Geräte, die z.B. statt der originalen Firmware für Sonoff-Geräte und andere ESP8266-basierte WLAN-Steckdosen usw. verwendet werden kann.
{{Hinweis|[[Datei:Tasmota mqtt config.png|120px|thumb|right]]Vor allem, aber nicht nur bei Verwendung des MQTT2_CLIENT als IO, ist es empfehlenswert, in der MQTT-Konfiguration der tasmota-Geräte für den Parameter ''<nowiki>topic = %topic% (sonoff)</nowiki>'' ebenfalls die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' zu verwenden. (Kopieren Sie einfach diese Zeichenkette aus dem Eingabefeld für ''"client ..."'', siehe nebenstehende Abbildung). Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}
=== MQTT2_DEVICE ===
Dieses sollte bei aktiviertem ''autocreate'' am MQTT2_SERVER-Device automatisch angelegt werden, sobald das betreffende Gerät eingesteckt oder neu gestartet oder an einem evtl. vorhandenen Taster geschalten wird. Hier wurden Tasmota version(en) 6.1.1 und 6.2.1 getestet, Hardware war Sonoff Touch und S20.

=== Manuelle Anpassungen ===
Die RAW-Definition kann dann beispielsweise wie folgt ergänzt werden:
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
attr MQTT2_DVES_9B01BD IODev m2server
attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\
DVES_9B01BD:cmnd/DVES_9B01BD/POWER:.* POWER\
DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/DVES_9B01BD/POWER on\
off cmnd/DVES_9B01BD/POWER off\
reboot cmnd/DVES_9B01BD/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot

=== attrTemplate ===
Für gängige Tasmota-Geräte stehen ''templates'' bereit, mit denen sich diese schnell konfigurieren lassen.
Beachten Sie dazu den Abschnitt ''attrTemplate'' in [[MQTT2 DEVICE#attrTemplate|MQTT2_DEVICE]]. Bei Anwendung eines template mit "split" im Namen werden dabei weitere Geräte angelegt und konfiguriert.

== Shelly ==
=== Vorbemerkung ===
Auch für Shelly-Geräte steht eine Auswahl an [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|templates]] bereit.
Beachten Sie auch hier, dass uU. bei Anwendung eines template mit "split" im Namen weitere Geräte angelegt und konfiguriert werden.

=== Shelly1 ===

=== Shellybulb ===
Zunächst muss man einen Statusupdate des Shellybulb erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:
Internals:
CFGFN
CID shellybulb_3CC533
DEF shellybulb_3CC533
DEVICETOPIC MQTT2_shellybulb_3CC533
IODev MQTT2_FHEM_Server
NAME MQTT2_shellybulb_3CC533
NR 246
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2018-12-12 19:28:08 status_blue 0
2018-12-12 19:28:08 status_brightness 61
2018-12-12 19:28:08 status_effect 0
2018-12-12 19:28:08 status_gain 26
2018-12-12 19:28:08 status_green 0
2018-12-12 19:28:08 status_ison true
2018-12-12 19:28:08 status_mode color
2018-12-12 19:28:08 status_red 255
2018-12-12 19:28:08 status_temp 3250
2018-12-12 19:28:08 status_white 0
Attributes:
IODev MQTT2_FHEM_Server
readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
room MQTT2_DEVICE
[[Bild:MQTT2 Shellybulb.png|400px|thumb|Darstellung in FHEMWEB nach Anwendung des template]]Dann bei den set-Anweisungen das attrTemplate "shellybulb" auswählen und setzen. Es erscheint eine Abfrage, ob die vorhandenen Readings gelöscht werden sollen. Diese bitte bestätigen und die Seite neu laden. Danach einmal An- und Ausschalten, damit die Readings auch durch einen neuen Status initialisiert werden und die Seite im Browser neu laden.

=== Shelly Plug S ===
Über die Lwistungsmessung des Shelly Plug S lässt sich sehr einfach auch eine Erkennung des Betriebszustandes des angeschlossenen Gerätes realisieren. Dazu stellt man zuerst fest, wieviel Leistung das Gerät in jedem Betriebszustand verbraucht und kann dann z.B. für einen angeschlossenen Fernseher, der im Standby 1 Watt und im Betrieb > 100 Watt verbraucht, den Zustand erkennen und als on/off Status anzeigen. Dazu wird das state Reading wie folgt definiert:
attr readingList shellies/shellyplug-s-123456/relay/0/power:.* { { state => $EVTPART0<100?"off":"on" } }
Der Status des MQTT2 Devices zeigt dann bei <100W "off" und sonst "on" an.

== Milight-Bridge ==
=== Vorbemerkung ===
Der [https://github.com/sidoh/esp8266_milight_hub esp8266_milight_hub] ist ein open source- Projekt, mit dem auf Basis von ''openmili'' eine Vielzahl von MiLight-Geräten gesteuert werden können. Der MiLight-Hub erstetzt dabei eine beliebige Zahl von Milight-Bridges und ist auch zu verschiedenen Versionen des MiLight-Protokols kompatibel.
Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspricht dabei im Wesentlichen einem MySensors-Wifi-Gateway<ref>Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.</ref>.
Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist.
Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.

=== Einstellungen am MiLight-Hub ===
Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Vorgaben sind im Web-Interface des Hub einzustellen. Gegebenenfalls passen Sie die vom Hub zurückzugebenden Elemente im Web-Interface des Hub an.
Die Einstellungen für ''MQTT topic pattern'' usw. können auf den default-Werten<ref>Diese sind: ''milight/:device_id/:device_type/:group_id'' für "topic pattern" ''milight/updates/:hex_device_id/:device_type/:group_id'' für "update topic pattern" ''milight/states/:hex_device_id/:device_type/:group_id'' für "state topic pattern". Der Autor hat derzeit folgende Infotypen zum Senden markiert: "status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color" (enthält eventuell zu viele Angaben. Bei einem Eventhandler muß man uU. darauf achten, dass kurz hintereinander zweimal dasselbe Event kommen kann (für ON/OFF)).</ref> belassen werden, für die seit Mitte 2019 vorhandene Option, eine LWT-Message zu senden (''MQTT Client Status Topic''), tragen Sie ''milight/LWT'' ein und aktivieren ''Detailed''.

=== FHEM-Devices ===
[[Bild:MQTT2 MiLight.png|400px|thumb|Milight: Darstellung in FHEMWEB]]
==== Bridge ====
Wird nun über den Hub oder eine von diesem erkannte Fernbedienung ein vorhandenes Leuchtmittel geschaltet, wird bei eingeschaltetem autocreate ein erstes Device erstellt, die zunächst erstellte Definition sieht typischerweise etwa so aus:
defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325
attr MQTT2_milight_hub_1370325 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_1370325 readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_hub_1370325 room MQTT2_DEVICE

Auf dieses Device wird nun das ''template'' X_01_esp_milight_hub_bridge angewandt.

==== Einzelne Leuchtmittel ====

Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:
defmod MQTT2_milight_0xBE59_1 MQTT2_DEVICE milight_0xBE59_1
attr MQTT2_milight_0xBE59_1 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0xBE59_1 readingList milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_0xBE59_1 room MQTT2_DEVICE

Auf dieses wird nun eines der Bulb-templates angewendet. Wählt man das template X_01_esp_milight_hub_rgbw_bulb, wird eine einfache Variante erstellt, die neben einem toggelnden Icon nur Regler für Helligkeit, die Farbe und zwei Schaltflächen für den Weiß- und Nachtmodus enthält. Wer mehr oder andere Steuerelemente erhalten möchte, verwendet ein anderes template. Nicht benötigte Elemente kann man dabei einfach aus der Definition löschen.

Alle weiteren Devices werden genauso erstellt.

Um ein Device zu erhalten, mit dem sich alle Kanäle gleichzeitig steuern lassen, kann das template ''X_01a_esp_milight_hub_make_rgbw_group'' verwendet werden. Dieses verändert nicht das aktuelle Device, sondern erstellt '''eine Kopie''', die dann modifiziert wird. Diese Kopie ist unter dem Namen ''milight_<RemoteID>_0'' im selben Raum zu finden wie das Ausgangsgerät und kann ebenfalls an die eigenen Wünsche angepaßt werden.

Weitere Beispiele:
Beispiel für ein RGB-CCT-Device:
defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight_hub_10693013:milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight_hub_10693013:milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\

attr Licht_Wz_all room Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
attr Licht_Wz_all sortby 1
attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command\
:brightness:saturation\
:color_temp:hue

==== Fernbedienung als Input-Device nutzen ====
In diesem {{Link2Forum|Topic=103493|LinkText=Thread}} ist dargestellt, wie man eine Fernbedingung des Typs FUT089 dazu verwenden kann, einen [[MPD]] oder Rollladenaktoren zu steuern, oder diese Fernbedienung für [[Hue#HUE-Device|HUEDevice]]-Leuchtmittel zu nutzen.
Um hier nur Differenz-Meldungen zu erhalten und doppelte Events zu verhindern, sollte hier die readingList so angepaßt werden, dass nur Messages aus dem "updates"-Zweig ausgewertet werden:
defmod MiLight_RC1_0 MQTT2_DEVICE milight_0xABCD_0
attr MiLight_RC1_0 readingList milight/updates/0xABCD/fut089/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/fut089/0:.* {}

== eBus ==
An dieser Stelle sollen lediglich die Grundzüge erläutert werden, eine ausführliche Anleitung über die Konfiguration des [[EBUS-MQTT2|eBus mit MQTT2 gibt es hier]].

=== Vorbereitung und Definition am eBus ===
Vorausgesetzt wird ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel [[EBUS#Software|EBUS]] beschrieben.
In der Konfiguration des Dämons ( /etc/default/ebusd ) ist die Kommunikation über MQTT zu aktivieren und die Topic-Struktur festzulegen, z.B. ''ebusd/%circuit/%name''.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
{{Hinweis|Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ''ebusd'' verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ''ebus...'' zu beginnen!}}

=== Vorbereitung und Definition in FHEM ===
Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem '''''vor''''' den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der ''readingList'' enthalten, die vom ebus stammen. Da wir die ''readingList'' anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen zumindest sämtliche ''readingList''-Attribute entsprechend bereinigt oder gelöscht werden; in der Regel ist es einfacher, diese Geräte nach dem Deaktivieren des autocreate am IO zu löschen.
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT als IO nutzen, sollte für das weitere Vorgehen eine Kopie des MQTT2-"Sammeldevices" genutzt werden, und dessen ''CID'' auf ''ebusd'' geändert werden. Nach Anwendung des ebusd-splitter-templates müssen dann alle den ebus betreffenden Einträge aus der ''readingList'' des "Sammeldevices" gelöscht werden oder diese ganz gelöscht.}}Ist der ebus-Dämon lauffähig und für MQTT konfiguriert, sendet dieser regelmäßige Messages.

Sind die Vorbereitungen abgeschlossen, aktivieren wir ''autocreate'' wieder, allerdings wählen wir als autocreate-Methode ''complex'' aus, da der eBus-Dämon teilweise<ref>Dies betrifft vorrangig die Statusmeldungen</ref> eine weiter verschachtelte JSON-Struktur zum Versenden der Informationen verwendet als üblich. Danach wird wie bei den anderen o.g. Geräten automatisch ein neues MQTT2_DEVICE angelegt<ref>Bei Verwendung des MQTT2_CLIENT wird dann die ''readingList'' am bereits definierten MQTT2_DEVICE aus der Kopie des "Sammeldevice" automatisch wieder erstellt bzw. gefüllt.</ref>

==== "ebus-Bridge" ====
Auf das von ''autocreate'' erstellte MQTT2_DEVICE wird nunmehr das template ''E_01a_eBus_daemon_splitter'' angewendet. Nach einiger Zeit sollte sowohl die readingList an diesem Device erweitert worden sein, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.
Dieses Device liefert zukünftig Readings zum Dämon selbst, wie dessen ''uptime'', alle weiteren am eBus angeschlossenen Teilnehmer werden dagegen zweckmäßigerweise durch ein oder mehrere weitere MQTT2_DEVICE-Geräte dargestellt.
==== "ebusd_bai" und weitere Geräte ====
{{Hinweis|Der eBus-Dämon sendet nicht alle Informationen zu allen am eBus angeschlossenen Geräte automatisch. Diese müssen teilweise erst aktiv angefragt werden. Wie das im einzelnen erfolgen kann, ist dem o.g. Detailartikel zu entnehmen.}}
Funktioniert die Kommunikation zwischen dem eBus-Dämon und FHEM, sollte nach einigen Minuten zumindest ein weiteres Gerät namens ''MQTT2_ebus_bai'' angelegt worden sein.

== Allgemeine Hinweise ==
=== MQTT2_SERVER und MQTT2_CLIENT für Debugging nutzen ===
Nutzt man das rawEvents-Attribut am MQTT2-IO<ref>z.B. <code>attr MQTT2_FHEM_Server rawEvents .*</code>, der regex-Filter kann wie üblich angepaßt werden</ref>, kann man den Datenverkehr des Servers am Event-Monitor mitschneiden. Dies ist insbesondere für unbekannte Geräte nützlich, deren Topic- und Payload-Struktur noch nicht bekannt ist.
Um den kompletten MQTT Datenaustausch mitzuschneiden, kann man mit <code>attr mqtt2_server verbose 5</code> auch alles ins FHEM-Log schreiben lassen.

=== attrTemplate ===
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''attrTemplate'' genutzt werden.
Die Anwendung ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.
== Links ==
* {{Link2Forum|Topic=91394|LinkText=Thread, aus dem diese Anleitung ursprünglich entstanden ist}}
* {{Link2Forum|Topic=91807|LinkText=Thread zum Tasmota-Device}}
* {{Link2Forum|Topic=97989|LinkText=Thread, aus dem diese Anleitung für den eBus ursprünglich entstanden ist}}
* {{Link2Forum|Topic=94495|LinkText=Neue templates einreichen}}
* {{Link2Forum|Topic=94494|LinkText=Fragen, Wünsche und Kritik zu mqtt2.template}}

== Hinweise ==
<references />
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]
[[Kategorie:ZigBee]]
[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]

Batterieüberwachung

2018-12-31T12:42:22Z

Reibuehl: Fehlender : eingefügt

Verschiedene batteriebetriebene Geräte ([[:Kategorie:HomeMatic Components|Homematic]], RFXtrx, ZWave,..) übermitteln unter anderem den Zustand der eingelegten Batterie. Bei diesen kann der Batteriestatus übersichtlich dargestellt und / oder aktiv überwacht werden. Bei Geräten ohne eigenen Batteriestatus muss man diesen "nachrüsten".

== Geräte mit Batteriestatus ==
=== Übersichtsdarstellung per readingsGroup ===
Mit Hilfe einer ReadingsGroup kann einfach eine Übersicht aller Geräte mit "battery"-Reading erstellt werden, s. [[ReadingsGroup#Auswahl_.C3.BCber_Reading-Namen.2C_Status_als_Symbol_dargestellt|hier]].

=== Benachrichtigung per notify ===
Um Ausfälle frühzeitig zu erkennen, kann man sich per E-Mail benachrichtigen lassen, sobald eine Batteriemeldung mit etwas anderem als "ok" gesendet wird (z.B. "low"). Zusätzlich erzeugt der unten stehende Code einen Eintrag im Logfile. Der Code ist für die Raw Definition und nicht für den DEF Editor!

<nowiki>define n_batt_chk notify .*:[Bb]attery.* { if ($EVENT !~ m/ok/) { \
{ FB_mail('recipient@internet.de', 'FHEM Batteriewarnung', $NAME.': '.$EVENT)};; \
Log 3, "$NAME : Batteriewarnung $EVENT";; \
} \
}</nowiki>

'''Achtung:''' Für Nutzer eines [[HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat|HM-CC-RT-DN]] muss der Code anders aussehen, da mit diesem Thermostat erstmalig der aktuelle Spannungswert der Batterie gesendet wird, also z.B.:

UG.Treppe.Heizung batteryLevel: 3.1 V

Man würde bei der Verwendung des o.g. Codes bei jeder Batteriemeldung eines HM-CC-RT-DN eine E-Mail erhalten. Daher muss der o.g. Code wie folgt geändert werden (Doppelpunkt hinter "[Bb]attery"):

<nowiki>define n_batt_chk notify .*:[Bb]attery:|.*:[Bb]atteryS { if($EVENT !~ m/ok/) { \
{ FB_mail('recipient@internet.de', 'FHEM Batteriewarnung', $NAME.': '.$EVENT)};; \
Log 3, "$NAME: Batteriewarnung $EVENT";; \
} \
}</nowiki>

Achtung: FB_mail setzt die Installation auf einer FritzBox voraus. Für andere Hardware-/OS-Plattformen ist die Vorgehensweise unter dem Titel [[E-Mail_senden]] beschrieben.

Wer statt einer email lieber eine Pushover-Nachricht auf sein Smartphone bekommen möchte, kann diesen Code benutzen:

<nowiki>define n_batt_chk notify .*:[Bb]attery:|.*:[Bb]atteryS { if($EVENT !~ m/ok/) { \
{ fhem ("set PushoverChristoph msg FHEM Batteriewarnung, $NAME: $EVENT:\nBatterien sollten demnächst gewechselt werden!");; \
Log 3, "$NAME: Batteriewarnung $EVENT";; \
} \
} \
}</nowiki>

Natürlich muß dafür eine Pushover-Installation in fhem vorhanden sein - sonst bitte gem. [[Pushover]] nachholen.

Testen kann man dies z.B. mit <code>trigger HeizungWZ Battery:low</code>

Man sollte auch darauf achten, dass sich das Ereignis, auf das man triggert, nicht zu häufig wiederholt (z.B. durch das Attribut <code>event-on-change-reading</code>).

== Geräte ohne Batteriestatus ==
Bei Geräten ohne Reading für den Batteriestatus kann man diesen auf verschiedene Weisen schätzen und als Reading eintragen. Dies funktioniert aber natürlich nur, wenn das Gerät sendet - bei einem rein empfangenden Aktor wie dem [[FHT 8v direkt ansprechen|FHT Stellantrieb]] klappt es also nicht...

=== Erweiterung des Geräts um battery-Reading ===
Mit Hilfe von {{Link2CmdRef|Lang=de|Anker=userReadings|Label=userReadings}} kann man recht einfach einen Batteriestatus schätzen und als Reading bereitstellen. Dann greift auch direkt die oben beschriebene Auswertung.

Die Idee ist, den zeitlichen Abstand des aktuellen Timestamps mit dem letzten geloggten Timestamp zu vergleichen und daraus auf den Batteriestatus zu schliessen - bspw. Abstand > 10min = Batterie low.

Dazu muss lediglich folgendes userReading für jedes batteriebetriebene Device (ohne Batteriestatus) angelegt werden (um bei >10min "low" zu setzen):

; Konfiguration:
Lediglich der Schwellwert (600) braucht nach Wunsch angepasst zu werden, alles andere passt automatisch (vgl. [[Notify#Hinweise]]).

; Im Webinterface:
<pre>
battery { return "ok" if ( (time_str2num(ReadingsTimestamp($NAME,"state","0")) - time_str2num(OldTimestamp($NAME))) < 600 ); return "low" }
</pre>

; Alternativ im Config-File:
<pre>
attr MeinSensor userReadings battery { return "ok" if ( (time_str2num(ReadingsTimestamp($NAME,"state","0")) - time_str2num(OldTimestamp($NAME))) < 600 ); return "low" }
</pre>

; Erläuterung:
: <code>$NAME</code> - ist die Variable für das Device (und braucht nicht angepasst zu werden)
: <code>battery {...}</code> - Name des userreadings mit Spezifikation, vgl. {{Link2CmdRef|Lang=de|Anker=userReadings}}.
: <code>return "ok" if ( ... ); return "low"</code> - Spezifikation: Reading = "ok", wenn if erfüllt, sonst "low"
: <code>time_str2num(ReadingsTimestamp($NAME,"state","0")</code> - Aktueller Timestamp in Sekunden, vgl. {{Link2CmdRef|Lang=de|Anker=perl}}, [[Notify#Hinweise]]
: <code>time_str2num(OldTimestamp($NAME))</code> - Letzter Timestamp im Log in Sekunden (egal ob FileLog oder DbLog), vgl. {{Link2CmdRef|Lang=de|Anker=perl}}, [[Notify#Hinweise]]
: <code>600</code> - Schwellwert für "low" (600 sec = 10 min), nach Bedarf anpassen

=== Alternativ per Skript ===
Andere Komponenten, wie z. B. [[:Kategorie:FS20 Components|FS20 Komponenten]], übermitteln keinen Batteriestatus.

Um dort dennoch einen Test darauf zu machen, ob die Batterie evtl. leer ist, kann man z. B. prüfen, wann der letzte Status des jeweiligen Gerätes empfangen wurde, etwa mit folgender Funktion in [[99_myUtils_anlegen|99_myUtils.pm]]:

<pre>sub check_if_alive($$) {
# Expects:
# 1. Devicename to be checked
# 2. Age in hours, after the expiry of which with no new state the device will be considered as dead.
# Returns:
# 0 -> Device dead
# 1 -> Device alive
# 2 -> Error
my ($Device,$hours_threshold) = @_;
my ($Device) = @_;
my $now = time;
my $Timestamp = ReadingsTimestamp($Device,"state","0");
if ($Timestamp eq "0") {
return 2;
}

my @splitdatetime = split(/ /,$Timestamp);
my @splitdate = split(/-/, $splitdatetime[0]);
my @splittime = split(/:/, $splitdatetime[1]);
my $last_state_time = timelocal($splittime[2], $splittime[1], $splittime[0], $splitdate[2], $splitdate[1]-1, $splitdate[0]);
my $age_in_hours = ($now - $last_state_time) / 3600;

if ($age_in_hours > $hours_threshold) {
Log 1, ("check_if_alive: $Device dead, last state was $age_in_hours hours ago");
return 0;
} else {
return 1;
}

}</pre>

Diese Funktion kann man z.B. in einem at je zu prüfendem Gerät regelmäßig (z. B. einmal am Tag um 05:55 Uhr) aufrufen, und testen, ob die letzten 12 Stunden etwas empfangen wurde:

<pre>*05:55:55 {
check_if_alive("KS300", 12);
}</pre>

KS300 ist dabei der Name des Devices in fhem.

Wenn das Gerät nicht geantwortet hat, erzeugt die oben vorgeschlagene Funktion einen Logeintrag.

Hinweis: Dieser Batterietest schlägt natürlich auch an, wenn die FS20 Geräte noch funktionieren, aber der CUL zum Empfangen der Signale nicht mehr funktioniert. In dem Fall sind dann auf einen Schlag angeblich alle Batterien leer. Um dies zumindest teilweise abzufangen, könnte man vor dem Erzeugen des Logeintrags noch auf den state des CUL testen, dass dieser nicht "disconnected" ist.

==== Visualisierung ====
Der Abschnitt Links unten enthält einen Verweis, wie man den Batteriestatus visuell anzeigen kann. Das funktioniert mit der oben vorgeschlagenen Funktion mit einigen Ergänzungen auch, wenn das Gerät selbst keinen Batteriestatus anzeigt.

Dafür braucht man einen zusätzlichen Dummy je zu überwachendem Gerät, mit dem Namen dum_<zu_überwachendes_Gerät>_dead. Für das Gerät KS300 heißt dieser dummy also z. B. dum_KS300_dead:

<pre>Internals:
NAME dum_KS300_dead
NR 795
STATE nein
TYPE dummy
Readings:
2015-04-28 07:47:48 state nein
Attributes:
devStateIcon ja:measure_battery_50@red nein:measure_battery_100@green</pre>

Dieser dummy soll hier die Zustände "ja" und "nein" annehmen können. Bei ja ist ihm über devStateIcon ein rotes Icon einer eher leeren Batterie zugewiesen, bei nein ein grünes Icon einer vollen Batterie.

Nun muss noch die oben vorgeschlagene Funktion angepasst werden, um den Zustand des dummy entsprechend dem ermittelten Batteriestatus neu zu setzen. Dafür wird die Abfrage des Alters am Ende der Funktion um eine Zeile erweitert, die den Status des dummy setzt:

<pre> if ($age_in_hours > $hours_threshold) {
Log 1, ("check_if_alive: $Device dead, last state was $age_in_hours hours ago");
fhem("set dum_".$Device."_dead ja");
return 0;
} else {
fhem("set dum_".$Device."_dead nein");
return 1;
}</pre>

Den Dummy mit diesem devStateIcon kann man so der unter "Links" unten vorgeschlagenen readingsGroup hinzufügen, und damit auch Geräte ohne eigenen Batteriestatus überwachen.

== Links ==
* [[ReadingsGroup#Auswahl_.C3.BCber_Reading-Namen.2C_Status_als_Symbol_dargestellt|visuelle Batterieüberwachung mit readingsGroup]]
* {{Link2CmdRef|Lang=de|Anker=userReadings}} - userReadings
* {{Link2CmdRef|Lang=de|Anker=perl}} - Perl specials
* [[Notify#Hinweise|Hinweise zu Variablen]] (ansonsten auch an div. Stellen in der {{Link2CmdRef}})

[[Kategorie:HOWTOS]]

Batterieüberwachung

2018-12-31T12:35:11Z

Reibuehl: Anpassung laut Forumsvorschlag von Forumuser "Paul" zur Unterstützung des BatteryStatus Readings.

Verschiedene batteriebetriebene Geräte ([[:Kategorie:HomeMatic Components|Homematic]], RFXtrx, ZWave,..) übermitteln unter anderem den Zustand der eingelegten Batterie. Bei diesen kann der Batteriestatus übersichtlich dargestellt und / oder aktiv überwacht werden. Bei Geräten ohne eigenen Batteriestatus muss man diesen "nachrüsten".

== Geräte mit Batteriestatus ==
=== Übersichtsdarstellung per readingsGroup ===
Mit Hilfe einer ReadingsGroup kann einfach eine Übersicht aller Geräte mit "battery"-Reading erstellt werden, s. [[ReadingsGroup#Auswahl_.C3.BCber_Reading-Namen.2C_Status_als_Symbol_dargestellt|hier]].

=== Benachrichtigung per notify ===
Um Ausfälle frühzeitig zu erkennen, kann man sich per E-Mail benachrichtigen lassen, sobald eine Batteriemeldung mit etwas anderem als "ok" gesendet wird (z.B. "low"). Zusätzlich erzeugt der unten stehende Code einen Eintrag im Logfile. Der Code ist für die Raw Definition und nicht für den DEF Editor!

<nowiki>define n_batt_chk notify .*:[Bb]attery.* { if ($EVENT !~ m/ok/) { \
{ FB_mail('recipient@internet.de', 'FHEM Batteriewarnung', $NAME.': '.$EVENT)};; \
Log 3, "$NAME : Batteriewarnung $EVENT";; \
} \
}</nowiki>

'''Achtung:''' Für Nutzer eines [[HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat|HM-CC-RT-DN]] muss der Code anders aussehen, da mit diesem Thermostat erstmalig der aktuelle Spannungswert der Batterie gesendet wird, also z.B.:

UG.Treppe.Heizung batteryLevel: 3.1 V

Man würde bei der Verwendung des o.g. Codes bei jeder Batteriemeldung eines HM-CC-RT-DN eine E-Mail erhalten. Daher muss der o.g. Code wie folgt geändert werden (Doppelpunkt hinter "[Bb]attery"):

<nowiki>define n_batt_chk notify .*:[Bb]attery|.*:[Bb]atteryS { if($EVENT !~ m/ok/) { \
{ FB_mail('recipient@internet.de', 'FHEM Batteriewarnung', $NAME.': '.$EVENT)};; \
Log 3, "$NAME: Batteriewarnung $EVENT";; \
} \
}</nowiki>

Achtung: FB_mail setzt die Installation auf einer FritzBox voraus. Für andere Hardware-/OS-Plattformen ist die Vorgehensweise unter dem Titel [[E-Mail_senden]] beschrieben.

Wer statt einer email lieber eine Pushover-Nachricht auf sein Smartphone bekommen möchte, kann diesen Code benutzen:

<nowiki>define n_batt_chk notify .*:[Bb]attery|.*:[Bb]atteryS { if($EVENT !~ m/ok/) { \
{ fhem ("set PushoverChristoph msg FHEM Batteriewarnung, $NAME: $EVENT:\nBatterien sollten demnächst gewechselt werden!");; \
Log 3, "$NAME: Batteriewarnung $EVENT";; \
} \
} \
}</nowiki>

Natürlich muß dafür eine Pushover-Installation in fhem vorhanden sein - sonst bitte gem. [[Pushover]] nachholen.

Testen kann man dies z.B. mit <code>trigger HeizungWZ Battery:low</code>

Man sollte auch darauf achten, dass sich das Ereignis, auf das man triggert, nicht zu häufig wiederholt (z.B. durch das Attribut <code>event-on-change-reading</code>).

== Geräte ohne Batteriestatus ==
Bei Geräten ohne Reading für den Batteriestatus kann man diesen auf verschiedene Weisen schätzen und als Reading eintragen. Dies funktioniert aber natürlich nur, wenn das Gerät sendet - bei einem rein empfangenden Aktor wie dem [[FHT 8v direkt ansprechen|FHT Stellantrieb]] klappt es also nicht...

=== Erweiterung des Geräts um battery-Reading ===
Mit Hilfe von {{Link2CmdRef|Lang=de|Anker=userReadings|Label=userReadings}} kann man recht einfach einen Batteriestatus schätzen und als Reading bereitstellen. Dann greift auch direkt die oben beschriebene Auswertung.

Die Idee ist, den zeitlichen Abstand des aktuellen Timestamps mit dem letzten geloggten Timestamp zu vergleichen und daraus auf den Batteriestatus zu schliessen - bspw. Abstand > 10min = Batterie low.

Dazu muss lediglich folgendes userReading für jedes batteriebetriebene Device (ohne Batteriestatus) angelegt werden (um bei >10min "low" zu setzen):

; Konfiguration:
Lediglich der Schwellwert (600) braucht nach Wunsch angepasst zu werden, alles andere passt automatisch (vgl. [[Notify#Hinweise]]).

; Im Webinterface:
<pre>
battery { return "ok" if ( (time_str2num(ReadingsTimestamp($NAME,"state","0")) - time_str2num(OldTimestamp($NAME))) < 600 ); return "low" }
</pre>

; Alternativ im Config-File:
<pre>
attr MeinSensor userReadings battery { return "ok" if ( (time_str2num(ReadingsTimestamp($NAME,"state","0")) - time_str2num(OldTimestamp($NAME))) < 600 ); return "low" }
</pre>

; Erläuterung:
: <code>$NAME</code> - ist die Variable für das Device (und braucht nicht angepasst zu werden)
: <code>battery {...}</code> - Name des userreadings mit Spezifikation, vgl. {{Link2CmdRef|Lang=de|Anker=userReadings}}.
: <code>return "ok" if ( ... ); return "low"</code> - Spezifikation: Reading = "ok", wenn if erfüllt, sonst "low"
: <code>time_str2num(ReadingsTimestamp($NAME,"state","0")</code> - Aktueller Timestamp in Sekunden, vgl. {{Link2CmdRef|Lang=de|Anker=perl}}, [[Notify#Hinweise]]
: <code>time_str2num(OldTimestamp($NAME))</code> - Letzter Timestamp im Log in Sekunden (egal ob FileLog oder DbLog), vgl. {{Link2CmdRef|Lang=de|Anker=perl}}, [[Notify#Hinweise]]
: <code>600</code> - Schwellwert für "low" (600 sec = 10 min), nach Bedarf anpassen

=== Alternativ per Skript ===
Andere Komponenten, wie z. B. [[:Kategorie:FS20 Components|FS20 Komponenten]], übermitteln keinen Batteriestatus.

Um dort dennoch einen Test darauf zu machen, ob die Batterie evtl. leer ist, kann man z. B. prüfen, wann der letzte Status des jeweiligen Gerätes empfangen wurde, etwa mit folgender Funktion in [[99_myUtils_anlegen|99_myUtils.pm]]:

<pre>sub check_if_alive($$) {
# Expects:
# 1. Devicename to be checked
# 2. Age in hours, after the expiry of which with no new state the device will be considered as dead.
# Returns:
# 0 -> Device dead
# 1 -> Device alive
# 2 -> Error
my ($Device,$hours_threshold) = @_;
my ($Device) = @_;
my $now = time;
my $Timestamp = ReadingsTimestamp($Device,"state","0");
if ($Timestamp eq "0") {
return 2;
}

my @splitdatetime = split(/ /,$Timestamp);
my @splitdate = split(/-/, $splitdatetime[0]);
my @splittime = split(/:/, $splitdatetime[1]);
my $last_state_time = timelocal($splittime[2], $splittime[1], $splittime[0], $splitdate[2], $splitdate[1]-1, $splitdate[0]);
my $age_in_hours = ($now - $last_state_time) / 3600;

if ($age_in_hours > $hours_threshold) {
Log 1, ("check_if_alive: $Device dead, last state was $age_in_hours hours ago");
return 0;
} else {
return 1;
}

}</pre>

Diese Funktion kann man z.B. in einem at je zu prüfendem Gerät regelmäßig (z. B. einmal am Tag um 05:55 Uhr) aufrufen, und testen, ob die letzten 12 Stunden etwas empfangen wurde:

<pre>*05:55:55 {
check_if_alive("KS300", 12);
}</pre>

KS300 ist dabei der Name des Devices in fhem.

Wenn das Gerät nicht geantwortet hat, erzeugt die oben vorgeschlagene Funktion einen Logeintrag.

Hinweis: Dieser Batterietest schlägt natürlich auch an, wenn die FS20 Geräte noch funktionieren, aber der CUL zum Empfangen der Signale nicht mehr funktioniert. In dem Fall sind dann auf einen Schlag angeblich alle Batterien leer. Um dies zumindest teilweise abzufangen, könnte man vor dem Erzeugen des Logeintrags noch auf den state des CUL testen, dass dieser nicht "disconnected" ist.

==== Visualisierung ====
Der Abschnitt Links unten enthält einen Verweis, wie man den Batteriestatus visuell anzeigen kann. Das funktioniert mit der oben vorgeschlagenen Funktion mit einigen Ergänzungen auch, wenn das Gerät selbst keinen Batteriestatus anzeigt.

Dafür braucht man einen zusätzlichen Dummy je zu überwachendem Gerät, mit dem Namen dum_<zu_überwachendes_Gerät>_dead. Für das Gerät KS300 heißt dieser dummy also z. B. dum_KS300_dead:

<pre>Internals:
NAME dum_KS300_dead
NR 795
STATE nein
TYPE dummy
Readings:
2015-04-28 07:47:48 state nein
Attributes:
devStateIcon ja:measure_battery_50@red nein:measure_battery_100@green</pre>

Dieser dummy soll hier die Zustände "ja" und "nein" annehmen können. Bei ja ist ihm über devStateIcon ein rotes Icon einer eher leeren Batterie zugewiesen, bei nein ein grünes Icon einer vollen Batterie.

Nun muss noch die oben vorgeschlagene Funktion angepasst werden, um den Zustand des dummy entsprechend dem ermittelten Batteriestatus neu zu setzen. Dafür wird die Abfrage des Alters am Ende der Funktion um eine Zeile erweitert, die den Status des dummy setzt:

<pre> if ($age_in_hours > $hours_threshold) {
Log 1, ("check_if_alive: $Device dead, last state was $age_in_hours hours ago");
fhem("set dum_".$Device."_dead ja");
return 0;
} else {
fhem("set dum_".$Device."_dead nein");
return 1;
}</pre>

Den Dummy mit diesem devStateIcon kann man so der unter "Links" unten vorgeschlagenen readingsGroup hinzufügen, und damit auch Geräte ohne eigenen Batteriestatus überwachen.

== Links ==
* [[ReadingsGroup#Auswahl_.C3.BCber_Reading-Namen.2C_Status_als_Symbol_dargestellt|visuelle Batterieüberwachung mit readingsGroup]]
* {{Link2CmdRef|Lang=de|Anker=userReadings}} - userReadings
* {{Link2CmdRef|Lang=de|Anker=perl}} - Perl specials
* [[Notify#Hinweise|Hinweise zu Variablen]] (ansonsten auch an div. Stellen in der {{Link2CmdRef}})

[[Kategorie:HOWTOS]]

SVG-Plots von FileLog auf DbLog umstellen

2018-04-30T11:39:20Z

Reibuehl: /* @fld */ Weitere Beispiele eingefügt.

Grundsätzlich verhält sich [[DbLog]] bei der Verwendung in [[Creating Plots|SVG-Plots]] sehr ähnlich wie ein [[FileLog]]. So kann ein neuer Plot auf DbLog-Daten in der [[FHEMWEB|FHEM-Oberfläche]] genauso angelegt werden wie beim FileLog, indem man an der Definition des DbLog Devices auf "Create SVG plot from DbLog" klickt. Wenn man von FileLog auf DbLog umstellt, möchte man aber evtl. nur die Definitionen der SVG-Plots anpassen. Hier einige Anmerkungen dazu.

== Define ==

Eine bestehende FileLog Definition für ein Thermostat könnte zB so aussehen:

define FileLog_W_HEIZUNG FileLog ./log/W_HEIZUNG-%Y.log W_HEIZUNG
attr FileLog_W_HEIZUNG logtype text
attr FileLog_W_HEIZUNG room hidden

define SVG_FileLog_W_HEIZUNG_1 SVG FileLog_W_HEIZUNG:SVG_FileLog_W_HEIZUNG_1:CURRENT
attr SVG_FileLog_W_HEIZUNG_1 room hidden

Bei Umstellung auf DbLog kann das FileLog-Device natürlich gelöscht werden, nachdem es durch ein allgemeines DbLog-Device ersetzt worden ist (siehe [[DbLog]]). Die Definition des Plots wird danach folgendermassen geändert:

define DBLOG DbLog mydb.conf .*:.*

define SVG_W_HEIZUNG_1 SVG DBLOG:SVG_DBLOG_W_HEIZUNG_1:CURRENT
attr SVG_W_HEIZUNG_1 room hidden

Mit dieser Anweisung wird ein SVG-Plot mit Namen ''SVG_W_HEIZUNG_1'' (der Name muss natürlich nicht geändert werden, soviel Zeit sollte man sich allerdings nehmen) angelegt, der seine Daten vom DbLog-Device ''DBLOG'' bezieht und mit Hilfe der Gplot-Datei ''SVG_DBLOG_W_HEIZUNG_1.gplot'' (auch dieser Name muss nicht zwingend geändert werden) rendert.

== Gplot-Datei ==

Die bestehende Gplot-Datei ''SVG_FileLog_W_HEIZUNG_1.gplot'' (im Verzeichnis ''www/gplot'') wird zunächst nach ''SVG_DBLOG_W_HEIZUNG_1.gplot'' kopiert. Sie kann gelöscht werden, wenn die Umstellung zufrieden stellend abgeschlossen ist. Geändert werden müssen nur die Zeilen, die mit ''#FileLog'' beginnen:

#FileLog 4:W_HEIZUNG.temperature\x3a:0:
#FileLog 4:W_HEIZUNG.desiredTemperature:0:
#FileLog 4:W_HEIZUNG.valveposition\x3a:0:

Daraus wird:

#DbLog W_HEIZUNG:temperature:0:
#DbLog W_HEIZUNG:desiredTemperature:0:
#DbLog W_HEIZUNG:valveposition:0:

''#FileLog'' wird durch ''#DbLog'' ersetzt. Die Angabe der Feldnummer vor dem Device (hier: "4") fällt weg, ebenso evtl. notierte Sonderzeichen am Ende der Readings-Bezeichnung (hier "\x3a"). Ansonsten bleibt der Inhalt der Gplot-Datei gleich.

===@fld===
Ein Sonderfall in der Notation liegt in der Verwendung von Mappings mit Hilfe des @fld-Arrays (siehe auch [[Creating Plots]]). Da es dieses Array in der Form in DbLogs nicht gibt, muss auf eine Zuweisung der Variable $val umgestellt werden. Lautet die Anweisung bei Verwendung von FileLog zB:

#FileLog 3:W_FENSTER:onoff::$fld[2]=~"1"?24:-10

muss sie für DbLog folgendermassen geändert werden:

#DbLog W_FENSTER:onoff:::$val=($val=~'1'?24:-10)

Insbesondere ist auch der zusätzliche Doppelpunkt vor der Anweisung zu beachten (Grund ist mir leider nicht bekannt, bitte ergänzen!).

Falls on/off-Werte geloggt werden sollen, muss der Code wie folgt lauten:

.gplot-File:
#DbLog HMW02.O05_4k7:state:::$val=($val=~"on"?10:1)
SVG-Editor:
RE_TEMP_BRT:temperature:::$val=$val/10

Um auch noch dim-Werte abzufangen und mit dem entsprechenden Value zu loggen, bietet sich folgendes an:

#DbLog Stellantrieb_Buero:state:::$val=~s/(on|off)(\d*).*/$1eq"on"?1:($1eq"dim"?$2*0.01:0)/eg

Bei Logeinträgen die aus mehreren Werten bestehen, muss der richtige Wert über eine Perl Expression extrahiert und der Variablen $val zugewiesen werden. Hierbei sind im replace Teil der Expression auch arithmetische Operationen möglich. Um z.B. aus dem Log des eState Readings eines HomeMatic Schaltaktors mit Leistungsmessung (HM-ES-PMSw1-Pl) den Strom in Ampere darzustellen, muss dieser erst extrahiert und dann von mA in A umgerechnet werden. Die Logzeile sieht Beispielsweise so aus:

2018-04-28_00:00:35 E: 24019.7 P: 0.82 I: 150 U: 234

Mit filelog konnte der Wert über den Eintrag

#FileLog 4:UG_WK_Waschmaschine_Pwr.eState\x3a::$fld[6]/1000

extrahiert und durch 1000 geteilt werden. Mit DbLog muss stattdessen eine Regular Expression mit arithmetischem Ausdruck im Zuweisungsteil verwendet werden:

#logdb UG_WK_Waschmaschine_Pwr:eState:::$val=~s/.*I:\s([-\.\d]+).*/$1\/1000/eg

Mit ähnlichen Ausdrücken ist z.B. auch eine Umsetzung von zwei Wertebereichen auf 1/0 Werte für einen Plot, der on/off darstellen soll, möglich. Um z.B. bei Werten unter 250mA eine 0 (off) und über 250mA eine 1 (on) zurück zu liefern, kann dieser Ausdruck verwendet werden:

#logdb UG_WK_Waschmaschine_Pwr:eState:::$val=~s/.*I:\s([-\.\d]+).*/$1<250?0:1/eg

===logProxy===

#logProxy FileLog:FileLog_W_HEIZUNG:4:W_HEIZUNG.valveposition\x3a:0:

wird zu

#logProxy DbLog:DBLOG:W_HEIZUNG:valveposition:0:

Näheres dazu unter [[LogProxy]].

[[Kategorie:HOWTOS]]

HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach

2017-01-27T11:23:57Z

Reibuehl: Erweiterungen aus https://forum.fhem.de/index.php?topic=65830.0 eingepflegt.

{{Infobox Hardware|Bild=platzHalter.png
|Bildbeschreibung=HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach für Markenschalter
|HWProtocol=HomeMatic
|HWType=Aktor / Sender
|HWCategory=HomeMatic
|HWComm=868,3MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=0,5W (Standby)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=eQ-3}}

[[HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach]] ist ein einkanaliger Funk-Schaltaktor "für Markenschalter", der mittels entsprechender Installationsadapter mit Tasterwippen diverser renommierter Hersteller versehen werden kann und sich dadurch nahtlos in bestehende Elektroinstallationen einfügt.

== Features ==
Das besondere an diesem Schalter ist, dass er den vorhandenen Unterputzeinsatz vollständig ersetzt. Dabei kann die Wippe des vorhandenen Schalters - je nach Hersteller - mit einer entsprechenden Adapterplatte weiterverwendet werden.

Es handelt sich hierbei nur um einen Aktor. Es ist nicht möglich die Taster mit anderen Homematic Geräten zu peeren. Man kann nur andere Taster mit dem Aktor peeren und diesen fernsteuern.

== Technische Daten ==

{|
| Art
| Unterputz
|-
| Typ
| 1fach
|-
| Stand-by-Verbrauch
| 0,5 W (lt. Bedienungsanleitung, S. 31, Stand 02/2012, 1 W)
|-
| Versorgungsspannung
| 230 V
|-
| Abmessungen (B x H x T)
| 71 x 71 x 37 mm
|-
| Farbe
| Grau
|-
| Max. Schaltleistung
| 1000 W
|-
| Relaistyp
| Wechsler
|-
| Funkfrequenz
| 868,3 MHz
|-
| Empfängerklasse
| SRD Class 2
|-
| Sicherung (intern)
| Rundsicherung 5 A, träge
|-
| Max. Sendeleistung
| 10 mW
|-
| IP-Schutzgrad
| IP 20
|-
| Umgebungstemperaturbereich
| 5–35 °C
|}

== Hinweise zur Hardware-Installation ==
Der vorhandene Schalter muss ersetzt werden. Dabei sind ein paar Dinge zu beachten:

* Der (neue) Schalter benötigt neben dem L-Leiter auch einen N-Leiter für die Stromversorgung.
* Die Befestigung ist nicht wie bei dem System z.B. von Merten durch spreizen von Klammern möglich. Der Schalter muss in die Löcher in der Dose geschraubt werden (Schrauben im Lieferumfang enthalten).
* Die "Frontplatte" bzw. der Befestigungsrahmen ist etwas dicker, als der Rahmen eines normalen Schalters. Dadurch kann es sein, dass der vorhandene Rahmen des Schalters nicht mehr ganz an der Wand anliegt.
* Um die bereits vorhandene Schalter-Wippe weiter nutzen zu können, muss ein passender Adapter verwendet werden.

{{Randnotiz|RNText='''Info zum Bausatz'''
Das Gerät ist als Bausatz verfügbar, es sind die folgenden bedrahteten Bauteile einzulöten:
* 6 Kondensatoren
* 3 Stiftleisten/Fassungen (insgesamt 16 Pole)
* 1 Spannungsregler, 1 Diode
* 1 Relais (8 Pole)
* 1 Induktivität
* 1 Widerstand, 1 Varistor
Die zu lötenden Bauteile sind relativ unproblematisch, die Lötstellen befinden sich jedoch in drei Fällen sehr nah an bzw. zwischen vorbestückten SMD-Bauteilen.}}
== Hinweise zum Betrieb mit FHEM ==
Das [[Pairing (HomeMatic)|Pairing]] sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

=== FHEM Config-Auszug ===
Ein exemplarischer Auszug aus der [[Konfiguration]]:

<pre>
define LichtWohnzimmer CUL_HM 197764
attr LichtWohnzimmer devInfo 010100
attr LichtWohnzimmer firmware 2.1
attr LichtWohnzimmer hmClass receiver
attr LichtWohnzimmer model unknown
attr LichtWohnzimmer room Wohnzimmer
attr LichtWohnzimmer serialNr JEQ0xxxxxx
attr LichtWohnzimmer subType switch
</pre>

=== Mögliche Schaltoperationen ===
Der Aktor versteht folgende Aktionen:

<pre>
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den Zustand des Aktors, d.h. ein eingeschalteter Aktor wird ausgeschaltet
</pre>

Zusätzliche Funktionen wie ein direkter Zugriff auf die integrierten Taster (self01 und self02) des Schalters können durch Programmieren der [[HomeMatic_Register_programmieren | HomeMatic Register]] realisiert werden.

Dabei entspricht self01 dem Ausschalter des Wippschalters und self02 dem Einschalter des Wippschalters. Settings, die man also für den self01 Schalter einstellt, werden beim Ausschalten des Lichts (im Standard) angewandt und umgekehrt.

=== Log-Auszug ===
In FHEM ist nach dem Schalten des HM-LC-Sw1PBU-FM folgendes Log zu sehen:
<pre>
2012-06-05_00:09:22 LichtWohnzimmer deviceMsg: off
2012-06-05_00:09:22 LichtWohnzimmer off
2012-06-05_07:40:51 LichtWohnzimmer on
2012-06-05_07:40:51 LichtWohnzimmer deviceMsg: on
</pre>

Beim Einrichten des Schalters kommt folgender Auszug (Stand: 06.2012)
<pre>
2012.06.04 23:12:27 2: CUL_HM pair: CUL_HM_switch_197764 is a switch, model unknown serialNr JEQ0xxxxxx
</pre>

=== Funktion als Treppenlichtschalter ===
Um dafür zu sorgen, dass z.B. ein durch den HM-LC-Sw1PBU-FM eingeschaltetes Licht automatisch von FHEM nach 10 Minuten ausgeschaltet wird, kann folgende Definition verwendet werden:
:<code>define Beleuchtung_an notify Beleuchtung:on* define Beleuchtung_aus at +00:10:00 set Beleuchtung off </code>
Das Licht kann auch direkt über den Schalter nach 10 Minuten ausgeschaltet werden. Dies hat den Vorteil, dass die Funktion auch ohne FHEM funktioniert und keinen Funkverkehr verursacht. Wert ist in Sekunden also 60*10 für 10 Minuten. Es gibt zwei Schaltoperationen long press (lg) und short press (sh), short press ist ein kurzes antippen, long press ist den Schalter für ca. 1 Sekunde oder mehr gedrückt halten.
set <device> regSet shOnTime 600 self01
set <device> regSet lgOnTime 600 self01
set <device> regSet shOnTime 600 self02
set <device> regSet lgOnTime 600 self02

=== Workaround um den Taster in FHEM zu nutzen ===
Man kann den Taster in der Originalfirmware nicht mit anderen Geräten peeren. Allerdings kann man mit folgendem Workaround den Taster in FHEM nutzen. Das hat jedoch eine Verzögerung zwischen drei und acht Sekunden zur Folge. Dabei ist es trotzdem möglich, den Aktor per FHEM oder gepeertem Gerät weiter zu steuern. Der Taster beeinflusst den Aktor nicht mehr. Das ganze funktioniert, weil der HM-LC-Sw1PBU-FM bei jedem Tastendruck das reading für state aktualisiert, auch wenn sich der Wert nicht ändert.

Zuerst setzt man ein event auf event-on-change-reading:

attr HM-LC-Sw1PBU-FM event-on-change-reading state
attr HM-LC-Sw1PBU-FM event-on-update-reading state

Weiterhin wird der Schalter deaktiviert (hier nur für kurzen Tastendruck; mit lgSwJtXXX wird dieser Effekt auch für den langen Tastendruck erzielt):
set HM-LC-Sw1PBU-FM regSet intKeyVisib visib
set HM-LC-Sw1PBU-FM getConfig
set HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self01
set HM-LC-Sw1PBU-FM regSet prep shSwJtOn on self01
set HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self02
set HM-LC-Sw1PBU-FM regSet exec shSwJtOn on self02

Nun setzt man einen Notify auf das Reading:
:<code>define HM-LC-Sw1PBU-FM-TasterPressed notify HM-LC-Sw1PBU-FM {set YourOtherDevice toggle}</code>

=== Alternative Firmware ===
Um die beiden Taster als Remote und den Aktor getrennt zu nutzen gibt es alternative Firmware, deren Funktion und Benutzung auf der Seite [[HM-LC-Sw1PBU-FM Alternative Firmware]] im Detail beschrieben ist.

=== Schalter immer toggeln lassen ===
Im Werkszustand schaltet die Wippe bei Druck auf der einen Seite ein, auf der anderen Seite aus. Möchte man, dass bei jedem Tastendruck einfach der Zustand geändert wird, kann man das wie folgt erreichen (unten nur für den kurzen Tastendruck dargestellt):
set HM-LC-Sw1PBU-FM regSet intKeyVisib visib
set HM-LC-Sw1PBU-FM getConfig
set HM-LC-Sw1PBU-FM regSet shActionType jmpToTarget self01
set HM-LC-Sw1PBU-FM regSet shSwJtOn dlyOff self01
set HM-LC-Sw1PBU-FM regSet shSwJtOff dlyOn self01
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOn on self01
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOff off self01
set HM-LC-Sw1PBU-FM regSet shActionType jmpToTarget self02
set HM-LC-Sw1PBU-FM regSet shSwJtOn dlyOff self02
set HM-LC-Sw1PBU-FM regSet shSwJtOff dlyOn self02
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOn on self02
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOff off self02

Um den Werkszustand bezüglich Schaltwippe wiederherzustellen (eine Seite schaltet aus, die andere wieder ein) entsprechen folgende Einstellungen dem Werkszustand:
set <device> regSet shSwJtOn dlyOff self01
set <device> regSet shSwJtOff off self01
set <device> regSet shSwJtDlyOn off self01
set <device> regSet shSwJtDlyOff off self01
set <device> regSet shSwJtOn on self02
set <device> regSet shSwJtOff dlyOn self02
set <device> regSet shSwJtDlyOn on self02
set <device> regSet shSwJtDlyOff on self02

=== on-for-timer Ersatz ===
Der HM-LC-Sw1PBU-FM kennt kein <code>set on-for-timer</code>. Um den HM-LC-Sw1PBU-FM trotzdem für einige Zeit anschalten zu können (z. B. wenn ein Fensteröffner dranhängt und das Fenster nur für eine gewisse Zeit geöffnet werden soll), muss ein Button der vccu mit dem HM-LC-Sw1PBU-FM gepeered werden:
set vccu_Btn4 peerChan 0 HM-LC-Sw1PBU-FM dual set

Danach wären (in diesem Fall mit vccu_Btn4) die virtuellen Buttons 4 und 5 mit dem HM-LC-Sw1PBU-FM gepeered. Das Fenster könnte dann über <code>set vccu_Btn4 press short</code> für die vorher über <code>set HM-LC-Sw1PBU-FM regSet shOnTime [Dauer] vccu_Btn4</code> die Öffnungszeit eingestellt werden kann.

== Links ==
* Anleitung (PDF {{DocLink|elv|/Assets/Produkte/10/1030/103029/Downloads/103029_FunkSchaltaktor_um.pdf}})
* Produktwebseite bei [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=37991 ELV]
* [[HM-LC-Sw1PBU-FM Alternative_Firmware|Alternative Firmware]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Empfänger)]]

Verkehrslage

2016-07-25T13:42:00Z

Reibuehl: Fehlerbehebung nach Meldung im Forum

Hier wird ein Device erstellt um sich die [[Verkehrslage]] einer bestimmten Strecke anzeigen zu lassen. Das ganze beruht auf dem Modul [[HTTPMOD]].

== Zielsetzung ==
Ziel ist es, dass ein Dummy die aktuelle Verkehrslage für einen bestimmten Weg anzeigt und sich regelmäßig aktualisiert.

== Vorraussetzungen ==
Benötigt wird das Modul [[HTTPMOD]], welches standardmäßig installiert ist. Weiterhin wird ein Google Account benötigt und ein API Key um auf die Daten der Google Verkehrslage zuzugreifen.

== API Key von Google beziehen ==
Der Google API Key ist ein Schlüssel, welcher uns berechtigt Daten von Google zu erhalten. Google hat verschiedene Programme, welche über eine API Schnittstelle zur Verfügung gestellt werden. Damit nicht jeder einfach auf diese Daten zugreifen kann, wird der Key benötigt. Um diesen zu bekommen müsst ihr als aller erstes einen Google Account erstellen auf www.google.de

Sobald ihr dies habt, müssen wir in die Developer Console. Grund ist, dass der Zugriff auf die Daten eigentlich für Entwickler ist. Dorthin gelang ihr über diesen [https://console.developers.google.com/start?hl=de Link].

Als nächstes müsst ihr oben Links auf "Google APIs verwenden" klicken und ein neues Projekt erstellen, wenn ihr noch keins habt.

Jetzt in der Übersicht beim Reiter "Google APIs" unter Google Maps API "Google Maps Distance Matrix API" auswählen und dort auf den blauen Button "Enable" klicken.

Unter dem Reiter "Nutzung" könnt ihr später die Häufigkeit eurer Zugriffe anzeigen lassen. Unter dem Reiter "Kontingente" seht ihr, wie viele Zugriffe ihr an diesem Tag noch tätigen könnt. Insgesamt sind 2500 Zugriffe pro Tag erlaubt. Das sind etwa 1,7 Zugriffe pro Minute. So viele sollte man eigentlich nicht brauchen.

Auf der linken Seite unter "Zugangsdaten" kann man sich nun auch seinen Key anzeigen lassen. Diesen werden wir später für die Zugriffe benötigen.

== Link für das Modul erstellen ==

<pre>https://maps.googleapis.com/maps/api/distancematrix/json?origins=ORT,STRASSE+NR&destinations=ORT,STRASSE+NR&mode=driving&language=de-DE&departure_time=now&key=APIKEY</pre>

Den Link müssen wir mit unseren eigenen Angaben ergänzen. Starten wir zB in Frankfurt an der Friedberger Straße 291 und wollen nach Gießen in die Straße Schiffenberger Weg 115 sieht unser Link wie folgt aus:

<pre>https://maps.googleapis.com/maps/api/distancematrix/json?origins=Frankfurt,Friedberger%20Stra%C3%9Fe%20291&destinations=Gie%C3%9Fen,%20Schiffenberger%20Weg%20115&mode=driving&language=de-DE&departure_time=now&key=APIKEY</pre>

Es empfiehlt sich den Link einmal in die Browserzeile einzugeben. Dann muss auch nicht auf Leerzeichen geachtet werden und Google formatiert ihn uns automatisch, wie wir ihn brauchen. Übrigens seht ihr dann auch, wie die Seite aussieht, auf welche wir später mit dem HTTPMOD Modul zugreifen werden.

== HTTPMOD Einrichtung ==

=== Definieren des Device ===
Wenn wir nun unseren Google API Key und den Link haben, müssen wir ein neues Device mittels des [[HTTPMOD]] Moduls anlegen. In unserem Beispiel werden wir es wie folgt nennen: Verkehr.FFM.GI Verkehr für die Übersicht, FFM, weil wir ins Frankfurt am Main starten werden und GI, weil wir in Gießen enden.

Wir geben also folgendes in unsere Kommandozeile ein:
<pre>define Verkehr.FFM.GI HTTPMOD Link 3600</pre>
in unserem Beispiel also:
<pre>define Verkehr.FFM.GI HTTPMOD https://maps.googleapis.com/maps/api/distancematrix/json?origins=Frankfurt,Friedberger%20Stra%C3%9Fe%20291&destinations=Gie%C3%9Fen,%20Schiffenberger%20Weg%20115&mode=driving&language=de-DE&departure_time=now&key=APIKEY 3600</pre>

Die Zahl am Ende bestimmt die Häufigkeit der Abfrage in Sekunden. In unserem Fall also einmal die Stunde.

=== Anlegen der Attribute ===
Die benötigten Daten werden nun über die Attribut readingXXName und readingXXRegex abgefragt.

readingXXName: Hiermit geben wir dem späteren Reading einen Namen.

readingXXRegex: Hier wird festgelegt, welcher Teil des Textes "herausgeschnitten" werden soll.

XX: Wird durch Zahlen ersetzt, damit man eine Übersicht hat.

Als aller Erstes müssen wir uns unsere eigenen Attribute vorbereiten. Dies machen wir mit dem attr userattr wie folgt:

==== UserReadings Attribut ====
Hier definieren wir die später benötigte Attribute:
<pre>attr Verkehr.FFM.GI userattr reading01Name reading01Regex reading02Name reading02Regex reading03Name reading03Regex reading04Name reading04Regex reading05Name reading05Regex </pre>

Mehr zu den Attributen unter [[HTTPMOD]].

Legen wir nun unsere weiteren Attribut an:

==== Dauer der Reise ====
Die Dauer der Reise greifen wir mit den Attributen:
<pre>attr Verkehr.FFM.GI reading01Name duration
attr Verkehr.FFM.GI reading01Regex "duration"\s*:\s*{\s*["\w\s:,]+"value"\s*:\s*(\d+)\s*} </pre>

Unser Reading wird später "duration" heißen. Darin wird die Dauer der Reise in Sekunden angegeben.

==== Dauer der Reise mit aktuellem Verkehr ====
Die Dauer der Reise mit Verkehr greifen wir mit den Attributen:
<pre>attr Verkehr.FFM.GI reading02Name duration_in_traffic
attr Verkehr.FFM.GI reading02Regex "duration_in_traffic"\s*:\s*{\s*["\w\s:,]+"value"\s*:\s*(\d+)\s*} </pre>

Unser Reading wird später "duration" heißen. Darin wird die Dauer der Reise in Sekunden angegeben.

==== Entfernung ====
Die Entfernung greifen wir mit den Attributen:
<pre>attr Verkehr.FFM.GI reading03Name distance
attr Verkehr.FFM.GI reading03Regex "distance"\s*:\s*{\s*["\w\s:,]+"value"\s*:\s*(\d+)\s*} </pre>

Unser Reading wird später "distance" heißen und uns die Entfernung angeben.

==== Zielort ====
Den Zielort greifen wir mit den Attributen:
<pre>attr Verkehr.FFM.GI reading04Name destination_addresses
attr Verkehr.FFM.GI reading04Regex "destination_addresses"\s*:\s*\[\s*"([\w\s.,-:üöäß(\)]+)"\s*\] </pre>

Unser Reading wird später "destination_addresses" heißen und uns den Zielort angeben.

==== Startort ====
Den Startort greifen wir mit den Attributen:
<pre>attr Verkehr.FFM.GI reading05Name origin_addresses
attr Verkehr.FFM.GI reading05Regex "origin_addresses"\s*:\s*\[\s*"([\w\s.,-:üöäß(\)]+)"\s*\] </pre>

Unser Reading wird später "origin_addresses" heißen und uns den Zielort angeben.

==== Berechnung der Werte für die spätere Anzeige ====
Damit die Werte später User freundlich angezeigt werden, lassen wir sie von FHEM berechnen:
<pre>attr Verkehr.FFM.GI userReadings duration_hr {strftime "%H:%M", gmtime( int( ReadingsVal("$name","duration",0) /60+0.5)*60 );}, duration_in_traffic_hr {strftime "%H:%M", gmtime( int( ReadingsVal("$name","duration_in_traffic",0) /60+0.5)*60 );}, distance_hr {int( ReadingsVal("$name","distance",0) /1000+0.5);}, duration_diff {int((ReadingsVal("$name","duration_in_traffic",0)-ReadingsVal("$name","duration",0))/60+0.5);}, duration_diff_hr {my $diff=int((ReadingsVal("$name","duration_in_traffic",0)-ReadingsVal("$name","duration",0))/60+0.5); return "+".$diff if ($diff>0); return "+0";} </pre>

==== State Anzeige ====
Uns als letztes noch, wie wir das ganze in State angezeigt bekommen möchten:
<pre>attr Verkehr.FFM.GI stateFormat duration_hr duration_diff_hr Min. (distance_hr km) </pre>

== Fertig ==
Fertig ist das Device, welches uns nun unseren Weg anzeigt. Natürlich könnt ihr die einzelnen Berechnungen und auch die State Anzeige für euch selbst anpassen und entsprechend ändern.

== Anmerkung ==
Zwei Dinge möchte ich anmerken:

1. Das ganze beruht auf {{Link2Forum|Topic=20151|Message=363109|LinkText=diesem}} und {{Link2Forum|Topic=20151|Message=365322|LinkText=diesem}} Beitrag.

2. Sobald Google die Ausgabe der Website verändert, wird es vermutlich nicht mehr funktionieren. Wie ihr dem Thema im Forum entnehmen könnt, ist dies schon vorgekommen. Daher nicht wundern, sondern im Forum schauen, ob es schon eine Veränderung gibt oder selbst die Readings anpassen.

[[Kategorie:Code_Snippets]]

HM-Sec-WDS Funk-Wassermelder

2016-06-09T13:30:20Z

Reibuehl: Link zur Bedienungsanleitung korrigiert

[[Datei:HM-Sec-WDS-Funk-Wassermelder1.png|thumb|right|HM-Sec-WDS Funk-Wassermelder]]

Wassermelder, der feuchte und nasse Untergründe detektieren kann.

== Features ==
[[Datei:HM-Sec-WDS-Funk-Wassermelder2.png|thumb|right|Kontakte des Wassermelders]]

Der Wassermelder wird an einer HomeMatic Anlage betrieben, z.B. an einem [[HMLAN Konfigurator]].

Gemeldet werden drei verschiedene Stati: "dry", "damp" und "wet".

Den Status "damp" (feucht) nimmt das System an, wenn zwei der äußeren Kontakte (rot) über eine Wasserfläche Kontakt haben.
Der Status "Wet" (nass) wird angenommen, wenn einer der äußeren Kontakte über eine Wasserfläche mit dem inneren, ca. 1,5 mm
höher liegenden Kontakt (blau) hat. Unbedingt Seite 5 der Anleitung beachten.

Ca. alle 24 Stunden sendet das System eine "battery" Meldung.

== Hinweise zum Betrieb mit FHEM ==
=== Auszug aus der fhem.cfg ===
Beispielhafter Auszug aus der [[Konfiguration]], die durch [[autocreate]] angelegt wurde:
<nowiki>define CUL_HM_HM_SEC_WDS_xxxxxx CUL_HM xxxxxx
attr CUL_HM_HM_SEC_WDS_xxxxxx .devInfo yyyyyy
attr CUL_HM_HM_SEC_WDS_xxxxxx .stc 80
attr CUL_HM_HM_SEC_WDS_xxxxxx actCycle 028:00
attr CUL_HM_HM_SEC_WDS_xxxxxx actStatus alive
attr CUL_HM_HM_SEC_WDS_xxxxxx alias WassermelderHeizung
attr CUL_HM_HM_SEC_WDS_xxxxxx expert 2_full
attr CUL_HM_HM_SEC_WDS_xxxxxx firmware 1.1
attr CUL_HM_HM_SEC_WDS_xxxxxx model HM-SEC-WDS
attr CUL_HM_HM_SEC_WDS_xxxxxx peerIDs
attr CUL_HM_HM_SEC_WDS_xxxxxx room 8-Wasseralarm
attr CUL_HM_HM_SEC_WDS_xxxxxx serialNr xyz
attr CUL_HM_HM_SEC_WDS_xxxxxx subType threeStateSensor
#Melde alle Kontaktstatusänderungen
define Wasseralarm_Contact notify CUL_HM_HM_SEC_WDS_xxxxxx:contact.* { sendmail('local@@mail.tld','%-@','%-@') }
attr Wasseralarm_Contact room 8-Wasseralarm
#Melde Batteriewarnung
define Wasseralarm_Battery notify CUL_HM_HM_SEC_WDS_xxxxxx:battery.* { sendmail('local@@mail.tld','%-@','%-@') }
attr Wasseralarm_Battery room 8-Wasseralarm
#Melde nur "wet" Meldung
define Wasseralarm_Contact_Wet notify CUL_HM_HM_SEC_WDS_xxxxxx:contact:.wet.* { sendmail('local@@mail.tld','WET-ONLY-ALARM-%-@','%-@') }
attr Wasseralarm_Contact_Wet room 8-Wasseralarm
define CUL_HM_HM_SEC_WDS_xxxxxx FileLog /usr/local/FHEM/var/log/CUL_HM_HM_SEC_WDS_xxxxxx-%Y-%m.log CUL_HM_HM_SEC_WDS_xxxxxx
attr CUL_HM_HM_SEC_WDS_xxxxxx logtype wateralert:Plot,text
attr CUL_HM_HM_SEC_WDS_xxxxxx room 8-Wasseralarm
define CUL_HM_HM_SEC_WDS_xxxxxx weblink fileplot FileLog_CUL_HM_HM_SEC_WDS_xxxxxx:wateralert:CURRENT
attr CUL_HM_HM_SEC_WDS_xxxxxx room 8-Wasseralarm,97-Graphen</nowiki>

=== Plots / Grafiken ===
Beispiel für einen [[Plots_erzeugen|Plot]]:
<nowiki>set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics ("dry" 0, "damp" 1, "wet" 2)
set y2tics ("dry" 0, "damp" 1, "wet" 2)
set yrange [-0.1:2.1]
set y2range [-0.1:2.1]
set ylabel "Status"
set y2label "Status"
#FileLog 3::0:$fld[2]=~"damp"?1:$fld[2]=~"wet"?2:0
plot "< awk '{print $1, $3~/damp/? 1 : $3~/wet/? 2 : 0; }' <IN>"\
using 1:2 notitle with steps</nowiki>

=== Log-Auszug ===
<nowiki>2013-03-07_21:47:28 CUL_HM_HM_SEC_WDS_xxxxxx Activity:: alive
2013-03-08_09:56:20 CUL_HM_HM_SEC_WDS_xxxxxx alive: yes
2013-03-08_09:56:20 CUL_HM_HM_SEC_WDS_xxxxxx battery: ok
2013-03-08_09:56:20 CUL_HM_HM_SEC_WDS_xxxxxx dry
2013-03-08_09:56:20 CUL_HM_HM_SEC_WDS_xxxxxx contact: dry (to HMLAN)
2013-03-08_17:42:29 CUL_HM_HM_SEC_WDS_xxxxxx wet
2013-03-08_17:42:29 CUL_HM_HM_SEC_WDS_xxxxxx contact: wet (to HMLAN)
2013-03-08_17:42:53 CUL_HM_HM_SEC_WDS_xxxxxx dry
2013-03-08_17:42:53 CUL_HM_HM_SEC_WDS_xxxxxx contact: dry (to HMLAN)
2013-03-08_17:43:10 CUL_HM_HM_SEC_WDS_xxxxxx damp
2013-03-08_17:43:10 CUL_HM_HM_SEC_WDS_xxxxxx contact: damp (to HMLAN)
2013-03-08_17:43:16 CUL_HM_HM_SEC_WDS_xxxxxx dry
2013-03-08_17:43:16 CUL_HM_HM_SEC_WDS_xxxxxx contact: dry (to HMLAN)</nowiki>

=== Automatische E-Mail bei Feuchte/Nässe ===
Mittels folgendem Eintrag in der ''fhem.cfg'' wird bei jedem Statuswechsel des HM-Sec-WDS auf ''damp'' bzw. ''wet'' von FHEM eine E-Mail an eine bestimmte E-Mail-Adresse gesendet und ein entsprechender Eintrag in der ''fhem.log'' erzeugt:

<nowiki>define n_wasser_chk notify CUL_HM_HM_SEC_WDS_xxxxxx:contact.* { \
if("$EVENT" !~ m/dry/) {\
{fhemMail('Max.Mustermann@Mustermann.de','FHEM Wasseralarm',"$NAME $EVENT")};;\
Log 3, "$NAME: Wassermeldung $EVENT";;\
}\
}</nowiki>
Das Beispiel setzt eine [[99 myUtils anlegen|99_myUtils.pm]] mit einer funktionierenden, selbst erstellten Unterroutine fhemMail() für den [[E-Mail_senden|Mailversand]] voraus.

Die Mail, die erzeugt wird, hat den Inhalt:

<nowiki>An: Max.Mustermann@Mustermann.de
Betreff: FHEM Wasseralarm
Mail-Text: CUL_HM_HM_SEC_WDS_xxxxxx contact: wet (to HMLAN1)</nowiki>
'''Hinweis:''' Man kann zwar nur auf '':contact.*'' filtern, aber dann kommt z.B. auch bei Statusänderungen von vorhandenen HM-Sec-SC eine Mail. Bei mehreren HM-Sec-WDS muss der Filter entsprechend angepasst werden, um mit einem [[notify]] auszukommen.

== Links ==
Anleitung [http://files.elv.de/service/manuals/Homematic/83459_HM_Sec_WDS_D_v1_0_UM.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Wassermelder]]

Raspberry Pi: GPIOs schalten

2016-03-01T20:10:56Z

Reibuehl: /* Dummy-Schalter */ Umstellung auf $EVENT

Mit FHEM lassen sich auch die '''GPIOs''' des [[Raspberry Pi]] steuern. Generell gibt es einige Möglichkeiten, eine entsprechende Steuerung zu verwirklichen. Als Informationsquelle empfiehlt sich hier die [http://elinux.org/RPi_Low-level_peripherals Low-Level Peripherals Seite des Embedded Linux Wiki]

== Bash Script ==
Zum schalten der GPIOs via Bash kann folgendes Script (fhem-gpio.sh) verwendet werden:

<nowiki>#!/bin/bash
PORT=$1;
if ! [ -d /sys/class/gpio/gpio$PORT ]
then
echo "$PORT" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio$PORT/direction
fi
STATE=$2;
if [ $STATE -ge 1 ]
then
STATE=1
fi
echo "$STATE" > /sys/class/gpio/gpio$PORT/value</nowiki>
Der Aufruf des Scripts erfolgt dann mit Angabe der Pinnummer sowie des Zustands des Pins, z. B.:

<nowiki>fhem-gpio.sh 17 1 # Pin 17 in High-Zustand versetzen
fhem-gpio.sh 17 0 # Pin 17 in Low-Zustand versetzen</nowiki>
Wichtig: Das Script muss leider unter root (z.B. per sudo) aufgerufen werden.
Der Einfachheithalber kann das Script unter /usr/sbin kopiert werden.

== Perl-Modul ==
Das Modul '''RPI_GPIO''' für den Zugriff auf die GPIO Pins des Raspberry wird bereits mit FHEM mitgeliefert.
Es setzt die [http://wiringpi.com/download-and-install/ WiringPi] Bibliothek voraus.
Installationsschritte sind in der Commandref zu finden. [http://forum.fhem.de/index.php/topic,16519.0.html Diskussions Thread im Forum]

In Arbeit: Perl-Modul basierend auf [http://search.cpan.org/~mikem/Device-BCM2835-1.0/lib/Device/BCM2835.pm BCM2835-Modul]

'''Wichtig'''

Der Benutzer „fhem“ muss der Gruppe „gpio“ hinzugefügt werden, damit FHEM später auch Zugriff auf die GPIO Ports hat.

<code>sudo adduser fhem gpio</code>

== Dummy-Schalter ==
Über einen Dummy-Schalter kann das Bash-Script dann getriggert werden.

Im Fall von [[FS20 Allgemein|FS20]] sähe eine entsprechende Schalter-Definition beispielsweise so aus:

<nowiki>define gpio_17 FS20 [Hauscode] [Devicecode]
attr gpio_17 dummy 1
define act_on_gpio_17 notify gpio_17 {\
if ("$EVENT" ne "off") {\
system("sudo fhem-gpio.sh 17 1 &")\
} else {\
system("sudo fhem-gpio.sh 17 0 &")\
}\
}</nowiki>

== Externe Links ==
* [http://elinux.org/RPi_Low-level_peripherals http://elinux.org/RPi_Low-level_peripherals]
* [http://search.cpan.org/~mikem/Device-BCM2835-1.0/lib/Device/BCM2835.pm http://search.cpan.org/~mikem/Device-BCM2835-1.0/lib/Device/BCM2835.pm]
* [http://wiringpi.com/download-and-install/ http://wiringpi.com/download-and-install/]

{{SORTIERUNG:GPIOs schalten}}
[[Kategorie:Raspberry Pi]]

Weekprofile

2016-01-14T13:55:21Z

Reibuehl: /* Eingabeformat für Wochenprofile */

== Allgemeines ==

Das Modul 98_weekprofile.pm stellt Funktionen zur Verwaltung von Wochenprofilen für Heizkörperthermostate zur Verfügung. Momentan werden die folgenden Systeme unterstützt:

* [[MAX]]
* [[HomeMatic]]

Momentan ist es möglich, verschiedene Wochenprofile anzulegen, zu kopieren, zu ändern und zu löschen. Außerdem können die erstellten Profile den entsprechenden Devices zugewiesen werden. Ein Import bestehender Profile aus den Devices ist momentan noch nicht möglich.

== Eingabeformat für Wochenprofile ==

Die Wochenprofile werden mit dem Befehl <code>set <name> profile_data <profilename> <json data></code> angelegt. Die eigentlichen Daten liegen dabei in einer [https://de.wikipedia.org/wiki/JavaScript_Object_Notation JSON] Datenstruktur, die wie folgt aussieht:

<pre>{
"Sun": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Sat": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Thu": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Fri": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Tue": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Wed": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Mon": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
}
}
</pre>

Es handelt sich dabei um eine unsortierte Liste von "Tages-Objekten", die wiederum eine unsortierte Liste von Schlüssel - Werte-Liste Paaren enthält. Die beiden verwendeten Schlüssel "time" und "temp" für Zeit und Temperatur verweisen jeweils auf eine sortierte Liste mit Werten.

Der Schlüssel "time" enthält die Liste die gewünschten Zeitpunkte, zu denen ein Temperaturwechsel stattfinden soll. Die Zeitangaben müssen im Format "hh:mm" angegeben werden. Falls für den ganzen Tag nur eine Temperatur verwendet werden soll, so ist als Zeitpunkt "24:00" anzugeben.

Der Schlüssel "temp" enthält die Temperaturen, die zu den in "time" hinterlegten Schaltzeitpunkten eingestellt werden sollen. Dabei entspricht die Reihenfolge der Temperaturen der Reihenfolge der Zeitpunkte in "time".

Zur Übergabe an FHEM sollte die JSON Struktur um sämtliche Formatierungen (Zeilenumbrüche, Tabs, überflüssige Leerzeichen) bereinigt werden, so dass ein einzeiliger String entsteht. Für das oben angegebene Beispiel würde das dann so aussehen:

<code><nowiki>{"Sun":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Sat":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Thu":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Fri":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Tue":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Wed":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Mon":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]}}</nowiki></code>

Für eine einfache Bearbeitung der JSON Daten empfiehlt sich ein JSON-Editor wie z.B. [http://www.jsoneditoronline.org/].

Weekprofile

2016-01-14T13:50:46Z

Reibuehl: /* Eingabeformat für Wochenprofile */

== Allgemeines ==

Das Modul 98_weekprofile.pm stellt Funktionen zur Verwaltung von Wochenprofilen für Heizkörperthermostate zur Verfügung. Momentan werden die folgenden Systeme unterstützt:

* [[MAX]]
* [[HomeMatic]]

Momentan ist es möglich, verschiedene Wochenprofile anzulegen, zu kopieren, zu ändern und zu löschen. Außerdem können die erstellten Profile den entsprechenden Devices zugewiesen werden. Ein Import bestehender Profile aus den Devices ist momentan noch nicht möglich.

== Eingabeformat für Wochenprofile ==

Die Wochenprofile werden mit dem Befehl <code>set <name> profile_data <profilename> <json data></code> angelegt. Die eigentlichen Daten liegen dabei in einer [https://de.wikipedia.org/wiki/JavaScript_Object_Notation JSON] Datenstruktur, die wie folgt aussieht:

<code><pre>{
"Sun": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Sat": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Thu": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Fri": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Tue": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Wed": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Mon": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
}
}
</pre></code>

Es handelt sich dabei um eine unsortierte Liste von "Tages-Objekten", die wiederum eine unsortierte Liste von Schlüssel - Werte-Liste Paaren enthält. Die beiden verwendeten Schlüssel "time" und "temp" für Zeit und Temperatur verweisen jeweils auf eine sortierte Liste mit Werten.

Der Schlüssel "time" enthält die Liste die gewünschten Zeitpunkte, zu denen ein Temperaturwechsel stattfinden soll. Die Zeitangaben müssen im Format "hh:mm" angegeben werden. Falls für den ganzen Tag nur eine Temperatur verwendet werden soll, so ist als Zeitpunkt "24:00" anzugeben.

Der Schlüssel "temp" enthält die Temperaturen, die zu den in "time" hinterlegten Schaltzeitpunkten eingestellt werden sollen. Dabei entspricht die Reihenfolge der Temperaturen der Reihenfolge der Zeitpunkte in "time".

Zur Übergabe an FHEM sollte die JSON Struktur um sämtliche Formatierungen (Zeilenumbrüche, Tabs, überflüssige Leerzeichen) bereinigt werden, so dass ein einzeiliger String entsteht. Für das oben angegebene Beispiel würde das dann so aussehen:

<code>{<nowiki>{"Sun":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Sat":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Thu":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Fri":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Tue":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Wed":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Mon":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]}}</nowiki></code>

Für eine einfache Bearbeitung der JSON Daten empfiehlt sich ein JSON-Editor wie z.B. [http://www.jsoneditoronline.org/].

Weekprofile

2016-01-14T13:34:12Z

Reibuehl: Beschreibung der JSON Syntax für weekprofile

== Allgemeines ==

Das Modul 98_weekprofile.pm stellt Funktionen zur Verwaltung von Wochenprofilen für Heizkörperthermostate zur Verfügung. Momentan werden die folgenden Systeme unterstützt:

* [[MAX]]
* [[HomeMatic]]

Momentan ist es möglich, verschiedene Wochenprofile anzulegen, zu kopieren, zu ändern und zu löschen. Außerdem können die erstellten Profile den entsprechenden Devices zugewiesen werden. Ein Import bestehender Profile aus den Devices ist momentan noch nicht möglich.

== Eingabeformat für Wochenprofile ==

Die Wochenprofile werden mit dem Befehl <code>set <name> profile_data <profilename> <json data></code> angelegt. Die eigentlichen Daten liegen dabei in einer [https://de.wikipedia.org/wiki/JavaScript_Object_Notation JSON] Datenstruktur, die wie folgt aussieht:

<code><pre>{
"Sun": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Sat": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Thu": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Fri": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Tue": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Wed": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
},
"Mon": {
"time": [
"06:00",
"22:00",
"24:00"
],
"temp": [
"20.0",
"22.0",
"20.0"
]
}
}
</pre></code>

Es handelt sich dabei um eine unsortierte Liste von "Tages-Objekten", die wiederum eine unsortierte Liste von Schlüssel - Werte-Liste Paaren enthält. Die beiden verwendeten Schlüssel "time" und "temp" für Zeit und Temperatur verweisen jeweils auf eine sortierte Liste mit Werten.

Der Schlüssel "time" enthält die Liste die gewünschten Zeitpunkte, zu denen ein Temperaturwechsel stattfinden soll. Die Zeitangaben müssen im Format "hh:mm" angegeben werden. Falls für den ganzen Tag nur eine Temperatur verwendet werden soll, so ist als Zeitpunkt "24:00" anzugeben.

Der Schlüssel "temp" enthält die Temperaturen, die zu den in "time" hinterlegten Schaltzeitpunkten eingestellt werden sollen. Dabei entspricht die Reihenfolge der Temperaturen der Reihenfolge der Zeitpunkte in "time".

Zur Übergabe an FHEM sollte die JSON Struktur um sämtliche Formatierungen (Zeilenumbrüche, Tabs, überflüssige Leerzeichen) bereinigt werden, so dass ein einzeiliger String entsteht. Für das oben angegebene Beispiel würde das dann so aussehen:

<code>{<nowiki>{"Sun":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Sat":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Thu":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Fri":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Tue":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Wed":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]},"Mon":{"time":["06:00","22:00","24:00"],"temp":["20.0","22.0","20.0"]}}</nowiki></code>

Systemübersicht

2016-01-13T13:28:29Z

Reibuehl: /* Protokolle */ MAX! Frequenz angepasst auf Wert von Hersteller Webseite

Ein Fhem '''System''' besteht im Prinzip aus den in der nachfolgenden '''Übersicht''' aufgeführten Bestandteilen.
[[Datei:Systemübersicht.png]]

<div style="float: right;">__TOC__</div>

== Server ==
Bei der Komponente '''Server''' muss unterschieden werden zwischen dem eigentlichen '''Fhem''' Hausautomations-Server (implementiert in der Perl-Datei fhem.pl) und der Hardware, auf der dieser Server ausgeführt wird.

Als Server '''Hardware''' sind (z. B.) möglich:
* Windows Rechner
* Linux Rechner
* OS X Rechner
* Router (z. B. [[AVM Fritz!Box|FritzBox]])
* Einplatinencomputer, wie [[:Kategorie:Raspberry Pi|Raspberry Pi]], BeagleBone
* DockStar, PogoPlug, etc.
* diverse NAS Systeme wie Buffalo Linkstation, Synology Diskstation
(Diese Aufstellung ist nur eine unvollständige Auswahl; Details zu unterstützten Server Systemen finden sich in der Kategorie [[:Kategorie:Server Hardware|Server Hardware]]).

== Konfiguration ==
Das Hausautomations-System wird definiert über die [[Konfiguration]], die im Regelfall besteht aus der
* reinen Textdatei <code>fhem.cfg</code> (Standard nach der Erstinstallation) oder alternativ einer
* [[configdb|SQL-Datenbank]]

Die Konfiguration enthält Definitionen für die Bestandteile (Geräte) und Funktionen des jeweiligen Hausautomations-Systems. Die verfügbaren Befehle und deren Syntax sind in der Befehlsreferenz ([http://fhem.de/commandref.html commandref]) aufgeführt und beschrieben. Zu einigen Hilfsmodulen gibt es [[:Kategorie:Hilfsmodul|detaillierte Beschreibungen]] mit Beispielen.

== Benutzeroberfläche ==
Der Zugriff auf FHEM erfolgt mittels Webbrowser oder App über die verfügbaren '''[[:Kategorie:FHEM Frontends|Fhem Benutzeroberflächen]]'''.

In den Fhem Server integriert ist ein Webserver ([[PGM2]]), der im Prinzip immer zur Verfügung steht. Abhängig vom benutzten Klienten ist PGM2 über
* <code>serverhostnameoderIP:8083/fhem</code> (Desktop-Darstellung = Port 8083),
* <code>serverhostnameoderIP:8084/fhem</code> (Smartphone-Darstellung = Port 8084) oder
* <code>serverhostnameoderIP:8085/fhem</code> (Tablet-Darstellung = Port 8085)
erreichbar.

Eine Auswahl der Benutzeroberflächen:
* PGM2 - das Standardinterface
* [[FLOORPLAN]]
* [[FHEM Tablet UI]]
* [[SmartVisu]]
* diverse Apps für iOS und Android (Auswahl unter: [[:Kategorie:FHEM Frontends|Fhem Benutzeroberflächen]])

Beispielhafte Screenshots diverser Benutzeroberflächen: http://fhem.de/fhem.html#Screenshots

== Module ==
Die Funktionalität von Fhem kann über '''Module''' erweitert werden. Module können die unterschiedlichsten Aufgaben übernehmen vom Anbinden eines Hardwaresystems
über die Bereitstellung eines Frontends bis zur Automatisierung von Aufgaben. Beispiele für Module:
* 00_CUL.pm - Implementierung der Unterstützung für den [[CUL]]
* 11_FHT.pm - Unterstützung der [[:Kategorie:FHT Components|FHT]] Heizungssteuerung
* 95_FLOORPLAN.pm - Grundriss (oder Ähnliches) als Benutzeroberfläche
* ...

Module können unterteilt werden in
* [[:Kategorie:FhemBefehl|Befehlsmodule]] (FhemBefehle sind teilweise eigenständige Module)
* [[:Kategorie:Hilfsmodul|Hilfsmodule]]
* [[:Kategorie:Gerätemodul|Gerätemodule]]
Die offiziell in Fhem enthaltenen Module sind in der [http://fhem.de/commandref Commandref] beschrieben. Sie werden über den [[Update]]-Befehl von Fhem verteilt und aktualisiert. Voraussetzung für die Aufnahme als offizielles Modul sind Supportwille durch den Entwickler und Dokumentation des Moduls.

Zusätzlich existiert eine Vielzahl von [[:Kategorie:Modul (Inoffiziell)|inoffiziellen Modulen]], die manuell in Fhem installiert werden müssen. Auch die Aktualisierung erfolgt nicht über den Update-Befehl, sondern muss durch den Nutzer selbst erfolgen. Inoffizielle Module sind an den verschiedensten Stellen zu finden:
* [[:Kategorie:Modul (Contrib)|Contrib]]-Verzeichnis im offiziellen Fhem-Sourcecode-SVN [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/]
* Beiträge im Fhem-Forum
* private Homepages

== Interfaces ==
Die Verbindung zu den angeschlossenen '''Geräten''' der Hausautomation wird im Allgemeinen - geräteabhängig - über [[Interface|Interfaces]] (manchmal auch als '''Gateway''' bezeichnet) hergestellt. Das kann z. B. im Falle von [[HomeMatic]] ein [[HMLAN Konfigurator]] sein, ein mittels LAN mit dem Fhem Server verbundenes Gerät, das die Fhem Steuerbefehle in das HomeMatic Funkprotokoll umsetzt - und auch die Funktelegramme der HomeMatic Komponenten an Fhem zurückgibt. Entsprechende Interfaces gibt es auch für andere Funkprotokolle und für die drahtgebundenen Systeme.

Eine (unvollständige) Liste solcher Interfaces (siehe auch [[:Kategorie:Interfaces|Kategorie Interfaces]]):
* [[CUL]] - je nach Einstellung für die Kommunikation mit [[:Kategorie:FS20 Components|FS20]], [[:Kategorie:FHT Components|FHT]] und andere [[SlowRF]] Protokolle, [[MAX|MAX!]] Heizungssteuerung oder [[:Kategorie:HomeMatic Components|HomeMatic]] und, mit Einschränkungen, InterTechno (nur senden)
* [[CUNO]], ähnlich CUL, jedoch nicht per USB sondern per IP angebunden (z.Zt. -Stand Januar 2014 - nicht für HomeMatic empfohlen)
* [[HMLAN Konfigurator|HomeMatic LAN Konfigurations-Adapter]] - HomeMatic
* [[MAX#MAXLAN|MAX! Cube LAN-Gateway]]
* Schnittstellen(karten) für [[:Kategorie:1-Wire|1-Wire]]
* TCM(120/310) zur Anbindung von [[:Kategorie:EnOcean Components|EnOcean]]
* [[Arduino]] mit Firmata über USB oder Netzwerk
* [[panStamp]] als Möglichkeit Arduinos mit diversen Sensor- und I/O- Boards per 868MHz Funk über das SWAP protokoll anzubinden
* [[JeeLink]], ein weiteres USB-Stick Interface (ebenfalls arduino basiert) für diverse 433MHz und 868MHz Komponenten
* [[RFXtrx]] für InterTechno, RSL, ELRO etc., Wetter-Sensoren (Oregon-Scientific, Cresta, La Crosse, TFA, UPM) und andere 433 Mhz Geräte.
* manche Komponenten ([[:Kategorie:IP Components|IP Komponenten]]) können über TCP/IP (LAN) direkt vom Fhem Server aus angesprochen werden; hier ist dann kein weiteres Interface im eigentlichen Sinne erforderlich. Dies gilt auch für diverse Module die Geräte über WEB Dienste des Herstellers anbinden (z. B. Withings, [[netatmo]]).

== Protokolle ==
Der Kommunikation zwischen Interfaces und Geräten liegt jeweils ein bestimmtes Protokoll zugrunde. Unterstützte Protokolle mit ihren Eigenschaften sind in der folgenden Tabelle aufgelistet.


{| class="wikitable sortable"
|+ Übersicht über unterstützte Funkprotokolle
|-
! Name !! rfMode !! Frequenz !! Modulation !! Datenrate !! class="unsortable" | Interfaces !! class="unsortable" | Modul !! class="unsortable" | Geräte (Beispiel) !! class="unsortable" | Bemerkungen
|-
| [[FS20_Allgemein|FS20]] || SlowRF || 868,35MHz || AM || 1kHz || CU*, FHZ || [http://fhem.de/commandref.html#FS20 FS20] || - || -
|-
| FHT || SlowRF || 868,35MHz || AM || 1kHz || CU*, FHZ || [http://fhem.de/commandref.html#CUL_FHTTK FHTTK], [http://fhem.de/commandref.html#FHT FHT] || Heizungsregelung || -
|-
| S300 || SlowRF || 868,35MHz || AM || 1kHz || CU*, FHZ || [http://fhem.de/commandref.html#CUL_WS CUL_WS] || Temperatur-/Feuchtesensoren || -
|-
| HMS || SlowRF || 868,35MHz || AM || 1kHz || CU*O, FHZ || - || ?? || -
|-
| EM || SlowRF || 868,35MHz || AM || 1kHz || CU*, FHZ || [http://fhem.de/commandref.html#CUL_EM CUL_EM] || Energiemonitore (Strom, Gas) || -
|-
| [[HomeMatic ]]|| HomeMatic || 868,3MHz || FM || 20kHz || CU*, [[HM-CFG-LAN_LAN_Konfigurations-Adapter|HMLan]], [[HM-CFG-USB_USB_Konfigurations-Adapter|HMUsb]] || [http://fhem.de/commandref.html#CUL_HM CUL_HM] || [[:Kategorie:HomeMatic_Components|diverse]] || -
|-
| [[MAX|MAX!]] || MAX || 868,3MHz || FM || 20kHz || CU*, [[MAX#MAXLAN|MAXLAN]] || [http://fhem.de/commandref_DE.html#MAX MAX] || [[:Kategorie:MAX|Wandthermostat, Heizkörperthermostate, Fensterkontakt, Zwischenstecker]] || -
|-
| IT || - || 433MHz || AM? || 1kHz || CU*433, || - || - || -
|-
| FRM || - || ?? || ?? || ?? || ?? || - || ?? || -
|-
| SWAP || - || 868 (433/915) MHz || GFSK || 38.3835 Kbps || panStamp (+panStick) || [http://fhem.de/commandref.html#SWAP SWAP] || RGB LED Driver, diverse Sensoren und Aktoren || -
|-
| [[:Kategorie:EnOcean Components|EnOcean]] || - || 315 / 868 / 902 / 928MHz || ASK || 125 kbit/s || [http://fhem.de/commandref.html#TCM TCM] || [http://fhem.de/commandref.html#EnOcean EnOcean] || Batterielose Funksensoren, diverse Aktoren || -
|-
| PCA || - || 868,35MHz || ?? || ?? || [[JeeLink]] || [http://fhem.de/commandref.html#PCA301 PCA301] || [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]] || -
|-
| LaCrosse || - || 868,35MHz || ?? || ?? || [[JeeLink]] || [http://fhem.de/commandref.html#LaCrosse LaCrosse] || LaCrosse IT+ (Technoline) Sensoren || -
|-
| ZigBee Light Link || - || 2,4 GHz || || || HUE Bridge (RaspBee) || [http://fhem.de/commandref.html#HUEBridge HUEBridge] || Philips HUE und LightLink Lampen (auch Osram LIGHTIFY an der HUE-Bridge)|| [http://www.developers.meethue.com/documentation/how-hue-works]
|-
| [[:Kategorie:Z-Wave Components|Z-Wave]] || - || 868MHz || 2-FSK || 9.600 bit/s oder 40 Kbit/s || [http://fhem.de/commandref.html#ZWDongle ZWDongle] || [http://fhem.de/commandref.html#ZWave ZWave] || - || -
|-
| [[WMBUS]] || WMBus_T, WMBus_S || 868MHz || ?? || 100 kbit/s / 32.768 kbit/s || CU* || [http://fhem.de/commandref.html#WMBUS WMBUS] || Wasseruhren, Wärmezähler, Elektrozähler || -
|-
| colspan="9" | ''Tabelle muss noch vervollständigt werden''
|-
| colspan="2" | '''Legende:'''
| colspan="7" | CU* = CUL, CUN, CUNO /
|}

{| class="wikitable sortable"
|+ Übersicht über drahtgebundene Systeme
|-
! Name !! class="unsortable" | Interfaces (Hardware) !! class="unsortable" | Modul !! class="unsortable" | Geräte (Beispiel) !! class="unsortable" | Bemerkungen
|-
| [[1-Wire]] || [[Interfaces für 1-Wire|diverse]] || [http://fhem.de/commandref.html#OWX OWX] || [[:Kategorie:1-Wire|1-Wire]] || -
|-
| [[EIB_/_KNX|EIB/KNX]] || [http://fhem.de/commandref.html#TUL TUL] || [http://fhem.de/commandref.html#EIB EIB] || [[:Kategorie:EIB/KNX|EIB/KNX]] || -
|-
| [[HomeMatic Wired]] || [[HomeMatic Wired RS485 LAN Gateway|HM485 LAN Gateway]] || [http://fhem.de/commandref.html#HM485_LAN HM485_LAN] || [[:Kategorie:HomeMatic Components|Präfix HMW]] || -
|-
| colspan="5" | ''Tabelle muss noch vervollständigt werden''
|-
| colspan="2" | '''Legende:'''
| colspan="3" | ...
|}

== Komponenten ==
Der eigentliche Zweck eines Hausautomatisierungs-Projekts sind dann letztendlich die '''Geräte''' (Komponenten / Aktoren / [[:Kategorie:Schalter (Empfänger)|Empfänger]]), die automatisch gesteuert werden sollen, bzw. auch Auslöser für Aktionen ([[:Kategorie:Schalter (Sender)|Sender]]) und Lieferant von Datenmaterial ([[:Kategorie:Hardware Typen|Sensoren]]) sind.

Diese Geräte sind, sofern es eine detaillierte Beschreibung dazu gibt, in den jeweiligen Unterseiten der [[:Kategorie:Hardware|Hardwareliste]] aufgeführt.

== Weblinks ==
* [http://www.enocean.com/de/home/ EnOcean] Homepage
* [http://www.elv.de ELV], (Haupt-)Lieferant von FS20, FHT, HomeMatic, MAX!
* [http://www.panstamp.com panStamp], panStamp Hersteller
* [http://jeelabs.com/products/jeelink Jeelabs], JeeLink Hersteller
* [http://www.zigbee.org/ Zigbee] Homepage

[[Kategorie:FHEM]]

Systemübersicht

2016-01-01T12:29:45Z

Reibuehl: /* Protokolle */ HomeMatic Frequenz auf die beim Hersteller angegebenen 868,3 MHz geändert.

Ein Fhem '''System''' besteht im Prinzip aus den in der nachfolgenden '''Übersicht''' aufgeführten Bestandteilen.
[[Datei:Systemübersicht.png]]

<div style="float: right;">__TOC__</div>

== Server ==
Bei der Komponente '''Server''' muss unterschieden werden zwischen dem eigentlichen '''Fhem''' Hausautomations-Server (implementiert in der Perl-Datei fhem.pl) und der Hardware, auf der dieser Server ausgeführt wird.

Als Server '''Hardware''' sind (z. B.) möglich:
* Windows Rechner
* Linux Rechner
* OS X Rechner
* Router (z. B. [[AVM Fritz!Box|FritzBox]])
* Einplatinencomputer, wie [[:Kategorie:Raspberry Pi|Raspberry Pi]], BeagleBone
* DockStar, PogoPlug, etc.
* diverse NAS Systeme wie Buffalo Linkstation, Synology Diskstation
(Diese Aufstellung ist nur eine unvollständige Auswahl; Details zu unterstützten Server Systemen finden sich in der Kategorie [[:Kategorie:Server Hardware|Server Hardware]]).

== Konfiguration ==
Das Hausautomations-System wird definiert über die [[Konfiguration]], die im Regelfall besteht aus der
* reinen Textdatei <code>fhem.cfg</code> (Standard nach der Erstinstallation) oder alternativ einer
* [[configdb|SQL-Datenbank]]

Die Konfiguration enthält Definitionen für die Bestandteile (Geräte) und Funktionen des jeweiligen Hausautomations-Systems. Die verfügbaren Befehle und deren Syntax sind in der Befehlsreferenz ([http://fhem.de/commandref.html commandref]) aufgeführt und beschrieben. Zu einigen Hilfsmodulen gibt es [[:Kategorie:Hilfsmodul|detaillierte Beschreibungen]] mit Beispielen.

== Benutzeroberfläche ==
Der Zugriff auf FHEM erfolgt mittels Webbrowser oder App über die verfügbaren '''[[:Kategorie:FHEM Frontends|Fhem Benutzeroberflächen]]'''.

In den Fhem Server integriert ist ein Webserver ([[PGM2]]), der im Prinzip immer zur Verfügung steht. Abhängig vom benutzten Klienten ist PGM2 über
* <code>serverhostnameoderIP:8083/fhem</code> (Desktop-Darstellung = Port 8083),
* <code>serverhostnameoderIP:8084/fhem</code> (Smartphone-Darstellung = Port 8084) oder
* <code>serverhostnameoderIP:8085/fhem</code> (Tablet-Darstellung = Port 8085)
erreichbar.

Eine Auswahl der Benutzeroberflächen:
* PGM2 - das Standardinterface
* [[FLOORPLAN]]
* [[FHEM Tablet UI]]
* [[SmartVisu]]
* diverse Apps für iOS und Android (Auswahl unter: [[:Kategorie:FHEM Frontends|Fhem Benutzeroberflächen]])

Beispielhafte Screenshots diverser Benutzeroberflächen: http://fhem.de/fhem.html#Screenshots

== Module ==
Die Funktionalität von Fhem kann über '''Module''' erweitert werden. Module können die unterschiedlichsten Aufgaben übernehmen vom Anbinden eines Hardwaresystems
über die Bereitstellung eines Frontends bis zur Automatisierung von Aufgaben. Beispiele für Module:
* 00_CUL.pm - Implementierung der Unterstützung für den [[CUL]]
* 11_FHT.pm - Unterstützung der [[:Kategorie:FHT Components|FHT]] Heizungssteuerung
* 95_FLOORPLAN.pm - Grundriss (oder Ähnliches) als Benutzeroberfläche
* ...

Module können unterteilt werden in
* [[:Kategorie:FhemBefehl|Befehlsmodule]] (FhemBefehle sind teilweise eigenständige Module)
* [[:Kategorie:Hilfsmodul|Hilfsmodule]]
* [[:Kategorie:Gerätemodul|Gerätemodule]]
Die offiziell in Fhem enthaltenen Module sind in der [http://fhem.de/commandref Commandref] beschrieben. Sie werden über den [[Update]]-Befehl von Fhem verteilt und aktualisiert. Voraussetzung für die Aufnahme als offizielles Modul sind Supportwille durch den Entwickler und Dokumentation des Moduls.

Zusätzlich existiert eine Vielzahl von [[:Kategorie:Modul (Inoffiziell)|inoffiziellen Modulen]], die manuell in Fhem installiert werden müssen. Auch die Aktualisierung erfolgt nicht über den Update-Befehl, sondern muss durch den Nutzer selbst erfolgen. Inoffizielle Module sind an den verschiedensten Stellen zu finden:
* [[:Kategorie:Modul (Contrib)|Contrib]]-Verzeichnis im offiziellen Fhem-Sourcecode-SVN [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/]
* Beiträge im Fhem-Forum
* private Homepages

== Interfaces ==
Die Verbindung zu den angeschlossenen '''Geräten''' der Hausautomation wird im Allgemeinen - geräteabhängig - über [[Interface|Interfaces]] (manchmal auch als '''Gateway''' bezeichnet) hergestellt. Das kann z. B. im Falle von [[HomeMatic]] ein [[HMLAN Konfigurator]] sein, ein mittels LAN mit dem Fhem Server verbundenes Gerät, das die Fhem Steuerbefehle in das HomeMatic Funkprotokoll umsetzt - und auch die Funktelegramme der HomeMatic Komponenten an Fhem zurückgibt. Entsprechende Interfaces gibt es auch für andere Funkprotokolle und für die drahtgebundenen Systeme.

Eine (unvollständige) Liste solcher Interfaces (siehe auch [[:Kategorie:Interfaces|Kategorie Interfaces]]):
* [[CUL]] - je nach Einstellung für die Kommunikation mit [[:Kategorie:FS20 Components|FS20]], [[:Kategorie:FHT Components|FHT]] und andere [[SlowRF]] Protokolle, [[MAX|MAX!]] Heizungssteuerung oder [[:Kategorie:HomeMatic Components|HomeMatic]] und, mit Einschränkungen, InterTechno (nur senden)
* [[CUNO]], ähnlich CUL, jedoch nicht per USB sondern per IP angebunden (z.Zt. -Stand Januar 2014 - nicht für HomeMatic empfohlen)
* [[HMLAN Konfigurator|HomeMatic LAN Konfigurations-Adapter]] - HomeMatic
* [[MAX#MAXLAN|MAX! Cube LAN-Gateway]]
* Schnittstellen(karten) für [[:Kategorie:1-Wire|1-Wire]]
* TCM(120/310) zur Anbindung von [[:Kategorie:EnOcean Components|EnOcean]]
* [[Arduino]] mit Firmata über USB oder Netzwerk
* [[panStamp]] als Möglichkeit Arduinos mit diversen Sensor- und I/O- Boards per 868MHz Funk über das SWAP protokoll anzubinden
* [[JeeLink]], ein weiteres USB-Stick Interface (ebenfalls arduino basiert) für diverse 433MHz und 868MHz Komponenten
* [[RFXtrx]] für InterTechno, RSL, ELRO etc., Wetter-Sensoren (Oregon-Scientific, Cresta, La Crosse, TFA, UPM) und andere 433 Mhz Geräte.
* manche Komponenten ([[:Kategorie:IP Components|IP Komponenten]]) können über TCP/IP (LAN) direkt vom Fhem Server aus angesprochen werden; hier ist dann kein weiteres Interface im eigentlichen Sinne erforderlich. Dies gilt auch für diverse Module die Geräte über WEB Dienste des Herstellers anbinden (z. B. Withings, [[netatmo]]).

== Protokolle ==
Der Kommunikation zwischen Interfaces und Geräten liegt jeweils ein bestimmtes Protokoll zugrunde. Unterstützte Protokolle mit ihren Eigenschaften sind in der folgenden Tabelle aufgelistet.


{| class="wikitable sortable"
|+ Übersicht über unterstützte Funkprotokolle
|-
! Name !! rfMode !! Frequenz !! Modulation !! Datenrate !! class="unsortable" | Interfaces !! class="unsortable" | Modul !! class="unsortable" | Geräte (Beispiel) !! class="unsortable" | Bemerkungen
|-
| [[FS20_Allgemein|FS20]] || SlowRF || 868,35MHz || AM || 1kHz || CU*, FHZ || [http://fhem.de/commandref.html#FS20 FS20] || - || -
|-
| FHT || SlowRF || 868,35MHz || AM || 1kHz || CU*, FHZ || [http://fhem.de/commandref.html#CUL_FHTTK FHTTK], [http://fhem.de/commandref.html#FHT FHT] || Heizungsregelung || -
|-
| S300 || SlowRF || 868,35MHz || AM || 1kHz || CU*, FHZ || [http://fhem.de/commandref.html#CUL_WS CUL_WS] || Temperatur-/Feuchtesensoren || -
|-
| HMS || SlowRF || 868,35MHz || AM || 1kHz || CU*O, FHZ || - || ?? || -
|-
| EM || SlowRF || 868,35MHz || AM || 1kHz || CU*, FHZ || [http://fhem.de/commandref.html#CUL_EM CUL_EM] || Energiemonitore (Strom, Gas) || -
|-
| [[HomeMatic ]]|| HomeMatic || 868,3MHz || FM || 20kHz || CU*, [[HM-CFG-LAN_LAN_Konfigurations-Adapter|HMLan]], [[HM-CFG-USB_USB_Konfigurations-Adapter|HMUsb]] || [http://fhem.de/commandref.html#CUL_HM CUL_HM] || [[:Kategorie:HomeMatic_Components|diverse]] || -
|-
| [[MAX|MAX!]] || MAX || 868,35MHz || FM || 20kHz || CU*, [[MAX#MAXLAN|MAXLAN]] || [http://fhem.de/commandref_DE.html#MAX MAX] || [[:Kategorie:MAX|Wandthermostat, Heizkörperthermostate, Fensterkontakt, Zwischenstecker]] || -
|-
| IT || - || 433MHz || AM? || 1kHz || CU*433, || - || - || -
|-
| FRM || - || ?? || ?? || ?? || ?? || - || ?? || -
|-
| SWAP || - || 868 (433/915) MHz || GFSK || 38.3835 Kbps || panStamp (+panStick) || [http://fhem.de/commandref.html#SWAP SWAP] || RGB LED Driver, diverse Sensoren und Aktoren || -
|-
| [[:Kategorie:EnOcean Components|EnOcean]] || - || 315 / 868 / 902 / 928MHz || ASK || 125 kbit/s || [http://fhem.de/commandref.html#TCM TCM] || [http://fhem.de/commandref.html#EnOcean EnOcean] || Batterielose Funksensoren, diverse Aktoren || -
|-
| PCA || - || 868,35MHz || ?? || ?? || [[JeeLink]] || [http://fhem.de/commandref.html#PCA301 PCA301] || [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]] || -
|-
| LaCrosse || - || 868,35MHz || ?? || ?? || [[JeeLink]] || [http://fhem.de/commandref.html#LaCrosse LaCrosse] || LaCrosse IT+ (Technoline) Sensoren || -
|-
| ZigBee Light Link || - || 2,4 GHz || || || HUE Bridge (RaspBee) || [http://fhem.de/commandref.html#HUEBridge HUEBridge] || Philips HUE und LightLink Lampen (auch Osram LIGHTIFY an der HUE-Bridge)|| [http://www.developers.meethue.com/documentation/how-hue-works]
|-
| [[:Kategorie:Z-Wave Components|Z-Wave]] || - || 868MHz || 2-FSK || 9.600 bit/s oder 40 Kbit/s || [http://fhem.de/commandref.html#ZWDongle ZWDongle] || [http://fhem.de/commandref.html#ZWave ZWave] || - || -
|-
| [[WMBUS]] || WMBus_T, WMBus_S || 868MHz || ?? || 100 kbit/s / 32.768 kbit/s || CU* || [http://fhem.de/commandref.html#WMBUS WMBUS] || Wasseruhren, Wärmezähler, Elektrozähler || -
|-
| colspan="9" | ''Tabelle muss noch vervollständigt werden''
|-
| colspan="2" | '''Legende:'''
| colspan="7" | CU* = CUL, CUN, CUNO /
|}

{| class="wikitable sortable"
|+ Übersicht über drahtgebundene Systeme
|-
! Name !! class="unsortable" | Interfaces (Hardware) !! class="unsortable" | Modul !! class="unsortable" | Geräte (Beispiel) !! class="unsortable" | Bemerkungen
|-
| [[1-Wire]] || [[Interfaces für 1-Wire|diverse]] || [http://fhem.de/commandref.html#OWX OWX] || [[:Kategorie:1-Wire|1-Wire]] || -
|-
| [[EIB_/_KNX|EIB/KNX]] || [http://fhem.de/commandref.html#TUL TUL] || [http://fhem.de/commandref.html#EIB EIB] || [[:Kategorie:EIB/KNX|EIB/KNX]] || -
|-
| [[HomeMatic Wired]] || [[HomeMatic Wired RS485 LAN Gateway|HM485 LAN Gateway]] || [http://fhem.de/commandref.html#HM485_LAN HM485_LAN] || [[:Kategorie:HomeMatic Components|Präfix HMW]] || -
|-
| colspan="5" | ''Tabelle muss noch vervollständigt werden''
|-
| colspan="2" | '''Legende:'''
| colspan="3" | ...
|}

== Komponenten ==
Der eigentliche Zweck eines Hausautomatisierungs-Projekts sind dann letztendlich die '''Geräte''' (Komponenten / Aktoren / [[:Kategorie:Schalter (Empfänger)|Empfänger]]), die automatisch gesteuert werden sollen, bzw. auch Auslöser für Aktionen ([[:Kategorie:Schalter (Sender)|Sender]]) und Lieferant von Datenmaterial ([[:Kategorie:Hardware Typen|Sensoren]]) sind.

Diese Geräte sind, sofern es eine detaillierte Beschreibung dazu gibt, in den jeweiligen Unterseiten der [[:Kategorie:Hardware|Hardwareliste]] aufgeführt.

== Weblinks ==
* [http://www.enocean.com/de/home/ EnOcean] Homepage
* [http://www.elv.de ELV], (Haupt-)Lieferant von FS20, FHT, HomeMatic, MAX!
* [http://www.panstamp.com panStamp], panStamp Hersteller
* [http://jeelabs.com/products/jeelink Jeelabs], JeeLink Hersteller
* [http://www.zigbee.org/ Zigbee] Homepage

[[Kategorie:FHEM]]

HomeMatic

2015-07-25T10:16:48Z

Reibuehl: Umzug von CCU-2 zu Fhem

'''Achtung, diese Seite wird derzeit im Sinne einer klareren Beschreibung überarbeitet'''

'''HomeMatic''' (HM) ist ein System des Herstellers eQ-3 zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Erhältlich sind sowohl Geräte mit Funkschnittstelle 868.3 MHz, als auch (seit 2008) drahtgebundene Geräte mit RS485-Schnittstelle. Im Programm sind Geräte zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation, ferner gibt es noch Fernbedienungen und Statusdisplays.

=Grundlagen=
HomeMatic-Geräte können untereinander ''gepeert'' werden (engl. ''peers'' = "Gleiche"), im einfachsten Fall kann deshalb bereits ein Sensor (z.B. ein Temperatursensor) mit einem Aktor (z.B. einem Heizkörperregler) verbunden werden und diesen steuern. Hierbei können mehrere Sensoren und Aktoren untereinander verbunden werden, die Vorstellung der "Gleichen" ist also zutreffend.

HomeMatic-Geräte können auch mit einer Zentrale verbunden (''gepairt'') werden, die dann einen Teil der Steuerungslogik übernehmen kann. Bei dieser Verbindung spricht man vom ''Pairing'', weil jedes HomeMatic-Gerät nur mit einer Zentrale verbunden werden kann. Gepairte Geräte können auch nicht mehr direkt gepeert werden - dies geht dann nur noch unter Beteiligung der Zentrale.

==Voraussetzungen==
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen.
===Zentrale von eQ-3===
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU-2) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten.

===Fhem als Zentrale===
Für den Einsatz mit Fhem wird eine Funkschnittstelle benötigt, in Frage kommen [[CUL]], der [[HMLAN Konfigurator]] oder ein [[HM-CFG-USB_USB_Konfigurations-Adapter|HM-CFG-USB]].
'''Fehlt Bemerkung zu Wired'''

===Umzug von CCU-2 zu Fhem===
Der Umzug einer bestehenden HomeMatic Installation von einer HomeMatic CCU-2 auf Fhem ist möglich. Um die an die Zentrale angebundenen Devices in Fhem ohne größere Umkonfiguration weiter verwenden zu können, muß die HM-Id und, falls verwendet, die AES-Schlüssel der CCU-2 in Fhem eingetragen werden. Hierzu müssen diese Daten aus der CCU-2 ausgelesen werden. Dazu wird per SSH (z.B. mit PuTTY unter Windows) eine Verbindung zur CCU-2 aufgebaut. Die HM-Id befindet sich in der Datei /usr/local/etc/config/rfd/BidCoS-RF.dev in einer Zeile wie dieser:

<device serial="BidCoS-RF" type="HM-RCV-50" address="0xABCDEF" aes_key_index="0" firmware_version="2.11.9" bidcos_interface="KEQ1234567" roaming="true">

Die HM-Id ist der Wert im address Feld. Die dort angegebene hexadezimale Zahl (hier 0xABCDEF) ist die HM-Id und wird in Fhem ohne den Prefix "0x" eingetragen.

Falls bereits AES-Schlüssel verwendet wurden, sind diese in der Datei /etc/config_templates/crypttool.cfg zu finden und können 1:1 als Schlüssel im HMLAN in der gleichen Reihenfolge hinterlegt werden.

==Prototokoll==
HM-Geräte kommunizieren untereinander mit dem Protokoll ''Bidirectional Communication Standard'', abgekürzt ''BidCoS''. Jedes HM-Gerät enthält also Sender und Empfänger, das ist einer der wesentlichen Unterschiede z.B. zum FS20-System.
*Jedes HM-Gerät meldet beim Empfang eines Steuerbefehls durch einen Peer an diesen eine Bestätigung „ACK“ zurück. Erkennt das HM-Gerät den Befehl nicht, sendet es ein ''NACK''. Kommt vom HM-Gerät keine Rückmeldung innerhalb einer festgelegten Zeit, meldet der steuernde Peer ein ''MISSING ACK''.
*Jedes HM-Gerät meldet ferner seinen Status nach dem Erhalt eines Steuerbefehls zurück - so kann auch ein lokal am Gerät erfolgender Tastendruck in beim steuernden Peer oder in der Zentrale registriert werden.

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als HomeBrew (HB) bezeichnet, siehe hier [[Kategorie:HomeBrew]]
=Betrieb mit Fhem=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit Fhem"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

=== Einrichten des IO-Devices (Funkschnittstelle)===
Zuerst muss ein IO-Device eingerichtet werden, um mit HM Geräten kommunizieren zu können. Siehe hierzu [[HMLAN Konfigurator]].

=== Struktur von HM Geräten===
HM Geräte sind logisch in ein '''Device''' und ein oder mehrere '''Kanäle''' gegliedert. Jedes Device und jeder Kanal (Channel) wird in einer Entity in FHEM repräsentiert. 
Ausnahme: Sollte ein Gerät nur einen Kanal haben wird dieser in einer Entity mit dem Device eingerichtet.
====Device====
Das Device ist für die Kommunikation verantwortlich. Es sortiert und ordnet die zu sendenden und empfangenden Nachrichten.
Man kann prüfen, ob alle Nachrichten übertragen sind, oder ob es Probleme gegeben hat. Die Variablen "prot..." geben Auskunft darüber. Siehe auch [[Homematic_HMInfo#protoEvents]].
Zu beachten sind zudem die Übertragungsmodi. Nicht alle Devices sind ständig auf Empfang - FHEM muss berücksichtigen, wann gesendet werden kann. In '''protState''' kann man sehen, ob Kommandos auf Verarbeitung warten, also pending sind.
Einige Devices unterstützen mehrere Modi parallel.
===== Config=====
Wird von allen Devices unterstützt, auch wenn es bei Always kaum genutzt werden kann.
Man setzt die Kommandos in FHEM ab und diese warten in der Kommando-queue.
Wenn die config-funktion am Device ausgelöst wird (Anlerntaste drücken) sendet FHEM die wartenden Nachrichten der Reihe nach.
Config wird bei allen Devices zum pairen genutzt.
===== Always=====
Trifft man meist bei netzbetriebenen Geräten an, da diese kein Problem mit dem Energieverbrauch haben. Man kann immer mit dem Device kommunizieren.
===== Burst=====
Nur der Empfänger des Device ist aktiv. Über eine Aufweck-sequenz kann das Device geweckt werden. Man kann quasi immer mit dem Device kommunizieren. Nachteil des Aufwecken ist zum Einen, dass immer ALLE Devices im Funknetz geweckt werden, was deren Batterie belastet. Zum Andere ist die Aufweck-sequenz funktechnisch aufwändig und belastet die maximal erlaubte Sendekapazität des IO device je Stunde.
===== ConditionalBurst=====
Bei einigen Devices kann man den Burst mode zuschalten. Dies sind Devices, die zusätzlich über andere modi verfügen, so z.B. wakeup. Schaltet man burst-empfang ein kann man immer und sofort mit dem Device reden, es kostet aber etwas mehr Batterie. Siehe hierzu Attribut '''burstAccess''', Kommando '''burstXmit''' und Register '''burstRx'''
===== LazyConfig=====
Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung.
Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.a. auf ein Config.

===== Wakeup=====
Die Devices wachen regelmäßig auf und senden Daten, z.B. Temperatursensoren. Zu diesem Zeitpunkt kann FHEM die Nachrichten übertragen. Die Aufwachperiode ist unterschiedlich von 3 min bis zu 24h.

====Kanal====
Ein Kanal ist die Funktionseinheit des Geräts. Hier ist die Funktion des Sensors oder Aktors realisiert.
=== Variablen===
Wie alle FHEM Entities werden 4 Gruppen von Daten unterstützt:
* Internals: Im Web-Interface sichtbare Variablen, die allgemeine Informationen über den Zustand enthalten.
* Readings: Im Web-Interface sichtbare Variablen. Sie werden aus von Entites empfangenen Nachrichten generiert. Man kann mit notify Trigger auf die setzen. Readings werden im Statefile bei save und gewissen neustarts gesichert und beim Booten eingelesen. Readings haben einen Zeitstempel.
* Attribute: Im Web-Interface sichtbare Variablen. Über sie kann man die Eigenschaften der Entity in FHEM steuern.
* Helper: Im Web-Interface nicht sichtbare Variablen. Man kann sie mit dem Kommando 'list' sehen. Es sind hilfsvariablen, die für den User keine Bedeutung haben sollen.
==== Internals====
Viele Variablen sind nicht HM spezifisch - deren Bedeutung muss in allgemeinen Teil nachgelesen werden. Spezifische Variablen sind:
*Device
** channel_xx: Liste der Kanäle, die dem Device zugeordnet sind.
** prot... : Gruppe von Daten zum Zustand des [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device.
** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|Empfangspegel]] des Device bei IOs, Peers und Repeatern darstellt.

*Kanäle
** device: Das übergeordnete Device
** chanNo: Die Kanalnummer
** peerList: Ist die Entity mit einem anderen gepeert ist steht hier der Name der Peers. Siehe auch attribut peerIDs und Reading peerList. Diese Variable ist mit dem peer verlinkt, man kann darauf 'clicken'.

==== Readings====
Readings für HM Entites unterliegenden allgemeinen FHEM Regeln.
Generell gilt, dass ein Wert, der von FHEM gesetzt wurde mit dem prefix '''"set_"''' versehen wird. Wenn der Zustand bestätigt ist wird das set_ entfernt. Sollte man also ein Reading mit diesem prefix haben, das sich nicht selbst entfernt sollt man unbedingt den Zustand kontrollieren. 
So ist nach einem "set Licht on" der Zustand des Licht erst einemal "set_on". Mit der Antwort des Device wird es dann auf "on" gesetzt. 
Register machen eine Ausnahme:
=====Register=====
Register sind Konfigurationsparameter, die '''im Device flash''' gespeichert werden. Daten, die Registern zureordnet sind beginnen mit "R-". Sollte das Register einem peer zugeordnet sein kommt dieser danach. Der Namen ist also
'''R-<peer>-<registerName>''' 
Der Zugriff ist indirekt, geht also nur über Methoden und Kommandos. Man kann die Konfiguration (Register und peers) mit '''getConfig''' aus dem Device lesen und in FHEM dargestellen. FHEM bemüht sich, die angezeigten Register aktuell zu halten - der User muss aber ein gewisse Vorsicht im Umgang damit walten lassen. Register können mit '''regSet''' gesetzt werden. Ob die gelesenen Register komplett sind prüft [[Homematic_HMInfo#Integrit.C3.A4tspr.C3.BCfungen|configCheck]].
Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern. 
siehe auch [[Homematic_HMInfo#Infos|register]]. 
Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[Homematic_HMInfo#archConfig|archivieren]] und beim reboot wieder [[Homematic_HMInfo#archConfig|laden]].

==== Attribute====
Attribute sind i.a. Parameter, die das Verhalten der Entity steuern. Sie werden mit '''save''' in fhem.cfg oder einem seiner subfiles gespeichert. Nach einer Änderung sollte der User ein "save" machen, sonst sind diese nach einem Reboot verloren. 
Hier werden nur '''HM spezifische Attribute''' besprochen. 
Attribute, die das System '''automatisch''' anlegt. Sollten diese nicht mehr stimmen kann der User anlernen am Device drücken und sie werden wieder hergestellt. Der User sollte sie '''nicht ändern'''.
* model
* subType
* peerIDs: HMIds der peers. Wird gelegentlich verschoben!
* serialNr: auslaufend - durch Reading D-serianNr ersetzt
* firmware: auslaufend - durch Reading D-firmware ersetzt

Attribute für HM Entities, die der User steuern kann
* webCmd: FHEM setzt ggf. einen Default, der User kann dies anpassen
* expert: schaltet mehr oder weniger Readings sichtbar - dient der Übersichtlichkeit des Web-Interface.
* autoReadReg: steuert das automatische Lesen der Konfiguration - ggf. zeitverzögert um Resourcen zu schonen. Es wird Level 5 empfohlen

Attribute für HM Entities am Device, die der User steuern kann
* msgRepeat: kann man im Device einstellen. Es legt fest wir oft eine Nachricht wiederholt werden soll, falls sie nicht empfangen wird. Beachte, dass unabhängig davon ein HMLAN/USB immer 3-mal probiert zu senden. Insbesondere bei Burst Devices sollte man einen niedrigen level einstellen.
* IODev: Sollte man auf das IO device setzen, über das zu diesem Device gesendet werden soll. Es wird i.a. beim Pairen gesetzt.

Empfohlene Attribute außerhalb von HM
* event-on-change-reading .*

===Kommandos===
====Allgemein====
* get <name> cmdList ''# zeigt alle Kommandos mit Parametern für diese Entity an''
* clear [readings|register|rssi|msgEvents] ''# löschen von Readings oder Zählern''
====Register kommandos====
* set <name> getConfig ''# liest alle Peers und Register. Auf ein Device angewendet werden ALLE channels auch gelesen''
* set <name> regSet [prep|exec] <regName> <value> ... [<peerChannel>]'' #schreiben eines Registerwerts. Das Kommando landet im Kommandstack''
* set <name> regbulk ...''# kommando zum setzen von rohdaten und ganzen Registerlisten. Ausser zum re-configurieren eines ganzen Device eher nicht für den User zu gebrauchen''

* set <name> sign [on|off ''# setzt das Register um AES einzuschalten. Man sollte sich über AES '''vorher''' einlesen!!''

* get <name> regList ''# zeigt alle Register, die diese Entity '''unterstützt''' - incl Beschreibung und Wertebereich. Als Anfänger sollte man einmal hinsehen!''
* get <name> reg all ''# zeigt alle Register, die diese Entity '''hat''' und den aktuellen Wert''
===Kommunikation===
Die Kommunikation zwischen Device und der Zentrale folgt einem Protokoll. Für die meisten Nachrichten erwartet der Sender eine Empfangsbestätigung. FHEM beachtet das Protokoll und implementiert es entsprechend der Fähigkeiten des IO device. 
Grundsätzlich kann jedes Device an jedes andere Nachrichten senden. Damit dies auch einen erfolg hat, müssen die Kanäle gepeert werden. 
Um FHEM zu erlauben, Nachrichten an das Device zu richten muss FHEM gepairt werden. 
Das Senden der Nachrichten macht IMMER das Device - ein Kanal selbst kann nicht wirklich senden.
====Protokoll====
Da für das Senden das Device verantwortlich ist sind hier die entsprechenden Informationen zu finden. Zu Beachten sind die [[HomeMatic#Device|Übertragungsmodi]], die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
* protState: Der Zustand der Protokollmaschine
** CMDs_done: alle Nachrichten übertragen, eine Fehler in diesem Durchgang aufgetreten
** CMDs_done_Error:xx : es hat xx Fehler bei der letzten Übertragung gegeben.
** CMDs_pending: Nachrichten warten auf das Senden
** CMDs_processing... : die Nachrichtenübertragung ist im Gange
** Info_Cleared: die Protokoll Statistik wurde rückgesetzt
* protCmdPend: Anzahl der Nachrichten, die auf das Senden warten
* protCmdDel: Anzahl gelöschter Nachrichten aufgrund von Fehlern
* protCmdNack: Anzahl der negativen Acknowledges
* protCmdResnd: Anzahl der Wiederholungen - die Nachrichten wurden nicht gelöscht.
* protCmdResndFail: Anzahl der fehlgeschlagenen Wiederholungen - die Nachrichten wurden gelöscht.
* protCmdIOerr: Anzahl der IO Fehler - Übertragung war nicht Möglich, weil das IO Device Probleme hatte. Der Grund sollte im IO Device nachgesehen werden.
* protCmdIOdly: Anzahl der Verzögerungen aufgrund von IO Problemen
* protCmdTimedOn: Anzahl der Nachrichten, wenn ein Timer im Device genutzt wird - z.B. durch on-for-timer
* protCmdRcv: Anzahl empfangene Nachrichten
* protCmdSnd: Anzahl gesendete Nachrichten
* protCmdErrIoId_...: Anzahl der Sendeversuche zum Device von einer anderen Zentrale
* protCmdErrIoAttack: Anzahl der Sendeversuche zum Device die nicht von FHEM kam- es könnte ein Versuch sein, das System zu hacken. Dies wird auch im Reading '''sabotageAttack''' ausgegeben und man kann ein notify darauf ansetzen.

* protCmdEvt_AESCom: Anzahl der AES Nachrichten von Device
* protCmdEvt_AESKey: Benutzter AES key

Die Zähler können mit '''set <device> clear msgEvents''' rückgesetzt werden. Dies kann vor Konfigurationsänderungen Sinn machen, um Probleme besser erkennen zu können. 
Eine Übersicht kann man mit HMInfo [[Homematic_HMInfo#protoEvents|protoEvents]] erhalten. Auch das Löschen aller Zähler ist von HMInfo aus möglich.

====Rssi====
Zeigt den Empfangspegel, den ein Device von einem Anderen misst. Die Variablen sind in Internals abgelegt. Angegeben werden minimale und maximale Wert. Außerdem wird der Durchschnitt und die Anzahl der Nachrichten ausgewertet. 
HM liefert Empfangspegel am IO Device (FHEM standard) aber auch den Empfangspegel am Device selbst. Ebenfalls ausgewertet werden Pegel, die beim Senden zwischen Peers erreicht werden. 
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden. 
Eine Übersicht erkält man mit HMInfo [[Homematic_HMInfo#RSSI|Rssi]]. Das Löschen der Zähler aller HM devices ist von HMInfo aus möglich. 

Man kann RSSI kontinuierlich aufzeichnen, wenn das Attribut '''rssiLog''' im Device gesetzt ist. Es wird ein Reading rssi_<name> erzeugt. Das generelle setzen dieses Attributs wird aus Performance-gründen nicht empfohlen.

== Pair / Peer bzw. pairen und peeren ==
HM Geräte können mit und ohne Zentrale betrieben werden. In FHEM wird davon ausgegangen, dass Geräte immer von einer Zentrale aus gesteuert werden können. Um dies zu erreichen muss das Device mit der Zentrale gepairt werden.

=> [[HomeMatic Devices pairen|Devices Pairen]]

Um einen Betrieb (auch)ohne Zentrale zu ermöglichen kann man Kanäle <ins>p'''ee'''ren</ins>. Hier bei wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft werden.
siehe [[Homematic_Peering_Beispiele|Channels peeren]] für Details.

== HMInfo ==
Mit [[Homematic_HMInfo|HMInfo]] kann man eine Übersicht der HM Installation erhalten, Konfiguration prüfen und Alarme gesammelt auswerten.

== Besondere Entites ==

=== Virtuelle Entities ===
Virtuelle Entities sind nicht reale HM Devices und Kanäle. Man kann sie als Sender und Empfänger nutzen, auch im Zusammenhang mit Rauchmeldern oder zur Steuerung von Heizungsventilen. Die spezifischen Anwendungen sind im entsprechenden Kapitel nachzulesen. 
Angelegt wird das Device, dann wird per Kommando eine Anzahl Kanäle angelegt.
define <virtDev> CUL_HM 112233
set <virtDev> virtual 10
jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt.
Die die gültigen Kommandos kann man wie immer mit '''get <entity> cmdList''' erfahren. 
Auch einem Virtuellen Device sollte man das '''Attribut IODev setzen '''.
=== IO Entities ===
Analog virtuellen Entities kann man auch IO entities erzeugen. IO ist nicht ganz korrekt, eigentlich sind es Kanäle einer Zentrale. Da diese in FHEM nicht abgebildet wird sind sie teilweise in den IOs realisiert. 
Faktisch ist es ein Kanal, der der HMId des gewählten IO device zugeordnet ist. Aktuell wird dieser Kanal nicht in FHEM dargestellt. Man kann diese Entity jedoch peeren. 
Man kann jeder HMId bis zu 50 Kanäle zuweisen. Da mehrere IO devices die gleiche HMId nutzen können, teilen sich diese in diesem Fall die Kanäle.

=== Action Detector===
Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, andere alle 3 Tage. Wenn so eine Zeit für einen Device spezifiziert ist wird diese automatisch vom ActionDetector überwacht. 
Meist sind dies batteriebetriebene Geräte. Sollte aus irgendwelchen Gründen der Batteriealarm übersehen werden und das Gerät keine Nachricht mehr senden wird es auf Dead gesetzt.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000"

* attribut
** actCycle: gibt an, in welchen Abständen sich das Device melden muss
** actStatus: gibt den Zustand an
*** alive: Device hat sich in der erwarteten Zeit min einmal gemeldet
*** dead: Device hat sich in der erwarteten Zeit nicht gemeldet
*** unknown: Device hat sich nicht gemeldet, es ist aber seit dem letzten reboot die Zykluszeit noch nicht abgelaufen.

* readings
** Activity: entsprechend dem actStatus.

* get
** listDevice: Gibt alle Objekte zurück
** listDevice notActive: Gibt alle Objekte zurück die nicht "alive" sind
** listDevice alive: Gibt alle Objekte zurück die "alive" sind
** listDevice unknown: Gibt alle Objekte zurück die "unknown" sind
** listDevice dead: Gibt alle Objekte zurück die "dead" sind

Durch das Setzen des Attributs im HM device wird der ActionDetector automatisch definiert - nach einem save steht er auch in der fhem.cfg.
Alternativ ist auch eine manuelle Definition möglich und sollte in etwa so aussehen:

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Die HMId "000000" darf nicht geändert werden.

In der Entity actionDetector kann man die Infos gesammelt einsehen.
Der User kann durch das Setzen des Attributs actCycle jedes Device in diese Liste aufnehmen. Es wird dann geprüft, ob sich das Device in dieser Zeit auch meldet. Der User muss dies aber selbst sicherstellen.

== Tipps / HowTos / Beispiele ==

* [[HomeMatic Devices pairen|HM Devices pairen]] zum '''Pairen''' der Geräte untereinander.
* [[CUL]] (also gleichzeitig)?
* [[Slider für HM-Rolladensteuerung anzeigen]]
* Für den "Fall der Fälle": Erstellen Sie eine Liste aller HM-Geräte mit den Installationsorten, HM-Namen, Fhem-Namen '''und''' den Geräte-IDs. Falls Sie sich ihr Fhem einmal zerschießen, wird diese Liste sehr hilfreich sein. Zur Abwicklung von Gewährleistungsansprüchen sind Daten über Kaufdatum und Lieferant (bei größeren Installationen mit Zukauf in zeitlichen Abständen) ebenfalls angebracht.

== Probleme ==

=== Messages Sniffen ===
Um Probleme besser nachvollziehen zu können, kann man [[Homematic_Nachrichten_sniffen|Nachrichten mitsniffen]]

=== Daten können empfangen werden, Befehle werden nicht übertragen ===

Das kann mehrere Ursachen haben:
* P'''ai'''ring nicht abgeschlossen (bei den ''Readings'' "PairedTo" bzw. "R-pairCentral" steht der Wert '''set_'''0x1A2B3C). Das P'''ai'''ring ist erst dann erfolgreich abgeschlossen, wenn das '''set_''' fehlt, also nur noch (beispielhaft) "0x1A2B3C" steht. Siehe [[HomeMatic_Devices_pairen]]
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu nah (RSSI-Werte bei ~ "-17") beieinander
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu weit (RSSI-Werte bei unter ~ "-80") voneinander entfernt
* ...

=== Notifys und anderes funktionieren nach einem Fhem-Neustart nicht mehr oder nicht mehr zeitnah ===

Obwohl HomeMatic wegen der höhren Datenübertragungsrate wesentlich weniger von der [[1% Regel]] betroffen ist als z.b. FS20 oder FHT, so kann es dennoch zu Funkkontingentüberschreitungen kommen.

Insbesondere ist bei FHEM Versionen ab Oktober 2013 das Attribut ''autoReadReg'' auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim Fhem-Start ein ''getConfig'' durchgeführt, was viel Funkverkehr erfordert.

Je nach Anzahl der Geräte kann dazu führen, dass insgesamt zu viel Funklast erzeugt wird, im Logfile erscheint dann eine Meldung wie:

2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload

Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontigent aufgebraucht ist. Erst nach einer Stunde kann erneut gesendet werden. Als '''Notbehelf''' kann die Funkschnittstelle resetted oder ([[HMLAN Konfigurator]]) kurz stromlos gemacht werden. Dann wird der Zähler wieder auf Null gesetzt.

Alternativ können so viele HM-Geräte wie möglich auf ''autoReadReg 0_off'' gesetzt werden.

Siehe auch: [[1% Regel]]

=== Spannungsversorgung ===
Die Batterielebensdauer der HomaMatic Komponenten ist durchwachsen. Besonders die mitgelieferten Batterien sind mitunter schon nach wenigen Wochen leer, trotzdem werden öfters keine ''battery low'' Meldung erzeugt. Bei Störung des Funkverkehrs (z.b. blinkendes Antennensymbol im HM-CC-TC und kurzes piepen zur vollen Stunde von morgens bis abends, fehlende ACK Meldungen, nicht auslösende IR-Bewegungssensoren und ähnliches) sollte also immer auch eine schlechte Spannungsversorgung in Betracht gezogen werden.

Gute neue Batterien halten jedoch i.d.R. 12 Monate und mehr, auch Lebensdauern über 2 Jahre sind bei einigen Geräten (Tür/Fensterkontakte, Sender, Retroanzeige, IR-Bewegungsmelder) keine Seltenheit.

== Links ==
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

HM-PB-2-WM55 2fach-Funk-Wandtaster

2015-04-09T11:04:09Z

Reibuehl: Integration in Jung CD 500 Markenschalterprogramm

HomeMatic HM-PB-2-WM55 2fach-Funk-Wandtaster

== Features ==

<bitte eintragen>

== Hinweise zur Hardware-Installation ==
Die Integration in FHEM läuft wie mit allen Komponenten. Den LAN-Adapter in FHEM auf hmPairForSec 60 (Zahl bedeutet die Zeit des Zustands in Sekunden und kann beliebig geändert werden) setzen und den Knopf auf der Rückseite des Schalters drücken. Dann sollte der Schalter wie unten dargestellt in FHEM angelegt werden (wird in die fhem.cfg eingetragen). Je nach Einstellungen in autocreate (http://fhem.de/commandref.html#autocreate) kann es sein, dass auch noch weitere Aktionen ausgeführt wurden.

== Hinweise zum Betrieb mit FHEM ==

=== Auszug aus der fhem.cfg ===
Hier der Originaleintrag aus der fhem.cfg der automatisch erstellt wird (mit den "xxx" habe ich meine Nummer erstetzt):
<pre>
define CUL_HM_HM_PB_2_WM55_1F1xxx CUL_HM 1F1xxx
attr CUL_HM_HM_PB_2_WM55_1F1xxx .devInfo 020000
attr CUL_HM_HM_PB_2_WM55_1F1xxx .stc 40
attr CUL_HM_HM_PB_2_WM55_1F1xxx firmware 1.1
attr CUL_HM_HM_PB_2_WM55_1F1xxx model HM-PB-2-WM55
attr CUL_HM_HM_PB_2_WM55_1F1xxx room Bad
attr CUL_HM_HM_PB_2_WM55_1F1xxx serialNr KEQ003xxx
attr CUL_HM_HM_PB_2_WM55_1F1xxx subType pushButton
define FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx FileLog ./log/CUL_HM_HM_PB_2_WM55_1F1xxx-%Y.log CUL_HM_HM_PB_2_WM55_1F1xxx
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx logtype text
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx room CUL_HM
define CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 CUL_HM 1F1xxx01
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 model HM-PB-2-WM55
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 room CUL_HM
define FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 FileLog ./log/CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01-%Y.log CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 logtype text
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 room CUL_HM
define CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 CUL_HM 1F1xxx02
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 model HM-PB-2-WM55
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 room CUL_HM
define FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 FileLog ./log/CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02-%Y.log CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 logtype text
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 room CUL_HM
</pre>

=== Bearbeiten ===
Das ist der Standardeintrag, den fhem automatisch erstellt. Es macht aber Sinn, einiges zu verändern.
Zum einen sollten die Entities umbenannt werden, um sie besser finden und somit bedienen zu können. Das geht entweder manuell in der fhem.cfg (suche "CUL_HM_HM_PB_2_WM55_1F1xxx" ersetze mit neuem Begriff) oder besser per Befehl:
<pre>
rename CUL_HM_HM_PB_2_WM55_1F1xxx LichtFlurDev
rename CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 LichtFlur1
rename CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 LichtFlur2
</pre>

Auch ist es nicht sinnvoll, für jede Entity (in diesem Fall 3: Schalter und die beiden Knöpfe) je ein eigenes Logfile anzulegen, auch wenn autocreate das so macht, denn das kostet Performance und Übersichtlichkeit. Das Beispiel unten zeigt, wie die Ereignisse aller drei Entities mitgeschrieben werden - achtet auf das .* am Ende:

<pre>
define FileLog_LichtFlur FileLog ./log/LichtFlur-%Y.log LichtFlur.*
attr FileLog_LichtFlur logtype text
attr FileLog_LichtFlur room CUL_HM
</pre>

Und jetzt natürlich noch aufräumen und die alten Logfiles entsorgen:
<pre>
delete FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx
delete FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01
delete FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02
</pre>

'''Wichtig:''' Folgende Attribute solltet ihr '''nicht aendern''': .devInfo, .stc, model, firmware, serialNr, subType

Weitere interessante Attribute, die man nutzen sollte (siehe auch commandref)sind:room, group, expert, webCmd: gruppieren und darstellen auf der webseite, autoRegRead: automatisches Lesen der Register (für push-Button sollte es auf 0 stehen)

Letztendlich könnte die "gepflegte" fhem.cfg so aussehen:
<pre>
#====== Das Device
define LichtFlurDev CUL_HM 1F1xxx
attr LichtFlurDev .devInfo 020000
attr LichtFlurDev .stc 40
attr LichtFlurDev firmware 1.1
attr LichtFlurDev model HM-PB-2-WM55
attr LichtFlurDev serialNr KEQ003xxx
attr LichtFlurDev subType pushButton
#--- user Attribute zum Device
attr LichtFlurDev room Flur,Device,Licht
attr LichtFlurDev group Schalter
attr LichtFlurDev webCmd statusRequest:getConfig
attr LichtFlurDev expert 1
attr LichtFlurDev autoRegRead 0
#--- erste Taste
define LichtFlur1 CUL_HM 1F1xxx01
attr LichtFlur1 model HM-PB-2-WM55
attr LichtFlur1 room Flur,Button,Licht
attr LichtFlur1 group Schalter
#--- zweite Taste
define LichtFlur2 CUL_HM 1F1xxx02
attr LichtFlur2 model HM-PB-2-WM55
attr LichtFlur2 room Flur,Button,Licht
attr LichtFlur2 group Schalter

define FileLog_LichtFlur FileLog ./log/LichtFlur-%Y.log LichtFlur.*
attr FileLog_LichtFlur logtype text
attr FileLog_LichtFlur room logfiles
</pre>

=== Mit virtuellem Aktor verbinden ===
Wenn man den Taster nicht direkt mit einem Aktor verbindet, erhält er keine Rückmeldungen, wird also immer orange und rot blinken, wenn ihr einen Befehl absetzt. Dieser wird zwar von fhem verarbeitet, fhem weiß aber nicht, dass es etwas zurückmelden soll. Daher solltet ihr Euch einen virtuellen Aktor anlegen und den Taster dann mit diesem verbinden:

In der FHEM-Web Oberfläche gebt ihr in der Kommandozeile ein (die hmId kann freigewählt werden, darf aber in echt nicht existieren):
define virtueller_Aktor CUL_HM 123456
sowie:
set virtueller_Aktor virtual 2

Jetzt habt ihr einen Virtuellen Aktor mit einem Kanal erstellt, jetzt gilt es noch das ganze mit dem realen Taster zu verbinden. Verbunden werden zuerst die Kanäle und dann wird die ganze Konfiguration am Taster gespeichert:

set LichtFlur1 peerChan 0 virtueller_Aktor_Btn1 single set
set LichtFlur2 peerChan 0 virtueller_Aktor_Btn2 single set
set LichtFlurDev getConfig

und am Taster einmal anlernen drücken, ggf. nochmal ein <code>set LichtFlurDev getConfig</code>

Nun drückt einmal einen Button eures Tasters. Wenn alles geklappt hatte, sollte bei Euren Kanälen im State ein (to virtueller_Aktor_Btn1) dahinter stehen und unter den Attributen etwas in den peerIDs auftauchen. Diesen virtuellen Aktor kann man übrigens als Gegenpart für beliebig viele Taster nehmen, ihr braucht also nicht für jeden Taster einen virtuellen Aktor erstellen. Um den virtuellen Aktor zu erweitern einfach ein <code>set virtueller_Aktor virtual [Gesamtanzahl aller Kanäle]</code> ausführen, schon habt ihr weitere Kanäle die ihr mit euren echten Tastern peeren könnt.

Am Ende umbedingt einmal "Save config" drücken, damit der virtuelle Aktor in der fhem.cfg abgespeichert wird.

=== Mit Rolladenaktor verbinden (peeren) ===

Der HM-PB-2-WM55 kann auch z.B. direkt mit einem [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Rollladenaktor]] gepeert werden. Hierdurch lässt er sich ohne Fhem nutzen. Weitere Infos dazu finden Sie [[HM-LC-BL1-FM_Funk-Jalousieaktor#Peeren_mit_einem_HM-PB-2-WM55|hier]].

== Integration in bestehende Markenschalterprogramme ==

Obwohl der HM-PB-2-WM55, im Gegensatz zu den Funk-Schaltaktoren für Markenschalter (HM-LC-Sw1PBU-FM, HM-LC-Dim1TPBU-FM und HM-LC-Bl1PBU-FM), eigentlich nicht für die Integration in bestehende Markenschalterprogramme geeignet ist, kann man ihn mit etwas Bastelaufwand doch optisch zumindest etwas integrieren.

=== Jung CD 500 ===

Mit Hilfe einer im 3D Drucker selbst gedruckten Adapterplatte und etwas dremeln lässt sich der HM-PB-2-WM55 recht gut in die Jung CD 500 Serie integrieren. Eine bebilderte Anleitung ist [http://www.instructables.com/id/HomeMatic-Wandschalter-mit-Jung-CD500-Blenden hier] zu finden.

== Probleme ==

=== Bausatz: Der Taster lässt sich nicht anlernen / rotes Dauerblinken ===
Dann stimmt vermutlich etwas mit der Lötung nicht. Am besten insbesondere die Lötungen des Funkmoduls (8 auf jeder Seite überprüfen).
Am besten mal in der fhem.cfg
<pre>
attr LANInterface loglevel 1
</pre>
eintragen und dann die Logdatei anschauen, was dort für Funkverkehr aufgezeichnet wird. Euren Schalter könnt ihr identifizieren, indem ihr den kleineren QR-code auf der Platine des Schalters z.B. mit einem Android Handy und Barcoo auslest. Die App zeigt Euch dann den sechsstelligen Gerätecode an (wenn der Code siebenstellig erscheint, dann die erste Ziffer / Buchtstaben weglassen), den ihr in der Logdatei suchen könnt.

== Links ==

Anleitung: [http://www.elv-downloads.de/Assets/Produkte/10/1030/103076/Downloads/103076_HM_PB_2_WM55_UM.pdf PDF]

Integration in Jung CD 500 Schalterprogramm: [http://www.instructables.com/id/HomeMatic-Wandschalter-mit-Jung-CD500-Blenden Instructable]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Sender)]]

Diskussion:HomeMatic Type Thermostat

2015-02-13T12:59:20Z

Reibuehl: Die Seite wurde neu angelegt: „Das Format der Temperaturlisten für HM-CC-RT-DN und HM-TC-IT-WM-W-EU unterscheiden sich meines Wissens in den Namen der Tagesprogramme. Das geht aus fdem Arti…“

Das Format der Temperaturlisten für HM-CC-RT-DN und HM-TC-IT-WM-W-EU unterscheiden sich meines Wissens in den Namen der Tagesprogramme. Das geht aus fdem Artikel nicht hervor.

Kategorie Diskussion:Hardware Typen

2015-01-31T08:25:29Z

Reibuehl: /* Konsolidierung der Seiten "HomeMatic Type xxx" */

== Konsolidierung der Seiten "HomeMatic Type xxx" ==

Also ich hatte die Idee von [[Benutzer Diskussion:Strauch|"Strauch"]] nicht als Konkurenz oder Ergänzung zu der allgemeinen Kategorie Hardware Type verstanden. Ich sehe sie als einen Versuch, '''HomeMatic-spezifische''' Informationen, die zur Zeit über die Seiten mehrerer Hardware Devices verstreut sind, die aber eine ganze Kategorie von HomeMatic Devices betreffen, an einer zentralen stelle zu sammeln. Damit kann vermieden werden, das z.B. Wiki-Updates, die den Umgang mit Temperatur Templates betreffen, im Artikel für jeden Heizungs- und Wandthermostat separat nachgetragen werden müssen (oder eben auch nicht passieren). Durch das sammeln solcher Teile in einem Typen- und HomeMatic-spezifischen Artikel kann dann von den Devices nur noch auf den Artikel verwiesen werden und wenn sich dann was ändert oder besser dokumentiert wird, profitieren alle Artikel davon.
(--[[Benutzer:Reibuehl|Reibuehl]] ([[Benutzer Diskussion:Reibuehl|Diskussion]]) 08:23, 31. Jan. 2015 (UTC))

Zum Thema "HomeMatic Type xxx", die im Prinzip etwas ähnliches wie die Unterkategorien zu Hardware Typen dargestellt haben, gab es einen Mail-Austausch, den ich zur allgemeinen weiteren Diskussion hierher kopiere: (--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 18:47, 30. Jan. 2015 (UTC))

:''ich habe die Einrichtung der "HomeMatic Type..."-Seiten in den letzten Wochen/Monaten schon bemerkt ... und nicht wirklich verstanden, was das letztendliche Ziel ist. Es beruhigt mich, dass Du selbst Zweifel daran bekommst, ob das der richtige Ansatz ist - ich fand ihn nämlich nicht sinnvoll, nicht zuletzt, weil er nicht sauber in das Fhem-Wiki interiert werden kann und irgendwie für mich auch generell nicht zum Wiki-Konzept passt.''
:''Ich würde vorschlagen, auf diese neuen/HM-spezifischen Typen zu verzichten und stattdessen die Geräte in die bestehenden Unterkategorien von '''[[:Kategorie:Hardware Typen|Hardware Typen]]''' einzusortieren. Das ist auch jetzt schon möglich und wird für viele andere (auch HomeMatic) Geräte so gemacht.''
:''Die Problematik des aktuellen "HomeMatic Type-"Konzepts kannst Du allein daran erkennen, dass sie nicht sauber untereinander verlinkt sind - eine Sache, die bei Verwendung der Kategorien automatisch funktioniert.''
:''Sollten einzelne HomeMatic Geräte überhaupt nicht in eine der bestehenden Hardware-Typen einzuordnen sein, besteht ja immer noch die Möglichkeit, eine neue Unterkategorie anzulegen - bisher sehe ich die Notwendigkeit noch nicht. Wenn es HomeMatic-spezifische Unterschiede oder Besonderheiten gibt, die sich am Gerätetyp festmachen lassen, würde ich das eher auf einer eigenen Seite (für alle Typen) beschreiben. Diese eine Seite sollte über die HomeMatic Hauptseite (deren Struktur meiner Ansicht nach auch dringend überarbeitet werden müsste) im richtigen Kontext erreichbar sein.''
:''Wir können - und sollten - das gern weiterdiskutieren bevor Du viel weiteren Aufwand in die Seiten steckst. Mein Vorschlag: wenn Du damit einverstanden bist, dann leg doch eine Seite "HomeMatic Hardware Typen - Besonderheiten" (oder ähnlich) an. Hier aber nur die grobe Struktur. Auf der Diskussionsseite zu dieser Seite (oder, falls Dir das lieber ist, auf Deiner Diskussionsseite) sollte dieser Mailthread als Start der Diskussion über das Gesamtkonzept stehen. Dann können auch andere Fhem-Wiki-Benutzer (Krikan war in den letzten Monaten auch recht engagiert, was die Wiki-Struktur und Kategorien angeht, ebenso Tupol vor längerer Zeit) ihre Ideen und Vorschläge einbringen. Ich denke, dann kann das eine runde, verständliche und komplette Sache werden.''

Die ursprüngliche Mail (von [[Benutzer Diskussion:Strauch|"Strauch"]]) war:
:''ich baue gerade am Fhemwiki im Bereich Homematic um. Ich hatte mit Martin irgendwann mal besprochen. Das wir die Gerätegruppen wie Thermostat, Remote, Threestate als Einzelseiten anlegen und dort die Informationen hinterlegen die für alle Geräte dieser Kartegorie zutreffen. Nun glaube ich würde es Sinn machen die entsprechenden Artikel als Subkategorie in Homematic anzulegen. Wie siehst du das? Wenn ja kannst du das entsprechend einrichten?''
:''Hier die vorhanden HomematicTyp Artikel (ich muss noch ein paar hinzufügen):''
::*''HomeMatic Type Blind''
::*''HomeMatic Type Dimmer''
::*''HomeMatic Type MotionDetector''
::*''HomeMatic Type PushButton''
::*''HomeMatic Type Remote''
::*''HomeMatic Type Switch''
::*''HomeMatic Type Thermostat''
::*''HomeMatic Type ThreeState''
::*''HomeMatic Type THSensor''

:''Beim ThermostatTyp bin ich am weitesten: [[HomeMatic Type Thermostat]]''

=== Zuordnung(sversuch) HomeMatic Type zu "Hardware Typen"-Unterkategorie ===
{| class="wikitable"
|-
! Hardware Typen !! HomeMatic Type !! Bemerkungen / Kommentare
|-
| Rollladensteuerung || HomeMatic Type Blind || ...
|-
| Dimmer || HomeMatic Type Dimmer || ...
|-
| Bewegungs- und Anwesenheitsmelder || HomeMatic Type MotionDetector || ...
|-
| ??? || HomeMatic Type PushButton || ...
|-
| Schalter (Sender) || HomeMatic Type Remote || ...
|-
| Schalter (Empfänger) || HomeMatic Type Switch || ...
|-
| Heizungssteuerung || HomeMatic Type Thermostat || Es gibt auch noch Kategorie Heizungsventile
|-
| ??? || HomeMatic Type ThreeState || Wofür wird dieser Typ benötigt? Ist er relevant für Endanwender?
|-
| Temperatursensoren / Feuchtesensoren || HomeMatic Type THSensor || ...
|-
|}

Ich denke, es ergibt sich schon eine fast vollständige Abdeckung. Es sollte geprüft werden, ob die Information, die derzeit auf einer "HomeMatic Type xxx" Seite steht - falls überhaupt erforderlich - auf die (Unter-)Kategorieseite passen würde. Mit einem HomeMatic-spezifischen Kommentar nur da wo er wirklich nötig ist.

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

2015-01-31T08:01:50Z

Reibuehl:

{{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=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

== Hinweis ==
Wird mit aktiviertem AES ausgeliefert und kann nur mit Gateways die AES unterstützen gepaired werden (HM-LAN-CFG und HM-USB-CFG).

== Features ==

[[Kategorie:HomeMatic Components]]

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

2015-01-31T08:01:17Z

Reibuehl: Infobox hinzugefügt

{{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=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

Homematic Funk-Tür-Fensterkontakt, optisch
== Hinweis ==
Wird mit aktiviertem AES ausgeliefert und kann nur mit Gateways die AES unterstützen gepaired werden (HM-LAN-CFG und HM-USB-CFG).

== Features ==

[[Kategorie:HomeMatic Components]]

HM-OU-LED16 Funk-Statusanzeige LED16

2015-01-05T10:09:51Z

Reibuehl: /* fhem.log Auszug */

{{Infobox Hardware
|Bild=HM-OU-LED16.jpg
|Bildbeschreibung=HomeMatic Funk-Statusanzeige LED16
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=16 (3 Tasten, Hoch, Runter und Enter)
|HWVoltage=7,5 V DC (über mitgeliefertes Steckernetzteil
|HWPowerConsumption=max. 250 mA
|HWPoweredBy=Netz
|HWSize=100x100x15mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

= Features =
Anzeige von 16 Statuswerten über rot/grün/orange LED

= Allgemeines =
Die Funk-Statusanzeige LED16 kann mit ihren 16 Kanälen und insgesamt 32 LED's (je 1xGrün und 1xRot -> Rot+Grün=Orange) diverse Stati anzeigen.
Das Schriftfeld ist nicht beleuchtet und kann mit einer Word-Vorlage befüllt werden.
Außerdem kann man sie auch als 16-Kanal Funk-Fernbedienung verwenden. Hier ist die Auswahl des Kanals allerdings etwas umständlich. Mit Hilfe der Hoch- und Runtertaste auf der Rückseite kann man den Kanal, der durch ein blinken der jeweiligen LED's angezeigt wird, auswählen und seine Wahl mit der, ebenfalls auf der Rückseite liegenden Enter-Taste bestätigen.

= Hinweise zur Inbetriebnahme und Installation =

Die Funk-Statusanzeige kann nicht direkt gepeered werden sondern funktioniert nur mit einer Zentrale, wie z.B. FHEM.
<Bitte ergänzen>

= Probleme =

<ggfls. ergänzen>
= Betrieb mit FHEM =

== event Monitor ==

<Bitte ergänzen>
== fhem.log Auszug ==

<pre>
2014.12.31 16:01:11 3: CUL_HM set OG_Statusdisplay_Led_01 led red
2014.12.31 16:02:37 3: CUL_HM set OG_Statusdisplay_Led_01 led off
2014.12.31 16:03:46 3: CUL_HM set OG_Statusdisplay_Led_01 led green
2014.12.31 16:06:39 3: CUL_HM set OG_Statusdisplay_Led_01 led off
</pre>

== fhem.cfg ==

<pre>
define OG_Statusdisplay CUL_HM 1EAB54
attr OG_Statusdisplay IODev HMLAN1
attr OG_Statusdisplay autoReadReg 4_reqStatus
attr OG_Statusdisplay expert 2_full
attr OG_Statusdisplay firmware 1.1
attr OG_Statusdisplay model HM-OU-LED16
attr OG_Statusdisplay room Wohnzimmer
attr OG_Statusdisplay serialNr JEQxxxxxxx
attr OG_Statusdisplay subType outputUnit
attr OG_Statusdisplay webCmd getConfig:clear msgEvents

define OG_Statusdisplay_Led_01 CUL_HM 1EAB5401
attr OG_Statusdisplay_Led_01 model HM-OU-LED16
attr OG_Statusdisplay_Led_01 peerIDs 00000000,

define OG_Statusdisplay_Led_02 CUL_HM 1EAB5402
attr OG_Statusdisplay_Led_02 model HM-OU-LED16
attr OG_Statusdisplay_Led_02 peerIDs 00000000,

define OG_Statusdisplay_Led_03 CUL_HM 1EAB5403
attr OG_Statusdisplay_Led_03 model HM-OU-LED16
attr OG_Statusdisplay_Led_03 peerIDs 00000000,

define OG_Statusdisplay_Led_04 CUL_HM 1EAB5404
attr OG_Statusdisplay_Led_04 model HM-OU-LED16
attr OG_Statusdisplay_Led_04 peerIDs 00000000,

define OG_Statusdisplay_Led_05 CUL_HM 1EAB5405
attr OG_Statusdisplay_Led_05 model HM-OU-LED16
attr OG_Statusdisplay_Led_05 peerIDs 00000000,

define OG_Statusdisplay_Led_06 CUL_HM 1EAB5406
attr OG_Statusdisplay_Led_06 model HM-OU-LED16
attr OG_Statusdisplay_Led_06 peerIDs 00000000,

define OG_Statusdisplay_Led_07 CUL_HM 1EAB5407
attr OG_Statusdisplay_Led_07 model HM-OU-LED16
attr OG_Statusdisplay_Led_07 peerIDs 00000000,

define OG_Statusdisplay_Led_08 CUL_HM 1EAB5408
attr OG_Statusdisplay_Led_08 model HM-OU-LED16
attr OG_Statusdisplay_Led_08 peerIDs 00000000,

define OG_Statusdisplay_Led_09 CUL_HM 1EAB5409
attr OG_Statusdisplay_Led_09 model HM-OU-LED16
attr OG_Statusdisplay_Led_09 peerIDs 00000000,

define OG_Statusdisplay_Led_10 CUL_HM 1EAB540A
attr OG_Statusdisplay_Led_10 model HM-OU-LED16
attr OG_Statusdisplay_Led_10 peerIDs 00000000,

define OG_Statusdisplay_Led_11 CUL_HM 1EAB540B
attr OG_Statusdisplay_Led_11 model HM-OU-LED16
attr OG_Statusdisplay_Led_11 peerIDs 00000000,

define OG_Statusdisplay_Led_12 CUL_HM 1EAB540C
attr OG_Statusdisplay_Led_12 model HM-OU-LED16
attr OG_Statusdisplay_Led_12 peerIDs 00000000,

define OG_Statusdisplay_Led_13 CUL_HM 1EAB540D
attr OG_Statusdisplay_Led_13 model HM-OU-LED16
attr OG_Statusdisplay_Led_13 peerIDs 00000000,

define OG_Statusdisplay_Led_14 CUL_HM 1EAB540E
attr OG_Statusdisplay_Led_14 model HM-OU-LED16
attr OG_Statusdisplay_Led_14 peerIDs 00000000,

define OG_Statusdisplay_Led_15 CUL_HM 1EAB540F
attr OG_Statusdisplay_Led_15 model HM-OU-LED16
attr OG_Statusdisplay_Led_15 peerIDs 00000000,

define OG_Statusdisplay_Led_16 CUL_HM 1EAB5410
attr OG_Statusdisplay_Led_16 model HM-OU-LED16
attr OG_Statusdisplay_Led_16 peerIDs 00000000,
</pre>

= Links =

* Anleitung: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/103206_HM-OU-LED16_UM_GE_V1.3_20120815.pdf PDF]

[[Kategorie:Schalter (Sender)]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:HomeMatic Components]]

HM-OU-LED16 Funk-Statusanzeige LED16

2015-01-05T09:19:09Z

Reibuehl: /* fhem.cfg */

{{Infobox Hardware
|Bild=HM-OU-LED16.jpg
|Bildbeschreibung=HomeMatic Funk-Statusanzeige LED16
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=16 (3 Tasten, Hoch, Runter und Enter)
|HWVoltage=7,5 V DC (über mitgeliefertes Steckernetzteil
|HWPowerConsumption=max. 250 mA
|HWPoweredBy=Netz
|HWSize=100x100x15mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

= Features =
Anzeige von 16 Statuswerten über rot/grün/orange LED

= Allgemeines =
Die Funk-Statusanzeige LED16 kann mit ihren 16 Kanälen und insgesamt 32 LED's (je 1xGrün und 1xRot -> Rot+Grün=Orange) diverse Stati anzeigen.
Das Schriftfeld ist nicht beleuchtet und kann mit einer Word-Vorlage befüllt werden.
Außerdem kann man sie auch als 16-Kanal Funk-Fernbedienung verwenden. Hier ist die Auswahl des Kanals allerdings etwas umständlich. Mit Hilfe der Hoch- und Runtertaste auf der Rückseite kann man den Kanal, der durch ein blinken der jeweiligen LED's angezeigt wird, auswählen und seine Wahl mit der, ebenfalls auf der Rückseite liegenden Enter-Taste bestätigen.

= Hinweise zur Inbetriebnahme und Installation =

Die Funk-Statusanzeige kann nicht direkt gepeered werden sondern funktioniert nur mit einer Zentrale, wie z.B. FHEM.
<Bitte ergänzen>

= Probleme =

<ggfls. ergänzen>
= Betrieb mit FHEM =

== event Monitor ==

<Bitte ergänzen>
== fhem.log Auszug ==

<Bitte ergänzen>
== fhem.cfg ==

<pre>
define OG_Statusdisplay CUL_HM 1EAB54
attr OG_Statusdisplay IODev HMLAN1
attr OG_Statusdisplay autoReadReg 4_reqStatus
attr OG_Statusdisplay expert 2_full
attr OG_Statusdisplay firmware 1.1
attr OG_Statusdisplay model HM-OU-LED16
attr OG_Statusdisplay room Wohnzimmer
attr OG_Statusdisplay serialNr JEQxxxxxxx
attr OG_Statusdisplay subType outputUnit
attr OG_Statusdisplay webCmd getConfig:clear msgEvents

define OG_Statusdisplay_Led_01 CUL_HM 1EAB5401
attr OG_Statusdisplay_Led_01 model HM-OU-LED16
attr OG_Statusdisplay_Led_01 peerIDs 00000000,

define OG_Statusdisplay_Led_02 CUL_HM 1EAB5402
attr OG_Statusdisplay_Led_02 model HM-OU-LED16
attr OG_Statusdisplay_Led_02 peerIDs 00000000,

define OG_Statusdisplay_Led_03 CUL_HM 1EAB5403
attr OG_Statusdisplay_Led_03 model HM-OU-LED16
attr OG_Statusdisplay_Led_03 peerIDs 00000000,

define OG_Statusdisplay_Led_04 CUL_HM 1EAB5404
attr OG_Statusdisplay_Led_04 model HM-OU-LED16
attr OG_Statusdisplay_Led_04 peerIDs 00000000,

define OG_Statusdisplay_Led_05 CUL_HM 1EAB5405
attr OG_Statusdisplay_Led_05 model HM-OU-LED16
attr OG_Statusdisplay_Led_05 peerIDs 00000000,

define OG_Statusdisplay_Led_06 CUL_HM 1EAB5406
attr OG_Statusdisplay_Led_06 model HM-OU-LED16
attr OG_Statusdisplay_Led_06 peerIDs 00000000,

define OG_Statusdisplay_Led_07 CUL_HM 1EAB5407
attr OG_Statusdisplay_Led_07 model HM-OU-LED16
attr OG_Statusdisplay_Led_07 peerIDs 00000000,

define OG_Statusdisplay_Led_08 CUL_HM 1EAB5408
attr OG_Statusdisplay_Led_08 model HM-OU-LED16
attr OG_Statusdisplay_Led_08 peerIDs 00000000,

define OG_Statusdisplay_Led_09 CUL_HM 1EAB5409
attr OG_Statusdisplay_Led_09 model HM-OU-LED16
attr OG_Statusdisplay_Led_09 peerIDs 00000000,

define OG_Statusdisplay_Led_10 CUL_HM 1EAB540A
attr OG_Statusdisplay_Led_10 model HM-OU-LED16
attr OG_Statusdisplay_Led_10 peerIDs 00000000,

define OG_Statusdisplay_Led_11 CUL_HM 1EAB540B
attr OG_Statusdisplay_Led_11 model HM-OU-LED16
attr OG_Statusdisplay_Led_11 peerIDs 00000000,

define OG_Statusdisplay_Led_12 CUL_HM 1EAB540C
attr OG_Statusdisplay_Led_12 model HM-OU-LED16
attr OG_Statusdisplay_Led_12 peerIDs 00000000,

define OG_Statusdisplay_Led_13 CUL_HM 1EAB540D
attr OG_Statusdisplay_Led_13 model HM-OU-LED16
attr OG_Statusdisplay_Led_13 peerIDs 00000000,

define OG_Statusdisplay_Led_14 CUL_HM 1EAB540E
attr OG_Statusdisplay_Led_14 model HM-OU-LED16
attr OG_Statusdisplay_Led_14 peerIDs 00000000,

define OG_Statusdisplay_Led_15 CUL_HM 1EAB540F
attr OG_Statusdisplay_Led_15 model HM-OU-LED16
attr OG_Statusdisplay_Led_15 peerIDs 00000000,

define OG_Statusdisplay_Led_16 CUL_HM 1EAB5410
attr OG_Statusdisplay_Led_16 model HM-OU-LED16
attr OG_Statusdisplay_Led_16 peerIDs 00000000,
</pre>

= Links =

* Anleitung: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/103206_HM-OU-LED16_UM_GE_V1.3_20120815.pdf PDF]

[[Kategorie:Schalter (Sender)]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:HomeMatic Components]]

HM-OU-LED16 Funk-Statusanzeige LED16

2015-01-05T09:16:59Z

Reibuehl: fhem.cfg Auszug hinzugefügt

{{Infobox Hardware
|Bild=HM-OU-LED16.jpg
|Bildbeschreibung=HomeMatic Funk-Statusanzeige LED16
|HWProtocol=HomeMatic
|HWType=Empfänger, Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=16 (3 Tasten, Hoch, Runter und Enter)
|HWVoltage=7,5 V DC (über mitgeliefertes Steckernetzteil
|HWPowerConsumption=max. 250 mA
|HWPoweredBy=Netz
|HWSize=100x100x15mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

= Features =
Anzeige von 16 Statuswerten über rot/grün/orange LED

= Allgemeines =
Die Funk-Statusanzeige LED16 kann mit ihren 16 Kanälen und insgesamt 32 LED's (je 1xGrün und 1xRot -> Rot+Grün=Orange) diverse Stati anzeigen.
Das Schriftfeld ist nicht beleuchtet und kann mit einer Word-Vorlage befüllt werden.
Außerdem kann man sie auch als 16-Kanal Funk-Fernbedienung verwenden. Hier ist die Auswahl des Kanals allerdings etwas umständlich. Mit Hilfe der Hoch- und Runtertaste auf der Rückseite kann man den Kanal, der durch ein blinken der jeweiligen LED's angezeigt wird, auswählen und seine Wahl mit der, ebenfalls auf der Rückseite liegenden Enter-Taste bestätigen.

= Hinweise zur Inbetriebnahme und Installation =

Die Funk-Statusanzeige kann nicht direkt gepeered werden sondern funktioniert nur mit einer Zentrale, wie z.B. FHEM.
<Bitte ergänzen>

= Probleme =

<ggfls. ergänzen>
= Betrieb mit FHEM =

== event Monitor ==

<Bitte ergänzen>
== fhem.log Auszug ==

<Bitte ergänzen>
== fhem.cfg ==

define OG_Statusdisplay CUL_HM 1EAB54
attr OG_Statusdisplay IODev HMLAN1
attr OG_Statusdisplay autoReadReg 4_reqStatus
attr OG_Statusdisplay expert 2_full
attr OG_Statusdisplay firmware 1.1
attr OG_Statusdisplay model HM-OU-LED16
attr OG_Statusdisplay room Wohnzimmer
attr OG_Statusdisplay serialNr JEQxxxxxxx
attr OG_Statusdisplay subType outputUnit
attr OG_Statusdisplay webCmd getConfig:clear msgEvents

define OG_Statusdisplay_Led_01 CUL_HM 1EAB5401
attr OG_Statusdisplay_Led_01 model HM-OU-LED16
attr OG_Statusdisplay_Led_01 peerIDs 00000000,

define OG_Statusdisplay_Led_02 CUL_HM 1EAB5402
attr OG_Statusdisplay_Led_02 model HM-OU-LED16
attr OG_Statusdisplay_Led_02 peerIDs 00000000,

define OG_Statusdisplay_Led_03 CUL_HM 1EAB5403
attr OG_Statusdisplay_Led_03 model HM-OU-LED16
attr OG_Statusdisplay_Led_03 peerIDs 00000000,

define OG_Statusdisplay_Led_04 CUL_HM 1EAB5404
attr OG_Statusdisplay_Led_04 model HM-OU-LED16
attr OG_Statusdisplay_Led_04 peerIDs 00000000,

define OG_Statusdisplay_Led_05 CUL_HM 1EAB5405
attr OG_Statusdisplay_Led_05 model HM-OU-LED16
attr OG_Statusdisplay_Led_05 peerIDs 00000000,

define OG_Statusdisplay_Led_06 CUL_HM 1EAB5406
attr OG_Statusdisplay_Led_06 model HM-OU-LED16
attr OG_Statusdisplay_Led_06 peerIDs 00000000,

define OG_Statusdisplay_Led_07 CUL_HM 1EAB5407
attr OG_Statusdisplay_Led_07 model HM-OU-LED16
attr OG_Statusdisplay_Led_07 peerIDs 00000000,

define OG_Statusdisplay_Led_08 CUL_HM 1EAB5408
attr OG_Statusdisplay_Led_08 model HM-OU-LED16
attr OG_Statusdisplay_Led_08 peerIDs 00000000,

define OG_Statusdisplay_Led_09 CUL_HM 1EAB5409
attr OG_Statusdisplay_Led_09 model HM-OU-LED16
attr OG_Statusdisplay_Led_09 peerIDs 00000000,

define OG_Statusdisplay_Led_10 CUL_HM 1EAB540A
attr OG_Statusdisplay_Led_10 model HM-OU-LED16
attr OG_Statusdisplay_Led_10 peerIDs 00000000,

define OG_Statusdisplay_Led_11 CUL_HM 1EAB540B
attr OG_Statusdisplay_Led_11 model HM-OU-LED16
attr OG_Statusdisplay_Led_11 peerIDs 00000000,

define OG_Statusdisplay_Led_12 CUL_HM 1EAB540C
attr OG_Statusdisplay_Led_12 model HM-OU-LED16
attr OG_Statusdisplay_Led_12 peerIDs 00000000,

define OG_Statusdisplay_Led_13 CUL_HM 1EAB540D
attr OG_Statusdisplay_Led_13 model HM-OU-LED16
attr OG_Statusdisplay_Led_13 peerIDs 00000000,

define OG_Statusdisplay_Led_14 CUL_HM 1EAB540E
attr OG_Statusdisplay_Led_14 model HM-OU-LED16
attr OG_Statusdisplay_Led_14 peerIDs 00000000,

define OG_Statusdisplay_Led_15 CUL_HM 1EAB540F
attr OG_Statusdisplay_Led_15 model HM-OU-LED16
attr OG_Statusdisplay_Led_15 peerIDs 00000000,

define OG_Statusdisplay_Led_16 CUL_HM 1EAB5410
attr OG_Statusdisplay_Led_16 model HM-OU-LED16
attr OG_Statusdisplay_Led_16 peerIDs 00000000,

= Links =

* Anleitung: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/103206_HM-OU-LED16_UM_GE_V1.3_20120815.pdf PDF]

[[Kategorie:Schalter (Sender)]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:HomeMatic Components]]

Datei:HM-OU-LED16.jpg

2015-01-05T09:12:09Z

Reibuehl:

2014-01-20T12:08:01Z

Reibuehl:

== Features ==
Die FlammEx Rauchmelder der Serie FL 100 sind VdS-zertifizierte Rauchmelder, die über Kabel oder ein optionales Funk-Vernetzungsmodul untereinander und unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden können.

FlammEx bietet die Funk-Vernetzungsmodule sowohl in einer 433 MHz als auch in einer 868 MHz Variante an.

== Hinweise zum Betrieb mit FHEM ==
Da das von den Funk-Vernetzungsmodulen verwendete Protokoll proprietär und bisher noch nicht über FHEM Sender wie [[CUL]] verwendbar ist, besteht momentan nur die Möglichkeit, die Rauchmelder über ein Funkmodul anzubinden, das bereits von FHEM unterstützt wird.

Aufgrund des geringen Preises bieten sich hier die FS20 oder HomeMatic Funk-Tür-/Fensterkontakt an. Am Beispiel eines HomeMatic [[HM-SEC-SC Tür-Fensterkontakt]] soll hier beschrieben werden, wie die Rauchmelder an FHEM angebunden werden können.

=== Hardware ===
Benötig werden:

* FlammEx FL 100 Rauchmelder mit Funk-Vernetzungsmodul
* FlammEx Relaismodul FL 00 4738K
* FlammEx Anschlussdose FL 100 KAD
* HomeMatic [[HM-SEC-SC Tür-Fensterkontakt]]
* etwas zweiadriges Kabel, Lötkolben und Werkzeug

Der [[HM-SEC-SC Tür-Fensterkontakt]] wird wie in der unten Verlinkten Anleitung aus dem FHEM Forum mit zwei Anschlußdrähten versehen. Diese werden rechts und links an den Reed-Kontakt angelötet. Die Kabel können dann durch die bestehende Öffnung in der Batteriefachabdeckung nach außen geführt werden.

[[Datei:FlammEx1.JPG|600px]]

Anschließend wird das Relaismodul mit dem Funk-Vernetzungsmodul des Rauchmelders verbunden und in die Anschlussdose gesetzt. Der HM-SEC-SC passt auch noch in die Dose. Die beiden am HM-SEC-SC festgelöteten Kabel werden jetzt mit den Schließer-Kontakten des Relaismoduls verbunden und dann kann alles montiert werden.

[[Datei:FlammEx2.JPG|600px]]

Da am Rauchmelder und am Funk-Vernetzungsmodul keine Modifikationen vorgenommen werden, sollte es hinsichtlich der VdS-Zertifizierung und Garantie keine Probleme geben. Die Garantie des HM-SEC-SC erlischt natürlich durch das anlöten der Kabel!

[[Datei:FlammEx3.JPG|600px]]

=== FHEM Config-Auszug ===
Beispiel für die Konfiguration der Einbindung über einen [[HM-SEC-SC Tür-Fensterkontakt]]:

ssssss -> 6-stellige hexadezimale Seriennummer. (Siehe Logfile: CUL_HM Unknown device CUL_HM_SD_ssssss, please define it)

xxxxxxxxxx -> 10-stellige Seriennummern (vom Aufkleber auf dem Gerät)

define Rauchmelder CUL_HM ssssss
attr Rauchmelder .devInfo 810101
attr Rauchmelder .stc 80
attr Rauchmelder actCycle 028:00
attr Rauchmelder actStatus dead
attr Rauchmelder autoReadReg 4_reqStatus
attr Rauchmelder expert 2_full
attr Rauchmelder firmware 2.1
attr Rauchmelder model HM-SEC-SC
attr Rauchmelder peerIDs
attr Rauchmelder room Flur
attr Rauchmelder serialNr xxxxxxxxxx
attr Rauchmelder subType threeStateSensor

== Links ==
Anleitung zur Modifikation des HM-Sec-Sc Funk-Tür-/Fensterkontakt [http://forum.fhem.de/index.php/topic,12379.0.html]

[[Kategorie:Other Components]]