hallo, bei der wahl eines geeigneten hausbusses stört mich der gedanke des aubaus einer entsprechenden infrastruktur immer mehr. besonders in der hinsicht bereits zwei bestehender netze (240V und IP LAN/WLAN, beide bereits unverzichtbar ;-)) wird für mich der aufbau eines dritten (CAN oder 485) immer fragwürdiger. im neubau wäre es ja noch denkbar aber im altbau halte ich den aufwand für nicht mehr vertretbar. so wie es aussieht ist wohl auch der preisunterschied zwischen LAN- und CAN- interfaces in letzter zeit ziemlich geschrumpft. da auch die rechenleistung der prozzessoren enorm gestiegen ist habe ich meine zweifel das sich die geringeren anforderungen des CAN bezüglich hardware/software aufwand gegenüber des vorteils einer bereits vorhandenen infrastruktur und der unverselleren weltweiten verwendung noch lohnen. besonders bei verwendung von relativ wenig knoten(wie es im altbau sein wird) dürfte sich der einsatz eines zusätzlichen struktur(CAN) imho nicht mehr lohnen. nur bei einer hohen knotendichte (quasi jeder schalter und verbraucher seinen eigenen CANcontroller) würde es sich noch rechnen. da auch ein immer größeres angebot von günstigen massen IP LAN-geräten auf den markt kommt (obwohl technologisch aufwendiger so ist wohl mittlerweile das einstecken eines LAN-HUB günstiger(und gängiger) als die verdrahtung einer CAN-abzweigung ;-)) so schlägt wohl doch das pendel eher zu aufwendigen IP LAN als zu einfacheren Systemen . So betrachtet halte ich jetzt für mich, anstelle einer komplexen CAN architektur ala EIB mit repeater und routingfunktionen, mehr die Verwendung des IP-LAN gegeben. gegenfalls mit Raum/Insel subnetzen (I2C/1W Portexpander usw)ausgestattet. wie seht ihr dies? reinhard
Ich sehe das nicht nur bei Altbauten so. Warum sollte man sich bei Neubauten 2 Busse ins Haus legen wenss einer locker tut. Bald kommt QoS richtig zum Einsatz und man kann die Haussteuerung ja in einem anderen Subnetz fahren so das man keinen Virus in sein Haus bekommt. Nur wie siehts mit der zu verwendenden Hardware aus?
Toll wärs schon - und ich denke wenn das schön gekapselt wird, ist es dem [OS-HB] egal ob er über CAN oder Ethernet läuft - aber das LAN-Interface halte ich momentan noch für Utopie. Was kostet so ein Chip, wo kann man den bekommen (ich meine in Stückzahlen, keine Samples) und wie aufwändig ist der zu verdrahten/programmieren? Auch wenns einfacher geworden ist, ich denke momentan ist es noch keine wirkliche Alternative. Ich bin auch der totale Netzwerkfan, bei mir sind sogar am Grillplatz im Garten hinter der Garage Netzwerkanschlüsse, aber trotzdem zweifle ich ein wenig... Aber ich lasse mich gern vom Gegenteil überzeugen. Wenn es ein vernünftiges Konzept gibt, bin ich gern dabei. Mit dem [OS-HB] möchte ich auch baldmöglichst weitermachen, nur momentan macht mein Server derartige Probleme, dass ich schon fast vermute, dass er weiblich ist oder weibliche Züge entwickelt oder wasweissich... Aber bis meine beiden gecrashten Platten mit den wichtigen Daten wieder laufen, werde ich mich erstmal darum kümmern, deswegen bleibt leider wenig Zeit mich um den Hausbus zu kümmern... :-/
Guck dich doch mal auf der HP vom Hersteller um, soll ganz einfach zu handeln sein da der Ganze ethernet Kram auf Hardwareebene laueft. Das Teil kann dann via I2C an den AVR angebunden werden. Zum Preis/beschaffbarkeit kann ich im Moment nix sagen. Aber 1-3 von den Modulen pro Zimmer ist doch sicher machbar, oder? Dann in jedem Raum an strategisch guter STelle (WAF) einen kleinen Unterputzkosten wo die LAN Platine via LSA Klemmen mit ihren Sensoren verbunden werden kann. Hier koennen dann auch die Relais fuer die Aktoren Platz finden wenn man das nicht zentral machen moechte.... Mode
Hab grad mal die andere Diskussion angeschaut (http://www.mikrocontroller.net/forum/read-1-179365.html), das hört sich besser an als ich dachte... Wenn man von diesem Chip Samples bekommen könnte, könnte man das testen bzw. in unser Projekt einbeziehen. Wär ne Sache, schon allein wenn man nur beispielsweise ne Bridge daraus basteln könnte - um längere Strecken über Ethernet überwinden zu können. Aber für direkte Knoten wärs natürlich auch super. Vom Protokoll her denke ich sollten wir das auf jeden Fall berücksichtigen, aber unser Vorschlag geht ja eh schon in Richtung IP. @reloni: Hättest du mal Lust, dich mit der Materie zu befassen und evtl. mal mit den Samples zu experimentieren?
hallo, nach ein paar tagen internetabstinenz wieder da. allgemein denke ihr das ähnlich wie ich sehe: 1:CAN-Bus als notlösung da ethernet zu aufwendig. 2:wenn ethernet einfacher dann wechsel! Wenn ich mir den oben genannten thread http://www.mikrocontroller.net/forum/read-1-310134.html mit der projektvorstellungvon Sssssssssssss: http://avr.auctionant.de/avrETH1/ so denke ich das dies (evtl. mit ein paar winzigen modifikationen)die richtige Hardware Basis für ein Hausbus wäre: mit ethernet anbindung : also eine bereits in den meisten technikfreundlichen häusern vorhandene infrastruktur. mit PoE (power over ethernet) könnte die bei vielen knoten aufwendige Versorgungsproblematik. die platine könnte wohl noch installationsdosen gerecht dimensioniert werden. der mehrkostenaufwand des ethernetcontrolers gegenüber CAN wäre mit (so wie ich es rauslese) ca 5 euro nicht das entscheidende kriterium. insbesondere da sich dafür die vernetzung in den meisten fällen vereinfachen würde. das was mich persönlich noch stört wäre dieses smd design. da ich nicht unbedingt der hardwarefreak bin ist es für mich erstmal ein gravierendes hindernis. da andererseits das größenproblem für den steckdoseneinbau dies wohl sowieso erfordert würde ich auf eine dip- portierung absehen. ideal wäre es wenn man eine standard os-hb version entwickeln könnte und diese als sammelbestellung fertig smdbestückt beziehen könnte. aber ich werde ersteinmal noch das obengenannte projekt beobachten. auch für das eingebaute html protokoll könnte ich mich erstmal anfreunden. ließe es doch erstmal eine sehr offene software struktur zu (es heißt ja schließlich OS-HB ;-) ) daher sehe ich auch erstmal keine veranlassung es zu kapseln. man solte noch mal durchchecken inwieweit ethernet html der erforderlichen hausbus performence entspricht. alternativ hätte ich da noch snmp: im hinterkopf. schau reinhard
Eben. niemand zwingt dir mit dem Teil HTML auf. Waere auch garnicht so
gut dafuer. Gerade SNMP ist doch genau zum Steuern und Auslesen von
Geraeten gemacht:
* Überwachung von Netzwerkkomponenten.
* Fernsteuerung und Fernkonfiguration von Netzwerkkomponenten.
* Fehlererkennung und Fehlerbenachrichtigung.
Laeuft zwar ueber UDP auf SNMP wartet ja auf nen Response so dass das
Licht auf jeden Fall angeht - auch wenn das erste UDP Paket verloren
geht. Dauert dann eben nur ein paar ms laenger.
Und gerade Geschwindigkeit ist wichtig. Es kann nicht sein dass das
Licht nach Knopfdruck noch 500ms braucht bis es angeht. Daher auf jeden
Fall so etwas Kleines wie SNMP.
H.V.
nein - keines falls fühle ich mir das html aufgezwungen. im gegenteil - ich bin begeistert von den möglichkeiten - man stelle sich vor: jeder lichtschalter seine eigene hompage: wwww.lichtschalter.badezimmer.mysweethome.net/acces.php?switchble=false mit bebildeter bedienanleitunganfahrskizze und gästebuch ;-) reinhard
zum protokoll habe ich mir folgende gedanken gemacht: zwei hauptlinien 1. kompaktes binär basierendes festframe Päckchen 2. komplexes asciibasierendes freiskalierbares Päckchen zu 1. wenig traffic, rel. einfach zu codieren, decodieren, keine strigverarbeitung/hochsprache erfoerdlich, geeignet für kleine controller. nicht mit monitor_/terminalprogramm lesbar, nicht skalierbar und nur aufwendig zu modifizieren,gut geignet für einfache schaltfunktionen zu 2: viel traffic, bei kleinen controller aufwendig zu codieren/decodieren, erfordert im allg. hochsprache mit stringverarbeitung. eher für größere controller geeignet. mit normalen terminalprogramm sichtbar und sendbar. beliebig skalierbar und modifizierbar. gut geignet für komplexere geräte wie klimasteuerung und mediageräte anbindung. da beide hauptlinien ihre daseinberechtigung haben möchte ich auch beide im projekt ermöglichen. dies ist durch die vergabe unterschiedlicher ports auch ohne crashwahrscheinlichkeit gegeben. Protokoll 1 OS-HB_Ethernet_BIN_protokoll grundprotokoll UDP! da nicht zuviele protokolle im OS-HB rumschwirren würde ich hie, wie auch beim CAN bus das CAN/CANopen Protokoll verwenden. damit man auch brücken leicht bauen kann sollte das CAN-Protokoll einfach in UDP eingepackt/gekapselt werden (ob mit oder ohne CAN-Header weiß ich noch nicht?). bis auf die eigentliche CAN/Ethernet-Baustein-Kommunikation könnten die gleichen encoding routinen verwendet werden. Protokoll 2 OS-HB_Ethernet_Text_Protokoll auch hier grundprotokoll UDP vorrausgesetzt das wir hier bei standards bleiben(was ein prinzip von mir ist) sehe ich zwei möglichkeiten: 1 XML http://de.wikipedia.org/wiki/Xml 2 SNMP ( http://www.jklein.de/techniker_arbeit/tech_html/snmp_allgemein.htm ) Beide sind textbasierend und freiskalierbar . snmp (einfaches netzwerk verwaltungs protokoll) wäre altbewährter standard zum verwalten von netzwerkkomponenten wie router, printserver usw. es beinhaltet wie CANopen nicht nur den aufbau des eigentlichen packetes sondern auch den dazugehörigen hintergrund wie spezifizierte geräte tabellen und variablen. das heißt wenn wir uns für das snmp system im ganzen entscheiden würden dann hätten wir uns auf viel mehr festgelegt als nur das protokoll. und wir müssten uns auch ne ganze menge spezifikationszeug reinziehen.(siehe link oben) xml ist noch flexibler als snmp. festgelegt wäre nur der aufbau der textnachricht. das heißt wir wären im weiteren freier für die umsetzung .frei heißt nun das wir uns nicht versenken müssen in die snmp spezifikation sondern uns in der umsetzung frei austoben können. Allerdings dies auch müssen!
Bei einem Binärprotokoll kann man noch ein Java Applet entwickeln das dieses Protokoll beherscht. Dieses kann man gleich über den Webserver ausliefern. Mfg Michael
Aber bestimmt nicht ueber einen Webserver auf uC Basis! Und nein ich will auch so kein Java im Hausbus. Ist ungeeignet da viel zu langsam... dann lieber etwas mehr Programmieren.
Hallöchen, ich mische mich mal kurz ein :) Ich bin auch gerade dabei für meine (dieses Jahr zu sanierende) Hütte ein Automatisierungssystem zu entwickeln und lese hier deshalb mit großem Interesse mit! Ich werde auf jeden Fall auf Ethernet als Bus setzen und habe auch schon eine Hardwareplattform bestehend aus einem MSP430 Board mit CS8900A Ethernet Chip, dass ich um ein bisschen IO und Stromversorgung über Netzwerkkabel erweitere. Unter anderem werde ich auch ein grafisches Display, einen Encode, einen Lautsprecher und ein Mikrophon anschließen. Zum Protokoll: Ich schicke Nachrichten über UDP mit Bestätigung, die ein eigenes binäres Format enthalten. Habe mir gerade mal den SNMP Link angeschaut. Im Prinzip habe ich ein ähnliches Protokoll entwickelt, nur etwas einfacher. Ich bin nicht sicher, was es für Vorteile hat auf SNMP zu setzen. Vorhandene Applikationen sind vermutlich sehr speziell auf bestimmte Hardwareprodukte programmiert, oder? Deshalb wird es eh nötig sein, eine eigene Software zur Konfiguration und Überwachung zu schreiben. Ausserdem scheint es mir ziemlich aufwändig zu sein, eine komplette SNMP Unterstützung in den Geräten zu programmieren. Es ist ja auch die Frage, ob die Geräte untereinander oder nur über einen zentralen Server kommunizieren sollen? Ich plane die zentrale Variante. Das geht zwar zu Lasten der Ausfallsicherheit, hat aber viele Vorteile. Mein Protokoll hat Befehle und Events, dass heißt, sowohl der Server (Master) als auch die Nodes (Clients) können Nachrichten senden. Clients senden Events an den Master, wenn sie sich Initialisieren und wenn sich Eingansdaten ändern. Der Master schickt Konfigurationsparameter auf einen INIT-Event und SetAktor-Befehle aufgrund eines beliebig komplexen Regelwerks, dass ich definitiv nicht auf einem 8 oder 16 bit Controller programmieren möchte :) Es gibt Befehle um Geräte-Variablen (Inputs und Outputs) zu lesen und zu schreiben (nur Outputs). Die Serversoftware schreibe ich in .NET. Ich will versuchen, sie unter Mono zum Laufen zu bekommen, dann kann ich nämlich las Haardwareplattform z.B: einen Linksys NSLU2 einsetzen und muss keinem PC vertrauen ! Gruß, Jan
Warum traust du einem Linksys NSLU2 mehr als einem PC? ServerPCs mit KLEINEM Stromverbrauch und Notebooklautstaerke gibt es NEU ab 300 EUR zzgl Mwst vom Markenhersteller. Dem wuerde ich mehr vertrauen als einem Linksys NSLU2 ;)
Naja, allein schon mal weil er keine beweglichen Teile hat (z.B. Festplatte) Ich habe eh einen LInux-Server laufen. Möglicherweise nehme ich den NSLU2 auch nur als Backupsystem. Muss auch kein NSLU2 sein. Der steht halt bei www.mono-project.com auf der Liste der Geräte, die momentan unterstützt werden! Gruß, Jan
Take Raid 1 ;) Natuerlich reicht auch was kleineres wenn er nur Hausbus machen muss. Aber mein Linux Server hat schon allerhand zu tun ;) Fuer Hausbus wuerde ich mri aber in jedme Fall konfigurierte Ersatzhardware daneben stellen die nur umgesteckt werden muss. Und ne Taschenlampe :)
Jupp, das ist auf jeden Fall sinnvoll. Klar, mein Server macht auch so Einiges. Aber ich würde ihn noch nicht als Hochverfügbarkeits-Plattform auslegen wollen :) Wenns Internet oder das Telefon mal nicht geht, geht ja nicht gleich die Welt unter. Aber RAID-1 ist auf jeden Fall ne sinnvolle Sache und kann jee Menge Ärger sparen...
... wenn ne Platte kaputtgeht. Wenn der Server einfach so sporadisch abstürzt und das Dateisystem mitzieht, dann hilft dir das auch herzlich wenig - das spür ich zur Zeit am eigenen Leib. Dann hilft nur noch ein gutes Backup. Aber Redundanz ist immer wichtig, deswegen find ich beim Hausbus eine dezentrale Steuerung sinnvoller...
Ok, damit wären wir wieder beim Thema (Protokoll). Hat sich denn schon jemand Gedanken gemacht, wie man das ganze System initialisiert? Jede Node muss dann doch eine (möglicherweise ziemlich umfangreiche) Konfiguration erhalten. Welche Nachricht wird an welche Node gesendet, wenn bestimmte Bedingungen erfüllt sind. Ich beabsichtige als Bedingung nicht nur das Ändern des Wertes eines lokalen Sensors zuzulassen sondern auch komplexere Verknüpfungen abhängig von Zeit, globalem Status des Systems, Sensorwerten von anderen Modulen, etc... Ausserdem kann eine Aktion ja mehr sein, als einfach einen Aktorwert einer Node zu setzen. Da können ja auch zeitliche Abläufe gewünscht sein, die mehrere Operationen beinhalten. Das kann ja beliebig komplex werden - deswegen bin ich für eine zentrale Steuerung. Ich implementiere gerade eine Art einfache Programmiersprache, mit der ich solche Aktionen, Regeln und Bedingungen formulieren kann. Die werden dann zyklisch oder beim Auslösen von Events zentral geprüft und die entsprechenden Aktionen werden gestartet.
Also wenns ums Thema Protokoll geht, wäre das im anderen Thread besser aufgehoben... Ich persönlich halte aber von der rein zentralen Steuerung nicht viel - wenn dein Server mal weg ist, dann hockst du im Dunkeln und wirst den Tag verfluchen an dem du dich für diese Methode entschieden hast. Wie schon erwähnt - mein Server zickt derzeit auch ziemlich rum und stürzt dauernd ab, aber trotz stundenlanger Suche hab ich den Fehler nicht lokalisiert, weil dieser sporadisch auftritt. Vermutlich sind irgendwelche Elkos defekt oder was auch immer... Hast du das bei deinem Hausbus auch, werden deine (besonders weiblichen) Hausgefährten schnell einen Krieg anzetteln, wenn was nicht funktioniert... Aber warum muss man das festlegen? Man kann doch auch ein Multimaster-System nehmen und ein Controller hat eben besonders viel Intelligenz. Ob das ein PC oder ein "größerer" µC ist, ist ja egal. So wie es in dem Thread über die Hutschienenkomponente beschrieben ist. Jeder Taster kann selbst eine Lampe ansteuern, aber es gibt auch einen Controller im Sicherungskasten, der eben für komplexere Aufgaben zuständig ist. Wer den nicht haben will, lässt ihn weg, wer nur ne zentrale Steuerung haben will, baut die und wer beides haben will kann dies auch realisieren...
Klar, beide Konzepte zu kombinieren ist vermutlich die beste Möglichkeit eine Balance zwischen Ausfallsicherheit und Funktionsumfang zu haben. >wenn dein Server mal weg ist, dann hockst du im Dunkeln und wirst den >Tag verfluchen an dem du dich für diese Methode entschieden hast. Naja, deswegen werde ich wenn möglich Hardware einsetzen, die a) günstig ist, damit ich ein zweites System einfach daneben stellen kann und b) möglichst wenig bewegliche Teile hat.
am besten ist du machst eine linux-boot-cd... 2 gleiche rechner.. die cd kopierst auch gleich und legst in beide rechner ein... system rennt dann aus dem ram und du hast nie mehr probs ;) 73
Hallo Zusammen, bei meiner suche nach einem Ethernet Hausbus mit POE bin ich auf diese Thread gestossen. Hat einer von euch so eine Webserver als Aktor schon mal erfolgreich getestet. Mir geht es darum nicht noch mal die Wände aufreisen zu müssen. Ich habe ca. 8 Zimmer die mit einem Netzwerksanschlusss versehn sind und an einem MDIX fähigen Switch hängen, Teilweise sind DBox 2 Receiver ans Netz angeschlossen. Jetzt wollte ich in die Zimmer noch normale Switches anschliessen und an diese dann die Actor die mir Schaltzustände melden b.z.w. diese auslösen können oder wäre es doch besser auf CAN zu setzen und eine Leitung zusätzlich zu legen. Gruß Uwe
Naja ich vermute mal, du hast kein Gigabit - dann sind doch die Adern 4/5,7/8 nicht belegt. Wenn du diese in den Dosen abgreifst oder dir einen Adapter bastelst, kannst du die verlegten Kabel verwenden und trotzdem CAN darüber fahren. Bei einem Webserver seh ich das Problem der Instabilität - der hat sehr viel Code drauf und ist dementsprechend fehleranfälliger. Bei unserem OS-HB Projekt (http://devel.antimon.de/hausbus) haben wir auch Konverter CAN/Ethernet geplant, aber da sind wir leider noch nicht so weit. Ausserdem sind die Kosten für einen Ethernet-Knoten um einiges höher als die eines CAN-Knotens... Also ich würd vorschlagen, nimm CAN. Ausserdem ist bei PoE die Spannungsversorgung das Problem - die Step-Down Regler von 48V sind sehr schwer zu bekommen... ansonsten wärs toll.
Was mit dem eZ80Acclaim hat der nicht schon alles was man dafür bröchte? Und mit etwa 25 für ein fast Fertigen Knoten ist es noch ganz ok...
Naja, der eZ80F91 wäre vergleichbar (von dem, was er in einem Knoten an Funktion abdeckt) mit einem uC (mind. 32kB Flash denke ich mal) und einem Ethernet-Controller. Wenn man da einfach mal einen ATmega128 (ca 10€) und einen ENC28J60 (ca 6€) nimmt, ist man nur bei 16€ ... Das drum rum dürfte bei beiden Varianten etwa gleich sein.
Also erst mal vielen Dank für eure Antworten, aber jetzt bin ich genau so schlau wie vorher. @Matthias Beitz: Wenn bleib ich beim AVR der eZ80Acclaim hat einen Z80 Core und das heist wieder umdenken und ich bin einer von den ATMEL Fans ;-). zu dem beschäftige ich mich mit den ARM von ATMEL. Na mal sehen werde jetzt erst einmal den avrETH1 etwas anpassen oder was eigenes entwickeln und ein paar versuche machen danach geht es weiter mit POE und evtl. Funkmodulen für den Gartenbereich. Gruß Uwe
Der ENC28J60 hatte ich noch gar nicht gesehen das teil scheint sehr nett zu sein leider nur 10MBit... Dann Blinken gar nicth alle lampen am Switch aber naja für einen Hausbus recht es dicke und dreifach... Gibt es dafür schon fertige Experimentierplatinen? In Software entwickeln bin ich ja gut aber Routen in Eagel ist nicht so mein fall... Auf alle fälle brauchen die Knoten dann PoE versorgung...
Sorry wenn ich da als Neuling etwas in die Diskussion reinplatze. Ich habe auch mal über Ethernet zur Hausautomatisierung nachgedacht, habe das aber wieder verworfen. Vielleicht lag ich ja falsch. Ethernet ist ja eine Sterntopologie. In der Industrieelektronik geht der Trend derzeit zu Bausteinen, die zwei Ethernet Konoten on Board haben, so dass jeder Baustein quasi ein kleiner Switch ist. Damit kann man dann lange Stränge bilden. Aber so ein Konzept scheint ja hier niemand zu planen. Würde auch die Kosten für einen Knoten deutlich hochtreiben, weil zwei komplette Ethernet Anschlüsse benötigt würden. Die Alternative wäre in jedes Zimmer einen eigenen Ethernet Strang mit einem riesen zentralen Switch zu machen oder alternativ diverse Unterswitches ? Ich habe mal die Stromaufnahme meines Routers gemessen, der liegt bei 10W, was etwa 10 Stromkosten im Jahr bedeutet. Von daher finde ich die Lösung mit diversen Unterverteilern auf Dauer etwas teuer. Gruss Axel
Das was du da erwähnst sind so ziemlcih die 3 Hauptpunkte warum Ethernet als Hausautomatisierungsbus ungeeignet ist. 1. Sternform. Benötigt unmassen an zusätzlichen Leitungen + riesen Hub/Switch oder viele kleine Switches. 2. Kosten. Ethernet mit allem drum und dran ist atm wohl immer noch (wenn auch nur geringfügig) teurer als andere Busse. Sowas macht sich halt bemerkbar, wenn man >50 Knoten hat. 3. Strom. Sowohl Hubs/Switches ziehen da Strom, als auch die Ethernet-Hardware auf den Knoten. Ich habe in einem Projekt von mir den ENC28J60 im Einsatz, der zieht alleine etwa 150mA bei 5V also 0,75W. Wenn man jetzt davon mal 50 Knoten hat, ist man auch schon wieder 37,5W ... Auch die Implementierung einer geeigneten Ethernet-Software auf den Knoten dürfte da eine ziemlich lange Zeit in Anspruch nehmen und als minimal-uC (bei Atmel) den ATmega32 vorraussetzen... Gruß, Chris
http://www.beitz-online.de/catalog/product_info.php?products_id=74&osCsid=3887b7ed3f066758aba9fb76f43f3a61 Dort ist der ENC28J60 nun für 3,99 verfügbar... Das spart dann noch mal 2...
Hallo, also ich kann auch nicht sagen ob Ethernet zur Zeit die beste
Lösung ist. Vielleicht ist das gerade zur Zeit eher eine
Geschmacksfrage.
Aber ich habe mir den ganzen Thread durchgeleesen und wollte nur mal
ein Scenario erläutern was mir so in den Kopf kam:
-----
Also zunächst zu den Nodes. Es gibt einen Standartbaustein dieser hat
neben der Verbindung zum Ethernet zum Beispiel 8 Eingänge 8 Ausgänge.
Außerdem klept auf jedem dieser Bausteine ein Aufkleber mit seiner MAC.
Diese Bausteine werden einfach verbaut, an ihre Ein und Ausgänge werden
Scahlter und Lampen angeschlossen. Diese Bausteine sind erstmal ganz
dumm.
Wenn ich das System jetzt einschalte, wird nix passieren. Die
Standardmodule werden keine Daten im Ethernet verschicken. Doch jetzt
kann ich meinen Laptop an das Netzwerk anschließen und eine Software
starten. Diese sucht erstmal alle Standartmodule und zeigt sie mir in
einer Liste an. Jetzt kommt erst der Teil der nicht so viel Spaß macht,
mir aber später die Arbeit enorm erleichtert: Ich habe mir die
MAC-Addresse der Standartbausteine beim verbauen aufgeschrieben und
kann den einzelnen Modulen jetzt Namen verpassen (zB "Schlafzimmer").
Nun kann ich über die Software die Standartmodule vituell verschalten.
Rein Grafisch, ohne Programmierkenntnisse.
Hier als Beispiel: Mit den Schaltern an Modul A kann ich die Lampe an
Modul aus und einschalten. Mit den Schaltern an Eingang 1 der Module B
& C kann ich den Zustand der Lampe an jeweils umgehren (also an nach
aus und um geh kehrt ;) ) AUßerdem kann ich mit Modul C auch die zweite
Lampe steuern.
+-------------+
| Modul A |
| |
| Eingang 1 |-----------+
| | |
| Eingang 2 |---------+ |
| | | |
| 1 | | | |
| 0 } Aus 1 | | |
| T | | | |
| | | |
| 1 | | | |
| 0 } Aus 2 | | |
| T | | | |
+-------------+ | |
| |
+-------------+ | | +-------------+
| Modul B | | | | Modul D |
| | | | | |
| Eingang 1 |-----+ | | | Eingang 1 |
| | | | | | |
| Eingang 2 | | | | | Eingang 2 |
| | | | | | |
| 1 | | | | +--->| 1 | |
| 0 } Aus 1 | | +----->| 0 } Aus 1 |
| T | | +--------->| T | |
| | | | |
| 1 | | | | 1 | |
| 0 } Aus 2 | | | 0 } Aus 2 |
| T | | | +---->| T | |
+-------------+ | | +-------------+
| |
+-------------+ | |
| Modul C | | |
| | | |
| Eingang 1 |-----+ |
| | |
| Eingang 2 |--------- +
| |
| 1 | |
| 0 } Aus 1 |
| T | |
| |
| 1 | |
| 0 } Aus 2 |
| T | |
+-------------+
Wenn ich fertig mit der Planung bin gibt die Software jedem Modul eine
kleine liste mit auf den Weg:
zB Modul C:
Ausgang 1 -> Sende T an Ausgang 1 von Modul D
Ausgang 2 -> Sende T an Ausgang 2 von Modul D
Für kompliziertere Dinge kann man immernoch ein kleines Modul als
Steuerzentrale anschließen, das kann dann Zeitgesteuert Lampen
einschalten, beim verlassen der Wohung die gesammte Stromversorgung in
der Küche ausschalten, oder auch als Webinterface dienen. Aber wenn es
ausfällt funktioniert immernoch die normale Lichtsteuerung.
Was die Kosten und den Stromverbrauch angeht müßte vielleicht ein
Kompromiss gefunden werden: Zum Beispiel sollte jedes Modul viele Ein
uns Ausgänge haben, so das hat nicht jeder Schalter ein eigenes Modul
haben muss sondern nur jedes Zimmer. Das würde natürlich auf Kosten der
verdratung gehen.
Wäre toll von euch zu hören was ihr davon denkt.
Wenn du das Ganze auf CAN aufbaust und nur einen Adapter von CAN auf Ethernet bastelst, kannst du das Gleiche erreichen, aber vermutlich um einiges günstiger bei der Anschaffung und auch im Betrieb (Verbrauch). Denn Ethernet ist für sowas eigentlich Overkill - erstens hast du sehr umfangreiche Software, dann brauchst du mehr Bausteine die vermutlich mehr Strom benötigen. Und dann brauchst du auch noch mehr Leitungen zu den Knoten...
Auch die CAN brauchen Strom und das mit den mehr Leitungen stimmt nicht ganz so wenn du eine CAT 5e Leitung nimmst ist ist die Leitung vom CAN voll Belegt es sei den du nutzt nur einen Bruchteil des CAN. und mehr Bausteine auch nicht unbedingt: http://home.cogeco.ca/~hduff/EIO_Main.htm das Board müsste nur etwas modernisiert werden, das mit der Software wäre für mich auch kein Probelm als Progger und ein Server steht sowieso bei mir im Büro das einzige was man zusätzlich bräuchte wäre ein Hub oder ein Switch aber sowas wie ein zenralknoten brauchst du auch beim CAN. Also meine Entscheidung ist immer noch nicht gefallen, bin zwar auch im Hausbusforum auf deiner Webseite aber CAN oder Ethernet weis ich immer noch nicht. Gruß Uwe
Hmmm ... ich kenne mich mit CAN nicht so gut aus. Ich bin gerade am überlegen ob es möglich wäre eine Platine zu entwerfen die je nach bestückung mit CAN oder Ethernet abeitet. Gibt es denn ein aktives Projekt wo sowas schon versucht wird?
Also das Argument mit der Leitung, die von CAN belegt sein soll, kann ich nicht teilen. CAN braucht 2 Drähte, wenn du noch die Spannungsversorgung dazuschaltest hast du 4 - dann sind noch 4 frei, die z.B. noch für Ethernet verwendet werden könnten. Bei Ethernet hast du allein 4 Leitungen nur für Daten - ohne Spannungsversorgung. Dann brauchst du noch einen Switch/Hub, der wieder extra Strom braucht, geschirmte Kabel, etc. Einen zentralen Knoten braucht man bei CAN nicht, das ist der große Vorteil. Ich meine, es ist natürlich jedem selbst überlassen was er verwenden möchte - aber ich brauch mir keinen Ferrari zu kaufen wenn ich eh nur mit angezogener Handbremse in der 30'er Zone fahr... ;) Knoten verschiedenster Art wird es bald bei uns geben - ein Schaltknoten mit 16 Ausgängen und 4 Eingängen (erweiterbar) ist bereits vom Layout her fertig, ein Unterputz-Schaltknoten auch. In Entwicklung ist gerade ein USB-CAN Adapter sowie ein CAN-Ethernet-Adapter. Weitere Sensoren und andere Knoten sind noch in Planung. Ich hab momentan leider Prüfungszeit und kann mich dem Projekt deswegen nicht voll widmen, aber Alloc und trick sind immer fleissig am Entwickeln und in 4 Wochen werd ich auch wieder voll einsteigen können. Aber wer an dem Projekt interessiert ist und mithelfen möchte, kann gern einsteigen, dann geht das Ganze noch schneller...
Also ich habe eben meine Entscheidung getroffen ich werde CAN einsetzen und extra Leitungen legen da es zu beträchtlichen Störungen kommen kann. Ich nutze das Ethernet unter anderem für Streaming (DBox2, PC) es kann zu Störungen vor allem beim Aufnehmen kommen. Also werden jetzt noch vorraussichtlich zwei Leitungen dazu kommen, eine für CAN und eine für 12V oder 24V. Gruß Uwe
Ich finde die Idee gemeinsamm einen Hausbus zu entwickel sehr gut! Anscheinend gibt es aber schon bei der verwendetet Übertragungshardware (CAN/Ethernet) Meinungsverschiedenheiten. Dabei wäre das vielleicht garnicht so entscheident, denn wenn man sich einen einzelnen Teilnehmer von so einem Hausbus anschaut, dann Wäre sowohl auf der Hardwareseite wie auch auf der Softwareseite vieles unabhängig vom Bus. Hardware Seite Software Seite +------------------+------------------+ | Hardware der | Steuerung der | | Ein und Ausgänge | Ein und Ausgänge | +------------------+------------------+ | | Handhabung der | | Mikrocontroller | ein und aus- | | | gehenden Daten | +------------------+------------------+ | CAN / Ethernet | CAN / Ethernet | | Controller | Logik | +------------------+------------------+ So könnte der Hard und Softwareteil der bei beiden verfahren zum Einsatz kommt von beiden verfechtern entwickelt werden, und der sezielle CAN/Ethernet-Teil von den jeweiligen Gruppen. Eine Platine die je nach Bestückung an einem CAN-Bus oder am Ethernet hängt, würde auch die Kosten pro Stück drücken. Und vielleicht könnte man sogar ein Modul bauen, sodas man zwischen CAN und Ethernet vermitteln kann, ohne das die Teilnehmer davon überhaupt was merken. Dann könnte auch ein CAN-Verfechter zwei CAN-Sub-Netze über Ethernet verbinden, oder umgekehrt.
Autsch, Florian ganz so einfach ist das nicht. Mal abgesehen davon das CAN ein ganz eigenes Protokoll hat so sieht es bei Ethernet schon mal ganz anders aus, dort gibt es gleich mehrere Protokolle (TCP/IP, UDP, FTP, u.s.w.). Also verbinden so wie du dir das vorstellst ist nicht, du kannst zwar das CAN Modul über eine CAN<>PC Schnittstelle mit einer Software auf dem PC Steuern aber beide Netze nicht miteinander verbinden. Packetaufbau beim CAN:http://vvl.fh-reutlingen.de/cocoon/my/vvl/vvl?lang=de&goto_page=P_GLP_CAN_INTRODUCTION&open=1&mute= Gruß Uwe
Danke erst mal für den Link. Wenn ich es richtig verstanden habe gibt es doch auch bei CAN-Nachrichten ein art Zeiladresse oder? Bis zu 128 Teilnehmer? Wenn es so ist hätte ich noch die Frage wie diese Zieladresse ausgehandelt wird. Oder stellt man die schon vorher ein?
CAN arbeitet im Gegensatz zum Ethernet mit Nachrichten-IDs, nicht mit Adressen. Teilnehmer kannst du im Prinzip beliebig viele haben, lediglich begrenzt durch die Buslänge und die Treiberfähigkeit der Bausteine (eben die ca. 128) Nachrichten-IDs gibts aber 536870912 (2^29), wie viele Bausteine auf eine Nachricht hören ist nicht festgelegt. Das Problem bei der Kombination seh ich im Platzbedarf - beides nach Bedarf zu bestücken wäre toll, aber in ner UP-Dose is verdammt wenig Platz...
Wie ich oben schon geschrieben habe kann es zu Störungen kommen das liegt ganz einfach daran das z.b. ein CAN Modul eine Anfrage sendet diese Anfrage geht erst einmal an alle Module wenn dann ein Modul erkennt das es gemeint ist sendet dieses wieder eine bestätigung an den Absender damit dieser gewißheit hat das, daß Modul noch da ist und die Nachricht auch empfangen kann erst dann wird die Nachricht gesendet. Aber mal davon abgesehen kann man anhand der ID's den Modulen Prioritäten zuordnen. Gruß Uwe
> diese Anfrage geht erst einmal an alle Module wenn dann ein Modul > erkennt das es gemeint ist sendet dieses wieder eine bestätigung an > den Absender Wenn du damit den Acknowledge-Mechanismus beschreiben wolltest (den jeder CAN-Controller automatisch verwendet), dann trifft das so nicht zu. Es sendet JEDER Knoten ein Ack, wenn er die formale Richtigkeit des CAN-Telegrammes erkannt hat - egal ob er sich für das Telegramm interessiert oder nicht. Wenn du eine höhere (Applikations-) Schicht beschreiben wolltest, oder deine Umsetzung, dann kann man das natürlich so machen. Hier gibt es immer wieder viele Missverständnisse wenn das Thema CAN aufs Tablett kommt... Und was du mit den Störungen meinst, habe ich nicht verstanden.
Da durch die Ethernetmodule relativ viel Traffic erzeugt werden kann, können Störungen beim Streamen oder beim Telefonieren (Voice over IP) entstehen. Mit dem ACK hast du natürlich Recht, wo hatte ich nur wieder meinen Kopf ;-). Bei mir kommen Ethernet (Streamen,Voice Over IP, Kameras), CAN (Steuerung und Sensoren), 230V (Licht und Steckdosen), 24 / 12 V (Reserve Module, Rolladen-motor, Heizungsthermostat, u.s.w.) getrennt in die Wand und der CAN über ein Interface an den PC um Ihn Überwachen zu können ich kann mir Später mal vorstellen das ganze über einen Server mit anderen Rechnern oder einem PDA steuern zu können (C# mit Webservices). Gruß Uwe
Ist es den möglich über den CAN-Bus die einzelnen Nodes zu programmieren? Kann ich also bei einem Hausbus die einzelnen Nodes dann virtuell verschalten? Gruß Flo
Bei unserem Projekt ja - sofern es natürlich soweit ist. Die Software zeigt alle Nodes an und du kannst ihnen dann Aufgaben zuteil werden lassen und evtl. kleine Makros ablaufen lassen. Die Einstellungen werden dann natürlich in den Knoten gespeichert und sind unabhängig vom PC, dieser wird nur zur Konfiguration und Überwachung benötigt.
Was mir bei eurem Projekt aufgefallen ist: Ihr habt eine riesen Liste an verschiedenen Knoten. Warum entwerft ihr nicht erstmal einen Knoten der ein paar Ein- und Ausgänge hat und mit dem man schon viel machen kann. Den könnte man dann weiter entwickeln und optimieren bevor man sich weitere Knoten ausdenkt.
Die Liste ist hauptsächlich eine Ideensammlung, was möglich wäre. Ob und welche davon realisiert werden, hängt dann davon ab, was sinnvoll ist, was benötigt wird etc. Ein einfacher Knoten mit ein paar Ein-/Ausgängen ist in Entwicklung, und zwar zum einen ein Taster-Knoten für die Unterputzmontage sowie ein Schaltknoten für die Hutschienenmontage. Der Hutschienenknoten ist beispielsweise mit 4 Eingängen und 16 Ausgängen ausgestattet und um weitere Ein-/Ausgänge erweiterbar. Die beiden genannten Knoten werden natürlich zuerst fertig entwickelt und getestet bevor spezielle Knoten drankommen, aber ein gewisser Ausblick ist nie schlecht, beim Tunnelblick übersieht man oft wichtige Details, die einem später das Leben schwer machen. Beispielsweise sollte ich für das Protokoll wissen, welche Daten irgendwann mal übermittelt werden müssen...
Kann man das ganze nicht einfach als Can over Ethernet "entwerfen" oder übersehe ich dabei etwas? Die meisten dürften ja keine aufwendige Regelaufgaben mit viel Traffic haben sondern ab und zu mal ein Licht schalten, Rollladen betätigen,... Wenn man das ganze komplett in Can macht hat man doch etwas sehr spezielles - entscheidet man sich dann in wenigen Jahren doch für ein anderes System weil z.B. EIB spotbillig wurde hat man einen Bus liegen der schwer umzurüsten ist. Ethernet ist dagegen ein MAssenprodukt für das es sicher in vielen Jahren auch noch Komponenten geben wird und sich somit einfach weiterverwenden lässt. Garry
@garry: ach und wenn CAT7-Leitung liegt als CanBusLeitung kann man nicht auf EIB umrüsten? Das sehe ich aber anders.... greetz Danny
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.