Die BMA soll bei mir zuhause eingesetzt werden.
Es soll um Gottes Willen kein kompliziertes Projekt werden.
Eingesetzt werden gewöhnliche Rauchmelder. Diese sollen auch weiterhin ihre Funktion behalten, also im eigenen Raum auslößen.

Geplant hatte ich das ganze in etwa so:

* Ein Rauchmelder in Raum A lößt aus und schaltet die Melder in Raum B,C,D... auch auf Alarm. (Könnte ich über die Prüftaste realisieren)

* Einzelne Melder ausschalten, z.B. bei Bohrarbeiten. (Könnte man ein Relais zwischen die Batterie und den Melder klemmen welches dann den Stromkreis unterbricht). Dabei verwende ich natürlich einen Öffner Kontakt, der beim Ausfall der Anlage den Stromkreis wieder schließt damit der Melder wieder aktiv geschaltet ist.

* Das ganze soll über ein Display und Taster gesteuert werden.
Lößt z.B ein Melder aus, soll eine LED blinken und auf dem Display erscheint "Melder Raum X Feueralarm".

* Die Adressierung sollte über das geschaltete Relais erfolgen. (Kontakt wird geschlossen und sendet eine Spannung an die Input Platine) Müsste doch Möglich sein das ganze Softwaremäßig zu verschrauben.


So habe ich mir das ganze in etwa vorgestellt. Ob es realisierbar ist?
Im absoluten Notfall würde ich mir eine fertige kaufen und diese "modifizieren". Aber selberbauen ist immer noch am schönsten und man weiß wie´s funktioniert.



[ Diese Nachricht wurde geändert von: flippy am 21 Mär 2009 21:53 ]

Hallo,

Zitat :

Es soll um Gottes Willen kein kompliziertes Projekt werden.

Dann lass es und kauf dir eine.

Tut mir leid, das so direkt zu sagen, aber von so einer Anlage hängt eines an Finaziellem ab, ganz zu schweigen von potentiellen Todesfällen.

Sowas läuft professionell mit eigener USV und anderen technischen Mittelchen, um es so störfest wie nur möglich zu machen; schon garkeine Basteleien mit Relais, irgendwelchen IO-Karten und einem ganzen PC.


Es wäre durchaus möglich, bestehende Rauchmelder zu vernetzen, ohne dass sie ihre Aufgabe im Falle eines Netzausfalles nicht übernehmen könnten (Piepton erzeugen). Dazu sollte es dann aber doch schon eine Eigenentwicklung sein, die einen potenten Mikrokontroller besitzt. Der kann auch die Ansteuerung des Displays übernehmen sowie die anderen Rauchmelder aktivieren. Das geht allerdings nicht ohne Eingriffe in die Elektronik.

Mikrokontroller lassen sich in gängigen Sprachen programmieren; ich würde hierfür C++ empfehlen. Jaja, auch wenn hier gleich wieder gebrüllt wird: C++ und kleine µCs passen nicht; ich habs selbst ausprobiert; es klappt hervorragend und es ist angenehmer als Basic und C, wobei C sonst zu empfehlen wäre.

_________________

@ DonComi
Ich kann nicht mal ansatzweise eine der genannten Programmiersprachen.
Eine Visualisierung wie mit Galileo wäre eine Alternative.

Wenn ich dann nun eine fertige kaufen soll: Woher? Die Preise sind gigantisch und so ein 200 Euronen eBucht Teil kann man direkt verbrennen.

[ Diese Nachricht wurde geändert von: flippy am 21 Mär 2009 22:17 ]

Hast du die Innenschaltung der Rauchmelder ?
ohne die geht erst mal gar nichts!!!!
guß Bernd
edit gruß

[ Diese Nachricht wurde geändert von: der mit den kurzen Armen am 21 Mär 2009 22:21 ]

Hier die Schaltung des Rauchmelders

Tach,

Das würde man auf jeden Fall hinbekommen. Dennoch sind, um den Status abzufragen bzw. den Melder zu aktivieren Eingriffe nötig.

Die Vernetzung ließe sich über relativ einfache und günstige Datenleitungen aus dem Netzwerkbereich erledigen. Da es hierbei recht gemütlich zugeht muss man sich über die Datenübertragung kaum Sorgen machen; man sollte aber darüber nachdenken, alles potentialgetrennt zu machen; spricht: Auslösung über Optokoppler und Abfrage des Status' über einen zweiten Optokoppler.
Das hat den Vorteil, dass man keine, für alle Melder geltenden Massebezüge haben muss.

Dadurch werden ja die Melder nicht in ihrer Funktion beeinträchtigt (wenn man es ordentlich anstellt).

Allerdings, und das ist hier das größte Problem, musst du wohl oder übel eine Sprache, rudimentär, erlernen. Du brauchst keine komplexen Algorithmen oder ähnliches, es reichen also wirklich grundlegende Kenntnisse einer Sprache und eben die Möglichkeit, Programme auf den µC zu übertragen.

Es gibt fertige Bibliotheken für die Displayansteuerung, bleibt also nur noch die eigentliche Logik; und die besteht eigentlich nur aus dem zyklischen Abfragen aller Melder und dem entsprechenden Reagieren darauf.



_________________

Hmmm...
Seit wann sollte man(n) einen Microcontroller in C++ programmieren??? Bei einem 32bitter würde ich das ja noch einsehen, bei einem 16bitter evtl. Ansonsten würde ich sagen C oder Assembler bei einem 8bitter, der hier sicher ausreicht! Ich programmiere immer noch gerne in Assembler, null Overhead und immer genau wissen was das Ding macht ist etwas wert. Für kompliziertere Dinge langt meiner Meinung nach C auch.
Grüße,
Ralph

P.S.: Der kein C++ kann...

Mahlzeit Ralph,

Du hast ja im Ansatz Recht: Assembler ist meist das Optimum. Aber ich tue mir das nicht mehr an.
Angefangen habe ich bei den AVRs beispielsweise auch mit Assembler und kann es auch immer noch. Nur sehe ich nicht ein, warum ich als Programmierer mir mehr Gedanken über die Verwaltung des Heap und des Stacks machen sollte, als über die eigentliche Programmlogik.

Deswegen bin ich dazu übergegangen, nur noch kleine µC direkt in Assembler zu programmieren, größere werden in C kodiert. Sollten dort zeitkritische oder speicherkritische Algorithmen gebraucht werden, dann kodiere ich weiterhin in Assembler, und binde den erzeugten Objektkode in meinem C/C++-Programm mit ein. Das ist überhaupt kein Problem.

Und ich habe kürzlich scherzhaft mal den avr-g++, also den GCC mit C++-Backend für AVRs, bemüht, und wollte wissen, ob er effizienten Kode erzeugt - und siehe da: sehr wenig Overhead. Das kommt vor allem daher, dass Exceptions und dynamische Speicherverwaltung sowie die STL nicht implementiert wurden. D.H., ich habe ziemlich knackigen Kode, der auch verdammt schnell rennt.
Dennoch kann ich objektorierntiert programmieren, sowie Operatoren und andere Dinge überladen, polymorphe Funktionen benutzen, Namensräume benutzen und so weiter.

C find ich zwar schöner, da es so übersichtlich ist, aber mir ist mittlerweile der kleine Overhead egal, wenn es nur um die Programmlogik und dennoch schnelle Laufzeit geht. Deshalb tue ich mir auch Basic nicht an...


Das z.B. ist damit möglich, das find ich klasse

lcd Display;

Display << "Hallo Welt\n";

oder Display << CLEAR_DISPLAY;

oder Display << SHIFT_LEFT;

Und der avr-g++ macht das wirklich effizient, ist kaum länger als die äquivalente Programmlogik in C. Zumal man portabler wird.

_________________

der Finger hat mal sowas gebaut:
http://www.fingers-welt.de/gallerie.....r.htm

_________________

Hallo DonComi,

wenn C++ da so gut läuft, dann ist das ja fein!

Ich hab damals im Studium nur Assembler verwendet und die Maßgabe war, wer den uC in Assembler programmieren kann, der kann dann auch C verwenden. Für einen Einsteiger ist Assembler natürlich erst mal schwierig, aber er sieht auch direkt was da passiert. Wenn denjenigen das natürlich nicht interessiert, dann kann er auch gleich in einer Hochsprache arbeiten. Verpaßt dabei aber halt den uC richtig zu verstehen. Also je nach Anwender und Anwendungsfall.
Ansonsten
Viele Grüße,
Ralph

@Nicki: Schöner Link vom Finger! Sieht ganz gut aus was er da mal wieder gestrickt hat!
Viele Grüße,
Ralph

dp wech

[ Diese Nachricht wurde geändert von: ElektroNicki am 22 Mär 2009 18:15 ]

Offtopic :

Hallo Ralph, Ich beherrsche den AVR-Assemblerdialekt vollkommen, andere Dialekte ebenso. Habe unzählige Dinge geschrieben, aber irgendwann nerven einen gewisse Dinge, die einem der Compiler eben auch abnehmen kann. Aber wie gesagt, wichtige Dinge werden direkt in Assembler kodiert, auch z.B. auf dem PC oder Laptop. C ist da schon ganz angenehm, aber C++ bietet eben eine höhere Abstraktion. Da ich genau weiß, wie so ein AVR funktioniert, kann ich ihn auch ruhig mit C++ programmieren, und auch den Compiler so parametrisieren, dass er sehr optimalen Kode erzeugt. Schöne Grüße zurück

_________________