Hallo, so nachdem nun meinen ersten Schritte im Bezug auf den Hausbus gemacht sind, möchte ich euch nun mal meinen Hausbus vorstellen. Der komplette Bus wird mit 4 Adern versorgt ( +12V GND A / B ) somit entfällt schon mal ein seperates Netzteil für alle einzelnen Baugruppen. Der größte Teil der Teilnehmer wird von einem Atmega 8 gesteuert, der über einen MAX485 an den Bus angekoppelt ist. Nach langen Tests und Überlegungen habe ich mich dazu entschlossen, auf ein seperates umfangreiches Protokoll zu verzichten. Sozusagen als Taktgeber für den Bus verwende ich einen DCF-77 Empfangsteilnehmer, der die aktuelle Zeit und das Datum auf den Bus legt. Diese Daten werden von allen Teilnehmern empfangen und ausgewertet. Nacheinander senden dann alle Teilnehmer Ihre Daten los. ( Da ich keine schnelle Vorgänge benötige, sende ich mit 2400 Baud, und nach jedem Sendevorgang des DCF-77 haben dann die restlichen Teilnehmer fast 1 Minute zeit, ihre Daten zu senden.) Momentan sind bereits folgende Komponenten fertig und laufen: 1.) DCF-77 Empfänger : sendet Zeit und Datum und Wochentag 2.) Wettersensor : sendet Außentemperatur, Helligkeit und Regen 3.) Aktor 1 : 4-Kanal Schaltuhr, incl. 2fach PWM-Regler für Außenbeleuchtung ( LED´s) incl. 6 Eingänge für Manuelle Steuereingriffe 4.) Controller : Überwacht den Bus, und zeigt die übertragenen Daten auf einem Display an. Wenn länger als 2 Minuten kein Signal empfangen wird, wird ein Masterreset ausgelöst ( Hat sich bisher noch nicht ereignet) 5.) Heizungsüberwachung : Vorlauf und Rücklauf-Temperatur, Störungsanzeige sowie Warmwasserumschaltung ( Kessel/Strom) Folgende Komponenten sind bereits in Arbeit : - Anzeige aller Daten auf einem Grapikdisplay 264x128, sowie 6 Eingänge für manuelle Änderungen - div. seperate Anzeigen ( fürs komplette Haus ) minimierte Ausführungen auf Displays 2x16 bis 4x20 - Sensor fürs Gewächshaus ( Temp. Luftfeuchte Helligkeit) Die nachfolgenden Komponenten werden dann in der Endphase noch eingebunden ( eine Planung ist hier noch nicht erfolgt): - div. weitere Aktoren ( bis zu 6-kanälig ) mit PWM-Ausgängen - Regenwassertank Überwachung mit Füllstandsanzeige - Schreiber ( protokolliert die Daten und speichert diese) - Ankopplung an GSM-Netz zur Fernüberwachung und Fernsteuerung Meine beiden Hauptprozessoren die ich einsetze ist der Atmega8 und der Atmega 32. Vielleicht hat ja noch jemand Ideen, was man noch mit einbinden kann, bzw. wenn jemand Interresse an dem Projekt hat, meldet euch bei mir. Jedoch gleich im Vorfeld, es gibt keine fertigen Platinen, da ich bisher alles auf Lochraster aufgebaut habe ( wird sich später noch ändern). Gruß
Hört sich gut an. So ähnlich ist mein Hausbus auch aufgebaut - 4 Adern, Betriebsspannung, GND, TxD und RxD. Taktregime (10 Sekunden) und Buspegel (modifizierte RS232 mit 1200 Baud) sind ähnlich. Leider ist das Projekt ziemlich alt und die Datenstationen sind noch mit einer separaten UART aufgebaut. Demnächst will ich auf LowPower-µC MSP430F1611 umsteigen - die Spannungsversorgung läuft bei mir autonom über einen solargeladenen 12V-Akku. Zusätzlich will ich dann ein paar Daten mehr übertragen. Die Anzeige (gleichzeitig Master und Datenspeicher) läuft bei mir über ein Notepad NC100 von Amstrad. Aber nur, weil es gerade rumlag, RS232 + Speicherkarte + Anzeige hat und fast keinen Strom braucht. Für den neuen Master hatte ich vor, eine 128x64-Grafikdisplay von Pollin in Verbindung mit einem MSP430-µC zu verwenden. Meine Datenstationen können nicht nur Reedkontakte an allen Fenstern und Türen lesen, sondern auch Netzspannungen und -ströme melden (Waschmaschine, Trockner, ...). Außerdem habe ich noch einige Lichtsensoren angebracht, da ab und zu mal selbiges vergessen wurde auszuschalten. Die Datenstationen haben auch mehrere Ausgänge und könn(t)en Aktoren schalten. Da der 4-Draht-Bus als (offener) Ring verlegt wurde, kann ich meinen Master überall aufklemmen/anstecken. Geplant hatte ich aber einen ortsfesten Master und ein "bewegliches" Display (mit dem man aber Einstellungen im Master vornehmen kann - sozusagen ein Sub-Master). Es soll zwar keine Alarmanlage werden, aber wenn einer als Letzter das Haus verläßt, müssen alle Fenster und Türen in einem bestimmten Zustand sein, Licht aus und sonst alles im "grünen Bereich". Das soll mir die Anlage mit einem Blick mitteilen. Und wenn ich wiederkomme, will ich alle sicherheitrelevaneten Ereignisse mit Uhrzeit und Datum aufgelistet haben. Wie sieht denn Dein Protokoll aus, wieviele Teilnehmer sind denn vorgesehen und wie erfolgt die Addressierung? Blackbird
Hmm, mal ein Kommentar dazu. Ich schalte über die Türkontakte teilweise auch das Licht, was mir jetzt schon zu lange dauert. Zwr wird der Türkontakt direkt an den Rechner angeschlossen, was natürlich an der Stelle kein Bussystem ist, aber es dauert so schon recht lange vom Öffnen der Haustür bis z. B. im Garten das Licht angeht. Wenn man jetzt noch so ein System im 1 Minuten Takt verwendet, ist diese Anwendung ja komplett unmöglich. Gruss Axel
@Axel >Ich schalte über die Türkontakte teilweise auch das Licht, was mir jetzt >schon zu lange dauert. Wie lange dauert es denn? >Wenn man jetzt noch so ein System im 1 Minuten Takt verwendet, ist diese >Anwendung ja komplett unmöglich. Dafür gibt es zwei Lösungen a) Takt erhöhen auf 1..10 Hz. b) Sensoren sind Masterfähig und senden bei einem Schaltvorgang an den Aktor. MFG Falk A
"Wie lange dauert es denn?" Na, Sensor pollen, verarbeiten im PC (die Software macht ja noch ein bischen was anderes), vielleicht 1-2 Sekunden. Schalter wird über X10 angesteuert, das dauert auch noch mal 1-2 Sekunden. Bis so eine Energiesparlampe dann zündet, auch noch mal 1-2 Sekunden. Macht also so ca. 3-6 Sekunden, von dem Zeitpunkt, wo man aus der Tür tritt, bis man Licht hat. Da geht es dann aber schon über die Stufen. Sicher kann man das beschleunigen, aber so ist das gerade noch akzeptabel. Aber länger würde nicht gehen. "b) Sensoren sind Masterfähig und senden bei einem Schaltvorgang an den Aktor." Dann muss man aber anfangen, sich über Kollisionserkennung Gedanken zu machen. Ich denke darüber nach, dass evtl. mit 1-Wire zu realisieren, bei dem es einen Alarm-Befehl gibt. Der muss zwar gepollt werden, aber evtl geht das doch. Allerdings habe ich derzeit Probleme mit der Drahtlänge. Theoretisch sollte es gehen, in der Praxis habe ich allerdings Ausfälle im Stundenbereich, danach geht es dann plötzlich wieder. Gruss Axel
@Axel >Macht also so ca. 3-6 Sekunden, von dem Zeitpunkt, wo man aus der Tür >tritt, bis man Licht hat. Da geht es dann aber schon über die Stufen. Das ist eindeutig zu lange. Auf den Lichtschalter drücken dauert 100ms. ;-) >Dann muss man aber anfangen, sich über Kollisionserkennung Gedanken zu >machen. Jep. Ist aber sehr stromsparend, weil zu 99,99% nix übertragen wird. >Ich denke darüber nach, dass evtl. mit 1-Wire zu realisieren, bei dem es >einen Alarm-Befehl gibt. Der muss zwar gepollt werden, aber evtl geht >das doch. Allerdings habe ich derzeit Probleme mit der Drahtlänge. >Theoretisch sollte es gehen, in der Praxis habe ich allerdings Ausfälle >im Stundenbereich, danach geht es dann plötzlich wieder. Da würde ich lieber RS485 nehmen. Soviel "Luxus" muss sein. Und wenn sowieso gepollt werden muss, tus auch jede andere einfache Schaltung. MfG Falk
Ja, Stromsparen ist ein Thema. Die ATMega kriegt man aus dem Powerdown raus mit einem Int1 interrupt. Dh man koennte den Rx auch noch auf den Interrupt legen und ein dummy byte vorher senden, damit er aufwacht. Synchron mit 1 Hz ist natuerlich nicht mehr sehr stromsparend. Vielleicht waere ein Protokol doch nicht so schlecht. Dann koennte man allenfalls Asynchron fahren. Waehrend irgendwelche Heizungsdaten im Heizungsrechner gepuffert werden koennen und dann alle 5min einen Block ergeben, sollte ein Licht schneller sein. Die Frage ist weshalb ein Lichtschalter immer auf den Bus muss. Kann der nicht das licht lokal einschalten ?
@ Rene >Synchron mit 1 Hz ist natuerlich nicht mehr sehr stromsparend. Was soll "synchron mit 1 Hz" ?? ASYNCHRON! Wenn ein Taster betätigt wird, weckt das den entsprechenden uC. Moin, moin. Der schickt eine Meldung an den ebenfalls noch schlafenden Aktor (Relais für Lich). Der wird auch per Interrupt geweckt, empfängt die Meldung, schaltet das (bistabile) Relais und geht wieder schlafen. Das Ganze dauert keine 10ms. Und nur einmal, wenn einer auf nen Taster drückt. >Vielleicht waere ein Protokol doch nicht so schlecht. Dann koennte man Es ist auf einem Bus unumgänglich. Die Frage ist eben halt nur, ob Single Master (einfach zu programmieren, jedoch sind dann Poll-Zyklen notwenig) oder Multimaster (Schwieriger zu programmieren, allerdings dann ereignisgesuerte Datenübertragung möglich). >ergeben, sollte ein Licht schneller sein. Die Frage ist weshalb ein >Lichtschalter immer auf den Bus muss. Weil das Thema des Forums "Hausbus" lautet? > Kann der nicht das licht lokal einschalten ? Dann hab ich ja wieder "old school" Verkabelung. Das bringt nix, wenn gleich es seinen Zweck auch erfüllt. MFG Falk
"Da würde ich lieber RS485 nehmen. Soviel "Luxus" muss sein." Naja, RS485 bringt aber in Richtung Kollisionserkennung auch nichts. "Die ATMega kriegt man aus dem Powerdown raus mit einem Int1 interrupt. Dh man koennte den Rx auch noch auf den Interrupt legen und ein dummy byte vorher senden, damit er aufwacht. Synchron mit 1 Hz ist natuerlich nicht mehr sehr stromsparend." Ja, und wenn zwei Teilnehmer gleichzeitig wach werden, knallt es. Ist für den WAF verheerend. "Die Frage ist weshalb ein Lichtschalter immer auf den Bus muss. Kann der nicht das licht lokal einschalten ?" Ich setze den Bus hier nicht nur aus Spass ein. Denn der schaltet das Licht nicht nur an der Haustür an, sondern auch an der Auffahrt. Das war eigentlich der ursprüngliche Ansatz, dass ich am Gartentor und an der Tür mehrere Lichtquellen schalten können wollte, ohne endlos 220V Leitungen neu zu verlegen. Wobei die beim weggehen über einen Zeitschalter auch wieder ausgehen sollen. Gruss Axel
@Falk, der urspruengliche Poster wollte den bus synchron (zur Zeit) mit 1 Miunte takten. Dann kamst Du und wolltest auf 1-10Hz erhoehen. Das heisst dann der ganze Bus wird mit 1-10Hz mit Nachrichten versorgt. Da ist natuerlich wenig mit Powersave. Dort benoetigt ein Mega32 6 oder 65ms zum Aufwachen. Daher mein Vorschlag, keinen getakteten bus zu verwenden. Wenn's nichts zum Mitteilen gibt, kan man das auch sein lassen. Irgendwelche Loggerfunktionen koennen gepuffert werden und nur selten senden. Du nennst das Multimaster & Event gesteuert. Das sollte man nehmen. Zudem scheint mir das Licht muesse nicht von einem zentralen Controller angeschaultet werden. Wenn der steht bleibt's dunkel. Lokal ist besser. Eine Cpu pro Zimmer oder zwei. Nein ?
@Axel >>"Da würde ich lieber RS485 nehmen. Soviel "Luxus" muss sein." >Naja, RS485 bringt aber in Richtung Kollisionserkennung auch nichts. Nein, da muss man sich schon per Protokoll drum kümmern. Oder CAN, da macht es der Tranceiver. >Ja, und wenn zwei Teilnehmer gleichzeitig wach werden, knallt es. Ist >für den WAF verheerend. So schnell bricht die Welt nicht zusammen. Ethernet läuft mit Kollisionserkenung sein Jahrzehnten! Klar, das Protokoll muss da schon mitspielen, aber das ist ja wohl implizit. MFG Falk
@Axel, Doch, RS485 kann zuruecklesen. Es unterstuetzt die Kollisionserkennung. Ein lokaler Prozessor kann auch einen Einschaltbefehl von anderswo bekommen, zusaetzlich zu um lokalen Schalter. Rene
Falk: "So schnell bricht die Welt nicht zusammen." Sooo ? Hast Du eine Ahnung, was los ist, wenn die beste Ehefrau von allen im Dunkeln steht, weil ich auf das Kollisionshandling verzichtet habe ? Da brechen noch ganz andere Dinge :-) Letztlich kommt man um ein Protokoll nicht drumherum. Das war jetzt nicht impliziz in dieser Diskussion. Ob die Transceiver Kollisionen verkraften ist dabei eigentlich sekundär. Und letztlich ist CAN oder 1-wire an der Stelle fast identisch. Und RS485 ist mir zu exotisch. Bräuchte man Treiber für, während ich bei 1-wire einfach einen Eingang eines Micros nehmen kann. Gruss Axel
@Axel >>"So schnell bricht die Welt nicht zusammen." >Sooo ? Hast Du eine Ahnung, was los ist, wenn die beste Ehefrau von >allen im Dunkeln steht, weil ich auf das Kollisionshandling verzichtet >habe ? Da brechen noch ganz andere Dinge :-) Marmor, Stein und Eisen bricht . . . ;-) >Letztlich kommt man um ein Protokoll nicht drumherum. Das war jetzt >nicht impliziz in dieser Diskussion. Ob die Transceiver Kollisionen >verkraften ist dabei eigentlich sekundär. ??? Bei einem BUS braucht man immer implizit ein Protokoll. Es sei denn wu willst kilometerweise Kabel von jedem Sensor/Aktor zur Zentrale ziehen. >Und letztlich ist CAN oder 1-wire an der Stelle fast identisch. Uhhh, na das ist aber mal eingewages Statement. Nur weil beide mit dominatem und rezessivem Pegel arbeiten .. . Gewagt. >Und RS485 ist mir zu exotisch. Bräuchte man Treiber für, während ich bei >1-wire einfach einen Eingang eines Micros nehmen kann. Wenn das mal nicht zu Kollisionen der unheimlichen Art führt. Ob der Scheidungsrichter "Geiz ist Geil" versteht? ;-) MFG Falk
Ich bin ja sehr fürs Energiesparen beim Hausbus, aber findet Ihr nicht, dass Powermodi > Idle etwas oversized sind? Viel sinnvoller ist es meiner Meinung nach, * die VCC des Controllers zu minimieren: 3.0 oder 3.3V (hat übrigens den Vorteil, dass viele modernen Graphik-LCD direkt angeschlossen werden können). * die Clock des Controllers zu minimieren. 1Mhz ist ausreichend für die skizzierten Aufgaben. Ein ATmega32 kommt im Idle mit 1Mhz und 3,0V auf 0,3mA. Das sind 0,9mW. Mit einem Linearregler und Up = 12V kommt man auf 3,6mW. Bevor hier weiter optimiert ist, sollte man sich besser das Hausbus-Netzteil ansehen und die weiteren Verbraucher. Z.B. die verwendeten Relais, wenn diese längere Einschaltzeiten haben. Gruß, Stefan
@Stefan Kleinwort >Ich bin ja sehr fürs Energiesparen beim Hausbus, aber findet Ihr nicht, >dass Powermodi > Idle etwas oversized sind? Viel sinnvoller ist es >meiner Meinung nach, >Ein ATmega32 kommt im Idle mit 1Mhz und 3,0V auf 0,3mA. Das sind 0,9mW. >Mit einem Linearregler und Up = 12V kommt man auf 3,6mW. Guter Punkt. Macht selbst bei 100 Slaves gerademal 360mW. Ein Billignetzteil verbraucht im Leerlauf ein Vielfaches! Da kann man auch mit 10 Hz pollen. MfG Falk
Das 1-wire direkt auf den Prozessor kannst du vergessen. Ein Bus benoetigt Treiber und Terminierungswiderstaende, die koennen allerdings AC sein. Sollte die Speisung nicht eine Batterie anstelle eines Billigstnetzteils sein?
@Axel: Wenn Dir Deine Ehefrau lieb ist, dann lass den 1-wire. Klar baust Du damit einen Bus, der erstmal funktioniert. Ein normaler Portpin ist aber wesentlich empfindlicher als ein Treiber-Pin. Es kann Dir passieren, dass der KOMPLETTE Bus bei einer ESD-Störung ausfällt. Das ist dann nicht nur teuer, Du musst auch Dein komplettes Haus wieder auseinandernehmen (ok, alle Stellen, wo Deine Elektronik verbaut ist). Dazu kann ein Blitz im weiteren Umkreis reichen. Die meisten Treiber haben eine ESD-Protection zwischen 10kV und 30kV, such mal im ATmega-Datenblatt nach ESD, damit Du vergleichen kannst ;-) Ein RS485-Treiber kostet zwischen 0,50 und 1,00€ für Hobbylöter, den Preis macht er allemal wett. Für einen CAN-Bus brauchst Du zusätzlich zum Treiber noch z.B. den MCP2515 und hast dann keine Probleme mehr mit Kollisionen etc. (ich weiss, die sind lösbar. Das Ding kostet 2,50€, dafür sparst Du Dir viel Zeit beim Protokoll. So habe ich es gemacht und es noch nicht bereut. Viele Grüße, Stefan
Das mit der ESD ist mir auch klar. Allerdings gelten die 2 kV, die da vermutlich stehen werden, auch direkt ohne Platine etc. Bisher hatte ich jedenfalls an der Stelle keine Probleme. Vorteil bei 1-Wire ist, dass ich grösstenteils Temperaturen abfrage, und das geht mit den 1-Wire Bausteinen ohne weitere Beschaltung. Dazu kommen dann noch ein paar Micros als 1-wire slaves, die einige Sonderfunktionen übernehmen. Derzeit habe ich da eine invers angeschlossene Schottky Diode und einen Abschlusswiderstand dran, die die ESD Festigkeit auch erhöhen. Alles mit zusätzlichen Transceivern würde eine aufwendige Platine erfordern. Seitdem ich das vor ein paar Wochen umstrukturiert habe, läuft der 1-wire Bus denn auch ganz gut. Aber ich gebe zu: für ein Kundenprojekt würde ich das nicht einsetzen. Und die wesentlichen Schaltungen wie Haustür/Licht werden direkt, ohne Bus geschaltet (was allerdings historische Gründe hat, war damals die erste Aktion in Richtung Hausautomatisierung). Gruss Axel
Hi, @Blackbird: > sondern auch Netzspannungen und -ströme melden > (Waschmaschine, Trockner, ...) Mich würde interessieren, wie du die Netzströme misst. Das ist ja ne Sache die für nen Hausbus generell interessant sein könnte =) Kannst ja vllt per Mail schreiben damit das hier nicht zu OT wird (oder neuen Thread aufmachen, werd ich schon bemerken wenn es im Hausbus-Forum hier ist ;) ). Gruß, Chris
"Mich würde interessieren, wie du die Netzströme misst." Mich auch. Gruss Axel
Hallo nochmal, wow, das Thema läuft ja irgendwie aus dem Ruder. Um nochmal die Übertragung klarzustellen : Die Sensoren senden Ihre Daten im 1 Minuten Takt, das langt vollkommen. Wenn ich aber z.B.: einen Tast- oder Schaltsignal weitergeben will, dann sendet dieser Sensor (nennen wir den Schalter mal so) natürlich sofort auf den Bus sein "Protokoll" Da ich ja ganau definieren kann, wann die -Umweltsensoren senden, teile ich jedem "Schalter" ein Fenster zu, inden er senden kann. Im ungünstigtenen Fall, kann der Schalter erst nach 2 Sekunden senden. Das ist zwar eine "relativ" lange Zeit für einen Prozessor, aber soviel Zeit muss sein. Außerdem lege ich normale Lichtschalter nicht mit auf den Bus ( halte ich für unnötig, und zuviel Aufwand) - bitte keine Diskussionen um diesen Punkt. Ich verwende natürlich auch sowas wie ein Pseudoprotokoll, um Befehle auf dem Bus als gültig oder nicht gültig zu definieren. Ich sende immer 16 Bit, wobei das 1te und das 16te überprüft wird, außerdem überprüfe ich ob die Sender bzw. Empfängeradressen gültig sind. Beispiel: !3099xxxxxxxxxx9 Das ! am Anfang und die 9 am Ende sind meine Prüfzeichen. Wenn die richtig sind, überprüfe ich noch die Sendeadresse ; hier die 30 und die Empfängeradresse ; hier die 99 für alle. Wenn diese "Eckdaten" stimmen, dann werden die daten, die in xxxx stehen ausgewertet. Gruß
Damit keine falschen Hoffnungen aufkommen: ich schrieb von "Strom MELDEN" nicht "messen"! Hab' mir 2 verschiedene Arten von Meldern aufgebaut: einen mit einem selbstgewickelten Strom-Reed-Relais (spricht bei ca. 50 mA an und ist bis 2kW belastbar), einen mit antiparallel geschalteten Dioden und Optokoppler (wenige mA und kann nur ca. 600W ab). Alles ordentlich mit Isolation (beim Wickeln und auf der Leiterplatte) und in einer Doppel-UP-Dose (weil Niederspannung und Netzspannung dürfen nicht in der gleichen Verteilerdose liegen). Die 3. Art von Strom-Melder habe ich gerade im Test. Es ist eine Variante von den vielen elektor-Schaltungs(-Ideen), die Master-Slave-Steckdosen betreffen. Mit einem Widerstand, OV, Optokoppler usw. Auch hier ist eine strikte Trennung Kleinspannung-Netzspannung zu beachten. Die (mechanische) Umsetzung der Schaltung wird bei allen Schaltungsvorschlägen das Hauptproblem sein. Deshalb möchte ich auch nicht die Schaltungen hier posten - sie suggerieren eine simple Lösung. Sind sie aber aber nicht! @hellraider, und auch mir, geht es vor allem darum zu überwachen und zu protokollieren, die eine oder andere Schaltaufgabe noch zusätzlich zu haben. Was @Falk und @Axel wollen ist aber schon eine richtige Steuerung, so SPS-mäßig, jedoch dezentral und stromsparend. Blackbird
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.