Für mein künftiges SmartHome: die - besondere - Alarmanlage
Translate from German into English (some links may be mistranslated, then turn back to the original site):
Alarmanlage? Selber bauen? Wozu? Es gibt doch schöne Funkalarmanlagen im Baumarkt für unter 200 €...
Na ja! Funk? Sicher ist das nicht. Funksignale können gezielt gestört werden, sodass die vermeintlich sichere Anlage komplett ausfällt. Besser ist eine Kabellösung.
Zugegeben: aufwändig und teuer. Aber sicher! Und die Baumarktware von der Stange wird in großen Stückzahlen (in China?) produziert. Sicherheitsupdates wird es wohl nie geben. Gewiefte Zeitgenossen wissen, wie sie die Sicherheitslücken finden - bei großen Produktionsstückzahlen lohnt sich der Aufwand! Wenn diese Anlagen dann über die Firmen-Cloud auch noch auffindbar und manipulierbar sind, wird die Alarmanlage schnell zum Wegweiser für den nächsten Einbrecher!
Da ist ganz sicherlich ein kabelgebundenes Unikat viel sicherer. Solch eine Lösung beschreibe ich hier.
Bei der letzten (Komplett-) Renovierung des Hauses habe ich gezielt dutzende Leerrohre verlegt. Für alle Kommunikations- und Steuerungskabel. Auch für heute noch nicht absehbare zukünftige Anforderungen. In jeden Jalousienkasten führt solch ein Leerrohr und geht von dort bis in den Keller. Darin liegen geschützt (!) die Kabel für die Jalousien-Antriebe sowie die Signalisierungskabel der Reed-Kontakte an den Fenstern / Türen.
Leerrohre liegen ebenso zu vielen Schalterdosen - für die entsprechende Schalterverkabelung (Jalousien, Alarmanlage, aber auch für SAT-Kabel, LAN-Kabel, ...). Im Keller sind diese Kabel über ein Kunststoff-Kanalsystem zur zentralen Steuerungszentrale geführt:
Es folgen die technischen Beschreibungen der Alarmanlage, zunächst die Hardware:
Das Projekt sollte schon vor Jahren begonnen werden. Irgendwie kam immer etwas dazwischen. Mein letztes Microcontroller-Projekt liegt nun (2021) schon fast ein Jahrzehnt zurück (Wörteruhr). Die Wörteruhr hatte ich seinerzeit um den ATMEL-AVR-Controller ATMEGA32 konstruiert. ATMEL gibt es inzwischen nicht mehr: die Firma wurde von Microchip übernommen.
In meinen Schätzen fand ich diverse Microcontroller, darunter auch einen ATMEGA32. Und - wieder - um diesen Chip herum konstruierte ich die Alarmanlage. Um später festzustellen, dass das keine gute Wahl war. Aber zunächst zu den Anforderungs-Items:
Folgende Punkte waren mir wichtig:
- mindestens 8 Reed-Kontakte sollen überwacht werden
- dabei soll beim Einschalten der Anlage geprüft werden, ob alle Reed-Kontakte geschlossen sind, ansonsten Meldung, welcher Kontakt geöffnet ist
- wurde ein Reed-Kontakt-Alarm ausgelöst und dem Kontakt ist ein Fenster zugeordnet, so soll die Jalousie dieses Fensters heruntergefahren werden
- das Herunterfahren soll dauerhaft sein: es darf nicht sein, dass am nächten Morgen die Zeitschaltung diese Jalousie wieder hochfährt (da wartet bereits der nächste Einbrecher vor dem defekten Fenster...).
- dieses Vorgehen soll auch einen Stromausfall überstehen!
- 2 Bewegungsmelder sollen abgefragt werden können
- der 1. Bewegungsmelder (Wohnzimmer) soll einen Modus erhalten, der beim Lüften (Terrassentür geöffnet) ausschließlich diesen Melder überwacht. Der Rest ist aus.
- der 2. Bewegungsmelder (im Flur neben dem Schlüsselschalter) soll mit 15 Sekunden Verzögerung alarmieren. Damit man die Chance hat, das Teil ohne Alarm abzustellen.
- und letztlich die "normale" Funktion, dass alle Eingangskanäle überwacht und alarmiert werden.
- Wiederholung eines weiteren Alarms soll möglich sein - mit Wiederholungssignalisierung.
- Diverse eingängige Blinkmuster sollen den Betriebszustand signalisieren.
- (später soll ein Web-Interface vorhanden sein)
Da es so etwas nicht zu kaufen gibt: Selbermachen! Und ist an der Zeit, vergessenes Wissen zu reaktivieren.
Der ATMEGA32 hat 3 externe Interrupts. Diese werden benötigt, wenn eine externe Zustandsänderung (Reed-Kontakt öffnet) eine Aktion auslösen soll. Ich habe (hatte ...!) den 3 Interrupts folgende Funktionen zugeordnet:
- INT0 für das Detektieren eines Reed-Alarms
- INT1 für die Überwachung der 2 Bewegungsmelder
- INT2 für die Erkennung der Schlüsselschalter-Verstellung
Da es immer Gruppen sind, die zu überwachen sind (8x Reed, 2x Bew.-Melder, 3 Schlüsselstellungen) müssen diese Gruppenmitglieder zusammengefasst ("verodert") werden. Hmm. Und da machte ich den ersten Denkfehler...
Irgendwie war mir sofort klar, dass das Nebenwirkungen haben wird. Aber ich habe erst einmal alles schön aufgebaut. Dazu verwende ich fast ausschließlich Lochrasterplatinen, die Verdrahtung nehme ich mittels dünner lackisolierter Drähte vor, die über Kunststoff-"Kämme" kanalisiert werden. Ich habe so schon ganze Rechner gebaut - die nach 30 Jahren noch immer funktionieren!
Dieser Aufbau hat den Vorteil, dass nachträglich fast beliebige Änderungen vorgenommen werden können. Und da ich nie in Großserie gehe und die Entwicklungshardware dann zur Wirkplattform wird, lohnt sich das Routen / Ätzen / Aufbauen / neu Konstruieren / neu Routen / neu Ätzen / neu Aufbauen / neu Konstruieren / ... / ... von Platinen bei mir nicht. Sieht am Ende zwar nicht ganz so schön aus, aber der Weg von der Entwicklung bis zur Fertigstellung ist kürzer. Und wenn das Ganze später in einem Gehäuse verschwindet, sieht das eh niemand mehr.
Und Änderungen waren nach Aufbau und Programmierung (s.u.) bitter nötig:
Beim Entwickeln der Software ging mir dann auf, dass lediglich 1 Reed-Alarm erkannt wird. Ein zweiter wird nicht erkannt. Klar! EIN Eingang auf "1" reicht für den Ausgang auf "1". Logisch "ODER", logisch! Dasselbe bei den Bewegungsmeldern. Lediglich beim Schlüsselschalter stört es nicht. Der kann nicht gleichzeitig links und rechts stehen.
Technisch habe ich das gelöst durch RC-Kombinationen, die ich zusätzlich eingebaut habe (Lochraster sei Dank). Die erzeugen einen kurzen (!) Impuls, der zum Triggern reicht, aber danach sind alle Eingänge wieder frei. Geht, ist aber nicht elegant! Und so etwas wollte ich nicht veröffentlichen.
Ich erinnerte mich an eine Funktion neuerer AVR-Controller, die der M32 noch nicht hat: "PCINT"s. Das sind PinChangeInterrupts. (Fast) Alle Controller-Eingänge können so konfiguriert werden, dass bei einer Änderung des logischen Pegels ein Interrupt ausgelöst wird. Das brauchte ich! Gefunden habe ich die Typen ATMEGA164, ATMEGA324 und ATMEGA644. Die sind Pin-kompatibel zum ATMEGA32. Schön. Und dann habe ich sogar einen 644 im Bestand gefunden. Der hat viel zu viel Speicher. Aber zum Entwickeln reicht es. Und der kleinste Typ 164 ist dazu Software-kompatibel.
Das ist der Grund, warum auf den Platinen jeweils 1 IC unbestückt ist. Nicht mehr nötig! Selbst die 3 Interrupteingänge INT0-INT2 sind jetzt unbeschaltet! Aber zum Neubauen (s.o.) habe ich keine Lust.
Es folgen die Beschreibungen der Platinen 1 und 2 - natürlich die korrigierte Version (Schaltungen hier als alarmanlage-schematic.pdf):
Fangen wir mit Platine 2 an:
Hier sind die 8 Leitungen der Reed-Kontakt-Kabel terminiert. Die Reed-Kontakte sind im Normalfall (Fenster / Tür geschlossen) ebenfalls geschlossen. So gibt es eine gewisse Sabotage-Sicherheit: es besteht immer eine geschlossene und stromführende Schleife. Nur durch Öffnen des Kontaktes bzw. Durchtrennen des Kabels wird die Schleife unterbrochen. Der fehlende Strom (ca. 5 mA) erzeugt am Eingangswiderstand (1 k) keinen Spannungsabfall und der nachfolgende invertierende Treiber (Buffer) liefert Signal "1" am Ausgang. Die entsprechende Leuchtdiode brennt. Das Ganze gibt es 8 mal.
Die 8 Signalleitungen werden über die Verkabelung hinten im Gehäuse über die VG-Leisten an die Platine 1 weitergereicht.
Die Induktivitäten am Eingang sollen die Störsicherheit erhöhen. Als Hochfrequenzbastler weiß ich um die teilweise erstaunlich hohen Spannungen, die so ein mehrere Meter langes Kabel einfangen kann. Besonders abends auf Kurzwelle.
Dann Platine 1 der Alarmanlage:
In Blattmitte erscheinen die 8 Leitungen von Platine 2. Die 10k-Widerstände am Eingang sollen sicher stellen, dass "0"-Potential anliegt, wenn die Platine 2 abgezogen ist. Zum Entwickeln und Testen vereinfacht das Einiges. Anschließend werden durch ein Tiefpassfilter (RC-Kombination) evtl. Kontaktpreller wirksam entfernt (dann spielt nix verrückt...). Diese RC-Kombinationen erleichtern in vielen Situationen die Programmierung, da man sich um Schmutzeffekte durch prellende Kontakte nicht kümmern muss.
Links findet man die obligatorischen Induktivitäten, die Hochfrequenzstörungen vermeiden helfen. Den Eingängen für Bewegungsmelder und Schlüsselschalter folgen Treiber (nicht invertierend) und an deren Ausgängen die beschriebenen RC-Kombinationen. Die Ausgangsleitungen zu den Leuchtdioden werden ebenfalls gefiltert und durch die Transistoren gepuffert. Ebenso die Leitungen zu den Sirenenanschlüssen. Die Signalleitungen landen dann beim Controller. Letzterer ist Quarz-getaktet. Mit recht geringer Frequenz (3,6864 MHz). Die Anforderungen an die Rechenleistung sind ja auch eher gering. Genau diese Frequenz hat den Vorteil, dass sich daraus sehr genaue Bitraten für die serielle Schnittstelle realisieren lassen (es gibt einen UART an Bord des Controllers - später soll er Teil eines "Token Rings" werden...).
Und schließlich gibt es noch die Leitungen, die dafür sorgen, dass die Jalousien herunter gefahren werden können. Die Verkabelung geschieht wieder hinten im Gehäuse. Neben den "8x Jalousien ab" gibt es noch Pin 3 = Netzaktivierung und Pin 17 "zum ISM-Modul". Letzteres führt zur Gadget-Schaltung (Signalisierungseinheit, s.u.).
[Update:] Mir ist aufgefallen, dass eine Möglichkeit besteht, die Anlage von außen so zu kompromittieren, dass sie ausfällt:
Die Versorgungsspannung der kompletten Schaltung ist an einigen Stellen direkt auf den Kabeln der Signalleitungen abgreifbar. Ein Kurzschluss nach Masse / Erder / Schutzleiter könnte die Anlage ggf. außer Kraft setzen. Hier sollten passende Feinsicherungen eingesetzt werden, die sicher stellen, dass die Schaltung weiterhin mit Spannung versorgt bleibt.......
Noch einen Hinweis zu den Bewegungsmeldern: Melder, die die Netzspannung schalten, gibt es zuhauf. Melder mit zugänglichem Relais-Kontakt-Ausgang für die Signalleitungen sind meist recht teuer. Ich habe meinen leicht auf Kontaktausgang umbauen können. Sein Nachteil: nach dem Anlegen der Versorgungsspannung braucht er geraume Zeit, bis er einsatzbereit ist. Dabei "klickt" auch hin und wieder das Relais. Diese Zeit muss also abgewartet werden ("Vorbereitung"). Oder man versorgt ihn dauernd mit Netzspannung. Dann stört aber ggf. das ständige "Klicken", wenn man sich nähert...
Die Schaltbilder für die Netzaktivierung und das folgende Jalousien-Out-Interface gibt es als netzakt-out-interface-schematic.pdf
Zunächst zu Pin 3 Netzaktivierung:
Mit der Netzaktivierung wollte ich vermeiden, dass an dem hinteren Bussystem im Gehäuse und an den Jalousien-Out-Interfaces ständige Netzspannung anliegt. Die Platine Netzaktivierung unterbricht die Spannung und aktiviert sie nur bei Bedarf. Dazu reicht ein kurzer Impuls an Pin 3. Anschließend liegt ca. 1 Minute Netzspannung an den Out-Interfaces an. Das reicht für alle Jalousien zum kompletten Herauf- und Herunterfahren. Die Alarmanlage aktiviert diese Schaltung über ihren Pin 3. Die Schaltung ist retriggerbar.
Das Jalousien-Out-Interface:
Hier werden die Relais gesteuert, die die Netzspannung für die Jalousienantriebe schalten. Die Schaltung verriegelt sich gegenseitig so, dass gleichzeitiges Ausgeben der Netzspannung für Herauf- und Herunterfahren unmöglich ist. Werden die Eingänge für "Auf" (Pin 4 und 6) und "Ab" (Pin 27 und 29) gleichzeitig aktiviert: geschieht...nix! Die Eingänge "Ab" sind - über Dioden "ODER"-Schaltung(!) - direkt mit den Jalousien-Ausgängen der Alarmanlage Platine 1 verbunden.
DAS ist aber genau die geforderte Funktion des Blockierens einer Jalousie gegen Herauffahren: die Alarmanlage sendet einfach ein DAUER-Abwärts-Signal zum Blockieren!
Hinweis: die Netzaktivierung und das Jalousien-Out-Interface beschreibe ich an dieser Stelle lediglich, damit das Zusammenspielen aller Komponenten verstanden werden kann. BEIDE gehören ja nicht zur eigentlichen Alarmanlagenfunktion und können ggf. entfallen oder anders realisiert werden.
Die Signalisierungseinheit:
Diese Platine habe ich um eine alte Funkklingel herum gebaut. Das Besondere ist bei meinem Modell (gab es vor Jahrzehnten bei Conrad-Electronic), dass der Sender bestimmt, welche der 4 möglichen Melodien der Empfänger abspielen soll. Das lässt sich trefflich nutzen, um verschiedene Ereignisse zu unterscheiden. Folgende 3 sind aktuell unterscheidbar:
- "normaler" Alarm der Alarmanlage. Eigentlich sollte die Sirene laut genug sein... Aber interessant zum Testen, ohne die Nachbarn zu stören
- Terrassentür geöffnet: wenn wir im Garten in unserer Laube sitzen und nicht ständig die (nicht abgeschlossene) Terrassentür im Blick haben wollen
- nochmals in der Laube: wenn jemand an der Haustür den Klingelknopf drückt - sehr praktisch!
Ja, ja, ich weiß: Funk! Aber es ist ja keine sehr sicherheitsrelevante Funktion.
Es folgt die Software-Beschreibung:
Aufgrund meiner guten Erfahrungen bei Projekten der Vergangenheit habe ich wieder auf die Entwicklungsumgebung von mcselec.com gesetzt: "BASCOM-AVR". Dieses Produkt wird vom Hersteller trotz der Konkurrenz von ARDUINO-Plattformen immer noch aktiv unterstützt und weiterentwickelt. Und es gibt weiterhin eine kostenfreie Demo-Version, die Code bis zu einer Grenze von 4 KByte compilieren kann. Und für dieses Projekt ist das mehr als ausreichend!
Gegenüber ARDUINO hat das den Vorteil, dass man keine fertigen Boards verwendet, die IMMER Einschränkungen bescheren. Z. B. dadurch, dass nicht ALLE Controller-Pins für das Projekt zur Verfügung stehen. BASCOM erlaubt die Verwendung des Chips pur!
Bevor ich die Software präsentiere, möchte ich einige Anmerkungen machen:
BASCOM-AVR erlaubt die Programmierung von Controllerfunktionen mit High-Level-Befehlen. Das macht es für den Anfänger einfach, erste Erfolge zu feiern. Da gibt es z. B. Anweisungen wie:"Config Timer1 = Timer , Prescale = 1024"
oder"Config Timer1 = Counter , Edge = Falling , Capture_Edge = Falling , Noise_Cancel = 1"
.
Solche Ungetüme werden Sie bei mir nicht finden. Dabei weiß man nie so genau, was der Compiler daraus macht - und welche Nebenwirkungen das haben kann. Ich "klappere" lieber direkt an den Controller-Registern "herum" - Low-Level-Anweisungen wie im Datasheet beschrieben.
Beschreibungen wie "When the PCIE2 bit is set (one) and the I-bit in the Status Register (SREG) is set (one), pin change interrupt 2 is enabled. Any change on any enabled PCINT23..16 pin will cause an interrupt. The corresponding interrupt of Pin Change Interrupt Request is executed from the PCI2 Interrupt Vector. PCINT23..16 pins are enabled individually by the PCMSK2 Register." sind doch eigentlich eindeutig!
Wenn Sie sich meiner Sichtweise anschließen können, dann noch ein Insider-Tipp zu den Bezeichnern, die in BASCOM verwendet werden: manchmal ist man unsicher, wie ein Bezeichner lautet. Der Compiler meckert, weil er etwas nicht findet. Z. B. die Vectoradresse für den Interrupt "$001A = TIMER1_COMPA". So steht es im Datasheet für die TIMER1-CompareA-Interrupt-Adresse. Diese wird in meinem Programm für den 10 Hz-Heartbeat des Systems benutzt.
Ein Blick in die (Text-) Datei(en) "m644def.dat" oder "m644Pdef.dat" oder "m644PAdef.dat" (diese findet man im Unterordner \DAT im BASCOM-Installationsverzeichnis und sie steuern den Compiler) liefert:
"OC1A=$01A; Timer1 Output Compare A Interrupt Vector Address"
.
Der Bezeichner für die Vectoradresse lautet somit "OC1A". Gleichzeitig haben Sie erfahren, dass es den ATMEGA644 in 3 Versionen gibt: als 644, 644P und 644PA. Und der genaue Typ muss dem Compiler ganz zu Beginn der Quelltextes mitgeteilt werden:
$regfile = "m644def.dat"
.
Statt m644def.dat - da haben wir gerade hineingeschaut, könnte auch m644Pdef.dat oder m644PAdef.dat korrekt sein - je nach verwendetet Typ. Genauso leicht findet man Differenzen zwischen BASCOM-Registerbezeichnungen und den Registernamen im Datasheet.
Ich wollte Sie aber nicht verwirren. Lassen Sie sich das durch den Kopf gehen, wenn es Compiler-Probleme geben sollte.
Hier finden Sie den Quelltext der Controller-Software. Zu Anfang sind die möglichen Blinkfolgen der roten und grünen LED am Schlüsselschalter beschrieben:
- langsam grün blinkend (Vorbereitungszeit, direkt nach dem Einschalten)
- 1 - 8 mal kurz rot blinkend, ewig wiederholend (Reed-Kontakt X ist geöffnet -> Warnung, dass ein Fenster auf ist)
- Dauer-Grün (Schalterstellung "Alle", Anlage SCHARF!)
- Dauer-Rot (ALARM! Sirene ertönt 3 Minuten, Jalousie X fährt herunter, wenn Reed-X-ALARM)
- Dauer-Rot mit Unterbrechung (wie 4. , Wiederholung)
- schnell rot blinkend (Beweg.-Melder Flur meldet, 15 Sekunden Zeit zum Abschalten, sonst ALARM)
- rot-grün langsam im Wechsel blinkend (bei Schalterstellung "WoZi", Überwachung ausschließlich mit Beweg.-Sensor im Wohnzimmer - "Lüftungskontrolle")
- alle LEDs aus (Anlage ausgeschaltet)
Alle Texte in grün sind Bemerkungen. Als Programmierer kann man gar nicht genug kommentieren. Das erleichtert das spätere Wiedereinlesen und Verständnis. Bezeichner in braun sind Registernamen des Controllers. Eine Anweisungen wie:pcicr.pcie3=1
bedeutet: Bit "PCIE3" im Register "PCICR" wird auf "1" gesetzt. Diese Namen findet man im Datasheet wieder - mit der genauen Erläuterung dazu. Lediglich die Punkt "." - Notation findet sich so nur bei BASCOM.
Im Kopf des Quelltextes sind diverse Konstanten, Variablen und Aliase gesetzt. Mit Aliasen kann man die Lesbarkeit verbessern. Z. B. kann man überSirene alias Portb.3
die Sirene direkt ansprechen statt kryptisch mit Portb.3
. Bedeutet: Bit 3 im Pin-Port "B" ist gemeint. Bit 3 ist das 4. Bit, da die Nummerierung mit Null beginnt.
Das soll erst einmal genug sein zu den Sprach-Basics von BASCOM... Mein Programm besteht grob aus 4 Teilen: dem Kopf mit den Deklarationen (s.o.), der Programmhauptschleife (zwischen "do" und "loop"), den Unterprogrammen (mehrmals "sub" bis "end sub") und den Interrupt-Handlern (mehrfach "onXYZ:" bis "return").
Eigentlich ist mein Programm ein Musterbeispiel für eine ereignisgesteuerte sequenzielle Zustandsablaufsteuerung. Die meiste Zeit verbringt der Prozessor seine Zeit damit, die Hauptschleife immer wieder zu durchlaufen. Und nur das zu machen, was dem aktuellem "status" zugeordnet ist. Ein Wechsel von "status x" zu "status y" wird meist durch ein Ereignis eingeleitet. Ereignisse können externe Anstöße sein (=Interrupt, z. B. ausgelöst durch den "0" nach "1" -Wechsel auf einer Reed-Leitung). Oder interne Anstöße, z. B. durch ein TIMER-Ereignis (hier alle 100 ms). Der zugehörige Interrupt-Handler wird "angesprungen" und führt irgend etwas aus. Z. B. den "status" neu setzen. Interrupt-Programme laufen immer nur ganz kurz; am Ende wird mit "return" dorthin zurückgekehrt, wo die Hauptschleife unterbrochen wurde! Umfangreichere Aktionen finden meist im Hauptprogramm statt. Das Hauptprogramm würde z. B. dann die dem neuem "status" zugeordnete Aktion ausführen. Um danach wieder die ewige Mühle der Hauptschleife tatenlos zu durchlaufen.
Ausgestattet mit diesen Informationen dürfte es Ihnen gelingen, sich die Funktionsweise des Programmes zu erschließen. Ich habe mir Mühe gegeben, möglichst alles zu kommentieren. Vielleicht noch einige Hinweise dazu, was ich mir mit dem Wechsel vom 1. zum 2. Controller mit seinen PCINTs-Interrupts eingehandelt habe. Beim ersten Controller waren von den 3 externen Interrupts 2 so schön zu konfigurieren: nur bei einem Wechsel von "0" auf "1" sollte reagiert werden. Wechsel von "1" nach "0" wurden ignoriert; der Wegfall eines Alarms interessierte nicht. Bei den PCINTs wird JEDE Änderung registriert. Leider lässt sich das nicht einschränken. Und es gibt keine weitere Informationen welches Bit sich in einer PCINT-Gruppe wie geändert hat... Das muss das Programm selbst herausfinden!
Da bleibt dem armen Programmierer nichts anderes übrig, als auf alle Änderungen zu reagieren, sie sich zu merken und anschließend mit den neuen Zuständen zu vergleichen...
Sollten Sie Interesse an dem Projekt haben und selber experimentieren wollen, so muss das Programm anschließend aus dem Rechner auf den Controller kommen. Dazu braucht man einen ISP-Brenner (In-System-Programming Programmiergerät). Das gibt es beim Hersteller von BASCOM-AVR (USB-ISP-Prog - teuer -) oder bei ebay - billig aus China. Die zugehörigen Treiber gibt es im ersten Fall direkt auf der WebSite, im letzten Fall bei Fischl. "Gebrannt" wird der Chip dann direkt aus der BASCOM-Entwicklungsumgebung - nachdem in den Einstellungen der entsprechende Programmer ausgewählt wurde (!!).
Und natürlich kann Ihr Projekt dann Anpassungen an Ihre spezielle Umgebung enthalten. Und Erweiterungen: es sind noch die Controller-Pins PB2, PB5, PB6 und PD0 bis PD3 frei! Auch meine Alarmanlage hat "Spezial"-Funktionen und Erweiterungen erhalten, die ich hier aus Sicherheitsgründen natürlich nicht beschreibe ...!
Noch einen Hinweis zu den sogenannten "Fusebits" der Controller. Diese stellen gewisse Voreinstellungen her. Ob bestimmte Schnittstellen aktiviert sind, die Taktversorgung (intern / extern mit Quarz, ...). Wichtig sind hier die "Fusebits" und "Fusebits High". Diese kann man auswählen und ändern und dann mit "Write FS" bzw. "Write FSH" übertragen. Bitte anschließend kontrollieren, ob das geklappt hat. In der Regel wird erst nach Ausschalten und Wiedereinschalten der Stromversorgung des Controllers die Änderung übernommen! Abhängig vom Brenner sollte der "Lock and Fuse Bits"-Dialog so aussehen:
Stellen Sie sicher, dass der Quarz für die externe Taktversorgung auch vorhanden ist. Und KEINE ANDEREN ÄNDERUNGEN vornehmen!!!!!!!!!!!
[Update (11.2022)]: Es ist 1 Jahr später und ich habe mit der Konstruktion der SmartHome-Zentrale begonnen. Das Konzept sieht vor, dass alle Komponenten miteinander kommunizieren können. Die Software der Alarmanlage wurde also um den Kommunikationsteil samt Routingmechanismus ergänzt [/Update].
(Beitrag wird später fortgesetzt)
Au! Alles falsch gemacht! Eine Alarmanlage selber bauen? Das sollten Sie besser sein lassen!
Keine Garantie! Was mache ich nur bei einem Fehler? Und keine Gebrauchsanleitung! Wie nur baue ich sie ein? Und kein Wartungsvertrag!
Was natürlich stimmt: wenn Ihre Versicherungsbestimmungen eine zertifizierte Anlage verlangen, dann ist der Selbstbau nicht anzuraten. Ansonsten: besser als nix und mit Überraschungsfunktionen kann man den Einbrecher verwirren und vielleicht verjagen...