Ich möchte, dass verteilte, verschiedene Sensoren im Alarmfall zum
Versand einer oder mehrer SMS führen.
Natürlich soll es nichts kosten und alles können, ohne dass ich einen
Finger krümmen müsste :-)
Ein Bussystem verspricht geringen Hardwareaufwand und Erweiterbarkeit
bei der Anbindung der Sensoren. Einfach und günstig ist EIA-485.
Am anderen Ende ist ein GSM Modul, dass über serielle Schnittstelle AT
Kommandos gesteuert wird und so SMS verschicken kann.
Vorerst sind die Sensoren binär, interessant ist jedoch noch etwas
Klartext zum Sensor (z.B. "Das Fenster zum Hof").
Die Sensoren sind auch recht dumm, d.h. kleine Controller reichen aus.
Im besten Fall tritt der Alarm nicht ein und das System wird gar nicht
gebraucht, d.h. es ist eigentlich nie Datenverkehr.
Ich kann mich nun leider nicht unmittelbar entscheiden, wie man das
aufziehen sollte:
Der Bus ist eigentlich single-master, d.h. er muss die Slaves kennen und
pollen. Sofern es kein einfaches Plug und Play-Verfahren gibt, muss man
bei neuen oder anderen Sensoren immer an den Master ran. Die Sensoren
können sehr einfach ausfallen, sie müssen nur wenige Informationen
senden, wenn sie gefragt werden.
Alternativ könnte die Intelligenz in die Slaves geteckt werden, sie
könnten eigentlich auch direkt mit dem GSM Modul sprechen.
Vorteil: das System kann durch Slaves leicht ergänzt werden.
Nachteil: die Slaves tragen das komplette System (Ansteuerung des GSM
Moduls) vornehmen. Und es könnte zu Kollisionen kommen. Der Bus wäre für
andere Nutzung nicht verfügbar.
Ein Mittelweg wäre evtl., dass ein Controller als Gateway zwischen Bus
und GSM-Modul funktioniert, so dass die Slaves einfach Fenster-Alarm!
schreien und das Gateway sich um den Versand kümmert.
CAN ist etwa doppelt so teuer und die Leitungslänge könnte knapp werden.
Mhh. Man kann nicht alles haben (Ethernet ist wirklich zu teuer :-).
Vielleicht habt ihr ja noch Ideen...
Bevor man sich mit Preisen befasst sollte man wissen, ob es um ein
Stueck geht, oder eine Entwicklung zur Serie. Ich verwende ein fertiges
Modul : das Comat SMS Relay von www.comat.ch. Fuer ein paar hundert
Euro. Alles andere, eine Entwicklung mit Bus ist beliebig viel teurer,
hat drei Nullen hinten dran.
Ethernet ist gaenzlich fehl am Platz, denn der Standby Stromverbrauch
ist viel zu hoch im Vergleich zur den erforderlichen Datenraten. Wenn's
denn ein Selbstbau sein muss, Master-Slave ist einfacher wie
Multimaster. Und Beim Master-Slave ist Fullduplex einfacher wie
Halbduplex. Daher wuerd ich RS422 nehmen. Die paar Kabel fallen bei den
Projektkosten nicht ins Gewicht.
Wenn das ganze nur in eine Richtung laufen soll und auch noch über lange
Kabel ist RS485 wohl Mittel der Wahl. Bei kurzen/seltenen Alarmmeldungen
kannst du dir auch Master Slave Protokolle schenken und eine
Kollisionerkennung nutzen (was auch die Betriebssicherheit erhöht da
kein Master ausfallen kann).
Sensorausfall kann dann mittels zeitgesteuerter Meldungen ermittelt
werden.
Es ist ein Bastelprojekt. Für ca. 130 Euro bekommt man ein Telit GSM
Modul und Platine (sparkfun, oder Hutschienenmodul:
http://www.falcom.de/products/modems/dr864/) das ein paar IO hat und mit
Python skriptfähig ist. Wenn man wenige binäre Sensoren hat braucht man
nur ein Netzteil und gut (stelle ich mir vor, habe nicht weiter
recherchiert). Man könnte auch alle Sensoren an eine Alarm-Leitung
setzen, es gibt dann eben nur eine Meldung für alle.
Hier werden CAN Transceiver als Physical genutzt:
Beitrag "CAN Hausbus - Konzept von Klaus Gusenleitner" bzw. direkt
http://members.aon.at/hausbus/German/index-Dateien/general.htm
Damit ließe sich erkennen, ob eine Kollision stattfindet.
Von Kollisionsvermeidung allgemein habe ich noch keine Ahnung.
D.h. wenn mehrere senden, werden irgendwann bei einem die rezessiven
Bits dominiert und der rezessive gibt dann auf. Anhand seiner ID könnte
er dann nach einiger Zeit die Sendung wiederholen.
Es wäre also Multi-Master und sollte für seltene Übertragung und wenig
Daten gehen.
Das Gateway ist halbdumm und abstrahiert den Versand von Nachrichten,
ein Sensorknoten übermittelt den Auftrag und eine Nachricht.
Zur Absicherung gegen Ausfall von Sensorknoten kein Polling, sondern
zeitgesteuerte Meldungen, d.h. das Gateway muss die vorhandenen Knoten
lernen und prüfen, ob innerhalb einer bestimmten Zeit eine Nachricht
eingegangen ist.
Klingt das soweit schlüssig?
Für Euro 179,00 bekommt man das Pythonskriptfähige GPRS Modem hier:
http://www.gsm-modem.de/M2M/m2m-gallery/gsm-modem-with-watch-dog/
+++ FALCOM DR864 versus GPRS Modem mit Watchdog +++
keine galvanische Trennung / galvanische Trennung
1 GPIO / 4 Eingänge und 1 Ausgang
Input nur DC / Input DC und AC
kein I2C-Bus / I2C-Bus für 128 ext.
Sensoren/Aktoren
kein Notstrombetrieb / Notstrombetrieb mit int. Akku (opt.)
kein ext. HW-Watchdog / HW-Watchdog mit ext. Microcontroller
kein Test Server / Test Server
RS232 (5 Pins,u.a fehlt DTR+ RING / RS232 9 Pins
UB unklar, verschiedene Angaben) / UB 8 bis 36 Volt
Mittels I2C-Bus können sehr viele, externe Geräte über ein preiswertes
Kabel über mehrere hundert Meter angeschlossen werden. Den Lasttest
würde mittels Kabeltrommel und ganz viel Kabel drauf gemacht.
Da Python im Telit GC864-Quad nicht echtzeitfähig ist empfehle ich ein
Polling auf dem I2C-Bus. Ohne DTR auf der RS232 diese kann das
Telit-Modul nicht in den 2 mA Mode Empfangsmode geschaltet werden (Deep
Idle mit Möglichkeit des Sendens und Empfangens von SMS, Voice, Fax und
CSD). Der Ring-Indikator wurde auch nicht aufgelegt. Der RING kann, wenn
ich mich richtig informiert, bin auch bei eingehender SMS aktiv werden.
Ohne galvanische Trennung kommt langfristig keine Freude auf.
Da ich nun aktiv mit in die Entwicklung des GPRS-Modem mit Watchdog
eingebunden bin, kenne ich das Innenleben recht gut. Sollte jemand die
RS485 bevorzugen, kann dies über einen Konverter an der RS232 oder am
I2C-Bus erfolgen.
Das GC864 unterstützt auf den SPI-Bus. Der wurde aber bisher nicht unter
Last mit externen Geräten getestet.
Damit ein User beim Einschalten des GPRS-Modem mit Watchdog sofort ein
Erfolgserlebnis hat liegen 2 Pyhonscripts als Binärfile mit bei.
Wünsche für Änderungen bzw. Ergänzungen könnt ihr gerne per Email an
harald.naumann@gsm-modem.de mitteilen. Soweit möglich, fließen diese
ohne Aufpreis in das Seriengerät mit ein. Für Hobby-Elektroniker
entstehen somit keine Mehrkosten.
Änderungen und Anpassungen am Seriengerät sind ab Stückzahl 100 möglich.
Darüber hinaus sind kundenspezifische Geräte ab Stückzahl 250 möglich.
Gruß aus Neustadt
Harald Naumann
Eine eigene Frage?
Dieser Thread ist über 15 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
