Hi, da ich nun schon eine ganze Weile hier mitlese und mittlerweile auch alle Threads in diesem Forum mit Ausnahme des lindwurmartigen Monsterthreads Hausbus komplett gelesen habe, will ich auch mal meinen Senf loswerden. Was mir nicht ganz klar geworden ist: Gibt es hier das Bedürfnis ein Gemeinschaftsprojekt auf die Beine zu stellen, mit dem Ziel, am Ende die komplette Hardware und Software zu haben, die man nur noch in ein Haus einbauen muss, oder geht es mehr darum, sich bei seinen eigenen Hausbus-Projekten gegenseitig auszutauschen? Es scheint die Anzahl Leute die hier tatsächlich versuchen etwas gemeinsam auf die Beine zu stellen ist eher gering (?). Viele diskutieren zwar hier, was ja auch sehr schön ist, verfolgen aber wohl nur ihr eigenes Projekt. Falls wirklich ein Community-Projekt gewünscht ist, finde ich die Art, wie hier versucht wird dies zu entwickeln, sehr problematisch. Zum einen die Wikis, welches der Wikis ist denn als Hauptseite für dieses Projekt gedacht, es gibt ja eine Menge: Hausbaus, Hausbus_Diskussion, Can, Can als Hausbus Das Problem ist, das dort versucht wird, es allen Menschen recht zu machen die jemals auf die Idee mit einem Hausbus kommen könnten, es werden einfach alle Möglichkeiten aufgezählt: CAN, EIB, RS485, I2C, 1-Wire, Ethernet. Als Übersicht: Toll Zum Entwickeln: Horror Ein weiteres Problem ist, dass man sich schon über Sachen unterhält, die man ganz ganz zum Schluss machen sollte, wie zum Beispiel die Steckerbelegung oder das Aussehen der Benutzeroberfläche zum Konfigurieren der Knoten. Diese Dinge sind für den Anfang doch wirklich total unwichtig, weil man sie einfach selbst ganz zum Schluss noch ändern kann (Die Steckerbelegung braucht ja nur ein kleines bisschen Löten), selbst die Stromversorgung kann man über eine Änderung der Platine noch verändern, wenn das ganze Protokoll und die Software schon fertig ist. Um noch ein bisschen zu kritisieren (ich mache das gerne wie man sieht g), man sollte nicht versuchen Kompatibilität mit allem zu halten, das klingt gut auf dem Papier wenn man sich alle Möglichkeiten offen hält, aber dadurch führt dies zu einer riesigen Komplexität und im Endeffekt dazu, dass man nicht vorwärts kommt. CAN über IP oder ähnliches ist so etwas. Hier versucht man zwei völlig diametral entgegengesetze Ansätze miteinander zu verbinden: Hausautomation mit einem Bus wie CAN Hausautomation über Ethernet (ist halt kein HausBUS mehr) Dies sind total unterschiedliche Ansätze, während man mit CAN nur eine zentrale Leitung braucht, an die man die Teilnehme anklemmt und so problemlos >100 Teilnehmer erreichen kann, also in dem Haus eine Menge Schalter/Aktoren und Sensoren platzieren kann, muss man bei Ethernet für jeden Teilnehmer einen Platz am Switch bereithalten und das wird nicht nur unübersichtlich, sondern braucht auch eine Menge Platz (und Geld, weil Ethernet nunmal kompliziert ist und die Chips teuer, wie man an den beiden Threads zum Thema kleiner Webserver sieht). Zusätzlich hat man bei großen Dateitransfers über das Netz eventuell das Problem großer Latenzzeiten. Dies soll auf gar keinen Fall eine Polemik gegen Ethernet werden, es sind einfache andere Ansätze die beide ihre Einsatzberechtigung in unterschiedlichen Bereichen haben. Worauf ich hinauswill ist: Wenn man sie verbindet, dann kombiniert man hier nicht ihre Stärken, sondern ihre Schwächen, verbunden mit Protokoll-Overhead und einer Menge Möglichkeiten für Fehler. Mein Vorschlag: - Eine dedizierte Webseite für das Projekt, auf der man auch den Sourcecode und die Schaltpläne speichern kann (wenn das hier im Wiki geht und vom Betreiber erwünscht ist -> um so besser) (Falls die Antwort kommt: "Haben wir doch schon", dann die Frage: Welche der vielen?) - Einigung auf ein System (CAN/Ethernet/...) - Gucken welche Geräte man darüber anbinden möchte, welche Anforderungen dadurch gestellt werden und wie man das Protokoll gestaltet. (( Bei CAN ist sowas in der Art ja im Gange, auch wenn das leider wieder ausartet, >70 Beiträge sind leider nicht wirklich übersichtlich, sowas wäre im Wiki mit Vorschlägen, Pro/Kontra und dann evtl. einer Abstimmung und Einigung etwas leichter, insb. da die Diskussion leider etwas unspezifisch ausfällt. Ithamar Garbe hat das mit dem ersten Post sehr schön gemacht, das ist aber dann scheinbar etwas abgedriftet und außer Kontrolle geraten ohne wirklich auf seine angesprochenen Punkte einzugehen )) - Wenn man dann das Protokoll hat, auf eine grobe Hardware-Basis einigen, z.B. Can -> Atmel AVR + MCP2515 Ethernet -> Atmel AVR + ENC28j60 (nur als Vorschläge, bei CAN könnte man sich auch auf einen integrierten Controller einigen) - Überlegen wie man das am einfachsten und sinnvollsten in Source-Code übersetzt, so dass man zwar alles nutzen kann, aber nicht muss (z.B. Sensoren für Temperatur, Feuchtigkeit, Bewegungsmelder, Helligkeit, Tür/Fenster offen, etc.) Hierbei sollte man auch beachten, dass es die ICs in 10 Jahren nicht mehr gibt, und man das ganze möglichst so programmiert, dass man bei einem Austausch des uCs oder des Bustreibers nur einen kleinen Teil des Programms austauscht (C böte sich hier an, insb. weil die AVRs ja darauf ausgelegt sind). Dabei sollten die ganzen Materialien wie Source-Code und Schaltpläne auf der Website sein, damit auch die anderen etwas davon haben. Ich würde sehr gerne mithelfen, aber wenn ich ehrlich bin sehe ich momentan absolut kein Vorankommen, es wird zwar viel diskutiert, aber ohne sich am Ende auf etwas konkretes zu einigen. Ich hoffe jemand hat tatsächlich bis hier unten durchgehalten, dies ist jetzt auch wirklich der Schluss: Besteht interesse und wenn ja, welcher Website/Wikiseite ist der Hauptort? Wer hat überhaupt Lust an dem gemeinsamen Projekt teilzunehmen? Bitte kritisieren und kommentieren (und meine Kritik nicht böse nehmen, ist nicht so gemeint) Viele Grüße ProkyonA
Ich lese schon seit einiger Zeit in diesem Hausbus-Bereich mit, und sehe es, was die Threads angeht genauso. Nirgendswo wird über was Grundlegendes diskutiert. Es wandert gleich zu irgendwelchen völlig unwichtigen Sachen wie z.B. Steckerbelegung, oder so was, liegt wohl an der Art von "Bastlern". Ich hätte auch Lust an einem gemeinsamen Projekt teilzunehmen, wenn auch nur ganz, wenn dieses mit meiner Grundanforderung (diese nenne ich jetzt hier aus konstruktiven Gründen nicht) deckungsgleich ist. Sonnst bin ich halt nur am Anfang bei den grundsätzlichen Sachen dabei. Kann aber aus zeitlichen Gründen erst in ca. zwei Monaten mit einsteigen. MfG =>dnb<=
Also in einem muss ich dir schon mal voll und ganz zustimmen: Die Entwicklung hier vorzunehmen, finde ich auch nicht gerade optimal. Ich habe schon mehrfach angeboten, eine Seite einzurichten, die speziell für dieses Projekt ausgelegt ist. Die ist auch vorhanden, inklusive eigenem Wiki, Forum, Webspace, Subversion, Datenbank, ... Sie müsste nur genutzt werden. Allerdings gab es da die Kritik, dass man dann noch eine andere Seite aufrufen müsste um auf dem aktuellen Stand zu bleiben und hier hätte man alles zusammen. Stimmt einerseits, aber ich finde, dass die Themen hier total untergehen, weil eben alles zusammen mit anderen Themen diskutiert wird. Und deine Meinung unterstreicht das. Ich würde jetzt mal vorschlagen, jeder der aktiv mitarbeiten möchte, schreibt das hier rein und ich fange an, den Webserver einzurichten. Die Webseite schmeisse ich ins SVN, richte einen cronjob ein, der diese alle paar Stunden aus dem SVN ausliest und auf den Webserver spielt, so kann jeder, der möchte auch aktiv die Webseite gestalten. Im Forum kann dann speziell über verschiedene Bereiche diskutiert und die Ergebnisse im Wiki veröffentlicht werden. Das heisst ja nicht, dass hier nicht mehr gepostet werden soll, das kann man ja trotzdem machen, aber vielleicht nicht mehr so ganz spezielle, zum Projekt gehörende Dinge. Um das Ziel der Projektes auf den Punkt zu bringen: Es soll gemeinsam ein Hausbus entwickelt werden, basierend auf CAN/AVR, kostengünstig und einfach nachzubauen. Übrigens gehört der Wiki-Artikel Hausbus Diskussion dazu ;) Wo ich allerdings nicht ganz mit deiner Meinung übereinstimme, ist die Tatsache, dass man z.B. die Oberfläche ganz zum Schluss entwickeln sollte. Natürlich soll nicht am Anfang alles bis ins kleinste Detail besprochen werden, aber die Ideen sollten auch ins gesamte System einfließen. Wenn ich beispielsweise den Knoten per Oberfläche eine Adresse zuweisen können soll, muss ich das auch irgendwie im Protokoll definieren bzw. vormerken. Bei einem fertigen Protokoll könnte es Schwierigkeiten geben, das nachträglich einzufügen. So, jetzt bitte ich nochmal alle, die am Projekt [OS-HB] aktiv mitarbeiten möchten, sich hier zu melden, ich bereite derweil die Webseite vor.
Es freut mich, dass ich mit meiner Meinung nicht ganz alleine dastehe, insbesondere bei den Leuten die hier aktiv mitarbeiten ;) <quote> Wo ich allerdings nicht ganz mit deiner Meinung übereinstimme, ist die Tatsache, dass man z.B. die Oberfläche ganz zum Schluss entwickeln sollte. Natürlich soll nicht am Anfang alles bis ins kleinste Detail besprochen werden, aber die Ideen sollten auch ins gesamte System einfließen. Wenn ich beispielsweise den Knoten per Oberfläche eine Adresse zuweisen können soll, muss ich das auch irgendwie im Protokoll definieren bzw. vormerken. Bei einem fertigen Protokoll könnte es Schwierigkeiten geben, das nachträglich einzufügen. </quote> Je nachdem was du darunter verstehst. Man muss sich natürlich darüber klar werden wie man seine Busteilnehmer neuprogrammieren will. - Nur über eine Neuprogrammierung des uC, z.B. über ISP - Bootloader - Bei kleineren Dingen über CAN-Nachrichten Hier muss man natürlich aufpassen, das man sich keine Möglichkeiten verbaut, insbesondere da in einem Haus in dem man ja lebt, das ganze möglichst einfach, unkompliziert und fehlerfrei funktionieren sollte. Die uCs ausbauen und dann separat neuprogrammieren ist sicherlich die schlechteste Möglichkeit. Wenn es geht sollte die Neuprogrogrammierung aus der Ferne möglich sein (ich hab keine Ahnung ob das möglich ist). Wenn diese Möglichkeit vorhanden und gut dokumentiert (wichtig) ist, wo ist dann der Sinn schon an dem Programm zu arbeiten? Es ist im Endeffekt dann unerheblich ob man es in C,C++,Java,Eiffel,... schreibt und ob es auf Windows/Linux/MacOS läuft, da es jeder für seine Bedürfnisse anpassen kann. Insbesondere da das zugrundeliegende Protokoll noch nicht fertig ist und man auch erst testen muss ob das ganze so funktioniert wie man möchte. Du hast natürlich Recht, das man im Auge behalten sollte, dass es so eine Oberfläche geben wird (geben muss! sonst ist das ganze nicht auf Dauer sinnvoll benutzbar). Da mir die Grundvoraussetzungen AVR/CAN zusagen (ein Bus ist einfach sinnvoller als ein zentraler Ansatz imho), wäre ich auf jeden Fall dabei. Wie sieht das denn hier im Wiki mit Sourcecode/Schaltplänen aus? Wenn du auch ein Wiki zur verfügen stellen könntest, wäre das glaube ich eine sehr gute Möglichkeit. Insbesondere wenn wir dann das Programm schreiben ist so etwas wie Subversion extrem hilfreich. Ich würde trotzdem vorschlagen, selbst wenn wir dies auf deinem Server machen, die Verbindung hierhin auf keinen Fall abreißen zu lassen. Grüße, ProkyonA
Also ich habe jetzt unter http://devel.antimon.de/hausbus eine Seite eingerichtet, die sich ganz dem Projekt widmet. Momentan sind ein Forum und ein Wiki vorhanden, SVN schalte ich bei Bedarf frei und Mailinglisten könnte ich auch einrichten. Bitte schaut doch mal auf der Seite vorbei und helft mir, die Diskussionen dorthin zu portieren, damit die Information dort konzentriert wird und sich jeder schnell zurecht findet.
Hier gab es mal einen provokativen Thread (ist wohl gelöscht worden?), in dem einer auf recht krasse Art genau auf diese Mißstände gewettet hat, daß hier nichts bei rum kommt. Es waren in dem Thread auch ein paar gute Antworten dabei. Das viele geschreibe ist zwar toll, aber es kommen immer nur neue Ideen und Ansätze, keiner macht aber mal einen wirklichen Start und schafft Fakten. Auch der Ansatz von Ithamar mir der neuen Seite ist nicht vernünftig, eine zusätzliche Seite verläuft günstigenfalls im Sande, schlimmstenfalls splittet sie die Kräfte von hier auf.
Schön von dir Boris, dass du die "Mißstände" so gut erkennst - dann zeig uns doch mal bitte wie es zu funktionieren hat. Reden kann ich auch... Ich finds besser, erst mal alles auszudiskutieren und dann was vernünftiges auf die Beine zustellen als halbfertige Sachen, die dann vorn und hinten Probleme bereiten weil sie nicht durchdacht sind... Der Thread den du meinst, ist glaub ich ins OT verschoben worden.
Tatsächlich im OT, dies ist der Thread: http://www.mikrocontroller.net/forum/read-7-306646.html#new > Auch der Ansatz von Ithamar mir der neuen Seite ist nicht vernünftig, > eine zusätzliche Seite verläuft günstigenfalls im Sande, > schlimmstenfalls splittet sie die Kräfte von hier auf. Mal provokativ gefragt, welche Kräfte splittet die Seite auf? Wer versucht denn hier wirklich ernsthaft gemeinschaftlich etwas auf die Beine zu stellen? Genau aus diesem Grund habe ich diesen Thread gestartet. In diesem Forum und auch im Wiki gibt es 100 verschiedene Ansätze, ohne das die meisten ein Interesse haben sich mal auf einen zu einigen und "anzufangen". Dies geht auch schlecht, da man, ohne das ein paar Leute hinter einem stehen, wohl nicht eigenmächtig die "sinnlosen" Vorschläge aus den Wikis streichen kann und mit "vernünftigen" Sachen anfangen kann. Ithamars Seite ist der Versuch, sich auf einen mehr oder weniger kleinen gemeinsamen Nenner zu einigen und auch tatsächlich brauchbare Ergebnisse zu produzieren. Diejenigen die ein Interesse daran haben, werden wohl durch die zusätzlichen 2 Mausklicks pro Tag nicht daran gehindert teilzunehmen und müssen sich nicht durch 100 Threads wühlen die nur ein privates Projekt betreffen. > ist nicht vernünftig [... und] verläuft günstigenfalls im Sande Vielen Dank für diese positiven Wünsche und den konstruktiven Beitrag. Je öfter ich das lese desto unhöflicher finde ich es, wo ist denn dein Beitrag zum ganzen?
die Texte hier sind ziemlich lang ... und viel ist dabei noch nicht rumgekommen ... deshalb halte ich mich kurz ... Ich bin dabei ... @ProkyonA Dein Ansatz gefällt mir ... und trifft dem Nagel wohl auf den Kopf Grüße trick
Einen Haken hat der CAN-Bus: Stichleitungen sind nicht möglich. Gerade im Hausbau ist so etwas aufgrund der üblichen Topologien ungemein praktisch. Deshalb lassen Busse wie EIB oder DALI so etwas auch zu. Dafür sollte auf jeden Fall eine Lösung dafür gefunden werden. Und sei es, daß irgendwelche Knoten eingeführt werden, die als Hub etagen-, gebiets- oder zimmerweise fungieren (nicht nur Etagen-Unterverteiler, das reicht oft nicht aus!).
Wo ein Problem ist, gibts (zum Glück) meist mehrere Lösungsansätze ;) Was hier schon vorgeschlagen wurde, ist die Bus-über-Stern-Verkabelung. Du legst zwei Adernpaare mehr zum Knoten, die dann als Rückleitung dienen. Die Rückleitung ist dann der Anschluss für den nächsten Knoten. So geht deine Buslinie zum Knoten hin, wieder zurück, zum nächsten Knoten, zurück, etc... Eine andere Möglichkeit ist folgende: Du baust die Knoten relativ dicht auf einen Haufen und die "Stichleitungen" sind nur die Leitungen zum Anschluss der Taster, Relais oder was auch immer. Dann musst du zwar einige Leitungen von den Knoten zu deren Peripherie legen, aber wenns nicht anders geht, ist das auch eine Lösung.
dritte Möglichkeit: Repeater einsetzen! Im Sternpunkt sitzt ein Repeater (lediglich zusammengeschaltete Bus-Treiber) und die Sache läuft auch ohne Hin- und Rückverdrahtung. Wird bei uns (Industrie) in einigen Maschinen Herstellerseitig eingesetzt. Ähnlich ist ja auch Stefan Kleinworts Idee: Er hat auf den UP-Busankopplern einen 2. Bustreiber vorgesehen um von dort (wos halt Sinn macht) einen Stich zu legen... greetz Danny
Hallo *, wirklich sehr viel Text hier - aber solch ein Grundlagen Thread war längst überfällig. Das Hauptproblem ist, dass viele Leute hier eigene Projekte verfolgen und zum Teil schon erfolgreich umgesetzt haben. Für solche Leute ist eine komplette Neuentwicklung wahrscheinlich nicht im Scope. Wenn ja - versuchen sie Ihr System durchzusetzen anstatt konstruktiv und unvoreingenommen mit zu designen... Vielleicht gehöre ich ja auch ein bisschen dazu ;-) Deshalb sollte dieses Hausbus Forum das bleiben was es ist - eine Tummelwiese für Hausbusfreaks, wo man verschiedenen Ansätze und Ideen vorstellen und diskutieren kann. Für das Design des Open-Source Busses - ist Ithamars Forum besser. Es sollte aber auch wirklich "sauber" gehalten werden ;-) Ich bin natürlich auch dabei - habe aber wenig Zeit wegen parallelem Hausbau. Weiterhin setze ich nun mehr auf energieautarke Systeme, die mit Funk kommunizieren. Das ist flexibler und minimal invasiv in meinem geplanten Holzhaus. Kilometerweise Kabel verlegen ist einfach nicht möglich und auch nicht gewünscht... Technik und damit verbundener Komfort soll schon da sein, aber man soll sie kaum bemerken ;-) Und die batterielose Funktechnik funktioniert super mit einer beachtlichen Übertragungssicherheit! Ist leider noch ganz schön teuer - aber die gewonnene Flexibilität holt das wieder raus. Meine Funkschaltzentrale fürs Licht ist nun auch schon zu 80% fertig. Hardware ist im Hutschienen Gehäuse und in der Software fehlt nur noch ne schicke Menusteuerung und EEPROM Speicherung der gelernten Schalter+Verknüpfungen. Ich würde gern auch eine CAN Anbindung für den geplanten Hausbus vorsehen, um evtl. von hier entwickelten drahtgebundenen Busknoten profitieren zu können. Dafür stelle ich dann auch mein Projekt mit in das (richtige) Forum und benutze den thread hier: http://www.mikrocontroller.net/forum/read-11-270943.html#new nur noch zum Gedankenaustausch über wireless Hausbus Technik. Also Ithamar - wenn die Funkanbindung noch oder schon ne Rolle spielt - dann sag mir, wo ich im neuen Forum meinen Platz finde! Dann stelle ich dort mein Projekt im Detail vor mit dem Ziel der CAN Anbindung. Ich denke auch, dass viele meiner schon entwickelten Schaltungen und Softwareideen auch für drahtgebundene Schaltzentralen interessant wären! Aber mir ist klar, dass ich erstmal ein Randproblem abdecke. Aber dafür hab ich schon running Code und Hardware, die innerhalb der nächsten 2 Wochen in die Systemtestphase geht ;-) Gruss Mario
@Mario: Deine Vorschläge, Ideen und Erfahrungen sind herzlich willkommen! Natürlich spielen Funktaster eine Rolle, sei es aus Bequemlichkeit, kein Kabel verlegen zu wollen, oder weil einfach keine Leitung gelegt werden kann! Schau doch einfach mal unter http://devel.antimon.de/hausbus/ vorbei - im Forum gibts einen eigenen Bereich für die Knoten, ich denke da würden die Funk-Taster ganz gut hinpassen.
@Ithamar, trick und co: Was ist aus dem interessanten Projekt geworden? Auf der Homepage ist ja leider nicht so viel passiert, ist ja mittlerweile auch schon über ein Jahr her. Wenn ihr dort nicht weitergemacht habt, wo seit ihr dann am werkeln?
Es ist gekommen, wie ich vorhergesagt habe: Es ist im Sande verlaufen... Was war denn anderes zu erwarten?
Hi, @Boris: Du solltest dich vllt auch erstmal genauer informieren bevor du solche Mutmaßungen in den Raum stellst ;) @Daniel: Das auf der Seite nichts sichtbar passiert stimmt (leider). Nur haben wir uns an einem Punkt in der Entwicklung entschieden, die Seite hintenanzustellen solang es noch nichts wirklich sinnvolles vorzuzeigen gibt. Wir sind aber dennoch seit dem Beginn immer fleißig am werkeln gewesen. Als Kommunikationsplattform dient uns halt primär IRC (#isysbus auf euirc.net), für Daten nutzen wir ein SVN (http://svn.isysbus.org) und für andere Infos auch teilweise unser Wiki (http://www.isysbus.org/wiki). Da wir halt nicht nur eine Person sind und so durchaus mehrere Sichtweisen zusammenkommen ist das halt mal nicht so "hingewurschtelt" wie an manch andrer Stelle, was aber auch bedeutet dass wir ne Menge Zeit brauchen. Im Prinzip sind wir immer noch am Protokoll ;) Allerdings gibt es einiges an Hardware, was prinzipiell fertig sein sollte. Grüße, Chris
Hallo! Was ich an einem Community-Projekt auch noch begrüßen würde, wäre die Abstrahierung der physikalischen Schicht. Warum? Als Mieter hat man eher nicht die Möglichkeit Kabel nach eigenem Ermessen zu verlegen. Daher wäre hier eine Funklösung zu bevorzugen. Konkret geht es mir um die Einbindung von 802.15.4/Zigbee Modulen. Funk: Ich habe bereits unterschiedliche Module zuhause und fände eine Hausbus System-Architektur prima, die auch Funk nicht ausschliesst. Unicasts, Broadcasts lassen sich mit den o.g. Modulen ja auch bewerkstelligen. Höhere Schichten: Wichtig wäre aus meiner Sicht zunächst erst einmal die Diskussion der höheren Schichten. Ich finde, dass zunächst leider immer irgendwie "unten" angefangen. Also Hardware definieren, ein einfaches Protokoll, etc.... Aber das ist doch gar nicht das eigentliche Problem. Interessant ist doch dann erst der Teil, wenn es darum geht, was in den Daten der einfachen Protokoll übertragen wird. Vielleicht könnte man erst einmal hier ansetzen? Architektur: Von der Idee her finde ich soetwas wie UPNP und das SLP (Service Location Protocol) nicht schlecht. Ist natürlich auf so kleinen Controllern Overkill. Aber wie schon auf den 6LoWPAN Seiten zu sehen ist, gibt es ja einen Ansatz wie das Simple-SLP. Die Idee eines solchen Ansatzes ist, dass jedes Modul selbst mitteilen kann, was es kann. Wichtig dabei: alles unabhängig vom verwendeten Übertragungsmedium! Ein Schalter besitzt ein Switch-Profile und eine Lampe ein Lighting-Profile. Beide geben ihre unterstützten Profile kund und lassen sich eine GUI verknüpfen, so dass die Lampe weiß, auf welche Nachrichten welches Schalters sie hören muss. Also nochmal: Bitte doch erst einmal mehr Gedanken über die Architektur machen, als über die eigentlich schon offensichtlichen Dinge. Mit einer vernünftigen Architektur, die nicht zwingend unglaublich komplex sein muss, kann man meiner Meinung nach, alles unter einen Hut bringen!!!
ProkyonA wrote: > Es scheint die Anzahl Leute die hier tatsächlich versuchen etwas > gemeinsam auf die Beine zu stellen ist eher gering (?). Viele > diskutieren zwar hier, was ja auch sehr schön ist, verfolgen aber wohl > nur ihr eigenes Projekt. Ich habe jetzt nicht den ganzen Thread gelesen und ich sehe auch das er schon etwas älter ist. Der Grund warum jeder sein eigenes Ding macht liegt wohl hauptsächlich daran das jeder andere Anforderungen hat. Der eine hat die Möglichkeit zusätzliche Kabel für einen CAN Bus o.ä. zu verlegen, der zweite will es unbedingt per Funk und der dritte würde es gerne über die vorhandene Hausinstallation machen. Deshalb klingt der Vorschlag von Christian auch vernünftig alles bis zum Hardwarelayer zu "standartisieren" so das die tatsächliche physikalische Schnittstelle egal ist. Aber neu ist das sicher nicht
Also, mit der Protokollschicht gebe ich dir recht, das macht absolut Sinn :) Allerdings ist das ganze Thema leider nicht so trivial, wie es aussieht. Und was leider meist der Fall ist, dass viel diskutiert wird, aber dabei bleibt es dann auch. Weil Lust, sich da reinzuhängen, haben die wenigsten. Ich beschäftige mich jetzt seit ca. zwei Jahren mit einem Hausautomatisierungs-System und was einfach gehen "sollte" ist leider meist alles andere als trivial. Deswegen passiert auch auf unserer Projekt-Webseite nicht viel, wie Christian Illy bereits gesagt hat, denn wir verwenden unsere Energie um das Projekt voranzutreiben und erst wenn das vernünftig läuft kommt die Webseite wieder dran. Übrigens - das mit der abstrahierten Protokollschicht haben wir auch in die Tat umgesetzt - um nicht nur CAN, sondern auch RS232, RS485 oder Funk etc. als Medium für den Bus verwenden zu können. Aber wie gesagt, es ist viel Arbeit, deswegen geht die Umsetzung nicht so schnell. Wer sich davor nicht scheut und z.B. Lust hat, die Funk-Geschichte umzusetzen, ist jederzeit willkommen, am besten einfach mal im IRC reinschauen (Daten stehen auf der Webseite unter http://www.isysbus.org)
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.