Alarmanlage: Unterschied zwischen den Versionen

Version vom 31. Dezember 2017, 14:12 Uhr

Mit FS20 und/oder HM Komponenten lassen sich auch Alarmanlagen realisieren. Im Folgenden soll eine einfache Alarmanlage beschrieben werden. Die Beschreibung ist an manchen Stellen noch unvollständig und außerdem an konkrete Begebenheiten angepasst. Sie soll daher nur als Anregung dienen, ferner werden einige typische Probleme diskutiert.

Alternativ kann eine Alarmanlage auch über das Modul_Alarmanlage realisiert werden, das einem einiges an Arbeit abnimmt.

Anforderung

Die Alarmanlage soll mittels Taster im Innenraum und Fernbedienungen scharf und unscharf gestellt werden können. Die Scharfschaltung soll verzögert erfolgen. Der Zustand der Anlage soll auf dem Webinterface aber auch auf einer im Haus zu montierenden Anzeige sichtbar sein. Die Auslösung soll beim Verletzen der Aussenhaut und bei Bewegung im Innenraum erfolgen. Es soll im Moment der Auslösung grob angezeigt werden, in welchem Bereich ausgelöst wurde.

Vorausetzung

Voraussetzung sind Sensoren. Vielfach sind aber Bewegungsmelder und Türkontakte vorhanden, unter Umständen muss nur wenig ergänzt werden. Im konkreten Fall waren auch schon mehrere FS20 PIRA Infrarot-Bewegungsmelder installiert.

Design / Anzeige / Schaltlogik

Der Zustand der Anlage muss angezeigt werden. Dies kann zum Teil über einen Raum "Alarmanlage" geschehen, den man per WebGUI ansehen kann, denkbar ist aber auch eine Hardwareanzeige. Im konkreten Fall wurde ein FS20 SM8 8-Kanal-Schaltmodul realisiert. Dessen Ausgänge können direkt bis zu 12 Volt 1 Ampere schalten, was für Leuchtdioden und sogar 12 Volt Sirenen ausreicht. Wichtig ist vor allem, dass von außen zu sehen ist, dass die Anlage scharf ist. Hierzu kann im Bereich der Eingangstür eine Leuchtdiode angebracht werden, die durch einen Kanal des FS20SM8 angesteuert wird. Es empfiehlt sich eine blinkende LED zu verwenden, da Blinken über einen grösseren Zeitraum mit FHEM/FS20 kaum realisierbar ist.

Zunächst muss die Anlage ein und auschaltbar sein, oder besser: scharf und unscharf. Ferner soll zwischen "scharf" und nur "scharf intern" unterschieden werden. Scharf intern soll dabei nur die Aussenhautsensoren überwachen (Türen, Fenster) nicht jedoch Innenraumsensoren (Bewegungsmelder, Taster)

Scharf intern wird also eingeschaltet, wenn sich Bewohner im Gebäude aufhalten eine Grundsicherung aber dennoch erfolgen soll, typischerweise also nachts. Ebenso ist die interne Scharfschaltung sinnvoll, wenn z.B. Hunde alleine im Haus zurückbleiben, die sonst eventuell die Bewegungsmelder auslösen würden.

Das Einschalten soll zwar per Fernbedienung passieren, zusätzlich aber über im Haus verdeckt angebrachte Taster. Die im Haus angebrachten Taster ermöglichen Scharf- und auch Unscharfschalten ohne Eingabe weiterer Berechtigungen, d.h. es ist derzeit kein Codeschloss oder dergleichen realisiert. Die Sicherheit ergibt sich auschliesslich dadurch, dass die Taster getarnt und als solche nicht erkennbar sind. Hierzu wurden nicht als Taster erkennbare Mechanismen mit einem FS20 S4M verbunden, das als Sender dient.

Um Fehlbedienungen zu erschweren sind Wartezeiten eingebaut: Nach der letzten Unscharfschaltung müssen 11 Sekunden vergehen, bis wieder scharf geschaltet werden kann.

Die Scharfschaltung muss außerdem verzögert erfolgen, damit man bereits im Inneren des Hauses scharf schalten kann aber noch genug Zeit hat das Haus zu verlassen. Hier ist eine Minute ausreichend.

Um diese diversen Zustände zu steuern, werden mehre Variablen (dummys) und FS20 Aktoren eingerichtet, nämlich:

ANLAGE_STATUS
ALARM_STATUS
ANLAGE_SCHARF
ALARM_AKTOR

Zur Anzeige außerdem:

Scharfanzeige1
Scharfanzeige2

Im Einzelnen:

ANLAGE_STATUS

Ein reiner Dummy, der folgende Werte annehmen kann

aus (Anlage initialisiert, ohne weitere Funktion)
60sec (Anlage wurde scharf geschaltet, ein Minute Wartezeit bis Aktivierung)
scharf (Anlage ist scharf)
scharf_intern (Anlage ist intern scharf, es werden nurAussenhautsensoren überwacht)
warten (Anlage wurde unscharf geschaltet, kann aber die nächsten 11 Sekunden noch nicht erneut scharf geschaltet werden.
unscharf (Anlage ist unscharf)

ALARM_STATUS

Ein reiner Dummy, der folgende Werte annehmen kann

aus (Anlage initialisiert, ohne weitere Funktion)
bereit (Anlage scharf, keine Alarmauslösung)
ALARM (Anlage scharf, Alarmauslösung)
unscharf (Anlage unscharf)
IRausgeloest (Anlage ist scharf, Alarmauslösung durch Bewegungsmelder, letzte Bewegung vor mindestens 3 Minuten)

Es ist möglich die Satus ANLAGEN_STATUS und ALARM_STATUS in einer Variabel zusammen zu fassen, was die Sache aber unübersichtlich macht.

ANLAGE_SCHARF

Ein FS20 Schalter, der dazu da ist, die Alarmanlage mit den Tastern im Haus, einer Fernbedienung oder ggf. über die Webseite zu schalten. ON soll die Anlage scharf schalten, OFF unscharf. Ferner kann überlegt werden, auch versehentlich zu lange Tastendrücke (dimup und dimdown) abzufangen und zum Schalten zuzulassen.

ANLAGE_SCHARF_intern

Ein FS20 Schalter, der dazu da ist, die Alarmanlage mit den Tastern im Haus, einer Fernbedienung oder ggf. über die Webseite zu schalten. ON soll die Anlage scharf_intern schalten, OFF unscharf. Ferner kann überlegt werden, auch versehentlich zu lange Tastendrücke (dimup und dimdown) abzufangen und zum Schalten zuzulassen.

ALARM_AKTOR

Ein FS20 Aktor, der dazu dient die Sirenensteuerung zu triggern. Die Signalisierung bei Alarm ist 2-stufig aufgebaut. ALARM_STATUS löst im Inneren des Hauses direkt eine Alarmanzeige (LED und/oder interne Sirene aus). Äussere Signaleinrichtungen unterliegen aber gesetzlichen Regelungen was die Länge der Alarmierung betrifft und werden daher durch eine eigene Logik bzw. einen eigene Aktor betrieben: ALARM_AKTOR

Zur Anzeige ausserdem:

Scharfanzeige1

Scharfanzeige2

FS20 Aktoren, die mittels LED den Zustand der Anlage zeigen:

Scharfanzeige1 leuchtet, wenn die Anlage scharf geschaltet wurde (nur intern oder komplett) und auch, wenn die Anlage zwar scharf geschaltet wurde, aber die eine Minute Wartezeit noch nicht um ist. Sie dient als sofortiges Feedback, dass die Einschaltung erfolgreich war. Wird die Anlage unscharf geschaltet, leuchtet Scharfanzeige1 noch so lange wie die Anlage im Status „warten“ ist, also nicht erneut scharf geschaltet werden kann.
Scharfanzeige2 hingegen leuchtet nur, wenn der Anlagenstatus „scharf“ ist (nur intern oder komplett), also 1 Minute nach dem Einschalten. Hier kann z.b. eine zweite LED im Aussenbereich angebracht werden, die von außen sichtbar anzeigt, dass die Anlage scharf ist. Scharfanzeige2 geht sofort aus, wenn die Anlage unscharf geschaltet wird, sodass von außen kontrollierbar ist, ob die Anlage erfolgreich unscharf gestellt wurde.

Mit zwei LEDs (oder ähnlichen Aktoren) können also Zustände der Anlage (ausser dem eigentlichen Alarm) angezeigt werden:

Nach einschalten:

Scharfanzeige1	 Scharfanzeige2	 	Status der Anlage
aus	 		aus			unscharf			
an	 		aus			eingeschaltet, 1 Minute Wartezeit
an	 		an			scharf

Durch weitere Anzeigen ließe sich zwischen scharf und scharf_intern unterscheiden. Speziell von aussen betrachtet bringt dies aber wenig Erkenntnisgewinn, da ein versehentliches Öffnen der Tür in beiden Fällen Alarm auslösen würde.

Nach ausschalten:

Scharfanzeige1	 Scharfanzeige2	 		Status der Anlage
an	 		aus			unscharf, noch warten			
aus	 		aus			unscharf, einschaltbar

Praktische Probleme

Grenzen

Die Alarmanlage ist insgesamt nur so sicher wie die verwendeten Komponenten. Die hier eingesetzten FS20 Sensoren und Sender sind funktechnisch nicht sicher und könnten von Dritten, die über geeignete Kenntnisse, Geräte und Zeit verfügen, analysiert und dann bedient werden. Sie dient nur der Grundsicherung gegen "durchschnittlich begabte" Einbrecher. Sie ist besser als nichts, weil man wohl davon ausgehen kann, dass normale Einbrecher nicht über das notwendige Wissen verfügen, überdies würde der zeitliche Aufwand das Objekt eventuell weniger lohnend erscheinen lassen. Es ist aber definitiv möglich, die Anlage mit einer FHEM Installation auf einem Laptop inklusive z.B. einem CUL abzuschalten, wenn die nötige Kenntnisse vorliegen. Mit HomeMatic Komponenten kann höhere Sicherheit erreicht werden, insbesondere wenn der AES Signing Request mit eigenem Schlüssel verwendet wird.

Neben der informationstechnischen Unsicherheit muss auch immer berücksichtigt werden, dass lizenzfreie Funkübertragung überwiegend in einigen wenigen Frequenzbereichen (433MHz, 868MHz, 2.4GHz) realisiert wird. Für alle diese Bereiche gibt es in zwischen Störsender. Diese werden z.B. von Autodieben verwendet um die GPS-Überwachung per Mobilfunk außer Betrieb zu setzen. Der Betrieb solcher Störsender ist wesentlich einfacher als die Analyse der IT-Komponenten. Jemand der sich durch einen Einbruch strafbar macht, hat keinerlei Grund sich an Fernmeldegesetze zu halten. Sogar die Datenübertragung über das eigene Stromnetz (HomePlug) lässt sich relativ einfach stören. Viele Häuser haben Außensteckdosen, Lampen diverse Gartenautomatisierung etc. die gut geeignet sind um Störungen ein zu koppeln. Selbst ohne direkten Zugang zu einer Stromleitung kann eine geeignet breitbandige Störung induktiv eingekoppelt werden.

Nun könnte man den Betrieb eines Störsenders oder Manipulationen an Komponenten am Verbindungsverlust oder Statusänderungen merken. Doch was dann tun? Einfach mal auf Verdacht den Alarm auslösen auch wenn es dann doch nur eine gewöhnliche Störung war? Jeder einzelne Fehlalarm konditioniert die Nachbarn zum nichts tun.

Wenn alles tut und die Heimautomatisierung einen Einbruch erkennt, bleibt immer noch die Frage was zu tun ist. Die Aufmerksamkeit der Nachbarn erregen? Einen SMS, e-Mail oder ähnliches absetzen? Wer hat nicht schon mal irgendwo eine Alarmsirene gehört und auch einfach nichts getan. Die typischen Sirenen mit rotem Blinklicht werden regelmäßig mit Bauschaum und einem Deckel deaktiviert. Derlei Sirenen aus denen noch der Bauschaum quillt, sind in großen Städten immer wieder zu sehen. Diese Methode funktioniert mit einem langen Röhrchen sogar an sehr schlecht zugänglichen Stellen und aktiviert in der Regel keine Sabotagekontakte. Langer Rede kurzer Sinn: Es muss die gesamte Meldekette bis zu einer Person die etwas unternimmt manipulationssicher und sehr schnell funktionieren, sonst sind Einbrecher mit dem was sie holen wollten weg bevor irgend jemand reagiert. Auch Videoaufzeichnungen von Leuten mit Sturmhauben nutzen nichts. Die polizeiliche Aufklärungsquote beim Straftatbestand Wohnungseinbruchdiebstahl in Deutschland schwankte von 1999 bis 2016 zwischen 15 und 20% [1]. Vier von fünf Einbrüchen bleiben unaufgeklärt. Daran hat der in den letzten Jahren einsetzende Boom der Hausautomatisierung kaum etwas geändert. Im Gegenteil die Aufklärungsquote war noch nie so niedrig wie 2015.

Abstraktionlayer

Wenn die Haussteuerung vor dem „Bau“ der Alarmanlage bereits besteht und wenn verschiedene Sensortypen eingesetzt werden, so sind die Namen der Sensoren vermutlich nicht nach den Bedürfnissen der Alarmanlage strukturiert benannt. Ausserdem liefern z.b. FHT Türsensoren andere Ergebnisse als FS20 und HM Türsensoren:

FHT80TF -> Open / Closed
HM-SEC-SC -> open / closed
FS 20 TFK -> on / off

Dadurch ist eine einfache Abfrage, ob eine Tür oder ein Fenster offen ist nicht möglich, vielmehr müssten alle Kontakte einzeln per notify behandelt werden.

Ausserdem:

Die FHT80TF senden ihren Status alle ca 2 Minuten. Ohne eine zusätzliche Logik würden simple notifys daher alle 2 Minuten ausgelöst.
PIRA/PIRIs sind meist so konfiguriert, dass sie zwar bei Bewegung ein Event senden (etwa um Licht einzuschalten) aber kein Event, wenn keine Bewegung (für eine bestimmte Zeit) erkannt wurde. Dies muss berücksichtigt werden.

Um nicht nachträglich alle Sensoren umbennen zu müssen und um die Zustände zu vereinheitlichen, wurde eine Abstraktionschicht eingeführt. Dazu werden alle Sensoren einer Meldegruppe bzw Funktionsgruppe als Dummy mit strukturierten Namen neu angelegt und deren Zustand über notifys der eigentlichen Sensoren ausgelöst.

Durch die Alarmanlage werden nur Events der Dummies abgefragt.

Dieses Vorgehen hat folgende Vorteile:

Vereinheitlichung der Namen
Vereinheitlichung der Zustände.
zusätzliche Logik in den Notifies der Dummys, z.b. Rücksetzen der Bewegungsmelder, Verzögerungen
Anzeige aller Sensoren in einem Raum („Alarmanlage“) ohne weitere Strukture-Konstrukte und unabhängig vom eigentlichen Sensor.
Manipulation der Dummysensoren ohne dass ausserhalb der Alarmanlage Aktionen ausgelöst werden . (Es kann z.b. zu Testzwecken eine Bewegungsmelder auf ON gesetzt werden, ohne das die normalerweise ausgelöste Lichtschaltung erfolgt)

Funklast

Im Betrieb kann im Moment von Zustandsänderungen einiges an Funklast erzeugt werden. Die konkreten Installation wird mit zwei CULs und einem HMLAN Konfigurator betrieben. Die Zustandsanzeige der Alarmanlage ist von beiden CULs mit vernünftigem RSSI erreichbar und daher konnten die Anzeigen auf die CULs per IOdev verteilt werden, um die Funklast zu senken.

Dabei wurden die kritischen Signalisierungen (Scharfanzeige und Alarm) von den eher sekundären Anzeigen (Meldegruppen) getrennt, die aufgrund häufiger Statusänderungen oft ausgelöst werden. Die Auslösung des Alarmaktors (Sirene) wird über HM geroutet.

Kommentierter Code

(Gegenwärtig sind Definitionen und zugehörige Funktionen zusammengefasst, eleganter ist es vermutlich, alle für die Anlage notwendigen Definitionen zusammen zu fassen)

Der Code basiert auf PERL "if", nicht auf dem inzwischen verfügbaren FHEM Befehl DOIF.

Der Code ist hier unstrukturiert als "Einzeiler" ausgeführt. Dies ist allein der Vorliebe des Erstellers geschuldet und hat keinen funktionalen Hintergrund. Im Code enthalten Zeilumbrüche sind vor Übernahme in eine eigene Konfiguration zu entfernen.

Einschalten / auschalten

#-----Scharf/unscharf--------------------------------
define ANLAGE_STATUS dummy
attr ANLAGE_STATUS room Alarmanlage
define ANLAGE_SCHARF FS20 22224222 32
attr ANLAGE_SCHARF dummy 1
attr ANLAGE_SCHARF room Alarmanlage
define ANLAGE_SCHARF_intern FS20 22224222 30
attr ANLAGE_SCHARF_intern dummy 1
attr ANLAGE_SCHARF_intern room Alarmanlage
define Scharfanzeige1 FS20 22224222 01
attr Scharfanzeige1 IODev CUL1
define Scharfanzeige2 FS20 22224222 02
attr Scharfanzeige2 IODev CUL1

Über diese Dummies und Aktoren wird die Anlage gesteuert. Die Anlage wurde mit einem von der sonstigen Installation abweichendem Hauscode versehen, als Beispiel 22224222

Einschalten

define act_on_ANLAGE_SCHARF_on notify ANLAGE_SCHARF:on { if (Value("ANLAGE_STATUS") ne "scharf" &&
Value("ANLAGE_STATUS") ne "60sec" && Value("ANLAGE_STATUS") ne "warten" ) { fhem("set Scharfanzeige1 on ;; 
set ANLAGE_STATUS 60sec ;; set ALARM_STATUS bereit ;; define verzoegert_Heizung_absenken at +00:07:00 set 
Heizung_absenken on ;; define verzoegert_scharf at +00:01:00 set ANLAGE_STATUS scharf ;;;; 
set Scharfanzeige2 on") }}

Beim Betätigen des Tasters / Fernbedienung wird die Alarmanlage eingeschaltet, wenn:

der Taster ON gedrückt wurde
die Anlage nicht schon scharf ist (Vermeidung unnötiger Funklast)
die Anlage nicht innerhalb der letzten Minute scharf geschaltet wurde
die Anlage nicht innerhalb der letzten 11 Sekunden ausgeschaltet wurde.

Das Scharfschalten löst folgende Aktionen aus:

die Scharfanzeige 1 wird aktiviert
Der Status der Anlage wird auf „60sec“ gesetzt, um anzudeuten, das sie noch nicht scharf ist, aber in einer Minute
der Alarmstatus wird auf „bereit“ gesetzt
die Heizung wird in 7 Minuten auf Absenkbetrieb gesetzt, in der Annahme, dass die Alarmanlage nur dann auf scharf gestellt wird, wenn alle das Haus verlassen haben. Die Verzögerung von 7 Minuten dient vor allem dazu, die erhebliche Funklast der Heizungsabsenkung – Brenner und alle FHTs werden verstellt - zeitlich von (auch mehrfachen) Scharfschaltungen zu entkoppeln. Dies erhöht die Zuerlässigkeit der Alarmanlage.
mittels define verzoegert_scharf at +00:01:00 wird die Anlage eine Minute nach Scharfschaltung tatsächlich scharf geschaltet, gleichzeitig wird Scharfanzeige2 eingeschaltet, die eine auch im Außenbereich sichtbare Anzeige aktiviert.

Einschalten intern

define act_on_ANLAGE_SCHARF_intern_on notify ANLAGE_SCHARF_intern:on { if (Value("ANLAGE_STATUS") ne "scharf_intern" &&
Value("ANLAGE_STATUS") ne "60sec" && Value("ANLAGE_STATUS") ne "warten" ) { fhem("set Scharfanzeige1 on ;; 
set ANLAGE_STATUS 60sec ;; set ALARM_STATUS bereit ;; define verzoegert_scharf at +00:01:00 set ANLAGE_STATUS scharf_intern ;;;; set Scharfanzeige2 on") }}

Das Verhalten ist analog zur normalen Scharfschaltung. Jedoch wird die Heizung nicht abgesenkt. Die Alarmanlage kann auch ohne vorheriges Auschalten von einer Scharfschaltung in die andere überführt werden. Dies kann nützlich sein, wenn z.b. von aussen versehentlich nur intern scharf gestellt wurde. Es ist dann möglich direkt auf komplette Scharfschaltung zu erweitern.

Ausschalten

define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off { if (Value("ANLAGE_STATUS") eq "scharf_intern" || Value("ANLAGE_STATUS") eq "scharf") 
{ fhem("set ALARM_Melder off ;; 
set Scharfanzeige2 off ;; delete verzoegert_scharf ;; set ANLAGE_STATUS warten ;; 
set ALARM_STATUS unscharf  ;; define Alarmanlage_aufraeumen 
at +00:00:11 set ANLAGE_STATUS unscharf ;;;; set Scharfanzeige1 off ;; 
delete verzoegert_Heizung_absenken ;; set brenner on ;; set ANLAGE_SCHARF_intern,ANLAGE_SCHARF off") } 
else { fhem("set ALARM_Melder off ;; 
set Scharfanzeige2 off ;; delete verzoegert_scharf ;; set ANLAGE_STATUS warten ;; 
set ALARM_STATUS unscharf  ;; define Alarmanlage_aufraeumen 
at +00:00:11 set ANLAGE_STATUS unscharf ;;;; set Scharfanzeige1 off ;; 
delete verzoegert_Heizung_absenken") }}

Beim Betätigen des Tasters / Fernbedienung wird die Alarmanlage ausgeschaltet, wenn der Taster OFF gedrückt wurde. Durch ANLAGE_SCHARF.* (also das angehängte ".*") werden dabei beide Schalter ausgewertet, also sowohl ANLAGE_SCHARF als auch ANLAGE_SCHARF_intern. Beide Schalter schalten die Anlage bei OFF also aus, egal auf welche Art sie scharf geschaltet wurde.

Das Unscharfschalten löst - sofern die Alarmanlage vorher scharf war - folgende Aktionen aus:

Der ALARM_Melder (wird weiter unten definiert) wird abgeschaltet. (konkret schaltet dies die eventuell laufende Aussensirene aus)
die Scharfanzeige 2 wird deaktiviert, damit ist auch von aussen sichtbar, dass die Unscharfschaltung erfolgreich war.
„verzoegert_scharf“ wird gelöscht, sofern es existiert. Dies verhindert vor allem, das die Anlage sich unkontrolliert selber scharf schaltet, wenn die Unscharfschaltung innerhalb einer Minute nach Scharfschaltung erfolgt (Im Haus was vergessen eben nochmal rein...). Im Normalfall erzeugt dies eine Fehlermeldung, da „verzoegert_scharf“ nach finaler Scharfschaltung nicht mehr exisitert, die Fehlermeldung kann aber ignoriert werden.
Die Anlage wird auf „Warten“ gestellt . Dies soll verhindern, dass bei eventuell hektischem Manipulieren mit einer Fernbedienung die Anlage versehentlich sofort wieder scharf gestellt wird.
Der ALARM Status wird auf unscharf gesetzt (damit geht auch eine eventuell interne Sirene aus)
Die Scharfanzeige1 wird deaktiviert
Die Anlage wird per at +00:00:11 in 11 Sekunden in den finalen Zustand überführt und auf unscharf gestellt. Sie ist jetzt wieder bereit zum Einschalten. Sicherheitshalber wird außerdem die Scharfanzeige2 nochmal deaktiviert, ausserdem wird die eventuell noch vorhanden Absenkung der Heizung (letzte Scharfschaltung nur 7 Minuten oder weniger zurück) gelöscht. Im Normalfall erzeugt dies eine Fehlermeldung, da „verzoegert_Heizung_absenken“ 7 Minuten nach einer scharfschaltung nicht mehr existiert, die Fehlermeldung kann aber ignoriert werden. Zuletzt wird der Brenner eingeschaltet; hier sind weitere ähnliche „Willkommensaktionen“ denkbar, wie Licht im Hausflur einschalten oder dergleichen.
ANLAGE_SCHARF_intern und ANLAGE_SCHARF werden beide auf OFF gesetzt. Dies sorgt dafür das beide Schalter auf dem Webfrontend auf OFF stehen. Allerdings würde damit

define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off

sich selbst auslösen. Um dies zu verhindern wird mit folgendem Abschnitt vorher geprüft, ob die Anlage überhaupt scharf war:

define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off { if (Value("ANLAGE_STATUS") eq "scharf_intern" || (Value("ANLAGE_STATUS") eq "scharf")

Hier liesse sich eventuell auch mit "setstate" anstatt "set" arbeiten, da setstate nur den Status auf dem Webfrontend ändern würde.

Ist die Anlage bei Betätigen eines Ausschalters nicht scharf, werden sicherheitshalber mit

else { fhem(" ... ")

trotzdem alle Abschaltschritt ausgeführt, ausser ANLAGE_SCHARF_intern und ANLAGE_SCHARF auf OFF zu setzen (sowie den Brenner einzuschalten). Dies dient der höheren Robustheit, so können z.b. auch unklare Zustände der Anlage durch auschalten bereinigt werden. (Insbesondere der Fall, dass aus irgendwelchen Gründen die Sirenen an sind, obwohl die Anlage eigentlich aus ist.)

Scharfanzeige aktualisieren

define Scharfanzeige_update at +*00:10:00 { if (Value("ANLAGE_STATUS") eq "scharf" 
&& Value("ANLAGE_SCHARF") eq "on" ) { fhem ("set Scharfanzeige2 on ") }}
define Scharfanzeige_intern_update at +*00:30:00 { if (Value("ANLAGE_STATUS") eq "scharf_intern" 
&& Value("ANLAGE_SCHARF_intern") eq "on" ) { fhem ("set Scharfanzeige2 on ") }}

Diese Codeabschnitte dienen einzig dazu, sicherzustellen, dass die von außen sichtbare Scharfanzeige den Zustand der Alarmanlage auch korrekt anzeigt, selbst wenn die Auslösung bei der Scharfschaltung aufgrund von Funkstörungen nicht erfolgreich war. Nichts senkt die Akzeptanz einer Alarmanalge so nachhaltig wie eine Scharfschaltung z.b. per Weboberfläche (die die erfolgreiche Scharfschaltung anzeigt, auch wenn die Scharfanzeige2 nicht geschaltet werden konnte) und ein anschließend nach Hause zurückkehrendes Familienmitglied, das nicht sehen kann, dass die Anlage scharf ist und dann ohne Unscharfschaltung die Haustür aufmacht.

Da dieser Teil im Falle einer scharfen Anlage regelmäßig Funklast erzeugt, ist der Abfrageabstand hinreichend gross zu wählen. Im Beispiel ist die Abfrage für internen Alarm länger, da angenommen wird, dass bei interner Scharfschaltung alle Bewohner sowieso im Haus sind.

Beide Codeabschnitte könnten durch Verwendung von "oder" Bedingungen zusammengefasst werden was aber eventuell etwas unübersichtlich ist.

Abstraktionsschicht für Türkontakte (Fensterkontakte)

#------Tuerkontakte----Namen-und-Zustände vereinheitlichen-------
define AussentuerEG_Eingang dummy
attr AussentuerEG_Eingang room Alarmanlage
attr AussentuerEG_Eingang loglevel 6

define act_on_Eingang_TFK notify Eingang_TFK { if (Value("Eingang_TFK") eq "off") 
{ fhem("define Eingangstuer_verzoegert_zu at +00:00:04 set AussentuerEG_Eingang zu ;; set AussentuerEG_Eingang zu") } 
else { fhem("define Eingangstuer_verzoegert_offen at +00:00:04 set AussentuerEG_Eingang offen") }}
define AussentuerEG_Terrasse dummy
attr AussentuerEG_Terrasse room Alarmanlage
attr AussentuerEG_Terrasse loglevel 6
define act_on_Tuer_Wohn_u1 notify Tuer_Wohn_u { if (Value("Tuer_Wohn_u") eq "Closed") 
{ fhem("set AussentuerEG_Terrasse zu") } else { fhem("set AussentuerEG_Terrasse offen") }}
define AussentuerUG_Keller dummy
attr AussentuerUG_Keller room Alarmanlage
attr AussentuerUG_Keller loglevel 6
define act_on_Tuer_Keller_Aussen1 notify Tuer_Keller_Aussen { if (Value("Tuer_Keller_Aussen") eq "Closed") 
{ fhem("set AussentuerUG_Keller zu") } else { fhem("set AussentuerUG_Keller offen") }}
define AussentuerUG_Heizungskeller dummy
attr AussentuerUG_Heizungskeller room Alarmanlage
attr AussentuerUG_Heizungskeller loglevel 6
define act_on_Tuer_Heizungskeller1 notify Tuer_Heizungskeller { if (Value("Tuer_Heizungskeller") eq "closed") 
{ fhem("set AussentuerUG_Heizungskeller zu") } else { fhem("set AussentuerUG_Heizungskeller offen") }}

Hier wird der Abstraktionslayer für die Türsensoren angelegt. Alle Dummies heißen „AussentuerXX_Ort“ und sind daher später mittels eines Events der Art notify Aussentuer.* abfragbar. Außerdem werden die verschiedenen Status der diversen Melder auf die Zusände „offen“ und „zu“ gemappt. Durch Loglevel= 6 wird verhindert, das die Zustandsänderungen gesondert im Log erscheinen, da die Zustandsänderungen der jeweiligen Sensoren bereits im Log vermerkt sind.

Im Beispiel sind nur einige Türen aufgeführt, tatsächlich sind so alle Türen mit dem einen oder anderen Sensor einbindbar. Da die FHT80TF Sensoren (FHEM: FHTTK) nicht bei Statusänderungen senden, kann eine Alarmauslösung hier bis zu 2 Minuten verzögert erfolgen.

Hier nicht ausgeführt, aber prinzipiell analog können Fenstersensoren aufgebaut werden. Mittels handelsüblicher Glasbruchsensoren, die an die externen Kontakte eines FS20 oder HM Türkontakts angeschlossen werden, lassen sich günstig Glasbruchmelder bauen. Bei Fenstern, die nicht optisch sichtbar sind (Kellerfenster) lässt sich anstatt eines „echten“ Glasbruchsensors der Glasbruch auch durch einen getrennt auf die Scheibe geklebten Magneten und HM-SEC-SC realisieren, bei Glasbruch fallen beide Komponenten höchstwahrscheinlich getrennt zu Boden und lösen dann aus.

Die Eingangstür erfährt ausserdem eine Sonderbehandlung. Sie soll Alarm erst 4 Sekunden nach öffnen auslösen. Dies dient dazu bei z.b. vergessenem Sender das Haus dennoch betreten zu können. Und zwar hat man nach öffnen der Tür noch 4 Sekunden Zeit, die Alarmanlage mit dem innen verdeckt angebrachten Schalter unscharf zu schalten. Es liegt zunächst nahe, diese Verzögerung in die eigentliche (weiter unten beschriebene) Alarmauslösungsroutine einzubauen. Allerdings würde diese dadurch deutlich komplizierter, es wäre insbesondere nicht mehr möglich mit nur einem Ausdruck alle Türen auf einemal abzufragen.

Anstelle dessen wird hier der Abstraktionslayer über dem eigentlichen Sensor verwendet um zusätzliche Funktionalität einzubauen:

define act_on_Eingang_TFK notify Eingang_TFK { if (Value("Eingang_TFK") eq "off")
{ fhem("set AussentuerEG_Eingang zu ;; define Eingangstuer_verzoegert_zu at +00:00:04 set AussentuerEG_Eingang zu") } 
else { fhem("define Eingangstuer_verzoegert_offen at +00:00:04 set AussentuerEG_Eingang offen") }}

Hier wird einfach jeder Schaltvorgang des TFK 4 Sekunden verzögert. Wichtig ist es, dies auch beim Schliessen der Tür zu tun, da sonst bei einem (z.b. versehentlichen) schnellen Öffnen und Schliessen der Tür der Dummy "AussentuerEG_Eingang" den falschen Wert annehmen kann: Wird die Tür nämlich geöffnet, aber z.b. nach 2 Sekunden geschlossen, würde die AussentuerEG_Eingang zwar zunächst auf "zu" gesetzt, aber weitere 2 Sekunden später durch die 4 Sekunden Öffnungsverzögerung wieder auf "offen" gesetzt. Daher muss auch das Setzen von AussentuerEG_Eingang auf "zu" mit 4 Sekunden Verzögerung erneut erfolgen.

Die zunächst naheliegend erscheinende Lösung, beim Schliessen das eventuelle noch vorhandene "Eingangstuer_verzoegert_offen" zu löschen, kann nicht verwendet werden, da dann ein Einbrecher, der es schaffen würden, die Tür zu öffnen und innerhalb von 4 Sekunden wieder zu schliessen keinen Alarm auslösen würde.

Abstraktionsschicht für Bewegungsmelder

#------Bewegungsmelder----Namen-und-Zustände vereinheitlichen-------
define Bewegung_Wohnen_oben dummy
attr Bewegung_Wohnen_oben room Alarmanlage
define act_on_PIRI_WZ_o1 notify PIRI_WZ_o:on.* { fhem("set Bewegung_Wohnen_oben bewegung ;; 
define reset_Bewegung_Wohnen_oben at +00:03:00 set Bewegung_Wohnen_oben keine ") }

define Bewegung_Bad_EG dummy
attr Bewegung_Bad_EG room Alarmanlage

define act_on_zk_pumpe1 notify zk_pumpe:on.* { fhem("set Bewegung_Bad_EG bewegung ;; 
define reset_Bewegung_Bad_EG at +00:03:00 set Bewegung_Bad_EG keine ") }
define act_on_Licht1_Bad notify Licht1_Bad:on.* { fhem("set Bewegung_Bad_EG bewegung ;; 
define reset_Bewegung_Bad_EG at +00:03:00 set Bewegung_Bad_EG keine ") }

Hier wird der Abstraktionslayer für Bewegungsmelder definiert. Exemplarisch sind 2 Melder aufgehführt. Alle Dummies heissen „Bewegung_Ort1_ort1“ und sind daher mit „notify Bewegung.*“ abfragbar Alle Zustände werden auf „bewegung“ bzw „keine“ gemappt. Da Bewegungsmelder idR. Nur „on“ melden, aber nicht „off“ bei keiner Bewegung, wird hier 3 Minuten nach einer Auslösung der Zustand auf „keine“ gesetzt. Diese Zeit ist mit den eingestellten Sendezeiten des Bewegungsmelders abzustimmen.

Ein Besonderheit ist Bewegung_Bad_EG: Historisch bedingt ist hier ein Bewegungsmelder direkt mit der Zirkulationspumpe gekoppelt, bzw über den zweiten Kanal mit dem Licht im Badezimmer. Eine Besonderheit ist dabei, dass die Zirkulationspumpe nach 2 Uhr bis 6 Uhr trotz Auslösung nicht eingeschaltet wird (nachts will keiner duschen) und Licht tagsüber nicht angeht. Zur Abdeckung von Bewegungen über den gesamten Tagesverlauf müssen daher sowohl Statusänderung der Zirkulationspumpe als auch des Badezimmerlichts abgefragt werden. Als Nebeneffekt würde das Einschalten der Zirkulationspumpe über andere Methoden im Falle einer scharfen Alarmanlage einen Alarm auslösen. Tatsächlich lässt sich die Zirkulationspumpe über Schalter im Schlafzimmer und in der Küche für 15 Minuten einschalten. Faktisch spiel dies allerdings keine Rolle, da das Betätigen von Schaltern im Haus bei scharfer Alarmanlage eigentlich nur von unberechtigten Personen erfolgen kann.

Eine mögliche Erweiterung ist sogar, dass Betätigen aller Schalter (außer den Tastern zum Schalten der Alarmanlage selbst) zur Alarmauslösung zu nutzen. Das ist hier noch nicht realisiert, da bei umfangreichen Automatisonsszenarien peinlich genau geprüft werden muss, ob Schaltungen nicht automatisch durch Scripte in FHEM erfolgen, also welche Lichter z.b. bei Dämmerung von alleine eingeschaltet werden.

Meldegruppen

#------Meldegruppenueberwachung----------------------
define MeldegruppeUG FS20 22224222 11
attr MeldegruppeUG IODev CUL2
define MeldegruppeEG FS20 22224222 21
attr MeldegruppeEG IODev CUL2
define Meldegruppe3 FS20 22224222 31
attr Meldegruppe3 IODev CUL2

Hier werden verschiedene Meldegruppen definiert. Es werden diverse Melder so zusammengefasst, dass eine grobe Anzeige des Auslöseortes möglich ist. Im Beispiel werden die Türen im Keller, Türen im EG und Bewegungsmelder zusammengefasst. Die Meldegruppen lösen einen Aktor aus, der den Zustand der Meldegruppe anzeigt, hier eine LED am Ausgang des FS20 8-Kanal-Schaltmodul FS20SM8. Da die Schaltung bei Bewegung im Haus relativ häufig erfolgt, ist als IOdev das schwächer belastetes RFR CUL definiert. (im folgenden Codebeispiel finden sich auch Melder, die in den Beispielen weiter oben der Übersichtlichkeit halber weggelassen wurden)

define check_MeldegruppeUG_klar notify AussentuerUG.* { if (Value("MeldegruppeUG") eq "off" && 
Value("AussentuerUG_Keller") eq "zu" && Value("AussentuerUG_Waschkeller") eq "zu" && 
Value("AussentuerUG_Heizungskeller") eq "zu") { fhem ("set MeldegruppeUG on") }}

define check_MeldegruppeUG_unklar notify AussentuerUG.*:offen { if (Value("MeldegruppeUG") eq "on") 
{ fhem("set MeldegruppeUG off") }}

define check_MeldegruppeEG_klar notify AussentuerEG.* { if (Value("MeldegruppeEG") eq "off" && 
Value("AussentuerEG_Schlafen") eq "zu" && Value("AussentuerEG_Terrasse") eq "zu" && 
Value("AussentuerEG_Eingang") eq "zu") { fhem ("set MeldegruppeEG on") }}

define check_MeldegruppeEG_unklar notify AussentuerEG.*:offen { if (Value("MeldegruppeEG") eq "on") 
{ fhem("set MeldegruppeEG off") }}

define check_Meldegruppe3 notify Bewegung.* { if (Value("Bewegung_Wohnen_oben") eq "keine" && 
Value("Bewegung_Bad_EG") eq "keine" && Value("Bewegung_Wohnen_unten") eq "keine") 
{ fhem ("set Meldegruppe3 on") } else { fhem ("set Meldegruppe3 off") }}

Hier wird jede Meldegruppe behandelt. Zunächst wird bei jeder Veränderung einer Aussentür in der passenden Etage (durch strukturierte Namen der Dummies mit einem notify abfragbar) geprüft, ob alle Türen zu sind und ob die Meldegruppe bisher „off“ (also „unklar“) war. Wenn alle Bedingungen zutreffen wird die Meldegruppe auf „on“ (also „klar“) gesetzt.

"notify AussentuerEG.*" wird dabei durch den Einsatz der FHT80TF ca. alle 2 Minuten ausgelöst. Um zu verhindern, dass alle zwei Minuten - oder beim Einsatz mehrerer FHT80TF in einer Meldegruppe auch öfters – Funksignale zum Schalten einer LED ausgesendet werden, obwohl die LED bereits den richtigen Zustand hat, wird nach dem Zustand der Meldegruppe gefragt und nur ein „on“ gesendet, wenn die Gruppe vorher „off“ war. Dies macht das Auschalten über ein „else“ Statement aber schwierig, da die Gruppe dann auf „off“ geschaltet würde, wenn bei einem Event alle Türen zu sind, aber auch vorher schon alle zu waren und die Gruppe daher schon „on“ war.

Die Gruppe wird daher über eine seperates notify ausgeschaltet, hier wird nur gesendet, wenn irgendeine der Türen seinen Status zu offen ändert und die Gruppe vorher „on“ war.

Die Bewegungsmelder senden nur bei einem tatsächlichen Event. Es muss daher streng genommen nicht überprüft werden, welchen Zustand die Meldegruppe vorher hatte. Jede Statusmeldung ist eine tatsächliche Änderung. Allerdings führt jede Auslösung eines Bewegungsmelders zu

else { fhem ("set Meldegruppe3 off") }

Sind viele Bewegungsmelder vorhanden und/oder werden diese oft ausgelöst (Wohnzimmer), kann hierdurch eine hohe Funklast entstehen. Es kann daher sinnvoll sein, diese Meldegruppe auch mit einer Zustandsüberprüfung zu versehen und die Meldegruppe nur dann auf "unklar" zu setzen, wenn sie vorher nicht schon "unklar" (=off) war:

define check_Meldegruppe3 notify Bewegung.* { if (Value("Bewegung_Wohnen_oben") eq "keine" && 
Value("Bewegung_Bad_EG") eq "keine" && Value("Bewegung_Wohnen_unten") eq "keine") 
{ fhem ("set Meldegruppe3 on") } else { if (Value("Meldegruppe3") ne "off") 
{ fhem ("set Meldegruppe3 off") }}

Da die Meldegruppen den Zustand häufig ändern, kann überlegt werden, mit

attr .... loglevel 6

die Anzahl der Logeinträge zu reduzieren.

Alarmauslösung und Behandlung

#------Alarmauslösung-------------------------------
define ALARM_STATUS dummy
attr ALARM_STATUS room Alarmanlage
define ALARM_Melder FS20 22224222 33

Hier wird der Dummy für den eigentlichen Alarm definiert sowie ein Aktor für den Alarmmelder, also typischerweise einen Aussensirene. ALARM_Melder ist dabei noch nicht der tatsächliche Aktor. In der konkreten Anlage ist der Aktor eine HM Schalter, da beim Auslösen der Aussensirene höchste Zuverlässigkeit gefordert ist. Die bidirektionale Kommunikation von HM ist daher vorteilhaft. Dieser HM Aktor wird durch ALARM_Melder per Notify ausgelöst. Die Abstraktion über den zusätzlichen FS20 Aktor dient hier nur dazu, die Sirene auch über andere FS20 Sender direkt auslösen zu können, z.b. durch einen Paniksender. Je nach gegebener Umgebung kann diese Abstraktion aufgegeben werden.

Alarmauslösung durch Türöffnung

define act_on_Aussentuer notify Aussentuer.*:offen 
{ if (Value("ANLAGE_STATUS") eq "scharf" || Value("ANLAGE_STATUS") eq "scharf_intern") 
{ fhem("set ALARM_STATUS ALARM ;; set Licht_an on ;; set ALARM_Melder on") } }

Dieser Teil des Codes löst den Alarm aus, wenn eine Tür geöffnet wird. (Für Fenster gibt einen analogen Codeabschnitt) Hierbei verhalten sich die FHT80TF und "normale" FS20 Tür/Fensterkontakte unterschiedlich: Der FTH80TF löst Alarm aus, auch wenn er zum Zeitpunkt der Scharfschaltung schon offen war: eine nach spätestens ca. 4 Minuten kommende Meldung über den Zustand des Tür (oder des Fensters) löst den Alarm aus. Andere Sensoren ändern den Status jedoch nicht mehr, bis sie wieder geschlossen wurden und lösen daher keinen Alarm aus, wenn sie schon offen waren als die Alarmanlage scharf geschaltet wurde.

In jedem Fall löst ein Wechsel des Zustandes als solches keinen Alarm aus. Wenn also z.b ein Fenster, das mit einem FHT80TF überwacht wird, erst vor kurzem geschlossen wurde und sein Zustand daher (innerhalb der ersten maximal 4 Minuten nach schliessen) noch auf "open" steht, so kann die Alarmanlage trotzdem scharf geschaltet werden. Die wenige Minuten später eintreffende Aktualisierung zu "closed" löst die Anlage nicht aus.

Jedes „Tür offen“ Event löst die Prüfung aus, ob die Anlage scharf oder scharf_intern ist. (Dies geschieht durch den Perl-Ausdruck für "oder" " || ")

Wenn die Anlage in einem der beiden Scharzfustände ist, wird

ALARM STATUS auf ALARM gesetzt. Damit wird die LED Anzeige für Alarm ausgelöst und eine ggf an den Aktor ebenfalls angeschlossene Sirene im Haus sofort ausgelöst. Für externe Sirenen wird jedoch der zusätzliche Aktor
ALARM_Melder auf „on“ gesetzt. Dies erlaubt abgestuft zu reagieren, z.b. den Hauptalarm verzögert auszulösen und mit Zeitbegrenzung zu versehen.
ausserdem wird mit dem in der normalen Automation definierten Dummy „Licht_an“ jedes im Haus schaltbare Licht eingeschaltet.

Natürlich liessen sich auch weitere Aktionen auslösen.

Alarmauslösung durch Bewegung

define act_on_Bewegung notify Bewegung.*:bewegung { if (Value("ANLAGE_STATUS") eq "scharf" && 
Value("ALARM_STATUS") ne "ALARM") { fhem("set ALARM_STATUS ALARM ;; set Licht_an on ;; 
set ALARM_Melder on ;; define ALARMIERT at +00:03:00 set ALARM_STATUS IRausgeloest") }}

Dieser Teil des Codes löst den Alarm aus, wenn eine Bewegung registriert wird. Weil Bewegungsmelder potentiell im Alarmfall häufiger ausgelöst werden als Türen, muss hier zur Vermeidung von Problemen mit dem Erreichen der maximalen Sendezeit nicht nur überprüft werden, ob die Anlage scharf ist, sondern auch, ob der Alarm bereits ausgelöst wurde.

Ist dies nicht der Fall (also ist die Anlage unscharf oder ALARM_STATUS bereits auf „ALARM“) wird keine weitere Aktion ausgelöst. Dadurch wird die Anzahl der Funksignale deutlich reduziert.

Dieser Teil reagiert ausserdem nicht, wenn die Anlage nur intern scharf ist.

Ist die Anlage scharf und wurde bisher kein Alarm ausgelöst, dann erzeugt eine Bewegung:

ALARM_STATUS wird auf ALARM gesetzt
ALARM_Melder wird auf „on“ gesetzt. Dies erlaubt abgestuft zu reagieren, z.b. den Hautpalarm verzögert auszulösen und mit Zeitbegrenzung zu versehen.
ausserdem wird mit dem in der normalen Automation definiertem Dummy „Licht_an“ jedes im Haus schaltbare Licht eingeschaltet.

Die Maßnahme zur Reduzierung der Funklast bei Bewegung im Haus wenn die Anlage scharf ist bewirkt jedoch, dass die Anlage stumm bleibt, nachdem die maximale (gesetzliche) Alarmdauer von 3 Minuten bei der Außensirene erreicht ist. Der Codeabschnitt:

define ALARMIERT at +00:03:00 set ALARM_STATUS IRausgeloest

dient dazu, nach diesen 3 Minuten den Zustand der Anlage von „ALARM“ auf „IRausgeloest“ zu setzen. Somit würde nach 3 Minuten eine erneute Bewegung die Anlage erneut auslösen und die Sirene würde ebenso erneut ausgelöst.

Sirene

#------Sirene---------------------------------------
define act_on_ALARM_Melder notify ALARM_Melder:on
{ if (Value("ANLAGE_STATUS") eq "scharf") { fhem("define EXT_SIRENE_AN 
at +00:00:15 set HM_SIRENE on-for-timer 176") }}

Es wird vor dem Einschalten der Sirene letztmalig überprüft, ob die Anlage scharf ist (Bei zusätzlicher Auslösemöglichkeit durch Panikschalter o.ä. müsste dieser Punkt angepasst werden). Wenn ja, wird die Sirene zeitverzögert um 15 Sekunden für 3 Minuten eingeschaltet. Da die interne Sirene direkt an die Alarmauslösung gekoppelt ist, erzeugt dies nach einem Fehlalarm (interne Sirene bereits an) noch etwas Zeit, die Alarmanlage schnell auszuschalten, bevor auch die externe Sirene aktiviert wird.

Praxis

Es empfiehlt sich, die Anlage zunächst ohne externe Sirene zu betreiben, am Anfang eventuell sogar mit gedämpfter interner Sirene. Erfahrungsgemäss dauert es mindestens 2-3 Wochen, bis alle Familienmitglieder an die Anlage denken, bevor sie das Haus betreten.

Weitere Schritte

Bei externer Scharfschaltung löst das Betätigen von Schaltern (jemand macht das Licht an) Alarm aus
nach einem längeren Zeitraum ohne erkennbare Aktivität im Innenraum (keiner da, vergessen scharf zu schalten) schaltet sich die Anlage selber scharf.
Alarmierung bei Auslösung von Feuermeldern
diverse etwas unsaubere Stellen bereinigen (Defintion aller Dummies und Aktoren zusammenfassen, Code vereinheitlichen, Funklast weiter reduzieren, etc.)
In Zusammenhang mit im Wiki an anderer Stelle beschriebenen "Zuhause Status" Überprüfungen lässt sich eventuell eine vollautomatische Scharf/-Unscharfschaltung bei An- und Abwesenheit berechtigter Personen realisieren.
Hier wird eine LED-Anzeige auf 1-wire Basis beschrieben: 1-Wire_LED-Statusmonitor
Hier wird eine Dual LED-Anzeige auf FS20 Basis beschrieben: FS20_Statusanzeige_mit_Dual-LED
Als Scharfanzeige im Aussenbereich eignet sich auch gut die HM-Dis-TD-T Retro Anzeige