FHEMWiki - Benutzerbeiträge [de]

Trick der Woche

2026-01-18T23:33:41Z

Soulman: /* HomeMatic Heizungsregler Uhrzeit einstellen */

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== August 2025==
=== FTUI(3) Dateien direkt in FHEMWEB bearbeiten ===
Im Attribut editFileList der [https://fhem.de/commandref_modular.html#FHEMWEB FHEMWEB]-Definition '''zusätzlich zu den Default-Werten''' eintragen:
FTUI (www/tablet):$FW_dir.'/tablet':^.*html$
FTUI3 (www/ftui)<code>:$FW_dir.'/tablet':^.*\.(html|htm|js|css)$</code>

== August 2022==
=== Update ===
Wenn der Befehl "Update" nicht funktioniert und insbesondere die Fehlermeldung ''Bad hostname 'fhem.de:80''' zurück gibt, kann es sinnvoll sein, den Parameter -noSSL zu versuchen. Details dazu im Artikel [[Update]]

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

Die oben erwähnten "if" sind "perl if"s. Die Verwendung des FHEM Modul DOIF ist deutlich langsamer. Die Betrachtung betrifft sowieso nur langsame Host-Systeme mit gleichzeitig vielen defines. Bei Verwendung z.b. einen Raspberry Pi 4 oder schnellerem Host dürften die Unterschiede vernachlässigbar sein.

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzwingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt wird, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich Strom durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL1 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

Virtueller Controller VCCU

2026-01-07T22:17:35Z

Soulman: /* Einrichten */ etwas gestrafft

{{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie: Eine VCCU innerhalb FHEM ist nicht zu verwechseln mit einer virtualisierten CCU3! Für letztere gibt es eine eigene Modulfalmilie [[HMCCU]], hier geht es ausschließlich um Geräte des TYPE CUL_HM.}}Eine '''Virtuelle CCU''', auch '''VCCU''' genannt, ist eine Zentrale für [[HomeMatic]]-Geräte. Die VCCU tritt beim [[Pairing (HomeMatic)|Pairing]] an die Stelle des ''I/O-Devices'' (auch "Schnittstelle" genannt, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]).

HomeMatic-Geräte werden üblicherweise mit einer Zentrale gepaired, um sie zentral verwalten zu können. Der Pairing-Partner ist im einfachsten Fall das I/O-Device ([[CUL]], [[HM-CFG-LAN]], …) selbst. Nachteilig dabei ist, dass der Ausfall der Schnittstelle bewirkt, dass alle gepairten Geräte nicht mehr bedient werden können. Dies lässt sich im Gegensatz zu ungepairten Protokollen (z.b. FS20) auch nicht durch doppelte Definition mit abweichenden IO-Devices lösen, da das Pairing nur mit einer ''hmId'' erfolgen kann. Daher kann auch durch mehrere Schnittstellen / IOs keine Redundanz erreicht werden. Ähnliches gilt für eine Vergrößerung der Funkabdeckung durch mehrere Schnittstellen.

Dieses Problem kann durch eine VCCU gelöst werden. Die VCCU ist eine virtuelle Zentrale; sie tritt beim Pairing an die Stelle der Schnittstelle. Sie erhält eine eigene ''hmId'', mit der die HM Sensoren und Geräte gepaired werden. Die Funkschnittstelle(n) werden dann von der VCCU als reine "dumme" IOs verwaltet. Dieses bietet vielfältige Möglichkeiten, z.B. die Verwendung mehrerer IOs, aus denen die VCCU die "beste" nach diversen Kriterien (z.B. RSSI) auswählt. Dadurch kann sowohl die Redundanz als auch die Funkabdeckung erhöht werden.

Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:

* Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
* Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
* Die VCCU stellt virtuelle Kanäle zur Verfügung, mit denen HomeMatic-Geräte [[HomeMatic Peering Beispiele|gepeert]] werden können.
* "Geordnete" Termination von Nachrichten (da die üblichen Funkschnittstellen (wie CUL im HM-Mode oder HM-LAN-Konfigurator) relativ "dumm" sind, führen viele Zustände zu den bekannten "Help me" Einträgen im Log)

Der einzige Nachteil einer VCCU gegenüber dem direkten Pairing mit dem I/O-Device ist ein Mehraufwand bei der initialen Konfiguration vom FHEM.

== Kurzbeschreibung ==
Ein virtueller Controller '''VCCU''' ist der Protokoll-Endpunkt der Zentrale und ersetzt dabei logisch (jedoch nicht physikalisch) z.b. den [[HM-CFG-LAN LAN Konfigurations-Adapter]] einer "klassischen" FHEM Konfiguration

Es können einer VCCU einzelne oder mehrere IO Devices zugeordnet werden. Man bündelt dadurch mehrere I/O Devices (z.B. CULs und HM-CFG-LANs) zu einem ''Pool''. Den HM-Devices in FHEM (Aktoren, Sensoren) kann dann als I/O Device die ''VCCU'' zugeordnet werden, dies geschieht durch das Attribut ''IOgrp.''

Durch diese Gruppierung der I/O Devices und dem Zuordnen der VCCU zu einem Device entstehen verschieden Vorteile, abhängig des Einsatzes der VCCU. So kann ein beliebiges I/O Device im Device Pool der VCCU ausfallen und das oder die verbliebenden I/O Devices übernehmen diese Funktion (abhängig von der Funkreichweite/Erreichbarkeit). Die VCCU wird das nächst verfügbare I/O Device zum Senden/Empfangen verwenden.

Ein weiterer Vorteil ist, dass durch die VCCU auch das I/O Device genutzt werden kann, welches die beste Funkqualität aufweist. Dies kann z.B. bei beweglichen Sensoren/Aktoren (Fernbedienungen) sinnvoll sein, oder wenn die Funkqualität durch andere Faktoren beeinflusst wird (z.B. Tür/Tor oder andere "bewegliche" Störfaktoren)

== Mehrere VCCUs in einer Installation==
Theoretisch erlaubt FHEM die parallele Nutzung mehrerer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann bereits eine VCCU verschiedene I/O-Devices bedienen, zum Beispiel einen [[CUL]] ''und'' ein [[HM-CFG-LAN]].

Jede VCCUs muss eine eindeutige ''HomeMatic-ID'' haben, mit der HomeMatic-Geräte gepaired werden. Folglich kann jedes HomeMatic-Gerät nur mit ''einer'' VCCU gepaired werden.

Die VCCU überschreibt die hmid eines I/O Device mit seiner eignen, daher können nicht mehrere VCCUs dasselbe I/O Device verwenden.

== Definition der VCCU==
=== hmId wählen ===
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Bei Schnittstellen und Zentralen ist dies eine ''hmId''. Da die VCCU eine (virtuelle) Zentrale ist, muss sie auch mit einer ''hmId'' versehen werden. Dies geschieht per define analog zur Anlage einer physischen Schnittstelle (siehe weiter unten)

Eine VCCU gibt die ''hmId'' an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. Damit haben alle von einer VCCU genutzten I/Os nach der Zuweisung dieselbe ''hmId''.

* Definiert man eine VCCU nachdem IOs für HomeMatic angelegt und in Verwendung sind, sollte man die ''hmId'' der bereits vorhandenen Funkschnittstelle verwenden, hierdurch kann man sich das Neupairen der HM Devices ersparen.
* Hat man bereits mehrere Funkschnittstellen im Einsatz, werden diese unterschiedliche ''hmIds'' haben, zumindest eine Schnittstelle wird nach der Zuweisung zur VCCU seine ''hmId'' also ändern.
* Für mit dieser Schnittstelle schon gepairte Devices ist ein Neupairen unumgänglich.

Außerdem muss in jedem Fall das attr IOgrp eines vor Anlage der VCCU gepairten Gerätes auf die VCCU angelegt/geändert werden., z.B. so
attr <device> IOgrp <Name der vccu>
(Siehe weiter unten ein Tipp, wie dies leicht nachträglich erledigt werden kann)

Mit der Anlage einer VCCU hat der Inhalt des vorhandenen Attributes IODev eines HM_Devices keine Wirkung mehr. Statt dessen setzt die VCCU ein Internal IODev automatisch je nach Verfügbarkeit und Funklage. Das Attribut IODev ist dann nicht mehr notwendig und kann auch nicht mehr gesetzt werden, wenn IOgrp gesetzt ist.

=== Einrichten ===
{{Randnotiz|RNTyp=g|RNText=Achtung, die Reihenfolge der Befehle muss exakt eingehalten werden.CUL_HM ist leider nicht Raw Definition fähig!}}
Diese Befehlsfolge erzeugt eine VCCU, bitte die Reihenfolge genau so abarbeiten!
Die Werte in <> durch die echten Werte ersetzen und die <> weglassen!

Das Attribut ''IOList'' dient dazu festzulegen, welche physikalischen Schnittstellen ("IO") von der VCCU genutzt werden, dies sind in der Regel '''alle''' HM-fähigen Schnittstellen einer Installation.

''IOList'' beinhaltet die Komma-getrennte Liste der IOs ('''keine Leerzeichen'''!), so wie sie in FHEM angelegt sind.<pre>
define <Name der vccu> CUL_HM <hmId>
attr <Name der vccu> model CCU-FHEM
attr <Name der vccu> IOList <Name des io1>[,<Name des io2>,...]
attr <Name der vccu> IOgrp <Name der vccu>
</pre>

Die folgende Darstellung mit zwei IOs im Raw Definition Format dient nur als Beispiel:

Es seien z.B. in FHEM bereits die beiden Schnittstellen HMLAN0 und CUL0 angelegt:

define HMLAN0 HMLAN 192.168.168.2:1000
attr HMLAN0 hmId 123456
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic

Dann kann zusätzlich die VCCU mit derselben hmId angelegt werden und die beiden physikalischen Schnittstellen ihr zugewiesen:

define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU IOgrp VCCU
attr VCCU model CCU-FHEM

Wird die VCCU mit einer von vorhandenen Schnittstellen abweichenden ''hmId'' angelegt, so wird die ''hmId'' der ihr zugewiesenen Schnittstelle(n) automatisch angepasst. Dies hat in der Regel zur Folge, dass HM Devices neu gepairt werden müssen.

Dies trifft auch zu, wenn bereits vorhandene Schnittstellen unterschiedliche hmIDs haben, dann wird sich die hmID mindestens einer Schnittstelle ändern. (Der Einfachheit halber war im obigen Beispiel angenommen, dass auch vorher die beiden Schnittstellen bereits die gleiche ID hatten.)

=== Auswirkungen auf IOs / Funkschnittstellen===
Sind IOs durch das Attribut IOList einer VCCU zugewiesen und werden die notwendigen Attribute im IO gesetzt, so wird die hmId durch die VCCU kontrolliert. Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Beim HMLAN kann die HMId nicht mehr geändert werden. Die kontrollierende VCCU wird in den Internals ''owner'' und ''owner_CCU'' des IO automatisch eingetragen. 

=== Was passiert beim Austausch/Wegfall von IOs ===
Häufig wird das Thema VCCU erst angefasst, wenn das System schon eine Weile besteht und ein zweiter IO eingebaut, oder der alte IO ausgetauscht werden soll. Dabei entsteht folgende ungünstige Struktur in der fhem.cfg
...
define erster IO
...
define alle möglichen HM Geräte
...
define VCCU
define neuer IO
Beim Start von FHEM wird die cfg Zeilenweise abgearbeitet und für jedes HM Gerät geprüft ob ein IO vorhanden ist, gegebenenfalls erfolgt ein Fehlereintrag im Log (unknown IODev specified). Wenn der neue IO erst am Ende der cfg definiert ist, ist er für alle davor liegenden HM Geräte nicht vorhanden. Das ist nur ein Schönheitsfehler beim Start von FHEM, im laufenden Betrieb spielt das keine Rolle.

Folgende Struktur wäre erstrebenswert
...
define Homematic IO 1
define Homematic IO 2
define VCCU
define HM Geräte
...
Solange kein Modul die Einträge in der fhem.cfg entsprechend einsortiert, muss diese Korrektur von Hand erfolgen. Dies ist einer der wenigen Fälle, wo direktes Editieren der fhem.cfg z.B. mit dem eingebautem Editor unumgänglich ist. Soll der im Standard-WEBinterface von FHEM eingebaute Editor verwendet werden, muss zuerst das Attribut
attr WEB editConfig 1
in FHEM gesetzt werden.
Anschließend die kompletten define Blöcke mit allem was dazu gehört entsprechend in die empfohlene Struktur bringen.
Datei sichern und rereadcfg eingeben.

=== Pairen von HM Devices===
Ein erneutes Pairen nach dem Anlegen einer VCCU in bestehenden Installationen ist nicht notwendig!

Neue HM Devices sollten vorzugsweise direkt mit der VCCU gepairt werden, hierzu werden die normalen Befehle
hmPairForSec
also z.b.
set VCCU hmPairForSec 600
oder
hmPairSerial
verwendet.

Es ist alternativ weiter möglich - auch nach Anlage einer VCCU - HM Devices mit diesen Kommandos direkt an ein IO zu pairen, d.h. diese Kommandos haben auch nach Anlage einer VCCU noch eine Funktion an der physikalischen Schnittstelle (im Gegensatz z.b. zum attr IODev).

Da die VCCU und alle IOs die selbe ''hmId'' teilen, hat diese '''nicht''' die Wirkung, dass das Geräte etwa nicht mit der VCCU, sondern nur mit dem gepairten IO angesprochen werden kann.

Ist der Pairvorgang nicht sofort (oder nur teilweise) erfolgreich, kann/muss er ohne Weiteres 2 bis 3 mal wiederholt werden. Dann sollte das Gerät erfolgreich gepairt sein. Mit hmInfo configCheck kann das einfach überprüft werden. Mitunter kann es auch sinnvoll sein, das Gerät in den Auslieferungszustand zu bringen (siehe Handbuch, oft Knopf mindestens 5 Sekunden drücken, bis es blinkt, dann loslassen und nochmals 5 Sekunden drücken, bis es schneller blinkt) und danach erneut zu pairen.

==== Autocreate ====
Sofern Autocreate eingeschaltet ist und das Pairing wie oben beschrieben an die VCCU erfolgt, wird unter anderem für das Device folgendes Attribut angelegt:

attr <device> IOgrp VCCU:<PhysischesIO>

z.B.

attr Thermostat_Bad IOgrp VCCU:HMLAN1

Das attr <device> IOgrp:... zeigt an, welches physikalische IO zum Zeitpunkt des Autocreates verwendet wurde, vermutlich ist das das IO mit der besseren Funklage (wenn mehrere existieren). Dasselbe IO wird mit
IOgrp VCCU:HMLAN1
auch als prefered eingetragen. D.h. die VCCU wird später zuerst prüfen ob HMLAN1 verfügbar ist (condition=ok) und es dann verwenden, andere IOs werden nur verwendet, wenn HMLAN1 nicht verfügbar ist.
Dieser Eintrag kann manuell geändert werden, Details im folgenden Abschnitt.

== Dynamisches IO ==
Ohne VCCU sendet das System Befehle an ein HM Device in der Regel immer über das gleiche IO-Device. Fällt es aus, wird nicht mehr gesendet, selbst wenn ein zweites IO verfügbar wäre. Außerdem kann eine ''bewegliche'' Fernbedienung ihre Verbindung zu einem IO verlieren, obwohl sie über ein anderes IO gut kommunizieren könnten.

Die VCCU adressiert beide Probleme:

Durch das Attibut IOgrp
attr <device> IOgrp <vccu>:<preferredIO>
kann bestimmt werden, wie die VCCU die IO Devices genau nutzt. Insbesondere ist optional ein Preferd IO Device definierbar: bei stationären Devices - der häufigste Fall - sollte man das beste IO auswählen und als Default nutzen. Ein weiteres IO wird bei Ausfall des Ersten genutzt.

Das preferredIO ist jedoch optional und kann insbesondere bei beweglichen HM Devices (Fernbedienungen) weggelassen werden.

Es können auch mehrere preferredIO definiert werden, diese werden in der definierten Reihenfolge genutzt
attr <device> IOgrp <vccu>:<prefIO1>,<prefIO2>,<prefIO3>

Beispiele:

Durch
attr <device> IOgrp VCCU:HMLAN1
wird die VCCU zuerst versuchen Befehle an <device> mit HMLAN1 zu senden, falls seine condition=ok.
Falls nicht wird (einer) der verbleibende(n) IOs verwendet, hier der mit dem besten RSSI.

Durch
attr <device> IOgrp VCCU
wird durch die VCCU der IO mit dem besten RSSI zum Device gewählt, falls seine condition=ok ist.

Da dies für jedes angelegte HM Device einzeln definiert werden kann/muss, kann so auch eine Verteilung des Funkverkehrs vorgenommen werden, z.b. um die 1%-Regel (HighLoad) zu berücksichtigen, dennoch bleibt die Redundanz bei Ausfall einer Schnittstelle erhalten.

=== Bemerkungen ===
Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen. Kanäle senden nicht selbständig und haben daher auch kein Attribut IOgrp.

=== IOgrp bei nachträglicher Einrichtung einer VCCU ===
Wie erwähnt wird beim Verwenden von Autocreate das Attribut IOgrp mit angelegt.
Bei HM Devices die vor der Einrichtung einer VCCU angelegt wurden, fehlt das Attribut aber.
Es wird empfohlen, das Attribut IOgrp in solchen Devices zu nachträglich setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp. 
Das Attribut '''IODev''' wird dann automatisch gelöscht, wenn es gesetzt war, Usereinträge haben keine Funktion. 

==== Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl ====
In einer bestehenden FHEM-Installation mit mehreren/vielen Devices, kann das Setzen der ''IOgrp'' aufwendig sein.

Mit folgendem Befehl werden alle Geräte mit einer 6 stelligen DEF (HEX Zahl) um das notwendige Attribut erweitert. Die DEF 000000 (ActionDetector) wird ausgespart.

Zunächst kann man den Filter testen und damit die Auswirkung auf Geräte prüfen.
:<code>list TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6}</code>

Bitte nur '''VCCU''' durch den echten Namen der VCCU ersetzen!
:<code>attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp VCCU</code>
Anschließend nicht vergessen, die Konfiguration mit '''save''' zu speichern.

== Virtuelle Kanäle der VCCU==
{{Randnotiz|RNTyp=r|RNText= Die virtuellen Kanäle der VCCU funktionieren nicht als:
# virtueller Fensterkontakt
# virtueller Temperaturfühler
# virtueller HM-CC-TC
# virtueller TeamLead für Rauchmelder
Siehe Beispiel in [[HM-CC-RT-DN]] im Abschnitt externe Sensoren}}
: ''→ Siehe auch: [[HomeMatic#IO_Entities]]''

Eine VCCU kann bis zu 50 virtuelle Kanäle, sogenannte '''IO-Entities''', bedienen. Diese können als Sender/Sensoren oder Empfänger genutzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern.

Man peert beispielsweise einen Dimmer mit einer IO-Entity um "Tastendrücke" in der Zentrale auslösen zu können. Sowohl kurze (short) als auch lange (long) Tastendrücke können so an den Dimmer gesendet werden.
Auch mehrere Aktoren können mit einer IO-Entity gepeert werden, beispielsweise um alle Lichter der Gruppe mit einem "press" gleichzeitig zu schalten.

=== Anlegen ===
set VCCU virtual <Anzahl Button>
z.B.
set VCCU virtual 10
legt 10 Kanäle für die VCCU an, die Kanäle 1-10. Evtl. vorhandene Kanäle größer 10 werden gelöscht.

=== Kommandos ===
: ''→ Siehe auch: {{Link2CmdRef|Anker=CUL_HM-set-virtual}}''

Verfügbare Kommandos auflisten:

get vccu_Btn1 cmdList

Insbesondere gibt es:
set vccu_Btn1 press short
set vccu_Btn1 press long
set vccu_Btn1 postEvent <condition>

[[Kategorie:HomeMatic supportDevice]]

[[Kategorie:HOWTOS]]

Virtueller Controller VCCU

2026-01-07T22:11:26Z

Soulman: /* Einrichten */

{{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie: Eine VCCU innerhalb FHEM ist nicht zu verwechseln mit einer virtualisierten CCU3! Für letztere gibt es eine eigene Modulfalmilie [[HMCCU]], hier geht es ausschließlich um Geräte des TYPE CUL_HM.}}Eine '''Virtuelle CCU''', auch '''VCCU''' genannt, ist eine Zentrale für [[HomeMatic]]-Geräte. Die VCCU tritt beim [[Pairing (HomeMatic)|Pairing]] an die Stelle des ''I/O-Devices'' (auch "Schnittstelle" genannt, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]).

HomeMatic-Geräte werden üblicherweise mit einer Zentrale gepaired, um sie zentral verwalten zu können. Der Pairing-Partner ist im einfachsten Fall das I/O-Device ([[CUL]], [[HM-CFG-LAN]], …) selbst. Nachteilig dabei ist, dass der Ausfall der Schnittstelle bewirkt, dass alle gepairten Geräte nicht mehr bedient werden können. Dies lässt sich im Gegensatz zu ungepairten Protokollen (z.b. FS20) auch nicht durch doppelte Definition mit abweichenden IO-Devices lösen, da das Pairing nur mit einer ''hmId'' erfolgen kann. Daher kann auch durch mehrere Schnittstellen / IOs keine Redundanz erreicht werden. Ähnliches gilt für eine Vergrößerung der Funkabdeckung durch mehrere Schnittstellen.

Dieses Problem kann durch eine VCCU gelöst werden. Die VCCU ist eine virtuelle Zentrale; sie tritt beim Pairing an die Stelle der Schnittstelle. Sie erhält eine eigene ''hmId'', mit der die HM Sensoren und Geräte gepaired werden. Die Funkschnittstelle(n) werden dann von der VCCU als reine "dumme" IOs verwaltet. Dieses bietet vielfältige Möglichkeiten, z.B. die Verwendung mehrerer IOs, aus denen die VCCU die "beste" nach diversen Kriterien (z.B. RSSI) auswählt. Dadurch kann sowohl die Redundanz als auch die Funkabdeckung erhöht werden.

Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:

* Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
* Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
* Die VCCU stellt virtuelle Kanäle zur Verfügung, mit denen HomeMatic-Geräte [[HomeMatic Peering Beispiele|gepeert]] werden können.
* "Geordnete" Termination von Nachrichten (da die üblichen Funkschnittstellen (wie CUL im HM-Mode oder HM-LAN-Konfigurator) relativ "dumm" sind, führen viele Zustände zu den bekannten "Help me" Einträgen im Log)

Der einzige Nachteil einer VCCU gegenüber dem direkten Pairing mit dem I/O-Device ist ein Mehraufwand bei der initialen Konfiguration vom FHEM.

== Kurzbeschreibung ==
Ein virtueller Controller '''VCCU''' ist der Protokoll-Endpunkt der Zentrale und ersetzt dabei logisch (jedoch nicht physikalisch) z.b. den [[HM-CFG-LAN LAN Konfigurations-Adapter]] einer "klassischen" FHEM Konfiguration

Es können einer VCCU einzelne oder mehrere IO Devices zugeordnet werden. Man bündelt dadurch mehrere I/O Devices (z.B. CULs und HM-CFG-LANs) zu einem ''Pool''. Den HM-Devices in FHEM (Aktoren, Sensoren) kann dann als I/O Device die ''VCCU'' zugeordnet werden, dies geschieht durch das Attribut ''IOgrp.''

Durch diese Gruppierung der I/O Devices und dem Zuordnen der VCCU zu einem Device entstehen verschieden Vorteile, abhängig des Einsatzes der VCCU. So kann ein beliebiges I/O Device im Device Pool der VCCU ausfallen und das oder die verbliebenden I/O Devices übernehmen diese Funktion (abhängig von der Funkreichweite/Erreichbarkeit). Die VCCU wird das nächst verfügbare I/O Device zum Senden/Empfangen verwenden.

Ein weiterer Vorteil ist, dass durch die VCCU auch das I/O Device genutzt werden kann, welches die beste Funkqualität aufweist. Dies kann z.B. bei beweglichen Sensoren/Aktoren (Fernbedienungen) sinnvoll sein, oder wenn die Funkqualität durch andere Faktoren beeinflusst wird (z.B. Tür/Tor oder andere "bewegliche" Störfaktoren)

== Mehrere VCCUs in einer Installation==
Theoretisch erlaubt FHEM die parallele Nutzung mehrerer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann bereits eine VCCU verschiedene I/O-Devices bedienen, zum Beispiel einen [[CUL]] ''und'' ein [[HM-CFG-LAN]].

Jede VCCUs muss eine eindeutige ''HomeMatic-ID'' haben, mit der HomeMatic-Geräte gepaired werden. Folglich kann jedes HomeMatic-Gerät nur mit ''einer'' VCCU gepaired werden.

Die VCCU überschreibt die hmid eines I/O Device mit seiner eignen, daher können nicht mehrere VCCUs dasselbe I/O Device verwenden.

== Definition der VCCU==
=== hmId wählen ===
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Bei Schnittstellen und Zentralen ist dies eine ''hmId''. Da die VCCU eine (virtuelle) Zentrale ist, muss sie auch mit einer ''hmId'' versehen werden. Dies geschieht per define analog zur Anlage einer physischen Schnittstelle (siehe weiter unten)

Eine VCCU gibt die ''hmId'' an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. Damit haben alle von einer VCCU genutzten I/Os nach der Zuweisung dieselbe ''hmId''.

* Definiert man eine VCCU nachdem IOs für HomeMatic angelegt und in Verwendung sind, sollte man die ''hmId'' der bereits vorhandenen Funkschnittstelle verwenden, hierdurch kann man sich das Neupairen der HM Devices ersparen.
* Hat man bereits mehrere Funkschnittstellen im Einsatz, werden diese unterschiedliche ''hmIds'' haben, zumindest eine Schnittstelle wird nach der Zuweisung zur VCCU seine ''hmId'' also ändern.
* Für mit dieser Schnittstelle schon gepairte Devices ist ein Neupairen unumgänglich.

Außerdem muss in jedem Fall das attr IOgrp eines vor Anlage der VCCU gepairten Gerätes auf die VCCU angelegt/geändert werden., z.B. so
attr <device> IOgrp <Name der vccu>
(Siehe weiter unten ein Tipp, wie dies leicht nachträglich erledigt werden kann)

Mit der Anlage einer VCCU hat der Inhalt des vorhandenen Attributes IODev eines HM_Devices keine Wirkung mehr. Statt dessen setzt die VCCU ein Internal IODev automatisch je nach Verfügbarkeit und Funklage. Das Attribut IODev ist dann nicht mehr notwendig und kann auch nicht mehr gesetzt werden, wenn IOgrp gesetzt ist.

=== Einrichten ===
{{Randnotiz|RNTyp=g|RNText=Achtung, die Reihenfolge der Befehle muss exakt eingehalten werden.CUL_HM ist leider nicht Raw Definition fähig!}}
Diese Befehlsfolge erzeugt eine VCCU, bitte die Reihenfolge genau so abarbeiten!
Die Werte in <> durch die echten Werte ersetzen und die <> weglassen!

Das Attribut ''IOList'' dient dazu festzulegen, welche physikalischen Schnittstellen ("IO") von der VCCU genutzt werden, dies sind in der Regel '''alle''' HM-fähigen Schnittstellen einer Installation.

''IOList'' beinhaltet die Komma-getrennte Liste der IOs ('''keine Leerzeichen'''!), so wie sie in FHEM angelegt sind.<pre>
define <Name der vccu> CUL_HM <hmId>
attr <Name der vccu> model CCU-FHEM
attr <Name der vccu> IOList <Name des io1>[,<Name des io2>,...]
attr <Name der vccu> IOgrp <Name der vccu>
</pre>
Die folgende Darstellung mit zwei IOs im Raw Definition Format dient nur als Beispiel. '''Diese Abfolge ist nicht zum Anlegen der VCCU geeignet!'''

Es seien z.B. in FHEM bereits die beiden Schnittstellen HMLAN0 und CUL0 angelegt:

define HMLAN0 HMLAN 192.168.168.2:1000
attr HMLAN0 hmId 123456
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic

Dann kann zusätzlich die VCCU mit derselben hmId angelegt werden und die beiden physikalischen Schnittstellen ihr zugewiesen:

define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU IOgrp VCCU
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Wird die VCCU mit einer von vorhandenen Schnittstellen abweichenden ''hmId'' angelegt, so wird die ''hmId'' der ihr zugewiesenen Schnittstelle(n) automatisch angepasst. Dies hat in der Regel zur Folge, dass HM Devices neu gepairt werden müssen.

Dies trifft auch zu, wenn bereits vorhandene Schnittstellen unterschiedliche hmIDs haben, dann wird sich die hmID mindestens einer Schnittstelle ändern. (Der Einfachheit halber war im obigen Beispiel angenommen, dass auch vorher die beiden Schnittstellen bereits die gleiche ID hatten.)

=== Auswirkungen auf IOs / Funkschnittstellen===
Sind IOs durch das Attribut IOList einer VCCU zugewiesen und werden die notwendigen Attribute im IO gesetzt, so wird die hmId durch die VCCU kontrolliert. Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Beim HMLAN kann die HMId nicht mehr geändert werden. Die kontrollierende VCCU wird in den Internals ''owner'' und ''owner_CCU'' des IO automatisch eingetragen. 

=== Was passiert beim Austausch/Wegfall von IOs ===
Häufig wird das Thema VCCU erst angefasst, wenn das System schon eine Weile besteht und ein zweiter IO eingebaut, oder der alte IO ausgetauscht werden soll. Dabei entsteht folgende ungünstige Struktur in der fhem.cfg
...
define erster IO
...
define alle möglichen HM Geräte
...
define VCCU
define neuer IO
Beim Start von FHEM wird die cfg Zeilenweise abgearbeitet und für jedes HM Gerät geprüft ob ein IO vorhanden ist, gegebenenfalls erfolgt ein Fehlereintrag im Log (unknown IODev specified). Wenn der neue IO erst am Ende der cfg definiert ist, ist er für alle davor liegenden HM Geräte nicht vorhanden. Das ist nur ein Schönheitsfehler beim Start von FHEM, im laufenden Betrieb spielt das keine Rolle.

Folgende Struktur wäre erstrebenswert
...
define Homematic IO 1
define Homematic IO 2
define VCCU
define HM Geräte
...
Solange kein Modul die Einträge in der fhem.cfg entsprechend einsortiert, muss diese Korrektur von Hand erfolgen. Dies ist einer der wenigen Fälle, wo direktes Editieren der fhem.cfg z.B. mit dem eingebautem Editor unumgänglich ist. Soll der im Standard-WEBinterface von FHEM eingebaute Editor verwendet werden, muss zuerst das Attribut
attr WEB editConfig 1
in FHEM gesetzt werden.
Anschließend die kompletten define Blöcke mit allem was dazu gehört entsprechend in die empfohlene Struktur bringen.
Datei sichern und rereadcfg eingeben.

=== Pairen von HM Devices===
Ein erneutes Pairen nach dem Anlegen einer VCCU in bestehenden Installationen ist nicht notwendig!

Neue HM Devices sollten vorzugsweise direkt mit der VCCU gepairt werden, hierzu werden die normalen Befehle
hmPairForSec
also z.b.
set VCCU hmPairForSec 600
oder
hmPairSerial
verwendet.

Es ist alternativ weiter möglich - auch nach Anlage einer VCCU - HM Devices mit diesen Kommandos direkt an ein IO zu pairen, d.h. diese Kommandos haben auch nach Anlage einer VCCU noch eine Funktion an der physikalischen Schnittstelle (im Gegensatz z.b. zum attr IODev).

Da die VCCU und alle IOs die selbe ''hmId'' teilen, hat diese '''nicht''' die Wirkung, dass das Geräte etwa nicht mit der VCCU, sondern nur mit dem gepairten IO angesprochen werden kann.

Ist der Pairvorgang nicht sofort (oder nur teilweise) erfolgreich, kann/muss er ohne Weiteres 2 bis 3 mal wiederholt werden. Dann sollte das Gerät erfolgreich gepairt sein. Mit hmInfo configCheck kann das einfach überprüft werden. Mitunter kann es auch sinnvoll sein, das Gerät in den Auslieferungszustand zu bringen (siehe Handbuch, oft Knopf mindestens 5 Sekunden drücken, bis es blinkt, dann loslassen und nochmals 5 Sekunden drücken, bis es schneller blinkt) und danach erneut zu pairen.

==== Autocreate ====
Sofern Autocreate eingeschaltet ist und das Pairing wie oben beschrieben an die VCCU erfolgt, wird unter anderem für das Device folgendes Attribut angelegt:

attr <device> IOgrp VCCU:<PhysischesIO>

z.B.

attr Thermostat_Bad IOgrp VCCU:HMLAN1

Das attr <device> IOgrp:... zeigt an, welches physikalische IO zum Zeitpunkt des Autocreates verwendet wurde, vermutlich ist das das IO mit der besseren Funklage (wenn mehrere existieren). Dasselbe IO wird mit
IOgrp VCCU:HMLAN1
auch als prefered eingetragen. D.h. die VCCU wird später zuerst prüfen ob HMLAN1 verfügbar ist (condition=ok) und es dann verwenden, andere IOs werden nur verwendet, wenn HMLAN1 nicht verfügbar ist.
Dieser Eintrag kann manuell geändert werden, Details im folgenden Abschnitt.

== Dynamisches IO ==
Ohne VCCU sendet das System Befehle an ein HM Device in der Regel immer über das gleiche IO-Device. Fällt es aus, wird nicht mehr gesendet, selbst wenn ein zweites IO verfügbar wäre. Außerdem kann eine ''bewegliche'' Fernbedienung ihre Verbindung zu einem IO verlieren, obwohl sie über ein anderes IO gut kommunizieren könnten.

Die VCCU adressiert beide Probleme:

Durch das Attibut IOgrp
attr <device> IOgrp <vccu>:<preferredIO>
kann bestimmt werden, wie die VCCU die IO Devices genau nutzt. Insbesondere ist optional ein Preferd IO Device definierbar: bei stationären Devices - der häufigste Fall - sollte man das beste IO auswählen und als Default nutzen. Ein weiteres IO wird bei Ausfall des Ersten genutzt.

Das preferredIO ist jedoch optional und kann insbesondere bei beweglichen HM Devices (Fernbedienungen) weggelassen werden.

Es können auch mehrere preferredIO definiert werden, diese werden in der definierten Reihenfolge genutzt
attr <device> IOgrp <vccu>:<prefIO1>,<prefIO2>,<prefIO3>

Beispiele:

Durch
attr <device> IOgrp VCCU:HMLAN1
wird die VCCU zuerst versuchen Befehle an <device> mit HMLAN1 zu senden, falls seine condition=ok.
Falls nicht wird (einer) der verbleibende(n) IOs verwendet, hier der mit dem besten RSSI.

Durch
attr <device> IOgrp VCCU
wird durch die VCCU der IO mit dem besten RSSI zum Device gewählt, falls seine condition=ok ist.

Da dies für jedes angelegte HM Device einzeln definiert werden kann/muss, kann so auch eine Verteilung des Funkverkehrs vorgenommen werden, z.b. um die 1%-Regel (HighLoad) zu berücksichtigen, dennoch bleibt die Redundanz bei Ausfall einer Schnittstelle erhalten.

=== Bemerkungen ===
Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen. Kanäle senden nicht selbständig und haben daher auch kein Attribut IOgrp.

=== IOgrp bei nachträglicher Einrichtung einer VCCU ===
Wie erwähnt wird beim Verwenden von Autocreate das Attribut IOgrp mit angelegt.
Bei HM Devices die vor der Einrichtung einer VCCU angelegt wurden, fehlt das Attribut aber.
Es wird empfohlen, das Attribut IOgrp in solchen Devices zu nachträglich setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp. 
Das Attribut '''IODev''' wird dann automatisch gelöscht, wenn es gesetzt war, Usereinträge haben keine Funktion. 

==== Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl ====
In einer bestehenden FHEM-Installation mit mehreren/vielen Devices, kann das Setzen der ''IOgrp'' aufwendig sein.

Mit folgendem Befehl werden alle Geräte mit einer 6 stelligen DEF (HEX Zahl) um das notwendige Attribut erweitert. Die DEF 000000 (ActionDetector) wird ausgespart.

Zunächst kann man den Filter testen und damit die Auswirkung auf Geräte prüfen.
:<code>list TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6}</code>

Bitte nur '''VCCU''' durch den echten Namen der VCCU ersetzen!
:<code>attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp VCCU</code>
Anschließend nicht vergessen, die Konfiguration mit '''save''' zu speichern.

== Virtuelle Kanäle der VCCU==
{{Randnotiz|RNTyp=r|RNText= Die virtuellen Kanäle der VCCU funktionieren nicht als:
# virtueller Fensterkontakt
# virtueller Temperaturfühler
# virtueller HM-CC-TC
# virtueller TeamLead für Rauchmelder
Siehe Beispiel in [[HM-CC-RT-DN]] im Abschnitt externe Sensoren}}
: ''→ Siehe auch: [[HomeMatic#IO_Entities]]''

Eine VCCU kann bis zu 50 virtuelle Kanäle, sogenannte '''IO-Entities''', bedienen. Diese können als Sender/Sensoren oder Empfänger genutzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern.

Man peert beispielsweise einen Dimmer mit einer IO-Entity um "Tastendrücke" in der Zentrale auslösen zu können. Sowohl kurze (short) als auch lange (long) Tastendrücke können so an den Dimmer gesendet werden.
Auch mehrere Aktoren können mit einer IO-Entity gepeert werden, beispielsweise um alle Lichter der Gruppe mit einem "press" gleichzeitig zu schalten.

=== Anlegen ===
set VCCU virtual <Anzahl Button>
z.B.
set VCCU virtual 10
legt 10 Kanäle für die VCCU an, die Kanäle 1-10. Evtl. vorhandene Kanäle größer 10 werden gelöscht.

=== Kommandos ===
: ''→ Siehe auch: {{Link2CmdRef|Anker=CUL_HM-set-virtual}}''

Verfügbare Kommandos auflisten:

get vccu_Btn1 cmdList

Insbesondere gibt es:
set vccu_Btn1 press short
set vccu_Btn1 press long
set vccu_Btn1 postEvent <condition>

[[Kategorie:HomeMatic supportDevice]]

[[Kategorie:HOWTOS]]

Global

2026-01-07T19:07:21Z

Soulman: /* httpcompress */ Wozu sollte WAS gut sein?

{{SEITENTITEL:global}} 
{{Infobox Modul
|ModPurpose=Gerät zur Definition von globalen Attributen
|ModType=d
|ModCmdRef=global
|ModForumArea=Automatisierung
|ModTechName=fhem.pl ("Built-in")
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

Das '''Device global''' dient dazu, diverse allgemein für das gesamte FHEM gültige Eigenschaften und Verhaltensvorgaben zu definieren. Diese werden in [[Attribut|Attributen]] des devices verwaltet, indem deren Werten gemäß der {{Link2CmdRef|Lang=de|Anker=global|Label=dokumentierten}} Bedeutung gesetzt werden.

Das Pseudogerät '''global''' wird automatisch erstellt, kann weder gelöscht noch [[rename|umbenannt]] werden und hat auch keine ''set'' oder ''get'' Parameter.
{{Todo|Ergänzen}}

== Definition ==
Nicht erforderlich; wird automatisch angelegt.
== Attribute ==
=== altitude ===
Höhe in Metern über dem Meeresspiegel, Voreinstellung ist 0.
=== latitude ===
Geographische Breite in Dezimalgrad, Voreinstellung ist 50.112, Frankfurt am Main.
=== longitude ===
Geographische Länge in Dezimalgrad, Voreinstellung ist 8.686, Frankfurt am Main.
=== archivedir, archivecmd, nrarchive ===
Diese Attribute können grundsätzlich in allen Devices gesetzt werden und beziehen sich dann auf deren Logging. Im Device global wirken sie ausschließlich auf das FHEM [[#logfile|logfile]].

Wenn eine neue FileLog-Datei geöffnet wird, wird der FileLog archiver aufgerufen. Das geschieht aber nur, wenn der Name der Datei sich geändert hat (abhängig von den zeitspezifischen Wildcards, die in FileLog (define) beschrieben werden) und gleichzeitig ein neuer Datensatz in diese Datei geschrieben werden muss.

Wenn das Attribut archivecmd benutzt wird, startet es als shell-Kommando (eine Einbettung in " ist nicht notwendig), und jedes % in diesem Befehl wird durch den Namen des alten Logfiles ersetzt.

Wenn dieses Attribut nicht gesetzt wird, aber dafür nrarchive, werden nrarchive viele Logfiles im aktuellen Verzeichnis gelassen, und ältere Dateien in das Archivverzeichnis (archivedir) verschoben (oder gelöscht, falls kein archivedir gesetzt wurde).

'''Achtung''': "ältere Dateien" sind die, die in der alphabetisch sortierten Liste oben sind.
=== archivesort ===
archivesort kann auf dem (voreingestellten) Wert ''alphanum'' oder auf ''timestamp'' gesetzt werden, und bestimmt die Methode für die Reihenfolgenberechnung der Dateien für nrarchive.
=== autoload_undefined_devices ===
Wenn dieses Attribut gesetzt ist, werden die zu einer neu empfangenen Nachricht zugehörigen Module automatisch geladen. Dies erfolgt vom autocreate Gerät, um so automatisch ein FHEM-Gerät bei erreichen einer entsprechenden Nachricht zu erstellen.
{{Todo|Ergänzen: gesetzt mit welchem Wert?}}
=== backupcmd ===
Wenn dieses Attribut gesetzt ist, startet es als ein SHELL-Befehl und erstellt eine durch Leerzeichen getrennte Liste von Dateien/Verzeichnissen als ein Argument zum Befehl, z.B.:
"/etc/fhem.cfg /var/log/fhem/fhem.save /usr/share/fhem/contrib /usr/share/fhem/FHEM /usr/share/fhem/foo /usr/share/fhem/foobar /usr/share/fhem/www"
'''Bemerkung''': Ihr Befehl/Skript muss die Zeichenkette "backup done" zurückgeben oder eine entsprechende Zeichenkette um Fehlermeldungen auszugeben, damit die Zusammenarbeit mit update funktioniert!

{{Todo|Ergänzen: Was denn nun: 'backup done' oder die oben beschriebene Zeichenkette?}}
Dieses Attribut wird vom backup Befehl benutzt.

'''Beispiel''':
attr global backupcmd /usr/local/bin/myBackupScript.sh
=== backupdir ===
Ein Verzeichnis, in dem die komprimierten Sicherheitsdateien zu speichern sind. Dieses Attribut wird vom backup Befehl benutzt.
'''Beispiel:'''
attr global backupdir /Volumes/BigHD

=== backupsymlink ===
Wird dieses Attribut auf etwas anderes als ''no'' gesetzt, dann unterstützt der Archivierungsbefehl "tar" symbolische Links in Ihrem Backup. Andererseits, anderenfalls (Wert ''no'') werden symbolische Links vom Befehl "tar" ignoriert. Dieses Attribut wird vom backup Befehl benutzt.

'''Beispiel:'''
attr global backupsymlink yes
=== blockingCallMax ===
Begrenzt die Anzahl der parallel laufenden Prozesse, die von der FHEM Hilfsroutine ''BlockingCall'' gestartet wurden. Sinnvoll auf weniger leistungsfähigeren Hardware.
=== configfile ===
Enthält den Namen der FHEM Konfigurationsdatei. Wenn save ohne Argumente aufgerufen wird dann wird die Ausgabedatei unter diesem Dateinamen gespeichert.
=== commandref ===
Falls der Wert ''full'' (die Voreinstellung) ist, wird nach jedem update ein komplettes commandref.html generiert. Falls der Wert ''modular'' ist, wird die Moduldokumentation erst nach Bedarf während der Laufzeit per JavaScript geladen.
=== dnsHostsFile ===
Falls dnsServer gesetzt ist, wird die angegebene Datei nach dem Hostnamen durchsucht. Um die vom System verwendete Datei zu benutzen, ist es unter Linux/Unix/OSX auf ''/etc/hosts'' und unter Windows auf ''C:\windows\system32\drivers\etc\hosts'' zu setzen. Achtung: es wird nur IPv4 unterstützt.
=== dnsServer ===
Enthält die IP Adresse des DNS Servers. Die von bestimmten Modulen (oder eigenen Code) aufgerufene HttpUtils_NonblockingGet wird auch bei der DNS Auflösung nicht mehr blockieren, falls dieses Attribut gesetzt ist, da es in diesem Fall FHEM eigene Routinen aufgerufen werden. Sonst werden die Betriebssystem eigenen, blockierenden Routinen inet_aton bzw gethostbyname aufgerufen.
=== featurelevel ===
Der Wert dieses Attributes de-/aktiviert einzelne Fähigkeiten (Features) bzw. Verhaltensweisen, die im Laufe der Versionsgeschichte dazugekommen sind, entfernt oder geändert wurden basierend auf der angegebenen FHEM Version.

Bei einer Neuinstallation oder einem Update wird der Featurelevel automatisch auf die aktuelle Version gesetzt. Ein manuelles
attr global featurelevel x.y
mit den Werten für x und y aus den gewünschten Haupt- und Unterversionsnummern setzt temporär oder - bei Speicherung in der fhem.cfg dauerhaft - eine gewünschte Version als Basis. Dieses Vorgehen kann z.B. bei Upgrades mit unerwarteten Nebenwirkungen eine erste Maßnahme und Workaround sein.
=== holiday2we ===
Ist dieses Attribut gesetzt, wird die Variable ''$we'' als "true" betrachtet, wenn der Wert der Variable ''holiday'' zu diesem Attribut nicht "none" ist.

Falls der Wert des Attributes eine Komma getrennte Liste ist, dann ist ''$we'' wahr, falls eine der referenzierten Instanzen nicht "none" ist.

'''Beispiel:'''
attr global holiday2we hessen
{{Todo|Verwirrung auflösen...}}
=== httpcompress ===
Einige Module von FHEM verwenden das Modul ''HttpUtils'' mit aktivierter Komprimierung (Voreinstellung). Falls man httpcompress auf 0 setzt, wird die Komprimierung deaktiviert.

=== keyFileName ===
FHEM Module speichern Passwörter und IDs in der Datei FHEM/FhemUtils/uniqueID. Um mehrere FHEM-Instanzen im gleichen Verzeichnis starten zu können, kann man dieses Attribut setzen, dessen Wert an FHEM/FhemUtils/ angehängt wird.
=== logdir ===
Falls gesetzt, wird %L in dem Attribut ''[[#logfile|logfile]]'' (oder in der Dateinamen Spezifikation des [[FileLog]] Moduls) durch den Wert des Attributes ersetzt.

'''Achtung''' Wird der Wert des Attributes geändert, bewirkt dies '''nicht''' das Verschieben bereits erstellter Dateien, und kann daher potentiell zu diversen Problemen führen.
=== logfile ===
Gibt das Logfile an, in welches gespeichert werden soll. Mit dem Wert ''"-"'' erfolgt die Ausgabe des Logs in das stdout-Gerät. In diesem Fall stellt sich der Server nicht selbst in den Hintergrund.

Der Name der Logdatei kann auch "wildcards" enthalten, um eine einfachere Abfolge für die Dateien zu erreichen. Weiteres zu den Dateinamen beim Modul [[FileLog]].

Die Attribute [[#archivedir, archivecmd, nrarchive|archivedir, archivecmd, nrarchive]] können ggf. passend gesetzt werden.

Sie können den Namen der Logdatei mit {$currlogfile} festlegen.
{{Todo|Der Gehalt des letzten Satzes erschließt sich nicht.}}
=== maxShutdownDelay ===
Einige Module benötigen Zeit zum Aufräumen beim shutdown, aber FHEM begrenzt diese Zeit auf 10 Sekunden. Mit diesem Attribut kann man sie anpassen.
=== modpath ===
Mit modpath geben Sie den Pfad zu dem Verzeichnis der FHEM Module an. Der Pfad enthält nicht das Verzeichnis FHEM. Das festgelegte Verzeichnis wird nach Dateinamen in der Form NN_<NAME>.pm durchsucht. Die gefundenen Dateien dienen als Quelle die Definition von Geräten unter dem Namen <NAME>. Wenn das erste Gerät des Typs <NAME> definiert wird, werden die entsprechenden Module geladen und in dem Modul die entsprechende Funktion mit dem Namen <NAME>_Initialize aufgerufen. Eine Ausnahme bilden Module die mit der Nummer 99 im Dateinamen beginnen. Diese enthalten PERL-Hilfsfunktionen und werden zur Startzeit geladen.
=== motd ===
''Message Of The Day'' (Nachricht des Tages). Der hier hinterlegte Text wird im Begrüßungsbildschirm von FHEM angezeigt, oder direkt beim Start einer "telnet" Sitzung, bevor der Prompt (''fhem>'')erscheint. Der SecurityCheck setzt motd wenn es bisher nicht gesetzt ist. Um das zu verhindern, können sie den Wert von motd auf ''none'' setzen. motd wird auch verwendet, um Fehlermeldungen während des FHEM-Starts zu sammeln und anzuzeigen.
=== mseclog ===
Wenn dieses Attribut (z. B. auf den Wert 1) gesetzt ist, enthalten Datums/Zeiteinträge (timestamp) in der Logdatei einen Millisekunden-Eintrag.

=== nofork ===
Wenn dieses Attribut oder das Attribut [[#logfile|logfile]] auf "''-''" gesetzt ist, wird FHEM nicht im Hintergrund abgearbeitet. Dieses Attribut ist bei einigen FHEM Installationen auf FRITZ!-Boxen notwendig, und wird fuer Windows automatisch gesetzt.
{{Todo|Ist das so formuliert tatsächlich korrekt?}}
=== pidfilename ===
In die angegebene Datei wird die Prozess-ID des FHEM(-Perl)-Prozesses geschrieben. Der Server läuft als Hintergrundprozess (daemon). Einige Distributionen wollen anhand der PID testen, ob der FHEM Prozess läuft. Die Datei wird bei Ausführung des "shutdown"-Kommandos gelöscht.
=== proxy ===
Der Wert wird in der Form ''IP:PORT'' gesetzt, wenn HttpUtils einen HTTP-Proxy verwenden soll.
=== proxyAuth ===
Base64 kodiertes Benutzername:Passwort für den HTTP-Proxy (vgl. [[#proxy|Attribut proxy]].
=== proxyExclude ===
Regulärer Ausdruck für die Namen aller Hosts, die '''nicht''' via Proxy anzusprechen sind.
=== restoreDirs ===
''Update'' sichert (kopiert) jede Datei, bevor sie durch die neue Version ersetzt wird. Zu diesen Zweck wird zuerst ein restoreDir/Update-Verzeichnis angelegt (vgl. Attribut [[#modpath|modpath]]) und danach ein Unterverzeichnis mit dem aktuellen Datum. In dieses Verzeichnis werden die alten Versionen der Dateien vor dem Überschreiben gerettet. Die Voreinstellung ist 3, d.h. die letzten 3 Datums-Verzeichnisse werden aufgehoben, und die älteren entfernt.

Auch fhem.cfg und fhem.state wird auf diese Weise vor dem Ausführen von save gesichert, diesmal in das restoreDir/save Verzeichnis. Zum Restaurieren der alten Dateien kann man das restore Befehl verwenden.

Falls man den Wert auf 0 setzt, ist dieses Feature deaktiviert.
=== sendStatistics ===
Der Wert dieses Attributes steuert das Verhalten des Moduls [[Fheminfo]]:

* ''onUpdate'': Übertragung von INFO-Daten bei jedem Update (empfohlene Einstellung).
* ''manually'': Manuelle Übertragung der INFO-Daten mit dem FHEM-Befehl [[fheminfo|fheminfo send]].
* ''never'': Die Übertragung von INFO-Daten wird komplett verhindert.

=== statefile ===
Der Wert dieses Attributes legt den Namen der Datei fest, in die Statusinformationen aller Geräte gespeichert werden, bevor der Server heruntergefahren wird. Falls diese Datei nicht angegeben wird, werden keinerlei Informationen gesichert.
=== title ===
Setzt im Browser den Fenstertitel der FHEM-Session. Ist der Wert in {} eingeschlossen, wird er als Perl-Ausdruck ausgewertet.
=== useInet6 ===
Die HttpUtils Routinen verwenden IPv6 für die Kommunikation, falls der Server eine IPv6 Adresse hat.

'''Achtung''': das Perl-Modul IO::Socket::INET6 wird benötigt.
{{Todo|Welcher Wert ist für das Attribut zu setzen?}}
=== userattr ===
Enthält eine durch Leerzeichen getrennte Liste, in der die Namen zusätzlicher Attribute aufgeführt sind, die in allen Devices verfügbar werden. Diese müssen zuerst in dieser Liste definiert werden, bevor sie (individuell bei allen Geräten) angewendet werden können.

''userattr'' kann auch als Attribut in einzelnen Gerätekonfigurationen spezifiziert werden, um weitere Attribute '''für diese Geräte''' zu definieren.

'''Achtung''': Bei der Festlegung global verfügbarer, zusätzlicher Attributnamen ist dringend darauf zu achten, dass keine Kollisionen mit Geräte spezifischen Attributen erzeugt werden.
=== dupTimeout ===
Definert die Wartezeit, nach der 2 identische Ereignisse zweier Empfänger als Duplikat angesehen werden. Voreingestellt sind 0,5 Sekunden.
=== showInternalValues ===
Attribute, Geräte, Readings die mit Punkt (.) anfangen werden nicht angezeigt, es sei denn das globale Attribut ''showInternalValues'' ist gesetzt. Diese Variable wird bei den Befehlen ''[[list]]'' und ''[[xmllist]]'' und bei der FHEMWEB Raumansicht geprüft.
{{Todo|... gesetzt auf welchen Wert?}}
=== sslVersion ===
Setzt die akzeptierten Crypto-Algorithmen im Hilfsmodul [[TcpServices]]. Die Voreinstellung ''TLSv12:!SSLv3'' wird als sicherer erachtet als die vorherige ''SSLv23:!SSLv3:!SSLv2'', aber sie kann Probleme mit nicht ausreichend aktualisierten Netzwerk-Diensten verursachen.
=== stacktrace ===
Falls auf ''1'' gesetzt, schreibt FHEM zusätzlich zu jedem "PERL WARNING" den stacktrace ins Log.
=== restartDelay ===
Setzt die Verzögerung beim Neustart mit ''shutdown restart'', die Voreinstellung ist 2 (Sekunden).
=== autosave ===
Erlaubt manchen Modulen, nach einer automatischen Änderung der Konfiguration ''save'' auszuführen, z. B. nachdem ein Gerät angelegt wurde. Die Voreinstellung ist ''1'' (wahr), man kann es ausschalten, indem man den Wert auf ''0'' setzt.

Auch wenn man autosave auf ''1'' setzt, wird es automatisch beim Starten wieder auf ''0'' gesetzt, falls beim Starten was schiefgegangen ist, damit ein automatisches Save (wie auch manche Module das ungefragt machen) nicht zum Verlust von Teilen der Konfiguration führt.
== weitere Informationen ==
Siehe {{Link2CmdRef|Lang=de|Label=commandref|Anker=global}}.

CUL

2026-01-05T19:34:46Z

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */

Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.

== CUL HW ==
Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongle des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkattached Module ([[CUN]]O), Module zum direkten Aufstecken auch einen Raspberry Pi ([[COC]]), und auf Arduino basierende Lösungen ([[SIGNALduino]]).

== Einführung ==
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.

Das CUL kann mittels des '''[[CUL (Modul)|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== Definition in FHEM ==
Das CUL wird definiert mit

<code>define <name> CUL <device> <FHTID> </code>

als z.b.:

<code>define myCUL CUL /dev/ttyUSB0 0000</code>

Da FHT zur Heizungssterung kaum noch eine Rolle spielen dürfte ist die Vergabe der FHT-ID 0000 sinnvoll, da das CUL dann nicht auf FHT Communication achtet.

Was <device> ist hängt von der Art des CUL ab:
=== Geräte, die an USB angeschlossen sind (CUL/CUN) ===
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden:
modprobe usbserial vendor=0x03eb product=0x204b
In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.

Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.:

/dev/ttyACM0@38400.

Wenn mehrer CULs an einem System betrieben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit

ls /dev/serial/by-id

zu ermittlen wie sich diese melden, z.B.

usb-busware.de_CUL868-if00 usb-SHK_NANO_CUL_433-if00-port0

und diese dann mit

define CUL1 CUL /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400 0000
define CUL2 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@38400 1234

anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.

Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.

=== Geräte, die mit dem Netzwerk verbunden sind (CUN(O)) ===
<device> gibt die Hostadresse:Port des Gerätes an, z.B. 192.168.0.244:2323

Weiteres in der commandref [https://fhem.de/commandref.html#CUL]

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen.

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.

Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl).

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang="bash">
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.

Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik.
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.

Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne.

Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene.

Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser.

Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.

Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 MHz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 MHz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 MHz
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz

== Bekannte Probleme ==

=== RF-Tuning ===
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt
* CUL commandref [https://fhem.de/commandref.html#CUL]

[[Kategorie:Interfaces]]
[[Kategorie:CUL|!]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

CUL

2026-01-05T18:52:20Z

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */

Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.

== CUL HW ==
Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongle des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkattached Module ([[CUN]]O), Module zum direkten Aufstecken auch einen Raspberry Pi ([[COC]]), und auf Arduino basierende Lösungen ([[SIGNALduino]]).

== Einführung ==
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.

Das CUL kann mittels des '''[[CUL (Modul)|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== Definition in FHEM ==
Das CUL wird definiert mit

<code>define <name> CUL <device> <FHTID> </code>

als z.b.:

<code>define myCUL CUL /dev/ttyUSB0 0000</code>

Da FHT zur Heizungssterung kaum noch eine Rolle spielen dürfte ist die Vergabe der FHT-ID 0000 sinnvoll, da das CUL dann nicht auf FHT Communication achtet.

Was <device> ist hängt von der Art des CUL ab:
=== Geräte, die an USB angeschlossen sind (CUL/CUN) ===
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden:
modprobe usbserial vendor=0x03eb product=0x204b
In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.

Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.:

/dev/ttyACM0@38400.

Wenn mehrer CULs an einem System betrieben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit

ls /dev/serial/by-id

zu ermittlen wie sich diese melden, z.B.

usb-busware.de_CUL868-if00 usb-SHK_NANO_CUL_433-if00-port0

und diese dann mit

define CUL1 CUL /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400 0000
define CUL2 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@38400 1234

anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.
Dabei ist allerdings zu beachten, dass original Busware CULs sich immer gleich melden.
Wenn man also z.b. mehrere Busware 868Mhz CULs einsetzen will, werden die sich alle mit
usb-busware.de_CUL868-if00
melden und sind nicht unterscheidbar, während nano CULs und ähnlich oft eigene Seriennummern haben.

Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.

=== Geräte, die mit dem Netzwerk verbunden sind (CUN(O)) ===
<device> gibt die Hostadresse:Port des Gerätes an, z.B. 192.168.0.244:2323

Weiteres in der commandref [https://fhem.de/commandref.html#CUL]

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen.

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.

Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl).

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang="bash">
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.

Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik.
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.

Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne.

Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene.

Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser.

Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.

Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 MHz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 MHz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 MHz
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz

== Bekannte Probleme ==

=== RF-Tuning ===
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt
* CUL commandref [https://fhem.de/commandref.html#CUL]

[[Kategorie:Interfaces]]
[[Kategorie:CUL|!]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

CUL

2026-01-05T18:51:14Z

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */ Anbidung per by-ID ergänzt

Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.

== CUL HW ==
Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongle des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkattached Module ([[CUN]]O), Module zum direkten Aufstecken auch einen Raspberry Pi ([[COC]]), und auf Arduino basierende Lösungen ([[SIGNALduino]]).

== Einführung ==
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.

Das CUL kann mittels des '''[[CUL (Modul)|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== Definition in FHEM ==
Das CUL wird definiert mit

<code>define <name> CUL <device> <FHTID> </code>

als z.b.:

<code>define myCUL CUL /dev/ttyUSB0 0000</code>

Da FHT zur Heizungssterung kaum noch eine Rolle spielen dürfte ist die Vergabe der FHT-ID 0000 sinnvoll, da das CUL dann nicht auf FHT Communication achtet.

Was <device> ist hängt von der Art des CUL ab:
=== Geräte, die an USB angeschlossen sind (CUL/CUN) ===
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden:
modprobe usbserial vendor=0x03eb product=0x204b
In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.

Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.:

/dev/ttyACM0@38400.

Wenn mehrer CULs an einem System betreiben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL 433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit

ls /dev/serial/by-id

zu ermittlen wie sich diese melden, z.B.
usb-busware.de_CUL868-if00 usb-SHK_NANO_CUL_433-if00-port0

und diese dann mit

define CUL1 CUL /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400 0000
define CUL2 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@38400 1234

anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.
Dabei ist allerdings zu beachten, das original Busware CULs sich immer gleich melden.
Wenn man also z.b. mehrere Busware 868Mhz CULs einsetzen will, werden die sich alle mit
usb-busware.de_CUL868-if00
melden und sind nicht unterscheidbar, während nano CULs und ähnlich oft eigene Seriennummern haben.

Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.

=== Geräte, die mit dem Netzwerk verbunden sind (CUN(O)) ===
<device> gibt die Hostadresse:Port des Gerätes an, z.B. 192.168.0.244:2323

Weiteres in der commandref [https://fhem.de/commandref.html#CUL]

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen.

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.

Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl).

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang="bash">
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.

Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik.
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.

Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne.

Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene.

Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser.

Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.

Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 MHz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 MHz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 MHz
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz

== Bekannte Probleme ==

=== RF-Tuning ===
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt
* CUL commandref [https://fhem.de/commandref.html#CUL]

[[Kategorie:Interfaces]]
[[Kategorie:CUL|!]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

CUL

2026-01-05T18:49:50Z

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */

Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.

== CUL HW ==
Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongle des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkattached Module ([[CUN]]O), Module zum direkten Aufstecken auch einen Raspberry Pi ([[COC]]), und auf Arduino basierende Lösungen ([[SIGNALduino]]).

== Einführung ==
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.

Das CUL kann mittels des '''[[CUL (Modul)|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== Definition in FHEM ==
Das CUL wird definiert mit

<code>define <name> CUL <device> <FHTID> </code>

als z.b.:

<code>define myCUL CUL /dev/ttyUSB0 0000</code>

Da FHT zur Heizungssterung kaum noch eine Rolle spielen dürfte ist die Vergabe der FHT-ID 0000 sinnvoll, da das CUL dann nicht auf FHT Communication achtet.

Was <device> ist hängt von der Art des CUL ab:
=== Geräte, die an USB angeschlossen sind (CUL/CUN) ===
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden:
modprobe usbserial vendor=0x03eb product=0x204b
In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.

Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.:

/dev/ttyACM0@38400.

Wenn mehrer CULs an einem System betreiben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL 433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit

ls /dev/serial/by-id

zu ermittlen wie sich diese melden, z.B.
usb-busware.de_CUL868-if00 usb-SHK_NANO_CUL_433-if00-port0

und diese dann mit

define CUL1 CUL /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400 0000
define CUL2 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@38400 1234

anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.
Dabei ist allerdings zu beachten, das original Busware CULs sich immer gleich melden.
Wenn man also z.b. mehrere Busware 868Mhz CULs einsetzen will, werden die sich alle mit
usb-busware.de_CUL868-if00
melden und sind nicht unterscheidbar, während nano CULs und ähnlich oft eigene Seriennummern haben.

Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.

=== Geräte, die mit dem Netzwerk verbunden sind (CUN(O)) ===
<device> gibt die Hostadresse:Port des Gerätes an, z.B. 192.168.0.244:2323

Weiteres in der commandref [https://fhem.de/commandref.html#CUL]

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen.

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.

Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl).

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang="bash">
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.

Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik.
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.

Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne.

Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene.

Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser.

Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.

Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 MHz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 MHz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 MHz
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz

== Bekannte Probleme ==

=== RF-Tuning ===
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt
* CUL commandref [https://fhem.de/commandref.html#CUL]

[[Kategorie:Interfaces]]
[[Kategorie:CUL|!]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

CUL

2026-01-05T18:49:08Z

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */

Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.

== CUL HW ==
Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongle des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkattached Module ([[CUN]]O), Module zum direkten Aufstecken auch einen Raspberry Pi ([[COC]]), und auf Arduino basierende Lösungen ([[SIGNALduino]]).

== Einführung ==
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.

Das CUL kann mittels des '''[[CUL (Modul)|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== Definition in FHEM ==
Das CUL wird definiert mit

<code>define <name> CUL <device> <FHTID> </code>

als z.b.:

<code>define myCUL CUL /dev/ttyUSB0 0000</code>

Da FHT zur Heizungssterung kaum noch eine Rolle spielen dürfte ist die Vergabe der FHT-ID 0000 sinnvoll, da das CUL dann nicht auf FHT Communication achtet.

Was <device> ist hängt von der Art des CUL ab:
=== Geräte, die an USB angeschlossen sind (CUL/CUN) ===
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden:
modprobe usbserial vendor=0x03eb product=0x204b
In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.

Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.: /dev/ttyACM0@38400.

Wenn mehrer CULs an einem System betreiben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL 433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit

ls /dev/serial/by-id

zu ermittlen wie sich diese melden, z.B.
usb-busware.de_CUL868-if00 usb-SHK_NANO_CUL_433-if00-port0

und diese dann mit

define CUL1 CUL /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400 0000
define CUL2 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@38400 1234

anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.
Dabei ist allerdings zu beachten, das original Busware CULs sich immer gleich melden.
Wenn man also z.b. mehrere Busware 868Mhz CULs einsetzen will, werden die sich alle mit
usb-busware.de_CUL868-if00
melden und sind nicht unterscheidbar, während nano CULs und ähnlich oft eigene Seriennummern haben.

Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.

=== Geräte, die mit dem Netzwerk verbunden sind (CUN(O)) ===
<device> gibt die Hostadresse:Port des Gerätes an, z.B. 192.168.0.244:2323

Weiteres in der commandref [https://fhem.de/commandref.html#CUL]

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen.

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.

Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl).

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang="bash">
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.

Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik.
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.

Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne.

Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene.

Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser.

Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.

Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 MHz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 MHz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 MHz
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz

== Bekannte Probleme ==

=== RF-Tuning ===
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt
* CUL commandref [https://fhem.de/commandref.html#CUL]

[[Kategorie:Interfaces]]
[[Kategorie:CUL|!]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

AT zu einem absoluten Datum ausführen

2025-12-19T22:49:31Z

Soulman: Diverse Edits zusammengefasst

Mit dem Befehl [[at]] können in FHEM Aktionen zu einem definierten Zeitpunkt ausgeführt werden:

<nowiki>define morgens_Licht_an at *07:15:00 set Licht1 on</nowiki>
Es können relative und absolute Uhrzeiten, sowie ein bestimmtes Datum definiert werden.

<nowiki>define Licht_25_Januar_an at 2011-01-25T07:15:00 set Licht1 on</nowiki>

Die Ausführung kann an Bedingungen geknüpft sein, wie z.b. bestimmte Wochentage oder nur am Wochenende:

<nowiki>define morgens_Licht_Wochenende at *07:15:00 {if (!($we)) {fhem("set Licht1 on")} }</nowiki>

Theoretisch kann auf die selbe Art kann auch auf ein Ausführungsdatum geprüft werden.

<nowiki>define Licht_25_Januar_an at *07:15:00 {if($year==2011 && $month==1 && $mday==25) {fhem("set Licht1 on")} }</nowiki>
In diesem Fall wird täglich um 7:15 Uhr geprüft, ob der 25. Januar 2011 ist und falls ja, wird die Aktion ausgeführt.

Da dieser Fall nur einmal zutrifft, ist es sinnvoll, die Aktion nach Auslösung zu löschen, damit nicht nach dem 25. Januar 2011 weiter täglich geprüft wird, ob das Datum nochmal auftritt:

<pre>define Licht_25_Januar_an at *07:15:00 {if($year==2011 && $month==1 && $mday==25) \
{fhem ("set Licht1 on; delete Licht_25_Januar_an"} }</pre>

Grundsätzlich erfordert die Lösung, täglich bei Erreichen der gewünschten Uhrzeit zu prüfen ob der richtige Tag erreicht wurde, mehr Code und ist auch Perfomanceseitig ungünstiger. Das dies als Lösung des Problems gelegentlich empfohlen wird, basiert auf der verbreiteten, aber falschen Annahme, dass als Zeitpunkt kein bestimmtes Datum definiert werden könne.

Siehe auch
* [[At]]
* [[Trick_der_Woche#Januar_2018]]

[[Kategorie:Code Snippets]]

FS20 Allgemein

2024-12-27T15:33:15Z

Soulman:

Allgemeine Informationen, die für alle FS20 Geräte im Zusammenhang mit FHEM Gültigkeit haben.
== ON/OFF Befehle mit Time Parameter ==
=== Einführung ===
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).
Ein erneutes Senden eines for-timer Befehls löscht die alte Zeit und beginnt von vorne an zu zählen.

===Mögliche Zeiten ===

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).

{| class="wikitable" style="text-align:right"
! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
|   || || || || || || || || ||
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
|   || || || || || || || || ||
|-
| 1152 || 0:19:12,00 || 2304 || 0:38:24,00 || 4608 || 1:16:48,00 || 9216 || 2:33:36,00 || ||
|-
| 1280 || 0:21:20,00 || 2560 || 0:42:40,00 || 5120 || 1:25:20,00 || 10240 || 2:50:40,00 || ||
|-
| 1408 || 0:23:28,00 || 2816 || 0:46:56,00 || 5632 || 1:33:52,00 || 11264 || 3:07:44,00 || ||
|-
| 1536 || 0:25:36,00 || 3072 || 0:51:12,00 || 6144 || 1:42:24,00 || 12288 || 3:24:48,00 || ||
|-
| 1664 || 0:27:44,00 || 3328 || 0:55:28,00 || 6656 || 1:50:56,00 || 13312 || 3:41:52,00 || ||
|-
| 1792 || 0:29:52,00 || 3584 || 0:59:44,00 || 7168 || 1:59:28,00 || 14336 || 3:58:56,00 || ||
|-
| 1920 || 0:32:00,00 || 3840 || 1:04:00,00 || 7680 || 2:08:00,00 || 15360 || 4:16:00,00 || ||
|-
| 2048 || 0:34:08,00 || 4096 || 1:08:16,00 || 8192 || 2:16:32,00 || 0 || 0 || ||
|}
Beispiele und die Ausgabe im FHEM log:

define TestDev_2 at *12:52 set TestDev on-for-timer 0,27 '''-> Bad time spec (Komma statt Punkt)'''
define TestDev_1 at *13:23 set TestDev on-for-timer 16000 '''-> Specified timeout too large, max is 15360'''
define TestDev_2 at *13:24 set TestDev on-for-timer 2.6 '''-> TestDev: changing timeout to 2.75 from 2.6'''
define TestDev_2 at *13:24 set TestDev on-for-timer 81 '''-> TestDev: changing timeout to 88 from 81'''

=== Einsatzmöglichkeiten ===
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:

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 von
off-for-timer 15360
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.
Längere Auschaltzeiten als 4,5 Stunden können durch erneutes senden eines off-for-timer kurz vor Ablauf des Timers realisiert werden.

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
on-for-timer 0.25
sendet, bzw EINschalten indem man
off-for-timer 0.25
sendet.

== Gerätetimer setzen / löschen ==
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.
:<code>set schalterZwei timer 16 </code> -> Timer von Gerät '''schalterZwei''' wird auf 16 Sekunden gesetzt
Theoretisch lässt sich der timer auch wieder auschalten mit:
:<code>set schalterEins timer 0 </code> -> Timer von Gerät '''schalterEins''' wird deaktiviert / gelöscht
jedoch scheint dies nicht bei allen Geräten einwandfrei zu funktionieren. Ggf. Mehrmals versuchen.

Für folgende Geräte funktioniert der <code>set xxx timer</code> Befehl definitiv:
* [[FS20 RSU Rolladenschalter (Unterputz)]],
* FS20 SM4,
* [[FS20 SU Unterputz-Funk-Schalter]].
* FS20 ST-4



Sobald der Timer in einem FS20 Geräte gesetzt wird, schaltet auch der Befehel
:<code>set schalterZwei on </code>
das Gerät nur für 16 Sekunden an.

== FS20 Adressumrechnung ==
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.

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:

{| class="wikitable" style="width:100%; text-align:center"
! 1x quad !! 2x quad !! 3x quad !! 4x quad
|-
| 11 = 0x0 || 12 = 0x1 || 13 = 0x2 || 14 = 0x3
|-
| 21 = 0x4 || 22 = 0x5 || 23 = 0x6 || 24 = 0x7
|-
| 31 = 0x8 || 32 = 0x9 || 33 = 0xA || 34 = 0xB
|-
| 41 = 0xC || 42 = 0xD || 43 = 0xE || 44 = 0xF
|}

''Beispiel:'' [[Was ist der Hauscode?|Hauscode]] nach ELV (pseudoquaternär) "43 21 12 34" ergibt nach FHEM (hexadezimal) "E 4 1 B".

Einen automatischen Umrechner findet man auch unter [https://www.homematic-inside.de/praxis/tools/fs20converter www.homematic-inside.de]

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.

== FS20 Adressierungsschema (Vorschlag) ==
=== "klassisches" Schema ===
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.
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}}.

{| class="wikitable"
!Bezeichnung !! Schema !! Beispiel
|-
| Hauscode || xxxx xxxx || 4332 3221
|-
| Gerätecode || yyyy || 1111
|-
| Funktionsgruppe || 44aa || 4411 bis 4443
|-
| Lokaler Master || bb44 || 1144 bis 4344
|-
| Globaler Master || 4444 || 4444
|}

Mit Hilfe dieser Adressgruppen kann man jetzt sein System entwerfen:

Hauscode festlegen:
* s.o. 4332 3221

Funktionsgruppen festlegen:
* 4411: Deckenleuchten
* 4412: Rolläden

Lokale Master festlegen:
* 1144: Flur
* 1244: Esszimmer
* 1344: Wohnzimmer
* 1444: Schlafzimmer

Globaler Master
* ist fest auf 4444

Einzeladressen festlegen: Aus Gründen der Übersichtlichkeit werden die Lokalen Master-Adressen im vorderen Teil verwendet. Dies ist für die Funktion '''nicht''' erforderlich.:
* 1311: Stereoanlage Wohnzimmer
* 1312: Deckenlampe Wohnzimmer
* 1112: Steckdose Flur
* 1244: Deckenlampe Esszimmer
* 1411: Deckenlampe Schlafzimmer
usw.

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:
* mit 4411 alle Deckenleuchten im Haus
* mit 1312 nur die Deckenlampe im Wohnzimmer
* mit 1344 sowohl Deckenlampe als auch Stereoanlage
* mit 4444 alle Geräte (bei denen diese Adresse einprogrammiert ist)

=== Alternatives Schema===
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, sowie wenn FS20 Komponenten durch Fernsteuerungen direkt (quasi an FHEM vorbei) gesteuert werden sollen.
Kann man auf dieses Feature verzichten - z.B. weil es in FHEM auch anders abgebildet werden kann - sind auch andere Adressschemata möglich.

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.

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.

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.

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.

In diesem alternative Schema können FS20 Fernbedienungen allerdings nur eingeschränkt zur '''Direkt'''steuerung von FS20 Komponenten verwendet werden, da jede Fernbedienung einen Hauscode für alle Kanäle/Tasten verwendet.
Gerade in solchen Installationen ist es also sinnvoll, Fernbedienungen nicht den Komponenten direkt zuzuordnen, sondern damit Aktionen über FHEM mittels <code>define…notify</code> auszulösen.

== FS20 - Probleme durch LTE ==
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]).

Zur weiteren Informationen sei auf die folgenden Artikel verwiesen:

* [http://www.heise.de/ct/artikel/Hausautomationssystem-ELV-FS20-Probleme-mit-LTE-Routern-1758453.html heise.de]
* [http://www.elv.de/nicht-lte-stoerfest.html elv.de]

Betroffen von diesen Problemen sollen insbesondere FS20-Geräte '''älterer''' Bauart sein, da deren Empfangsteil zu breitbandig sei.

Unter [ftp://ftp.heise.de/pub/ct/listings/1226-025.zip Textdatei] findet sich eine ''Liste der vom LTE-Problem betroffenen FS20-Geräte''.

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.

== FS20 - Abgekündigt ==
Das FS320 System ist inzwischen als veraltet zu betrachten. Es hat wegen einiger Features die es sonst kaum gibt (z.b. off-for-timer) durchaus noch Vorteile, ist aber insbesondere wegen fehlender Verschlüsselung und fehlendem Rückkanal kaum noch zeitgemäss. Ähnlich dem InterTechno 433 mhz Funksystem ("Baumarktfunkdosen"), kann jeder, der einen FS20 Fernbedienung hat und in Funkreichweite ist, prinzipiell alle Komponenten einer Installation steuern. Als Neugeräte sind aktuell (2024) nur noch Restbestände erhältlich.

== Links ==
ELV (Journal) Serie über das FS20 System in der Praxis:
* Teil 1 {{DocLink|elv|/bilder/journal/2006_04/01/fs20_system_teil1.pdf}} - Einleitung
* Teil 2 {{DocLink|elv|/bilder/journal/2006_05/18/fs20_system_teil2.pdf}} - Installationsbeispiel Unterputzschalter
* Teil 3 {{DocLink|elv|/bilder/journal/2006_06/03/fs20_system_teil3.pdf}} - Beleuchtungssteuerung durch Verknüpfung von Komponenten
* Teil 4 {{DocLink|elv|/bilder/journal/2007_01/14/fs20_system_teil4.pdf}} - Planung und Einrichtung eines Haussteuerungssystems
* Teil 5 {{DocLink|elv|/bilder/journal/2007_04/13/fs20_system_teil5.pdf}} - Rollladensteuerung
* Teil 6 {{DocLink|elv|/bilder/journal/2007_05/04/fs20_system_teil6.pdf}} - Kameraüberwachung + Dokumentation einer FS20 Installation
* Teil 7 {{DocLink|elv|/bilder/journal/2007_06/03/fs20_system_teil7.pdf}} - Rollladensteuerung mit "homeputer Studio"
* Teil 8 {{DocLink|elv|/bilder/journal/2008_01/04/fs20_system_teil8.pdf}} - Makroprogrammierung (mit "homeputer Studio")
* Teil 9 {{DocLink|elv|/bilder/journal/2008_02/05/fs20_system_teil9.pdf}} - FS20 Audio Komponenten

[[Kategorie:FS20 Components|Allgemein]]

FS20 Allgemein

2024-12-27T15:21:45Z

Soulman: /* Gerätetimer setzen / löschen */

Allgemeine Informationen, die für alle FS20 Geräte im Zusammenhang mit FHEM Gültigkeit haben.
== ON/OFF Befehle mit Time Parameter ==
=== Einführung ===
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).
Ein erneutes Senden eines for-timer Befehls löscht die alte Zeit und beginnt von vorne an zu zählen.

===Mögliche Zeiten ===

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).

{| class="wikitable" style="text-align:right"
! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
|   || || || || || || || || ||
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
|   || || || || || || || || ||
|-
| 1152 || 0:19:12,00 || 2304 || 0:38:24,00 || 4608 || 1:16:48,00 || 9216 || 2:33:36,00 || ||
|-
| 1280 || 0:21:20,00 || 2560 || 0:42:40,00 || 5120 || 1:25:20,00 || 10240 || 2:50:40,00 || ||
|-
| 1408 || 0:23:28,00 || 2816 || 0:46:56,00 || 5632 || 1:33:52,00 || 11264 || 3:07:44,00 || ||
|-
| 1536 || 0:25:36,00 || 3072 || 0:51:12,00 || 6144 || 1:42:24,00 || 12288 || 3:24:48,00 || ||
|-
| 1664 || 0:27:44,00 || 3328 || 0:55:28,00 || 6656 || 1:50:56,00 || 13312 || 3:41:52,00 || ||
|-
| 1792 || 0:29:52,00 || 3584 || 0:59:44,00 || 7168 || 1:59:28,00 || 14336 || 3:58:56,00 || ||
|-
| 1920 || 0:32:00,00 || 3840 || 1:04:00,00 || 7680 || 2:08:00,00 || 15360 || 4:16:00,00 || ||
|-
| 2048 || 0:34:08,00 || 4096 || 1:08:16,00 || 8192 || 2:16:32,00 || 0 || 0 || ||
|}
Beispiele und die Ausgabe im FHEM log:

define TestDev_2 at *12:52 set TestDev on-for-timer 0,27 '''-> Bad time spec (Komma statt Punkt)'''
define TestDev_1 at *13:23 set TestDev on-for-timer 16000 '''-> Specified timeout too large, max is 15360'''
define TestDev_2 at *13:24 set TestDev on-for-timer 2.6 '''-> TestDev: changing timeout to 2.75 from 2.6'''
define TestDev_2 at *13:24 set TestDev on-for-timer 81 '''-> TestDev: changing timeout to 88 from 81'''

=== Einsatzmöglichkeiten ===
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:

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 von
off-for-timer 15360
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.
Längere Auschaltzeiten als 4,5 Stunden können durch erneutes senden eines off-for-timer kurz vor Ablauf des Timers realisiert werden.

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
on-for-timer 0.25
sendet, bzw EINschalten indem man
off-for-timer 0.25
sendet.

== Gerätetimer setzen / löschen ==
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.
:<code>set schalterZwei timer 16 </code> -> Timer von Gerät '''schalterZwei''' wird auf 16 Sekunden gesetzt
Theoretisch lässt sich der timer auch wieder auschalten mit:
:<code>set schalterEins timer 0 </code> -> Timer von Gerät '''schalterEins''' wird deaktiviert / gelöscht
jedoch scheint dies nicht bei allen Geräten einwandfrei zu funktionieren. Ggf. Mehrmals versuchen.

Für folgende Geräte funktioniert der <code>set xxx timer</code> Befehl definitiv:
* [[FS20 RSU Rolladenschalter (Unterputz)]],
* FS20 SM4,
* [[FS20 SU Unterputz-Funk-Schalter]].
* FS20 ST-4



Sobald der Timer in einem FS20 Geräte gesetzt wird, schaltet auch der Befehel
:<code>set schalterZwei on </code>
das Gerät nur für 16 Sekunden an.

== FS20 Adressumrechnung ==
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.

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:

{| class="wikitable" style="width:100%; text-align:center"
! 1x quad !! 2x quad !! 3x quad !! 4x quad
|-
| 11 = 0x0 || 12 = 0x1 || 13 = 0x2 || 14 = 0x3
|-
| 21 = 0x4 || 22 = 0x5 || 23 = 0x6 || 24 = 0x7
|-
| 31 = 0x8 || 32 = 0x9 || 33 = 0xA || 34 = 0xB
|-
| 41 = 0xC || 42 = 0xD || 43 = 0xE || 44 = 0xF
|}

''Beispiel:'' [[Was ist der Hauscode?|Hauscode]] nach ELV (pseudoquaternär) "43 21 12 34" ergibt nach FHEM (hexadezimal) "E 4 1 B".

Einen automatischen Umrechner findet man auch unter [https://www.homematic-inside.de/praxis/tools/fs20converter www.homematic-inside.de]

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.

== FS20 Adressierungsschema (Vorschlag) ==
=== "klassisches" Schema ===
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.
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}}.

{| class="wikitable"
!Bezeichnung !! Schema !! Beispiel
|-
| Hauscode || xxxx xxxx || 4332 3221
|-
| Gerätecode || yyyy || 1111
|-
| Funktionsgruppe || 44aa || 4411 bis 4443
|-
| Lokaler Master || bb44 || 1144 bis 4344
|-
| Globaler Master || 4444 || 4444
|}

Mit Hilfe dieser Adressgruppen kann man jetzt sein System entwerfen:

Hauscode festlegen:
* s.o. 4332 3221

Funktionsgruppen festlegen:
* 4411: Deckenleuchten
* 4412: Rolläden

Lokale Master festlegen:
* 1144: Flur
* 1244: Esszimmer
* 1344: Wohnzimmer
* 1444: Schlafzimmer

Globaler Master
* ist fest auf 4444

Einzeladressen festlegen: Aus Gründen der Übersichtlichkeit werden die Lokalen Master-Adressen im vorderen Teil verwendet. Dies ist für die Funktion '''nicht''' erforderlich.:
* 1311: Stereoanlage Wohnzimmer
* 1312: Deckenlampe Wohnzimmer
* 1112: Steckdose Flur
* 1244: Deckenlampe Esszimmer
* 1411: Deckenlampe Schlafzimmer
usw.

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:
* mit 4411 alle Deckenleuchten im Haus
* mit 1312 nur die Deckenlampe im Wohnzimmer
* mit 1344 sowohl Deckenlampe als auch Stereoanlage
* mit 4444 alle Geräte (bei denen diese Adresse einprogrammiert ist)

=== Alternatives Schema===
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, sowie wenn FS20 Komponenten durch Fernsteuerungen direkt (quasi an FHEM vorbei) gesteuert werden sollen.
Kann man auf dieses Feature verzichten - z.B. weil es in FHEM auch anders abgebildet werden kann - sind auch andere Adressschemata möglich.

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.

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.

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.

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.

In diesem alternative Schema können FS20 Fernbedienungen allerdings nur eingeschränkt zur '''Direkt'''steuerung von FS20 Komponenten verwendet werden, da jede Fernbedienung einen Hauscode für alle Kanäle/Tasten verwendet.
Gerade in solchen Installationen ist es also sinnvoll, Fernbedienungen nicht den Komponenten direkt zuzuordnen, sondern damit Aktionen über FHEM mittels <code>define…notify</code> auszulösen.

== FS20 - Probleme durch LTE ==
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]).

Zur weiteren Informationen sei auf die folgenden Artikel verwiesen:

* [http://www.heise.de/ct/artikel/Hausautomationssystem-ELV-FS20-Probleme-mit-LTE-Routern-1758453.html heise.de]
* [http://www.elv.de/nicht-lte-stoerfest.html elv.de]

Betroffen von diesen Problemen sollen insbesondere FS20-Geräte '''älterer''' Bauart sein, da deren Empfangsteil zu breitbandig sei.

Unter [ftp://ftp.heise.de/pub/ct/listings/1226-025.zip Textdatei] findet sich eine ''Liste der vom LTE-Problem betroffenen FS20-Geräte''.

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.

== Links ==
ELV (Journal) Serie über das FS20 System in der Praxis:
* Teil 1 {{DocLink|elv|/bilder/journal/2006_04/01/fs20_system_teil1.pdf}} - Einleitung
* Teil 2 {{DocLink|elv|/bilder/journal/2006_05/18/fs20_system_teil2.pdf}} - Installationsbeispiel Unterputzschalter
* Teil 3 {{DocLink|elv|/bilder/journal/2006_06/03/fs20_system_teil3.pdf}} - Beleuchtungssteuerung durch Verknüpfung von Komponenten
* Teil 4 {{DocLink|elv|/bilder/journal/2007_01/14/fs20_system_teil4.pdf}} - Planung und Einrichtung eines Haussteuerungssystems
* Teil 5 {{DocLink|elv|/bilder/journal/2007_04/13/fs20_system_teil5.pdf}} - Rollladensteuerung
* Teil 6 {{DocLink|elv|/bilder/journal/2007_05/04/fs20_system_teil6.pdf}} - Kameraüberwachung + Dokumentation einer FS20 Installation
* Teil 7 {{DocLink|elv|/bilder/journal/2007_06/03/fs20_system_teil7.pdf}} - Rollladensteuerung mit "homeputer Studio"
* Teil 8 {{DocLink|elv|/bilder/journal/2008_01/04/fs20_system_teil8.pdf}} - Makroprogrammierung (mit "homeputer Studio")
* Teil 9 {{DocLink|elv|/bilder/journal/2008_02/05/fs20_system_teil9.pdf}} - FS20 Audio Komponenten

[[Kategorie:FS20 Components|Allgemein]]

FS20 Allgemein

2024-12-27T15:19:17Z

Soulman: /* Einsatzmöglichkeiten */

Allgemeine Informationen, die für alle FS20 Geräte im Zusammenhang mit FHEM Gültigkeit haben.
== ON/OFF Befehle mit Time Parameter ==
=== Einführung ===
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).
Ein erneutes Senden eines for-timer Befehls löscht die alte Zeit und beginnt von vorne an zu zählen.

===Mögliche Zeiten ===

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).

{| class="wikitable" style="text-align:right"
! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer !! Sekunden !! Zeitdauer
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
|   || || || || || || || || ||
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
| 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
|-
|   || || || || || || || || ||
|-
| 1152 || 0:19:12,00 || 2304 || 0:38:24,00 || 4608 || 1:16:48,00 || 9216 || 2:33:36,00 || ||
|-
| 1280 || 0:21:20,00 || 2560 || 0:42:40,00 || 5120 || 1:25:20,00 || 10240 || 2:50:40,00 || ||
|-
| 1408 || 0:23:28,00 || 2816 || 0:46:56,00 || 5632 || 1:33:52,00 || 11264 || 3:07:44,00 || ||
|-
| 1536 || 0:25:36,00 || 3072 || 0:51:12,00 || 6144 || 1:42:24,00 || 12288 || 3:24:48,00 || ||
|-
| 1664 || 0:27:44,00 || 3328 || 0:55:28,00 || 6656 || 1:50:56,00 || 13312 || 3:41:52,00 || ||
|-
| 1792 || 0:29:52,00 || 3584 || 0:59:44,00 || 7168 || 1:59:28,00 || 14336 || 3:58:56,00 || ||
|-
| 1920 || 0:32:00,00 || 3840 || 1:04:00,00 || 7680 || 2:08:00,00 || 15360 || 4:16:00,00 || ||
|-
| 2048 || 0:34:08,00 || 4096 || 1:08:16,00 || 8192 || 2:16:32,00 || 0 || 0 || ||
|}
Beispiele und die Ausgabe im FHEM log:

define TestDev_2 at *12:52 set TestDev on-for-timer 0,27 '''-> Bad time spec (Komma statt Punkt)'''
define TestDev_1 at *13:23 set TestDev on-for-timer 16000 '''-> Specified timeout too large, max is 15360'''
define TestDev_2 at *13:24 set TestDev on-for-timer 2.6 '''-> TestDev: changing timeout to 2.75 from 2.6'''
define TestDev_2 at *13:24 set TestDev on-for-timer 81 '''-> TestDev: changing timeout to 88 from 81'''

=== Einsatzmöglichkeiten ===
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:

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 von
off-for-timer 15360
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.
Längere Auschaltzeiten als 4,5 Stunden können durch erneutes senden eines off-for-timer kurz vor Ablauf des Timers realisiert werden.

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
on-for-timer 0.25
sendet, bzw EINschalten indem man
off-for-timer 0.25
sendet.

== Gerätetimer setzen / löschen ==
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.
:<code>set schalterZwei timer 16 </code> -> Timer von Gerät '''schalterZwei''' wird auf 16 Sekunden gesetzt
Theoretisch lässt sich der timer auch wieder auschalten mit:
:<code>set schalterEins timer 0 </code> -> Timer von Gerät '''schalterEins''' wird deaktiviert / gelöscht
jedoch scheint dies nicht bei allen Geräten einwandfrei zu funktionieren. Ggf. Mehrmals versuchen.

Für folgende Geräte funktioniert der <code>set xxx timer</code> Befehl definitiv:
* [[FS20 RSU Rolladenschalter (Unterputz)]],
* FS20 SM4,
* [[FS20 SU Unterputz-Funk-Schalter]].
* FS20 ST-4



== FS20 Adressumrechnung ==
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.

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:

{| class="wikitable" style="width:100%; text-align:center"
! 1x quad !! 2x quad !! 3x quad !! 4x quad
|-
| 11 = 0x0 || 12 = 0x1 || 13 = 0x2 || 14 = 0x3
|-
| 21 = 0x4 || 22 = 0x5 || 23 = 0x6 || 24 = 0x7
|-
| 31 = 0x8 || 32 = 0x9 || 33 = 0xA || 34 = 0xB
|-
| 41 = 0xC || 42 = 0xD || 43 = 0xE || 44 = 0xF
|}

''Beispiel:'' [[Was ist der Hauscode?|Hauscode]] nach ELV (pseudoquaternär) "43 21 12 34" ergibt nach FHEM (hexadezimal) "E 4 1 B".

Einen automatischen Umrechner findet man auch unter [https://www.homematic-inside.de/praxis/tools/fs20converter www.homematic-inside.de]

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.

== FS20 Adressierungsschema (Vorschlag) ==
=== "klassisches" Schema ===
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.
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}}.

{| class="wikitable"
!Bezeichnung !! Schema !! Beispiel
|-
| Hauscode || xxxx xxxx || 4332 3221
|-
| Gerätecode || yyyy || 1111
|-
| Funktionsgruppe || 44aa || 4411 bis 4443
|-
| Lokaler Master || bb44 || 1144 bis 4344
|-
| Globaler Master || 4444 || 4444
|}

Mit Hilfe dieser Adressgruppen kann man jetzt sein System entwerfen:

Hauscode festlegen:
* s.o. 4332 3221

Funktionsgruppen festlegen:
* 4411: Deckenleuchten
* 4412: Rolläden

Lokale Master festlegen:
* 1144: Flur
* 1244: Esszimmer
* 1344: Wohnzimmer
* 1444: Schlafzimmer

Globaler Master
* ist fest auf 4444

Einzeladressen festlegen: Aus Gründen der Übersichtlichkeit werden die Lokalen Master-Adressen im vorderen Teil verwendet. Dies ist für die Funktion '''nicht''' erforderlich.:
* 1311: Stereoanlage Wohnzimmer
* 1312: Deckenlampe Wohnzimmer
* 1112: Steckdose Flur
* 1244: Deckenlampe Esszimmer
* 1411: Deckenlampe Schlafzimmer
usw.

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:
* mit 4411 alle Deckenleuchten im Haus
* mit 1312 nur die Deckenlampe im Wohnzimmer
* mit 1344 sowohl Deckenlampe als auch Stereoanlage
* mit 4444 alle Geräte (bei denen diese Adresse einprogrammiert ist)

=== Alternatives Schema===
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, sowie wenn FS20 Komponenten durch Fernsteuerungen direkt (quasi an FHEM vorbei) gesteuert werden sollen.
Kann man auf dieses Feature verzichten - z.B. weil es in FHEM auch anders abgebildet werden kann - sind auch andere Adressschemata möglich.

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.

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.

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.

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.

In diesem alternative Schema können FS20 Fernbedienungen allerdings nur eingeschränkt zur '''Direkt'''steuerung von FS20 Komponenten verwendet werden, da jede Fernbedienung einen Hauscode für alle Kanäle/Tasten verwendet.
Gerade in solchen Installationen ist es also sinnvoll, Fernbedienungen nicht den Komponenten direkt zuzuordnen, sondern damit Aktionen über FHEM mittels <code>define…notify</code> auszulösen.

== FS20 - Probleme durch LTE ==
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]).

Zur weiteren Informationen sei auf die folgenden Artikel verwiesen:

* [http://www.heise.de/ct/artikel/Hausautomationssystem-ELV-FS20-Probleme-mit-LTE-Routern-1758453.html heise.de]
* [http://www.elv.de/nicht-lte-stoerfest.html elv.de]

Betroffen von diesen Problemen sollen insbesondere FS20-Geräte '''älterer''' Bauart sein, da deren Empfangsteil zu breitbandig sei.

Unter [ftp://ftp.heise.de/pub/ct/listings/1226-025.zip Textdatei] findet sich eine ''Liste der vom LTE-Problem betroffenen FS20-Geräte''.

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.

== Links ==
ELV (Journal) Serie über das FS20 System in der Praxis:
* Teil 1 {{DocLink|elv|/bilder/journal/2006_04/01/fs20_system_teil1.pdf}} - Einleitung
* Teil 2 {{DocLink|elv|/bilder/journal/2006_05/18/fs20_system_teil2.pdf}} - Installationsbeispiel Unterputzschalter
* Teil 3 {{DocLink|elv|/bilder/journal/2006_06/03/fs20_system_teil3.pdf}} - Beleuchtungssteuerung durch Verknüpfung von Komponenten
* Teil 4 {{DocLink|elv|/bilder/journal/2007_01/14/fs20_system_teil4.pdf}} - Planung und Einrichtung eines Haussteuerungssystems
* Teil 5 {{DocLink|elv|/bilder/journal/2007_04/13/fs20_system_teil5.pdf}} - Rollladensteuerung
* Teil 6 {{DocLink|elv|/bilder/journal/2007_05/04/fs20_system_teil6.pdf}} - Kameraüberwachung + Dokumentation einer FS20 Installation
* Teil 7 {{DocLink|elv|/bilder/journal/2007_06/03/fs20_system_teil7.pdf}} - Rollladensteuerung mit "homeputer Studio"
* Teil 8 {{DocLink|elv|/bilder/journal/2008_01/04/fs20_system_teil8.pdf}} - Makroprogrammierung (mit "homeputer Studio")
* Teil 9 {{DocLink|elv|/bilder/journal/2008_02/05/fs20_system_teil9.pdf}} - FS20 Audio Komponenten

[[Kategorie:FS20 Components|Allgemein]]

Kategorie:FS20 Components

2024-12-27T15:17:30Z

Soulman:

This category lists hardware components of the FS20 system. Please note that the FS20 system has been discontinued and no new devices are available apart from remaining stocks.

General information on using FS20 components with FHEM should go into [[FS20 Allgemein]]. This document, up to now, contains information on:

* [[FS20_Allgemein#Ger.C3.A4tetimer_setzen_.2F_l.C3.B6schen|Using Timers]]
* [[FS20_Allgemein#FS20_Adressierung_.28Adressierung_der_Ger.C3.A4te.29|FS20 Adressierung (Hauscode, Einzeladressen)]]

[[Kategorie:Hardware]]

FS20 PIRA Infrarot-Bewegungsmelder

2024-12-27T15:14:01Z

Soulman:

{{Infobox Hardware
|Bild=FS20-PIRA.jpg
|Bildbeschreibung= FS20 PIRA mit Streichhölzern zum Größenvergleich
|HWProtocol=FS20
|HWType=Sensor
|HWCategory=FS20
|HWComm=868MHz
|HWChannels=2
|HWVoltage=3V
|HWPowerConsumption=ca. 1 Jahr bei 1000 x Senden täglich
|HWPoweredBy=Batterie
|HWSize=53x50x35mm
|HWDeviceFHEM=FS20

|HWManufacturer=ELV Elektronik AG
}}
Infrarot-Bewegungsmelder in kompakten Gehäuse, auch für Außeneinsatz geeignet.

Das Gerät ist neu nicht mehr verfügbar, da FS20 von ELV insgesamt abgekündigt ist und nur noch Restbestände verkauft werden (2024)

= Features =
Wasserdichtes IP65-Gehäuse, das zum Betätigen der Tasten aufgeschraubt werden muss.
Im Innenbereich durch geringe Grösse unauffällig.

Features unterscheiden sich darüber hinaus kaum von anderen FS 20 Infrarot-Bewegungsmeldern, also 2 Sendekanäle, Dämmerungsautomatik, einstellbarer Sendeabstand (8,24,56,120 Sekunden), Dimmbefehle etc.

Das Gerät ist vergleichsweise teuer (Mai 2018: ca. 45€).

= Hinweise zum Betrieb mit FHEM =
Es gibt Anzeichen dafür, dass die FS20PIRA besser empfangen werden, wenn das CUL/CUN auf 868.3 MHz und eine leicht erweiterte Bandbreite von bWidth:464KHz eingestellt sind.

Beim kürzesten einstellbaren Sendeintervall (8 Sekunden), provoziert der PIRA schnell [[LOVF]] Meldungen in FHEM , wenn jede Bewegung in FHEM eine Aktion auslöst, die ihrerseits einen Sendebefehl beinhaltet. Im schlimmsten Fall ist das Sendekontingent einer Stunde nach 22 Minuten verbraucht, bei Aussendung von 2 Befehlen je Bewegung sogar schon nach 11 Minuten.

= Bekannte Probleme =
Die benötigten 2 x Batterien "Lady" LR1/HR1/E90 sind nicht überall erhältlich und teuer (2024: ca. 1 - 1,50 €/Stck.), da unübliche Grösse (keine Mignon oder Micro).
Jedoch: Lebensdauer auch bei 50-100 Auslösungen pro Tag mehrere Jahre.

Wie bei allen Geräten im 868 Mhz Band gilt die [[1%_Regel]] auch für Bewegungsmelder. Der FS20 PIRA gestattet als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist nicht nur das Sendekontigent einer FHEM Zentrale die aufgrund der Meldungen Aktionen auslost (siehe oben), sondern auch das Kontingent des PIRA selbst schnell verbraucht. Das Sendekontingent einer Stunde ist nach 22 Minuten aufgebraucht und danach wird der Bewegungsmelder für den Rest der Stunde nicht mehr senden. Dies ist insbesondere zu beachten, wenn der Sensor als Anwesenheitserkennung in einem Raum verwendet werden soll, der Sensor wäre dann für mehr als die Hälfte der Zeit "blind".
Der Sendeabstand 8 Sekunden ist daher eher zu vermeiden, generell ist es günstig, den längsten für den konkreten Anwendungsfall noch sinnvollen Abstand zu wählen.

= Links =
* [https://files.elv.com/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleiteung] bei ELV
* [https://web.archive.org/web/20100415071131/http://www.elv-downloads.de/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|P]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]
[[Kategorie:868MHz]]

FS20 PIRA Infrarot-Bewegungsmelder

2024-12-27T15:08:18Z

Soulman: /* Bekannte Probleme */

{{Infobox Hardware
|Bild=FS20-PIRA.jpg
|Bildbeschreibung= FS20 PIRA mit Streichhölzern zum Größenvergleich
|HWProtocol=FS20
|HWType=Sensor
|HWCategory=FS20
|HWComm=868MHz
|HWChannels=2
|HWVoltage=3V
|HWPowerConsumption=ca. 1 Jahr bei 1000 x Senden täglich
|HWPoweredBy=Batterie
|HWSize=53x50x35mm
|HWDeviceFHEM=FS20

|HWManufacturer=ELV Elektronik AG
}}
Infrarot-Bewegungsmelder in kompakten Gehäuse, auch für Außeneinsatz geeignet.
= Features =
Wasserdichtes IP65-Gehäuse, das zum Betätigen der Tasten aufgeschraubt werden muss.
Im Innenbereich durch geringe Grösse unauffällig.

Features unterscheiden sich darüber hinaus kaum von anderen FS 20 Infrarot-Bewegungsmeldern, also 2 Sendekanäle, Dämmerungsautomatik, einstellbarer Sendeabstand (8,24,56,120 Sekunden), Dimmbefehle etc.

Das Gerät ist vergleichsweise teuer (Mai 2018: ca. 45€).

= Hinweise zum Betrieb mit FHEM =
Es gibt Anzeichen dafür, dass die FS20PIRA besser empfangen werden, wenn das CUL/CUN auf 868.3 MHz und eine leicht erweiterte Bandbreite von bWidth:464KHz eingestellt sind.

Beim kürzesten einstellbaren Sendeintervall (8 Sekunden), provoziert der PIRA schnell [[LOVF]] Meldungen in FHEM , wenn jede Bewegung in FHEM eine Aktion auslöst, die ihrerseits einen Sendebefehl beinhaltet. Im schlimmsten Fall ist das Sendekontingent einer Stunde nach 22 Minuten verbraucht, bei Aussendung von 2 Befehlen je Bewegung sogar schon nach 11 Minuten.

= Bekannte Probleme =
Die benötigten 2 x Batterien "Lady" LR1/HR1/E90 sind nicht überall erhältlich und teuer (2024: ca. 1 - 1,50 €/Stck.), da unübliche Grösse (keine Mignon oder Micro).
Jedoch: Lebensdauer auch bei 50-100 Auslösungen pro Tag mehrere Jahre.

Wie bei allen Geräten im 868 Mhz Band gilt die [[1%_Regel]] auch für Bewegungsmelder. Der FS20 PIRA gestattet als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist nicht nur das Sendekontigent einer FHEM Zentrale die aufgrund der Meldungen Aktionen auslost (siehe oben), sondern auch das Kontingent des PIRA selbst schnell verbraucht. Das Sendekontingent einer Stunde ist nach 22 Minuten aufgebraucht und danach wird der Bewegungsmelder für den Rest der Stunde nicht mehr senden. Dies ist insbesondere zu beachten, wenn der Sensor als Anwesenheitserkennung in einem Raum verwendet werden soll, der Sensor wäre dann für mehr als die Hälfte der Zeit "blind".
Der Sendeabstand 8 Sekunden ist daher eher zu vermeiden, generell ist es günstig, den längsten für den konkreten Anwendungsfall noch sinnvollen Abstand zu wählen.

= Links =
* [https://files.elv.com/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleiteung] bei ELV
* [https://web.archive.org/web/20100415071131/http://www.elv-downloads.de/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|P]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]
[[Kategorie:868MHz]]

FS20 PIRA Infrarot-Bewegungsmelder

2024-12-27T15:05:35Z

Soulman: /* Features */

{{Infobox Hardware
|Bild=FS20-PIRA.jpg
|Bildbeschreibung= FS20 PIRA mit Streichhölzern zum Größenvergleich
|HWProtocol=FS20
|HWType=Sensor
|HWCategory=FS20
|HWComm=868MHz
|HWChannels=2
|HWVoltage=3V
|HWPowerConsumption=ca. 1 Jahr bei 1000 x Senden täglich
|HWPoweredBy=Batterie
|HWSize=53x50x35mm
|HWDeviceFHEM=FS20

|HWManufacturer=ELV Elektronik AG
}}
Infrarot-Bewegungsmelder in kompakten Gehäuse, auch für Außeneinsatz geeignet.
= Features =
Wasserdichtes IP65-Gehäuse, das zum Betätigen der Tasten aufgeschraubt werden muss.
Im Innenbereich durch geringe Grösse unauffällig.

Features unterscheiden sich darüber hinaus kaum von anderen FS 20 Infrarot-Bewegungsmeldern, also 2 Sendekanäle, Dämmerungsautomatik, einstellbarer Sendeabstand (8,24,56,120 Sekunden), Dimmbefehle etc.

Das Gerät ist vergleichsweise teuer (Mai 2018: ca. 45€).

= Hinweise zum Betrieb mit FHEM =
Es gibt Anzeichen dafür, dass die FS20PIRA besser empfangen werden, wenn das CUL/CUN auf 868.3 MHz und eine leicht erweiterte Bandbreite von bWidth:464KHz eingestellt sind.

Beim kürzesten einstellbaren Sendeintervall (8 Sekunden), provoziert der PIRA schnell [[LOVF]] Meldungen in FHEM , wenn jede Bewegung in FHEM eine Aktion auslöst, die ihrerseits einen Sendebefehl beinhaltet. Im schlimmsten Fall ist das Sendekontingent einer Stunde nach 22 Minuten verbraucht, bei Aussendung von 2 Befehlen je Bewegung sogar schon nach 11 Minuten.

= Bekannte Probleme =
Die benötigten 2 x Batterien "Lady" LR1/HR1/E90 sind nicht überall erhältlich und teuer (Mai 2018: ca. 1 - 1,50 €/Stck.), da unübliche Grösse (keine Mignon oder Micro).
Jedoch: Lebensdauer auch bei 50-100 Auslösungen pro Tag mehrere Jahre.

Wie bei allen Geräten im 868 Mhz Band gilt die [[1%_Regel]] auch für Bewegungsmelder. Der FS20 PIRA gestattet als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist nicht nur das Sendekontigent einer FHEM Zentrale die aufgrund der Meldungen Aktionen auslost (siehe oben), sondern auch das Kontingent des PIRA selbst schnell verbraucht. Das Sendekontingent einer Stunde ist nach 22 Minuten aufgebraucht und danach wird der Bewegungsmelder für den Rest der Stunde nicht mehr senden. Dies ist insbesondere zu beachten, wenn der Sensor als Anwesenheitserkennung in einem Raum verwendet werden soll, der Sensor wäre dann für mehr als die hälfte der Zeit "blind".
Es sollte immer ein für den Anwendungsfall noch sinnvoller möglichst grosser Sendeabstand eingestellt werden. Eine garantierte Abdeckung einer Stunde ist nur bei mindestens 22 Sekunden Sendeabstand gewährleistet.

= Links =
* [https://files.elv.com/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleiteung] bei ELV
* [https://web.archive.org/web/20100415071131/http://www.elv-downloads.de/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|P]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]
[[Kategorie:868MHz]]

FS20 PIRA Infrarot-Bewegungsmelder

2024-12-27T15:03:58Z

Soulman: /* Bekannte Probleme */

{{Infobox Hardware
|Bild=FS20-PIRA.jpg
|Bildbeschreibung= FS20 PIRA mit Streichhölzern zum Größenvergleich
|HWProtocol=FS20
|HWType=Sensor
|HWCategory=FS20
|HWComm=868MHz
|HWChannels=2
|HWVoltage=3V
|HWPowerConsumption=ca. 1 Jahr bei 1000 x Senden täglich
|HWPoweredBy=Batterie
|HWSize=53x50x35mm
|HWDeviceFHEM=FS20

|HWManufacturer=ELV Elektronik AG
}}
Infrarot-Bewegungsmelder in kompakten Gehäuse, auch für Außeneinsatz geeignet.
= Features =
Wasserdichtes IP65-Gehäuse, das zum Betätigen der Tasten aufgeschraubt werden muss.
Im Innenbereich durch geringe Grösse unauffällig.

Features unterscheiden sich darüber hinaus kaum von anderen FS 20 Infrarot-Bewegungsmeldern, also 2 Sendekanäle, Dämmerungsautomatik, einstellbarer Sendeabstand etc.

Gerät ist vergleichsweise teuer (Mai 2018: ca. 45€).

= Hinweise zum Betrieb mit FHEM =
Es gibt Anzeichen dafür, dass die FS20PIRA besser empfangen werden, wenn das CUL/CUN auf 868.3 MHz und eine leicht erweiterte Bandbreite von bWidth:464KHz eingestellt sind.

Beim kürzesten einstellbaren Sendeintervall (8 Sekunden), provoziert der PIRA schnell [[LOVF]] Meldungen in FHEM , wenn jede Bewegung in FHEM eine Aktion auslöst, die ihrerseits einen Sendebefehl beinhaltet. Im schlimmsten Fall ist das Sendekontingent einer Stunde nach 22 Minuten verbraucht, bei Aussendung von 2 Befehlen je Bewegung sogar schon nach 11 Minuten.

= Bekannte Probleme =
Die benötigten 2 x Batterien "Lady" LR1/HR1/E90 sind nicht überall erhältlich und teuer (Mai 2018: ca. 1 - 1,50 €/Stck.), da unübliche Grösse (keine Mignon oder Micro).
Jedoch: Lebensdauer auch bei 50-100 Auslösungen pro Tag mehrere Jahre.

Wie bei allen Geräten im 868 Mhz Band gilt die [[1%_Regel]] auch für Bewegungsmelder. Der FS20 PIRA gestattet als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist nicht nur das Sendekontigent einer FHEM Zentrale die aufgrund der Meldungen Aktionen auslost (siehe oben), sondern auch das Kontingent des PIRA selbst schnell verbraucht. Das Sendekontingent einer Stunde ist nach 22 Minuten aufgebraucht und danach wird der Bewegungsmelder für den Rest der Stunde nicht mehr senden. Dies ist insbesondere zu beachten, wenn der Sensor als Anwesenheitserkennung in einem Raum verwendet werden soll, der Sensor wäre dann für mehr als die hälfte der Zeit "blind".
Es sollte immer ein für den Anwendungsfall noch sinnvoller möglichst grosser Sendeabstand eingestellt werden. Eine garantierte Abdeckung einer Stunde ist nur bei mindestens 22 Sekunden Sendeabstand gewährleistet.

= Links =
* [https://files.elv.com/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleiteung] bei ELV
* [https://web.archive.org/web/20100415071131/http://www.elv-downloads.de/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|P]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]
[[Kategorie:868MHz]]

Trick der Woche

2024-01-08T17:53:59Z

Soulman: /* Aktoren über mehrere Funkschnittstellen ansprechen */

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== August 2022==
=== Update ===
Wenn der Befehl "Update" nicht funktioniert und insbesondere die Fehlermeldung ''Bad hostname 'fhem.de:80''' zurück gibt, kann es sinnvoll sein, den Parameter -noSSL zu versuchen. Details dazu im Artikel [[Update]]

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

Die oben erwähnten "if" sind "perl if"s. Die Verwendung des FHEM Modul DOIF ist deutlich langsamer. Die Betrachtung betrifft sowieso nur langsame Host-Systeme mit gleichzeitig vielen defines. Bei Verwendung z.b. einen Raspberry Pi 4 oder schnellerem Host dürften die Unterschiede vernachlässigbar sein.

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt wird, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich Strom durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL1 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

Trick der Woche

2024-01-08T17:48:57Z

Soulman: /* Performance von Notifys */

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== August 2022==
=== Update ===
Wenn der Befehl "Update" nicht funktioniert und insbesondere die Fehlermeldung ''Bad hostname 'fhem.de:80''' zurück gibt, kann es sinnvoll sein, den Parameter -noSSL zu versuchen. Details dazu im Artikel [[Update]]

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

Die oben erwähnten "if" sind "perl if"s. Die Verwendung des FHEM Modul DOIF ist deutlich langsamer. Die Betrachtung betrifft sowieso nur langsame Host-Systeme mit gleichzeitig vielen defines. Bei Verwendung z.b. einen Raspberry Pi 4 oder schnellerem Host dürften die Unterschiede vernachlässigbar sein.

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt wird, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich Strom durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL2 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

CUL

2023-12-06T16:05:12Z

Soulman: Umformatiert, typos

Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.

== CUL HW ==
Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongle des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkattached Module ([[CUN]]O), Module zum direkten Aufstecken auch einen Raspberry Pi ([[COC]]), und auf Arduino basierende Lösungen ([[SIGNALduino]]).

== Einführung ==
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.

Das CUL kann mittels des '''[[CUL (Modul)|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== Definition in FHEM ==
Das CUL wird definiert mit

<code>define <name> CUL <device> <FHTID> </code>

als z.b.:

<code>define myCUL CUL /dev/ttyUSB0 0000</code>

Da FHT zur Heizungssterung kaum noch eine Rolle spielen dürfte ist die Vergabe der FHT-ID 0000 sinnvoll, da das CUL dann nicht auf FHT Communication achtet.

Was <device> ist hängt von der Art des CUL ab:
=== Geräte, die an USB angeschlossen sind (CUL/CUN) ===
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden:
modprobe usbserial vendor=0x03eb product=0x204b
In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.

Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.: /dev/ttyACM0@38400.

Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.

=== Geräte, die mit dem Netzwerk verbunden sind (CUN(O)) ===
<device> gibt die Hostadresse:Port des Gerätes an, z.B. 192.168.0.244:2323

Weiteres in der commandref [https://fhem.de/commandref.html#CUL]

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen.

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.

Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl).

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang="bash">
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.

Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik.
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.

Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne.

Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene.

Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser.

Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.

Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 MHz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 MHz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 MHz
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz

== Bekannte Probleme ==

=== RF-Tuning ===
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt
* CUL commandref [https://fhem.de/commandref.html#CUL]

[[Kategorie:Interfaces]]
[[Kategorie:CUL|!]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

CUL

2023-12-06T16:00:11Z

Soulman: definition ergänzt

Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.

Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.

Das CUL kann mittels des '''[[CUL (Modul)|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== CUL HW ==
Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongel des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkaattached Module (CUNO), modulle zum direkten aufstecken auch einen Rapbi (COC), und auf Ardunino basierenende Lösugnen.

== Definition in FHEM ==
Das CUL wird definiert mit

<code>define <name> CUL <device> <FHTID> </code>

als z.b.:

<code>define myCUL CUL /dev/ttyUSB0 0000</code>

Da FHT zur Heizungssterung kaum noch eine Rolle spielen dürfte ist die Vergabe der FHT-ID 0000 sinnvoll, da das CUL dann nicht auf FHT Communication achtet.

Was <device> ist hängt von der Art des CUL ab:
=== Geräte, die an USB angeschlossen sind (CUL/CUN) ===
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden:
modprobe usbserial vendor=0x03eb product=0x204b
In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.

Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.: /dev/ttyACM0@38400.

Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.

=== Geräte, die mit dem Netzwerk verbunden sind (CUN(O)) ===
<device> gibt die Hostadresse:Port des Gerätes an, z.B. 192.168.0.244:2323

Weiteres in der commandref [https://fhem.de/commandref.html#CUL]

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen.

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.

Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl).

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang="bash">
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.

Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik.
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.

Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne.

Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene.

Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser.

Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.

Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 MHz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 MHz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 MHz
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz

== Bekannte Probleme ==

=== RF-Tuning ===
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt
* CUL commandref [https://fhem.de/commandref.html#CUL]

[[Kategorie:Interfaces]]
[[Kategorie:CUL|!]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

CUL

2023-12-06T15:17:29Z

Soulman: Umfangreiche Löschung von forenartigen Einträgen der Lösungsgeschichte einer Einzelperson, siehe Diskussion

Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.

Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben.

Das CUL kann mittels des '''[[CUL (Modul)|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}}

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen.

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.

Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl).

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden.
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang="bash">
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.

Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik.
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.

Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne.

Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene.

Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser.

Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.

Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 MHz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 MHz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 MHz
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz

== Bekannte Probleme ==

=== RF-Tuning ===
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt

[[Kategorie:Interfaces]]
[[Kategorie:CUL|!]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Diskussion:CUL

2023-12-06T15:16:23Z

Soulman:

== Abschnittslöschungen aus dem Artikel==
Ich habe mir erlaubt mal diesen ganzen Abschnitt mit den LockUps, Kabeldicken, ach ne doch nicht?, nanCUL Problemen und so aus dem Artikel zu entfernen.
Das sind im Grunde eher Forumseinträge und es hilft dem Interessierten nicht unbedingt weiter wenn er im Artikel lesen muss, was eine einzelner Nutzer mal dachte was seine spezifischen Probleme löste und das war - "update"- dann doch nicht der Fall.

Auch die Hinweise auf eine Fehlkonfiguration von Sendpool gehört hier nicht rein, wenn schon dann in den Artikel zu "Sendpool". Es so darzustellen als sei es ein Bug in der culfw, weil das CUL bei Fehlkonfiguration ... fehlfunktioniert ... halte ich auch für eher weit hergeholt.

Kurzum: So funktionieren Wikiartikel eher nicht denke ich, da sollten gesicherte Erkenntnisse stehen.

Insgesamt muss das, wenn es drin bleiben soll, deutlich gekürzt und die Vermutungen und persönliche Einzelerfahrungen bereinigt werden.

_______________gelöschter___abschnitt___________________________________________________

Übertragungs-Stall nach zu vielen Einträgen in der Queue

Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.

Harter Lockup des CUL

Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per [https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux uhubctl].
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.

Device-Attribute wie <code>version</code> etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...

(nanoCUL; V 1.26.00 a-culfw Build: 267).

UPDATE: die Lösung des Problems steht evtl. im Forum (Lockup beseitigt durch Optiboot bootloader):
: {{Link2Forum|Topic=73144|Message=977406|LinkText=[Gelöst] Nanocul LED blinkt schnell}}.
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"

--> Empfehlung: Redundanz für nahtlosen Weiterbetrieb schaffen: weiteren CUL kaufen, dessen Inbetriebnahme erfolgreich testen, dann einen der CULs auf optiboot umflashen (...lassen? Siehe bekanntes Online-Auktionshaus...), und testen.
(Idee: dreckiger Workaround: mit mehreren CULs könnte man sich auch ein Script schreiben, das zwischen ihnen umschalten kann, sobald es mal wieder Probleme gibt)

Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): [https://github.com/heliflieger/a-culfw/issues/23 Selfmade Cul freezing with blinking LED when sending ITv3 messages #23]

Randnotiz: interessante Optiboot-Modifikation, die es trotz Hardware-Sperren erreicht, per Software den Bootloader-Bereich zu flashen: [https://hackaday.com/2015/07/03/arduinos-and-other-avrs-write-to-own-flash/ Arduinos (and Other AVRs) Write To Own Flash]

Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt in diesem {{Link2Forum|Topic=77380|Message=783352|LinkText=Forenbeitrag}}.
UPDATE: ein erster Test (Device herausfinden [https://unix.stackexchange.com/questions/81754/how-to-match-a-ttyusbx-device-to-a-usb-serial-device] via fhem log infos etc., fhem shutdown, usbreset, start fhem) hat bei mir nicht funktioniert ("get ccconf" --> "No FD").

Ständige Lockups
Falls Lockups gefühlt "ständig" passieren sollten (alle paar Tage, oder fast täglich insb. bei warmem Wetter), dann könnte es z.B. an einem schlechten/kaputten Kabel liegen (bei mir: dünne USB-2-"Drachenschnur", mit Bissmarken o.ä. - durch ein gutes dickes USB-3-Kabel ersetzt und sofort dramatisch robuster - UPDATE: das war der erste Eindruck innerhalb weniger Tage, aber längerfristig war es gefühlt nicht wirklich besser).

_____________________________________________________________________________________

Ich will hier dem Ersteller dieses Erfahrungsbereichtes nicht auf die Füsse treten, zumal man da eine "Leidengeschichte"rauslesen kann, aber wir sollten überlegen, was andern Lesern tatsächlich verwertbare Informationen liefert.
--[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 16:15, 6. Dez. 2023 (CET)

Diskussion:CUL

2023-12-06T15:15:41Z

Soulman: Begründung einer grösseren Löschung

Ich habe mir erlaubt mal diesen ganzen Abschnitt mit den LockUps, Kabeldicken, ach ne doch nicht?, nanCUL Problemen und so aus dem Artikel zu entfernen.
Das sind im Grunde eher Forumseinträge und es hilft dem Interessierten nicht unbedingt weiter wenn er im Artikel lesen muss, was eine einzelner Nutzer mal dachte was seine spezifischen Probleme löste und das war - "update"- dann doch nicht der Fall.

Auch die Hinweise auf eine Fehlkonfiguration von Sendpool gehört hier nicht rein, wenn schon dann in den Artikel zu "Sendpool". Es so darzustellen als sei es ein Bug in der culfw, weil das CUL bei Fehlkonfiguration ... fehlfunktioniert ... halte ich auch für eher weit hergeholt.

Kurzum: So funktionieren Wikiartikel eher nicht denke ich, da sollten gesicherte Erkenntnisse stehen.

Insgesamt muss das, wenn es drin bleiben soll, deutlich gekürzt und die Vermutungen und persönliche Einzelerfahrungen bereinigt werden.

_______________gelöschter___abschnitt___________________________________________________

Übertragungs-Stall nach zu vielen Einträgen in der Queue

Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL').
Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen [[Sendpool]]-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den [[Sendpool]]-Mechanismus (noch) gar nicht unterstützt!
Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne [[Sendpool]]-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.

Harter Lockup des CUL

Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED.
Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per [https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux uhubctl].
Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.

Device-Attribute wie <code>version</code> etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...

(nanoCUL; V 1.26.00 a-culfw Build: 267).

UPDATE: die Lösung des Problems steht evtl. im Forum (Lockup beseitigt durch Optiboot bootloader):
: {{Link2Forum|Topic=73144|Message=977406|LinkText=[Gelöst] Nanocul LED blinkt schnell}}.
[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] scheint das zu bestätigen:
"Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen.
Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"

--> Empfehlung: Redundanz für nahtlosen Weiterbetrieb schaffen: weiteren CUL kaufen, dessen Inbetriebnahme erfolgreich testen, dann einen der CULs auf optiboot umflashen (...lassen? Siehe bekanntes Online-Auktionshaus...), und testen.
(Idee: dreckiger Workaround: mit mehreren CULs könnte man sich auch ein Script schreiben, das zwischen ihnen umschalten kann, sobald es mal wieder Probleme gibt)

Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): [https://github.com/heliflieger/a-culfw/issues/23 Selfmade Cul freezing with blinking LED when sending ITv3 messages #23]

Randnotiz: interessante Optiboot-Modifikation, die es trotz Hardware-Sperren erreicht, per Software den Bootloader-Bereich zu flashen: [https://hackaday.com/2015/07/03/arduinos-and-other-avrs-write-to-own-flash/ Arduinos (and Other AVRs) Write To Own Flash]

Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt in diesem {{Link2Forum|Topic=77380|Message=783352|LinkText=Forenbeitrag}}.
UPDATE: ein erster Test (Device herausfinden [https://unix.stackexchange.com/questions/81754/how-to-match-a-ttyusbx-device-to-a-usb-serial-device] via fhem log infos etc., fhem shutdown, usbreset, start fhem) hat bei mir nicht funktioniert ("get ccconf" --> "No FD").

Ständige Lockups
Falls Lockups gefühlt "ständig" passieren sollten (alle paar Tage, oder fast täglich insb. bei warmem Wetter), dann könnte es z.B. an einem schlechten/kaputten Kabel liegen (bei mir: dünne USB-2-"Drachenschnur", mit Bissmarken o.ä. - durch ein gutes dickes USB-3-Kabel ersetzt und sofort dramatisch robuster - UPDATE: das war der erste Eindruck innerhalb weniger Tage, aber längerfristig war es gefühlt nicht wirklich besser).

_____________________________________________________________________________________

Ich will hier dem Ersteller dieses Erfahrungsbereichtes nicht auf die Füsse treten, zumal man da eine "Leidengeschichte"rauslesen kann, aber wir sollten überlegen, was andern Lesern tatsächlich verwertbare Informationen liefert.
--[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 16:15, 6. Dez. 2023 (CET)

FHT80TF-2

2023-11-16T15:27:20Z

Soulman: Ergänzungen

{{Infobox Hardware
|Bild=FHT80TF.jpg
|Bildbeschreibung=Tür-/ Fensterkontakt, kleine Bauform
|HWProtocol=FHT
|HWType=Sensor
|HWCategory=FHT
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=3V
|HWPowerConsumption=Batterielaufzeit bis zu 5 Jahre
|HWPoweredBy=2xLR03 (AAA)
|HWSize=25x117x17 mm (Sensor) 11x48x12 mm (Magnet)
|HWDeviceFHEM=[[CUL_FHTTK|09_CUL_FHTTK.pm]]
|HWManufacturer=ELV
}}

Der '''FHT80TF Tür-/Fensterkontakt''', ein Zubehörteil zum [[FHT80b]] Raumregler, dient zur Erkennung einer offenen Tür, eines offenen Fensters oder ähnlicher Meldesituationen. Das Geräte existiert in zwei Bauformen, dem älteren und deutlich grösseren FHT80TF und dem kleineren FHT80TF-2 (Bild). Die Geräte sind funktional identisch. Sie können auch ohne FHT Raumregler verwendet und durch das Modul [[CUL FHTTK]] ausgewertet werden.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''{{Link2Forum|Topic=60219}}

== Features ==
Mittels des FHT80TF kann überprüft werden, ob eine Tür oder ein Fenster im zu heizenden Raum offen ist. Ist dies der Fall, wird der FHT80b, mit dem der Tür/Fensterkontakt gepairt ist, die Heiztemperatur auf die separat einstellbare "Fenstertemperatur" einregeln. Wird das Fenster (und damit der Kontakt) wieder geschlossen, so regelt der FHT80b wieder auf die aktuell eingestellte Temperatur hoch.

Der FHT80TF besteht aus dem eigentlichen Gehäuse mit Sender und Batteriefach (2x Micro) und einem separaten Magneten, der im geschlossenen Zustand des Fensters oder der Tür einen Reedkontakt im Inneren des Sendergehäuses betätigt. Das FHT80TF Gehäuse hat zwecks wahlfreier Installation einen solchen Kontakt auf beiden Gehäuseseiten, sowie einen Anschluss für externe Kontakte (normally Closed). Es kann nur einer der internen Kontakte verwendet werden, ein interner und externe Kontakte oder nur externe. Alle Kontakte sind in Reihe geschaltet, es ist also keine Einzelauswertung möglich.

== Hinweise zum Betrieb mit FHEM ==
In der Standard FHT/FS20 Umgebung ist die Einsetzbarkeit des FHT80TF eingeschränkt, da er nur vom gepairten FHT80b zwecks Temperaturabsenkung ausgewertet wird.

FHEM kann einen FHT80TF jedoch überdies direkt als Device auswerten, sodass sich damit ähnlich wie beim HMS Device [[HMS 100 TFK]] oder dem FS20 TFK Schließzustände von Türen, Toren und Fenstern direkt auswerten lassen. Voraussetzung ist allerdings ein [[CUL]], CUNO oder COC als [[Interface|Funkschnittstelle / Zentrale]].

Der sechsstellige (hexadezimale) Devicecode des FHT80TF lässt sich nicht ändern und wird während der Produktion eindeutig vergeben. Es wird also kein Hauscode vergeben und der FHT80TF ist auch kein FS20 Sender.
=== Definition ===
Der jeweilige Devicecode kann über das Logfile ermittelt werden. Wird ein neuer Türkontakt erkannt, erscheint im Logfile "FHTTK unknown device 123abc, please define it." (wobei 123abc ein Stellvertreter für den tatsächlichen Devicecode des Fensterkontaktes ist, der dem Logfileeintrag zu entnehmen ist), der Fensterkontakt kann dann mit
:<code>define <name> [[CUL_FHTTK]] <devicecode></code>
definiert werden.

Im Gegensatz zum FS20 TFK wird die Statusänderung des Kontaktes nicht sofort übermittelt. Die Sendung wird nicht durch Öffnen oder Schliessen unmittelbar ausgelöst, vielmehr sendet das Modul in Abständen zwischen um die vier Minuten eine Statusnachricht über den aktuellen Zustand der Kontakte. Mehr dazu unter [[FHT80TF-2#Protokoll|Protokoll]]. Der Einsatz in [[Alarmanlage|Alarmanlagen]] oder ähnlichen Anwendungen ist daher nur eingeschränkt möglich. Vorteilhaft ist jedoch der geringere Preis gegenüber einem FS20 TFK.

=== Anwendungsbeispiel ===
Die Programmierung eines [[notify]] ist unter [[FHTTK: Benachrichtigung bei offenem Fenster]] beschrieben.

Im Wesentlichen ist zu beachten, dass das FHTTK neben dem Fensterzustand (Open oder Closed) auch den Batteriezustand (ok oder Low.Batt) meldet. Ein bedingtes Notify muss also definieren, welcher Wert abgefragt werden soll.

z. B.: <code>define mach_was_bei_Fenster_auf notify myFHTTK:Window:Open ...</code>

Über die Attribute bei der Definition können im Webinterface auch Zustand und Batteriestatus als Icon angezeigt werden.

z. B.: <code>attr Tuer_Balkon devStateIcon Open:fts_door_open@red Closed:fts_door@green Closed,.Low.Batt:measure_battery_25@yellow Open,.Low.Batt:measure_battery_25@red</code>

Hier würde der Zustand des FHTTK bei geöffneter Tür mit einen roten "Door Open" Icon, und im geschlossen Zustan mit dem "Door" Icon dargestellt. Wenn jedoch die Batterie sich dem Ende nähert, die offene Tür mit einem roten Batterie Leer Icon und wenn sie geschlossen ist mit gelben Batterie Leer Icon.

Den Batteriezustand zu beachten ist beim FHTTK wichtig, siehe unten.

== Batterielebensdauer ==
Der Stromverbrauch des Gerätes ist sehr gering. (Gute) Batterien halten mehrere Jahre. Da in diesen Zeiträumen die Selbstentladung eine ebenso grosse Rolle spielt wie der Stromverbrauch des Gerätes, halten die Batterien um so länger, je '''kälter''' es ist (Selbstentladung sinkt mit der Temperatur deutlich ab). Im Aussenbereich wurden Batterielebensdauern von bis zu acht Jahren beobachtet.

== Bekannte Probleme ==
* Bei Unterspannung (fast leere Batterie) fangen vor allem die FHT80TF (alte grösser Bauform) gelegentlich an, wild auf dem 868 MHz Band zu funken und blockieren hierdurch fast alle anderen Funkteilnehmer. Besonders betroffen sind FS20 Sensoren und Aktoren sowie FHT Kommunikation, aber auch HM, MAX! und ähnlich wird gestört. Dieser Effekt tritt ab etwa 1,1 Volt Zellenspannung ein. Der Zeitraum von der erste LOW BATT Warnung bis zum Effekt ist in der Regel sehr kurz, etwa 1-3 Tage. Daher bei der ersten Warnung Batterien sofort wechseln.

== Sonstiges ==
* Das Gerät arbeitet zuverlässig bis ca. -20 Grad, kann bei entsprechend wasserdichter Anbringung auch im Aussenbereich eingesetzt werden.
* Durch die Möglichkeit, einen eigenen Kontakt an Klemmen im Inneren anzuschliessen, lassen sich auch Lösungen für andere Einsatzzwecke realisieren.
* Da der Tür-/Fensterkontakt von alleine ca. alle vier Minuten seinen Status sendet, lässt er sich auch gut zum Ausmessen der [[SlowRF]] Funklage eines Gebäudes verwenden. Den Tür-/Fensterkontakt im Haus an die zu untersuchenden Stellen legen und mittels FHEM RSSI beobachten. FS20 / FHT etc. arbeitet gut bei RSSI oberhalb -80, mäßig zwischen -80 und -85 und bei RSSI kleiner als -85 unzuverlässig bis gar nicht.
* Die "Antenne" der älteren Bauform ist eine Attrappe

== Protokoll ==

Das benutzte Protokoll der FHT Baugruppen wird auf der Seite von FHZ4Linux [http://fhz4linux.info/tiki-index.php?page=FHT%20protocol FHT Protokoll] beschrieben. Ein FHT80TF-2 sendet in bestimmten Zeitabständen seinen momentanen Status. Dabei kann man in einen Hauptintervall und in einen Statusänderungsintervall unterscheiden. Erst genannter Intervall sendet immer in einem gleichen Abstand von 240 + x Sekunden seinen Status (unten Fett hervorgehoben) und zweit genannter geschieht intern immer in (240 + x) / 4 Sekunden. Sollte nun innerhalb des Hauptintervalls ein Statuswechsel von "on" auf "off" bzw. "Open" auf "Closed" eintreten, wird nach Ablauf von 1x (240 + x) / 4 (Statusänderungsintervall) der neue Status gesendet und noch einmal nach (240 + x) / 4 wiederholt. Danach verfällt der TF-2 wieder in den Hauptintervall, beginnend bei 0. Die Variable x wird aus dem Adressbyte vom Fensterkontakt berechnet, ähnlich dem Intervall für den [[FHT80b#Hinweise_zum_Betrieb_mit_FHEM|FHT8v]]. Es werden nur die 3 niederwertigen Bits verwendet. Beispiel: FHTTF-2 ID 8631'''0A''' -> 0x0A & 0x07 = '''2''' -> (16 - ('''2''' * 2)) = 12 Sekunden. 
 
Formel: 
:x = (16 - (Adressbyte & 0x7) * 2) 
:y = 240 + x
:y == Hauptintervall von 4 min + x
 
{| class="wikitable"
|-
! FHT Code !! HC1 !! HC2 !! Adressbyte !! Adressbyte & 0x7 !! Intervall
|-
| F7 FD 57 || 1111 0111 || 1111 1101 || 0101 0'''111''' || 7 || 4:02
|-
| 83 C0 D7 || 1000 0011 || 1100 0000 || 1101 0'''111''' || 7 || 4:02
|-
| 86 30 0A || 1000 0110 || 0011 0000 || 0000 1'''010''' || 2 || 4:12
|-
| 86 31 0A || 1000 0110 || 0011 0001 || 0000 1'''010''' || 2 || 4:12
|-
| CA 54 01 || 1100 1010 || 0101 0100 || 0000 0'''001''' || 1 || 4:14
|-
| 64 C8 70 || 0110 0100 || 1100 1000 || 0111 0'''000''' || 0 || 4:16
|}
 
<code>
2013-10-07_21:17:15 Fenster Window: off 
2013-10-07_21:21:17 Fenster Window: on 
2013-10-07_21:22:17 Fenster Window: on 
2013-10-07_21:26:19 Fenster Window: on 
2013-10-07_21:30:21 Fenster Window: on 
'''2013-10-07_21:34:23 Fenster Window: on''' 
'''2013-10-07_21:38:25 Fenster Window: on''' 
2013-10-07_21:50:32 Fenster Window: on 
2013-10-07_21:54:34 Fenster Window: off 
2013-10-07_21:55:34 Fenster Window: off 
2013-10-07_21:59:36 Fenster Window: off 
2013-10-07_22:03:38 Fenster Window: off 
2013-10-07_22:06:40 Fenster Window: on 
2013-10-07_22:07:40 Fenster Window: on 
2013-10-07_22:08:41 Fenster Window: off 
2013-10-07_22:09:41 Fenster Window: off 
2013-10-07_22:13:43 Fenster Window: off 
</code>
 
Ergänzung zur Synchronisierung:

Der Synchronisierungsprozess mit einem FHT 80 Regler wird mit einer Nachricht 0x0C (Befehlsbyte) begonnen und einem folgenden 0x0F (Befehlsbyte) abgeschlossen. Erst dann ist der TF am FHT angemeldet.

== Links ==
* Bedienungsanleitung (PDF {{DocLink|elv|/service/manuals/84919_FHT80TF_2_UM.pdf}})
* {{Link2Forum|Topic=27465|LinkText=Diskussionsthread}} dazu

[[Kategorie:FHT Components]]
[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:868MHz]]

FHT80TF-2

2023-11-16T15:24:40Z

Soulman: /* Sonstiges */ Ergänzung

{{Infobox Hardware
|Bild=FHT80TF.jpg
|Bildbeschreibung=Tür-/ Fensterkontakt, kleine Bauform
|HWProtocol=FHT
|HWType=Sensor
|HWCategory=FHT
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=3V
|HWPowerConsumption=Batterielaufzeit bis zu 5 Jahre
|HWPoweredBy=2xLR03 (AAA)
|HWSize=25x117x17 mm (Sensor) 11x48x12 mm (Magnet)
|HWDeviceFHEM=[[CUL_FHTTK|09_CUL_FHTTK.pm]]
|HWManufacturer=ELV
}}

Der '''FHT80TF Tür-/Fensterkontakt''', ein Zubehörteil zum [[FHT80b]] Raumregler, dient zur Erkennung einer offenen Tür, eines offenen Fensters oder ähnlicher Meldesituationen. Das Geräte existiert in zwei Bauformen, dem älteren und deutlich grösseren FHT80TF und dem kleineren FHT80TF-2 (Bild). Die Geräte sind funktional identisch.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''{{Link2Forum|Topic=60219}}

== Features ==
Mittels des FHT80TF kann überprüft werden, ob eine Tür oder ein Fenster im zu heizenden Raum offen ist. Ist dies der Fall, wird der FHT80b, mit dem der Tür/Fensterkontakt gepairt ist, die Heiztemperatur auf die separat einstellbare "Fenstertemperatur" einregeln. Wird das Fenster (und damit der Kontakt) wieder geschlossen, so regelt der FHT80b wieder auf die aktuell eingestellte Temperatur hoch.

Der FHT80TF besteht aus dem eigentlichen Gehäuse mit Sender und Batteriefach (2x Micro) und einem separaten Magneten, der im geschlossenen Zustand des Fensters oder der Tür einen Reedkontakt im Inneren des Sendergehäuses betätigt. Das FHT80TF Gehäuse hat zwecks wahlfreier Installation einen solchen Kontakt auf beiden Gehäuseseiten, sowie einen Anschluss für externe Kontakte (normally Closed). Es kann nur einer der internen Kontakte verwendet werden, ein interner und externe Kontakte oder nur externe. Alle Kontakte sind in Reihe geschaltet, es ist also keine Einzelauswertung möglich.

== Hinweise zum Betrieb mit FHEM ==
In der Standard FHT/FS20 Umgebung ist die Einsetzbarkeit des FHT80TF eingeschränkt, da er nur vom gepairten FHT80b zwecks Temperaturabsenkung ausgewertet wird.

FHEM kann einen FHT80TF jedoch überdies direkt als Device auswerten, sodass sich damit ähnlich wie beim HMS Device [[HMS 100 TFK]] oder dem FS20 TFK Schließzustände von Türen, Toren und Fenstern direkt auswerten lassen. Voraussetzung ist allerdings ein [[CUL]], CUNO oder COC als [[Interface|Funkschnittstelle / Zentrale]].

Der sechsstellige (hexadezimale) Devicecode des FHT80TF lässt sich nicht ändern und wird während der Produktion eindeutig vergeben. Es wird also kein Hauscode vergeben und der FHT80TF ist auch kein FS20 Sender.
=== Definition ===
Der jeweilige Devicecode kann über das Logfile ermittelt werden. Wird ein neuer Türkontakt erkannt, erscheint im Logfile "FHTTK unknown device 123abc, please define it." (wobei 123abc ein Stellvertreter für den tatsächlichen Devicecode des Fensterkontaktes ist, der dem Logfileeintrag zu entnehmen ist), der Fensterkontakt kann dann mit
:<code>define <name> [[CUL_FHTTK]] <devicecode></code>
definiert werden.

Im Gegensatz zum FS20 TFK wird die Statusänderung des Kontaktes nicht sofort übermittelt. Die Sendung wird nicht durch Öffnen oder Schliessen unmittelbar ausgelöst, vielmehr sendet das Modul in Abständen zwischen um die vier Minuten eine Statusnachricht über den aktuellen Zustand der Kontakte. Mehr dazu unter [[FHT80TF-2#Protokoll|Protokoll]]. Der Einsatz in [[Alarmanlage|Alarmanlagen]] oder ähnlichen Anwendungen ist daher nur eingeschränkt möglich. Vorteilhaft ist jedoch der geringere Preis gegenüber einem FS20 TFK.

=== Anwendungsbeispiel ===
Die Programmierung eines [[notify]] ist unter [[FHTTK: Benachrichtigung bei offenem Fenster]] beschrieben.

Im Wesentlichen ist zu beachten, dass das FHTTK neben dem Fensterzustand (Open oder Closed) auch den Batteriezustand (ok oder Low.Batt) meldet. Ein bedingtes Notify muss also definieren, welcher Wert abgefragt werden soll.

z. B.: <code>define mach_was_bei_Fenster_auf notify myFHTTK:Window:Open ...</code>

Über die Attribute bei der Definition können im Webinterface auch Zustand und Batteriestatus als Icon angezeigt werden.

z. B.: <code>attr Tuer_Balkon devStateIcon Open:fts_door_open@red Closed:fts_door@green Closed,.Low.Batt:measure_battery_25@yellow Open,.Low.Batt:measure_battery_25@red</code>

Hier würde der Zustand des FHTTK bei geöffneter Tür mit einen roten "Door Open" Icon, und im geschlossen Zustan mit dem "Door" Icon dargestellt. Wenn jedoch die Batterie sich dem Ende nähert, die offene Tür mit einem roten Batterie Leer Icon und wenn sie geschlossen ist mit gelben Batterie Leer Icon.

Den Batteriezustand zu beachten ist beim FHTTK wichtig, siehe unten.

== Batterielebensdauer ==
Der Stromverbrauch des Gerätes ist sehr gering. (Gute) Batterien halten mehrere Jahre. Da in diesen Zeiträumen die Selbstentladung eine ebenso grosse Rolle spielt wie der Stromverbrauch des Gerätes, halten die Batterien um so länger, je '''kälter''' es ist (Selbstentladung sinkt mit der Temperatur deutlich ab). Im Aussenbereich wurden Batterielebensdauern von bis zu acht Jahren beobachtet.

== Bekannte Probleme ==
* Bei Unterspannung (fast leere Batterie) fangen vor allem die FHT80TF (alte grösser Bauform) gelegentlich an, wild auf dem 868 MHz Band zu funken und blockieren hierdurch fast alle anderen Funkteilnehmer. Besonders betroffen sind FS20 Sensoren und Aktoren sowie FHT Kommunikation, aber auch HM, MAX! und ähnlich wird gestört. Dieser Effekt tritt ab etwa 1,1 Volt Zellenspannung ein. Der Zeitraum von der erste LOW BATT Warnung bis zum Effekt ist in der Regel sehr kurz, etwa 1-3 Tage. Daher bei der ersten Warnung Batterien sofort wechseln.

== Sonstiges ==
* Das Gerät arbeitet zuverlässig bis ca. -20 Grad, kann bei entsprechend wasserdichter Anbringung auch im Aussenbereich eingesetzt werden.
* Durch die Möglichkeit, einen eigenen Kontakt an Klemmen im Inneren anzuschliessen, lassen sich auch Lösungen für andere Einsatzzwecke realisieren.
* Da der Tür-/Fensterkontakt von alleine ca. alle vier Minuten seinen Status sendet, lässt er sich auch gut zum Ausmessen der [[SlowRF]] Funklage eines Gebäudes verwenden. Den Tür-/Fensterkontakt im Haus an die zu untersuchenden Stellen legen und mittels FHEM RSSI beobachten. FS20 / FHT etc. arbeitet gut bei RSSI oberhalb -80, mäßig zwischen -80 und -85 und bei RSSI kleiner als -85 unzuverlässig bis gar nicht.
* Die "Antenne" der älteren Bauform ist eine Attrappe

== Protokoll ==

Das benutzte Protokoll der FHT Baugruppen wird auf der Seite von FHZ4Linux [http://fhz4linux.info/tiki-index.php?page=FHT%20protocol FHT Protokoll] beschrieben. Ein FHT80TF-2 sendet in bestimmten Zeitabständen seinen momentanen Status. Dabei kann man in einen Hauptintervall und in einen Statusänderungsintervall unterscheiden. Erst genannter Intervall sendet immer in einem gleichen Abstand von 240 + x Sekunden seinen Status (unten Fett hervorgehoben) und zweit genannter geschieht intern immer in (240 + x) / 4 Sekunden. Sollte nun innerhalb des Hauptintervalls ein Statuswechsel von "on" auf "off" bzw. "Open" auf "Closed" eintreten, wird nach Ablauf von 1x (240 + x) / 4 (Statusänderungsintervall) der neue Status gesendet und noch einmal nach (240 + x) / 4 wiederholt. Danach verfällt der TF-2 wieder in den Hauptintervall, beginnend bei 0. Die Variable x wird aus dem Adressbyte vom Fensterkontakt berechnet, ähnlich dem Intervall für den [[FHT80b#Hinweise_zum_Betrieb_mit_FHEM|FHT8v]]. Es werden nur die 3 niederwertigen Bits verwendet. Beispiel: FHTTF-2 ID 8631'''0A''' -> 0x0A & 0x07 = '''2''' -> (16 - ('''2''' * 2)) = 12 Sekunden. 
 
Formel: 
:x = (16 - (Adressbyte & 0x7) * 2) 
:y = 240 + x
:y == Hauptintervall von 4 min + x
 
{| class="wikitable"
|-
! FHT Code !! HC1 !! HC2 !! Adressbyte !! Adressbyte & 0x7 !! Intervall
|-
| F7 FD 57 || 1111 0111 || 1111 1101 || 0101 0'''111''' || 7 || 4:02
|-
| 83 C0 D7 || 1000 0011 || 1100 0000 || 1101 0'''111''' || 7 || 4:02
|-
| 86 30 0A || 1000 0110 || 0011 0000 || 0000 1'''010''' || 2 || 4:12
|-
| 86 31 0A || 1000 0110 || 0011 0001 || 0000 1'''010''' || 2 || 4:12
|-
| CA 54 01 || 1100 1010 || 0101 0100 || 0000 0'''001''' || 1 || 4:14
|-
| 64 C8 70 || 0110 0100 || 1100 1000 || 0111 0'''000''' || 0 || 4:16
|}
 
<code>
2013-10-07_21:17:15 Fenster Window: off 
2013-10-07_21:21:17 Fenster Window: on 
2013-10-07_21:22:17 Fenster Window: on 
2013-10-07_21:26:19 Fenster Window: on 
2013-10-07_21:30:21 Fenster Window: on 
'''2013-10-07_21:34:23 Fenster Window: on''' 
'''2013-10-07_21:38:25 Fenster Window: on''' 
2013-10-07_21:50:32 Fenster Window: on 
2013-10-07_21:54:34 Fenster Window: off 
2013-10-07_21:55:34 Fenster Window: off 
2013-10-07_21:59:36 Fenster Window: off 
2013-10-07_22:03:38 Fenster Window: off 
2013-10-07_22:06:40 Fenster Window: on 
2013-10-07_22:07:40 Fenster Window: on 
2013-10-07_22:08:41 Fenster Window: off 
2013-10-07_22:09:41 Fenster Window: off 
2013-10-07_22:13:43 Fenster Window: off 
</code>
 
Ergänzung zur Synchronisierung:

Der Synchronisierungsprozess mit einem FHT 80 Regler wird mit einer Nachricht 0x0C (Befehlsbyte) begonnen und einem folgenden 0x0F (Befehlsbyte) abgeschlossen. Erst dann ist der TF am FHT angemeldet.

== Links ==
* Bedienungsanleitung (PDF {{DocLink|elv|/service/manuals/84919_FHT80TF_2_UM.pdf}})
* {{Link2Forum|Topic=27465|LinkText=Diskussionsthread}} dazu

[[Kategorie:FHT Components]]
[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:868MHz]]

FHT80TF-2

2023-11-16T15:20:17Z

Soulman: /* Bekannte Probleme */

{{Infobox Hardware
|Bild=FHT80TF.jpg
|Bildbeschreibung=Tür-/ Fensterkontakt, kleine Bauform
|HWProtocol=FHT
|HWType=Sensor
|HWCategory=FHT
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=3V
|HWPowerConsumption=Batterielaufzeit bis zu 5 Jahre
|HWPoweredBy=2xLR03 (AAA)
|HWSize=25x117x17 mm (Sensor) 11x48x12 mm (Magnet)
|HWDeviceFHEM=[[CUL_FHTTK|09_CUL_FHTTK.pm]]
|HWManufacturer=ELV
}}

Der '''FHT80TF Tür-/Fensterkontakt''', ein Zubehörteil zum [[FHT80b]] Raumregler, dient zur Erkennung einer offenen Tür, eines offenen Fensters oder ähnlicher Meldesituationen. Das Geräte existiert in zwei Bauformen, dem älteren und deutlich grösseren FHT80TF und dem kleineren FHT80TF-2 (Bild). Die Geräte sind funktional identisch.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''{{Link2Forum|Topic=60219}}

== Features ==
Mittels des FHT80TF kann überprüft werden, ob eine Tür oder ein Fenster im zu heizenden Raum offen ist. Ist dies der Fall, wird der FHT80b, mit dem der Tür/Fensterkontakt gepairt ist, die Heiztemperatur auf die separat einstellbare "Fenstertemperatur" einregeln. Wird das Fenster (und damit der Kontakt) wieder geschlossen, so regelt der FHT80b wieder auf die aktuell eingestellte Temperatur hoch.

Der FHT80TF besteht aus dem eigentlichen Gehäuse mit Sender und Batteriefach (2x Micro) und einem separaten Magneten, der im geschlossenen Zustand des Fensters oder der Tür einen Reedkontakt im Inneren des Sendergehäuses betätigt. Das FHT80TF Gehäuse hat zwecks wahlfreier Installation einen solchen Kontakt auf beiden Gehäuseseiten, sowie einen Anschluss für externe Kontakte (normally Closed). Es kann nur einer der internen Kontakte verwendet werden, ein interner und externe Kontakte oder nur externe. Alle Kontakte sind in Reihe geschaltet, es ist also keine Einzelauswertung möglich.

== Hinweise zum Betrieb mit FHEM ==
In der Standard FHT/FS20 Umgebung ist die Einsetzbarkeit des FHT80TF eingeschränkt, da er nur vom gepairten FHT80b zwecks Temperaturabsenkung ausgewertet wird.

FHEM kann einen FHT80TF jedoch überdies direkt als Device auswerten, sodass sich damit ähnlich wie beim HMS Device [[HMS 100 TFK]] oder dem FS20 TFK Schließzustände von Türen, Toren und Fenstern direkt auswerten lassen. Voraussetzung ist allerdings ein [[CUL]], CUNO oder COC als [[Interface|Funkschnittstelle / Zentrale]].

Der sechsstellige (hexadezimale) Devicecode des FHT80TF lässt sich nicht ändern und wird während der Produktion eindeutig vergeben. Es wird also kein Hauscode vergeben und der FHT80TF ist auch kein FS20 Sender.
=== Definition ===
Der jeweilige Devicecode kann über das Logfile ermittelt werden. Wird ein neuer Türkontakt erkannt, erscheint im Logfile "FHTTK unknown device 123abc, please define it." (wobei 123abc ein Stellvertreter für den tatsächlichen Devicecode des Fensterkontaktes ist, der dem Logfileeintrag zu entnehmen ist), der Fensterkontakt kann dann mit
:<code>define <name> [[CUL_FHTTK]] <devicecode></code>
definiert werden.

Im Gegensatz zum FS20 TFK wird die Statusänderung des Kontaktes nicht sofort übermittelt. Die Sendung wird nicht durch Öffnen oder Schliessen unmittelbar ausgelöst, vielmehr sendet das Modul in Abständen zwischen um die vier Minuten eine Statusnachricht über den aktuellen Zustand der Kontakte. Mehr dazu unter [[FHT80TF-2#Protokoll|Protokoll]]. Der Einsatz in [[Alarmanlage|Alarmanlagen]] oder ähnlichen Anwendungen ist daher nur eingeschränkt möglich. Vorteilhaft ist jedoch der geringere Preis gegenüber einem FS20 TFK.

=== Anwendungsbeispiel ===
Die Programmierung eines [[notify]] ist unter [[FHTTK: Benachrichtigung bei offenem Fenster]] beschrieben.

Im Wesentlichen ist zu beachten, dass das FHTTK neben dem Fensterzustand (Open oder Closed) auch den Batteriezustand (ok oder Low.Batt) meldet. Ein bedingtes Notify muss also definieren, welcher Wert abgefragt werden soll.

z. B.: <code>define mach_was_bei_Fenster_auf notify myFHTTK:Window:Open ...</code>

Über die Attribute bei der Definition können im Webinterface auch Zustand und Batteriestatus als Icon angezeigt werden.

z. B.: <code>attr Tuer_Balkon devStateIcon Open:fts_door_open@red Closed:fts_door@green Closed,.Low.Batt:measure_battery_25@yellow Open,.Low.Batt:measure_battery_25@red</code>

Hier würde der Zustand des FHTTK bei geöffneter Tür mit einen roten "Door Open" Icon, und im geschlossen Zustan mit dem "Door" Icon dargestellt. Wenn jedoch die Batterie sich dem Ende nähert, die offene Tür mit einem roten Batterie Leer Icon und wenn sie geschlossen ist mit gelben Batterie Leer Icon.

Den Batteriezustand zu beachten ist beim FHTTK wichtig, siehe unten.

== Batterielebensdauer ==
Der Stromverbrauch des Gerätes ist sehr gering. (Gute) Batterien halten mehrere Jahre. Da in diesen Zeiträumen die Selbstentladung eine ebenso grosse Rolle spielt wie der Stromverbrauch des Gerätes, halten die Batterien um so länger, je '''kälter''' es ist (Selbstentladung sinkt mit der Temperatur deutlich ab). Im Aussenbereich wurden Batterielebensdauern von bis zu acht Jahren beobachtet.

== Bekannte Probleme ==
* Bei Unterspannung (fast leere Batterie) fangen vor allem die FHT80TF (alte grösser Bauform) gelegentlich an, wild auf dem 868 MHz Band zu funken und blockieren hierdurch fast alle anderen Funkteilnehmer. Besonders betroffen sind FS20 Sensoren und Aktoren sowie FHT Kommunikation, aber auch HM, MAX! und ähnlich wird gestört. Dieser Effekt tritt ab etwa 1,1 Volt Zellenspannung ein. Der Zeitraum von der erste LOW BATT Warnung bis zum Effekt ist in der Regel sehr kurz, etwa 1-3 Tage. Daher bei der ersten Warnung Batterien sofort wechseln.

== Sonstiges ==
* Das Gerät arbeitet zuverlässig bis ca. -20 Grad, kann bei entsprechend wasserdichter Anbringung auch im Aussenbereich eingesetzt werden.
* Durch die Möglichkeit, einen eigenen Kontakt an Klemmen im Inneren anzuschliessen, lassen sich auch Lösungen für andere Einsatzzwecke realisieren.
* Da der Tür-/Fensterkontakt von alleine ca. alle vier Minuten seinen Status sendet, lässt er sich auch gut zum Ausmessen der [[SlowRF]] Funklage eines Gebäudes verwenden. Den Tür-/Fensterkontakt im Haus an die zu untersuchenden Stellen legen und mittels FHEM RSSI beobachten. FS20 / FHT etc. arbeitet gut bei RSSI oberhalb -80, mäßig zwischen -80 und -85 und bei RSSI kleiner als -85 unzuverlässig bis gar nicht.

== Protokoll ==

Das benutzte Protokoll der FHT Baugruppen wird auf der Seite von FHZ4Linux [http://fhz4linux.info/tiki-index.php?page=FHT%20protocol FHT Protokoll] beschrieben. Ein FHT80TF-2 sendet in bestimmten Zeitabständen seinen momentanen Status. Dabei kann man in einen Hauptintervall und in einen Statusänderungsintervall unterscheiden. Erst genannter Intervall sendet immer in einem gleichen Abstand von 240 + x Sekunden seinen Status (unten Fett hervorgehoben) und zweit genannter geschieht intern immer in (240 + x) / 4 Sekunden. Sollte nun innerhalb des Hauptintervalls ein Statuswechsel von "on" auf "off" bzw. "Open" auf "Closed" eintreten, wird nach Ablauf von 1x (240 + x) / 4 (Statusänderungsintervall) der neue Status gesendet und noch einmal nach (240 + x) / 4 wiederholt. Danach verfällt der TF-2 wieder in den Hauptintervall, beginnend bei 0. Die Variable x wird aus dem Adressbyte vom Fensterkontakt berechnet, ähnlich dem Intervall für den [[FHT80b#Hinweise_zum_Betrieb_mit_FHEM|FHT8v]]. Es werden nur die 3 niederwertigen Bits verwendet. Beispiel: FHTTF-2 ID 8631'''0A''' -> 0x0A & 0x07 = '''2''' -> (16 - ('''2''' * 2)) = 12 Sekunden. 
 
Formel: 
:x = (16 - (Adressbyte & 0x7) * 2) 
:y = 240 + x
:y == Hauptintervall von 4 min + x
 
{| class="wikitable"
|-
! FHT Code !! HC1 !! HC2 !! Adressbyte !! Adressbyte & 0x7 !! Intervall
|-
| F7 FD 57 || 1111 0111 || 1111 1101 || 0101 0'''111''' || 7 || 4:02
|-
| 83 C0 D7 || 1000 0011 || 1100 0000 || 1101 0'''111''' || 7 || 4:02
|-
| 86 30 0A || 1000 0110 || 0011 0000 || 0000 1'''010''' || 2 || 4:12
|-
| 86 31 0A || 1000 0110 || 0011 0001 || 0000 1'''010''' || 2 || 4:12
|-
| CA 54 01 || 1100 1010 || 0101 0100 || 0000 0'''001''' || 1 || 4:14
|-
| 64 C8 70 || 0110 0100 || 1100 1000 || 0111 0'''000''' || 0 || 4:16
|}
 
<code>
2013-10-07_21:17:15 Fenster Window: off 
2013-10-07_21:21:17 Fenster Window: on 
2013-10-07_21:22:17 Fenster Window: on 
2013-10-07_21:26:19 Fenster Window: on 
2013-10-07_21:30:21 Fenster Window: on 
'''2013-10-07_21:34:23 Fenster Window: on''' 
'''2013-10-07_21:38:25 Fenster Window: on''' 
2013-10-07_21:50:32 Fenster Window: on 
2013-10-07_21:54:34 Fenster Window: off 
2013-10-07_21:55:34 Fenster Window: off 
2013-10-07_21:59:36 Fenster Window: off 
2013-10-07_22:03:38 Fenster Window: off 
2013-10-07_22:06:40 Fenster Window: on 
2013-10-07_22:07:40 Fenster Window: on 
2013-10-07_22:08:41 Fenster Window: off 
2013-10-07_22:09:41 Fenster Window: off 
2013-10-07_22:13:43 Fenster Window: off 
</code>
 
Ergänzung zur Synchronisierung:

Der Synchronisierungsprozess mit einem FHT 80 Regler wird mit einer Nachricht 0x0C (Befehlsbyte) begonnen und einem folgenden 0x0F (Befehlsbyte) abgeschlossen. Erst dann ist der TF am FHT angemeldet.

== Links ==
* Bedienungsanleitung (PDF {{DocLink|elv|/service/manuals/84919_FHT80TF_2_UM.pdf}})
* {{Link2Forum|Topic=27465|LinkText=Diskussionsthread}} dazu

[[Kategorie:FHT Components]]
[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:868MHz]]

FHT80TF-2

2023-11-16T15:15:39Z

Soulman: Ergänzungen

{{Infobox Hardware
|Bild=FHT80TF.jpg
|Bildbeschreibung=Tür-/ Fensterkontakt, kleine Bauform
|HWProtocol=FHT
|HWType=Sensor
|HWCategory=FHT
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=3V
|HWPowerConsumption=Batterielaufzeit bis zu 5 Jahre
|HWPoweredBy=2xLR03 (AAA)
|HWSize=25x117x17 mm (Sensor) 11x48x12 mm (Magnet)
|HWDeviceFHEM=[[CUL_FHTTK|09_CUL_FHTTK.pm]]
|HWManufacturer=ELV
}}

Der '''FHT80TF Tür-/Fensterkontakt''', ein Zubehörteil zum [[FHT80b]] Raumregler, dient zur Erkennung einer offenen Tür, eines offenen Fensters oder ähnlicher Meldesituationen. Das Geräte existiert in zwei Bauformen, dem älteren und deutlich grösseren FHT80TF und dem kleineren FHT80TF-2 (Bild). Die Geräte sind funktional identisch.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''{{Link2Forum|Topic=60219}}

== Features ==
Mittels des FHT80TF kann überprüft werden, ob eine Tür oder ein Fenster im zu heizenden Raum offen ist. Ist dies der Fall, wird der FHT80b, mit dem der Tür/Fensterkontakt gepairt ist, die Heiztemperatur auf die separat einstellbare "Fenstertemperatur" einregeln. Wird das Fenster (und damit der Kontakt) wieder geschlossen, so regelt der FHT80b wieder auf die aktuell eingestellte Temperatur hoch.

Der FHT80TF besteht aus dem eigentlichen Gehäuse mit Sender und Batteriefach (2x Micro) und einem separaten Magneten, der im geschlossenen Zustand des Fensters oder der Tür einen Reedkontakt im Inneren des Sendergehäuses betätigt. Das FHT80TF Gehäuse hat zwecks wahlfreier Installation einen solchen Kontakt auf beiden Gehäuseseiten, sowie einen Anschluss für externe Kontakte (normally Closed). Es kann nur einer der internen Kontakte verwendet werden, ein interner und externe Kontakte oder nur externe. Alle Kontakte sind in Reihe geschaltet, es ist also keine Einzelauswertung möglich.

== Hinweise zum Betrieb mit FHEM ==
In der Standard FHT/FS20 Umgebung ist die Einsetzbarkeit des FHT80TF eingeschränkt, da er nur vom gepairten FHT80b zwecks Temperaturabsenkung ausgewertet wird.

FHEM kann einen FHT80TF jedoch überdies direkt als Device auswerten, sodass sich damit ähnlich wie beim HMS Device [[HMS 100 TFK]] oder dem FS20 TFK Schließzustände von Türen, Toren und Fenstern direkt auswerten lassen. Voraussetzung ist allerdings ein [[CUL]], CUNO oder COC als [[Interface|Funkschnittstelle / Zentrale]].

Der sechsstellige (hexadezimale) Devicecode des FHT80TF lässt sich nicht ändern und wird während der Produktion eindeutig vergeben. Es wird also kein Hauscode vergeben und der FHT80TF ist auch kein FS20 Sender.
=== Definition ===
Der jeweilige Devicecode kann über das Logfile ermittelt werden. Wird ein neuer Türkontakt erkannt, erscheint im Logfile "FHTTK unknown device 123abc, please define it." (wobei 123abc ein Stellvertreter für den tatsächlichen Devicecode des Fensterkontaktes ist, der dem Logfileeintrag zu entnehmen ist), der Fensterkontakt kann dann mit
:<code>define <name> [[CUL_FHTTK]] <devicecode></code>
definiert werden.

Im Gegensatz zum FS20 TFK wird die Statusänderung des Kontaktes nicht sofort übermittelt. Die Sendung wird nicht durch Öffnen oder Schliessen unmittelbar ausgelöst, vielmehr sendet das Modul in Abständen zwischen um die vier Minuten eine Statusnachricht über den aktuellen Zustand der Kontakte. Mehr dazu unter [[FHT80TF-2#Protokoll|Protokoll]]. Der Einsatz in [[Alarmanlage|Alarmanlagen]] oder ähnlichen Anwendungen ist daher nur eingeschränkt möglich. Vorteilhaft ist jedoch der geringere Preis gegenüber einem FS20 TFK.

=== Anwendungsbeispiel ===
Die Programmierung eines [[notify]] ist unter [[FHTTK: Benachrichtigung bei offenem Fenster]] beschrieben.

Im Wesentlichen ist zu beachten, dass das FHTTK neben dem Fensterzustand (Open oder Closed) auch den Batteriezustand (ok oder Low.Batt) meldet. Ein bedingtes Notify muss also definieren, welcher Wert abgefragt werden soll.

z. B.: <code>define mach_was_bei_Fenster_auf notify myFHTTK:Window:Open ...</code>

Über die Attribute bei der Definition können im Webinterface auch Zustand und Batteriestatus als Icon angezeigt werden.

z. B.: <code>attr Tuer_Balkon devStateIcon Open:fts_door_open@red Closed:fts_door@green Closed,.Low.Batt:measure_battery_25@yellow Open,.Low.Batt:measure_battery_25@red</code>

Hier würde der Zustand des FHTTK bei geöffneter Tür mit einen roten "Door Open" Icon, und im geschlossen Zustan mit dem "Door" Icon dargestellt. Wenn jedoch die Batterie sich dem Ende nähert, die offene Tür mit einem roten Batterie Leer Icon und wenn sie geschlossen ist mit gelben Batterie Leer Icon.

Den Batteriezustand zu beachten ist beim FHTTK wichtig, siehe unten.

== Batterielebensdauer ==
Der Stromverbrauch des Gerätes ist sehr gering. (Gute) Batterien halten mehrere Jahre. Da in diesen Zeiträumen die Selbstentladung eine ebenso grosse Rolle spielt wie der Stromverbrauch des Gerätes, halten die Batterien um so länger, je '''kälter''' es ist (Selbstentladung sinkt mit der Temperatur deutlich ab). Im Aussenbereich wurden Batterielebensdauern von bis zu acht Jahren beobachtet.

== Bekannte Probleme ==
* Bei Unterspannung (fast leere Batterie) fangen die Sensoren an wild auf dem 868 MHz Band zu funken und blockieren hierdurch fast alle anderen Funkteilnehmer. Besonders betroffen sind FS20 Sensoren und Aktoren sowie FHT Kommunikation, aber auch HM, MAX! und ähnlich wird gestört. Dieser Effekt tritt ab etwa 1,1 Volt Zellenspannung ein. Der Zeitraum von der erste LOW BATT Warnung bis zum Effekt ist in der Regel sehr kurz, etwa 1-3 Tage. Daher bei der ersten Warnung Batterien sofort wechseln.

== Sonstiges ==
* Das Gerät arbeitet zuverlässig bis ca. -20 Grad, kann bei entsprechend wasserdichter Anbringung auch im Aussenbereich eingesetzt werden.
* Durch die Möglichkeit, einen eigenen Kontakt an Klemmen im Inneren anzuschliessen, lassen sich auch Lösungen für andere Einsatzzwecke realisieren.
* Da der Tür-/Fensterkontakt von alleine ca. alle vier Minuten seinen Status sendet, lässt er sich auch gut zum Ausmessen der [[SlowRF]] Funklage eines Gebäudes verwenden. Den Tür-/Fensterkontakt im Haus an die zu untersuchenden Stellen legen und mittels FHEM RSSI beobachten. FS20 / FHT etc. arbeitet gut bei RSSI oberhalb -80, mäßig zwischen -80 und -85 und bei RSSI kleiner als -85 unzuverlässig bis gar nicht.

== Protokoll ==

Das benutzte Protokoll der FHT Baugruppen wird auf der Seite von FHZ4Linux [http://fhz4linux.info/tiki-index.php?page=FHT%20protocol FHT Protokoll] beschrieben. Ein FHT80TF-2 sendet in bestimmten Zeitabständen seinen momentanen Status. Dabei kann man in einen Hauptintervall und in einen Statusänderungsintervall unterscheiden. Erst genannter Intervall sendet immer in einem gleichen Abstand von 240 + x Sekunden seinen Status (unten Fett hervorgehoben) und zweit genannter geschieht intern immer in (240 + x) / 4 Sekunden. Sollte nun innerhalb des Hauptintervalls ein Statuswechsel von "on" auf "off" bzw. "Open" auf "Closed" eintreten, wird nach Ablauf von 1x (240 + x) / 4 (Statusänderungsintervall) der neue Status gesendet und noch einmal nach (240 + x) / 4 wiederholt. Danach verfällt der TF-2 wieder in den Hauptintervall, beginnend bei 0. Die Variable x wird aus dem Adressbyte vom Fensterkontakt berechnet, ähnlich dem Intervall für den [[FHT80b#Hinweise_zum_Betrieb_mit_FHEM|FHT8v]]. Es werden nur die 3 niederwertigen Bits verwendet. Beispiel: FHTTF-2 ID 8631'''0A''' -> 0x0A & 0x07 = '''2''' -> (16 - ('''2''' * 2)) = 12 Sekunden. 
 
Formel: 
:x = (16 - (Adressbyte & 0x7) * 2) 
:y = 240 + x
:y == Hauptintervall von 4 min + x
 
{| class="wikitable"
|-
! FHT Code !! HC1 !! HC2 !! Adressbyte !! Adressbyte & 0x7 !! Intervall
|-
| F7 FD 57 || 1111 0111 || 1111 1101 || 0101 0'''111''' || 7 || 4:02
|-
| 83 C0 D7 || 1000 0011 || 1100 0000 || 1101 0'''111''' || 7 || 4:02
|-
| 86 30 0A || 1000 0110 || 0011 0000 || 0000 1'''010''' || 2 || 4:12
|-
| 86 31 0A || 1000 0110 || 0011 0001 || 0000 1'''010''' || 2 || 4:12
|-
| CA 54 01 || 1100 1010 || 0101 0100 || 0000 0'''001''' || 1 || 4:14
|-
| 64 C8 70 || 0110 0100 || 1100 1000 || 0111 0'''000''' || 0 || 4:16
|}
 
<code>
2013-10-07_21:17:15 Fenster Window: off 
2013-10-07_21:21:17 Fenster Window: on 
2013-10-07_21:22:17 Fenster Window: on 
2013-10-07_21:26:19 Fenster Window: on 
2013-10-07_21:30:21 Fenster Window: on 
'''2013-10-07_21:34:23 Fenster Window: on''' 
'''2013-10-07_21:38:25 Fenster Window: on''' 
2013-10-07_21:50:32 Fenster Window: on 
2013-10-07_21:54:34 Fenster Window: off 
2013-10-07_21:55:34 Fenster Window: off 
2013-10-07_21:59:36 Fenster Window: off 
2013-10-07_22:03:38 Fenster Window: off 
2013-10-07_22:06:40 Fenster Window: on 
2013-10-07_22:07:40 Fenster Window: on 
2013-10-07_22:08:41 Fenster Window: off 
2013-10-07_22:09:41 Fenster Window: off 
2013-10-07_22:13:43 Fenster Window: off 
</code>
 
Ergänzung zur Synchronisierung:

Der Synchronisierungsprozess mit einem FHT 80 Regler wird mit einer Nachricht 0x0C (Befehlsbyte) begonnen und einem folgenden 0x0F (Befehlsbyte) abgeschlossen. Erst dann ist der TF am FHT angemeldet.

== Links ==
* Bedienungsanleitung (PDF {{DocLink|elv|/service/manuals/84919_FHT80TF_2_UM.pdf}})
* {{Link2Forum|Topic=27465|LinkText=Diskussionsthread}} dazu

[[Kategorie:FHT Components]]
[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:868MHz]]

HomeMatic Namen verstehen

2022-12-16T16:47:32Z

Soulman: /* Montageart */ WM55 ergänzt

[[HomeMatic]] Sender und Aktoren sind oft mit den Bezeichnungen des Herstellers (die ELV Tochtergesellschaft eQ-3) benannt.

Da es sich um Buchstaben und Zahlenkürzel handelt, ist nicht immer sofort erkennbar, um was für ein Gerät es sich handelt.

== Namensschema ==
Die Namen sind jedoch meist nach einem Schema aufgebaut, der Aufbau ist:

Medientyp - Generelle Funktion - Sensor/Sender/Aktorfunktion [mit Taster] - [Montageart]

also z. B. HM-LC-SW1-FM

Die Gross- und Kleinschreibung wird nicht durchgängig stringent eingehalten. So wird die Aktorfunktion Schalter mal mit SW, mal mit Sw bezeichnet.
[ ] umschliessen optionale Bestandteile

Ferner hält sich ELV nicht vollumfänglich an sein Namenschema.
Die LED Statusanzeige heisst z. B. HM-OU-LED16, müsste nach Namenschema aber eigentlich HM-Dis-16 heissen.
Zudem sind ähnliche Geräte mit Zusatzfunktionen völlig anders benannt (siehe Beispiele).

Es bedeuten (Liste unvollständig):

== Medientyp ==
* HM = HomeMatic Funk
* HMW = HomeMatic Wired
* HB = [[HomeBrew]] = HomeMatic Eigenentwicklungen, Nachbauten und Erweiterungen
* HBW = [[HomeBrew]] = HomeMatic-Wired Eigenentwicklungen, Nachbauten und Erweiterungen

== Funktion ==
* CC = Heizungssteuerung (Climate Control)
* CFG = Konfiguration (Configuration)
* Dis = Anzeige (Display)
* ES = Energieversorgung (Energy Systems)
* IO = Eingang/Ausgang (Input/Output, nur bei HomeMatic Wired)
* LC = Licht/Strom (Light Control)
* LGW = LAN-Schnittstelle (LAN Gateway)
* MOD = Modul (Module)
* OU = Klang (evtl. allgemein als Output Unit, ?)
* PB[U] = Wandtaster (Push Button [Unit, z.B. Unterputzaktoren mit integrierten Tastern (Schalterersatz)])
* PBI = Tasterschnittstelle (Push Button Interface)
* RC = Fernbedienung (Remote Control)
* SCI = Schalterzustandserkennung (Shutter Contact Interface)
* SEC = Sicherheit/Überwachung (Security) (teilweise auch Sec)
* Sen = Sensor
* SwI = Schalterinterface (Switch Interface)
* Sys = Systemerweiterung (nur vom Repeater bekannt)
* TC = Temperatursteuerung (temperature control), eigentlich eine Untergruppe von CC
* UW = Umweltsensor (nur bei HomeBrew)
* WDSxx = Feuchte- und/oder Temperatursensor
* 1W = Ankopplung an [[:Kategorie:1-Wire|1-Wire Komponenten]]

== Sensor/Sender/Aktorfunktion ==
* BLx = Jalousieaktor mit x Kanälen (Blind) (oft auch Blx)
* CF[M] = Gong und Blitz/Licht (und Klang-Speicher) (Chime with Flash (and Memory))
* DB = Türklingel (Door Bell)
* DimxT = Dimmer mit x Kanälen mit Phasen'''ab'''schnittsteuerung ('''t'''railing edge, für ohmsche und elektronische Lasten)
* DimxL = Dimmer mit x Kanälen mit Phasen'''an'''schnittsteuerung ('''l'''eading edge, für ohmsche und induktive Lasten)
* EM = Sender (Emitter, ?)
* EP = (Sensor für) Elektrische Impulse
* KEY = Schließsystem
* Px = Paniksender mit x Kanälen (Panic)
* T = Temperatursensor
* TH = Temperatur und Feuchtesensor (Temperature & Humidity)
* TiS = Neigungssensor (Tilt Sensor)
* Re = Empfänger (Receiver, ?)
* RT = Heizkörperthermostat (Radiator Thermostat)
* SC[o] = Tür- / Fenster / Schliesserkontakt (Shutter Contact (optical))
* SCD = Luftgütesensor (Sensor Carbon Dioxide)
* SFA = Sirenen- und Blitz-Aktor (sirene and flash actuator)
* SWx = Schaltaktor mit x Kanälen (Switch) (oft auch Swx)
* VD = Stellantrieb (Ventile Drive)
* WDS = Wassermelder
* MDIR = Infrarot Bewegungsmelder (Motion Detector Infrared)
* 1 = Einkanal
* 2 = Zweikanal
* 4 = Vierkanal
* 8 = Achtkanal
* 12 = Zwölfkanal
* 16 = Sechzehnkanal
* 19 = Neunzehnkanal

== Montageart ==
Optional, nur soweit bedeutsam, z. B. um Geräte ansonsten gleicher Funktion zu unterscheiden, wird die Montageart angefügt:

* CV = Zwischendeckenmontage (Ceiling mount)
* DN = Heizkörpermontage (???)
* DR = Hutschienenmontage (DIN Rail)
* FM = Unterputz (Floating Mount)
* PL = Zwischenstecker (Plug) (oft auch Pl)
* SM = Aufputz (Surface Mount)
* WM = beliebige Festmontage, meist Aufklebegerät (Wall Mount)
* WM55 = Wandmontage mit 55er Rahmen und Grundplatte
* I = Innenmontage (Indoor)
* O = Aussenmontage (Outdoor)
* T = Frei aufstellbares Gerät (eventuell von "Tabletop")

==Sonstiges==

* B = schwarz
* W = weiss (auch SW?)
* PCB = Bausatz / Platinenversion

== Beispiel ==
[[HM-LC-SW1-FM Schaltaktor 1-fach UP|HM-LC-SW1-FM]] = HomeMatic Funk - Licht/Strom - Schaltaktor mit einem Kanal - Unterputzmontage

[[HM-LC-Sw2PB-FM Schaltaktor mit Tasteraufsatz 2fach|HM-LC-Sw2PB-FM]] = HomeMatic Funk - Licht/Strom - Schaltaktor mit zwei Kanälen UND Tastern - Unterputzmontage

[[HM-LC-Sw1-Pl2_Funk-Zwischenstecker-Schaltaktor_1fach|HM-LC-Sw1-Pl2]] = HomeMatic Funk - Licht/Strom - Schaltaktor mit einem Kanal - Zwischenstecker (auch als HM-LC-Sw1-Pl-DN-R1 erhätlich

[[HM-ES-PMSw1-Pl_Funk-Schaltaktor_1-fach_mit_Leistungsmessung|HM-ES-PMSw1-Pl]] = HomeMatic Funk - Energiesysteme - Leistungsmessung+Schaltaktor mit einem Kanal - Zwischenstecker (eben nicht HM-'''LC'''-'''PM'''Sw1-Pl, im Vergleich dazu)

[[Kategorie:HOWTOS]]
[[Kategorie:HomeBrew]]
[[Kategorie:HomeMatic Components]]

Trick der Woche

2022-08-09T22:29:59Z

Soulman: /* Grundlastmodul */ typos

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== August 2022==
=== Update ===
Wenn der Befehl "Update" nicht funktioniert und insbesondere die Fehlermeldung ''Bad hostname 'fhem.de:80''' zurück gibt, kann es sinnvoll sein, den Parameter -noSSL zu versuchen. Details dazu im Artikel [[Update]]

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt wird, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich Strom durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL2 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

Trick der Woche

2022-08-09T22:17:32Z

Soulman: /* Oktober 2014 */ typo

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== August 2022==
=== Update ===
Wenn der Befehl "Update" nicht funktioniert und insbesondere die Fehlermeldung ''Bad hostname 'fhem.de:80''' zurück gibt, kann es sinnvoll sein, den Parameter -noSSL zu versuchen. Details dazu im Artikel [[Update]]

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich ström durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL2 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

Trick der Woche

2022-08-09T22:13:14Z

Soulman: /* Januar 2022 */ -noSSL Update

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== August 2022==
=== Update ===
Wenn der Befehl "Update" nicht funktioniert und insbesondere die Fehlermeldung ''Bad hostname 'fhem.de:80''' zurück gibt, kann es sinnvoll sein, den Parameter -noSSL zu versuchen. Details dazu im Artikel [[Update]]

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich ström durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt es viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL2 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

Update

2022-08-09T22:07:49Z

Soulman: /* Parameter */ noSSL ergänzt

{{SEITENTITEL:update}}
{{Infobox Modul
|ModPurpose=Befehl zur Aktualisierung der FHEM-Installation
|ModType=cmd
|ModCmdRef=update
|ModForumArea=Sonstiges
|ModTechName=98_update.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
[[update]] ist ein Befehl zur Aktualisierung der FHEM-Installation direkt über das FHEM [[FHEMWEB|Webfrontend]]. Von den Entwicklern bis zu einem bestimmten Zeitpunkt freigegebene Änderungen sind jeweils morgens ab 8:00 Uhr über die Update Funktion verfügbar. Änderungen, die später freigegeben werden, werden dementsprechend erst am nächsten Tag verfügbar.

== Syntax ==
:<code><nowiki>update [-noSSL] [<fileName>|all|check|force] [http://.../controlfile]</nowiki></code>
oder
:<code><nowiki>update [add source|delete source|list|reset]</nowiki></code>

'''Hinweise:'''
* FHEM sichert mit den Standardeinstellungen während des Updates "nur" die aktualisierten Modul(Installations-)dateien und bei Standardinstallationen ({{Link2Forum|Topic=59669|Message=511367}}) ab Updatestand 29.10.2016 die [[Konfiguration]] und fhem.save, aber beispielsweise nicht [[Plots erzeugen|Plots]] oder [[FileLog]]s. Soll vor dem Update ein vollständiges Backup von FHEM erstellt werden, muss das mit dem Attribut <code>[[#backup_before_update|backup_before_update]]</code> eingeschaltet werden.
* Lesen Sie aufmerksam die nach dem Update auf dem Monitor erscheinenden Meldungen zu Neuerungen und Änderungen.
* Nach einem Update ist immer ein ''shutdown restart'' erforderlich.
* geänderte und neu eingecheckte Module werden grundsätzlich erst am Folgetag ab ca. 8.00 Uhr durch den Update-Befehl verteilt.
* Mit dem Befehl [[version]] lässt sich die Version einzelner oder aller benutzten Module bestimmen.

== Parameter ==
Details zu Parametern des update Befehls:

=== Standardaufrufe ===
==== update ====
Die ganze FHEM-Installation wird auf die neueste Version gebracht. Vorhandene Module werden akualisiert und neue Module installiert.

==== update check ====
Es werden alle Module aufgelistet, von denen eine neuere als die bereits installierte Version verfügbar ist. Es wird nicht installiert.

==== update force ====
Das Update wird erzwungen (falls es beim regulären ''update'' Probleme geben sollte). Dieser Befehl ist nur mit Bedacht und ausschließlich im Notfall einzusetzen. Sollte ein reproduzierbares Problem existieren, dies bitte im FHEM-Forum berichten, damit dem nachgegangen werden kann.

==== update <Dateiname> ====
Mit z.B. <code>update 02_HTTPSRV.pm</code> wird nur von der Datei ''02_HTTPSRV.pm'' eine neue Version installiert. Alle anderen FHEM-Dateien werden nicht angetastet.

==== update -noSSL ====
Mit -noSSL wird das http Protocol statt https verwendet, was bei bestimmten
veralteten Distributionen notwendig sein kann. -noSSL steht erst seit 98_update.pm von Ende 2019 zur Verfügung.

==== update all ====
Alle [[Systemübersicht#Module|offiziellen Module]] von FHEM sind in einem gemeinsamen Repository gespeichert. Nur diese Module werden in der Standardeinstellung durch den update-Befehl mit den bisher aufgeführten [[#Standardaufrufe|Standardaufrufen]] aktualisiert bzw. installiert. Einige Entwickler stellen ihre Module jedoch aus verschiedensten Gründen nicht im gemeinsamen Repository zur Verfügung, sondern nutzen eigene, separate Repositorys. Diese sogenannten "Thirdparty-Module" (auch bezeichnet als inoffizielle Module) können ebenfalls über update installiert und aktualisiert werden, wenn der Entwickler eine sogenannte Kontrolldatei (controlfile) in seinem Repository zur Verfügung stellt.

Zur Installation bzw. Update jedes einzelnen Thirdparty-Moduls ist nachfolgender Befehl aufzurufen (Webadresse und Kontrolldateiname sind modulabhängig passend zu ersetzen):
<code><nowiki>update all http://thirdparty.com/controls_funnymodule.txt</nowiki></code>

Die in den vorherigen Abschnitten erläuterten Standardaufruf (bis auf <code>update</code>) können durch Ergänzung um Webadresse und Kontrolldateiname (<nowiki>http://.../controlfile</nowiki> beim Befehls-Aufruf für das Update von einzelnen Thirdparty-Modulen genutzt werden.

=== Repository-Verwaltung ===
In den Standardeinstellungen von FHEM ist für jedes einzelne Repository ein separater Aufruf der [[#Standardaufrufe|Standardaufrufe]] zur Aktualiserung/Installation notwendig. Zur Vereinfachung des Update-Prozesses hat der update-Befehl eine eingebaute Repository-Verwaltung. Mittels der Repository-Verwaltung lassen sich die Standardaufrufe so beeinflussen, dass mit einem einzigen Aufruf sowohl die Module aus dem FHEM-Repository als auch aus verschiedenen Thirdparty-Repositorys beim Update berücksichtigt werden.

==== update add ====
Fügt ein zusätzliches Repository zur vereinfachten Nutzung über die Standardaufrufe hinzu. Ein Aufruf von <code><nowiki>update <Dateiname>|all|check|force</nowiki></code> berücksichtigt dann automatisch neben dem FHEM-eigenen Repository auch das hinzugefügte "Thirdparty-Repository".

Nach dem Hinzufügen durch beispielsweise <code><nowiki>update add http://thirdparty.com/controls_funnymodule.txt</nowiki></code> entfällt somit der manuelle Aufruf der Form <code><nowiki>update all http://thirdparty.com/controls_funnymodule.txt</nowiki></code> zur Aktualiserung. Er kann aber weiterhin genutzt werden, um ausschließlich für ein bestimmtes Repository ein Update zu erhalten und und nicht für alle.

Die Liste der Repositorys wird in der Verwaltungsdatei FHEM/controls.txt gespeichert.

==== update delete ====
Entfernt eine Repository aus der Verwaltungsdatei.

==== update list ====
Listet alle in der Verwaltungsdatei enthaltenen Repositorys auf.

==== update reset ====
Entfernt alle Fremd-Repositorys aus der Verwaltungsdatei. Nur das eigene Repository von FHEM wird noch von den Standardparametern berücksichtigt.

==== Syntax controlfile ====
Das Controlfile für thirdparty Module unterliegt einer festen Syntax. In jeder Zeile steht ein Dateiname und ein Befehl, was damit passieren soll. Ein Zeilenumbruch wird durch ein \n dargestellt.

Es können drei Befehle verwendet werden: CRE, MOV und UPD.

===== CRE - Anlegen einer Datei =====

Hiermit können vom Entwickler Dateinamen festgelegt und entsprechende Initial-Dateien verteilt werden; der Inhalt der Datei liegt nach dem ''ersten'' Verteilen in Anwenderhänden (z.B. nützlich bei *-user.css-Dateien).

<code>CRE <Datum> <Dateigröße> <Datei inkl. Pfad> </code>

Das Anlegen wird nur ausgeführt, wenn
* die Datei noch nicht vorhanden ist.

===== MOV - Verschieben oder Umbenennen einer Datei =====

<code>MOV <Quelldatei inkl. Pfad> <Zieldatei inkl. Pfad> </code>

Da Dateien nicht vollständig gelöscht werden können, kann eine Datei mit dem MOV Befehl in einen speziellen Ordner namens "unused" verschoben werden:

<code>MOV <Quelldatei inkl. Pfad> unused </code>

===== UPD - Aktualisieren einer Datei =====

<code>UPD <Datum> <Dateigröße> <Datei inkl. Pfad> </code>

Die Aktualisierung wird nur ausgeführt, wenn
* das Datum der lokalen Datei sich vom Datum der Update-Datei unterscheidet.
* die Dateigröße der Update-Datei mit der Dateigröße im UPD Eintrag übereinstimmt.

Beispiel:

<code>
UPD 2018-10-04_20:17:35 55143 FHEM/55_MyFirstFile.pm

UPD 2018-09-27_23:26:21 17121 FHEM/55_MySecondFile.pm
</code>

Beispiel für die Erzeugung der UPD Einträge:

<syntaxhighlight lang="perl">
#!/usr/bin/perl

use File::Basename;
use POSIX qw(strftime);
use strict;

my @filenames = ( "55_MyFirstFile.pm",
"55_MySecondFile.pm");

my $prefix = "FHEM";
my $filename = "";
foreach $filename (@filenames)
{
my @statOutput = stat($prefix."/".$filename);

if (scalar @statOutput != 13)
{
printf("error: stat has unexpected return value for ".$prefix."/".$filename."\n");
next;
}

my $mtime = $statOutput[9];
my $date = POSIX::strftime("%Y-%m-%d", localtime($mtime));
my $time = POSIX::strftime("%H:%M:%S", localtime($mtime));
my $filetime = $date."_".$time;

my $filesize = $statOutput[7];

printf("UPD ".$filetime." ".$filesize." ".$prefix."/".$filename."\n");
}
</syntaxhighlight>

== Attribute ==
Zur weiteren Beeinflussung der Funktionsweise des update Befehls können Attribute verwendet werden. Diese müssen für das Objekt ''global'' gesetzt werden, also mit einem Konfigurationsbefehl der Art
:<code>attr global ...</code>

=== backup_before_update ===
siehe auch [[backup]]

=== restoreDirs ===
siehe [[#Rücksichern beim Update überschriebener Dateien|Rücksichern beim Update überschriebener Dateien]]

=== exclude_from_update ===
Mit der Definition
:<code>attr global exclude_from_update ...</code>
kann eine Liste von Dateien spezifiziert werden, die bei der Ausführung des update Befehls '''nicht''' aktualisiert werden sollen. Dateien können auch über reguläre Ausdrücke definiert werden, die einzelnen Einträge werden durch Leerzeichen voneinander getrennt.

Einen Spezialfall stellt die ''commandref'' dar, die seit einer Modifikation des Update Prozesses (März 2015, beschrieben in dieser {{Link2Forum|Topic=34450|LinkText=Forendiskussion}}) nicht mehr heruntergeladen wird, sondern auf dem Benutzersystem durch Extraktion der Dokumentation aus den einzelnen Modulen generiert wird, angezeigt durch die Meldung im fhem.log:
:''Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while''.
Sollte dieser Prozess (z.B. auf einem langsamen Rechner) zu lange dauern, bleibt die Meldung
:''update finished, "shutdown restart" is needed to activate the changes.''
aus. Wird ''commandref'' in das <code>exclude_from_update</code> Attribut eingetragen, entfällt dieser Schritt, die lokale ''commandref'' wird allerdings dann auch nicht mehr aktualisiert. Die modulspezifische Hilfe, die z.B. über <code>help modulname</code> aufgerufen werden kann, ist davon nicht betroffen.

== Anwendungsbeispiel / Problembehebung ==
=== Durchführung eines Updates ===
Zunächst kann mit dem Befehl
:<code>update check</code>
überprüft werden, ob es überhaupt ein neues Update gibt und welche Dateien hierbei ausgetauscht würden (die angezeigten Infos sollten in einer Textdatei gesichert werden. Mit diesen Infos kann gezielter nach Problemen, die vielleicht nach einem Update auftreten, gesucht werden). Anschließend kann mittels:
:<code>update</code>
das Update eingespielt werden. Hierbei ist zu beachten, dass die Befehle auf der FHEM Webseite oben ([[Konfiguration|Befehls-Eingabefeld]]) eingegeben werden und anschließend die "Enter" Taste auf der Tastatur gedrückt werden muss.

Gibt es kein Update für FHEM, sieht die Ausgabe z.B. nach "update check" wie folgt aus:

:<code>List of new / modified files since last update:</code>
:<code>nothing to do...</code>

=== Rücksichern beim Update überschriebener Dateien ===
Sollte nach einem update etwas ganz oder teilweise nicht mehr funktionieren, kann man auf den Stand vor dem Update zurückgehen. Die Befehle sind für die FHEM Kommandozeile.

Man kann sich einen Überblick über die Funktion des Befehls {{Link2CmdRef|Anker=restore|Label=restore}} verschaffen:
<pre>
help restore
</pre>
Man kann die gesicherten Versionen listen
<pre>
restore list update

Available for restore in update:
2020-11-01
</pre>
Man kann in der Verzeichnis Ebene tiefer suchen
<pre>
restore list update/2020-11-01

Available for restore in update/2020-11-01:
CHANGED
FHEM
MAINTAINER.txt
configDB.pm
fhem.cfg
fhem.pl
lib
log
</pre>
Man kann gezielt wiederherstellen, entweder den kompletten Pfad oder einzelne Dateien.
<pre>
restore update/2020-11-01/FHEM
restore update/2020-11-01/FHEM/10_CUL_HM.pm
</pre>
Weitere Informationen:
* Per default werden vor dem Überschreiben durch update alle Dateien in einem neuen Verzeichnis (restoreDir/update/YYYY-MM-DD) gesichert.
* Mit dem restoreDirs Attribut kann man die Anzahl der aufgehobenen Sicherungen (== Datum-Verzeichnisse) bestimmen, die Voreinstellung ist 3. Mit 0 kann man das Feature komplett abschalten.
* Ab Updatestand 29.10.2016 können bei Standardinstallationen ({{Link2Forum|Topic=59669|Message=511367}}) die fhem.cfg und fhem.save mit der Option -a des restore-Befehl wiederhergestellt werden.
* Zu Neuerungen ab Updatestand 18.03.2018 siehe {{Link2Forum|Topic=85801|Message=782640}}.

=== Update ging schief - restore letzte funktionierende Version ===
Sollte der Fall eintreten, dass FHEM nach dem Update nicht mehr startet, kann das restore des letzten Standes auch auf Systemebene durchgeführt werden. Anzeigen der vorhandenen Sicherungen:
<syntaxhighlight lang="bash">
ls /opt/fhem/restoreDir/update
</syntaxhighlight>
Die Pfad-Angabe YYYY-MM-DD durch das gewünschte Datum ersetzen:<syntaxhighlight lang="bash">
sudo -su fhem cp -R /opt/fhem/restoreDir/update/YYYY-MM-DD/* /opt/fhem/
</syntaxhighlight>
Die Berechtigungen bleiben durch die Verwendung des Users fhem erhalten. Danach sollte sich FHEM normal starten lassen. Im Zweifelsfall ist ein reboot des Systems die einfachste Lösung.

=== Einzelne Dateien aus dem SVN holen ===
Manchmal wird im Forum die Empfehlung gegeben ''Die Fehler-bereinigte Datei bitte direkt aus dem SVN holen''. Dies kann mit der Perlfunktion { Svn_GetFile('from SVN Path', 'to local Path') } direkt in der FHEM Kommandozeile erfolgen, hier ein paar Beispiele:
<syntaxhighlight lang="perl">
{ Svn_GetFile('FHEM/DevIo.pm', 'FHEM/DevIo.pm') }
{ Svn_GetFile('contrib/86_FS10.pm', 'FHEM/86_FS10.pm') }
{ Svn_GetFile('fhem.cfg', 'minimal.cfg') }
</syntaxhighlight>
Wie man sieht, kann man sich damit auch aktuelle Dateien aus dem SVN contrib Pfad in den lokalen FHEM Pfad holen. Der lokale contrib Pfad wird beim update NICHT aktualisiert und befindet sich damit immer auf dem Stand der Erstinstallation!

Update

2022-08-09T22:04:12Z

Soulman: /* Syntax */ update [-noSSL] ergänzt

{{SEITENTITEL:update}}
{{Infobox Modul
|ModPurpose=Befehl zur Aktualisierung der FHEM-Installation
|ModType=cmd
|ModCmdRef=update
|ModForumArea=Sonstiges
|ModTechName=98_update.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
[[update]] ist ein Befehl zur Aktualisierung der FHEM-Installation direkt über das FHEM [[FHEMWEB|Webfrontend]]. Von den Entwicklern bis zu einem bestimmten Zeitpunkt freigegebene Änderungen sind jeweils morgens ab 8:00 Uhr über die Update Funktion verfügbar. Änderungen, die später freigegeben werden, werden dementsprechend erst am nächsten Tag verfügbar.

== Syntax ==
:<code><nowiki>update [-noSSL] [<fileName>|all|check|force] [http://.../controlfile]</nowiki></code>
oder
:<code><nowiki>update [add source|delete source|list|reset]</nowiki></code>

'''Hinweise:'''
* FHEM sichert mit den Standardeinstellungen während des Updates "nur" die aktualisierten Modul(Installations-)dateien und bei Standardinstallationen ({{Link2Forum|Topic=59669|Message=511367}}) ab Updatestand 29.10.2016 die [[Konfiguration]] und fhem.save, aber beispielsweise nicht [[Plots erzeugen|Plots]] oder [[FileLog]]s. Soll vor dem Update ein vollständiges Backup von FHEM erstellt werden, muss das mit dem Attribut <code>[[#backup_before_update|backup_before_update]]</code> eingeschaltet werden.
* Lesen Sie aufmerksam die nach dem Update auf dem Monitor erscheinenden Meldungen zu Neuerungen und Änderungen.
* Nach einem Update ist immer ein ''shutdown restart'' erforderlich.
* geänderte und neu eingecheckte Module werden grundsätzlich erst am Folgetag ab ca. 8.00 Uhr durch den Update-Befehl verteilt.
* Mit dem Befehl [[version]] lässt sich die Version einzelner oder aller benutzten Module bestimmen.

== Parameter ==
Details zu Parametern des update Befehls:

=== Standardaufrufe ===
==== update ====
Die ganze FHEM-Installation wird auf die neueste Version gebracht. Vorhandene Module werden akualisiert und neue Module installiert.

==== update check ====
Es werden alle Module aufgelistet, von denen eine neuere als die bereits installierte Version verfügbar ist. Es wird nicht installiert.

==== update force ====
Das Update wird erzwungen (falls es beim regulären ''update'' Probleme geben sollte). Dieser Befehl ist nur mit Bedacht und ausschließlich im Notfall einzusetzen. Sollte ein reproduzierbares Problem existieren, dies bitte im FHEM-Forum berichten, damit dem nachgegangen werden kann.

==== update <Dateiname> ====
Mit z.B. <code>update 02_HTTPSRV.pm</code> wird nur von der Datei ''02_HTTPSRV.pm'' eine neue Version installiert. Alle anderen FHEM-Dateien werden nicht angetastet.

==== update all ====
Alle [[Systemübersicht#Module|offiziellen Module]] von FHEM sind in einem gemeinsamen Repository gespeichert. Nur diese Module werden in der Standardeinstellung durch den update-Befehl mit den bisher aufgeführten [[#Standardaufrufe|Standardaufrufen]] aktualisiert bzw. installiert. Einige Entwickler stellen ihre Module jedoch aus verschiedensten Gründen nicht im gemeinsamen Repository zur Verfügung, sondern nutzen eigene, separate Repositorys. Diese sogenannten "Thirdparty-Module" (auch bezeichnet als inoffizielle Module) können ebenfalls über update installiert und aktualisiert werden, wenn der Entwickler eine sogenannte Kontrolldatei (controlfile) in seinem Repository zur Verfügung stellt.

Zur Installation bzw. Update jedes einzelnen Thirdparty-Moduls ist nachfolgender Befehl aufzurufen (Webadresse und Kontrolldateiname sind modulabhängig passend zu ersetzen):
<code><nowiki>update all http://thirdparty.com/controls_funnymodule.txt</nowiki></code>

Die in den vorherigen Abschnitten erläuterten Standardaufruf (bis auf <code>update</code>) können durch Ergänzung um Webadresse und Kontrolldateiname (<nowiki>http://.../controlfile</nowiki> beim Befehls-Aufruf für das Update von einzelnen Thirdparty-Modulen genutzt werden.

=== Repository-Verwaltung ===
In den Standardeinstellungen von FHEM ist für jedes einzelne Repository ein separater Aufruf der [[#Standardaufrufe|Standardaufrufe]] zur Aktualiserung/Installation notwendig. Zur Vereinfachung des Update-Prozesses hat der update-Befehl eine eingebaute Repository-Verwaltung. Mittels der Repository-Verwaltung lassen sich die Standardaufrufe so beeinflussen, dass mit einem einzigen Aufruf sowohl die Module aus dem FHEM-Repository als auch aus verschiedenen Thirdparty-Repositorys beim Update berücksichtigt werden.

==== update add ====
Fügt ein zusätzliches Repository zur vereinfachten Nutzung über die Standardaufrufe hinzu. Ein Aufruf von <code><nowiki>update <Dateiname>|all|check|force</nowiki></code> berücksichtigt dann automatisch neben dem FHEM-eigenen Repository auch das hinzugefügte "Thirdparty-Repository".

Nach dem Hinzufügen durch beispielsweise <code><nowiki>update add http://thirdparty.com/controls_funnymodule.txt</nowiki></code> entfällt somit der manuelle Aufruf der Form <code><nowiki>update all http://thirdparty.com/controls_funnymodule.txt</nowiki></code> zur Aktualiserung. Er kann aber weiterhin genutzt werden, um ausschließlich für ein bestimmtes Repository ein Update zu erhalten und und nicht für alle.

Die Liste der Repositorys wird in der Verwaltungsdatei FHEM/controls.txt gespeichert.

==== update delete ====
Entfernt eine Repository aus der Verwaltungsdatei.

==== update list ====
Listet alle in der Verwaltungsdatei enthaltenen Repositorys auf.

==== update reset ====
Entfernt alle Fremd-Repositorys aus der Verwaltungsdatei. Nur das eigene Repository von FHEM wird noch von den Standardparametern berücksichtigt.

==== Syntax controlfile ====
Das Controlfile für thirdparty Module unterliegt einer festen Syntax. In jeder Zeile steht ein Dateiname und ein Befehl, was damit passieren soll. Ein Zeilenumbruch wird durch ein \n dargestellt.

Es können drei Befehle verwendet werden: CRE, MOV und UPD.

===== CRE - Anlegen einer Datei =====

Hiermit können vom Entwickler Dateinamen festgelegt und entsprechende Initial-Dateien verteilt werden; der Inhalt der Datei liegt nach dem ''ersten'' Verteilen in Anwenderhänden (z.B. nützlich bei *-user.css-Dateien).

<code>CRE <Datum> <Dateigröße> <Datei inkl. Pfad> </code>

Das Anlegen wird nur ausgeführt, wenn
* die Datei noch nicht vorhanden ist.

===== MOV - Verschieben oder Umbenennen einer Datei =====

<code>MOV <Quelldatei inkl. Pfad> <Zieldatei inkl. Pfad> </code>

Da Dateien nicht vollständig gelöscht werden können, kann eine Datei mit dem MOV Befehl in einen speziellen Ordner namens "unused" verschoben werden:

<code>MOV <Quelldatei inkl. Pfad> unused </code>

===== UPD - Aktualisieren einer Datei =====

<code>UPD <Datum> <Dateigröße> <Datei inkl. Pfad> </code>

Die Aktualisierung wird nur ausgeführt, wenn
* das Datum der lokalen Datei sich vom Datum der Update-Datei unterscheidet.
* die Dateigröße der Update-Datei mit der Dateigröße im UPD Eintrag übereinstimmt.

Beispiel:

<code>
UPD 2018-10-04_20:17:35 55143 FHEM/55_MyFirstFile.pm

UPD 2018-09-27_23:26:21 17121 FHEM/55_MySecondFile.pm
</code>

Beispiel für die Erzeugung der UPD Einträge:

<syntaxhighlight lang="perl">
#!/usr/bin/perl

use File::Basename;
use POSIX qw(strftime);
use strict;

my @filenames = ( "55_MyFirstFile.pm",
"55_MySecondFile.pm");

my $prefix = "FHEM";
my $filename = "";
foreach $filename (@filenames)
{
my @statOutput = stat($prefix."/".$filename);

if (scalar @statOutput != 13)
{
printf("error: stat has unexpected return value for ".$prefix."/".$filename."\n");
next;
}

my $mtime = $statOutput[9];
my $date = POSIX::strftime("%Y-%m-%d", localtime($mtime));
my $time = POSIX::strftime("%H:%M:%S", localtime($mtime));
my $filetime = $date."_".$time;

my $filesize = $statOutput[7];

printf("UPD ".$filetime." ".$filesize." ".$prefix."/".$filename."\n");
}
</syntaxhighlight>

== Attribute ==
Zur weiteren Beeinflussung der Funktionsweise des update Befehls können Attribute verwendet werden. Diese müssen für das Objekt ''global'' gesetzt werden, also mit einem Konfigurationsbefehl der Art
:<code>attr global ...</code>

=== backup_before_update ===
siehe auch [[backup]]

=== restoreDirs ===
siehe [[#Rücksichern beim Update überschriebener Dateien|Rücksichern beim Update überschriebener Dateien]]

=== exclude_from_update ===
Mit der Definition
:<code>attr global exclude_from_update ...</code>
kann eine Liste von Dateien spezifiziert werden, die bei der Ausführung des update Befehls '''nicht''' aktualisiert werden sollen. Dateien können auch über reguläre Ausdrücke definiert werden, die einzelnen Einträge werden durch Leerzeichen voneinander getrennt.

Einen Spezialfall stellt die ''commandref'' dar, die seit einer Modifikation des Update Prozesses (März 2015, beschrieben in dieser {{Link2Forum|Topic=34450|LinkText=Forendiskussion}}) nicht mehr heruntergeladen wird, sondern auf dem Benutzersystem durch Extraktion der Dokumentation aus den einzelnen Modulen generiert wird, angezeigt durch die Meldung im fhem.log:
:''Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while''.
Sollte dieser Prozess (z.B. auf einem langsamen Rechner) zu lange dauern, bleibt die Meldung
:''update finished, "shutdown restart" is needed to activate the changes.''
aus. Wird ''commandref'' in das <code>exclude_from_update</code> Attribut eingetragen, entfällt dieser Schritt, die lokale ''commandref'' wird allerdings dann auch nicht mehr aktualisiert. Die modulspezifische Hilfe, die z.B. über <code>help modulname</code> aufgerufen werden kann, ist davon nicht betroffen.

== Anwendungsbeispiel / Problembehebung ==
=== Durchführung eines Updates ===
Zunächst kann mit dem Befehl
:<code>update check</code>
überprüft werden, ob es überhaupt ein neues Update gibt und welche Dateien hierbei ausgetauscht würden (die angezeigten Infos sollten in einer Textdatei gesichert werden. Mit diesen Infos kann gezielter nach Problemen, die vielleicht nach einem Update auftreten, gesucht werden). Anschließend kann mittels:
:<code>update</code>
das Update eingespielt werden. Hierbei ist zu beachten, dass die Befehle auf der FHEM Webseite oben ([[Konfiguration|Befehls-Eingabefeld]]) eingegeben werden und anschließend die "Enter" Taste auf der Tastatur gedrückt werden muss.

Gibt es kein Update für FHEM, sieht die Ausgabe z.B. nach "update check" wie folgt aus:

:<code>List of new / modified files since last update:</code>
:<code>nothing to do...</code>

=== Rücksichern beim Update überschriebener Dateien ===
Sollte nach einem update etwas ganz oder teilweise nicht mehr funktionieren, kann man auf den Stand vor dem Update zurückgehen. Die Befehle sind für die FHEM Kommandozeile.

Man kann sich einen Überblick über die Funktion des Befehls {{Link2CmdRef|Anker=restore|Label=restore}} verschaffen:
<pre>
help restore
</pre>
Man kann die gesicherten Versionen listen
<pre>
restore list update

Available for restore in update:
2020-11-01
</pre>
Man kann in der Verzeichnis Ebene tiefer suchen
<pre>
restore list update/2020-11-01

Available for restore in update/2020-11-01:
CHANGED
FHEM
MAINTAINER.txt
configDB.pm
fhem.cfg
fhem.pl
lib
log
</pre>
Man kann gezielt wiederherstellen, entweder den kompletten Pfad oder einzelne Dateien.
<pre>
restore update/2020-11-01/FHEM
restore update/2020-11-01/FHEM/10_CUL_HM.pm
</pre>
Weitere Informationen:
* Per default werden vor dem Überschreiben durch update alle Dateien in einem neuen Verzeichnis (restoreDir/update/YYYY-MM-DD) gesichert.
* Mit dem restoreDirs Attribut kann man die Anzahl der aufgehobenen Sicherungen (== Datum-Verzeichnisse) bestimmen, die Voreinstellung ist 3. Mit 0 kann man das Feature komplett abschalten.
* Ab Updatestand 29.10.2016 können bei Standardinstallationen ({{Link2Forum|Topic=59669|Message=511367}}) die fhem.cfg und fhem.save mit der Option -a des restore-Befehl wiederhergestellt werden.
* Zu Neuerungen ab Updatestand 18.03.2018 siehe {{Link2Forum|Topic=85801|Message=782640}}.

=== Update ging schief - restore letzte funktionierende Version ===
Sollte der Fall eintreten, dass FHEM nach dem Update nicht mehr startet, kann das restore des letzten Standes auch auf Systemebene durchgeführt werden. Anzeigen der vorhandenen Sicherungen:
<syntaxhighlight lang="bash">
ls /opt/fhem/restoreDir/update
</syntaxhighlight>
Die Pfad-Angabe YYYY-MM-DD durch das gewünschte Datum ersetzen:<syntaxhighlight lang="bash">
sudo -su fhem cp -R /opt/fhem/restoreDir/update/YYYY-MM-DD/* /opt/fhem/
</syntaxhighlight>
Die Berechtigungen bleiben durch die Verwendung des Users fhem erhalten. Danach sollte sich FHEM normal starten lassen. Im Zweifelsfall ist ein reboot des Systems die einfachste Lösung.

=== Einzelne Dateien aus dem SVN holen ===
Manchmal wird im Forum die Empfehlung gegeben ''Die Fehler-bereinigte Datei bitte direkt aus dem SVN holen''. Dies kann mit der Perlfunktion { Svn_GetFile('from SVN Path', 'to local Path') } direkt in der FHEM Kommandozeile erfolgen, hier ein paar Beispiele:
<syntaxhighlight lang="perl">
{ Svn_GetFile('FHEM/DevIo.pm', 'FHEM/DevIo.pm') }
{ Svn_GetFile('contrib/86_FS10.pm', 'FHEM/86_FS10.pm') }
{ Svn_GetFile('fhem.cfg', 'minimal.cfg') }
</syntaxhighlight>
Wie man sieht, kann man sich damit auch aktuelle Dateien aus dem SVN contrib Pfad in den lokalen FHEM Pfad holen. Der lokale contrib Pfad wird beim update NICHT aktualisiert und befindet sich damit immer auf dem Stand der Erstinstallation!

Diskussion:FHT: Datum und Zeit von FHEM setzen lassen

2022-01-04T17:17:58Z

Soulman: Neuer Abschnitt /* Überkomplexe Lösung */

== Seitentitel ==

Auch hier wieder ein Doppelpunkt im Seitentitel. Eventuell ändern auf "FHT - Datum und ..."? --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 10:08, 25. Jan. 2017 (CET)
:analog [[Diskussion:FritzBox:_FHEM_unter_root_starten#Seitentitel]] erst einmal keine Änderung. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 09:24, 26. Jan. 2017 (CET)

== Überkomplexe Lösung ==

Für mich ist das ein Beispiel, wie Personen in FHEM überkomplexe Lösungen für Probleme erstellen, die im Prinzip recht einfach lösbar sind. Die dargestellten Varianten C und D sind "the way to go", die Codeschnippsel in A und B bergen keinerlei Vorteile, sondern sind vermutlich blosser Unkenntnis der Möglichkeiten unter wie unter c und D beschrieben geschuldet. Das schreckt Neulinge eher ab oder sie eignen sich diese "Schwurbelstil" selbst an und erzeugen dann auch unnötig komplexen Code um simpelste Dinge zu lösen. Speziell da FHT auch langsam echt aus der Mode kommt und die Relevanz daher des Artikels daher gering ist, würde ich daher die Varianten A und B demnächst löschen. Oder sogar den ganzen Artikel. --[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 18:17, 4. Jan. 2022 (CET)

AT zu einem absoluten Datum ausführen

2022-01-04T16:50:58Z

Soulman: Ergänzung

'''Achtung:''' der Befehl [[at]] kennt im Gegensatz zur Behauptung im Artikel unten durchaus Ausführungen zu einem bestimmtes Datum.

Das letztgenannte Beispiel kann z.b. mit
<nowiki>define Licht_25_Januar_an at 2011-01-25T07:15:00 set Licht1 on</nowiki>
Realisiert werden, siehe auch Commandrefeintrag.

Die unten dargestellt Lösung, täglich bei Erreichen der gewünschten Uhrzeit zu prüfen ob der richtige Tag erreicht wurde, erfordert mehr Code und ist auch Perfomanceseitig ungünstiger.

________________________________________________________________________________________________

Mit dem Befehl [[at]] können in FHEM Aktionen zu einem definierten Zeitpunkt ausgeführt werden:

<nowiki>define morgens_Licht_an at *07:15:00 set Licht1 on</nowiki>
Es können nur relative und absolute Uhrzeiten, jedoch nicht ein bestimmtes Datum definiert werden.

Allerdings kann die Ausführung an Bedingungen geknüpft sein, wie z.b. bestimmte Wochentage oder nur am Wochenende:

<nowiki>define morgens_Licht_Wochenende at *07:15:00 {if (!($we)) {fhem("set Licht1 on")} }</nowiki>
Auf die selbe Art kann auch auf ein Ausführungsdatum geprüft werden.

<nowiki>define Licht_25_Januar_an at *07:15:00 {if($year==2011 && $month==1 && $mday==25) {fhem("set Licht1 on")} }</nowiki>
In diesem Fall wird täglich um 7:15 Uhr geprüft, ob der 25. Januar 2011 ist und falls ja, wird die Aktion ausgeführt.

Da dieser Fall nur einmal zutrifft, ist es sinnvoll, die Aktion nach Auslösung zu löschen, damit nicht nach dem 25. Januar 2011 weiter täglich geprüft wird, ob das Datum nochmal auftritt:

<pre>define Licht_25_Januar_an at *07:15:00 {if($year==2011 && $month==1 && $mday==25) \
{fhem ("set Licht1 on; delete Licht_25_Januar_an"} }</pre>

[[Kategorie:Code Snippets]]

Diskussion:AT zu einem absoluten Datum ausführen

2022-01-04T16:44:55Z

Soulman: Die Seite wurde neu angelegt: „Hm.. die Behauptng "Es können nur relative und absolute Uhrzeiten, jedoch nicht ein bestimmtes Datum definiert werden." ist meiner Auffassung nach falsch, das…“

Hm.. die Behauptng "Es können nur relative und absolute Uhrzeiten, jedoch nicht ein bestimmtes Datum definiert werden." ist meiner Auffassung nach falsch, das geht auch aus der Commandref anders hervor, denn es gibt da expliziet "<Datespec>". Damit der ganze Artikel hinfällig. Ich würde den gerne löschen--[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 17:44, 4. Jan. 2022 (CET)

Trick der Woche

2022-01-04T16:37:04Z

Soulman: Luftfeuchtesensor

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich ström durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt es viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL2 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

HM-CC-VD Funk-Stellantrieb

2022-01-04T16:30:34Z

Soulman: /* Betrieb mit FHEM */ Ergänzung

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]], mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen [[HM-CC-TC Funk-Wandthermostat]] [[Peering (HomeMatic)|gepeert]], dieser wird dann mit FHEM (z.b. einer [[Virtueller Controller VCCU |VCCU]]) gepairt. Dadurch ist der HM-CC-TC für die Ansteuerung der Ventiltriebe zuständig. Achtung: Peeren zwischen Ventiltrieb (und ggf Tür-/Fensterkontakte) und HM-CC-TC muss zuerst erfolgen, erst dann pairing des Thermostaten mit FHEM.

Alternativ können auch Stellantriebe und Tür-/Fensterkontakte sowie der HM-CC-TC mit FHEM (z.b. einem VCCU oder direkt mit einem IO wie dem CUL) gepairen werden, also z.b. <pre>
set CUL hmPairForSec 300
</pre>und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden). Dann Stellantriebe und Tür-/Fensterkontakte mit den Channels des HM-CC-TC peeren (siehe [http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan].

Eine etwas detailliertere Diskussion der beiden Optionen findet sich im Artikel zum Nachfolgemodell [[HM-TC-IT-WM-W-EU]]

Ausserdem kann der Antrieb mit einem virtuellen HM-CC-TC betreiben werden, siehe weiter unten.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Stromversorgung / Batterien ==

=== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ===
* Bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery:low in den Readings und Events.
* Bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery:critical in den Readings und Events.
Faktisch ist ein Betrieb bis ca. 2,2 Volt möglich (also je Zelle 1,1 Volt) darunter nimmt die Zuverlässigkeit der Funkverbindung stark ab.

=== Akkubetrieb ===
Wegen der oben genannten Warngrenzen eigenen sich viele Akkus nicht sehr gut, da auch frisch geladenen NiMh-Akkus eine Zellenspannung von nur etwas über 1,2 Volt haben. Desshalb wird schnell die battery:low Warngrenze erreicht; mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt. Mit ''NiMh-Akkus mit geringer Selbstentladung'' (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,2 Volt verläuft.

= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU) 'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung.<ref>{{Link2Forum|Topic=41588|Message=339484|LinkText=FHEM-Forum-Beitrag}}</ref>
<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>

=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID

Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>

=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.

= Fehlercodes =
Im Display des Antriebs wird im Normalbetrieb der Öffnungswinkel in % angezeigt, jedoch vor der Montage bzw. Im Fehlerfall folgende Codes:

== Statuscodes ==

*'''A1''' Batterien neu eingelegt, Antrieb fährt Stellstift zurück
*'''A2''' Batterien neu eingelegt, Stellstift ist komplett eingefahren, fertig zur Montage
*'''A3''' Taste wurde nach Montage kurz gedrückt, Stellstift fährt aus und schließt Ventil
Wenn Vorgang abgeschlossen zeigt der Antrieb 0%, solange bis das Ventil im Betrieb geöffnet werden soll.

== Fehlercodes ==

*'''F1''' Ventilantrieb kann Stift nicht bewegen. Ventil zu schwergängig oder blockiert
*'''F2''' Ventilantrieb nicht montiert oder Stellbereich zu gross. Ursache ist fast immer, dass die Taste im Zustand '''A2''' gedrückt wurde, obwohl der Antrieb noch nicht montiert war. Batterie kurz entnehmen, warten bis Display erlischt, neu einlegen, Antrieb nach '''A2''' zuerst montieren, dann Taste drücken.
*'''F3''' Stellbereich zu klein. Ursache ist oft ein klemmendes Ventil, versuchen Ventil gangbar zu machen.
*'''F4+Batterisymbol''' Batterien sind leer (Batteriespannung liegt dann unter 2,3 Volt). Speziell bei Nutzung von Akkus funktioniert der Antrieb aber mitunter noch eine kurze Zeit weiter.
*'''F5''' Anlernen gesperrt. Tritt z.b. auf, wenn versucht wird, das Ventil mit beiden oben beschrieben Methoden zu betreiben, also peering mit HM-CC-TC und zugleich pairing mit FHEM.
*''' Antennensymbol blinkt''' Keine Funkverbindung. Gerät ist noch nicht gepeert oder gepairt oder das gepeerte oder gepairte Device kann nicht empfangen werden. (z.b. Batterie im HM-CC-TC leer oder Funkstörung)
*''' Battriesymbol''' Batterien sind fast leer. Speziell bei Nutzung von Akkus funktioniert der Antrieb aber mitunter noch recht lange problemlos weiter.

= bekannte Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in FHEM (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

----

; Quellen:
* {{Link2Forum|Topic=60296|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=22419|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=30738|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=54911|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=41588|LinkText=FHEM-Forum-Thema}}

= Links =
* Anleitung bei EQ-3: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

----
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HM-CC-VD Funk-Stellantrieb

2022-01-04T16:28:41Z

Soulman: /* Fehlercodes */ typos

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]], mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen [[HM-CC-TC Funk-Wandthermostat]] [[Peering (HomeMatic)|gepeert]], dieser wird dann mit FHEM (z.b. einer [[Virtueller Controller VCCU |VCCU]]) gepairt. Dadurch ist der HM-CC-TC für die Ansteuerung der Ventiltriebe zuständig.

Alternativ können auch Stellantriebe und Tür-/Fensterkontakte sowie der HM-CC-TC mit FHEM (z.b. einem VCCU oder direkt mit einem IO wie dem CUL) gepairen werden, also z.b. <pre>
set CUL hmPairForSec 300
</pre>und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden). Dann Stellantriebe und Tür-/Fensterkontakte mit den Channels des HM-CC-TC peeren (siehe [http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan].

Eine etwas detailliertere Diskussion der beiden Optionen findet sich im Artikel zum Nachfolgemodell [[HM-TC-IT-WM-W-EU]]

Ausserdem kann der Antrieb mit einem virtuellen HM-CC-TC betreiben werden, siehe weiter unten.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Stromversorgung / Batterien ==

=== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ===
* Bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery:low in den Readings und Events.
* Bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery:critical in den Readings und Events.
Faktisch ist ein Betrieb bis ca. 2,2 Volt möglich (also je Zelle 1,1 Volt) darunter nimmt die Zuverlässigkeit der Funkverbindung stark ab.

=== Akkubetrieb ===
Wegen der oben genannten Warngrenzen eigenen sich viele Akkus nicht sehr gut, da auch frisch geladenen NiMh-Akkus eine Zellenspannung von nur etwas über 1,2 Volt haben. Desshalb wird schnell die battery:low Warngrenze erreicht; mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt. Mit ''NiMh-Akkus mit geringer Selbstentladung'' (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,2 Volt verläuft.

= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU) 'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung.<ref>{{Link2Forum|Topic=41588|Message=339484|LinkText=FHEM-Forum-Beitrag}}</ref>
<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>

=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID

Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>

=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.

= Fehlercodes =
Im Display des Antriebs wird im Normalbetrieb der Öffnungswinkel in % angezeigt, jedoch vor der Montage bzw. Im Fehlerfall folgende Codes:

== Statuscodes ==

*'''A1''' Batterien neu eingelegt, Antrieb fährt Stellstift zurück
*'''A2''' Batterien neu eingelegt, Stellstift ist komplett eingefahren, fertig zur Montage
*'''A3''' Taste wurde nach Montage kurz gedrückt, Stellstift fährt aus und schließt Ventil
Wenn Vorgang abgeschlossen zeigt der Antrieb 0%, solange bis das Ventil im Betrieb geöffnet werden soll.

== Fehlercodes ==

*'''F1''' Ventilantrieb kann Stift nicht bewegen. Ventil zu schwergängig oder blockiert
*'''F2''' Ventilantrieb nicht montiert oder Stellbereich zu gross. Ursache ist fast immer, dass die Taste im Zustand '''A2''' gedrückt wurde, obwohl der Antrieb noch nicht montiert war. Batterie kurz entnehmen, warten bis Display erlischt, neu einlegen, Antrieb nach '''A2''' zuerst montieren, dann Taste drücken.
*'''F3''' Stellbereich zu klein. Ursache ist oft ein klemmendes Ventil, versuchen Ventil gangbar zu machen.
*'''F4+Batterisymbol''' Batterien sind leer (Batteriespannung liegt dann unter 2,3 Volt). Speziell bei Nutzung von Akkus funktioniert der Antrieb aber mitunter noch eine kurze Zeit weiter.
*'''F5''' Anlernen gesperrt. Tritt z.b. auf, wenn versucht wird, das Ventil mit beiden oben beschrieben Methoden zu betreiben, also peering mit HM-CC-TC und zugleich pairing mit FHEM.
*''' Antennensymbol blinkt''' Keine Funkverbindung. Gerät ist noch nicht gepeert oder gepairt oder das gepeerte oder gepairte Device kann nicht empfangen werden. (z.b. Batterie im HM-CC-TC leer oder Funkstörung)
*''' Battriesymbol''' Batterien sind fast leer. Speziell bei Nutzung von Akkus funktioniert der Antrieb aber mitunter noch recht lange problemlos weiter.

= bekannte Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in FHEM (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

----

; Quellen:
* {{Link2Forum|Topic=60296|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=22419|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=30738|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=54911|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=41588|LinkText=FHEM-Forum-Thema}}

= Links =
* Anleitung bei EQ-3: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

----
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HM-CC-VD Funk-Stellantrieb

2022-01-04T16:27:59Z

Soulman: /* Fehlercodes */ Korrektur

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]], mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen [[HM-CC-TC Funk-Wandthermostat]] [[Peering (HomeMatic)|gepeert]], dieser wird dann mit FHEM (z.b. einer [[Virtueller Controller VCCU |VCCU]]) gepairt. Dadurch ist der HM-CC-TC für die Ansteuerung der Ventiltriebe zuständig.

Alternativ können auch Stellantriebe und Tür-/Fensterkontakte sowie der HM-CC-TC mit FHEM (z.b. einem VCCU oder direkt mit einem IO wie dem CUL) gepairen werden, also z.b. <pre>
set CUL hmPairForSec 300
</pre>und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden). Dann Stellantriebe und Tür-/Fensterkontakte mit den Channels des HM-CC-TC peeren (siehe [http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan].

Eine etwas detailliertere Diskussion der beiden Optionen findet sich im Artikel zum Nachfolgemodell [[HM-TC-IT-WM-W-EU]]

Ausserdem kann der Antrieb mit einem virtuellen HM-CC-TC betreiben werden, siehe weiter unten.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Stromversorgung / Batterien ==

=== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ===
* Bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery:low in den Readings und Events.
* Bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery:critical in den Readings und Events.
Faktisch ist ein Betrieb bis ca. 2,2 Volt möglich (also je Zelle 1,1 Volt) darunter nimmt die Zuverlässigkeit der Funkverbindung stark ab.

=== Akkubetrieb ===
Wegen der oben genannten Warngrenzen eigenen sich viele Akkus nicht sehr gut, da auch frisch geladenen NiMh-Akkus eine Zellenspannung von nur etwas über 1,2 Volt haben. Desshalb wird schnell die battery:low Warngrenze erreicht; mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt. Mit ''NiMh-Akkus mit geringer Selbstentladung'' (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,2 Volt verläuft.

= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU) 'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung.<ref>{{Link2Forum|Topic=41588|Message=339484|LinkText=FHEM-Forum-Beitrag}}</ref>
<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>

=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID

Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>

=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.

= Fehlercodes =
Im Display des Antriebs wird im Normalbetrieb der Öffnungswinkel in % angezeigt, jedoch vor der Montage bzw. Im Fehlerfall folgende Codes:

== Statuscodes ==

*'''A1''' Batterien neu eingelegt, Antrieb fährt Stellstift zurück
*'''A2''' Batterien neu eingelegt, Stellstift ist komplett eingefahren, fertig zur Montage
*'''A3''' Taste wurde nach Montage kurz gedrückt, Stellstift fährt aus und schließt Ventil
Wenn Vorgang abgeschlossen zeigt der Antrieb 0%, solange bis das Ventil im Betrieb geöffnet werden soll.

== Fehlercodes ==

*'''F1''' Ventilantrieb kann Stift nicht bewegen. Ventil zu schwergängig oder blockiert
*'''F2''' Ventilantrieb nicht montiert oder Stellbereich zu gross. Ursache ist fast immer, dass die Taste im Zustand '''A2''' gedrückt wurde, obwohl der Antrieb noch nicht montiert war. Batterie kurz entnehmen, warten bis Display erlischt, neu einlegen, Antrieb nach '''A2''' zuerst montieren, dann Taste drücken.
*'''F3''' Stellbereich zu klein. Ursache ist oft ein klemmendes Ventil, versuchen Ventil gangbar zu machen.
*'''F4+Batterisymbol''' Batterien sind leer. (Batteriespannung liegt dann unter 2,3 Volt) Speziell bei Nutzung von Akkus funktioniert der Antrieb aber mitunter noch eine kurze Zeit weiter.
*'''F5''' Anlernen gesperrt. Tritt z.b. auf, wenn versucht wird, das Ventil mit beiden oben beschrieben Methoden zu betreiben, also peering mit HM-CC-TC und zugleich pairing mit FHEM.
*''' Antennensymbol blinkt''' Keine Funkverbindung. Gerät ist noch nicht gepeert oder gepairt oder das gepeerte oder gepairte Device kann nicht empfangen werden. (z.b. Batterie im HM-CC-TC leer oder Funkstörung)
*''' Battriesymbol'''Batterien sind fast leer. Speziell bei Nutzung von Akkus funktioniert der Antrieb aber mitunter noch recht lange problemlos weiter.

= bekannte Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in FHEM (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

----

; Quellen:
* {{Link2Forum|Topic=60296|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=22419|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=30738|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=54911|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=41588|LinkText=FHEM-Forum-Thema}}

= Links =
* Anleitung bei EQ-3: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

----
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HM-CC-VD Funk-Stellantrieb

2022-01-04T16:23:08Z

Soulman: /* Fehlercodes */ typos

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]], mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen [[HM-CC-TC Funk-Wandthermostat]] [[Peering (HomeMatic)|gepeert]], dieser wird dann mit FHEM (z.b. einer [[Virtueller Controller VCCU |VCCU]]) gepairt. Dadurch ist der HM-CC-TC für die Ansteuerung der Ventiltriebe zuständig.

Alternativ können auch Stellantriebe und Tür-/Fensterkontakte sowie der HM-CC-TC mit FHEM (z.b. einem VCCU oder direkt mit einem IO wie dem CUL) gepairen werden, also z.b. <pre>
set CUL hmPairForSec 300
</pre>und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden). Dann Stellantriebe und Tür-/Fensterkontakte mit den Channels des HM-CC-TC peeren (siehe [http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan].

Eine etwas detailliertere Diskussion der beiden Optionen findet sich im Artikel zum Nachfolgemodell [[HM-TC-IT-WM-W-EU]]

Ausserdem kann der Antrieb mit einem virtuellen HM-CC-TC betreiben werden, siehe weiter unten.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Stromversorgung / Batterien ==

=== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ===
* Bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery:low in den Readings und Events.
* Bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery:critical in den Readings und Events.
Faktisch ist ein Betrieb bis ca. 2,2 Volt möglich (also je Zelle 1,1 Volt) darunter nimmt die Zuverlässigkeit der Funkverbindung stark ab.

=== Akkubetrieb ===
Wegen der oben genannten Warngrenzen eigenen sich viele Akkus nicht sehr gut, da auch frisch geladenen NiMh-Akkus eine Zellenspannung von nur etwas über 1,2 Volt haben. Desshalb wird schnell die battery:low Warngrenze erreicht; mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt. Mit ''NiMh-Akkus mit geringer Selbstentladung'' (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,2 Volt verläuft.

= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU) 'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung.<ref>{{Link2Forum|Topic=41588|Message=339484|LinkText=FHEM-Forum-Beitrag}}</ref>
<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>

=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID

Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>

=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.

= Fehlercodes =
Im Display des Antriebs wird im Normalbetrieb der Öffnungswinkel in % angezeigt, jedoch vor der Montage bzw. Im Fehlerfall folgende Codes:

== Statuscodes ==

*'''A1''' Batterien neu eingelegt, Antrieb fährt Stellstift zurück
*'''A2''' Batterien neu eingelegt, Stellstift ist komplett eingefahren, fertig zur Montage
*'''A3''' Taste wurde nach Montage kurz gedrückt, Stellstift fährt aus und schließt Ventil
Wenn Vorgang abgeschlossen zeigt der Antrieb 0%, solange bis das Ventil im Betrieb geöffnet werden soll.

== Fehlercodes ==

*'''F1''' Ventilantrieb kann Stift nicht bewegen. Ventil zu schwergängig oder blockiert
*'''F2''' Ventilantrieb nicht montiert oder Stellbereich zu gross. Ursache ist fast immer, dass die Taste im Zustand '''A2''' gedrückt wurde, obwohl der Antrieb noch nicht montiert war. Batterie kurz entnehmen, warten bis Display erlischt, neu einlegen, Antrieb nach '''A2''' zuerst montieren, dann Taste drücken.
*'''F3''' Stellbereich zu klein. Ursache ist oft ein klemmendes Ventil, versuchen Ventil gangbar zu machen.
*'''F4+Batterisymbol''' Batterien sind leer, nicht mehr genug Spannung um Antrieb zu bewegen. Batteriespannung liegt dann meist um die 2 Volt.
*'''F5''' Anlernen gesperrt. Tritt z.b. auf, wenn versucht wird, das Ventil mit beiden oben beschrieben Methoden zu betreiben, also peering mit HM-CC-TC und zugleich pairing mit FHEM.
*''' Antennensymbol blinkt''' Keine Funkverbindung. Gerät ist noch nicht gepeert oder gepairt oder das gepeerte oder gepairte Device kann nicht empfangen werden. (z.b. Batterie im HM-CC-TC leer oder Funkstörung)
*''' Battriesymbol'''Batterien sind fast leer. Speziell bei Nutzung von Akkus funktioniert der Antrieb aber mitunter noch recht lange weiter.

= bekannte Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in FHEM (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

----

; Quellen:
* {{Link2Forum|Topic=60296|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=22419|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=30738|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=54911|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=41588|LinkText=FHEM-Forum-Thema}}

= Links =
* Anleitung bei EQ-3: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

----
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HM-CC-VD Funk-Stellantrieb

2022-01-04T16:21:24Z

Soulman: /* Fehlercodes */ Formatierung

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]], mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen [[HM-CC-TC Funk-Wandthermostat]] [[Peering (HomeMatic)|gepeert]], dieser wird dann mit FHEM (z.b. einer [[Virtueller Controller VCCU |VCCU]]) gepairt. Dadurch ist der HM-CC-TC für die Ansteuerung der Ventiltriebe zuständig.

Alternativ können auch Stellantriebe und Tür-/Fensterkontakte sowie der HM-CC-TC mit FHEM (z.b. einem VCCU oder direkt mit einem IO wie dem CUL) gepairen werden, also z.b. <pre>
set CUL hmPairForSec 300
</pre>und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden). Dann Stellantriebe und Tür-/Fensterkontakte mit den Channels des HM-CC-TC peeren (siehe [http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan].

Eine etwas detailliertere Diskussion der beiden Optionen findet sich im Artikel zum Nachfolgemodell [[HM-TC-IT-WM-W-EU]]

Ausserdem kann der Antrieb mit einem virtuellen HM-CC-TC betreiben werden, siehe weiter unten.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Stromversorgung / Batterien ==

=== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ===
* Bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery:low in den Readings und Events.
* Bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery:critical in den Readings und Events.
Faktisch ist ein Betrieb bis ca. 2,2 Volt möglich (also je Zelle 1,1 Volt) darunter nimmt die Zuverlässigkeit der Funkverbindung stark ab.

=== Akkubetrieb ===
Wegen der oben genannten Warngrenzen eigenen sich viele Akkus nicht sehr gut, da auch frisch geladenen NiMh-Akkus eine Zellenspannung von nur etwas über 1,2 Volt haben. Desshalb wird schnell die battery:low Warngrenze erreicht; mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt. Mit ''NiMh-Akkus mit geringer Selbstentladung'' (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,2 Volt verläuft.

= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU) 'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung.<ref>{{Link2Forum|Topic=41588|Message=339484|LinkText=FHEM-Forum-Beitrag}}</ref>
<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>

=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID

Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>

=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.

= Fehlercodes =
Im Display des Antriebs wird im Normalbetrieb der Öffnungswinkel in % angezeigt, jedoch vor der Montage bzw. Im Fehlerfall folgende Codes:

== Statuscodes ==

*'''A1''' Batterien neu eingelegt, Antrieb fährt Stellstift zurück
*'''A2''' Batterien neu eingelegt, Stellstift ist komplett eingefahren, fertig zur Montage
*'''A3''' Taste wurde nach Montage kurz gedrückt, Stellstift fährt aus und schließt Ventil
Wenn Vorgang abgeschlossen zeigt der Antrieb 0%, solange bis das Ventil im Betrieb geöffnet werden soll.

== Fehlercodes ==

*'''F1''' Ventilantrieb kann Stift nicht bewegen. Ventil zu schwergängig oder blockiert
*'''F2''' Ventilantrieb nicht montiert oder Stellbereich zu gross. Ursache ist fast immer, dass die Taste im Zustand '''A2''' gedrückt wurde, obwohl der Antrieb noch nicht montiert war. Batterie kurz entnehmen, warten bis Display erlischt, neu einlegen, Antrieb nach '''A2''' zuerst montieren, dann Taste drücken.
*'''F3''' Stellbereich zu klein. Ursache ist oft ein klemmendes Ventil, versuchen Ventil gangbar zu machen.
*'''F4+Batterisymbol''' Batterien sind leer, nicht mehr genug Spannung um Antrieb zu bewegen. Batteriespannung liegt dann meist um die 2 Volt.
*'''F5''' Anlernen gesperrt. Tritt z.b. auf, wenn versucht wird das Ventil mit beiden oben beschrieben MEthoden zu betreiben also peering mit HM-CC-TC und zugleich pairing mit FHEM.
*''' Antennensymbol blinkt''' Keine Funkverbindung. Gerät ist noch nicht gepeert oder gepairt oder das gepeerte oder gepairte Device kann nicht empfangen werden. (Batterie im HM-CC-TC leer oder Funkstörung)
*''' Battriesymbol'''Batterien sind fast leer.

= bekannte Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in FHEM (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

----

; Quellen:
* {{Link2Forum|Topic=60296|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=22419|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=30738|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=54911|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=41588|LinkText=FHEM-Forum-Thema}}

= Links =
* Anleitung bei EQ-3: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

----
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HM-CC-VD Funk-Stellantrieb

2022-01-04T16:19:36Z

Soulman: /* Akkubetrieb */ korrektur

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]], mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen [[HM-CC-TC Funk-Wandthermostat]] [[Peering (HomeMatic)|gepeert]], dieser wird dann mit FHEM (z.b. einer [[Virtueller Controller VCCU |VCCU]]) gepairt. Dadurch ist der HM-CC-TC für die Ansteuerung der Ventiltriebe zuständig.

Alternativ können auch Stellantriebe und Tür-/Fensterkontakte sowie der HM-CC-TC mit FHEM (z.b. einem VCCU oder direkt mit einem IO wie dem CUL) gepairen werden, also z.b. <pre>
set CUL hmPairForSec 300
</pre>und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden). Dann Stellantriebe und Tür-/Fensterkontakte mit den Channels des HM-CC-TC peeren (siehe [http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan].

Eine etwas detailliertere Diskussion der beiden Optionen findet sich im Artikel zum Nachfolgemodell [[HM-TC-IT-WM-W-EU]]

Ausserdem kann der Antrieb mit einem virtuellen HM-CC-TC betreiben werden, siehe weiter unten.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Stromversorgung / Batterien ==

=== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ===
* Bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery:low in den Readings und Events.
* Bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery:critical in den Readings und Events.
Faktisch ist ein Betrieb bis ca. 2,2 Volt möglich (also je Zelle 1,1 Volt) darunter nimmt die Zuverlässigkeit der Funkverbindung stark ab.

=== Akkubetrieb ===
Wegen der oben genannten Warngrenzen eigenen sich viele Akkus nicht sehr gut, da auch frisch geladenen NiMh-Akkus eine Zellenspannung von nur etwas über 1,2 Volt haben. Desshalb wird schnell die battery:low Warngrenze erreicht; mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt. Mit ''NiMh-Akkus mit geringer Selbstentladung'' (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,2 Volt verläuft.

= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU) 'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung.<ref>{{Link2Forum|Topic=41588|Message=339484|LinkText=FHEM-Forum-Beitrag}}</ref>
<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>

=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID

Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>

=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.

= Fehlercodes =
Im Display des Antriebs wird im Normalbetrieb der Öffnungswinkel in % angezeigt, jedoch vor der Montage bzw. Im Fehlerfall folgende Codes:

== Statuscodes ==

*'''A1''' Batterien neu eingelegt, Antrieb fährt Stellstift zurück
*'''A2''' Batterien neu eingelegt, Stellstift ist komplett eingefahren, fertig zur Montage
*'''A3''' Taste wurde nach Montage kurz gedrückt, Stellstift fährt aus und schließt Ventil
Wenn Vorgang abgeschlossen zeigt der Antrieb 0%, solange bis das Ventil im Betrieb geöffnet werden soll.

== Fehlercodes ==

*'''F1'''Ventilantrieb kann Stift nicht bewegen. Ventil zu schwergängig oder blockiert
*'''F2'''Ventilantrieb nicht montiert oder Stellbereich zu gross. Ursache ist fast immer, dass die Taste im Zustand '''A2''' gedrückt wurde, obwohl der Antrieb noch nicht montiert war. Batterie kurz entnehmen, warten bis Display erlischt, neu einlegen, Antrieb nach '''A2''' zuerst montieren, dann Taste drücken.
*'''F3'''Stellbereich zu klein. Ursache ist oft ein klemmendes Ventil, versuchen Ventil gangbar zu machen.
*'''F4+Batterisymbol''' Batterien sind leer, nicht mehr genug Spannung um Antrieb zu bewegen. Batteriespannung liegt dann meist um die 2 Volt.
*'''F5'''Anlernen gesperrt. Tritt z.b. auf, wenn versucht wird das Ventil mit beiden oben beschrieben MEthoden zu betreiben also peering mit HM-CC-TC und zugleich pairing mit FHEM.
*'''Antennensymbol blinkt''' Keine Funkverbindung. Gerät ist noch nicht gepeert oder gepairt oder das gepeerte oder gepairte Device kann nicht empfangen werden. (Batterie im HM-CC-TC leer oder Funkstörung)
*'''Battriesymbol'''Batterien sind fast leer.

= bekannte Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in FHEM (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

----

; Quellen:
* {{Link2Forum|Topic=60296|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=22419|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=30738|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=54911|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=41588|LinkText=FHEM-Forum-Thema}}

= Links =
* Anleitung bei EQ-3: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

----
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HM-CC-VD Funk-Stellantrieb

2022-01-04T16:18:26Z

Soulman: typo

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]], mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen [[HM-CC-TC Funk-Wandthermostat]] [[Peering (HomeMatic)|gepeert]], dieser wird dann mit FHEM (z.b. einer [[Virtueller Controller VCCU |VCCU]]) gepairt. Dadurch ist der HM-CC-TC für die Ansteuerung der Ventiltriebe zuständig.

Alternativ können auch Stellantriebe und Tür-/Fensterkontakte sowie der HM-CC-TC mit FHEM (z.b. einem VCCU oder direkt mit einem IO wie dem CUL) gepairen werden, also z.b. <pre>
set CUL hmPairForSec 300
</pre>und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden). Dann Stellantriebe und Tür-/Fensterkontakte mit den Channels des HM-CC-TC peeren (siehe [http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan].

Eine etwas detailliertere Diskussion der beiden Optionen findet sich im Artikel zum Nachfolgemodell [[HM-TC-IT-WM-W-EU]]

Ausserdem kann der Antrieb mit einem virtuellen HM-CC-TC betreiben werden, siehe weiter unten.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Stromversorgung / Batterien ==

=== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ===
* Bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery:low in den Readings und Events.
* Bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery:critical in den Readings und Events.
Faktisch ist ein Betrieb bis ca. 2,2 Volt möglich (also je Zelle 1,1 Volt) darunter nimmt die Zuverlässigkeit der Funkverbindung stark ab.

=== Akkubetrieb ===
Wegen der oben genannten Warngrenzen eigenen sich viele Akkus nicht sehr gut, da auch frisch geladenen NiMh-Akkus eine Zellenspannung von nur 1,2 Volt haben. Desshalb wird schnell die battery:low Warngrenze erreicht; mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt. Mit ''NiMh-Akkus mit geringer Selbstentladung'' (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,3 Volt verläuft.

= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU) 'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung.<ref>{{Link2Forum|Topic=41588|Message=339484|LinkText=FHEM-Forum-Beitrag}}</ref>
<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>

=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID

Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>

=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.

= Fehlercodes =
Im Display des Antriebs wird im Normalbetrieb der Öffnungswinkel in % angezeigt, jedoch vor der Montage bzw. Im Fehlerfall folgende Codes:

== Statuscodes ==

*'''A1''' Batterien neu eingelegt, Antrieb fährt Stellstift zurück
*'''A2''' Batterien neu eingelegt, Stellstift ist komplett eingefahren, fertig zur Montage
*'''A3''' Taste wurde nach Montage kurz gedrückt, Stellstift fährt aus und schließt Ventil
Wenn Vorgang abgeschlossen zeigt der Antrieb 0%, solange bis das Ventil im Betrieb geöffnet werden soll.

== Fehlercodes ==

*'''F1'''Ventilantrieb kann Stift nicht bewegen. Ventil zu schwergängig oder blockiert
*'''F2'''Ventilantrieb nicht montiert oder Stellbereich zu gross. Ursache ist fast immer, dass die Taste im Zustand '''A2''' gedrückt wurde, obwohl der Antrieb noch nicht montiert war. Batterie kurz entnehmen, warten bis Display erlischt, neu einlegen, Antrieb nach '''A2''' zuerst montieren, dann Taste drücken.
*'''F3'''Stellbereich zu klein. Ursache ist oft ein klemmendes Ventil, versuchen Ventil gangbar zu machen.
*'''F4+Batterisymbol''' Batterien sind leer, nicht mehr genug Spannung um Antrieb zu bewegen. Batteriespannung liegt dann meist um die 2 Volt.
*'''F5'''Anlernen gesperrt. Tritt z.b. auf, wenn versucht wird das Ventil mit beiden oben beschrieben MEthoden zu betreiben also peering mit HM-CC-TC und zugleich pairing mit FHEM.
*'''Antennensymbol blinkt''' Keine Funkverbindung. Gerät ist noch nicht gepeert oder gepairt oder das gepeerte oder gepairte Device kann nicht empfangen werden. (Batterie im HM-CC-TC leer oder Funkstörung)
*'''Battriesymbol'''Batterien sind fast leer.

= bekannte Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in FHEM (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

----

; Quellen:
* {{Link2Forum|Topic=60296|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=22419|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=30738|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=54911|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=41588|LinkText=FHEM-Forum-Thema}}

= Links =
* Anleitung bei EQ-3: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

----
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HM-CC-VD Funk-Stellantrieb

2022-01-04T16:17:26Z

Soulman: Ergänzung Fehlercodes

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]], mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen [[HM-CC-TC Funk-Wandthermostat]] [[Peering (HomeMatic)|gepeert]], dieser wird dann mit FHEM (z.b. einer [[Virtueller Controller VCCU |VCCU]] gepairt. Dadurch ist der HM-CC-TC für die Ansteuerung der Ventiltriebe da.

Alternativ können auch Stellantriebe und Tür-/Fensterkontakte sowie der HM-CC-TC mit FHEM (z.b. einem VCCU oder direkt mit einem IO wie dem CUL) gepairen werden, also z.b. <pre>
set CUL hmPairForSec 300
</pre>und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden). Dann Stellantriebe und Tür-/Fensterkontakte mit den Channels des HM-CC-TC peeren (siehe [http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan].

Eine etwas detailliertere Diskussion der beiden Optionen findet sich im Artikel zum Nachfolgemodell [[HM-TC-IT-WM-W-EU]]

Ausserdem kann der Antrieb mit einem virtuellen HM-CC-TC betreiben werden, siehe weiter unten.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Stromversorgung / Batterien ==

=== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ===
* Bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery:low in den Readings und Events.
* Bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery:critical in den Readings und Events.
Faktisch ist ein Betrieb bis ca. 2,2 Volt möglich (also je Zelle 1,1 Volt) darunter nimmt die Zuverlässigkeit der Funkverbindung stark ab.

=== Akkubetrieb ===
Wegen der oben genannten Warngrenzen eigenen sich viele Akkus nicht sehr gut, da auch frisch geladenen NiMh-Akkus eine Zellenspannung von nur 1,2 Volt haben. Desshalb wird schnell die battery:low Warngrenze erreicht; mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt. Mit ''NiMh-Akkus mit geringer Selbstentladung'' (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,3 Volt verläuft.

= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU) 'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung.<ref>{{Link2Forum|Topic=41588|Message=339484|LinkText=FHEM-Forum-Beitrag}}</ref>
<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>

=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID

Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>

=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.

= Fehlercodes =
Im Display des Antriebs wird im Normalbetrieb der Öffnungswinkel in % angezeigt, jedoch vor der Montage bzw. Im Fehlerfall folgende Codes:

== Statuscodes ==

*'''A1''' Batterien neu eingelegt, Antrieb fährt Stellstift zurück
*'''A2''' Batterien neu eingelegt, Stellstift ist komplett eingefahren, fertig zur Montage
*'''A3''' Taste wurde nach Montage kurz gedrückt, Stellstift fährt aus und schließt Ventil
Wenn Vorgang abgeschlossen zeigt der Antrieb 0%, solange bis das Ventil im Betrieb geöffnet werden soll.

== Fehlercodes ==

*'''F1'''Ventilantrieb kann Stift nicht bewegen. Ventil zu schwergängig oder blockiert
*'''F2'''Ventilantrieb nicht montiert oder Stellbereich zu gross. Ursache ist fast immer, dass die Taste im Zustand '''A2''' gedrückt wurde, obwohl der Antrieb noch nicht montiert war. Batterie kurz entnehmen, warten bis Display erlischt, neu einlegen, Antrieb nach '''A2''' zuerst montieren, dann Taste drücken.
*'''F3'''Stellbereich zu klein. Ursache ist oft ein klemmendes Ventil, versuchen Ventil gangbar zu machen.
*'''F4+Batterisymbol''' Batterien sind leer, nicht mehr genug Spannung um Antrieb zu bewegen. Batteriespannung liegt dann meist um die 2 Volt.
*'''F5'''Anlernen gesperrt. Tritt z.b. auf, wenn versucht wird das Ventil mit beiden oben beschrieben MEthoden zu betreiben also peering mit HM-CC-TC und zugleich pairing mit FHEM.
*'''Antennensymbol blinkt''' Keine Funkverbindung. Gerät ist noch nicht gepeert oder gepairt oder das gepeerte oder gepairte Device kann nicht empfangen werden. (Batterie im HM-CC-TC leer oder Funkstörung)
*'''Battriesymbol'''Batterien sind fast leer.

= bekannte Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in FHEM (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

----

; Quellen:
* {{Link2Forum|Topic=60296|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=22419|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=30738|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=54911|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=41588|LinkText=FHEM-Forum-Thema}}

= Links =
* Anleitung bei EQ-3: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

----
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HM-CC-VD Funk-Stellantrieb

2022-01-04T15:38:42Z

Soulman: /* Betrieb mit FHEM */ Ergänzung

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]], mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen HM-CC-TC [[Peering (HomeMatic)|gepeert]], dieser wird dann mit FHEM (z.b. einer [[VCCu]] gepairt. Dadurch ist der TC für die Ansteuerung der Ventiltriebe da.
Alternativ können auch Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit FHEM (z.b. einer VCCU) pairen (also set CUL hmPairForSec 300 und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
Die Stellantriebe und Tür-/Fensterkontakte mit den Channels (siehe unten) peeren (siehe [http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]).
Eine etwas detailliertere Diskussion der beiden Optionen findet sich im Artikel zum [[HM-TC-IT-WM-W-EU]]

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Stromversorgung / Batterien ==

=== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ===
* Bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery:low in den Readings und Events.
* Bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery:critical in den Readings und Events.
Faktisch ist ein Betrieb bis ca. 2,2 Volt möglich (also je Zelle 1,1 Volt) darunter nimmt die Zuverlässigkeit der Funkverbindung stark ab.

=== Akkubetrieb ===
Wegen der oben genannten Warngrenzen eigenen sich viele Akkus nicht sehr gut, da auch frisch geladenen NiMh-Akkus eine Zellenspannung von nur 1,2 Volt haben. Desshalb wird schnell die battery:low Warngrenze erreicht; mitunter unmittelbar nach dem Einsetzen mit der Kalibierungsfahrt. Mit ''NiMh-Akkus mit geringer Selbstentladung'' (z.b. Panasonic Eneloop) ist ein Betrieb jedoch sinnvoll möglich, da der Spannungsabfall bei den sehr geringen Entladeströmen im Stellantrieb relativ lange oberhalb 1,3 Volt verläuft.

= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU) 'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung.<ref>{{Link2Forum|Topic=41588|Message=339484|LinkText=FHEM-Forum-Beitrag}}</ref>
<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>

=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID

Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>

=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.

= bekannte Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in FHEM (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

----

; Quellen:
* {{Link2Forum|Topic=60296|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=22419|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=30738|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=54911|LinkText=FHEM-Forum-Thema}}
* {{Link2Forum|Topic=41588|LinkText=FHEM-Forum-Thema}}

= Links =
* Anleitung bei EQ-3: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

----
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

RSL 2-Draht Einbauschalter

2021-12-06T14:29:37Z

Soulman: /* Bekannte Probleme */

Conrad Funk-Einbauschalter 2-Draht RSL (Intertechno kompatibel), zum Einbau in Montagedosen / Unterputzdosen auch ohne Neutralleiter und unter Verwendung des normalen Schalters. (Beschreibung gilt grösstenteils auch für das sehr ähnliche Intertechno ITL-230 Funk Schaltermodul)
== Eigenschaften ==
Der wesentliche Vorteil des Conrad Funk-Einbauschalter 2-Draht ist, dass er lediglich den Aussenleiter ("Phase") benötigt, um betrieben zu werden. In vielen Installationen befindet sich in der Unterputzwanddose für den Lichtschalter kein Neutrallleiter ("Nullleiter"), sodass die üblichen FS20 oder HomeMatic Unterputzschalter nicht verwendet werden können. In der klassischen Elektroinstallation wird in der Wandose nur der Aussenleiter geschaltet und der Rückleiter auf anderem Wege zur Lichtfassung geführt. Der Conrad Funk-Einbauschalter 2-Draht benötigt tatsächlich nur den ankommenden und abgehenden (geschalteten) Aussenleiter. Er bezieht seine Stromversorgung vermutlich aus den Potentialunterschieden der beiden Aussenleiterstränge auch im ausgeschalteten Zustand, hierbei wird wahrscheinlich das Neutralleiterpotential durch den zu schaltenden Verbraucher genutzt.

Der RSL Schalter bezieht seinen Betriebsstrom also vom Aussenleiter in der Dose vor dem Schalter und dem geringen Strom, der "rückwärts" durch eine Ohmsche Last (z.b. klassische Glühbirne oder Halogenlampe) geführt werden kann, den im ausgeschaltet zustand ist die Glühbirne technisch nur ein Widerstand in der Neutralleitung.

Vermutlich aus diesem Grunde kann der Schalter nicht verwendet werden, wenn der zu schaltende Verbraucher eine Leuchtstoffröhre, oder - je nach Typ und Vorschaltgerät - Energiespar- oder LED-Lampe ist, da diese im Stromlosenzustand zu hochohmig sind. Als Resultat bekommt der RSL nicht genug Betriebsspannung. Da der RSL Schalter im stromlosen Zustand durchlässig ist (also EINschaltet), können diese Leuchtmittel aus nicht ausgeschaltet werden: Beim Abschalten verliert der RSL Schalter seine Versorgungsspannung, als Resultat wird wieder eingeschaltet, der RSL bekommt wieder Versorgungsspannung und versucht jetzt wieder auszuschalten etc. Also Resultat gehen LEDs am RSL Schalter mit einer Frequenz von ca 10 hz an und aus, wenn der Befehl zum abschalten kommt.

Der Conrad Funk-Einbauschalter 2-Draht benötigt keinen Taster zur Vor-Ort-Betätigung, sondern die zwei herausgeführten Schaltdrähte können mittels des vorher verbauten Schalters aus einem normalen Schalterprogramm betrieben werden. Der Schalter wird hierbei wie ein Toggle verwendet. D.h., egal welche Stellung der Schalter hat, der Conrad Funk-Einbauschalter 2-Draht kann vollständig per Funk geschaltet werden, der lokale mechanische Schalter ändert bei jeder Betätigung den Schaltzustand.

Vorteile des Conrad Funk-Einbauschalter 2-Draht gegenüber FS20 und HM Unterputzschaltern wie [[FS20 SU Unterputz-Funk-Schalter]]:

* benötigt nur Aussenleiter zur Stromversorgung
* dünner als FS20 Unterputzschalter, daher leichter auch hinter dem normalen Lichtschalter einbaubar
* benötigt keinen Taster, sondern kann mit (vorhandenem) Schalter betrieben werden
* RSL Funk, also kompatibel mit Intertechno 433 Mhz

Nachteile:
* benötigt Grundlast
* Schaltleistung gering (sieh weiter unten)

== Hinweise zum Betrieb mit FHEM ==
Der Conrad Funk-Einbauschalter 2-Draht hat keine Kodierschalter, sondern muss angelernt werden. Da dazu der gewünschte Intertechnokanal drei Sekunden lang senden muss, ist ein Anlernen mit FHEM nicht möglich, da FHEM ununterbrochenes Senden nicht beherrscht. Der Schalter kann aber leicht mit einer gängigen Intertechno Fernbedienung wie z.b. einer YCT-100 angelernt werden. (Es muss eine IT Fernbedienung sein, bei der man die Adresse selber einstellen kann, das ist bei der YCT-100 der Fall. Nicht geeignet sind die Fernbedienungen, deren Code fest ist, wie z.b. die aus den IT 1500 Sets).
Dann den [[Intertechno_Code_Berechnung#originales_Intertechno_System|Code ermitteln]] und in Fhem eintragen.

Einmal angelernt ist eine Schaltung per FHEM kein Problem.

== Bekannte Probleme ==
Die Schaltleistung des Conrad Funk-Einbauschalter ist mit 300 Watt ohmscher und 100 Watt induktiver Last deutlich geringer als die anderer Produkte, für Licht aber völlig ausreichend. Wegen der nur 100 Watt induktiver Last können aber keine Halogeninstallationen mit "echten" Trafos geschaltet werden.

Nicht geeignet, wenn im zu schaltetenden Stromkreis nur Leuchtstoffröhren zu schalten sind. Offiziell geht er auch nicht mit LED oder Leuchtstoff-Energiesparlampen, praktisch können oft aber auch solche Lampen geschaltet werden, wenngleich mit gelegentlich ca 0,5 Sekunden Verzögerung und u.U leichtem Flackern. LED Strips mit den üblichen Netzteilen/Steckernetzteilen gehen nicht.

Vermutlich kann eine Funktion in diesen Fällen aber durch ein parallel zum Verbraucher geschaltetes "Grundlastmodul" wie dem ELTAKO Grundlastelement GLE/PTC(letztlich nur ein geeignet dimensionierter PTC-Widerstand) erreicht werden.

Falls im zu schaltenden Stromkreis mehrere Lampen parallel verdrahtet sind (übliche Schaltung), reicht es, wenn eine davon zu den unterstützten Typen gehört, die Restlichen können dann auch Leuchtstoffröhren etc. sein. So ist es z.b. möglich eine Reihe von LED Spots die sich nicht schalten lassen, doch schaltbar zu machen, indem man '''einen''' LED-Spot gegen einen Halogen-Spot austauscht.

Bei schlechter Funklage hilft ggf. das Drehen des Schalters in der Wanddose um 90 Grad.

Bei Tasterschaltungen wird der tatsächliche State nie in FHEM erfasst, da
a) der Schalter immer wieder auf OFF gesetzt wird
b) in der Regel mehrere Taster im Flur vorhanden sind, deren Betätigung FHEM nicht mitbekommt. Ebenso wir eine lokale Bedienung am lokalen Schalter nicht erfasst.

== Sonstiges==
Von InterTechno gibt es mit dem ITL-230 Funk Schaltermodul ein sehr ähnliches Produkt, das den selben Einschränkungen unterliegt.

== Links ==

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

RSL 2-Draht Einbauschalter

2021-12-06T14:26:30Z

Soulman: /* Eigenschaften */

Conrad Funk-Einbauschalter 2-Draht RSL (Intertechno kompatibel), zum Einbau in Montagedosen / Unterputzdosen auch ohne Neutralleiter und unter Verwendung des normalen Schalters. (Beschreibung gilt grösstenteils auch für das sehr ähnliche Intertechno ITL-230 Funk Schaltermodul)
== Eigenschaften ==
Der wesentliche Vorteil des Conrad Funk-Einbauschalter 2-Draht ist, dass er lediglich den Aussenleiter ("Phase") benötigt, um betrieben zu werden. In vielen Installationen befindet sich in der Unterputzwanddose für den Lichtschalter kein Neutrallleiter ("Nullleiter"), sodass die üblichen FS20 oder HomeMatic Unterputzschalter nicht verwendet werden können. In der klassischen Elektroinstallation wird in der Wandose nur der Aussenleiter geschaltet und der Rückleiter auf anderem Wege zur Lichtfassung geführt. Der Conrad Funk-Einbauschalter 2-Draht benötigt tatsächlich nur den ankommenden und abgehenden (geschalteten) Aussenleiter. Er bezieht seine Stromversorgung vermutlich aus den Potentialunterschieden der beiden Aussenleiterstränge auch im ausgeschalteten Zustand, hierbei wird wahrscheinlich das Neutralleiterpotential durch den zu schaltenden Verbraucher genutzt.

Der RSL Schalter bezieht seinen Betriebsstrom also vom Aussenleiter in der Dose vor dem Schalter und dem geringen Strom, der "rückwärts" durch eine Ohmsche Last (z.b. klassische Glühbirne oder Halogenlampe) geführt werden kann, den im ausgeschaltet zustand ist die Glühbirne technisch nur ein Widerstand in der Neutralleitung.

Vermutlich aus diesem Grunde kann der Schalter nicht verwendet werden, wenn der zu schaltende Verbraucher eine Leuchtstoffröhre, oder - je nach Typ und Vorschaltgerät - Energiespar- oder LED-Lampe ist, da diese im Stromlosenzustand zu hochohmig sind. Als Resultat bekommt der RSL nicht genug Betriebsspannung. Da der RSL Schalter im stromlosen Zustand durchlässig ist (also EINschaltet), können diese Leuchtmittel aus nicht ausgeschaltet werden: Beim Abschalten verliert der RSL Schalter seine Versorgungsspannung, als Resultat wird wieder eingeschaltet, der RSL bekommt wieder Versorgungsspannung und versucht jetzt wieder auszuschalten etc. Also Resultat gehen LEDs am RSL Schalter mit einer Frequenz von ca 10 hz an und aus, wenn der Befehl zum abschalten kommt.

Der Conrad Funk-Einbauschalter 2-Draht benötigt keinen Taster zur Vor-Ort-Betätigung, sondern die zwei herausgeführten Schaltdrähte können mittels des vorher verbauten Schalters aus einem normalen Schalterprogramm betrieben werden. Der Schalter wird hierbei wie ein Toggle verwendet. D.h., egal welche Stellung der Schalter hat, der Conrad Funk-Einbauschalter 2-Draht kann vollständig per Funk geschaltet werden, der lokale mechanische Schalter ändert bei jeder Betätigung den Schaltzustand.

Vorteile des Conrad Funk-Einbauschalter 2-Draht gegenüber FS20 und HM Unterputzschaltern wie [[FS20 SU Unterputz-Funk-Schalter]]:

* benötigt nur Aussenleiter zur Stromversorgung
* dünner als FS20 Unterputzschalter, daher leichter auch hinter dem normalen Lichtschalter einbaubar
* benötigt keinen Taster, sondern kann mit (vorhandenem) Schalter betrieben werden
* RSL Funk, also kompatibel mit Intertechno 433 Mhz

Nachteile:
* benötigt Grundlast
* Schaltleistung gering (sieh weiter unten)

== Hinweise zum Betrieb mit FHEM ==
Der Conrad Funk-Einbauschalter 2-Draht hat keine Kodierschalter, sondern muss angelernt werden. Da dazu der gewünschte Intertechnokanal drei Sekunden lang senden muss, ist ein Anlernen mit FHEM nicht möglich, da FHEM ununterbrochenes Senden nicht beherrscht. Der Schalter kann aber leicht mit einer gängigen Intertechno Fernbedienung wie z.b. einer YCT-100 angelernt werden. (Es muss eine IT Fernbedienung sein, bei der man die Adresse selber einstellen kann, das ist bei der YCT-100 der Fall. Nicht geeignet sind die Fernbedienungen, deren Code fest ist, wie z.b. die aus den IT 1500 Sets).
Dann den [[Intertechno_Code_Berechnung#originales_Intertechno_System|Code ermitteln]] und in Fhem eintragen.

Einmal angelernt ist eine Schaltung per FHEM kein Problem.

== Bekannte Probleme ==
Die Schaltleistung des Conrad Funk-Einbauschalter ist mit 300 Watt ohmscher und 100 Watt induktiver Last deutlich geringer als die anderer Produkte, für Licht aber völlig ausreichend. Wegen der nur 100 Watt induktiver Last können aber keine Halogeninstallationen mit "echten" Trafos geschaltet werden.

Nicht geeignet, wenn im zu schaltetenden Stromkreis nur Leuchtstoffröhren zu schalten sind. Offiziell geht er auch nicht mit LED oder Leuchtstoff-Energiesparlampen, praktisch können oft aber auch solche Lampen geschaltet werden, wenngleich mit gelegentlich ca 0,5 Sekunden Verzögerung und u.U leichtem Flackern. Vermutlich kann eine Funktion aber durch ein parallel zum Verbraucher geschaltetes "Grundlastmodul" (letztlich nur ein geeignet dimensionierter Widerstand) erreicht werden.

LED Strips mit den üblichen Netzteilen/Steckernetzteilen gehen nicht.

Falls im zu schaltenden Stromkreis mehrere Lampen parallel verdrahtet sind (übliche Schaltung), reicht es, wenn eine davon zu den unterstützten Typen gehört, die Restlichen können dann auch Leuchtstoffröhren etc. sein. So ist es z.b. möglich eine Reihe von LED Spots die sich nicht schalten lassen, doch schaltbar zu machen, indem man '''einen''' LED-Spot gegen einen Halogen-Spot austauscht.

Bei schlechter Funklage hilft ggf. das Drehen des Schalters in der Wanddose um 90 Grad.

Bei Tasterschaltungen wird der tatsächliche State nie in FHEM erfasst, da
a) der Schalter immer wieder auf OFF gesetzt wird
b) in der Regel mehrere Taster im Flur vorhanden sind, deren Betätigung FHEM nicht mitbekommt. Ebenso wir eine lokale Bedienung am lokalen Schalter nicht erfasst.

== Sonstiges==
Von InterTechno gibt es mit dem ITL-230 Funk Schaltermodul ein sehr ähnliches Produkt, das den selben Einschränkungen unterliegt.

== Links ==

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