Forum: Haus & Smart Home Projekt: Open-Source Hausautomation

@Unbekannter: Teilweise stimme ich dir zu, teilweise muss ich dir aber
auch widersprechen.

Ich selbst habe schon ein paar Projekte hinter mir, ein bischen
Erfahrung ist also schon vorhanden.

Dein Tip, das Ganze allein aufzuziehen und dann für die Öffentlichkeit
freizugeben hat vielleicht bei gewissen Bereichen einen Sinn, für eine
Hausautomation aber nicht, finde ich. Wenn du eine Software für eine
präzise Problemstellung schreibst, ist das was anderes als wenn du ein
weit gefächertes Spektum abdecken möchtest, das ist ganz klar. Dass das
nicht unbedingt einfach ist, ist mir auch klar.

Nur es bringt nichts, wenn ich ein Projekt beginne, das für meine
Bedürfnisse angepasst ist und ich es dann als Open-Source
veröffentliche. Dann gibts vielleicht eine Handvoll Leute, die das
Konzept fast 1:1 übernehmen können, der Rest hat nix davon.
Und selbst wenn ich ein System für alle möglichen Szenarien entwickle,
kann es sein dass es niemanden interessiert und ich mir die Arbeit
umsonst gemacht habe...

Deswegen möchte ich von vorne herein mit mehreren Leuten
zusammenarbeiten, um verschiedene Voraussetzungen, Wünsche und Ideen
diskutieren zu können, und dann ein gemeinsames Projekt zu starten - je
mehr Leute ihre Vorschläge einbringen, desto mehr Leute wird das Ganze
später auch mal ansprechen, so meine Meinung.
Und sollte sich kein gemeinsamer Nenner finden lassen, kann man ja
immer noch zwei unabhängige Projekte starten - oder es lassen.
Aber so wie ich es sehe, gibt es hier mehr Leute, die Interesse an
einer solchen Aufgabe hätten, und jeder alleine hat wahrscheinlich
nicht die Ressourcen - zusammen könnte man was auf die Beine stellen.

Also ich finde, einen Versuch wäre es wert... was meinen die Anderen?

Also Interesse besteht schon. (Habe ja selbst schon den Vorschlag nach
nem OpenSource Projekt gemacht)

Nur leider hab ich grad extrem wenig Zeit. Ich könnte momentan
allenfalls Vorschläge für die Realisierung machen und etwas
mitdiskutieren. Naja, das meiste was ich mir so vorstelle habe ich aber
auch schon in den anderen Threads gesagt.

Wie in den anderen Threads schon angeklungen, könnte man JEDE Funktion
die ein Modul bietet standardisieren und jedes Modul meldet seine
Funktionen bei einem Busscan einmal der Steuerungssoftware.
Dann können mit definierten Nachrichten die jeweiligen Funktionen
gesteuert werden - natürlich nicht nur von der Software, sondern auch
von anderen Modulen.
Z.B. sollte die Ausgabe auf einem Ausgangsport schon eine solche
Funktion sein. (evtl. ganzer Port, oder nur ein einzelnes Portbit)
Oder eben ein PWM Port, oder ein A/D Wandler, oder oder oder...



Dann könnte man das ganze Automatisch in der Software z.B. in einer
Baumansicht aufgelistet werden.
Aus der Baumansicht kann man die Module dann einfach auf die Karte
ziehen und dort platzieren.

Grundlegender Aufbau der Steuerungssoftware:
Links: Baumansicht;
Mitte: Karte;
Rechts: Eigenschaften des gewählten Objekts.

Wenn man ein Objekt wählt, bekommt man gleich die Eigenschaften und
Funktionen in der linken Ansicht angezeigt... na dürfte wohl klar sein
was ich meine oder?



Ach und Java und Eclipse sind gut ;)


Aber wirklich mitentwickeln - da hab ich in den nächsten paar Wochen
leider erstmal absolut keine Zeit mehr zu. Leider leider leider...

@SlyD: Das ist ja kein Projekt, das nur zwei Wochen dauert, also kannst
du gern einsteigen, wenn du wieder mehr Zeit hast.
Ich werd im Dezember/Januar auch nicht so viel Zeit haben, da dann die
Uni-Prüfungen anstehen, aber danach wieder gern...
Das Projekt kann ja langsam reifen ;)

An alle anderen: Wer mitmachen möchte, gerne, ich würde mich freuen!

Nichtsdestotrotz möchte ich mal ein paar Vorschläge machen zum ersten
Busknoten, und jeder kann seine Meinung dazu abgeben:

Der Busknoten soll aus 4 Aus- und 4 Eingängen bestehen, quasi ein
univerelles Modul, das klein und kompakt für Lichtschalter, Rolladen,
etc. verwendet werden können soll.

Die Ausgänge sollen entweder schalt- oder Dimmbar sein, die
Defaultstellung (Ein oder Aus) beim Einschalten soll per
Jumper/Drahtbrücke/Software(?) einstellbar sein. Damit beispielsweise
Lüfter nach einem Stromausfall sofort laufen, bzw. falls der Sensor
seine Daten eine Zeitlang nicht sendet (weil z.B. ein Kabelbruch im Bus
ist).
Als Treiber könnte ich mir einen ULN2803 vorstellen (für einfache
Ausgänge) oder einen FET für größere Lasten.

Die Eingänge sollten entweder direkt (für Schalter) oder per
Optokoppler angeschlossen werden können und sowohl als Taster als auch
als Schalter programmierbar sein.

Da es verschiedene Konfigurationsmöglichkeiten gibt und je nach
Einsatzzweck nur manche benötigt werden, dachte ich mir, man könnte die
Platine so gestalten, dass gewisse Bereiche optional sind und alternativ
bestückt werden können (also im Layout sind beide Möglichkeiten
vorhanden). Beispielsweise löte ich die Optokoppler nur dann ein, wenn
ich diese brauche und lasse dafür die FETs weg...

Ausserdem wäre es eine Überlegung wert, die Platine "mehrstöckig" zu
gestalten, also z.B. ein Modul mit FETs und Kühlkörper einfach
draufzustecken in einer zweiten Ebene.

Zur Versorgung der Busknoten: Praktisch wäre es, neben dem Datenbus
auch noch eine Versorgungsspannung führen zu können, die einfache
Sensoren (Schalter, Temperatursensoren) speisen kann. Da der CAN-Bus
meines Wissens nicht dafür ausgelegt ist, müsste man fast immer noch
ein Versorgungskabel dazulegen oder?
Bei Aktoren (z.B. Lampen) könnte man ja einen Mini-Trafo bauen, die
Steuerung braucht ja nicht viel Strom, aber die Sensoren würde ich
gerne wegen der Sicherheit mit Niederspannung versorgen. Ausserdem
werden da auch keine so dicken Kabel benötigt.

Was meint Ihr dazu? Über Eure Meinungen, Verbesserungsvorschläge und
Kritik freue ich mich!

Also prinzipiell hatte ich das auch so gedacht, allerdings nicht so
extrem auf verschiedene Platinen verstreut wie du ;)

Der µC mit dem CAN-Controller sowie der Spannungsversorgung soll auf
jede Platine mit drauf - auf "größere" Nodes kommt halt auch ein
"größerer" µC mit drauf.

Das von mir vorgestellte Basismodul ist nur eines der Module (wie eins
für Temperatur, eines mit Display und Eingabemöglichkeit, ...) und soll
deswegen für simple Eingaben/Schaltaufgaben verwendet werden.
Prinzipiell wäre es toll, alle Ports als Ein- oder Ausgabeport zu
verwenden, aber letztendlich dürfte das eine Platzfrage sein, Ziel ist
es, das Teil in eine Unterputzdose einzubauen, da ist der Platz sehr
begrenzt.
Deswegen waren auch nur 4 Ein-/Ausgänge vorgesehen, da das für die
meisten Schaltaufgaben langen sollte, oft werden wohl eh nicht alle
verwendet.
Beispiel: Lichtschalter, hier wird meist nur ein bzw. zwei Eingänge
verwendet
Beispiel 2: Hier braucht man wohl zwei Eingänge (Auf/Ab) und zwei für
die Endschalter, sowie zwei Ausgänge für ne Motor-H-Brücke.

Aber ne Idee wäre, ein Schieberegister über ne weitere Platine
anzusteuern, statt den Ausgabeports gibt es dann halt 8 vom
Schieberegister, die ursprünglichen werden für Takt etc. verwendet...

Vorteil der festen 4 Ein- und Ausgabeports wäre, dass auch nicht so
bewanderte Leute das System anschliessen können, die dann einfach ne
Standard-Software verwenden, in der die Ports fest beschalten sind.
Selbst wenn die dann was falsch beschalten, dürfte es weniger Probleme
geben...

Also das schaut zwar gut aus, aber ich denke wir reden da grad ein wenig
aneinander vorbei...

Was ich mit dem Knoten meinte ist eine kleine Platine, die in eine
Unterputzdose eingebaut werden kann, um z.B. an einen Lichtschalter
angeschlossen werden kann - was du meinst ist ein zentraler Verteiler.

So weit bin ich noch gar nicht, aber der Ansatz ist schon nicht
schlecht, ich denke eine Kombination aus beidem wäre praktisch. Zum
einen einen Zentralverteiler im Hutschienengehäuse, von dem aus die
Sensoren/Aktoren angeschlossen werden, zum Anderen einen wirklichen
Bus, der durch das Haus geht und an den die Nodes angeschlossen werden.


Damit schlägt man zwei Fliegen mit einer Klappe und man kann sich das
für sein Haus sinnvollste System raussuchen - oder ne Kombination aus
beidem.

Bei mir läufts momentan so, dass ich meinen zentralen Verteiler in ein
19" Gehäuse mit Europlatinen einbaue, auch leicht erweiterbar, aber
eher für industrielle Steuerungen gedacht - bei mir steuerts einen 19"
Schrank, wird aber genauso an den Hausbus angeschlossen. Aber dann halt
über ne extra Software bedient, bzw. solls mal werden ;)

@Ithamar:
Ja ich hab dann auch Uni-Prüfungen ;)
Und aktuell noch ein paar andere Dinge die fertig werden wollen...


@Matthias:
Na aber die Leiterbahnen von Deinem Spannungsregler machste dann aber
doch besser noch ein bisschen breiter wo schon soviel Platz auf dem
Board ist ;)
So 0.8mm oder mehr... (für die LEDs kanns natürlich so bleiben ;) )



Das mit dem stapelbar machen ist schon gut so - allerdings sollte die
5V / 3.3V Regelung schon auf dem jeweiligen Busknoten sitzten.
In SMD selbstverständlich, da sonst viel zu viel Platz verschwendet
wird.

Und die Aufteilung passt so auch schon - ein Zentralverteiler und viele
viele kleine Busknoten. Im Zentralverteiler kann man dann ja eben auch
den Bus Sternförmig legen, so wie es in den anderen Threads schon
angeklungen ist, und dort auch alle größeren Aktoren platzieren. (so
ein großes Dimmermodul oder nen größeres Relais bzw. SSR passen eben
nicht so gut inne Unterputzdose ;) )

Also Ideen sind ja schon reichlich vorhanden - was haltet Ihr davon,
wenn ich wie oben schon angedeutet, eine Mailingliste, ein
Versionskontrollsystem etc. vorbereite? Ich denke irgendwann werden wir
an die Grenzen der Möglichkeiten des Forums stoßen...

Praktisch wäre es auch mal, alle Vorschläge  Wünsche  Ideen
zusammenzuschreiben, vielleicht im Wiki? Dann können wir erst mal
sammeln, bevor wir konkrete Pläne schmieden...

Wiki:
http://www.mikrocontroller.net/articles/Hausbus

Da hatte schonmal jemand angefangen was zu schreiben...

Ja ein Versionskontrollsystem wäre auch gut. Momentan ist hier im
Hausbusforum allerdings noch nicht allzuviel los - also bleibt es
momentan noch relativ übersichtlich.

Joa, die Seite im Wiki kenn ich - allerdings meinte ich eher eine Seite,
auf der Wünsche, Vorschläge, etc. zu genau diesem Projekt gesammelt
werden können - oder einfach Notizen etc.
Ich werd mal ein Wiki auf meinem Server bereitstellen und SVN, etc.

Dann sind zumindest die Grundvoraussetzungen gegeben, falls es genutzt
wird, ists okay, wenn nicht, ist es auch nicht weiter schlimm...

Naja wie gesagt, anbieten will ichs, obs genutzt wird, hängt von den
Entwicklern ab...

Nur denke ich, dass beispielsweise eine Mindstorming-Seite oder
Versionsänderungen nicht unbedingt hier ins Wiki gehören, weil die zu
sehr projektspezifisch sind. Aber ne Seite hier für Vorschläge und
Anregungen oder eher allgemeinere Doku find ich auch okay...

Dein Wunsch ist mir ein Befehl :)

Hier ist der Artikel:
http://www.mikrocontroller.net/articles/Hausbus_Diskussion

Ich bitte um rege Beteiligung!

Klar mach ich gern - in welcher Form hattest du es dir vorgestellt? Als
Unterpunkt im Wiki oder auf ner extra Seite, ...?

Was meinst du genau mit der Software? Sowas quasi für den
Kühlschrank-PC, der die Lebensmittel verwaltet und dir Kochrezepte
vorschlägt, nebenbei die Beleuchtung steuert oder wie?
Wenn du das Ganze in Delphi machen möchtest, gerne. Ich denke wenn wir
ein Protokoll entwickelt haben, bzw. den Rahmen festgelegt haben wie
die Kommunikation aussehen soll ist es egal, in welcher
Programmiersprache das Programm geschrieben ist.

Deswegen nochmal die Aufforderung: Wer Ideen hat, die Seite im Wiki ist
zum Bearbeiten da, nur keine Hemmungen ;) Wenn zu viel Leute dran
rumwerkeln können wir immer noch die Bremse ziehen, aber momentan
schauts nicht danach aus ;)

Falls du mich damit meinst, dann hast du die Funktion eines Wikis nicht
verstanden... nur weil ich den Artikel angelegt habe, heisst das nicht
automatisch, dass auch alle Änderungen von mir stammen.

Im Übrigen denke ich, dass meine Rechtschreibung ganz gut ist und
Fehler macht jeder mal, auch Du!

BTW, dein Beitrag war alles andere als konstruktiv - du solltest mal
einen Kurs über das Verhalten in Foren machen :P

Ein paar generelle Bitten zum Projekt hätte ich noch:

- Bitte im Wiki registrieren, damit man sofort sieht, wer welche
Änderungen gemacht hat
- Bitte die Vorschau-Funktion benutzen, damit nicht so oft editiert
werden muss und die Übersichtlichkeit drunter leidet
- Wichtige Änderungen hier im Forum zuerst diskutieren und das Ergebnis
ins Wiki eintragen, sonst kommen wir nicht auf einen gemeinsamen Nenner

Zum Universalknoten möchte ich noch was sagen: Mein einfacher
I/O-Knoten war genau für diese Aufgabe gedacht: Als günstiges
Universalmodul mit 4 Ein- und 4 Ausgängen, die z.B. für Lichtschalter
verwendet werden können und in eine Unterputzdose passen. Den Attiny
habe ich gewählt, weil dieser günstig hergeht und für solche einfachen
Anwendungen locker langen sollte. Durch optionale Optokoppler / Relais
/ ... auch zum Schalten von 230V geeignet.
Vielleicht können wir da einen gemeinsamen Nenner finden und beide
Vorschläge zusammenfassen. Den AT90CAN128 halte ich mit 16 EUR für zu
teuer und der AtMega32 ist denke ich auch überdimensioniert für
einfache Schalter, denn in einem Haus braucht man mehrere Knoten, da
summiert sich das Ganze schnell...

Ich würde vorschlagen, dass wir uns auf ein paar Mikrocontroller
einigen, damit wir nicht zu viele mischen, sonst wirds zu kompliziert.
Mein Vorschlag wäre der Attiny2313 für ganz kleine Knoten (eben z.B.
Schalter) und dann den Mega32/64 für größere Aufgaben. Möglichst
pinkompatible ICs, die sich nur durch Speichergröße unterscheiden,
damit die einfach austauschbar sind.

Cat-Kabel halte ich für sehr gut, die sind oft schon vorhanden oder
günstig zu beschaffen. Da wäre es praktisch, nicht benutzte Pins zu
verwenden (z.B. 1/2 für CAN_H und CAN_L, sowie 7/8 für die
Spannungsversorgung), damit man beim falsch Einstecken weniger Probleme
bekommt ;)
Da wäre eine Idee, das Ganze PoE-konform zu machen (mit +48V laufen zu
lassen), dann kann das gleich auch von einem PoE Equipment gespeist
werden. Wäre eine Idee, fraglich ist ob die Bauteile zum
Heruntertransformieren gut verfügbar sind und auch platzmäßig auf die
Platine passen.

Bei der CAN-Übertragungsrate würde ich irgendwas um die 250KBaud
vorschlagen - damit kann man längere Kabel verwenden und die
Geschwindigkeit sollte auch ausreichen - was meint Ihr dazu?

Bei CAN ist die Frage ob wir 2.0B verwenden, was ich gutheißen würde.
Da können wir die IDs größzügig vergeben und z.B. in bestimmte Bereiche
einteilen.
Zwar ist CAN ja nicht Adressen- sondern Nachrichtenorientiert, aber ich
denke für eine Hausautomation wären Adressen sinnvoll zu vergeben, mein
Vorschlag wäre, dies per DIP-Schalter oder Jumper zu tun. Damit dieser
nicht zu viel Platz auf der Platine wegnimmt, könnte man Adressbereiche
für den Typ des Knotens festlegen (ob I/O Knoten, Sensor, Bedienpanel,
usw.), die fest in der Software einprogrammiert sind - sollten die
Adressen doch ausgehen, kann man das dann ja von Hand ändern.

Beim Protokoll stellt sich die Frage ob ein eigenes implementiert
werden soll oder ob beispielsweise auf CanOpen aufgebaut wird. Ich
kenne mich mit CanOpen noch zu wenig aus, aber möchte mich mal
einlesen. Vielleicht hat jemand von Euch schon Erfahrungen damit
gemacht?

Schön wäre ein einfach zu debuggendes Protokoll, das auch vielleicht
"von Hand" bedient werden kann.
z.B. könnte ich von Hand auf einen Seriell->CAN-Konverter schreiben:
"set pin1=on" und schicke es an einen Knoten für eine Lampe, die sich
dann anschaltet. Oder ich frage deren Status mit "get pin1" ab.

Eine Netzstruktur könnte man in der Form aufbauen:
"busname.segment.knoten.pin" - wobei jedes Element in der
hierarchischen Ebene gewisse Eigenschaften haben, die entweder nur
gelesen oder gelesen und geschrieben werden können.
Z.B. könnte ich mit "busname.segment.knoten=beschreibung" einem
Knoten einen Kommentar verpassen, der in diesem Fall vielleicht nur für
die Beschreibung des Knotens in der Software dient, ein
"busname.segment.knoten.pin2.mode=input" schreibt dagegen in den
Flash des Busknotens, dass Pin2 ein Eingang sein soll, etc.

Das Ganze soll jetzt mal eine Art "Mindstorming" sein, was man machen
könnte, sagt mir doch bitte Eure Meinung dazu. Die Feinheiten müssen
natürlich noch detaillierter betrachtet werden, aber das ist die Idee
wie ich mir das ungefähr vorstelle. Und jetzt würde mich Eure Ansicht
dazu interessieren :)

Also bezüglich PoE: Schwer ist das nicht, wenn man die passenden Chips
dazu hat - dann braucht man nur einen Widerstand, durch den das Gerät
klassifiziert wird, den Rest macht der IC. Ist wie bei CAN - ich könnte
auch direkt per µC an den Bustreiber gehen und alle Bits "manuell" auf
den Bus schicken - aber das kann mir auch mein CAN-Controller abnehmen.

Die Steckerbelegung für CAN sind meines Wissens nach nicht genormt - es
werden auch nur bestimmte Steckertypen (z.B. 9-pol D-SUB, Mini-DIN)
empfohlen, nicht vorgeschrieben. Aber ich würd auf jeden Fall schauen,
falls es wirklich keinen Standard gibt, dass die Ethernet-Pins
freibleiben, denn das könnte sonst echt zu einem Problem werden.

Genauso würde ich es vorschlagen bezüglich Verkabelung. Nix festlegen,
nur vorschlagen. Warum nicht Stern und Bus kombinieren?
Beispielsweise bei mir wäre es so: Die Logik sitzt in einem
19"-Gehäuse mit Europlatinen-Einschüben im Keller und steuert dort
sternförmig meine Geräte. Ein Leitungspaar geht dann in den 1. Stock
und läuft als Linie weiter, um Lampen, Taster, etc. zu versorgen.

Jeder kann den Bus nach seinem Gutdünken und seinen Gelegenheiten
verlegen - jemand der schon Ethernetkabel verlegt hat, wird vielleicht
physikalisch Stern, logisch Bus bevorzugen, jemand der ein bestehendes
Gebäude verkabeln möchte, in den Rohren aber vielleicht nur ganz wenig
Platz hat, zieht vielleicht lieber nur zwei Busleitungen durchs ganze
Haus...

Zu den Topics - noch ist nicht viel im Forum los, weils kaum jemand
kennt (mangels Verlinkung), deswegen könnte man in mehreren Beiträgen
diskutieren, die sollten aber möglichst unabhängig voneinander sein.
Ich werde mal einen aufmachen für das Busprotokoll, das ist wie du
schon sagtest, sehr wichtig und wird einiges an Diskussionsbedarf
haben...

Also ich habe mir mal erlaubt, den Artikel im Wiki im Layout anzupassen,
damit er übersichtlicher wird.

Ich hoffe, dass ich nicht die Arbeit von jemand anderem zunichte
gemacht hat, falls doch, tut es mir leid. In diesem Fall bitte melden,
dann machen wir es rückgängig.

Ausserdem habe ich noch Vorschläge für Ein-/Ausgabeknoten hinzugefügt,
bitte postet mal Eure Meinung dazu.

Schade - dann war die Mühe umsonst :(

Was gefällt dir denn im Vergleich zu vorher nicht mehr? Dass vielleicht
nicht alles rückgängig gemacht werden muss, bin heute mindestens ne
halbe Stunde dran gesessen um die Code-Blöcke und die Links
einzufügen.

Was mir vorher überhaupt nicht gefallen hat, waren die gemischten
Überschriften, teilweise waren bei den Unterpunkten Hauptüberschriften
drin, etc.

Du kannst dich gern mal dran versuchen, vielleicht bekommst du es ja
noch besser hin, bin offen für alles :)

Also alle Funktionen wollte ich eh nicht auf eine Platine packen - auf
eine Platine soll der µC, vielleicht die Stromversorgung und dann die
wichtigsten Bauteile - der Rest wird je nach Konfigurationswunsch per
Huckepack draufgesteckt (wobei man vielleicht, falls der Platz langt,
zwei Platinen draufstecken können soll - um die Ausgänge und Eingänge
gleichzeitig erweitern zu können).
Eine Huckepackplatine enthält beispielsweise zusätzliche Optokoppler
für die Eingänge. Eine andere entweder MosFETs oder einen ULN2803 für
die Ausgänge, je nachdem was man braucht...
So hatte ich mir das gedacht, aber wahrscheinlich nicht klar genug
ausgedrückt, ich denke im Prinzip meinen wir das Gleiche...

Die anderen Module (Anzeige, etc.) müssen ja vermutlich nicht immer in
einer UP-Dose Platz finden, deswegen kann man die anders
dimensionieren, aber durchaus mit Huckepackplatinen.

Du kannst gern die Änderungen ins Wiki einpflegen. Das "<pre
class="code">" nutze ich eigentlich hauptsächlich, um bestimmte
Passagen die inhaltlich zusammengehören, einzurahmen. Damit man wie bei
den anderen Artikeln im Wiki durch die Zusammenfassung mehr Überblick
bekommt. Sonst hebt sich das vom Rest des Textes nicht mehr stark ab...

@Koopi:

Erst mal Danke für deine Erfahrungen, sowas ist immer gut zu hören!

Also zum Knoten: Der Knoten wurde mit 4 Ein-/Ausgängen knapp bemessen,
weil die Geldfrage hier mit reinspielt, und die ist in diesem Fall die
wichtigste denke ich. Denn ansonsten würde ich nen AT90CAN128 nehmen,
der hat den CAN-Controller gleich integriert und zig I/O Pins, die man
verwenden könnte. Kostet halt nur 16 EUR das gute Stück.
So und jetzt nehmen wir an, du baust in jeden Lichtschalter so ein
Modul, der nix weiter macht, als den einen oder wenns hoch kommt den
Doppeltaster zu überwachen - das sind grad mal zwei Pins... und das
vielleicht 20x im Haus - da wirst du arm.
Der Attiny ist da genau das richtige, denn der ist schön billig und
insgesamt kosten die Bauteile für so nen Knoten vielleicht 6-8 EUR...

Dass man damit aber nicht viel mehr machen kann, da hast du Recht, aber
dafür gibts ja die anderen Knoten, z.B. mit dem AtMega32, der für
"größere" Anwendungen geeignet ist.

Die +48V sind mir deshalb eingefallen, da sie dem PoE-Standard
entsprechen und man das eventuell gleich miteinander verbinden
könnte... war aber nur so ne Idee, kann man gleich verwerfen wenn zu
viele Argumente dagegen sprechen.

Bei der Geschwindigkeit bin ich auch am Überlegen, da fehlen mir
einfach die Erfahrungswerte... zu niedrig soll die Geschwindigkeit
natürlich nicht sein, nicht dass es Engpässe gibt.
Eine Idee ist mir nämlich mal gekommen - wenn man schon einen Bus hat
der quasi im ganzen Haus liegt, warum da nicht gleich ne Webcam
anschliessen zur Überwachung? Im Forum wurde viel über so billige
Handy-Cams diskutiert, die auch sehr einfach anzusprechen sind. Dafür
bräuchte man nämlich schon einiges an Bandbreite, ist halt die Frage,
ob das dann nicht zu viel ist...
Aber ab und zu mal ein Bild (muss ja ned 25 fps haben) abrufen zu
können, fände ich schon praktisch...

Ich würde auch für eher niedrige Geschwindigkeit plädieren - so zwischen
10-50Kbit/s maximal - das mit der Webcam mach mal lieber übers LAN ;)

> und das vielleicht 20x im Haus - da wirst du arm

Da haste allerdings Recht.

Ich hatte ja dran gedacht evtl. die neuen Philips LPC ARM dafür zu
verwenden wenn ich denn mal endlich damit anfange...
Der LPC2102 (16K Flash, 4K SRAM) kostet etwa 2.70 Euro pro Stück wenn
Du 25 Stück nimmst (LPC2101 mit 8K/2K etwa 2.15 Euro...) - also
verdammt billig für nen 32bitter (mit zig I/Os)
Den muss man für die Hausautomatisierung aber natürlich nicht mit 70MHz
laufen lassen und dann zieht der soweit ich dass bisher gehört habe auch
nicht sonderlich viel...

Spannungsregler (LPC210x braucht 3.3V und 1.8V - ist aber 5V I/O
tolerant.) sind kein großes Problem, da gibt es z.B. von TI kleine im
SOT-23 Gehäuse (dieses kleine 3 Pin SMD Transistor Gehäuse)
und die kosten vielleicht zusammengerechnet 80 cent oder so um den
Dreh...

Überdimensioniert sind die LPC natürlich - klar. Aber wenn die ohnehin
so billig sind seh ich keinen Grund der groß dagegen sprechen würde. Na
gut das LQFP-48 Gehäuse is'n büschn friemelig zu löten, aber wozu hat
man nen Toaster Ofen ;)

Falls man mehr Speicher und Integriertes CAN braucht:
Nen LPC2119 mit zwei CANs (und 128K Flash, 16K RAM) gibts auch schon ab
etwa 7.xx Euro ...

Also der Philips hört sich sehr interessant an, aber ich halte ihn für
zu überdimensioniert.

Ich hoffe wir reden nicht aneinander vorbei, was ich mit dem Attiny
erreichen möchte ist lediglich eine Steuerung von 4 Ein-/Ausgängen, für
die simpelsten Anwendungen.
Beim EIB gibts das beispielsweise - es ist lediglich ein Modul, das 4
Taster abfragt und deren Status auf den Bus sendet - mehr will ich gar
nicht. Für einen Lichtschalter am Wohnzimmereingang sollte das völlig
ausreichen.

Für die aufwändigeren Steuerungen sieht das anders aus, beispielsweise
Temperatur/Luftfeuchte/wasweissich. Das ist vermutlich ein Kasten, in
dem mehrere Sensoren etc. drinstecken, der braucht mehr Rechenpower und
Speicher - aber nicht mein Taster, der jede Stunde vielleicht einen
Befehl auf den Bus raushaut: Schalte Lampe A ein
Auch wenns vielleicht nur 20 Cent mehr sind - aber bei zig Modulen
macht sich das bemerkbar.

Was mir an einem einfachen Mikrocontroller wichtig wäre (bitte ergänzt
ruhig Eure Meinung):
- kostengünstig (!!)
- leicht zu beschaffen (Reichelt & co.)
- leicht zu programmieren (ISP, dieser sollte leicht zu
beschaffen/bauen sein)
- weit verbreitet
- evtl. DIL und kleinere Packages - zum testen und dann
miniaturisieren

Und nicht zu viele verschiedene uCs im Projekt - sonst gibts ein
Chaos... vielleicht 2 oder 3 verschiedene - möglichst vom gleichen
Hersteller oder so. Denn sonst wird das Projekt keinen Anklang finden,
vermute ich. Klar, der MSP430 wäre sicher auch nicht schlecht, hat ne
Menge Speicher, etc. Aber ist halt wieder nicht so günstig, leicht zu
beschaffen etc. Die AVRs dagegen bekommt man in allen möglichen
Variationen und günstigen Preisen - die Entwicklungsumgebung gibts
gratis dazu. Wie ist das z.B. bei Philips?

Also klar sind die für nen Schalter überdimensioniert - aber da kann man
es einfach so machen, das man pro Raum ein kleines Sub-Netz mit einem
einfacheren Bussystem erstellt - z.B. RS485 (oder I2C, oneWire,
weissDerGeier) - nen UART haben ja die meisten Mikrocontroller schon
drin. Das Board mit dem LPC gibts dann nur einmal pro Raum z.B. neben
der Tür in einer Bedieneinheit, die auch gleich noch nen paar Anzeigen
drin hat(Raumtemperatur usw.) und Sensoren und Aktoren die sich in der
Nähe befinden direkt ansteuern kann. Die kleineren Controller dienen
aber eigentlich dabei nur als I/O Erweiterung! Die Kommunikation mit
den anderen Busknoten regelt dann der Haupt µC in jedem Raum.
Das wäre so die Lösung die ich mir vorstelle.

Kurz Zusammengefasst:
Ein großer µC pro Raum, und (je nach Größe des Raums) ein paar kleinere
I/O Erweiterungen - aber die auch nur damit man nicht soviel Kabel legen
muss...

Das ich nicht in jeden Schalter nen 32bitter reinsetzten will, dürfte
wohl hoffentlich klar sein ;)

Wenn ich mal ein wenig drüber nachdenke:
Das hat einen weiteren Vorteil - jeder hier hat so seinen Lieblings
8-bitter würde ich mal sagen - viele AVR, weniger PIC usw.
Einigen wir uns doch nur auf den großen Controller pro Raum - der Rest
kann dann je nach belieben in Sub-Netzen mit der eigenen lieblings
Controller Familie erledigt werden... Wenns dann zufällig die gleiche
ist - kann man ja auch Code austauschen.

...
...
...

Zur Entwicklung mit den LPCs:

Bei den LPC gibt nen port vom GCC wie für AVR - gibt sogar nen WinARM
Projekt analog zum WinAVR... Also alles für lau. Als C Editor kann
eigentlich alles herhalten was man mag - DevC++ oder Eclipse mit CDT
Beispielsweise.

ISP ist kein Problem - die Philips haben nen guten seriellen Bootloader
gleich drin. Einfach an die serielle hängen (oder USB Adapter) und über
ein Tool von Philips programmieren. Also ebenfalls einfach und für
lau.
Wenn man nen bisschen Geld investiert kann man sich noch nen JTAG
Debugger besorgen wenn man mag... braucht man aber nicht unbedingt.


Kosten pro Stück - tja also habe ich ja oben schon gesagt - sehr billig
für die gebotene Leistung.

Gehäuse: Zum Basteln gibts den LPC2103 (32K Flash, 8K RAM) sogar im
44-PLCC Gehäuse! Da fehlen nur 4 weniger wichtige Pins.

Bei der Beschaffbarkeit sieht es bei den LPC210x natürlich NOCH
schlecht aus, da die gerade erst diesen Monat neu rauskommen!
Das wird sich aber noch ändern.

Die anderen gängigeren LPCs (die aber viel teurer sind) die schon
länger auf dem Markt gibt, gibts vielleicht nicht bei Reichelt, aber
andere Shops haben die wohl. (Muss ich nochmal genauer schauen wo es
die gibt - embedit.de hat nen paar die schon länger auf dem Markt sind.
Farnell und Segor haben auch welche ...

Digikey hat so wie ich das bisher gesehen habe alle anderen, die neuen
stehen auch schon im Programm, aber die sind noch nicht auf Lager. Ja
Digikey liefert auch nach DE, allerdings nur Kreditkarte und eben etwas
höhere Versandkosten...)

Zum Basteln gibts hier nette Headerboards für die SMD Varianten:
http://elmicro.com/de/lpchb.html
Die Boards von embeddedartists sehen auch ganz nett aus:
http://www.embeddedartists.com/




KLEINE NEBENBEMERKUNG:
Ich habe noch nichts mit den LPCs gemacht (bin noch bei 8bittern ;) ) -
aber ich finde das die verdammt gut ausschauen und ich wollte sowieso
mal was mit 32bittern machen - da wäre doch die HA
(=Hausautomatisierung - das Wort ist mir einfach zu sperrig - heisst ab
jetzt HA ;)) ein gutes Projekt...
Hier auf µC.net gibts ja auch schon einige Threads zum Thema. (Filter:
"ARM" im Mikrocontroller Forum...)

axo: Warum ich noch nicht mit den LPCs angefangen habe?
--> Keine Zeit.
Hätte ich Zeit, wäre ich schon längt dabei.

Nochwas damit der Admin hier nicht verärgert ist:
http://shop.mikrocontroller.net/csc_articles.php?VID=OkTC5AJlj3qYNlNV&saSearch[category]=ARM

Hier gibts die natürlich auch... nur scheinbar hat Andreas öfters
Lieferprobleme wie ich es aus einigen Posts hier herauslesen kann.
Deswegen hatte ich das hier nicht sofort dabeigeschrieben.

Okay, ist ne interessante Idee, einen "Master" pro Raum und dann
"Unter-Controller" - aber sei mir nicht böse, das halte ich für keine
gute Idee...
Ist unnötig kompliziert, wenn ich erst über CAN Nachrichten verschicke
und dann vom Controller weiterleite an andere Controller - wenn der
erstere mal ausfällt, geht der ganze Raum nicht mehr...
Da könnte ich gleich einen Controller in den Verteilerkasten legen und
dann die ganzen Strippen dahin ziehen, wozu dann Bus nehmen?

Also nichts gegen deine Idee und so, ich finds gut wenn es viele Ideen
gibt, aber es sollte nicht zu komplex werden. Und vor allem
störunanfällig. Wenn jemand z.B. nen Temperatursensor als einziges
Gerät pro Raum haben will - wozu braucht er dann noch nen
Master-Controller der den Sensor-Controller überwacht? Okay, so hast du
dir das wahrscheinlich auch nicht vorgestellt, aber auch bei einigen
Geräten pro Raum find ich dass es das nicht braucht.

Der große Vorteil eines Busses ist ja der, dass ich Knoten beliebig
positionieren kann, wie z.B. bei uns in der FH: Der Installateur des
EIB hat schlauerweise den Schalter für die Jalousie an die Tür gebaut
und den für die Lichtbänder ans Fenster (genau gegenüber von der Tür).
Also einfach beide Schalter vertauschen und trotzdem werden die
gleichen Geräte geschalten. Bei deiner Lösung müsste ich jetzt
beispielsweise wieder Kabel ziehen...

Gut, jeder hat andere Vorstellungen vom Bus, das ist mir klar, meine
ist beispielsweise die: Ich habe viele Sensoren und Aktoren die im Bus
verstreut sind und jeweils eine Aufgabe zugewiesen bekommen - und
positionieren kann ich die wie ich will und unabhängig voneinander,
hauptsache sie hängen am gleichen Bus.

Es spricht ja nichts dagegen, dass sich jeder "seinen" Bus
individualisiert, ich möchte beispielsweise auch eine Lüftersteuerung
eines Serverschrankes über den Bus laufen lassen, die ausser mir
vermutlich keinen interessiert - aber das kann ich ja für mich selbst
entwickeln. Aber das Grundkonzept des Projektes sollte meiner Meinung
nach einfach zu verstehen, nachzubauen und anzuwenden sein. Und
Erweiterungen kann ja jeder bauen wie er will und mit welchem µC er
will. Aber der Einstieg fällt auf jeden Fall leichter wenn es die
Sachen einfach zu ordern gibt. Wenn ich z.B. sehe dass man für etwas
Bauteile braucht, die es nur bei einem Händler gibt, bin ich schon mal
abgeschreckt. Weil ich will nicht gleich zig der Bausteine bestellen,
sondern erst mal probieren... Und ich behaupte das geht auch anderen
Leuten so...

Vielleicht ist in dem letzten Posting nicht ganz rübergekommen was ich
eigentlich mit dem "Subnetz" bezwecke:
Das mit dem Subnetz macht das ganze IMHO einfacher und viel billiger.
In den Bedienelementen und Sensoren selbst braucht man nämlich nur noch
ganz ganz einfache und billige Knoten z.B. in den einzelnen Tastern -
nen ATTiny oder PIC12 oder gar PIC10F (die sind wirklich winzig und
kosten nur nen paar Cent) oder so da rein. Der CAN Controller +
Transceiver + (wahrscheinlich) Stromversorgung für die kleinen Knoten
fallen so komplett weg und diese Platinen können auch viel kleiner
werden.
Das einzige teure ist dann der große Controller im Raum. Ich will
wirklich kein großes Controllermodul für zwei kleine popelige Schalter
verschwenden. Wer will, kann das natürlich trotzdem tun.

UND DIE KABEL DIE VERLEGT WERDEN:
Können entweder genau die gleichen Kabel wie fürn CAN sein, oder viel
billiger, denn die Geschwindigkeit auf diesem SubNetz kann seeeehr viel
langsamer sein. (zwischen 1 - 5KBit/s oder weniger - mehr brauchts da
wirklich nicht...)
Und noch ein Vorteil: Die Länge des CAN Busses wird stark reduziert -
weniger Reflexionen und somit ist eine höhere Geschwindigkeit auf dem
Hauptbus denkbar.


AUS SICHT DER SOFTWARE, sind das immer noch alles einzelne Module mit
eigener Adresse - nur eben von einem großen Controller
"repräsentiert". Das sollte ja ohnehin so sein - auch ohne Subnetz
sollte ein Controller (virtuell) mehrere Aktoren und Sensoren
"repräsentiern" können!
 Das macht dem großen Controller ja nix, ob der nun 2 Sensoren, oder 10
darstellen soll. Der kann rein Performance Mäßig auch das ganze Haus
alleine Steuern. Das gilt ja sogar schon für größere ATMEGAs bzw. PICs,
und erst recht für nen ARM7.

OK - die Redundanz in einem Raum fällt weg. Das stimmt. Aber ob das nun
so wichtig ist? Wenn man das Hauptmodul robust baut (man hat ja nun jede
Menge Geld gespart, durch so ein Subnetz ;) ), sollte das schon nen
bisschen was aushalten können und wenns doch mal nicht mehr geht, hat
man ja noch nen paar auf Reserve lagern.


Man muss das natürlich nicht so machen - man kann ja trotzdem so ein
größeres Modul pro drei Taster ver(sch)wenden wenn man das möchte...


> z.B. sehe dass man für etwas Bauteile braucht,
> die es nur bei einem Händler gibt, bin ich schon mal
> abgeschreckt

Das ist nun aber nicht auf die LPCs bezogen?
Denn die gibts ja bei vielen Händlern (die LPC2101-2-3 neuen kommen
(sind noch nicht) ja erst diesen Monat auf den Markt! Trotzdem hat sie
Digikey jetzt schon im Programm und die anderen üblichen Verdächtigen
werden nachziehen) - vielleicht ist das in meinem obigen Post aber auch
falsch rübergekommen.

> Bei deiner Lösung müsste ich jetzt
> beispielsweise wieder Kabel ziehen...

?
Nein auch nicht wirklich - ist doch rein Softwaremäßig was welcher
Sensor macht. Man soll ja einfach mit der Steuerungssoftware festlegen
können welcher Aktor auf welchen Sensor reagieren soll und wie... Das
Thema hatten wir aber nun schon mehrmals durch.
Das ist ja eigentlich Sinn des Ganzen.

Nix mit Strippenziehen - ein Häckchen in der Konfigurations Software
setzen vielleicht ;)

Ach noch zur Ergänzung: Der Bus ist immer noch sinnvoll, denn man hat in
einem Haus ja - sagen wir mal drei Etagen (Keller, Erdgeschoss, 1.
Etage...) mit durchschnittlich 6 Räumen - macht schon 18 Module wenn
man in jeden Raum eins reinmachen möchte.
So, nun überleg mal wenn Du pro Raum durchschnittlich drei Module hast
(wenn in jeden dritten Schalter eins reinkommt) - macht schon über 50
Stück... und die wollen erstmal gelötet werden.
Ist vielleicht etwas übertrieben, aber mit 40 Modulen muss man rechnen.
Dann noch welche auf Reserve bauen...
Neee neee. Da lieber Pro Raum einen Master reinsetzten. Ist schneller
zusammengebaut.


Denn mit einem kleinen Subnetz werden die Platinen für die Sensoren und
Aktoren viel einfacher. Erstmal kleiner, und dann haben die ja auch nur
weniger als ca. 10 kleine einfache Bauteile, während auf einem größeren
Modul durchaus mal 30 Bauteile, z.T. mit vielen Pins sitzten könnten...


Aber es zwingt einen keiner dazu das so zu machen. Man kann auch die
großen Module für alles verwenden und auf kleinere Unternetze
verzichten. Das wird ja alles per Software geregelt.

> man in jeden Raum eins reinmachen möchte.

Da hinter gehört ein Absatz. Das war schon der nächste Gedanke und
bezog sich auf die Idee viele große Module für alles zu verwenden.

Mit dem obigen Absatz wollte ich sagen, das sich ein Bus für 18 Module
ja immer noch gut lohnt.


Sorry für die vielen Posts. Ich will ne Edit funktion! ;)

löl jo Edit wär ab und zu ganz praktisch...

Okay, also das leuchtet mir schon eher ein - aber machen wirs doch
einfach so - wir bieten beides an und jeder kann sich das raussuchen,
was ihm das liebste ist...

Was ich meinte mit der Bestellung: Ich bin von Natur aus faul. Und
stolz drauf ;)
Und wenn ich nicht alles bei nem Händler bekomm, schreckt mich das
schon mal ab - also am liebsten hätt ich gern alle Komponenten vom
Reichelt - da bestell ich öfters, die Versandkosten sind auch okay, da
bin ich zufrieden... aber andere mögen da anders denken ;)

Bau doch deinen Vorschlag der Knoten einfach mal ins Wiki mit ein...

"Subnetz" war vielleicht auch der falsche Ausdruck - das hört sich ja
viel komplizierter an als es ist.

Ist eigentlich nur eine billige Port-Erweiterung über ein einfaches
Bussystem - nichts weiter. Anstatt also einen Schalter direkt an das
Modul ranzuhängen könnte man den und ein paar weitere eben über ein
Kabel nen paar Meter entfernt anbringen. Viel Protokoll muss das gar
nicht sein - RS485 ist sogar überdimensionniert mit dem Treiber, das
ist richtig.
Man kann diesen Bus ja seeeehr langsam laufen lassen - 100 bis 1000 Bit
pro Sekunde oder so reichen für nen paar Schalter und Temperatursensoren
locker aus. Die Störanfälligkeit dürfte so sehr gering sein und man
könnte auf eine differentielle Übertragung verzichten. Mit
Fehlererkennung dürfte das dann wirklich kein Problem sein.

Aber gut - wie Ithamar schon sagt, wir können einfach beide
Möglichkeiten anbieten... jedes Modul mit einem kleinen Expansionsbus
Anschluss ausstatten. Da kann man dann auch für allgemeine
Porterweiterungen verwenden - auch in derselben Unterputzdose.
Die Baudrate dieses Busses kann ja variabel gestaltet werden, dann kann
man auch anspruchsvollere Dinge damit anstellen.

Es zwingt einen ja keiner das dann zu benutzen.

Aber neben jeden dritten Schalter werde ich definitiv kein komplettes
Modul setzen.



Zur Bestellung: Na es eilt ja mit dem Bussystem noch nicht so oder?

Wenn wir die Jungs bei Reichelt ganz lieb bitten, werden die die neuen
billigen LPCs bestimmt auch ins Programm aufnehmen. Hat ja schon bei
diversen Sachen von der Reichelt-Wishlist gut funktioniert.

Und mal ab und an ne Bestellung bei nem anderen Laden aufgeben tut auch
wirklich nicht weh.

Was mir heut noch spontan eingefallen ist: Wenn der Strom ausfällt und
wieder da ist, sind alle Knoten ja in ihrem Ursprungszustand - also die
Verbraucher meist ausgeschalten.
Da könnte man einen Knoten bauen, der einfach nur den Bus abhört und
alle Schaltvorgänge mitprotokolliert. Wenn der Strom ausfällt wird der
Knoten über eine angeschlossene Batterie gespeist und schaltet sich in
den Ruhezustand, um möglichst viel Energie zu sparen. Kommt die
Versorgungsspannung zurück, wacht der Knoten auf und sendet die
mitgeloggten Befehle an die Busteilnehmer, damit sie ihren
ursprünglichen Zustand bekommen...

Ist jetzt nicht so das wichtigste Modul, aber sicher nicht schlecht
wenns existiert. Eventuell könnte man das Teil noch erweitern, dass
bestimmte notgespeiste Knoten einen Befehl erhalten (z.B. die Rolladen
gehen bei Stromausfall zu -> Einbrecher), wenn der Strom ausfällt.

Wenn man die Steuerung über das Hutschienengerät bedient, könnte dies
die Funktion noch übernehmen... ansonsten halt ein kleiner
Busteilnehmer irgendwo, wo es nicht stört.

@and_ref: Da hast du natürlich Recht. Aber eigentlich bekommt der Knoten
ja wie beim vorherigen Mal den Befehl, irgendwas zu tun - ob er es dann
macht oder nicht ist eine andere Sache...
Aber es kann natürlich sein, dass da ungewünschte Nebeneffekte
entstehen, deswegen sollte man vielleicht nicht ALLE Befehle nach nem
Stromausfall nochmal rausschicken.
Aber jedem Modul ne Batterie für den Stromausfall zu spendieren finde
ich auch blöd, das ist zu aufwändig.

Ein anderer Ansatz wäre: Wenn man die Stromversorgung der Knotenlogik
eh von zentraler Stelle vornimmt, kann man von hier ja notspeisen...

Aber generell wäre es nicht schlecht, sich zu überlegen, ob man jedem
Knoten nicht eine "Notfunktion" spendiert, die z.B. bei einem
Stromausfall oder Versagen des Busses greift. Denn wenn plötzlich alle
Lampen im Haus aus sind und trotz wiederkehrenden Stromes nicht wieder
angehen, ist das auch nicht grad angenehm ;)

Aber das war nur ne Überlegung, die mir mal eingefallen ist, da kann
man sich später ja noch mehr Gedanken drum machen - ich wollts nur ned
bis dahin vergessen haben ;)

@Koopi: Mit der Webcam hast du Recht, das war so ne Schnapsidee die mir
mal in den Sinn gekommen ist. Ich bin zur Zeit ein wenig am
Rumexperimentieren mit dem ZoneMinder, das ist eine
Überwachungssoftware mit Bewegungserkennung, mein Gedanke war, das
Ganze miteinander zu verbinden.
Aber man könnte ja eine Schnittstelle zwischen Hausauto und den
Alarmtriggern von ZoneMinder schaffen, und immer wenn z.B. ein
Bewegungsmelder aktiviert wird, schaltet dieser die Überwachung
scharf.
Das ist jetzt auch erst mal nebensächlich, aber ich möchte sowas im
Hinterkopf behalten, um nicht später mal feststellen zu müssen, dass
man am Anfang des Projektes mehr hätte berücksichtigen müssen.

Die Preise für die Module waren nur ganz überschlägig gerechnet - kann
sein dass ich weit danebengelegen bin. Aber falls das Projekt ein
verwendbares Stadium erreicht und Interesse von mehreren Leuten
beherrscht, könnte man Platinen und Bauteile in höheren Stückzahlen
einkaufen und den Preis somit schon ein wenig drücken - falls möglich
möchte ich mit der Elektronik für ein Modul unter 10 EUR kommen -
Taster und so natürlich nicht eingerechnet!

Aber wozu du so viele Taster brauchst, ist mir nicht ganz klar. Bei uns
in der Uni (EIB) gibt es an der Tür 8 Taster, wobei aber Licht An/Aus
jeweils ein Taster sind, und man dies eigentlich auch ganz gut mit
einem toggeln könnte.
Des weiteren soll das Grundmodul ja noch erweitert werden können und
wenn das nicht reicht, gibts ja noch größere Module. Das kleine Modul
ist wirklich nur für einfachste Aufgaben gedacht, z.B. das Schalten
einer Lampe, wo beispielsweise nur ein Ausgang benötigt wird. Hängen
z.B. mehr als 4 Lampen an der Decke, nimmt man halt den
nächst"größeren" Knoten, oder ein Ausgangs-Zusatzmodul.

Also zumindest für unsere Wohnung würde das vollkommen langen, für
größere Bauten braucht man natürlich auch größere Module, die mehr
kosten...

Die Idee mit dem Funk gefällt mir sehr gut. Sollte auf jeden Fall im
Auge behalten werden.

Das Firmware-Update per Bus ist auch nicht schlecht, wobei man evtl.
gar nicht so weit gehen muss - die Einstellungen sollten auf jeden Fall
im Flash abgelegt werden und können dann auch von zentraler Stelle
programmiert werden. Die Schwierigkeit sehe ich da drin, dass man einen
extra Controller bräuchte, um den IC zu programmieren, der dann eine
eigene Firmware hat, etc...
Evtl. könnte es gehen dass man eine spezielle Startup-Routine hat die
den CAN-Controller in den Empfangsmodus setzt und die empfangenen Daten
einprogrammiert - aber ob und wie das geht, weiss ich leider nicht.

Aber ich hoffe, ein Firmwareupdate kommt nicht so häufig vor, notfalls
muss man die Knoten halt mit nem ISP-Adapter flashen...

Wenn du übrigens grad am Hausbau planen bist, ist das perfekt, dann
kannst du uns immer mit frischen Ideen und Vorschlägen versorgen, die
dann gleich mit einfließen können :)

Im Übrigen werde ich in nächster Zeit etwas weniger von mir hören
lassen, da ich mich auf meine Prüfungen vorbereiten muss, ich bleibe
aber am Ball. Richtig weiterentwickeln werde ich aber vermutlich erst
wieder Anfang Februar können... :-/

Also nen CAN Bootloader gehört in jeden Knoten! Das ist Grundausstattung
von so einem verteilten Bussystem!

Will ich immer die ganzen UPs auseinanderbasteln wenn ich mal was am
Programm ändern will - vielleicht sogar im ganzen Haus?

Kostet doch eh so gut wie nix an Speicher...

Da haben sich die Postings wohl überschnitten. Ich denk eigentlich das
man ohne funktionsfähigen Bootloader den man auf Herz und Nieren
getestet hat, nicht anfangen sollte das System im Haus einzubauen.

Nur meine Meinung.

Also ich finde es super, dass hier so ausgelassen diskutiert wird,
allerdings denke ich, dass man für die beiden Bereiche (Funkkomponenten
und Remote-Flashen) vielleicht jeweils einen eigenen Topic eröffnen
könnte. Dann bleibt das Ganze übersichtlicher und wenn man zu einem
speziellen Thema was sucht, findet man das Ganze schneller...

Meine Meinung zum Thema: Einen Bootloader fände ich nicht schlecht,
kenne mich allerdings damit zu wenig aus. Wenn sich jemand damit gleich
intensiv auseinandersetzen möchte gerne, ansonsten denke ich wäre es
sinnvoller, erst mal ein funktionsfähiges Netzwerk zumindest für den
Laborbetrieb aufzubauen, damit die Grundfunktionen vorhanden sind und
getestet werden können...

Funk finde ich prinzipiell auch toll, ist halt die Frage ob man zwei
Subnetze per Funk verbinden will, z.B. um zwei Stockwerke zu verbinden
oder ob man einzelne Sensoren/Aktoren mit dem Bus verbinden will. In
ersterem Fall sollte Strom kein Problem sein, in letzterem ist die
Frage ob der Stromstoß eines Piezokristalls langen kann um den µC mit
Strom zu versorgen, ihn zu booten und das Kommando per Funk
abzuschicken. Und die Reichweite ist dabei auch nicht uninteressant...

Hi Leute,

ich habe diesen Thread hier schon eine weile Beobachtet und bin
begeistert. Ich habe mir natürlich auch schon diesbezüglich einige
gedanken gemacht.
Eins bereitet mir aber noch Kopfschmerzen. Da ich gelernter Elektriker
bin, kenne ich mich einigermassen mit den VDE Normen aus. Leider hat
man keinerlei gewärhleistung auf selbsterstellte Elektronik mit der man
230V Schalten möchte. Daher habe ich mir gedacht, die VDE ein wenig zu
biegen. Wenn man nun statt 230V einfach 12V auf der Platine schaltet
würde man keinerlei Probleme mit der VDE bekommen, da man mit den 12V
in die Schutzkleinspannung fallen würde. Nun könnte man aber mit den
12V ein Relais Schalten das VDE und CE Zertifiziert ist und somit im
Fehlerfall auch kein Problem mit der VDE (Versicherung) kriegen würde.
Ich habe da auch schon etwas gegoogelt und folgendes Relais gefunden.

http://www.elektromaterial-discount.de/sess/utn;jsessionid=1543d934cd00f00/shopdata/?main_url=go.shopscript%3Fa%3DN114075

Was haltet ihr davon?
Eure Meinung würde mich echt interessieren.
Gruß
   Sascha

@Sascha:
genauso habe ich das gemacht (gut, ich habe 24V statt 12V). Im
Schaltschrank schalte ich "ganz normale" Schaltschrankrelais. Der Bus
ist komplett Niederspannung, in die Busdosen führt nirgends 230V.

Dein Eltako sieht etwas teuer aus, ausserdem: wie montierst Du das?

Gruß, Stefan

Tja das Problem ist nicht wegzudiskutieren, aber ich denke es besteht
immer... auch wenn man 12V schaltet und dann auf ein Relais geht, so
muss dieses immer noch angeschlossen werden. Und das sollte ein
Elektriker machen, sonst gibts im Problemfalle trotzdem Ärger.

Ich studiere beispielsweise Elektrotechnik und kann Schaltungen
entwickeln - darf sie aber nicht in Betrieb nehmen, wenn 230V im Spiel
sind. Man lernt im Studium zwar wie man Laplace-Transformationen
vornimmt, aber wie man richtig Gebäude verkabelt oder so, das bekommt
man leider nicht richtig vermittelt.
Ich wäre dafür, dass man einen Teilabschluss machen kann, der einem
einfache Kenntnisse in solchen Sachen beibringt und auch prüft, mit dem
man dann "offiziell" kleinere Geräte am 230V-Netz in Betrieb nehmen
darf. Klar dass man mal nicht eben die Ausbildung eines Meisters machen
kann, aber zumindest so die Basics sollten einem auch vermittelt
werden.

Man bewegt sich immer in ner Grauzone. Man lernt viel und will viel
ausprobieren, aber darfs eigentlich nicht. Ne einfache Steckdose
anschliessen darf man offiziell nicht, daran halten tun sich natürlich
vermutlich die wenigsten...

Um zum Thema zurückzukommen: Wenn man mit Relais schaltet, hat man
leider wieder das Problem, dass z.B. eine Phasenabschnittssteuerung
nicht funktioniert... also nix mit Dimmen, zumindest nicht mit
Relais...

@Ithamar:
Also einen Dimmer entwickeln darfst Du (wenn Du fertig bist). Nur das
fertige Gerät an die Kabel anschliessen, das darf nur der Elektriker.

Übrigens: bei Conrad gibt es ein Schaltschrank-Dimmer-Modul zur
Ansteuerung über 0..5V für 20€. Ist das billigste, was ich bis
jetzt an fertigen Dimmern gefunden habe. Inkl. den magischen CE- und
VDE-Zeichen ...

Gruß, Stefan

Meine Meinung:
Mit dem Selbstbau spart man kein Geld. Wenn man möglichst effizient ein
toll automatisiertes Haus will: zum Chef gehen, 20 Überstunden die Woche
ausmachen und sich gut dafür bezahlen lassen. Für das mehr verdiente
Geld alles mit EIB bauen.
Wenn man sich in seiner Hauselektronik selbst verwirklichen will:
selber bauen.

> Musst Du ja beim Verkauf nicht verraten...

Das würde ich nicht machen ... das kann nach hinten losgehen. Besser
dem Käufer die Vorteile schmackhaft machen. Noch besser: Nicht
verkaufen ...

Ich habe bei mir EIB-Kabel verlegt und die an meine eigenen Buskoppler
angeschlossen. Wenn das Haus je verkauft wird, ist eine EIB-Umrüstung
damit möglich (davon abgesehen: einen Hausbus macht doch hoffentlich
jeder mit LEerrohren?).

Gruß, Stefan

>Na klar, vor dem Verkauf steckt man dann mehrere tausend Euro in die
>EIB-Umrüstung. Auch nicht so toll.

Andersrum: nach dem Verkauf ;-)

So kannst Du immerhin sagen:
"Schaut her, tolle Automation, ganz einfach zu Bedienen, blablabla...
... wenn Sie trotzdem je Probleme bekommen: alle Kabel sind schon
EIB-Standard, Sie müssen bei Bedarf nur noch die Elektronik gegen
Standard-EIB-Teile tauschen, geht ganz fix".

Gruß, Stefan

Gegenfrage:
Du baust Dir Deinen eigenen Motor für Dein Auto. Machst Du das, um
billig an einen Motor zu kommen, oder weil es Dir Spass macht, den
Motor zu bauen?

Wenn Du das Haus verkaufen willst, ist selbstgebauter Hausbus
sicherlich von Nachteil. Deine Investitionen in den Bus (finanziell und
ideell) wirst Du nie wiedersehen. Ich kann mir aber durchaus vorstellen,
dass man Käufer von dem System überzeugen kann und die das dann auch
drinlassen, wenn die wissen, dass sie im Notfall problemlos auf EIB
umrüsten können.

Übrigens: ich würde so ein Haus gleich kaufen ... und sofort die alte
Elektronik rausreissen und meine eigene einbauen ;-)

Gruß, Stefan

Sagen wirs mal so, schon alleine aus praktischen Gründen würd ich die
Elektroinstallation so wenig wie modifizieren, damit man eventuell
sogar  mit einem Schalter auf "herkömmliche" Verkabelung umschalten
kann.
Denn wenn mal der Bus nicht funktioniert, sitzt man im Dunkeln und das
könnte zu Ehekrieg führen ;)
Wenn man neu baut, ist es eh sinnvoll mehrere Leerrohre zu verlegen -
der Aufwand ist nicht soo viel höher, aber man ist nachträglich sicher
froh, vorgesorgt zu haben. Z.B. auch wenn man Netzwerkkabel oder
sonstiges verlegen möchte...

Interesse ist sicher da, das sieht man an den zahlreichen Beiträgen...

Kompatibel zu EIB sollte schwieriger werden, da EIB anders aufgebaut
ist als der hier vorgeschlagene CAN-Bus.

Klar ist der Umfang des Projektes groß, aber immerhin gibt es ja ein
eigenes Unterforum und einen Artikel im Wiki.
Und wenn die Entwicklung noch konkreter wird, steht auf meinem Server
vorbereitet ein eigenes Forum, ein Wiki, Webspace für Dokumente etc.
sowie Mailinglisten, SVN und was man sonst so zum Entwickeln braucht.

In einer Woche sind meine Prüfungen endlich vorbei, dann werde ich auch
Zeit haben, mich weiter mit der Entwicklung zu beschäftigen und wenn ich
recht informiert bin, haben hier im Forum dann auch andere Leute wieder
mehr Zeit, ich denke dann geht das Projekt wieder mit größeren
Schritten voran, momentan ist ein wenig Flaute.
Und dann werden wir sehen was sich alles realisieren lässt...

Hallo zusammen, was ist dennn an EIB so schlecht? Stromzuführung und
Daten extrem lahm über zwei Drähte zu schicken ist doch Ideal. Warum
dann CAN? Nur wegen dem Treiber? Bei 9600 Baud gibt es so gut wie keine
Probleme mit Reflektionen, Abschlüssen und ähnlichen Problemen. Den kann
man direkt mit einem Transistor und einer Drossel zur Stromauskopplung
treiben. Wenn man was selber machen will, würde ich erst mal soviel wie
möglich vom EIB abkupfern. Man muss es ja nicht EIB nennen.
Als Chip würde ich erstmal was nehmen, was sich Incircuit flashen
lässt. Sonst kann man Debugging gleich ganz vergessen.
EIB Protokoll ist ähnlich CAN aufgebaut. Hat aber viel einfachere
Schutzmechanismen. Das kann man selbst programmieren.

Auf Kompatibilität zum EIB würde ich z.B. bei dem automatischen
Anlernen der Aktuatoren erst mal verzichten. Aber um Himmels Willen
kein neues Protokoll erfinden. Wie viel man ändern muss, damit es keine
Rechtsansprüche seitens EIB gibt weiss ich allerdings nicht.

Den echten Vorteil einer Eigenentwicklung würde ich bei der Topologie
sehen, die mehr dezentral ist.
Und, dass man handelsübliche Billigschalter mit einer Huckepacklösung
auf Bus umrüsten kann. Damit ist die Baugrösse und der Formfaktor der
Platine schon fast vorgegeben: 60mm Durchmesser und max 15mm dick.

henry67

CAN ist nur in der absoluten Höchstgeschwindigkeit von 1Mbit/s auf 40m
begrenzt, für 50kbit/s gilt als Obergrenze 1km, für 10kbit/s gilt 5km.

Der Vorteil von RS485 gegenüber CAN ist gleichzeitig sein größter
Nachteil: kein eigenes Protokoll.

D.h. du musst dich um alles selber kümmern, Kollisionen,
Fehlermeldungen, etc.
Das ist bei CAN alles schon (imho recht clever) fertig. Der Nachteil
ist eben der dadurch entstehende Protokoll-Overhead.

Hardwaremäßig sind RS485 und CAN fast identisch

Sehr netter Thread,
Ich moechte noch einen Gedankenanstoss gegen CAN oder RS485 bringen .
All dies fordert eine neue Infrastruktur und ist kompatibel zu nichts.
Zudem muessen auch sicherheitsrelevante Teile wie Spannungsversorgung
selber gebaut werden. Dies ist im Brandfall kritisch.

Setzt man komplett auf Ethernet (dh. auch PoE) werden ganz klar die
einzelnen "Platinen (I/O etc)" teurer da sie einen Ethernetchip fuer
ca 6 EUR tragen muessen. Dies koennen aber in naher Zukunft von
guenstig zu erhaltenen PoE Switches versorgt werden. Zudem hat man dann
im Haus fuer alles (Hausbus, PC, SatReciever, Kameras, WLAN, Telefon
etc) einen sternfoermiges Netz welches erprobt und rel. ausfallsicher
ist. Oder was passiert wenn einer der CAN Konten nen Kurzen hat?

Gerade bei einem Neubau ist das der richtige Weg in die Zukunft weil es
kompatibel ist und Zukunft. Es werden sicherlich auch Kommerzielle diese
Richtung einschlagen. (siehe oben genannte Firma "IMOTIX")

Was denkt ihr?

Gruss

H:V

Ethernet und PoE hört sich ganz toll an und ich bin auch totaler Fan
davon - nur in diesem Falle stimme ich ProkyonA ganz zu, denn Ethernet
ist dafür weniger geeignet. Ich halte es zwar für nützlich, Knoten auch
per Ethernet ankoppeln zu können, aber nicht zwingend erforderlich.

Und das Thema PoE ist auch so ne Sache, es gibt kaum günstig
beschaffbare DC-DC Konverter, die 48V vertragen. Ich hatte mal vor, ein
8-Kanal PoE Netzteil mit Überwachung etc. zu bauen und die Pläne im
Internet zu veröffentlichen. Die ICs als Samples habe ich zwar da, aber
das bringt niemandem was, wenn er sie nicht beschaffen kann... und da
brauch ich mit PoE gar nicht erst anfangen. In meinem Fall hab ich
meine Stromversorgung auf 18V gelegt und kompensiere so den
Spannungsabfall auf den Leitungen, den Rest regelt ein Linearregler
runter, fertig.
802.3af wäre toll, aber noch nicht brauchbar...

> Ethernet/PoE mit 100 MBit (denn mehr geht mit PoE nicht, wegen den
> fehlend Pärchen), ist in 25 Jahren genau so alt und exotisch wie
CAN,
> vielleicht sogar noch exotischer.

Hmm hast du dir mal die Specs für PoE genau angeschaut? Also nicht so
ein Ich-Bau-Mir-Selbst-Mein-PoE, sondern die 802.3af. Dort ist nämlich
beschrieben, dass entweder die freien Adern oder die Signaladern für
die Spannungsversorgung verwendet werden können - die auf freien Adern
beruhende ist halt einfacher zu implementieren.
Ob das allerdings mit Gigabit auch geht, weiss ich nicht, das einzige
Problem sehe ich momentan in der Dämpfung der benötigten Bauteile zum
Auskoppeln der Spannungsversorgung - ansonsten ist es ja kein Thema, da
es sich ja nur um eine Gleichspannung handelt, die die Daten nicht
stört.

Als Bussystem für die Hausautomation würde ich aber nicht Ethernet an
sich verwenden, sondern CAN, aber dann über entsprechende Konverter die
CAN-Daten in Ethernet-Frames kapseln, die dann für den weiteren
Transport sorgen. So wie PPPoE, sonst muss man zwei Protokolle
entwickeln und man sieht ja, dass es für uns schon schwer ist, eins
fertigzustellen. Liegt in meinem Fall aber auch besonders dran, dass
die Uni momentan viel Zeit kostet...

Hallo!

-Ich habe den Threat nur eben mal oberflogen, schaue aber bestimmt
nochmal genauer rein, wenn ich die Zeit habe.
-Hab auf jeden Fall auch Interesse am Thema Hausbus und vor einiger
Zeit dazu mal im inet herumgestöbert.
-Folgendes Projekt scheint hier noch nicht erwähnt worden zu sein:
http://caraca.sourceforge.net/
-Die benutzen auch Atmel, CAN, Unterputznodes, etc. ...

_
mfg,
Kevin.

Nach über 3 Jahren?

Denke da wurde zwischenzeitlich schon ordentlich getestet

@G. L.: Prinzipiell hast du Recht, aber bei einem solchen Projekt gibt 
es immer wieder etwas zu testen - und wenn es neue Features sind...

@Moritz: Gerne, schau doch mal bei uns auf der Projektseite vorbei 
(http://www.isysbus.org) oder ins Forum (http://forum.isysbus.org) - 
dort läuft auch gerade eine Platinen-Sammelbestellung, falls du dich 
dran beteiligen möchtest.

Die meisten Diskussionen laufen aber über das IRC (EU-IRC, Channel 
#iSysBus) - schau doch einfach mal rein, wir freuen uns!

Hui, da lehnt sich aber jemand weit aus dem Fenster...

CAN ist ein "toter Fisch"? Zu teuer? Auwei ... sehr schlecht 
recherchiert... SEHR schlecht.

Sorry, dass ich das jetzt so direkt schreibe, aber ich kann mich einfach 
nicht zurückhalten... hast du mal geschaut was ein CAN-Baustein beim 
Reichelt kostet? Und dann was einer für RS485 kostet? Was fällt dir auf?
Mal davon abgesehen, dass du mehr Aufwand bei RS485 hast, zwecks 
Kollisionserkennung, Priorisierung etc. - das macht bei CAN der 
Controller.

Und von wegen Einsatz... bist du schon mal mit nem Auto gefahren? 
Flugzeug geflogen? Weisst du was da ziemlich häufig verwendet wird? 
Richtig: CAN. Ist auch recht gut erprobt...

Und 30 Meter für ein ganzes Einfamilienhaus? Naja wenn du ein Flurlicht 
steuern möchtest, dann könnte das langen. Rechne mal mit 500 Metern, 
dann kommst du eher hin. Wenn du schon mal Kabel verlegt hast, weisst du 
wie schnell sich die Meter aufsummieren. 10 Meter durch ein Leerrohr um 
ein paar Ecken sind schnell weg.

Visualisierung per PowerPoint mag ja vielleicht gehen (meinst du nicht 
eher Excel?), aber das ist für Präsentationen und nicht für 
Gebäudeautomatisierungen gedacht.

Sorry, ich bin normal nicht so - aber ich beschäftige mich seit mehreren 
Jahren intensiv mit Gebäudeautomatisierungen - da tut es weh, sowas zu 
lesen! Den Rest kommentier ich mal nicht...

F.H. schrieb:
> Hallo Ithamar,drum bleiben ja auch viele neue Autos stehen,ich sehe es
> jeden Tag auf der Autobahn.Can ist natürlich für das Auto konzipiert
> worden, und da würde ich es auch lassen.
>

Also ich bezweifle mal das es am CAN Bus liegt und so viele neue Autos 
sehe ich persönlich nicht stehen bleiben.

Der CAN Bus ist schließlich auch schon seit den späten 80ern in 
einzelnen Fahrzeugen im Einsatz und soweit mir bekannt ist gab es da 
keine größeren Pobleme das die Wagen wegen dem Bus System stehen 
bleiben, warum sonst sollte man auf immer mehr Bus Systeme setzen 
(FlexRay, MOST, LIN)?

Der Aufwand einen RS485 Bus in Software so hinbekommen, dass er auch nur 
annähernd so sicher ist wie CAN ist enorm. Der CAN Bus wird 
mittelfristig der Bus der Wahl bleiben. Kommerzielle Buse wie Profibus 
usw sind für open-source Projekte eher nicht geeignet

Hmm du bist also unzufrieden dass es so viele Bussysteme gibt, alles 
vergänglich ist und obendrein noch Arbeit macht... schon mal überlegt 
ohne Hausbus zu wohnen? Nicht jeder muss unbedingt einen Hausbus 
haben...

Was ich auch nicht so ganz verstehe - du findest bis auf RS485 alle 
Bussysteme doof, und alle die mit einem anderen System arbeiten haben eh 
keine Zukunft. Such dir doch nen Hausbus mit RS485 oder bau dir einen 
eigenen - spätestens wenn du das tust und dich intensiver mit der 
Materie beschäftigst, wirst du wohl sehen dass es optimalere Systeme 
gibt. Und seien es so Dinge wie der Energieverbrauch, den man im ersten 
Moment vielleicht nicht betrachtet (das soll jetzt keine Wertung 
gegenüber RS485 sein, nur ein Beispiel, was man beachten muss). Auch DMX 
mag erprobt sein und für Lichtsteuerung funktionieren. Aber schon mal 
dran gedacht, dass DMX erweitert wurde, weil es einfach nicht mehr für 
die Anwendungen ausgereicht hat? DMX is halt sehr begrenzt, für ne 
Hausautomatisierung, bei der es nicht nur Beleuchtung und einfache 
Geräte gibt, vielleicht halt zu begrenzt.

Und das "Nee,mit einer Festplatte nicht,aber die Systeme sind 
gespiegelt,und dann geht es gleich weiter,geht genauso schnell,wie einen 
Lichtschalter
auswechseln." glaubst du ja selbst nicht. Oder hast noch nie wirklich 
damit gearbeitet.

Mach doch bitte einen ich-beschwere-mich-über-alles-Thread auf, hier 
gehts aber eigentlich um Open-Source-Hausautomatisierungen...

Hallo euch allen,

ich bin schon seit einiger Zeit auf der Suche nach einem CAN-Bootlader
für den AT90CAN. Leider konnte ich dazu aber kein fertiges Projekt
finden.
Genauere Informationen gibt es unter fogendem Link:

Titel - Beitrag "CAN BUS Bootloader AT90CAN"

Ich hoffe es finden sich einige um dieses Projekt zu realisieren oder
die dabei helfen können.

Grüße martin