http://wiki.fhem.de/w/api.php?action=feedcontributions&user=BerndArnold&feedformat=atomFHEMWiki - Benutzerbeiträge [de]2024-03-28T15:03:08ZBenutzerbeiträgeMediaWiki 1.39.3http://wiki.fhem.de/w/index.php?title=TR%C3%85DFRI&diff=35184TRÅDFRI2021-03-10T20:17:25Z<p>BerndArnold: Beispiel zu Ikea Remote Control hinzugefügt</p>
<hr />
<div><div style="float:right">{{Infobox Modul<br />
|Name=tradfri<br />
|ModPurpose=Anbindung IKEA TRÅDFRI Gateway<br />
|ModType=d<br />
<!-- |ModCategory= (noch?) nicht verwendet --><br />
|ModCmdRef=tradfri<br />
|ModForumArea=Zigbee<br />
|ModTechName=30_tradfri.pm<br />
|ModOwner=Andre ([http://forum.fhem.de/index.php?action=profile;u=430 Forum] / [[Benutzer Diskussion:justme|Wiki]])<br />
}}<br />
</div><br />
<br />
'''TRÅDFRI''' bzw. '''IKEA Home smart''' ist die Serie smarter Beleuchtungslösungen von IKEA auf ZigBee-Basis, ähnlich Phillips Hue.<br />
<br />
== tradfri ==<br />
<br />
TRÅDFRI (nach Umbennung jetzt '''IKEA Home smart''') ist die Serie smarter Beleuchtungslösungen von IKEA. Ähnlich wie von Phillips [[Hue]] gibt es diverse LEDs in Glühbirnenform, LED-Streifen-Treiber, Flächenleuchten, Wandtaster, Bewegungsmelder, Fernbedienung, Dimmer, etc. und alles via Funk gekoppelt. Außerdem ein Gateway, das sich via Ethernetstecker ins heimische LAN einbinden lässt und die Bedienung via IKEA-App auf dem Handy ermöglicht. <br />
{{Hinweis|Da die Geräte über den [[ZigBee]]-Standard kommunizieren, können auch andere Gateways für diese Leuchtmittel (und andere Geräte wie Rollos) genutzt werden. Dieser Artikel behandelt ausschließlich die Verwendung zusammen mit einem IKEA-Gateway!}}<br />
Mit dem IKEA-Gateway ist auch eine Anbindung in FHEM möglich, dazu funktionieren zwei '''alternative''' Lösungen:<br />
<br />
=== alt: IKEA Trådfri Modul ===<br />
IKEA Trådfri Modul (TYPE ''TradfriDevice'' und ''TradfriGateway'', mehr Infos: https://forum.fhem.de/index.php/topic,70653.0.html seit April 2017)<br />
* Erkennt Lampen<br />
* Fernbedienung erscheint zwar in der Geräteliste, lässt sich aber nicht als Gerät anlegen oder Status lesen<br />
<br />
Die Weiterentwicklung des Moduls durch den ursprünglichen Entwickler scheint Stand 07.19 eingestellt. Inwieweit andere am Modul weiter arbeiten ist unklar.<br />
<br />
=== neu: tradfri-fhem Modul ===<br />
tradfri-fhem Modul (TYPE ''HUEDevice'' und ''tradfri'' Gateway, mehr Infos: https://forum.fhem.de/index.php/topic,96125.0.html seit Januar 2019, Beschreibung folgt auf dieser Seite)<br />
* Unterstützt Lampen (als [[Hue#HUE-Device|HUE-Device]])<br />
* Unterstützt Rollos (Fyrtur und Kadrilj) <br />
* Erkennt Fernbedienung, jedoch zur Zeit Batteriestatus als einziges Reading<br />
* Erstellt (wenn gewünscht) automatisch Gruppen<br />
* Erkennt Bewegungsmelder, jedoch zur Zeit Batteriestatus als einziges Reading<br />
* Erkennt Repeater, nur Erreichbarkeit (reachable) als Reading <br />
<br />
====Einrichtung in FHEM====<br />
<br />
# node installieren (mindestens version 8)<br />
# sudo npm install -g tradfri-fhem<br />
# <code>define <tradfri> tradfri</code><br />
# <code>attr <tradfri> tradfriFHEM-securityCode <security code></code><br />
<br />
wenn das gateway nicht automatisch erkannt wird:<br />
<code>attr <tradfri> tradfriFHEM-params --ip <ip></code><br />
<br />
WICHTIG: danach in FHEM einmal die Konfiguration speichern damit der Pairing-Key gesichert wird. Sonst muss beim nächsten FHEM-Neustart das Pairing erneut durchgeführt werden.<br />
<br />
==== HUE-Device ====<br />
Alle auf dem Gateway bekannten Geräte automatisch als [[Hue#HUE-Device|HUEDevice]] in FHEM angelegt:<br />
* Lampen, Stecker, Trafos, ...<br />
: Hiermit werden die einzelnen Leuchten gesteuert<br />
* Gruppen<br />
: Hiermit lassen sich ganze Gruppen und Räume steuern<br />
* Fernbedienungen<br />
: aktuell gibt es nur ein Battery-Reading<br />
<br />
==== Darstellung im Webfrontend ====<br />
Wenn man die SVG Icons verwendet ist es sinnvoll, das Attribut color-icons zu setzen. Mit <code>attr HUEDevice1 color-icons 2</code> werden z.B. die Farben und der Dimmzustand der Lampe als Icon dargestellt.<br />
Damit das ganze funktioniert, müsst ihr auch noch das <code>attr WEB iconPath fhemSVG:openautomation:default</code> setzen.<br />
<br />
=== Beispiel Tradfri Remote Control mit Conbee ===<br />
<br />
[[Datei: Ikea-Tradfri-RemoteControl.jpeg|200px|thumb|right|Die Remote-Control von Ikea]] <br />
<br />
Hier ist ein konkretes Beispiel, die Remote Control in Fhem zu integrieren. Vorausgehend muss die Remote Control bereits ins Zigbee-Netz über den Conbee-Stick (Deconz) aufgenommen worden sein.<br />
<br />
Mit <code>get <zigbeedevice> sensors</code> bekommt man eine Liste. Die Zahl (ID) zu Beginn der Zeile vor "TRÅDFRI remote control" merken.<br />
<br />
Nun ein neues Device anlegen: <code>def Zigbee_IkeaRemoteControl HUEDevice sensor <ID> IODev=<zigbeedevice></code> (Namen entsprechend anpassen).<br />
<br />
Im STATE von Zigbee_IkeaRemoteControl erscheint nun ein vierstelliger Code beim Drücken der Tasten. Die Tasten oben und unten (mit den Sonnensymbolen) reagieren auf längeren Tastendruck. Für die einzelnen Codes siehe Bild.<br />
<br />
Zur Steuerung anderer Geräte kann ein DOIF oder ein Notify verwendet werden.<br />
<br />
Beispiel DOIF (kopiert aus der Raw-Definition):<br />
<br />
<pre>defmod Zigbee_IkeaRemoteControl.DOIF DOIF ( [Zigbee_IkeaRemoteControl] eq "1002" ) ({\<br />
fhem( "set Licht on-for-timer 5" );;\<br />
fhem( "set Pushover msg 'Türklingel' 'Bimmelimm' 'iPhone,iPad' 0 'bike'" );;\<br />
fhem( "set MQTT_Aktionen msgOut DoorBell bimmelimm" );;\<br />
})\<br />
<br />
attr Zigbee_IkeaRemoteControl.DOIF do always</pre><br />
<br />
<br />
== Links ==<br />
* [https://github.com/peterkappelt/Tradfri-FHEM/issues/16#issuecomment-445461242 Githubeintrag über Einstellung der Feature-Entwicklung des IKEA Trådfri Moduls].<br />
* [https://wiki.fhem.de/wiki/Hue#RaspBee_.26_ConBee Betrieb von IKEA smart home Devices mit Dritthersteller Gateway wie ConBee2]<br />
[[Kategorie:ZigBee]]<br />
[[Kategorie:Lichteffektgeräte]]<br />
[[Kategorie:IP Components]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Datei:Ikea-Tradfri-RemoteControl.jpeg&diff=35183Datei:Ikea-Tradfri-RemoteControl.jpeg2021-03-10T19:55:02Z<p>BerndArnold: Remote Control, Quelle: eigenes Foto,</p>
<hr />
<div>== Beschreibung ==<br />
Remote Control, Quelle: eigenes Foto,</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=ABFALL&diff=33628ABFALL2020-07-28T10:13:55Z<p>BerndArnold: Wikify</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Filtern von (Abfall-)Terminen aus einem Calendar.<br />
|ModType=x<br />
|ModFTopic=48237<br />
|ModForumArea=Codeschnipsel<br />
|ModTechName=57_ABFALL.pm<br />
|ModOwner=Constantin / {{Link2FU|14026|uniqueck}}<br />
}}<br />
<br />
[[ABFALL]] ist ein (inoffizielles, nicht Bestandteil der Distribution) Hilfsmodul, das bestimmte Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt. <br />
<br />
== Voraussetzungen ==<br />
Es muss ein [[Calendar]]-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des ABFALL-Objekts spezifiziert werden.<br />
Es können auch mehrere Calendar Objekte übergeben werden.<br />
<br />
Sonderzeichen aus dem Namen der Termine, werden entfernt um die Namen der generierten Readings FHEM tauglich zu machen, für die Werte der Readings bleiben diese allerdings erhalten.<br />
<br />
== Anwendung ==<br />
=== Installation ===<br />
Mit folgendem Befehl kann das Modul direkt in den Standard FHEM Update Prozess eingeklinkt werden.<br />
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code><br />
Um es nur zu installieren, kann auch einfach nur das Command<br />
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code><br />
eingegeben werden.<br />
<br />
=== Entwicklungsstrang ===<br />
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code><br />
bzw.<br />
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code><br />
<br />
=== Define ===<br />
:<code>define <Name> ABFALL <calendarname>,<calendarname2>,...</code><br />
<br />
Erläuterung der Parameter im '''define''':<br />
;<calendarname><br />
:Name des '''Calendar''' Kalenders <br />
<br />
Beispiel:<br />
:<code>define AbfallGoogleCalender Calendar ical url https://......</code><br />
:<code>define myABFALL ABFALL AbfallGoogleCalender</code><br />
<br />
=== Werte aktualisieren ===<br />
Die Werte aktualisieren sich abhängig vom [[notify]] der entsprechenden Calendar Instanz, welche im define angegeben wurde(n).<br />
<br />
=== Weitere Attribute ===<br />
<br />
{| class="wikitable"<br />
!Attribut<br />
!Werteliste<br />
!Beschreibung<br />
!Default Wert<br />
|-<br />
!align="right" |calendarname_praefix<br />
|0 und 1<br />
|soll der Kalendername als praefix dem Reading vorangestellt werden, sollte bei nur einem Kalender auf 0 gesetzt werden<br />
|1 - praefix wird vorangestellt, sofern mehrere Kalender angegeben wurden, ansonsten 0 - praefix wird nicht vorangestellt<br />
|-<br />
!align="right" |abfall_clear_reading_regex<br />
|<br />
|regex zum Entfernen von Anteilen aus dem Termin, dieser wird vor dem Entfernen von Sonderzeichen aus den Namen der Termine angewandt.<br />
|<br />
|-<br />
!align="right" |disable<br />
|0 und 1<br />
|deaktiviert das Modul<br />
|0<br />
|-<br />
!align="right" |weekday_mapping<br />
|<br />
|Mapping, wie die Readings der Tage angezeigt werden sollen, zum Beispiel So Mo Di Mi Do Fr Sa<br />
|Sonntag Montag Dienstag Mittwoch Donnerstag Freitag Samstag<br />
|-<br />
!align="right" |delimiter_text_reading<br />
|<br />
|Wenn zwei Abholungen an ein und demselben Tag existieren, wird dieses Trennzeichen genutzt, um die beiden (oder mehrere) Werte zu einem Text zu verbinden. Nur relevant für die Readings next_text und now_text<br />
|und<br />
|-<br />
!align="right" |delimiter_reading<br />
|<br />
|wie attribute delimiter_text_reading, allerdings nur für die readings next und now<br />
|<br />
|-<br />
!align="right" |filter<br />
|<br />
|regex zum Filtern der Namen der Termine aus den Kalendern, so dass nur solche genutzt werden, welche diesem Filter entsprechen<br />
|<br />
|-<br />
|}<br />
<br />
== Anwendungsbeispiel(e) ==<br />
=== Einbindung ins Tablet UI ===<br />
<pre><div data-device="myABFALL" data-type="symbol" class="bigger warn wider" <br />
data-get="next" data-get-warn=".*(\d+).*" <br />
data-get-on='["Restmuell_.*","Wertstoff_.*"]'<br />
data-colors='["#000","#6EB54C"]' <br />
data-icons='["fa-trash-o","fa-trash-o"]'></div></pre><br />
<br />
=== Einbindung ins Tablet UI, erweitert ===<br />
Fallen die Leerungen zweier verschiedener Tonnen nicht auf den selben Tag, reicht es normalerweise, nur ein Symbol auf der Oberfläche zu platzieren und dieses dann dynamisch zu befüllen. In folgendem Beispiel werden folgende Anforderungen umgesetzt:<br />
* Anzeige unterschiedlicher Symbole bzw. Farben für Papiertonne, Restmülltonne, Biotonne und gelbe Säcke<br />
* Anzeige der verbleibenden Tage bis zur Leerung als "Warn"-Marker in Rot, aber nur, wenn die Leerung innerhalb der nächsten 2 Tage ist<br />
* Blinken des Symbols, wenn die nächste Leerung morgen ansteht<br />
* Rotation des Symbols, wenn die nächste Leerung noch am selben Tag ansteht. Nach einer bestimmten Uhrzeit (z.B. 9 Uhr morgens) soll dann auf die nächste Tonne geschaltet werden<br />
* Anzeige des Datums bzw. von "heute" oder "morgen" unter dem Symbol als Label<br />
<br />
Zur Datumsanzeige wird eine kleine Hilfsfunktion in die 99_myUtils eingebaut. <br />
<syntaxhighlight lang="perl"><br />
sub datumHeuteMorgen($){<br />
my $compareDate = shift;<br />
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);<br />
$year += 1900; $mon += 1; <br />
my $heute = sprintf('%02d.%02d.%04d', $mday, $mon, $year);<br />
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time+86400);<br />
$year += 1900; $mon += 1;<br />
my $morgen = sprintf('%02d.%02d.%04d', $mday, $mon, $year);<br />
return "heute" if $compareDate eq $heute;<br />
return "morgen" if $compareDate eq $morgen;<br />
return $compareDate;<br />
}<br />
</syntaxhighlight><br />
Diese Funktion wird in den userReadings des Abfall-Moduls verwendet. Das Abfallmodul erzeugt eine Gruppe von Readings mit dem Namen now_*, wenn die Leerung am selben Tag ansteht, bzw. genau dann, wenn der Termin im zu Grunde liegenden Kalender gerade aktiv ist. In diesem Beispiel liegt dem Kalender-Modul ein Google-Kalender zu Grunde, bei dem die Termine immer von 0 Uhr bis 9 Uhr morgens eingetragen sind. Dadurch wird erreicht, dass die Anzeige nach 9 Uhr weiterspringt, weil dann die now-Readings verschwinden.<br />
<br />
Folgende userReadings werden zum Abfallmodul hinzugefügt, welches in diesem Beispiel "myABFALL" genannt ist:<br />
<syntaxhighlight lang="perl"><br />
attr myABFALL userReadings ftui_datum {ReadingsVal("myABFALL","now_text","") eq "" ? datumHeuteMorgen(ReadingsVal("myABFALL","next_date","")) : "heute";},ftui_next {ReadingsVal("myABFALL","now_text","") eq "" ? ReadingsVal("myABFALL","next","") : ReadingsVal("myABFALL","now","")."_0";;}<br />
</syntaxhighlight><br />
Das Reading "ftui_next" bildet die Grundlage für das Symbol in TabletUI, das Reading "ftui_datum" wird für das Label genutzt. <br />
<br />
Somit lässt sich ganze in FTUI wie folgt darstellen:<br />
<syntaxhighlight lang="html"><br />
<div data-device="myABFALL" <br />
data-type="symbol"<br />
data-get="ftui_next"<br />
data-get-on='["Biotonne_0$","Biotonne_1$","Biotonne_.*","GelberSack_0$","GelberSack_1$","GelberSack_.*","Papiertonne_0$","Papiertonne_1$","Papiertonne_.*","Restmuelltonne_0$","Restmuelltonne_1$","Restmuelltonne_.*"]'<br />
data-get-warn=".*([0|1|2]).*"<br />
data-colors='["#8B4513","#8B4513","#8B4513","#f4e946","#f4e946","#f4e946","#2d9e1c","#2d9e1c","#2d9e1c","#696969","#696969","#696969"]'<br />
class="large warn"<br />
data-icons='["fa-trash-o fa-spin","fa-trash-o blink","fa-trash-o","fs-bag fa-spin","fs-bag blink","fs-bag","fs-dustbin fa-spin","fs-dustbin blink","fs-dustbin","fa-trash fa-spin","fa-trash blink","fa-trash"]'<br />
/><br />
<div data-device="myABFALL" data-get="ftui_datum" data-type="label"/><br />
</syntaxhighlight><br />
Für Jede Tonne werden hier drei Zustände unterschieden und einzeln in "data-get-on", "data-on-colors" und "data-icons" zugeordnet. Daher haben diese Listen jeweils 12 Einträge.<br />
<br />
=== Benachrichtigung ===<br />
==== DOIF ====<br />
====== TelegramBot Beispiel ======<br />
<pre>[myABFALL:next_days] == 1) ( set fhemBot message 'Morgen wird [myABFALL:next_text] abgeholt')<br />
[myABFALL:now_text] ne "") ( set fhemBot message 'Heute wird [myABFALL:now_text] abgeholt')</pre><br />
<br />
====== Pushbullet Beispiel ======<br />
<br />
Die morgigen Leerungen per Push um 19:30 mittels [[Pushbullet]]:<br />
<br />
<code>define dAbfallmorgen doif ([19:30] and [myABFALL:next_days] == 1) ( msg |Morgen wird [myABFALL:next_text] abgeholt)<br />
<br />
attr dAbfallmorgen do always</code><br />
<br />
Die heutigen Leerungen per Push um 07:00 mittels Pushbullet:<br />
<br />
<code>define dAbfallheute doif ([07:00] and [myABFALL:now_text] ne "") ( msg |Heute wird [myABFALL:now_text] abgeholt)<br />
<br />
attr dAbfallheute do always</code><br />
<br />
=== Links ===<br />
* Forenthema {{Link2Forum|Topic=50177|LinkText=Abfall Visualisierung mit Bilderrahmen}}</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HMS_100_TF&diff=29976HMS 100 TF2019-03-23T18:37:37Z<p>BerndArnold: Platzhalter durch Bild vom HMS 100 TF ersetzt; Daten vom HMS 100 TFK übernommen</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HMS_100_TF.png<br />
|Bildbeschreibung=HMS 100 TF<br />
|HWProtocol=HMS<br />
|HWType=Sensor/Sender<br />
|HWCategory=HMS<br />
|HWComm=868MHz<br />
|HWChannels=?<br />
|HWVoltage=3V<br />
|HWPowerConsumption=?<br />
|HWPoweredBy=2x1,5V Mignon AA<br />
|HWSize=70x100x24mm<br />
|HWDeviceFHEM=12_HMS.pm<br />
|HWManufacturer=ELV / eQ-3 <br />
}}<br />
<br />
Der [[HMS 100 TF]] ist ein Temperatur-/Luftfeuchte-Sensor in einem Gerät<br />
<br />
== Features ==<br />
Anders als beim '''HMS 100 T''', bei dem der Temperatursensor mit einem ca. 1 m langen Kabel abgesetzt ist, sind hier die beiden Sensoren für Temperatur und Luftfeuchtigkeit im Gehäuse untergebracht.<br />
<br />
* Der Temperaturmessbereich erstreckt sich von -30°C bis +70°C<br />
* Die Messgenauigkeit der Luftfeuchtigkeit liegt bei +/- 8% und hat eine Auflösung von 1%<br />
<br />
Der Sensor meldet alle 5 Minuten die gemessenen Temperatur- und Luftfeuchtewerte an die Zentrale und gibt dabei auch eine Statusmeldung ab, die den Batteriezustand beinhaltet. Ein Sendevorgang wird durch das Aufleuchten der Kontrollleuchte auf der Vorderseite der Auswerte- und Sendeeinheit signalisiert.<br />
Bei meinem HMS kommen die Daten regelmässig in FHEM an, allerdings leuchtet die Kontrolleuchte auf der Vorderseite '''nicht''' auf.<br />
<br />
== Readings ==<br />
{| class="wikitable" <br />
! Parameter <br />
! Wertbeispiel <br />
! Erklärung<br />
|- <br />
| battery <br />
| replaced <br />
| Ladezustand der Batterie<br />
|- <br />
| humidity <br />
| 25.8 <br />
| relative Luftfeuchte in Prozent<br />
|- <br />
| temperature <br />
| 24.3 <br />
| Temperatur in °C<br />
|- <br />
| state <br />
| T: 20.7 H: 25.8 Bat: replaced <br />
| Zusammenfassung einiger Werte<br />
|- <br />
| type<br />
| HMS100TF <br />
| Typenbezeichnung<br />
|}<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Wenn [[autocreate]] aktiv ist, erkennt FHEM automatisch das HMS Gerät. Anderenfalls erscheint im Logfile von FHEM die Meldung:<br />
:<code>Unknown HMS device detected, define one to get detailed information.</code><br />
Wird nun ein HMS Gerät in der [[Konfiguration]] definiert, erscheint auch der Hauscode des HMS device.<br />
<br />
:<code>define Dachboden HMS 1234</code><br />
:<code>Unknown HMS device 1000/da1f, please define it</code><br />
Der beispielhaft gewählte Hauscode 1234 kann nun durch den erkannten Hauscode da1f ersetzt werden, und schon ist der HMS 100 TF einsatzbereit.<br />
:<code>define Dachboden HMS da1f</code><br />
<br />
== Bekannte Probleme ==<br />
Keine<br />
<br />
== Ähnliche Geräte ==<br />
Eine ähnliche Funktion bietet der [[S300TH]], der jedoch deutlich weniger kostet.<br />
<br />
== Link ==<br />
* Bedienungsanleitung (PDF {{DocLink|elv|/service/manuals/HMS100TF/HMS100TF_UM_G_030226.pdf}})<br />
<br />
[[Kategorie:HMS Components]]<br />
[[Kategorie:Feuchtesensoren]]<br />
[[Kategorie:Temperatursensoren]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Datei:HMS_100_TF.png&diff=29975Datei:HMS 100 TF.png2019-03-23T18:35:13Z<p>BerndArnold: Die FS20-Komponente HMS 100 TF</p>
<hr />
<div>== Beschreibung ==<br />
Die FS20-Komponente HMS 100 TF</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=FS20_Allgemein&diff=28668FS20 Allgemein2018-12-12T17:07:37Z<p>BerndArnold: URL aktualisiert /* FS20 Adressumrechnung */</p>
<hr />
<div>Allgemeine Informationen, die für alle FS20 Geräte im Zusammenhang mit FHEM Gültigkeit haben.<br />
== ON/OFF Befehle mit Time Parameter ==<br />
=== Einführung ===<br />
Viele FS20 Geräte lassen sich für eine bestimmte Zeitdauer schalten, die Schaltzeit kann beim Befehl bereits mitgegeben werden, das Gerät verwaltet die Zeit eigenständig, es muss also kein Ausschaltbefehl (bzw. Einschaltbefehl) mehr gesendet werden, um den vorherigen Zustand wieder herzustellen (es handelt sich hier '''nicht''' um die in FS20 Empfängern einstellbare Timer-Funktion, die (Ein-)Schaltzeiten zwischen einer Sekunde und 4,5 Stunden ermöglicht). <br />
Ein erneutes Senden eines for-timer Befehls löscht die alte Zeit und beginnt von vorne an zu zählen.<br />
<br />
<br />
===Mögliche Zeiten ===<br />
<br />
Die on/off-for... Befehle in FHEM ([http://fhem.de/commandref.html#FS20 Command Reference, FS20]) unterstützen einen optionalen '''time''' Parameter. Der Wert wird in Sekunden angegeben, erlaubt Nachkommastellen (als Dezimaltrenner ist der Punkt zu verwenden, anderenfalls bekommt man von FHEM die Meldung "Bad time spec"), wird aber letztendlich immer in einen der folgenden (112) Werte umgesetzt. FHEM rundet immer auf den nächsthöheren möglichen Wert auf (siehe Beispiele unter der Tabelle).<br />
<br />
{| class="wikitable" style="text-align:right"<br />
! Sekunden !! Zeit !! Sekunden !! Zeit !! Sekunden !! Zeit !! Sekunden !! Zeit !! Sekunden !! Zeit<br />
|-<br />
| 0,25 || 0:00:00,25 || 2,25 || 0:00:02,25 || 4,5 || 0:00:04,50 || 9 || 0:00:09,00 || 18 || 0:00:18,00<br />
|-<br />
| 0,5 || 0:00:00,50 || 2,5 || 0:00:02,50 || 5 || 0:00:05,00 || 10 || 0:00:10,00 || 20 || 0:00:20,00<br />
|-<br />
| 0,75 || 0:00:00,75 || 2,75 || 0:00:02,75 || 5,5 || 0:00:05,50 || 11 || 0:00:11,00 || 22 || 0:00:22,00<br />
|-<br />
| 1 || 0:00:01,00 || 3 || 0:00:03,00 || 6 || 0:00:06,00 || 12 || 0:00:12,00 || 24 || 0:00:24,00<br />
|-<br />
| 1,25 || 0:00:01,25 || 3,25 || 0:00:03,25 || 6,5 || 0:00:06,50 || 13 || 0:00:13,00 || 26 || 0:00:26,00<br />
|-<br />
| 1,5 || 0:00:01,50 || 3,5 || 0:00:03,50 || 7 || 0:00:07,00 || 14 || 0:00:14,00 || 28 || 0:00:28,00<br />
|-<br />
| 1,75 || 0:00:01,75 || 3,75 || 0:00:03,75 || 7,5 || 0:00:07,50 || 15 || 0:00:15,00 || 30 || 0:00:30,00<br />
|-<br />
| 2 || 0:00:02,00 || 4 || 0:00:04,00 || 8 || 0:00:08,00 || 16 || 0:00:16,00 || 32 || 0:00:32,00<br />
|-<br />
| &nbsp; || || || || || || || || ||<br />
|-<br />
| 36 || 0:00:36,00 || 72 || 0:01:12,00 || 144 || 0:02:24,00 || 288 || 0:04:48,00 || 576 || 0:09:36,00<br />
|-<br />
| 40 || 0:00:40,00 || 80 || 0:01:20,00 || 160 || 0:02:40,00 || 320 || 0:05:20,00 || 640 || 0:10:40,00<br />
|-<br />
| 44 || 0:00:44,00 || 88 || 0:01:28,00 || 176 || 0:02:56,00 || 352 || 0:05:52,00 || 704 || 0:11:44,00<br />
|-<br />
| 48 || 0:00:48,00 || 96 || 0:01:36,00 || 192 || 0:03:12,00 || 384 || 0:06:24,00 || 768 || 0:12:48,00<br />
|-<br />
| 52 || 0:00:52,00 || 104 || 0:01:44,00 || 208 || 0:03:28,00 || 416 || 0:06:56,00 || 832 || 0:13:52,00<br />
|-<br />
| 56 || 0:00:56,00 || 112 || 0:01:52,00 || 224 || 0:03:44,00 || 448 || 0:07:28,00 || 896 || 0:14:56,00<br />
|-<br />
| 60 || 0:01:00,00 || 120 || 0:02:00,00 || 240 || 0:04:00,00 || 480 || 0:08:00,00 || 960 || 0:16:00,00<br />
|-<br />
| 64 || 0:01:04,00 || 128 || 0:02:08,00 || 256 || 0:04:16,00 || 512 || 0:08:32,00 || 1024 || 0:17:04,00<br />
|-<br />
| &nbsp; || || || || || || || || ||<br />
|-<br />
| 1152 || 0:19:12,00 || 2304 || 0:38:24,00 || 4608 || 1:16:48,00 || 9216 || 2:33:36,00 || ||<br />
|-<br />
| 1280 || 0:21:20,00 || 2560 || 0:42:40,00 || 5120 || 1:25:20,00 || 10240 || 2:50:40,00 || ||<br />
|-<br />
| 1408 || 0:23:28,00 || 2816 || 0:46:56,00 || 5632 || 1:33:52,00 || 11264 || 3:07:44,00 || ||<br />
|-<br />
| 1536 || 0:25:36,00 || 3072 || 0:51:12,00 || 6144 || 1:42:24,00 || 12288 || 3:24:48,00 || ||<br />
|-<br />
| 1664 || 0:27:44,00 || 3328 || 0:55:28,00 || 6656 || 1:50:56,00 || 13312 || 3:41:52,00 || ||<br />
|-<br />
| 1792 || 0:29:52,00 || 3584 || 0:59:44,00 || 7168 || 1:59:28,00 || 14336 || 3:58:56,00 || ||<br />
|-<br />
| 1920 || 0:32:00,00 || 3840 || 1:04:00,00 || 7680 || 2:08:00,00 || 15360 || 4:16:00,00 || ||<br />
|-<br />
| 2048 || 0:34:08,00 || 4096 || 1:08:16,00 || 8192 || 2:16:32,00 || 0 || Dauer || ||<br />
|}<br />
Beispiele und die Ausgabe im FHEM log:<br />
<br />
define TestDev_2 at *12:52 set TestDev on-for-timer 0,27 '''-> Bad time spec (Komma statt Punkt)'''<br />
define TestDev_1 at *13:23 set TestDev on-for-timer 16000 '''-> Specified timeout too large, max is 15360''' <br />
define TestDev_2 at *13:24 set TestDev on-for-timer 2.6 '''-> TestDev: changing timeout to 2.75 from 2.6''' <br />
define TestDev_2 at *13:24 set TestDev on-for-timer 81 '''-> TestDev: changing timeout to 88 from 81'''<br />
<br />
=== Einsatzmöglichkeiten ===<br />
Im Gegensatz zu HM unterstützt FS20 den Timer auch bei OFF Befehlen. Damit lassen sich neben dem offensichtlichen Nutzen auch zwei Probleme lösen:<br />
<br />
1. Erhöhung der Zuverlässigkeit bei Ausschaltung kritischer Systeme. Schaltet man Beispielsweise mittels FHEM und einem FS20 Aktor eine Heizung aus, so garantiert die Verwendung eins <br />
off-for-timer 15360<br />
dass die Heizung auch wieder einschaltet, selbst wenn es später zu Funkstörungen kommen sollte. Sollte hingegen der off-for-timer 15360 nicht korrekt empfangen werden, geht die Heizung gar nicht erst aus, was ggf. die bessere Option darstellt. <br />
Längere Auschaltzeiten als 4,5 Stunden können durch erneutes senden eines off-for-timer kurz vor Ablauf des Timers realisiert werden.<br />
<br />
2. Es kommt offenbar unter ungünstigen Bedingungen vor, dass bestimmte Befehle (on oder off) von einem FS20 Aktor nicht gut empfangen werden, der jeweilige Gegenteilige Befehl aber wohl. Machmal kann man sich dann helfen, indem man einen Aktor ausschliesslich durch den gegenteiligen Befehl steuert. FS20 Aktoren lassen sich z.B. AUSschalten in dem man <br />
on-for-timer 0.25<br />
sendet, bzw EINschalten indem man<br />
off-for-timer 0.25<br />
sendet.<br />
<br />
== Gerätetimer setzen / löschen ==<br />
Zumindest bei einigen FS20 Geräten läßt sich auch der interne Gerätetimer über FHEM setzen. Dieser Timer wird vom Gerät dann bei normalen ON Befehlen berücksichtigt. <br />
:<code>set schalterZwei timer 16 </code> -> Timer von Gerät '''schalterZwei''' wird auf 16 Sekunden gesetzt<br />
Theoretisch lässt sich der timer auch wieder auschalten mit:<br />
:<code>set schalterEins timer 0 </code> -> Timer von Gerät '''schalterEins''' wird deaktiviert / gelöscht<br />
jedoch scheint dies nicht bei allen Geräten einwandfrei zu funktionieren. Ggf. Mehrmals versuchen.<br />
<br />
Für folgende Geräte funktioniert der <code>set xxx timer</code> Befehl definitiv: <br />
* [[FS20 RSU Rolladenschalter (Unterputz)]], <br />
* FS20 SM4, <br />
* [[FS20 SU Unterputz-Funk-Schalter]].<br />
* FS20 ST-4<br />
<br />
<!-- {{Todo|List of devices needs to be extended/completed; please add source of information on the FS20 discussion page}} --><br />
<br />
== FS20 Adressumrechnung ==<br />
Die direkte Einstellung der Codierung an FS20 und Homematic-Fernbedienungen erfolgt laut ELV Bedienungsanleitungen nur mit den Zahlen 1 bis 4. Das heißt, der Code basiert auf dem "Quaternärzahlensystem" (Vierersystem, Zahlensystem mit Basis 4 [0...3]). Dabei werden den für die Codierung verwendeten Tasten aber nicht die Zahlen 0...3 sondern 1...4 (pseudoquaternär) zugewiesen.<br />
<br />
Obwohl FHEM die pseudoquaternäre Schreibweise unterstützt, kann es notwendig sein, die Adressen in hex umzurechnen (Zahlensystem mit Basis 16 [0...F], Kennzeichnung durch vorangestelltes "0x"). Anhand der folgenden Tabelle kann zwischen beiden Darstellungsarten umgerechnet werden:<br />
<br />
{| class="wikitable" style="width:100%; text-align:center"<br />
! 1x quad !! 2x quad !! 3x quad !! 4x quad<br />
|-<br />
| 11 = 0x0 || 12 = 0x1 || 13 = 0x2 || 14 = 0x3<br />
|-<br />
| 21 = 0x4 || 22 = 0x5 || 23 = 0x6 || 24 = 0x7<br />
|- <br />
| 31 = 0x8 || 32 = 0x9 || 33 = 0xA || 34 = 0xB<br />
|-<br />
| 41 = 0xC || 42 = 0xD || 43 = 0xE || 44 = 0xF<br />
|}<br />
<br />
''Beispiel:'' [[Was ist der Hauscode?|Hauscode]] nach ELV (pseudoquaternär) "43 21 12 34" ergibt nach FHEM (hexadezimal) "E 4 1 B".<br />
<br />
Einen automatischen Umrechner findet man auch unter [https://www.homematic-inside.de/praxis/tools/fs20converter www.homematic-inside.de]<br />
<br />
Da FHEM beide Schreibweisen unterstützt, hat Verwendung der pseudoquaternärern Schreibweise auch innerhalb FHEM den Vorteil, die notwendigen Tastendrücke zur Einrichtung des FS20 Hauscodes direkt ablesbar zu machen.<br />
<br />
== FS20 Adressierungsschema (Vorschlag) ==<br />
=== "klassisches" Schema ===<br />
Bei der Adressierung der Geräte können verschiedene Adressgruppen und -bereiche eingerichtet werden. Der Einfachheit halber (weil man an den Geräten keine Hex-Werte einstellen kann) erfolgt die Erklärung anhand der Pseudoquarternärzahlen.<br />
Eine gute Erklärung ist auch hier zu finden: Serie im ELV Journal, Teil 4 {{DocLink|elv|/bilder/journal/2007_01/14/fs20_system_teil4.pdf}}.<br />
<br />
{| class="wikitable"<br />
!Bezeichnung !! Schema !! Beispiel<br />
|-<br />
| Hauscode || xxxx xxxx || 4332 3221<br />
|-<br />
| Gerätecode || yyyy || 1111<br />
|-<br />
| Funktionsgruppe || 44aa || 4411 bis 4443<br />
|-<br />
| Lokaler Master || bb44 || 1144 bis 4344<br />
|-<br />
| Globaler Master || 4444 || 4444<br />
|}<br />
<br />
Mit Hilfe dieser Adressgruppen kann man jetzt sein System entwerfen:<br />
<br />
Hauscode festlegen:<br />
* s.o. 4332 3221<br />
<br />
Funktionsgruppen festlegen:<br />
* 4411: Deckenleuchten<br />
* 4412: Rolläden<br />
<br />
Lokale Master festlegen:<br />
* 1144: Flur<br />
* 1244: Esszimmer<br />
* 1344: Wohnzimmer<br />
* 1444: Schlafzimmer<br />
<br />
Globaler Master <br />
* ist fest auf 4444<br />
<br />
Einzeladressen festlegen: Aus Gründen der Übersichtlichkeit werden die Lokalen Master-Adressen im vorderen Teil verwendet. Dies ist für die Funktion '''nicht''' erforderlich!:<br />
* 1311: Stereoanlage Wohnzimmer<br />
* 1312: Deckenlampe Wohnzimmer<br />
* 1112: Steckdose Flur<br />
* 1244: Deckenlampe Esszimmer<br />
* 1411: Deckenlampe Schlafzimmer<br />
usw.<br />
<br />
Somit bekommt jeder Aktor '''bis zu vier''' Adresszuweisungen zusätzlich zum Hauscode! Die Sensoren hingegen bekommen '''nur eine''' Adresse zusätzlich zum Hauscode zugewiesen! Nun können alle Aktoren nach belieben geschaltet werden: <br />
* mit 4411 alle Deckenleuchten im Haus<br />
* mit 1312 nur die Deckenlampe im Wohnzimmer<br />
* mit 1344 sowohl Deckenlampe als auch Stereoanlage<br />
* mit 4444 alle Geräte (bei denen diese Adresse einprogrammiert ist)<br />
<br />
=== Alternatives Schema===<br />
{{Randnotiz|RNTyp=y|RNText=In diesem alternative Schema können FS20 Fernbedienungen nur eingeschränkt zur '''Direkt'''steuerung von FS20 Komponenten eingesetzt werden sollen, da jede Fernbedienung einen Hauscode für alle Kanäle/Tasten verwendet.}}<br />
Das normale oben beschriebene Herangehen entfaltet seine Vorteile vor allem bei Nutzung von lokalen Masteradressen und Funktionsgruppen, die das Schalten vieler Komponenten mit nur einem Befehl ermöglicht.<br />
Kann man auf dieses Feature verzichten - z.B. weil es in FHEM auch anders abgebildet werden kann - sind auch andere Adressschemata möglich.<br />
<br />
Gerade im Umfeld von FHEM mit Nutzung von [[CUL]] oder ähnlichen Funkschnittstellen (im Gegensatz zu ELV Zentralen wie FHZ1000) kann man den Hauscode nämlich auch nur als bloßen Adressbestandteil auffassen und in einer Installation mehrere Hauscodes verwenden. <br />
<br />
Dadurch könnte man diverse funktional unterscheidbare Komponenten jeweils mit eigenen Hauscodes versehen, z.b.: Alle Lichtaktoren Hauscode 4332 3221, alle Aktoren im Aussenbereich 4332 3222, alle Rolladenaktoren 4332 3223 etc. <br />
<br />
Gerade in solchen Installationen ist es sinnvoll, Fernbedienungen nicht den Komponenten direkt zuzuordnen, sondern damit Aktionen über FHEM mittels <code>define…notify</code> auszulösen.<br />
<br />
<br />
In solchen Installationen kann die globale Masteradresse die Funktion des lokalen Masters übernehmen: Mit Adresse 4444 und Hauscode 4332 3221 liesse sich im Beispiel alles Licht zugleich Ausschalten, ohne dass die Aktoren im Aussenbereich oder Rolladen betroffen wären.<br />
<br />
Da FS20 je Hauscode "nur" 254 Adressen kennt, kann die "klassische" Adressierung mit Funktionsgruppen und Lokalen Mastern durchaus aufwendige Planung erfordern, um den Adressbereich sinnvoll einzuteilen. Die Verwendung mehrerer Hauscodes erfordert meistens weniger Planung.<br />
<br />
== FS20 - Probleme durch LTE ==<br />
Ende 2012 tauchten die ersten Meldungen in den Medien auf, dass FS20-Empfänger Probleme durch den LTE-Ausbau bekommen. Erste Problemschilderungen tauchten bereits Ende 2011 in einigen Foren auf (z.B. [http://www.lte-anbieter.info/lte-forum/threads/128-LTE-und-Haussteuerung hier]).<br />
<br />
Zur weiteren Informationen sei auf die folgenden Artikel verwiesen:<br />
<br />
* [http://www.heise.de/ct/artikel/Hausautomationssystem-ELV-FS20-Probleme-mit-LTE-Routern-1758453.html heise.de]<br />
* [http://www.elv.de/nicht-lte-stoerfest.html elv.de]<br />
* &lt; bitte ergänzen &gt;<br />
<br />
Betroffen von diesen Problemen sollen insbesondere FS20-Geräte '''älterer''' Bauart sein, da deren Empfangsteil zu breitbandig sei.<br />
<br />
Unter [ftp://ftp.heise.de/pub/ct/listings/1226-025.zip Textdatei] findet sich eine ''Liste der vom LTE-Problem betroffenen FS20-Geräte''.<br />
<br />
Für Bastler gibt es einen [https://www.heise.de/ct/ausgabe/2017-21-FS20-Schalter-Dimmer-und-Interfaces-LTE-sicher-machen-3837756.html Artikel in CT 2017/21, S. 152], wo ein Austausch des jeweiligen Empfangsbausteins (durch z. B. den ELV RX868SH-DV, ca. 13 €) beschrieben wird.<br />
<br />
== Links ==<br />
ELV (Journal) Serie über das FS20 System in der Praxis:<br />
* Teil 1 {{DocLink|elv|/bilder/journal/2006_04/01/fs20_system_teil1.pdf}} - Einleitung<br />
* Teil 2 {{DocLink|elv|/bilder/journal/2006_05/18/fs20_system_teil2.pdf}} - Installationsbeispiel Unterputzschalter<br />
* Teil 3 {{DocLink|elv|/bilder/journal/2006_06/03/fs20_system_teil3.pdf}} - Beleuchtungssteuerung durch Verknüpfung von Komponenten<br />
* Teil 4 {{DocLink|elv|/bilder/journal/2007_01/14/fs20_system_teil4.pdf}} - Planung und Einrichtung eines Haussteuerungssystems<br />
* Teil 5 {{DocLink|elv|/bilder/journal/2007_04/13/fs20_system_teil5.pdf}} - Rollladensteuerung<br />
* Teil 6 {{DocLink|elv|/bilder/journal/2007_05/04/fs20_system_teil6.pdf}} - Kameraüberwachung + Dokumentation einer FS20 Installation<br />
* Teil 7 {{DocLink|elv|/bilder/journal/2007_06/03/fs20_system_teil7.pdf}} - Rollladensteuerung mit "homeputer Studio"<br />
* Teil 8 {{DocLink|elv|/bilder/journal/2008_01/04/fs20_system_teil8.pdf}} - Makroprogrammierung (mit "homeputer Studio") <br />
* Teil 9 {{DocLink|elv|/bilder/journal/2008_02/05/fs20_system_teil9.pdf}} - FS20 Audio Komponenten<br />
<br />
[[Kategorie:FS20 Components|Allgemein]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HM-Sen-DB-PCB_Klingelsignalsensor&diff=27991HM-Sen-DB-PCB Klingelsignalsensor2018-10-07T09:23:59Z<p>BerndArnold: Stil, Typo</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=PlatzHalter.png<br />
|Bildbeschreibung=<br />
|HWProtocol=BidCoS ([[HomeMatic]])<br />
|HWType=Sensor<br />
|HWCategory=Sensor<br />
|HWComm=868,3&nbsp;MHz<br />
|HWChannels=1<br />
|HWVoltage=3&nbsp;V<br />
|HWPowerConsumption=30&nbsp;mA (max)<br />
|HWPoweredBy=2x1,5&nbsp;V (Micro/AAA/LR03)<br />
|HWSize=68 x 127 x 23 mm (mit Antenne), 68 x 58 x 23 mm (ohne Antenne)<br />
|HWDeviceFHEM=[[CUL_HM]]<br />
|HWManufacturer=ELV / eQ-3 <br />
}}<br />
<br />
[[HM-Sen-DB-PCB]] ist ein Funk-Klingelsignalsensor, der auf externe Signalspannung reagiert und angelernte HomeMatic-Geräte über Funk steuert.<br />
<br />
== Features / Funktionen ==<br />
Die auslösende Signalspannung kann sowohl Gleich- als auch Wechselspannung sein, die zwischen 5 und 12 V liegt. Das Gerät kann somit direkt in eine bestehende Klingelanlage integriert werden. Alternativ kann ein potentialfreier Taster zur Auslösung verwendet werden.<br />
* Als Sensor zur Spannungserkennung oder als Taster-Sender einsetzbar<br />
* Kann andere HomeMatic-Geräte direkt ansteuern oder Anbindung über FHEM möglich<br />
* Lange Batterielebensdauer (ca. 5 Jahre)<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Das Pairing sollte wie unter [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.<br />
<br />
== Bekannte Probleme ==<br />
Der Klingelsignalsensor sendet keine zyklische Statusmeldung und Batterieüberwachung. Erst bei Signalerkennung sendet das Gerät den erkannten Tastendruck und liefert den aktuellen Status.<br />
<br />
== Beispiel zu Auslesen ==<br />
Das Beispiel zeigt, wie der Klingelsensor ausgelesen werden kann um damit Aktionen auszuführen.<br />
Der Code wurde direkt aus dem fhem.cfg kopiert.<br />
<br />
define 1OG.KLINGEL.DOIF DOIF ([1OG.KLINGEL:?Short]) \<br />
(\<br />
set 2OG.WHZ.CABTV1 msg yesno 15 1OG.KLINGEL - Es steht jemand vor der Tür, \<br />
set 1OG.SZ.CABTV1 msg yesno 15 1OG.KLINGEL - Es steht jemand vor der Tür, \<br />
set pushmsg.fhemapp.* message '1OG.KLINGEL Es steht jemand vor der Tür', \<br />
set FritzBox ring 610 15 show:Türklingel\<br />
)<br />
<br />
<br />
<br />
== Weblinks ==<br />
* [http://www.elv.de/homematic-funk-klingelsignalsensor-bausatz.html Produktbeschreibung bei ELV]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:868MHz]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=DOIF/Tipps_zur_leichteren_Bedienung&diff=21247DOIF/Tipps zur leichteren Bedienung2017-04-10T12:51:50Z<p>BerndArnold: Typo korrigiert /* Größe des Editorfensters ändern */</p>
<hr />
<div>[[Kategorie:Hilfsmodul]]<br />
'''Anmerkung:''' Dieser Artikel wurde {{Link2Forum|Topic=45373|Message=371668|LinkText=aus dem Forum}} übernommen.<br />
<br />
Hier sind ein paar Hinweise gesammelt, die den Umgang mit dem DOIF erleichtern können. Nichts Neues, aber vielleicht hilft es dem Einen oder Anderen.<br />
<br />
== Verwenden des DEF-Editors zum Erstellen und Bearbeiten des DOIF ==<br />
Zuerst eine minimale Definition in der Eingabezeile der WEB-Oberfläche erstellen<br />
<pre><br />
define <DOIF Name> DOIF ##<br />
</pre><br />
danach die Eingabetaste drücken, dann öffnet sich die Geräteübersicht (DeviceOverview), dort den DEF-Editor öffnen (auf DEF klicken) und die Definition weiter bearbeiten und strukturieren.<br />
<br />
== Einschalten von Syntaxhervorhebung, Zeilenumbruch, Suchen und Ersetzen, Klammerprüfung uvm. ==<br />
<pre><br />
attr WEB JavaScripts codemirror/fhem_codemirror.js<br />
attr WEB codemirrorParam { "lineWrapping":true }<br />
</pre><br />
<br />
== Länge der Eingabezeile (Befehlszeile) ändern ==<br />
Per Attribut die Länge der Eingabezeile ändern.<br />
<pre><br />
attr WEB mainInputLength 80<br />
</pre><br />
<br />
== Eingabefeld für bestimmte Attribute vergrößern, z.B. für das Attribut "state", um bequem Berechnungen zu erstellen. ==<br />
<pre><br />
attr <DOIF Name> widgetOverride state:textField-long<br />
</pre><br />
<br />
== Größe des Editorfensters ändern ==<br />
Wem das Editorfenster zu groß oder zu klein ist, kann die Höhe optimieren mit<br />
<pre><br />
attr WEB codemirrorParam { ..., "height":"auto" }<br />
</pre><br />
<br />
Weitere einstellbare Parameter für codemirror siehe auch:<br />
[[Konfiguration#Syntaxhervorhebung|Codemirror Bedienung und Einstellungen]]<br />
<br />
== Umschaltung auf deutsche Befehlsreferenz ==<br />
Direkter Aufruf der deutschsprachigen Hilfe in der "Device specific help" und direkter Zugriff auf die deutschsprachige Befehlsreferenz im Hauptmenü.<br />
<pre><br />
attr global language DE<br />
</pre><br />
<br />
== Fehlende Geräte in "Probably associated with" anzeigen ==<br />
Geräte, die im DOIF über einen regulären Ausdruck angesprochen werden, tauchen in der Liste von "Probably associated with" nicht auf.<br />
Diese Geräte werden aufgeführt, wenn sie in der Definition des DOIF als Kommentar mit vollständigem Namen aufgezählt werden.<br />
<pre><br />
(["^GERAET(1|2)$:"]) ## GERAET1 GERAET2<br />
(set ...)<br />
</pre><br />
==Import von Code Snippets==<br />
Code Snippets können über '''Raw definition''' importiert werden, siehe [[DOIF/Import von Code Snippets]].<br />
<br />
==DOIFtools das Modul zum DOIF==<br />
Das Modul '''[[DOIFtools]]''' enthält Funktionen zur Unterstützung des Benutzers im Umgang mit DOIF:<br />
<br />
* erstellen von readingsGroup Definitionen, zur Beschriftung von Frontendelementen.<br />
* erstellen eines Debug-Logfiles, in dem mehrere DOIF und zugehörige Geräte geloggt werden.<br />
* optionales DOIF-Listing bei jeder Status und Wait-Timer Aktualisierung im Debug-Logfile.<br />
* Navigation zwischen den DOIF-Listings im Logfile, wenn es über DOIFtools geöffnet wird.<br />
* erstellen von userReadings in DOIF-Geräten zur Anzeige des realen Datums bei Wochentag behafteten Timern.<br />
* löschen von benutzerdefinierten Readings in DOIF-Definitionen über eine Mehrfachauswahl.<br />
* erfassen statistischer Daten über Events.<br />
* Begrenzung der Datenerfassungsdauer.<br />
* erstellen eines Statistikreports.<br />
* Liste aller DOIF-Definitionen in probably associated with.<br />
* Zugriff auf DOIFtools aus jeder DOIF-Definition über die Liste in probably associated with.<br />
* Zugriff aus DOIFtools auf vorhandene DOIFtoolsLog-Logdateien.<br />
* einblenden des Event-Monitor in der Detailansicht.<br />
* ermöglicht den Zugriff auf den Event Monitor in der Detailansicht von DOIF.<br />
* prüfen der DOIF Definitionen mit Empfehlungen.<br />
* erstellen eigener Shortcuts<br />
<br />
== Weiterführende Links ==<br />
[[DOIF/Tools und Fehlersuche|Tools und Fehlersuche]]<br />
<br />
[[Kategorie:Hilfsmodul]]<br />
[[Kategorie:HOWTOS]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HM-SEC-SD_Rauchmelder&diff=20790HM-SEC-SD Rauchmelder2017-03-19T09:19:03Z<p>BerndArnold: Typos korrigiert, Text vereinheitlicht</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-SEC-SD o.jpeg <!-- HM-SEC-SD o.jpeg --><br />
|Bildbeschreibung=HomeMatic HM-SEC-SD Rauchmelder Oberseite<br />
|HWProtocol=HomeMatic<br />
|HWType=Aktor<br />
|HWCategory=HomeMatic<br />
|HWComm=868MHz<br />
|HWChannels=<br />
|HWVoltage=9V<br />
|HWPowerConsumption= W im Standby<br />
|HWPoweredBy=3 x 1,5 V LR6/AA<br />
|HWSize=120x44mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]<br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
== Features ==<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD]] ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter. Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD-2]] ist die neue Version seit 2016. Auch dieser Melder wird in FHEM unterstützt.<br />
<br />
[[Datei: HM-SEC-SD-2.jpg|300px|thumb|right|HM-SEC-SD-2]]<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit [[HMLAN Konfigurator]] oder mit [[CUL]] möglich. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.<br />
<br />
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!<br />
<br />
=== Teams ===<br />
Rauchmelder können mittels [[Peering (HomeMatic)|Peering]] in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst peeren.<br />
<br />
Beispiele:<br />
nutzt man einen SD und will diesen nicht mit anderen in einem Team haben peert man ihn mit sich selbst. Damit ist der SD sein eigener TeamLead. <br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor</code><br />
<br />
Hat man mehrere SDs, die in einem Team zusammengefasst werden sollen, wird der TeamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden. <br />
<pre>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor </pre><br />
<br />
Nutzt man einen virtuellen TeamLead - (siehe [[#virtueller TeamLead|virtueller TeamLead]]) - werden alle realen SDs mit diesem gepeert<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor<br />
</pre><br />
<br />
Ein SD kann aus einem Team mittels unset entfernt werden.<br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single unset actor </code><br />
<br />
Um einen SD von einem Team in ein anderes zu transferieren, muss man ihn erst mit ''unset'' aus dem Team entfernen, dann mit ''set'' in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen Teammitgliedern entfernt. <br />
<br />
Die korrekte Gruppierung sollte nach der Konfiguration durch einen Teamcall geprüft werden.<br />
<br />
Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen, muss man ihn erst aus dem ersten Team entfernen und dann in das Neue aufnehmen.<br />
<br />
=== TeamLead ===<br />
Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert, gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen, verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs. Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuellen SD als TeamLead nutzen. Siehe hierzu [[#virtueller TeamLead|virtueller TeamLead]].<br />
<br />
Nutzt man nur einen einzelnen SD, sollte man diesen mit sich selbst peeren.<br />
<br />
=== Kommandos ===<br />
Es gibt Team-Nachrichten, die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen Teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden '''nicht''' von einem SD zum anderen weitergereicht. Auch der TeamLead hat '''keine''' Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf.<br />
<br />
Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können.<br />
<br />
Die Kommandos können von der Zentrale getriggert werden. Da sie unter der Team-ID gesendet werden, stehen sie nur bei der Komponente des TeamLeads zu Verfügung.<br />
<br />
Dazu gehören teamCall, teamCallBat, alarmOn und alarmOff.<br />
<br />
Sie stehen nur für die Entity des TeamLeads zu Verfügung.<br />
<pre>set EurerTeamLeader alarmOn<br />
set EurerTeamLeader alarmOff<br />
set EurerTeamLeader teamCall<br />
set EurerTeamLeader teamCallBat ## nur für alte SDs <br />
</pre><br />
<br />
'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen. '''teamCallBat''' erzeugt einen kürzeren Teamcall mit anderer Signalfolge, wie er bei schwacher Batterie eines Melders automatisch ausgelöst wird.<br />
<br />
Einzelne SDs kann man mit "statusRequest" abfragen.<br />
<br />
== virtueller TeamLead ==<br />
Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine Team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine Team-ID verloren.<br />
<br />
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als Lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine sauberere Struktur.<br />
<br />
Erzeugen eines virtuellen TeamLeads könnte so aussehen:<br />
<pre>define TeamDev CUL_HM 111111 <br />
set TeamDev virtual 1<br />
rename TeamDev_Btn1 Rauchmelder_Team</pre><br />
<br />
Bitte beachten: '''die HMID muss für die gesamte Installation einmalig sein'''.<br />
<br />
Anschließend muss man noch einen Homematic-Kanal für das Peering definieren.<br />
<br />
Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
...<br />
save</pre><br />
<br />
Hierbei ist "Rauchmelder_Team" der Name des virtuellen TeamLeaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.<br />
<br />
Das "save" ist notwendig, um auch die Einstellungen des virtuellen SDs in der [[Konfiguration]] zu sichern.<br />
<br />
Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.<br />
<br />
Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.<br />
<br />
== Variablen ==<br />
=== Internals ===<br />
Keine Spezifischen.<br />
<br />
=== Readings ===<br />
Für '''jeden''' SD sind folgende Readings relevant:<br />
<br />
teamCall from <name>:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
battery:[ok|low]<br />
level:<0..200><br />
<br />
*'''count''' ist ein Zähler, den das Gerät liefert um neue Alarme unterscheiden zu können<br />
*'''level''' ist ein Wert zwischen 0 und 200. 200 ist Alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.<br />
<br />
Beim '''TeamLead''' laufen alle Alarme auf<br />
<br />
teamCall: from <name>:<count><br />
recentAlarm:<von_name><br />
level:<0..200><br />
eventNo:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
SDteam:[add_<name>|remove_<name>]<br />
<br />
*'''von_name''' ist der Name des SD, der gemeldet hat. <br />
*'''smoke_detect''' ist der aktuelle Alarm, während '''recentAlarm''' die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.<br />
*'''SDteam''' kommt gelegentlich bei Konfigurationsereignissen zum Tragen.<br />
<br />
=== Attribute ===<br />
Besondere Attribute<br />
* '''msgRepeat''' sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-Kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms. <br />
* '''actCycle''' wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.<br />
* '''msgRepeat''' 1<br />
Allgemein vorgeschlagen<br />
:'''IODev''' [HMLAN/HMUSB/CUL]<br />
:'''autoReadReg''' 5_readMissing<br />
:'''event-on-change-reading''' .*<br />
Optional, nur als Anregung zu verstehen<br />
:'''devStateIcon''' off:general_ok *:secur_alarm<br />
:'''group''' smokeDetect<br />
:'''icon''' secur_smoke_detector<br />
<br />
== Alarme ==<br />
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.<br />
<br />
Nutzt man [[HomeMatic HMInfo|HMinfo]], wird ein Rauchalarm auch hier als "Error" gemeldet. In HMinfo wird dies für alle SD-Teams im System gemacht.<br />
<br />
== Nützliche Notifies ==<br />
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein. <br />
* Bei Alarm E-Mail schicken und Licht im Flur anschalten<br />
<pre><br />
define sd.nf.report notify sdTeam:.*smoke-Alarm.* {\<br />
<Mail versenden>;;<br />
fhem("set LichtTreppenhaus on");;<br />
}\<br />
</pre><br />
<br />
* Bei Alarm alle SDs des Teams stumm schalten durch Stummschalten eines einzelnen<br />
:<code>define sd.nf.quiet notify sdTeam:.*level:.199 set sdTeam alarmOff</code><br />
<br />
== Links ==<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD_GE_UM_V1.5_150407.pdf Anleitung (PDF)]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Rauchmelder]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HM-SEC-SD_Rauchmelder&diff=20545HM-SEC-SD Rauchmelder2017-03-05T20:04:01Z<p>BerndArnold: Bild vom HM-SEC-SD-2 hinzugefügt</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-SEC-SD o.jpeg <!-- HM-SEC-SD o.jpeg --><br />
|Bildbeschreibung=HomeMatic HM-SEC-SD Rauchmelder Oberseite<br />
|HWProtocol=HomeMatic<br />
|HWType=Aktor<br />
|HWCategory=HomeMatic<br />
|HWComm=868MHz<br />
|HWChannels=<br />
|HWVoltage=9V<br />
|HWPowerConsumption= W im Standby<br />
|HWPoweredBy=3 x 1,5 V LR6/AA<br />
|HWSize=120x44mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]<br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
== Features ==<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD]] ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter. Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD-2]] ist die neue Version seit 2016. Auch dieser Melder wird in FHEM unterstützt.<br />
<br />
[[Datei: HM-SEC-SD-2.jpg|300px|thumb|right|HM-SEC-SD-2]]<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit [[HMLAN Konfigurator]] oder mit [[CUL]] möglich. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.<br />
<br />
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!<br />
<br />
=== Teams ===<br />
Rauchmelder können mittels [[Peering (HomeMatic)|Peering]] in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst peeren.<br />
<br />
Beispiele:<br />
nutzt man einen SD und will diesen nicht mit anderen in einem team haben peert man ihn mit sich selbst. Damit ist der SD sein eigener TeamLead. <br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor</code><br />
<br />
Hat man mehrere SDs, die in einem Team zusammengefasst werden sollen, wird der TeamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden. <br />
<pre>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor </pre><br />
<br />
Nutzt man einen virtuellen TeamLead - (siehe [[#virtueller TeamLead|virtueller TeamLead]]) - werden alle realen SDs mit diesem gepeert<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor<br />
</pre><br />
<br />
Ein SD kann aus einem Team mittels unset entfernt werden.<br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single unset actor </code><br />
<br />
Um einen SD von einem Team in ein anderes zu transferieren, muss man ihn erst mit ''unset'' aus dem Team entfernen, dann mit ''set'' in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen Teammitgliedern entfernt. <br />
<br />
Die korrekte Gruppierung sollte nach der Konfiguration durch einen teamCall geprüft werden.<br />
<br />
Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen, muss man ihn erst aus dem ersten Team entfernen und dann in das Neue aufnehmen.<br />
<br />
=== TeamLead ===<br />
Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert, gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen, verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs. Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuellen SD als TeamLead nutzen. Siehe hierzu [[#virtueller TeamLead|virtueller TeamLead]].<br />
<br />
Nutzt man nur einen einzelnen SD, sollte man diesen mit sich selbst peeren.<br />
<br />
=== Kommandos ===<br />
Es gibt Team-Nachrichten, die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden '''nicht''' von einem SD zum anderen weitergereicht. Auch der TeamLead hat '''keine''' Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf.<br />
<br />
Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können.<br />
<br />
Die Kommandos können von der Zentrale getriggert werden. Da sie unter der TeamId gesendet werden, stehen sie nur bei der Komponente des TeamLeads zu Verfügung.<br />
<br />
Dazu gehören teamCall, teamCallBat, alarmOn und alarmOff.<br />
<br />
Sie stehen nur für die Entity des TeamLeads zu Verfügung.<br />
<pre>set EurerTeamLeader alarmOn<br />
set EurerTeamLeader alarmOff<br />
set EurerTeamLeader teamCall<br />
set EurerTeamLeader teamCallBat ## nur für alte SDs <br />
</pre><br />
<br />
'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen. '''teamCallBat''' erzeugt einen kürzeren Teamcall mit anderer Signalfolge, wie er bei schwacher Batterie eines Melders automatisch ausgelöst wird.<br />
<br />
Einzelne SDs kann man mit "statusRequest" abfragen.<br />
<br />
== virtueller TeamLead ==<br />
Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine team-ID verloren.<br />
<br />
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine sauberere Struktur.<br />
<br />
Erzeugen eines virtuellen TeamLeads könnte so aussehen:<br />
<pre>define TeamDev CUL_HM 111111 <br />
set TeamDev virtual 1<br />
rename TeamDev_Btn1 Rauchmelder_Team</pre><br />
<br />
Bitte beachten: '''die HMID muss für die gesamte Installation einmalig sein'''.<br />
<br />
Anschließend muss man noch einen Homematic-Kanal für das Peering definieren.<br />
<br />
Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
...<br />
save</pre><br />
<br />
Hierbei ist "Rauchmelder_Team" der Name des virtuellen TeamLeaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.<br />
<br />
Das "save" ist notwendig, um auch die Einstellungen des virtuellen SDs in der [[Konfiguration]] zu sichern.<br />
<br />
Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.<br />
<br />
Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.<br />
<br />
== Variablen ==<br />
=== Internals ===<br />
Keine Spezifischen.<br />
<br />
=== Readings ===<br />
Für '''jeden''' SD sind folgende Readings relevant:<br />
<br />
teamCall from <name>:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
battery:[ok|low]<br />
level:<0..200><br />
<br />
*'''count''' ist ein Zähler, den das Gerät liefert um neue Alarme unterscheiden zu können<br />
*'''level''' ist ein Wert zwischen 0 und 200. 200 ist Alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.<br />
<br />
Beim '''TeamLead''' laufen alle Alarme auf<br />
<br />
teamCall: from <name>:<count><br />
recentAlarm:<von_name><br />
level:<0..200><br />
eventNo:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
SDteam:[add_<name>|remove_<name>]<br />
<br />
*'''von_name''' ist der Name des SD, der gemeldet hat. <br />
*'''smoke_detect''' ist der aktuelle Alarm, während '''recentAlarm''' die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.<br />
*'''SDteam''' kommt gelegentlich bei Konfigurationsereignissen zum Tragen.<br />
<br />
=== Attribute ===<br />
besondere Attribute<br />
* '''msgRepeat''' sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms. <br />
* '''actCycle''' wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.<br />
* '''msgRepeat''' 1<br />
Allgemein vorgeschlagen<br />
:'''IODev''' [HMLAN/HMUSB/CUL]<br />
:'''autoReadReg''' 5_readMissing<br />
:'''event-on-change-reading''' .*<br />
Optional, nur als Anregung zu verstehen<br />
:'''devStateIcon''' off:general_ok *:secur_alarm<br />
:'''group''' smokeDetect<br />
:'''icon''' secur_smoke_detector<br />
<br />
== Alarme ==<br />
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.<br />
<br />
Nutzt man [[HomeMatic HMInfo|HMinfo]], wird ein Rauchalarm auch hier als "Error" gemeldet. In HMinfo wird dies für alle SD-teams im System gemacht.<br />
<br />
== Nützliche Notifies ==<br />
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein. <br />
* Bei Alarm email schicken und Licht im Flur anschalten<br />
<pre><br />
define sd.nf.report notify sdTeam:.*smoke-Alarm.* {\<br />
<Mail versenden>;;<br />
fhem("set LichtTreppenhaus on");;<br />
}\<br />
</pre><br />
<br />
* Bei Alarm alle SDs des Team stumm schalten durch stumm Schalten eines einzelnen<br />
:<code>define sd.nf.quiet notify sdTeam:.*level:.199 set sdTeam alarmOff</code><br />
<br />
== Links ==<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD_GE_UM_V1.5_150407.pdf Anleitung (PDF)]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Rauchmelder]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Datei:HM-SEC-SD-2.jpg&diff=20544Datei:HM-SEC-SD-2.jpg2017-03-05T20:00:26Z<p>BerndArnold: Frontansicht, Rückseite und Draufsicht</p>
<hr />
<div>Frontansicht, Rückseite und Draufsicht</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=TRAFFIC&diff=20307TRAFFIC2017-02-26T09:15:33Z<p>BerndArnold: Typos korrigiert, Text vereinheitlicht</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Verkehrsdaten zu fest definierten Routen ermitteln<br />
|ModType=d<br />
|ModForumArea=Unterstützende Dienste<br />
|ModTechName=98_TRAFFIC.pm<br />
|ModOwner=jmike <br />([https://forum.fhem.de/index.php/topic,56045.0.html Forum] / [[Benutzer:Jmike|Wiki]])<br />
}}<br />
<br />
Dieses Modul erfasst Fahrzeiten in aktueller Verkehrslage mittels Google Maps Directions API.<br />
<br />
== Features / Funktionen ==<br />
* Distanz einer Route<br />
* Fahrzeit ohne Verkehr<br />
* Fahrzeit mit Verkehr<br />
* Verzögerung der geplanten Route<br />
* Waypoints definieren<br />
* Ausgabesprache festlegen <br />
* Outputs in Sekunden / Meter (raw)<br />
* Ausgabe als Text, in Minuten, Sekunden oder als Durchschnitt<br />
* Device STATE frei wählbar<br />
* einstellbares Update Interval<br />
* update-burst für Stosszeiten<br />
* Strecke kann zusätzlich in gegengesetzte Richtung ausgelesen werden<br />
* Ankunfszeit bei Abfahrt zum Update-Zeitpunkt<br />
* verschiedene Travel Modes (driving, walking, bicycling und transit)<br />
* flexibler Update Schedule für Stosszeiten<br />
* integrierte Google Map zum Visualisieren der konfigurierten Route<br />
<br />
== Voraussetzungen ==<br />
Erstmal muss ein eigener API Key angefordert werden. <br />
Das geht über Googles [https://console.developers.google.com/apis/ API Manager]<br><br />
Dort "Google Maps Directions API" suchen und ein neues Projekt erstellen, anschliessend API aktivieren.<br />
<br />
Je nach FHEM Installation zusätzlich die Perl Module LWP::Simple, JSON und MIME::Base64 nach installieren:<br><br />
<code>sudo apt-get install libwww-perl</code><br><br />
<code>sudo apt-get install libjson-perl</code><br><br />
oder<br><br />
<code>sudo cpan -i LWP::Simple</code><br><br />
<code>sudo cpan -i JSON</code><br><br />
<code>sudo cpan -i MIME::Base64</code><br />
<br />
== Definition ==<br />
<code> define <devicename> TRAFFIC <API-KEY> [update-interval] </code><br />
<br />
'''Beispiel:'''<br><br />
<code>define muc2berlin TRAFFIC ABCDEFGHIJKLMNOPQRSTVWYZ 600</code><br />
<br />
Der API Key muss selbstverständlich mit dem eigenen Key aus dem API Manager ersetzt werden.<br><br />
Das Intervall in Sekunden ist optional, der default beträgt 3600 (1 Stunde).<br><br />
Attribute start_address und end_address definieren.<br />
<br />
== Readings ==<br />
* average_delay_min<br />
* average_duration_in_traffic_min<br />
* average_duration_min<br />
* delay<br />
* delay_min<br />
* distance<br />
* duration<br />
* duration_in_traffic<br />
* duration_in_traffic_min<br />
* duration_in_traffic_sec<br />
* duration_min<br />
* duration_sec<br />
* [error_message]<br />
* eta<br />
* state<br />
* status<br />
<br />
== Befehle ==<br />
<br />
==== update [burst-update-count] [burst-update-interval] ====<br />
Readings manuell aktualisieren, der optionale Burst kann wie folgt genutzt werden:<br><br />
- erster Wert gibt an wie viele Updates abgearbeitet werden<br><br />
- zweiter Wert gibt an wie viele Sekunden zwischen den Updates gewartet wird<br><br />
<br />
Beispiel um für 1 Stunde alle 5 Minuten zu aktualisieren:<br><br />
<code>set <device> update 12 300</code><br />
<br />
<br />
== STATE ==<br />
* Initialized - modul initialisiert<br />
* OK - update war erfolgreich<br />
* incomplete configuration - Konfigurationsfehler (start_address oder end_address leer)<br />
* <APIRETURN> - Fehlermeldung von Google Maps, falls vorhanden (siehe Reading error_message)<br />
* <Reading> - der Wert des Readings welches mit Attribut stateReading ausgewählt wurde<br />
* disabled - das Device wurde über das Attribut disable deaktiviert<br />
<br />
== Attribute ==<br />
<br />
{| class="wikitable"<br />
!Attribut<br />
!Default Wert<br />
!mögliche Werte<br />
!Beschreibung<br />
!Beispiel<br />
|-<br />
!align="right" |start_address<br />
|<br />
|<text><br />
|die vollständige Startadresse (erforderlich!)<br />
|Startstr 1, 12345 Startcity<br />
|-<br />
!align="right" |end_address<br />
|<br />
|<text><br />
|die vollständige Zieladresse (erforderlich!)<br />
|Zielstr 99, 99099 Zielstadt<br />
|-<br />
!align="right" |raw_data<br />
|0<br />
|0:1<br />
|legt Readings an mit allen unbearbeiteten Werten <br />
|<br />
|-<br />
!align="right" |language<br />
|<br />
|de, en, etc.<br />
|Google ermittelt die Sprache automatisch, falls nicht fest definiert<br />
|de<br />
|-<br />
!align="right" |waypoints<br />
|<br />
|lat, long<nowiki>|</nowiki>lat, long<br />
|fixe Wegpunkte auf der Strecke, mehrere Werte per pipe <nowiki>(|)</nowiki> trennen, LAT, LONG Koordinaten angeben<br />
|48.187918, 11.590514<br />
|-<br />
!align="right" |returnWaypoints<br />
|<br />
|lat, long<nowiki>|</nowiki>lat, long<br />
|fixe Wegpunkte für den Rückweg, mehrere Werte per pipe <nowiki>(|)</nowiki> trennen, LAT, LONG Koordinaten angeben, wenn leer werden "waypoints" in umgekehrter Reihenfolge verwendet<br />
|48.187918, 11.590514<br />
|-<br />
!align="right" |disable<br />
|0<br />
|0:1<br />
|Modul deaktivieren<br />
|1<br />
|-<br />
!align="right" |stateReading<br />
|<br />
|<beliebiges-Reading><br />
|Name eines Readings, dessen Wert in den STATE des Devices geschrieben wird<br />
|delay_min<br />
|-<br />
!align="right" |outputReadings<br />
|text<br />
|text,min,sec,average<br />
|Konfiguration, welche Readings erstellt werden sollen, eine oder mehrere möglich<br />
|text min<br />
|-<br />
!align="right" |includeReturn<br />
|0<br />
|0:1<br />
|aktiviert/deaktiviert, ob die gleiche Strecke in umgekehrter Richtung hinzugefügt werden soll<br>Readings werden mit return_* angegeben<br />
|1<br />
|-<br />
!align="right" |verbose<br />
|1<br />
|0:1:2:3:4:5<br />
|gibt vor, wie ausführlich geloggt wird<br />
|5<br />
|-<br />
!align="right" |travelMode<br />
|driving<br />
|driving:walking:bicycling:transit<br />
|Fortbewegungsmethode für Kalkulation<br />
|walking<br />
|-<br />
!align="right" |updateSchedule<br />
|<br />
|<Beginn-volle-Stunde>-<Ende-volle-Stunde> [<Tag>] <update-Intervall-in-Sekunden><br />
|definiert einen flexiblen Zeitraum für feinere Updates, Tag als Zahl (Sonntag 0, Montag 1 etc.), mehrere Definitionen per <nowiki>(|)</nowiki> getrennt<br />
| 6-8 1 60|6-8 2 60|6-8 3 60|6-8 4 60|6-8 5 60<br />
|-<br />
|}<br />
<br />
<br />
== Integrierte Karte ==<br />
* Zum Überprüfen der verwendeten Wegstrecke können der Hin- und Rückweg für ein TRAFFIC-Device auf einer Karte angezeigt werden.<br />
* Diese Karte ist verfügbar unter: <nowiki>http://fhem-ip:port/fhem/TRAFFIC_debug?name=<TRAFFIC-DEVICE></nowiki><br />
* Um die Karte zu erzeugen, muss "verbose" auf 5 gesetzt werden. Das führt dazu, dass ein Weblink auf die jeweilige Karte im automatisch generierten Raum "TRAFFIC_debug" angelegt wird.<br />
** <code>attr <DEVICE> verbose 5</code><br />
** <code>set <DEVICE> update</code><br />
** Raum / Link öffnen<br />
*** grün visualisiert den Hinweg<br />
*** rot visualisiert den Rückweg<br />
* Der Weblink und ggf. der erzeugte Raum werden wieder entfernt, sobald verbose auf Werte unter 5 gesetzt wird.<br />
<br />
== Bekannte Probleme ==<br />
* STATE: "REQUEST DENIED"<br />
* Reading error_message: "This API project is not authorized to use this API"<br />
** => API Key ist nicht aktiviert. Google API > API Manager > Google Maps Directions API > AKTIVIEREN <br />
<br />
* STATE: "UNKNOWN_ERROR"<br />
** => Es liegt ein Fehler bei Google vor.<br />
** => "UNKNOWN_ERROR indicates a directions request could not be processed due to a server error. The request may succeed if you try again." [https://developers.google.com/maps/documentation/javascript/directions?hl=de]<br />
<br />
* STATE: "OVER_QUERY_LIMIT"<br />
** Es wurden mehr als 2500 requests pro Tag abgesetzt. Abhilfe: Update Intervalle der TRAFFIC Devices erhöhen und "burst" zu den Stosszeiten nutzen.<br />
<br />
* STATE: "ZERO_RESULTS"<br />
** Die Waypoint Definition kann Google nicht realisieren. Statt Städtenamen besser exakte Koordinaten verwenden.<br />
<br />
== Tips ==<br />
* täglicher Burst Update zum Feierabend, 1 Stunde alle 5 Minuten updaten:<br />
** <code>define FeierabendCheck AT *17:00 set <device> update 12 300</code><br />
<br />
* komplette Reisezeit, also Hin- und Rückweg, im STATE anzeigen:<br />
** <code>attr <device> stateFormat {int(ReadingsVal($name,"delay_min",0)) + int(ReadingsVal($name,"return_delay_min",0))}</code><br />
<br />
* updateSchedule einsetzen um default update Intervall zu verfeinern<br />
** Montag bis Freitag von 6 bis 8 Uhr alle 60 Sekunden<br />
** <code>attr <device> updateSchedule 6-8 1 60|6-8 2 60|6-8 3 60|6-8 4 60|6-8 5 60</code><br />
** jeden Tag von 17 bis 19 Uhr alle 2 Minuten<br />
** <code>attr <device> updateSchedule 17-19 120</code><br />
<br />
* Waypoints definieren (Tip von erdo_king)<br />
** In Google-Maps die gewünschte Route auswählen (am PC)<br />
** Auf eine signifikante Stelle der Route klicken - hierbei auf die Fahrtrichtung achten!<br />
** Hier auf die Koordinaten klicken, diese können dann aus dem Suchfeld kopiert werden<br />
** Im Browser zurückgehen, bis die Route wieder sichtbar ist (zum späteren Datenabgleich)<br />
** Waypoints in FHEM deklarieren, Daten aktualisieren (set <device> update)<br />
** distance + duration mit den Daten von Google-Maps am PC abgleichen<br />
<br />
== to Do ==<br />
* Reading error_message löschen wenn update erfolgreich<br />
* deutsche Commandref<br />
<br />
== Weblinks ==<br />
* [https://forum.fhem.de/index.php/topic,56045.0.html Modul Vorstellung und Diskussionen]<br />
* [http://fhem.de/commandref.html#TRAFFIC Commandref]<br />
* [https://console.developers.google.com/apis Google API Manager]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Diskussion:SunnyHomeManager&diff=14752Diskussion:SunnyHomeManager2016-03-20T15:04:46Z<p>BerndArnold: Pushover ergänzt /* Steuerung der Spülmaschine */</p>
<hr />
<div>== Steuerung der Spülmaschine ==<br />
<br />
Das Forecast-Modul (98_SHMForecast) von Brun habe ich so angepasst, dass es die relativen Zeitwerte und deren Daten (Consumption, IsConsumptionRecommended, PvMeanPower) abbildet. Abhängig davon steuere ich über ein [[DOIF]] die Spülmaschine (oder Waschmaschine). Das Gerät muss nur eine Eigenschaft aufweisen: nach einem Stromausfall muss das Gerät an der Stelle weitermachen, wo es war, als der Strom "ausfiel".<br />
<br />
Wie läuft das ganze ab?<br />
* Spülmaschine füllen<br />
* Strom einschalten (direkt an der Funksteckdose - ich habe den [[HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung|HM-ES-PMSw1]] von Homematic -, per Funkschalter oder über Fhem)<br />
* Spülmaschine einschalten/starten<br />
* Den Dummy z. B. auf "NaechsteGelegenheit" setzen und die Stromzufuhr unterbrechen<br />
* Die Stromzufuhr wird dann über das DOIF wieder hergestellt, sobald die Bedingungen erfüllt sind und der Geschirrspüler setzt das Programm fort<br />
<br />
Das alles ist noch recht neu, deshalb habe ich es erstmal nur hier auf die Diskussionsseite gesetzt. Dieser Beitrag bezieht sich auf die Diskussion im Forum (siehe {{Link2Forum|Topic= 27667|Message=427122}}). Dort ist auch das benötigte Modul 98_SHMForecastRelative.<br />
Ich habe es erst seit ein paar Tagen im Einsatz. Es hat erste Tests bestanden. Als perfekt würde ich es aber noch nicht bezeichnen :-)<br />
<br />
Das DOIF kann man beliebig anpassen und mehrere Bedingungen miteinander koppeln. Ich habe z. B. eingestellt, dass die Spülmaschine nur zwischen 10:00 Uhr und 15:00 Uhr eingeschaltet werden soll (Modus NaechsteGelegenheit). Im Modus Pflicht soll er frühestens um 11:00 Uhr laufen. <br /><br />
Beim automatischen Wiedereinschalten wird eine Nachricht auf das Smartphone per [[Pushover]] verschickt.<br />
<br />
Das Abschalten muss übrigens manuell gemacht werden (entweder über den Funkschalter oder direkt an der Funksteckdose wenn man ausräumt).<br />
<br />
Der Kanal zum Schalten der HM-Funksteckdose heißt bei mir ''HM_Sw1_Spuelmaschine_Sw''. Auf die Wiedergabe der Definition habe ich hier verzichtet.<br />
<br />
''Hinweis'': alle Code-Zeilen habe ich aus der fhem.cfg-Datei kopiert. Sie sind also nicht dazu geeignet, sie in das [[Konfiguration|Befehl-Eingabefeld]] einzutragen und dort auszuführen.<br />
<br />
Hier ist zunächst der [[Dummy]], mit dem den gewünschten Modus einstellt. Die Beschreibung habe ich in das comment-Attribut gepackt.<br />
<br />
<nowiki>define SpuelmaschinenAutomatik dummy <br />
attr SpuelmaschinenAutomatik comment Aus: Geschirrspüler soll nicht laufen\<br />
NaechsteGelegenheit: Geschirrspüler wird laufen, wenn PV-Überschuss vorherrscht\<br />
Pflicht: Geschirrspüler wird laufen, unabhängig vom PV-Überschuss (weil er halt übervoll ist und es Zeit wird)\<br />
Aktiv: Geschirrspüler wurde eingeschaltet vom DOIF.\ <br />
Sofort: Geschirrspüler soll jetzt eingeschaltet werden.\<br />
\<br />
In Verbindung mit einem DOIF.\<br />
<br />
attr SpuelmaschinenAutomatik room EG_Kueche<br />
attr SpuelmaschinenAutomatik setList Aus NaechsteGelegenheit Pflicht Sofort</nowiki><br />
<br />
Voraussetzung 1: Das SHM-Modul von Brun (98_SHM.pm aus {{Link2Forum|Topic= 27667|Message=205871}}). Siehe dazu auch die Hinweise auf [[SunnyHomeManager]].<br />
<br />
<nowiki>define MySHM SHM benutzername@example.com kennwort intervall</nowiki><br />
<br />
Voraussetzung 2: Das SHMForecastRelative-Modul (98_SHMForecastRelative.pm aus {{Link2Forum|Topic= 27667|Message=427154}}). <br />
<br />
<nowiki>define MySHMForecastRelative SHMForecastRelative intervall</nowiki><br />
<br />
Und hier ist nun das Haupt-DOIF:<br />
<br />
<nowiki>define SpuelmaschineEinschalten.Pruefung DOIF ( [SpuelmaschinenAutomatik] eq "Aus" ) (\<br />
) DOELSEIF ( [SpuelmaschinenAutomatik] eq "Sofort" ) (\<br />
(set HM_Sw1_Spuelmaschine_Sw on)\ <br />
) DOELSEIF ( [SpuelmaschinenAutomatik] eq "NaechsteGelegenheit" and [MySHMForecastRelative:Next04Hours-Total] > 1000 and [MySHMForecastRelative:Next04Hours-IsConsumptionRecommended] >= 2 and [MySHMForecastRelative:ThisHour_IsConsumptionRecommended] eq "yes" and [10:00-15:00] ) (\<br />
(set Pushover msg 'Sauber' 'Jetzt wird mal die Spuelmaschine eingeschalten.' 'MeinHandy' 0 '')\<br />
(set HM_Sw1_Spuelmaschine_Sw on)\<br />
) DOELSEIF ( [SpuelmaschinenAutomatik] eq "Pflicht" and [11:00-13:00] ) (\<br />
(set Pushover msg 'Sauber' 'Jetzt wird mal die Spuelmaschine eingeschalten.' 'MeinHandy' 0 '')\<br />
(set HM_Sw1_Spuelmaschine_Sw on)\<br />
) DOELSE ()<br />
attr SpuelmaschineEinschalten.Pruefung group Photovoltaik<br />
attr SpuelmaschineEinschalten.Pruefung room EG_Kueche<br />
attr SpuelmaschineEinschalten.Pruefung wait 0:10:60:60:30</nowiki><br />
<br />
Hier ist das zweite DOIF, welches den Dummy steuert. Den Dummy innerhalb des oberen DOIFs zu setzen würde zwar funktionieren, aber dann bekommt es das obere DOIF nicht mit, dass sich der Status geändert hat (das soll Loops verhindern und ist innerhalb Fhem so gewollt).<br />
<br />
<nowiki>define SpuelmaschineEingeschaltet.Pruefung DOIF ( [HM_Sw1_Spuelmaschine_Sw] eq "on" ) (\<br />
(set SpuelmaschinenAutomatik Aktiv)\<br />
) DOELSEIF ( [HM_Sw1_Spuelmaschine_Sw] eq "off" ) (\<br />
\<br />
) DOELSE ()<br />
attr SpuelmaschineEingeschaltet.Pruefung room EG_Kueche</nowiki><br />
<br />
Ich hatte noch einen FS20-Schalter ([[FS20 S4A Aufputz Sender|S4A]]) übrig. Mit diesem steuere ich den Dummy. Das ist nicht zwingend notwendig, erhöht aber bestimmt den WAF :-)<br />
<br />
<nowiki>define Spuelmaschine.TasterWahl notify FS20S4_Kueche_Btn.:toggle { \<br />
Log 1, "Button $NAME: $EVENT";;\<br />
if ( $NAME =~ /Btn1/ ) {\<br />
fhem( "set SpuelmaschinenAutomatik Aus" );;\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw off" );;\<br />
} elsif ( $NAME =~ /Btn2/ ) {\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw on" );;\<br />
} elsif ( $NAME =~ /Btn3/ ) {\<br />
fhem( "set SpuelmaschinenAutomatik NaechsteGelegenheit" );;\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw off" );;\<br />
} elsif ( $NAME =~ /Btn4/ ) {\<br />
fhem( "set SpuelmaschinenAutomatik Pflicht" );;\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw off" );;\<br />
} else {\<br />
Log 1, "Unbekannter Fall: $NAME / $EVENT";;\<br />
}\<br />
}<br />
attr Spuelmaschine.TasterWahl room EG_Kueche</nowiki><br />
<br />
Der Nachteil bei diesem [[Notify]] ist, dass das Taster-Objekt nicht unter "Probably associated with..." angelistet wird. Wenn man das möchte, muss man vier einzelne Notifiy-Definitionen erstellen anstelle dem einen hier.<br />
<br />
--[[Benutzer:BerndArnold|BerndArnold]] ([[Benutzer Diskussion:BerndArnold|Diskussion]]) 01:00, 20. Mär. 2016 (CET)</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Diskussion:SunnyHomeManager&diff=14746Diskussion:SunnyHomeManager2016-03-20T11:54:46Z<p>BerndArnold: Hinweise auf 98_SHM* hinzugefügt, Leerzeile am Ende der Codeblöcke entfernt, Details hinzugefügt /* Steuerung der Spülmaschine */</p>
<hr />
<div>== Steuerung der Spülmaschine ==<br />
<br />
Das Forecast-Modul (98_SHMForecast) von Brun habe ich so angepasst, dass es die relativen Zeitwerte und deren Daten (Consumption, IsConsumptionRecommended, PvMeanPower) abbildet. Abhängig davon steuere ich über ein [[DOIF]] die Spülmaschine (oder Waschmaschine). Das Gerät muss nur eine Eigenschaft aufweisen: nach einem Stromausfall muss das Gerät an der Stelle weitermachen, wo es war, als der Strom "ausfiel".<br />
<br />
Wie läuft das ganze ab?<br />
* Spülmaschine füllen<br />
* Strom einschalten (direkt an der Funksteckdose - ich habe den [[HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung|HM-ES-PMSw1]] von Homematic -, per Funkschalter oder über Fhem)<br />
* Spülmaschine einschalten/starten<br />
* Den Dummy z. B. auf "NaechsteGelegenheit" setzen und die Stromzufuhr unterbrechen<br />
* Die Stromzufuhr wird dann über das DOIF wieder hergestellt, sobald die Bedingungen erfüllt sind und der Geschirrspüler setzt das Programm fort<br />
<br />
Das alles ist noch recht neu, deshalb habe ich es erstmal nur hier auf die Diskussionsseite gesetzt. Dieser Beitrag bezieht sich auf die Diskussion im Forum (siehe {{Link2Forum|Topic= 27667|Message=427122}}). Dort ist auch das benötigte Modul 98_SHMForecastRelative.<br />
Ich habe es erst seit ein paar Tagen im Einsatz. Es hat erste Tests bestanden. Als perfekt würde ich es aber noch nicht bezeichnen :-)<br />
<br />
Das DOIF kann man beliebig anpassen und mehrere Bedingungen miteinander koppeln. Ich habe z. B. eingestellt, dass die Spülmaschine nur zwischen 10:00 Uhr und 15:00 Uhr eingeschaltet werden soll (Modus NaechsteGelegenheit). Im Modus Pflicht soll er frühestens um 11:00 Uhr laufen.<br />
<br />
Das Abschalten muss übrigens manuell gemacht werden (entweder über den Funkschalter oder direkt an der Funksteckdose wenn man ausräumt).<br />
<br />
Der Kanal zum Schalten der HM-Funksteckdose heißt bei mir ''HM_Sw1_Spuelmaschine_Sw''. Auf die Wiedergabe der Definition habe ich hier verzichtet.<br />
<br />
''Hinweis'': alle Code-Zeilen habe ich aus der fhem.cfg-Datei kopiert. Sie sind also nicht dazu geeignet, sie in das [[Konfiguration|Befehl-Eingabefeld]] einzutragen und dort auszuführen.<br />
<br />
Hier ist zunächst der [[Dummy]], mit dem den gewünschten Modus einstellt. Die Beschreibung habe ich in das comment-Attribut gepackt.<br />
<br />
<nowiki>define SpuelmaschinenAutomatik dummy <br />
attr SpuelmaschinenAutomatik comment Aus: Geschirrspüler soll nicht laufen\<br />
NaechsteGelegenheit: Geschirrspüler wird laufen, wenn PV-Überschuss vorherrscht\<br />
Pflicht: Geschirrspüler wird laufen, unabhängig vom PV-Überschuss (weil er halt übervoll ist und es Zeit wird)\<br />
Aktiv: Geschirrspüler wurde eingeschaltet vom DOIF.\ <br />
Sofort: Geschirrspüler soll jetzt eingeschaltet werden.\<br />
\<br />
In Verbindung mit einem DOIF.\<br />
<br />
attr SpuelmaschinenAutomatik room EG_Kueche<br />
attr SpuelmaschinenAutomatik setList Aus NaechsteGelegenheit Pflicht Sofort</nowiki><br />
<br />
Voraussetzung 1: Das SHM-Modul von Brun (98_SHM.pm aus {{Link2Forum|Topic= 27667|Message=205871}}). Siehe dazu auch die Hinweise auf [[SunnyHomeManager]].<br />
<br />
<nowiki>define MySHM SHM benutzername@example.com kennwort intervall</nowiki><br />
<br />
Voraussetzung 2: Das SHMForecastRelative-Modul (98_SHMForecastRelative.pm aus {{Link2Forum|Topic= 27667|Message=427154}}). <br />
<br />
<nowiki>define MySHMForecastRelative SHMForecastRelative intervall</nowiki><br />
<br />
Und hier ist nun das Haupt-DOIF:<br />
<br />
<nowiki>define SpuelmaschineEinschalten.Pruefung DOIF ( [SpuelmaschinenAutomatik] eq "Aus" ) (\<br />
) DOELSEIF ( [SpuelmaschinenAutomatik] eq "Sofort" ) (\<br />
(set HM_Sw1_Spuelmaschine_Sw on)\ <br />
) DOELSEIF ( [SpuelmaschinenAutomatik] eq "NaechsteGelegenheit" and [MySHMForecastRelative:Next04Hours-Total] > 1000 and [MySHMForecastRelative:Next04Hours-IsConsumptionRecommended] >= 2 and [MySHMForecastRelative:ThisHour_IsConsumptionRecommended] eq "yes" and [10:00-15:00] ) (\<br />
(set Pushover msg 'Sauber' 'Jetzt wird mal die Spuelmaschine eingeschalten.' 'MeinHandy' 0 '')\<br />
(set HM_Sw1_Spuelmaschine_Sw on)\<br />
) DOELSEIF ( [SpuelmaschinenAutomatik] eq "Pflicht" and [11:00-13:00] ) (\<br />
(set Pushover msg 'Sauber' 'Jetzt wird mal die Spuelmaschine eingeschalten.' 'MeinHandy' 0 '')\<br />
(set HM_Sw1_Spuelmaschine_Sw on)\<br />
) DOELSE ()<br />
attr SpuelmaschineEinschalten.Pruefung group Photovoltaik<br />
attr SpuelmaschineEinschalten.Pruefung room EG_Kueche<br />
attr SpuelmaschineEinschalten.Pruefung wait 0:10:60:60:30</nowiki><br />
<br />
Hier ist das zweite DOIF, welches den Dummy steuert. Den Dummy innerhalb des oberen DOIFs zu setzen würde zwar funktionieren, aber dann bekommt es das obere DOIF nicht mit, dass sich der Status geändert hat (das soll Loops verhindern und ist innerhalb Fhem so gewollt).<br />
<br />
<nowiki>define SpuelmaschineEingeschaltet.Pruefung DOIF ( [HM_Sw1_Spuelmaschine_Sw] eq "on" ) (\<br />
(set SpuelmaschinenAutomatik Aktiv)\<br />
) DOELSEIF ( [HM_Sw1_Spuelmaschine_Sw] eq "off" ) (\<br />
\<br />
) DOELSE ()<br />
attr SpuelmaschineEingeschaltet.Pruefung room EG_Kueche</nowiki><br />
<br />
Ich hatte noch einen FS20-Schalter ([[FS20 S4A Aufputz Sender|S4A]]) übrig. Mit diesem steuere ich den Dummy. Das ist nicht zwingend notwendig, erhöht aber bestimmt den WAF :-)<br />
<br />
<nowiki>define Spuelmaschine.TasterWahl notify FS20S4_Kueche_Btn.:toggle { \<br />
Log 1, "Button $NAME: $EVENT";;\<br />
if ( $NAME =~ /Btn1/ ) {\<br />
fhem( "set SpuelmaschinenAutomatik Aus" );;\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw off" );;\<br />
} elsif ( $NAME =~ /Btn2/ ) {\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw on" );;\<br />
} elsif ( $NAME =~ /Btn3/ ) {\<br />
fhem( "set SpuelmaschinenAutomatik NaechsteGelegenheit" );;\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw off" );;\<br />
} elsif ( $NAME =~ /Btn4/ ) {\<br />
fhem( "set SpuelmaschinenAutomatik Pflicht" );;\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw off" );;\<br />
} else {\<br />
Log 1, "Unbekannter Fall: $NAME / $EVENT";;\<br />
}\<br />
}<br />
attr Spuelmaschine.TasterWahl room EG_Kueche</nowiki><br />
<br />
Der Nachteil bei diesem [[Notify]] ist, dass das Taster-Objekt nicht unter "Probably associated with..." angelistet wird. Wenn man das möchte, muss man vier einzelne Notifiy-Definitionen erstellen anstelle dem einen hier.<br />
<br />
--[[Benutzer:BerndArnold|BerndArnold]] ([[Benutzer Diskussion:BerndArnold|Diskussion]]) 01:00, 20. Mär. 2016 (CET)</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Diskussion:SunnyHomeManager&diff=14740Diskussion:SunnyHomeManager2016-03-20T00:00:42Z<p>BerndArnold: Neuer Abschnitt /* Steuerung der Spülmaschine */</p>
<hr />
<div>== Steuerung der Spülmaschine ==<br />
<br />
Das Forecast-Modul (98_SHMForecast) von Brun habe ich so angepasst, dass es die relativen Zeitwerte und deren Daten (Consumption, IsConsumptionRecommended, PvMeanPower) abbildet. Abhängig davon steuere ich über ein [[DOIF]] die Spülmaschine (oder Waschmaschine). Das Gerät muss nur eine Eigenschaft aufweisen: nach einem Stromausfall muss das Gerät an der Stelle weitermachen, wo es war, als der Strom "ausfiel".<br />
<br />
Wie läuft das ganze ab?<br />
* Spülmaschine füllen<br />
* Strom einschalten (direkt an der Funksteckdose - ich habe den [[HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung|HM-ES-PMSw1]] von Homematic -, per Funkschalter oder über Fhem)<br />
* Spülmaschine einschalten/starten<br />
* Den Dummy z. B. auf "NaechsteGelegenheit" setzen und die Stromzufuhr unterbrechen<br />
* Die Stromzufuhr wird dann über das DOIF wieder hergestellt, sobald die Bedingungen erfüllt sind und das Geschirr wird gespült<br />
<br />
Das alles ist noch recht neu, deshalb habe ich es erstmal nur hier auf die Diskussionsseite gesetzt. Dieser Beitrag bezieht sich auf die Diskussion im Forum (siehe {{Link2Forum|Topic= 27667 |Message=427122}}). Dort ist auch das benötigte Modul 98_SHMForecastRelative.<br />
Ich habe es erst seit ein paar Tagen im Einsatz. Es hat erste Tests bestanden. Als perfekt würde ich es aber noch nicht bezeichnen :-)<br />
<br />
Das DOIF kann man beliebig anpassen und mehrere Bedingungen miteinander koppeln. Ich habe z. B. eingestellt, dass die Spülmaschine nur zwischen 10:00 Uhr und 15:00 Uhr eingeschaltet werden soll (Modus NaechsteGelegenheit). Im Modus Pflicht soll er frühestens um 11:00 Uhr laufen.<br />
<br />
Das Abschalten muss übrigens manuell gemacht werden (entweder über den Funkschalter oder direkt an der Funksteckdose wenn man ausräumt).<br />
<br />
Hier ist zunächst der [[Dummy]], mit dem den gewünschten Modus einstellt. Die Beschreibung habe ich in das comment-Attribut gepackt.<br />
<br />
''Hinweis'': alle Code-Zeilen habe ich aus der fhem.cfg-Datei kopiert. Sie sind also nicht dazu geeignet, sie in das [[Konfiguration|Befehl-Eingabefeld]] einzutragen und dort auszuführen.<br />
<br />
<nowiki>define SpuelmaschinenAutomatik dummy <br />
attr SpuelmaschinenAutomatik comment Aus: Geschirrspüler soll nicht laufen\<br />
NaechsteGelegenheit: Geschirrspüler wird laufen, wenn PV-Überschuss vorherrscht\<br />
Pflicht: Geschirrspüler wird laufen, unabhängig vom PV-Überschuss (weil er halt übervoll ist und es Zeit wird)\<br />
Aktiv: Geschirrspüler wurde eingeschaltet vom DOIF.\ <br />
Sofort: Geschirrspüler soll jetzt eingeschaltet werden.\<br />
\<br />
In Verbindung mit einem DOIF.\<br />
<br />
attr SpuelmaschinenAutomatik room EG_Kueche<br />
attr SpuelmaschinenAutomatik setList Aus NaechsteGelegenheit Pflicht Sofort<br />
</nowiki><br />
<br />
Und hier ist nun das Haupt-DOIF:<br />
<br />
<nowiki>define SpuelmaschineEinschalten.Pruefung DOIF ( [SpuelmaschinenAutomatik] eq "Aus" ) (\<br />
) DOELSEIF ( [SpuelmaschinenAutomatik] eq "Sofort" ) (\<br />
(set HM_Sw1_Spuelmaschine_Sw on)\ <br />
) DOELSEIF ( [SpuelmaschinenAutomatik] eq "NaechsteGelegenheit" and [MySHMForecastRelative:Next04Hours-Total] > 1000 and [MySHMForecastRelative:Next04Hours-IsConsumptionRecommended] >= 2 and [MySHMForecastRelative:ThisHour_IsConsumptionRecommended] eq "yes" and [10:00-15:00] ) (\<br />
(set Pushover msg 'Sauber' 'Jetzt wird mal die Spuelmaschine eingeschalten.' 'MeinHandy' 0 '')\<br />
(set HM_Sw1_Spuelmaschine_Sw on)\<br />
) DOELSEIF ( [SpuelmaschinenAutomatik] eq "Pflicht" and [11:00-13:00] ) (\<br />
(set Pushover msg 'Sauber' 'Jetzt wird mal die Spuelmaschine eingeschalten.' 'MeinHandy' 0 '')\<br />
(set HM_Sw1_Spuelmaschine_Sw on)\<br />
) DOELSE ()<br />
attr SpuelmaschineEinschalten.Pruefung group Photovoltaik<br />
attr SpuelmaschineEinschalten.Pruefung room EG_Kueche<br />
attr SpuelmaschineEinschalten.Pruefung wait 0:10:60:60:30<br />
</nowiki><br />
<br />
Hier ist das zweite DOIF, welches den Dummy steuert. Den Dummy innerhalb des oberen DOIFs zu setzen würde zwar funktionieren, aber dann bekommt es das obere DOIF nicht mit, dass sich der Status geändert hat (das soll Loops verhindern und ist innerhalb Fhem so gewollt).<br />
<br />
<nowiki>define SpuelmaschineEingeschaltet.Pruefung DOIF ( [HM_Sw1_Spuelmaschine_Sw] eq "on" ) (\<br />
(set SpuelmaschinenAutomatik Aktiv)\<br />
) DOELSEIF ( [HM_Sw1_Spuelmaschine_Sw] eq "off" ) (\<br />
\<br />
) DOELSE ()<br />
attr SpuelmaschineEingeschaltet.Pruefung room EG_Kueche<br />
</nowiki><br />
<br />
Ich hatte noch einen FS20-Schalter ([[FS20 S4A Aufputz Sender|S4A]]) übrig. Mit diesem steuere ich den Dummy. Das ist nicht zwingend notwendig, erhöht aber bestimmt den WAF :-)<br />
<br />
<nowiki>define Spuelmaschine.TasterWahl notify FS20S4_Kueche_Btn.:toggle { \<br />
Log 1, "Button $NAME: $EVENT";;\<br />
if ( $NAME =~ /Btn1/ ) {\<br />
fhem( "set SpuelmaschinenAutomatik Aus" );;\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw off" );;\<br />
} elsif ( $NAME =~ /Btn2/ ) {\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw on" );;\<br />
} elsif ( $NAME =~ /Btn3/ ) {\<br />
fhem( "set SpuelmaschinenAutomatik NaechsteGelegenheit" );;\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw off" );;\<br />
} elsif ( $NAME =~ /Btn4/ ) {\<br />
fhem( "set SpuelmaschinenAutomatik Pflicht" );;\<br />
fhem( "set HM_Sw1_Spuelmaschine_Sw off" );;\<br />
} else {\<br />
Log 1, "Unbekannter Fall: $NAME / $EVENT";;\<br />
}\<br />
}<br />
attr Spuelmaschine.TasterWahl room EG_Kueche<br />
</nowiki><br />
<br />
Der Nachteil bei diesem [[Notify]] ist, dass das Taster-Objekt nicht unter "Probably associated with..." angelistet wird. Wenn man das möchte, muss man vier einzelne Notifiy-Definitionen erstellen anstelle dem einen hier.<br />
<br />
--[[Benutzer:BerndArnold|BerndArnold]] ([[Benutzer Diskussion:BerndArnold|Diskussion]]) 01:00, 20. Mär. 2016 (CET)</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Pushover&diff=12467Pushover2015-10-08T10:24:25Z<p>BerndArnold: Stil, Rechtschreibung, Korrektur, Wikify</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Senden von sogenannten Push-Nachrichten auf Tablets oder Smartphones<br />
|ModType=d<br />
<!-- |ModCategory= (noch?) nicht verwendet --><br />
<!-- |ModCmdRef= wird automatisch generiert --><br />
|ModTechName=70_Pushover.pm<br />
|ModOwner=Johannes B<br />
}}<br />
<br />
[[Pushover]] ist ein Dienst, mit dem es möglich ist, sogenannte Push-Nachrichten auf ein Apple- oder Android-Gerät zu schicken (Link zum Dienst: [https://pushover.net pushover.net]).<br />
Um die Push-Nachrichten zu empfangen, muss die dazu passende App installiert werden (siehe unten). Der Dienst ist grundlegend kostenlos. Die App-Nutzung ist einmalig zu bezahlen. Es fallen keine Abo-Gebühren an (Stand 08.10.2015).<br />
<br />
== Installation ==<br />
Es muss zwingend ein Pushover-Account erstellt werden. Anschließend ist auf der Pushover-Website eine Application zu hinterlegen (auf der Pushover-Website zu ''Apps & Plugins'' navigieren, Punkt ''Create a New Application'' wählen).<br />
Die Application dient dazu, die Nachrichten Fhem zuzuweisen und sie leichter erkennbar zu machen. Für die Application wird von Pushover automatisch ein Token generiert (siehe Abschnitt ''API Token/Key'' auf der Pushover-Website).<br />
<br />
Nach Erstellung der Application müssen (nach erfolgter Registrierung auf der Webseite) die einzelnen Geräte, auf denen Nachrichten gesendet werden sollen, registriert werden.<br />
Die Registrierung der Geräte erfolgt nach dem Anmelden in der App auf dem Endgerät automatisch.<br />
<br />
Auf dem Endgerät muss die Pushover-App installiert werden. Dies geschieht z. B. bei Apple-Geräten mit Hilfe des AppStores. Stand 08.10.2015 kostet diese Anwendung nach einer 7-tägigen kostenlosen Probephase 4,99 Euro (In-App-Kauf).<br />
* Apple-Geräte: [https://itunes.apple.com/de/app/pushover-notifications/id506088175?mt=8 Pushover-App im Apple Store]<br />
* Android-Geräte: [https://play.google.com/store/apps/details?id=net.superblock.pushover&hl=de Pushover-App im Google Playstore]<br />
<br />
'''Wichtig für Debian-Nutzer'''<br /><br />
Für das Modul ist noch eine Library notwendig:<br />
<pre>sudo apt-get install libio-socket-ssl-perl</pre><br />
<br />
== Einbinden des Dienstes in Fhem ==<br />
Das Modul wird mit dem folgenden Befehl in Fhem definiert:<br />
:<code>define pushmsg Pushover <TOKEN> <USER></code><br />
<br />
Die Token werden der Pushover-Seite entnommen.<br /><br />
TOKEN = API Token/Key (zu finden unter der angelegten Application)<br /><br />
USER = Your User Key (wird direkt nach dem Einloggen angezeigt)<br />
<br />
== Senden einer Nachricht mit Fhem ==<br />
Syntax:<br />
<pre>You can send messages via the following command:<br />
# set <Pushover_device> msg <title> <msg> <device> <priority> <sound> [<retry> <expire>]<br />
</pre><br />
<br />
Beispiel:<br />
:<code>fhem("set pushmsg msg 'fhem' 'Das Fenster wurde geschlossen!' '' 0 ''");</code><br />
<br />
Nachricht, sobald Fhem neu geladen wurde, mit Hilfe einer [[Notify]]-Anweisung:<br />
<pre>define notify_fhem_reload notify global:INITIALIZED set pushmsg msg 'fhem' 'Ich wurde neu geladen! - $EVENT' '' 0 ''</pre><br />
<br />
== Erinnerungsfunktion mit Hilfe des Kalendermoduls ==<br />
Zuerst wird eine Textdatei mit den Daten für die Erinnerung im Fhem-Hauptverzeichnis erzeugt. Hier folgt ein Beispiel für den Fall, dass Fhem auf einer Fritzbox läuft:<br />
<br />
<pre><br />
telnet fritz.box<br />
cd /var/media/ftp/fhem/opt/fhem/FHEM/<br />
vi events.holiday<br />
<br />
# ESC-i drücken um in den vi-Editmodus zu gelangen<br />
<br />
# Format fur einzelne Tage: 1 MM-DD <Text><br />
1 03-23 Schwarze Tonne rausstellen<br />
1 03-24 Gelbe Tonne rausstellen<br />
<br />
# mit ESC:wq die Datei speichern<br />
</pre><br />
[[Datei:Define_events_holiday.png|mini|400px|rechts|Details des definierten Kalenders]]<br />
In Fhem muss der Kalender folgendermaßen definiert werden:<br />
:<code>define events holiday</code><br />
<br />
Das im Bild gezeigte ''Device'' sollte erscheinen.<br />
<br />
Der Befehl für die Zeitsteuerung wird mit dem folgenden [[at]] definiert (dieser Befehl muss ohne Zeilenumbrüche in die [[Konfiguration]] übernommen werden, vorzugsweise durch Eingabe in das Befehlsfeld):<br />
:<code>define CheckEventToday at *20:15:00 {my $Eventname;;my $EventHeute;;$EventHeute=fhem("get events today");;print $EventHeute;;if ($EventHeute ne "none"){ $Eventname="Ereignis: $EventHeute";;fhem("set pushmsg msg 'fhem' 'Erinnerung an: $Eventname' '' 0 ''");;}}</code><br />
<br />
== Links ==<br />
* Fhem-Commandref [http://fhem.de/commandref_DE.html#Pushover Pushover]<br />
* Thread über das Modul im [http://forum.fhem.de/index.php/topic,16215.0.html Fhem-Forum]<br />
* Pushover-API [https://pushover.net/api https://pushover.net/api]<br />
<br />
[[Kategorie:Code Snippets]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HM-Sen-MDIR-O_Funk-IR-Bewegungsmelder_au%C3%9Fen&diff=10598HM-Sen-MDIR-O Funk-IR-Bewegungsmelder außen2015-03-22T18:20:40Z<p>BerndArnold: Infobox hinzugefügt (Quelle: eq-3.de); Bild ergänzt; Rechtschreibung korrigiert; Stil; Wikify</p>
<hr />
<div>{{Infobox Hardware|Bild=HM-Sen-MDIR-O.jpg<br />
|Bildbeschreibung=HM-Sen-MDIR-O<br />
|HWProtocol=HomeMatic<br />
|HWType=Sensor<br />
|HWCategory=HomeMatic<br />
|HWComm=868,3 MHz<br />
|HWChannels=1<br />
|HWPowerConsumption=unbekannt<br />
|HWVoltage=4,5 V<br />
|HWPoweredBy=Batterie, 3x LR06 (Mignon)<br />
|HWSize=76 x 74 x 90 mm<br />
|HWDeviceFHEM=[[CUL_HM]]<br />
|HWManufacturer=eQ-3 <br />
}}<br />
<br />
'''HM-Sen-MDIR-O'''<br />
HomeMatic Funk-IR-Bewegungsmelder außen<br />
<br />
== Features ==<br />
PIR-Bewegungsmelder mit Helligkeitssensor zur Tag-/Nachtumschaltung.<br />
<br />
'''Technische Daten:'''<br />
* Erfassungswinkel: ca. 90°<br />
* Erfassungsbereich: ca. 9 m<br />
* Drehbar: 360°<br />
* Neigbar: 45°<br />
* Schutzart: IP 44<br />
<br />
== Hinweise zur Inbetriebnahme und Installation ==<br />
&lt;Bitte ergänzen&gt;<br />
<br />
<br />
<br />
== Betrieb mit FHEM ==<br />
<br />
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Die Anlerntaste am Bewegungsmelder sollte hierzu nur kurz betätigt werden. Bei einer Betätigung von vier Sekunden wird der Melder nur bei Unterschreiten einer festgelegten Helligkeitsschwelle auslösen (weitere Informationen siehe Abschnitt ''Anlernen'' der Herstellerdokumentation).<br />
<br />
=== Event-Monitor ===<br />
<br />
In regelmäßigen Abständen werden die folgenden Daten vom Bewegungsmelder (hier: HM-Sen-MDIR-O-2) übermittelt:<br />
<pre><br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120<br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer cover: closed<br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer battery: ok<br />
</pre><br />
<br />
Wird Bewegung erkannt, wird Folgendes vom Gerät (hier: HM-Sen-MDIR-O-2) übermittelt:<br />
<pre><br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer trigDst_2573FB: noConfig<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion: on (to MyHMLAN)<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motionCount: 235_next:116s<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120<br />
</pre><br />
<br />
=== Log-Auszug ===<br />
<br />
&lt;Bitte ergänzen&gt;<br />
<br />
=== fhem.cfg ===<br />
<br />
Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt (Beispiel: HM-Sen-MDIR-O-2).<br />
<br />
<pre><br />
define HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer CUL_HM 2B033A<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer IODev MyHMLAN<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actCycle 000:10<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actStatus alive<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer autoReadReg 4_reqStatus<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer expert 2_full<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer firmware 1.6<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer model HM-Sen-MDIR-O-2<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer peerIDs 00000000,<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer room CUL_HM<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer serialNr LEQ0xxxxxx<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer subType motionDetector<br />
</pre><br />
<br />
=== Konfiguration über Register ===<br />
==== Anzeige aller dekodierten Register ====<br />
<nowiki>get &lt;name&gt; regList</nowiki><br />
zeigt alle moeglichen 'dekodierten' Register an. Fuer mdir sind dies alle, sollte also komplett sein. Hier findet man sowohl den Wertebereich alsauch eine (sehr) kleine Beschreibung.<br />
Ausgabe:<br />
<br />
<nowiki><br />
list: register | range | peer | description<br />
0: pairCentral | 0 to 16777215 | | pairing to central<br />
1: brightFilter | 0 to 7 | | brightness filter - ignore light at night<br />
1: captInInterval | literal | | capture within interval options:on,off<br />
1: evtFltrNum | 1 to 15 | | sensitivity - read each n-th puls<br />
1: evtFltrPeriod | 0.5 to 7.5s | | event filter period<br />
1: ledOnTime | 0 to 1.275s | | LED ontime<br />
1: minInterval | literal | | minimum interval in sec options:240,60,120,30,15<br />
4: peerNeedsBurst | literal | required | peer expects burst options:on,off<br />
</nowiki><br />
<br />
;minInterval<br />
: Minimaler Interval in Sekunden ab wann die nächste Bewegung registriert werden kann. Der Standard ist 240. Also nach einer Bewegungs-Meldung werden weitere Bewegungen für 4 Minuten ignoriert bis die nächste Meldung erfolgt.<br />
;brightFilter<br />
: Filtert Bewegungen nach Helligkeit aus. 0 Filtert nichts aus, d.h. es wird auch bei Helligkeit gemeldet. 7 Filtert bis 10 Lux? alles aus, daher werden Bewegungen nur bei Dunkelheit gemeldet.<br />
;evtFltrNum<br />
: Filtert Bewegungen aus. Steht dieser Wert z.B. auf 5 so wird erst bei der fünften Bewegung die Meldung gesendet.<br />
;evtFltrPeriod<br />
: Gibt an wie viel Zeit zwischen zwei Bewegungen vergehen muss um für den evtFltrNum Filter gezählt zu werden. Steht dieser Wert auf 1 und evtFltrNum auf 5 so muss der Sensor 5 Sekunden Bewegungen registrieren um eine Meldung zu senden.<br />
<br />
=== Gerät bei Bewegung schalten ===<br />
<br />
Mit dem folgenden [[Notify]] kann z. B ein [[HM-LC-SW1-FM Schaltaktor 1-fach UP|Unterputz-Schaltaktor]] für die angegebene Zeit (in Sekunden) eingeschaltet werden - ein [[Homematic Peering Beispiele|Peeren]] ist dazu vorher nicht erforderlich. Das Einschalten passiert in diesem Beispiel unabhängig von der Helligkeit.<br />
<br />
<pre><br />
define Notify_Bewegungsmelder_Haustuer notify HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer:motion set HM_LC_SW1_FM_298FB2_HaustuerLicht on-for-timer 300<br />
</pre><br />
<br />
=== Gerät bei Bewegung und Dunkelheit mit minimaler Funklast schalten ===<br />
<br />
Das fortgeschrittene Beispiel steuert die Beleuchtung in Abhängigkeit von der Außenhelligkeit und minimiert die Funklast. In diesem Beispiel werden zwei Lichtkreise angesteuert, die die Außenbeleuchtung realisieren:<br />
<br />
define WintergartenAussen structure room EG.Durchgang.Aussenlicht_Sw_03 EG.Durchgang.Aussenlicht_Sw_04<br />
<br />
define MotionTerasseScheune notify EG.Scheune.OutsideMotionDetect:motion:.* { \<br />
if ( Value("EG.Durchgang.Aussenlicht_Sw_03") eq "off" && ReadingsVal( "EG.Scheune.OutsideMotionDetect", "brightness", "") <= 90 ) { \<br />
fhem ("set WintergartenAussen on ;; define MWG_AUS at +00:05:00 set WintergartenAussen off") } \<br />
else { \<br />
fhem ("delete MWG_AUS ;; define MWG_AUS at +00:05:00 set EWintergartenAussen off" ) } }<br />
<br />
define MotionTerasseDurchgang notify EG.Durchgang.OutsideMotionDetect:motion:.* { \<br />
if ( Value("EG.Durchgang.Aussenlicht_Sw_03") eq "off" && ReadingsVal( "EG.Durchgang.OutsideMotionDetect", "brightness", "") <= 90 ) { \<br />
fhem ("set WintergartenAussen on ;; define MWG_AUS at +00:05:00 set WintergartenAussen off") } \<br />
else { \<br />
fhem ("delete MWG_AUS ;; define MWG_AUS at +00:05:00 set EWintergartenAussen off" ) } }<br />
<br />
Es werden zwei notify-Kommandos definiert, die von zwei verschiedenen Bewegungsmeldern (EG.Scheune.OutsideMotionDetect und EG.Durchgang.OutsideMotionDetect) getriggert werden. Beide aktivieren das Licht nur, wenn es derzeit '''aus'''<br />
<br />
(Value("EG.Durchgang.Aussenlicht_Sw_03") eq "off)<br />
<br />
und '''dunkel'''<br />
<br />
(ReadingsVal( "EG.Durchgang.OutsideMotionDetect", "brightness", "") <= 90 ))<br />
<br />
ist.<br />
<br />
Da die Bewegungsmelder bei jeder weiteren Bewegung neue '''on-for-timer'''-Kommandos triggern würden, ist die Lösung mit dem at-Befehl eleganter. Dieser löscht und verzögert die Ausschaltzeit nur auf dem fhem-Server ohne Funkkommunikation.<br />
<br />
Die Schalter sind in diesem Beispiel EG.Durchgang.Aussenlicht_Sw_03 EG.Durchgang.Aussenlicht_Sw_04 zwei Kanäle des Hutschienen-4-Kanal-230V-Aktors. Es ist dringend empfohlen, diesen beim Schalten von Außenbeleuchtung mit einem LS/FS-Schutz (16A+0.03A) für jeden Kanal abzusichern. Das ganze kann sehr adrett in einen 8-Einheiten-Verteilerkasten in Unterputz- oder Aufputz-Verschaltung realisiert werden.<br />
<br />
=== Gerät bei Bewegung in Abhängigkeit der Helligkeit schalten ===<br />
<br />
Mit der nachfolgenden Notify-Definition werden zwei Log-Einträge erzeugt, eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und ein [[HM-LC-SW1-FM Schaltaktor 1-fach UP|Unterputz-Schaltaktor]] für die angegebene Zeit (in Sekunden) eingeschaltet, falls die gemessene Helligkeit am Bewegungsmelder kleiner oder gleich 90 ist.<br />
<br />
Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann.<br />
<br />
<pre><br />
HM_BewegMelder_Carport:motion { <br />
Log 1, "Trigger-Notify von BewegMelderCarport: @";<br />
Log 1, ReadingsVal( "HM_BewegMelder_Carport", "brightness", "");<br />
fhem( "set E2_Dreambox showText Bewegung am Carport" ) if ReadingsVal("E2_Dreambox","state","") eq "on"; <br />
if ( ReadingsVal( "HM_BewegMelder_Carport", "brightness", "") <= 90 ) {<br />
fhem( "set HM_Sw1_GarageLED on-for-timer 300" );<br />
}<br />
}<br />
</pre><br />
<br />
== Bekannte Probleme ==<br />
Die Geräte der HM-Sen Serie senden keine zyklischen Status-Informationen. Der Action Detektor erklärt sie daher für tot bzw. ist nicht brauchbar. Zum Messen der Außen-Helligkeit sind die Sensoren dadurch unbrauchbar. Darüber hinaus verfügen diese Geräte auch über keinen Sabotage-Kontakt.<br />
<br />
== Links ==<br />
Manual: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/104108_HM-Sen-MDIR-O_V1.2_GE_eQ-3_20120510.pdf PDF HM-Sen-MDIR-O],<br />
[http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-Sen-MDIR-O-2_UM_GE_131024.pdf PDF HM-Sen-MDIR-O-2]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Lichtsensoren]]<br />
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Datei:HM-Sen-MDIR-O.jpg&diff=10597Datei:HM-Sen-MDIR-O.jpg2015-03-22T18:05:43Z<p>BerndArnold: </p>
<hr />
<div></div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=If-condition&diff=10419If-condition2015-03-03T16:28:24Z<p>BerndArnold: Logikkorrektur ("ab 18:00" erfordert einen Größer-gleich-Vergleichsoperator); Typos; Gleichhaltung Schreibweise "Perl-"; Verdeutlichung</p>
<hr />
<div>{{SEITENTITEL:if-condition}}<br />
{{Randnotiz|RNTyp=Info|RNText=Hier wird die Verwendung der Perl-Anweisung if beschrieben. Diese ist nicht mit dem Fhem-Befehl [http://fhem.de/commandref.html#IF IF] zu verwechseln!}}<br />
Hier entsteht eine Erklärung über die richtige Benutzung von if-Bedingungen.<br />
<br />
if-Abfragen können Bedingungen prüfen und abhängig davon Befehle ausführen. Die Syntax und die Verwendung sollen an möglichst vielen Beispielen erläutert werden.<br />
<br />
== Einfache if-Bedingung ==<br />
:<code>define einschalten at +*00:15 { if ( &quot;1&quot; eq &quot;1&quot; ) { fhem(&quot;set Funkschalter on&quot;) }}</code><br />
* Die äusseren geschweiften Klammern sagen Fhem, dass innerhalb Perl-Befehle ausgeführt werden.<br />
* Das Wort '''if''' leitet die Bedingung ein.<br />
* In den runden Klammern steht die Bedingung<br />
: ([http://de.selfhtml.org/perl/sprache/operatoren.htm#vergleich Perl-Vergleichsoperatoren] sind für Zeichen(ketten)- und Zahlenvergleiche unterschiedlich!)<br />
* In den folgenden geschweifen Klammern steht ebenfalls Perl-Code, der ausgeführt wird, falls die Bedingung zutrifft.<br />
* Der Perl-Code besteht nun wiederum aus der Anweisung, einen Fhem-Befehl auszuführen. Dieser wird zwischen die runden Klammern in Anführungsstriche gesetzt.<br />
<br />
== Komplexere if-Bedingung ==<br />
Achtung Klammersetzung! Hiermit wird das komplette Verhalten beeinflusst!<br />
* mit den zwei senkrechten Strichen wird ein "[http://de.selfhtml.org/perl/sprache/operatoren.htm#logisch oder]" formuliert (also nur Mittwoch ODER Donnerstag schalten):<br />
:<code>define a2 at *00:01:00 { if (($wday == 3) || ($wday == 4)) { fhem("set LICHT off") } }</code><br />
* mit den zwei "&" wird ein "und" formuliert (also nur mittwochs UND auch dann nur zwischen 18:00 und 5:00 Uhr schalten):<br />
:<code>define a2 at *00:01:00 { if (($wday == 3) && (($hour >= 18 || $hour < 5))) { fhem("set LICHT off") } }</code><br />
* Änderung der Logik durch andere Klammersetzung:<br />
:<code>define a2 at *00:01:00 { if ((($wday == 3) && ($hour >= 18)) || ($hour < 5)) { fhem("set LICHT off") } }</code><br />
:'''Achtung''': dieser Befehl schaltet '''mittwochs''' ab 18:00 und außerdem '''jeden Tag''' vor 5:00<br />
<br />
== if-else-Bedingung ==<br />
:<code>define einschalten at +*00:15 {if(Value("Variable") eq "on") { fhem(&quot;set Funkschalter on&quot;) } else { fhem(&quot;set funkschalter off&quot;)}}</code><br />
<br />
Wenn mehrere Bedingungen ausgeführt werden sollen:<br />
:<code>define einschalten at +*00:15 {if(Value("Variable") eq "on") { fhem(&quot;set Funkschalter on;; set FHT80B desired-temp 21&quot;) }}</code><br />
:Die beiden Bedingungen müssen nun mit zwei Semikola getrennt werden, da Perl vor der Übergabe an Fhem den Befehl übersetzt und dabei das eine Semikolon entfernt.<br />
<br />
== Links ==<br />
* [[Trick_der_Woche#Struktur_von_.22else_if.22_Verzweigungen|Struktur von "else if"-Verzweigungen]]<br />
<br />
[[Kategorie:HOWTOS]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HM-LC-SW2-FM_Schaltaktor_2-fach_UP&diff=10397HM-LC-SW2-FM Schaltaktor 2-fach UP2015-03-02T18:13:07Z<p>BerndArnold: Hinweis auf Schaltvermögen hinzugefügt (Quelle: gedrucktes Handbuch, 1. Ausgabe Deutsch 11/2011, S. 26); auskommentiertes HTML entfernt; Auszug aus fhem.cfg aktualisiert (Basis, Kanal 1 und 2); Typos</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-LC-Sw2-FM.jpg<br />
|Bildbeschreibung=HomeMatic Funk-Schaltaktor 2-fach (Unterputz)<br />
|HWProtocol=HomeMatic<br />
|HWType=Empfänger, Aktor<br />
|HWCategory=HomeMatic<br />
|HWComm=868 MHz<br />
|HWChannels=2<br />
|HWVoltage=230 V~<br />
|HWPowerConsumption=Eigenverbrauch ca. 0,5 W<br />
|HWPoweredBy=Netz<br />
|HWSize=53 x 53 x 30 mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]<br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
[[HM-LC-SW2-FM Schaltaktor 2-fach UP]] ist ein zweikanaliger Homematic Funk-Schaltaktor für die Unterputzmontage.<br />
<br />
== Features ==<br />
Unabhängiges Schalten von zwei Verbrauchern mittels Fhem ([[Interface]]: [[CUL]], [[CUN]], [[HMLAN Konfigurator]]) oder über angeschlossene(n) Taster.<br />
<br />
Das maximale Schaltvermögen liegt bei 5 A (Summe beider Kanäle, ohmsche Last). Für ein Schaltvermögen von bis zu 16 A ist der [[HM-LC-SW1-FM Schaltaktor 1-fach UP|einkanalige HM-LC-SW1]] eine Alternative.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Das Pairing muss wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.<br />
<br />
=== FHEM Config-Auszug ===<br />
Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt. Ein exemplarischer Auszug aus der fhem.cfg (Seriennummer anonymisiert):<br />
<pre><br />
define HM_Sw2_Garage CUL_HM 2D38E9<br />
attr HM_Sw2_Garage IODev MyHMLAN<br />
attr HM_Sw2_Garage autoReadReg 4_reqStatus<br />
attr HM_Sw2_Garage expert 2_full <br />
attr HM_Sw2_Garage firmware 1.12<br />
attr HM_Sw2_Garage model HM-LC-SW2-FM<br />
attr HM_Sw2_Garage room CUL_HM<br />
attr HM_Sw2_Garage serialNr LEQ0xxxxxx<br />
attr HM_Sw2_Garage subType switch <br />
attr HM_Sw2_Garage webCmd getConfig:clear msgEvents<br />
<br />
define HM_Sw2_GarageLicht1 CUL_HM 2D38E901<br />
attr HM_Sw2_GarageLicht1 model HM-LC-SW2-FM<br />
attr HM_Sw2_GarageLicht1 peerIDs 00000000,<br />
attr HM_Sw2_GarageLicht1 room CUL_HM<br />
attr HM_Sw2_GarageLicht1 webCmd statusRequest:toggle:on:off<br />
<br />
define HM_Sw2_GarageLicht2 CUL_HM 2D38E902<br />
attr HM_Sw2_GarageLicht2 model HM-LC-SW2-FM<br />
attr HM_Sw2_GarageLicht2 peerIDs 00000000, <br />
attr HM_Sw2_GarageLicht2 room CUL_HM<br />
attr HM_Sw2_GarageLicht2 webCmd statusRequest:toggle:on:off<br />
</pre><br />
<br />
=== Mögliche Schaltoperationen ===<br />
Der Aktor versteht folgende Aktionen:<br />
<pre><br />
set <name> on -> Schaltet den Aktor ein<br />
set <name> off -> Schaltet den Aktor aus<br />
set <name> toggle -> Ändert den Zustand des Aktors, d.h. ein eingeschalteter Aktor wird ausgeschaltet und ein ausgeschalteter Aktor wird eingeschaltet<br />
</pre><br />
<br />
=== Log-Auszug ===<br />
In FHEM ist nach dem Schalten des HM-LC-SW2-FM folgendes Log zu sehen:<br />
<pre><br />
2012.02.05 15:29:04 2: CUL_HM set LichtSchreibtisch on<br />
2012.02.05 15:29:09 2: CUL_HM set LichtSchreibtisch off<br />
2012.02.12 19:04:42 2: CUL_HM set LichtSchreibtisch toggle<br />
</pre><br />
<br />
== Einsatzbeispiel ==<br />
[[Bild:HM-LC-Sw1-FM_aufHutschiene.jpg|thumb|right|LC-Sw2-FM als Ersatz für (zwei) "Eltako" Stromstoßrelais]]<br />
Im gezeigten Bild werden zwei Eltako-Stromstoßrelais durch den Zweikanal-Schaltaktor ersetzt. Hierbei sind nur die vorhandenen Verbindungen auf den LC-Sw2-FM umzuklemmen. Sämtliche Taster funktionieren unverändert wie vorher, zusätzlich sind die angeschlossenen Leuchten damit über Funk (Fhem, HomeMatic-Fernbedienung etc.) direkt oder auch zeitgesteuert schaltbar.<br />
<br />
Zur Vereinfachung der Montage in einem Hutschienenverteiler ist das Schaltmodul mit Kabelbindern in einem Hutschienengehäuse (Breite: 73 mm) fixiert.<br />
<br />
Die gezeigte Verschaltung ist möglich, da die Tastereingänge S1 und S2 mit Netzspannung (und damit wie ein herkömmliches Stromstoßrelais) angesteuert werden können.<br />
<br />
== Links ==<br />
* Ein Integrationsbeispiel ist in [[Jalousie und Beleuchtung in mehreren Räumen]] zu finden.<br />
* Anleitung: [http://www.elv-downloads.de/service/manuals/76793_HM_Unterputzschalter_UM.pdf PDF]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Schalter (Empfänger)]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HM-Sec-SCo_T%C3%BCr-Fensterkontakt,_optisch&diff=9977HM-Sec-SCo Tür-Fensterkontakt, optisch2015-02-08T19:24:43Z<p>BerndArnold: Bild ergänzt; Betrieb mit Fhem hinzugefügt (Vorlage: HM-Sen-MDIR-O Funk-IR-Bewegungsmelder außen)</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-SEC-SCo.jpg<br />
|Bildbeschreibung=HomeMatic Tür-Fensterkontakt, optisch<br />
|HWProtocol=HomeMatic<br />
|HWType=Sensor<br />
|HWCategory=HomeMatic<br />
|HWComm=868MHz<br />
|HWChannels=1<br />
|HWVoltage=1,5 V DC<br />
|HWPowerConsumption=max. 100 mA<br />
|HWPoweredBy=Batterie (1x 1,5V LR03/Micro/AAA)<br />
|HWSize=15x100x18mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]<br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
== Features ==<br />
[[HomeMatic]] Funk-Tür-/Fensterkontakt zur optischen Erkennung von Tür- bzw. Fensteröffnungen oder -schließungen, z.B. zur Sicherheit oder um automatisch, bei vorhandenem [[HM-CC-RT-DN]], die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird.<br />
<br />
== Hinweis ==<br />
Das meiste zum [[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] Beschriebene zur Nutzung gilt auch für den HM-SEC-SCo.<br />
<br />
Wird mit aktiviertem [[AES Encryption|AES]] ausgeliefert und kann nur mit Gateways, die AES unterstützen, gepaired werden ([[HM-CFG-USB USB Konfigurations-Adapter|HM-LAN-CFG]] und [[HM-CFG-LAN LAN Konfigurations-Adapter|HM-USB-CFG]]).<br />
<br />
== Betrieb mit FHEM ==<br />
<br />
=== Event-Monitor ===<br />
<br />
Wird z. B. das Fenster geöffnet, wird Folgendes vom Gerät übermittelt:<br />
<pre><br />
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 11<br />
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig<br />
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG battery: ok<br />
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG open<br />
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG contact: open (to MyHMLAN)<br />
</pre><br />
<br />
Beim Schließen wird Folgendes übermittelt:<br />
<pre><br />
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 12<br />
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig<br />
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG battery: ok<br />
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG closed<br />
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG contact: closed (to MyHMLAN)<br />
</pre><br />
<br />
=== fhem.cfg ===<br />
<br />
Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt.<br />
<br />
<pre><br />
define HM_Fensterstatus_BadEG CUL_HM 35E390<br />
attr HM_Fensterstatus_BadEG IODev MyHMLAN<br />
attr HM_Fensterstatus_BadEG actCycle 000:50<br />
attr HM_Fensterstatus_BadEG actStatus dead<br />
attr HM_Fensterstatus_BadEG autoReadReg 4_reqStatus<br />
attr HM_Fensterstatus_BadEG expert 2_full<br />
attr HM_Fensterstatus_BadEG firmware 1.0<br />
attr HM_Fensterstatus_BadEG model HM-SEC-SCo<br />
attr HM_Fensterstatus_BadEG peerIDs 00000000,<br />
attr HM_Fensterstatus_BadEG room CUL_HM<br />
attr HM_Fensterstatus_BadEG serialNr LEQxxxxxxx<br />
attr HM_Fensterstatus_BadEG subType threeStateSensor<br />
</pre><br />
<br />
=== Aktionen durchführen, wenn Fenster zu lange geöffnet ist ===<br />
<br />
Mit der nachfolgenden DOIF-Definition wird ein Log-Eintrag erzeugt, eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und eine Nachricht per Prowl (funktioniert vermutlich nur unter Linux) verschickt.<br />
<br />
Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann. Das DOIF ist vorab zu definieren, zum Beispiel mit:<br />
:<code>def DOIF_FensterOffenMsg DOIF ([HM_Fensterstatus_BadEG])</code><br />
<br />
<pre><br />
([HM_Fensterstatus_BadEG] eq "open") ({<br />
Log 1, "Fenster seit mehr als 2 Stunden (7200 Sekunden) offen";;<br />
system( "/path/to/prowl.pl -apikeyfile=/path/to/prowl-apikey -event=Info -notification='Fenster ist noch offen' &" );;<br />
fhem( "set E2_Dreambox showText Fenster ist noch offen" ) if ReadingsVal("E2_Dreambox","state","") eq "on";;<br />
})<br />
DOELSE<br />
</pre><br />
<br />
Damit der Code-Block erst nach 7200 Sekunden getriggert wird, ist noch Folgendes auszuführen:<br />
<br />
:<code>attr DOIF_FensterOffenMsg wait 7200:0</code><br />
<br />
== Bekannte Probleme ==<br />
Teilweise (siehe Diskussion im {{Link2Forum|Topic=33264|LinkText=Forum}}) werden die Fensterkontakte regelmäßig wiederkehrend als "dead" angezeigt. Grund ist, dass beim Anlernen ein actCycle von 50 Minuten eingetragen wird, während die Kontakte auch gerne mal länger brauchen, um sich bei der Zentrale zu melden.<br />
<pre style="width:500px;"><br />
2015-01-31_17:57:39 Fstr_AusgTerrasse alive: yes<br />
2015-01-31_17:57:39 Fstr_AusgTerrasse battery: ok<br />
2015-01-31_17:57:39 Fstr_AusgTerrasse sabotageError: off<br />
2015-01-31_17:57:39 Fstr_AusgTerrasse closed<br />
2015-01-31_17:57:39 Fstr_AusgTerrasse contact: closed (to HMLAN1)<br />
2015-01-31_18:54:09 Fstr_AusgTerrasse Activity: dead<br />
2015-01-31_18:58:03 Fstr_AusgTerrasse alive: yes<br />
2015-01-31_18:58:03 Fstr_AusgTerrasse battery: ok<br />
2015-01-31_18:58:03 Fstr_AusgTerrasse sabotageError: off<br />
2015-01-31_18:58:03 Fstr_AusgTerrasse closed<br />
2015-01-31_18:58:03 Fstr_AusgTerrasse contact: closed (to HMUSB)<br />
2015-01-31_19:04:09 Fstr_AusgTerrasse Activity: alive<br />
</pre><br />
<br />
Um Abhilfe zu schaffen, den actCycle auf 01:05 setzen:<br />
:<code>attr <HM-SEC-SCo> actCycle 001:05</code><br />
<br />
Save config nicht vergessen.<br />
<br />
== Links ==<br />
* Anleitung [http://www.eq-3.de/Downloads/eq3/pdf_produkte/130873_HM-Sec-SCo_UM_GE_eQ-3_20141013_web.pdf PDF]<br />
* Datenblatt [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Tuer-Fensterkontakt-optisch_130297_Produktdatenblatt_V1.1.pdf PDF]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Kontaktsensor (optisch)]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Datei:HM-SEC-SCo.jpg&diff=9971Datei:HM-SEC-SCo.jpg2015-02-08T18:55:22Z<p>BerndArnold: </p>
<hr />
<div></div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Diskussion:HM-Sec-SCo_T%C3%BCr-Fensterkontakt,_optisch&diff=9967Diskussion:HM-Sec-SCo Tür-Fensterkontakt, optisch2015-02-08T15:54:36Z<p>BerndArnold: Neuer Abschnitt /* Inkompatibel mit HM-CC-RT-DN? */</p>
<hr />
<div>== Inkompatibel mit HM-CC-RT-DN? ==<br />
<br />
Im Handbuch (1. Ausgabe Deutsch 06/2014) ist auf Seite 7 unter anderem aufgeführt, dass der HM-SEC-SCo '''nicht''' mit dem HM-CC-RT kompatibel ist. Gibt es da Unterschiede zu dem mit dem Suffix ''-DN''? Falls nicht, dann wäre er mit dem [[HM-CC-RT-DN Funk-Heizkörperthermostat]] inkompatibel. Evtl. weiß da jemand mehr?<br />
<br />
[[Benutzer:BerndArnold|BerndArnold]] ([[Benutzer Diskussion:BerndArnold|Diskussion]]) 15:54, 8. Feb. 2015 (UTC)</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HM-Sen-MDIR-O_Funk-IR-Bewegungsmelder_au%C3%9Fen&diff=9432HM-Sen-MDIR-O Funk-IR-Bewegungsmelder außen2015-01-18T20:06:52Z<p>BerndArnold: Notify-Beispiel mit Perl-Mehrzeiler (evtl. kann der Hinweis mit dem DEF-Feld noch mit einem Wiki-Link ergänzt werden - ich habe gerade keinen gefunden)</p>
<hr />
<div>'''HM-Sen-MDIR-O'''<br />
HomeMatic Funk-IR-Bewegungsmelder außen<br />
<br />
== Features ==<br />
PIR-Bewegungsmelder mit Helligkeitssensor zur Tag-/Nachtumschaltung.<br />
<br />
'''Technische Daten:'''<br />
* Erfassungswinkel: ca. 90°<br />
* Erfassungsbereich: ca. 9 m<br />
* Drehbar: 360°<br />
* Neigbar: 45°<br />
* Stromversorgung: 3 x 1,5 V Mignon/AA/LR6<br />
* Schutzart: IP 44<br />
<br />
== Hinweise zur Inbetriebnahme und Installation ==<br />
&lt;Bitte ergänzen&gt;<br />
<br />
== Probleme ==<br />
Die Geräte der HM-Sen Serie senden keine zyklischen Status-Informationen. Der Action Detektor erklärt sie daher für tot bzw. ist nicht brauchbar. Zum messen der Außen-Helligkeit sind die Sensoren dadurch unbrauchbar. Darüber hinaus verfügen diese Geräte auch über keinen Sabotage-Kontakt.<br />
<br />
== Betrieb mit FHEM ==<br />
<br />
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Die Anlerntaste am Bewegungsmelder sollte hierzu nur kurz betätigt werden. Bei einer Betätigung von vier Sekunden wird der Melder nur bei Unterschreiten einer festgelegten Helligkeitsschwelle auslösen (weitere Informationen siehe Abschnitt ''Anlernen'' der Herstellerdokumentation).<br />
<br />
=== Event-Monitor ===<br />
<br />
In regelmäßigen Abständen werden die folgenden Daten vom Bewegungsmelder (hier: HM-Sen-MDIR-O-2) übermittelt:<br />
<pre><br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120<br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer cover: closed<br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer battery: ok<br />
</pre><br />
<br />
Wird Bewegung erkannt, wird Folgendes vom Gerät (hier: HM-Sen-MDIR-O-2) übermittelt:<br />
<pre><br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer trigDst_2573FB: noConfig<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion: on (to MyHMLAN)<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motionCount: 235_next:116s<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120<br />
</pre><br />
<br />
=== Log-Auszug ===<br />
<br />
&lt;Bitte ergänzen&gt;<br />
<br />
=== fhem.cfg ===<br />
<br />
Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt (Beispiel: HM-Sen-MDIR-O-2).<br />
<br />
<pre><br />
define HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer CUL_HM 2B033A<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer IODev MyHMLAN<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actCycle 000:10<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actStatus alive<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer autoReadReg 4_reqStatus<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer expert 2_full<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer firmware 1.6<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer model HM-Sen-MDIR-O-2<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer peerIDs 00000000,<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer room CUL_HM<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer serialNr LEQ0xxxxxx<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer subType motionDetector<br />
</pre><br />
<br />
=== Konfiguration über Register ===<br />
==== Anzeige aller dekodierten Register ====<br />
<nowiki>get &lt;name&gt; regList</nowiki><br />
zeigt alle moeglichen 'dekodierten' Register an. Fuer mdir sind dies alle, sollte also komplett sein. Hier findet man sowohl den Wertebereich alsauch eine (sehr) kleine Beschreibung.<br />
Ausgabe:<br />
<br />
<nowiki><br />
list: register | range | peer | description<br />
0: pairCentral | 0 to 16777215 | | pairing to central<br />
1: brightFilter | 0 to 7 | | brightness filter - ignore light at night<br />
1: captInInterval | literal | | capture within interval options:on,off<br />
1: evtFltrNum | 1 to 15 | | sensitivity - read each n-th puls<br />
1: evtFltrPeriod | 0.5 to 7.5s | | event filter period<br />
1: ledOnTime | 0 to 1.275s | | LED ontime<br />
1: minInterval | literal | | minimum interval in sec options:240,60,120,30,15<br />
4: peerNeedsBurst | literal | required | peer expects burst options:on,off<br />
</nowiki><br />
<br />
;minInterval<br />
: Minimaler Interval in Sekunden ab wann die nächste Bewegung registriert werden kann. Der Standard ist 240. Also nach einer Bewegungs-Meldung werden weitere Bewegungen für 4 Minuten ignoriert bis die nächste Meldung erfolgt.<br />
;brightFilter<br />
: Filtert Bewegungen nach Helligkeit aus. 0 Filtert nichts aus, d.h. es wird auch bei Helligkeit gemeldet. 7 Filtert bis 10 Lux? alles aus, daher werden Bewegungen nur bei Dunkelheit gemeldet.<br />
;evtFltrNum<br />
: Filtert Bewegungen aus. Steht dieser Wert z.B. auf 5 so wird erst bei der fünften Bewegung die Meldung gesendet.<br />
;evtFltrPeriod<br />
: Gibt an wie viel Zeit zwischen zwei Bewegungen vergehen muss um für den evtFltrNum Filter gezählt zu werden. Steht dieser Wert auf 1 und evtFltrNum auf 5 so muss der Sensor 5 Sekunden Bewegungen registrieren um eine Meldung zu senden.<br />
<br />
=== Gerät bei Bewegung schalten ===<br />
<br />
Mit dem folgenden Notify kann z. B ein [[HM-LC-SW1-FM Schaltaktor 1-fach UP|Unterputz-Schaltaktor]] für die angegebene Zeit (in Sekunden) eingeschaltet werden - ein Peeren ist dazu vorher nicht erforderlich. Das Einschalten passiert in diesem Beispiel unabhängig von der Helligkeit.<br />
<br />
<pre><br />
define Notify_Bewegungsmelder_Haustuer notify HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer:motion set HM_LC_SW1_FM_298FB2_HaustuerLicht on-for-timer 300<br />
</pre><br />
<br />
=== Gerät bei Bewegung in Abhängigkeit der Helligkeit schalten ===<br />
<br />
Mit der nachfolgenden Notify-Definition werden zwei Log-Einträge erzeugt, eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und ein [[HM-LC-SW1-FM Schaltaktor 1-fach UP|Unterputz-Schaltaktor]] für die angegebene Zeit (in Sekunden) eingeschaltet, falls die gemessene Helligkeit am Bewegungsmelder kleiner oder gleich 90 ist.<br />
<br />
Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das DEF-Feld übernommen werden kann.<br />
<br />
<pre><br />
HM_BewegMelder_Carport:motion { <br />
Log 1, "Trigger-Notify von BewegMelderCarport: @";<br />
Log 1, ReadingsVal( "HM_BewegMelder_Carport", "brightness", "");<br />
fhem( "set E2_Dreambox showText Bewegung am Carport" ) if ReadingsVal("E2_Dreambox","state","") eq "on"; <br />
if ( ReadingsVal( "HM_BewegMelder_Carport", "brightness", "") <= 90 ) {<br />
fhem( "set HM_Sw1_GarageLED on-for-timer 300" );<br />
}<br />
}<br />
</pre><br />
<br />
== Links ==<br />
Manual: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/104108_HM-Sen-MDIR-O_V1.2_GE_eQ-3_20120510.pdf PDF HM-Sen-MDIR-O],<br />
[http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-Sen-MDIR-O-2_UM_GE_131024.pdf PDF HM-Sen-MDIR-O-2]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Lichtsensoren]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Diskussion:HM-Sen-MDIR-O_Funk-IR-Bewegungsmelder_au%C3%9Fen&diff=9431Diskussion:HM-Sen-MDIR-O Funk-IR-Bewegungsmelder außen2015-01-18T19:49:31Z<p>BerndArnold: Neuer Abschnitt /* Regelmäßige Datenübermittlung vs. keiner */</p>
<hr />
<div>== Regelmäßige Datenübermittlung vs. keiner ==<br />
<br />
Hallo [[Corneliusweiss]],<br /><br />
ich beziehe mich auf die Änderung vom [http://www.fhemwiki.de/w/index.php?title=HM-Sen-MDIR-O_Funk-IR-Bewegungsmelder_au%C3%9Fen&diff=8609&oldid=8528 28.11.2014].<br />
<br />
Meine HM-Sen-Bewegungsmelder senden in regelmäßigen Abständen (in den letzten zwei Stunden ca. alle 6 Minuten) Werte bezüglich Helligkeit, Batterie- und Cover-Status, ohne dass ich besondere Einstellungen getroffen habe.<br />
<br />
Sie werden im ActionDetector als ''alive'' gekennzeichnet und ich messe tatsächlich damit die Außenhelligkeit.<br />
<br />
Ist das bei deinen Bewegungsmeldern anders oder weshalb hast du den Abschnitt, dass die Geräte keine regelmäßigen Daten senden, hinzugefügt?<br />
<br />
Viele Grüße<br /><br />
[[Benutzer:BerndArnold|BerndArnold]] ([[Benutzer Diskussion:BerndArnold|Diskussion]]) 19:49, 18. Jan. 2015 (UTC)</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HM-WDS40-TH-I_Funk-Temperatur-/Feuchtesensor_innen_(IT)&diff=9430HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen (IT)2015-01-18T19:35:42Z<p>BerndArnold: Infobox hinzugefügt (Quelle: eq-3.de); Bild ergänzt; Rechtschreibung korrigiert; fhem.cfg, Eventmonitor hinzugefügt; Readings-Namen korrigiert</p>
<hr />
<div>{{Infobox Hardware|Bild=HM-WDS40-TH-I-2 Vorderseite.jpg<br />
|Bildbeschreibung=HM-WDS40-TH-I-2 (Vorderseite)<br />
|HWProtocol=HomeMatic<br />
|HWType=Sensor<br />
|HWCategory=HomeMatic<br />
|HWComm=868,3 MHz<br />
|HWChannels=1<br />
|HWPowerConsumption=unbekannt<br />
|HWVoltage=3 V<br />
|HWPoweredBy=Batterie, 2x LR06 (Mignon)<br />
|HWSize=100 x 70 x 24 mm<br />
|HWDeviceFHEM=[[CUL_HM]]<br />
|HWManufacturer=eQ-3 <br />
}}<br />
<br />
[[HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen (IT)]] ist ein Homematic-Funksensor für Temperatur und Luftfeuchte, der für den Einsatz im Innenbereich geeignet ist.<br />
<br />
== Features ==<br />
* Wandaufhängung möglich<br />
* Für Temperaturen von -20 °C bis +80 °C<br />
* Für relative Luftfeuchte von 1 bis 99 %<br />
* Datenübermittlung alle 120 bis 180 Sekunden<br />
* Übermittlung des Batteriestatus<br />
* Aktuelle Firmware: 1.3<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Das Pairing sollte wie unter [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Hierfür muss die Anlerntaste auf der Vorderseite mit einem spitzen Gegenstand gedrückt werden.<br />
<br />
=== Protokoll-Modi ===<br />
[[HomeMatic#Config|config]]<br />
[[HomeMatic#Wakeup|Wakeup]]<br />
[[HomeMatic#ConditionalBurst|ConditionalBurst]]<br />
<br />
=== Kommandos ===<br />
Der Sensor kann mit Aktoren gepeert werden. Sinnvoll ist Peering jedoch nur mit einem Aktor, der Temperaturwerte verarbeiten kann, z. B. dem Weatherchannel eines RT. <br />
<br />
=== ActionDetector ===<br />
Das Device wacht regelmäßig auf und wird somit im ActionDetector automatisch eingetragen. Der Timeout ist 10 Minuten.<br />
<br />
=== Event-Monitor ===<br />
In regelmäßigen Abständen werden die folgenden Daten vom Sensor (hier: HM-WDS40-TH-I-2) übermittelt:<br />
<pre><br />
2015-01-18 20:22:17 CUL_HM HM_TemperaturFeuchteBadOG temperature: 15.3<br />
2015-01-18 20:22:17 CUL_HM HM_TemperaturFeuchteBadOG battery: ok<br />
2015-01-18 20:22:17 CUL_HM HM_TemperaturFeuchteBadOG humidity: 42<br />
2015-01-18 20:22:17 CUL_HM HM_TemperaturFeuchteBadOG T: 15.3 H: 42<br />
</pre><br />
<br />
=== fhem.cfg ===<br />
Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt (Beispiel: HM-WDS40-TH-I-2).<br />
<br />
<pre><br />
define HM_TemperaturFeuchteBadOG CUL_HM 239738<br />
attr HM_TemperaturFeuchteBadOG IODev MyHMLAN<br />
attr HM_TemperaturFeuchteBadOG actCycle 000:10<br />
attr HM_TemperaturFeuchteBadOG actStatus alive<br />
attr HM_TemperaturFeuchteBadOG autoReadReg 4_reqStatus<br />
attr HM_TemperaturFeuchteBadOG expert 2_full<br />
attr HM_TemperaturFeuchteBadOG firmware 1.3<br />
attr HM_TemperaturFeuchteBadOG model HM-WDS40-TH-I-2<br />
attr HM_TemperaturFeuchteBadOG peerIDs 00000000,<br />
attr HM_TemperaturFeuchteBadOG room CUL_HM<br />
attr HM_TemperaturFeuchteBadOG serialNr KEQxxxxxxx<br />
attr HM_TemperaturFeuchteBadOG subType THSensor<br />
</pre><br />
<br />
== Variablen ==<br />
Gültig sind [[HomeMatic#Variablen|HM Variablen]]. Darüber hinaus gilt wie folgt<br />
<br />
=== Internals ===<br />
Keine Spezifischen<br />
<br />
=== Readings ===<br />
* temperature:<temp><br />
* humidity:<humidity><br />
* battery:[low|ok]<br />
* state: T: <temp> H: <humidity><br />
<br />
=== Attribute ===<br />
Keine Spezifischen<br />
<br />
=== Register ===<br />
Keine Spezifischen<br />
<br />
== Nützliche Notifies ==<br />
Aktuell keine.<br />
<br />
== Bekannte Probleme ==<br />
Keine bekannt.<br />
<br />
== Links ==<br />
* [http://www.elv-downloads.de/service/manuals/76998_HM_GE_WDS40_TH_I_GE_V1_1.pdf Bedienungsanleitung] (PDF)<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Feuchtesensoren]]<br />
[[Kategorie:Temperatursensoren]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Datei:HM-WDS40-TH-I-2_Vorderseite.jpg&diff=9428Datei:HM-WDS40-TH-I-2 Vorderseite.jpg2015-01-18T19:33:02Z<p>BerndArnold: </p>
<hr />
<div></div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=EM1000WZ_Funk-Sensor_f%C3%BCr_Drehstromz%C3%A4hler&diff=9016EM1000WZ Funk-Sensor für Drehstromzähler2014-12-27T17:16:35Z<p>BerndArnold: Infobox hinzugefügt (Quelle: eq-3.de); Bild ergänzt; Weblink zum Handbuch auf eq-3 hinzugefügt (auf elv.de nichts gefunden); einheitliche Schreibweise (EM 1000-WZ etc.)</p>
<hr />
<div>{{Infobox Hardware|Bild=EM 1000-S und EM 1000-IR Fhem.png<br />
|Bildbeschreibung=EM 1000-S und EM 1000-IR<br />
|HWProtocol=unbekannt<br />
|HWType=Sensor<br />
|HWCategory=EM<br />
|HWComm=868,35 MHz<br />
|HWChannels=4<br />
|HWPowerConsumption=max. 40 mA<br />
|HWVoltage=7 V - 15 V DC<br />
|HWPoweredBy=Netzteil<br />
|HWSize=55 x 160 x 25 mm <small>(EM 1000-S)</small><br />30 x 44 x 15 mm <small>(EM 1000-IR)</small><br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_EM 15_CUL_EM.pm]<br />
|HWManufacturer=ELV<br />
}}<br />
<br />
Der '''EM 1000-WZ Funk-Sensor für Drehstromzähler''' ist ein Funk-Sensor, der die Umdrehungen der Zählerscheibe (Ferraris-Scheibe) eines Stromzählers erfasst.<br />
<br />
== Features ==<br />
Der '''EM 1000-WZ''' besteht aus einer Infrarot-Sensoreinheit (EM 1000-IR) und einer "abgesetzten" Sendeeinheit (EM 1000-S). Die Sensoreinheit wird vor die Sichtscheibe des Zählers geklebt und ist dadurch wieder ablösbar. Der Sensor sendet über den mit einem Kabel verbundenen Sender die Zählimpulse.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Zum Empfang der Daten muss ein CUL im [[SlowRF]]-Modus verwendet werden.<br />
<br />
Definition in fhem.cfg:<br />
:<code>define &lt;name&gt; CUL_EM &lt;code&gt; [corr1 corr2 CostPerUnit BasicFeePerMonth]</code><br />
<br />
* '''&lt;code&gt;''' ist die Einstellung, die innerhalb des Sensors gewählt werden muss. Das EM-1000-System sieht insgesamt 12 Adressen vor, von denen die Adressen von 1 bis einschließlich 4 für EM-1000-WZ-Geräte vorgesehen sind. Aus diesem Bereich muss die zu verwendende Adresse per DIP-Schalter im Sendegerät ausgewählt werden (siehe Handbuch)<br />
* corr1 = die Umdrehungsgeschwindigkeit (U/kWh) des verwendeten Stromzählers (z. B. 150)<br />
* corr2 = 12 mal des <code>corr1</code>-Wertes (z. B. corr1=150, dann corr2=1800)<br />
<br />
== Log-Auszüge ==<br />
Regelmäßige Datenübermittlung<br />
<nowiki>2014.12.06 07:10:38 4: CUL_EM em1000wz: CNT: 252 CUM: 7168.987 5MIN: 0.480 TOP: 0.406<br />
2014.12.06 07:15:39 4: CUL_EM em1000wz: CNT: 253 CUM: 7169.027 5MIN: 0.480 TOP: 0.471<br />
2014.12.06 07:20:40 4: CUL_EM em1000wz: CNT: 254 CUM: 7169.053 5MIN: 0.320 TOP: 0.405<br />
2014.12.06 07:25:41 4: CUL_EM em1000wz: CNT: 255 CUM: 7169.093 5MIN: 0.480 TOP: 0.584<br />
2014.12.06 07:30:41 4: CUL_EM em1000wz: CNT: 2 CUM: 7169.120 5MIN: 0.320 TOP: 0.366<br />
2014.12.06 07:35:42 4: CUL_EM em1000wz: CNT: 3 CUM: 7169.147 5MIN: 0.320 TOP: 0.394<br />
2014.12.06 07:40:43 4: CUL_EM em1000wz: CNT: 4 CUM: 7169.173 5MIN: 0.320 TOP: 0.453<br />
2014.12.06 07:45:44 4: CUL_EM em1000wz: CNT: 5 CUM: 7169.200 5MIN: 0.320 TOP: 0.244</nowiki><br />
<br />
Tägliche Statistik<br />
<nowiki>2014.12.06 00:04:37 3: CUL_EM em1000wz: CUM_DAY: 7.933 CUM: 7167.493 COST: 1.82</nowiki><br />
<br />
Monatliche Statistik<br />
<nowiki>2014.12.01 00:02:06 4: CUL_EM em1000wz: CNT: 254 CUM: 7124.867 5MIN: 0.160 TOP: 0.160<br />
2014.12.01 00:02:06 3: CUL_EM em1000wz: CUM_DAY: 13.160 CUM: 7124.867 COST: 3.03<br />
2014.12.01 00:02:06 3: CUL_EM em1000wz: CUM_MONTH: 306.627 CUM: 7124.867 COST: 78.69</nowiki><br />
<br />
== Bekannte Probleme ==<br />
Keine<br />
<br />
== Links ==<br />
* [http://fhem.de/commandref.html#EMWZ Beschreibung in der commandref]<br />
* [http://groups.google.com/group/fhem-users/browse_thread/thread/4657018e850618e9/351c9ff5d6d79372 Diskussion] in der FHEM Google Group<br />
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/EM1000SIR_UM_G_060510.pdf Handbuch]<br />
<br />
[[Kategorie:EMS Components]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Datei:EM_1000-S_und_EM_1000-IR_Fhem.png&diff=9015Datei:EM 1000-S und EM 1000-IR Fhem.png2014-12-27T16:56:23Z<p>BerndArnold: </p>
<hr />
<div></div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=FS20_S4A_Aufputz_Sender&diff=8980FS20 S4A Aufputz Sender2014-12-26T18:39:28Z<p>BerndArnold: Bildbeschreibung korrigiert</p>
<hr />
<div>{{Infobox Hardware|Bild=FS20-S4A_Vorderseite.jpg<br />
|Bildbeschreibung=FS20S4A Aufputzsender<br />
|HWProtocol=FS20<br />
|HWType=Sender<br />
|HWCategory=FS20<br />
|HWComm=868,35 MHz<br />
|HWChannels=2 bzw. 4<br />
|HWVoltage=3 V<br />
|HWPowerConsumption=unbekannt<br />
|HWPoweredBy=2x LR44<br />
|HWSize=78 x 15 x 78 mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#FS20 10_FS20.pm]<br />
|HWManufacturer=ELV<br />
}}<br />
<br />
Der '''FS20S4A Aufputz-Wandsender''' ist ein 4 Tasten-Wandsender 2/4 Kanal<br />
<br />
== Features ==<br />
Sender zum Aufkleben an beliebiger Stelle, maximale Dicke 15 Millimeter. Betrieb mit Knopfzellen (2x LR44, Lebensdauer je nach Benutzung ca. 2 Jahre), 4 Tasten, mittige Kontroll-LED. Konfiguration entweder als 2-Kanal-Sender oder als 4-Kanal-Sender. Jede Taste sendet unterschiedliche Befehle, je nachdem, ob sie kurz oder lang gedrückt wird.<br />
<br />
Bei Einrichtung als 2-Kanal-Sender mit zwei Tastenpaaren mit jeweils ON/dimUp (rechte Taste) und OFF/dimDown (linke Taste).<br />
<br />
Bei Einrichtung als 4-Kanal-Sender mit vier einzelnen Tasten, die jeweils toggle/dimupdown senden.<br />
<br />
Details zur Konfiguration stehen im Handbuch zum Gerät.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Einsetzbar<br />
<br />
== Bekannte Probleme ==<br />
Es kommt bei zu kurzem Tastendruck vor, dass die Leuchtdiode zwar den Tastendruck quittiert, aber kein Funksignal abgesetzt wird.<br />
<br />
Beim Programmieren per FS20 IRP reicht es nicht, eine Taste ausser Funktion zu setzen durch Auswählen von "funktionsloser Befehl". Dadurch sendet die Taste bei Tastendruck einen "Sendstate" auf dem eingestellten Gerätecode. Man sollte also eine deaktivierte Taste auf einen nicht benutzten Gerätecode verwenden um Störungen zu vermeiden.<br />
<br />
== Vorlage für Beschriftung ==<br />
[http://www.ulimaass.de/fhem/S4A-Tastenaufkleber.ppt Tastenaufkleber.ppt]<br />
<br />
== Links ==<br />
Anleitung [http://files.elv.de/service/manuals/FS20S4A/73623_um.pdf PDF]<br />
<br /><br />
Details siehe [http://fhem.de/commandref.html#FS20 http://fhem.de/commandref.html#FS20]<br />
<br />
[[Kategorie:FS20 Components]]<br />
[[Kategorie:Schalter (Sender)]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=EM-1000_EM_Wirkleistungsmessger%C3%A4t&diff=8979EM-1000 EM Wirkleistungsmessgerät2014-12-26T18:37:40Z<p>BerndArnold: Infobox hinzugefügt (Quelle: elv.de); Bild ergänzt; Infos über WZ nach EM1000WZ-Seite verschoben</p>
<hr />
<div>{{Infobox Hardware|Bild=EM_1000-EM_Vorderseite.jpg<br />
|Bildbeschreibung=EM 1000-EM Wirkleistungsmessgerät<br />
|HWProtocol=unbekannt<br />
|HWType=Sensor<br />
|HWCategory=EM<br />
|HWComm=868,35 MHz<br />
|HWPowerConsumption=unbekannt<br />
|HWVoltage=230 V<br />
|HWPoweredBy=Netz<br />
|HWSize=56 x 134 x 77 mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_EM 15_CUL_EM.pm]<br />
|HWManufacturer=ELV<br />
}}<br />
<br />
Der '''EM-1000 EM Wirkleistungsmessgerät''' ist ein als Zwischensteckdose ausgeführter Sensor. Er misst und sendet die effektive Leistungsaufnahme des angeschlossenen Verbrauchers.<br />
<br />
== Lieferumfang ==<br />
* EM1000-EM<br />
* Bedienungsanleitung<br />
<br />
== Funktionen ==<br />
* Der Sender kann über [[CUL]] empfangen werden. <br />
* Siehe [[FHEM Command Reference]] unter CUL_EM<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Zum Empfang der Daten muss ein CUL im [[SlowRF]]-Modus verwendet werden.<br />
<br />
Definition in fhem.cfg:<br />
:<code>define &lt;name&gt; CUL_EM &lt;code&gt; [corr1 corr2 CostPerUnit BasicFeePerMonth]</code><br />
<br />
* '''&lt;code&gt;''' ist die Einstellung, die innerhalb des Sensors gewählt werden muss. Das EM1000-System sieht insgesamt 12 Adressen vor, von denen die Adressen 5..8 für EM1000EM vorgesehen sind. Aus diesem Bereich muss die zu verwendende Adresse per Tastendruck am Gerät ausgewählt werden (siehe Handbuch)<br />
* '''[corr1,corr2]''' corr1 ist der Kalibrierfaktor für den Momentanverbrauch, corr2 für den Gesamtverbrauch, bitte die [http://fhem.de/commandref.html#CUL_EM Hinweise in der commandref] beachten<br />
<br />
=== Log-Auszüge ===<br />
Erkennung des EM-1000-Sensors durch FHEM<br />
<nowiki>2012.11.24 14:13:29 1: CUL_EM detected, Code 7 CNT: 222 CUM: 38721 5MIN: 0 TOP: 0<br />
2012.11.24 14:13:29 2: autocreate: define CUL_EM_7 CUL_EM 7<br />
2012.11.24 14:13:29 2: autocreate: define FileLog_CUL_EM_7 FileLog ./log/CUL_EM_7-%Y-%m.log CUL_EM_7:CNT.*<br />
2012.11.24 14:13:29 2: autocreate: define weblink_CUL_EM_7 weblink fileplot FileLog_CUL_EM_7:power8:CURRENT</nowiki><br />
<br />
Empfangene Daten des EM-1000-Sensors<br />
<nowiki>2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank CNT: 151 CUM: 41.394 5MIN: 0.050 TOP: 0.130<br />
2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank tsecs: 1354046303<br />
2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank seqno: 151<br />
2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank peak: 0.13<br />
2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank total: 41.394<br />
2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank current_cnt: 5<br />
2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank current: 0.05<br />
2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank total_cnt: 41394<br />
2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank peak_cnt: 13<br />
2012-11-27 20:58:23 CUL_EM UG.EM7.Gefrierschrank RAW: CNT: 151 CUM: 41394 5MIN: 5 TOP: 13</nowiki><br />
<br />
=== Basiswert zurücksetzen ===<br />
Um den kumulierten Zählerstand einmalig auf den abgelesenen Zählerstand zu bringen, sind folgende Schritte erforderlich:<br />
<br />
* fhem stoppen (shutdown)<br />
* folgende Zeile in fhem.save erzeugen:<br /><code>setstate EMEZ_NAME 2012-mm-dd hh:MM:SS basis basisWert</code> <br />mit &lt;basisWert&gt; = &lt;abgelesenerMeterWert&gt; / &lt;corr2&gt; - &lt;total_cnt_Reading&gt; <br />(01.06.2013/Anmerkung PeMue: ist vermutlich nicht ganz korrekt, da im fhem Forum folgendes diskutiert wird: <br /><code>&lt;basisWert> = &lt;zaehlerwert&gt; * &lt;corr1&gt; - &lt;total_cnt&gt;</code><br />
* dann fhem starten.<br />
<br />
Alternativ im Fhem-Befehlsfeld mit dem Befehl:<br />
:<code>{ setReadingsVal($defs{EMEZ_NAME},"basis",basisWert,TimeNow()) }</code><br />
<br />
== Bekannte Probleme ==<br />
Das Senden der Verbrauchsdaten findet alle fünf Minuten mit einer Auflösung von 1Wh statt, somit erhält Fhem nur dann einen neuen Energieverbrauchswert, wenn insgesamt 1Wh verbraucht wurde. Bei geringer Leistungsaufnahme des Verbrauchers kann dies recht lange dauern.<br />
<br />
== Links ==<br />
* Bedienungsanleitung bei ELV [http://www.elv-downloads.de/service/manuals/EM1000EM/62117_um.pdf PDF]<br />
<br />
[[Kategorie:EMS Components]]<br />
[[Kategorie:Energieverbrauchsmessung]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=EM1000WZ_Funk-Sensor_f%C3%BCr_Drehstromz%C3%A4hler&diff=8978EM1000WZ Funk-Sensor für Drehstromzähler2014-12-26T18:35:08Z<p>BerndArnold: Rechtschreibung korrigiert; Log-Auszug hinzugefügt; Definition von EM 1000-EM übernommen und angepasst; Einleitung nach Vorgabe angepasst (kein =)</p>
<hr />
<div>Der '''EM1000WZ Funk-Sensor für Drehstromzähler''' ist ein Funk-Sensor, der die Umdrehungen der Zählerscheibe (Ferraris-Scheibe) eines Stromzählers erfasst.<br />
<br />
== Features ==<br />
Eine Infrarot-Sensoreinheit, die vor die Sichtscheibe des Zählers geklebt wird (wieder ablösbar), sendet über einen "abgesetzten" (mit einem Kabel verbundenen) Sender Zählimpulse.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Zum Empfang der Daten muss ein CUL im [[SlowRF]]-Modus verwendet werden.<br />
<br />
Definition in fhem.cfg:<br />
:<code>define &lt;name&gt; CUL_EM &lt;code&gt; [corr1 corr2 CostPerUnit BasicFeePerMonth]</code><br />
<br />
* '''&lt;code&gt;''' ist die Einstellung, die innerhalb des Sensors gewählt werden muss. Das EM1000-System sieht insgesamt 12 Adressen vor, von denen die Adressen von 1 bis einschließlich 4 für EM1000WZ-Geräte vorgesehen sind. Aus diesem Bereich muss die zu verwendende Adresse per Tastendruck am Gerät ausgewählt werden (siehe Handbuch)<br />
* corr1 = die Umdrehungsgeschwindigkeit (U/kWh) des verwendeten Stromzählers (z. B. 150)<br />
* corr2 = 12 mal des <code>corr1</code>-Wertes (z. B. corr1=150, dann corr2=1800)<br />
<br />
== Log-Auszüge ==<br />
Regelmäßige Datenübermittlung<br />
<nowiki>2014.12.06 07:10:38 4: CUL_EM em1000wz: CNT: 252 CUM: 7168.987 5MIN: 0.480 TOP: 0.406<br />
2014.12.06 07:15:39 4: CUL_EM em1000wz: CNT: 253 CUM: 7169.027 5MIN: 0.480 TOP: 0.471<br />
2014.12.06 07:20:40 4: CUL_EM em1000wz: CNT: 254 CUM: 7169.053 5MIN: 0.320 TOP: 0.405<br />
2014.12.06 07:25:41 4: CUL_EM em1000wz: CNT: 255 CUM: 7169.093 5MIN: 0.480 TOP: 0.584<br />
2014.12.06 07:30:41 4: CUL_EM em1000wz: CNT: 2 CUM: 7169.120 5MIN: 0.320 TOP: 0.366<br />
2014.12.06 07:35:42 4: CUL_EM em1000wz: CNT: 3 CUM: 7169.147 5MIN: 0.320 TOP: 0.394<br />
2014.12.06 07:40:43 4: CUL_EM em1000wz: CNT: 4 CUM: 7169.173 5MIN: 0.320 TOP: 0.453<br />
2014.12.06 07:45:44 4: CUL_EM em1000wz: CNT: 5 CUM: 7169.200 5MIN: 0.320 TOP: 0.244</nowiki><br />
<br />
Tägliche Statistik<br />
<nowiki>2014.12.06 00:04:37 3: CUL_EM em1000wz: CUM_DAY: 7.933 CUM: 7167.493 COST: 1.82</nowiki><br />
<br />
Monatliche Statistik<br />
<nowiki>2014.12.01 00:02:06 4: CUL_EM em1000wz: CNT: 254 CUM: 7124.867 5MIN: 0.160 TOP: 0.160<br />
2014.12.01 00:02:06 3: CUL_EM em1000wz: CUM_DAY: 13.160 CUM: 7124.867 COST: 3.03<br />
2014.12.01 00:02:06 3: CUL_EM em1000wz: CUM_MONTH: 306.627 CUM: 7124.867 COST: 78.69</nowiki><br />
<br />
== Bekannte Probleme ==<br />
Keine<br />
<br />
== Links ==<br />
* [http://fhem.de/commandref.html#EMWZ Beschreibung in der commandref]<br />
* [http://groups.google.com/group/fhem-users/browse_thread/thread/4657018e850618e9/351c9ff5d6d79372 Diskussion] in der FHEM Google Group<br />
<br />
[[Kategorie:EMS Components]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Datei:EM_1000-EM_Vorderseite.jpg&diff=8976Datei:EM 1000-EM Vorderseite.jpg2014-12-26T17:47:26Z<p>BerndArnold: </p>
<hr />
<div></div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Notify&diff=8938Notify2014-12-22T16:08:36Z<p>BerndArnold: Wiki-Link nach Umbenennung korrigiert /* Weiterführende Links */</p>
<hr />
<div>{{SEITENTITEL:notify}}<br />
{{Infobox Modul<br />
|ModPurpose=Ausführung von Anweisung als Reaktion auf Events<br />
|ModType=h<br />
|ModCmdRef=notify<br />
|ModForumArea=Automatisierung<br />
|ModTechName=91_notify.pm<br />
|ModOwner=rudolfkoenig ([http://forum.fhem.de/index.php?action=profile;u=8 Forum] / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])<br />
}}<br />
__TOC__<br />
{{Todo|generelle Überarbeitung, Fehlerkontrolle, Formatierung}}<br />
{{Randnotiz|RNTyp=[g|Info|RNText=Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit Fhem]<br />
"Um Ihren Perlcode zu testen, verwenden Sie das [http://fhem.de/commandref#trigger trigger-Kommando]. [...] Wenn Sie also z.B. ein <code>define Testcode notify Schalter1:on {Perlcode}</code> testen möchten, können Sie Ihren Code mit <code>trigger Schalter1 on</code> testen. trigger simuliert das Eintreten eines Ereignisses [...]" (Tipp von S. 38 der Version 4.0)}} <br />
== Notify, das mächtige Tool ==<br />
Die nachfolgenden Beispiele beziehen sich hauptsächlich auf [[EIB / KNX|KNX (EIB)]]. Sie sind aber auf alle anderen System übertragbar.<br />
<br />
Bitte nicht die [[Konfiguration|fhem.cfg]] direkt bearbeiten, sondern die "Befehl-Eingabezeile" und die "Objektdetails" zum Bearbeiten nutzen.<br />
<br />
Was ist notify? <br />
Notify ist eine der mächtigsten Funktionen bei Fhem. Sie dient dazu, Aktionen abhängig von einem anderen Ereignis/Event auszulösen. Es ist damit möglich, Logikfunktionen im Fhem abzubilden.<br />
<br />
Z.B.: das Licht in der Küche wird eingeschaltet ====&gt; draus folgt, dass auch das Radio eingeschaltet wird.<br />
<br />
=== Syntax von notify ===<br />
define <name> notify <Suchmuster> <command> <br />
<br />
Das Suchmuster (auch Regexp = regulärer Ausdruck) ist sehr wichtig. Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) Gerätename:Event. Die Events kann man dem Event-Monitor entnehmen. Wenn da z.B. Rollo1 steht, dann reagiert notify auf Rollo1 on und off und was es sonst noch alles gibt.<br />
<br />
Wenn man mehrere Suchmuster möchte, kann man diese in Klammer schreiben (Rollo1|Rollo2|Steckdose5)<br />
als Trenner wird dann Pipe (|) genutzt.<br />
<br />
Man kann auch mit Platzhaltern arbeiten.<br />
<br />
* Rollo. ==> das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg<br />
* Rollo.* ==> das notify reagiert auf alles das mit Rollo beginnt.<br />
* .*isch ==>; Reagiere auf alles das mit isch aufhört (Tisch, Fisch)<br />
<br />
Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.<br />
<br />
=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===<br />
Wenn man das obige mit KNX abbilden möchte, benötigt man auf der KNX Seite:<br />
<br />
==== Vorbereitung ====<br />
* Gruppenadresse (GA) für die Steckdose vom Radio (0/0/10)<br />
* GA vom Licht (0/0/20)<br />
<br />
Auf der Fhem Seite wird benötigt:<br />
<br />
define RadioKueche EIB 0/0/10<br />
define LichtKueche EIB 0/0/20<br />
<br />
==== notify Befehl ====<br />
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" } <br />
oder<br />
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT <br />
<br />
==== Erklärung ====<br />
* Der Begriff "LichtamRadioan" ist nur ein Platzhalter, damit das notify in Fhem verwaltet werden kann.<br />
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus ist und ein "on" wenn das Licht eingeschaltet ist.<br />
* "{ &lt;perlcode&gt; }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort Fhem. Das Schlüsselwort Fhem dient dazu, Fhem Befehle auszuführen. Es wird also der Fhem Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche Fhem Befehl muss in " " stehen.<br />
<br />
=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===<br />
==== Vorbereitung ====<br />
KNX:<br />
* 3 GAs für drei Geräten bzw Lampen (0/0/30 0/0/31 0/0/32)<br />
<br />
Fhem:<br />
define LichtWZ EIB 0/0/30<br />
define Steckdose1 EIB 0/0/31<br />
define Steckdose2 EIB 0/0/32<br />
<br />
==== notify Befehl ====<br />
define SteckdoseWZein notify LichtWZ { fhem "set Steckdose1 $EVENT;;set Steckdose2 $EVENT " } <br />
oder<br />
define SteckdoseWZein notify LichtWZ set Steckdose1,Steckdose2 $EVENT<br />
<br />
==== Erklärung ====<br />
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Steckdosen (1 und 2) eingeschaltet.<br />
<br />
=== Einfache ODER Funktion ===<br />
Eine einfache ODER Funktion kann sehr einfach realisiert werden<br />
<br />
==== Vorbereitung ====<br />
KNX:<br />
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)<br />
<br />
Fhem:<br />
define Licht1 EIB 0/0/40<br />
define Licht2 EIB 0/0/41<br />
define Steckdose EIB 0/0/42<br />
<br />
==== notify Befehl ====<br />
define SteckdoseWZein notify (Licht1|Licht2) set Steckdose $EVENT <br />
oder<br />
define SteckdoseWZein notify (Licht.) set Steckdose $EVENT<br />
<br />
==== Erklärung ====<br />
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.<br />
<br />
Danach folgt der set Befehl.<br />
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"<br />
<br />
=== Einfache UND Funktion ===<br />
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezeifeln. In Fhem fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).<br />
Dadurch ist Fhem zwar mächtig, wird aber für viele sehr kompliziert.<br />
<br />
In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.<br />
<br />
==== Vorbereitung ====<br />
KNX:<br />
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)<br />
* GD LED am Lichtschalter (0/0/106)<br />
<br />
Fhem:<br />
define R1ZU EIB 0/0/50<br />
attr R1ZU dummy 1<br />
define R2ZU EIB 0/0/51<br />
attr R1ZU dummy 1<br />
define R3ZU EIB 0/0/52<br />
attr R1ZU dummy 1<br />
define LEDalleRolloZu EIB 0/0/106<br />
Durch das Atribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.<br />
<br />
==== notify Befehl ====<br />
define nt.allerolloszu notify (R1ZU|R2ZU|R6ZU) {<br />
my $r1 = $value{"R1ZU"};;<br />
my $r2 = $value{"R2ZU"};;<br />
my $r3 = $value{"R6ZU"};;<br />
if ($r1 eq "on" &amp;&amp; $r2 eq "on" &amp;&amp; $r3 eq "on") {<br />
fhem "set LEDalleRolloZu on"<br />
} else {<br />
fhem "set LEDalleRolloZu off"<br />
}<br />
}<br />
<br />
==== Erklärung ====<br />
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }<br />
<br />
my $r1 =&gt; Variable $r1 definieren<br />
= $value{"R1ZU"};; ==&gt; weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu <br />
<br />
Der doppelte ;; ist ein Fhem Thema. Eigentlich würde für Perl ein ; reichen. Aber Fhem nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variabeln zugewiesen.<br />
<br />
Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" &amp;&amp; $r2 eq "on" &amp;&amp; $r3 eq "on")«&#160;kann man so lesen: Wenn $r1 den Wert "on" und (&amp;&amp;) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}<br />
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")<br />
<br />
=== Zeitverzögert schalten ===<br />
{| class="wikitable"<br />
| '''Aufgabe:''' || Zeitverzögert schalten<br />
|- <br />
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.<br />
|- <br />
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.<br />
|-<br />
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code><br />
|-<br />
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.<br />
:''Quelle: [http://forum.fhem.de/index.php/topic,17161.0.html Fhem Forum]''<br />
|}<br />
<br />
<br />
=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===<br />
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.<br />
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)<br />
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)<br />
<br />
==== Vorbereitung ====<br />
PV Anlage mit SolarView abfragen.<br />
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.<br />
<br />
==== notify Syntax ====<br />
Fhem:<br />
<br />
define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter<br />
attr sv event-on-change-reading currentPower <br />
<br />
define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <br />
if ($EVTPART1 &lt; 3000 ) {<br />
fhem('set Flur1 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 5000 ) {<br />
fhem('set Flur1 Ab');<br />
} <br />
}<br />
}<br />
<br />
Optional 1: Zeitabhängig<br />
<br />
(sv:currentPower.*) { <br />
my $hm = sprintf("%%02d:%%02d", $hour, $min);<br />
if ( $hm gt "09:30" &amp;&amp; $hm lt "17:00") { <br />
if ($EVTPART1 &lt; 5000 ) {<br />
fhem('set Flur1 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 8000 ) {<br />
fhem('set Flur1 Ab');<br />
} <br />
}<br />
}<br />
}<br />
<br />
Optional 2: Zeit und Datum<br />
<br />
(sv:currentPower.*) { <br />
my $hm = sprintf("%%02d:%%02d", $hour, $min);<br />
if ($month >= 6 &amp;&amp; $month <= 9) {<br />
if ( $hm gt "09:30" &amp;&amp; $hm lt "17:00") { <br />
if ($EVTPART1 &lt; 5000 ) {<br />
fhem('set Flur1,RBUERO1,RBUERO2 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 8000 ) {<br />
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');<br />
} <br />
}<br />
}<br />
}<br />
}<br />
<br />
==== Erklärung ====<br />
* Das define wird in der Kommandozeile im Webbrowser eingegeben.<br />
* Anschliessend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl<br />
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView<br />
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert<br />
if ($EVTPART1 &lt; 3000 ) {<br />
fhem('set Flur1 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 5000 ) {<br />
fhem('set Flur1 Ab');<br />
} <br />
}<br />
}<br />
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Splitergebnis vom Rückgabewert ist<br />
<br />
Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".<br />
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"<br />
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr Fhem.<br />
<br />
Ergebnis: <br />
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.<br />
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.<br />
<br />
'''Optional 1:''' Der Block "my $hm = sprintf("%%02d:%%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d (wegen Fhem Besonderheit: %%02d) begrenzt die Ausgabe auf zwei Stellen.<br />
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichende Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.<br />
<br />
'''Optional 2:'''if( $month >= 6 && $month <= 9) {<br />
<br />
Hier wird die numerische Fhem-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.<br />
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.<br />
<br />
=== Hinweise ===<br />
Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschliessende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.<br />
<br />
== Weiterführende Links ==<br />
* [http://fhem.de/commandref.html#notify commandref]<br />
* [[Escapen in Perlbefehlen]] => Bei Bearbeitung über Objektdetails nicht notwendig!<br />
* [[Klammerebenen]]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Hilfsmodul]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Klammerebenen&diff=8936Klammerebenen2014-12-22T16:08:08Z<p>BerndArnold: BerndArnold verschob Seite Klammerebnen nach Klammerebenen: Name korrigiert; nur eine Seite (Notify) verweist hierauf</p>
<hr />
<div>Nachdem das Thema im Forum zum xten mal aufkam, hier ein schneller Stub zum Thema Klammern und Mischen von Perl und Fhem Kommandos.<br />
<br />
Ich mach das später schön.<br />
<br />
Fhem kennt einges an Befehlen um Aktoren zu Schalten und auf Dinge zu reagieren. Es kann aber insbesondere keine komplexeren Operationen wie "if...else". Will man diese nutzen, muss man Fhem mit Perl-Einzeilern versehen.<br />
<br />
Die Perl Ebene wird mittels geschweifter Klammern aufgerufen: { }<br />
<br />
INNERHALB von Perlausdrücken will man aber oft doch Fhem Kommandos abgeben. Dies macht man indem man Perl sagt, das bestimmte Kommandos an Fhem übergeben werden sollen. Dies macht man durch den Ausdruck:<br />
{ fhem(" ")}. <br />
Fhem Befehle innerhalb von Perlausdrücken müssen "Escaped" werden (verdoppelt). Mehr dazu hier: [[Escapen_in_Perlbefehlen]].<br />
<br />
Ein kompletter Ausdruck mit Perl und Fhem gemischt hat daher diese äussere Form:<br />
<br />
define Name notify Ereignis {''ab hier Perl-Code'' { fhem(" ''hier Fhem Kommandos, escapen nicht vergessen'' ")} }<br />
<br />
<br />
Konkretes Beispiel: Es soll ein Garagentor geöffnet werden, aber nur wenn es vorher auch wirklich zu war. Dazu wird mittels des Perl Befehls "if" geprüft ob das Tor zu ist. Wenn ja (Value("Einfahrt") eq "Closed"), dann wird der Toraktor eingeschaltet, ausserdem einen Kontrollleuchte.<br />
<br />
define act_on_Einfahrt_AUF notify Einfahrt_AUF { if (Value("Einfahrt") eq "Closed") { fhem("set Tor_Aktor on ;; set Kontrollampe on")} }<br />
<br />
<br />
[[Kategorie:HOWTOS]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Benutzer:BerndArnold&diff=8904Benutzer:BerndArnold2014-12-17T20:55:02Z<p>BerndArnold: Seite erstellt; danke an Benutzer:Ph1959de für die Vorlage :-)</p>
<hr />
<div>== Allgemeines ==<br />
<br />
Informationen über mich in Kurzform:<br />
* Benutzer von FHEM (FHEM läuft unter Arch Linux auf einem Intel-Rechner)<br />
* angefangen mit einem FHZ1000 und FS20-Komponenten, umgestiegen auf CUL wegen [[EM1000WZ_Funk-Sensor_für_Drehstromzähler|EM1000WZ]]<br />
* Kontrolle meiner FS20- und EM-Komponenten mit einem CUL<br />
* ich möchte mich in die Bearbeitung dieses Wikis einbringen<br />
* [[HM-CFG-LAN LAN Konfigurations-Adapter|HMLan]] in Betrieb<br />
<br />
''Bernd''</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=FS20_S4A_Aufputz_Sender&diff=8903FS20 S4A Aufputz Sender2014-12-17T20:37:55Z<p>BerndArnold: Weblink zum Handbuch hinzugefügt; Ebenen korrigiert (kein =); Stil; Infobox hinzugefügt (Quelle: elv.de); Bild ergänzt</p>
<hr />
<div>{{Infobox Hardware|Bild=FS20-S4A_Vorderseite.jpg<br />
|Bildbeschreibung=FS20 S6A Aufputzsender<br />
|HWProtocol=FS20<br />
|HWType=Sender<br />
|HWCategory=FS20<br />
|HWComm=868,35 MHz<br />
|HWChannels=2 bzw. 4<br />
|HWVoltage=3 V<br />
|HWPowerConsumption=unbekannt<br />
|HWPoweredBy=2x LR44<br />
|HWSize=78 x 15 x 78 mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#FS20 10_FS20.pm]<br />
|HWManufacturer=ELV<br />
}}<br />
<br />
Der '''FS20S4A Aufputz-Wandsender''' ist ein 4 Tasten-Wandsender 2/4 Kanal<br />
<br />
== Features ==<br />
Sender zum Aufkleben an beliebiger Stelle, maximale Dicke 15 Millimeter. Betrieb mit Knopfzellen (2x LR44, Lebensdauer je nach Benutzung ca. 2 Jahre), 4 Tasten, mittige Kontroll-LED. Konfiguration entweder als 2-Kanal-Sender oder als 4-Kanal-Sender. Jede Taste sendet unterschiedliche Befehle, je nachdem, ob sie kurz oder lang gedrückt wird.<br />
<br />
Bei Einrichtung als 2-Kanal-Sender mit zwei Tastenpaaren mit jeweils ON/dimUp (rechte Taste) und OFF/dimDown (linke Taste).<br />
<br />
Bei Einrichtung als 4-Kanal-Sender mit vier einzelnen Tasten, die jeweils toggle/dimupdown senden.<br />
<br />
Details zur Konfiguration stehen im Handbuch zum Gerät.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Einsetzbar<br />
<br />
== Bekannte Probleme ==<br />
Es kommt bei zu kurzem Tastendruck vor, dass die Leuchtdiode zwar den Tastendruck quittiert, aber kein Funksignal abgesetzt wird.<br />
<br />
Beim Programmieren per FS20 IRP reicht es nicht, eine Taste ausser Funktion zu setzen durch Auswählen von "funktionsloser Befehl". Dadurch sendet die Taste bei Tastendruck einen "Sendstate" auf dem eingestellten Gerätecode. Man sollte also eine deaktivierte Taste auf einen nicht benutzten Gerätecode verwenden um Störungen zu vermeiden.<br />
<br />
== Vorlage für Beschriftung ==<br />
[http://www.ulimaass.de/fhem/S4A-Tastenaufkleber.ppt Tastenaufkleber.ppt]<br />
<br />
== Links ==<br />
Anleitung [http://files.elv.de/service/manuals/FS20S4A/73623_um.pdf PDF]<br />
<br /><br />
Details siehe [http://fhem.de/commandref.html#FS20 http://fhem.de/commandref.html#FS20]<br />
<br />
[[Kategorie:FS20 Components]]<br />
[[Kategorie:Schalter (Sender)]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Datei:FS20-S4A_Vorderseite.jpg&diff=8902Datei:FS20-S4A Vorderseite.jpg2014-12-17T20:29:00Z<p>BerndArnold: </p>
<hr />
<div></div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Erinnerungsfunktion_durch_FHEM_inkl._Anzeige_auf_dem_Iphone&diff=8901Erinnerungsfunktion durch FHEM inkl. Anzeige auf dem Iphone2014-12-17T18:26:12Z<p>BerndArnold: Stil, Wikify, Rechtschreibung, aktualisiert; andere Schreibweisen bewusst belassen (kein ß, Iphone, Mail)</p>
<hr />
<div>== Aufgabe: ==<br />
FHEM kann bei vielen Erinnerungsfunktionen - z. B. welcher Mülleimer ist abends vor die Tür zu stellen, welche Partei hat aktuell Kehrwoche, wen muss ich heute Abend anrufen um zum Geburtstag zu gratulieren - unterstützen.<br />
<br />
Um für all diese Termine den Durchblick zu behalten habe ich mir mittels der Urlaubsfunktion eine Erinnerungsfunktion gebastelt, die mich am Abend vorher per Mail an das Rausstellen der Mülltonnen bzw. am gleichen Abend an den obligatorischen Geburtstagsanruf erinnert.<br />
<br />
Anstatt der Info als E-Mail lassen sich natürlich auch alle anderen Info-Optionen nutzen.<br />
Weiterhin nutze ich diese Art der Erinnerung auch z. B. in der Anzeige im FHEM für die Anzeige der Partei, die Kehrwoche hat.<br />
<br />
Anbei der Code (zu 99% von anderen geklaut&#160;!):<br />
<br />
1. Eine Datei namens <code>events.holiday</code> im Verzeichnis <code>fhem/FHEM</code> (bei mir auf der FB ist es so) anlegen und alle Termine eintragen.<br />
Ich habe jeweils den Vortag der Abfuhr eingetragen, da ich ja nach 20:00 Uhr am Vortag den Müll rausstellen muss.<br />
<br />
<nowiki># Format fur einzelne Tage: 1 MM-DD<br />
1 05-10 GelberSack<br />
1 05-15 Altpapier<br />
1 05-17 Restmuell_Bio<br />
1 05-24 Bio <br />
1 05-30 Altpapier</nowiki><br />
<br />
2. Folgende Zeilen in die <code>fhem.cfg</code> hinzufügen und die E-Mail-Adresse eintragen. Dann geht um 20:00 Uhr eine Erinnerungs-E-Mail raus.<br />
<br />
<nowiki>define events holiday<br />
attr events room 6_EVENTS # optional<br />
attr events group Events #optional<br />
define CheckEventHeute at *20:00:00 {\<br />
my $Eventname;;\<br />
my $EventHeute;;\<br />
$EventHeute = fhem(&quot;get events today&quot;);;\<br />
print $EventHeute;;\<br />
if ($EventHeute ne &quot;none&quot;) {\<br />
$Eventname = &quot;Reminder: $EventHeute&quot;&#160;;;\<br />
FBMail('DeineEmailadresse',$Eventname,$Eventname);;\<br />
}\<br />
}<br />
attr CheckEventHeute room 5_SYSTEM #optional</nowiki><br />
Eine Abwandlung könnte der Aufruf für den morgigen Tag sein, wenn die Events-Tabelle mit den echten Abfuhrtagen gefüllt ist: <code>$EventMorgen = fhem("get events tomorrow");;</code><br />
<br />
== Optionen: ==<br />
Für die Kehrwochen habe ich eine andere Datei <code>Kehrwoche.holiday</code>, die folgendermassen aufgebaut ist:<br />
<br />
<nowiki># Format: 4 MM-DD MM-DD &lt;Text&gt;<br />
4 05-07 05-13 Partei 1.OG Links<br />
4 05-28 06-03 Partei 1.OG Rechts<br />
4 06-04 06-10 Partei 2.OG Links<br />
4 06-18 06-24 Partei 2.OG Rechts</nowiki><br />
Diese Kehrwocheninfo wird nur in meinen "Räumen" Vorschau und Events jeweils in der Gruppe Events angezeigt. Der dazugehörige Eintrag in der <code>fhem.cfg</code> lautet:<br />
<br />
<nowiki>define Kehrwoche holiday<br />
attr Kehrwoche group EVENTS #optional<br />
attr Kehrwoche room 6_EVENTS,0_VORSCHAU #optional</nowiki><br />
<br />
== Anzeige auf dem Iphone: ==<br />
Schöner als eine E-Mail finde ich jedoch eine Notification auf meinem Iphone.<br />
Das lässt sich z. B. mit dem Prowl-Service erreichen.<br />
<br />
1. Im Appstore Prowl auf dem Iphone installiert (kostete im Dezember 2014 2,69 Euro)<br />
<br />
2. Bei Prowl registrieren (auch auf Iphone) [http://www.prowlapp.com http://www.prowlapp.com]<br />
<br />
3. Neuen API-Key auf der Prowl-Homepage anlegen --&gt; dann wird dem Key entsprechend auch eine Prowl-Mailadresse definiert<br />
<br />
4. In die Mailadresse für die Erinnerung die Prowl-Mailadresse eintragen und schon schickt die Fritzbox über den Umweg der E-Mail an den Prowl-Server eine Notification aufs Iphone.<br />
<br />
Viel Spass<br />
[[Kategorie:Code Snippets]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Twilight_Anwendungsbeispiel&diff=8807Twilight Anwendungsbeispiel2014-12-11T08:17:26Z<p>BerndArnold: Typos, Stil, Verdeutlichung</p>
<hr />
<div>Das Modul Twilight errechnet verschiedene Dämmerungsphasen und kalkuliert daraus einen wetter- und dämmerungsabhängigen Lichtwert, der den Grad der Außenhelligkeit angibt. Hier soll an einem Beispiel der Einsatz dieses Moduls zur Steuerung eines Ambient-Lichtes und einer Vitrinenbeleuchtung gezeigt werden.<br />
<br />
Ziel: Eine indirekte Beleuchtung, z. B. im Wohnzimmer, soll sich, sobald es zu dämmern anfängt bzw. wetterabhängig schon früh "gefühlt" dunkler wird, eingeschaltet werden. In diesem Beispiel wird eine dimmbare indirekte Beleuchtung (ein LED-Lichtschlauch) verwendet. Die Helligkeit des Lichtschlauchs soll bei nur leichter Dämmerung maximal sein und soll sich dann bei Dunkelheit bis auf 20% reduzieren. Die Vitrinenbeleuchtung (ebenfalls LED) soll ebenfalls nur dann eingeschaltet sein, wenn es nicht taghell ist, da man die da sowieso nicht sieht. Nachts soll die Beleuchtung natürlich nicht an sein, dazu wird hier auf eine Variable "Anwesend" zurückgegriffen, die beim Autor als Indikator für Nacht und Abwesenheitsbetrieb verwendet wird. Dies kann individuell angepasst werden. Anwesend=2 bedeutet "Die Bewohner sind im Bett" und Anwesend=4 bedeutet "Die Bewohner sind abwesend".<br />
<br />
Neben der automatischen Beleuchtung soll auch ein manuelles Eingreifen möglich sein. So kann über einen Wandtaster sowohl das AmbientLight als auch die Vitrinenbeleuchtung ein- oder ausgeschaltet werden, wobei die Automatik nach einer bestimmten Zeit automatisch wieder greifen soll. Hier werden ein Homematic-Schaltaktor und ein Homematic-Dimmer verwendet, das Beispiel lässt sich leicht auf andere Komponenten übertragen.<br />
<br />
Zur Realisierung wurden einige Perl-Schnipsel in ein externes Modul ausgelagert, weil dies wesentlich übersichtlicher ist als die Inline-Definition in der fhem.cfg. Als Basis kann das Modul 99_Utils.pm genommen werden. Der Autor hat diese Datei kopiert, das Modul umbenannt, und den zusätzlichen Code eingetragen.<br />
<br />
<br />
<br />
== Definition des Twilight-Devices ==<br />
<br />
Um überhaupt die Lichtwerte zur Verfügung zu haben, muss zunächst in der fhem.cfg ein Twilight-Device erzeugt werden. Hierzu wird folgender Aufruf verwendet:<br />
<br />
Syntax: <code>define <name> Twilight <Längengrad> <Breitengrad> <Indoor_Horizont> <Yahoo-Wetter-ID></code><br />
<br />
Beispiel für Helgoland:<br />
<pre><br />
define T twilight 54.18258 7.885938 1 709403<br />
</pre><br />
<br />
Hier beispielhaft eine Eingabe direkt per telnet in FHEM auf Port 7072<br />
<br />
=== Code ===<br />
<pre><br />
define T twilight 54.18258 7.885938 1 709403<br />
<br />
list T<br />
Internals:<br />
CFGFN<br />
DEF 54.18258 7.885938 1 709403<br />
INDOOR_HORIZON 1<br />
LATITUDE 54.18258<br />
LONGITUDE 7.885938<br />
NAME THelgo<br />
NR 751<br />
STATE 6<br />
TYPE Twilight<br />
WEATHER 709403<br />
WEATHER_HORIZON 6<br />
Readings:<br />
2012-03-30 08:40:34 light 6<br />
2012-03-30 08:40:34 nextEvent ss_weather<br />
2012-03-30 08:40:34 nextEventTime 19:13:23<br />
2012-03-30 08:40:34 nextUpdate 08:55:34<br />
2012-03-30 08:40:34 sr 07:10:41<br />
2012-03-30 08:40:34 sr_astro 04:57:56<br />
2012-03-30 08:40:34 sr_civil 06:28:52<br />
2012-03-30 08:40:34 sr_indoor 07:17:33<br />
2012-03-30 08:40:34 sr_naut 05:45:13<br />
2012-03-30 08:40:34 sr_weather 07:51:46<br />
2012-03-30 08:40:34 ss 19:54:28<br />
2012-03-30 08:40:34 ss_astro 22:07:13<br />
2012-03-30 08:40:34 ss_civil 20:36:17<br />
2012-03-30 08:40:34 ss_indoor 19:47:36<br />
2012-03-30 08:40:34 ss_naut 21:19:56<br />
2012-03-30 08:40:34 ss_weather 19:13:23<br />
</pre><br />
<br />
Zu sehen ist hier die Übersicht der entsprechenden Dämmerungszeiten des aktuellen Tages (Details siehe FHEM commandref).<br />
<br />
== Berechnung des Automatik-Wertes ==<br />
<br />
In folgender Routine wird zunächst abhängig vom Lichtwert und der aktuellen Anwesenheit der Automatikwert für den Lichtschlauch und die Schrankbeleuchtung errechnet. Der Lichtschlauch ist ein Dimmer, erhält also Werte zwischen 0% und 100% und die Vitrine ist ein Schaltaktor, ist also entweder an oder aus.<br />
<pre><br />
sub calc_a_schlauch{<br />
my $licht=ReadingsVal("T","light","6");<br />
my $anwesend=ReadingsVal("anwesend","state","4");<br />
if($licht eq 6 || $anwesend eq 2 || $anwesend eq 4){<br />
fhem "set a_schlauch 0" ;<br />
fhem "set a_schrank off";<br />
}elsif($licht<6 && $licht>3){<br />
fhem "set a_schlauch 100";<br />
fhem "set a_schrank on";<br />
}elsif($licht>2 && $licht<5){<br />
fhem "set a_schlauch 40";<br />
fhem "set a_schrank on";<br />
}elsif($licht<3){<br />
fhem "set a_schlauch 20";<br />
fhem "set a_schrank on";<br />
}<br />
}<br />
</pre><br />
<br />
Die Ausgangsbedingungen "light" und "anwesend" werden zu Beginn abgefragt. In der darauffolgenden IF-Schleife wird dann je nach Lichtstärke ein Wert für die beiden Automatikwerte gesetzt. Zu beachten ist, dass die Devices a_schlauch und a_schrank Dummy-Devices sind (siehe fhem.cfg unten). Hier wird noch nicht direkt geschaltet sondern nur ein Wert berechnet und zwischengespeichert.<br />
<br />
== Manuelle Schaltung Vitrine ==<br />
<br />
Zur manuellen Schaltung wird durch das Drücken eines Tasters folgender Schnipsel ausgeführt, der dann den neuen Manuell-Wert berechnet:<br />
<pre><br />
sub calc_m_schrank{<br />
my $aktuell = ReadingsVal("m_schrank","state","auto");<br />
my $auto = ReadingsVal("a_schrank","state","off");<br />
if($aktuell eq "off" || ($aktuell eq "auto") && $auto eq "off"){<br />
fhem "set m_schrank on";<br />
}else{<br />
fhem "set m_schrank off";<br />
}<br />
}<br />
</pre><br />
Die aktuellen Werte für Manuell und Automatik werden zunächst aus den Dummy-Devices abgefragt. Jetzt gibt es zwei Möglichkeiten. Wenn die Vitrine gerade in dem Zustand ist, dass sie schon manuell ausgeschaltet wurde (also $aktuell eq "off"), dann muss sie jetzt eingeschaltet werden. Dies muss auch dann passieren, wenn man gerade im Automatikmodus ist, und eben dieser gerade auf "off" steht. Dies ist wichtig, damit für den Anwender, dem nicht klar ist, in welcher Betriebsart die Beleuchtung gerade ist, bei jedem Tasterdruck auch ein sichtbarer Schaltvorgang ausgelöst wird.<br />
<br />
== Manuelle Schaltung LED-Schlauch ==<br />
<br />
Die manuelle Schaltung des LED-Schlauchs ist noch etwas aufwendiger, da mehrere Dimmerstufen angefahren werden sollen:<br />
<pre><br />
sub calc_m_schlauch{<br />
my $aktuell = ReadingsVal("m_schlauch","state",0);<br />
my $auto = ReadingsVal("a_schlauch","state",0);<br />
if($aktuell==0 || ($aktuell==-1 && $auto==0)){<br />
fhem "set m_schlauch 100";<br />
}elsif($aktuell==100){<br />
fhem "set m_schlauch 30";<br />
}elsif($aktuell==30 || ($aktuell==-1 && $auto>0)){<br />
fhem "set m_schlauch 0";<br />
}else{<br />
fhem "set m_schlauch 0";<br />
}<br />
}<br />
</pre><br />
<br />
Das Prinzip ist wie bei der Vitrine. Da hier mit numerischen Werten gearbeitet wird, ist die Bedeutung "Automatik" nicht als "auto" definiert sondern als Zahlenwert "-1". D.h. der Wert für "m_schlauch" kann zwischen -1 und 100 schwanken, wobei im Bereich 0-100 ein manueller Wert gesetzt wird und bei "-1" die Automatik greifen soll.<br />
<br />
In der IF-Abfrage wird zunächst der Fall behandelt, dass das Licht komplett aus ist. Dies ist entweder der Fall, wenn es manuell aus ist oder die Automatik greift und diese aber auch auf "0" ist. Der zweite Zweig schaltet den manuellen Wert auf 30 runter, wenn dieser gerade auf 100 ist. In allen anderen Fällen wird das Licht im nächsten Schritt manuell ausgeschaltet.<br />
<br />
== Schalten der Aktoren ==<br />
<br />
Letztlich müssen natürlich die Aktoren tatsächlich geschaltet werden. Dazu wird folgende "Treiber"-Routine genutzt, die die manuellen und automatischen Werte logisch kombiniert:<br />
<pre><br />
sub drive_schrank_schlauch{<br />
my $dimmer=dimvalue(ReadingsVal("dim_schlauch","state",0));<br />
my $man=ReadingsVal("m_schlauch","state",0);<br />
my $auto=ReadingsVal("a_schlauch","state",0);<br />
my $newvalue;<br />
my $zeit=60;<br />
<br />
if($man==-1){<br />
$newvalue=$auto;<br />
}else{<br />
$newvalue=$man;<br />
$zeit=5;<br />
}<br />
if($dimmer ne $newvalue){<br />
fhem "set dim_schlauch ".$newvalue." 84000 ".$zeit;<br />
}<br />
my $schrank=ReadingsVal("akt_schrank","state","off");<br />
$man=ReadingsVal("m_schrank","state","auto");<br />
$auto=ReadingsVal("a_schrank","state","off");<br />
if($man eq "auto"){<br />
$newvalue=$auto;<br />
}else{<br />
$newvalue=$man;<br />
}<br />
if($schrank ne $newvalue){<br />
fhem "set akt_schrank ".$newvalue;<br />
}<br />
<br />
}<br />
</pre><br />
<br />
Hier wird nun zuerst der LED-Schlauch und dann der Schrank behandelt. Zunächst wird sowohl der aktuelle Wert des tatsächlichen Aktors (hier: dim_schlauch) als auch die Manuell- und Automatik-Werte abgefragt. Die Variable $newvalue soll den neuen Schaltwert erhalten. Dies wird deswegen eingesetzt, um einen Schaltbefehl nur dann über Funk zu senden, wenn sich der Zustand geändert hat. Die Variable $zeit wird hier genutzt, um beim automatischen Schalten den Dimmer sehr langsam fahren zu lassen, so dass es zu keiner abrupten merklichen Helligkeitsänderung kommt. Dies geht nur mit Homematic-Dimmern.<br />
<br />
In der folgenden IF-Abfrage wird geklärt, ob der Dimmer im manuellen oder automatischen Modus betrieben wird. Dementsprechend wird $newvalue gesetzt. Bei manuellem Betrieb wird die Zeit auf 5 Sekunden runtergesetzt, denn hier soll eine merkliche Helligkeitsänderung in kurzer Zeit nach dem Betätigen des Tasters erfolgen. Stellt sich dann in der kommenden Abfrage heraus, dass der aktuelle Wert des Aktors noch nicht dem von $newvalue entspricht, wird ein tatsächlicher Schaltvorgang ausgelöst. Die Zahl 84000 ist die Einschaltzeit des Dimmers (unwichtig hier, muss nur hoch genug sein, ist aus Sicherheitsgründen nicht auf 0=unendlich - so geht der Dimmer auch bei einem FHEM-Ausfall nach knapp 24 Stunden aus).<br />
Im weiteren Verlauf wird die Vitrine nach dem gleichen Prinzip geschaltet, wobei hier keine Zeit sinnvoll ist.<br />
<br />
=== fhem.cfg ===<br />
In der fhem.cfg müssen, damit die Schnipsel funktionieren, neben dem Twilight-Device auch die Dummy-Devices, die beiden Aktoren, und entsprechende At-/Notify-Defines eingetragen werden, die dafür sorgen, dass die Code-Schnipsel ausgeführt werden. Die Definition der beiden Aktoren ist hier nicht aufgeführt und muss individuell eingetragen werden.<br />
<br />
<pre><br />
define a_schlauch dummy<br />
define m_schlauch dummy<br />
define a_schrank dummy<br />
define m_schrank dummy<br />
define T twilight 54.18258 7.885938 1 709403<br />
set m_schlauch -1<br />
set m_schrank auto<br />
<br />
define m_a_schlauch notify m_a_schlauch {calc_a_schlauch();;}<br />
define n_abwesend_ambient notify anwesend {fhem "trigger m_a_schlauch";;}<br />
define n_lightchange_ambient notify T:light.* {fhem "trigger m_a_schlauch";;}<br />
define n_d_schlauch notify a_schlauch {drive_schrank_schlauch();;}<br />
define n_d_schlauch2 notify m_schlauch {drive_schrank_schlauch();;}<br />
define n_d_schrank notify a_schrank {drive_schrank_schlauch();;}<br />
define n_d_schrank2 notify m_schrank {drive_schrank_schlauch();;}<br />
define n_m_schlauch_reset notify m_schlauch {fhem "delete temp_at_m_schlauch_reset";;fhem "define temp_at_m_schlauch_reset at +01:00:00 set m_schlauch -1";;}<br />
define n_m_schrank_reset notify m_schrank {fhem "delete temp_at_m_schrank_reset";;fhem "define temp_at_m_schrank_reset at +01:00:00 set m_schrank auto";;}<br />
define n_m_schlauch notify taster_wohn:Btn1.off[^L]* {calc_m_schlauch();;}<br />
define n_m_schrank notify taster_wohn:Btn2.on[^L]* {calc_m_schrank();;}<br />
</pre><br />
<br />
<code>m_a_schlauch</code> ist ein Makro, was hier überflüssig erscheint, aber sinnvoll ist, wenn man einen Perl-Aufruf von verschiedenen Stellen aus antriggern will, so ist man unabängig vom tatsächlichen Inhalt.<br />
<br />
Die Berechnung wird also immer dann angetriggert, wenn entweder der Anwesenheitsstatus oder der Lichtwert sich verändert haben. Die folgenden Notifys reagieren auf Werteänderungen der Automatik- und Manuell-Dummys. Die nächsten beiden Notifys (<code>n_m_schlauch_reset</code> und <code>n_m_schrank_reset</code>) sorgen dafür, dass bei einer Änderung der Manuell-Werte durch das Drücken von Tastern, etc. der Wert nach einer Stunde wieder auf Automatik zurückfällt. Die letzten beiden Notifys reagieren auf genau diese Taster, wobei hier ein Homematic-Wandtaster eingesetzt wird, bei dem nur auf einen kurzen Tastendruck reagiert werden soll.<br />
<br />
Der bisherige Code sieht nicht vor, mit den Tastern auch frühzeitig wieder auf Automatik zurückzuschalten. Das kann z. B. mit einem zusätzlichen Taster gemacht werden:<br />
<br />
<pre><br />
define n_tEingang_lichtReset notify taster_eingang:Btn1.offLong.* {lichtReset();;}<br />
</pre><br />
<br />
Hier wird auf den langen Tastendruck eines anderen Tasters reagiert, wobei dieser Notify zündet, sobald man den Taster länger als 0,4 Sekunden festhält, also noch bevor dieser losgelassen wird. Der Code von lichtReset kann dann mehr tun, als nur die beiden hier beschriebenen Beleuchtungen auf Automatik zu setzen. Beispiel:<br />
<pre><br />
sub lichtReset{<br />
fhem "set m_schlauch -1";<br />
fhem "set m_schrank auto";<br />
fhem "set akt_treppe off";<br />
fhem "set akt_eingang off";<br />
fhem "set akt_esszimmer off";<br />
}<br />
</pre><br />
<br />
== yahoo - Condition Codes ==<br />
<pre><br />
Condition code Beschreibung Internes Mapping in: sub Twilight_getWeatherHorizon<br />
0 tornado 25<br />
1 tropical storm 25<br />
2 hurricane 25<br />
3 severe thunderstorms 25<br />
4 thunderstorms 20<br />
5 mixed rain and snow 10<br />
6 mixed rain and sleet 10<br />
7 mixed snow and sleet 10<br />
8 freezing drizzle 10<br />
9 drizzle 10<br />
10 freezing rain 10<br />
11 showers 7<br />
12 showers 7<br />
13 snow flurries 7<br />
14 light snow showers 5<br />
15 blowing snow 10<br />
16 snow 10<br />
17 hail 6<br />
18 sleet 6<br />
19 dust 6<br />
20 foggy 10<br />
21 haze 6<br />
22 smoky 6<br />
23 blustery 6<br />
24 windy 6<br />
25 cold 6<br />
26 cloudy 6<br />
27 mostly cloudy (night) 5<br />
28 mostly cloudy (day) 5<br />
29 partly cloudy (night) 3<br />
30 partly cloudy (day) 3<br />
31 clear (night) 0<br />
32 sunny 0<br />
33 fair (night) 0<br />
34 fair (day) 0<br />
35 mixed rain and hail 7<br />
36 hot 0<br />
37 isolated thunderstorms 15<br />
38 scattered thunderstorms 15<br />
39 scattered thunderstorms 15<br />
40 scattered showers 9<br />
41 heavy snow 15<br />
42 scattered snow showers 8<br />
43 heavy snow 5<br />
44 partly cloudy 12<br />
45 thundershowers 6<br />
46 snow showers 8<br />
47 isolated thundershowers 8<br />
not available 1<br />
</pre><br />
<br />
== Zusammenhang STATE und light ==<br />
<br />
STATE wird beim Twilight-Modul von 0 - 11 durchgezählt.<br />
<br />
0 -> vor astronomischen Aufgang, 1 -> vor nautischem Aufgang, 2 -> vor zivilem Aufgang, 3 -> vor Sonnenaufgang, 4 -> vor Indoor-Aufgang, 5 -> vor "Wetter-Aufgang", 6 -> vor "Wetter-Untergang" (also den meisten Tag lang)<br />
<br />
Bis hierher ist light = STATE. Von nun an wird light wieder weniger (es wird ja dunkler) aber STATE schreitet vor, um Sonnenuntergänge von -aufgängen unterscheidbar zu machen.<br />
<br />
7 -> vor Indoor-Untergang, 8 -> vor Sonnenuntergang, 9 -> vor zivilem Untergang, 10 -> vor nautischem Untergang, 11 -> vor astronomischem Untergang<br />
<br />
Bitte auch bedenken, dass in der Nordhälfte Deutschlands die Sonne astronomisch im Sommer ca. 6 Wochen lang nicht untergeht, State wird also nicht alle Werte durchlaufen und light wird nie 0 sein.<br />
<br />
[[Kategorie:Examples]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Z-Wave-PHI_PSM02-T%C3%BCr-,_Bewegungs-,_Helligkeits-,_Temperatursensor&diff=8780Z-Wave-PHI PSM02-Tür-, Bewegungs-, Helligkeits-, Temperatursensor2014-12-09T06:47:00Z<p>BerndArnold: Stil, Typo</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=platzHalter.png<br />
|Bildbeschreibung=todo<br />
|HWProtocol=Z-Wave <br />
|HWType=Sensor, Sender<br />
|HWCategory=Z-Wave<br />
|HWComm=Funk 868MHz<br />
|HWChannels=<br />
|HWVoltage=3V<br />
|HWPowerConsumption=48uA Standby, 37mA Operating<br />
|HWPoweredBy=1xBatterie CR123A, >2 Jahre<br />
|HWSize=Sensor 28X96X23mm, Magnet 10X50X12mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#ZWave Z-Wave]<br />
|HWManufacturer=[http://www.philio-tech.com/ Philio Technology]<br />
}}<br />
<br />
[[Z-Wave-PHI PSM02-Tür-, Bewegungs-, Helligkeits-, Temperatursensor]] ist ein 4-in-1-Sensor <br />
(Tür-/Fenstersensor, PIR/Bewegungsmelder, Temperatur-, Lichtsensor)<br />
<br />
== Features ==<br />
* Slave with routing capabilities<br />
* siehe Handbuch<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
=== Inklusion === <br />
Der Sensor wird bei der Inklusion und aktiviertem Autocreate vollautomatisch erkannt und definiert. Es sind keine manuellen Eingriffe in fhem.cfg notwendig. <br />
<br />
=== Assoziation ===<br />
Der Controller sollte zur korrekten Funktion in die Assoziationsgruppe 1 des Sensors aufgenommen werden:<br />
set <device> associationAdd 1 <Controller-NodeID><br />
<br />
=== Konfiguration ===<br />
Das Gerät von Fhem einmalig durch folgenden Befehl identifizieren: <br />
get <name> model<br />
Die Readings <code>model</code>, <code>modelID</code> und <code>modelConfig</code> werden dadurch erzeugt. In <code>model</code> steht nach korrekter Ausführung des Befehls der Klartextname des Gerätes "Philio Technology Corporation Slim Multi-Sensor PSM02". Zudem sind dann spezielle set/get-Kommandos configXYZ des Gerätes im Auswahldialog der Detailansicht mit den zugehörigen Hilfetexten verfügbar.<br />
<br />
Temperaturenheit auf Celsius umstellen (Parameter 5 wird auf 8 (Binär: 1000) geändert):<br />
set <device> configOperationMode 8<br />
<br />
Ggfs. kann das Wakeup-Intervall des Sensors angepasst werden<br />
set <device> <time/s> <Controller-NodeID><br />
<br />
=== Definition ===<br />
Ein exemplarischer Auszug aus der [[Konfiguration|fhem.cfg]]:<br />
define ZWave_SENSOR_BINARY_3 ZWave e345d763 3<br />
attr ZWave_SENSOR_BINARY_3 IODev ZWDongle_0<br />
attr ZWave_SENSOR_BINARY_3 classes BATTERY ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP MARK BASIC<br />
attr ZWave_SENSOR_BINARY_3 room ZWave<br />
define FileLog_ZWave_SENSOR_BINARY_3 FileLog ./log/ZWave_SENSOR_BINARY_3-%Y.log ZWave_SENSOR_BINARY_3<br />
attr FileLog_ZWave_SENSOR_BINARY_3 logtype text<br />
attr FileLog_ZWave_SENSOR_BINARY_3 room ZWave<br />
<br />
=== Logbeispiel ===<br />
2014-08-26_17:58:23 ZWave_SENSOR_BINARY_3 wakeup: notification<br />
2014-08-26_18:51:24 ZWave_SENSOR_BINARY_3 open<br />
2014-08-26_18:51:24 ZWave_SENSOR_BINARY_3 reportedState: open<br />
2014-08-26_18:51:24 ZWave_SENSOR_BINARY_3 luminance: 5 %<br />
2014-08-26_18:51:24 ZWave_SENSOR_BINARY_3 temperature: 24.0 C<br />
2014-08-26_18:51:25 ZWave_SENSOR_BINARY_3 closed<br />
2014-08-26_18:51:25 ZWave_SENSOR_BINARY_3 reportedState: closed<br />
2014-08-26_18:51:25 ZWave_SENSOR_BINARY_3 luminance: 5 %<br />
2014-08-26_18:51:25 ZWave_SENSOR_BINARY_3 temperature: 24.0 C<br />
2014-08-26_18:51:26 ZWave_SENSOR_BINARY_3 open<br />
2014-08-26_18:51:26 ZWave_SENSOR_BINARY_3 reportedState: open<br />
2014-08-26_18:51:26 ZWave_SENSOR_BINARY_3 luminance: 5 %<br />
2014-08-26_18:51:26 ZWave_SENSOR_BINARY_3 temperature: 24.0 C<br />
2014-08-26_18:52:03 ZWave_SENSOR_BINARY_3 motion: ff<br />
2014-08-26_18:52:03 ZWave_SENSOR_BINARY_3 luminance: 5 %<br />
2014-08-26_18:52:03 ZWave_SENSOR_BINARY_3 temperature: 24.0 C<br />
== Links ==<br />
* Handbuch: [http://www.zwave.eu/api/pdf.php?type=manual&id=PHI_PSM02_de_long.html PDF]<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Kategorie:Z-Wave Components]]<br />
[[Kategorie:Lichtsensoren]]<br />
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]<br />
[[Kategorie:Kontaktsensor (magnetisch)]]<br />
[[Kategorie:Temperatursensoren]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=EnOcean_Starter_Guide&diff=8779EnOcean Starter Guide2014-12-08T16:27:17Z<p>BerndArnold: Link-Korrektur, Typox, Stil</p>
<hr />
<div>{{Infobox Modul<br />
|Name=EnOcean<br />
|ModPurpose=Ansteuerung EnOcean-Geräte über TCM<br />
|ModType=d<br />
|ModCmdRef=EnOcean<br />
|ModForumArea=EnOcean<br />
|ModTechName=10_EnOcean.pm <br />
|ModOwner=klaus.schauer ([http://forum.fhem.de/index.php?action=profile;u=293 Forum] / [[Benutzer Diskussion:Klaus.schauer|Wiki]])<br />
}}{{Infobox Modul<br />
|Name=TCM<br />
|ModPurpose=Einbindung EnOcean-Gateway<br />
|ModType=d<br />
|ModCmdRef=TCM<br />
|ModForumArea=EnOcean<br />
|ModTechName=00_TCM.pm <br />
|ModOwner=klaus.schauer ([http://forum.fhem.de/index.php?action=profile;u=293 Forum] / [[Benutzer Diskussion:Klaus.schauer|Wiki]])<br />
}}<br />
<br />
== EnOcean ==<br />
[http://www.enocean.com/de/ EnOcean] ist <br />
* ein [http://www.enocean.com/de/enocean-wireless-standard/ ISO ratifizierter Funkstandard], ausgelegt für Funksensoren und Funksensornetze mit besonders niedrigem Energieverbrauch<br />
* ein Anbieter batterieloser Funksensoren<br />
EnOcean-Endgeräte mit dem von der EnOcean Alliance zur Verfügung gestellten EnOcean-Funkprotokoll werden von [http://www.enocean-alliance.org/de/hiererhaeltlich/ zahlreichen Hardware-Herstellern] angeboten. <br />
<br />
=== EnOcean Equipment Profile ===<br />
Abhängig von den Funktionen des EnOcean-Endgerätes werden bestimmte veröffentlichte Anwendungs-Profile/Funk-Telegramme, die sogenannten EnOcean Equipment Profiles (EEPs), zur Funkkommunikation genutzt. Technische Details zum EnOcean-Funkprotokoll und insbesondere zu den [http://www.enocean-alliance.org/eep/ EnOcean Equipment Profiles (EEPs)] sind auf der Internetseite der [http://www.enocean-alliance.org EnOcean Alliance] zu finden.<br />
<br />
==== Manufacturer Specific Communication ====<br />
EnOcean bietet - neben den veröffentlichten Standard-Enocean-Profilen - die Möglichkeit für die Nutzung von herstellerspezifischen Anwendungs-Profilen/Funk-Telegrammen (MSC = Manufacturer Specific Communication). Falls die Herstellerfirmen den Inhalt dieser MSC-Telegramme nicht veröffentlichen, ist eine Unterstützung durch Fhem grundsätzlich nicht möglich. Teilweise werden die Produkte sowohl mit MSC- als auch mit Standard-Enocean-Profilen vertrieben [http://forum.fhem.de/index.php/topic,19544.msg132240.html#msg132240]. Angaben zu den verwendeten Profilen/Telegrammen sind den Bedienungsanleitungen der Produkte zu entnehmen.<br />
<br />
=== uni- versus bidirektional ===<br />
EnOcean-Endgeräte gibt es sowohl in uni- als auch in bidirektionalen Ausführungen. Bei '''unidirektionalen Endgeräten''' erfolgt die Funk-Kommunikation nur in eine Richtung. Einem Aktor, der Licht schaltet, kann zwar der Befehl zum An- bzw. Ausschalten gegeben werden, er liefert aber keine Rückinformation über die erfolgreiche Ausführung des Befehls. Bei '''bidirektionalen Endgeräten''' erfolgt die Funk-Kommunikation hingegen in zwei Richtungen: sie bieten <br />
# Sende- und <br />
# Empfangsmöglichkeiten. <br />
Der bidirektionale Aktor kann somit unter anderem die erfolgreiche Ausführung eines empfangenen Befehls zurückmelden.<br />
<br />
=== SenderID ===<br />
Damit EnOcean Funk-Aktoren (z.B. Relais, Dimmer, Heizungsventil) auf EnOcean Sensoren (z.B. Taster, Temperatursensor, Fensterkontakt, Energieverbrauchsmesser) reagieren können, werden die Sensoren bei den Aktoren eingelernt (Teach-in). So wird festgelegt, dass z.B. "Funktaster 1" den "Dimmer 1" steuert. <br />
Alle EnOcean Geräte mit Sendefunktion haben mindestens eine eindeutige, unabänderliche 8-stellige Hex-SenderID (z.B. ffc54500; teilweise auch dargestellt mit Punkten oder Doppelpunkten dazwischen). Die SenderID ist meist auf den EnOcean Geräten aufgedruckt oder liegt der Verpackung des Endgerätes bei. Beim Anlernvorgang wird die eindeutige SenderID des Sensors in der Empfängertabelle des Aktors gespeichert.<br />
<br />
== EnOcean in Fhem ==<br />
=== Allgemein ===<br />
Fhem wird fortwährend weiterentwickelt und verbessert. Daher ist es zwingend notwendig, dass Fhem auf dem aktuellsten Stand ist. Dazu nach der Fhem-Installation den Befehl <code>update</code> ausführen und anschließend <code>shutdown restart</code> durchführen. Genauso auch vor Anfragen im Forum die Aktualität von Fhem überprüfen.<br />
<br />
Die Nutzung von EnOcean in Fhem ist für den Anfänger nur mit der standardmäßig eingeschalteten [http://fhem.de/commandref.html#autocreate autocreate-Funktion] einfach umsetzbar. Die Kenntnis der Fhem-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere ist [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit Fhem] zu empfehlen, auch wenn es nicht speziell EnOcean behandelt, so werden doch wesentliche Punkte für ein Verständnis von Fhem vermittelt.<br />
<br />
Im Folgenden und auf den [[:Kategorie:EnOcean Components|Wiki-Seiten der Einzelgeräte]] werden immer wieder Auszüge aus der [[Konfiguration|fhem.cfg]] dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der [[Konfiguration|fhem.cfg]] sollte - zur Verhinderung von Anfängerfehlern - nach Möglichkeit immer über das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" und die "[[Konfiguration#Objektdetails|Objektdetails]]" erfolgen.<br />
<br />
=== Vorbereitung ===<br />
Die SenderIDs der EnOcean-Geräte haben eine zentrale Bedeutung in Fhem. Sie sind eindeutiges Unterscheidungsmerkmal, werden von Fhem im Rahmen der Funkkommunikation genutzt und in der Definition der Geräte bzw. den Attributen des Geräte hinterlegt. Es empfiehlt sich daher, eine Tabelle aufzubauen mit folgender oder ähnlicher Struktur:<br />
<br />
<table class="wikitable" border="1"><br />
<tr><br />
<th> A<br />
</th><br />
<th> B<br />
</th><br />
<th> C<br />
</th><br />
<th> D<br />
</th><br />
<th> E<br />
</th></tr><br />
<tr><br />
<th> Nr.<br />
</th><br />
<th> Name EnOcean<br />
</th><br />
<th> Name in Fhem<br />
</th><br />
<th> HEX (Sender-ID)<br />
</th><br />
<th> Zimmer<br />
</th></tr><br />
<tr><br />
<td><br />
</td><br />
<td> &lt;Name Hardwareschalter&gt;<br />
</td><br />
<td> &lt;Name in Fhem&gt;<br />
</td><br />
<td> &lt;HEX Code&gt;<br />
</td><br />
<td> &lt;Raumname&gt;<br />
</td></tr><br />
<tr><br />
<td><br />
</td><br />
<td> TCM_ESP3_0<br />
</td><br />
<td> TCM_ESP3_0<br />
</td><br />
<td> AABBCC00<br />
</td><br />
<td><br />
</td></tr><br />
<tr><br />
<td> 1<br />
</td><br />
<td> EnO_switch_123456<br />
</td><br />
<td> eg_fl_Licht<br />
</td><br />
<td> AABBCC01<br />
</td><br />
<td> EG_Flur<br />
</td></tr><br />
<tr><br />
<td> ...<br />
</td><br />
<td><br />
</td><br />
<td><br />
</td><br />
<td><br />
</td><br />
<td><br />
</td></tr><br />
<tr><br />
<td> 128<br />
</td><br />
<td><br />
</td><br />
<td><br />
</td><br />
<td><br />
</td><br />
<td><br />
</td></tr></table><br />
<br />
== Definition von TCM / Gateway ==<br />
Fhem kann mit einem Funkgateway, das auf einem TCM-Modul basiert, EnOcean-Funk empfangen und senden. <br />
Bisher gibt es zwei Transceiver Chips von EnOcean: <br />
* TCM120 (ausgelaufen)<br />
** für den USB-Port: [https://embedded-intelligence.de/de/products/hardware/bsc-bor.html BSC BOR] <br />
* TCM310 <br />
** als USB-Stick: [http://www.enocean.com/de/enocean_module/usb-300-oem/ USB 300] und [http://busware.de/tiki-index.php?page=EUL Busware EUL]<br />
** als Aufsteckmodul für Raspberry Pi: [http://www.enocean.com/de/enocean-pi/ EnOceanPi]<br />
<br />
Zudem existiert eine [http://forum.fhem.de/index.php/topic,22635.msg160582.html#msg160582 Lösung zur kabelgebundenen Anbindung] des Fhem-Rechners mittels Eltako FGW14 an den [[EnOcean-Eltako-RS485-Bus|Eltako RS485-Bus]], über die sowohl Busaktoren als auch EnOcean-Funkaktoren gesteuert werden können und auch EnOcean-Funktelegramme über das [[EnOcean-Eltako-RS485-Bus|FAM14 Funkantennenmodul]] am RS485-Bus empfangen werden können.<br />
<br />
Das TCM-basierte Gateway wird nach dem Anschluss an den Fhem-Rechner beim Fhem-Start automatisch erkannt und grundlegend durch entsprechende Einträge in der fhem.cfg definiert. Ein manuelles Anlegen des TCM-Moduls oder Eingriff in die fhem.cfg ist nicht notwendig und auch nicht ratsam. Eine Ausnahme bilden RS485-basierte Gateways (bspw. FGW14) bei denen manuell das Attribut <code>comType</code> auf <code>RS485</code> in der [[Konfiguration|fhem.cfg]] gesetzt werden muss, da ansonsten Fhem nicht mehr startet. <br />
<br />
Beispiele der automatisch erzeugten define-Zeile in der fhem.cfg:<br />
<br />
EnOceanPi an Raspberry Pi:<br />
define TCM_ESP3_0 TCM ESP3 /dev/ttyAMA0@57600<br />
<br />
TCM310/USB300 an Fritzbox oder Raspberry Pi:<br />
define TCM_ESP3_0 TCM ESP3 /dev/ttyUSB0@57600<br />
<br />
Hier folgt ein Beispiel der define-Zeile in der fhem.cfg für kabelgebundene Anbindung mit FGW14 über serielle Schnittstelle<br />
define TCM_ESP2_0 TCM ESP2 /dev/ttyS3@57600<br />
attr TCM_ESP2_0 comType RS485 <---- Manuell zu setzen; zwingend, sonst startet Fhem nicht!!<br />
<br />
Nach erfolgreicher Definition ist das Gateway im Raum "Everything" in der Gruppe "TCM" zu finden. Wenn neben dem Gatewaynamen "initialized" oder "opened" angezeigt wird, ist Fhem in der Lage mit den EnOcean-Geräten zu kommunizieren.<br />
<br />
Wie im [[#SenderID|Einführungsabschnitt]] bereits erläutert hat jedes sendende EnOcean-Endgerät mindestens eine eindeutige SenderID. Diese SenderID kann aus Sicherheitsgründen nicht vom EnOcean-Gateway simuliert werden. Vielmehr hat das Gateway eigene SenderIDs, die separat in die Endgeräte/Aktoren angelernt werden müssen. Das Gateway stellt 128 verschiedene SenderIDs zur Verfügung. Ausgehend von der baseID, die bei jedem Gateway grundsätzlich anders ist, werden die SenderIDs fortlaufend hexadezimal hochgezählt:<br />
* Fhem stehen 127 fortlaufende eigene SenderID zur Verfügung<br />
* beginnend mit der baseID des TCM + 1<br />
<br />
Die baseID des TCM erhält man durch Eingabe von<br />
get TCM_ESP3_0 baseID <br />
in das Befehl-Eingabefeld (TCM_ESP3_0 gegebenenfalls durch den eigenen Gatewaynamen ersetzen).<br />
<br />
Das Webfrontend zeigt dann:<br />
BaseID=AABBCC00,RemainingWriteCycles=0A<br />
Die niedrigste SenderID in diesem Beispiel ist AABBCC0'''1''' (BaseID=AABBCC00 +1 HEX!!!), die nächste AABBCC0'''2''' usw.<br />
<br />
Nach der Definition des Gateways und Ermittlung der baseID des Gateways kann nun der nächste Schritt, die Definition der EnOcean-Geräte in Fhem, erfolgen.<br />
<br />
Mehr Details in der [http://fhem.de/commandref.html#TCM commandref] zu TCM.<br />
<br />
== Definition von Geräten ==<br />
=== Definition / Anlernvorgang (Teach-In) ===<br />
Damit Fhem und EnOcean-Geräte miteinander kommunizieren können, müssen sie untereinander bekannt gemacht werden. Dies geschieht durch Definition des Gerätes in Fhem und den Anlernvorgang. Dazu muss sich Fhem im [http://fhem.de/commandref.html#TCM_learningMode learningMode] befinden. Viele Geräte werden von Fhem während des Anlernvorgangs automatisch erkannt und definiert. Dennoch ist ein grundlegendes Verständnis der Anlernvorgänge und Unterscheidungsprinzipen in Fhem und EnOcean notwendig. Sofern das Gerät Bestätigungstelegramme verschicken kann, sind diese zwingend '''vorher''' am Gerät einzuschalten (u.a. Eltako). <br />
<br />
Fhem entnimmt die Angaben, wie ein Funk-Telegramm für ein bestimmtes Gerät aufgebaut ist, im Wesentlichen aus den Attributen <code>subType</code>, <code>manufID</code> und/oder <code>model</code> der Definition des Gerätes:<br />
*<code>subtype</code>: genutztes EEP-Profil des Gerätes (steht meist in der Bedienungsanleitung des Gerätes)<br />
*<code>manufID</code>: Code für den Hersteller des Gerätes<br />
*<code>model</code>: Modell des Gerätes<br />
Während des Anlernvorgangs werden diese Angaben von Fhem soweit wie möglich automatisch in der Definition vorbelegt. Hinweise zu den Besonderheiten von bestimmten Geräten und EEP-Profilen finden sich oft in der [http://fhem.de/commandref.html#EnOcean commandref] zu EnOcean. Darum bitte immer in der commandref zunächst nach dem speziellen Gerät (Modellbezeichnung) suchen, wenn dies keinen Treffer liefert nach dem verwendeten EEP suchen. Die gegebenen Hinweise und Erläuterungen dort beachten.<br />
<br />
Die Definition und der Anlernvorgang unterscheiden sich je nach Gerätetyp:<br />
* Sensoren:<br />
** [[#Schalter/Switch|Schalter (EEP RPS)]]: werden automatisch beim ersten empfangenen Funktelegramm in Fhem mit den notwendigen Attributen angelegt.<br />
** [[#Kontakte|Kontakte (EEP 1BS)]]: werden automatisch beim ersten empfangenen Funktelegramm in Fhem mit den notwendigen Attributen angelegt.<br />
** [[#Sonstige_Sensoren|Sonstige Sensoren (EEP 4BS)]]: Durch Versand eines speziellen Anlern-Funktelegramms können sie in Fhem automatisch mit den notwendigen Attributen angelegt werden. Im Anlerntelegramm übermittelt der Sensor Fhem die EEP-Profilangabe und die Hersteller-ID. Aufgrund dieser Angaben kann Fhem das Gerät eindeutig erkennen und die richtigen Attribute in Fhem setzen. Einige wenige Sensoren verschicken leider ein Anlerntelegramm ohne EEP-Profilangabe und/oder Herstellerangabe (Bsp: Omnio Ratio eagle-PM101). Bei diesen Sensoren müssen die Attribute subType, manufID und/oder model manuell in Fhem gesetzt werden, damit eine richtige Auswertung der Funktelegramme erfolgt.<br />
* Aktoren (4BS, VLD, UTE, MSC): Bei den Aktoren gibt es je nach Gerätetyp verschiedene Anlernvorgänge, die unterschiedlich in Fhem ausgeführt werden. Einige Aktoren unterstützen auch mehrere Anlernvorgänge. Grundsätzlich muss wegen abweichender Vorgehensweise in Fhem unterschieden werden zwischen<br />
** [[#uni- versus bidirektional|unidirektionalen]] Aktoren und<br />
*** [[#Teach-In_als_Tasteremulation|Teach-In als Tasteremulation]]<br />
*** [[#Teach-In_als_Gateway.2FPC-Steuerung|Teach-In als Gateway/PC-Steuerung]]<br />
** [[#uni- versus bidirektional|bidirektionalen]] Aktoren<br />
*** [[#Teach-In_als_Tasteremulation_2|Teach-In als Tasteremulation]]<br />
*** [[#Unidirektionales_4BS-Teach-In|Unidirektionales 4BS-Teach-In]]<br />
*** [[#Bidirektionales_4BS-Teach-In|Bidirektionales 4BS-Teach-In]]<br />
*** [[#UTE-Teach-In|UTE-Teach-In]]<br />
<br />
In den nachfolgenden Gliederungspunkten wird beispielhaft für je ein Gerät aus den obigen Gerätetypen die Einbindung in Fhem erläutert.<br />
<br />
Grundlegend gilt immer:<br />
Fhem legt sendende, noch nicht definierte EnOcean Geräte selbst an, wenn<br />
* in fhem.cfg autocreate aktiviert ist:<br />
** <code>[http://fhem.de/commandref_DE.html#autocreate define autocreate autocreate]</code><br />
* Fhem/das TCM-Modul sich im <code>learningMode</code> befindet und<br />
* Fhem eine Nachricht vom noch nicht definierten EnOcean Gerät empfängt<br />
Im Webfrontend werden automatisch angelegte neue Geräte im Raum EnOcean angezeigt.<br />
<br />
=== Sensoren ===<br />
'''Sensoren Beispiele:'''<br />
<br />
==== Schalter/Switch ====<br />
[[EnOcean-PTM-210-Taster|PTM 210 - Schaltermodul]] ([http://www.enocean.com/de/enocean_module/ptm-210-data-sheet-pdf/ Datenblatt])<br />
<br />
EEP: F6-02-xx<br />
<br />
Fhem in den learningMode (<code>set <IODev> teach <time/s></code>) versetzen, dazu im Befehl-Eingabefeld eingeben:<br />
set TCM_ESP3_0 teach 600<br />
<br />
Dann einen beliebigen Taster des Moduls drücken (und loslassen). Beim Drücken des Tasters wird vom Taster eine Nachricht ausgesendet, die von Fhem empfangen wird. Daraufhin definiert Fhem automatisch den Taster und der Taster ist in Fhem angelernt. Fhem fügt dazu folgenden Code zur fhem.cfg hinzu:<br />
* exemplarischer Auszug aus fhem.cfg<br />
define EnO_switch_FFC54500 EnOcean FFC54500 <-- "FFC54500" ist die 8-stellige Hex-SenderID des Tasters<br />
attr EnO_switch_FFC54500 IODev TCM_ESP3_0<br />
attr EnO_switch_FFC54500 room EnOcean<br />
attr EnO_switch_FFC54500 subType switch <-- handelt sich um einen Schalter<br />
# attr EnO_switch_FFC54500 eventMap AI:off A0:on BI:an B0:aus <-- bei Bedarf ... die gemapten Werte (hier: off, on, an, aus) sollen eindeutig sein<br />
define FileLog_EnO_switch_FFC54500 FileLog ./log/EnO_switch_FFC54500-%Y.log EnO_switch_FFC54500<br />
attr FileLog_EnO_switch_FFC54500 logtype text<br />
<br />
Ein Schalter (hier: FT55) hat vier Taster:<br />
{|<br />
| '''Taster''' || '''in Fhem'''<br />
|-<br />
| links oben || A0<br />
|-<br />
| links unten || AI (nicht "eins" sondern "i"!)<br />
|-<br />
| rechts oben || B0<br />
|-<br />
| rechts unten || BI<br />
|}<br />
<br />
Das Log FileLog_EnO_switch_FFC54500 zeichnet beim einmaligen Drücken des linken unteren Tasters ("AI") folgendes auf:<br />
2014-01-01_07:00:01 EnO_switch_FFC54500 buttons: pressed<br />
2014-01-01_07:00:01 EnO_switch_FFC54500 channelA: AI<br />
2014-01-01_07:00:01 EnO_switch_FFC54500 AI<br />
2014-01-01_07:00:02 EnO_switch_FFC54500 buttons: released<br />
<br />
Der angelegte Sensor repräsentiert im Webfrontend den physischen Schalter (bspw. an der Wand). Ein Druck auf den physischen Taster ändert den Zustand im Webfrontend. Jedoch führt ein Schalten des Repräsentanten im Webfrontend nicht zu einer Schaltung des Aktors.<br />
<br />
Fhem kann sich '''nicht''' als einer der vorhandenen (automatisch angelegten) physischen Sensoren ausgeben (um z.B. das Licht zu schalten) sondern verwendet eigene SenderIDs. Diese Fhem-eigenen SenderIDs können in EnOcean-Aktoren eingelernt werden, damit die Aktoren auf Fhem reagieren [[#Aktoren|siehe unten]].<br />
<br />
==== Kontakte ====<br />
[[EnOcean-STM-250-Fenster-T%C3%BCrkontakt|STM 320 Batterieloses Magnetkontakt-Funkmodul]] ([http://www.enocean.com/de/enocean_module/stm-320-data-sheet-pdf/ Datenblatt])<br />
<br />
EEP: D5-00-01<br />
<br />
Fhem in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:<br />
set TCM_ESP3_0 teach 600<br />
<br />
Anlerntelegramm laut Anleitung verschicken oder Magnetkontakt öffnen und schließen.<br />
<br />
Der Kontakt wird automatisch in Fhem definiert und ist angelernt.<br />
<br />
* exemplarischer Auszug aus fhem.cfg<br />
define EnO_contact_0000FF53 EnOcean 0000FF53<br />
attr EnO_contact_0000FF53 IODev TCM_ESP3_0<br />
attr EnO_contact_0000FF53 room EnOcean<br />
attr EnO_contact_0000FF53 subType contact<br />
define FileLog_EnO_contact_0000FF53 FileLog ./log/EnO_contact_0000FF53-%Y.log EnO_contact_0000FF53<br />
attr FileLog_EnO_contact_0000FF53 logtype text<br />
attr FileLog_EnO_contact_0000FF53 room EnOcean<br />
<br />
==== Sonstige Sensoren ====<br />
===== 4BS-Teach-In =====<br />
Fhem in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:<br />
set TCM_ESP3_0 teach 600<br />
Dann das Anlerntelegramm laut Bedienungsanleitung am Sensor auslösen. Der Sensor wird dann wird automatisch in Fhem definiert und ist angelernt.<br />
<br />
===== Profilloses 4BS-Teach-In =====<br />
Omnio Ratio eagle-PM101 Licht- und Anwesenheitssensor ([http://www.omnio.ch/content-en/downloads/Betriebsanleitungen/2902000_Betriebsanleitung_ea.pdf Betriebsanleitung])<br />
<br />
Fhem in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:<br />
set TCM_ESP3_0 teach 600<br />
<br />
Das Anlerntelegramm vom Omnio Ratio eagle-PM101 verschicken (MÖGLICH??)<br />
<br />
Im angelegten Fhem-Device manuell das Attribut <code>subType</code> auf <code>PM101</code> setzen.<br />
<br />
=== Aktoren ===<br />
Die Bedienungsanleitungen und die commandref liefern Informationen, welche Anlernvorgänge der Aktor unterstützt. Finden sich keine Hinweise auf besondere PC- oder Gateway-Anlernvorgänge, so kann Fhem als "Notlösung" immer als virtueller Fhem-Schalter (Tasteremulation) angelernt werden. Einige Aktoren unterstützen mehrere Arten von Anlernvorgängen. Hier ist der mit den meisten/besten Steuerungsmöglichkeiten zu bevorzugen.<br />
<br />
'''Aktoren Beispiele:'''<br />
<br />
==== unidirektionale Aktoren ====<br />
'''MERKE:''' Eine SenderID des TCM-Gateways muss bei unidirektionalen Aktoren immer im <code>define</code> des Devices stehen.<br/><br />
'''MERKE:''' Im Webfrontend stimmt der Status von unidirektionalen Aktoren nur mit dem realen Zustand überein, wenn ausschließlich über Fhem oder einen Wandtaster gesteuert wird ([[#Physischer_EnOcean-_und_virtueller_Fhem-Schalter_zu_einem_Device_zusammenfassen|Abhilfe]])<br />
<br />
===== Teach-In als Tasteremulation =====<br />
PEHA 451 FU-EP o.T. (Schaltaktor unidirektional) <br />
<br />
Fhem in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:<br />
set TCM_ESP3_0 teach 600<br />
<br />
Eine [[#Wie ermittelt man freie Sender-IDs des TCM-basierten Funkgateways?|freie SenderID des TCM-basierten Gateways heraussuchen]] und diese als EnOcean-Gerät in Fhem definieren, dazu im Befehl-Eingabefeld eingeben:<br />
define eg_fl_Licht EnOcean AABBCC01<br />
<br />
Durch diese Definition wird ein 8-fach EnOcean-Taster mit dem Attribut <code>subType</code> auf <code>switch</code> erzeugt. Der Taster hat 4 Kanälen (A,B,C,D) zu je 2 Tasten (0,I). Alle diese 8 Taster senden mit der gleichen SenderID des TCM. Das entspricht einem Gerät mit 4 Schaltwippen die jeweils "oben" '''oder''' "unten" gedrückt sein können. Fhem emuliert mit diesem EnOcean-Gerät einen EnOcean-Schalter (darum auch "virtueller Fhem-Schalter"). Der Taster 0 des Kanal A wird "gedrückt" mit <code>set eg_fl_Licht A0</code>.<br />
<br />
Dieser virtuelle Fhem-Schalter wird in den Aktor wie ein physischer Schalter eingelernt. Den Aktor in den Anlernmodus bringen (Taste LRN/SET drücken) und den virtuellen Fhem-Schalter betätigen, indem im Befehl-Eingabefeld eingeben wird:<br />
set eg_fl_Licht B0<br />
Wenn der Aktor den erfolgreichen Anlernvorgang signalisiert, den Anlernmodus am Aktor ausschalten.<br />
<br />
* exemplarischer Auszug aus fhem.cfg<br />
define eg_fl_Licht EnOcean AABBCC01 <--- AABBCC01 ist eine der 127 SenderID's des TCM, mit der Fhem sendet <br />
attr eg_fl_Licht room EG_Flur<br />
attr eg_fl_Licht eventMap BI:off B0:on<br />
attr eg_fl_Licht subType switch<br />
define FileLog_eg_fl_Licht FileLog ./log/ eg_fl_Licht-%Y.log eg_fl_Licht<br />
attr FileLog_eg_fl_Licht logtype text<br />
<br />
Der Status des Devices im Webfrontend stimmt bei unidirektionalen Aktoren nur, wenn die Steuerung des Aktors ausschließlich über Fhem erfolgt. Wird der Aktor sowohl über einen physischen Schalter als auch über Fhem gesteuert, so müssen die Stati der beiden Devices für physischen und virtuellen Schalter im Webfrontend verknüpft werden, damit der richtige Status des Aktors angezeigt wird ([[#Physischer EnOcean- und virtueller Fhem-Schalter zu einem Device zusammenfassen |siehe unten]]).<br />
<br />
===== Teach-In als Gateway/PC-Steuerung =====<br />
"ältere" Eltako FSB61 (Produktionszeitraum KW 43/10 - KW 40/11 [http://www.eltako.com/fileadmin/downloads/de/_bedienung/FSB61NP_30200420-3_dtsch.pdf Bedienungsanleitung])<br />
<br />
EEP: A5-3F-7F <br />
<br />
Fhem in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:<br />
set TCM_ESP3_0 teach 600<br />
<br />
Eine [[#Wie ermittelt man freie Sender-IDs des TCM-basierten Funkgateways?|freie SenderID des TCM-basierten Gateways heraussuchen]] und diese als EnOcean-Gerät in Fhem definieren, dazu im Befehl-Eingabefeld eingeben:<br />
define eg_fl_Rollo EnOcean AABBCC02<br />
<br />
Hierdurch wird in Fhem ein EnOcean-Gerät definiert, das standardmäßig das Attribut <code>subType</code> auf <code>switch</code> gesetzt hat. Das Attribut <code>subType</code> muss auf <code>manufProfile</code> geändert werden. Die Attribute <code>manufID</code> und <code>model</code> müssen auf die unten in der fhem.cfg gezeigten Werte gesetzt werden.<br />
<br />
Dieser virtuelle Fhem-Schalter wird in den Aktor als PC/Szenentaster angelernt indem im Befehl-Eingabefeld eingeben wird:<br />
set eg_fl_Rollo teach<br />
Wenn der Aktor den erfolgreichen Anlernvorgang signalisiert, den Anlernmodus am Aktor ausschalten.<br />
<br />
* exemplarischer Auszug aus fhem.cfg<br />
define eg_fl_Rollo EnOcean AABBCC02 <--- AABBCC02 ist eine der 127 SenderID's des TCM, mit der Fhem sendet <br />
attr eg_fl_Rollo room EG_Flur<br />
attr eg_fl_Rollo subType manufProfile<br />
attr eg_fl_Rollo manufID 00D<br />
attr eg_fl_Rollo model FSB61<br />
<br />
Der Status des Devices im Webfrontend stimmt bei unidirektionalen Aktoren nur, wenn die Steuerung des Aktors ausschließlich über Fhem erfolgt. Wird der Aktor sowohl über einen physischen Schalter als auch über Fhem gesteuert, so müssen die Stati der beiden Devices für physischen und virtuellen Schalter im Webfrontend verknüpft werden, damit der richtige Status des Aktors angezeigt wird ([[#Physischer EnOcean- und virtueller Fhem-Schalter zu einem Device zusammenfassen |siehe unten]]).<br />
<br />
==== bidirektionale Aktoren ====<br />
'''MERKE:''' Eine SenderID des TCM-Gateways muss bei bidirektionalen Aktoren immer im Attribut <code>subDef</code> des Devices stehen.<br/><br />
'''MERKE:''' Im Webfrontend stimmt der Status von bidirektionalen Aktoren nach korrekter Einbindung in Fhem immer mit dem realen Zustand überein.<br />
<br />
===== Teach-In als Tasteremulation =====<br />
[[EnOcean-FSR61VA-10A-Stromsto%C3%9F-Schaltrelais_mit_Strommessung|10A-Stromstoß-Schaltrelais mit Strommessung FSR61VA]]<br/><br />
Schaltrelais (bidirektional)<br />
<br />
Fhem in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:<br />
set TCM_ESP3_0 teach 600<br />
<br />
Die [[#SenderID|SenderID]] des Aktors heraussuchen und diese als EnOcean-Gerät in Fhem definieren, dazu im Befehl-Eingabefeld eingeben:<br />
define EnO_switch_FSR61VA EnOcean FFAABBC0<br />
<br />
Eine freie SenderID des TCM-basierten Gateways heraussuchen und diese im Attribut <code>subDef</code> des angelegten Devices hinterlegen.<br />
<br />
Anschließend die Attribute <code>subType</code> und <code>switchMode</code> wie im unten wiedergegebenen exemplarischen Auszug aus der fhem.cfg anlegen.<br />
<br />
Damit der FSR61VA auf Fhem reagieren kann (Ein/Ausschalten), wird das Fhem-Device EnO_switch_FSR61VA in den FSR61VA als Richtungstaster (bzw. Taster ein/aus) eingelernt:<br />
# Unterer Drehschalter je nach Produktionswoche des FSR61VA (aufgedruckt):<br />
## bis KW 2/13: "ca. Mitte" (Taster Ein/Aus einlernen)<br />
## ab KW 3/13 bis KW 10/14: "60" (Taster Ein/Aus einlernen)<br />
## ab KW 11/14: "40" (Richtungstaster einlernen)<br />
# Oberer Funktions-Drehschalter: "LRN" (LED blinkt)<br />
# Fhem Eingabefeld: „set EnO_switch_FSR61VA B0“, &lt;Enter&gt; (LED erlischt)<br />
# Oberer Funktions-Drehschalter: Eine der ESV-Einstellungen<br />
# Unterer Funktions-Drehschalter: auf "oo" einstellen (unendlich)<br />
<br />
* exemplarischer Auszug aus der fhem.cfg<br />
define EnO_switch_FSR61VA EnOcean FFAABBC0 --> EnO_switch_FSR61VA ist ein frei gewählter eindeutiger Name<br />
für das Fhem-Device.<br />
FFAABBC0 ist die erste am Boden des FSR61VA aufgedruckte SenderID. <br />
Damit sendet das FSR61VA den Schaltzustand (B0/BI --> ein/aus)<br />
attr EnO_switch_FSR61VA IODev TCM_ESP3_0 --> TCM_ESP3_0 ist der Name des Devices, mit dem Fhem EnOcean-Funk <br />
sendet und empfängt.<br />
attr EnO_switch_FSR61VA subDef FF998877 --> FF998877 ist eine der 127 SendeIDs des TCM_ESP3_0, damit sendet Fhem an den FSR61VA<br />
attr EnO_switch_FSR61VA subType switch --> es handelt sich um einen EnOcean Schalter (der kann A0, AI, B0, BI,...)<br />
attr EnO_switch_FSR61VA switchMode pushbutton --> als "pushbutton" sendet Fhem bei einem <br />
"set EnO_switch_FSR61VA B0" nach dem Kommando (B0) noch ein "release".<br />
Das brauchts, wenn der FSR61VA als ES oder ESV betrieben wird.<br />
Sonst wird jedes "set"-Kommando vom FSR61VA als <br />
"länger als eine Sekunde gedrückt" interpretiert -> "Tasterdauerlicht".<br />
<br />
===== Unidirektionales 4BS-Teach-In =====<br />
[[EnOcean-FSR14-4x-RS485-Bus-Schaltaktor-4-Kanal-Stromsto%C3%9F-Schaltrelais|RS485-Bus-Aktor 4-Kanal-Stromstoß-Schaltrelais FSR14]]<br/><br />
Schaltrelais (bidirektional)<br />
<br />
Fhem in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:<br />
set TCM_ESP3_0 teach 600<br />
<br />
Die [[#SenderID|SenderID]] des Aktors heraussuchen und diese als EnOcean-Gerät in Fhem definieren, dazu im Befehl-Eingabefeld eingeben:<br />
define EnOcean_switch_FEFF4AF8 EnOcean FEFF4AF8<br />
<br />
Eine freie SenderID des TCM-basierten Gateways heraussuchen und diese im Attribut <code>subDef</code> des angelegten Devices hinterlegen.<br />
<br />
Anschließend die Attribute <code>subType</code> und <code>gwCmd</code> wie im unten wiedergegebenen exemplarischen Auszug aus der fhem.cfg anlegen.<br />
<br />
Jetzt den Aktor in den Lernmodus versetzen und dann von Fhem das Lerntelegramm verschicken:<br />
set EnOcean_switch_FEFF4AF8 teach<br />
Lernmodus am Aktor ausschalten<br />
<br />
* exemplarischer Auszug aus fhem.cfg<br />
define EnOcean_switch_FEFF4AF8 EnOcean FEFF4AF8 <--- FEFF4AF8 ist hier die SenderID eines FSR14-Kanals (Aktor)<br />
attr EnOcean_switch_FEFF4AF8 subDef AABBCC03 <--- AABBCC03 ist eine der 127 SenderID's des TCM, mit der Fhem sendet [[#Taster - physisch und in Fhem|(siehe unten)]]<br />
attr EnOcean_switch_FEFF4AF8 room EnOcean # Der Raum kann angepasst werden<br />
attr EnOcean_switch_FEFF4AF8 gwCmd switching # Wichtig für FSR14<br />
attr EnOcean_switch_FEFF4AF8 subType gateway # Wichtig für FSR14<br />
define FileLog_EnOcean_switch_FEFF4AF8 FileLog ./log/EnOcean_switch_FEFF4AF8-%Y.log EnOcean_switch_FEFF4AF8<br />
attr FileLog_EnOcean_switch_FEFF4AF8 logtype text<br />
<br />
===== Bidirektionales 4BS-Teach-In =====<br />
[[EnOcean-MD15-Kleinstellantrieb|Kleinstellantrieb MD15-FTL-xx]]<br/> <br />
Funkgesteuerter, batteriegespeister Kleinstellantrieb für Raumtemperaturregelung (bidirektional)<br />
<br />
EEP: A5-20-01<br />
<br />
4BS-Bidirektionales-Teach-In:<br />
<br />
#Aktor möglichst komplett zurücksetzen, sofern nicht mehr im Original-Auslieferzustand<br />
#Falls vorhanden, alle bisherigen Fhem-Devices des Aktors löschen<br />
#Fhem in Lernmodus schalten: <code>set <IODev> teach <time/s></code><br />
#Taster am MD15-FTL-xx so lange drücken, bis ein Signalton ertönt. MD15 bestätigt erfolgreichen Anlernvorgang durch das Aufleuchten der Status-LED und 2 Signaltöne<br />
#Aktor wird in Fhem automatisch mit allen notwendigen Parametern angelegt.<br />
<br />
* exemplarischer Auszug aus fhem.cfg<br />
define EnO_sensor_01000EFA EnOcean 01000EFA<br />
attr EnO_sensor_01000EFA IODev TCM_ESP3_0<br />
attr EnO_sensor_01000EFA comMode biDir<br />
attr EnO_sensor_01000EFA destinationID unicast<br />
attr EnO_sensor_01000EFA manufID 00A<br />
attr EnO_sensor_01000EFA room EnOcean<br />
attr EnO_sensor_01000EFA subDef AABBCC04<br />
attr EnO_sensor_01000EFA subType hvac.01<br />
define FileLog_EnO_sensor_01000EFA FileLog ./log/EnO_sensor_01000EFA-%Y.log EnO_sensor_01000EFA<br />
attr FileLog_EnO_sensor_01000EFA logtype text<br />
attr FileLog_EnO_sensor_01000EFA room EnOcean<br />
<br />
===== UTE-Teach-In =====<br />
[[EnOcean-D-452-FU-EBIM-Aktor-2fach|Einbau-Aktor 452 FU-EBIM o.T.]]<br/><br />
2-Kanal-Multifunktionsaktor (bidirektional) mit Energiemessfunktion<br />
<br />
EEP: D2-01-08<br />
<br />
UTE-Teach-In:<br />
<br />
#Aktor möglichst komplett zurücksetzen, sofern nicht mehr im Original-Auslieferzustand<br />
#Falls vorhanden, alle bisherigen Fhem Devices des Aktors löschen<br />
#Fhem in Lernmodus schalten: <code>set <IODev> teach <time/s></code><br />
#Aktor-Kanal 0 oder 1 in Lernmodus versetzen (immer nur einen Kanal)<br />
#Aktor-Kanal 0 oder 1 wird in Fhem automatisch mit allen notwendigen Parametern angelegt.<br />
#Das Anlernen für den zweiten Kanal wie nach 3. bis 5. beschrieben wiederholen<br />
<br />
Die Kanäle können jetzt geschaltet werden mit:<br />
<br />
*Fhem Device für Kanal 0: set <Name_0> on|off 0<br />
*Fhem Device für Kanal 1: set <Name_1> on|off 1<br />
<br />
Falls gewünscht, kann der Kanal mit dem Attribut attr <Name_0|1> defaultChannel 0|1 voreingestellt werden. Dann entfällt die Angabe des Kanals im set-Befehl.<br />
<br />
Die Statusrückmeldungen mit den aktuellen Werten des Energieverbrauches und der Leistung werden vom Aktor automatisch gesendet. Sie werden sowohl als Telegramme nach EEP D2-01-08 als auch nach EEP A5-11-04 mit unterschiedlichen SenderIDs (vgl. Etikett in Original-Verpackung) gesendet.<br />
Die Rückmeldungen nach EEP D2-01-08 werden von Fhem im Aktor-Device subType actuator.01 berücksichtigt. Die Rückmeldungen nach EEP A5-11-04 werden von Fhem in einem senor-device subType lightCtrlState.02 berücksichtigt. <br />
<br />
<br />
== Besonderheiten für die Anzeige im WebFrontend ==<br />
<br />
=== Aufteilung der Kanäle in unabhängige Devices ===<br />
===== Mehrkanalige bidirektionale Aktoren =====<br />
Mehrkanalige bidirektionale Aktoren (bspw. Eltako FMS61NP) haben teilweise nur eine SenderID und werden daher in Fhem über ein Fhem-Device im Webfrontend abgebildet und gesteuert. Um im WebFrontend für jeden Kanal ein separates Fhem-Device zur Anzeige und Steuerung zu erhalten, kann [[ReadingsProxy|readingsProxy]] genutzt werden.<br />
<br />
Zunächst wird der Aktor standardmäßig in Fhem definiert/angelernt und die Funktion geprüft (hier am Beispiel eines Aktor mit dem Namen "Aktor"). Anschließend wird pro Kanal ein readingProxy-Device mit Bezug auf das Reading channelA, channelB, ... angelegt:<br />
<br />
#Kanal A zur Steuerung mit on und off<br />
define AktorKanalA readingsProxy Aktor:channelA<br />
attr AktorKanalA setFn {($CMD eq "on")?"A0":"AI";;} <br />
attr AktorKanalA setList off on <br />
attr AktorKanalA valueFn {($VALUE eq "A0")?"on":"off"}<br />
attr AktorKanalA webCmd off:on <br />
<br />
#Kanal B zur Steuerung mit on und off<br />
define AktorKanalB readingsProxy Aktor:channelB<br />
attr AktorKanalB setFn {($CMD eq "on")?"B0":"BI";;} <br />
attr AktorKanalB setList off on <br />
attr AktorKanalB valueFn {($VALUE eq "B0")?"on":"off"}<br />
attr AktorKanalB webCmd off:on <br />
<br />
Jeder Kanal wird jetzt separat im WebFrontend durch das readingsProxy-Device abgebildet (Statusanzeige) und kann mit diesem gesteuert werden.<br />
<br />
===== virtuelle Schalter für unidirektionale Aktoren =====<br />
Um die 4 Kanäle jeweils einzeln als Schalter (einzelne Schaltwippe) im WebFrontend abzubilden kann [[ReadingsProxy|readingsProxy]] genutzt werden. Anders als bei den bekannten bidirektionalen Aktoren und den Fhem-Devices der physischen Schalter, existiert bei den virtuellen Schaltern das Reading channelA, channelB, ... nicht. Daher muss das readingsProxy für den virtuellen Schalter vom Reading state abgeleitet werden:<br />
<br />
#Kanal A zur Steuerung mit on und off<br />
define fhemSchalterKanalA readingsProxy fhemSchalter:state<br />
attr fhemSchalterKanalA setFn {($CMD eq "on")?"A0":"AI";;}<br />
attr fhemSchalterKanalA setList on off<br />
attr fhemSchalterKanalA valueFn {$LASTCMD}<br />
attr fhemSchalterKanalA webCmd on:off<br />
<br />
#Kanal B zur Steuerung mit on und off<br />
define fhemSchalterKanalB readingsProxy fhemSchalter:state<br />
attr fhemSchalterKanalB setFn {($CMD eq "on")?"B0":"BI";;}<br />
attr fhemSchalterKanalB setList on off<br />
attr fhemSchalterKanalB valueFn {$LASTCMD}<br />
attr fhemSchalterKanalB webCmd on:off<br />
<br />
#Kanal C zur Steuerung mit on und off<br />
define fhemSchalterKanalC readingsProxy fhemSchalter:state<br />
attr fhemSchalterKanalC setFn {($CMD eq "on")?"C0":"CI";;}<br />
attr fhemSchalterKanalC setList on off<br />
attr fhemSchalterKanalC valueFn {$LASTCMD}<br />
attr fhemSchalterKanalC webCmd on:off<br />
<br />
#Kanal D zur Steuerung mit on und off<br />
define fhemSchalterKanalD readingsProxy fhemSchalter:state<br />
attr fhemSchalteKanalD setFn {($CMD eq "on")?"D0":"DI";;}<br />
attr fhemSchalterKanalD setList on off<br />
attr fhemSchalterKanalD valueFn {$LASTCMD}<br />
attr fhemSchalterKanalD webCmd on:off<br />
<br />
Werden diese Fhem-Taster (und etwaige physische Taster) in EnOcean-Aktoren eingelernt (siehe Anleitung des Aktors), so können nun die EnOcean-Aktoren mit physischen Tastern (sendet mit der 8-stelligen SenderID des Tasters) und mit virtuellen Fhem-Readingsproxy-Schaltern (senden mit einer der 127 eigenen SenderIDs) bedient werden.<br />
<br />
=== Physischer EnOcean- und virtueller Fhem-Schalter zu einem Device zusammenfassen ===<br />
Um im Webfrontend die Aktionen beider Schalter in einem Element zusammengefasst und damit den realen Zustand bei '''unidirektionalen''' Aktoren zu sehen, kann man eine <code>structure</code> nutzen:<br />
<br /><br />
(Bei bidirektionalen Aktoren ist dies aufgrund der Statusrückmeldungen nicht notwendig. Achtung: Teilweise müssen Statusrückmeldungen/Bestätigungstelegramme erst am Aktor eingeschaltet werden)<br />
<br />
#Definition des virtuellen Fhem-Schalters<br />
define fhemSchalter EnOcean AABBCC01 <--- AABBCC01 ist eine der 127 SenderID's des TCM, mit der Fhem sendet<br />
attr fhemSchalter eventMap BI:off B0:on<br />
attr fhemSchalter icon icoBELEUCHTUNG.png<br />
attr fhemSchalter subType switch<br />
<br />
#Definition des physischen Tasters (z.B. durch autocreate erzeugt)<br />
define EnO_switch_0021E4BB EnOcean 0021E4BB <--- 0021E4BB ist die (aufgedruckte) 8-stellige SenderID des physischen Tasters<br />
attr EnO_switch_0021E4BB eventMap BI:off B0:on<br />
attr EnO_switch_0021E4BB room EnOcean<br />
attr EnO_switch_0021E4BB subType switch<br />
attr EnO_switch_0021E4BB dummy<br />
<br />
#fhemSchalter ist der Name des virtuellen Fhem-Schalters<br />
#EnO_switch_0021E4BB ist der (z.B. per autocreate erstellte) Fhem-Taster<br />
define Gruppe_test_notify structure room fhemSchalter EnO_switch_0021E4BB<br />
attr Gruppe_test_notify eventMap BI:off B0:on<br />
attr Gruppe_test_notify room Gaestezimmer<br />
attr Gruppe_test_notify clientstate_behavior last<br />
<br />
Alternativ kann man für diesen Zweck auch ein <code>notify</code> in Verbindung mit <code> setreading <device> state <state></code> nutzen:<br />
<br />
define nAbgleich notify EnO_switch_0021E4BB:(on|off) setreading fhemSchalter state $EVENT<br />
<br />
== FAQ ==<br />
=== Warum schaltet mein Aktor nicht, wenn ich im WebFrontend auf das Icon für den physischen Taster/Schalter klicke bzw. mit <code>set <device> <command></code> ansteuere? ===<br />
:Aus Sicherheitsgründen können bei EnOcean keine physischen Geräte(-adressen) durch Fhem bzw. das TCM-Gateway emuliert werden. Fhem muss zur Steuerung separat an den Aktor angelernt werden. Dazu eine der TCM-Adressen an den Aktor anlernen.<br />
=== Welche Infos sollten Anfragen im EnOcean-Forum enthalten? ===<br />
* Anfragen bitte nur zur aktuellsten Fhem-Version: Befehl <code>update</code> ergibt Ausgabe "nothing to do..."<br />
* detaillierte Beschreibung des Problems<br />
* beteiligte Komponenten (genaue Bezeichnung und evtl. Link auf Hersteller-Dokumentation)<br />
* Config-Auszug (fhem.cfg)<br />
* list des jeweiligen devices (<code>list <device></code>)<br />
* logs mit verbose 5 (<code>attr <device> verbose 5</code>)<br />
=== Wie kann ich zur Fortentwicklung der EnOcean-Module beitragen? ===<br />
* Erfolgreichen Einsatz von neuen/bisher nicht gemeldeten EnOcean-Geräten im Forum mitteilen<br />
* In der Commandref als [untested] markierte EEPs bei erfolgreichen Tests im Forum als getestet melden<br />
* Codeschnipsel und Ideen im Forum posten<br />
* Fehler und Probleme im Forum melden<br />
* Wiki: Neue Geräte ins Wiki aufnehmen; Codeschnipsel und Beispiele einpflegen<br />
=== Wie findet man die Sender-ID eines bidirektionalen Aktors? ===<br />
* Aufkleber auf dem Aktor oder beigelegte Information in der Aktorverpackung<br />
* Ermittlung mit Fhem:<br />
# Bestätigungstelegramme am Aktor aktivieren<br />
# physischen Taster am Aktor anlernen<br />
# Fhem in den learningMode versetzen: <code>set <IODev> teach <time/s></code><br />
# EventMonitor aufrufen<br />
# Aktor mit physischen Taster schalten<br />
# Im EventMonitor wird nun neben der Sender-ID des Tasters die Sender-ID des Aktors durch das Bestätigungstelegramm angezeigt<br />
# Fhem hat mittels autocreate für das Bestätigungstelegramm ein Device mit dem subType switch angelegt, sofern das vorher noch nicht existierte. Dieses Device kann man nach eventueller Änderung des subType und dem Setzen anderer gegebenenfalls notwendiger Attribute an den Aktor anlernen.<br />
<br />
=== Wie ermittelt man freie Sender-IDs des TCM-basierten Funkgateways? ===<br />
* Aus der oben [[EnOcean_Starter_Guide#Vorbereitung|gezeigten Tabelle]] oder hilfsweise mit den nachfolgenden Befehlen<br />
* Anzeige der nächsten freien Sender-ID: <pre>{EnOcean_CheckSenderID("getNextID", "<IODev>", "0000000")}&#13; </pre><br />
* Auflistung der bereits vergebenen Sender-IDs: <pre>{EnOcean_CheckSenderID("getUsedID", "<IODev>", "0000000")}&#13; </pre><br />
* Auflistung der noch nicht vergebenen Sender-IDs: <pre>{EnOcean_CheckSenderID("getFreeID", "<IODev>", "0000000")}&#13; </pre><br />
=== Schaltet immer AI ein und A0 aus, BI ein und B0 aus usw. ? ===<br />
Nein. <br><br />
Das Verhalten der Aktoren ist abhängig vom Anlernvorgang und/oder vom Hersteller.<br />
=== Für mein EnOcean-Gerät gibt es keine spezielle Wiki-Seite; wo finde ich dann Informationen? ===<br />
* In der commandref nach dem Gerät suchen<br />
* In der commandref nach dem verwendeten EEP suchen<br />
* Im Wiki nach einem Gerät mit einer ähnlichen EEP/subType suchen<br />
* Im EnOcean-Forum nach Threads zum Gerät/EEP suchen<br />
=== Warum funktioniert mein Eltako-Gerät nicht wie in commandref/Wiki beschrieben? ===<br />
* Eltako-Geräte haben bei gleicher Produktbezeichnung teilweise je nach Produktionswoche unterschiedliche Funktionen/Eigenschaften<br />
* die Produktionswoche ist auf dem Gerät angegeben (z.B. 11/14 -> Elfte Woche im Jahr 2014)<br />
* in den nach Produktionswoche untergliederten [http://www.eltako.com/de/bedienungsanleitungen/der-gebaeudefunk.html Bedienungsanleitungen] stehen genauere Angaben<br />
* Angaben in commandref/Wiki analog für die Angaben laut Bedienungsanleitung für den speziellen Produktionszeitraum umsetzen<br />
* bei gravierenden Abweichungen und Neuerungen Info im Forum/Wiki <br />
=== Wie kann ich Eltako-Aktoren anhand Ihrer Modellbezeichnung grob unterscheiden? ===<br />
* 12er Baureihe (ausgelaufen) = unidirektionale RS485-Bus-Aktoren für Hutschiene<br />
* 14er Baureihe = bidirektionale RS485-Bus-Aktoren für Hutschiene<br />
* 61er Baureihe = uni- und bidirektionale Aktoren je nach Produktionszeitraum für Einbaumontage (Hohlwanddose)<br />
* 70/71er Baureihe = uni- und bidirektionale Aktoren je nach Produktionszeitraum für Einbaumontage (Zwischendecke)<br />
* zwischen den Modellreihen gibt es bei uni- und bidirektonalen Aktoren bei der Ansteuerung Übereinstimmungen; Angaben können dementsprechend analog zwischen den Geräten übertragen werden<br />
=== Wie kann ich PEHA-Aktoren anhand Ihrer Modellbezeichnung grob unterscheiden? ===<br />
* Easyclick-Unterputzempfänger: unidirektionale Aktoren für Einbaumontage; Modellbezeichnung enthält typischerweise die Buchstaben EP<br />
* Easyclickpro-Unterputzempfänger: bidirektionale Aktoren für Einbaumontage; Modellbezeichnung enthält die Buchstaben EBI oder EBIM (mit zusätzlicher Energiemessung)<br />
=== Wo finde ich Angaben zu Jäger Direkt - OPUS GreenNet EnOcean-Geräten? ===<br />
* Es handelt sich im Wesentlichen um umgelabelte Produkte anderer Hersteller (Peha, Eltako usw.). Anhand der Gehäuseform lassen sich Rückschlüsse ziehen<br />
* Angaben zu den "Original"-Produkten können grundsätzlich -soweit bekannt- auf OPUS GreenNet Geräte übertragen werden<br />
<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:EnOcean Components]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HttpUtils&diff=8655HttpUtils2014-12-01T12:27:43Z<p>BerndArnold: Rechtschreibung, Stil</p>
<hr />
<div>= Allgemein =<br />
<br />
Das Modul HttpUtils.pm ist sowohl für Modulentwickler, als auch Endanwender gedacht um Daten via HTTP auszutauschen. Es stellt dabei eine Reihe von Funktionen bereit, auf die in diesem Artikel näher eingegangen werden soll.<br />
<br />
Erstellt wurde HttpUtils.pm von Rudolf König.<br />
<br />
== Die Funktionen im Einzelnen ==<br />
<br />
Es ist zu beachten, dass bei den Funktionen<br />
<br />
* GetHttpFile<br />
* GetFileFromURL<br />
* GetFileFromURLQuiet<br />
* HttpUtils_BlockingGet<br />
<br />
ein sogenannter "blockierender" Aufruf durchgeführt wird. Das bedeutet, dass FHEM bei einem Aufruf einer dieser Funktionen solange wartet und dabei absolut nichts macht, bis die Antwort vom HTTP-Server eintrifft und die Funktion damit beendet ist. Das kann bei Verbindungsproblemen evtl. dazu führen, dass FHEM für die gesamte Wartezeit (Timeout) steht und nichts verarbeitet. Problematisch ist so etwas gerade bei Anwendungen oder Hardware, die eine zeitnahe Reaktion von FHEM erwarten (z.B. HomeMatic-Geräte).<br />
<br />
Es wird daher empfohlen die Funktionen so sparsam wie möglich zu verwenden und die Timeouts so niedrig wie möglich zu halten um ein längeres Einfrieren von FHEM möglichst zu verhindern.<br />
<br />
<br />
Alternativ kann man die Funktion <br />
<br />
* HttpUtils_NonblockingGet<br />
<br />
verwenden, welche ein Blockieren von FHEM verhindert. Wie das genau funktioniert, wird in dem entsprechenden Kapitel beschrieben.<br />
<br />
<br />
Folgende Funktionen sind für Modulentwickler/Endanwender zur direkten Nutzung gedacht:<br />
<br />
<br />
=== GetHttpFile ===<br />
<br />
Die Funktion GetHttpFile ist die denkbar einfachste Variante um eine URL aufzurufen. <br />
<br />
<br />
'''Aufruf: <code>GetHttpFile($server, $file)</code>'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Parameter!! Bedeutung<br />
|-<br />
| style="vertical-align:top" | '''<code>$server</code>'''<br />
<br />
''mandatory''<br />
|| Der DNS-Name oder die IP-Adresse des HTTP-Servers<br><br><br />
Beispiel:<br />
<br />
* ''<nowiki>www.myhost.com</nowiki>''<br />
* ''<nowiki>192.168.0.10</nowiki>''<br />
|-<br />
| style="vertical-align:top" | '''<code>$file</code>''' <br />
<br />
''mandatory''<br />
|| Die Datei, welche auf dem HTTP-Server aufgerufen werden soll.<br><br><br />
Beispiel:<br />
* ''/''<br />
* ''/index.html''<br />
* ''/directory/image.jpg''<br />
|}<br />
<br />
Funktionsergebnis ist der Inhalt der aufgerufenen Seite in Form eines Strings.<br />
<br />
=== GetFileFromURL ===<br />
<br />
Die Funktion GetFileFromURL ruft die HTTP-URL auf und gibt als Funktionsergebnis den Seiteninhalt zurück. Im Gegensatz zu GetHttpFile beinhaltet GetFileFromURL einige Zusatzoptionen in Form von Funktionsparametern.<br />
<br />
<br />
'''Aufruf: <code>GetFileFromURL($url, ''[$timeout], [$data], [$noshutdown], [$loglevel]'')</code>'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Parameter!! Bedeutung<br />
|-<br />
| style="vertical-align:top" | '''<code>$url</code>'''<br />
<br />
''mandatory''<br />
|| Die HTTP-URL, welche aufgerufen werden soll. Diese kann optional Usernamen, Passwort und einen Port enthalten. Sowohl HTTP als auch HTTPS wird hierbei unterstützt.<br><br><br />
Beispiel:<br />
<br />
* ''<nowiki>http://www.myhost.com/directory/</nowiki>''<br />
* ''<nowiki>https://www.myhost.com/</nowiki>''<br />
* ''<nowiki>http://www.myhost.com:8080/</nowiki>''<br />
* ''<nowiki>http://foo:bar@www.myhost.com/</nowiki>''<br />
|-<br />
| style="vertical-align:top" | '''<code>$timeout</code>'''<br />
<br />
''optional''<br />
|| Die maximale Dauer in Sekunden für die HTTP-Anfrage<br />
<br />
<br />
Beispiel: 5 ''(Sekunden)''<br />
<br />
Standardwert: 4 Sekunden<br />
|-<br />
| style="vertical-align:top" | '''<code>$data</code>'''<br />
<br />
''optional''<br />
|| Wenn man Daten via HTTP-POST übertragen möchte, so kann man die Nutzdaten über $data übergeben. Die Daten werden dabei als Formulardaten übertragen. Wenn man den Content-Type beeinflussen oder mehrere Formular-Felder senden möchte, sollte man zur Funktion HttpUtils_BlockingGet oder HttpUtils_NonblockingGet greifen.<br />
<br />
<br />
Standardwert: ''[leer]''<br />
<br />
|-<br />
| style="vertical-align:top" | '''<code>$noshutdown</code>''' <br />
<br />
''optional''<br />
|| Wenn $noshutdown auf 1 gesetzt ist, wird dem HTTP-Server nicht implizit mitgeteilt, dass die Verbindung nach dem Request geschlossen werden soll. Viele Webserver schließen in solch einem Fall die Verbindung bevor sie die Antwort senden. Bei 0 wird dem Webserver mitgeteilt, dass der Sendevorgang beendet ist und nun die Antwort abgewartet wird.<br />
<br />
<br />
Standardwert: 1<br />
|-<br />
| style="vertical-align:top" | '''<code>$loglevel</code>'''<br />
<br />
''optional''<br />
|| Das Logleve, in dem sämtliche Logmeldungen zu dieser HTTP-Abfrage erzeugt werden sollen.<br />
<br />
<br />
Standardwert: 4<br />
|}<br />
<br />
Funktionsergebnis ist der Inhalt der aufgerufenen Seite in Form eines Strings.<br />
<br />
=== GetFileFromURLQuiet ===<br />
<br />
Diese Funktion funktioniert ähnlich wie GetFileFromURL. Allerdings wird die tatsächliche URL in allen erzeugten Log-Meldungen unkenntlich gemacht um z.B. Zugangsdaten nicht preiszugeben. Die aufgerufene Seite wird ebenfalls als Funktionsergebnis zurückgegeben.<br />
<br />
<br />
'''Aufruf: <code>GetFileFromURLQuiet($url, ''[$timeout], [$data], [$noshutdown], [$loglevel]'')</code>'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Parameter!! Bedeutung<br />
|-<br />
| style="vertical-align:top" | '''<code>$url</code>'''<br />
<br />
''mandatory''<br />
|| Die HTTP-URL, welche aufgerufen werden soll. Diese kann optional Usernamen, Passwort und einen Port enthalten. Sowohl HTTP als auch HTTPS wird hierbei unterstützt.<br><br><br />
Beispiel:<br />
<br />
* ''<nowiki>http://www.myhost.com/directory/</nowiki>''<br />
* ''<nowiki>https://www.myhost.com/</nowiki>''<br />
* ''<nowiki>http://www.myhost.com:8080/</nowiki>''<br />
* ''<nowiki>http://foo:bar@www.myhost.com/</nowiki>''<br />
|-<br />
| style="vertical-align:top" | '''<code>$timeout</code>'''<br />
<br />
''optional''<br />
|| Die maximale Dauer in Sekunden für die HTTP-Anfrage<br />
<br />
<br />
Beispiel: 5 ''(Sekunden)''<br />
<br />
Standardwert: 4 Sekunden<br />
|-<br />
| style="vertical-align:top" | '''<code>$data</code>'''<br />
<br />
''optional''<br />
|| Wenn man Daten via HTTP-POST übertragen möchte, so kann man die Nutzdaten über <code>$data</code> übergeben. Die Daten werden dabei als Formulardaten übertragen. Wenn man den Content-Type beeinflussen möchte, oder mehrere Formular-Felder senden möchte, sollte man zur Funktion HttpUtils_BlockingGet oder HttpUtils_NonblockingGet greifen.<br />
<br />
<br />
Standardwert: ''[leer]''<br />
<br />
|-<br />
| style="vertical-align:top" | '''<code>$noshutdown</code>''' <br />
<br />
''optional''<br />
|| Wenn $noshutdown auf 1 gesetzt ist, wird dem HTTP-Server nicht implizit mitgeteilt, dass die Verbindung nach dem Request geschlossen werden soll. Viele Webserver schließen in solch einem Fall die Verbindung bevor sie die Antwort senden. Bei 0 wird dem Webserver mitgeteilt, dass der Sendevorgang beendet ist und nun die Antwort abgewartet wird.<br />
<br />
<br />
Standardwert: 1<br />
|-<br />
| style="vertical-align:top" | '''<code>$loglevel</code>'''<br />
<br />
''optional''<br />
|| Das Loglevel, in dem sämtliche Logmeldungen zu dieser HTTP-Abfrage erzeugt werden sollen.<br />
<br />
<br />
Standardwert: 4<br />
|}<br />
<br />
Funktionsergebnis ist der Inhalt der aufgerufenen Seite in Form eines Strings.<br />
<br />
=== HttpUtils_BlockingGet ===<br />
<br />
Wenn die bisher genannten Funktionen nicht ausreichen um die gewünschte Abfrage durchzuführen, so kann man diese Funktion verwenden. Aufgrund zahlreicher Parameter ermöglicht sie viele Anpassungsmöglichkeiten. Diese Funktion hat dabei nicht wie üblich eine Liste an Funktionsparametern, sondern lediglich einen Parameter, welcher ein Hash mit allen Funktionsparametern darstellt. Dieser Hash enthält sämtliche Parameter inkl. Werten. <br />
<br />
<br />
'''Aufruf: <code>HttpUtils_BlockingGet($param)</code>'''<br />
<br />
Der Hash $param kann folgende Optionen beinhalten:<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:175px" | Parameter !! style="width:auto" | Bedeutung<br />
|-<br />
| style="vertical-align:top" | '''<code>$param->{url}</code>'''<br />
<br />
''mandatory''<br />
|| Die HTTP-URL, welche aufgerufen werden soll. Diese kann optional Usernamen, Passwort und einen Port enthalten. Sowohl HTTP als auch HTTPS wird hierbei unterstützt.<br><br><br />
Beispiel:<br />
<br />
* ''<nowiki>http://www.myhost.com/directory/</nowiki>''<br />
* ''<nowiki>https://www.myhost.com/</nowiki>''<br />
* ''<nowiki>http://www.myhost.com:8080/</nowiki>''<br />
* ''<nowiki>http://foo:bar@www.myhost.com/</nowiki>''<br />
<br />
|-<br />
| style="vertical-align:top" |'''<code>$param->{timeout}</code>'''<br />
<br />
''optional''<br />
|| Die maximale Dauer in Sekunden für die HTTP-Anfrage<br />
<br />
<br />
Beispiel: 5 ''(Sekunden)''<br />
<br />
Standardwert: 4 Sekunden<br />
|-<br />
| style="vertical-align:top" |'''<code>$param->{data}</code>'''<br />
<br />
''optional''<br />
|| Wenn man Daten via HTTP-POST übertragen möchte, so kann man die Nutzdaten über <code>$param{data}</code> übergeben. Die Daten werden dabei als Formulardaten übertragen. Die Daten können dabei auf zwei Arten übergeben werden:<br />
<br />
1. Daten als String:<br />
:* Die Daten werden komplett als gesamter String in <code>$param{data}</code> abgelegt (z.B.: $param{data} = "Jede Menge tolle Daten").<br />
2. Daten als Hash:<br />
:* Die Daten werden als Hash mit Key-Value-Pairs übergeben (z.B.: $param{data}{field1} = "value1", $param{data}{field2} = "value2", ... ). Die Daten werden dann als Formulardaten mit mehrfachen Datenfeldern übertragen.<br />
<br />
<br />
Standardwert: ''[leer]''<br />
<br />
|-<br />
| style="vertical-align:top" | '''<code>$param->{noshutdown}</code>''' <br />
<br />
''optional''<br />
||Wenn <code>$param->{noshutdown}</code> auf 1 gesetzt ist, wird dem HTTP-Server nicht implizit mitgeteilt, dass die Verbindung nach dem Request geschlossen werden soll. Viele Webserver schließen in solch einem Fall die Verbindung bevor sie die Antwort senden. Bei 0 wird dem Webserver mitgeteilt, dass der Sendevorgang beendet ist und nun die Antwort abgewartet wird.<br />
<br />
<br />
Standardwert: 1<br />
|-<br />
| style="vertical-align:top" | '''<code>$param->{loglevel}</code>'''<br />
<br />
''optional''<br />
|| Das Loglevel, in dem sämtliche Logmeldungen zu dieser HTTP-Abfrage erzeugt werden sollen.<br />
<br />
<br />
Standardwert: 4<br />
|-<br />
| style="vertical-align:top" | '''<code>$param->{hideurl}</code>'''<br />
<br />
''optional''<br />
|| Wenn dieser Parameter den Wert 1 trägt, wird die URL in sämtlichen Log-Ausgaben unkenntlich gemacht. Dies ist nützlich um z.B. Zugangsdaten geheim zu halten.<br />
<br />
<br />
Standardwert: 0<br />
|-<br />
| style="vertical-align:top" | '''<code>$param->{method}</code>'''<br />
<br />
''optional''<br />
|| Die HTTP-Methode, welche zur Abfrage verwendet werden soll. Sofern keine Daten übertragen werden ist dies standardmäßig "GET", ansonsten "POST". Es können aber auch andere Methoden verwendet werden.<br />
<br />
<br />
Standardwert: "GET"<br />
|-<br />
| style="vertical-align:top" | '''<code>$param->{header}</code>'''<br />
<br />
''optional''<br />
|| Eigene HTTP-Header-Zeilen können über diesen Parameter eingebracht werden. Er kann dazu genutzt werden um z.B. den Content-Type festzulegen, oder einfach nur zusätzliche Header-Felder zu setzen. Mehrere Header-Zeilen müssen dabei mit "\r\n" getrennt werden.<br />
<br />
<br />
Beispiel:<br />
* <code>User-Agent: Mozilla/1.22'''<u>\r\n</u>'''Content-Type: application/xml</code><br />
* <code>Content-Type: application/xml</code><br />
<br />
<br />
Standardwert: ''[leer]''<br />
|-<br />
| style="vertical-align:top" | '''<code>$param->{httpversion}</code>'''<br />
<br />
''optional''<br />
|| Die HTTP-Version, welche zur Abfrage verwendet werden soll. Standardmäßig werden alle Abfragen mit HTTP/1.0 durchgeführt. Falls es jedoch notwendig ist HTTP/1.1 zu verwenden, so sollte <code>$param->{httpversion}</code> auf "1.1" gesetzt werden. Bei Version 1.1 wird automatisch der Header "<code>Connection: close</code>" implizit mitgesendet.<br />
<br />
<br />
Standardwert: "1.0"<br />
|}<br />
<br />
<br />
Als Rückgabewert von HttpUtils_BlockingGet wird ein Array mit 2 Rückgabewerten zurückgegeben:<br />
<br />
($err, $data) = HttpUtils_BlockingGet( … )<br />
<br />
Diese 2 Rückgabewerten haben folgende Bedeutung:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Rückgabewert !! Bedeutung<br />
|-<br />
| style="vertical-align:top" | '''<code>$err</code>'''|| Falls beim Aufruf der URL ein Fehler aufgetreten ist (z.B. Server nicht erreichbar oder Verbindungstimeout), dann ist dieser Wert mit einer Fehlermeldung gefüllt. <br />
<br />
<br />
Wenn kein Fehler aufgetreten ist, ist dieser Wert mit einem Leerstring gefüllt (<code>$err = ""</code>)<br />
|-<br />
| style="vertical-align:top" | '''<code>$data</code>'''|| Die Ergebnisdaten, welche der HTTP-Server zurückgeliefert hat. Die Daten werden als Klartext in Form eines gesamten Strings zurückgegeben.<br />
<br />
<br />
Falls ein Fehler aufgetreten ist, ist dieser Wert mit einem Leersting gefüllt (<code>$data = ""</code>)<br />
|}<br />
<br />
=== HttpUtils_NonblockingGet ===<br />
{{Randnotiz|RNText=Die Funktion HttpUtils_NonblockingGet ist nicht komplett durchgehend "non-blocking". DNS-Abfragen sind nachwievor blockierend. Insbesondere wenn der DNS-Name nicht aufgelöst werden kann.}}<br />
Diese Funktion arbeitet ähnlich wie HttpUtils_BlockingGet. Allerdings wird das Ergebnis nicht als Funktionsergebnis zurückgegeben. Die Funktion HttpUtils_NonblockingGet initiiert den Verbindungsaufbau und übergibt alles weitere an FHEM interne Routinen. Sobald eine Antwort vom HTTP-Server eintrifft, wird eine Callback-Funktion mit verschiedenen Parametern (unter anderem auch das Ergebnis) aufgerufen, um die Antwort entgegenzunehmen und weiter zu verarbeiten.<br />
<br />
<br />
Der Aufruf ist daher ähnlich zu HttpUtils_BlockingGet mit nur einem Parameter-Hash:<br />
<br />
'''Aufruf: <code>HttpUtils_NonblockingGet($param)</code>'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:175px" | Parameter !! style="width:auto" | Bedeutung<br />
|-<br />
| colspan="2" style="text-align:center" | '''''<br>Alle Hash-Parameter, welche für HttpUtils_BlockingGet gelten, sind auch für HttpUtils_NonblockingGet gültig'''''<br><br><br />
|-<br />
| style="vertical-align:top" | '''<code>$param->{callback}</code>''' <br />
<br />
''mandatory''<br />
|| Eine Funktion (oder eine Referenz auf eine Funktion), welche die Ergebnisdaten entgegennimmt und die Antwort entsprechend weiterverarbeitet. Die Callback-Funktion muss dabei 3 Parameter erwarten. Die Funktionsparameter der Callback-Funktion werden im nachfolgenden Abschnitt näher erläutert.<br />
<br />
<br />
Beispiel: <br />
* <code>$param->{callback} = \&MyCallbackFn</code> — ''(Referenzzeiger auf Funktionsname)''<br />
* <code>$param->{callback} = sub($$$){ … }</code> — ''(direkte Funktionsdefinition)''<br />
|-<br />
| style="vertical-align:top" | ''Benutzerdefinierte Parameter'' <br />
|| Es können im Hash weitere benutzerdefinierte Parameter gesetzt werden, welche evtl. in der Callback-Funktion benötigt werden, um die Antwort korrekt zu verarbeiten.<br />
<br />
Zum Beispiel bei der Modul-Programmierung währe das $hash des aktuellen Devices. Alle gesetzten Parameter sind in der Callback-Funktion direkt abrufbar und können ausgewertet werden.<br />
<br />
<br />
Beispiel: <br />
* <code>$param->{hash} = $hash</code><br />
* <code>$param->{command} = "on"</code><br />
<br />
|} <br />
<br />
<br />
Ein Funktionsrückgabewert von HttpUtils_NonblockingGet existiert nicht, da die eigentliche Rückgabe der Daten über die Callback-Funktion erfolgt. Die Callback-Funktion wird aufgerufen, sobdald der HTTP-Request abgeschlossen ist, oder ein Fehler aufgetreten ist. Der Funktionsaufruf erfolgt mit den folgenden Parametern:<br />
<br />
<code> ''MyCallbackFn'' ( $param, $err, $data )</code><br />
<br />
<br />
Diese 3 Parameter haben dabei folgende Bedeutung:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Parameter !! Bedeutung<br />
|-<br />
| style="vertical-align:top" | '''<code>$param</code>''' || Der Parameter-Hash, mit allen Argumenten die beim Aufruf der Funktion übergeben worden sind.<br />
<br />
Es ist möglich, dass der Parameter-Hash nach erfolgter Abfrage zusätzliche oder veränderte Elemente enthält:<br />
* '''<code>$param->{redirects}</code>''' - Die Anzahl an Umleitungen die erfolgte, bis die Anfrage beantwortet wurde.<br />
* '''<code>$param->{url}</code>''' - Die URL, die nach erfolgter Umleitung die Anfrage beantwortet hat.<br />
* '''<code>$param->{protocol}</code>''' - Das verwendete Protokoll, welches zur Abfrage verwendet wurde ("http" oder "https").<br />
* '''<code>$param->{path}</code>''' - Der Pfad, welcher auf dem HTTP-Server angefragt wurde.<br />
* '''<code>$param->{host}</code>''' - Der Name oder die IP-Adresse des HTTP-Servers.<br />
* '''<code>$param->{code}</code>''' - Der HTTP-Statuscode, mit dem die Anfrage vom Server beantwortet wurde.<br />
* '''<code>$param->{addr}</code>''' - Die HTTP-URL ohne Pfad und evtl. Authentifizerungsinformationen des HTTP-Servers (z.B. "<nowiki>http://myserver.com:8080</nowiki>").<br />
* '''<code>$param->{auth}</code>''' - Der Authentifizierungs-String, welcher verwendet wurde um sich gegenüber dem HTTP-Server zu authentifizieren (nur wenn Authentifizierung benutzt wurde).<br />
|-<br />
| style="vertical-align:top" | '''<code>$err</code>'''|| Falls beim Aufruf der URL ein Fehler aufgetreten ist (z.B. Server nicht erreichbar oder Verbindungstimeout), dann ist dieser Wert mit einer Fehlermeldung gefüllt. <br />
<br />
<br />
Wenn kein Fehler aufgetreten ist, ist dieser Wert mit einem Leerstring gefüllt (<code>$err = ""</code>)<br />
|-<br />
| style="vertical-align:top" | '''<code>$data</code>'''|| Die Ergebnisdaten, welche der HTTP-Server zurückgeliefert hat. Die Daten werden als Klartext in Form eines gesamten Strings zurückgegeben. Es handelt sich hierbei ausschließlich um den HTTP-Body. <br />
<br />
<br />
Falls ein Fehler aufgetreten ist, ist dieser Wert mit einem Leersting gefüllt (<code>$data = ""</code>)<br />
|}<br />
<br />
Die Callback-Funktion kann nun die Daten aus der HTTP-Antwort verarbeiten oder bei Fehler entsprechende Log-Meldungen ausgeben.<br />
<br />
<br />
==== Programmierbeispiel für HttpUtils_NonblockingGet() ====<br />
<br />
Das folgende Beispiel soll eine Hilfestellung für eigene Anwendungen geben<br />
<br />
<pre>use HttpUtils;<br />
sub X_GetHttpResponse($)<br />
{<br />
my ($hash, $def) = @_;<br />
my $name = $hash->{NAME};<br />
my $param = {<br />
url => "http://www.foo.de",<br />
timeout => 5,<br />
hash => $hash, # Muss gesetzt werden, damit die Callback funktion wieder $hash hat<br />
method => "GET", # Lesen von Inhalten<br />
header => "agent: TeleHeater/2.2.3\r\nUser-Agent: TeleHeater/2.2.3\r\nAccept: application/json", # Den Header gemäss abzufragender Daten ändern<br />
callback => \&X_ParseHttpResponse # Diese Funktion soll das Ergebnis dieser HTTP Anfrage bearbeiten<br />
};<br />
<br />
HttpUtils_NonblockingGet($param); # Starten der HTTP Abfrage. Es gibt keinen Return-Code. <br />
<br />
}<br />
<br />
<br />
sub X_ParseHttpResponse($)<br />
{<br />
<br />
my ($param, $err, $data) = @_;<br />
my $hash = $param->{hash};<br />
my $name = $hash->{NAME};<br />
<br />
if($err ne "") # wenn ein Fehler bei der HTTP Abfrage aufgetreten ist<br />
{<br />
Log3 $name, 3, "error while requesting ".$param->{url}." - $err"; # Eintrag fürs Log<br />
readingsSingleUpdate($hash, "fullResponse", "ERROR"); # Readings erzeugen<br />
}<br />
<br />
elsif($data ne "") # wenn die Abfrage erfolgreich war ($data enthält die Ergebnisdaten des HTTP Aufrufes)<br />
{<br />
Log3 $name, 3, "url ".$param->{url}." returned: $data"; # Eintrag fürs Log<br />
<br />
# An dieser Stelle die Antwort parsen / verarbeiten mit $data<br />
<br />
readingsSingleUpdate($hash, "fullResponse", $data); # Readings erzeugen<br />
}<br />
<br />
# Damit ist die Abfrage zuende.<br />
# Evtl. einen InternalTimer neu schedulen<br />
}</pre><br />
<br />
<br />
[[Kategorie:Development]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Garagentorsteuerung&diff=8543Garagentorsteuerung2014-11-20T21:09:54Z<p>BerndArnold: Rechtschreibkorrekturen; Code-Formatierung /* Erläuterungen: */</p>
<hr />
<div>{{Randnotiz|RNTyp=y|RNText=Die in dieser Anleitung enthaltenen Code-Beispiele sind für die Eingabe in der fhem.cfg formatiert und sind (z.B. bei Benutzung in der Weboberfäche) ggf. [[Konfiguration|umzuformatieren]].}}<br />
Viele (Garagen)torantriebe haben keine seperaten Schalter für "Schliessen" und "Öffnen", sondern nur einen Taster, der das Tor schliesst wenn es offen ist und öffnet, wenn es geschlossen ist. Dies hat mehrere Nachteile:<br />
* Man kann das Tor nur korrekt bedienen, wenn man es sehen kann, bzw den Zustand kennt. Aber:<br />
* Fhem (und damit die Weboberfläche) hat keine Möglichkeit anhand des Zustandes des Aktors zu erkennen, ob das Tor zu oder auf ist.<br />
<br />
Damit ist eine zuverlässige echte "Fernbedienung" des Tores nicht möglich, man kann das Tor also wenn man nach Hause kommt nicht schon vorab öffnen, ebenso kann man nicht z.B. nachts prüfen, ob vergessen wurde es zu zu machen und es ggf. automatisch schliessen. Die folgende Schaltung versucht beide Probleme zu umgehen.<br />
<br />
== Aufgabe: ==<br />
Es soll ein Garagentor oder Einfahrtstor geschaltet werden. Die toreigene Steuerung kennt keinen absoluten Zustand, das Betätigen eines Tasters öffnet das Tor, wenn es zu ist und schliesst es, wenn es offen ist. Mit FHEM soll die Möglichkeit geschaffen werden, das Tor in einen definierten Zustand zu bringen. Der Garagentormotor ist so konstruiert, dass ein kurzer Druck des Tasters ausreicht um den Schliess- Öffenvorgang auszulösen, der Taster muss nicht gehalten werden bis das Tor auf oder zu ist. Das Tor soll über Schaltflächen auf der Weboberfläche von FHEM betätigt werden.<br />
<br />
== Voraussetzungen: ==<br />
Ein Tür/Fensterkontakt, der prüft, ob das Tor auf oder zu ist.<br />
<br />
Im konkreten Fall sei ein [[FHT80TF]] eingesetzt. <br />
<br />
Dieser ist zu definieren:<br />
<nowiki>define Einfahrt CUL_FHTTK 3b8823<br />
attr Einfahrt room Aussen</nowiki><br />
Ausserdem muss der Schaltaktor definiert werden, der auf Funkbefehl den Taster des Garagentormotors betätigt (im konkreten Fall wurde ein [[FS20 AS1 1-Kanal Funk Aufputzschalter|FS20 AS1]] eingesetzt, da galvanische Trennung des Schaltstromkreises notwendig ist).<br />
<br />
Die folgenden Beispiele gehen davon aus, dass der Aktor "on-for-timer" beherrscht, dies ist bei FS20 und HomeMatic Aktoren der Fall, nicht aber z.B. bei InterTechno Aktoren. <br />
<br />
<nowiki>#------EinfahrtsTor---------------<br />
define tor_sw FS20 11114444 23<br />
attr tor_sw follow-on-for-timer 1</nowiki><br />
==== Erläuterungen: ====<br />
* define tor_sw FS20 11114444 23<br />
<br />
Der Name "tor_sw" ist frei vergeben und könnte auch z.b. "Garagentor_Schalter" heissen. Der Hauscode der Installation ist 11114444, der Schaltaktor hat die Adresse 23. Dies ist der hexadezimale Wert, der der ELV-Notation 1314 entspricht.<br />
<br />
* attr tor_sw follow-on-for-timer 1<br />
<br />
Weiter unten werden wir für den Aktor "tor_sw FS20 11114444 23" einen Timer definieren, also dafür sorgen, dass er für nur eine Sekunde auf ON geschaltet wird. Dies soll die Betätigung des Taster simulieren. Die Anzeige auf dem Webinterface zeigt immer den letzten Schaltzustand. Im Falle eines Timers wäre dieser nach Betätigung "on for timer 1", man könnte am Webinterface also nicht erkennen, ob der FS20 Schalter aktuell aus oder an ist.<br />
<br />
"follow-on-for-timer 1" sorgt nun dafür, dass die Anzeige im Webinterface nach Ende des Timers wieder korrekt auf "off" geht. Dies ist für die eigentliche Funktion unerheblich und dient nur einer besseren Visualisierung des Schaltzustandes im Webinterface. Besonders interessant kann dieses Attribut bei Schaltungen sein, die länger als nur ein paar Sekunden dauern.<br />
<br />
Zuletzt müssen Aktionen definiert werden, die als Schalter auf der Weboberfläche von FHEM dienen, bzw. mit einer Fernbedienung ausgelöst werden können.<br />
<br />
<nowiki>define Einfahrt_ZU FS20 11114444 de<br />
attr Einfahrt_ZU dummy 1<br />
attr Einfahrt_ZU room Aussen<br />
define Einfahrt_AUF FS20 11114444 da<br />
attr Einfahrt_AUF dummy 1<br />
attr Einfahrt_AUF room Aussen</nowiki><br />
<br />
==== Erläuterungen: ====<br />
* define Einfahrt_ZU FS20 11114444 de<br />
<br />
Der Name "Einfahrt_ZU" ist frei vergeben und könnte auch z.b. "Garagentor_Schliessen" heissen. Der Hauscode der Installation ist 11114444, die Aktion hat die Adresse "de". Diese Adresse ermöglicht es, die Aktion mittels einer auf diese Adresse programmierten Fernbedienung auszulösen. "de" ist der hexadezimale Wert, der der ELV-Notation 4243 entspricht. <br />
<br />
* attr Einfahrt_AUF room Aussen<br />
<br />
Ordnet die Schalter auf der Weboberfläche dem Raum "Aussen" zu, dieser könnte auch beliebig anders heissen, er dient nur der Übersichtlichkeit.<br />
<br />
* dummy bewirkt, dass beim Betätigen des Schalters auf der Weboberfläche kein Funksignal gesendet wird. Dies ist nicht erwünscht, da "Einfahrt_ZU" erst im folgenden die eigentlichen Aktionen auslöst.<br />
<br />
== Script ==<br />
Es gibt zwei verschiedene Aktionen. Ziel ist es, dass das Einschalten von "Einfahrt_AUF" den Taster des Tores nur betätigt, wenn es zu ist, aber nichts tut, wenn das Tor schon offen ist (respektive "Einfahrt_ZU" entsprechend umgekehrt).<br />
<br />
Dazu dienen die folgenden Teile der Konfiguration, die die Aktionen unter bestimmten Bedingungen mit dem definierten Aktor "tor_sw FS20 11114444 23" verbinden:<br />
<br />
<pre><br />
#------Einfahrtstor ZU, wenn es noch auf ist--------<br />
define act_on_Einfahrt_ZU notify Einfahrt_ZU { if (Value("Einfahrt") eq "Open" && "%" ne "off") { fhem("set tor_sw off ;; set tor_sw on-for-timer 1 ;; setstate Einfahrt_AUF off") } }<br />
</pre><br />
<br />
<pre><br />
#------Einfahrtor auf, wenn es noch zu ist--------<br />
define act_on_Einfahrt_AUF notify Einfahrt_AUF { if (Value("Einfahrt") eq "Closed" && "%" ne "off") { fhem("set tor_sw off ;; set tor_sw on-for-timer 1 ;; setstate Einfahrt_ZU off") } }<br />
</pre><br />
<br />
==== Erläuterungen (exemplarisch Einfahrt_ZU, Einfahrt_AUF funktioniert analog): ====<br />
* act_on_Einfahrt_ZU<br />
<br />
Ist nur der Name der anschliessend definierten Aktion. Er könnte auch "MyName77" oder "Blubber" heissen. Es ist aber sicher sinnvoll, einen selbsterklärenden Namen zu wählen.<br />
<br />
* notify Einfahrt_ZU<br />
<br />
Es passiert erst etwas, wenn "Einfahrt_ZU" betätigt wird, also auf Weboberfläche oder Fernbedienung mit passender Adresse eine Taste gedrückt wird (zur Beachtung: Auch ein Drücken der OFF Taste von "Einfahrt_ZU" auf der Weboberfläche oder entsprechend der linken Taste des Tastenpaares einer Fernbedienung ist eine Betätigung!).<br />
<br />
* {<br />
<br />
Alles was jetzt folgt ist eine PERL Expression (PERL Expressions werden in geschweifte Klammern eingefasst.)<br />
<br />
* if (Value("Einfahrt") eq "Open" && "%" ne "off") <br />
<br />
Falls der Wert von "Einfahrt" (mithin der Zustand des am Anfang definierten Türkontakts FHT80TF) gleich ("eg" = equal) "Open" ist (der FHT80TF kennt die beiden Werte Open und Closed) und zugleich die gedrückte Taste von "Einfahrt_ZU" nicht gleich ("ne" = Not equal) "off" (also "on") ist, dann mache folgendes...<br />
Dieser Teil dient dazu, zwei Dinge abzufragen: <br />
<br />
1. Ist das Tor überhaupt offen? Durch Abfrage des durch den Türkontakt gemeldeten Zustandes wird dies festgestellt.<br />
<br />
2. Wurde die "on" Taste auf dem Webinterface (entsprechend der rechten Taste auf der zugeordneten Fernbedienung) betätigt? Dies wurde durch Abfragen der Variablen "%" erledigt. Diese enthält den Wert der zuletzt betätigten Taste der definierten Aktion. Diese Bedingung ist für die Funktion nicht zwingend. Sie soll nur verhindern, dass die Aktion auch dann gestartet wird, wenn die OFF Taste gedrückt wurde, was vielleicht nicht den Erwartungen des Benutzers entspricht.<br />
<br />
Die Form "not equal off" klingt zunächst wie ein etwas komplizierter Weg von "equal on". Diese beiden Abfragen sind aber nicht identisch, da FS20 Dim-Befehle kennt.<br />
Wenn man die Taste einer Fernbedienung versehentlich länger als 0,4 Sekunden betätigt, wir statt eines ON Befehls ein Dim-Befehl gesendet. Wird nun auf Tastendruck "on" geprüft, wird in diesem Falle die Aktion nicht ausgeführt, obwohl der Nutzer die richtige Taste drückte. Der Dim-Befehl hat für eine Garagentorsteuerung keine Bedeutung, wenn er gesendet wird kann das eigentlich nur heissen, dass der Nutzer versehentlich zu lange gedrückt hat. Dass die Aktion nicht ausgeführt wird, weil der Nutzer die richtige Taste (nur) zu lange gedrückt gehalten hat, entspricht aber nicht den Erwartungen des normalen Nutzers. Es ist daher besser, darauf zu testen, dass der Nutzer nicht die falsche Taste gedrückt hat. <br />
<br />
Nur wenn beide Bedingungen zutreffen, also das Garagentor offen ist und die richtige Taste (in beliebieger Länge) gedrückt wurde, werden die nachfolgenden Aktionen ausgeführt:<br />
<br />
* { fhem("set tor_sw off ;; set tor_sw on-for-timer 1 ;; setstate Einfahrt_AUF off") } }<br />
<br />
FHEM soll nacheinander ausführen:<br />
<br />
* set tor_sw off<br />
<br />
tor_sw auschalten. Dies ist streng genommen nicht erforderlich, da tor_sw nach Ende der Aktion immer auf OFF stehen sollte. Sollte allerdings aus irgendeinem Grund tor_sw doch auf ON stehen, hat das nachfolgende kurze Einschalten zur Simulation eines Tastendrucks am Garagentor keine Wirkung. Das vorherige Ausschalten erhöht also die Zuverlässigkeit der Aktion und fängt fehlerhafte oder unklare Zustände und Störungen ab.<br />
<br />
* set tor_sw on-for-timer 1<br />
<br />
der Aktor tor_sw soll für eine Sekunde einschalten und dann wieder auschalten. Dies simuliert einen kurzen Tastendruck.<br />
<br />
* setstate Einfahrt_AUF off<br />
<br />
Im ganzen "Einfahrt_ZU" Skript wird "Einfahrt_ZU" zwar unter bestimten Bedingungen eingeschaltet (und damit die oben beschriebene Aktionen ausgeführt) aber nie AUSgeschaltet. Das Script steht also im Webinterface auch nach Ausführung der Aktionen auf ON. Dies hat den Sinn, dass man am Webinterface am Schaltzustand des Scriptes den Zustand des Garagentors erkennen kann. Die Zustandsanzeige von "Einfahrt_ZU" (dargestellt durch eine kleine Glühbirne) leuchtet, wenn das Skript abgelaufen und das Tor somit zu ist. Analog leuchtet die Anzeige des Scripts "Einfahrt_AUF" wenn das Tor zuletzt geöffnet wurde. Damit nicht nach jeweils einer Betätigung beide Scripte im Webinterface beide Glühbirnen leuchten, schalten die Scripte sich gegenseitig aus. "setstate Einfahrt_AUF off" dient also dazu, nachdem das Tor geschlossen wurde, die Anzeige von "Einfahrt_AUF" auszuschalten. Dies ist eine rein optische Massnahme: Der Schaltzustand von "Einfahrt_AUF" und "Einfahrt_ZU" gibt nur die letzte Betätigung wieder, nicht den tatsächlichen Zustand des Tores. In der Praxis stimmt dies aber überein. Wenn jedoch z.B. jemand das Tor manuell öffnet, stimmt die Anzeige nicht mehr. Um eine tatsächliche Ausführung der Scripte zu vermeiden, wird das Kommando "setstate" verwendet, das nur den Status ändert, aber nicht ein tatsächliches "set" auslöst.<br />
<br />
== Vorteile der besprochenen Konfiguration ==<br />
* das Tor kann mit Weboberfläche und Fernbedienung eindeutig auf oder zu gemacht werden, obwohl der Torantrieb selber nur toggelt.<br />
* der Zustand des Tores muss nicht bekannt sein. Wenn man das Tor öffnen will, genügt es, auf Einfahrt_AUF zu drücken. Wenn das Tor schon auf ist, passiert nichts, ansonsten wird es geöffnet.<br />
* Manuelle Eingriffe am Garagentor selbst behindern die Schaltung nicht.<br />
* der Zustand des Tores lässt sich in der Regel am Schaltzustand der Aktionen im Webinterface feststellen. Dadurch ist es nicht zwingend erforderlich, den Türkontakt dem selben Raum zuzuordnen (obwohl es in diesem Beispiel so gemacht wurde)<br />
* Fehlbedienungen an der Fernbedienung (falsche Taste, zu lange gedrückt) werden abgefangen (dies ist insbesondere ein Vorteil gegenüber der Lösung, mit einer Fernbedienung den FS20 Aktor direkt anzusprechen, in dem ein Timer programmiert wurde. Das Auslösen des Dim-Befehles deaktiviert nämlich FS20 Timer).<br />
<br />
== Nachteile der besprochenen Konfiguration ==<br />
* der Einsatz des [[FHT80TF]], der den Zustand nur mit einer gewissen Verzögerung meldet.<br />
* belegt zwei Adressen und damit zwei Tastenpaare auf einer Fernbedienung. Ein Umschreiben auf ein Tastenpaar wäre aber möglich. Die Nutzung von zwei Schaltern auf der Weboberfläche hat sich bei der Bedienung mit (kleinem) Smartphonedisplay als vorteilhafter herausgestellt.<br />
* funktioniert wegen der Verwendung von "on-for-timer" nur bei Aktoren, die dies auch unterstützen, dies ist bei FS20 und HomeMatic der Fall, sonst umschreiben notwendig.<br />
<br />
== Anmerkungen: ==<br />
* Es wird hier nicht das Fhem-IF benutzt sondern das ältere Perl if. An der eigentlichen Logik ändert dies nichts.<br />
* Die Lebensdauer der Batterie des FHT80TF stellt kein Problem dar. Standzeiten von bis zu 7 Jahren sind trotz Ausseneinsatz keine Seltenheit, das Gerät muss z.B. durch einschweissen in Plastikfolie gut gegen Wasser geschützt sein.<br />
* die Zuverlässigkeit der Webanzeige kann noch erhöht werden, wenn in regelmässigen Intervallen der Zustand des Tors geprüft wird und die Schalter im Webinterface mit setstate angepasst werden (der gezeigte Befehl muss ohne Zeilenumbruch so in die [[Konfiguration|fhem.cfg]] eingetragen werden):<br />
:<code>define Torchecker at +*00:30:00 { if (Value("Einfahrt") eq "Closed") { fhem("setstate Einfahrt_AUF off ;; setstate Einfahrt_ZU on")} else { fhem ("setstate Einfahrt_ZU off ;; setstate Einfahrt_AUF on") } }</code><br />
:Das garantiert, dass die Schalter am Webinterface den Zustand auch dann korrekt wiedergeben, wenn das Tor anders als über Fhem betätigt wurde.<br />
<br />
[[Kategorie:Code Snippets]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=Pushbullet&diff=8542Pushbullet2014-11-20T17:48:02Z<p>BerndArnold: Stil, Rechtschreibung verbessert; Weblink korrigiert</p>
<hr />
<div>'''Pushbullet''' ist ein Dienst, um Benachrichtigungen an unterschiedliche Endgeräte zu senden. Pushbullet stellt Apps für iPhone, Android, Windows (Beta), Mac OS X (bald erhältlich) sowie Plugins für Chrome und Firefox an. Eine genaue Liste kann [http://www.pushbullet.com/apps hier] eingesehen werden. Der Dienst sowie die Apps sind kostenlos. <br />
{{Infobox Modul<br />
|ModPurpose=Senden von Push-Nachrichten an unterschiedliche Endgeräte<br />
|ModType=x<br />
|ModForumArea=Unterstützende Dienste<br />
|ModTechName=70_Pushbullet.pm (noch nicht eingecheckt)<br />
|ModOwner=fhainz<br />
}} <br />
<br />
<br />
==Installation==<br />
<br />
Zur Benutzung von Pushbullet ist ein Google Account zwingend notwenig. Falls noch kein Google Account vorhanden ist kann man diesen [https://accounts.google.com/SignUp hier einrichten]. Anschließend kann man sich auf [http://pushbullet.com pushbullet.com] mit den Google Benutzerdaten einloggen. Den benötigten accessToken findet man in den Account Settings (rechts oben auf das Benutzer-Symbol klicken). <br />
Auf dem gewünschten Endgerät muss nur noch der entsprechende Client installiert werden.<br />
<br />
===Offizielle Clients===<br />
<br />
'''Smartphones'''<br />
*Apple iOS: [https://itunes.apple.com/us/app/pushbullet/id810352052 Pushbullet App]<br />
*Android: [https://play.google.com/store/apps/details?id=com.pushbullet.android&hl=de Pushbullet App]<br />
<br />
'''Browser-Erweiterungen'''<br />
*Firefox: [https://addons.mozilla.org/de/firefox/addon/pushbullet Pushbullet Plugin]<br />
*Chrome: [https://chrome.google.com/webstore/detail/pushbullet/chlffgpmiacpedhhbkiomidkjlcfhogd Pushbullet Plugin]<br />
*Opera: [https://addons.opera.com/en/extensions/details/pushbullet/ Pushbullet Plugin]<br />
<br />
'''Betriebssystem-Erweiterungen'''<br />
*Windows: [https://update.pushbullet.com/pb_install.exe Pushbullet App]<br />
<br />
===Clients durch die Community===<br />
*Blackberry: [http://appworld.blackberry.com/webstore/content/58534486/?countrycode=de&lang=de BlackBullet]<br />
*Windows Phone: [http://www.windowsphone.com/en-us/store/app/pushpin/b6764b31-9f2a-4ba4-9e00-aba343928459 PushPin]<br />
*Ubuntu: [http://www.atareao.es/tag/pushbullet-indicator/ PB Indicator]<br />
<br />
Übersicht aller Clients: [https://www.pushbullet.com/apps]<br />
<br />
==Einbinden des Dienstes in Fhem==<br />
<br />
Das Modul wird mit dem folgenden Befehl in fhem definiert:<br />
<br />
define <name> Pushbullet <accessToken><br />
<br />
<br />
==Push Benachrichtigung senden==<br />
<br />
===Nachricht===<br />
<br />
Nachricht ohne Titel oder Gerät:<br />
set <name> message Das ist eine Nachricht<br />
<br />
Nachricht mit Titel ohne Gerät:<br />
set <name> message Das ist eine Nachricht | Ein Titel<br />
<br />
Nachricht mit Titel an Gerät iPhone:<br />
set <name> message Das ist eine Nachricht | Ein Titel | iPhone<br />
<br />
Nachricht mit Titel an Kontakt Max Mustermann<br />
set <name> message Das ist eine Nachricht | Ein Titel | Max Mustermann<br />
<br />
Wenn kein Titel angegeben wird tritt das Attribut defaultTitel in Kraft. Falls dies nicht gesetzt ist wird der Titel auf FHEM gesetzt.<br />
Wenn kein Device angeben wird tritt das Attribut defaultDevice in Kraft. Falls dies nicht gesetzt ist geht der Push an alle '''deine''' Devices. Kontakte erhalten die Benachrichtigung '''nicht!'''<br />
<br />
===Link===<br />
Der Inhalt des Links wird in der App direkt angezeigt. Ein Webcam Foto kann somit mit einem Touch direkt am Endgerät angezeigt werden.<br />
<br />
Link ohne Titel oder Gerät:<br />
set <name> link http://google.com<br />
<br />
Link mit Titel ohne Gerät:<br />
set <name> link http://google.com | Google<br />
<br />
Link mit Titel an Gerät iPhone<br />
set <name> link http://google.com | Google | iPhone<br />
<br />
Link mit Titel an Kontakt Max Mustermann<br />
set <name> link http://google.com | Google | MaxMustermann<br />
<br />
*Wenn kein Titel angegeben wird tritt das Attribut defaultTitel in Kraft. Falls dies nicht gesetzt ist wird der Titel auf FHEM gesetzt.<br />
*Wenn kein Device angeben wird tritt das Attribut defaultDevice in Kraft. Falls dies nicht gesetzt ist geht der Push an alle '''deine''' Devices. Kontakte erhalten die Benachrichtigung '''nicht!'''<br />
<br />
===Liste===<br />
<br />
Liste ohne Titel oder Gerät:<br />
set <name> list Milch, Brot, Zucker<br />
<br />
Liste mit Titel ohne Gerät:<br />
set <name> list Milch, Brot, Zucker | Einkaufsliste<br />
<br />
Liste mit Titel an Gerät iPhone<br />
set <name> list Milch, Brot, Zucker | Einkaufsliste | iPhone<br />
<br />
Liste mit Titel an Kontakt Max Mustermann<br />
set <name> list Milch, Brot, Zucker | Einkaufsliste | MaxMustermann<br />
<br />
*Wenn kein Titel angegeben wird tritt das Attribut defaultTitel in Kraft. Falls dies nicht gesetzt ist wird der Titel auf FHEM gesetzt.<br />
*Wenn kein Device angeben wird tritt das Attribut defaultDevice in Kraft. Falls dies nicht gesetzt ist geht der Push an alle '''deine''' Devices. Kontakte erhalten die Benachrichtigung '''nicht!'''<br />
<br />
<br />
==Kontakt hinzufügen==<br />
Mit<br />
set <name> contactAdd <Name> | <email><br />
wird eine neuer Kontakt hinzugefügt. Dieser bekommt erstmal eine E-Mail mit einer Einladung zur Pushbullet App. Fall die App nicht installiert wird, bekommt der Kontakt Push-Benachrichtigungen als E-Mail zugestellt.<br />
<br />
<br />
==Gerät / Kontakt umbenennen==<br />
Mit<br />
set <name> deviceRename <alterName> | <neuerName><br />
wird ein Gerät oder Kontakt umbenannt.<br />
<br />
<br />
==Gerät / Kontakt löschen==<br />
Mit<br />
set <name> deviceDelete <name><br />
wird ein Gerät oder Kontakt gelöscht.<br />
<br />
==Geräte / Kontakte neu einlesen==<br />
Mit<br />
get <name> devices<br />
kann man die Device Liste von pushbullet.com neu einlesen.<br />
<br />
<br />
==Pushbullet Website==<br />
Die Pushbullet Website bietet umfangreiche Möglichkeiten die gesendeten Push Nachrichten, Geräte und Kontakte zu verwalten. Weiters kann man auch Nachrichten versenden und löschen.<br />
<br />
<br />
==Links==<br />
*Thread über das Modul im [http://forum.fhem.de/index.php/topic,25615.0.html FHEM-Forum]<br />
*Pushbullet [https://www.pushbullet.com/apps Apps]<br />
*Pushbullet [https://docs.pushbullet.com API]<br />
*Homepage: [http://pushbullet.com pushbullet.com]<br />
<br />
[[Kategorie: Gerätemodul | Code Snippets]]</div>BerndArnoldhttp://wiki.fhem.de/w/index.php?title=HM-Sen-MDIR-O_Funk-IR-Bewegungsmelder_au%C3%9Fen&diff=8528HM-Sen-MDIR-O Funk-IR-Bewegungsmelder außen2014-11-19T16:32:28Z<p>BerndArnold: Ebenen korrigiert (kein =); Event-Monitor-Auszug, CFG-Auszug, Weblink O-2 und Notify-Beispiel hinzugefügt</p>
<hr />
<div>'''HM-Sen-MDIR-O'''<br />
HomeMatic Funk-IR-Bewegungsmelder außen<br />
<br />
== Features ==<br />
PIR-Bewegungsmelder mit Helligkeitssensor zur Tag-/Nachtumschaltung.<br />
<br />
'''Technische Daten:'''<br />
* Erfassungswinkel: ca. 90°<br />
* Erfassungsbereich: ca. 9 m<br />
* Drehbar: 360°<br />
* Neigbar: 45°<br />
* Stromversorgung: 3 x 1,5 V Mignon/AA/LR6<br />
* Schutzart: IP 44<br />
<br />
== Hinweise zur Inbetriebnahme und Installation ==<br />
&lt;Bitte ergänzen&gt;<br />
<br />
== Probleme ==<br />
&lt;ggfls. ergänzen&gt;<br />
<br />
== Betrieb mit FHEM ==<br />
<br />
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Die Anlerntaste am Bewegungsmelder sollte hierzu nur kurz betätigt werden. Bei einer Betätigung von vier Sekunden wird der Melder nur bei Unterschreiten einer festgelegten Helligkeitsschwelle auslösen (weitere Informationen siehe Abschnitt ''Anlernen'' der Herstellerdokumentation).<br />
<br />
=== Event-Monitor ===<br />
<br />
In regelmäßigen Abständen werden die folgenden Daten vom Bewegungsmelder (hier: HM-Sen-MDIR-O-2) übermittelt:<br />
<pre><br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120<br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer cover: closed<br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer battery: ok<br />
</pre><br />
<br />
Wird Bewegung erkannt, wird Folgendes vom Gerät (hier: HM-Sen-MDIR-O-2) übermittelt:<br />
<pre><br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer trigDst_2573FB: noConfig<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion: on (to MyHMLAN)<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motionCount: 235_next:116s<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120<br />
</pre><br />
<br />
=== Log-Auszug ===<br />
<br />
&lt;Bitte ergänzen&gt;<br />
<br />
=== fhem.cfg ===<br />
<br />
Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt (Beispiel: HM-Sen-MDIR-O-2).<br />
<br />
<pre><br />
define HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer CUL_HM 2B033A<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer IODev MyHMLAN<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actCycle 000:10<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actStatus alive<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer autoReadReg 4_reqStatus<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer expert 2_full<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer firmware 1.6<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer model HM-Sen-MDIR-O-2<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer peerIDs 00000000,<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer room CUL_HM<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer serialNr LEQ0xxxxxx<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer subType motionDetector<br />
</pre><br />
<br />
=== Gerät bei Bewegung schalten ===<br />
<br />
Mit dem folgenden Notify kann z. B ein [[HM-LC-SW1-FM Schaltaktor 1-fach UP|Unterputz-Schaltaktor]] für die angegebene Zeit (in Sekunden) eingeschaltet werden - ein Peeren ist dazu vorher nicht erforderlich. Das Einschalten passiert in diesem Beispiel unabhängig von der Helligkeit.<br />
<br />
<pre><br />
define Notify_Bewegungsmelder_Haustuer notify HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer:motion set HM_LC_SW1_FM_298FB2_HaustuerLicht on-for-timer 300<br />
</pre><br />
<br />
== Links ==<br />
Manual: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/104108_HM-Sen-MDIR-O_V1.2_GE_eQ-3_20120510.pdf PDF HM-Sen-MDIR-O],<br />
[http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-Sen-MDIR-O-2_UM_GE_131024.pdf PDF HM-Sen-MDIR-O-2]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Lichtsensoren]]</div>BerndArnold