EIA-485 SMS Alarm, Gateway möglichst dumm?

[Eva (Gast)]

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

[Eva (Gast)]

Evtl. ist diese Frage besser beim Hausbus aufgehoben?

[Purzel H. (hacky)]

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.

[gggggGast (Gast)]

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.

[Eva (Gast)]

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?

[Harald N. (harald_)]

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 
[e-mail] 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