Hallo, ich habe vor, unsere Hauselektrik mit einem Hausbus zu steuern. Ich bin mir nur nicht sicher, welches Bussystem ich verwenden soll. Im Augenblick habe ich mir EIB, CAN und RS485 näher angeschaut und mal die Vor- und Nachteile zusammengefasst: EIB + nur 2 Leitungen für Daten, Power und GND + kein Abschluss-R nötig, alle Bustopologien - Chips nur schwer erhältlich und teuer CAN + Protokoll bereits im Chip O Preis ist ausgewogen - es werden 2 Leitungen Daten + Power + GND benötigt - Abzweigungen vom Bus sind problematisch (max. 1m?) - abschluss-R notwendig RS485 + Preis ist spottbillig O Protokoll muss angepasst werden (ander Bsp. vorhanden) - es werden 2 Leitungen Daten + Power + GND benötigt - Abzweige vom Bus (Baum) sind problematisch - Abschluss-R notwendig Kennt jemand noch andere Systeme, die infrage kommen würden? Was ich besonders schön fände, wenn nur eine 2-adrige Leitung verwendet wird. Die Zerstörungsfestigkeit gegenüber induzierten Spannungen etc. (Blitzschlag) steht natürlich auch ganz oben. Kennt jemand Open-Hardware-Projekte in der Richtung? Alles, was ich bis jetzt gefunden habe, scheint den Schreibtisch noch nicht so recht verlassen zu haben. Haben auch andere an sowas Interesse? Viele Grüße, Stefan
Wie siehts aus mit einem I2C-Bus? Der benötigt soviel ich weiss nur 2 Leitungen, allerdings kann ich nicht sagen, ob er sich für Deine Applikation sonst eignet. Mfg Malve
Hallo Stefan, schau Dir mal bitte Powernet an. Das funktioniert über die normale Stromleitung, d.h. keine zusätzlichen Adern. Allerdings sind die dazu passenden Module relativ teuer und Du mußt die Dei Phasen koppeln. Ich hab dasSystem bisher nur in der theorie gesehen. Soll vom Aufbau der RS485 ähneln. Google mal, vielleicht gibts da noch irgendwo bessere Info's, als den spärlichen Kram, den ich hier habe. Gruß Marcus
Was heißt bei dir Elektrik steuern? Licht an/aus, Rolladen hoch/runter??? In diesem Fall kannst du schon CAN-Bus nehmen, den Saft holst du dir dann jedesmal vom Netz. (Sollte ja eigentlich an jedem Knotenpunkt vorhanden sein, da da ja was gesteuert werden soll.) CAN dürfte auch das einfachste sein, da du dich um fast nichts kümmern brauchst. Die CAN-Bausteine (z.B. SJA1000) übernehmen die komplette Arbeit, der Controller braucht im Prinzip nur noch Daten lesen oder schreiben. Du könntest auch ne kombinierte Bustopologie einsetzen. CAN bis zu den Knotenpunkten, und von den Knotenpunkten zum Anwendungspunkt mit RS232 oder ähnlichem. Auf dieser Seite unter Links sollte irgendwo bei den AVR ein Link auf ne schöne Site sein, die sehr gut nen Aufbau solch eines Homebusses mit CAN beschreibt.
@Malve: IIC ist für Busanwendungen etwas zu störanfällig, eigendlich ist IIC nur als interner Gerätebus gedacht und für kleine Entfernungen. Es werden ja auch keine Treiber verwendet, die die Elektronik vor Spikes etc. schützen können. @Marcus: Powernet habe ich mir schon angeschaut, aber was mich daran stört, ist eben die direkte Kopplung mit dem Netz. Eigendlich brauche ich die Netzspannung an den meisten Punkten ja garnicht, Lichtschalter, Sensoren kommen ohne aus, und die Leistung wird im Schaltschrank geschaltet und geht direkt an die Verbraucher. Deshalb ist Powernet mir zu teuer und auch zu gefährlcih (Netzspg nur da wo ich sie unbedingt brauche). @Erdi-Soft: Genau das und etwas mehr, aber alles im niedrigen Datenmengen-Bereich:, Licht an/aus, Jalousie, Raum-Thermostat, Raumheizungsventile, Dimmer, Sensor Fenster auf/zu ... und was mir später noch alles so einfällt. Du meinst sicher den Link canathome.de? Genau der sieht so aus, als ob er noch nie den Schreibtisch verlassen hätte ... Mein Ziel ist eigendlich, einen Bus einzusetzen, dessen Teilnehmer so günstig herzustellen sind, dass ich auch einen richtigen Bus aufbauen kann (der auch zu finanzieren ist). D.h. an jedem Taster, Sensor etc. steckt ein eigener intelligenter Busknoten. Bei EIB sind einzelnen Busknoten so teuer, dass in der Praxis kein richtiger Bus gebaut wird, sondern an einzelnen Stellen zentrale Busknoten platziert werden, zu denen dann die Eingangssignale hinverkabelt werden. Der CAN-Bus ist ja schon unter den Favoriten. Nur die eingeschränkte Topologie schreckt mich etwas ab. Die Stromversorgung soll für den Bus zentral vom Schaltschrank aus erfolgen, weil ich bei (fast) allen Busanschlüssen keinen Stromanschluss habe und brauche. @Michael: Danke für die Links. Den unteren kannte ich noch nicht, da ist interessant, dass für den AVR der CAN-Bus in Software emuliert wird. Das macht das Ganze natürlich sehr interessant, weil preiswert. Und jetzt weiss ich auch endlich, was Programmierstecker auf italienisch heisst :-)) Viele Grüße, Stefan
fällt mir noch der Bus a la digitale Modellbahn ein, relativ simpel, nur 2 Adern, allerdings kein direkter Rückkanal. Baum, Ring, Stern, auch gemischt sind kein Problem. Datenrate ist relativ niedrig, aber das sollte ja kein Problem sein.
sagt dir der ASI bus von Siemens etwas? der benötigt nur +24V und GND. Auf den 24V werden dann die Datensignale aufmoduliert, der Bus Funktioniert bidirektional. google doch ein wenig, habe mal tolle knowhow-sites darüber gelesen.
Nimm doch einfach 4 Drähte (GND, +24V, CANL, CANH). Die CAN-Treiber (PCA82C250) vertragen bis 5V Spannungsverschiebung. D.h. selbst wenn auf dem GND-Draht 5V abfallen, ist immer noch eine einwandfreie Detenübertragung gewärleistet. Wenns aber unbedingt nur 2 Drähte sein sollen, wäre der Meterbus eine Möglichkeit: http://www.nzr.de/all-mbus.pdf Die Übertragung erfolgt vom Master durch Spannungsabsenkung (24V/12V) und vom Slave durch Stromerhöhung, ist also Voll-Duplex. Peter
Hallo Hausbusfreaks, wie Peter schon sagt, "GND +24V CANL CANH". Die Knoten werden mit billiger Telefonleitung versorgt. Ein Can-Treiber z.B.PCA82C251 (1,20) ein Mega8 und ein wenig "Hühnerfutter"; das Knotenbasismodul steht. Aktormodul mit Relaise und Sensormodul mit Tastern, Thermometer usw. ausstatten. Protokoll ausdenken. Programmieren. 1 Jahr Fehler beseitigen. Schon läuft das Haus vollautomatisch. Anschließend EasyToWeb-Server kaufen und von der Arbeit aus das Haus beobachten. Bis auf den Webserver hat das alles den Schreibtisch bereits verlassen... Also Mut und ran. Sollte das passende Haus noch gebaut werden Leerrohre nicht vergessen. Bernhard
Wenn sowieso ein Schaltschrank vorhanden ist, kann mans auch zentral machen und auf Bus verzichten (ausgenommen einen Schaltschrankinternen). Die Erweiterungsmöglichkeiten sind halt nicht so prall, aber ich habe diese Methode benutzt und man ändert bei weitem nicht mehr so viel an der Grundinstallation, wie man zunächst annimmt. Die Frage ist, ob ein Lichtschalter überhaupt "Intelligenz" braucht oder ob es nicht reicht, eine 2-adrige Niedervoltleitung in den Schaltschrank zu legen. Natürlich ist ein Bus eleganter - aber auch teurer, und wenn mal ein Knoten verrückt spielt, kann man sich im ungünstigsten Fall einen Wolf suchen, bis man das faule Glied gefunden hat. Auch eine nette Sache: IR-Fernbedienung von Licht und Steckdosen. IR habe ich deshalb verwendet, weil dann jeder Raum seine eigene Belegung auf der Fernbedienung haben kann - bei Funk würden schnell die Tasten ausgehen, weil man Raumübergreifend ansteuern würde. Die Powerline-Übertragung ist dann sinnvoll, wenn die Installation bereits besteht und man nur schlecht Steuerleitungen zusätzlich verlegen kann. Ich benutze hierfür den TDA5051, der manierlich funktioniert und habe gute Erfahrungen damit gemacht. Man sollte es auch nicht übertreiben mit den Spezifikationen, man braucht sicherlich keine Übertragungsraten im mehrere 10 Kbit-Bereich, denn wie oft wird schon ein Lichtschalter geschaltet? In meiner Steuerung arbeite ich mit einem festen Zeitraster von 1/10 Sekunde, dies ist die Verzögerung von Lichtschalter drücken bis Licht an - nach anfänglichen Bedenken fällt das garnicht auf, wenn mans nicht weiß. Bei einer totalen Neuinstallation einer Wohnung würde ich die Verwendung von Leerrohren empfehlen. Die Kosten sind zwar höher, aber ich habe es nicht bereut - es fängt schon an mit einer "vergessenen" TV-Leitung bis hin zu zukünftigen Glasfaserleitungen fürs Internet.
> canathome.de? Genau der sieht so aus, als ob er noch nie den
Schreibtisch verlassen hätte ...
Hm, da hab ich aber anderes gehört. ;)
Die Webseite ist zwar nicht auf dem aktuellsten Stand, dennoch
funktioniert die Hardware seit ca.2 Jahren in eingebauten Zustand
fehlerfrei (bis auf das 8515-Eeprom-Brownoutproblem).
Den SAE81C90/91 würde ich zwar nicht mehr empfehlen, da nicht/schlecht
lieferbar, dafür einen µC mit integriertem CAN einsetzen. Ich bastle
gerade für die nächste Version an Motorola HCS12. Das soll dann in
einem Neubau eingebaut werden und dort "alles" steuern.
Zu deinem Topologieproblem:
Wenn du 8pol. CAT5-Kabel zur Vernetzung einsetzt, kannst du (neben
Versorgungsspannung) auch CANL/CANH mit 2 Adern hin und mit 2 Adern
wieder zurückführen. Der letzte Knoten in der Kette brückt den CAN-Bus
wieder zurück - damit entstehen keine Stichleitungen. So kannst du
geometrisch auch einen Baum aufbauen, der logisch eine Linie ist...
Tschüß,
André.
Servus, @ulrich: ASI Bus ist zwar schon irgendwie klasse, aber nicht so wirklich trivial, und meines wissens sind die Komponenten nicht wirklich billig, ausserdem ist das doch meher zur Ueberwachung gedacht, oder.... CAN mit wenig laengeren Stichleitungen sollte funktionieren, wenn es nicht zu viele werden, sonst werden es etwas viele Abschlusswiderstaende. Wenn die Baudrate niedrig ist, sollte man auch bei mittleren Stichleitungslaengen auf Abschlusswiderstaende verzichten koennen.
Es zwingt einen ja keiner, den CAN immer mit 1MBit zu fahren und z.B. bei 10kBit sieht alles schon viel unkritischer aus. Mann könnte auch, wie bei Modems mit kleiner Bitrate anfangen und dann testen, wie hoch man ohne Fehler kommt. Die CAN-Controller haben ja interne Errorcounter, mit denen man gut die Qualität der Übertragung ermitteln kann. Kostenmäßig ist ein T89C51CC01 + PCA80C251 auch nicht teurer als ein guter Lichtschalter (20Euro). Der PCA80C251 kann bis 40V ab, wenn man mal beim Installieren die +24V mit CANL oder CANH vertauscht, passiert also nichts. Peter
Von Microchip gibt es auch CAN-Controller, die sich per SPI an den Atmel anklemmen lassen - für die, die bei ihrem AVR bleiben wollen. Die ältere Version gibt es bei Segor für ca. 6 Euro. Ausserdem hat Microchip noch CAN-I/O-Expander, die standalone laufen und I/O, A/D, sowie PWM-Ports bieten und gar keinen Controller mehr brauchen. Besonders ideal für solche Sachen wie Lichtschalter, Sensoren, etc.
Erstmal danke für die vielen Antworten. Da komme ich ja fast nicht mehr nach mit lesen und Links anschauen :-)) Also erstmal die Baudrate - da habe ich auch an ca. 10kbit gedacht. Ist für einen Hausbus sicher voll ausreichend, wenn man mal Video auf dem Lichtschalter-Display schauen will, kann man immer noch aufrüsten ;-) So wie es aussieht, plädiert ja eine überwältigende Mehrheit für den CAN-Bus? Bis jetzt war ich ja eher RS485-Fan, weil ich es von DMX noch in guter Erinnerung habe. Aber nachdem es für CAN sogar eine Software-Emulation gibt und RS485 von der Topologie auch nicht besser ist, bin ich bereits am Umdenken. Welcher Controller am Schluss eingesetzt wird, kann ja noch entschieden werden. ATmega8 mit CAN-Emulation könnte ich halt über die Arbeit sehr günstig bekommen (aber nur im Ultra-Mini-Gehäuse). Wichtig ist für mich, dass kein externer Baustein verwendet wird, also im mc integriertes CAN oder Software-Emu. Ich werde mir mal die vorgeschlagene CAN-Controller ansehen. Der ASI-Bus sieht recht interessant aus, allerdings erlaubt er keine variablen Daten, sondern überträgt nur digitale und analoge Zustände. Das wäre zwar bei den meisten Haus-Anwendungen ausreichend, aber um z.B. Text auf ein Info-Display zu bekommen, wären schon Klimmzüge notwendig. Und leider ist er nicht Multi-Master-fähig. Was aber extrem genial ist, ist die supereinfache Kabelanklemmung. Einfach durch die Isolierung anklemmen und verpolsicher durch asymetrische Kabel-Außenform - da haben sich die Entwickler wirklich was gedacht. Meine Überlegungen gehen mittlerweile in folgedne Richtung: Als Bus CAN verwenden. Den Bus nach Möglichkeit geradelinig ausführen. Wo das nicht geht, kann ev. ein Dual-CAN-Controller eine Abzweigung realisieren. Die Baudrate wird erstmal mit 10kbit angenommen. Die Intelligenz dezentral verteilen, d.h. die Kommunikation läuft nicht über eine zentrale Schaltstelle, sondern z.B. ein Lichtschalter kommuniziert mit seinem Aktor direkt. Damit fällt nicht das gesamte System aus, wenn die Zentrale hinüber (oder abgestürzt ...) ist. Beim Software-Protokoll werde ich mir mal Caraca und CANatHome genauer anschauen und nach Möglichkeit mit einem der beiden kompatibel bleiben. Die Aktoren will ich nicht bis auf 220V-Ebene selberbauen, sondern Schaltschrank-Relais oder Dimmer (0..10V) ansteuern. Die gibt es so günstig, dss sich Selbstbau sicher nicht lohnt, und es gibt auch weniger Probleme mit dem Elektriker, wenn Bus und Netz voneinander getrennt gehalten werden. Viele Grüße, Stefan
@thkais Du hast nicht unbedingt unrecht, dass eine zentrale Steuerung auch einige gute Seiten hat. Wenn ich aber überlege, dass in einem Reihenhaus im Normalfall mindestens 3 Etagen zu überwinden sind, dann stellt sich die Frage, wieviel Leitungen Du verlegen willst. Ein großer Vorteil eines Hausbusses liegt doch in der Tatsache, dass ich mit verteilter Intelligenz Leitungen spare. Mir kostet ein Schaltermodul incl. professioneller Platinen, Bauteilen usw. 18,50 Euro. Damit kann man 10 Sensoren ( davon bis 4 analoge Eingänge ) in den Bus einspeisen. Desweiteren nimmt das Modul die IR-Signale meiner Fernbedienung auf. Dafür lege ich ein 4 adriges Telefonkabel zum Sicherungskasten und nicht mehr. Eine Raumtemperatur erfasse ich z.B. mit einem Spannungsteiler aus einem temperaturabhängien Widerstand. Da die Busgeschwindigkeit mit 10 KBit sehr niedrig ist und die meisten Events keine Daten transportieren müssen, liegt die Übertragungszeit bei ca. 6 ms und die maximale Leitungslänge weit über 1000m. Auch eine Sternverdrahtung mit Abschlußwiderständen im Mittelpunkt führen zu keinen Problemen. Highlight (m)eines Busses ist aber eindeutig die Flexibilität und Erweiterbarkeit. Bernhard
Sicher gibt es Vor- und Nachteile. In meinem speziellen Fall habe ich die zentrale Steuerung verwendet (auch weil ichs nicht besser wußte, ist jetzt an die 5 Jahre her). Ich habe auch niemals die Vorteile des Bussystems bezweifelt, das ist jetzt vielleicht etwas schlecht herübergekommen. Erweiterungen, die nun garnicht mehr bei mir reinpassen, habe ich mit dem Powerline-Bus gemacht. Wenn ichs nochmal machen müßte, würde ich wahrscheinlich auch eher zum CAN hintendieren, aber: Don't touch running systems. Bis jetzt 1 Ausfall, und der war aus eigener Schuld, weil ich die Prüfsumme des EPROM nicht aktualisiert hatte - nach einem Stromausfall wurde die überprüft, und das System startete aus Sicherheitsgründen nicht mehr.
Hallo, um die Diskusion zu erweitern, was haltet Ihr vom LIN-Bus? Dieser wird auch immer wieder mit CAN verglichen. Der ist fürs Auto als zukünftiger Standard gedacht un wird somit hoffentlich (?) billig. Mal zu googeln lohnt (?) sich ???? MfG Achim
@Achim: Hast Du das jetzt nur durch Zufall gelesen? LIN ist für die Haussteuerung völlig unbrauchbar. Das ist ein unsymmetrischer Bus in Multidroptechnologie mit bis zu 16 Knotenpunkten. Gedacht für preisgünstige KFZ-Anwendungen bei niedrigen Datenraten, sprich Knöppe und Hebel. Und nur Legastheniker vergleichen das mit dem CAN. Denn das ist nämlich völlig unabhängig vom CAN und erstzt das nur in den genannten Köppen-Anwendungen. Für etwas anderes taugt das nicht. Im KFZ werden deshalb CAN-LIN-Gateways ihren Dienst tun, um zwischen dem lahmen LIN und den schnellen Steuerungen zu vermitteln. Hättest Du aber bei Deinem googlen selber rausfinden können...
Hallo, hab nicht alle Beiträge gelesen, aber trozdem noch ein tipp: in der Fabrikautomation wird häufig AS-Interface verwendet. Im Protokoll sind 4 datenbits enthalten (sollten nach meiner Vorstellungskraft für Haustechnik ausreichen). ASi kommt auch ohne Abschlusswiderstand aus und hat nur zwei Leitungen. Max. leitungslänge beträgt 100m. die Leitungslänge kann theoretisch erhöht werden wenn trotzdem Abschlusswiderstände verwendet werden, aber bis 100m laut Spezifikation nicht erforderlich. Besonderes AS-I Netzteil ist erforderlich damit nicht die aufmodulierten Daten von dem zweidrahtsystem durch das innenleben des Netzteils geschluckt werden. Oder ein einfacher Filter (RC) vor ein herkömmliches netzteil bauen. Klappt einwandfrei. Preis keine Ahnung. Gruß Karl-heinz.
@Andre: Da bin ich ja schön ins Fettnäpchen getappt - sorry. Ich bin halt nach den Bildern gegangen und die sehen eben nach Schreibtisch aus - jedenfalls die ersten .. Warum bist Du denn vom Fujitsu-Controller weg und willst jetzt auf den HC12? Aus Bastelwut oder warst Du mit dem Fujitsu nicht zufrieden? Ich habe früher viel mit dem 68HC11 gemacht und war damit eigendlich sehr zufrieden, später hat dann Motorola den Flash-Speicher etwas verschlafen. Aber der HC12 sieht ziemlich gut aus, für den Hausbus eigendlich ideal, kleines Gehäuse, CAN, EEPROM, der Preis scheint sich auch im Rahmen zu bewegen. Taugt denn der gcc-Port dafür was? Mit der CAN-Rückleitung hast Du natürlich Recht. So macht das auch die Implementierung bei Caraca (Sourceforge). Aber dann sind es ja noch mehr Adern. Was hälst Du von einer Abzweigung durch einen 2.CAN-Bus onboard? Ich werde jetzt erstmal das Sotware-Protokoll auf Deiner Seite genauer studieren. Hast Du Dich da an andere Projekte angelehnt? Viele Grüße, Stefan
@Stefan: Die ersten Bilder sind vom Demobrettaufbau... später im Einbauzustand hab ich keine Fotos gemacht. Fujitsu war lange nicht lieferbar (zig Wochen)... ich wurde ewig vom Distri hingehalten - mir reichte es dann. Technisch gesehen ist der Fujitsu ok. AVR hab ich verlassen, da damals der SAE81C90/91 nur schlecht lieferbar war und die Kombination aus µC und ext.CAN-Hardware kostenmäßig nicht soo optimal war, außerdem wollte ich mal ne andere µC-Familie kennenlernen. Den HCS12 setzen wir auch in der Firma ein - d.h. die komplette Toolkette steht mir zur Verfügung. Preislich gesehen geben sich die 3 Lösungen nicht viel. > kleines Gehäuse naja, zu TQFP-112 würde ich das nicht sagen wollen ;) (ok, gibts auch in 80pol.) - zumindest IO-Port-Sorgen gibts damit nicht mehr. Den GCC-Port kenne ich nicht näher. Ich benutze die kostenlose 12k Version des Metrowerks Compilers. > Aber dann sind es ja noch mehr Adern Ja, genau 2 mehr. > Sotware-Protokoll auf Deiner Seite Zur Info: Ich verwende die CanId (entgegen ihrer eigentlichen Intention) als Zieladresse und nicht als Ereignisanzeiger bzw. Absende(r)kennung. Das gibt Probleme, sobald 2 Sender _zeitgleich_ (also innerhalb einer Bitzeit; bei 10kBit/s sind das 100µs) die gleiche CanId auf den Bus schreiben... praktisch stört das sicher nicht - theoretisch aber unsauber. In der neuen Fassung ist alles besser... Update der Webseite kommt vielleicht noch in 2004. > Hast Du Dich da an andere Projekte angelehnt? Bewusst nicht, um zu sehen wie weit man mit eigenen Ideen kommt... Inzwischen sieht die Sache anders aus. Von SoftwareCAN halte ich nix. IMHO kann man das mit "USB in Software" vergleichen - Riesenaufwand mit vielen potentiellen Stolperfallen. Besser gefällt mir die Idee auf RS485 ein eigenes Protokoll aufzusetzen. ASi ist elektrisch gesehen sicher für Hausinstallationen geeignet. Praktisch gibts aber keine Transceiver zu bezahlbaren Preisen (zumindest sind mir keine bekannt). Das Protokoll läßt praktisch nicht zu, damit anderes als nur Relais/Taster zu schalten und Analogwerte zu übertragen - ist auch nicht für mehr gedacht. (Mein letzter Stand ASi v2.1). Man "könnte" auf dieser Hardwarebasis allerdings eigene Protokolle aufsetzen. Für LIN gilt im Prinzip das gleiche wie für ASi - allerdings gibts hier Transceiver zu günstigen Preisen (z.B. TJA1020) - leider nicht bei Reichelt. Diese lassen sich einfach an die UART eines billigen µCs anbinden - eigenes Protokoll und fertig. Beide (ASi und LIN) haben aber den Nachteil nicht als Multimasterbus ausgelegt zu sein - im Gegensatz zum guten alten RS485. Zu den Preisen des nackten µC kommen noch Platine und Gehäuse hinzu - damit fällt die Differenz zwischen ATmega8 und RS485 gegenüber µC mit integr.CAN-Interface nicht mehr so stark ins Gewicht. Gruß, André.
Hallo Stefan, freut mich, dass Du inzwischen intensiver und wohlwollender über den CAN nachdenkst. Kein Wunder eigentlich - bei den vielen Empfehlungen pro CAN in diesem Thread. Ich hatte Dir ja schon vor Wochen vom CAN vorgeschwärmt... Du erinnerst Dich? Es ging dabei (auch) um den ETA-Kessel ;-) So klein ist die Welt, das Internet ist doch ein Dorf... Für andere Interessierte: ETA hat nix mit Spanien zu tun. Eher mit Österreich - zwar mit Feuer, aber nix mit Bomben. Mit Feuer im Heizkessel. Übrigens Stefan: Heute haben bei uns die Bagger die Baugrube ausgehoben. Wenn ich mir das so anschaue, mit wieviel Gefühl die Baggerfahrer mit diesen Riesenmaschinen auf den Zentimeter genau arbeiten... Hut ab bei den vielen Hebeln die sie dabei gleichzeitig zu bedienen haben. Da ist's doch einfacher mit ein paar Interrupts umzugehen... Auch ich werde den CAN als Hausbus einsetzen. Die 10 od. 20 kBit/s sind für diese Anwendung eh schnell genug und bzgl. der Verkabelungsstruktur ist der CAN bei diesen Bitraten nicht so empfindlich. Aufgrund www.canathome.de bin auch ich auf die Fujitsu-Controller aufmerksam geworden. Breite Palette mit CAN. Kostenlose Entwicklungsumgebung. Bisher habe ich nur mal eine "Machbarkeitsstudie" programmiert - funktioniert einwandfrei. Zumindest nachdem ich die meisten meiner SW-Fehler raus habe ;-) viele Grüße Wolfgang
Benutzt ihr separate Leerrohre für den CAN Bus oder kann/darf man diese CAN-Bus Leitungen im selben Leerrohr wie die Licht-Drähte legen ?
@André: Sollte ich mich da verguckt haben oder gibt es den HCS12 nicht auch im 48-Pin-Gehäuse? Auf der Motorola-Seite ist er dann mit 4,70$ angegeben, gut, bei 1000 Stück, ich bräuchte eigendlich 5 weniger. http://www.elektronikladen.de/en_chips12.html Mehr Pins stören doch eigendlich nur beim Löten und brauchen Platz, für die Applikation reicht so ein kleiner doch. Wie debuggst Du den HC12? Der BDM-Anschluss scheint ja ziemlich klasse zu sein, benutzt Du den? @Wolfgang: Willkommen im mc-Forum :-)) Wir sind leider noch nicht so weit wie Ihr, bevor die Bagger kommen, muss das Landratsamt noch eine Unterschrift leisten, scheint wesentlich mehr Arbeit zu sein als so ne popelige Grube ... Mit dem CAN hast Du wohl Recht gehabt. Obwohl ich es <theoretisch> immer noch nur als die zweitbeste Lösung halte. Eigendlich wäre EIB noch besser, aber da mauern mir die Hersteller zuviel. Ich schaue mich gerade bei den CAN-MCs um. Der HCS12 sieht ziemlich gut aus, oder der Mitsubishi M16C, mit dem habe ich schon etwas gearbeitet, wenn auch nicht mit CAN. Und der HCS12 ist ja sehr verwandt mit dem HC11, den habe ich früher benutzt. Der Fujitsu kommt eher weniger infrage, ich will mich einfach nicht mit nochmal einer neuen CPU beschäftigen. Viele Grüße, Stefan
@Peter: Ich habe vor, den Bus komplett separat von der Netz-Elektrik aufzubauen und nur im Schaltschrank die Relais anzusteuern. Ich würde mir zwar zutrauen, auch die Starkstromseite zu bauen, aber den Schaltschrank muss ja immer ein Elektriker abnehmen. Und billiger als die normalen Schaltschrank-Relais geht es sicher nicht selber zu bauen, nur diese Bus-Technik ist eben so schw..-teuer. Viele Grüße, Stefan
@Stefan Also von diesem zentralen Schaltschrank werden Lampen, Rolladen etc mittels Relais geschaltet. Dazu braucht es sternförmig Leitungen in jedes Zimmer. Hast Du den noch Lichtschalter in den Zimmer oder werden die Zimmer Lampen über separate Taster via CAN geschaltet ?
@Peter: Ich habe keine Schalter mehr am 220V-Netz, wenn Du das meinst. Die Schalter bzw. Taster der einzelnen Zimmer gehen über den Bus zum Schaltschrank. Dort steuern sie dann den zugehörigen Aktor an, der das entsprechende Relais schaltet. Die Kommunikation zwischen intelligentem Schalter und Aktor läuft dabei direkt, nicht über einen zentralen Master. Wenn der Bus beschädigt wird oder das Netzteil ausfällt, dann ist natürlich erstmal Schicht im Schacht. Also zumindest die Lampe im Technikraum wird per normalem Schalter betätigt! An den Aktoren sehe ich vielleicht noch manuelle Schalter vor, zumindest für manche Signale. DIL-Schalter würden ja schon reichen, als Notnagel. Dieser Zentralismus der Netzleitungen gefällt mir eigendlich auch nicht, scheint aber überall so gemacht zu werden, wenn ein Bus eingesetzt wird. Viele Grüße, Stefan
Ich lese hier nur "Mitsubishi" und "Fujitsu", warum denn nicht den Atmel T89C51CC01 ? Ich nehme den sehr gerne. Den kann man direkt einlöten und erst in der kompletten Schaltung programmieren oder updaten. Den mit CAN-Bootloader sogar über den CAN-Bus. Weg mit dem extra Programmierstecker, bequemer gehts nun wirklich nicht. Er ist auch im schönen PLCC-44 lieferbar, d.h. man kann ihn bequem in einen Sockel auf stinknormale Rasterplatinen einsetzen. Ist also nicht nur was für Platinenprofis, die können dann die BGA oder VQFP Version nehmen. Peter
Ich lese auch "Motorola" ;) Aber Peter hat schon recht, die Atmels sind was Feines. Und wenn es etwas mehr sein muss, dann halt den CC03 oder bei kleinerem Bedarf den CC02. Und wie ich oben schon schrieb, die Microchip-Teile funktionieren auch ohne Controller und somit ohne Programmierung, besonders ideal für einfache Sachen wie Schalterbedienung, Sensoren, Aktoren. Das spart nicht nur Zeit, sondern auch den Stress für die Fehlersuche in solch einem verteilten System.
Hallo, willst du die Hardware selber bauen oder auf was fertiges setzen. Wago bietet gute HW auf verschiedenen Bussen. Ethernet ist toll, kann man dann auch gleich für die Vernetzung der Rechner nutzen. Dann kann man auf dem Lichtschalter Video gucken. LON ist eine gute alternative, gibts für verschiedene Medien. Ich würde die Steuerung so aufbauen, dass immer eine Steuerung z.B. eine Etage übernimmt, fällt dann der Bus aus, kann jede Etage vor sich hinnudeln, so ist es nicht gleich im ganzen haus stockdunkel. Nicht zu vergessen ist die Gebäudeleittechnik (GLT), also ein Rechner, wo man sieht was los ist. Sowas bringt immer ziemlich hohe Buslast !
hmmmm ... Peter, Du machst mich fertig. Seit 15 Jahren hege ich meine Allergie gegen 8051-Derivate. Was viel an dem grauenhaften Speicherzugriff und den unterschiedlichen Zugriffsarten liegt. Ist nicht schön, wenn man auf mehr als die 128 bzw. 256 Byte zugreifen will. Aber für die Hausbus-Anwendung zählen diese Punkte ja nicht, und Atmel ist beim Flash wirklich führend (wenn es beim T89C51CC01 ähnlich wie beim ATmega ist). Den T89C51CC01 gibt es ja auch im SO24-Gehäuse. Das würde mir gut reinlaufen. Also ich werde die Sache mal überdenken. Wahrscheinlich bringt Ihr mich noch dazu, dass ich in einem Jahr auf einem Apple unter Linux im Baumhaus der Kinder programmiere ;-) @Andreas: Habe Deine PIC-Chips schon angeschaut und nicht vergessen. Sehen auch sehr interessant aus, es ist nur die Frage, ob es nicht mehr Sinn macht, auf jeder Platine dieselbe Hardware am laufen zu haben, einfach um sich nicht in 2 verschiedene Teile einarbeiten zu müssen. Das Datenblatt hat auf den ersten Blick nicht ganz trivial ausgesehen, aber ich werde es nochmal studieren. Viele Grüße, Stefan
@Stefan: [Motorola HCS12] > 48-Pin-Gehäuse stimmt, diese Serie hatte ich bisher noch nicht gesehen... > Mehr Pins stören doch eigendlich nur beim Löten und brauchen Platz auch ne Möglichkeit die Sache zu sehen ;) > Wie debuggst Du den HC12? BDM-Interface, USB-Programmer von P&E-Micro und Metrowerks Debugger. BDM ist ne feine Sache. @Peter: > Atmel T89C51CC01 bei Reichelt für 13,20EUR... billig ist das nicht gerade. Für das Geld bekomme ich auch Mikrocontroller von Herstellern, die ihre Produktpalette nicht alle 2 Jahre komplett umstellen ;) > in der kompletten Schaltung programmieren oder updaten. Den mit CAN-Bootloader sogar über den CAN-Bus. Das ist aber inzwischen der übliche Weg. > Er ist auch im schönen PLCC-44 lieferbar, d.h. man kann ihn bequem in einen Sockel auf stinknormale Rasterplatinen einsetzen. Das mag ein großer Vorteil sein. Tschüß, André.
Unter Digikey.com kann man Preise online suchen. Da hat man hat so eine ungefähre Richtung, wohin der Preis geht, wenn man nicht gerade bei Reichelt oder Conrad kauft (oder kaufen muss). Beim T89C51CC02 komme ich da auf 5,20 Euro (100Stk). Der CC01 ist etwas teurer. Den Motorola habe ich bei AVNET für 5,50$ (84 Stk) gefunden. Gute Suchlinks, gerade für Preise, gibt es hier: http://claymore.engineer.gvsu.edu/egr326/ElectronicComponents Hier ist übrigens ein Eval-Board für den Motorola: http://www.elektronikladen.de/chips12.html Also von den CPU-Preisen ist es relativ egal. Um auf dem HC12 zu entwickeln, braucht man das BDM-Pod. Den Compiler und Debugger (auf 12k limitiert) gibt es bei Metrowerks umsonst. André, was hast DU denn für Dein BDM bezahlt? Mit USB würde mir ja schon gut reinlaufen. Viele Grüße, Stefan
@Stefan:
www.pemicro.com -> USB-Multilink: 199$ - leider nur afaik direkt von
USA zu beziehen. Funktioniert mit Metrowerks CodeWarrior v3 und z.B.
HCS12DP256 zusammen recht gut.
Den elektronikladen-Pod habe ich noch nicht live gesehen - kostet
zusammen mit NoIce afair 265EUR - gibt sich also nicht viel. Bleibt der
Vorteil eines deutschen Ansprechpartners (Probleme/Garantie...).
[T89C51CC02]
> 5,20EUR
na das klingt doch schon wesentlich besser.
Tschüß,
André.
Ich habe mal von jemand gelesen, der hat sein Haus mit 1-Wire vernetzt, überall Temp-Sensoren, Jalousiemotoren, Schalter etc. Soll sehr gut funzen. Mit Web-Zugang (Beck IPC@web, http://www.beck-ipc.com) kann er das ganze Haus von jedem Ort der Welt aus fernsteuern. Bei Interesse kann ich die Adresse raussuchen.
So einen Hausbus wollte ich auch unbedingt haben. Das Problem war nur, dass meine Familie nicht 2 Jahre auf Licht im neuen Haus warten wollte. Also habe ich mich für EIB entschiden, und das ganze Häusle vollständig so aufgebaut. Was das alles kosten würde, das wusste angeblich keiner so genau, besonders nicht der Elektriker. Es käme drauf an, und je komplexer desto eher lohnt sich das usw. blablah. Hier die knallharten Fakten: hätte ich die Hütte konventionell mit all den Funktionen verdrahten lassen, die ich heute habe, dann wäre ich nicht unter 15000 DM davongekommen, aber auch nicht über 18000.- DM. Und was hat das mit EIB gekostet? 45000.- DM. Fuenfundvierzigtausend DE-EMM. Also: wer keine 4-8 Stockwerke mit allem PiPaPo verdrahten will, und aufs Geld schauen muss: Finger weg vom EIB, es ist im EFH-Bereich SCHWEIINNEETEUER!! Spass hab' ich trotzdem dran, und nur so kann mans sehen: die einen kaufen sich Spoiler und Breitreifen für den Golf mit bösem Blick, ich hab eben meinen EIB. Nun zur Topologie. Ich würde heute einiges anders verdrahten. Der Ist-Zustand: genau wie hier schon mehrfach besprochen: alle Verbraucher landen mit einer eigenen Strippe im zentralen Schaltkasten. Alle Sensoren (Lichschalter, PIR-Sensoren etc.) sind über Busleitung verdrahtet, bei EIB völlig wurscht ob Stern, Linie oder sonstwas. Die Busleitung landet ebenfalls im Zentralschrank, wo auch die Aktoren sitzen. Das funktioniert alles wunderbar, ist simpel zu Planen und man hat die volle Kontrolle über die Gesamtinstallation, auch später. ABER: in der Stadt gibt es kein Haus, wo soviel Kupfer vernagelt wurde wie bei mir. Von wegen Kabel sparen, alles Gewäsch. Und genau das würde ich heute anders machen: In jedem Stockwerk einen kleineren Schrank, wo alle Stockwerksleitungen zusammenlaufen, und auch alle für das Stockwerk zuständigen Aktoren sitzen. Ein Backbone-Kabel 5*DickundFett für die 220V vom Hauptanschluss zu den Unterverteilungen. Den Bus überall hin, wie gehabt, und fertig ist die Laube. Da in meinem Schaltschrank im Keller heute etwa 150 Strippen (je 3x1,5 bzw. 5x1,5) zusammenlaufen, kann sich jeder ausrechnen, was für einen Monsterschlitz ich dort in die Wand kloppen musste. Ausserdem kann man für jeden Verbraucher je Stockwerk mal eben 2,80m Kabelverlust rechnen, was sich bei meinem Häusle alleine auf geschätzte 420 Meter summiert. Die müssen bezahlt werden, die müssen verlegt werden, die müssen z.T geschlitzt werden, sie bedeuten Leitungsverluste (Wattmässig), sie stellen eine Brandlast dar und man KANN SIE ANBOHREN!! Und das ist nicht zu unterschätzen: es gibt Stellen im Haus, da bohr' ich kein Loch in die Wand, höchstens nach SEHR genauem Sudium meiner Fotos (oder gerade dann erst recht nicht!). Am besten mal zusammenrechnen, was so an Kabeln zusammenkommt: Deckenlicht, Steckdosen (einzeln schaltbar...), Jalousien, Wandlampen, Herd, Backofen, etc.etc. Ich hätte jedenfalls nie gedacht, dass man in einem EFH problemlos auf 150 Steckdosen kommen kann.... Die Lichtleitungen kommen natürlich hinzu, und auch so manches andere fällt einem noch ein. Achja: die Aussenelektrik nicht vergessen, wiederum Licht, Steckdosen, Alarm-Einrichtungen usw... Wenn dabei am Schluss irgendwas zwischen 100 und 200 Leitungen rauskommen, dann nicht wundern, sondern genau überlegen, WIE KRIEG ICH DIE ALLE IN DEN KELLER? Bei mir war's so, dass ich in der Küche ein einer Stelle keinen Oberschrank hätte hängen können, wär mangels (Wand-)masse einfach nicht gegangen: da geht der Monsterschlitz zur Hauptverteilung runter. Glücklicherweise sollte da eh' nur ein Hochschrank hin... Deshalb meine dringende Empfehlung (je nachdem wie gross das Projekt ist): In jedem Stockwerk einen eigenen Schaltschrank. Den dafuer aber kleiner. Macht die Sache auch übersichtlicher und leichter wartbar. Auch wenns einem nicht ins architektonische Konzept passt, glaubt mir: ES LOHNT SICH! Und ausserdem muss man, wenn eine Sicherung rausgeflogen ist, nicht zwei Stockwerke tief in den Keller laufen. Noch ein Problem, ich habs schon erwähnt: wer baut hat den Kopf voll. Und wenn da einer noch den Nerv und das Stehvermögen hat, einen eigenen Bus zu entwickeln, bzw. Anwendungen zu einem bekannten Bus für sein Haus zu entwickeln, dann muss ich sagen: Hut ab! Sowas müsste man eigentlich in den eins/zwei Jahren vor dem Baubeginn machen, wenn man noch Kraft und Ruhe hat. Wenns dann soweit ist, muss man in der Lage sein, alles einfach fix+fertig einzubauen, so wärs ideal. Denn eine doppelgleisige Installation (Konventionell und Busmässig) kommt nicht nur teurer sie ist schlichtweg Verschwendung und auch irgendwie frustrierend. Noch was zum EIB: man kann schon einiges draus lernen: dezentrale Intelligenz, Multimaster/Slave-fähig (es gibt eigentlich keine "Master", der Bus ist sehr "demokratisch"), ziemlich sicheŕ in der Übertragung, AFAIK 9600 Baud. Sehr schön: Alle Komponenten fernprogrammierbar über Bus/Internet etc., Sicherheitskonzepte. Ein Bekannter baut auch gerade seinen eigenen Bus (Walters Bus hat auch schon einen Namen: "Walli-Bus"). Es handelt sich um einen differentiellen 2-Draht Bus, d.h. die Spannung auf dem Bus ist ziemlich wurscht, über einen OpAmp wird einfach die Spannungs-Differenz zwischen zwei Leitungen ausgewertet. Ist natürlich ziemlich sicher, da Spannungschwankungen eigentlich keine grosse Rolle spielen, und auch Einstreuungen, die ja auf beide Leitungen wirken, wenig Effekte haben. Mehr weiss ich dazu allerdings auch nicht. Ich hab nur gesehen, dass es schon funktioniert. Noch was Allgemeines: Die Einzelprojekte so einer Idee sind sicher alle gut in den Griff zu bekommen. Man sollte aber die Gesamtaufgabe nicht unterschätzen - es ist mehr Arbeit, als man zunächst annimmt! Und wenn dann die liebe Gattin kein Licht in der Küche hat, oder kaltes Wasser in der Wanne, weil noch ein Bug im Busprotokoll ist, dann wirds echt bitter ... ;-) Trotzdem wünsche ich viel Erfolg damit! Ich werde gespannt weiter hier mitlesen! PS: z.Zt. versuche ich, mir ein paar Infineon "TP-UART EIB" zu organisieren. Serielle EIB-Busankoppler sind das, ich möchte da was Eigenes für meinen EIB machen, und zwar eine DCF77-Jahresschaltuhr mit zig-Programmiermöglichkeiten, sowas kostet im EIB-Bereich auch mal 500 Euro :-(( Wer Interesse hat, soll sich melden: die Mindestbestellwerte sind etwas hoch für einen allein. e.
Hallo Leute, bin neu in diesem Forum. Will mein Haus auch mit einem Bus ausrüsten. Habe da folgendes System entdeckt. LCN (www.lcn.de) + 230V und ein zusätzlicher Leiter als Datenleitung + Dezentraler (und Zentraler) Aufbau -- örtlich gesehen + Verwendung normaler oder EIB Taster Was sagt ihr dazu ????
Was noch nie angesprochen wurde, ist die Programmierung des Busses. Hie kommt nur eine Programmierung über den Bus in Betracht (wie bei EIB)Der Bus muß sehr einfach zum Programmieren gehen. (leichter als bei EIB, zb. Nikkobus von Möller) Mein Bus läuft so: Taste am Aktor drücken (Lernmodus) Taster drücken (zB. Lichtschalter) fertig. Jede andere Programmierungsart wäre Wahnsinn, da du in 3 Jahren überhaupt nichts mehr weist über dein Busprogramm und Weihnachten im Dunkeln sitzen könntest. Nimm lieber Siemens LOGO und schalte alles zentral, in jedem Stock ein Verteiler, fertig. Easysoft von Möller ist sogar vernetzbar (zB.von Stock zu Stock) Schöne Grüße Josef
Ich mach mir auch viel Gedanken über einen solchen Bus. Grundlegend hab ich bis jetzt folgendes durchdacht, 2 Leitungen einmal GND und einmal +12V. Hardware grundsätzlich Sender (Taster, Bewegungsmelder usw...) auf den Sendern wird mit DIP Schaltern eine Adresse eingestellt (0-255) somit sind 256 Sender möglich. auf die +12V wird dann das Datensignal aufmoduliert (voll Duplex, also senden und empfangen möglich). Dann gibt es ein Master Modul welches die Befehle von den Sensoren (sendern) zu den Aktoren (Relais, Triac-Schaltern) weitergibt! Dieses Master Modul möcht ich dann über die RS232 programmieren können! Die Aktoren sollen einfache Emfänger, ebenfalls eine Adresse einstellbar 0-255, sein. Tja diese Aufgabenstellung hab ich mir bis jetzt gemacht, weit gekommen bin ich aber bis jetzt noch nicht (Zeitmangel) Sollte ich jedoch weiterkommen lasse ich es euch wissen! mfg Michael Wulz
@Mario: So wie ich das sehe, wird lcn nur von einer Firma hergestellt? Ist natürlich etwas riskant, wenn die dann absaufen. Aus meiner persönlichen Sicht heraus ist ein separater Datenbus besser, weil ich dann eine eindeutige Trennung zwischen Netz und Bus habe. Ich bastel also immer an "ungefährlichen" Spannungen rum (und die Kinder auch, wenn sie mal Papa spielen). Das ist bei einer eingekauften Lösung aber sicher nicht das Problem. Was ich von Netzfreischaltung im Schlafzimmer halten soll, bin ich mir nicht so sicher, aber bei einer separaten 24V-Gleichspgs-Lösung fällt das schon vom Konzept mit ab. @Joseph: Ich habe im Moment die Aktoren alle im Schaltschrank (im Keller) geplant. So eine Programmierung wäre mir zuviel Rennerei. Die Programmierung z.B. von Lichtszenen soll aber schon vor Ort erfolgen: Lange auf den Szenentaster drücken speichert die momentane Lichteinstellung auf dem Schalter ab (analog auch bei Jalousien). @Michael: An dem Punkt (2 Leitungen) war ich auch schon mal. Technisch ist das sicher das naheliegendste und eleganteste. Allerdings habe ich ziemlich lange nach Bustransceivern für so eine Lösung gesucht und nichts integriertes gefunden. EIB verwendet ja so ein Verfahren, allerdings verwenden die einen Trafo am Eingang. Das Netzteil muss auch speziell dafür ausgelegt sein. Ich habe mich mittlerweile entschlossen, die zweitschönste Lösung mit 4 Adern zu bauen. Sind halt überall doppelt so viele Adern zu kontaktieren, dafür entfällt aber viel Elektronik-Aufwand, und ich kann den CAN-Bus von der Stange verwenden. Immerhin will ich irgendwann ja auch fertig werden. Als Spannungsversorgung habe ich 24V vorgesehen, weil viele Geräte damit direkt angesteuert werden können und deshalb oft das 220V-Kabel gespart werden kann, z.B. die elektrischen Heizungs-Steller. Ich habe 4* soviel Leistung als bei 12V (bei gleichem Kabelwiderstand), ev. ist es damit sogar möglich, Jalousiemotoren direkt zu betreiben (muss ich aber noch näher anschauen). Auch an eine Minibeleuchtung (Nachtlicht im Kinderzimmer oder an der Treppe, ein paar LEDs mit vielleicht 1W) habe ich schon gedacht. Die Adressen will ich entweder fest ins Flash schreiben oder per Dallas-Seriennummer-Chip (One-Wire). Ich bin gerade dabei, das Konzept mal grob zu beschreiben, wenn es fertig ist, stelle ich es hier natürlich rein. Viele Grüße, Stefan
@emax: erstmal Danke für Deinen superlangen Beitrag. Hat mich richtig erschlagen ;-) Für EIB-OEM-Komponenten ist vielleicht diese Seite recht interessant: http://www.knx-developer.de/ Zum Preis: genau so habe ich das von meinem Elektriker auch angeboten bekommen, nur dass der Preis mittlerweile nicht mehr in DM sondern in gilt :-(( Bei Elektrikern scheint das Wort EIB so einen Reflex auszulösen: "kein qm ohne eingebautes Kabel". Ich habe ihm dann desagt, dass ich mir den Bus lieber selber bauen will und er nur die Netzspg. einbauen darf, das hat er sogar ganz gut akzeptiert. Das mit den vielen Kabeln ist wirklich ein Argument. Ich bin mir nur nicht sicher, an welcher Stelle ein Unterkasten bei unserem Bauplan wirklich Sinn macht. Ich habe einen zweiten Kasten schon mit meinem Elektriker angesprochen, aber bis jetzt haben wir noch keinen guten Platz gefunden. Dass man von EIB viel lernen kann, habe ich auch schon gemerkt. Der größte Nachteil ist wirklich der Preis. Ausserdem möchte ich bei der Hauselektronik gerne Einiges mitreden und auch mitentwickeln. Und da sind die Hürden bei EIB doch recht hoch. Ob ich mit der Zeit hinkomme, das muss ich eben ausprobieren. Den Hausbau verschieben geht jedenfalls nicht mehr ;-) Die Wahl des CAN-Bus ist nicht zuletzt deswegen gefallen, weil es einen sicheren Unterbau darstellt und (wohl) recht einfach zu implementieren ist. Aber ich bin recht optimistisch, dass zumindest die rudimentären Sachen in 6 Monaten laufen. Eine automatische Jalousiesteuerung kann z.B. ruhig noch länger warten. Viele Grüße, Stefan
Hallo Stefan! Also das mit dem zentralen Schaltschrank überleg Dir gut! Ich hab' Dir im Anhang mal ein zwei Fotos von meiner Installation gepostet. Schau Dir besonders mal oben rechts im Kasten die Reihenklemmen an, da gehts schon sau-eng zu, auch wenn das auf dem Bild alles so schön locker aussieht. Die Linke Seite ist von den Zählern vollständig belegt (es sieht luftig aus, aber du kannst da nix mehr reinmachen), rechts ist zwar noch etwas Platz, aber der hätte nicht ausgereicht, wenn ich nicht einen zweiten Kasten unten drunter gesetzt hätte... In meiner Werkstatt habe ich noch UV, ausserdem sitzt dort mein patch-Kasten für die Cat-5 Kabel die von den 18 Anschlüssen im ganzen Haus dort zusammenlaufen, und in der Einliegerwohnung ist auch noch eine Verteilung. Es wäre NIEMALS alles in einen Kasten gegangen. Unten drunter siehst Du den zweiten Kasten mit einem Teil der EIB-Komponenten. Den musste ich setzen, als sich zeigte, dass der Platz in der HV nicht reichte. Ziemlich unpraktisch, man kann nur auf dem Boden hockend da was machen. Es ist noch nicht alles fertig angeschlossen, aber Du kannst in etwa schon die Ausmasse der Kabelorgie sehen. Stell Dir einfach vor, Du programmierst ein dickes Programm in einer einzigen Monster-Main-Spaghetti-Routine, anstatt in übersichtlichen Einzel-Funktionen. Es ist echt gut miteinander zu vergleichen: ein grosser Schaltschrank oder mehrere kleine. Wenn Du einen gut dimensionierten 400V-Strang als Backbone von der HV (Hauptverteilung)zu den UVen legst, und zwei (sicherheitshalber) Hausbus-Leitungen gleich dazu, dann bist du bestens gerüstet. Dann kannste z.B. auch Deine FI-Schalter stockwerkmässig abgrenzen usw... Ausserdem: du wirst echt irre, wenn Du Armbeugen-dicke Kabelbündel durch irgendein viel zu enges Loch in einer Betondecke würgen musst. Wo die Kabel zusammenlaufen, kannste auch später kaum noch guten Gewissens ein Loch bohren.... Hinzu kommt, dass die lieben Heizungsbauer dann auch noch ein paar Röhrchen da durch haben wollen, von Abwasser et. al. ganz zu schweigen. Und die sind mit den ggf. bereits liegenden Kabeln nicht immer sehr zimperlich.... So einen UV-Schrank kann man natürlich nicht in eine 11-5er Wand einbauen. Trotzdem gibt es genügend Möglichkeiten. z.B. hinter einer Tür, da sieht mans nicht so. Oder bevorzugt im Flur (weil man da am besten hinkommt, wenn mal die Sicherung rausfliegt), oder auch mitten auf jeder beliebigen Wand, wenn man an dieser Stelle vielleicht ein grosses Bild hinhängen kann. Ich wollte mir anfangs "UM GOTTES WILLEN" auch keine Wand mit einer UV "versauen". Hinterher weiss ich nun, dass alles halb so wild ist. Man gewöhnt sich an vieles, es gibt Gestaltungsmöglichkeiten, und wenn man gebaut HAT, dann sieht man ohnehin alles viel lockerer. Noch ein paar Fakten: so ein HV-Schrank ist SCHWEINETEUER! Und zwar deshalb, weil da wg. des Zählers usw. alle möglichen Anforderungen bestehen und weil "Hager" drauf steht. Ich hab' über tausend Märker für das bischen Blech abgedrückt. Wenn der Kasten dann noch besonders gross sein muss, dann wirds nochmal extra teuer. Wenn Du aber in den Stockwerken kleinere UVen setzt, dann kannste die auch im Baumarkt billig kaufen, es interessiert dann niemanden mehr, ob's einer von Hager ist, oder nicht. Und so wird dein HV-Schrank kleiner. Und noch ein Tipp, auch wenns jetzt etwas OT wird: Wenn Du Fussbodenheizung hast, haste das selbe Problem: wohin mit den Verteilerschränken? Die Antwort: dahin, wo Du Wärme brauchst, möglichst zentral im Stockwerk. Denn dahin, wo diese Verteiler sitzen, laufen natürlich auch alle Fussbodenleitungen, weshalb natürlich der Boden in der Umgebung zwangsbeheizt wird. Mir hat das damals niemand gesagt, weshalb ich heute eine viel zu warme Abstellkammer habe.... Soweit so gut. In welcher Gegend baust Du eigentlich? Ich wohne im Odenwald, wenns nicht so weit weg ist, dann schau ich mir das gerne mal an... bis denne, e.
Hallo Stefan, emax steht im Leben. Eine Zentrale Installation der Aktoren macht keinen Sinn. Mein Haus hat insgesamt 4 Etagen, die ich mit zum Teil 2 Verteilern ausgestattet habe. Der erste Vorteil besteht in der Tatsache, dass ich logische Einheiten habe. Somit ist es ein leichtes Verbrauchmesser, FI und Bussystem getrennt voneinander zu installieren. Der zweite Vorteil liegt in der Länge der Leitungen zu den Aktoren und Sensoren. Auch die Fehlersuche gestaltet sich wesentlich einfacher. Wenn ich am Bus die Verbindung zu anderen Verteilern unterbreche, kann man den Fehler relativ schnell eingrenzen. Ein weiterer Punkt ist speziell für vermietete Wohnungen wichtig. Da ich an meinem Bus einen Scanner hängen kann, wäre es mir möglich genau zu sehen was meine Mieter machen. Deshalb plane ich für diese Übergänge eine Firewall die den Bus elektrisch trennt und nur notwendige Events ( Außentemp., Heizungsdaten usw. ) überträgt. Auch Konfigurationssoftware kann somit nur im eigenen Bereich Unfug anrichten. Abschließend wie immer an jeden Häuslebauer: Legt keine Leitungen. Legt Leerrohre. Ich habe es sogar mit meinen Wasserleitungen praktiziert und bin damit sehr zufrieden. Bernhard Koopmeiners
@emax Bravo ! Tolle Arbeit.(meine ich ernst) Aber leider keine Kabel angeschrieben. Großer Fehler. Fehlersuche: Viel Spaß. Das sind Bus-Auswüchse ;-) EIB: Immer schon an der Praxis vorbei. Zu teuer, zu komplex, zu viel Platzverschwendung. Aber sehr zuverlässig und leistungsfähig. Kunden (Nichttechniker) machen sich durch EIB lebenslang von Ihrem Elektriker abhängig. Von selbstgestrickte Bussystemen würde ich die Finger lassen (wenn einem an der eigenen Frau was liegt). Schöne Grüße Josef
@josef Jaja, die Doku. Ist aber nur halb so schlimm: alle Klemmen sind im PC dokumentiert. Die Übertragung auf Etiketten ins richtige Leben steht noch an... Behelfsweise habe ich eine Klemmen- und Gerätedoku ausgedruckt und auf die Innenseiten der Schaltschranktüren geklebt. Ist ja alles noch nicht fertig - und wird es wohl auch nie :-)) Das mit der eigenen Frau hab' ich ja oben schon beschrieben, aber vielleicht ist Stefan ja Junggeselle ;-) Das mit derElektrikerabhängigkeit stimmt für Nichttechniker. Aber sogar Elektriker haben so ihre Probleme mit der Projektierung des EIB. Der ETS/2 liegt ein Datenmodell zugrunde, das die meisten Elektriker einfach nicht verstehen. Und dann kommt da was bei raus, wo die zwar physische Projektierung (Leitungstopologie) korrekt gemacht wurde, denn das ist ja was, was man "sehen" kann. Aber die "Logische Sicht" aufd die Installation (eine tolle Sache) wird oft nicht korrekt verstanden und deshalb als das Gleiche wie die Bustopologoie angesehen. Na egal. Ich hab jedenfalls konsequent die gesamte Grundinstallation des Elektrikergesellen gelöscht, und alles Pikkobello nach den optimalen Möglichkeiten der ETS/2 neu konfiguriert. Da lass ich keinen Elektriker mehr ran.... PS: ETS heisst "Eiba Tool Software", das ist die Projektier- und Programmiersoftware für den EIB.
Wow, wie schafft Ihr es, solche Mengen zu schreiben? Ich werde die Beiträge von Euch mal ausdrucken und meinem Elektriker zeigen. So eine Unterverteilung würde mir selber ja schon passen, weil sie dem dezentralen Konzept wenigstens ein Stückweit entgegenkommt. Aber Elektriker scheinen wohl allesamt zentralistisch zu denken, das EIB-Konzept war ja EIGENDLICH auch dezentral gedacht, draus geworden ist leider das Gegenteil. Natürlich habe ich Frau und Kinder, würde ich sonst den Wahnsinn angehen, ein Haus zu bauen? Aber bevor ich für Eigenleistung an der Betonmaschine stehe, baue ich lieber meinen eigenen Bus zusammen. Wenn ich die Fliesen selbst lege, heisst es die nächsten 30 Jahre: "hat mein Mann selbst gemacht, FAST professionell, oder?", bei einem eigenen Bus passiert mir das nicht, ich bin mir ziemlich sicher, dass die Elektrik später besser läuft als im Standard-0815-Haus. Klar, mit 45.000 EIB-Installation (habt Ihr den ct-Artikel gesehen?) ist meine Lösung sicher nicht zu vergleichen. Mit einem vom Elektriker installierten Bus würde es mir so gehen wie emax: zuerst viel ärgern, dann alles rausschmeissen und selber neuprogrammieren. Natürlich ginge das auch mit einem EIB-Bus. Aber den Ausweg habe ich ja immer noch. Wenn mein Bus nicht fertig wird, muss es halt doch ein (Mini-) EIB werden. Aber nicht selbst an der Elektrik rumzufummeln wäre für mich wie für den Architekten, wenn er sein Haus vom Bauträger hinklotzen läßt. Viele Grüße, Stefan
@emax: ach ja, wir bauen in Würzburg, ist ja garnicht so weit weg. Vielleicht können wir uns wirklich mal treffen. Viele Grüße, Stefan
Aber auch bei einer normalen Verdrahtung sind Zwischenverteiler in den Etagen sinnvoll. Ich würde das ganze so machen, daß ich die Lampe mit zur Schalterdose führe, also ganz normal und im Fehlerfall durch einen normalen Schalter ersetzbar. Und auf der Platine in der Schalterdose sitzt neben dem CAN-MC auch ein Opto-Triac mit Entstörbeschaltung. Statt des Schalters sitz eine Sensorfläche davor, die der MC mittels Kapazitätsmessung prüft, ob sie berührt wird oder nicht (wurde hier schon mal beschrieben). Eventuell noch ein kleines Fenster mit drin für den TSOP IR-Empfänger und fertig ist die Lampensteuerung. Der Verdrahtungsmehraufwand ist also nur das 4-polige Bus/24V-Kabel. Der Funktionsvielfalt sind dann keine Grenzen gesetzt. Man könnte z.B. beim 5-maligen Drücken im Schlafzimmer sämtliche Lampen im Haus mit ausschalten. Peter
"Ich würde das ganze so machen, daß ich die Lampe mit zur Schalterdose führe, also ganz normal und im Fehlerfall durch einen normalen Schalter ersetzbar." So hatte ich zunächst auch angefangen. Als dann aber Kreuzschaltungen, Wechselschaltungen usw. auftauchten, war schnell klar, das ich damit alle Vorteile des Busses, nämlich eine simple Verdrahtung (alles ab zum Verteiler und basta), aufgab. Man kann das natürlich sicherheitshalber in einfacher Form tun: keine Kreuz- oder Wechselschaltungen usw, dann kann man halt im Treppenhaus nur im untersten Stock alles an+ und ausschalten.... Also das muss man sich gut überlegen. @Stefan in der Nähe v. Würzburg kenne ich einen Ort namens "Thüngen", da ährt man vielleicht eine Stunde von hier aus. Wenn die Hütte Forman annimmt, und die ersten Strippen gezogen werden, dann meld' Dich mal per PM. An einem Sonntag mal mit dem Motorrad rüber hüpfen wär kein Thema. e.
"keine Kreuz- oder Wechselschaltungen" Da die Schaltereinheiten alle untereinander vernetzt sind, kann man das sehr wohl machen. Ist alles nur eine Frage der Programmierung. An Halloween kann z.B. der Taster im Flur den Triac im Wohnzimmer schalten und umgekehrt. Steuerungstechnisch ist doch nur ein Output (Lampe) und ein Input (Taster) am selben MC angeschlossen. Die Verknüpfung der beiden kann entweder zentral oder im jeweiligen MC selber erfolgen. Der Taster sendet also ein Datenpaket entweder an die Zentrale: "Taste 1234 gedrückt" oder direkt an die Lampe: "Lampe 5678 einschalten". Peter
Das ist mir völlig klar, der EIB arbeitet ja so: Datagram vom Sensor "Adresse 1.2.3 EIN". Nur brauchts dann doch keine 220V am Lichtschalter mehr. Was ich meinte, war, dass die 220V Verkabelung, die ich ZUNÄCHST parallel zum Bus an die Schalter führen wollte, bei Ausführung aller Anschlusse auch für Kreuz- und Wechselschaltung viel komplexer geworden wäre, als das bei einer Buslösung nötig ist. Ich habe deshalb den Versuch, die Lichtschalter (und die anderen Sensoren) zusätzlich mit 220V zu verdrahten, schnell aufgegeben.
@Peter: Als Sicherheits-Backup werde ich bei wichtigen 220V-Kreisen im Schaltschrank Relais mit integriertem manuellen Ein-Schalter einbauen. Das muss als Sicherheit reichen. Wenn der Bus wirklich mal ausfällt, dann muss eben im Schaltschrank geschaltet werden. Kommt ja hoffentlich nicht so häufig vor. An einigen Stellen ist bei uns eine Doppelverkabelung auch rein vom Platz her nicht möglich. Den Bus will ich ganz bewusst von der 220V-Schiene trennen. Ich habe zwar früher komplette Lichtanlagen selbst gebaut, aber mittlerweile bin ich doch etwas vorsichtiger geworden. Wenn etwas passiert, auch wenn die Elektronik nicht der Auslöser war, ist sonst der Ärger groß. Rein von der Technologie her wäre Dein Ansatz natürlich am Besten, wobei ich dann die Aktoren direkt an die Lampenausgänge und Steckdosen legen würde. Der Schaltschrank wäre damit auf einmal ganz leer ... @Emax: In 2 Wochen kommen erstmal die Bagger, wenn alles klappt, dann steht der Rohbau Ende Mai. Dann ist ja (hoffentlich) auch das Wetter Motorrad-tauglich. Viele Grüße, Stefan
Die Aktoren im Schaltschrank unterzubringen hat noch einen Vorteil: Die Stromleitungen in Wänden/Decke/Fussboden werden bei "AUS" stromlos geschaltet. Weniger Brandlast, weniger Elektrosmog. Damit lässt sich sowas übrigens etwas leichter an die Ehefrauen verkaufen ;-) e.
Hi! Als heimlicher Mitleser melde ich mich auch mal zu Wort! >Ich würde das ganze so machen, daß ich die Lampe mit zur Schalterdose >führe, also ganz normal und im Fehlerfall durch einen normalen >Schalter >ersetzbar. >Und auf der Platine in der Schalterdose sitzt neben dem CAN-MC auch >ein >Opto-Triac mit Entstörbeschaltung. Genau das habe ich auch in Planung:) Schonmal ueber Transistor anstatt Triac nachgedacht? Damit geht auch ein Phasenabschnitt, was die Entstörung minimiert. Soviel Platz ist ja nicht in einer Schalterdose. Mein Konzept beruht auf einem Standard Buskoppler mit AVR, CAN Baustein (SJA1000) und ein wenig drumherum. Dieser wird je nach Bedarf Hukepack auf einen Aktor aufgesetzt. Z.B. Dimmer, Relais, IR, Rolläden etc. Bei SMD Bestückung sollte sich z.B. ein Buskoppler und Dimmer in einer tiefen Schalterdose unterbringen lassen. Bei Wechselschaltungen wird 2x ein Buskoppler und 1x ein Aktor gesetzt. Die beiden Buskoppler "unterhalten" sich dann direkt. Da hier doch einige Interesse an Homeautomation zeigen wäre es doch nicht schlecht das gemeinsam anzugehen, oder?? Gruss, Michael
Sorry dass ich mich so lange nicht gemeldet habe. Michael, Dein Posting muss beim Email-Aufräumen unten durch gefallen sein (grr geht mir irgendwie öfters so). Über den Transistor statt Triac habe ich mir wirklich schonmal Gedanken gemacht. Hat auch ein paar andere Vorteile, z.B. kann der Strom sehr einfach gemessen werden. Wäre natürlich schon ein schickes Feature ... Ich habe mittlerweile ein Modul als Schaltplan und als Platine fertig, jetzt muss ich das Layout noch fertigen lassen. Bauteile sind für die Prototypen schon da, demnächst soll es mit der Programmierung losgehen. Mal sehen, wie ich die nächsten Tage dazukomme, dann werde ich das Ganze mal hier vorstellen. Als Grundlage habe ich übrigens jetzt einen AVR16 vorgesehen, mit Microchip MP2515 CAN-Transceivern. Ist zwar leider kein Single-Chip mehr, aber durch die Ansteuerung per SPI-Bus hält sich das Leiterbahn-Chaos in Grenzen. AVR habe ich deshalb genommen, weil ich a) beruflich gerade ein größeres Projekt damit starte und b) schon den JTAG-Debugger dafür habe. Ich kann also sofort komfortabel damit starten. Was mir auch noch wichtig war: ich will an manchen Stellen CAN-Kreuzungen einbauen, d.h. vom Hauptbus gehen Unterbusse ab, um z.B. ein Zimmer zu versorgen. Da ist es natürlich besser zu programmieren, wenn beide CAN-Transceiver dieselbe Hardware sind. Zugegeben, viele andere Lösungen, die hier genannt wurden, haben auch ihren Reiz, aber am Ende habe ich dann eben doch pragmatisch entschieden. Sobald die Doku einigermassen vorzeigbar ist, hört Ihr wieder von mir. Stefan
Hallo, habe gerade den Thread mit großem Interesse gelesen. Ich hätte bis dato auch eine Installation wie es Peter Dannegger vorgeschlagen hat (http://www.mikrocontroller.net/forum/read-1-66019.html#68989) vorgezogen. Jetzt bin ich aber doch ein bisschen verunsichert, ob das Prinzip, alle Aktoren in eine gemeinsame UV zu ziehen, nicht doch besser ist. Der Vorteil der "herkömmlichen" Methode (inkl. zusätzlicher Busleitung) wäre, dass die Buskoppler auch autark, also ohne Bus arbeiten können. Jedoch müßte dann wahrscheinlich auch jeder speziell programmiert werden. Mal nur 1 Taster, mal 2 Taster und ein IR usw., die ja dann auch jeweils unterschiedliche Funktionen zum Ergebnis haben. Und man hat eben auch 230V in der Schalterdose. Der Vorteil der gemeinsamen Verteilung ist sicher, dass mehr oder weniger alle 230V-Leitungen an einer Stelle zusammenlaufen und man von hier aus elektrisch alles recht einfach durch simples Umklemmen (auch neu) zuordnen kann. Aber benötigt man dann nicht einen Master, der sich um das tatsächliche Schalten dere Aktoren kümmert? @Stefan: >Ich habe keine Schalter mehr am 220V-Netz, wenn Du das meinst. Die >Schalter bzw. Taster der einzelnen Zimmer gehen über den Bus zum >Schaltschrank. Dort steuern sie dann den zugehörigen Aktor an, der >das entsprechende Relais schaltet. Die Kommunikation zwischen >intelligentem Schalter und Aktor läuft dabei direkt, nicht über einen >zentralen Master. Wie funktioniert das? Also ich habe das so verstanden: Es gibt an verschiedenen Stellen irgendwelche Busteilnehmer, die Signale auswerten z.B. einen Taster. Diese sollen auch Aktoren direkt schalten können. Die Aktoren sind aber in der UV geschaltet. Dann muss es doch in der UV einen Master geben, der die "Wünsche" der Busteilnehmer auswertet und ausführt, oder? Joline
Wenn das System nur ein Haus steuern soll, habe ich DALI im Angebot. Hardware ziemlich einfach und störunempfindlich. DALI heißt Digital Adressable Lighting Interface. Ist vor ich glaube 4 - 5 Jahren geboren worden. Michael
@Joline: >Wie funktioniert das? >Also ich habe das so verstanden: Es gibt an verschiedenen Stellen >irgendwelche Busteilnehmer, die Signale auswerten z.B. einen Taster. >Diese sollen auch Aktoren direkt schalten können. Die Aktoren sind >aber in der UV geschaltet. Dann muss es doch in der UV einen Master >geben, der die "Wünsche" der Busteilnehmer auswertet und ausführt, >oder? Unter Master verstehe ich einen Teilnehmer im Bus, der die Kommunikation aller anderen regelt. Das braucht man (beim CAN-Bus) nicht. Vielmehr können sich alle angeschlossenen Teilnehmer gleichberechtigt unterhalten. Der Lichtschalter kann also dem Aktor (Relaistreiber oder Dimmer) im Schaltschrank direkte Kommandos geben, ohne dass ein Master ihm dazu die Berechtigung erteilt. Und wenn ein Aktor im Schaltschrank ausfällt, dann funktionieren alle anderen Aktoren weiter. Die CAN-Treiber haben intern spezielle Sicherheitsschaltungen, die verhindern, dass ein amoklaufender Busteilnehmer alle andere Kommunikation blockiert. >Jetzt bin ich aber doch ein bisschen verunsichert, ob das >Prinzip, alle Aktoren in eine gemeinsame UV zu ziehen, nicht doch >besser ist. Wenn Du es alles selber baust oder der Elektriker mitspielt, würde ich mehrere UV an einigen zentralen Stellen vorschlagen, jedenfalls bei einer Hausverdrahtung. Also vielleicht stockwerksweise. So, jetzt muss ich auf die Baustelle ... ;-) Viele Grüße, Stefan
@Stefan: >Unter Master verstehe ich einen Teilnehmer im Bus, der die >Kommunikation aller anderen regelt. Das braucht man (beim CAN-Bus) >nicht. Vielmehr können sich alle angeschlossenen Teilnehmer >gleichberechtigt unterhalten. Das ist schon klar. Ist ja einer der Riesenvorteile von CAN. Vielleicht hatte ich mich unverständlich ausgedrückt. Es sitzt doch bspw. in jeder Schalterdose ein Teilnehmer, der Signale auswertet (wie ein Satellit), oder? Diese Signale sendet er dann über den Bus an die UV. Aber dort muss doch auch einer sitzen, der eben dann wirklich das Relais schaltet. Und entweder ist das einer (oder mehrere natürlich), der alles macht (den hatte ich quasi als Master bezeichnet). Oder es gibt wieder für jeden Aktor einen einzelnen Teilnehmer, der sich nur um diesen einen Aktor kümmert. D.h. Anzahl der Aktoren ~ Anzahl der Teilnehmer in der UV. Aus Deiner Anwort deute ich, dass tatsächlich jeder Aktor auch über einen Teilnehmer am Bus angekoppelt ist. Das ist zwar sehr flexibel, weil sich ja alles per Software "umverdrahten" läßt. Aber wenn das so ist, ist das nicht ein ziemlicher Aufwand? Mal abgesehen von den Kosten (fertige Profi-Systeme kosten auch Geld, und nicht wenig...) müssen die Module ja auch hergestellt werden, also Platine bestücken, Controller programmieren usw.? Ist Deine Topologie so, wie ich denke, dass sie ist? Joline
@Joline: natürlich hat nicht jedes Relais seinen eigenen Busanschluss - wäre ja viel zu teuer ... * Module zur Relaisansteuerung können 24 Relais schalten * Module zum Dimmen beinhalten 6 Dimmer * Module für Heizungsventile können 6 Heizventile stellen Jede einzelne Funktion - also z.B. die Ansteuerung eines Relais-Paares für eine Jalousie - lässt sich aber unabhängig von den anderen ansprechen. Viele Grüße, Stefan
Hallo Stefan, ich habe noch einmal 2 Fragen. Es kommen da ja sicher eine Menge Module zusammen. Wie machst Du das mit der Programmierung der Controller im eingebauten Zustand? Also ich denke, wenn mal ein Firmwareupdate notwendig ist, wäre es ja ziemlich lästig, sich an jeden Controller einzeln anstöpseln zu müssen... Wie Du weiter oben schon einmal beschrieben hast, kann ein Sensor-Modul auch direkt ein Aktor-Modul ansprechen und somit bspw. ein Taster (fast) direkt eine Lampe einschalten (Taster A -> Sensor-Modul ==> Aktor-Modul -> Relais 1). Das setzt aber voraus, dass in dem Sensor-Modul die entsprechenden Befehle hinterlegt sind, um die passende Nachricht auch an das entsprechende Aktor-Modul zu senden. Wenn sich nun aber mal die Zuordnung ändern soll, weil z. B. nicht nur Relais 1, sondern auch Relais 2 geschaltet werden soll, dann müßte doch das entsprechende Sensor-Modul neu programmiert werden, oder? Joline
Würde die ganze Hauselektrik konventionel machen. In jedem Stock ein Kleinverteiler 3-reihig. Von diesem ein Instabuskabel von Verteiler zu Verteiler. Jedes Zimmer eigene Zuleitung zum Verteiler inkl. freier Ader für jede Lampe bzw Taster (minimalste Kosten). Ebenso Jalosien / Rolos in den Verteiler. Kannst jetzt ohne Risiko Bussysteme aller Art verbauen. In den Räumen würde ich Funktaster einsetzen. Da kannst du den Taster "mitnehmen" und von allen Stellen aus dimmen. Fernbedienung usw. auch kein Problem. SG Josef
Die Module sollten man gar nicht programmieren müssen . Beim Instabus wirst hier ein Waserl. Optimal ist: Adresse manuell mittels Codierschalter einstellen, fertig. Das Telegramm entscheidet was das Ding machen soll. zB.: 10, 01, 02,45, 19 heißt: Telegramm an Adresse 10, 01 = Ausgang 1, 02 = Zeitfunktion, 45 = für 45 Sec. 19 = Absender. Mit dieser Methode brauchst du überhaupt kein Modul programmieren. Wenn ein Eingang betätigt wir, sendet dieser ein Telegramm, das den Eingang eindeutig identifiziert. Wenn du jetzt einen Master ins Netz legst, brauchst du nur die Telegramme bei diesem verknüpfen und fertig. SG Josef
Hallo Joline, >Es kommen da ja sicher eine Menge Module zusammen. Wie machst Du das >mit der Programmierung der Controller im eingebauten Zustand? Also >ich denke, wenn mal ein Firmwareupdate notwendig ist, wäre es ja >ziemlich lästig, sich an jeden Controller einzeln anstöpseln zu >müssen... Das ist doch das Schöne am AVR, dass man sehr einfach selbst einen Bootloader schreiben kann. Updates werden natürlich über den Bus eingespielt. Nach Einschalten der Stromversorgung warten die Busmodule 2s auf einen Programmierbefehl. Danach wird das "normale" Programm erst verifiziert und dann gestartet (wenn Verify ok war). Jedes Modul hat (im Bootloader-Teil) eine fortlaufende Nummer (ähnlich den Adressen in Netzwerkkarten). >-> Relais 1). Das setzt aber voraus, dass in dem Sensor-Modul die >entsprechenden Befehle hinterlegt sind, um die passende Nachricht >auch an das entsprechende Aktor-Modul zu senden. Wenn sich nun aber >mal die Zuordnung ändern soll, weil z. B. nicht nur Relais 1, sondern >auch Relais 2 geschaltet werden soll, dann müßte doch das >entsprechende Sensor-Modul neu programmiert werden, oder? Programmiert ist vielleicht der falsche Ausdruck. Eher neu parametrisiert. Denn am Programmcode muss man deshalb natürlich nichts ändern. Jede Funktion kann bis zu 16 Nachrichten an beliebige Empfänger schicken. Die Parametrisierung der Funktionen erfolgt über den Bus. Auch welche Funktionen eine Busmodul realisiert, wird parametrisiert. Pro Busmodul sind 32 Funktionen möglich, das können z.B. sein: * Lichtschalter * Jalousieschalter * Relais einfach (.z.B. für Licht an/aus) * Relais zweifach (z.B. für Jalousie hoch/runter) * Temperaturfühler * Heizungsventilsteuerung (inkl. Regelung) * Displayansteuerung In jedem Busmodul ist dabei die Software für alle diese Funktionsmöglichkeiten bereits enthalten. Jedes Busmodul kann also dieselbe Software besitzen, egal ob nun Lichttaster oder Relais angeschlossen sind, nur die Parametrisierung ist unterschiedlich. @Josef: Das Problem, was ich mit Instabus/EIB etc. habe, ist einfach, dass es ein ziemlich geschlossenes System ist. Beispiel: ich habe eine Lüftungsanlage mit 14 möglichen Stufen im Haus. Die würde ich gerne über den Bus anschliessen. Bei Insta/EIB wird das schwierig oder teuer (weil spezielles EIB-Lüftungsgerät notwendig).Beim eigenen Bus schreibst Du ein entsprechendes Software-Modul dazu und steuerst die Lüftung genau so an, wie Du es haben willst, inkl. Anzeige auf einem Display, falls gewünscht. ... natürlich muss einem das auch Spass machen ... Viele Grüße, Stefan
Hallo Stefan, ich habe noch nichts mit dem Bootloader angestellt. Klingt aber interessant, dass man dort schon über Kennungen entscheiden kann, ob der entsprechende Controller programmiert werden soll oder nicht. Muss ich mir unbedingt mal ansehen. Hast Du da eine Vorlage benutzt oder einen völlig neu geschrieben? >Die Parametrisierung der Funktionen erfolgt über den Bus. Auch welche >Funktionen eine Busmodul realisiert, wird parametrisiert. Also sendet irgendwer (ich nehme mal an, ein PC) an irgendwen (Busmodul) z.B. eine Nachricht mit neuen Parametrierdaten. Das Busmodul erkennt, dass das jetzt eine "Parametrierdaten-Nachricht" ist und speichert die Daten intern (im EEPROM?) ab, richtig? Hat dann noch jemand die Übersicht, wer was macht (z.B. in Form einer Tabelle)? >Jede Funktion kann bis zu 16 Nachrichten an beliebige Empfänger >schicken. Dass es verschiedene Funktionen gibt und z.B. eine Funktion für einen Lichtschalter intern anders funktioniert als für einen Temperaturregler ist klar. Aber wieso bis zu 16 Nachrichten pro Funktion? Gibt es nicht einfach jeweils eine Steuer-Nachricht: "Mach-Was(-mit-Sollwerten)" und eine Status-Nachricht: "Bin-Fertig(-mit-Istwerten)"? Viele Grüße Joline
Ist ja schon interessant, mit was für Kanonen hier auf Spatzen geschossen wird. Für Hausautomation sind die meisten Bussysteme Overkill. Die erzielbaren Geschwindigkeiten sind völlig unnötig (muss man auf die Änderung einer Raumtemperatur binnen 1 msec reagieren können?), die Anforderungen an die Verkabelung sind extrem und der Protokolloverhead ist auch nicht ohne. Aus der Gebäudeautomatisierung kenne ich ein - proprietäres - Bussystem, das erfolgreich eingesetzt wird und doch banal simpel ist. Verwendet wird RS422 mit galvanisch getrennten Sendern/Empfängern. Der Bus ist eine Zweidrahtleitung und kann bis etwa ein km Länge relativ beliebige Verdrahtungsformen annehmen. Das geht dank der Beschränkung auf eine sinnvoll niedrige Datenübertragungsrate, nämlich 9600 Baud. Ein entsprechend sparsames Protokoll (mit Fehlerüberwachung) und ein Master, der zyklisch alle Geräte am Bus pollt, genügt vollends. Das Protokoll kann trotzdem simpel genug gehalten werden, daß mit Controllern der MCS51-Reihe gearbeitet werden kann. Datenreduzierend wirkt sich eine Änderungsauswertung im Controller aus - der sendet auf Anfrage entweder "nix los" oder aber die geänderten Daten. Da meistens nichts los ist, können so trotz Pollverfahren und niedriger Datenrate Reaktionszeiten im Bereich von 1-2 sec erzielt werden - was für Heimautomation genauso genügen sollte, wie es für Gebäudeautomation im industriellen Bereich genügt.
@Rufus: RS485 habe ich vor einem Jahr auch mal in Erwägung gezogen, lese einfach mal den ganzen Thread durch. Warum mit Kanonen auf Spatzen? Den CAN-Bus kann man beliebig in der Baudrate einstellen, von 20kbaud (beim MCP2515) bis 1Mbaud. Ist ja niemand gezwungen, ständig Vollgas zu fahren ... RS485 ist auf dem physikalischen Layer übrigens sehr mit CAN verwandt, in den CAN-Anfängen wurden teilweise auch RS485-Treiber verwendet. Dass RS522/485 für beliebige Bustopologien spezifiziert ist, wäre mir neu, bei 9k6 wird das wohl gehen, aber sicher nicht innerhalb der Spec (auch CAN dürfte bei niedrigen Baudraten mit einer Sterntopographie wohl laufen). Ein Master/Slave-System finde ich nicht sehr sinnvoll, schon allein wegen dem ständigen Busbetrieb (Master muss ständig alle Slaves nach Infos pollen). 1-2 sek Verzögerung wenn ich auf den Lichtschalter drücke, ich sehe meine Frau schon genervt den Elektriker rufen, um konventionelle Kabel einziehen zu lassen ... Multimaster auf RS485 funktioniert übrigens auch auf RS485 (Kollisionserkennung per Software), ist aber mit zusätzlichem Software-Aufwand verbunden. Viele Grüße, Stefan
Hallo Stefan, hast Du vielleicht mein Posting weiter oben wegen des Einwurfs von Rufus übersehen? Es interessiert mich schon, wie das funktioniert. Joline
Hallo Joline, keine Angst, ich habe Dich nicht vergessen - die andere Antwort ging einfach schneller, und heute mittag hatte ich nicht soviel Zeit - so langsam geht unsere Baustelle in die heisse Phase ... >ich habe noch nichts mit dem Bootloader angestellt. Klingt aber >interessant, dass man dort schon über Kennungen entscheiden kann, ob >der entsprechende Controller programmiert werden soll oder nicht. >Muss ich mir unbedingt mal ansehen. Hast Du da eine Vorlage benutzt >oder einen völlig neu geschrieben? Was der Bootloader letztlich genau macht, kannst Du völlig frei wählen. Im Prinzip ist es ein Programm wie jedes andere auch. Der Booloader startet direkt nach dem Reset, initialisiert dann zuerst den CAN und wartet dann 2sek auf einen Programmierbefehl. Eigendlich recht simpel. Es gibt bei Atmel einige App-Notes, die sich damit beschäftigen, und hier im Forum hat Peter Danegger einen veröffentlicht. Vorlage ist das richtige Wort, ich schaue mir solche Programme gerne an und schreibe dann meinen eigenen Code. Das Rosinenprinzip sozusagen. >Also sendet irgendwer (ich nehme mal an, ein PC) an irgendwen >(Busmodul) z.B. eine Nachricht mit neuen Parametrierdaten. Das >Busmodul erkennt, dass das jetzt eine "Parametrierdaten-Nachricht" >ist und speichert die Daten intern (im EEPROM?) ab, richtig? Hat dann >noch jemand die Übersicht, wer was macht (z.B. in Form einer >Tabelle)? Eigendlich schwebt mir ein komfortables PC-Programm vor, mit dem die Parameter-Daten aller Module editiert und verwaltet werden. Bis jetzt ist es aber noch nicht so weit. >Dass es verschiedene Funktionen gibt und z.B. eine Funktion für einen >Lichtschalter intern anders funktioniert als für einen >Temperaturregler >ist klar. Aber wieso bis zu 16 Nachrichten pro Funktion? Gibt es >nicht einfach jeweils eine Steuer-Nachricht: >"Mach-Was(-mit-Sollwerten)" und eine Status-Nachricht: >"Bin-Fertig(-mit-Istwerten)"? Ein Lichtschalter kann ja u.U. mehrere Lampen schalten. Für jede schickt er dann eine eigene Nachricht los. Eigendlich ist der CAN aber genau andersherum gedacht: Wird z.B. ein Lichtschalter gedrückt, dann schickt er eine Nachricht los und alle, die es wissen wollen, reagieren diese Nachricht. Es ist einfach eine Frage der Sichtweise: sehe ich es vom Standpunkt des Lichtschalters: welche Lampen soll er alle schalten können? -Oder vom Standpunkt der Lampe: von welchen Lichtschaltern (oder generell Ereignissen) soll sie geschaltet werden? Bei beiden Sichtweisen gibt es sicherlich Vor- und Nachteile. Es sind auch beide Varianten nebeneinander möglich und auch geplant: Nachrichten, die einen bestimmten Busteilnehmer adressieren und Broadcast-Nachrichten, die "an alle" gerichtet sind (falls die es interessiert). Bis jetzt läuft auch noch längst nicht alles (im Augenblick ist die Zeit einfach zu knapp - neben der Baustelle). Wenn alles läuft, werde ich es auch noch genauer dokumentieren und hier vorstellen. Viele Grüße, Stefan
Hallo Stefan, vielen Dank erst einmal für die Antworten. Ich bin nämlich gerade in der Planungsphase und da interessieren mich natürlich ganz viele Meinungen. Im Moment stehe ich noch ein bißchen auf RS485, weil das recht simple und preisgünstig ist und auch protokollmäßig ganz einfach zu handhaben. Wird ja auch in der Industrie häufig eingesetzt, z.B. mit Modbus-Protokoll. Aber - wie Du ja auch schon vor einiger Zeit - denke ich auch über CAN nach. Da muss eben nicht immer ein Master alle Slaves ständig pollen. Ist eigentlich schon besser, aber auch teurer. Vom Softwareaufwand habe ich noch keine Vorstellung. Sollte aber bestimmt auch nicht sooo schlimm werden. Joline
Instabus Minimalausstattung: 1 Netzgerät 180 4 Eingangsmodule je 4 Eingänge (16 Eingänge ) ca. 290 4 Schaltaktoren je 4 Ausgänge ( 16 Ausgänge) ca. 480 1 Kleinzeugs 50 Lüftung über Logo und Instabusgateway. Das andere im Selbstbau - damit auch Spaß aufkommt. Zeitfunktionen im Logo nützen (Zufallsbeleuchtung ect.) Eigenen CAN/485 Bus im Haus verlegen, damit man flexibel bleibt. Würde ein Ethernetnetzwerk mit einbauen, darüber kannst du telefonieren, CAN betreiben, PC und Internetten usw. Sieht auch fesch aus. Licht über Funk. War nur so eine Überlegung. SG Josef
Hallo Joline, was planst Du denn genau? >Im Moment stehe ich noch ein bißchen auf RS485, weil das recht simple >und preisgünstig ist und auch protokollmäßig ganz einfach zu >handhaben. >Wird ja auch in der Industrie häufig eingesetzt, z.B. mit >Modbus-Protokoll. >Aber - wie Du ja auch schon vor einiger Zeit - denke ich auch über >CAN nach. Da muss eben nicht immer ein Master alle Slaves ständig >pollen. >Ist eigentlich schon besser, aber auch teurer. Vom Softwareaufwand >habe ich noch keine Vorstellung. Sollte aber bestimmt auch nicht sooo >schlimm werden. RS485 kannst Du übrigens auch ohne Master betreiben. Kollisionen werden erkannt, indem ein sendendes Modul die empfangenen Daten mit den gesendeten Daten vergleicht. Gibt es Differenzen, dann liegt eine Buskollision vor, und der Datentransfer muss später wiederholt werden. Ähnlich läuft es ja auch bei CAN, da macht das eben schon die Hardware, und: bei CAN gibt es bei Kollisionen einen Gewinner, d.h. das Bustiming wird durch eine Kollision nicht belastet. Bei RS485 müssen dagegen beide die Übertragung wiederholen. Das sollte bei den wenigen Daten auf einem Hausbus aber kein Problem darstellen. zu den Kosten: einen Treiber brauchst Du in jedem Fall, ob CAN oder RS485 ist preislich fast gleich. Als CAN-Controller benutze ich den MCP2515, den bekommst Du für unter 2, wenn Du ihn nicht gerade einzeln bestellst. CAN gibt es übrigens auch rein in Software. falls Dir der CAN-Chip zu teuer ist: http://caraca.sourceforge.net/#intro War mir persönlich die Preisersparnis aber nicht wert Viele Grüße, Stefan
Zum Thema "Licht über Funk" möchte ich noch auf die recht interessanten fremdenergiefreien Piezo-Funk-Lichtschalter von Siemens (wenn ich mich nicht täusche) hinweisen. Das ist im Gegensatz zu allen anderen Funklösungen sehr interessant, weil sämtliche im Schalter benötigte Energie aus der Energie der Schalterbetätigung entnommen wird und so keine Batterien oder sonstige Stromversorgung erforderlich ist. Ist leider schweineteuer, das Zeug.
"bei CAN gibt es bei Kollisionen einen Gewinner, d.h. das Bustiming wird durch eine Kollision nicht belastet. Bei RS485 müssen dagegen beide die Übertragung wiederholen." Genau das ist der Kasus Knacksus ! Bei CAN wiederholen alle, sobald der Bus frei ist und der nächste gewinnt usw. bis jeder fertig ist. Bei RS485 muß man dagegen eine variable Wartezeit so einlegen, daß eine weitere Kollision möglichst unwarscheinlich scheint. Du darfst also nicht einfach die gleiche Software mit der gleichen Wartezeit benutzen. Z.B. die Wartezeit aus Pseudozufallszahl + Deviceadresse + Chiptemperatur oder so. Es gibt ganze Abhandlungen und Doktorarbeiten über die Optimierung der Kollisionswiederhohlwartezeit. Die Arbitrierung beim CAN erlaubt außerdem die Priorisierung von Nachrichten. D.h. auch wenn auf dem Bus ständig was am Sabbeln ist, werden höherpriorisierte Nachrichten einfach dazwischen geschoben. Je mehr ein dominantes Bit (0) am Anfang des Identifier ist, umso höher priorisiert ist diese Nachricht. d.h. der Identifier 0x00000000 hat die absolut höchste Priorität und 0x1FFFFFFF die geringste (CAN2.0B). Es gibt aber eine Fallgrube beim CAN: Wenn zufällig 2 Nachrichten an den gleichen Empfänger (gleicher Identifier) gesendet werden, kommt es zu einer echten Kollision im Datenpaket. D.h. es gibt keinen Gewinner mehr und beide versuchen es so oft, bis der Fehlerzähler überläuft und sie sich abschalten. Aber da hilft der Trick, daß man einfach im Identifier die Senderadresse mit überträgt und die sollte ja immer unterschiedlich sein. Peter
Hi alle man kann sich ja auch gedanken über ein Funk System machen. Empfänger und Sender mit MC ok aber wahrscheinlich werden die Endgeräte ein Problem sein. Grüße Andi
Hallo Stefan, >was planst Du denn genau? Mal was ganz Neues: Eine Hausautomation. ;o) Ich bin aber wie oben schon erwähnt, noch in der Planungsphase. Ich habe schon mal probehalber auf dem Schreibtisch einen Modbus-Slave auf RS485 laufen. Aber immer mehr tendiere ich doch zu CAN. Wenn man da z.B. den MCP2515 nimmt, dann hat man ja sogar noch die UART als Debug-Schnittstelle frei (Ich trace anfangs gern mit, was da so auf dem Controller passiert ;o) ). Insgesamt stelle ich mir eine Lösung vor, bei der es nur sehr wenig verschiedene Hardware gibt, z.B. ein Eingabe-Modul mit Analog- und Digitaleingängen (sollte in eine Unterputzdose passen) sowie je ein Modul für digitale und eines für analoge Ausgänge. Prinzipiell sollte auf jedem Modultyp die gleiche Software (Firmware) laufen, so dass man ein Modul ohne spezielle Programmierung austauschen kann. Was das Modul dann tatsächlich macht, soll nur von einem PC aus konfiguriert werden. Joline
Hallo Joline >z.B. den MCP2515 nimmt, dann hat man ja sogar noch die UART als Beim MCP2515/2510 handelt es sich um einen SPI<->CAN Controller ohne eigenen Prozessor, daher würde ich eher einen PIC18Fxx8 hernehmen. Dieser verfügt über einen integrierten CAN-Controller und ist self-programmable. Über einen Bootstrap-Loader lässt sich so eine Firmware via CAN neu einspielen. Soweit es geht würde ich den CAN-Bus immer der Low-Level-RS485-Kommunikation vorziehen. Der Mehrpreis kann fast vernachlässigt werden und der Software-Aufwand reduziert sich dramatisch. Ich selbst plane gerade ein kombiniertes System aus Powerline und CAN. Dabei werden Sensoren und Aktoren (Schalter und Lampen) über einen ATtiny/PIC12.. und einem Powerline-Modem(TDA5051) in die Netzleitung eingekoppelt. In jedem Stromkreis sitzt dann ein 'üppiger' Mikrocontroller(68HCS12) als Master, der die jeweiligen Sensoren und Aktoren koordiniert. Diese 'üppigen' Mikrocontroller sollen dann über CAN vernetzt werden. Das ganze hat den Vorteil, dass ich eine konvetionelle Installation schrittweise (...wie's der Geldbeutel mitmacht), durch ein Bus-System ersetzen/erweitern kann. Die ungelösten Probleme hierbei sind noch die Baugrösse der Sensor-/Aktor-Elektronik (UP-Dose/Baldachin) und die Trennung der Kommunikation der Stromkreise über ein Sperrfilter. Vieleicht hat da jemand eine Idee ??? Gruss, Peter
Hallo Leuts! Erst mal an alle: wg. Spam habe ich meine email-Adresse geändert: s.o. Also der Thread hier hat sich ja prächtig entwickelt. @Stefan: wie siehts denn mit Deinem Häusle aus? Kannst mir ja mal ein paar Fotos per pm senden... Meine Hütte kannste übrigens hier sehen: http://www.bauerbaut.de/16.0.html Draufklicken vergrössert das Bild. (Die Website hab' übrigens ich für das Bauunternehmen gebastelt). Und was macht Dein Bus: läuft alles nach Plan? Meld' Dich mal! Grüsse emax
also nur mal vorweg solche steuerungen (egal was auch immer gesterut werden soll) sind mit allem zu realisieren. für die haustechnik jedoch gibts es bestimmte systeme welche seit jahren angewendet werden. zu diesen zählen: eib, sps, logo, simatic (k.a. ob´s richtig geschrieben ist), dann gibts haufenweise feldbussysteme usw. aber mit "lächerlichen" avr´s lässt sich auch einiges / alles realisieren was so in den steur und regelungsbereich in bauten fällt. und nur mal so nebenbei: beim eib wirst du keine chips bekommen, sondern fertige module. jedoch wirst du die ohne nötiger kenntniss und vorallem deren software (preis für die software liegt bei 833) nicht programmieren können mfg ralf
Hallo Emax! sorry für die späte Reaktion, aber im Moment habe ich nicht ganz die Ruhe, zu schreiben ... Vor ein paar Wochen war Einzug, der Hausbus läuft zwar schon rudimentär, aber fertig ist was anderes. Irgendwie habe ich dieses Jahr viel weniger Zeit als notwendig wäre .. aber das haben mir ja schon etliche Leute hier vorausgesagt. Ich habe mal ein Bild von der Buskoppler-Platine angehängt. Mehr kommt demnächst. Viele Grüße, Stefan
Hallo Stefan! Mann Mann! Das sieht ja klasse aus! Voll professionelles Teil, Kompliment! Machst Du sowas eigentlich beruflich? Ich denke, da were ich noch mal per PM auf Dich zukommen.... Beste Grüsse und guten Rutsch! Edgar
@ Stefan Kleinwort Hm ..... ich will ja jetzt nichts sagen, aber hast du die selber gemacht ?????????????????????????????? Ich frage so blöd, weil diese Platine komplett identisch mit dem Merten EIB Busankoppler vom Octocolor-Programm gleicht ....... Und wenn man mich fragt (bin übrigens ausgebildeter EIB - Profi) ist diese Ähnlichkeit zum Original doch sehr bedenklich .....
@Ralf "Ich frage so blöd, weil diese Platine komplett identisch mit dem Merten EIB Busankoppler vom Octocolor-Programm gleicht ..." Optisch? Oder elektronisch? Also optisch ists völlig wurscht: Unterputzdosen sind nun mal rund und deshalb die Platine eben passend gesägt, Chips sind nunmal schwarz und Platinen in der Regel nun mal grün. Hm. Wäre ja echt ne Überlegung wert, sich dieses Design (schwarze chips, grüne platinen etc) mal ganz allgemein schützen zu lassen ;-D Unn eleggdronisch isses hoid scho a bisserl anders, gäi? Das ist CAN, kein EIB .... Aber tolle Arbeit, wirklich. Vielleicht kannste ja mal ein Bildchen von der Rückseite schicken ...? emax
Hallo Stefan, sieht ja Klasse aus. Wie machst Du eigentlich einen Firmwareupdate? Direkt über den CAN-Bus oder musst Du dann doch wieder jede Dose öffnen? Wenn das über den CAN-Bus geht, kannst Du da vielleicht mal ein Codebeispiel posten wie das dann so funktioniert? Danke Hans
@Hans: am Firmware-Upgrade programmiere ich im Moment. Jeder einzelne Knoten hat bei mir exakt dieselbe Software. Was ein Knoten genau macht und wem er was signalisiert, wird über ein Parameterfeld festgelegt. Deshalb kann auch der gesamte Bus "in einem Rutsch" upgedated werden. Aber wie gesagt, im Moment noch Baustelle -> im Moment sind nur die nötigsten Dosen bestückt, und der Bootloader muss demnächst in jeder Dose von Hand aufgespielt werden. @Emax: meinst Du mit Rückseite das Layout? Kann ich Dir gerne mal schicken, aber nur als Gerber-Files, viel mehr bekomme ich aus meinem ECAD nicht raus. Stefan P.S.: Für Trolle gibts übrigens das Heise-Forum.
@ emax also bevor du nur sch**** von dir gibst, rate ich dir mal dich genauer zu informieren - kann immerhin nichts dafür das du dich nüsse mit eib auskennst ..... bleda noob nur mal ne kurze erleuterung: der eib ist ein genormtes bussystem welches laufend von der instagruppe überwacht und kontrolliert wird. ebenso ist dieser für die entwicklung (und wen diese es nicht selbst entwickeln) für die überprüfung und normung zuständig. merten ist eine europaweit (mit sitz in deutschland) riesige firma welche sich mit unter normalen installationen der erzeugung von buskomponenten verschrieben hat .... diese eckige form der platine wird seit 1999 in den "octocolorsystemen" der firma merten verwendet. ebenso sind die buskomponenten der firma merten mit avr´s der firma atmel ausgestattet. weiters besitzen auch diese die nötigen can-bus anschlüsse um sie mit anderen systemen zu verbinden und erweitern ..... und bevor du jetzt nochmal so´n sch*** von dir gibst (und das auchnoch zweimal hintereinander) rate ich dir die klappe zu halten - immerhin bist du nicht auf den eib spezialisiert und hast ne irre lang ausbildung, noch wette ich das du nicht in brüssel auf dem ausbildungskurs warst, und außerdem glaub ich auch nicht das du sonst viel damit zu tun hattest weil sonst würdest nichtmal son schwachsinn geschrieben haben ...... also guter tipp: wenn man als noob schon was sagen will, dann wäre es von vorteil sich mal genauer damit zu beschäftigen bevor man die "bappen" aufreißt !!!
@Ralf: bevor Du hier noch ausfallender wirst: EIB-Buskoppler zeichnen sich in erster Linie dadurch aus, dass sie einen EIB-Chip onboard haben. Eckige Formen werden von all denen verwendet, die sich das Geld für runde Fräsungen sparen wollen. Und Atmels oboard - wow, das sollte sich merten wirklich patentieren lassen. Stefan
@Ralf Sonst gehts Dir gut? Les besser erst mal den ganzen Thread, vielleicht findste da auch was von mir, ein JPG-Bildchen meiner eigenen EIB-Installation etwa. Habe bislang so etwa 140 Teilnehmer in 3 Linien, eigenes Konzept, aber ja doch, selbst programiert, klaro .... Was uns voneinander unterscheidet ist mal mindestens die Tatsache, dass ich meine EIB-Installation auch ohne Ausbildung hinbekommen hab. Die Sache ist m.E. nämlich so simpel, dass die schweineteure Ausbildung vermutlich ohnehin nur von Leuten bezahlt wird, die's ohne nie gebacken bekämen. Fürs neue Jahr wünsch ich Dir ein bischen mehr Erleuchting. Bis denne emax
Ach - und was glaubst du wird wohl dein "EIB-Chip" sein ...... Das stimmt nicht ganz so wie du´s sagst: bei "normalen" Schaltern verwendet Merten immernoch quadratische Formen der Platine. Beim Octocolorprogramm wird diese eckige Form verwendet, da der ganze Schalter anders aufgebaut ist und so die Platine nichtmehr rein passen würde. Und außerdem habe ich ja nicht behauptet dass die Firmware die drauf ist noch die originale ist (weil die könnt sogar ich schon ändern, und ich bin ein totaler Elektronikneuling und somit selber ein verdammter Noob) habe nur behauptet das die Platine von der Firma zu stammen scheint - es ist sogar der Schaltplan komplett ident mit dem Schaltplan den ich vor mir liegen habe (eben von Merten) Aber ist ja sowieso egal ..... war nur ne interessensmäßige Frage. Immerhin habe ich damit schon lang genug zu tun ....
He Ralf: es ist CAN, nicht EIB!! Capito? @Stefan: oder hat Merten heimlich ein "CAN Over EIB" entwickelt, und wir alle wissen das nur noch nicht? MannMannMann...
@ emax also mal folgendes: du hast recht ich habe mir nicht alle pot´s durchgelesen - interessiert mich ehrlich auch nicht so wirklich. mit ist nur die platine ins auge gesprungen und hat mich verdammt an das zeug was bei mir im lager rumliegt errinnert - sogar der schaltplan ist ident mit meinem .... und außerdem muss ich dir gleich nochmal sagen halt die bappen wennst di net auskennst; erstens habe ich schon damit gearbeitet, als es noch keine kurse gab und das ganze system noch in kinderschuhen stand. zweitens werden diese jeweils dreimonatigen kurse sogar von spezialisten besucht, drittens zahlen das die firmen welche was auf ihre "profis" halten und zu den besten gehören wollen, und viertens dienen die kurse der weiterbildung weil es laufend neuerungen gibt, der entwicklung und verbesserung (vorschläge werden eingebracht) der gemeinsamen planung heikler projekte und mit heikel mein ich nicht ein lächerliches hochhaus mit 40 stockwerken planen - das könnt jeder vollidiot. könnte noch ewig weiter reden - aber du solltest lieber mal bei der firma merten in der entwicklungsabteilung rumstöbern bevor du was sagst. - ups hab ich vergessen, da darfst du nicht rein g naja schlag mal vor nicht weiter zu "streiten" weils sowieso sinnlos ist - außerdem war es ja nur ne "blöde" frage, das firmware geändert sein kann hab ich nie bestritten. dir auch noch ein schönes neues jahr ....
@A.Capone: Mann.. jetzt fällt es mir wie Schuppen aus den Haaren: da hätte ich mir doch tatsächlich die ganze 4-adrige Busverkabelung sparen können. Oder verwechsle ich jetzt auch schonwas? Stefan
Tja der Ralf. Bist' an Österricher oder waas? Unta dieesn Umständn kamma dia natüalich vezäihn! Füad di!
@Ralf "sogar der schaltplan ist ident mit meinem ...." 2 CAN-Controller hängen am SPI eines Atmel, die restlichen Portpins sind nach außen geführt und ein Spannungsregler ist mit drauf, sowie die obligatorischen CAN-Treiberchips. Die ganze Schaltung ist also sowas von 0815, die muß es einfach 100 mal oder mehr geben. Die Chips haben nun mal ihre Standardbeschaltung. Ich kann also auch nicht nachvollziehen, ob Du vielleicht was schlechtes gegessen hattest oder was. Peter
@Stefan, wenn Du auch über SPI programmieren willst, mußt Du noch an CS0 und CS1 Pull-Ups anschalten, sonst könnten sich die CAN-Chips angesprochen fühlen und das Download stören, da die Ausgänge ja beim Programmieren floaten. Insofern ist die Schaltung doch nicht ganz Standard. Peter
@Peter: ich programmiere immer über den JTAG-ICE, aber stimmt, falls das mal jemand nachbauen will, der kein JTAG hat, wären 2 R ganz nützlich. Wenn es nochmal ein Update gibt, werde ich sie mit reinsetzen. Viele Grüße, Stefan
Hallo zusammen, die Beiträge waren auch für einen Neueinsteiger sehr interessant. Bei all der Theorie habe ich jetzt aber mal ein paar Fragen zur praxis. Ich möchte über den Can Bus ein paar 8051er Systeme vernetzen. Ich habe bisher weder einen Schaltplan noch eine passen Software (möglichst Basic) gefunden. Kann mir jemand helfen? Guten Rutsch Tobias
Hallo an alle, also erstens vorne weg. Die Koppler-Platine gefällt mir auch gut. Habe aber trotzdem eine Frage. Bei EIB gibt es Dosen wo der Bus und die 230V getrennt sind. Zumindest habe ich das so in den EIB-Kursen die ich besucht habe gelernt. Daher die Frage, wie sieht es bei der Koppler-Platine mit der eigensicheren Trennung aus. ODer ist das nicht notwendig. Auf Grund einiger Beiträge direkt vorne weg. Ich habe mehrere EIB-Kurse besucht und habe auch die Zulassung die Dinger zu programmieren. Mich aber danach nicht mehr damit beschäftigt, daher nicht mehr so ganz im Detail drin. Kenne das aber auch aus Schaltschränken, das Kleinspannungen getrennt von 230/400V sein müssen. Danke für die Info. Grüße Andreas
Hallo Andreas, bei mir ist der Bus komplett getrennt von der 220V-Seite. Zu den Lichtschaltern gehen extra Leerrohre, der einzige Berührungspunkt ist im Schaltschrank. Dort werden im Moment nur Relais angesteuert, also kein Problem mit Potentialtrennung. Später will ich noch Dimmer einbauen, da muss eben auf eine normgerechte optische Trennung geachtet werden. Genauso beim Netzteil. Viele Grüße, Stefan
Moin, wir haben dieses Jahr (oder eher letztes ;) ) einen (relativ) neuen Gebäudebus kennengelernt. LCN Local Control Network Der Vorteil besteht, dass man die LCN Module direkt an 230V anschließen kann!!! Keine Netzgeräte mehr. Die Kommunikation zwischen den einzelnen Modulen geschieht über ! 1x 1,5mm² !. Es sind also keine extra geschirmten, getrennt verlegten Niederspannungsleitungen nötig. Die Installation ist auch recht einfach in tiefen Unterputzdosen findet ein Standartmodul spielend platz. Mit EINEM Modul sind schon folgende Sachen möglich: * zwei elektronischen Schaltausgängen 230V, je 300VA, dimmbar oder als Nullspannungsschalter * Tasteneingang für bis zu 8 Tasten oder A/D-Wandler * Impulsmeßeingang für Fernsteuerempfänger, Ereigniszählung * 100 Lichtszenen pro Ausgang verfügbar, jeweils mit programmierbarer Helligkeit und Rampe ( Änderungsgeschwindigkeit ) die Programmierung ist sehr einfach. (Ich hatte vorher noch NIE sowas in der Art gemacht, und nach 2-3h hatte ich meine erste Rolladensteuerung und Lichterinstallation auf nem Probekäfig programmiert) schau dirs mal an, www.LCN.DE
Hmmm, LCN ist proprietär, nur ein Anbieter. Wenn der pleite geht, dann ist es Essig mit dem Nachrüsten bzw. Instandsetzen. Ich würde das nicht riskieren, sondern lieber auf eine standardisierte Lösung setzen oder es selbst entwickeln.
Hallo Stefan, habe mir jetzt mal Deinen Schaltplan in Ruhe angesehen. Dort habe ich nirgendwo 230V entdeckt. Verstehe ich das richtig, daß sich in Deiner Schalterdose dann nur Kleinspannungen befinden? Wie machst Du es dann bei einer schaltbaren Steckdose? ODer wird die über ein Relais vom Schaltschrank aus angesteuert? Bin davon ausgegangen, daß sich das Busmodul auch in der Steckdose befindet. Zumindest bei EIB hat man die Möglichkeit. Wie verlegst Du Busleitungen und 230V. In demselben Schlitz? Wegen Störungen. Der Begriff "eigensicher" war Käse. Das hat was mit EX-Anlagen zu tun. Bin nicht auf den richtigen Ausdruck gekommen, aber Du hast ja verstanden was ich meinte. Grüße Andreas
@Andreas: wer lesen kann, ist klar im Vorteil. Les doch einfach mal die Antworten auf Dein e bisherigen Beiträge. emax
@Stefan Wäre es vielleicht möglich, das Layout als TIFF, PDF oder ähnliches (nicht Gerber) einmal hier zu posten? Danke Hans
@Stefan, wie hast du deine Buskoppler eigentlich verkabelt? Alles in einer Linie (den zweiten CAN port für Stichleitungen habe ich gesehen)? Oder gibt es eigentlich eine Art CAN-Hub? Mir persönlich wäre es lieber von zentraler Stelle sternförmig in die einzelnen Räume zu springen. So wäre im Fehlerfall nicht das ganze Haus dunkel :) Gruss, Michael PS. Schon mal dran gedacht aus deiner Basis ein Gemeinschaftsprojekt zu machen?
@Stefan, @Alle hast Du (habt ihr ), entgegen der offiziellen Definition, einen CAN-Bus schon einmal sternförmig verdrahtet? Ich habe es in meinem Haus so gemacht. An jedem Ende ( 20 Knoten ) habe ich den Bus mit 12K abgeschlossen. Die ersten 12 Knoten ( Erdgeschoss ) laufen seit 13 Monaten ohne Probleme. Bei der heute abgeschlossenen Erweiterung um 8 Knoten in einem weiteren Geschoss hatte ich erst Probleme. Nun wäre es interessant wenn auch andere schon einmal ausserhalb der Definition Erfahrung gesammelt hätten. Übrigens läuft mein Bus nur physikalisch als CAN ( 82C251 ). Das Protokoll ist auf meinem eigenen Mist gewachsen. Sowohl die unteren Layer, wie auch die Anwendungen laufen auf einem Mega8. Die neueste Version auch auf dem Mega168. Bernhard
Hallo zusammen, ich habe alle Beiträge sehr interresiert durchgelesen. Ich habe auch schon ein bischen über Hausautomation nachgedacht. Meine bisherigen überlegungen gehen aber eher auf Ethernet. Ja, ich weiß, das ist zwar ein bischen mehr Verkabelungsaufwand (CAT5, geschirmt, usw) und die Aktoren und Sensor-Platinen sind auch ein bischen aufwendiger aber die Möglichkeiten (finde ich) sind einfach riesig. Und auserdem gehe ich davon aus, dass in jedem neu gebauten Haus eine Ethernet-Verdrahtung vorgesehen bzw. Realisiert wird. Die Konfiguration der Teilnehmer wäre über ein WEB-Interface dann auch 'für die Hausfrau' möglich. Ein Externer Eingriff in den Bus währe mit einem einfachen PC möglich. Fast jede Programmiersprache hat die Möglichkeit sich per TCP/IP mit der Außenwelt in Verbindung zu sezten. Die Trennung zwischen verschiedenen Segmenten ist mit der Netz-Adresse auch leicht möglich. Besonders Inspiriert wurde ich von folgender Diplomarbeit: http://www.ifas.htwk-leipzig.de/easytoweb/php/download/Verwendung%20eines%208-bit%20Microcontrollers%20zur%20Ethernet%20Vernetzung%20in%20der%20Hausautomation.pdf Fast das wichtigste finde ich, dass das System Dezentral aufgebaut ist. Denn wenn der Master bei einem Zentralen System einmal ausfällt, dann läuft gar nichts mehr. Werde aber weiterhin 'dran' bleiben. Gruß, Florian
@Florian, habe ich auch drüber nachgedacht. Der Aufwand ist aber nicht zu rechtfertigen. Mit einem Ethernetmodul kommst du außerdem fast nicht in eine Steck- bzw. Schalterdose. Alleine der Stecker ist schon fast zu gross. Außerdem kann man an jedes andere Bussystem einen Webserver hängen. Somit sind die Vorteile von Ethernet relativiert. Ich habe einen Bus der mit nur einem Treiber, einem Microcontroller und etwas "Hühnerfutter" auskommt. Notwendige und realisierte Geschwindigkeit 10 KHz. Da liegt der Preis für ein 10 fach Tasterknoten unter 20 ( bei kleinen Stückzahlen ). Mit Ethernet wahrscheinlich Faktor 4 bis 5. Als nächstes wäre das Kabel zu nennen. Ich nutze billiges 4 adriges Telefonkabel. Auch hier liegt CAT5 im Preis wieder ganz weit vorne. Das Kosten- Nutzenproblem zieht sich durch den gesamten Bus. Bis dann Bernhard
Da der Thread schon ziemlich lang ist fänd ich's gut wenn man es in einem wiki zusammenfässt. ich hab schon eins angelegt, jetzt aber neu strukturiert: Can-Bus: http://www.mikrocontroller.net/wiki/CAN-Bus Hausbus: http://www.mikrocontroller.net/wiki/Hausbus CAN_als_Hausbus: http://www.mikrocontroller.net/wiki/CAN_als_Hausbus fänd es z.b gut wenn man die erfahrungen bei der verkablung usw. dort documentiert. Wenn jemand sein projekt documentieren will könnte er z.b.dort auch ne extra projektseite anlegen. @Bernhart: hab dich zitiert hof is o.k.
Sorry für die lange Verzögerung ... @Hans: Ich habe mal das Layout als pdf und noch ein paar Bilder angehängt. Folgende Bauteile-Werte haben sich mittlerweile geändert, sind aber noch nicht im Schaltplan upgedated: R1, R2 : 27k R20, R22 : 1,2k R23, R24 : unbestückt R19 : 0 Ohm bei Elko-C11 : 0,1 - 1 Ohm bei keramic-C11 R11-R18 : optional, normalerweise unbestückt IC1, IC2 : TI -230, 233, oder Maxim-3,3V-CAN-Treiber @Andreas: siehst Du richtig, 230V und Bus sind komplett getrennt. Natürlich geht das mit der Steckdose bei EIB theoretisch, wird aber nie jemand machen, weil viel zu teuer (für jede Dose ein eigener Koppler). @Michael: Ich finde das Risiko mit einem zentralen Hub für Totalausfälle wesentlich höher. Wenn bei mir ein Buskoppler kaputtgeht, dann funktioniert eben diese eine Funktion nicht mehr. Der Rest läuft weiter. Ev. läuft eine Stichleitung nicht mehr. Die CAN-Treiber sind so konstruiert, dass sie einen amoklaufenden Busteilnehmer automatisch abkoppeln. >PS. Schon mal dran gedacht aus deiner Basis ein Gemeinschaftsprojekt >zu machen? Wenn ich komplett fertig bin, will ich das Ganze mal gesammelt dokumentieren und ins Netz stellen. Wer vorher schon mitmachen will, kann sich gerne an mich wenden, allerdings bin ich im Moment zeitlich sehr knapp.. @Bernhard: wo war denn anfangs das Problem? Kommunikationsprobleme wegen längerem Bus? Dass CAN bei niedriger Baudrate auch sternförmig funktionieren sollte, dachte ich mir auch. Nur wollte ich mir langes Ausprobieren erparen, deshalb packte ich den 2.CAN mit drauf. @Florian: bei Ethernet sehe ich eine ganze Menge Probleme: * Stromversorgung der einzelnen Komponenten * rein sternförmige Verkabelung oder überall Switches stehen * Platz in UP-Dosen wird nicht langen * Preis! Bernhard hat sicher sehr realistisch geschätzt! @123: gute Idee. Werde gerne etwas reinschreiben, aber noch nicht gleich ... Viele Grüße, Stefan
Hallo, ok, ihr habt ich überzeugt, dass Ethernet ein bischen übertrieben, teuer und platzverschwenderisch ist. @Stefan Kleinwort: Das mit der Spannungsversorgung hätte ich über POE (Power over Ethernet) gemacht. Ist aber auch aufwendig, weil laut spezifikation die Spannung bis ~50V betragen darf. Das mit der Sternförmien Verdrahtung stört mich eigentlich weniger, denn ich will in meinem Haus eh in jedes Zimmer Ethenet legen, die Grundausstattung wäre also vorhanden. Müsste dann halt nur ein bischen größer ausfallen. Aber das ganze wird dann ja wieder um einiges teuerer. Ich werde mich in Zukunft mehr auf CAN konzentrieren. (Mache gerade meine Abschlussprüfung als Industrieelektroniker, danach will ich Studieren und erst dann ein Haus bauen. Hab also noch ein bischen Zeit.) Vielen Dank für die ganzen Hinweise, Tips u. Kritik. Gruß, Florian
@Stefan, >> wo war denn anfangs das Problem? Kommunikationsprobleme wegen >> längerem Bus? Ich bin mit dem Bus an seine Grenzen gestossen, da mir ein Modul des "alten" Anlagenteils eine Datenleitung auf Masse gelegt hat und die zweite Leitung konnte nur noch einen Pegel zwischen 0,7 und 2,1 Volt. Nachdem ich das endlich gefunden hatte lief der Bus sauber. Bernhard
Hallo emax habe das mit den Tpuarts gelesen, hätte Interessa an 4 Stück. Melde dich bitte, falls du noch nicht bestellt hast. ux55
Schau Dir mal LCN an. Ich baue seit mehr als 10 Jahren EIB. Sehr gut. Ich baue ebenfalls LCN. Sehr gut. Bussysteme haben Ihren Preis. Bieten aber Komfort ohne Kompromisse. Zentral oder dezentral, diese Bussysteme sind die Besten für den Heimbereich und Gewerbliche Anwendungen.
Hallo Stefan, gibt's inzwischen was Neues zu berichten? Du hattest ja vor einiger Zeit mal ein paar Bilder Deiner Busknoten hier eingestellt. Wie weit bist Du mit Deiner Software? Kannst Du vielleicht schon ein paar Codeschnipsel, die Dein prinzipielles Vorgehen verdeutlichen, hier einstellen? Wäre prima und würde bestimmt sehr viele interessieren. Joline P.S. Es muss ja nicht 100% alles funktionieren und lauffähig sein. Es reicht sicher schon, das Prinzip zu sehen.
Hallo Joline, die Basics funktionieren, aber das Administrieren des Systems ist noch nicht implementiert, bis jetzt müssen die Buskoppler zur Parametrisierung noch separat programmiert werden, für einen Bootloader und eine Parametrierung über den Bus habe ich bis jetzt noch keine Zeit gehabt. An der Doku hapert es (natürlich) auch noch ziemlich, trotzdem hänge ich den Source mal dazu, sorry, wenn der Code noch etwas unaufgeräumt aussieht. Viele Grüße, Stefan
Hallo Leute, mir fällt auf das hier im Gros der EIB-Bus stark vorgezogen wird. Man stelle sich folgende Fälle vor. 1. Der Elektriker nimmt die Projektierungsdiskette/CD-Rom mit, oder die Daten gehen irgendwie verloren (alles schon passiert). Dann besteht theoretisch mit der ETS keine Möglichkeit mehr einen Eingriff in der Anlage vorzunehmen. Es gibt ein Auslesemodul es nennt sich -Rekonstruktion-, das haben wir uns mal besorgen müssen und hat damals schlappe 500,00DM gekostet. Was solls? Dieses Modul arbeitet extrem langsam, da es die Datenbankapplikationen fast sämtlicher Hersteller mit sich rumschleppen muß. 2. Ein Modul z.B: 2-fach Taster von Jung Bj. 1994 stirbt im Jahre 2002, so wirklich geschehen, kann ja auch vorkommen. Also denkt man kein Problem, neues Modul holen einbauen Software rein und gut. Nee stimmt nicht. Der Ablauf heißt Modil holen, neu Applikation im Internet besorgen, Gruppenadressen und Eigenschaften neu programmieren dann in Anlage übertragen. Zeitfaktor gegenüber LCN ca. mal 2. Zusätzlicher Nachteil sind für mich die hohen Ausbildungs- und Softwarekosten, jedes update muß gegen den Einwurf von Münzen eingekauft werden. Zum LCN folgendes. LCN ist proprietär, das stimmt, hat auch seine Vorteile, man hat immer die gleichen Ansprechpartner und ich muß sagen die Leute in der Hotline sind absolut kompetent. Achja wer kennt übrigens eine EIB-Hotline die nicht herstellerbezogen ist? Ich nicht. Außerdem hat meines Wissens nach Hr.Issendorf ein Konstrukt aufgebaut, das solche Fälle wie Insolvenz oder Ableben des Inhabers abfängt. Wie das genau aussieht kann und darf ich hier nicht schreiben, da mir die genauen Insiderinfos und die Erlaubniss hierzu fehlen. Aber eines ist sicher, die Investitionssicherheit ist ähnlich der Sicherheit zum EIB und wächst ständig. Zu den o.g. Themen bei LCN ist die Parametrierung in den Modulen gespeichert und kann auch ausgelesen werden, außerdem ist es möglich mit der LCN-Pro (Software ca 760,00€) die Daten auf Datenträger zu bannen. Zu den Kosten. Man bezahlt einen Grundkurs für 250,00€ Dauer 10std der sollte schon absolviert werden um den Grundgedanken zu verstehen. Gesamtkosten 1010,00€. Die Kosten bei EIB sind Software (professional) 895,00€. Die Starterversion 149,00€ (würde mir nicht genügen)700,00€ 40std Gesamtkosten 1595/ 1044€ Der Gewerbetreibende muß jetzt noch die Ausfallkosten während der Unterrichtszeit hinzurechnen. Ich möchte nicht das ein falscher Eindruck entsteht, ich war früher ein erbitterter Gegner des LCN-Systems, musste aber mit der Zeit meine Meinung wirklich ändern. Was für mich noch gravierender Nachteile sind, ist zum einen die fehlende Ethernetschnittstelle, dies kann mittels OPC-Server realisiert werden, ist aber teuer und umständlich, sowie die Auslesegeschwindigkeit der Software LCN-pro. Daher mach ich auch heute noch 60% meiner Progs. mit der DOS Version. Die Auslesegeschwindigkeit soll mit der Pro3 angeblich gesteigert werden. Bin mal gespannt. So ich hoffe einige Infos die zum Nachdenken anregen vermittelt zu haben. Wer noch Fragen hat kann mich unter meiner E-Mail Adresse erreichen. m.f.G Uwe Manz
Anmerkung zur Info in meinem obigen Beitrag werden folgende Zeichen angezeigt - € -. Dies soll dem Eurozeichen entsprechen. Ciao Uwe
hallo, wie wäre es hiermit: http://www.dicomm.de/buildnet/bnwc.htm das gesamte system ist bedienbar über: pc-browser pda handy telefon etc. keine besonderen aktoren, sondern standard-kompnenten
Hallo Ihr, Ich mache gerade eine Projektarbeit in der Schule und bin dabei einen IPC chip von der Fa. Beck an eine sja1000 controller anzubinden. Jetzt ist folgendes ich habe eine kleine Platine entwickelt die mit einem CAN-Bus versehen ist. Ich bekomme von einem externen Kältegerät Daten zugesende. Diese Temperaturdaten werden eingelesen und ich sollte sie via Paket(Programm) zu dem IPC-server weiterleiten. So nun bin ich nicht gerade fit im progammieren von Borland c. Ich muss zum einen ein Programm schreiben das es mir ermöglicht das Datenpaket von dem sja1000 an den server weitergeleitet wird. Was für Befehle benötige ich überhaupt und wie kann dieses Paket auf den Ipc senden. Habe keine Ahnung wie dies anlaufen soll. Genauso wenig Ahnung habe ich ein Programm zu schreib um die Daten von dem externen Kältegerät auf meinen CAN-Bus zu empfangen...gibt es da bestimmte vorgaben...wie ich diese Daten einlesen kann...wie wird der CAN angesprochen...fragen über fragen. Also wenn irgendjemand hierzu mir vielleicht helfen kann wäre ich sehr erfreut darüber oder noch fragen dazu sellen kann falls er etwas nicht verstanden hat. Würde mich auf eine positive antwort freuen MFG Marc
Sieht schon interessant aus, aber da sind verschiedene Fragen zum WEB-Control 1. Wie werden die Module und deren Funktionen verknüpft ? 2. Wie ist die Verkabelung (wahrscheinlich nur im Stern ein Gerät)? 3. Beziehen sich die 4 Ampere belastbarkeit auf Gesamtlast oder pro Schließer und dann induktiv oder ohmsche Last (AC1/AC3)? 4. Ist es erlaubt hierüber Drehstrom zu schalten ? 5. Wie dimme ich normale Glühlampen ohmsche Last, doch nur über einen zusätzlichen Ferndimmer ? 6. Verschiedene Gehäuße? Auch uP Schalterdosen? Wie stehts mit Reiheneinbaugeräten. 7. Was sagt der VDE dazu? Ansonsten gilt wie oben erwähnt, wirklich interessant. Viel besser finde ich die Video- Sprechanlage übers LAN, das hätte ich schon öfters einsetzen können. Hast du sch on damit gearbeitet ??
Hallo Stefan, vielen Dank. Ich werd' mir das demnächst mal reinziehen. Dass noch nicht alles perfekt ist, ist doch klar (wenn man den Thread gelesen hat ;o) ). Aber mir geht es ja auch um das zugrundeliegende Prinzip. Übrigens, wie hast Du letztendlich Deine Elektroverkabelung gemacht? Alle Kabel in einen Schaltschrank (bzw. mehrere) und dort die Laststeuerung oder doch "herkömmliche" Verkabelung mit busfähigen Lastschaltern? Deine geplante Variante war ja ziemlich aufwendig und teuerer. Joline
Hallo Joline, alles geht in einen Schaltschrank. Die Lampen und teilweise die Steckdosen werden dort mit Relais geschaltet, die Lampen-Relais sollen im Sommer noch gegen Dimmer getauscht werden. Eigendlich wären mir mehrere kleine Schaltschränke ja lieber gewesen, aber der Elektriker, der die 220V-Seite bei uns verkabelt hat, hat sich dafür nicht recht erwärmen können -> ist so aber auch ok. Viele Grüße, Stefan
hallo uwe, 1. mit Java-module in html, wenn ein server eingesetz wird über apis 2. stern (strukturierte verkabelung) 3. induktive lasten, immer zwei relais sind gegenseitig veriegelbar (z.b. jalousie) 4. sowerit ich weiß > nein nur über externe schütze 5. es können nur dimmer, ll-vorschaltgeräte und elektronische halogen mit 0-10v steuereingang angesteuert werden. 6. ist in einen uP Abzeigdose eingebaut. als aktoren (z.b. schalter) werden schalter aus dem standard-programm verwendet. als thermostat wir ein poti genutzt. kann auf eine montageplatte montiert werden. 7. ist vde-gemäß viele grüße eddi
Hallo Eddi, danke für die Antwort. Hört sich für mich an , als ob das System nur bedingt einsetzbar ist. Großer Vorteil ist halt die Ethernet- Schnittstelle. Es hat aber meiner Meinung noch nichts mit einenm professionellen Bussystem zu tun, sondern hat eher den Touch einer Bastlerlösung. So haben andere aber auch angefangen und für eine Nischenlösung ist es vorab allemal gut. Verkaufen will die Firma offenbar wohl nicht. Hab schon mehrfach versucht dort anzurufen, geht keiner ran. Naja, wird schon noch klappen ciao Uwe
Hallo Stefan, mit Interesse verfolge ich das Forum, da ich in der Planungsphase unseres Einfamilienhauses stecke. Da mir der CAN-Bus programmiertechnisch bekannt ist, ist es besonders interessant, diesen als Hausbus einzusetzen. Gibt es die Möglichkeit, die Platinen Deines Busknotens (über Dich) zu beziehen? Viele Grüße, Andreas
Hallo Andreas, Sorry fürs Wartenlassen, ich habe mit der Installation meines neuen Rechners gekämpft ... ich kann Dir entweder die Produktionsdaten schicken (Gerber, das Layout ist auf TopCAD gemacht und dessen Daten sind nirgends anders zu gebrauchen) oder Dir ein paar Platinen aus der Testphase anbieten. Da muss man eine Leitung noch fädeln. Zu beachten: den MCP2515 habe ich im MSOP-Gehäuse verbaut, den gibts nicht um die Ecke bzw. bei Reichelt. Ich brauche aber auch noch ein paar, ev. kann man zusammen bei buy.microchip bestellen. Viele Grüße, Stefan
Ach ja, die neuere Platinenversion kann ich Dir leider nicht abgeben, weil die von der Anzahl bei mir gerade so aufgehen wird. Stefan
Hallo, per google bin ich auf Euch gestoßen. ich bin ein elektronischer Laie und beginne nächste Woche mit dem Hausbau. ich habe 13 Jalousien, 10 Rolläden, eine Markise und ein Fenster mit Elektromotr, welche ich über Zeit, Wind u. Licht Steuern möchte. darüber hinaus möchte ich gerne bei den Jalousien, welche in einem Wintergarten sind auf die ganzen Schalter verzichten, sondern hätte gerne eine Logik über eine Gruppenschaltung bzw. Einzelschaltung über nur ein paar Sterungsfunktionen ausgeführt. Kann mir da jemand helfen? Gruß Florian
Hallo *, ich habe einen Controler von AVR Atiny15 über SPI mit einem MCP2515 CAN bus Controler gekoppelt und das ganze mit zwei Triacs (jeder macht ca. 1 KW Schaltleistung) zur Steuerung meiner Rollos und Dunstabzugshaube versehen. Klappt besser als erwartet. Leider sind die Platinen gefädelt um man sollte eine vernünftige Platine haben. Preis ca. 20 Eu pro Modul! MFG Klaus
Ich hab da mal ne blöde Frage: Wenn ich so einen Hausbus installiere, d.h. z.B. Niedervolt Taster, die durch Elektronik (Relais) dann das Licht einschalten, irgendwo reinhaue (Schaltschrank, irgendwo anders), dann hab ich doch bei einem Brandfall sicher Probleme mit der Versicherung bzw. es ist zumindest nicht erlaubt, da ich ja kein geprüfter Elektriker bin.
@dave schau Dir die FS20- und FHZ1000PC -Komponenten an. Sind auch nicht so teuer und haben CE-Zeichen!!! Kannste auch noch die Heizung, Rolläden usw. beschalten. Schaltschrankmodule gibt es auch. 'nen Link für Erweiterungen gefällig? http://www.ip-symcon.de/ MfG
Hey zusammen! Ich plane auch gerade einen Hausbus auf CAN-Basis. Mich würde mal interessieren ob ihr mit euren schon laufenden System Probleme mit Störeinstreuungen bekommen habt. Nicht bezogen auf den Bus, da mach ich mir keinerlei Sorgen. Eher auf dem bis zu 30cm langen Leitungsstück vom "Buskoppler" zum Schalter (durch 3 UP-Dosen). Besonders würds mich bei Gewitter interessieren. Nich das ständig das Licht eingeschaltet wird nur weil ein Pin meinte nen Signal zu sehen (Induktionsspannung auf der Leitung durch Blitz z.B.). Software-entprellen is klar, aber habt ihr zusätzlich noch Hardware-Aufwand betrieben? Oder einfach nur die internen Pullups und gut? Stefan Kleinworts´ Hardware habe ich schon mal bewundert, läuft die schon? Problem in Bezug auf meine Frage? thx & greetz Danny
Hallo Stefan, inzwischen habe ich mir mal Deine HW und SW angesehen (Man müßte viel mehr Zeit haben...). Sieht ja schon ziemlich gut aus. Seit dem letzten Posten ist nun wieder eine ganze Weile vergangen. Läuft denn Dein System inzwischen einigermaßen zufriedenstellend? Gibt's denn vielleicht schon mal was Neues zu bewundern, z.B. mit Bootloader über CAN usw.? Noch eine Frage: Weiter oben schreibst Du, dass alle Buskoppler die gleichen Funktionen implementiert haben und nur über Parameter "gesagt" bekommen, was sie zu tun haben. In der tab.c werden dann die verschiedenen Buskoppler parametriert, oder? Wie funktioniert diese Parametrierung? Joline
Hi Danny, zum Thema Störanfälligkeit, Tastereingänge: ich frage die taster alle 20ms ab, wenn 3* "Taste gedrückt" gefunden wurde, akzeptiere ich den Tastendruck. Einen falsch erkannten Tastendruck habe ich noch nie feststellen können. Eine zusätzliche Hardware habe ich nicht verwendet, vorgesehen sind zwar zusätzlich Pullups, um die Tasteneingänge bei Bedarf niederohmiger als die intern vorhandenen Pullups machen zu können, bestückt habe ich die aber nicht. Störungen bei Gewitter o.ä. habe ich bisher noch nicht erlebt, es ist auch noch nie etwas kaputtgegangen (seit einem halben Jahr in Betrieb). Die einzigen Probleme, die ich habe: beim gleichzeitigen Schalten aller Jalousien (20 Relais gleichzeitig ein) steigt manchmal der Buskoppler im Schaltschrank aus. Um das zu verhindern, werde ich noch ein paar EMV-Massnahmen treffen und den Watchdog einschalten (den WDG schalte ich meistens erst ein, wenn das Projekt praktisch fertig ist, um Fehler nicht zu verdecken). Viele Grüße, Stefan
@ Stefan Kleinwort Vieleicht könntest du eien kleine Wiki-Artikel über deien Buskoppler schreiben. den Ganzen tread durchzulesen braucht ja Jahre.
Hallo Joline, den Bootloader habe ich leider immer noch nicht fertig. Im Moment läuft alles ganz ordentlich, aber ohne grossen Komfort, die Heizungssteuerung ist auch noch nicht drin, brauchen wir im Moment auch noch nicht ... ich hoffe, im August habe ich wieder mehr Zeit dafür. Die Software und ihre Parametrisierung beschreibe ich gerade - habe bitte noch etwas Geduld ... Viele Grüße, Stefan
Wer versucht hat, das Projekt zu übersetzen, ist vielleicht wie Joline am fehlenden Linker-Script-File bootloader_avr´5.x gescheitert. Sorry dafür! Im Anhang ist es nachgeliefert. Viele Grüße, Stefan
Hallo Stefan, ich habe gerade mal etwas intensiver über das Projekt nachgedacht. Dabei ist mir folgendes aufgefallen: Wenn ich das richtig in Erinnerung habe, hast Du in Deinem Haus ja eine Etagenverteilung. D.h. alle Kabel gehen erst einmal in einen Schaltschrank, werden dort zusammengeführt und entsprechend geschaltet. Deine Buskoppler-Platine hat aber die Ausmaße, genau in eine UP-Dose zu passen. Wieso eigentlich? Passieren nicht die eigentlichen Schalt- und Steuerungsvorgänge im Schaltschrank? Und dann könnte die Platine ja auch etwas größer ausfallen, oder? Joline
Hallo Joline, nein, ich habe in jeder Schaltergruppe einen Buskoppler. Ich möchte in einige UP-Dosen Displays einbauen (Graphik 132*64), um z.B. einen Raumthermostat realisieren zu können. Die Ansteuerung der Displays funktioniert auch schon, nur eingebaut sind sie noch nicht, weil die Mechanik eine ziemliche Bastelei ist (und ausserdem erst meine Werkstatt einigermassen eingerichtet sein muss). Im Schaltschrank benutze ich die gleichen Buskoppler mit einem druntergesetzten Relais-Modul. Viele Grüße, Stefan
Hallo Stefan, wenn ich das jetzt richtig verstehe, brauchst Du dann für einen "einfachen" Lichtschalter 2 Buskoppler. Einen in der Schaltergruppe in dem jeweiligen Zimmer und einen im Schaltschrank, der dann tatsächlich die Lampe(n) über Relais schaltet, oder? Joline
Die Aufteilung wird anders verständlicher: Ein Lichtschalter hängt an einem Buskoppler, richtig. Je nach Beschaltung könnte ein Koppler auch mehrere Tasten abfragen, entspricht dann mehreren Gebern, also: Lichtschaltern, Fensterkontakte o.ä. Ein Relais braucht auch einen Buskoppler. Welcher Lichtschalter dann das Relais ansteuert ist eine Frage der Konfiguration. Ergo: Je INPUT (z.B. Schalter) einen Koppleranschluss Je OUTPUT (z.B. Relais) einen Koppleranschluss Wenn man genau einen Schalter genau einer Lampe zuordnet, stimmt Deine Aussage. Das ist aber gerade nicht der Sinn des Busses: man hätte dann auch konventionell verkabeln können. Richtig ist, das ein Schalter immer an einem Koppler angeschlossen sein muss, um am Busverkehr partizipieren zu können, genau wie auch die Relais. aber die Zuordnung Schalter/Relais hat damit nichts zu tun. Es können auch 3 Lichtschalter im Haus EINE Lampe ( = Relais) ansteuern. Das wären dann z.B. vier Koppler: einen für das Relais, und je einer für einen Lichtschalter.
Hallo Joline, an den meisten Stellen habe ich 3 UP-Dosen übereinander. Hier mal die typischste Anordnung: In den unteren beiden Dosen befinden sich zwei 4-fach-Taster. Ich habe Berker-Taster verwendet, das Ganze sieht also aus wie 2 "normale" Doppel-Lichtschalter (oben muss es davon ein Photo geben). Damit kann man dann entweder 4 Jalousien steuern (rauf/runter) oder 8 Lampen oder eine beliebige Mischung aus beidem. In der oberen Dose sitzt ein Display, bedienbar über 4 kleine Taster , die das Display-Menu steuern (ist von der Mechanik her aber noch nicht fertig, Display-SW läuft schon). Zusätzlich ist neben dem Display noch ein Temperatursensor für dei Raumtemperatur eingebaut Diese ganze Einheit wird von einem Buskoppler bedient. Ich habe tiefe UP-Dosen verwendet, damit kann der Buskoppler hinter einem Schalter, Taster oder Display eingebaut werden. An manchen Stellen habe ich auch "analoge" Tastersignale über max. 4m bis zum nächsten Buskoppler geführt, wenn dort noch ein paar Eingänge frei waren. Im Schaltschrank sitzen im Augenblick 3 Module, die jeweils 24 Relais ansteuern. Jedes Modul hat einen Buskoppler. Ein Buskoppler im Schaltschrank bedient also bis zu 24 Lampen-Relais oder 12 Jalousien (je 2 Relais), oder eine Mischung aus beidem. Später sollen die meisten Lampenrelais durch Dimmer ersetzt werden. Was genau ein Buskoppler macht, kann per Parameter eingestellt werden. Ein Buskoppler kann bis zu 32 verschiedene Funktionen (Taster, Temp.Sensor, Relais-Ausgang) übernehmen, wobei diese Zahl im Grunde beliebig ist. Demnächst kommt - ganz ehrlich - eine anständige Doku, im Moment bin ich aber mit Garten- und Terassenarbeiten ziemlich ausgelastet, sorry ... Viele Grüße, Stefan
@emax Das war ja auch nur ein Beispiel, um mal nachzufragen, ob ich das richtig verstanden habe. Ich hatte erst gedacht, ein Buskoppler handelt Ein- und Ausgänge. Dann allerdings wäre der Bus recht sinnlos geworden (Ausser als Verbindung zwischen den Unterverteilern). @Stefan Dann hast Du also pro Zimmer (meistens) genau einen Buskoppler, der die Eingangssignale einsammelt und Ausgänge werden nur von den Buskopplern im Schaltschrank geschaltet. Macht ja auch Sinn. Setzt allerdings auch voraus, dass die Buskoppler alle vorhanden sind und gewisse Grundfunktionen beherrschen, bevor man einzieht. ;o) Ich würde eigentlich lieber erst einmal alles hart verdrahten und dann Schritt für Schritt mit Buskopplern ausstatten (Man will ja auch nicht ständig im Dunkeln sitzen ;o) ). Aber dafür ist mir auch noch keine vernünftige Lösung eingefallen. Das mit den verschiedenen Funktionen der Buskoppler muss ich mir noch mal genauer in der SW anschauen (siehe auch weiter oben). Habe aber leider auch nicht so viel Zeit... Joline P.S. "Demnächst kommt - ganz ehrlich - eine anständige Doku, ..., sorry" - Du musst Dich nicht entschuldigen. Ist ja schon prima, dass Du Deine Erfahrungen hier im Forum einbringst.
@Stefan: Du hast ja die Intelligenz deines Systems auf alle Knoten verteilt. Hast du vorher mal drüber nachgedacht die einzelnen Knoten eher "doof" zu machen und dafür eine Art "Master" zu nutzen. Ich Frage weil im Falle einer Erweiterung/Änderung müsste ja jeder Knoten den´s betrifft ein neues Programm erhalten. Auch wenn du nun im Normalbetrieb nur parametrierst, sind dort ja zukünftige Erweiterungen noch nicht programmiert, oder? Ich bin am überlegen ob ich die Schalter etc. nur die veränderten Signale stur zu einem Zentralgerät senden lasse. In diesem würden dann die Verknüpfungen stattfinden und der Befehl zum Ausgänge setzen o.ä. gesendet werden. Ich muss dann zwar zwei Telegramme senden statt nur eines (Schalter->Master, Master->Ausgangskarte) aber bräuchte jede beliebige Änderung/Erweiterung nur auf dem Zentraldings ändern... Hattest mal über sowas nachgedacht? Oder sonstige Anregungen?
Wenn ein neues Gerät hinzukommt, muss nicht jeder Knoten neu programmiert werden: nur diejenigen Knoten, die das neue Device ansprechen, müssen neue Informationen erhalten, also z.B. die Taster, die ein neues Relais schalten müssen, müssen auch dessen Adresse kennen. Und die müssen dann ohnehin neu programmiert werden. Alle anderen tun weiterhin das, was sie auch bisher getan getan haben: Datenpakete schicken, die von denjenigen Teilnehmern umgesetzt werden, die angesprochen sind. Stell es Dir vor, wie ein Computernetzwerk: wenn im Internet ein neuer Rechner angeschlossen wird, müssen das auch nicht alle wissen, nur diejenigen, die darauf zugreifen wollen.
[Single-Master Konzept]
> Hattest mal über sowas nachgedacht?
Ich antworte mal, da ich mir über sowas auch schonmal "Gedanken"
gemacht habe:
Fällt dann aber der Master aus, dann stehste im Dunkeln. Fällt dagegen
nur der Lichtschalter aus oder nur eine Lampe, dann geht der Rest noch.
Deswegen macht man sowas nicht als SingleMaster-Syetem.
Und im Falle von Erweiterungen wärs keine Neuprogrammierung (die über
ein Programmiergerät o.ä. erfolgen müsste), sondern eine
Neuparametrierung, worauf die Knoten schon in ihrer Knotensoftware
vorbereitet sein könnten.
@Stefan: Hast du inzw. schonmal so eine Art Konfigurationssoftware
zusammengebastelt? Screenshot? Wie sieht das
Benutzerkonfigurationsinterface aus?
@emax: Das ist mir schon klar, aber wenn man sich Stefan´s Philosophie der einzelnen Knoten ansieht stellt man fest das alle Knoten alles können und nur durch Parametrierung angepasst werden. Und daher muß konsequenter Weise bspw. beim Hinzukommen einer weiteren Ausgabebaugruppe jeder Knoten auch ein neues Programm bekommen. Sonst hätte er sich den Umweg über diese Parametrierung ja sparen können. @and_ref: Ja das mit dem Ausfall ist halt der größte Nachteil, aber wenn beim EIB das Netzteil (oder unser speisendes Netzteil) aufraucht is auch Schicht im Schacht... :-) von daher denke ich das es immer einen wichtigen Punkt gibt der alles zu Fall bringt. Ich denke nur das eine Parametrierung die auch Erweiterungen (Hardware) umfasst sehr aufwändig sein muss... Ich hab schon mal versucht Stefan´s Lösung zu verstehn aber ich hab so meine Prob´s in umfangreichen C-Programmen ... :-) @Stefan: Kannst du evt. in kurzen Worten zusammenfasse wie deine Parametrierung prinzipiell läuft? Ordnest du über eine Art Tabelle jedem Schalter ein Ziel zu? (so sahs für mich auf den ersten Blick aus)
Dann formuliere ich mal anders: > stellt man fest > das alle Knoten alles können > und nur durch Parametrierung angepasst werden. Wenn ein neues Gerät hinzukommt, WAS muss denn dann bei den bereits installierten Einheiten angepasst werden? Die Frage ist doch: "kommt ein neues Gerät hinzu?", und nicht "kommt eine neue Funktion (i.e. Fähigkeit" hinzu?" Letzteres erfordert in der Tat eine Neuprogrammierung, aber nur für diejenigen, die die neue Funktion unterstützen sollen. Wenn beispielsweise als neue Funktion im System "Dimmen" hinzukäme, dann müssten in der Tat alle diejenigen Knoten neu programmiert werden, die das "Dimmen" beherrschen sollen. Das ist auch beim EIB nicht anders: es gibt dann eine neue Applikation für die betroffenen Bausteine. Der scheinbare Nachteil, mehrere Bausteine neu Programmieren zu müssen, beschränkt isch also wirklich nur auf solche Fälle, und da auch nur auf einzelne Bausteine. Selbst wenn man eine zentrale "Intelligenz" im Sinne eines Masters hätte, käme man um solche Einzelprogrammierung gar nicht herum, weil ja eine neue Funktion auch immer neue Fähigkeiten eines "finalen Konsumers" voraussetzt, soll heissen: am Schluss muss der Koppler am Ausgabegerät (am Aktor) die Dimmeinheit ja doch ansteuern, und entsprechend neu programmiert werden. Solche Steuersignale direkt von einem Master aus übers Netz an die Treiberendstufe zu senden wäre nun ganz schlechtes Design, sowas wird üblicherweis immer "vor Ort" eledigt, also im vorliegenden Falle im Schaltschrank direkt vom ansteuerneden Koppler. Das alle Teilnehmer "alles" können, ist als Option zu verstehen denke ich, und weniger als Voraussetzung.
@emax: mein Gedanke war das die eigentlichen Eingänge einfach nur an den "Pseudo-Master" gesendet werden. Ein Telegramm beim betätigen, eines beim Loslassen. Mehr nicht. Der Master kann nun leicht schalten, oder nach 300ms das Dimmen anfangen, oder nach 500ms den Backofen einschalten, was weiss ich.... Somit würden die Buskoppler einfach ihre Eingangssignale weitergeben... Und beim Dimmen beispielsweise würde der Master einfach den aktuellen %-Wert o.ä. an den entsprechenden Empfänger senden. Kommt nun eine gedimmte Leuchte hinzu wird im Master einfach ein ankommendes Eingangssignal verarbeitet und an einen anderen Empfänger gesendet (nur der %-Anteil) Sicher ist so ein "Pseudo-Master" nich ganz im Sinne des Can-Bus und an einigen Stellen auch nachteilig. Aber ich kann mich irgendwie nicht damit anfreunden ein "Gesamtprogramm" auf viele einzelne µC´s zu verteilen... Wenns nur Licht ein/aus wäre ok... aber wenn ich an An-/Abwesenheitskontrolle, Sprachausgabe (ja etwas übertrieben, ich weiss - natürlich nicht über den Bus, nur die Ansteuerung), Zeitglieder mit verschiedensten Voraussetzungen, Überwachung etc. etc. denke scheint mir das Verteilen der Gesamtintelligenz schnell unübersichtlich zu werden. Da gefällt mir ein Master der das Gesamtprojekt enthält irgendwie besser.
> Da gefällt mir ein Master der das Gesamtprojekt enthält irgendwie > besser. Man kann das auch Mischen, indem man z.B. ein Szenarioknoten vorsieht, der bestimmte Dimmerkombinationen ausgibt. Oder ein Timerknoten, der zu bestimmten Uhrzeiten die Rolläden fährt usw. Aber ich würde diese Komfortfunktionen nur in einen Master packen, wenn die Grundfuntionalität (Rolladen muß auch ohne Master "manuell" fahrbar sein) in den einzelnen Knoten steckt und ohne Master auskommt! Ich weiß nicht wieso du dich so gegen die Verteilung sträubst? Eine Konfigurationssoftware zum Bus muß sowieso her, damit isses dann auch egal, ob du damit einen zentralen Master oder viele kleine parametrierst. Außerdem ist die zig-mal gleiche Software einfacher zu stricken, als eine einzelne Riesensoftware, die viele verschiedene Funktionen unter einen Hut bringen muß. Im verteilten Modell kannst du dazuhängen soviel du willst (bzw. solange Buskapazität da ist) - besser skalierbar. Im Master-Modell, nur soviel der Master verarbeiten kann. > denke scheint mir das Verteilen der Gesamtintelligenz schnell > unübersichtlich zu werden. Ich sehs genau umgekehrt. :-)
hm... also ich wüsste nun nich gerade wofür ich noch extra eine parametriersoftware einbinden muss... naja daher hab ich stefan ja mal nach der genaueren funktion gefragt, evt. hab ichs bisher auch noch nich richtig verstanden und am ende gefällts mir doch ganz gut... naja der rest ist evt. einfach geschmackssache. Ich persönliche finde es sehr übersichtlich (von der vorstellung her) wenn alle knoten im prinzip nur ausgänge setzen oder bei änderung eigänge senden. somit steckt alles im "master" und ich habe in einem file alles enthalten (schalter-knoten brauchen nie mehr angefasst zu werden) und brauch nur verknüpfungen ändern, da der rest ja schon vorhanden ist (einfache bitverarbeitung). im anderen fall muss ich gleich mehrere files ändern, ein knoten bekommt von allen anderen befehle... und dein vorschlag die grundfunktionen direkt zu machen und "spielerein" per sonderknoten.... puh da kommt meine welt ganz durcheinander :-) Evt. auch nur daher weil ich zu sehr (beruflich) an Simatic gewöhnt bin... ich kanns auch nich vernünftig beschreiben... aber wenn befehle nur von einem kommen ist es für mich aufgeräumter (vom denken her) als alles durcheinander und jeder mit jedem.... ..aber evt. bekommt ihr mich ja doch noch überzeugt :-) so schlecht kanns dezentral ja schliesslich auch nicht sein.... sonst würdens ja nich so viele machen.... kopfzerbrech :-)
> im anderen fall muss ich gleich mehrere files ändern, ein knoten > bekommt von allen anderen befehle... das muß nicht so sein. Die Parameter können ja auch im Eeprom abgelegt werden - damit wäre keine "Fileänderung" notwendig. Die Software ist von Anfang an darauf vorbereitet, (z.B.) die Telegramme aus dem Eeprom zu lesen und dann zu verschicken. Die Konfigurationssoftware ändert nur die Telegramme im KnotenEeprom (indem sie spezielle CAN-Konfigurationstelegramme (so nenn ichs jetzt mal) an den Knoten schickt). Tja, das ist halt alles eines Frage des Konzepts - aber darüber diskutieren wir ja gerade :-) > ist es für mich aufgeräumter (vom denken her) als alles > durcheinander und jeder mit jedem.... Hm, denk weniger an "jeder mit jedem", sondern, daß (z.B.) vom Standpunkt Taster, dieser selbst alle möglichen Teilnehmer/Aktoren erreichen kann. Alle Aktionen am Bus sind voneinander komplett unabhängig. Von daher sehe ich auch keinen Vorteil, diese gedanklich in einen Knoten zu projezieren. > so schlecht kanns dezentral ja schliesslich auch nicht sein.... > sonst würdens ja nich so viele machen.... Vorteile: - Ausfallsicherheit - Skalierbarkeit/Erweiterbarkeit - Überschaubare, begrenzte Funktionalität (Software dadurch einfacher, stabiler, usw.) Gaaanz anderes Konzept/Modell: Der Taster schickt nur noch ein CAN-Telegramm: "Ich bin jetzt gedrückt". Alle angeschlossenen Lampen reagieren darauf. Vorteil: Kommt eine neue Lampe hinzu, so muß nur noch diese eine neue Lampe parametriert werden ("Bitte auf gedrückten Taster xyz achten"). Nachteil: Kommt ein neuer Taster hinzu, so müssen alle bestehenden Lampen, die darauf reagieren sollen, neu parametriert werden. Ursprünglich ist das Konzept von CAN genau so gedacht gewesen und so wirds ja auch im KFZ eingesetzt - ereignisgesteuert eben.
guck, auf so ein zündfunken hab ich doch gewartet :-) Taste1 entspricht 2 Epromstellen (Zieladresse & Info) Eprom könnte leicht über den Bus verändert werden. Damit ist die Parametrierung tatsächlich leicht gemacht (und ich überleg seit Tagen... Brett vorm Kopf :-) ) aber zur ausfallsicherheit... auch wenn ich gleich ausge-buh´t werde :-) die zählt für mich nicht. der master ist ja nicht prinzipiell das schwächste glied... es ist mindestens so warscheinlich das das Netzteil aufraucht oder ein Bustreiber der den Bus lahmlegt oder oder oder... und dann wird daraus auch ein "can(n)-nicht-bus" (ja flach ich weiss :-) ) aber mal zu den Zeit oder Zustandsgesteuerten Dingen: ein Master mit ner schönen RTC oder gar DCF-77 - einwandfreie Sache :-) dezentral... naja oder wenn ich eine leuchte von taster1 ein/austasten will und von taster2 abfallverzögert (10min) einschalten will... naja... könnte den taster so programmieren das er nach 10min das ausschalten sendet... oder das "relais" so das es zwischen normaler betätigung oder verzögerungen unterscheiden kann... macht man das denn wirklich so? mein master hätte noch einen vorteil den ich evt. nutzen wollen würde: er ist EINE stelle die alle Infos und alle schaltzustände hat. wenn ich eine visualisierung einbringen möchte (oder anzeige auf dem pc oder so) brauche ich nur ne verbindung zu ihm. löse ich es dezentral müsste ich alle abfragen oder dauerhaft mitlesen.... ich weiss nich warum :-) aber irgendwie hab ich probleme mich damit anzufreunden :-) ich werd nochmal versuchen nachzuvollziehen wie stefan es bspw. gemacht hat aber du hast mich schon etwas auf den weg gebracht :-)
noch mal ein zusatz zu meinem eben genannten vorteil "EINE stelle mit allen Info´s": habe ich einen Master ist eine verknüpfung "wenn lampe1 ein und lampe2 ein und taster1 gedrückt dann lampe1 aus und lampe3 ein" leicht zu machen. ist es dezentral aufgebaut müste ja lampe3 auch "gucken" ob lampe1 und lampe2 ein sind. oder taster1 müsste gucken ob lampe1 oder lampe2 ein sind.... und das meinte ich vorhin... bei solchen sachen muss ich halt doch verknüfungen "jeder mit jedem" und "alle durcheinander" machen :-) zumal ich dann auch mit extendet frames arbeiten müsste um jedes mal empfänger und absender mitzuschicken... das würd ich mir mit nem "master" auch sparen können
> macht man das denn wirklich so? Das frag' ich mich auch immer... solange man aber nix besseres findet (ich bin da sehr offen) macht "man"/ich das so. > Taste1 entspricht 2 Epromstellen (Zieladresse & Info) im Prinzip ja - man könnte sich das ja noch ausgedehnter vorstellen (mehrere, dynamische Eepromstellen usw.). Wobei: Vorsicht mit "Zieladresse". Wenn mehrere Knoten gleichzeitig die gleiche CanId versenden gibt's Busmüll! (unwahrscheinlich aber denkbar). So ist das CAN-Konzept eben. Deshalb am besten extended Ids verwenden und in die CanId nicht nur die Zieladresse stecken, sondern gleich auch noch eine Absendeadresse... > aber zur ausfallsicherheit... die zählt für mich nicht. :-) Das ist das einzige was zählt!! > der master ist ja nicht prinzipiell das schwächste glied... > es ist mindestens so warscheinlich das das Netzteil aufraucht [...] Somit hätten wir die Ausfallwahrscheinlichkeit also schon verdoppelt. > [...] oder ein Bustreiber der den Bus lahmlegt Das gibt's nicht, zumindest nicht ohne vorhergehenden gravierenden Hardwareschaden. Die Transceiver sind deutlich robuster als die restliche Elektronik! Und für Sicherheitsfanatiker gibt's ja auch fehlertolerante Bustransceiver - da darf eine Leitung abfaulen - CAN geht immernoch. (Für Automationszwecke habe ich sowas aber noch nicht gesehen). > mein master hätte noch einen vorteil den ich evt. nutzen wollen > würde: er ist EINE stelle die alle Infos und alle schaltzustände > hat. Wo ist das ein Vorteil? Wenn du einen Zugang vom PC zum CAN-Bus hast, dann ist es prinzipiell egal, ob du einen Knoten abfragst, oder ob du mehrere Knoten abfragst. Oder? > ich weiss nich warum :-) aber irgendwie hab ich probleme mich damit > anzufreunden :-) ich merk's schon :-) Ich will dir auch nicht meine Meinung aufdrücken, sondern übernehm in der Diskussion nur den Gegenpart, um die Argumente für oder gegen etwas darzustellen.
> zumal ich dann auch mit extendet frames arbeiten müsste um jedes mal > empfänger und absender mitzuschicken... das würd ich mir mit nem > "master" auch sparen können Naja, es darf halt nicht vorkommen, daß gleichzeitig mehrmals die gleiche CanId auf dem Bus liegt. Wie du das sicherstellst ist eigentlich egal. > habe ich einen Master, ist eine verknüpfung [...] leicht zu machen. Das stimmt. Nenn' mir mal einen (weiteren) praktischen Anwendungsfall der sowas verlangen würde oder bei dem sowas praktisch wäre. (Bin grad am überlegen, wie ich sowas in meinem Konzept machen würde).
du bist also immer gegen meine meinung, ja? :) scherz mit den gleichen "Zieladressen" und evt. Busmüll hast du recht... bei der Ausfallsicherheit kommen wir wohl nicht zusammen... :) ok, man hat durch weglassen des Masters eine Ausfallquelle ausgeschlossen... aber es gibt noch genu andere (wie ich finde) daher wollte ich nur sagen das dieses Argument gegen den Master bei mir nicht zählt... natürlich soll der bus stabil laufen :) klar ist es egal ob ich einen oder mehrere abfrag... aber bei einem könnt ich alles in eine message quetschen (64 zustände darstellen)... naja ok nich der hammervorteil... aber nun bin ich auf die stellungnahme zu meinem "zusatz" gespannt :) und keine angst du zwingst mir nicht deine meinung auf, ich bin mir auch sicher das es die bessere lösung ist (wie schon gesagt sonst würds ja keiner machen.. autos, industrie... etc) ich möchte es halt auch gern verstehn und somit auch vernünftig zu nutzen wissen und nicht nur nachmachen...
naja... weitere praktische anwendungsfälle... bspw. alles was nicht ein betätigen eines schalters vorraussetzt. ich würde gern (ist noch fern aber wenn ichs nicht ausreizen wollen würde bräuchte ich kein bussystem im haus) meinen schichtplan (4wochen-rhytmus) hinterlegen und dadurch zum beispiel die jalousinen oder die zirkulationspume oder signal des telefons beeinflussen. ok, dafür könnte ich eine art kalender machen, gleichzeitig auch noch ne zeitschaltuhr einbauen... wenn jetzt zu jedem zeitpunkt gleichzeitig noch ein taster die einzelnen dinge beeinflussen soll (bspw. mal nen tag frei) dann habe ich schon mal einen knoten der schaltstellen des ganzen hauses in bestimmten abhängigkeiten schaltet und gleichzeitig noch auf tastersignale wartet um wieder was zu schalten.... da is die entfernung zum master nicht mehr gross... naja.. und soetwas dezentral zu machen müsste ich das programm eines einzelnen knoten (der normal nur 8 relais setzen/rücksetzen würde) total aufblähen... dann lieber nur ein grosses programm im projekt. und an der stelle wird meiner meinung nach echt unübersichtlich im bus. klar bei lampe ein/aus rollo hoch/runter - keine frage hast du recht. aber sobald die abhängigkeiten untereinander zu gross werden... ich überleg mir nochmal ein paar konkrete fälle evt denk ich auch nur zu kompliziert. hast du denn auch ein can-bus laufen? oder noch in der planung?
ich versuche mal konkrete beispiele, evt. hast du ja ne lösung aus deinem konzept: 7h morgens UND keine Nachtschicht (entweder aus dem kalender oder am abend vorher per schalter ausgesetzt [urlaub])-> alle rolläden hoch 7h morgens UND nachtschicht -> alle rolläden ausser schlafzimmer hoch hierbei müssten sich zeituhr (inkl. kalender), rolläden, und ein schalter unterhalten ich könnte mir vorstellen bestimmte schaltvorgänge davon abhängig zu machen ob ich (oder jemand anderes) zu haus ist. bspw: bewegungsmelder flur UND nach 20h UND jemand zu haus -> Flurlicht an bewegungsmelder flur UND niemand zu hause -> Alarm Hierbei müssten sich schon der Bewegungsmelder der anwesenheitsschalter, die zeituhr, das flurlicht und der alarmteil miteinander unterhalten... und dieser verkehr der knoten untereinander würde bei entsprechend vielen verknüpfungen entsprechend hoch werden... aus diesem grund sagte ich immer ich würds "geordneter" mit nem master finden.... Alle Meldungen der Knoten --> Master...verknüpfung untereinander und mit kalender und mit zeit bzw. zeitgliedern... Master --> Ausgänge der Knoten setzen
> aber nun bin ich auf die stellungnahme zu meinem "zusatz" gespannt Was meinst du? > aber sobald die abhängigkeiten untereinander zu gross werden... und genau da hakts bei meiner Vorstellung noch. Ich sehe da im Moment nicht so viele Abhängigkeiten. Damit meine ich Dinge/Vorgänge/sonstwas, die nur durchgeführt werden sollen, wenn eine bestimmte Bedingung erfüllt ist, die der Knoten nicht selbst weiß, sondern erst irgendwie erfragen muß. Um nochmal auf dein Beispiel mit den Lampen zurückzukommen: > "wenn lampe1 ein und lampe2 ein und taster1 gedrückt dann lampe1 aus > und lampe3 ein" würde ich so machen: Einmaliges Drücken des Tasters schaltet Lampe1+2 ein, der zweite Tastendruck schaltet Lampe1 aus und Lampe3 ein - unbedingt und ohne vorher irgendwas abzufragen oder zu wissen. Einfach stur die Lampen so schalten. Oder habe ich da noch einen Denkfehler drin? Beim dritten Tastendruck werden alle drei Lampen stur ausgeschaltet. Wie schaltest du die Lampen wieder aus (ohne eine zu vergessen)? Und die Geschichte mit dem 4Wochenrhythmus/Schichtplan: Dafür gibt's z.B. Profile für alle Teilnehmer (z.B. Rolläden). Es sind bestimmte Rolladenstellungen oder Heizungseinstellungen usw. vordefiniert. Die "Zeitschaltuhr" (so nenn ich jetzt mal den intelligenten Knoten, der weiß wann welche Schicht ist) schickt zu bestimmten Uhrzeiten und/oder Ereignissen ein Telegramm in dem steht: "Bitte jetzt Position/Situation/Szenario 'Hausverlassen' einnehmen". Alle relevanten Knoten kennen diese Nachricht und reagieren darauf. z.B. fahren die Rolläden in die gewünschte Position - bei Hitze/Sonneneinstrahlung (meldet ja das Außenthermometer/Sonnensensor) z.B. auf Halbmast, oder alle Lampen im Haus gehen aus, die Steckdosen schalten ab, Heizung fährt runter usw. - die ganz normalen unnötigen Spielereien eben. Diese Profile haben natürlich alle Knoten in ihrer Software implementiert - abhängig von der eigenen, umzusetzenden Funktion. Ich muß keine Riesenliste erstellen, die der Master dann rumfunken muß, sondern ich parametriere nur noch wie der Knoten auf ein Profil reagieren soll (Eeprom). Etwas überspitzt: Der Master muß also nicht noch den Sonnenstand berücksichtigen oder erfragen, damit er den Rolladen entsprechend positionieren kann - das weiß der Rolladen selbst. Im Prinzip ist das so ein gemischtes Prinzip aus: - Gerichteter Kommunikation (Taster sagt zu Lampe: Licht ein) - Broadcasting der Statusinfos (Regensensor meldet: "Es regnet" und 'betroffene' Knoten/Aktoren reagieren darauf (z.B. Fenster zu)). Sowas geht mit einem Nur-Master-System so auch wiederum nicht. Ach es gibt so viele interessante Ansätze und Konzepte... > ich überleg mir nochmal ein paar konkrete fälle evt denk ich auch > nur zu kompliziert. Meist ist das so. Mich interessieren die Fälle, die ich noch nicht berücksichtigt habe bzw. mit meinem Konzept nicht erschlagen kann. > hast du denn auch ein can-bus laufen? oder noch in der planung? Beides. Hobby halt :-) http://www.CANathome.de Ich habe mal diese Diskussion als Anlass genommen, das längst fällige Update der Webseite freizuschalten...
Hm, hab meinen letzten Beitrag abgeschickt, bevor ich deinen letzten (20:01) gesehen habe. Deshalb hier die Antwort darauf: > 7h morgens UND keine Nachtschicht (entweder aus dem kalender oder am > abend vorher per schalter ausgesetzt [urlaub])-> alle rolläden hoch > 7h morgens UND nachtschicht -> alle rolläden ausser schlafzimmer > hoch Zeitschaltuhr sendet um 7Uhr an einem Wochentag: Profil "Werktag" (die Rolläden fahren in die voreingestellte Stellung usw.). Ist aber gerade Wochenende, so wird "Wochenende" verschickt und die Schlafzimmerrolläden bleiben geschlossen, bis manuell.... -> Da sehe ich konzeptionell kein Problem. > bewegungsmelder flur UND nach 20h UND jemand zu haus -> > Flurlicht an Der Bewegungsmelder selbst weiß, daß er erst nach 20Uhr die Lampe einschalten darf. > bspw: (bewegungsmelder flur UND nach 20h UND jemand zu haus -> > Flurlicht an) bewegungsmelder flur UND niemand zu hause -> Alarm Die Uhrzeit ist jedem Knoten sowieso immer bekannt. Der Alarmknoten überwacht die Meldungen der Bewegungsmelder (broadcast) und kennt das zuletzt verschickte Profil "Haus verlassen". Zusammen mit der ebenfalls bekannten Uhrzeit schaltet der Alarmknoten dann die Außenlichter... Aber du hast recht, das sind Situationen, die durch logische Verknüpfungen relativ einfach in den Griff zu bekommen wären. Meine Beschreibung setzt aber voraus, daß die Verknüpfung in die Knotensoftware einfließt oder gar hart reinprogrammiert wird - das ist schlecht. Alternativlösung: Für solche spezielleren Fälle (wie z.B. Verknüpfungen) könnte man einen "Verknüpfungsknoten" programmieren, der genau so funktioniert wie du beschreibst. Natürlich muß er sich die Informationen die er dazu braucht erst beschaffen - sei es dadurch, daß er die Infos "gebroadcastet" bekommt, oder selbst aktiv anfragen muß. Die normale, "ausfallkritische" Funktion wäre davon unberührt und würde natürlich weiterhin (parallel) dazu ausgeführt werden.
ach... du bist can@home :) wusst ich auch noch nich :) du wohnst nicht zufällig in norddeutschland? mit "zusatz" meinte ich das posting mit lampe 1,2,3... hatte sich überschnitten weil wir gleichzeitig gepostet haben... ich werd mich nun mal hinsetzen und versuchen ein oder zwei knotenanwendungen zu durchdenken die bspw. auf solche broadcasts reagieren. Ich poste nachher mal mein Ergebnis :) noch bin ich zwar der ansicht das es dadurch nicht einfacher wird, aber mal schaun, vielleicht ärger ich mich anschliessend auch über mich selbst :)
@and_ref: mh... sendest du zyklisch ein telegramm zur aktualisierung (zählerincrement bei telegramm) der "knoten-uhrzeit" oder wird nur zyklisch korrigiert? bin nun dabei mal konkrete fälle "dezentral" zu verknüpfen... momentan überlege ich eine art "haus-statusregister" (jemand zu haus, kein alarm, draussen dunkel, windstill) einzubauen, welches infos enthält die alle knoten evt. brauchen können. diese würde ich aber konsequent auch dort aktualisieren/lesen wo sie eigentlich nicht benötig werden (gleiche software). wobei natürlich auch eine menge stati zusammenkommen würden... gedanke: lieber nur die wichtigen mitteilungen rausfiltern? dann müsste ich wieder (aufwändig) parametrieren und dies gefällt mir immer weniger da ich noch nicht weiss was ich in 5 jahren mal dazubauen werde, also vermute ich muss ich eh wieder an die eigentliche software ran. wie hast du denn bei dir (nur kurz zusammenfassen) parametriert? (es fällt mir ungeheuer schwer anderer leute c-code zu verstehn... :-( )
> sendest du zyklisch ein telegramm zur aktualisierung > (zählerincrement bei telegramm) der "knoten-uhrzeit" Momentan weiß noch kein Knoten was von Uhrzeit... (soviel zur Praxis). Ich werde aber die Uhrzeit zyklisch jede Sekunde senden (~1000CanMsg/s @100kBit/s möglich). > "haus-statusregister" > wobei natürlich auch eine menge stati zusammenkommen würden... richtig. Und diese sollten gescheit gruppiert werden. "draußen dunkel" und "jemand zuhaus" schließen sich ja nicht gegenseitig aus. Also werden das eine ganze Reihe von Bits... Naja, 64 Stück davon passen ja in eine CanBotschaft :-) > gedanke: lieber nur die wichtigen mitteilungen rausfiltern? Nein, alles was an einen selbst adressiert ist sollte mitgelesen werden. Wenn ein Knoten Daten an einen anderen Knoten schickt, die dieser nicht verarbeiten kann/will, dann stimmt am sendenden Knoten was nicht. Damit muß sich der empfangende Knoten nicht rumreissen. Broadcastmeldungen sollten sowieso alle mitgelesen werden. Die Applikation entscheidet dann, was davon interessant ist. Beispiel: Zum Entwicklungszeitpunkt steht schon fest, daß ein elektrisches Fenster sich für die Infos vom Regensensor interessiert. Deshalb kann man das auch gleich den Empfang und die Auswertung reinprogrammieren. Wenn in 5 Jahren noch weitere Anforderungen dazukommen, dann mußt du sowieso die Software ändern. Heute schon alles parametrierbar machen geht nicht. Aber diese Nachrüstungen sind dank nachladefähigen Mikrocontrollern (Stichwort Bootloader) ein kleineres Problem - theoretisch. Praktisch siehts bei mir hier genauso wie bei Stefan eher mau aus :-) Bootloader braucht man nicht unbedingt, also stellt man den erst mal hinten an... > wie hast du denn bei dir (nur kurz zusammenfassen) parametriert? Die Rolläden kennen 16 verschiedene Profile auf die sie reagieren (Nacht, Sommernacht, Morgensonne, EG lüften, Tag, usw.). Jedem Profil ist eine Rolladenposition zugewiesen. Diese Positionen kann man zur Laufzeit verändern. Zusätzlich ist die Umschaltzeit der Rolladenrelais parametrierbar (aber das führt jetzt zu hier weit)... Jeweils 6 Lichtschalter teilen sich 75 Speicherplätze für CAN-Telegramme, die je nach Tastendruck (mehrstufig) verschickt werden. Auch diese Telegramme lassen sich zur Laufzeit ändern. Dimmer lassen sich z.B. in ihrer Zeit, die sie für eine Helligkeitsänderung brauchen, einstellen (z.B. Dimmer braucht von 0% auf 100%: <xxx>Millisekunden). Softstart/Softstopp. Die maximale Einschaltdauer von Lampen und Relais ist begrenzbar. (z.B. das Türöffnerrelais darf nur 2s anziehen usw.). Auf welche CanIds die einzelnen Knoten hören leitet sich direkt aus deren Knotennummer ab - da muß nix parametriert werden. ~100m Cat5-CAN; ~40Knoten; bisher (6Monate) keine Probleme. > es fällt mir ungeheuer schwer anderer leute c-code zu verstehn... damit meinst du aber nicht mich - oder hab ich den Code schon hochgeladen? Oder hast du dich etwa bei Konzept1 verirrt?
bin immernoch am zusammenstellen einer lösung, auf jeden fall nochmals (oder schonmal g) danke für deine unterstützung, ich hoffe ich nerv nicht zu sehr :-) du ´sagtest du interessierst dich für bei dir nicht berücksichtigte dinge: ich hab deine seite nochmal umgegraben: du sendes ein telegramm nachdem eine teste gedrückt wurde. ich finde besser (und werde es so machen) 1.Telegramm - Taste gedrückt 2. Telegramm - Taste losgelassen Somit kann man über eine Zeitfunktion im Empfänger so eine art komfortfunktion wie beim auto-fensterheber machen: wird die taste nach max. 400mx wieder losgelassen -> fahre in endlage, stoppe bei erneutem druck (genau wie bei dir) nach 400ms stoppt das rolo sofort (zum kurzen nachpositionieren bspw.) ok, in diesem fall nich wirklich die verbesserung (1mal laaang oder 2 mal kurz drücken) aber evt. kann man eine solche funktion woanders doch noch gut brauchen... nur ein gedankenanstoß
nein, "verirrt" hab ich mich nicht. ich habe bewusst dort geschaut (anregungen besseres verständnis.. nein anfreunden mit dem dezentralen g) und stefans code natürlich.... siehst du ein vorteil darin den dimmwert (%-anteil) im taster zu generieren anstatt direkt im "dimmerknoten"? ich würde/werde dies nämlich im dimmerknoten generieren, so kann einfach auf andere eingehende befehle reagiert werden. im anderen fall müsste ja wieder ein taster ein broadcast senden damit andere schalter in abhängigkeit arbeiten können
> siehst du ein vorteil darin den dimmwert (%-anteil) im taster zu > generieren anstatt direkt im "dimmerknoten"? Ich kann einem Dimmer einen absoluten Wert schicken (0..100%), einen relativen (z.B. +10%) oder den Befehl "start heller; start dunkler; stopp". Damit sind eigentlich alle Fälle abgedeckt. Und letztendlich entscheidet der Dimmer, ob die Lampe jetzt schaltet/schalten darf oder nicht (rein konzeptionell). > im anderen fall müsste ja wieder ein taster ein broadcast senden > damit andere schalter in abhängigkeit arbeiten können Das interessiert mich noch näher. Ich sehe keinen Zusammenhang zwischen den einzelnen Tastern. Beispiel: - Taster1 schaltet Lampe1+2 ein, bei erneutem Tastendruck wieder aus - Taster2 schaltet Lampe1+3 ein, bei erneutem Tastendruck wieder aus Drückt der Benutzer Taster1 und anschließend Taster2, dann brennen alle 3 Lampen. Drückt er jetzt T1, dann geht L1+L2 aus. Drückt der Benutzer jetzt T2, dann geht L2+L3 aus (L2 reagiert nicht - war ja schon aus). Alternativkonfiguration: T1+T2 schalten bei jedem zweiten Tastendruck alle 3 Lampen aus (obwohl nur 2 Lampen damit eingeschaltet werden können - macht ja aber nix). Ich hoffe das ist halbwegs verständlich. Anderes Beispiel/Konzept: Sollen mehrere Taster gleichwertig z.B. mehrere Szenarien durchschalten, so könnte man ja von jedem dieser Taster den Befehl "nächstes abgespeichertes Szenario einnehmen" absetzen. Damit wüsste jede Lampe (intern), was sie als nächstes zu tun hat. So hab ich das aber (noch?) nicht umgesetzt. Wenn die Gesamtzahl der Szenarien z.B. "nur" 3 ist, dann läßt sich das auch noch vernünftig bedienen. Sollen mehrere Szenarien geschaltet werden, so würde ich das auf weitere, unabhängige Taster verteilen. (Bedienbarkeit!) Du merkst, so starr muß man sich garnicht festlegen. Im ersten Fall steckt die Intelligenz im Taster (der den Dimmwert vorgibt), im zweiten Fall (also dann wenn man mit dem ersten Fall nicht mehr weiterkommt, oder es einfacher ist) steckt die Intelligenz im Dimmer - ganz wie es passt. Diese beiden Konzepte können nebeneinander, gleichzeitig, gleichwertig eingesetzt werden. Ich sehe dabei keinen Stil- oder Konzeptbruch. Beide Konzepte haben ihre Vorteile - warum nicht beide verwenden :-) In der Praxis setze ich Doppeltaster ein, die ich so parametriert :-) habe, daß der linke Taster immer ein internes "Szenario" weiterschaltet (d.h. immer andere Lampentelegramme verschickt) und der rechte Taster alles wieder ausschaltet. Damit ist der linke Taster mehrfach belegt - der rechte schaltet definiert zum Ausgangszustand zurück - auch Gäste kommen so zurecht. Links einschalten - rechts ausschalten.
> gedanke: lieber nur die wichtigen mitteilungen rausfiltern? nein ich meinte damit das nur das auf dem knoten aktualisiert wird (in sram, eeprom wie auch immer) was er für seine funktion braucht. dem licht im gästeklo ist die aussentemp z.b. egal mitlerweile hab ich mir erstmal ein telegramm zusammengestellt: extendetFrame: Stand. Identifier-> 8Bit Ziel; 3Bit Nachrichtenart (E/A Analog, Zeit etc.. dienst nur der Vorauswahl) ext. Identifier-> 8Bit Absender; 10Bit BroadcastID (jeder wert der als Broadcast rausgeht hat eine unverwechselbare ID) als Ziel für Broadcast nehme ich immer 0x00 oder 0xFF, somit muss jeder knoten nur 2 adressen mitlesen (broadcast und direkte anrede) das ist deshalb praktisch weil ich den MCP2515 nutze und der hat nur 2 RxPuffer und bei einem nur 2Filter. Somit kann ich aber schön alles andere ausblenden und habe weniger interrupts durch CAN.... ich überlege auch bei standart e/a (durch vorauswahl) kein byte zu senden sondern die info (max 8bit) in den ext.Identifier zu packen... was hälst du davon? ist ja schon ähnlich wie bei deiner 2. version... ich glaub so langsam komm ich auf den geschmack ;-)
@and_ref: ich hab mir mal deine can-vergabe genauer angesehen... soweit ich es verstanden habe wird beim gleichzeitigen senden die nachricht als wichtig erkann (höhere priorität) die wärend des telegrammes als erstes ein dominantes bit sendet ("0"). wäre es dann nicht sinnvoll deine Nachricht genau andersherum aufzubauen? oder hast du dich nur bei der bit-nummerierung verschrieben? (schliesslich fängst du mit bit 28 an und zählst auf 0, dann erst folgen die datenbyte´s) wenn du dich nicht verschrieben hast: wenn du deine "object"-unterscheidung in den ID-Bits 0...3 sendest könntest du sicher gehen das ein "emergency-object" in jeden fall priorität hat, egal was später an weiteren ID-Bits noch dazuprogrammiert wird (hast ja auch geschrieben das das bishe rnoch nicht unterstützt wird)... oder hab ich das falsch verstanden?
> wäre es dann nicht sinnvoll deine Nachricht genau andersherum > aufzubauen? Nein. > oder hast du dich nur bei der bit-nummerierung verschrieben? Nein. > wenn du deine "object"-unterscheidung in den ID-Bits 0...3 sendest > könntest du sicher gehen das ein "emergency-object" in jeden fall > priorität hat Nein. :-) Bit28 ist das MSB. Bit0 ist das LSB. Damit wird zuerst Bit28 gesendet... > wird beim gleichzeitigen senden die nachricht als wichtig erkann > (höhere priorität) die wärend des telegrammes als erstes ein > dominantes bit sendet ("0"). So in etwa. Genauer gesagt: Derjenige der die niedrigere CanId schickt oder anders formuliert, derjenige der beim ersten verschiedenen Bit die Null schickt, erhält den Buszugriff. Bei mir: Deswegen sind auch prinzipiell alle EOs (CanId 0x00nnnnnn) grundsätzlich höher prior als die restlichen Nachrichtentypen, wie z.B. BOs (CanId 0x10nnnnnn): 0x00nnnnnn<0x10nnnnnn egal wie hoch oder niedrig die Ziel- oder Absendeadresse ist.
gut, dann hab ich das schon mal verstanden... zum msb.. lsb... peinlich ich weiss nich warum aber ich hab bei diesem telegramm das erste mal die bits von links nach rechts gezählt.. sorry ;-) jetzt wo ich mal eine message-unterscheidung "geplant" hab kann ich mich doch mehr und mehr mit dem dezentralen anfreunden ;-) spricht eigentlich was dagegen daten (1Byte Eingänge bspw.) direkt im Identifier mitzusenden? ist evt unschön, aber eigentlich doch nix gegen einzuwenden, oder? dann würd ich mir 1 byte sparen, da der idendifier ja eh immer komplett gesendet werden muss...
> mehr und mehr mit dem dezentralen anfreunden ;-) Vergiss die Verknüpfungsgeschichte (WENN größer 20Uhr UND Bewegungsmelder usw.) nicht, das läßt sich leichter mit einem zentralen System machen, ohne zuvor die ganzen Daten erst erfragen zu müssen... aber das ist wohl nur ein kleiner Punkt. > spricht eigentlich was dagegen daten (1Byte Eingänge bspw.) direkt > im Identifier mitzusenden? ist evt unschön, ja, außer unschön isses nichts schlimmes. Viele Busmonitore zeigen die CAN-Botschaften sortiert nach CanId an. Damit erhältst du mit "jeder" Botschaft eine neue Zeile in der Id-Übersicht... wenn dich das nicht stört. Ich würde es dennoch nicht tun - das eine Byte reissts nicht. Unn wenn du doch mal noch was (konzeptionell) erweitern willst... (Geschmackssache).
zu den verknüpfungen: naja wenn aber (wie du ja schon sagtest) jedem knoten die zeit bekannt ist (minütliche aktualisierung reicht ja locker für zeitschaltaufgaben) wird das problem aber auch schon wieder weniger... damit blase ich zwar immernoch die knotensoftware auf... aber es wäre immernoch ein "standart-programmteil" den alle gemein haben... sowas gefällt mir :-) hast eigentlich mal über mein Vorschlag nachgedacht das betätigen der taste und anschliessend das loslassen zu senden? wie in meinem beispiel?
Hallo zusammen, ich verfolge diesen Thread schon seit längerem und nun will ich auch ein paar Fragen in den Ring werfen. Was mir bei diesem Konzept nicht klar ist, warum muss jeder Knoten über die ID direkt adressierbar/ansprechbar sein? Ok, es gibt beispielsweise Diagnosebotschaften, die nur einen Knoten betreffen, da leuchtet es mir auch ein. In anderen Branchen wird dies so gelöst, dass beispielsweise Diagnosebotschaften ab einer bestimmten (niderprioren) ID definiert sind. Jeder Knoten bekommt dann eine eigene Diagnosenummer, die auf diese Basis-ID summiert wird. Wenn ich mir jetzt einen Knoten vorstelle, der irgendwelche Taster auswertet. Bei einem Tastendruck wird eine vordefinierte Botschaft mit situationsabhängigem Inhalt (parametrierbar) verschickt. Der Nummernkreis der ID bezieht sich auf eine bestimmte Etage oder Unterverteilung (ID200-ID299 im 2. Stock). Über die ID kann nun die dazugehörige Unterverteilung angesprochen werden (oder ein Gateway, das dann die Nachricht in ein anderes Stockwerk weitervermitteln kann). Aktuatoren besitzen doch nur die Knoten die im Schaltschrank sitzen, nur diese können aktiv werden (Relais schliessen/öffnen usw.) Würde es dann nicht Sinn machen, wenn die Knoten im Schaltschrank auf alle Botschaften in einem bestimmten ID Bereich mithören und diese dann auswerten? Warum sollte ein Knoten mit Tastern einen anderen mit Tastern aktiv ansprechen können? Informationen, die für alle interessant sind, werden in einem Nummernkreis verschickt, der von allen Knoten eingelesen wird (Zeit, Temperaturen, usw..) Um bei einem Taster-Knoten zu bleiben, wenn dieser keinen Tastendruck registriert, könnte dieser in einen Energiesparmodus fallen... Es kann natürlich auch gut sein, dass ich wg. meiner beruflichen Historie und meiner täglichen Arbeit hier etwas um das Eck denke :-) Viele Grüsse Volker
@Volker: also meine gedanken unterscheiden sich momentan nicht allzu sehr von deiner darstellung, bis auf eine ausnahme: ich möchte/werde nicht strikt nach Sensorlnoten und Aktorknoten unterscheiden. Wird an ein Knoten (an dem normal nur Taster hängen) doch mal ein LCD angeschlossen und ne IR-LED um den TV zu steuern oder weiss der teufel was möchte ich das es vorbereitet ist. Und somit wird in jedem Knoten die Grundfunktion senden/empfangen zu allem und jedem möglich sein müssen. Auch Aktoren die ja eigentlich nix zu melden haben können aber einen Sicherungsfall weitermelden (bspw. auch auf das eben erwähnte, am Tasterknoten hängende Display) und somit wäre eine Kommunikation Aktor -> Sendo nötig. Und um diese flexibilität zu erhalten ist es m.m.n. nötig das auch zwei Tasterknoten (eben alle) miteinander reden (können)
@Dany P. > das betätigen der taste und anschliessend das loslassen zu senden? Spricht nix dagegen, klingt gut; so kann man das machen. @Volker > Was mir bei diesem Konzept nicht klar ist, warum muss jeder Knoten > über die ID direkt adressierbar/ansprechbar sein? Per Definition ist das bei diesem Konzept so. Man will gezielt Informationen von einem Absende- an einen Zielknoten schicken. Das bedingt nunmal, daß die CanIds als "Adressen" verwendet werden. Andere Konzepte gehen da anders vor. Stichwort: Ereignisorientiert. Dabei wird nur mitgeteilt, daß jetzt ein bestimmtes Ereignis vorliegt (z.B. der Taster ist gedrückt oder die Tür ist geöffnet). > In anderen Branchen Von welchen Branchen sprichst du? Automobilindustrie? Da sind das ja ganz andere Voraussetzungen. Da ist zum Entwicklungszeitpunkt schon jede Funktion bzw. jeder Netzteilnehmer und jede CanBotschaft bekannt. Da kommen nicht plötzlich noch 2 "Taster" dazu. (Stichwort: nachträgliche Erweiterbarkeit). Außerdem ist jede Steuergerätesoftware unterschiedlich - bei der Hausautomation will man viele gleiche Knoten verwenden, die gleiche Aufgaben haben. Das führt zu anderen Konzepten. Außerdem sagt ja niemand, daß man das nicht beides gleichzeitig verwenden kann/darf. Für Ereignisse oder Broadcastnachrichten mach' ich das ja auch. > (ID200-ID299) Über die ID kann nun die dazugehörige Unterverteilung > angesprochen werden Wenn mehrere Taster die gleiche Lampe schalten wollen, und gleichzeitig gedrückt werden, dann liegt zum gleichen Zeitpunkt, die gleiche CanId auf dem Bus -> nix gut. > Aktuatoren besitzen doch nur die Knoten die im Schaltschrank sitzen Ich denke, daß es keinen Sinn macht, die Hardware nach Eingabe- und Ausgabehardware zu trennen. Deshalb kann jeder Knoten alles (so wie Dany P. das oben schon ausführt). > Informationen, die für alle interessant sind, werden in einem > Nummernkreis verschickt, der von allen Knoten eingelesen wird (Zeit, > Temperaturen, usw..) Ich filtere in der CAN-Hardware nicht nach bestimmten CanIds, das passiert rein durch Software - diese soll entscheiden, ob interessant oder nicht. Hab das mal eben grob überschlagen. Ich schätze, daß die Software innerhalb von 20µs erkennen kann, ob das Telegramm interessant ist oder nicht und dieses auch innerhalb dieser Zeit 'einlagert'/puffert. Bei _max._ 1000 eintreffenden Telegrammen pro Sekunde (@100kBit/s) sind das 20ms. -> Das wären dann 2% Prozessorauslastung. Wenn die CanRx-Interruptzeit noch kürzer sein sollte, dann entsprechend weniger. > Um bei einem Taster-Knoten zu bleiben, wenn dieser keinen > Tastendruck registriert, könnte dieser in einen Energiesparmodus > fallen... Das ist ein weiteres interessantes Thema. Aber da 'wir' ja einmalige Telegramme verschicken (nicht zyklisch wie im Auto), ist das mit dem Energiesparmodus so eine Sache... Aufwachen durch das CanTelegramm: ja. Aber auch gleichzeitig dieses CanTelegramm korrekt mitlesen: nein. D.h. man müsste ein Wecktelegramm schicken, bevor die eigentliche Information übertragen wird. Heißt das, daß vor jeder Übertragung ein Wecktelegramm stehen muß, damit ein evtl. eingeschlafener Knoten rechtzeitig wach wird? Nein, das ist unpraktikabel. Eine Alternative wäre alle Knoten gleichzeitig einschlafen zu lassen. Das muß dann aber irgendwie sichergestellt sein, daß das sauber funktioniert... wenn einer nicht mitmacht, dann schläft keiner jemals ein. Außerdem ist da schon ein gewisser Aufwand erforderlich, damit die Knoten sich da alle einig sind. Du weißt wahrscheinlich welcher Aufwand da im Auto betrieben wird... :-)
@and_ref: du arbeitest ja mit anderer hardware, ich hab mir nicht die mühe geguckt nachzuschauen, hat dein integrierter can-controller auch filter und du nutzt diese einfach nicht, oder hat er die gar nicht? ich hab nämlich für mich entschieden: jeder can-controller gibt nur dinge weiter die entweder direkt an ihn gerichtet sind oder broadcast (adresse 0x00... willkürlich definiert). die überlegung war: das was der can-controller schon kann brauch ich nicht programmieren (und weniger prozessorarbeit, nur prinzipiell, du hast ja schon vorgerechnet das es gering ist) und sollte ich mal andere telegramme haben wollen, kann ich das ja noch per software ändern... über nen energiesparmodus hab ich auch mal kurz nachgedacht, aber aus den gleichen gründen wie du verworfen... war mir zu heikel und unzuverlässig (und wenn zuverlässig dann zu zeitintensiv)
@ Danny P. > @Volker: also meine gedanken unterscheiden sich momentan nicht allzu > sehr von deiner darstellung, bis auf eine ausnahme: Ok, langsam synchronisiere ich mich auf :-) @and_ref > Per Definition ist das bei diesem Konzept so Ich finde diesen Ansatz durchaus interessant die CAN IDs als Adressen zu verwenden. In meiner Welt kam das bislang so nicht vor :-) > Automobilindustrie? Bingo! :-) > Da ist zum Entwicklungszeitpunkt schon jede Funktion bzw. jeder > Netzteilnehmer und jede CanBotschaft bekannt. Das wäre des Entwicklers Paradies :-) Problematisch ist immer der Verbau von vielen Sonderausstattungen. Die Nachrichtenkataloge ändern sich aber zum Glück nicht so dynamisch, während der Entwicklung ist das aber durchaus normal. > bei der Hausautomation will man viele gleiche Knoten verwenden, die > gleiche Aufgaben haben Ich glaube, das ist der zentrale Punkt der Diskussion > Wenn mehrere Taster die gleiche Lampe schalten wollen, und > gleichzeitig gedrückt werden, dann liegt zum gleichen Zeitpunkt, > die gleiche CanId auf dem Bus -> nix gut. Das wäre wirkich nicht gut, mein Ansatz ist aber der, dass im Extremfall einem Taster eine CAN ID zugeordnet ist und somit Eindeutigkeit herrscht. Ich würde also meine Informationen komplett im Datenteil der Botschaft unterbringen. Bei 8Byte und der Möglichkeit Multiplex Botschaften zu schicken ist das Ende nicht so schnell erreicht. Zum Energiesparmodus: Wenn ein Knoten eingeschlafen ist, dann muss er erst wieder durch den Bus geweckt werden. Der MCP2515 puffert doch die Botschaften solange bis sie durch den uC abgeholt werden. Das sollte reichen um den Controller aufwachen zu lassen (bei internem CAN kann das anders sein). Also dürften keine Weck-Botschaften nötig sein? Wenn ich jetzt wieder an den Taster-Knoten, meinetwegen mit Display, denke, dann würde das die Funktion nicht beeinträchtigen. Die Frage ist, ob ich ständig allgemeine Infos (die aus den Broadcast Nachrichten kommen) auf dem Display aktualisieren muss... hmm... Bei einfachen Taster-Knoten sollte das aber funktionieren, zumindest sehe ich gerade keinen Grund warum das nicht klappen sollte :-) Wenn der Knoten aber noch andere Aufgaben zu erledigen hat (das mit der IR-Led war ein gutes Beispiel), muss ich mir das nochmal durchdenken. Sobald ich meine reale Hardware auf dem Tisch habe werde ich das probieren, mit CANoe ist das ja kein Problem :-) Den Schuh eines kompletten Netzwerkmanagements würde ich mir nicht anziehen. Das kann nur schief gehen... es gibt zwar tolle Konzepte im Automobilbau, allerdings zeigen auch die wiederkehrenden Pannenstatistiken des ADAC, dass eine leere Batterie einer der Hauptgründe für Liegenbleiber ist... trotz NM :-)
@Dany P. > hat dein integrierter can-controller auch filter und du nutzt diese > einfach nicht So isses. @Volker: >> Da ist zum Entwicklungszeitpunkt schon jede Funktion bzw. jeder >> Netzteilnehmer und jede CanBotschaft bekannt. > Das wäre des Entwicklers Paradies :-) Das ist Realität! :-) Kommen neue Nachrichtenkataloge, so werden alle (betroffenen) Netzteilnehmer neu parametriert. Oder deutlicher: Ohne Umflashen keine Unterstützung der neuen CanBits... das wollen wir im Haus vermeiden. > mein Ansatz ist aber der, dass im Extremfall einem Taster eine CAN > ID zugeordnet ist Macht aber Umkonfigurieren der Taster/Lampen-Zuordnung extrem kompliziert. Außerdem kannst du so nicht "mehrstufige" "Schalter" realisieren - à la: erster Tastendruck schaltet diese Lampen, zweiter Tastendruck diese, dritter wieder aus... bzw. das wird extrem undurchsichtig. Du könntest dir ein Generierungs-/Parametrierungstool basteln, das den kompletten Bus für dich kennt und abstrahiert... dann aber viel Spass beim CAN-Debuggen. Du weißt ja schließlich nicht, was die gerade verschickte Botschaft eigentlich bedeuten soll, ohne den genauen inneren Zustand aller beteiligten Lampenknoten zu kennen... und dann das Problem, daß 'irgendwie' mal ein Lampenknoten resettet, während der andere weiterläuft... das wird dann unsynchron. Im schlimmsten Fall geht's Licht garnimmer aus, weil z.B. beide beteiligten Lampenknoten die Info "Taster wurde gerade gedrückt" aus unterschiedlichen Zuständen heraus, unterschiedlich bewerten... :-) [Busruhe] > Der MCP2515 puffert doch die Botschaften [...] (bei internem CAN kann das anders sein) Isses auch - zumindest wenn die CAN-Hardware im µC aus Stromspargründen (schon) abgeschaltet ist. In welchem Bereich arbeitest du? SG-Entwickler SW/HW? "AntriebsCAN" oder "InnenraumCAN"? Und wie/was möchtest du schönes (hobbymäßig) automatisieren?
> Das ist Realität! :-) Wo? :-) Meine Erfahrung zeigt, dass Nachrichtenkataloge durchaus nicht vollständig sind=> kurzfristige Änderungen der SW aber ohne flashen gehts dann nicht weiter, denn Funktions- und Schnittstellenänderungen ziehen das so nach sich... Im Hausbereich schwebt mir eine parametrierbare Tabelle für jede CAN Botschaft vor. Es könnten auch mehrere situationsabhängige sein. > Macht aber Umkonfigurieren der Taster/Lampen-Zuordnung extrem kompliziert Der Verdacht liegt nahe... ich glaube, ich laufe in ein Problem, wenn ich über einen Taster Lampen in verschiedenen Etagen schalten möchte. Zumindest kann ich das mit einer Botschaft nicht erschlagen. Im Extremfall muss ich für jeden Tastendruck auch mehrere Telegramme verschicken. In meinen Überlegungen kam bislang ein mehrfaches Tasten drücken für unterschiedliche Szenarien nicht vor, mal von ein/aus abgesehen... länger gedrückt wäre dann für ne Dimmer Funktionalität vorgehalten, der Knoten wertet die Dauer des Tastendrucks aus und übermittelt diesen zyklisch an den zuständigen Dimmerknoten im Schaltschrank. Ich möchte aber in jedem Fall vermeiden, dass ich neben jeden Taster einen Belegungsplan kleben muss... es muss einfach alles bedienbar bleiben :-) Ich seh schon, über das Nachrichtenkonzept muss ich mir noch eingehend Gedanken machen. Die Komplexität meines Ansatzes war bei weitem noch nicht so hoch :-)) Was habt/wollt ihr alles automatisieren, bzw. über den Bus steuern? Mit der Knotenhardware bin ich soweit durch, ich muss mir aber noch auf jeden Fall Gedanken über wohnzimmertaugliche Sensorik machen ... wie habt ihr das gelöst (Bewegungsmelder, Temperatursensoren, Fensterkontakte usw, der WAF lässt grüssen...)? Die Parametrierung der einzelnen Knoten wollte ich mit CANoe erschlagen (im Hinergrund steht dann ne CAN Datenbank, bzw Nachrichtenkatalog). Das eignet sich auch prima dafür den Bus zu debuggen/tracen/simulieren und aufzuzeichnen :-)) Mal schaun, wenn die Zeit bleibt, mach ich doch noch ne Requirement Analyse mit DOORS und pflastere das Ganze danach in UML :-) [Motivation] Bei mir steht auch ein automatisiertes Haus im Vordergrund. Ideen gibt es hierfür viele, aber bislang hab ich mich mehr mit der Umgebung und den prinzipiellen Problemen beschäftigt (CAN Anbindung, Hardware, die in ne UP Dose passt, usw...) So langsam rückt die SW in den Vordergrund und ich muss versuchen meine Ideen und Gedanken zu strukturieren und in SW zu pressen. In 3-4 Monaten sollte eine Basisfunktionalität erreichbar sein (wenn nun mal die HW läuft), denn Ende September kommen die Bagger :-) Ich arbeite übrigens in der Automobilentwicklung => sicherheitskritische Funktionalität, die auch mit dem Antriebs-CAN verbunden ist. Näheres erzähle ich dir gerne per PM :-)
@Volker: ein vorschlag um die länge des Tastendrucks auszuwerten: Ich hatte weiter oben schon beschrieben das ich ein Telegramm beim "drücken" und eines beim "loslassen" senden werde, also im prinzip immer nur die -änderung- eines schalters (ähnlich "make"/"break" bei der tastatur). jeder knoten den es interessiert kann dann selbst mitzählen oder halt auch nicht... so kann man auf das zyklische senden der schalterstellung verzichten, denn das werden da doch schon ne hand voll telegramme wen man schnelle reaktionszeiten haben möchte. klar das bringt den bus nicht an seine grenze... aber... naja.. vielleicht isses ja was für dich :)
@ Danny P.
Das ist auch ne interessante Möglichkeit :-) Wenn dann aber mal eine
Botschaft nicht durchkommt, gibt es interessante Effekte :-) Ich werde
diese Möglichkeit bestimmt in Betracht ziehen.
>jeder knoten den es interessiert kann dann selbst mitzählen oder halt
auch nicht...
Das würde aber dann bedeuten, dass du deine einzelnen Knoten nicht
direkt adressierst? Also Informationen auf den Bus legen, die Knoten,
die es interessiert, sollen sich die Info holen?
Wie sieht dein Konzept bislang aus? Wie machst du alles Wohnzimmer
tauglich? Was möchtest du alles automatisieren/steuern?
@volker: ich bin etwa im gleichen stadium wie du: hardware (busankoppler für die up-dose) läuft, nun kommt die software :-) zur wohnzimmertauglichkeit: ich werde an jeder schaltstelle ein busankoppler (mega8 + mcp2515) hinter den schalter in die up-dose setzen ich stelle mir vor 2 4-fach-taster (doppeltaster, mit mittelstellung) einzusetzen (8 tastkontakte sollten reichen g). an der zimmertür die obligatorische steckdose unter die schalter. an geeigneten stellen eine blindkappe zur aufnahme von ir-empfänger, ir-sender, lichtsensor, temepraturfühler oder display... (nicht alle überall) somit wäre auch im wohnzimmer alles vom sofa per fernbedienung schaltbar und man hat (finde ich) hohen komfort ohne weitere schalter am sofa. in einer uv (jede etage eine eigene) würden dann die schaltgeräte sitzen und per 12/24 volt-relais den 230v-teil schalten. zum dimmen suche ich noch geeignete hardware die ich einfach ansteuern kann. ich bin selbst auch elektroniker und habe sehr regelmässig auch mit allen entsprechenden spannungen zu tun, dennoch möchte ich (echt nur aus versicherungsgründen etc.) den "leistungsteil" als vde-gerechte geräte einsetzen. normales relais wird dem ja gerecht, lediglich die dimmerhardware.... dimmbare (0-10v) elektronische vorschaltgeräte gibts ja, aber n "normalen" dimmer... noch nix gescheites für hutschienenmontage gefunden... was will ich steuern: rolläden, licht, steckdosen, zirkulationspumpe, garagentor, bad-lüfter, alarm (alles auch in abhängigkeit mit tageszeit, anwesenheit, schichtplan etc.) eigentlich alles was strom hat :-) denn ich denke wenn man sich schon die mühe mit so einem system macht dann auch zu 100% rolläden und lichtleitungen werde ich direkt in die uv zu den schaltgeräten ziehen. weiterhin werde ich aber leitungen "tot" mit einziehen (z.b. schalter -> lampe etc.) um zu jederzeit auf "standart"-elektrik zurückrüsten zu können. und zwar nicht weil ich angst vor ausfällen habe (dann würd ichs gar nicht erst machen) sondern weil ich bei einem evt. hausverkauf (man weiss ja nie was man in 7 jahren will/kann... o.ä.) normale elektrik verkaufen möchte und nicht mein can-eigenbau. (1. will ichs behalten und 2. wer soll da mal was heile machen? g ) adressieren: doch, ich würde (momentan g) direkt adressieren. lediglich allgemein wichtige dinge (temp. zeit etc) würde ich an alle senden. der mcp2515 hat in jedem empfangspuffer mindestens 2 filter, somit kann den can-controller gleich filtern (direkte botschaften an eigene adresse und "an-alle-meldungen", der rest wird dem Mega8 gar nicht gemeldet. erleichtert die software ein wenig finde ich und wenn der das schon kann, was soll ich mich noch drum kümmern :)
Bei mir schauts gerade so aus, dass meine zum Teil fliegend aufgebaute Schaltung zu funktionieren scheint. Einige Teile der Sensorik funktionieren rudimentär in Einzelprojekten. Mein Layout für die UP Hardware ist soweit auch fertig, ein letztes Review mach ich am Wochenende und anschliessend will ich mir ein paar Prototypen fertigen lassen (wo hast du wieviele machen lassen?). Nach hoffentlich erfolgreicher Inbetriebnahme der HW (die übrigens auch mit nem MCP2515 arbeitet, aber als Controller entweder nen Mega16L oder Mega32L - je nach Notwendigkeit bekommen wird) geht es daran die SW für die Busknoten zu hacken. Meine Schalter, ebenfalls 4-fach Taster, hab ich als max. 4x4 Matrix verschaltet, die bei Bedarf auch nen Interrupt auf dem Mega generieren kann. Der Aufbau ist ganz ähnlich wie bei dir. Die max. 4 4fach Schalter hängen an einem UP-Busknoten (bei Bedarf könnte ich das über ne Stifleiste erweitern, oder an diese eben die Sensorik verschalten). Die Busknoten sind etagenweise verbunden, nur die HW im Schaltschrank (die auf den UP-Busknoten basiert) hat zwei CAN Anschlüsse und fungiert daher auch als Gateway zu den anderen Etagenverteilungen. Ich will auch den 230V Teil komplett von meiner Bus Installation trennen und dementsprechend lasse ich das auch vom Elektriker machen. Geplant ist, dass er alle Steckdosen auf Einzelklemmen in der Unterverteilung führt, somit habe ich auch später noch alle Freiheitsgrade. An eine redundante Verkabelung hab ich bislang nicht gedacht, zudem wird alles in Leerrohren verlegt, sodass eine ev. Rückrüstung auf eine Standardverschaltung nicht ganz ausgeschlossen ist. In der Etagenverteilung sitzen dann, wie bei dir, auch die Relais und Dimmer. Die Relais sind ja kein Problem, aber an Dimmern hab ich auch noch nichts passendes gefunden. Wenn dir da etwas über den Weg laufen sollte... :-) Einer der nächsten Schritte ist dann auch die Verteilung der Buskoppler und Sensorik im Haus zu planen. Ich glaube, das wird nochmal ein schwerer Schritt. Vor allem bei den Fensterkontakten und der zusätzlichen Sensorik hab ich noch etwas Bauchschmerzen. Die Frage ist immer, wie verteile ich die Buskoppler effektiv ohne zu den Sensoren all zu lange Leitungen legen zu müssen. Eine stete offene Frage ist immer auch die nach den Gehäusen. Der sichtbare Teil der Sensorik (Bewegungsmelder etc.) darf keinesfalls gebastelt wirken... so suche ich dahingehend auch noch ein "professionelles" Gehäuse für ein 240x128 Grafik Display, welches ich noch mit nem Touchpanel ausrüsten möchte... Ich hatte auch mal angefangen jeweils 8 Taster mit integrierter LED als Schaltelement zu verwenden... gefällt mir ganz gut... nur kommt sofort wieder das Gehäuseproblem hoch ... Bei der Adressierung tendiere ich auch zu einer Mischung aus direkt- und broadcast. Aber da ist der letzte Entschluss noch nicht gefasst, momentan sammle ich noch meine Anforderungen, daher ist dieser Thread hier wirklich Gold wert :-))
Hallo zusammen, ich lese hier auch schon eine Weile still mit, sehr interessante Diskussion. Mittelfristig bis längerfristig plane ich auch eine Heim-Automatisierung, nur wird es bei mit etwas diffiziler da es ein Altbau ist... Aber jetzt habe ich erst mal eine Frage an Volker: Was ist "DOORS"? Ist das eine Software oder ist es ein Konzept? Ansonsten, zum eigentlichen Thema: Ich würde die ganze Geschichte auch eher dezentral bauen, so dass sich die verschiedenen Knoten direkt untereinander unterhalten. Den Master als zentrale Schwachstelle würde mir auch nicht so sehr gefallen. Auch wenn es noch weiterhin einzelne Teile gibt, von denen viele Knoten abhängen, z.B. Verkabelung oder Netzteil, sind diese System aber auch primitiver. Da ist viel weniger dran was kaputt gehen kann und sie sind schneller geflickt. Und so könnte man z.B. auch nicht nur ein zentrales Netzteil an einer Phase vorsehen, sondern im extremfall für jeden Buskoppler ein separates Kleinnetzteil verwenden. Diese Netzteile können dann auch noch an verschiedene Phasen hängen etc. So könnte man schon einiges an Redundanz relativ einfach miteinbringen. Ansonsten, wegen der Nachrichten hin- und herschickerei. Ich denke, ihr konzetriert euch zu sehr auf die eigentlichen CAN-Nachrichten. Ich sehe die CAN-Nachrichten eher als Implemtierungsdetail und konzentriere mich mehr auf die abstrakteren Zustände der verschiedenen Komponenten: Ein Taster kann gedrückt oder nicht gedrückt sein oder ein Taster kann lange gedrückt sein. Ein Bewegungsmelder stellt eine Person fest oder auch nicht. Jeder einzelne Sensor stellt seinen aktuellen Zustand der Allgemeinheit zur Verfügung. D.h. wann immer sich der Zustand eines Sensors (Taster, Zeitplan, Fenster, Regen...) ändert, macht er in einer einzigen CAN-Botschaft seinen neuen Zustand allen Aktoren bekannt. Die Aktoren wiederum verknüpfen verschiedene Zustände und schalten ihre Ausgänge entsprechend. Also z.B. Lampe = "Schalter #1 an" ODER "Schalter #2 an". Wenn die Hardwarefilter der CAN-Transceiver nicht reichen, spielt das ja keine große Rolle, da der Mikrocontroller in den Knoten eh kaum etwas zu tun hat. Und ausserdem müssten viele Aktoren ja nur auf einige wenige Sensoren hören. Zusätzliche würde ich so eine Art "virtuelle Zustände" einführen. D.h. mehrere Taster können sich zu einem "virtuelles Kippglied" verbünden. D.h. Taster einmal gedrückt, bedeutet "Gruppe Treppenhauslicht an", den Taster nochmals gedrückt bedeutet "Gruppe Treppenhauslicht aus". Dabei kann die Gruppe Treppenhauslicht durch mehrer Taster gesteuert werden. Unter der Vorraussetzung das allen Tastern der aktuelle Zustand der Gruppe bekannt ist, kann ja jeder Taster in der Gruppe den nächsten Zustand der Gruppe bestimmen, wenn er gedrückt wurde, dass er einfach eine CAN-Botschaft sendet, mit dem Inhalt "Gruppe Treppenhauslich an". Alle anderen Taster auf den Bus, die diese Gruppe auch bedienen, lesen diese Nachricht ja auch mit, und kennen so den neuen Zustand der Gruppe und können bei einem Tastendruck entsprechend mit einer anderen Gruppennachricht reagiern (z.B. Treppenhauslicht aus). Die Lampen im Treppenhaus hören natürlich auch auf diese Nachricht und kennen so den Zustand der Gruppe, und verknüpfen den Gruppenzustand mit ihren Ausgängen. Also: Lampe = "Gruppe Treppenhauslicht an". Mit diesem Konzept könnte man wiederum einen virtuellen Timer einbauen, der nach einer bestimmten Zeit, wenn die Gruppe Treppenhauslicht lange genug im Zustand "an" war, die Nachricht "Gruppe Treppenhauslicht aus" versenden würde. Die Aktoren und die Taster selbst würden dann alle den neuen Zustand kennen und dementsprechend reagieren. So in etwa stelle ich mir mein dezentrales System vor. Die ganze Verknüpfung findet nicht annhand von Nachrichten statt, sonden verknüpft werden Zustände. Und mit den CAN-Nachrichten werden Zustände übertragen. Mir ist bis jetzt noch kein Anwendungsfall eingefallen, den man mit dieser Technik nicht ganz einfach parametrieren könnte. Was haltet ihr davon?
@volker: platinen habe ich gar nicht fertigen lassen, sondern ätze selbst. ich habe alles auf eine einseitige platine bekommen und es ist mit meinen mitteln sauber hinzubekommen. ich werde aber meine komplette elektrik selbst installieren (wozu bin ich sonst elektrofachkraft? g div. meßgeräte für die prüfung nach vde nach erfolgter installation kann ich mir leicht leihen...) nur die "schnittstelle" bus/leistung werde ich wie gesagt nicht selbst "bauen" sondern auf geprüfte schaltgeräte zurückgreifen zu den langen leitungen von kontakten zum buskoppler: hast du deine eingänge hardwaremässig entstört? rc-gliec? optokoppler? das habe ich bei meinen up-dosen-busankopplern nicht gemacht... pullup und software-entprellung sollten reichen (bei stefan´s busankoppler ja auch nicht anders). daher werde ich es unbedigt vermeiden die leitungslänge zwischen busankoppler und schalter länger als 20-30 cm (reicht im 3er-dosen-verbund) werden zu lassen. ich habe ein wenig angst das der µC sich irgendwie doch mal was an störimpulsen (grad bei gewitter) einfängt und je länger die antenne am eingangspin..... auch wenns durch die software-entprellung ausgeschlossen sein sollte, da zahl ich lieber 12eur mehr für nen extra-busankoppler (auch bei nur 1mtr abstand zwischen beiden) statt mir hinterher sonstwohin zu beissen, denn: man kann alles testen, prüfen, messen... aber son orginal "norm-gewitter" zum testen... schwer :-)
@Volker: 29.07.2005 9:30 > kurzfristige Änderungen der SW aber ohne flashen gehts dann nicht > weiter, na dann reden wir ja vom selben. :-) @Dany P. 29.07.2005 10:30 [Tastendruck verschickt CAN-Telegramm] > jeder knoten den es interessiert kann dann selbst mitzählen oder > halt auch nicht... Ich hab dabei Angst, daß die Knoten dann irgendwann unsynchron laufen - wie willste das verhindern? Irgendwann muß irgendwie was definiertes zum resynchronisieren kommen. @Volker 29.07.2005 13:21 > wie verteile ich die Buskoppler effektiv ohne zu den Sensoren all zu > lange Leitungen legen zu müssen. Umgekehrt. Überlege wo gehäuft Sensoren/Aktoren benötigt werden und plane danach einen Buskoppler mit all diesen Schnittstellen. z.B. am Fenster (Rolladenmotor, Rolladentaster, Fensterkontakte, (Heizung)) oder an der Tür (Lichtschalter, ggf. Bedienpanel?, Türkontakt?, Türöffner). Die Steckdosen und Lampen willst du ja sowieso von zentral anfahren. Bleibt nicht mehr soo viel übrig, das wild verstreut ist. > Ich hatte auch mal angefangen jeweils 8 Taster mit integrierter LED > als Schaltelement zu verwenden... gefällt mir ganz gut... nur kommt > sofort wieder das Gehäuseproblem hoch ... Die EIB-Schaltereinsätze von diversen Schalterherstellern sollen dafür geeignet sein (Anschlüsse auf mehrpoliger Stiftleiste). Das EIB-Modul selbst gehört ja nicht zum Schalter dazu. Die sehen zumindest gescheit aus. Such mal in diese Richtung. @Unbekannter 29.07.2005 14:15 > Was ist "DOORS"? Dokumentations-/Dokumentenverwaltung - braucht man nicht. > Ich sehe die CAN-Nachrichten eher als Implemtierungsdetail und > konzentriere mich mehr auf die abstrakteren Zustände der > verschiedenen Komponenten: Ack. > Ein Taster kann gedrückt oder nicht gedrückt sein Ja, aber gerade die Taster sind ja (wie man hier an der Diskussion sieht) bisher nicht eindeutig so zuordenbar, d.h. es ist ein Unterschied, ob er zum ersten Mal gedrückt ist, oder ob zuvor (in deinem Konzept) ein anderer, virtuell verbundener Taster gedrückt wurde usw.. Ich würde deine/unsere Ausführungen mal so zusammenfassen: - Sensoren broadcasten ihre Statusmeldungen (Regensensor, Zeitschaltuhr "Aktoren, bitte Szenario Nacht einnehmen", Taster) - Bedienelemente (Taster...) schicken gerichtete Telegramme an die Aktoren - Aktoren reagieren/schalten in Abhängigkeit der Broadcasts und den empfangenen Telegrammen der Bedienelemente. (selbst broadcasten diese natürlich auch ihren aktuell eingenommenen Zustand, z.B. zur Visualisierung; Rückmeldung) Wobei man die Taster ja (noch?) nicht eindeutig einordnen kann?! > Mir ist bis jetzt noch kein Anwendungsfall eingefallen, den man mit > dieser Technik nicht ganz einfach parametrieren könnte. Auch hier wieder das Problem: Wie synchronisieren sich die einzelnen Taster im Betrieb? (wenn mal einer "später" dazukommt oder kurz ausgefallen ist).
@and_ref: "unsynchrones laufen"... ich würde die schalter lediglich stati senden lassen. somit macht die eigentliche "auswertung/verknüpfung" der aktor. und der is allein und kann so nicht unsynchron werden. daher hate ich doch mal gefragt ob es so schön ist die dimmwerte schon im taster zu erzugen, weil ich möglichst viel teilprogramm in den aktor packen würde und weniger in die taster evt habe ich auch fälle übersehen... aber wenn ich mal von einer realisierten "eltaco-schaltung" im flur ausgehe: ich würde einfach den aktor bei jedem tastvorgang den ausgang togglen lassen. bei dieser art schaltung würd ich nicht die taster ein "ein" und "aus" schicken lassen, dann könnten sie echt mal unsynchron laufen wenn einer das vorherige telegramm verpasst hat... aber wenn er nur "umschalten" schickt sollte es keine probleme geben mit dem "selbst mitzählen oder auch nicht" meinte ich die zeit des tastendruck für die knoten dies interessiert. (wird im wohnzimmer der lichtschalter (aus) gedrückt geht sofort das licht aus (1.aktor) und nach 2 sekunden werden alle steckdosen freigeschaltet (2.aktor)... so langsam aber sicher fürchte ich das ich mich damit anfreunde selbst tastsignale als broadcast zu machen. dann würd ich nur noch auf den aktoren ändern müssen... aber nun zu fehlenden telegrammen: wenns "make" fehlt": nicht schlimm, wenn der break als erstes ankommt wird der tastvorgang als ungültig ignoriert o.ä. anders wenn der break fehlt... dann dimmt er.. und dimmt... und dimmt :) da muss ich noch mal drüber nachdenken, guter tip könntest du noch mal ein beispiel für "unsynchrones" laufen nennen? zu den EIB-Tastern: ich habe nichts diesbezüglich gefunden, ich weiss nur das die schaltelement eine (ich mein) 2x5polige stiftleiste haben. das würde für nen 4fach-doppeltaster inkl. led schon nicht ausreichen. von daher denke ich das die kontakte und led´s nicht nach aussen geführt sind sondern per bus/seriell oder sonst wie dem eigentlichen busankoppler zugeführt werden... aber wie gesagt nix gefunden :(
mmh, noch mal eine sache über die wir noch gar nicht gesprochen haben: Stromausfall... ich möchte das nach dem stromausfall die gleichen schaltzustände herrschen wie vorher. jeden zustand im eeprom ablegen um bei evt. stromausfall die vorherigen zustände wieder herzustellen finde ich persönlich blöse, da bei 100.000 schreibzyklen (ok es dauert ne ganze zeit) das eeprom ja irgendwann mal totgeschrieben ist (und einigen sachen werden ja oft geschaltet...) also muss/soll der bus weiterlaufen. ich wollte eigentlich ein zentrales netzteil und ein akku einsetzen. ein 7Ah akku hält den bus laaaaange am laufen. evt reicht sogar ein kleines solarmodul zum laden des akkus, damit hätte man auch wieder eine gewisse ausfallsicherheit... was haltet ihr davon? oder wollt ihr einfach ein netzabhängiges netzteil einsetzen?
Bitte 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.