www.mikrocontroller.net

Forum: Haus & Smart Home [OS-HB] Ethernet?


Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
bei der wahl eines geeigneten hausbusses stört mich der gedanke des
aubaus einer entsprechenden infrastruktur immer mehr.
besonders in der hinsicht  bereits zwei bestehender netze
(240V und IP LAN/WLAN, beide bereits unverzichtbar ;-)) wird für mich
der aufbau eines dritten (CAN oder 485) immer fragwürdiger.
im neubau wäre es ja noch denkbar aber im altbau halte ich den aufwand
für nicht mehr vertretbar.

so wie es aussieht ist wohl auch der preisunterschied zwischen LAN- und
CAN- interfaces in letzter zeit ziemlich geschrumpft.
da auch die rechenleistung der prozzessoren enorm gestiegen ist habe
ich meine zweifel das sich die geringeren anforderungen des CAN
bezüglich hardware/software aufwand gegenüber des vorteils einer
bereits vorhandenen infrastruktur und der unverselleren weltweiten
verwendung noch lohnen.

besonders bei verwendung von relativ wenig knoten(wie es im altbau sein
wird) dürfte sich der einsatz eines zusätzlichen struktur(CAN) imho
nicht mehr lohnen.
nur bei einer hohen knotendichte (quasi jeder schalter und verbraucher
seinen eigenen CANcontroller) würde es sich noch rechnen.

da auch ein immer größeres angebot von günstigen massen IP LAN-geräten
auf den markt kommt (obwohl technologisch aufwendiger so ist wohl
mittlerweile das einstecken eines LAN-HUB günstiger(und gängiger) als
die verdrahtung einer CAN-abzweigung ;-)) so schlägt wohl doch das
pendel eher zu  aufwendigen IP LAN als zu einfacheren Systemen .

So betrachtet halte ich jetzt für mich, anstelle einer komplexen CAN
architektur ala EIB mit repeater und routingfunktionen, mehr die
Verwendung des IP-LAN gegeben. gegenfalls mit Raum/Insel subnetzen
(I2C/1W Portexpander usw)ausgestattet.

wie seht ihr dies?

reinhard

Autor: Hr. Vorragend (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe das nicht nur bei Altbauten so. Warum sollte man sich bei
Neubauten 2 Busse ins Haus legen wenss einer locker tut. Bald kommt QoS
 richtig zum Einsatz und man kann die Haussteuerung ja in einem anderen
Subnetz fahren so das man keinen Virus in sein Haus bekommt.


Nur wie siehts mit der zu verwendenden Hardware aus?

Autor: Hr. Vorragend (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Toll wärs schon - und ich denke wenn das schön gekapselt wird, ist es
dem [OS-HB] egal ob er über CAN oder Ethernet läuft - aber das
LAN-Interface halte ich momentan noch für Utopie. Was kostet so ein
Chip, wo kann man den bekommen (ich meine in Stückzahlen, keine
Samples) und wie aufwändig ist der zu verdrahten/programmieren? Auch
wenns einfacher geworden ist, ich denke momentan ist es noch keine
wirkliche Alternative.
Ich bin auch der totale Netzwerkfan, bei mir sind sogar am Grillplatz
im Garten hinter der Garage Netzwerkanschlüsse, aber trotzdem zweifle
ich ein wenig...

Aber ich lasse mich gern vom Gegenteil überzeugen. Wenn es ein
vernünftiges Konzept gibt, bin ich gern dabei.

Mit dem [OS-HB] möchte ich auch baldmöglichst weitermachen, nur
momentan macht mein Server derartige Probleme, dass ich schon fast
vermute, dass er weiblich ist oder weibliche Züge entwickelt oder
wasweissich...
Aber bis meine beiden gecrashten Platten mit den wichtigen Daten wieder
laufen, werde ich mich erstmal darum kümmern, deswegen bleibt leider
wenig Zeit mich um den Hausbus zu kümmern... :-/

Autor: Hr. Vorragend (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guck dich doch mal auf der HP vom Hersteller um, soll ganz einfach zu
handeln sein da der Ganze ethernet Kram auf Hardwareebene laueft. Das
Teil kann dann via I2C an den AVR angebunden werden.
Zum Preis/beschaffbarkeit kann ich im Moment nix sagen.

Aber 1-3 von den Modulen pro Zimmer ist doch sicher machbar, oder?
Dann in jedem Raum an strategisch guter STelle (WAF) einen kleinen
Unterputzkosten wo die LAN Platine via LSA Klemmen mit ihren Sensoren
verbunden werden kann. Hier koennen dann auch die Relais fuer die
Aktoren Platz finden wenn man das nicht zentral machen moechte....

Mode

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab grad mal die andere Diskussion angeschaut
(http://www.mikrocontroller.net/forum/read-1-179365.html), das hört
sich besser an als ich dachte...

Wenn man von diesem Chip Samples bekommen könnte, könnte man das testen
bzw. in unser Projekt einbeziehen. Wär ne Sache, schon allein wenn man
nur beispielsweise ne Bridge daraus basteln könnte - um längere
Strecken über Ethernet überwinden zu können. Aber für direkte Knoten
wärs natürlich auch super.

Vom Protokoll her denke ich sollten wir das auf jeden Fall
berücksichtigen, aber unser Vorschlag geht ja eh schon in Richtung IP.

@reloni: Hättest du mal Lust, dich mit der Materie zu befassen und
evtl. mal mit den Samples zu experimentieren?

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Hr. Vorragend (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guter  Link

Da werde ich wohl dabei sein :)


Gruss

Mode

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
nach ein paar tagen internetabstinenz wieder da.

allgemein denke  ihr das ähnlich wie ich sehe:

1:CAN-Bus als notlösung da ethernet zu aufwendig.
2:wenn ethernet einfacher dann wechsel!

Wenn ich mir den oben genannten thread
http://www.mikrocontroller.net/forum/read-1-310134.html
mit der projektvorstellungvon Sssssssssssss:
http://avr.auctionant.de/avrETH1/

so denke ich das dies (evtl. mit ein paar winzigen modifikationen)die
richtige Hardware Basis für ein Hausbus wäre:

mit ethernet anbindung : also eine bereits in den meisten
technikfreundlichen häusern vorhandene infrastruktur.

mit PoE (power over ethernet) könnte die bei vielen knoten aufwendige
Versorgungsproblematik.

die platine könnte wohl noch installationsdosen gerecht dimensioniert
werden.

der mehrkostenaufwand des ethernetcontrolers gegenüber CAN wäre mit (so
wie ich es rauslese) ca 5 euro nicht das entscheidende kriterium.
insbesondere da sich dafür die vernetzung in den meisten fällen
vereinfachen würde.

das was mich persönlich noch stört wäre dieses smd design. da ich nicht
unbedingt der hardwarefreak bin ist es für mich erstmal ein gravierendes
hindernis. da andererseits das größenproblem für den steckdoseneinbau
dies wohl sowieso erfordert würde ich auf eine dip- portierung
absehen.

ideal wäre es wenn man eine standard os-hb version entwickeln könnte
und diese als sammelbestellung fertig smdbestückt beziehen könnte.

aber ich werde ersteinmal noch das obengenannte projekt beobachten.

auch für das eingebaute html  protokoll könnte ich mich erstmal
anfreunden. ließe es doch erstmal eine sehr offene software struktur zu
(es heißt ja schließlich OS-HB ;-)  )
daher sehe ich auch erstmal keine veranlassung es zu kapseln.

man solte noch mal durchchecken inwieweit ethernet html der
erforderlichen hausbus performence entspricht.
alternativ hätte ich da noch snmp: im hinterkopf.

schau
reinhard

Autor: Hr. Vorragend (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eben. niemand zwingt dir mit dem Teil HTML auf. Waere auch garnicht so
gut dafuer. Gerade SNMP ist doch genau zum Steuern und Auslesen von
Geraeten gemacht:
    * Überwachung von Netzwerkkomponenten.
    * Fernsteuerung und Fernkonfiguration von Netzwerkkomponenten.
    * Fehlererkennung und Fehlerbenachrichtigung.
Laeuft zwar ueber UDP auf SNMP wartet ja auf nen Response so dass das
Licht auf jeden Fall angeht - auch wenn das erste UDP Paket verloren
geht. Dauert dann eben nur ein paar ms laenger.
Und gerade Geschwindigkeit ist wichtig. Es kann nicht sein dass das
Licht nach Knopfdruck noch 500ms braucht bis es angeht. Daher auf jeden
Fall so etwas Kleines wie SNMP.


H.V.

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein - keines falls fühle ich mir das html aufgezwungen.
im gegenteil - ich bin begeistert von den möglichkeiten -
man stelle sich vor:
jeder lichtschalter seine eigene hompage:
wwww.lichtschalter.badezimmer.mysweethome.net/acces.php?switchble=false
mit bebildeter bedienanleitunganfahrskizze und gästebuch ;-)

reinhard

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zum protokoll habe ich mir folgende gedanken gemacht:

zwei hauptlinien
1. kompaktes binär basierendes festframe Päckchen
2. komplexes asciibasierendes freiskalierbares Päckchen

zu 1.
wenig traffic, rel. einfach zu codieren, decodieren,
keine strigverarbeitung/hochsprache erfoerdlich, geeignet für kleine
controller.
nicht mit monitor_/terminalprogramm lesbar, nicht skalierbar und nur
aufwendig zu modifizieren,gut geignet für einfache schaltfunktionen

zu 2:
viel traffic, bei kleinen controller aufwendig zu codieren/decodieren,
erfordert im allg. hochsprache mit stringverarbeitung. eher für größere
controller geeignet.
mit normalen terminalprogramm sichtbar und sendbar. beliebig skalierbar
und modifizierbar. gut geignet für komplexere geräte wie klimasteuerung
und mediageräte anbindung.

da beide hauptlinien ihre daseinberechtigung haben möchte ich auch
beide im projekt ermöglichen. dies ist durch die vergabe
unterschiedlicher ports auch ohne crashwahrscheinlichkeit gegeben.


Protokoll 1       OS-HB_Ethernet_BIN_protokoll
grundprotokoll UDP!
da nicht zuviele protokolle im OS-HB rumschwirren würde ich hie, wie
auch beim CAN bus das CAN/CANopen Protokoll verwenden.
damit man auch brücken leicht bauen kann sollte das CAN-Protokoll
einfach in UDP eingepackt/gekapselt werden (ob mit oder ohne CAN-Header
weiß ich noch nicht?). bis auf die eigentliche
CAN/Ethernet-Baustein-Kommunikation könnten die gleichen encoding
routinen verwendet werden.

Protokoll 2     OS-HB_Ethernet_Text_Protokoll
 auch hier grundprotokoll UDP
vorrausgesetzt das wir hier bei standards bleiben(was ein prinzip von
mir ist) sehe ich zwei möglichkeiten:

1 XML
http://de.wikipedia.org/wiki/Xml
2 SNMP     (
http://www.jklein.de/techniker_arbeit/tech_html/sn...   )

Beide sind textbasierend und freiskalierbar  .
snmp (einfaches netzwerk verwaltungs protokoll) wäre altbewährter
standard zum verwalten von netzwerkkomponenten wie router, printserver
usw.  es beinhaltet wie CANopen nicht nur den aufbau des eigentlichen
packetes sondern auch den dazugehörigen hintergrund wie spezifizierte
geräte tabellen und variablen.
das heißt wenn wir uns für das snmp system im ganzen entscheiden würden
dann hätten wir uns auf viel mehr festgelegt als nur das protokoll.
und wir müssten uns auch ne ganze menge spezifikationszeug
reinziehen.(siehe link oben)

xml ist noch flexibler als snmp. festgelegt wäre nur der aufbau der
textnachricht. das heißt wir wären im weiteren freier für die umsetzung
.frei heißt nun das wir uns nicht versenken müssen in die snmp
spezifikation sondern uns in der umsetzung frei austoben können.
Allerdings dies auch müssen!

Autor: Michael P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei einem Binärprotokoll kann man noch ein Java Applet entwickeln das
dieses Protokoll beherscht. Dieses kann man gleich über den Webserver
ausliefern.

Mfg Michael

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber bestimmt nicht ueber einen Webserver auf uC Basis! Und nein ich
will auch so kein Java im Hausbus. Ist ungeeignet da viel zu langsam...
dann lieber etwas mehr Programmieren.

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallöchen,

ich mische mich mal kurz ein :)
Ich bin auch gerade dabei für meine (dieses Jahr zu sanierende) Hütte
ein Automatisierungssystem zu entwickeln und lese hier deshalb mit
großem Interesse mit!

Ich werde auf jeden Fall auf Ethernet als Bus setzen und habe auch
schon eine Hardwareplattform bestehend aus einem MSP430 Board mit
CS8900A Ethernet Chip, dass ich um ein bisschen IO und Stromversorgung
über Netzwerkkabel erweitere. Unter anderem werde ich auch ein
grafisches Display, einen Encode, einen Lautsprecher und ein Mikrophon
anschließen.

Zum Protokoll: Ich schicke Nachrichten über UDP mit Bestätigung, die
ein eigenes binäres Format enthalten.

Habe mir gerade mal den SNMP Link angeschaut. Im Prinzip habe ich ein
ähnliches Protokoll entwickelt, nur etwas einfacher.

Ich bin nicht sicher, was es für Vorteile hat auf SNMP zu setzen.
Vorhandene Applikationen sind vermutlich sehr speziell auf bestimmte
Hardwareprodukte programmiert, oder?

Deshalb wird es eh nötig sein, eine eigene Software zur Konfiguration
und Überwachung zu schreiben.

Ausserdem scheint es mir ziemlich aufwändig zu sein, eine komplette
SNMP Unterstützung in den Geräten zu programmieren.

Es ist ja auch die Frage, ob die Geräte untereinander oder nur über
einen zentralen Server kommunizieren sollen?

Ich plane die zentrale Variante. Das geht zwar zu Lasten der
Ausfallsicherheit, hat aber viele Vorteile.

Mein Protokoll hat Befehle und Events, dass heißt, sowohl der Server
(Master) als auch die Nodes (Clients) können Nachrichten senden.

Clients senden Events an den Master, wenn sie sich Initialisieren und
wenn sich Eingansdaten ändern.

Der Master schickt Konfigurationsparameter auf einen INIT-Event
und SetAktor-Befehle aufgrund eines beliebig komplexen Regelwerks, dass
ich definitiv nicht auf einem 8 oder 16 bit Controller programmieren
möchte :)

Es gibt Befehle um Geräte-Variablen (Inputs und Outputs) zu lesen und
zu schreiben (nur Outputs).

Die Serversoftware schreibe ich in .NET. Ich will versuchen, sie unter
Mono zum Laufen zu bekommen, dann kann ich nämlich las
Haardwareplattform z.B: einen  Linksys NSLU2 einsetzen und muss keinem
PC vertrauen !

Gruß, Jan

Autor: Hr. Vorragend (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum traust du einem Linksys NSLU2 mehr als einem PC?
ServerPCs mit KLEINEM Stromverbrauch und Notebooklautstaerke gibt es
NEU ab 300 EUR zzgl Mwst vom Markenhersteller. Dem wuerde ich mehr
vertrauen als einem Linksys NSLU2 ;)

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, allein schon mal weil er keine beweglichen Teile hat (z.B.
Festplatte)

Ich habe eh einen LInux-Server laufen. Möglicherweise nehme ich den
NSLU2 auch nur als Backupsystem.

Muss auch kein NSLU2 sein. Der steht halt bei www.mono-project.com auf
der Liste der Geräte, die momentan unterstützt werden!

Gruß, Jan

Autor: Hr. Vorragend (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Take Raid 1 ;)
Natuerlich reicht auch was kleineres wenn er nur Hausbus machen muss.
Aber mein Linux Server hat schon allerhand zu tun ;)
Fuer Hausbus wuerde ich mri aber in jedme Fall konfigurierte
Ersatzhardware daneben stellen die nur umgesteckt werden muss. Und ne
Taschenlampe :)

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jupp, das ist auf jeden Fall sinnvoll.

Klar, mein Server macht auch so Einiges. Aber ich würde ihn noch nicht
als Hochverfügbarkeits-Plattform auslegen wollen :)

Wenns Internet oder das Telefon mal nicht geht, geht ja nicht gleich
die Welt unter.

Aber RAID-1 ist auf jeden Fall ne sinnvolle Sache und kann jee Menge
Ärger sparen...

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... wenn ne Platte kaputtgeht. Wenn der Server einfach so sporadisch
abstürzt und das Dateisystem mitzieht, dann hilft dir das auch herzlich
wenig - das spür ich zur Zeit am eigenen Leib.
Dann hilft nur noch ein gutes Backup.

Aber Redundanz ist immer wichtig, deswegen find ich beim Hausbus eine
dezentrale Steuerung sinnvoller...

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, damit wären wir wieder beim Thema (Protokoll).

Hat sich denn schon jemand Gedanken gemacht, wie man das ganze System
initialisiert? Jede Node muss dann doch eine (möglicherweise ziemlich
umfangreiche) Konfiguration erhalten. Welche Nachricht wird an welche
Node gesendet, wenn bestimmte Bedingungen erfüllt sind.

Ich beabsichtige als Bedingung nicht nur das Ändern des Wertes eines
lokalen Sensors zuzulassen sondern auch komplexere Verknüpfungen
abhängig von Zeit, globalem Status des Systems, Sensorwerten von
anderen Modulen, etc...

Ausserdem kann eine Aktion ja mehr sein, als einfach einen Aktorwert
einer Node zu setzen. Da können ja auch zeitliche Abläufe gewünscht
sein, die mehrere Operationen beinhalten.

Das kann ja beliebig komplex werden - deswegen bin ich für eine
zentrale Steuerung. Ich implementiere gerade eine Art einfache
Programmiersprache, mit der ich solche Aktionen, Regeln und Bedingungen
formulieren kann.

Die werden dann zyklisch oder beim Auslösen von Events zentral geprüft
und die entsprechenden Aktionen werden gestartet.

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenns ums Thema Protokoll geht, wäre das im anderen Thread besser
aufgehoben...

Ich persönlich halte aber von der rein zentralen Steuerung nicht viel -
wenn dein Server mal weg ist, dann hockst du im Dunkeln und wirst den
Tag verfluchen an dem du dich für diese Methode entschieden hast.
Wie schon erwähnt - mein Server zickt derzeit auch ziemlich rum und
stürzt dauernd ab, aber trotz stundenlanger Suche hab ich den Fehler
nicht lokalisiert, weil dieser sporadisch auftritt. Vermutlich sind
irgendwelche Elkos defekt oder was auch immer...
Hast du das bei deinem Hausbus auch, werden deine (besonders
weiblichen) Hausgefährten schnell einen Krieg anzetteln, wenn was nicht
funktioniert...

Aber warum muss man das festlegen? Man kann doch auch ein
Multimaster-System nehmen und ein Controller hat eben besonders viel
Intelligenz. Ob das ein PC oder ein "größerer" µC ist, ist ja egal.
So wie es in dem Thread über die Hutschienenkomponente beschrieben
ist.
Jeder Taster kann selbst eine Lampe ansteuern, aber es gibt auch einen
Controller im Sicherungskasten, der eben für komplexere Aufgaben
zuständig ist. Wer den nicht haben will, lässt ihn weg, wer nur ne
zentrale Steuerung haben will, baut die und wer beides haben will kann
dies auch realisieren...

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, beide Konzepte zu kombinieren ist vermutlich die beste Möglichkeit
eine Balance zwischen Ausfallsicherheit und Funktionsumfang zu haben.

>wenn dein Server mal weg ist, dann hockst du im Dunkeln und wirst den
>Tag verfluchen an dem du dich für diese Methode entschieden hast.

Naja, deswegen werde ich wenn möglich Hardware einsetzen, die
a) günstig ist, damit ich ein zweites System einfach daneben stellen
kann und
b) möglichst wenig bewegliche Teile hat.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
am besten ist du machst eine linux-boot-cd... 2 gleiche rechner.. die cd
kopierst auch gleich und legst in beide rechner ein... system rennt dann
aus dem ram und du hast nie mehr probs ;)

73

Autor: Uwe Stark (uwe_stark)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

bei meiner suche nach einem Ethernet Hausbus mit POE bin ich auf diese
Thread gestossen. Hat einer von euch so eine Webserver als Aktor schon
mal erfolgreich getestet. Mir geht es darum nicht noch mal die Wände
aufreisen zu müssen. Ich habe ca. 8 Zimmer die mit einem
Netzwerksanschlusss versehn sind und an einem MDIX fähigen Switch
hängen, Teilweise sind DBox 2 Receiver ans Netz angeschlossen. Jetzt
wollte ich in die Zimmer noch normale Switches anschliessen und an
diese dann die Actor die mir Schaltzustände melden b.z.w. diese
auslösen können oder wäre es doch besser auf CAN zu setzen und eine
Leitung zusätzlich zu legen.

Gruß
Uwe

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja ich vermute mal, du hast kein Gigabit - dann sind doch die Adern
4/5,7/8 nicht belegt. Wenn du diese in den Dosen abgreifst oder dir
einen Adapter bastelst, kannst du die verlegten Kabel verwenden und
trotzdem CAN darüber fahren.

Bei einem Webserver seh ich das Problem der Instabilität - der hat sehr
viel Code drauf und ist dementsprechend fehleranfälliger.

Bei unserem OS-HB Projekt (http://devel.antimon.de/hausbus) haben wir
auch Konverter CAN/Ethernet geplant, aber da sind wir leider noch nicht
so weit. Ausserdem sind die Kosten für einen Ethernet-Knoten um einiges
höher als die eines CAN-Knotens...

Also ich würd vorschlagen, nimm CAN. Ausserdem ist bei PoE die
Spannungsversorgung das Problem - die Step-Down Regler von 48V sind
sehr schwer zu bekommen... ansonsten wärs toll.

Autor: Matthias Beitz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mit dem eZ80Acclaim hat der nicht schon alles was man dafür bröchte?
Und mit etwa 25€ für ein fast Fertigen Knoten ist es noch ganz ok...

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, der eZ80F91 wäre vergleichbar (von dem, was er in einem Knoten an
Funktion abdeckt) mit einem uC (mind. 32kB Flash denke ich mal) und
einem Ethernet-Controller. Wenn man da einfach mal einen ATmega128 (ca
10€) und einen ENC28J60 (ca 6€) nimmt, ist man nur bei
16€ ... Das drum rum dürfte bei beiden Varianten etwa gleich
sein.

Autor: Uwe Stark (uwe_stark)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also erst mal vielen Dank für eure Antworten, aber jetzt bin ich genau
so schlau wie vorher.

@Matthias Beitz: Wenn bleib ich beim AVR der eZ80Acclaim  hat einen Z80
Core und das heist wieder umdenken und ich bin einer von den ATMEL Fans
;-). zu dem beschäftige ich mich mit den ARM von ATMEL.

Na mal sehen werde jetzt erst einmal den avrETH1 etwas anpassen oder
was eigenes entwickeln und ein paar versuche machen danach geht es
weiter mit POE und evtl. Funkmodulen für den Gartenbereich.

Gruß
Uwe

Autor: Matthias Beitz (vsn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der ENC28J60 hatte ich noch gar nicht gesehen das teil scheint sehr nett
zu sein leider nur 10MBit... Dann Blinken gar nicth alle lampen am
Switch aber naja für einen Hausbus recht es dicke und dreifach...
Gibt es dafür schon fertige Experimentierplatinen? In Software
entwickeln bin ich ja gut aber Routen in Eagel ist nicht so mein
fall... Auf alle fälle brauchen die Knoten dann PoE versorgung...

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry wenn ich da als Neuling etwas in die Diskussion reinplatze.
Ich habe auch mal über Ethernet zur Hausautomatisierung nachgedacht,
habe das aber wieder verworfen. Vielleicht lag ich ja falsch.

Ethernet ist ja eine Sterntopologie. In der Industrieelektronik geht
der Trend derzeit zu Bausteinen, die zwei Ethernet Konoten on Board
haben, so dass jeder Baustein quasi ein kleiner Switch ist. Damit kann
man dann lange Stränge bilden.

Aber so ein Konzept scheint ja hier niemand zu planen. Würde auch die
Kosten für einen Knoten deutlich hochtreiben, weil zwei komplette
Ethernet Anschlüsse benötigt würden.

Die Alternative wäre in jedes Zimmer einen eigenen Ethernet Strang mit
einem riesen zentralen Switch zu machen oder alternativ diverse
Unterswitches ?

Ich habe mal die Stromaufnahme meines Routers gemessen, der liegt bei
10W, was etwa 10 € Stromkosten im Jahr bedeutet. Von daher finde ich
die Lösung mit diversen Unterverteilern auf Dauer etwas teuer.

Gruss
Axel

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das was du da erwähnst sind so ziemlcih die 3 Hauptpunkte warum Ethernet
als Hausautomatisierungsbus ungeeignet ist.

1. Sternform. Benötigt unmassen an zusätzlichen Leitungen + riesen
Hub/Switch oder viele kleine Switches.

2. Kosten. Ethernet mit allem drum und dran ist atm wohl immer noch
(wenn auch nur geringfügig) teurer als andere Busse. Sowas macht sich
halt bemerkbar, wenn man >50 Knoten hat.

3. Strom. Sowohl Hubs/Switches ziehen da Strom, als auch die
Ethernet-Hardware auf den Knoten. Ich habe in einem Projekt von mir den
ENC28J60 im Einsatz, der zieht alleine etwa 150mA bei 5V also 0,75W.
Wenn man jetzt davon mal 50 Knoten hat, ist man auch schon wieder 37,5W
...

Auch die Implementierung einer geeigneten Ethernet-Software auf den
Knoten dürfte da eine ziemlich lange Zeit in Anspruch nehmen und als
minimal-uC (bei Atmel) den ATmega32 vorraussetzen...

Gruß,
Chris

Autor: Matthias Beitz (vsn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.beitz-online.de/catalog/product_info.ph...

Dort ist der ENC28J60 nun für 3,99€ verfügbar... Das spart dann noch
mal 2€...

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, also ich kann auch nicht sagen ob Ethernet zur Zeit die beste
Lösung ist. Vielleicht ist das gerade zur Zeit eher eine
Geschmacksfrage.

Aber ich habe mir den ganzen Thread durchgeleesen und wollte nur mal
ein Scenario erläutern was mir so in den Kopf kam:

-----

Also zunächst zu den Nodes. Es gibt einen Standartbaustein dieser hat
neben der Verbindung zum Ethernet zum Beispiel 8 Eingänge 8 Ausgänge.
Außerdem klept auf jedem dieser Bausteine ein Aufkleber mit seiner MAC.
Diese Bausteine werden einfach verbaut, an ihre Ein und Ausgänge werden
Scahlter und Lampen angeschlossen. Diese Bausteine sind erstmal ganz
dumm.

Wenn ich das System jetzt einschalte, wird nix passieren. Die
Standardmodule werden keine Daten im Ethernet verschicken. Doch jetzt
kann ich meinen Laptop an das Netzwerk anschließen und eine Software
starten. Diese sucht erstmal alle Standartmodule und zeigt sie mir in
einer Liste an. Jetzt kommt erst der Teil der nicht so viel Spaß macht,
mir aber später die Arbeit enorm erleichtert: Ich habe mir die
MAC-Addresse der Standartbausteine beim verbauen aufgeschrieben und
kann den einzelnen Modulen jetzt Namen verpassen (zB "Schlafzimmer").
Nun kann ich über die Software die Standartmodule vituell verschalten.
Rein Grafisch, ohne Programmierkenntnisse.

Hier als Beispiel: Mit den Schaltern an Modul A kann ich die Lampe an
Modul aus und einschalten. Mit den Schaltern an Eingang 1 der Module B
& C kann ich den Zustand der Lampe an jeweils umgehren (also an nach
aus und um geh kehrt ;) ) AUßerdem kann ich mit Modul C auch die zweite
Lampe steuern.



 +-------------+
 |   Modul A   |
 |             |
 |  Eingang 1  |-----------+
 |             |           |
 |  Eingang 2  |---------+ |
 |             |         | |
 | 1 |         |         | |
 | 0 } Aus 1   |         | |
 | T |         |         | |
 |             |         | |
 | 1 |         |         | |
 | 0 } Aus 2   |         | |
 | T |         |         | |
 +-------------+         | |
                         | |
 +-------------+         | |    +-------------+
 |   Modul B   |         | |    |   Modul D   |
 |             |         | |    |             |
 |  Eingang 1  |-----+   | |    |  Eingang 1  |
 |             |     |   | |    |             |
 |  Eingang 2  |     |   | |    |  Eingang 2  |
 |             |     |   | |    |             |
 | 1 |         |     |   | +--->| 1 |         |
 | 0 } Aus 1   |     |   +----->| 0 } Aus 1   |
 | T |         |     +--------->| T |         |
 |             |     |          |             |
 | 1 |         |     |          | 1 |         |
 | 0 } Aus 2   |     |          | 0 } Aus 2   |
 | T |         |     |    +---->| T |         |
 +-------------+     |    |     +-------------+
                     |    |
 +-------------+     |    |
 |   Modul C   |     |    |
 |             |     |    |
 |  Eingang 1  |-----+    |
 |             |          |
 |  Eingang 2  |--------- +
 |             |
 | 1 |         |
 | 0 } Aus 1   |
 | T |         |
 |             |
 | 1 |         |
 | 0 } Aus 2   |
 | T |         |
 +-------------+

Wenn ich fertig mit der Planung bin gibt die Software jedem Modul eine
kleine liste mit auf den Weg:

zB Modul C:

Ausgang 1 -> Sende T an Ausgang 1 von Modul D
Ausgang 2 -> Sende T an Ausgang 2 von Modul D

Für kompliziertere Dinge kann man immernoch ein kleines Modul als
Steuerzentrale anschließen, das kann dann Zeitgesteuert Lampen
einschalten, beim verlassen der Wohung die gesammte Stromversorgung in
der Küche ausschalten, oder auch als Webinterface dienen. Aber wenn es
ausfällt funktioniert immernoch die normale Lichtsteuerung.

Was die Kosten und den Stromverbrauch angeht müßte vielleicht ein
Kompromiss gefunden werden: Zum Beispiel sollte jedes Modul viele Ein
uns Ausgänge haben, so das hat nicht jeder Schalter ein eigenes Modul
haben muss sondern nur jedes Zimmer. Das würde natürlich auf Kosten der
verdratung gehen.

Wäre toll von euch zu hören was ihr davon denkt.

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du das Ganze auf CAN aufbaust und nur einen Adapter von CAN auf
Ethernet bastelst, kannst du das Gleiche erreichen, aber vermutlich um
einiges günstiger bei der Anschaffung und auch im Betrieb (Verbrauch).
Denn Ethernet ist für sowas eigentlich Overkill - erstens hast du sehr
umfangreiche Software, dann brauchst du mehr Bausteine die vermutlich
mehr Strom benötigen. Und dann brauchst du auch noch mehr Leitungen zu
den Knoten...

Autor: Uwe Stark (uwe_stark)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch die CAN brauchen Strom und das mit den mehr Leitungen stimmt nicht
ganz so wenn du eine CAT 5e Leitung nimmst ist ist die Leitung vom CAN
voll Belegt es sei den du nutzt nur einen Bruchteil des CAN. und mehr
Bausteine auch nicht unbedingt:
http://home.cogeco.ca/~hduff/EIO_Main.htm
das Board müsste nur etwas modernisiert werden, das mit der Software
wäre für mich auch kein Probelm als Progger und ein Server steht
sowieso bei mir im Büro das einzige was man zusätzlich bräuchte wäre
ein Hub oder ein Switch aber sowas wie ein zenralknoten brauchst du
auch beim CAN.

Also meine Entscheidung ist immer noch nicht gefallen, bin zwar auch im
Hausbusforum auf deiner Webseite aber CAN oder Ethernet weis ich immer
noch nicht.

Gruß
Uwe

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm ...

ich kenne mich mit CAN nicht so gut aus. Ich bin gerade am überlegen ob
es möglich wäre eine Platine zu entwerfen die je nach bestückung mit CAN
oder Ethernet abeitet. Gibt es denn ein aktives Projekt wo sowas schon
versucht wird?

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das Argument mit der Leitung, die von CAN belegt sein soll, kann
ich nicht teilen. CAN braucht 2 Drähte, wenn du noch die
Spannungsversorgung dazuschaltest hast du 4 - dann sind noch 4 frei,
die z.B. noch für Ethernet verwendet werden könnten.
Bei Ethernet hast du allein 4 Leitungen nur für Daten - ohne
Spannungsversorgung.
Dann brauchst du noch einen Switch/Hub, der wieder extra Strom braucht,
geschirmte Kabel, etc.

Einen zentralen Knoten braucht man bei CAN nicht, das ist der große
Vorteil.

Ich meine, es ist natürlich jedem selbst überlassen was er verwenden
möchte - aber ich brauch mir keinen Ferrari zu kaufen wenn ich eh nur
mit angezogener Handbremse in der 30'er Zone fahr... ;)

Knoten verschiedenster Art wird es bald bei uns geben - ein
Schaltknoten mit 16 Ausgängen und 4 Eingängen (erweiterbar) ist bereits
vom Layout her fertig, ein Unterputz-Schaltknoten auch. In Entwicklung
ist gerade ein USB-CAN Adapter sowie ein CAN-Ethernet-Adapter. Weitere
Sensoren und andere Knoten sind noch in Planung.

Ich hab momentan leider Prüfungszeit und kann mich dem Projekt deswegen
nicht voll widmen, aber Alloc und trick sind immer fleissig am
Entwickeln und in 4 Wochen werd ich auch wieder voll einsteigen können.
Aber wer an dem Projekt interessiert ist und mithelfen möchte, kann gern
einsteigen, dann geht das Ganze noch schneller...

Autor: Uwe Stark (uwe_stark)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe eben meine Entscheidung getroffen ich werde CAN einsetzen
und extra Leitungen legen da es zu beträchtlichen Störungen kommen
kann. Ich nutze das Ethernet unter anderem für Streaming (DBox2, PC) es
kann zu Störungen vor allem beim Aufnehmen kommen. Also werden jetzt
noch vorraussichtlich zwei Leitungen dazu kommen, eine für CAN und eine
für 12V oder 24V.

Gruß
Uwe

Autor: Florian Roether (florian__)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde die Idee gemeinsamm einen Hausbus zu entwickel sehr gut!
Anscheinend gibt es aber schon bei der verwendetet Übertragungshardware
(CAN/Ethernet) Meinungsverschiedenheiten. Dabei wäre das vielleicht
garnicht so entscheident, denn wenn man sich einen einzelnen Teilnehmer
von so einem Hausbus anschaut, dann Wäre sowohl auf der Hardwareseite
wie auch auf der Softwareseite vieles unabhängig vom Bus.


   Hardware Seite     Software Seite
+------------------+------------------+
|   Hardware der   |  Steuerung der   |
| Ein und Ausgänge | Ein und Ausgänge |
+------------------+------------------+
|                  |  Handhabung der  |
| Mikrocontroller  |   ein und aus-   |
|                  |  gehenden Daten  |
+------------------+------------------+
|  CAN / Ethernet  |  CAN / Ethernet  |
|   Controller     |      Logik       |
+------------------+------------------+

So könnte der Hard und Softwareteil der bei beiden verfahren zum
Einsatz kommt von beiden verfechtern entwickelt werden, und der
sezielle CAN/Ethernet-Teil von den jeweiligen Gruppen. Eine Platine die
je nach Bestückung an einem CAN-Bus oder am Ethernet hängt, würde auch
die Kosten pro Stück drücken. Und vielleicht könnte man sogar ein Modul
bauen, sodas man zwischen CAN und Ethernet vermitteln kann, ohne das die
Teilnehmer davon überhaupt was merken. Dann könnte auch ein
CAN-Verfechter zwei CAN-Sub-Netze über Ethernet verbinden, oder
umgekehrt.

Autor: Uwe Stark (uwe_stark)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autsch, Florian ganz so einfach ist das nicht. Mal abgesehen davon das
CAN ein ganz eigenes Protokoll hat so sieht es bei Ethernet schon mal
ganz anders aus, dort gibt es gleich mehrere Protokolle (TCP/IP, UDP,
FTP, u.s.w.). Also verbinden so wie du dir das vorstellst ist nicht, du
kannst zwar das CAN Modul über eine CAN<>PC Schnittstelle mit einer
Software auf dem PC Steuern aber beide Netze nicht miteinander
verbinden.
Packetaufbau beim
CAN:http://vvl.fh-reutlingen.de/cocoon/my/vvl/vvl?lang...

Gruß
Uwe

Autor: Florian Roether (florian__)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erst mal für den Link. Wenn ich es richtig verstanden habe gibt es
doch auch bei CAN-Nachrichten ein art Zeiladresse oder? Bis zu 128
Teilnehmer?

Wenn es so ist hätte ich noch die Frage wie diese Zieladresse
ausgehandelt wird. Oder stellt man die schon vorher ein?

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CAN arbeitet im Gegensatz zum Ethernet mit Nachrichten-IDs, nicht mit
Adressen.

Teilnehmer kannst du im Prinzip beliebig viele haben, lediglich
begrenzt durch die Buslänge und die Treiberfähigkeit der Bausteine
(eben die ca. 128)

Nachrichten-IDs gibts aber 536870912 (2^29), wie viele Bausteine auf
eine Nachricht hören ist nicht festgelegt.

Das Problem bei der Kombination seh ich im Platzbedarf - beides nach
Bedarf zu bestücken wäre toll, aber in ner UP-Dose is verdammt wenig
Platz...

Autor: Uwe Stark (uwe_stark)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie ich oben schon geschrieben habe kann es zu Störungen kommen das
liegt ganz einfach daran das z.b. ein CAN Modul eine Anfrage sendet
diese Anfrage geht erst einmal an alle Module wenn dann ein Modul
erkennt das es gemeint ist sendet dieses wieder eine bestätigung an den
Absender damit dieser gewißheit hat das, daß Modul noch da ist und die
Nachricht auch empfangen kann erst dann wird die Nachricht gesendet.
Aber mal davon abgesehen kann man anhand der ID's den Modulen
Prioritäten zuordnen.

Gruß
Uwe

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> diese Anfrage geht erst einmal an alle Module wenn dann ein Modul
> erkennt das es gemeint ist sendet dieses wieder eine bestätigung an
> den Absender
Wenn du damit den Acknowledge-Mechanismus beschreiben wolltest (den
jeder CAN-Controller automatisch verwendet), dann trifft das so nicht
zu. Es sendet JEDER Knoten ein Ack, wenn er die formale Richtigkeit des
CAN-Telegrammes erkannt hat - egal ob er sich für das Telegramm
interessiert oder nicht.
Wenn du eine höhere (Applikations-) Schicht beschreiben wolltest, oder
deine Umsetzung, dann kann man das natürlich so machen.

Hier gibt es immer wieder viele Missverständnisse wenn das Thema CAN
aufs Tablett kommt...

Und was du mit den Störungen meinst, habe ich nicht verstanden.

Autor: Uwe Stark (uwe_stark)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da durch die Ethernetmodule relativ viel Traffic erzeugt werden kann,
können Störungen beim Streamen oder beim Telefonieren (Voice over IP)
entstehen. Mit dem ACK hast du natürlich Recht, wo hatte ich nur wieder
meinen Kopf ;-). Bei mir kommen Ethernet (Streamen,Voice Over IP,
Kameras), CAN (Steuerung und Sensoren), 230V (Licht und Steckdosen), 24
/ 12 V (Reserve Module, Rolladen-motor, Heizungsthermostat, u.s.w.)
getrennt in die Wand und der CAN über ein Interface an den PC um Ihn
Überwachen zu können ich kann mir Später mal vorstellen das ganze über
einen Server mit anderen Rechnern oder einem PDA steuern zu können (C#
mit Webservices).

Gruß
Uwe

Autor: Florian Roether (florian__)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es den möglich über den CAN-Bus die einzelnen Nodes zu
programmieren? Kann ich also bei einem Hausbus die einzelnen Nodes dann
virtuell verschalten?

Gruß
Flo

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei unserem Projekt ja - sofern es natürlich soweit ist.

Die Software zeigt alle Nodes an und du kannst ihnen dann Aufgaben
zuteil werden lassen und evtl. kleine Makros ablaufen lassen. Die
Einstellungen werden dann natürlich in den Knoten gespeichert und sind
unabhängig vom PC, dieser wird nur zur Konfiguration und Überwachung
benötigt.

Autor: Florian Roether (florian__)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mir bei eurem Projekt aufgefallen ist: Ihr habt eine riesen Liste an
verschiedenen Knoten. Warum entwerft ihr nicht erstmal einen Knoten der
ein paar Ein- und Ausgänge hat und mit dem man schon viel machen kann.
Den könnte man dann weiter entwickeln und optimieren bevor man sich
weitere Knoten ausdenkt.

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Liste ist hauptsächlich eine Ideensammlung, was möglich wäre. Ob und
welche davon realisiert werden, hängt dann davon ab, was sinnvoll ist,
was benötigt wird etc.

Ein einfacher Knoten mit ein paar Ein-/Ausgängen ist in Entwicklung,
und zwar zum einen ein Taster-Knoten für die Unterputzmontage sowie ein
Schaltknoten für die Hutschienenmontage. Der Hutschienenknoten ist
beispielsweise mit 4 Eingängen und 16 Ausgängen ausgestattet und um
weitere Ein-/Ausgänge erweiterbar.

Die beiden genannten Knoten werden natürlich zuerst fertig entwickelt
und getestet bevor spezielle Knoten drankommen, aber ein gewisser
Ausblick ist nie schlecht, beim Tunnelblick übersieht man oft wichtige
Details, die einem später das Leben schwer machen.

Beispielsweise sollte ich für das Protokoll wissen, welche Daten
irgendwann mal übermittelt werden müssen...

Autor: elwls@yahoo.com (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brilliant. Freaking brilliant. Ian Schwartz.

Autor: Garry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man das ganze nicht einfach als Can over Ethernet "entwerfen"
oder übersehe ich dabei etwas? Die meisten dürften ja keine aufwendige
Regelaufgaben mit viel Traffic haben sondern ab und zu mal ein Licht
schalten, Rollladen betätigen,...

Wenn man das ganze komplett in Can macht hat man doch etwas sehr
spezielles - entscheidet man sich dann in wenigen Jahren doch für ein
anderes System weil z.B. EIB spotbillig wurde hat man einen Bus liegen
der schwer umzurüsten ist. Ethernet ist dagegen ein MAssenprodukt für
das es sicher in vielen Jahren auch noch Komponenten geben wird und
sich somit einfach weiterverwenden lässt.

Garry

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@garry: ach und wenn CAT7-Leitung liegt als CanBusLeitung kann man nicht
auf EIB umrüsten? Das sehe ich aber anders....

greetz
Danny

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.