www.mikrocontroller.net

Forum: Haus & Smart Home Community-Projekt


Autor: ProkyonA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: dnb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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<=

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan K. (prokyona)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Boris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan K. (prokyona)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: trick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!).

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mario Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Boris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist gekommen, wie ich vorhergesagt habe:
Es ist im Sande verlaufen...

Was war denn anderes zu erwarten?

Autor: Frank B. (frankman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, vielleicht sollten wir das mit dem zusammenlegen ???
http://www.hausbus-forum.de.vu/

Autor: Boris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Forum ist doch jetzt schon tot...

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian C.-Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!!

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.