www.mikrocontroller.net

Forum: Haus & Smart Home Hausbus


Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe vor, unsere Hauselektrik mit einem Hausbus zu steuern. Ich bin
mir nur nicht sicher, welches Bussystem ich verwenden soll. Im
Augenblick habe ich mir EIB, CAN und RS485 näher angeschaut und mal die
Vor- und Nachteile zusammengefasst:

EIB
  + nur 2 Leitungen für Daten, Power und GND
  + kein Abschluss-R nötig, alle Bustopologien
  - Chips nur schwer erhältlich und teuer

CAN
  + Protokoll bereits im Chip
  O Preis ist ausgewogen
  - es werden 2 Leitungen Daten + Power + GND benötigt
  - Abzweigungen vom Bus sind problematisch (max. 1m?)
  - abschluss-R notwendig

RS485
  + Preis ist spottbillig
  O Protokoll muss angepasst werden (ander Bsp. vorhanden)
  - es werden 2 Leitungen Daten + Power + GND benötigt
  - Abzweige vom Bus (Baum) sind problematisch
  - Abschluss-R notwendig

Kennt jemand noch andere Systeme, die infrage kommen würden? Was ich
besonders schön fände, wenn nur eine 2-adrige Leitung verwendet wird.
Die Zerstörungsfestigkeit gegenüber induzierten Spannungen etc.
(Blitzschlag) steht natürlich auch ganz oben.

Kennt jemand Open-Hardware-Projekte in der Richtung? Alles, was ich bis
jetzt gefunden habe, scheint den Schreibtisch noch nicht so recht
verlassen zu haben.

Haben auch andere an sowas Interesse?

Viele Grüße, Stefan

Autor: Malve (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie siehts aus mit einem I2C-Bus?
Der benötigt soviel ich weiss nur 2 Leitungen, allerdings kann ich
nicht sagen, ob er sich für Deine Applikation sonst eignet.

Mfg

Malve

Autor: Marcus Maul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

schau Dir mal bitte Powernet an.
Das funktioniert über die normale Stromleitung, d.h. keine zusätzlichen
Adern. Allerdings sind die dazu passenden Module relativ teuer und Du
mußt die Dei Phasen koppeln.

Ich hab dasSystem bisher nur in der theorie gesehen. Soll vom Aufbau
der RS485 ähneln.

Google mal, vielleicht gibts da noch irgendwo bessere Info's, als den
spärlichen Kram, den ich hier habe.

Gruß Marcus

Autor: ERDI - Soft (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was heißt bei dir Elektrik steuern? Licht an/aus, Rolladen
hoch/runter???
In diesem Fall kannst du schon CAN-Bus nehmen, den Saft holst du dir
dann jedesmal vom Netz. (Sollte ja eigentlich an jedem Knotenpunkt
vorhanden sein, da da ja was gesteuert werden soll.)
CAN dürfte auch das einfachste sein, da du dich um fast nichts kümmern
brauchst. Die CAN-Bausteine (z.B. SJA1000) übernehmen die komplette
Arbeit, der Controller braucht im Prinzip nur noch Daten lesen oder
schreiben.
Du könntest auch ne kombinierte Bustopologie einsetzen. CAN bis zu den
Knotenpunkten, und von den Knotenpunkten zum Anwendungspunkt mit RS232
oder ähnlichem.

Auf dieser Seite unter Links sollte irgendwo bei den AVR ein Link auf
ne schöne Site sein, die sehr gut nen Aufbau solch eines Homebusses mit
CAN beschreibt.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Malve:
IIC ist für Busanwendungen etwas zu störanfällig, eigendlich ist IIC
nur als interner Gerätebus gedacht und für kleine Entfernungen. Es
werden ja auch keine Treiber verwendet, die die Elektronik vor Spikes
etc. schützen können.

@Marcus:
Powernet habe ich mir schon angeschaut, aber was mich daran stört, ist
eben die direkte Kopplung mit dem Netz. Eigendlich brauche ich die
Netzspannung an den meisten Punkten ja garnicht, Lichtschalter,
Sensoren kommen ohne aus, und die Leistung wird im Schaltschrank
geschaltet und geht direkt an die Verbraucher. Deshalb ist Powernet mir
zu teuer und auch zu gefährlcih (Netzspg nur da wo ich sie unbedingt
brauche).

@Erdi-Soft:
Genau das und etwas mehr, aber alles im niedrigen Datenmengen-Bereich:,
Licht an/aus, Jalousie, Raum-Thermostat, Raumheizungsventile, Dimmer,
Sensor Fenster auf/zu  ... und was mir später noch alles so einfällt.
Du meinst sicher den Link canathome.de? Genau der sieht so aus, als ob
er noch nie den Schreibtisch verlassen hätte ...

Mein Ziel ist eigendlich, einen Bus einzusetzen, dessen Teilnehmer so
günstig herzustellen sind, dass ich auch einen richtigen Bus aufbauen
kann (der auch zu finanzieren ist). D.h. an jedem Taster, Sensor etc.
steckt ein eigener intelligenter Busknoten. Bei EIB sind einzelnen
Busknoten so teuer, dass in der Praxis kein richtiger Bus gebaut wird,
sondern an einzelnen Stellen zentrale Busknoten platziert werden, zu
denen dann die Eingangssignale hinverkabelt werden.

Der CAN-Bus ist ja schon unter den Favoriten. Nur die eingeschränkte
Topologie schreckt mich etwas ab. Die Stromversorgung soll für den Bus
zentral vom Schaltschrank aus erfolgen, weil ich bei (fast) allen
Busanschlüssen keinen Stromanschluss habe und brauche.

@Michael:
Danke für die Links. Den unteren kannte ich noch nicht, da ist
interessant, dass für den AVR der CAN-Bus in Software emuliert wird.
Das macht das Ganze natürlich sehr interessant, weil preiswert.
Und jetzt weiss ich auch endlich, was Programmierstecker auf
italienisch heisst :-))

Viele Grüße, Stefan

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fällt mir noch der Bus a la digitale Modellbahn ein, relativ simpel, nur
2 Adern, allerdings kein direkter Rückkanal. Baum, Ring, Stern, auch
gemischt sind kein Problem. Datenrate ist relativ niedrig, aber das
sollte ja kein Problem sein.

Autor: ulrich strobel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sagt dir der ASI bus von Siemens etwas? der benötigt nur +24V und GND.
Auf den 24V werden dann die Datensignale aufmoduliert, der Bus
Funktioniert bidirektional. google doch ein wenig, habe mal tolle
knowhow-sites darüber gelesen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm doch einfach 4 Drähte (GND, +24V, CANL, CANH).
Die CAN-Treiber (PCA82C250) vertragen bis 5V Spannungsverschiebung.
D.h. selbst wenn auf dem GND-Draht 5V abfallen, ist immer noch eine
einwandfreie Detenübertragung gewärleistet.


Wenns aber unbedingt nur 2 Drähte sein sollen, wäre der Meterbus eine
Möglichkeit:

http://www.nzr.de/all-mbus.pdf

Die Übertragung erfolgt vom Master durch Spannungsabsenkung (24V/12V)
und vom Slave durch Stromerhöhung, ist also Voll-Duplex.


Peter

Autor: Bernhard Koopmeiners (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hausbusfreaks,
wie Peter schon sagt, "GND +24V CANL CANH". Die Knoten werden mit
billiger Telefonleitung versorgt. Ein Can-Treiber z.B.PCA82C251 (1,20€)
ein Mega8 und ein wenig "Hühnerfutter"; das Knotenbasismodul steht.
Aktormodul mit Relaise und Sensormodul mit Tastern, Thermometer usw.
ausstatten. Protokoll ausdenken. Programmieren. 1 Jahr Fehler
beseitigen. Schon läuft das Haus vollautomatisch. Anschließend
EasyToWeb-Server kaufen und von der Arbeit aus das Haus beobachten.

Bis auf den Webserver hat das alles den Schreibtisch bereits
verlassen...

Also Mut und ran. Sollte das passende Haus noch gebaut werden Leerrohre
nicht vergessen.

Bernhard

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn sowieso ein Schaltschrank vorhanden ist, kann mans auch zentral
machen und auf Bus verzichten (ausgenommen einen
Schaltschrankinternen). Die Erweiterungsmöglichkeiten sind halt nicht
so prall, aber ich habe diese Methode benutzt und man ändert bei weitem
nicht mehr so viel an der Grundinstallation, wie man zunächst annimmt.
Die Frage ist, ob ein Lichtschalter überhaupt "Intelligenz" braucht
oder ob es nicht reicht, eine 2-adrige Niedervoltleitung in den
Schaltschrank zu legen. Natürlich ist ein Bus eleganter - aber auch
teurer, und wenn mal ein Knoten verrückt spielt, kann man sich im
ungünstigsten Fall einen Wolf suchen, bis man das faule Glied gefunden
hat.
Auch eine nette Sache: IR-Fernbedienung von Licht und Steckdosen. IR
habe ich deshalb verwendet, weil dann jeder Raum seine eigene Belegung
auf der Fernbedienung haben kann - bei Funk würden schnell die Tasten
ausgehen, weil man Raumübergreifend ansteuern würde.
Die Powerline-Übertragung ist dann sinnvoll, wenn die Installation
bereits besteht und man nur schlecht Steuerleitungen zusätzlich
verlegen kann. Ich benutze hierfür den TDA5051, der manierlich
funktioniert und habe gute Erfahrungen damit gemacht.
Man sollte es auch nicht übertreiben mit den Spezifikationen, man
braucht sicherlich keine Übertragungsraten im mehrere 10 Kbit-Bereich,
denn wie oft wird schon ein Lichtschalter geschaltet?
In meiner Steuerung arbeite ich mit einem festen Zeitraster von 1/10
Sekunde, dies ist die Verzögerung von Lichtschalter drücken bis Licht
an - nach anfänglichen Bedenken fällt das garnicht auf, wenn mans nicht
weiß.
Bei einer totalen Neuinstallation einer Wohnung würde ich die
Verwendung von Leerrohren empfehlen. Die Kosten sind zwar höher, aber
ich habe es nicht bereut - es fängt schon an mit einer "vergessenen"
TV-Leitung bis hin zu zukünftigen Glasfaserleitungen fürs Internet.

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> canathome.de? Genau der sieht so aus, als ob er noch nie den
Schreibtisch verlassen hätte ...

Hm, da hab ich aber anderes gehört. ;)
Die Webseite ist zwar nicht auf dem aktuellsten Stand, dennoch
funktioniert die Hardware seit ca.2 Jahren in eingebauten Zustand
fehlerfrei (bis auf das 8515-Eeprom-Brownoutproblem).
Den SAE81C90/91 würde ich zwar nicht mehr empfehlen, da nicht/schlecht
lieferbar, dafür einen µC mit integriertem CAN einsetzen. Ich bastle
gerade für die nächste Version an Motorola HCS12. Das soll dann in
einem Neubau eingebaut werden und dort "alles" steuern.

Zu deinem Topologieproblem:
Wenn du 8pol. CAT5-Kabel zur Vernetzung einsetzt, kannst du (neben
Versorgungsspannung) auch CANL/CANH mit 2 Adern hin und mit 2 Adern
wieder zurückführen. Der letzte Knoten in der Kette brückt den CAN-Bus
wieder zurück - damit entstehen keine Stichleitungen. So kannst du
geometrisch auch einen Baum aufbauen, der logisch eine Linie ist...

Tschüß,
 André.

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

@ulrich: ASI Bus ist zwar schon irgendwie klasse, aber nicht so
wirklich trivial, und meines wissens sind die Komponenten nicht
wirklich billig, ausserdem ist das doch meher zur Ueberwachung gedacht,
oder....

CAN mit wenig laengeren Stichleitungen sollte funktionieren, wenn es
nicht zu viele werden, sonst werden es etwas viele
Abschlusswiderstaende. Wenn die Baudrate niedrig ist, sollte man auch
bei mittleren Stichleitungslaengen auf Abschlusswiderstaende verzichten
koennen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es zwingt einen ja keiner, den CAN immer mit 1MBit zu fahren und z.B.
bei 10kBit sieht alles schon viel unkritischer aus.

Mann könnte auch, wie bei Modems mit kleiner Bitrate anfangen und dann
testen, wie hoch man ohne Fehler kommt.

Die CAN-Controller haben ja interne Errorcounter, mit denen man gut die
Qualität der Übertragung ermitteln kann.



Kostenmäßig ist ein T89C51CC01 + PCA80C251 auch nicht teurer als ein
guter Lichtschalter (20Euro).

Der PCA80C251 kann bis 40V ab, wenn man mal beim Installieren die +24V
mit CANL oder CANH vertauscht, passiert also nichts.


Peter

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von Microchip gibt es auch CAN-Controller, die sich per SPI an den Atmel
anklemmen lassen - für die, die bei ihrem AVR bleiben wollen. Die
ältere Version gibt es bei Segor für ca. 6 Euro.
Ausserdem hat Microchip noch CAN-I/O-Expander, die standalone laufen
und I/O, A/D, sowie PWM-Ports bieten und gar keinen Controller mehr
brauchen. Besonders ideal für solche Sachen wie Lichtschalter,
Sensoren, etc.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal danke für die vielen Antworten. Da komme ich ja fast nicht mehr
nach mit lesen und Links anschauen :-))

Also erstmal die Baudrate - da habe ich auch an ca. 10kbit gedacht. Ist
für einen Hausbus sicher voll ausreichend, wenn man mal Video auf dem
Lichtschalter-Display schauen will, kann man immer noch aufrüsten ;-)

So wie es aussieht, plädiert ja eine überwältigende Mehrheit für den
CAN-Bus? Bis jetzt war ich ja eher RS485-Fan, weil ich es von DMX noch
in guter Erinnerung habe. Aber nachdem es für CAN sogar eine
Software-Emulation gibt und RS485 von der Topologie auch nicht besser
ist, bin ich bereits am Umdenken.

Welcher Controller am Schluss eingesetzt wird, kann ja noch entschieden
werden. ATmega8 mit CAN-Emulation könnte ich halt über die Arbeit sehr
günstig bekommen (aber nur im Ultra-Mini-Gehäuse). Wichtig ist für
mich, dass kein externer Baustein verwendet wird, also im mc
integriertes CAN oder Software-Emu. Ich werde mir mal die
vorgeschlagene CAN-Controller ansehen.

Der ASI-Bus sieht recht interessant aus, allerdings erlaubt er keine
variablen Daten, sondern überträgt nur digitale und analoge Zustände.
Das wäre zwar bei den meisten Haus-Anwendungen ausreichend, aber um
z.B. Text auf ein Info-Display zu bekommen, wären schon Klimmzüge
notwendig. Und leider ist er nicht Multi-Master-fähig. Was aber extrem
genial ist, ist die supereinfache Kabelanklemmung. Einfach durch die
Isolierung anklemmen und verpolsicher durch asymetrische
Kabel-Außenform - da haben sich die Entwickler wirklich was gedacht.

Meine Überlegungen gehen mittlerweile in folgedne Richtung:

Als Bus CAN verwenden.
Den Bus nach Möglichkeit geradelinig ausführen. Wo das nicht geht, kann
ev. ein Dual-CAN-Controller eine Abzweigung realisieren. Die Baudrate
wird erstmal mit 10kbit angenommen.
Die Intelligenz dezentral verteilen, d.h. die Kommunikation läuft nicht
über eine zentrale Schaltstelle, sondern z.B. ein Lichtschalter
kommuniziert mit seinem Aktor direkt. Damit fällt nicht das gesamte
System aus, wenn die Zentrale hinüber (oder abgestürzt ...) ist.
Beim Software-Protokoll werde ich mir mal Caraca und CANatHome genauer
anschauen und nach Möglichkeit mit einem der beiden kompatibel
bleiben.
Die Aktoren will ich nicht bis auf 220V-Ebene selberbauen, sondern
Schaltschrank-Relais oder Dimmer (0..10V) ansteuern. Die gibt es so
günstig, dss sich Selbstbau sicher nicht lohnt, und es gibt auch
weniger Probleme mit dem Elektriker, wenn Bus und Netz voneinander
getrennt gehalten werden.

Viele Grüße, Stefan

Autor: Bernhard Koopmeiners (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais
Du hast nicht unbedingt unrecht, dass eine zentrale Steuerung auch
einige gute Seiten hat. Wenn ich aber überlege, dass in einem
Reihenhaus im Normalfall mindestens 3 Etagen zu überwinden sind, dann
stellt sich die Frage, wieviel Leitungen Du verlegen willst. Ein großer
Vorteil eines Hausbusses liegt doch in der Tatsache, dass ich mit
verteilter Intelligenz Leitungen spare. Mir kostet ein Schaltermodul
incl. professioneller Platinen, Bauteilen usw. 18,50 Euro. Damit kann
man 10 Sensoren ( davon bis 4 analoge Eingänge ) in den Bus einspeisen.
Desweiteren nimmt das Modul die IR-Signale meiner Fernbedienung auf.
Dafür lege ich ein 4 adriges Telefonkabel zum Sicherungskasten und
nicht mehr. Eine Raumtemperatur erfasse ich z.B. mit einem
Spannungsteiler aus einem temperaturabhängien Widerstand. Da die
Busgeschwindigkeit mit 10 KBit sehr niedrig ist und die meisten Events
keine Daten transportieren müssen, liegt die Übertragungszeit bei ca. 6
ms und die maximale Leitungslänge weit über 1000m. Auch eine
Sternverdrahtung mit Abschlußwiderständen im Mittelpunkt führen zu
keinen Problemen.
Highlight (m)eines Busses ist aber eindeutig die Flexibilität und
Erweiterbarkeit.

Bernhard

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sicher gibt es Vor- und Nachteile. In meinem speziellen Fall habe ich
die zentrale Steuerung verwendet (auch weil ichs nicht besser wußte,
ist jetzt an die 5 Jahre her). Ich habe auch niemals die Vorteile des
Bussystems bezweifelt, das ist jetzt vielleicht etwas schlecht
herübergekommen. Erweiterungen, die nun garnicht mehr bei mir
reinpassen, habe ich mit dem Powerline-Bus gemacht.
Wenn ichs nochmal machen müßte, würde ich wahrscheinlich auch eher zum
CAN hintendieren, aber: Don't touch running systems. Bis jetzt 1
Ausfall, und der war aus eigener Schuld, weil ich die Prüfsumme des
EPROM nicht aktualisiert hatte - nach einem Stromausfall wurde die
überprüft, und das System startete aus Sicherheitsgründen nicht mehr.

Autor: womisa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

um die Diskusion zu erweitern, was haltet Ihr vom LIN-Bus?
Dieser wird auch immer wieder mit CAN verglichen. Der ist fürs Auto als
zukünftiger Standard gedacht un wird somit hoffentlich (?) billig.
Mal zu googeln lohnt (?) sich ????

MfG Achim

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Achim:
Hast Du das jetzt nur durch Zufall gelesen?
LIN ist für die Haussteuerung völlig unbrauchbar. Das ist ein
unsymmetrischer Bus in Multidroptechnologie mit bis zu 16
Knotenpunkten.
Gedacht für preisgünstige KFZ-Anwendungen bei niedrigen Datenraten,
sprich Knöppe und Hebel.
Und nur Legastheniker vergleichen das mit dem CAN. Denn das ist nämlich
völlig unabhängig vom CAN und erstzt das nur in den genannten
Köppen-Anwendungen. Für etwas anderes taugt das nicht. Im KFZ werden
deshalb CAN-LIN-Gateways ihren Dienst tun, um zwischen dem lahmen LIN
und den schnellen Steuerungen zu vermitteln.
Hättest Du aber bei Deinem googlen selber rausfinden können...

Autor: Karl-Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab nicht alle Beiträge gelesen, aber trozdem noch ein tipp:

in der Fabrikautomation wird häufig AS-Interface verwendet. Im
Protokoll sind 4 datenbits enthalten (sollten nach meiner
Vorstellungskraft für Haustechnik ausreichen). ASi kommt auch ohne
Abschlusswiderstand aus und hat nur zwei Leitungen. Max. leitungslänge
beträgt 100m. die Leitungslänge kann theoretisch erhöht werden wenn
trotzdem Abschlusswiderstände verwendet werden, aber bis 100m laut
Spezifikation nicht erforderlich. Besonderes AS-I Netzteil ist
erforderlich damit nicht die aufmodulierten Daten von dem
zweidrahtsystem durch das innenleben des Netzteils geschluckt werden.
Oder ein einfacher Filter (RC) vor ein herkömmliches netzteil bauen.
Klappt einwandfrei.

Preis keine Ahnung.

Gruß

Karl-heinz.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andre:
Da bin ich ja schön ins Fettnäpchen getappt - sorry. Ich bin halt nach
den Bildern gegangen und die sehen eben nach Schreibtisch aus -
jedenfalls die ersten ..
Warum bist Du denn vom Fujitsu-Controller weg und willst jetzt auf den
HC12? Aus Bastelwut oder warst Du mit dem Fujitsu nicht zufrieden?

Ich habe früher viel mit dem 68HC11 gemacht und war damit eigendlich
sehr zufrieden, später hat dann Motorola den Flash-Speicher etwas
verschlafen. Aber der HC12 sieht ziemlich gut aus, für den Hausbus
eigendlich ideal, kleines Gehäuse, CAN, EEPROM, der Preis scheint sich
auch im Rahmen zu bewegen. Taugt denn der gcc-Port dafür was?

Mit der CAN-Rückleitung hast Du natürlich Recht. So macht das auch die
Implementierung bei Caraca (Sourceforge). Aber dann sind es ja noch
mehr Adern. Was hälst Du von einer Abzweigung durch einen 2.CAN-Bus
onboard?

Ich werde jetzt erstmal das Sotware-Protokoll auf Deiner Seite genauer
studieren. Hast Du Dich da an andere Projekte angelehnt?

Viele Grüße, Stefan

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan: Die ersten Bilder sind vom Demobrettaufbau... später im
Einbauzustand hab ich keine Fotos gemacht.
Fujitsu war lange nicht lieferbar (zig Wochen)... ich wurde ewig vom
Distri hingehalten - mir reichte es dann. Technisch gesehen ist der
Fujitsu ok.
AVR hab ich verlassen, da damals der SAE81C90/91 nur schlecht lieferbar
war und die Kombination aus µC und ext.CAN-Hardware kostenmäßig nicht
soo optimal war, außerdem wollte ich mal ne andere µC-Familie
kennenlernen.
Den HCS12 setzen wir auch in der Firma ein - d.h. die komplette
Toolkette steht mir zur Verfügung. Preislich gesehen geben sich die 3
Lösungen nicht viel.

> kleines Gehäuse
naja, zu TQFP-112 würde ich das nicht sagen wollen ;) (ok, gibts auch
in 80pol.) - zumindest IO-Port-Sorgen gibts damit nicht mehr.

Den GCC-Port kenne ich nicht näher. Ich benutze die kostenlose 12k
Version des Metrowerks Compilers.

> Aber dann sind es ja noch mehr Adern
Ja, genau 2 mehr.

> Sotware-Protokoll auf Deiner Seite
Zur Info: Ich verwende die CanId (entgegen ihrer eigentlichen
Intention) als Zieladresse und nicht als Ereignisanzeiger bzw.
Absende(r)kennung. Das gibt Probleme, sobald 2 Sender _zeitgleich_
(also innerhalb einer Bitzeit; bei 10kBit/s sind das 100µs) die
gleiche CanId auf den Bus schreiben... praktisch stört das sicher
nicht - theoretisch aber unsauber. In der neuen Fassung ist alles
besser... Update der Webseite kommt vielleicht noch in 2004.

> Hast Du Dich da an andere Projekte angelehnt?
Bewusst nicht, um zu sehen wie weit man mit eigenen Ideen kommt...
Inzwischen sieht die Sache anders aus.

Von SoftwareCAN halte ich nix. IMHO kann man das mit "USB in
Software" vergleichen - Riesenaufwand mit vielen potentiellen
Stolperfallen. Besser gefällt mir die Idee auf RS485 ein eigenes
Protokoll aufzusetzen.

ASi ist elektrisch gesehen sicher für Hausinstallationen geeignet.
Praktisch gibts aber keine Transceiver zu bezahlbaren Preisen
(zumindest sind mir keine bekannt). Das Protokoll läßt praktisch nicht
zu, damit anderes als nur Relais/Taster zu schalten und Analogwerte zu
übertragen - ist auch nicht für mehr gedacht. (Mein letzter Stand ASi
v2.1). Man "könnte" auf dieser Hardwarebasis allerdings eigene
Protokolle aufsetzen.

Für LIN gilt im Prinzip das gleiche wie für ASi - allerdings gibts hier
Transceiver zu günstigen Preisen (z.B. TJA1020) - leider nicht bei
Reichelt. Diese lassen sich einfach an die UART eines billigen µCs
anbinden - eigenes Protokoll und fertig.

Beide (ASi und LIN) haben aber den Nachteil nicht als Multimasterbus
ausgelegt zu sein - im Gegensatz zum guten alten RS485.

Zu den Preisen des nackten µC kommen noch Platine und Gehäuse hinzu -
damit fällt die Differenz zwischen ATmega8 und RS485 gegenüber µC mit
integr.CAN-Interface nicht mehr so stark ins Gewicht.

Gruß,
 André.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

freut mich, dass Du inzwischen intensiver und wohlwollender über den
CAN nachdenkst. Kein Wunder eigentlich - bei den vielen Empfehlungen
pro CAN in diesem Thread. Ich hatte Dir ja schon vor Wochen vom CAN
vorgeschwärmt... Du erinnerst Dich? Es ging dabei (auch) um den
ETA-Kessel ;-)

So klein ist die Welt, das Internet ist doch ein Dorf...

Für andere Interessierte: ETA hat nix mit Spanien zu tun. Eher mit
Österreich - zwar mit Feuer, aber nix mit Bomben. Mit Feuer im
Heizkessel.

Übrigens Stefan: Heute haben bei uns die Bagger die Baugrube
ausgehoben. Wenn ich mir das so anschaue, mit wieviel Gefühl die
Baggerfahrer mit diesen Riesenmaschinen auf den Zentimeter genau
arbeiten... Hut ab bei den vielen Hebeln die sie dabei gleichzeitig zu
bedienen haben. Da ist's doch einfacher mit ein paar Interrupts
umzugehen...

Auch ich werde den CAN als Hausbus einsetzen. Die 10 od. 20 kBit/s sind
für diese Anwendung eh schnell genug und bzgl. der Verkabelungsstruktur
ist der CAN bei diesen Bitraten nicht so empfindlich. Aufgrund
www.canathome.de bin auch ich auf die Fujitsu-Controller aufmerksam
geworden. Breite Palette mit CAN. Kostenlose Entwicklungsumgebung.
Bisher habe ich nur mal eine "Machbarkeitsstudie" programmiert -
funktioniert einwandfrei. Zumindest nachdem ich die meisten meiner
SW-Fehler raus habe ;-)

viele Grüße
Wolfgang

Autor: Peter Fleury (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benutzt ihr separate Leerrohre für den CAN Bus oder kann/darf man diese
CAN-Bus Leitungen im selben Leerrohr wie die Licht-Drähte legen ?

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@André:
Sollte ich mich da verguckt haben oder gibt es den HCS12 nicht auch im
48-Pin-Gehäuse? Auf der Motorola-Seite ist er dann mit 4,70$ angegeben,
gut, bei 1000 Stück, ich bräuchte eigendlich 5 weniger.

http://www.elektronikladen.de/en_chips12.html

Mehr Pins stören doch eigendlich nur beim Löten und brauchen Platz, für
die Applikation reicht so ein kleiner doch. Wie debuggst Du den HC12?
Der BDM-Anschluss scheint ja ziemlich klasse zu sein, benutzt Du den?

@Wolfgang:
Willkommen im mc-Forum :-))
Wir sind leider noch nicht so weit wie Ihr, bevor die Bagger kommen,
muss das Landratsamt noch eine Unterschrift leisten, scheint wesentlich
mehr Arbeit zu sein als so ne popelige Grube ...
Mit dem CAN hast Du wohl Recht gehabt. Obwohl ich es <theoretisch>
immer noch nur als die zweitbeste Lösung halte. Eigendlich wäre EIB
noch besser, aber da mauern mir die Hersteller zuviel.

Ich schaue mich gerade bei den CAN-MCs um. Der HCS12 sieht ziemlich gut
aus, oder der Mitsubishi M16C, mit dem habe ich schon etwas gearbeitet,
wenn auch nicht mit CAN. Und der HCS12 ist ja sehr verwandt mit dem
HC11, den habe ich früher benutzt. Der Fujitsu kommt eher weniger
infrage, ich will mich einfach nicht mit nochmal einer neuen CPU
beschäftigen.

Viele Grüße, Stefan

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
Ich habe vor, den Bus komplett separat von der Netz-Elektrik aufzubauen
und nur im Schaltschrank die Relais anzusteuern. Ich würde mir zwar
zutrauen, auch die Starkstromseite zu bauen, aber den Schaltschrank
muss ja immer ein Elektriker abnehmen. Und billiger als die normalen
Schaltschrank-Relais geht es sicher nicht selber zu bauen, nur diese
Bus-Technik ist eben so schw..-teuer.

Viele Grüße, Stefan

Autor: Peter Fleury (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan
Also von diesem zentralen Schaltschrank werden Lampen, Rolladen etc
mittels Relais geschaltet. Dazu braucht es sternförmig Leitungen in
jedes Zimmer. Hast Du den noch Lichtschalter in den Zimmer oder werden
die Zimmer Lampen über separate Taster via CAN geschaltet ?

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
Ich habe keine Schalter mehr am 220V-Netz, wenn Du das meinst. Die
Schalter bzw. Taster der einzelnen Zimmer gehen über den Bus zum
Schaltschrank. Dort steuern sie dann den zugehörigen Aktor an, der das
entsprechende Relais schaltet. Die Kommunikation zwischen intelligentem
Schalter und Aktor läuft dabei direkt, nicht über einen zentralen
Master.
Wenn der Bus beschädigt wird oder das Netzteil ausfällt, dann ist
natürlich erstmal Schicht im Schacht. Also zumindest die Lampe im
Technikraum wird per normalem Schalter betätigt! An den Aktoren sehe
ich vielleicht noch manuelle Schalter vor, zumindest für manche
Signale. DIL-Schalter würden ja schon reichen, als Notnagel.

Dieser Zentralismus der Netzleitungen gefällt mir eigendlich auch
nicht, scheint aber überall so gemacht zu werden, wenn ein Bus
eingesetzt wird.

Viele Grüße, Stefan

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich lese hier nur "Mitsubishi" und "Fujitsu", warum denn nicht den
Atmel T89C51CC01 ?

Ich nehme den sehr gerne.
Den kann man direkt einlöten und erst in der kompletten Schaltung
programmieren oder updaten. Den mit CAN-Bootloader sogar über den
CAN-Bus. Weg mit dem extra Programmierstecker, bequemer gehts nun
wirklich nicht.

Er ist auch im schönen PLCC-44 lieferbar, d.h. man kann ihn bequem in
einen Sockel auf stinknormale Rasterplatinen einsetzen.
Ist also nicht nur was für Platinenprofis, die können dann die BGA oder
VQFP Version nehmen.


Peter

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich lese auch "Motorola" ;)
Aber Peter hat schon recht, die Atmels sind was Feines. Und wenn es
etwas mehr sein muss, dann halt den CC03 oder bei kleinerem Bedarf den
CC02.

Und wie ich oben schon schrieb, die Microchip-Teile funktionieren auch
ohne Controller und somit ohne Programmierung, besonders ideal für
einfache Sachen wie Schalterbedienung, Sensoren, Aktoren. Das spart
nicht nur Zeit, sondern auch den Stress für die Fehlersuche in solch
einem verteilten System.

Autor: MMM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

willst du die Hardware selber bauen oder auf was fertiges setzen.

Wago bietet gute HW auf verschiedenen Bussen. Ethernet ist toll,
kann man dann auch gleich für die Vernetzung der Rechner nutzen. Dann
kann man auf dem Lichtschalter Video gucken. LON ist eine gute
alternative, gibts für verschiedene Medien.

Ich würde die Steuerung so aufbauen, dass immer eine Steuerung z.B.
eine Etage übernimmt, fällt dann der Bus aus, kann jede Etage vor sich
hinnudeln, so ist es nicht gleich im ganzen haus stockdunkel.

Nicht zu vergessen ist die Gebäudeleittechnik (GLT), also ein Rechner,
wo man sieht was los ist. Sowas bringt immer ziemlich hohe Buslast !

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmmm ...
Peter, Du machst mich fertig. Seit 15 Jahren hege ich meine Allergie
gegen 8051-Derivate. Was viel an dem grauenhaften Speicherzugriff und
den unterschiedlichen Zugriffsarten liegt. Ist nicht schön, wenn man
auf mehr als die 128 bzw. 256 Byte zugreifen will.
Aber für die Hausbus-Anwendung zählen diese Punkte ja nicht, und Atmel
ist beim Flash wirklich führend (wenn es beim T89C51CC01 ähnlich wie
beim ATmega ist). Den T89C51CC01 gibt es ja auch im SO24-Gehäuse. Das
würde mir gut reinlaufen.
Also ich werde die Sache mal überdenken. Wahrscheinlich bringt Ihr mich
noch dazu, dass ich in einem Jahr auf einem Apple unter Linux im
Baumhaus der Kinder programmiere  ;-)

@Andreas:
Habe Deine PIC-Chips schon angeschaut und nicht vergessen. Sehen auch
sehr interessant aus, es ist nur die Frage, ob es nicht mehr Sinn
macht, auf jeder Platine dieselbe Hardware am laufen zu haben, einfach
um sich nicht in 2 verschiedene Teile einarbeiten zu müssen. Das
Datenblatt hat auf den ersten Blick nicht ganz trivial ausgesehen, aber
ich werde es nochmal studieren.

Viele Grüße, Stefan

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan:

[Motorola HCS12]
> 48-Pin-Gehäuse
stimmt, diese Serie hatte ich bisher noch nicht gesehen...

> Mehr Pins stören doch eigendlich nur beim Löten und brauchen Platz
auch ne Möglichkeit die Sache zu sehen ;)

> Wie debuggst Du den HC12?
BDM-Interface, USB-Programmer von P&E-Micro und Metrowerks Debugger.
BDM ist ne feine Sache.

@Peter:
> Atmel T89C51CC01
bei Reichelt für 13,20EUR... billig ist das nicht gerade. Für das Geld
bekomme ich auch Mikrocontroller von Herstellern, die ihre
Produktpalette nicht alle 2 Jahre komplett umstellen ;)

> in der kompletten Schaltung programmieren oder updaten. Den mit
CAN-Bootloader sogar über den CAN-Bus.
Das ist aber inzwischen der übliche Weg.

> Er ist auch im schönen PLCC-44 lieferbar, d.h. man kann ihn bequem in
einen Sockel auf stinknormale Rasterplatinen einsetzen.
Das mag ein großer Vorteil sein.

Tschüß,
 André.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter Digikey.com kann man Preise online suchen. Da hat man hat so eine
ungefähre Richtung, wohin der Preis geht, wenn man nicht gerade bei
Reichelt oder Conrad kauft (oder kaufen muss).

Beim T89C51CC02 komme ich da auf 5,20 Euro (100Stk). Der CC01 ist etwas
teurer.

Den Motorola habe ich bei AVNET für 5,50$ (84 Stk) gefunden.

Gute Suchlinks, gerade für Preise, gibt es hier:
http://claymore.engineer.gvsu.edu/egr326/Electroni...

Hier ist übrigens ein Eval-Board für den Motorola:
http://www.elektronikladen.de/chips12.html

Also von den CPU-Preisen ist es relativ egal. Um auf dem HC12 zu
entwickeln, braucht man das BDM-Pod. Den Compiler und Debugger (auf 12k
limitiert) gibt es bei Metrowerks umsonst. André, was hast DU denn für
Dein BDM bezahlt? Mit USB würde mir ja schon gut reinlaufen.

Viele Grüße, Stefan

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan:
www.pemicro.com -> USB-Multilink: 199$ - leider nur afaik direkt von
USA zu beziehen. Funktioniert mit Metrowerks CodeWarrior v3 und z.B.
HCS12DP256 zusammen recht gut.
Den elektronikladen-Pod habe ich noch nicht live gesehen - kostet
zusammen mit NoIce afair 265EUR - gibt sich also nicht viel. Bleibt der
Vorteil eines deutschen Ansprechpartners (Probleme/Garantie...).

[T89C51CC02]
> 5,20EUR
na das klingt doch schon wesentlich besser.

Tschüß,
 André.

Autor: Leser1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal von jemand gelesen, der hat sein Haus mit 1-Wire vernetzt,
überall Temp-Sensoren, Jalousiemotoren, Schalter etc.

Soll sehr gut funzen.

Mit Web-Zugang (Beck IPC@web, http://www.beck-ipc.com) kann er das
ganze Haus von jedem Ort der Welt aus fernsteuern.

Bei Interesse kann ich die Adresse raussuchen.

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So einen Hausbus wollte ich auch unbedingt haben. Das Problem war nur,
dass meine Familie nicht 2 Jahre auf Licht im neuen Haus warten
wollte.

Also habe ich mich für EIB entschiden, und das ganze Häusle vollständig
so aufgebaut. Was das alles kosten würde, das wusste angeblich keiner
so genau, besonders nicht der Elektriker. Es käme drauf an, und je
komplexer desto eher lohnt sich das usw. blablah.

Hier die knallharten Fakten: hätte ich die Hütte konventionell mit all
den Funktionen verdrahten lassen, die ich heute habe, dann wäre ich
nicht unter 15000 DM davongekommen, aber auch nicht über 18000.- DM.

Und was hat das mit EIB gekostet? 45000.- DM. Fuenfundvierzigtausend
DE-EMM.

Also: wer keine 4-8 Stockwerke mit allem PiPaPo verdrahten will, und
aufs Geld schauen muss: Finger weg vom EIB, es ist im EFH-Bereich
SCHWEIINNEETEUER!!

Spass hab' ich trotzdem dran, und nur so kann mans sehen: die einen
kaufen sich Spoiler und Breitreifen für den Golf mit bösem Blick, ich
hab eben meinen EIB.

Nun zur Topologie. Ich würde heute einiges anders verdrahten. Der
Ist-Zustand: genau wie hier schon mehrfach besprochen: alle Verbraucher
landen mit einer eigenen Strippe im zentralen Schaltkasten. Alle
Sensoren (Lichschalter, PIR-Sensoren etc.) sind über Busleitung
verdrahtet, bei EIB völlig wurscht ob Stern, Linie oder sonstwas. Die
Busleitung landet ebenfalls im Zentralschrank, wo auch die Aktoren
sitzen. Das funktioniert alles wunderbar, ist simpel zu Planen und man
hat die volle Kontrolle über die Gesamtinstallation, auch später.

ABER: in der Stadt gibt es kein Haus, wo soviel Kupfer vernagelt wurde
wie bei mir. Von wegen Kabel sparen, alles Gewäsch. Und genau das würde
ich heute anders machen: In jedem Stockwerk einen kleineren Schrank, wo
alle Stockwerksleitungen zusammenlaufen, und auch alle für das
Stockwerk zuständigen Aktoren sitzen. Ein Backbone-Kabel 5*DickundFett
für die 220V vom Hauptanschluss zu den Unterverteilungen. Den Bus
überall hin, wie gehabt, und fertig ist die Laube.

Da in meinem Schaltschrank im Keller heute etwa 150 Strippen (je 3x1,5
bzw. 5x1,5) zusammenlaufen, kann sich jeder ausrechnen, was für einen
Monsterschlitz ich dort in die Wand kloppen musste. Ausserdem kann man
für jeden Verbraucher je Stockwerk mal eben 2,80m Kabelverlust rechnen,
was sich bei meinem Häusle alleine auf geschätzte 420 Meter summiert.
Die müssen bezahlt werden, die müssen verlegt werden, die müssen z.T
geschlitzt werden, sie bedeuten Leitungsverluste (Wattmässig), sie
stellen eine Brandlast dar und man KANN SIE ANBOHREN!! Und das ist
nicht zu unterschätzen: es gibt Stellen im Haus, da bohr' ich kein
Loch in die Wand, höchstens nach SEHR genauem Sudium meiner Fotos (oder
gerade dann erst recht nicht!).

Am besten mal zusammenrechnen, was so an Kabeln zusammenkommt:
Deckenlicht, Steckdosen (einzeln schaltbar...), Jalousien, Wandlampen,
Herd, Backofen, etc.etc. Ich hätte jedenfalls nie gedacht, dass man in
einem EFH problemlos auf 150 Steckdosen kommen kann.... Die
Lichtleitungen kommen natürlich hinzu, und auch so manches andere fällt
einem noch ein. Achja: die Aussenelektrik nicht vergessen, wiederum
Licht, Steckdosen, Alarm-Einrichtungen usw...

Wenn dabei am Schluss irgendwas zwischen 100 und 200 Leitungen
rauskommen, dann nicht wundern, sondern genau überlegen, WIE KRIEG ICH
DIE ALLE IN DEN KELLER? Bei mir war's so, dass ich in der Küche ein
einer Stelle keinen Oberschrank hätte hängen können, wär mangels
(Wand-)masse einfach nicht gegangen: da geht der Monsterschlitz zur
Hauptverteilung runter. Glücklicherweise sollte da eh' nur ein
Hochschrank hin...

Deshalb meine dringende Empfehlung (je nachdem wie gross das Projekt
ist): In jedem Stockwerk einen eigenen Schaltschrank. Den dafuer aber
kleiner. Macht die Sache auch übersichtlicher und leichter wartbar.
Auch wenns einem nicht ins architektonische Konzept passt, glaubt mir:
ES LOHNT SICH! Und ausserdem muss man, wenn eine Sicherung rausgeflogen
ist, nicht zwei Stockwerke tief in den Keller laufen.

Noch ein Problem, ich habs schon erwähnt: wer baut hat den Kopf voll.
Und wenn da einer noch den Nerv und das Stehvermögen hat, einen eigenen
Bus zu entwickeln, bzw. Anwendungen zu einem bekannten Bus für sein
Haus zu entwickeln, dann muss ich sagen: Hut ab!

Sowas müsste man eigentlich in den eins/zwei Jahren vor dem Baubeginn
machen, wenn man noch Kraft und Ruhe hat. Wenns dann soweit ist, muss
man in der Lage sein, alles einfach fix+fertig einzubauen, so wärs
ideal. Denn eine doppelgleisige Installation (Konventionell und
Busmässig) kommt nicht nur teurer sie ist schlichtweg Verschwendung und
auch irgendwie frustrierend.

Noch was zum EIB: man kann schon einiges draus lernen: dezentrale
Intelligenz, Multimaster/Slave-fähig (es gibt eigentlich keine
"Master", der Bus ist sehr "demokratisch"), ziemlich siche&#341; in
der Übertragung, AFAIK 9600 Baud. Sehr schön: Alle Komponenten
fernprogrammierbar über Bus/Internet etc., Sicherheitskonzepte.

Ein Bekannter baut auch gerade seinen eigenen Bus (Walters Bus hat auch
schon einen Namen: "Walli-Bus"). Es handelt sich um einen
differentiellen 2-Draht Bus, d.h. die Spannung auf dem Bus ist ziemlich
wurscht, über einen OpAmp wird einfach die Spannungs-Differenz zwischen
zwei Leitungen ausgewertet. Ist natürlich ziemlich sicher, da
Spannungschwankungen eigentlich keine grosse Rolle spielen, und auch
Einstreuungen, die ja auf beide Leitungen wirken, wenig Effekte haben.
Mehr weiss ich dazu allerdings auch nicht. Ich hab nur gesehen, dass es
schon funktioniert.

Noch was Allgemeines: Die Einzelprojekte so einer Idee sind sicher alle
gut in den Griff zu bekommen. Man sollte aber die Gesamtaufgabe nicht
unterschätzen - es ist mehr Arbeit, als man zunächst annimmt! Und wenn
dann die liebe Gattin kein Licht in der Küche hat, oder kaltes Wasser
in der Wanne, weil noch ein Bug im Busprotokoll ist, dann wirds echt
bitter ... ;-)

Trotzdem wünsche ich viel Erfolg damit! Ich werde gespannt weiter hier
mitlesen!

PS: z.Zt. versuche ich, mir ein paar Infineon "TP-UART EIB" zu
organisieren. Serielle EIB-Busankoppler sind das, ich möchte da was
Eigenes für meinen EIB machen, und zwar eine DCF77-Jahresschaltuhr mit
zig-Programmiermöglichkeiten, sowas kostet im EIB-Bereich auch mal 500
Euro :-((

Wer Interesse hat, soll sich melden: die Mindestbestellwerte sind etwas
hoch für einen allein.


e.

Autor: Mario B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
bin neu in diesem Forum.

Will mein Haus auch mit einem Bus ausrüsten.
Habe da folgendes System entdeckt.

LCN (www.lcn.de)

+ 230V und ein zusätzlicher Leiter als Datenleitung
+ Dezentraler (und Zentraler) Aufbau -- örtlich gesehen
+ Verwendung normaler oder EIB Taster

Was sagt ihr dazu ????

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was noch nie angesprochen wurde, ist die Programmierung des Busses.
Hie kommt nur eine Programmierung über den Bus in Betracht (wie bei
EIB)Der Bus muß sehr einfach zum Programmieren gehen. (leichter als bei
EIB, zb. Nikkobus von Möller) Mein Bus läuft so: Taste am Aktor drücken
(Lernmodus) Taster drücken (zB. Lichtschalter) fertig.
Jede andere Programmierungsart wäre Wahnsinn, da du in 3 Jahren
überhaupt nichts mehr weist über dein Busprogramm und Weihnachten im
Dunkeln sitzen könntest. Nimm lieber Siemens LOGO und schalte alles
zentral, in jedem Stock ein Verteiler, fertig. Easysoft von Möller
ist sogar vernetzbar (zB.von Stock zu Stock)

Schöne Grüße Josef

Autor: Michael Wulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mach mir auch viel Gedanken über einen solchen Bus.

Grundlegend hab ich bis jetzt folgendes durchdacht, 2 Leitungen
einmal GND und einmal +12V.
Hardware grundsätzlich Sender (Taster, Bewegungsmelder usw...)
auf den Sendern wird mit DIP Schaltern eine Adresse eingestellt (0-255)
somit sind 256 Sender möglich.
auf die +12V wird dann das Datensignal aufmoduliert (voll Duplex, also
senden und empfangen möglich).

Dann gibt es ein Master Modul welches die Befehle von den Sensoren
(sendern) zu den Aktoren (Relais, Triac-Schaltern) weitergibt! Dieses
Master Modul möcht ich dann über die RS232 programmieren können!

Die Aktoren sollen einfache Emfänger, ebenfalls eine Adresse
einstellbar 0-255, sein.

Tja diese Aufgabenstellung hab ich mir bis jetzt gemacht, weit gekommen
bin ich aber bis jetzt noch nicht (Zeitmangel)

Sollte ich jedoch weiterkommen lasse ich es euch wissen!

mfg Michael Wulz

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mario:
So wie ich das sehe, wird lcn nur von einer Firma hergestellt? Ist
natürlich etwas riskant, wenn die dann absaufen.

Aus meiner persönlichen Sicht heraus ist ein separater Datenbus besser,
weil ich dann eine eindeutige Trennung zwischen Netz und Bus habe. Ich
bastel also immer an "ungefährlichen" Spannungen rum (und die Kinder
auch, wenn sie mal Papa spielen). Das ist bei einer eingekauften Lösung
aber sicher nicht das Problem. Was ich von Netzfreischaltung im
Schlafzimmer halten soll, bin ich mir nicht so sicher, aber bei einer
separaten 24V-Gleichspgs-Lösung fällt das schon vom Konzept mit ab.

@Joseph:
Ich habe im Moment die Aktoren alle im Schaltschrank (im Keller)
geplant. So eine Programmierung wäre mir zuviel Rennerei.
Die Programmierung z.B. von Lichtszenen soll aber schon vor Ort
erfolgen: Lange auf den Szenentaster drücken speichert die momentane
Lichteinstellung auf dem Schalter ab (analog auch bei Jalousien).

@Michael:
An dem Punkt (2 Leitungen) war ich auch schon mal. Technisch ist das
sicher das naheliegendste und eleganteste. Allerdings habe ich ziemlich
lange nach Bustransceivern für so eine Lösung gesucht und nichts
integriertes gefunden. EIB verwendet ja so ein Verfahren, allerdings
verwenden die einen Trafo am Eingang. Das Netzteil muss auch speziell
dafür ausgelegt sein. Ich habe mich mittlerweile entschlossen, die
zweitschönste Lösung mit 4 Adern zu bauen. Sind halt überall doppelt so
viele Adern zu kontaktieren, dafür entfällt aber viel
Elektronik-Aufwand, und ich kann den CAN-Bus von der Stange verwenden.
Immerhin will ich irgendwann ja auch fertig werden.

Als Spannungsversorgung habe ich 24V vorgesehen, weil viele Geräte
damit direkt angesteuert werden können und deshalb oft das 220V-Kabel
gespart werden kann, z.B. die elektrischen Heizungs-Steller. Ich habe
4* soviel Leistung als bei 12V (bei gleichem Kabelwiderstand), ev. ist
es damit sogar möglich, Jalousiemotoren direkt zu betreiben (muss ich
aber noch näher anschauen). Auch an eine Minibeleuchtung (Nachtlicht im
Kinderzimmer oder an der Treppe, ein paar LEDs mit vielleicht 1W) habe
ich schon gedacht.

Die Adressen will ich entweder fest ins Flash schreiben oder per
Dallas-Seriennummer-Chip (One-Wire).

Ich bin gerade dabei, das Konzept mal grob zu beschreiben, wenn es
fertig ist, stelle ich es hier natürlich rein.

Viele Grüße, Stefan

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@emax:

erstmal Danke für Deinen superlangen Beitrag. Hat mich richtig
erschlagen ;-)

Für EIB-OEM-Komponenten ist vielleicht diese Seite recht interessant:
http://www.knx-developer.de/

Zum Preis: genau so habe ich das von meinem Elektriker auch angeboten
bekommen, nur dass der Preis mittlerweile nicht mehr in DM sondern in €
gilt :-((  Bei Elektrikern scheint das Wort EIB so einen Reflex
auszulösen: "kein qm ohne eingebautes Kabel". Ich habe ihm dann
desagt, dass ich mir den Bus lieber selber bauen will und er nur die
Netzspg. einbauen darf, das hat er sogar ganz gut akzeptiert.

Das mit den vielen Kabeln ist wirklich ein Argument. Ich bin mir nur
nicht sicher, an welcher Stelle ein Unterkasten bei unserem Bauplan
wirklich Sinn macht. Ich habe einen zweiten Kasten schon mit meinem
Elektriker angesprochen, aber bis jetzt haben wir noch keinen guten
Platz gefunden.

Dass man von EIB viel lernen kann, habe ich auch schon gemerkt. Der
größte Nachteil ist wirklich der Preis. Ausserdem möchte ich bei der
Hauselektronik gerne Einiges mitreden und auch mitentwickeln. Und da
sind die Hürden bei EIB doch recht hoch.

Ob ich mit der Zeit hinkomme, das muss ich eben ausprobieren. Den
Hausbau verschieben geht jedenfalls nicht mehr ;-)  Die Wahl des
CAN-Bus ist nicht zuletzt deswegen gefallen, weil es einen sicheren
Unterbau darstellt und (wohl) recht einfach zu implementieren ist. Aber
ich bin recht optimistisch, dass zumindest die rudimentären Sachen in 6
Monaten laufen. Eine automatische Jalousiesteuerung kann z.B. ruhig
noch länger warten.

Viele Grüße, Stefan

Autor: emax (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan!

Also das mit dem zentralen Schaltschrank überleg Dir gut! Ich hab' Dir
 im Anhang mal ein zwei Fotos von meiner Installation gepostet. Schau
Dir besonders mal oben rechts im Kasten die Reihenklemmen an, da gehts
schon sau-eng zu, auch wenn das auf dem Bild alles so schön locker
aussieht.

Die Linke Seite ist von den Zählern vollständig belegt (es sieht luftig
aus, aber du kannst da nix mehr reinmachen), rechts ist zwar noch etwas
Platz, aber der hätte nicht ausgereicht, wenn ich nicht einen zweiten
Kasten unten drunter gesetzt hätte...

In meiner Werkstatt habe ich noch UV, ausserdem sitzt dort mein
patch-Kasten für die Cat-5 Kabel die von den 18 Anschlüssen im ganzen
Haus dort zusammenlaufen,  und in der Einliegerwohnung ist auch noch
eine Verteilung. Es wäre NIEMALS alles in einen Kasten gegangen.

Unten drunter siehst Du den zweiten Kasten mit einem Teil der
EIB-Komponenten. Den musste ich setzen, als sich zeigte, dass der Platz
in der HV nicht reichte. Ziemlich unpraktisch, man kann nur auf dem
Boden hockend da was machen.

Es ist noch nicht alles fertig angeschlossen, aber Du kannst in etwa
schon die Ausmasse der Kabelorgie sehen.

Stell Dir einfach vor, Du programmierst ein dickes Programm in einer
einzigen Monster-Main-Spaghetti-Routine, anstatt in übersichtlichen
Einzel-Funktionen. Es ist echt gut miteinander zu vergleichen: ein
grosser Schaltschrank oder mehrere kleine.

Wenn Du einen gut dimensionierten 400V-Strang als Backbone von der HV
(Hauptverteilung)zu den UVen legst, und zwei (sicherheitshalber)
Hausbus-Leitungen gleich dazu, dann bist du bestens gerüstet. Dann
kannste z.B. auch Deine FI-Schalter stockwerkmässig abgrenzen usw...

Ausserdem: du wirst echt irre, wenn Du Armbeugen-dicke Kabelbündel
durch irgendein viel zu enges Loch in einer Betondecke würgen musst. Wo
die Kabel zusammenlaufen, kannste auch später kaum noch guten Gewissens
ein Loch bohren.... Hinzu kommt, dass die lieben Heizungsbauer dann
auch noch ein paar Röhrchen da durch haben wollen, von Abwasser et. al.
ganz zu schweigen. Und die sind mit den ggf. bereits liegenden Kabeln
nicht immer sehr zimperlich....

So einen UV-Schrank kann man natürlich nicht in eine 11-5er Wand
einbauen. Trotzdem gibt es genügend Möglichkeiten. z.B. hinter einer
Tür, da sieht mans nicht so. Oder bevorzugt im Flur (weil man da am
besten hinkommt, wenn mal die Sicherung rausfliegt), oder auch mitten
auf jeder beliebigen Wand, wenn man an dieser Stelle vielleicht ein
grosses Bild hinhängen kann.

Ich wollte mir anfangs "UM GOTTES WILLEN" auch keine Wand mit einer
UV  "versauen". Hinterher weiss ich nun, dass alles halb so wild ist.
Man gewöhnt sich an vieles, es gibt Gestaltungsmöglichkeiten, und wenn
man gebaut HAT, dann sieht man ohnehin alles viel lockerer.

Noch ein paar Fakten: so ein HV-Schrank ist SCHWEINETEUER! Und zwar
deshalb, weil da wg. des Zählers usw. alle möglichen Anforderungen
bestehen und weil "Hager" drauf steht. Ich hab' über tausend Märker
für das bischen Blech abgedrückt. Wenn der Kasten dann noch besonders
gross sein muss, dann wirds nochmal extra teuer.

Wenn Du aber in den Stockwerken kleinere UVen setzt, dann kannste die
auch im Baumarkt billig kaufen, es interessiert dann niemanden mehr,
ob's einer von Hager ist, oder nicht. Und so wird dein HV-Schrank
kleiner.

Und noch ein Tipp, auch wenns jetzt etwas OT wird: Wenn Du
Fussbodenheizung hast, haste das selbe Problem: wohin mit den
Verteilerschränken?

Die Antwort: dahin, wo Du Wärme brauchst, möglichst zentral im
Stockwerk. Denn dahin, wo diese Verteiler sitzen, laufen natürlich auch
alle Fussbodenleitungen, weshalb natürlich der Boden in der Umgebung
zwangsbeheizt wird. Mir hat das damals niemand gesagt, weshalb ich
heute eine viel zu warme Abstellkammer habe....

Soweit so gut.

In welcher Gegend baust Du eigentlich? Ich wohne im Odenwald, wenns
nicht so weit weg ist, dann schau ich mir das gerne mal an...

bis denne,
e.

Autor: Bernhard Koopmeiners (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

emax steht im Leben. Eine Zentrale Installation der Aktoren macht
keinen Sinn.
Mein Haus hat insgesamt 4 Etagen, die ich mit zum Teil 2 Verteilern
ausgestattet habe.
Der erste Vorteil besteht in der Tatsache, dass ich logische Einheiten
habe. Somit ist es ein leichtes Verbrauchmesser, FI und Bussystem
getrennt voneinander zu installieren.
Der zweite Vorteil liegt in der Länge der Leitungen zu den Aktoren und
Sensoren.
Auch die Fehlersuche gestaltet sich wesentlich einfacher. Wenn ich am
Bus die Verbindung zu anderen Verteilern unterbreche, kann man den
Fehler relativ schnell eingrenzen.
Ein weiterer Punkt ist speziell für vermietete Wohnungen wichtig. Da
ich an meinem Bus einen Scanner hängen kann, wäre es mir möglich genau
zu sehen was meine Mieter machen. Deshalb plane ich für diese Übergänge
eine Firewall die den Bus elektrisch trennt und nur notwendige Events (
Außentemp., Heizungsdaten usw. ) überträgt. Auch Konfigurationssoftware
kann somit nur im eigenen Bereich Unfug anrichten.
Abschließend wie immer an jeden Häuslebauer: Legt keine Leitungen. Legt
Leerrohre. Ich habe es sogar mit meinen Wasserleitungen praktiziert und
bin damit sehr zufrieden.

Bernhard Koopmeiners

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@emax
Bravo ! Tolle Arbeit.(meine ich ernst) Aber leider keine Kabel
angeschrieben. Großer Fehler. Fehlersuche: Viel Spaß. Das sind
Bus-Auswüchse ;-) EIB: Immer schon an der Praxis vorbei. Zu teuer, zu
komplex, zu viel Platzverschwendung. Aber sehr zuverlässig und
leistungsfähig. Kunden (Nichttechniker) machen sich durch EIB
lebenslang von Ihrem Elektriker abhängig.
Von selbstgestrickte Bussystemen würde ich die Finger lassen (wenn
einem an der eigenen Frau was liegt).


Schöne Grüße Josef

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@josef

Jaja, die Doku.

Ist aber nur halb so schlimm: alle Klemmen sind im PC dokumentiert.
Die Übertragung auf Etiketten ins richtige Leben steht noch an...

Behelfsweise habe ich eine Klemmen- und Gerätedoku ausgedruckt und auf
die Innenseiten der Schaltschranktüren geklebt. Ist ja alles noch nicht
fertig - und wird es wohl auch nie :-))

Das mit der eigenen Frau hab' ich ja oben schon beschrieben, aber
vielleicht ist Stefan ja Junggeselle ;-)

Das mit derElektrikerabhängigkeit stimmt für Nichttechniker. Aber sogar
Elektriker haben so ihre Probleme mit der Projektierung des EIB. Der
ETS/2 liegt ein Datenmodell zugrunde, das die meisten Elektriker
einfach nicht verstehen. Und dann kommt da was bei raus, wo die zwar
physische Projektierung (Leitungstopologie) korrekt gemacht wurde, denn
das ist ja was, was man "sehen" kann. Aber die "Logische Sicht"
aufd die Installation (eine tolle Sache) wird oft nicht korrekt
verstanden und deshalb als das Gleiche wie die Bustopologoie
angesehen.

Na egal. Ich hab jedenfalls konsequent die gesamte Grundinstallation
des Elektrikergesellen gelöscht, und alles Pikkobello nach den
optimalen Möglichkeiten der ETS/2 neu konfiguriert.

Da lass ich keinen Elektriker mehr ran....

PS: ETS heisst "Eiba Tool Software", das ist die Projektier- und
Programmiersoftware für den EIB.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow, wie schafft Ihr es, solche Mengen zu schreiben?

Ich werde die Beiträge von Euch mal ausdrucken und meinem Elektriker
zeigen. So eine Unterverteilung würde mir selber ja schon passen, weil
sie dem dezentralen Konzept wenigstens ein Stückweit entgegenkommt.
Aber Elektriker scheinen wohl allesamt zentralistisch zu denken, das
EIB-Konzept war ja EIGENDLICH auch dezentral gedacht, draus geworden
ist leider das Gegenteil.

Natürlich habe ich Frau und Kinder, würde ich sonst den Wahnsinn
angehen, ein Haus zu bauen? Aber bevor ich für Eigenleistung an der
Betonmaschine stehe, baue ich lieber meinen eigenen Bus zusammen. Wenn
ich die Fliesen selbst lege, heisst es die nächsten 30 Jahre: "hat
mein Mann selbst gemacht, FAST professionell, oder?", bei einem
eigenen Bus passiert mir das nicht, ich bin mir ziemlich sicher, dass
die Elektrik später besser läuft als im Standard-0815-Haus. Klar, mit
45.000€ EIB-Installation (habt Ihr den ct-Artikel gesehen?) ist meine
Lösung sicher nicht zu vergleichen.
Mit einem vom Elektriker installierten Bus würde es mir so gehen wie
emax: zuerst viel ärgern, dann alles rausschmeissen und selber
neuprogrammieren. Natürlich ginge das auch mit einem EIB-Bus. Aber den
Ausweg habe ich ja immer noch. Wenn mein Bus nicht fertig wird, muss es
halt doch ein (Mini-) EIB werden. Aber nicht selbst an der Elektrik
rumzufummeln wäre für mich wie für den Architekten, wenn er sein Haus
vom Bauträger hinklotzen läßt.

Viele Grüße, Stefan

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@emax:
ach ja, wir bauen in Würzburg, ist ja garnicht so weit weg. Vielleicht
können wir uns wirklich mal treffen.

Viele Grüße, Stefan

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber auch bei einer normalen Verdrahtung sind Zwischenverteiler in den
Etagen sinnvoll.


Ich würde das ganze so machen, daß ich die Lampe mit zur Schalterdose
führe, also ganz normal und im Fehlerfall durch einen normalen Schalter
ersetzbar.

Und auf der Platine in der Schalterdose sitzt neben dem CAN-MC auch ein
Opto-Triac mit Entstörbeschaltung.
Statt des Schalters sitz eine Sensorfläche davor, die der MC mittels
Kapazitätsmessung prüft, ob sie berührt wird oder nicht (wurde hier
schon mal beschrieben).
Eventuell noch ein kleines Fenster mit drin für den TSOP IR-Empfänger
und fertig ist die Lampensteuerung.

Der Verdrahtungsmehraufwand ist also nur das 4-polige Bus/24V-Kabel.

Der Funktionsvielfalt sind dann keine Grenzen gesetzt.
Man könnte z.B. beim 5-maligen Drücken im Schlafzimmer sämtliche Lampen
im Haus mit ausschalten.


Peter

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich würde das ganze so machen, daß ich die Lampe mit zur Schalterdose
führe, also ganz normal und im Fehlerfall durch einen normalen Schalter
ersetzbar."

So hatte ich zunächst auch angefangen. Als dann aber Kreuzschaltungen,
Wechselschaltungen usw. auftauchten, war schnell klar, das ich damit
alle Vorteile des Busses, nämlich eine simple Verdrahtung (alles ab zum
Verteiler und basta), aufgab.

Man kann das natürlich sicherheitshalber in einfacher Form tun: keine
Kreuz- oder Wechselschaltungen usw, dann kann man halt im Treppenhaus
nur im untersten Stock alles an+ und ausschalten....

Also das muss man sich gut überlegen.

@Stefan

in der Nähe v. Würzburg kenne ich einen Ort namens "Thüngen", da ährt
man vielleicht eine Stunde von hier aus.

Wenn die Hütte Forman annimmt, und die ersten Strippen gezogen werden,
dann meld' Dich mal per PM. An einem Sonntag mal mit dem Motorrad
rüber hüpfen wär kein Thema.

e.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"keine Kreuz- oder Wechselschaltungen"

Da die Schaltereinheiten alle untereinander vernetzt sind, kann man das
sehr wohl machen. Ist alles nur eine Frage der Programmierung.

An Halloween kann z.B. der Taster im Flur den Triac im Wohnzimmer
schalten und umgekehrt.

Steuerungstechnisch ist doch nur ein Output (Lampe) und ein Input
(Taster) am selben MC angeschlossen.
Die Verknüpfung der beiden kann entweder zentral oder im jeweiligen MC
selber erfolgen.
Der Taster sendet also ein Datenpaket entweder an die Zentrale: "Taste
1234 gedrückt" oder direkt an die Lampe: "Lampe 5678 einschalten".


Peter

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist mir völlig klar, der EIB arbeitet ja so: Datagram vom Sensor
"Adresse 1.2.3 EIN". Nur brauchts dann doch keine 220V am
Lichtschalter mehr.

Was ich meinte, war, dass die 220V Verkabelung, die ich ZUNÄCHST
parallel zum Bus an die Schalter führen wollte, bei Ausführung aller
Anschlusse auch für Kreuz- und Wechselschaltung viel komplexer geworden
wäre, als das bei einer Buslösung nötig ist.

Ich habe deshalb den Versuch, die Lichtschalter (und die anderen
Sensoren) zusätzlich mit 220V zu verdrahten, schnell aufgegeben.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
Als Sicherheits-Backup werde ich bei wichtigen 220V-Kreisen im
Schaltschrank Relais mit integriertem manuellen Ein-Schalter einbauen.
Das muss als Sicherheit reichen. Wenn der Bus wirklich mal ausfällt,
dann muss eben im Schaltschrank geschaltet werden. Kommt ja hoffentlich
nicht so häufig vor.
An einigen Stellen ist bei uns eine Doppelverkabelung auch rein vom
Platz her nicht möglich.
Den Bus will ich ganz bewusst von der 220V-Schiene trennen. Ich habe
zwar früher komplette Lichtanlagen selbst gebaut, aber mittlerweile bin
ich doch etwas vorsichtiger geworden. Wenn etwas passiert, auch wenn
die Elektronik nicht der Auslöser war, ist sonst der Ärger groß.
Rein von der Technologie her wäre Dein Ansatz natürlich am Besten,
wobei ich dann die Aktoren direkt an die Lampenausgänge und Steckdosen
legen würde. Der Schaltschrank wäre damit auf einmal ganz leer ...

@Emax:
In 2 Wochen kommen erstmal die Bagger, wenn alles klappt, dann steht
der Rohbau Ende Mai. Dann ist ja (hoffentlich) auch das Wetter
Motorrad-tauglich.

Viele Grüße, Stefan

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Aktoren im Schaltschrank unterzubringen hat noch einen Vorteil: Die
Stromleitungen in Wänden/Decke/Fussboden werden bei "AUS" stromlos
geschaltet.

Weniger Brandlast, weniger Elektrosmog.

Damit lässt sich sowas übrigens etwas leichter an die Ehefrauen
verkaufen ;-)


e.

Autor: Michael Buhr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Als heimlicher Mitleser melde ich mich auch mal zu Wort!

>Ich würde das ganze so machen, daß ich die Lampe mit zur Schalterdose
>führe, also ganz normal und im Fehlerfall durch einen normalen
>Schalter
>ersetzbar.

>Und auf der Platine in der Schalterdose sitzt neben dem CAN-MC auch
>ein
>Opto-Triac mit Entstörbeschaltung.


Genau das habe ich auch in Planung:) Schonmal ueber Transistor anstatt
Triac nachgedacht? Damit geht auch ein Phasenabschnitt, was die
Entstörung minimiert. Soviel Platz ist ja nicht in einer Schalterdose.

Mein Konzept beruht auf einem Standard Buskoppler mit AVR, CAN Baustein
(SJA1000) und ein wenig drumherum. Dieser wird je nach Bedarf Hukepack
auf einen Aktor aufgesetzt. Z.B. Dimmer, Relais, IR, Rolläden etc. Bei
SMD Bestückung sollte sich z.B. ein Buskoppler und Dimmer in einer
tiefen Schalterdose unterbringen lassen.

Bei Wechselschaltungen wird 2x ein Buskoppler und 1x ein Aktor gesetzt.
Die beiden Buskoppler "unterhalten" sich dann direkt.

Da hier doch einige Interesse an Homeautomation zeigen wäre es doch
nicht schlecht das gemeinsam anzugehen, oder??

Gruss, Michael

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry dass ich mich so lange nicht gemeldet habe. Michael, Dein Posting
muss beim Email-Aufräumen unten durch gefallen sein (grr geht mir
irgendwie öfters so). Über den Transistor statt Triac habe ich mir
wirklich schonmal Gedanken gemacht. Hat auch ein paar andere Vorteile,
z.B. kann der Strom sehr einfach gemessen werden. Wäre natürlich schon
ein schickes Feature ...

Ich habe mittlerweile ein Modul als Schaltplan und als Platine fertig,
jetzt muss ich das Layout noch fertigen lassen. Bauteile sind für die
Prototypen schon da, demnächst soll es mit der Programmierung losgehen.


Mal sehen, wie ich die nächsten Tage dazukomme, dann werde ich das
Ganze mal hier vorstellen.

Als Grundlage habe ich übrigens jetzt einen AVR16 vorgesehen, mit
Microchip MP2515 CAN-Transceivern. Ist zwar leider kein Single-Chip
mehr, aber durch die Ansteuerung per SPI-Bus hält sich das
Leiterbahn-Chaos in Grenzen. AVR habe ich deshalb genommen, weil ich a)
beruflich gerade ein größeres Projekt damit starte und b) schon den
JTAG-Debugger dafür habe. Ich kann also sofort komfortabel damit
starten. Was mir auch noch wichtig war: ich will an manchen Stellen
CAN-Kreuzungen einbauen, d.h. vom Hauptbus gehen Unterbusse ab, um z.B.
ein Zimmer zu versorgen. Da ist es natürlich besser zu programmieren,
wenn beide CAN-Transceiver dieselbe Hardware sind.

Zugegeben, viele andere Lösungen, die hier genannt wurden, haben auch
ihren Reiz, aber am Ende habe ich dann eben doch pragmatisch
entschieden.

Sobald die Doku einigermassen vorzeigbar ist, hört Ihr wieder von mir.

Stefan

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe gerade den Thread mit großem Interesse gelesen.

Ich hätte bis dato auch eine Installation wie es Peter Dannegger
vorgeschlagen hat
(http://www.mikrocontroller.net/forum/read-1-66019.html#68989)
vorgezogen. Jetzt bin ich aber doch ein bisschen verunsichert, ob das
Prinzip, alle Aktoren in eine gemeinsame UV zu ziehen, nicht doch
besser ist.

Der Vorteil der "herkömmlichen" Methode (inkl. zusätzlicher
Busleitung) wäre, dass die Buskoppler auch autark, also ohne Bus
arbeiten können. Jedoch müßte dann wahrscheinlich auch jeder speziell
programmiert werden. Mal nur 1 Taster, mal 2 Taster und ein IR usw.,
die ja dann auch jeweils unterschiedliche Funktionen zum Ergebnis
haben. Und man hat eben auch 230V in der Schalterdose.

Der Vorteil der gemeinsamen Verteilung ist sicher, dass mehr oder
weniger alle 230V-Leitungen an einer Stelle zusammenlaufen und man von
hier aus elektrisch alles recht einfach durch simples Umklemmen (auch
neu) zuordnen kann. Aber benötigt man dann nicht einen Master, der sich
um das tatsächliche Schalten dere Aktoren kümmert?

@Stefan:
>Ich habe keine Schalter mehr am 220V-Netz, wenn Du das meinst. Die
>Schalter bzw. Taster der einzelnen Zimmer gehen über den Bus zum
>Schaltschrank. Dort steuern sie dann den zugehörigen Aktor an, der
>das entsprechende Relais schaltet. Die Kommunikation zwischen
>intelligentem Schalter und Aktor läuft dabei direkt, nicht über einen
>zentralen Master.

Wie funktioniert das?

Also ich habe das so verstanden: Es gibt an verschiedenen Stellen
irgendwelche Busteilnehmer, die Signale auswerten z.B. einen Taster.
Diese sollen auch Aktoren direkt schalten können. Die Aktoren sind
aber in der UV geschaltet. Dann muss es doch in der UV einen Master
geben, der die "Wünsche" der Busteilnehmer auswertet und ausführt,
oder?

Joline

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das System nur ein Haus steuern soll, habe ich DALI im Angebot.
Hardware ziemlich einfach und störunempfindlich. DALI heißt Digital
Adressable Lighting Interface. Ist vor ich glaube 4 - 5 Jahren geboren
worden.
Michael

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joline:

>Wie funktioniert das?
>Also ich habe das so verstanden: Es gibt an verschiedenen Stellen
>irgendwelche Busteilnehmer, die Signale auswerten z.B. einen Taster.
>Diese sollen auch Aktoren direkt schalten können. Die Aktoren sind
>aber in der UV geschaltet. Dann muss es doch in der UV einen Master
>geben, der die "Wünsche" der Busteilnehmer auswertet und ausführt,
>oder?

Unter Master verstehe ich einen Teilnehmer im Bus, der die
Kommunikation aller anderen regelt. Das braucht man (beim CAN-Bus)
nicht. Vielmehr können sich alle angeschlossenen Teilnehmer
gleichberechtigt unterhalten.
Der Lichtschalter kann also dem Aktor (Relaistreiber oder Dimmer) im
Schaltschrank direkte Kommandos geben, ohne dass ein Master ihm dazu
die Berechtigung erteilt.
Und wenn ein Aktor im Schaltschrank ausfällt, dann funktionieren alle
anderen Aktoren weiter. Die CAN-Treiber haben intern spezielle
Sicherheitsschaltungen, die verhindern, dass ein amoklaufender
Busteilnehmer alle andere Kommunikation blockiert.

>Jetzt bin ich aber doch ein bisschen verunsichert, ob das
>Prinzip, alle Aktoren in eine gemeinsame UV zu ziehen, nicht doch
>besser ist.

Wenn Du es alles selber baust oder der Elektriker mitspielt, würde ich
mehrere UV an einigen zentralen Stellen vorschlagen, jedenfalls bei
einer Hausverdrahtung. Also vielleicht stockwerksweise.

So, jetzt muss ich auf die Baustelle ... ;-)

Viele Grüße, Stefan

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan:
>Unter Master verstehe ich einen Teilnehmer im Bus, der die
>Kommunikation aller anderen regelt. Das braucht man (beim CAN-Bus)
>nicht. Vielmehr können sich alle angeschlossenen Teilnehmer
>gleichberechtigt unterhalten.

Das ist schon klar. Ist ja einer der Riesenvorteile von CAN.

Vielleicht hatte ich mich unverständlich ausgedrückt. Es sitzt doch
bspw. in jeder Schalterdose ein Teilnehmer, der Signale auswertet (wie
ein Satellit), oder? Diese Signale sendet er dann über den Bus an die
UV. Aber dort muss doch auch einer sitzen, der eben dann wirklich das
Relais schaltet. Und entweder ist das einer (oder mehrere natürlich),
der alles macht (den hatte ich quasi als Master bezeichnet). Oder es
gibt wieder für jeden Aktor einen einzelnen Teilnehmer, der sich nur um
diesen einen Aktor kümmert. D.h. Anzahl der Aktoren ~ Anzahl der
Teilnehmer in der UV.

Aus Deiner Anwort deute ich, dass tatsächlich jeder Aktor auch über
einen Teilnehmer am Bus angekoppelt ist. Das ist zwar sehr flexibel,
weil sich ja alles per Software "umverdrahten" läßt. Aber wenn das so
ist, ist das nicht ein ziemlicher Aufwand? Mal abgesehen von den Kosten
(fertige Profi-Systeme kosten auch Geld, und nicht wenig...) müssen die
Module ja auch hergestellt werden, also Platine bestücken, Controller
programmieren usw.?

Ist Deine Topologie so, wie ich denke, dass sie ist?

Joline

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joline:
natürlich hat nicht jedes Relais seinen eigenen Busanschluss - wäre ja
viel zu teuer ...
* Module zur Relaisansteuerung können 24 Relais schalten
* Module zum Dimmen beinhalten 6 Dimmer
* Module für Heizungsventile können 6 Heizventile stellen

Jede einzelne Funktion - also z.B. die Ansteuerung eines Relais-Paares
für eine Jalousie - lässt sich aber unabhängig von den anderen
ansprechen.

Viele Grüße, Stefan

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

ich habe noch einmal 2 Fragen.

Es kommen da ja sicher eine Menge Module zusammen. Wie machst Du das
mit der Programmierung der Controller im eingebauten Zustand? Also ich
denke, wenn mal ein Firmwareupdate notwendig ist, wäre es ja ziemlich
lästig, sich an jeden Controller einzeln anstöpseln zu müssen...

Wie Du weiter oben schon einmal beschrieben hast, kann ein Sensor-Modul
auch direkt ein Aktor-Modul ansprechen und somit bspw. ein Taster (fast)
direkt eine Lampe einschalten (Taster A -> Sensor-Modul ==> Aktor-Modul
-> Relais 1). Das setzt aber voraus, dass in dem Sensor-Modul die
entsprechenden Befehle hinterlegt sind, um die passende Nachricht auch
an das entsprechende Aktor-Modul zu senden. Wenn sich nun aber mal die
Zuordnung ändern soll, weil z. B. nicht nur Relais 1, sondern auch
Relais 2 geschaltet werden soll, dann müßte doch das entsprechende
Sensor-Modul neu programmiert werden, oder?

Joline

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde die ganze Hauselektrik konventionel machen. In jedem Stock ein
Kleinverteiler 3-reihig. Von diesem ein Instabuskabel von Verteiler zu
Verteiler. Jedes Zimmer eigene Zuleitung zum Verteiler inkl. freier
Ader für jede Lampe bzw Taster (minimalste Kosten). Ebenso Jalosien /
Rolos in den Verteiler.
Kannst jetzt ohne Risiko Bussysteme aller Art verbauen.
In den Räumen würde ich Funktaster einsetzen. Da kannst du den Taster
"mitnehmen" und von allen Stellen aus dimmen. Fernbedienung usw. auch
kein Problem.





SG Josef

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Module sollten man gar nicht programmieren müssen . Beim Instabus
wirst hier ein Waserl. Optimal ist: Adresse manuell mittels
Codierschalter einstellen, fertig. Das Telegramm entscheidet was das
Ding machen soll. zB.: 10, 01, 02,45, 19 heißt: Telegramm an Adresse
10, 01 = Ausgang 1, 02 = Zeitfunktion, 45 = für 45 Sec. 19 = Absender.
Mit dieser Methode brauchst du überhaupt kein Modul programmieren. Wenn
ein Eingang betätigt wir, sendet dieser ein Telegramm, das den Eingang
eindeutig identifiziert. Wenn du jetzt einen Master ins Netz legst,
brauchst du nur die Telegramme bei diesem verknüpfen und fertig.

SG Josef

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joline,

>Es kommen da ja sicher eine Menge Module zusammen. Wie machst Du das
>mit der Programmierung der Controller im eingebauten Zustand? Also
>ich denke, wenn mal ein Firmwareupdate notwendig ist, wäre es ja
>ziemlich lästig, sich an jeden Controller einzeln anstöpseln zu
>müssen...

Das ist doch das Schöne am AVR, dass man sehr einfach selbst einen
Bootloader schreiben kann. Updates werden natürlich über den Bus
eingespielt. Nach Einschalten der Stromversorgung warten die Busmodule
2s auf einen Programmierbefehl. Danach wird das "normale" Programm
erst verifiziert und dann gestartet (wenn Verify ok war).
Jedes Modul hat (im Bootloader-Teil) eine fortlaufende Nummer (ähnlich
den Adressen in Netzwerkkarten).


>-> Relais 1). Das setzt aber voraus, dass in dem Sensor-Modul die
>entsprechenden Befehle hinterlegt sind, um die passende Nachricht
>auch an das entsprechende Aktor-Modul zu senden. Wenn sich nun aber
>mal die Zuordnung ändern soll, weil z. B. nicht nur Relais 1, sondern
>auch Relais 2 geschaltet werden soll, dann müßte doch das
>entsprechende Sensor-Modul neu programmiert werden, oder?

Programmiert ist vielleicht der falsche Ausdruck. Eher neu
parametrisiert. Denn am Programmcode muss man deshalb natürlich nichts
ändern. Jede Funktion kann bis zu 16 Nachrichten an beliebige Empfänger
schicken. Die Parametrisierung der Funktionen erfolgt über den Bus.
Auch welche Funktionen eine Busmodul realisiert, wird parametrisiert.
Pro Busmodul sind 32 Funktionen möglich, das können z.B. sein:
  * Lichtschalter
  * Jalousieschalter
  * Relais einfach (.z.B. für Licht an/aus)
  * Relais zweifach (z.B. für Jalousie hoch/runter)
  * Temperaturfühler
  * Heizungsventilsteuerung (inkl. Regelung)
  * Displayansteuerung
In jedem Busmodul ist dabei die Software für alle diese
Funktionsmöglichkeiten bereits enthalten. Jedes Busmodul kann also
dieselbe Software besitzen, egal ob nun Lichttaster oder Relais
angeschlossen sind, nur die Parametrisierung ist unterschiedlich.


@Josef:
Das Problem, was ich mit Instabus/EIB etc. habe, ist einfach, dass es
ein ziemlich geschlossenes System ist. Beispiel: ich habe eine
Lüftungsanlage mit 14 möglichen Stufen im Haus. Die würde ich gerne
über den Bus anschliessen. Bei Insta/EIB wird das schwierig oder teuer
(weil spezielles EIB-Lüftungsgerät notwendig).Beim eigenen Bus
schreibst Du ein entsprechendes Software-Modul dazu und steuerst die
Lüftung genau so an, wie Du es haben willst, inkl. Anzeige auf einem
Display, falls gewünscht.
... natürlich muss einem das auch Spass machen ...

Viele Grüße, Stefan

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

ich habe noch nichts mit dem Bootloader angestellt. Klingt aber
interessant, dass man dort schon über Kennungen entscheiden kann, ob
der entsprechende Controller programmiert werden soll oder nicht. Muss
ich mir unbedingt mal ansehen. Hast Du da eine Vorlage benutzt oder
einen völlig neu geschrieben?

>Die Parametrisierung der Funktionen erfolgt über den Bus. Auch welche
>Funktionen eine Busmodul realisiert, wird parametrisiert.

Also sendet irgendwer (ich nehme mal an, ein PC) an irgendwen
(Busmodul) z.B. eine Nachricht mit neuen Parametrierdaten. Das Busmodul
erkennt, dass das jetzt eine "Parametrierdaten-Nachricht" ist und
speichert die Daten intern (im EEPROM?) ab, richtig? Hat dann noch
jemand die Übersicht, wer was macht (z.B. in Form einer Tabelle)?

>Jede Funktion kann bis zu 16 Nachrichten an beliebige Empfänger
>schicken.

Dass es verschiedene Funktionen gibt und z.B. eine Funktion für einen
Lichtschalter intern anders funktioniert als für einen Temperaturregler
ist klar. Aber wieso bis zu 16 Nachrichten pro Funktion? Gibt es nicht
einfach jeweils eine Steuer-Nachricht: "Mach-Was(-mit-Sollwerten)"
und eine Status-Nachricht: "Bin-Fertig(-mit-Istwerten)"?

Viele Grüße
Joline

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist ja schon interessant, mit was für Kanonen hier auf Spatzen
geschossen wird.

Für Hausautomation sind die meisten Bussysteme Overkill. Die
erzielbaren Geschwindigkeiten sind völlig unnötig (muss man auf die
Änderung einer Raumtemperatur binnen 1 msec reagieren können?), die
Anforderungen an die Verkabelung sind extrem und der Protokolloverhead
ist auch nicht ohne.

Aus der Gebäudeautomatisierung kenne ich ein - proprietäres -
Bussystem, das erfolgreich eingesetzt wird und doch banal simpel ist.
Verwendet wird RS422 mit galvanisch getrennten Sendern/Empfängern. Der
Bus ist eine Zweidrahtleitung und kann bis etwa ein km Länge relativ
beliebige Verdrahtungsformen annehmen. Das geht dank der Beschränkung
auf eine sinnvoll niedrige Datenübertragungsrate, nämlich 9600 Baud.
Ein entsprechend sparsames Protokoll (mit Fehlerüberwachung) und ein
Master, der zyklisch alle Geräte am Bus pollt, genügt vollends. Das
Protokoll kann trotzdem simpel genug gehalten werden, daß mit
Controllern der MCS51-Reihe gearbeitet werden kann.
Datenreduzierend wirkt sich eine Änderungsauswertung im Controller aus
- der sendet auf Anfrage entweder "nix los" oder aber die geänderten
Daten. Da meistens nichts los ist, können so trotz Pollverfahren und
niedriger Datenrate Reaktionszeiten im Bereich von 1-2 sec erzielt
werden - was für Heimautomation genauso genügen sollte, wie es für
Gebäudeautomation im industriellen Bereich genügt.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Rufus T. Firefly ,
wäre toll, wenn du auch einen Namen nennen würdest.
Michael

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rufus:
RS485 habe ich vor einem Jahr auch mal in Erwägung gezogen, lese
einfach mal den ganzen Thread durch.
Warum mit Kanonen auf Spatzen? Den CAN-Bus kann man beliebig in der
Baudrate einstellen, von 20kbaud (beim MCP2515) bis 1Mbaud. Ist ja
niemand gezwungen, ständig Vollgas zu fahren ...

RS485 ist auf dem physikalischen Layer übrigens sehr mit CAN verwandt,
in den CAN-Anfängen wurden teilweise auch RS485-Treiber verwendet. Dass
 RS522/485 für beliebige Bustopologien spezifiziert ist, wäre mir neu,
bei 9k6 wird das wohl gehen, aber sicher nicht innerhalb der Spec (auch
CAN dürfte bei niedrigen Baudraten mit einer Sterntopographie wohl
laufen).

Ein Master/Slave-System finde ich nicht sehr sinnvoll, schon allein
wegen dem ständigen Busbetrieb (Master muss ständig alle Slaves nach
Infos pollen). 1-2 sek Verzögerung wenn ich auf den Lichtschalter
drücke, ich sehe meine Frau schon genervt den Elektriker rufen, um
konventionelle Kabel einziehen zu lassen ...

Multimaster auf RS485 funktioniert übrigens auch auf RS485
(Kollisionserkennung per Software), ist aber mit zusätzlichem
Software-Aufwand verbunden.

Viele Grüße, Stefan

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

hast Du vielleicht mein Posting weiter oben wegen des Einwurfs von
Rufus übersehen? Es interessiert mich schon, wie das funktioniert.

Joline

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joline,

keine Angst, ich habe Dich nicht vergessen - die andere Antwort ging
einfach schneller, und heute mittag hatte ich nicht soviel Zeit - so
langsam geht unsere Baustelle in die heisse Phase ...


>ich habe noch nichts mit dem Bootloader angestellt. Klingt aber
>interessant, dass man dort schon über Kennungen entscheiden kann, ob
>der entsprechende Controller programmiert werden soll oder nicht.
>Muss ich mir unbedingt mal ansehen. Hast Du da eine Vorlage benutzt
>oder einen völlig neu geschrieben?

Was der Bootloader letztlich genau macht, kannst Du völlig frei wählen.
Im Prinzip ist es ein Programm wie jedes andere auch. Der Booloader
startet direkt nach dem Reset, initialisiert dann zuerst den CAN und
wartet dann 2sek auf einen Programmierbefehl. Eigendlich recht simpel.
Es gibt bei Atmel einige App-Notes, die sich damit beschäftigen, und
hier im Forum hat Peter Danegger einen veröffentlicht. Vorlage ist das
richtige Wort, ich schaue mir solche Programme gerne an und schreibe
dann meinen eigenen Code. Das Rosinenprinzip sozusagen.

>Also sendet irgendwer (ich nehme mal an, ein PC) an irgendwen
>(Busmodul) z.B. eine Nachricht mit neuen Parametrierdaten. Das
>Busmodul erkennt, dass das jetzt eine "Parametrierdaten-Nachricht"
>ist und speichert die Daten intern (im EEPROM?) ab, richtig? Hat dann
>noch jemand die Übersicht, wer was macht (z.B. in Form einer
>Tabelle)?

Eigendlich schwebt mir ein komfortables PC-Programm vor, mit dem die
Parameter-Daten aller Module editiert und verwaltet werden. Bis jetzt
ist es aber noch nicht so weit.

>Dass es verschiedene Funktionen gibt und z.B. eine Funktion für einen
>Lichtschalter intern anders funktioniert als für einen
>Temperaturregler
>ist klar. Aber wieso bis zu 16 Nachrichten pro Funktion? Gibt es
>nicht einfach jeweils eine Steuer-Nachricht:
>"Mach-Was(-mit-Sollwerten)" und eine Status-Nachricht:
>"Bin-Fertig(-mit-Istwerten)"?

Ein Lichtschalter kann ja u.U. mehrere Lampen schalten. Für jede
schickt er dann eine eigene Nachricht los.
Eigendlich ist der CAN aber genau andersherum gedacht: Wird z.B. ein
Lichtschalter gedrückt, dann schickt er eine Nachricht los und alle,
die es wissen wollen, reagieren diese Nachricht. Es ist einfach eine
Frage der Sichtweise: sehe ich es vom Standpunkt des Lichtschalters:
welche Lampen soll er alle schalten können? -Oder vom Standpunkt der
Lampe: von welchen Lichtschaltern (oder generell Ereignissen) soll sie
geschaltet werden?
Bei beiden Sichtweisen gibt es sicherlich Vor- und Nachteile. Es sind
auch beide Varianten nebeneinander möglich und auch geplant:
Nachrichten, die einen bestimmten Busteilnehmer adressieren und
Broadcast-Nachrichten, die "an alle" gerichtet sind (falls die es
interessiert).

Bis jetzt läuft auch noch längst nicht alles (im Augenblick ist die
Zeit einfach zu knapp - neben der Baustelle). Wenn alles läuft, werde
ich es auch noch genauer dokumentieren und hier vorstellen.

Viele Grüße, Stefan

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

vielen Dank erst einmal für die Antworten. Ich bin nämlich gerade in
der Planungsphase und da interessieren mich natürlich ganz viele
Meinungen.

Im Moment stehe ich noch ein bißchen auf RS485, weil das recht simple
und preisgünstig ist und auch protokollmäßig ganz einfach zu handhaben.
Wird ja auch in der Industrie häufig eingesetzt, z.B. mit
Modbus-Protokoll.

Aber - wie Du ja auch schon vor einiger Zeit - denke ich auch über CAN
nach. Da muss eben nicht immer ein Master alle Slaves ständig pollen.
Ist eigentlich schon besser, aber auch teurer. Vom Softwareaufwand habe
ich noch keine Vorstellung. Sollte aber bestimmt auch nicht sooo schlimm
werden.

Joline

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Instabus Minimalausstattung:

1  Netzgerät 180 €
4  Eingangsmodule je 4 Eingänge (16 Eingänge ) ca. 290 €
4  Schaltaktoren je 4 Ausgänge  ( 16 Ausgänge)  ca. 480 €
1 Kleinzeugs   50 €

Lüftung über Logo und Instabusgateway. Das andere im Selbstbau - damit
auch Spaß aufkommt.
Zeitfunktionen im Logo nützen (Zufallsbeleuchtung ect.)
Eigenen CAN/485 Bus im Haus verlegen, damit man flexibel bleibt.
Würde ein Ethernetnetzwerk mit einbauen, darüber kannst du
telefonieren, CAN betreiben, PC und Internetten usw. Sieht auch fesch
aus.

Licht über Funk. War nur so eine Überlegung.


SG Josef

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joline,

was planst Du denn genau?

>Im Moment stehe ich noch ein bißchen auf RS485, weil das recht simple
>und preisgünstig ist und auch protokollmäßig ganz einfach zu
>handhaben.
>Wird ja auch in der Industrie häufig eingesetzt, z.B. mit
>Modbus-Protokoll.


>Aber - wie Du ja auch schon vor einiger Zeit - denke ich auch über
>CAN nach. Da muss eben nicht immer ein Master alle Slaves ständig
>pollen.
>Ist eigentlich schon besser, aber auch teurer. Vom Softwareaufwand
>habe ich noch keine Vorstellung. Sollte aber bestimmt auch nicht sooo
>schlimm werden.

RS485 kannst Du übrigens auch ohne Master betreiben. Kollisionen werden
erkannt, indem ein sendendes Modul die empfangenen Daten mit den
gesendeten Daten vergleicht. Gibt es Differenzen, dann liegt eine
Buskollision vor, und der Datentransfer muss später wiederholt werden.
Ähnlich läuft es ja auch bei CAN, da macht das eben schon die Hardware,
und: bei CAN gibt es bei Kollisionen einen Gewinner, d.h. das Bustiming
wird durch eine Kollision nicht belastet. Bei RS485 müssen dagegen
beide die Übertragung wiederholen. Das sollte bei den wenigen Daten auf
einem Hausbus aber kein Problem darstellen.

zu den Kosten:
einen Treiber brauchst Du in jedem Fall, ob CAN oder RS485 ist
preislich fast gleich. Als CAN-Controller benutze ich den MCP2515, den
bekommst Du für unter 2€, wenn Du ihn nicht gerade einzeln bestellst.

CAN gibt es übrigens auch rein in Software. falls Dir der CAN-Chip zu
teuer ist:
http://caraca.sourceforge.net/#intro
War mir persönlich die Preisersparnis aber nicht wert

Viele Grüße, Stefan

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema "Licht über Funk" möchte ich noch auf die recht
interessanten fremdenergiefreien Piezo-Funk-Lichtschalter von Siemens
(wenn ich mich nicht täusche) hinweisen.
Das ist im Gegensatz zu allen anderen Funklösungen sehr interessant,
weil sämtliche im Schalter benötigte Energie aus der Energie der
Schalterbetätigung entnommen wird und so keine Batterien oder sonstige
Stromversorgung erforderlich ist.

Ist leider schweineteuer, das Zeug.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"bei CAN gibt es bei Kollisionen einen Gewinner, d.h. das Bustiming
wird durch eine Kollision nicht belastet. Bei RS485 müssen dagegen
beide die Übertragung wiederholen."


Genau das ist der Kasus Knacksus !

Bei CAN wiederholen alle, sobald der Bus frei ist und der nächste
gewinnt usw. bis jeder fertig ist.
Bei RS485 muß man dagegen eine variable Wartezeit so einlegen, daß eine
weitere Kollision möglichst unwarscheinlich scheint.

Du darfst also nicht einfach die gleiche Software mit der gleichen
Wartezeit benutzen. Z.B. die Wartezeit aus Pseudozufallszahl +
Deviceadresse + Chiptemperatur oder so.
Es gibt ganze Abhandlungen und Doktorarbeiten über die Optimierung der
Kollisionswiederhohlwartezeit.


Die Arbitrierung beim CAN erlaubt außerdem die Priorisierung von
Nachrichten. D.h. auch wenn auf dem Bus ständig was am Sabbeln ist,
werden höherpriorisierte Nachrichten einfach dazwischen geschoben.

Je mehr ein dominantes Bit (0) am Anfang des Identifier ist, umso höher
priorisiert ist diese Nachricht. d.h. der Identifier 0x00000000 hat die
absolut höchste Priorität und 0x1FFFFFFF die geringste (CAN2.0B).


Es gibt aber eine Fallgrube beim CAN:

Wenn zufällig 2 Nachrichten an den gleichen Empfänger (gleicher
Identifier) gesendet werden, kommt es zu einer echten Kollision im
Datenpaket. D.h. es gibt keinen Gewinner mehr und beide versuchen es so
oft, bis der Fehlerzähler überläuft und sie sich abschalten.

Aber da hilft der Trick, daß man einfach im Identifier die
Senderadresse mit überträgt und die sollte ja immer unterschiedlich
sein.


Peter

Autor: Andreas Wienert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi alle

man kann sich ja auch gedanken über ein Funk System machen.
Empfänger und Sender mit MC ok aber wahrscheinlich werden die Endgeräte
ein Problem sein.


Grüße Andi

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

>was planst Du denn genau?

Mal was ganz Neues: Eine Hausautomation.  ;o)

Ich bin aber wie oben schon erwähnt, noch in der Planungsphase. Ich
habe schon mal probehalber auf dem Schreibtisch einen Modbus-Slave auf
RS485 laufen. Aber immer mehr tendiere ich doch zu CAN. Wenn man da
z.B. den MCP2515 nimmt, dann hat man ja sogar noch die UART als
Debug-Schnittstelle frei (Ich trace anfangs gern mit, was da so auf dem
Controller passiert ;o) ).

Insgesamt stelle ich mir eine Lösung vor, bei der es nur sehr wenig
verschiedene Hardware gibt, z.B. ein Eingabe-Modul mit Analog- und
Digitaleingängen (sollte in eine Unterputzdose passen) sowie je ein
Modul für digitale und eines für analoge Ausgänge. Prinzipiell sollte
auf jedem Modultyp die gleiche Software (Firmware) laufen, so dass man
ein Modul ohne spezielle Programmierung austauschen kann. Was das Modul
dann tatsächlich macht, soll nur von einem PC aus konfiguriert werden.

Joline

Autor: Peter Mahler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joline

>z.B. den MCP2515 nimmt, dann hat man ja sogar noch die UART als

Beim MCP2515/2510 handelt es sich um einen SPI<->CAN Controller ohne
eigenen Prozessor, daher würde ich eher einen PIC18Fxx8 hernehmen.
Dieser verfügt über einen integrierten CAN-Controller und ist
self-programmable. Über einen Bootstrap-Loader lässt sich so eine
Firmware via CAN neu einspielen.

Soweit es geht würde ich den CAN-Bus immer der
Low-Level-RS485-Kommunikation vorziehen. Der Mehrpreis kann fast
vernachlässigt werden und der Software-Aufwand reduziert sich
dramatisch.

Ich selbst plane gerade ein kombiniertes System aus Powerline
und CAN. Dabei werden Sensoren und Aktoren (Schalter und Lampen) über
einen ATtiny/PIC12..  und einem Powerline-Modem(TDA5051) in die
Netzleitung eingekoppelt. In jedem Stromkreis sitzt dann ein
'üppiger' Mikrocontroller(68HCS12) als Master, der die jeweiligen
Sensoren und Aktoren koordiniert. Diese 'üppigen' Mikrocontroller
sollen dann über CAN vernetzt werden.
Das ganze hat den Vorteil, dass ich eine konvetionelle Installation
schrittweise (...wie's der Geldbeutel mitmacht), durch ein Bus-System
ersetzen/erweitern kann.
Die ungelösten Probleme hierbei sind noch die Baugrösse der
Sensor-/Aktor-Elektronik (UP-Dose/Baldachin) und die Trennung der
Kommunikation der Stromkreise über ein Sperrfilter.

Vieleicht hat da jemand eine Idee ???

Gruss,
Peter

Autor: emax - E.Hermanns (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leuts!

Erst mal an alle: wg. Spam habe ich meine email-Adresse geändert: s.o.

Also der Thread hier hat sich ja prächtig entwickelt.

@Stefan: wie siehts denn mit Deinem Häusle aus? Kannst mir ja mal ein
paar Fotos per pm senden... Meine Hütte kannste übrigens hier sehen:

http://www.bauerbaut.de/16.0.html

Draufklicken vergrössert das Bild. (Die Website hab' übrigens ich für
das Bauunternehmen gebastelt).

Und was macht Dein Bus: läuft alles nach Plan?

Meld' Dich mal!

Grüsse
emax

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also nur mal vorweg solche steuerungen (egal was auch immer gesterut
werden soll) sind mit allem zu realisieren.
für die haustechnik jedoch gibts es bestimmte systeme welche seit
jahren angewendet werden. zu diesen zählen:
eib, sps, logo, simatic (k.a. ob´s richtig geschrieben ist), dann gibts
haufenweise feldbussysteme usw.
aber mit "lächerlichen" avr´s lässt sich auch einiges / alles
realisieren was so in den steur und regelungsbereich in bauten fällt.

und nur mal so nebenbei:
beim eib wirst du keine chips bekommen, sondern fertige module. jedoch
wirst du die ohne nötiger kenntniss und vorallem deren software (preis
für die software liegt bei 833€) nicht programmieren können

mfg ralf

Autor: Stefan Kleinwort (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Emax!

sorry für die späte Reaktion, aber im Moment habe ich nicht ganz die
Ruhe, zu schreiben ...

Vor ein paar Wochen war Einzug, der Hausbus läuft zwar schon
rudimentär, aber fertig ist was anderes. Irgendwie habe ich dieses Jahr
viel weniger Zeit als notwendig wäre .. aber das haben mir ja schon
etliche Leute hier vorausgesagt. Ich habe mal ein Bild von der
Buskoppler-Platine angehängt. Mehr kommt demnächst.

Viele Grüße, Stefan

Autor: Stefan Kleinwort (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch der Schaltplan des Buskopplers.

Viele Grüße, Stefan

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan!

Mann Mann! Das sieht ja klasse aus!

Voll professionelles Teil, Kompliment! Machst Du sowas eigentlich
beruflich?

Ich denke, da were ich noch mal per PM auf Dich zukommen....

Beste Grüsse und guten Rutsch!
Edgar

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan Kleinwort

Hm ..... ich will ja jetzt nichts sagen, aber hast du die selber
gemacht ??????????????????????????????

Ich frage so blöd, weil diese Platine komplett identisch mit dem Merten
EIB Busankoppler vom Octocolor-Programm gleicht .......
Und wenn man mich fragt (bin übrigens ausgebildeter EIB - Profi) ist
diese Ähnlichkeit zum Original doch sehr bedenklich .....

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralf

"Ich frage so blöd, weil diese Platine komplett identisch mit dem
Merten EIB Busankoppler vom Octocolor-Programm gleicht ..."

Optisch? Oder elektronisch?

Also optisch ists völlig wurscht: Unterputzdosen sind nun mal rund und
deshalb die Platine eben passend gesägt, Chips sind nunmal schwarz und
Platinen in der Regel nun mal grün.

Hm.

Wäre ja echt ne Überlegung wert, sich dieses Design (schwarze chips,
grüne platinen etc) mal ganz allgemein schützen zu lassen ;-D

Unn eleggdronisch isses hoid scho a bisserl anders, gäi?

Das ist CAN, kein EIB ....

Aber tolle Arbeit, wirklich. Vielleicht kannste ja mal ein Bildchen von
der Rückseite schicken ...?

emax

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

sieht ja Klasse aus.

Wie machst Du eigentlich einen Firmwareupdate? Direkt über den CAN-Bus
oder musst Du dann doch wieder jede Dose öffnen?

Wenn das über den CAN-Bus geht, kannst Du da vielleicht mal ein
Codebeispiel posten wie das dann so funktioniert?

Danke Hans

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans:
am Firmware-Upgrade programmiere ich im Moment.

Jeder einzelne Knoten hat bei mir exakt dieselbe Software. Was ein
Knoten genau macht und wem er was signalisiert, wird über ein
Parameterfeld festgelegt. Deshalb kann auch der gesamte Bus "in einem
Rutsch" upgedated werden. Aber wie gesagt, im Moment noch Baustelle ->
im Moment sind nur die nötigsten Dosen bestückt, und der Bootloader muss
demnächst in jeder Dose von Hand aufgespielt werden.

@Emax:
meinst Du mit Rückseite das Layout? Kann ich Dir gerne mal schicken,
aber nur als Gerber-Files, viel mehr bekomme ich aus meinem ECAD nicht
raus.

Stefan

P.S.:
Für Trolle gibts übrigens das Heise-Forum.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ emax

also bevor du nur sch**** von dir gibst, rate ich dir mal dich genauer
zu informieren - kann immerhin nichts dafür das du dich nüsse mit eib
auskennst ..... bleda noob

nur mal ne kurze erleuterung:
der eib ist ein genormtes bussystem welches laufend von der instagruppe
überwacht und kontrolliert wird. ebenso ist dieser für die entwicklung
(und wen diese es nicht selbst entwickeln) für die überprüfung und
normung zuständig.
merten ist eine europaweit (mit sitz in deutschland) riesige firma
welche sich mit unter normalen installationen der erzeugung von
buskomponenten verschrieben hat ....

diese eckige form der platine wird seit 1999 in den
"octocolorsystemen" der firma merten verwendet. ebenso sind die
buskomponenten der firma merten mit avr´s der firma atmel
ausgestattet.
weiters besitzen auch diese die nötigen can-bus anschlüsse um sie mit
anderen systemen zu verbinden und erweitern .....

und bevor du jetzt nochmal so´n sch*** von dir gibst (und das auchnoch
zweimal hintereinander) rate ich dir die klappe zu halten - immerhin
bist du nicht auf den eib spezialisiert und hast ne irre lang
ausbildung, noch wette ich das du nicht in brüssel auf dem
ausbildungskurs warst, und außerdem glaub ich auch nicht das du sonst
viel damit zu tun hattest weil sonst würdest nichtmal son schwachsinn
geschrieben haben ......

also guter tipp:
wenn man als noob schon was sagen will, dann wäre es von vorteil sich
mal genauer damit zu beschäftigen bevor man die "bappen" aufreißt !!!

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralf:

bevor Du hier noch ausfallender wirst:

EIB-Buskoppler zeichnen sich in erster Linie dadurch aus, dass sie
einen EIB-Chip onboard haben.

Eckige Formen werden von all denen verwendet, die sich das Geld für
runde Fräsungen sparen wollen.

Und Atmels oboard - wow, das sollte sich merten wirklich patentieren
lassen.

Stefan

Autor: emax (Edgar Hermanns) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralf

Sonst gehts Dir gut?

Les besser erst mal den ganzen Thread, vielleicht findste da auch was
von mir, ein JPG-Bildchen meiner eigenen EIB-Installation etwa. Habe
bislang so etwa 140 Teilnehmer in 3 Linien, eigenes Konzept, aber ja
doch, selbst programiert, klaro ....

Was uns voneinander unterscheidet ist mal mindestens die Tatsache, dass
ich meine EIB-Installation auch ohne Ausbildung hinbekommen hab. Die
Sache ist m.E. nämlich so simpel, dass die schweineteure Ausbildung
vermutlich ohnehin nur von Leuten bezahlt wird, die's ohne nie
gebacken bekämen.

Fürs neue Jahr wünsch ich Dir ein bischen mehr Erleuchting.

Bis denne
emax

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach - und was glaubst du wird wohl dein "EIB-Chip" sein ......

Das stimmt nicht ganz so wie du´s sagst:
bei "normalen" Schaltern verwendet Merten immernoch quadratische
Formen der Platine.
Beim Octocolorprogramm wird diese eckige Form verwendet, da der ganze
Schalter anders aufgebaut ist und so die Platine nichtmehr rein passen
würde.

Und außerdem habe ich ja nicht behauptet dass die Firmware die drauf
ist noch die originale ist (weil die könnt sogar ich schon ändern, und
ich bin ein totaler Elektronikneuling und somit selber ein verdammter
Noob) habe nur behauptet das die Platine von der Firma zu stammen
scheint - es ist sogar der Schaltplan komplett ident mit dem Schaltplan
den ich vor mir liegen habe (eben von Merten)

Aber ist ja sowieso egal ..... war nur ne interessensmäßige Frage.
Immerhin habe ich damit schon lang genug zu tun ....

Autor: A.Capone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
He Ralf: es ist CAN, nicht EIB!!

Capito?

@Stefan: oder hat Merten heimlich ein "CAN Over EIB" entwickelt, und
wir alle wissen das nur noch nicht?

MannMannMann...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ emax

also mal folgendes:
du hast recht ich habe mir nicht alle pot´s durchgelesen - interessiert
mich ehrlich auch nicht so wirklich.
mit ist nur die platine ins auge gesprungen und hat mich verdammt an
das zeug was bei mir im lager rumliegt errinnert - sogar der schaltplan
ist ident mit meinem ....

und außerdem muss ich dir gleich nochmal sagen halt die bappen wennst
di net auskennst; erstens habe ich schon damit gearbeitet, als es noch
keine kurse gab und das ganze system noch in kinderschuhen stand.
zweitens werden diese jeweils dreimonatigen kurse sogar von
spezialisten besucht, drittens zahlen das die firmen welche was auf
ihre "profis" halten und zu den besten gehören wollen, und viertens
dienen die kurse der weiterbildung weil es laufend neuerungen gibt, der
entwicklung und verbesserung (vorschläge werden eingebracht) der
gemeinsamen planung heikler projekte und mit heikel mein ich nicht ein
lächerliches hochhaus mit 40 stockwerken planen - das könnt jeder
vollidiot.

könnte noch ewig weiter reden - aber du solltest lieber mal bei der
firma merten in der entwicklungsabteilung rumstöbern bevor du was
sagst. - ups hab ich vergessen, da darfst du nicht rein g

naja schlag mal vor nicht weiter zu "streiten" weils sowieso sinnlos
ist - außerdem war es ja nur ne "blöde" frage, das firmware geändert
sein kann hab ich nie bestritten.

dir auch noch ein schönes neues jahr ....

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.Capone:

Mann.. jetzt fällt es mir wie Schuppen aus den Haaren: da hätte ich mir
doch tatsächlich die ganze 4-adrige Busverkabelung sparen können. Oder
verwechsle ich jetzt auch schonwas?

Stefan

Autor: Adolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja der Ralf.

Bist' an Österricher oder waas?

Unta dieesn Umständn kamma dia natüalich vezäihn!

Füad di!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralf

"sogar der schaltplan ist ident mit meinem ...."


2 CAN-Controller hängen am SPI eines Atmel, die restlichen Portpins
sind nach außen geführt und ein Spannungsregler ist mit drauf, sowie
die obligatorischen CAN-Treiberchips.

Die ganze Schaltung ist also sowas von 0815, die muß es einfach 100 mal
oder mehr geben.

Die Chips haben nun mal ihre Standardbeschaltung.

Ich kann also auch nicht nachvollziehen, ob Du vielleicht was
schlechtes gegessen hattest oder was.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan,

wenn Du auch über SPI programmieren willst, mußt Du noch an CS0 und CS1
Pull-Ups anschalten, sonst könnten sich die CAN-Chips angesprochen
fühlen und das Download stören, da die Ausgänge ja beim Programmieren
floaten.

Insofern ist die Schaltung doch nicht ganz Standard.


Peter

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
ich programmiere immer über den JTAG-ICE, aber stimmt, falls das mal
jemand nachbauen will, der kein JTAG hat, wären 2 R ganz nützlich. Wenn
es nochmal ein Update gibt, werde ich sie mit reinsetzen.

Viele Grüße, Stefan

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

die Beiträge waren auch für einen Neueinsteiger sehr interessant.
Bei all der Theorie habe ich jetzt aber mal ein paar Fragen zur
praxis.
Ich möchte über den Can Bus ein paar 8051er Systeme vernetzen.
Ich habe bisher weder einen Schaltplan noch eine passen Software
(möglichst Basic) gefunden.
Kann mir jemand helfen?

Guten Rutsch
Tobias

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle,

also erstens vorne weg. Die Koppler-Platine gefällt mir auch gut.
Habe aber trotzdem eine Frage.

Bei EIB gibt es Dosen wo der Bus und die 230V getrennt sind. Zumindest
habe ich das so in den EIB-Kursen die ich besucht habe gelernt.
Daher die Frage, wie sieht es bei der Koppler-Platine mit der
eigensicheren Trennung aus. ODer ist das nicht notwendig.

Auf Grund einiger Beiträge direkt vorne weg.
Ich habe mehrere EIB-Kurse besucht und habe auch die Zulassung die
Dinger zu programmieren.
Mich aber danach nicht mehr damit beschäftigt, daher nicht mehr so ganz
im Detail drin.
Kenne das aber auch aus Schaltschränken, das Kleinspannungen getrennt
von 230/400V sein müssen.

Danke für die Info.

Grüße
Andreas

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

bei mir ist der Bus komplett getrennt von der 220V-Seite. Zu den
Lichtschaltern gehen extra Leerrohre, der einzige Berührungspunkt ist
im Schaltschrank. Dort werden im Moment nur Relais angesteuert, also
kein Problem mit Potentialtrennung. Später will ich noch Dimmer
einbauen, da muss eben auf eine normgerechte optische Trennung geachtet
werden. Genauso beim Netzteil.

Viele Grüße, Stefan

Autor: Sebbi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

wir haben dieses Jahr (oder eher letztes ;) ) einen (relativ) neuen
Gebäudebus kennengelernt.

LCN   Local Control Network


Der Vorteil besteht, dass man die LCN Module direkt an 230V anschließen
kann!!! Keine Netzgeräte mehr. Die Kommunikation zwischen den einzelnen
Modulen geschieht über ! 1x 1,5mm² !. Es sind also keine extra
geschirmten, getrennt verlegten Niederspannungsleitungen nötig.
Die Installation ist auch recht einfach in tiefen Unterputzdosen findet
ein Standartmodul spielend platz.

Mit EINEM Modul sind schon folgende Sachen möglich:

    *  zwei elektronischen Schaltausgängen 230V, je 300VA, dimmbar oder
als Nullspannungsschalter
    * Tasteneingang für bis zu 8 Tasten oder A/D-Wandler
    * Impulsmeßeingang für Fernsteuerempfänger, Ereigniszählung
    * 100 Lichtszenen pro Ausgang verfügbar, jeweils mit
programmierbarer Helligkeit und Rampe ( Änderungsgeschwindigkeit )

die Programmierung ist sehr einfach. (Ich hatte vorher noch NIE sowas
in der Art gemacht, und nach 2-3h hatte ich meine erste
Rolladensteuerung und Lichterinstallation auf nem Probekäfig
programmiert)

schau dirs mal an,

www.LCN.DE

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm,

LCN ist proprietär, nur ein Anbieter. Wenn der pleite geht, dann ist es
Essig mit dem Nachrüsten bzw. Instandsetzen.
Ich würde das nicht riskieren, sondern lieber auf eine standardisierte
Lösung setzen oder es selbst entwickeln.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

habe mir jetzt mal Deinen Schaltplan in Ruhe angesehen.
Dort habe ich nirgendwo 230V entdeckt. Verstehe ich das richtig, daß
sich in Deiner Schalterdose dann nur Kleinspannungen befinden?

Wie machst Du es dann bei einer schaltbaren Steckdose? ODer wird die
über ein Relais vom Schaltschrank aus angesteuert?
Bin davon ausgegangen, daß sich das Busmodul auch in der Steckdose
befindet. Zumindest bei EIB hat man die Möglichkeit.

Wie verlegst Du Busleitungen und 230V. In demselben Schlitz? Wegen
Störungen.

Der Begriff "eigensicher" war Käse. Das hat was mit EX-Anlagen zu
tun. Bin nicht auf den richtigen Ausdruck gekommen, aber Du hast ja
verstanden was ich meinte.

Grüße
Andreas

Autor: emax (edgar hermanns) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas: wer lesen kann, ist klar im Vorteil.

Les doch einfach mal die Antworten auf Dein e bisherigen Beiträge.

emax

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan
Wäre es vielleicht möglich, das Layout als TIFF, PDF oder ähnliches
(nicht Gerber) einmal hier zu posten?

Danke Hans

Autor: Michael B. mi.bu(at)web,de (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan, wie hast du deine Buskoppler eigentlich verkabelt? Alles in
einer Linie (den zweiten CAN port für Stichleitungen habe ich
gesehen)?
Oder gibt es eigentlich eine Art CAN-Hub? Mir persönlich wäre es lieber
von zentraler Stelle sternförmig in die einzelnen Räume zu springen. So
wäre im Fehlerfall nicht das ganze Haus dunkel :)

Gruss, Michael

PS. Schon mal dran gedacht aus deiner Basis ein Gemeinschaftsprojekt zu
machen?

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan,
@Alle

hast Du (habt ihr ), entgegen der offiziellen Definition, einen CAN-Bus
schon einmal sternförmig verdrahtet? Ich habe es in meinem Haus so
gemacht. An jedem Ende ( 20 Knoten ) habe ich den Bus mit 12K
abgeschlossen.
Die ersten 12 Knoten ( Erdgeschoss ) laufen seit 13 Monaten ohne
Probleme. Bei der heute abgeschlossenen Erweiterung um 8 Knoten in
einem weiteren Geschoss hatte ich erst Probleme. Nun wäre es
interessant wenn auch andere schon einmal ausserhalb der Definition
Erfahrung gesammelt hätten. Übrigens läuft mein Bus nur physikalisch
als CAN ( 82C251 ). Das Protokoll ist auf meinem eigenen Mist
gewachsen. Sowohl die unteren Layer, wie auch die Anwendungen laufen
auf einem Mega8. Die neueste Version auch auf dem Mega168.

Bernhard

Autor: Florian Pfanater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe alle Beiträge sehr interresiert durchgelesen. Ich habe auch
schon ein bischen über Hausautomation nachgedacht. Meine bisherigen
überlegungen gehen aber eher auf Ethernet. Ja, ich weiß, das ist zwar
ein bischen mehr Verkabelungsaufwand (CAT5, geschirmt, usw) und die
Aktoren und Sensor-Platinen sind auch ein bischen aufwendiger aber die
Möglichkeiten (finde ich) sind einfach riesig. Und auserdem gehe ich
davon aus, dass in jedem neu gebauten Haus eine Ethernet-Verdrahtung
vorgesehen bzw. Realisiert wird. Die Konfiguration der Teilnehmer wäre
über ein WEB-Interface dann auch 'für die Hausfrau' möglich.
Ein Externer Eingriff in den Bus währe mit einem einfachen PC möglich.
Fast jede Programmiersprache hat die Möglichkeit sich per TCP/IP mit
der Außenwelt in Verbindung zu sezten. Die Trennung zwischen
verschiedenen Segmenten ist mit der Netz-Adresse auch leicht möglich.


Besonders Inspiriert wurde ich von folgender Diplomarbeit:
http://www.ifas.htwk-leipzig.de/easytoweb/php/down...

Fast das wichtigste finde ich, dass das System Dezentral aufgebaut ist.
Denn wenn der Master bei einem Zentralen System einmal ausfällt, dann
läuft gar nichts mehr.

Werde aber weiterhin 'dran' bleiben.
Gruß, Florian

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Florian,

habe ich auch drüber nachgedacht. Der Aufwand ist aber nicht zu
rechtfertigen. Mit einem Ethernetmodul kommst du außerdem fast nicht in
eine Steck- bzw. Schalterdose. Alleine der Stecker ist schon fast zu
gross. Außerdem kann man an jedes andere Bussystem einen Webserver
hängen. Somit sind die Vorteile von Ethernet relativiert. Ich habe
einen Bus der mit nur einem Treiber, einem Microcontroller und etwas
"Hühnerfutter" auskommt. Notwendige und realisierte Geschwindigkeit
10 KHz. Da liegt der Preis für ein 10 fach Tasterknoten unter 20 € (
bei kleinen Stückzahlen ). Mit Ethernet wahrscheinlich Faktor 4 bis 5.
Als nächstes wäre das Kabel zu nennen. Ich nutze billiges 4 adriges
Telefonkabel. Auch hier liegt CAT5 im Preis wieder ganz weit vorne. Das
Kosten- Nutzenproblem zieht sich durch den gesamten Bus.

Bis dann

Bernhard

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da der Thread schon ziemlich lang ist fänd ich's gut wenn man es in
einem wiki zusammenfässt. ich hab schon eins angelegt, jetzt aber neu
strukturiert:
Can-Bus:
http://www.mikrocontroller.net/wiki/CAN-Bus
Hausbus:
http://www.mikrocontroller.net/wiki/Hausbus
CAN_als_Hausbus:
http://www.mikrocontroller.net/wiki/CAN_als_Hausbus

fänd es z.b gut wenn man die erfahrungen bei der verkablung usw. dort
documentiert.
Wenn jemand sein projekt documentieren will könnte er z.b.dort auch ne
extra projektseite anlegen.

@Bernhart: hab dich zitiert hof is o.k.

Autor: Stefan Kleinwort (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sorry für die lange Verzögerung ...

@Hans:
Ich habe mal das Layout als pdf und  noch ein paar Bilder angehängt.
Folgende Bauteile-Werte haben sich mittlerweile geändert, sind aber
noch nicht im Schaltplan upgedated:
R1, R2   : 27k
R20, R22 : 1,2k
R23, R24 : unbestückt
R19      : 0 Ohm bei Elko-C11
         : 0,1 - 1 Ohm bei keramic-C11
R11-R18  : optional, normalerweise unbestückt
IC1, IC2 : TI -230, 233, oder Maxim-3,3V-CAN-Treiber

@Andreas:
siehst Du richtig, 230V und Bus sind komplett getrennt.
Natürlich geht das mit der Steckdose bei EIB theoretisch, wird aber nie
jemand machen, weil viel zu teuer (für jede Dose ein eigener Koppler).

@Michael:
Ich finde das Risiko mit einem zentralen Hub für Totalausfälle
wesentlich höher. Wenn bei mir ein Buskoppler kaputtgeht, dann
funktioniert eben diese eine Funktion nicht mehr. Der Rest läuft
weiter. Ev. läuft eine Stichleitung nicht mehr. Die CAN-Treiber sind so
konstruiert, dass sie einen amoklaufenden Busteilnehmer automatisch
abkoppeln.

>PS. Schon mal dran gedacht aus deiner Basis ein Gemeinschaftsprojekt
>zu machen?
Wenn ich komplett fertig bin, will ich das Ganze mal gesammelt
dokumentieren und ins Netz stellen. Wer vorher schon mitmachen will,
kann sich gerne an mich wenden, allerdings bin ich im Moment zeitlich
sehr knapp..

@Bernhard:
wo war denn anfangs das Problem? Kommunikationsprobleme wegen längerem
Bus?
Dass CAN bei niedriger Baudrate auch sternförmig funktionieren sollte,
dachte ich mir auch. Nur wollte ich mir langes Ausprobieren erparen,
deshalb packte ich den 2.CAN mit drauf.

@Florian:
bei Ethernet sehe ich eine ganze Menge Probleme:
 * Stromversorgung der einzelnen Komponenten
 * rein sternförmige Verkabelung oder überall Switches stehen
 * Platz in UP-Dosen wird nicht langen
 * Preis! Bernhard hat sicher sehr realistisch geschätzt!

@123:
gute Idee. Werde gerne etwas reinschreiben, aber noch nicht gleich ...

Viele Grüße, Stefan

Autor: Florian Pfanater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ok, ihr habt ich überzeugt, dass Ethernet ein bischen übertrieben,
teuer und platzverschwenderisch ist.

@Stefan Kleinwort: Das mit der Spannungsversorgung hätte ich über POE
(Power over Ethernet) gemacht. Ist aber auch aufwendig, weil laut
spezifikation die Spannung bis ~50V betragen darf. Das mit der
Sternförmien Verdrahtung stört mich eigentlich weniger, denn ich will
in meinem Haus eh in jedes Zimmer Ethenet legen, die Grundausstattung
wäre also vorhanden. Müsste dann halt nur ein bischen größer ausfallen.
Aber das ganze wird dann ja wieder um einiges teuerer.

Ich werde mich in Zukunft mehr auf CAN konzentrieren. (Mache gerade
meine Abschlussprüfung als Industrieelektroniker, danach will ich
Studieren und erst dann ein Haus bauen. Hab also noch ein bischen
Zeit.)

Vielen Dank für die ganzen Hinweise, Tips u. Kritik.
Gruß, Florian

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan,
>> wo war denn anfangs das Problem? Kommunikationsprobleme wegen
>> längerem Bus?

Ich bin mit dem Bus an seine Grenzen gestossen, da mir ein Modul des
"alten" Anlagenteils eine Datenleitung auf Masse gelegt hat und die
zweite Leitung konnte nur noch einen Pegel zwischen 0,7 und 2,1 Volt.
Nachdem ich das endlich gefunden hatte lief der Bus sauber.

Bernhard

Autor: Andreas Überall (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo emax

habe das mit den Tpuarts gelesen, hätte Interessa an 4 Stück.
Melde dich bitte, falls du noch nicht bestellt hast.

ux55

Autor: John Dietz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau Dir mal LCN an. Ich baue seit mehr als 10 Jahren EIB. Sehr gut.
Ich baue ebenfalls LCN. Sehr gut. Bussysteme haben Ihren Preis. Bieten
aber Komfort ohne Kompromisse. Zentral oder dezentral, diese Bussysteme
sind die Besten für den Heimbereich und Gewerbliche Anwendungen.

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

gibt's inzwischen was Neues zu berichten? Du hattest ja vor einiger
Zeit mal ein paar Bilder Deiner Busknoten hier eingestellt.

Wie weit bist Du mit Deiner Software? Kannst Du vielleicht schon ein
paar Codeschnipsel, die Dein prinzipielles Vorgehen verdeutlichen, hier
einstellen? Wäre prima und würde bestimmt sehr viele interessieren.

Joline

P.S. Es muss ja nicht 100% alles funktionieren und lauffähig sein. Es
reicht sicher schon, das Prinzip zu sehen.

Autor: Stefan Kleinwort (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joline,

die Basics funktionieren, aber das Administrieren des Systems ist noch
nicht implementiert, bis jetzt müssen die Buskoppler zur
Parametrisierung noch separat programmiert werden, für einen Bootloader
und eine Parametrierung über den Bus habe ich bis jetzt noch keine Zeit
gehabt.

An der Doku hapert es (natürlich) auch noch ziemlich, trotzdem hänge
ich den Source mal dazu, sorry, wenn der Code noch etwas unaufgeräumt
aussieht.

Viele Grüße, Stefan

Autor: Uwe Manz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
mir fällt auf das hier im Gros der EIB-Bus stark vorgezogen wird.
Man stelle sich folgende Fälle vor.

1.
Der Elektriker nimmt die Projektierungsdiskette/CD-Rom mit, oder die
Daten gehen irgendwie verloren (alles schon passiert). Dann besteht
theoretisch mit der ETS keine Möglichkeit mehr einen Eingriff in der
Anlage vorzunehmen. Es gibt ein Auslesemodul es nennt sich
-Rekonstruktion-, das haben wir uns mal besorgen müssen und hat damals
schlappe 500,00DM gekostet. Was solls? Dieses Modul arbeitet extrem
langsam, da es die Datenbankapplikationen fast sämtlicher Hersteller
mit sich rumschleppen muß.

2.
Ein Modul z.B: 2-fach Taster von Jung Bj. 1994 stirbt im Jahre 2002, so
wirklich geschehen, kann ja auch vorkommen. Also denkt man kein Problem,
neues Modul holen einbauen Software rein und gut. Nee stimmt nicht. Der
Ablauf heißt Modil holen, neu Applikation im Internet besorgen,
Gruppenadressen und Eigenschaften neu programmieren dann in Anlage
übertragen.
Zeitfaktor gegenüber LCN ca. mal 2.

Zusätzlicher Nachteil sind für mich die hohen Ausbildungs- und
Softwarekosten, jedes update muß gegen den Einwurf von Münzen
eingekauft werden.

Zum LCN folgendes.
LCN ist proprietär, das stimmt, hat auch seine Vorteile, man hat immer
die gleichen Ansprechpartner und ich muß sagen die Leute in der Hotline
sind absolut kompetent.
Achja wer kennt übrigens eine EIB-Hotline die nicht herstellerbezogen
ist? Ich nicht.
Außerdem hat meines Wissens nach Hr.Issendorf ein Konstrukt aufgebaut,
das solche Fälle wie Insolvenz oder Ableben des Inhabers abfängt. Wie
das genau aussieht kann und darf ich hier nicht schreiben, da mir die
genauen Insiderinfos und die Erlaubniss hierzu fehlen. Aber eines ist
sicher, die Investitionssicherheit ist ähnlich der Sicherheit zum EIB
und wächst ständig.
Zu den o.g. Themen bei LCN ist die Parametrierung in den Modulen
gespeichert und kann auch ausgelesen werden, außerdem ist es möglich
mit der LCN-Pro (Software ca 760,00&#8364;) die Daten auf Datenträger
zu bannen.
Zu den Kosten. Man bezahlt einen Grundkurs für 250,00&#8364; Dauer
10std der sollte schon absolviert werden um den Grundgedanken zu
verstehen.
Gesamtkosten 1010,00&#8364;.

Die Kosten bei EIB sind Software (professional) 895,00&#8364;.
Die Starterversion 149,00&#8364; (würde mir nicht genügen)700,00&#8364;
40std
Gesamtkosten 1595/ 1044&#8364;
Der Gewerbetreibende muß jetzt noch die Ausfallkosten während der
Unterrichtszeit hinzurechnen.

Ich möchte nicht das ein falscher Eindruck entsteht, ich war früher ein
erbitterter Gegner des LCN-Systems, musste aber mit der Zeit meine
Meinung wirklich ändern.
Was für mich noch gravierender Nachteile sind, ist zum einen die
fehlende Ethernetschnittstelle, dies kann mittels OPC-Server realisiert
werden, ist aber teuer und umständlich, sowie die Auslesegeschwindigkeit
der Software LCN-pro. Daher mach ich auch heute noch 60% meiner Progs.
mit der DOS Version.
Die Auslesegeschwindigkeit soll mit der Pro3 angeblich gesteigert
werden. Bin mal gespannt.

So ich hoffe einige Infos die zum Nachdenken anregen vermittelt zu
haben. Wer noch Fragen hat kann mich unter meiner E-Mail Adresse
erreichen.

m.f.G
Uwe Manz

Autor: Uwe Manz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anmerkung zur Info

in meinem obigen Beitrag werden folgende Zeichen angezeigt - &#8364 -.
Dies soll dem Eurozeichen entsprechen.

Ciao Uwe

Autor: eddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

wie wäre es hiermit:

http://www.dicomm.de/buildnet/bnwc.htm

das gesamte system ist bedienbar über:
pc-browser
pda
handy
telefon
etc.

keine besonderen aktoren, sondern standard-kompnenten

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ihr,

Ich mache gerade eine Projektarbeit in der Schule und bin dabei einen
IPC chip von der Fa. Beck an eine sja1000 controller anzubinden.

Jetzt ist folgendes ich habe eine kleine Platine entwickelt die mit
einem CAN-Bus versehen ist. Ich bekomme von einem externen Kältegerät
Daten zugesende. Diese Temperaturdaten werden eingelesen und ich sollte
sie via Paket(Programm) zu dem  IPC-server weiterleiten.

So nun bin ich nicht gerade fit im progammieren von Borland c.
Ich muss zum einen ein Programm schreiben das es mir ermöglicht das
Datenpaket von dem sja1000 an den server weitergeleitet wird.
Was für Befehle benötige ich überhaupt und wie kann dieses Paket auf
den Ipc senden. Habe keine Ahnung wie dies anlaufen soll.
Genauso wenig Ahnung habe ich ein Programm zu schreib um die Daten von
dem externen Kältegerät auf meinen CAN-Bus zu empfangen...gibt es da
bestimmte vorgaben...wie ich diese Daten einlesen kann...wie wird der
CAN angesprochen...fragen über fragen.

Also wenn irgendjemand hierzu mir vielleicht helfen kann wäre ich sehr
erfreut darüber oder noch fragen dazu sellen kann falls er etwas nicht
verstanden hat.

Würde mich auf eine positive antwort freuen
MFG
Marc

Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

@Eddi weißt Du was so ein Webmodul kostet?

MfG Achim

Autor: eddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo achim,

ich glaube so ca. 350.-- euro

viele grüße
eddi

Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Eddi

schnelle Antwort. Vielen Dank.

MfG Achim

Autor: Uwe Manz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht schon interessant aus,

aber da sind verschiedene Fragen zum WEB-Control

1. Wie werden die Module und deren Funktionen verknüpft ?
2. Wie ist die Verkabelung (wahrscheinlich nur im Stern ein Gerät)?
3. Beziehen sich die 4 Ampere belastbarkeit auf Gesamtlast oder pro
   Schließer und dann induktiv oder ohmsche Last (AC1/AC3)?
4. Ist es erlaubt hierüber Drehstrom zu schalten ?
5. Wie dimme ich normale Glühlampen ohmsche Last, doch nur über einen
   zusätzlichen Ferndimmer ?
6. Verschiedene Gehäuße? Auch uP Schalterdosen?
   Wie stehts mit Reiheneinbaugeräten.
7. Was sagt der VDE dazu?

Ansonsten gilt wie oben erwähnt, wirklich interessant.
Viel besser finde ich die Video- Sprechanlage übers LAN, das hätte ich
schon öfters einsetzen können.

Hast du sch on damit gearbeitet ??

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

vielen Dank. Ich werd' mir das demnächst mal reinziehen. Dass noch
nicht alles perfekt ist, ist doch klar (wenn man den Thread gelesen hat
 ;o)  ). Aber mir geht es ja auch um das zugrundeliegende Prinzip.

Übrigens, wie hast Du letztendlich Deine Elektroverkabelung gemacht?
Alle Kabel in einen Schaltschrank (bzw. mehrere) und dort die
Laststeuerung oder doch "herkömmliche" Verkabelung mit busfähigen
Lastschaltern? Deine geplante Variante war ja ziemlich aufwendig und
teuerer.

Joline

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joline,

alles geht in einen Schaltschrank. Die Lampen und teilweise die
Steckdosen werden dort mit Relais geschaltet, die Lampen-Relais sollen
im Sommer noch gegen Dimmer getauscht werden.
Eigendlich wären mir mehrere kleine Schaltschränke ja lieber gewesen,
aber der Elektriker, der die 220V-Seite bei uns verkabelt hat, hat sich
dafür nicht recht erwärmen können -> ist so aber auch ok.

Viele Grüße, Stefan

Autor: eddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo uwe,

1. mit Java-module in html, wenn ein server eingesetz wird über apis
2. stern (strukturierte verkabelung)
3. induktive lasten, immer zwei relais sind gegenseitig veriegelbar
(z.b. jalousie)
4. sowerit ich weiß > nein nur über externe schütze
5. es können nur dimmer, ll-vorschaltgeräte und elektronische halogen
mit 0-10v steuereingang angesteuert werden.
6. ist in einen uP Abzeigdose eingebaut. als aktoren (z.b. schalter)
werden schalter aus dem standard-programm verwendet. als thermostat wir
ein poti genutzt.
kann auf eine montageplatte montiert werden.
7. ist vde-gemäß

viele grüße
eddi

Autor: Uwe Manz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Eddi,

danke für die Antwort. Hört sich für mich an , als ob das System nur
bedingt einsetzbar ist.

Großer Vorteil ist halt die Ethernet- Schnittstelle.

Es hat aber meiner Meinung noch nichts mit einenm professionellen
Bussystem zu tun, sondern hat eher den Touch einer Bastlerlösung.
So haben andere aber auch angefangen und für eine Nischenlösung ist es
vorab allemal gut.

Verkaufen will die Firma offenbar wohl nicht. Hab schon mehrfach
versucht dort anzurufen, geht keiner ran.

Naja, wird schon noch klappen

ciao Uwe

Autor: Andreas B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

mit Interesse verfolge ich das Forum, da ich in der Planungsphase
unseres Einfamilienhauses stecke. Da mir der CAN-Bus
programmiertechnisch bekannt ist, ist es besonders interessant, diesen
als Hausbus einzusetzen.

Gibt es die Möglichkeit, die Platinen Deines Busknotens (über Dich) zu
beziehen?

Viele Grüße, Andreas

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

Sorry fürs Wartenlassen, ich habe mit der Installation meines neuen
Rechners gekämpft ...
ich kann Dir entweder die Produktionsdaten schicken (Gerber, das Layout
ist auf TopCAD gemacht und dessen Daten sind nirgends anders zu
gebrauchen) oder Dir ein paar Platinen aus der Testphase anbieten. Da
muss man eine Leitung noch fädeln.
Zu beachten: den MCP2515 habe ich im MSOP-Gehäuse verbaut, den gibts
nicht um die Ecke bzw. bei Reichelt. Ich brauche aber auch noch ein
paar, ev. kann man zusammen bei buy.microchip bestellen.

Viele Grüße, Stefan

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, die neuere Platinenversion kann ich Dir leider nicht abgeben,
weil die von der Anzahl bei mir gerade so aufgehen wird.

Stefan

Autor: Florian Schwab (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
per google bin ich auf Euch gestoßen.

ich bin ein elektronischer Laie und beginne nächste Woche mit dem
Hausbau. ich habe 13 Jalousien, 10 Rolläden, eine Markise und ein
Fenster mit Elektromotr, welche ich über Zeit, Wind u. Licht Steuern
möchte. darüber hinaus möchte ich gerne bei den Jalousien, welche in
einem Wintergarten sind auf die ganzen Schalter verzichten, sondern
hätte gerne eine Logik über eine Gruppenschaltung bzw. Einzelschaltung
über nur ein paar Sterungsfunktionen ausgeführt.


Kann mir da jemand helfen?

Gruß Florian

Autor: Klaus Kuhn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo *,
ich habe einen Controler von AVR Atiny15 über SPI mit einem MCP2515 CAN
bus Controler gekoppelt und das ganze mit zwei Triacs (jeder macht ca. 1
KW Schaltleistung) zur Steuerung meiner Rollos und Dunstabzugshaube
versehen. Klappt besser als erwartet. Leider sind die Platinen gefädelt
um man sollte eine vernünftige Platine haben. Preis ca. 20 Eu pro
Modul!

MFG

  Klaus

Autor: hanes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
veröffentlich doch bitte dein schaltplan und den code im wiki.

Autor: leif (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte statt Hausbus lieber ein Segelboot :-)

Autor: dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab da mal ne blöde Frage:
Wenn ich so einen Hausbus installiere, d.h. z.B. Niedervolt Taster, die
durch Elektronik (Relais) dann das Licht einschalten, irgendwo reinhaue
(Schaltschrank, irgendwo anders), dann hab ich doch bei einem Brandfall
sicher Probleme mit der Versicherung bzw. es ist zumindest nicht
erlaubt, da ich ja kein geprüfter Elektriker bin.

Autor: stromi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@dave
schau Dir die FS20- und FHZ1000PC -Komponenten an. Sind auch nicht so
teuer und haben CE-Zeichen!!!
Kannste auch noch die Heizung, Rolläden usw. beschalten.
Schaltschrankmodule gibt es auch.
'nen Link für Erweiterungen gefällig?
 http://www.ip-symcon.de/
MfG

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey zusammen!

Ich plane auch gerade einen Hausbus auf CAN-Basis.
Mich würde mal interessieren ob ihr mit euren schon laufenden System
Probleme mit Störeinstreuungen bekommen habt.

Nicht bezogen auf den Bus, da mach ich mir keinerlei Sorgen.
Eher auf dem bis zu 30cm langen Leitungsstück vom "Buskoppler" zum
Schalter (durch 3 UP-Dosen).

Besonders würds mich bei Gewitter interessieren. Nich das ständig das
Licht eingeschaltet wird nur weil ein Pin meinte nen Signal zu sehen
(Induktionsspannung auf der Leitung durch Blitz z.B.).
Software-entprellen is klar, aber habt ihr zusätzlich noch
Hardware-Aufwand betrieben? Oder einfach nur die internen Pullups und
gut?

Stefan Kleinworts´ Hardware habe ich schon mal bewundert, läuft die
schon? Problem in Bezug auf meine Frage?

thx & greetz
Danny

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

inzwischen habe ich mir mal Deine HW und SW angesehen (Man müßte viel
mehr Zeit haben...). Sieht ja schon ziemlich gut aus.

Seit dem letzten Posten ist nun wieder eine ganze Weile vergangen.
Läuft denn Dein System inzwischen einigermaßen zufriedenstellend?
Gibt's denn vielleicht schon mal was Neues zu bewundern, z.B. mit
Bootloader über CAN usw.?

Noch eine Frage:
Weiter oben schreibst Du, dass alle Buskoppler die gleichen Funktionen
implementiert haben und nur über Parameter "gesagt" bekommen, was sie
zu tun haben. In der tab.c werden dann die verschiedenen Buskoppler
parametriert, oder? Wie funktioniert diese Parametrierung?

Joline

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Danny,
zum Thema Störanfälligkeit, Tastereingänge:
ich frage die taster alle 20ms ab, wenn 3* "Taste gedrückt" gefunden
wurde, akzeptiere ich den Tastendruck. Einen falsch erkannten
Tastendruck habe ich noch nie feststellen können.

Eine zusätzliche Hardware habe ich nicht verwendet, vorgesehen sind
zwar zusätzlich Pullups, um die Tasteneingänge bei Bedarf niederohmiger
als die intern vorhandenen Pullups machen zu können, bestückt habe ich
die aber nicht.

Störungen bei Gewitter o.ä. habe ich bisher noch nicht erlebt, es ist
auch noch nie etwas kaputtgegangen (seit einem halben Jahr in Betrieb).
Die einzigen Probleme, die ich habe: beim gleichzeitigen Schalten aller
Jalousien (20 Relais gleichzeitig ein) steigt manchmal der Buskoppler
im Schaltschrank aus. Um das zu verhindern, werde ich noch ein paar
EMV-Massnahmen treffen und den Watchdog einschalten (den WDG schalte
ich meistens erst ein, wenn das Projekt praktisch fertig ist, um Fehler
nicht zu verdecken).

Viele Grüße, Stefan

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan Kleinwort

Vieleicht könntest du eien kleine Wiki-Artikel über deien Buskoppler
schreiben. den Ganzen tread durchzulesen braucht ja
Jahre.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joline,

den Bootloader habe ich leider immer noch nicht fertig. Im Moment läuft
alles ganz ordentlich, aber ohne grossen Komfort, die Heizungssteuerung
ist auch noch nicht drin, brauchen wir im Moment auch noch nicht ...
ich hoffe, im August habe ich wieder mehr Zeit dafür.

Die Software und ihre Parametrisierung beschreibe ich gerade - habe
bitte noch etwas Geduld ...

Viele Grüße, Stefan

Autor: Stefan Kleinwort (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wer versucht hat, das Projekt zu übersetzen, ist vielleicht wie Joline
am fehlenden Linker-Script-File bootloader_avr´5.x gescheitert. Sorry
dafür! Im Anhang ist es nachgeliefert.

Viele Grüße, Stefan

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

ich habe gerade mal etwas intensiver über das Projekt nachgedacht.
Dabei ist mir folgendes aufgefallen:

Wenn ich das richtig in Erinnerung habe, hast Du in Deinem Haus ja eine
Etagenverteilung. D.h. alle Kabel gehen erst einmal in einen
Schaltschrank, werden dort zusammengeführt und entsprechend
geschaltet.

Deine Buskoppler-Platine hat aber die Ausmaße, genau in eine UP-Dose zu
passen. Wieso eigentlich? Passieren nicht die eigentlichen Schalt- und
Steuerungsvorgänge im Schaltschrank? Und dann könnte die Platine ja
auch etwas größer ausfallen, oder?

Joline

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joline,

nein, ich habe in jeder Schaltergruppe einen Buskoppler. Ich möchte in
einige UP-Dosen Displays einbauen (Graphik 132*64), um z.B. einen
Raumthermostat realisieren zu können. Die Ansteuerung der Displays
funktioniert auch schon, nur eingebaut sind sie noch nicht, weil die
Mechanik eine ziemliche Bastelei ist (und ausserdem erst meine
Werkstatt einigermassen eingerichtet sein muss).

Im Schaltschrank benutze ich die gleichen Buskoppler mit einem
druntergesetzten Relais-Modul.

Viele Grüße, Stefan

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

wenn ich das jetzt richtig verstehe, brauchst Du dann für einen
"einfachen" Lichtschalter 2 Buskoppler. Einen in der Schaltergruppe
in dem jeweiligen Zimmer und einen im Schaltschrank, der dann
tatsächlich die Lampe(n) über Relais schaltet, oder?

Joline

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Aufteilung wird anders verständlicher:

Ein Lichtschalter hängt an einem Buskoppler, richtig. Je nach
Beschaltung könnte ein  Koppler auch mehrere Tasten abfragen,
entspricht dann mehreren Gebern, also: Lichtschaltern, Fensterkontakte
o.ä.

Ein Relais braucht auch einen Buskoppler. Welcher Lichtschalter dann
das Relais ansteuert ist eine Frage der Konfiguration.

Ergo: Je INPUT (z.B. Schalter) einen Koppleranschluss
      Je OUTPUT (z.B. Relais) einen Koppleranschluss

Wenn man genau einen Schalter genau einer Lampe zuordnet, stimmt Deine
Aussage. Das ist aber gerade nicht der Sinn des Busses: man hätte dann
auch konventionell verkabeln können.

Richtig ist, das ein Schalter immer an einem Koppler angeschlossen sein
muss, um am Busverkehr partizipieren zu können, genau wie auch die
Relais. aber die Zuordnung Schalter/Relais hat damit nichts zu tun.

Es können auch 3 Lichtschalter im Haus EINE Lampe ( = Relais)
ansteuern. Das wären dann z.B. vier Koppler: einen für das Relais, und
je einer für einen Lichtschalter.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joline,

an den meisten Stellen habe ich 3 UP-Dosen übereinander. Hier mal die
typischste Anordnung:

In den unteren beiden Dosen befinden sich zwei 4-fach-Taster. Ich habe
Berker-Taster verwendet, das Ganze sieht also aus wie 2 "normale"
Doppel-Lichtschalter (oben muss es davon ein Photo geben). Damit kann
man dann entweder 4 Jalousien steuern (rauf/runter) oder 8 Lampen oder
eine beliebige Mischung aus beidem.

In der oberen Dose sitzt ein Display, bedienbar über 4 kleine Taster ,
die das Display-Menu steuern (ist von der Mechanik her aber noch nicht
fertig, Display-SW läuft schon). Zusätzlich ist neben dem Display noch
ein Temperatursensor für dei Raumtemperatur eingebaut

Diese ganze Einheit wird von einem Buskoppler bedient. Ich habe tiefe
UP-Dosen verwendet, damit kann der Buskoppler hinter einem Schalter,
Taster oder Display eingebaut werden.

An manchen Stellen habe ich auch "analoge" Tastersignale über max. 4m
bis zum nächsten Buskoppler geführt, wenn dort noch ein paar Eingänge
frei waren.

Im Schaltschrank sitzen im Augenblick 3 Module, die jeweils 24 Relais
ansteuern. Jedes Modul hat einen Buskoppler. Ein Buskoppler im
Schaltschrank bedient also bis zu 24 Lampen-Relais oder 12 Jalousien
(je 2 Relais), oder eine Mischung aus beidem. Später sollen die meisten
Lampenrelais durch Dimmer ersetzt werden.

Was genau ein Buskoppler macht, kann per Parameter eingestellt werden.
Ein Buskoppler kann bis zu 32 verschiedene Funktionen (Taster,
Temp.Sensor, Relais-Ausgang) übernehmen, wobei diese Zahl im Grunde
beliebig ist.

Demnächst kommt - ganz ehrlich - eine anständige Doku, im Moment bin
ich aber mit Garten- und Terassenarbeiten ziemlich ausgelastet, sorry
...

Viele Grüße, Stefan

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@emax

Das war ja auch nur ein Beispiel, um mal nachzufragen, ob ich das
richtig verstanden habe. Ich hatte erst gedacht, ein Buskoppler handelt
Ein- und Ausgänge. Dann allerdings wäre der Bus recht sinnlos geworden
(Ausser als Verbindung zwischen den Unterverteilern).

@Stefan

Dann hast Du also pro Zimmer (meistens) genau einen Buskoppler, der die
Eingangssignale einsammelt und Ausgänge werden nur von den Buskopplern
im Schaltschrank geschaltet. Macht ja auch Sinn. Setzt allerdings auch
voraus, dass die Buskoppler alle vorhanden sind und gewisse
Grundfunktionen beherrschen, bevor man einzieht.  ;o)
Ich würde eigentlich lieber erst einmal alles hart verdrahten und dann
Schritt für Schritt mit Buskopplern ausstatten (Man will ja auch nicht
ständig im Dunkeln sitzen  ;o)  ). Aber dafür ist mir auch noch keine
vernünftige Lösung eingefallen.

Das mit den verschiedenen Funktionen der Buskoppler muss ich mir noch
mal genauer in der SW anschauen (siehe auch weiter oben). Habe aber
leider auch nicht so viel Zeit...

Joline

P.S. "Demnächst kommt - ganz ehrlich - eine anständige Doku, ...,
sorry" - Du musst Dich nicht entschuldigen. Ist ja schon prima, dass
Du Deine Erfahrungen hier im Forum einbringst.

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan: Du hast ja die Intelligenz deines Systems auf alle Knoten
verteilt. Hast du vorher mal drüber nachgedacht die einzelnen Knoten
eher "doof" zu machen und dafür eine Art "Master" zu nutzen.

Ich Frage weil im Falle einer Erweiterung/Änderung müsste ja jeder
Knoten den´s betrifft ein neues Programm erhalten. Auch wenn du nun im
Normalbetrieb nur parametrierst, sind dort ja zukünftige Erweiterungen
noch nicht programmiert, oder?

Ich bin am überlegen ob ich die Schalter etc. nur die veränderten
Signale stur zu einem Zentralgerät senden lasse. In diesem würden dann
die Verknüpfungen stattfinden und der Befehl zum Ausgänge setzen o.ä.
gesendet werden.
Ich muss dann zwar zwei Telegramme senden statt nur eines
(Schalter->Master, Master->Ausgangskarte) aber bräuchte jede beliebige
Änderung/Erweiterung nur auf dem Zentraldings ändern...

Hattest mal über sowas nachgedacht? Oder sonstige Anregungen?

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ein neues Gerät hinzukommt, muss nicht jeder Knoten neu
programmiert werden: nur diejenigen Knoten, die das neue Device
ansprechen, müssen neue Informationen erhalten, also z.B. die Taster,
die ein neues Relais schalten müssen, müssen auch dessen Adresse
kennen. Und die müssen dann ohnehin neu programmiert werden.

Alle anderen tun weiterhin das, was sie auch bisher getan getan haben:
Datenpakete schicken, die von denjenigen Teilnehmern umgesetzt werden,
die angesprochen sind.

Stell es Dir vor, wie ein Computernetzwerk: wenn im Internet ein neuer
Rechner angeschlossen wird, müssen das auch nicht alle wissen, nur
diejenigen, die darauf zugreifen wollen.

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[Single-Master Konzept]
> Hattest mal über sowas nachgedacht?
Ich antworte mal, da ich mir über sowas auch schonmal "Gedanken"
gemacht habe:
Fällt dann aber der Master aus, dann stehste im Dunkeln. Fällt dagegen
nur der Lichtschalter aus oder nur eine Lampe, dann geht der Rest noch.
Deswegen macht man sowas nicht als SingleMaster-Syetem.

Und im Falle von Erweiterungen wärs keine Neuprogrammierung (die über
ein Programmiergerät o.ä. erfolgen müsste), sondern eine
Neuparametrierung, worauf die Knoten schon in ihrer Knotensoftware
vorbereitet sein könnten.

@Stefan: Hast du inzw. schonmal so eine Art Konfigurationssoftware
zusammengebastelt? Screenshot? Wie sieht das
Benutzerkonfigurationsinterface aus?

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@emax:
Das ist mir schon klar, aber wenn man sich Stefan´s Philosophie der
einzelnen Knoten ansieht stellt man fest das alle Knoten alles können
und nur durch Parametrierung angepasst werden.

Und daher muß konsequenter Weise bspw. beim Hinzukommen einer weiteren
Ausgabebaugruppe jeder Knoten auch ein neues Programm bekommen.
Sonst hätte er sich den Umweg über diese Parametrierung ja sparen
können.

@and_ref:
Ja das mit dem Ausfall ist halt der größte Nachteil, aber wenn beim EIB
das Netzteil (oder unser speisendes Netzteil) aufraucht is auch Schicht
im Schacht...
:-) von daher denke ich das es immer einen wichtigen Punkt gibt der
alles zu Fall bringt.

Ich denke nur das eine Parametrierung die auch Erweiterungen (Hardware)
umfasst sehr aufwändig sein muss...
Ich hab schon mal versucht Stefan´s Lösung zu verstehn aber ich hab so
meine Prob´s in umfangreichen C-Programmen ... :-)

@Stefan:
Kannst du evt. in kurzen Worten zusammenfasse wie deine Parametrierung
prinzipiell läuft?
Ordnest du über eine Art Tabelle jedem Schalter ein Ziel zu? (so sahs
für mich auf den ersten Blick aus)

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann formuliere ich mal anders:

> stellt man fest
> das alle Knoten alles können
> und nur durch Parametrierung angepasst werden.

Wenn ein neues Gerät hinzukommt, WAS muss denn dann bei den bereits
installierten Einheiten angepasst werden?

Die Frage ist doch: "kommt ein neues Gerät hinzu?", und nicht "kommt
eine neue Funktion (i.e. Fähigkeit" hinzu?" Letzteres erfordert in der
Tat eine Neuprogrammierung, aber nur für diejenigen, die die neue
Funktion unterstützen sollen. Wenn beispielsweise als neue Funktion im
System "Dimmen" hinzukäme, dann müssten in der Tat alle diejenigen
Knoten neu programmiert werden, die das "Dimmen" beherrschen sollen.
Das ist auch beim EIB nicht anders: es gibt dann eine neue Applikation
für die betroffenen Bausteine.

Der scheinbare Nachteil, mehrere Bausteine neu Programmieren zu müssen,
beschränkt isch also wirklich nur auf solche Fälle, und da auch nur auf
einzelne Bausteine.

Selbst wenn man eine zentrale "Intelligenz" im Sinne eines Masters
hätte, käme man um solche Einzelprogrammierung gar nicht herum, weil ja
eine neue Funktion auch immer neue Fähigkeiten eines "finalen
Konsumers" voraussetzt, soll heissen: am Schluss muss der Koppler am
Ausgabegerät (am Aktor) die Dimmeinheit ja doch ansteuern, und
entsprechend neu programmiert werden. Solche Steuersignale direkt von
einem Master aus übers Netz an die Treiberendstufe zu senden wäre nun
ganz schlechtes Design, sowas wird üblicherweis immer "vor Ort"
eledigt, also im vorliegenden Falle im Schaltschrank direkt vom
ansteuerneden Koppler.

Das alle Teilnehmer "alles" können, ist als Option zu verstehen denke
ich, und weniger als Voraussetzung.

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@emax: mein Gedanke war das die eigentlichen Eingänge einfach nur an den
"Pseudo-Master" gesendet werden. Ein Telegramm beim betätigen, eines
beim Loslassen. Mehr nicht.

Der Master kann nun leicht schalten, oder nach 300ms das Dimmen
anfangen, oder nach 500ms den Backofen einschalten, was weiss ich....
Somit würden die Buskoppler einfach ihre Eingangssignale
weitergeben...

Und beim Dimmen beispielsweise würde der Master einfach den aktuellen
%-Wert o.ä. an den entsprechenden Empfänger senden.

Kommt nun eine gedimmte Leuchte hinzu wird im Master einfach ein
ankommendes Eingangssignal verarbeitet und an einen anderen Empfänger
gesendet (nur der %-Anteil)

Sicher ist so ein "Pseudo-Master" nich ganz im Sinne des Can-Bus und
an einigen Stellen auch nachteilig.
Aber ich kann mich irgendwie nicht damit anfreunden ein
"Gesamtprogramm" auf viele einzelne µC´s zu verteilen...

Wenns nur Licht ein/aus wäre ok... aber wenn ich an
An-/Abwesenheitskontrolle, Sprachausgabe (ja etwas übertrieben, ich
weiss - natürlich nicht über den Bus, nur die Ansteuerung), Zeitglieder
mit verschiedensten Voraussetzungen, Überwachung etc. etc. denke scheint
mir das Verteilen der Gesamtintelligenz schnell unübersichtlich zu
werden.
Da gefällt mir ein Master der das Gesamtprojekt enthält irgendwie
besser.

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da gefällt mir ein Master der das Gesamtprojekt enthält irgendwie
> besser.
Man kann das auch Mischen, indem man z.B. ein Szenarioknoten vorsieht,
der bestimmte Dimmerkombinationen ausgibt. Oder ein Timerknoten, der zu
bestimmten Uhrzeiten die Rolläden fährt usw. Aber ich würde diese
Komfortfunktionen nur in einen Master packen, wenn die
Grundfuntionalität (Rolladen muß auch ohne Master "manuell" fahrbar
sein) in den einzelnen Knoten steckt und ohne Master auskommt!

Ich weiß nicht wieso du dich so gegen die Verteilung sträubst? Eine
Konfigurationssoftware zum Bus muß sowieso her, damit isses dann auch
egal, ob du damit einen zentralen Master oder viele kleine
parametrierst. Außerdem ist die zig-mal gleiche Software einfacher zu
stricken, als eine einzelne Riesensoftware, die viele verschiedene
Funktionen unter einen Hut bringen muß.

Im verteilten Modell kannst du dazuhängen soviel du willst (bzw.
solange Buskapazität da ist) - besser skalierbar. Im Master-Modell, nur
soviel der Master verarbeiten kann.

> denke scheint mir das Verteilen der Gesamtintelligenz schnell
> unübersichtlich zu werden.
Ich sehs genau umgekehrt. :-)

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm... also ich wüsste nun nich gerade wofür ich noch extra eine
parametriersoftware einbinden muss...
naja daher hab ich stefan ja mal nach der genaueren funktion gefragt,
evt. hab ichs bisher auch noch nich richtig verstanden und am ende
gefällts mir doch ganz gut...

naja der rest ist evt. einfach geschmackssache. Ich persönliche finde
es sehr übersichtlich (von der vorstellung her) wenn alle knoten im
prinzip nur ausgänge setzen oder bei änderung eigänge senden.

somit steckt alles im "master" und ich habe in einem file alles
enthalten (schalter-knoten brauchen nie mehr angefasst zu werden) und
brauch nur verknüpfungen ändern, da der rest ja schon vorhanden ist
(einfache bitverarbeitung).

im anderen fall muss ich gleich mehrere files ändern, ein knoten
bekommt von allen anderen befehle...
und dein vorschlag die grundfunktionen direkt zu machen und
"spielerein" per sonderknoten.... puh da kommt meine welt ganz
durcheinander :-)

Evt. auch nur daher weil ich zu sehr (beruflich) an Simatic gewöhnt
bin...

ich kanns auch nich vernünftig beschreiben... aber wenn befehle nur von
einem kommen ist es für mich aufgeräumter (vom denken her) als alles
durcheinander und jeder mit jedem....

..aber evt. bekommt ihr mich ja doch noch überzeugt :-)
so schlecht kanns dezentral ja schliesslich auch nicht sein.... sonst
würdens ja nich so viele machen....

kopfzerbrech :-)

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> im anderen fall muss ich gleich mehrere files ändern, ein knoten
> bekommt von allen anderen befehle...
das muß nicht so sein. Die Parameter können ja auch im Eeprom abgelegt
werden - damit wäre keine "Fileänderung" notwendig. Die Software ist
von Anfang an darauf vorbereitet, (z.B.) die Telegramme aus dem Eeprom
zu lesen und dann zu verschicken. Die Konfigurationssoftware ändert nur
die Telegramme im KnotenEeprom (indem sie spezielle
CAN-Konfigurationstelegramme (so nenn ichs jetzt mal) an den Knoten
schickt).

Tja, das ist halt alles eines Frage des Konzepts - aber darüber
diskutieren wir ja gerade :-)

> ist es für mich aufgeräumter (vom denken her) als alles
> durcheinander und jeder mit jedem....
Hm, denk weniger an "jeder mit jedem", sondern, daß (z.B.) vom
Standpunkt Taster, dieser selbst alle möglichen Teilnehmer/Aktoren
erreichen kann. Alle Aktionen am Bus sind voneinander komplett
unabhängig. Von daher sehe ich auch keinen Vorteil, diese gedanklich in
einen Knoten zu projezieren.

> so schlecht kanns dezentral ja schliesslich auch nicht sein....
> sonst würdens ja nich so viele machen....
Vorteile:
- Ausfallsicherheit
- Skalierbarkeit/Erweiterbarkeit
- Überschaubare, begrenzte Funktionalität (Software dadurch einfacher,
stabiler, usw.)


Gaaanz anderes Konzept/Modell:
Der Taster schickt nur noch ein CAN-Telegramm: "Ich bin jetzt
gedrückt". Alle angeschlossenen Lampen reagieren darauf. Vorteil:
Kommt eine neue Lampe hinzu, so muß nur noch diese eine neue Lampe
parametriert werden ("Bitte auf gedrückten Taster xyz achten").
Nachteil: Kommt ein neuer Taster hinzu, so müssen alle bestehenden
Lampen, die darauf reagieren sollen, neu parametriert werden.
Ursprünglich ist das Konzept von CAN genau so gedacht gewesen und so
wirds ja auch im KFZ eingesetzt - ereignisgesteuert eben.

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guck, auf so ein zündfunken hab ich doch gewartet :-)

Taste1 entspricht 2 Epromstellen (Zieladresse & Info)
Eprom könnte leicht über den Bus verändert werden. Damit ist die
Parametrierung tatsächlich leicht gemacht (und ich überleg seit
Tagen... Brett vorm Kopf :-)  )

aber zur ausfallsicherheit... auch wenn ich gleich ausge-buh´t werde
:-)    die zählt für mich nicht.
der master ist ja nicht prinzipiell das schwächste glied...
es ist mindestens so warscheinlich das das Netzteil aufraucht oder ein
Bustreiber der den Bus lahmlegt oder oder oder...
und dann wird daraus auch ein "can(n)-nicht-bus" (ja flach ich weiss
:-) )

aber mal zu den Zeit oder Zustandsgesteuerten Dingen:
ein Master mit ner schönen RTC oder gar DCF-77 - einwandfreie Sache :-)

dezentral... naja

oder wenn ich eine leuchte von taster1 ein/austasten will und von
taster2 abfallverzögert (10min) einschalten will...
naja... könnte den taster so programmieren das er nach 10min das
ausschalten sendet...
oder das "relais" so das es zwischen normaler betätigung oder
verzögerungen unterscheiden kann...

macht man das denn wirklich so?

mein master hätte noch einen vorteil den ich evt. nutzen wollen würde:
er ist EINE stelle die alle Infos und alle schaltzustände hat. wenn ich
eine visualisierung einbringen möchte (oder anzeige auf dem pc oder so)
brauche ich nur ne verbindung zu ihm.
löse ich es dezentral müsste ich alle abfragen oder dauerhaft
mitlesen....

ich weiss nich warum :-)  aber irgendwie hab ich probleme mich damit
anzufreunden :-)
ich werd nochmal versuchen nachzuvollziehen wie stefan es bspw. gemacht
hat

aber du hast mich schon etwas auf den weg gebracht :-)

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noch mal ein zusatz zu meinem eben genannten vorteil "EINE stelle mit
allen Info´s":

habe ich einen Master ist eine verknüpfung

"wenn lampe1 ein und lampe2 ein und taster1 gedrückt dann lampe1 aus
und lampe3 ein"

leicht zu machen. ist es dezentral aufgebaut müste ja lampe3 auch
"gucken" ob lampe1 und lampe2 ein sind.
oder taster1 müsste gucken ob lampe1 oder lampe2 ein sind....

und das meinte ich vorhin... bei solchen sachen muss ich halt doch
verknüfungen "jeder mit jedem" und "alle durcheinander" machen :-)

zumal ich dann auch mit extendet frames arbeiten müsste um jedes mal
empfänger und absender mitzuschicken... das würd ich mir mit nem
"master" auch sparen können

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> macht man das denn wirklich so?
Das frag' ich mich auch immer... solange man aber nix besseres findet
(ich bin da sehr offen) macht "man"/ich das so.

> Taste1 entspricht 2 Epromstellen (Zieladresse & Info)
im Prinzip ja - man könnte sich das ja noch ausgedehnter vorstellen
(mehrere, dynamische Eepromstellen usw.).
Wobei: Vorsicht mit "Zieladresse". Wenn mehrere Knoten gleichzeitig
die gleiche CanId versenden gibt's Busmüll! (unwahrscheinlich aber
denkbar). So ist das CAN-Konzept eben. Deshalb am besten extended Ids
verwenden und in die CanId nicht nur die Zieladresse stecken, sondern
gleich auch noch eine Absendeadresse...

> aber zur ausfallsicherheit... die zählt für mich nicht.
:-) Das ist das einzige was zählt!!

> der master ist ja nicht prinzipiell das schwächste glied...
> es ist mindestens so warscheinlich das das Netzteil aufraucht [...]
Somit hätten wir die Ausfallwahrscheinlichkeit also schon verdoppelt.

> [...] oder ein Bustreiber der den Bus lahmlegt
Das gibt's nicht, zumindest nicht ohne vorhergehenden gravierenden
Hardwareschaden. Die Transceiver sind deutlich robuster als die
restliche Elektronik! Und für Sicherheitsfanatiker gibt's ja auch
fehlertolerante Bustransceiver - da darf eine Leitung abfaulen - CAN
geht immernoch. (Für Automationszwecke habe ich sowas aber noch nicht
gesehen).

> mein master hätte noch einen vorteil den ich evt. nutzen wollen
> würde: er ist EINE stelle die alle Infos und alle schaltzustände
> hat.
Wo ist das ein Vorteil? Wenn du einen Zugang vom PC zum CAN-Bus hast,
dann ist es prinzipiell egal, ob du einen Knoten abfragst, oder ob du
mehrere Knoten abfragst. Oder?

> ich weiss nich warum :-)  aber irgendwie hab ich probleme mich damit
> anzufreunden :-)
ich merk's schon :-) Ich will dir auch nicht meine Meinung aufdrücken,
sondern übernehm in der Diskussion nur den Gegenpart, um die Argumente
für oder gegen etwas darzustellen.

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> zumal ich dann auch mit extendet frames arbeiten müsste um jedes mal
> empfänger und absender mitzuschicken... das würd ich mir mit nem
> "master" auch sparen können
Naja, es darf halt nicht vorkommen, daß gleichzeitig mehrmals die
gleiche CanId auf dem Bus liegt. Wie du das sicherstellst ist
eigentlich egal.

> habe ich einen Master, ist eine verknüpfung [...] leicht zu machen.
Das stimmt.
Nenn' mir mal einen (weiteren) praktischen Anwendungsfall der sowas
verlangen würde oder bei dem sowas praktisch wäre. (Bin grad am
überlegen, wie ich sowas in meinem Konzept machen würde).

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du bist also immer gegen meine meinung, ja? :) scherz

mit den gleichen "Zieladressen" und evt. Busmüll hast du recht...

bei der Ausfallsicherheit kommen wir wohl nicht zusammen... :)
ok, man hat durch weglassen des Masters eine Ausfallquelle
ausgeschlossen... aber es gibt noch genu andere (wie ich finde) daher
wollte ich nur sagen das dieses Argument gegen den Master bei mir nicht
zählt... natürlich soll der bus stabil laufen :)

klar ist es egal ob ich einen oder mehrere abfrag...
aber bei einem könnt ich alles in eine message quetschen (64 zustände
darstellen)... naja ok nich der hammervorteil...

aber nun bin ich auf die stellungnahme zu meinem "zusatz" gespannt
:)

und keine angst du zwingst mir nicht deine meinung auf, ich bin mir
auch sicher das es die bessere lösung ist (wie schon gesagt sonst würds
ja keiner machen.. autos, industrie... etc)
ich möchte es halt auch gern verstehn und somit auch vernünftig zu
nutzen wissen und nicht nur nachmachen...

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja... weitere praktische anwendungsfälle...

bspw. alles was nicht ein betätigen eines schalters vorraussetzt.

ich würde gern (ist noch fern aber wenn ichs nicht ausreizen wollen
würde bräuchte ich kein bussystem im haus) meinen schichtplan
(4wochen-rhytmus) hinterlegen und dadurch zum beispiel die jalousinen
oder die zirkulationspume oder signal des telefons beeinflussen.
ok, dafür könnte ich eine art kalender machen, gleichzeitig auch noch
ne zeitschaltuhr einbauen...
wenn jetzt zu jedem zeitpunkt gleichzeitig noch ein taster die
einzelnen dinge beeinflussen soll (bspw. mal nen tag frei) dann habe
ich schon mal einen knoten der schaltstellen des ganzen hauses in
bestimmten abhängigkeiten schaltet und gleichzeitig noch auf
tastersignale wartet um wieder was zu schalten.... da is die entfernung
zum master nicht mehr gross...

naja.. und soetwas dezentral zu machen müsste ich das programm eines
einzelnen knoten (der normal nur 8 relais setzen/rücksetzen würde)
total aufblähen...  dann lieber nur ein grosses programm im projekt.

und an der stelle wird meiner meinung nach echt unübersichtlich im bus.
klar bei lampe ein/aus rollo hoch/runter - keine frage hast du recht.
aber sobald die abhängigkeiten untereinander zu gross werden...

ich überleg mir nochmal ein paar konkrete fälle evt denk ich auch nur
zu kompliziert.
hast du denn auch ein can-bus laufen? oder noch in der planung?

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich versuche mal konkrete beispiele, evt. hast du ja ne lösung aus
deinem konzept:

7h morgens UND keine Nachtschicht (entweder aus dem kalender oder am
abend vorher per schalter ausgesetzt [urlaub])-> alle rolläden hoch
7h morgens UND nachtschicht -> alle rolläden ausser schlafzimmer hoch

hierbei müssten sich zeituhr (inkl. kalender), rolläden, und ein
schalter unterhalten


ich könnte mir vorstellen bestimmte schaltvorgänge davon abhängig zu
machen ob ich (oder jemand anderes) zu haus ist.
bspw: bewegungsmelder flur UND nach 20h UND jemand zu haus -> Flurlicht
an
bewegungsmelder flur UND niemand zu hause -> Alarm

Hierbei müssten sich schon der Bewegungsmelder der
anwesenheitsschalter, die zeituhr, das flurlicht und der alarmteil
miteinander unterhalten...


und dieser verkehr der knoten untereinander würde bei entsprechend
vielen verknüpfungen entsprechend hoch werden...
aus diesem grund sagte ich immer ich würds "geordneter" mit nem
master finden.... Alle Meldungen der Knoten --> Master...verknüpfung
untereinander und mit kalender und mit zeit bzw. zeitgliedern... Master
--> Ausgänge der Knoten setzen

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber nun bin ich auf die stellungnahme zu meinem "zusatz" gespannt
Was meinst du?

> aber sobald die abhängigkeiten untereinander zu gross werden...
und genau da hakts bei meiner Vorstellung noch. Ich sehe da im Moment
nicht so viele Abhängigkeiten. Damit meine ich Dinge/Vorgänge/sonstwas,
die nur durchgeführt werden sollen, wenn eine bestimmte Bedingung
erfüllt ist, die der Knoten nicht selbst weiß, sondern erst irgendwie
erfragen muß.


Um nochmal auf dein Beispiel mit den Lampen zurückzukommen:
> "wenn lampe1 ein und lampe2 ein und taster1 gedrückt dann lampe1
aus
> und lampe3 ein"
würde ich so machen:
Einmaliges Drücken des Tasters schaltet Lampe1+2 ein, der zweite
Tastendruck schaltet Lampe1 aus und Lampe3 ein - unbedingt und ohne
vorher irgendwas abzufragen oder zu wissen. Einfach stur die Lampen so
schalten. Oder habe ich da noch einen Denkfehler drin?
 Beim dritten Tastendruck werden alle drei Lampen stur ausgeschaltet.
Wie schaltest du die Lampen wieder aus (ohne eine zu vergessen)?

Und die Geschichte mit dem 4Wochenrhythmus/Schichtplan:
Dafür gibt's z.B. Profile für alle Teilnehmer (z.B. Rolläden). Es sind
bestimmte Rolladenstellungen oder Heizungseinstellungen usw.
vordefiniert. Die "Zeitschaltuhr" (so nenn ich jetzt mal den
intelligenten Knoten, der weiß wann welche Schicht ist) schickt zu
bestimmten Uhrzeiten und/oder Ereignissen ein Telegramm in dem steht:
"Bitte jetzt Position/Situation/Szenario 'Hausverlassen' einnehmen".
Alle relevanten Knoten kennen diese Nachricht und reagieren darauf. z.B.
fahren die Rolläden in die gewünschte Position - bei
Hitze/Sonneneinstrahlung (meldet ja das Außenthermometer/Sonnensensor)
z.B. auf Halbmast, oder alle Lampen im Haus gehen aus, die Steckdosen
schalten ab, Heizung fährt runter usw. - die ganz normalen unnötigen
Spielereien eben.
Diese Profile haben natürlich alle Knoten in ihrer Software
implementiert - abhängig von der eigenen, umzusetzenden Funktion.
Ich muß keine Riesenliste erstellen, die der Master dann rumfunken muß,
sondern ich parametriere nur noch wie der Knoten auf ein Profil
reagieren soll (Eeprom).
Etwas überspitzt: Der Master muß also nicht noch den Sonnenstand
berücksichtigen oder erfragen, damit er den Rolladen entsprechend
positionieren kann - das weiß der Rolladen selbst.

Im Prinzip ist das so ein gemischtes Prinzip aus:
- Gerichteter Kommunikation (Taster sagt zu Lampe: Licht ein)
- Broadcasting der Statusinfos (Regensensor meldet: "Es regnet" und
'betroffene' Knoten/Aktoren reagieren darauf (z.B. Fenster zu)).

Sowas geht mit einem Nur-Master-System so auch wiederum nicht.

Ach es gibt so viele interessante Ansätze und Konzepte...

> ich überleg mir nochmal ein paar konkrete fälle evt denk ich auch
> nur zu kompliziert.
Meist ist das so.
Mich interessieren die Fälle, die ich noch nicht berücksichtigt habe
bzw. mit meinem Konzept nicht erschlagen kann.

> hast du denn auch ein can-bus laufen? oder noch in der planung?
Beides. Hobby halt :-)
http://www.CANathome.de

Ich habe mal diese Diskussion als Anlass genommen, das längst fällige
Update der Webseite freizuschalten...

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, hab meinen letzten Beitrag abgeschickt, bevor ich deinen letzten
(20:01) gesehen habe. Deshalb hier die Antwort darauf:

> 7h morgens UND keine Nachtschicht (entweder aus dem kalender oder am
> abend vorher per schalter ausgesetzt [urlaub])-> alle rolläden hoch
> 7h morgens UND nachtschicht -> alle rolläden ausser schlafzimmer
> hoch
Zeitschaltuhr sendet um 7Uhr an einem Wochentag: Profil "Werktag"
(die Rolläden fahren in die voreingestellte Stellung usw.). Ist aber
gerade Wochenende, so wird "Wochenende" verschickt und die
Schlafzimmerrolläden bleiben geschlossen, bis manuell....
-> Da sehe ich konzeptionell kein Problem.



> bewegungsmelder flur UND nach 20h UND jemand zu haus ->
> Flurlicht an
Der Bewegungsmelder selbst weiß, daß er erst nach 20Uhr die Lampe
einschalten darf.

> bspw: (bewegungsmelder flur UND nach 20h UND jemand zu haus ->
> Flurlicht an) bewegungsmelder flur UND niemand zu hause -> Alarm
Die Uhrzeit ist jedem Knoten sowieso immer bekannt. Der Alarmknoten
überwacht die Meldungen der Bewegungsmelder (broadcast) und kennt das
zuletzt verschickte Profil "Haus verlassen". Zusammen mit der
ebenfalls bekannten Uhrzeit schaltet der Alarmknoten dann die
Außenlichter...

Aber du hast recht, das sind Situationen, die durch logische
Verknüpfungen relativ einfach in den Griff zu bekommen wären. Meine
Beschreibung setzt aber voraus, daß die Verknüpfung in die
Knotensoftware einfließt oder gar hart reinprogrammiert wird - das ist
schlecht.

Alternativlösung: Für solche spezielleren Fälle (wie z.B.
Verknüpfungen) könnte man einen "Verknüpfungsknoten" programmieren,
der genau so funktioniert wie du beschreibst. Natürlich muß er sich die
Informationen die er dazu braucht erst beschaffen - sei es dadurch, daß
er die Infos "gebroadcastet" bekommt, oder selbst aktiv anfragen muß.

Die normale, "ausfallkritische" Funktion wäre davon unberührt und
würde natürlich weiterhin (parallel) dazu ausgeführt werden.

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach... du bist can@home :) wusst ich auch noch nich :)
du wohnst nicht zufällig in norddeutschland?

mit "zusatz" meinte ich das posting mit lampe 1,2,3... hatte sich
überschnitten weil wir gleichzeitig gepostet haben...

ich werd mich nun mal hinsetzen und versuchen ein oder zwei
knotenanwendungen zu durchdenken die bspw. auf solche broadcasts
reagieren. Ich poste nachher mal mein Ergebnis :)

noch bin ich zwar der ansicht das es dadurch nicht einfacher wird, aber
mal schaun, vielleicht ärger ich mich anschliessend auch über mich
selbst :)

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref:
mh... sendest du zyklisch ein telegramm zur aktualisierung
(zählerincrement bei telegramm) der "knoten-uhrzeit" oder wird nur
zyklisch korrigiert?

bin nun dabei mal konkrete fälle "dezentral" zu verknüpfen...

momentan überlege ich eine art "haus-statusregister" (jemand zu haus,
kein alarm, draussen dunkel, windstill) einzubauen, welches infos
enthält die alle knoten evt. brauchen können.
diese würde ich aber konsequent auch dort aktualisieren/lesen wo sie
eigentlich nicht benötig werden (gleiche software).

wobei natürlich auch eine menge stati zusammenkommen würden...

gedanke: lieber nur die wichtigen mitteilungen rausfiltern? dann müsste
ich wieder (aufwändig) parametrieren und dies gefällt mir immer weniger
da ich noch nicht weiss was ich in 5 jahren mal dazubauen werde, also
vermute ich muss ich eh wieder an die eigentliche software ran.

wie hast du denn bei dir (nur kurz zusammenfassen) parametriert? (es
fällt mir ungeheuer schwer anderer leute c-code zu verstehn... :-(  )

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> sendest du zyklisch ein telegramm zur aktualisierung
> (zählerincrement bei telegramm) der "knoten-uhrzeit"
Momentan weiß noch kein Knoten was von Uhrzeit... (soviel zur Praxis).
Ich werde aber die Uhrzeit zyklisch jede Sekunde senden (~1000CanMsg/s
@100kBit/s möglich).

> "haus-statusregister"
> wobei natürlich auch eine menge stati zusammenkommen würden...
richtig. Und diese sollten gescheit gruppiert werden. "draußen
dunkel" und "jemand zuhaus" schließen sich ja nicht gegenseitig aus.
Also werden das eine ganze Reihe von Bits... Naja, 64 Stück davon passen
ja in eine CanBotschaft :-)

> gedanke: lieber nur die wichtigen mitteilungen rausfiltern?
Nein, alles was an einen selbst adressiert ist sollte mitgelesen
werden. Wenn ein Knoten Daten an einen anderen Knoten schickt, die
dieser nicht verarbeiten kann/will, dann stimmt am sendenden Knoten was
nicht. Damit muß sich der empfangende Knoten nicht rumreissen.
Broadcastmeldungen sollten sowieso alle mitgelesen werden. Die
Applikation entscheidet dann, was davon interessant ist.

Beispiel: Zum Entwicklungszeitpunkt steht schon fest, daß ein
elektrisches Fenster sich für die Infos vom Regensensor interessiert.
Deshalb kann man das auch gleich den Empfang und die Auswertung
reinprogrammieren. Wenn in 5 Jahren noch weitere Anforderungen
dazukommen, dann mußt du sowieso die Software ändern. Heute schon
alles parametrierbar machen geht nicht.

Aber diese Nachrüstungen sind dank nachladefähigen Mikrocontrollern
(Stichwort Bootloader) ein kleineres Problem - theoretisch. Praktisch
siehts bei mir hier genauso wie bei Stefan eher mau aus :-)
Bootloader braucht man nicht unbedingt, also stellt man den erst mal
hinten an...

> wie hast du denn bei dir (nur kurz zusammenfassen) parametriert?
Die Rolläden kennen 16 verschiedene Profile auf die sie reagieren
(Nacht, Sommernacht, Morgensonne, EG lüften, Tag, usw.). Jedem Profil
ist eine Rolladenposition zugewiesen. Diese Positionen kann man zur
Laufzeit verändern. Zusätzlich ist die Umschaltzeit der Rolladenrelais
parametrierbar (aber das führt jetzt zu hier weit)...
Jeweils 6 Lichtschalter teilen sich 75 Speicherplätze für
CAN-Telegramme, die je nach Tastendruck (mehrstufig) verschickt werden.
Auch diese Telegramme lassen sich zur Laufzeit ändern.
Dimmer lassen sich z.B. in ihrer Zeit, die sie für eine
Helligkeitsänderung brauchen, einstellen (z.B. Dimmer braucht von 0%
auf 100%: <xxx>Millisekunden). Softstart/Softstopp. Die maximale
Einschaltdauer von Lampen und Relais ist begrenzbar. (z.B. das
Türöffnerrelais darf nur 2s anziehen usw.).

Auf welche CanIds die einzelnen Knoten hören leitet sich direkt aus
deren Knotennummer ab - da muß nix parametriert werden.

~100m Cat5-CAN; ~40Knoten; bisher (6Monate) keine Probleme.

> es fällt mir ungeheuer schwer anderer leute c-code zu verstehn...
damit meinst du aber nicht mich - oder hab ich den Code schon
hochgeladen? Oder hast du dich etwa bei Konzept1 verirrt?

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin immernoch am zusammenstellen einer lösung, auf jeden fall nochmals
(oder schonmal g) danke für deine unterstützung, ich hoffe ich nerv
nicht zu sehr :-)

du ´sagtest du interessierst dich für bei dir nicht berücksichtigte
dinge: ich hab deine seite nochmal umgegraben: du sendes ein telegramm
nachdem eine teste gedrückt wurde.

ich finde besser (und werde es so machen) 1.Telegramm - Taste gedrückt
2. Telegramm - Taste losgelassen
Somit kann man über eine Zeitfunktion im Empfänger so eine art
komfortfunktion wie beim auto-fensterheber machen:

wird die taste nach max. 400mx wieder losgelassen -> fahre in endlage,
stoppe bei erneutem druck (genau wie bei dir)
nach 400ms stoppt das rolo sofort (zum kurzen nachpositionieren bspw.)

ok, in diesem fall nich wirklich die verbesserung (1mal laaang oder 2
mal kurz drücken) aber evt. kann man eine solche funktion woanders doch
noch gut brauchen... nur ein gedankenanstoß

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein, "verirrt" hab ich mich nicht. ich habe bewusst dort geschaut
(anregungen besseres verständnis.. nein anfreunden mit dem dezentralen
g) und stefans code natürlich....

siehst du ein vorteil darin den dimmwert (%-anteil) im taster zu
generieren anstatt direkt im "dimmerknoten"?
ich würde/werde dies nämlich im dimmerknoten generieren, so kann
einfach auf andere eingehende befehle reagiert werden.
im anderen fall müsste ja wieder ein taster ein broadcast senden damit
andere schalter in abhängigkeit arbeiten können

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> siehst du ein vorteil darin den dimmwert (%-anteil) im taster zu
> generieren anstatt direkt im "dimmerknoten"?
Ich kann einem Dimmer einen absoluten Wert schicken (0..100%), einen
relativen (z.B. +10%) oder den Befehl "start heller; start dunkler;
stopp". Damit sind eigentlich alle Fälle abgedeckt. Und letztendlich
entscheidet der Dimmer, ob die Lampe jetzt schaltet/schalten darf oder
nicht (rein konzeptionell).

> im anderen fall müsste ja wieder ein taster ein broadcast senden
> damit andere schalter in abhängigkeit arbeiten können
Das interessiert mich noch näher. Ich sehe keinen Zusammenhang zwischen
den einzelnen Tastern.
Beispiel:
- Taster1 schaltet Lampe1+2 ein, bei erneutem Tastendruck wieder aus
- Taster2 schaltet Lampe1+3 ein, bei erneutem Tastendruck wieder aus
Drückt der Benutzer Taster1 und anschließend Taster2, dann brennen alle
3 Lampen. Drückt er jetzt T1, dann geht L1+L2 aus. Drückt der Benutzer
jetzt T2, dann geht L2+L3 aus (L2 reagiert nicht - war ja schon aus).
Alternativkonfiguration: T1+T2 schalten bei jedem zweiten Tastendruck
alle 3 Lampen aus (obwohl nur 2 Lampen damit eingeschaltet werden
können - macht ja aber nix).
Ich hoffe das ist halbwegs verständlich.

Anderes Beispiel/Konzept:
Sollen mehrere Taster gleichwertig z.B. mehrere Szenarien
durchschalten, so könnte man ja von jedem dieser Taster den Befehl
"nächstes abgespeichertes Szenario einnehmen" absetzen. Damit wüsste
jede Lampe (intern), was sie als nächstes zu tun hat. So hab ich das
aber (noch?) nicht umgesetzt. Wenn die Gesamtzahl der Szenarien z.B.
"nur" 3 ist, dann läßt sich das auch noch vernünftig bedienen. Sollen
mehrere Szenarien geschaltet werden, so würde ich das auf weitere,
unabhängige Taster verteilen. (Bedienbarkeit!)

Du merkst, so starr muß man sich garnicht festlegen. Im ersten Fall
steckt die Intelligenz im Taster (der den Dimmwert vorgibt), im zweiten
Fall (also dann wenn man mit dem ersten Fall nicht mehr weiterkommt,
oder es einfacher ist) steckt die Intelligenz im Dimmer - ganz wie es
passt. Diese beiden Konzepte können nebeneinander, gleichzeitig,
gleichwertig eingesetzt werden. Ich sehe dabei keinen Stil- oder
Konzeptbruch. Beide Konzepte haben ihre Vorteile - warum nicht beide
verwenden :-)

In der Praxis setze ich Doppeltaster ein, die ich so parametriert :-)
habe, daß der linke Taster immer ein internes "Szenario"
weiterschaltet (d.h. immer andere Lampentelegramme verschickt) und der
rechte Taster alles wieder ausschaltet. Damit ist der linke Taster
mehrfach belegt - der rechte schaltet definiert zum Ausgangszustand
zurück - auch Gäste kommen so zurecht. Links einschalten - rechts
ausschalten.

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> gedanke: lieber nur die wichtigen mitteilungen rausfiltern?

nein ich meinte damit das nur das auf dem knoten aktualisiert wird (in
sram, eeprom wie auch immer) was er für seine funktion braucht.
dem licht im gästeklo ist die aussentemp z.b. egal

mitlerweile hab ich mir erstmal ein telegramm zusammengestellt:

extendetFrame:
Stand. Identifier-> 8Bit Ziel; 3Bit Nachrichtenart (E/A Analog, Zeit
etc.. dienst nur der Vorauswahl)
ext. Identifier-> 8Bit Absender; 10Bit BroadcastID (jeder wert der als
Broadcast rausgeht hat eine unverwechselbare ID)

als Ziel für Broadcast nehme ich immer 0x00 oder 0xFF, somit muss jeder
knoten nur 2 adressen mitlesen (broadcast und direkte anrede)
das ist deshalb praktisch weil ich den MCP2515 nutze und der hat nur 2
RxPuffer und bei einem nur 2Filter.
Somit kann ich aber schön alles andere ausblenden und habe weniger
interrupts durch CAN....

ich überlege auch bei standart e/a (durch vorauswahl) kein byte zu
senden sondern die info (max 8bit) in den ext.Identifier zu packen...

was hälst du davon? ist ja schon ähnlich wie bei deiner 2. version...

ich glaub so langsam komm ich auf den geschmack ;-)

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref: ich hab mir mal deine can-vergabe genauer angesehen...

soweit ich es verstanden habe wird beim gleichzeitigen senden die
nachricht als wichtig erkann (höhere priorität) die wärend des
telegrammes als erstes ein dominantes bit sendet ("0").

wäre es dann nicht sinnvoll deine Nachricht genau andersherum
aufzubauen?
oder hast du dich nur bei der bit-nummerierung verschrieben?
(schliesslich fängst du mit bit 28 an und zählst auf 0, dann erst
folgen die datenbyte´s)

wenn du dich nicht verschrieben hast: wenn du deine
"object"-unterscheidung in den ID-Bits 0...3 sendest könntest du
sicher gehen das ein "emergency-object" in jeden fall priorität hat,
egal was später an weiteren ID-Bits noch dazuprogrammiert wird (hast ja
auch geschrieben das das bishe rnoch nicht unterstützt wird)...

oder hab ich das falsch verstanden?

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wäre es dann nicht sinnvoll deine Nachricht genau andersherum
> aufzubauen?
Nein.

> oder hast du dich nur bei der bit-nummerierung verschrieben?
Nein.

> wenn du deine "object"-unterscheidung in den ID-Bits 0...3 sendest

> könntest du sicher gehen das ein "emergency-object" in jeden fall
> priorität hat
Nein. :-)
Bit28 ist das MSB. Bit0 ist das LSB. Damit wird zuerst Bit28
gesendet...

> wird beim gleichzeitigen senden die nachricht als wichtig erkann
> (höhere priorität) die wärend des telegrammes als erstes ein
> dominantes bit sendet ("0").
So in etwa. Genauer gesagt: Derjenige der die niedrigere CanId schickt
oder anders formuliert, derjenige der beim ersten verschiedenen Bit die
Null schickt, erhält den Buszugriff.
Bei mir: Deswegen sind auch prinzipiell alle EOs (CanId 0x00nnnnnn)
grundsätzlich höher prior als die restlichen Nachrichtentypen, wie z.B.
BOs (CanId 0x10nnnnnn): 0x00nnnnnn<0x10nnnnnn egal wie hoch oder niedrig
die Ziel- oder Absendeadresse ist.

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gut, dann hab ich das schon mal verstanden...

zum msb.. lsb... peinlich ich weiss nich warum aber ich hab bei
diesem telegramm das erste mal die bits von links nach rechts gezählt..
sorry ;-)

jetzt wo ich mal eine message-unterscheidung "geplant" hab kann ich
mich doch mehr und mehr mit dem dezentralen anfreunden ;-)

spricht eigentlich was dagegen daten (1Byte Eingänge bspw.) direkt im
Identifier mitzusenden? ist evt unschön, aber eigentlich doch nix gegen
einzuwenden, oder? dann würd ich mir 1 byte sparen, da der idendifier ja
eh immer komplett gesendet werden muss...

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> mehr und mehr mit dem dezentralen anfreunden ;-)
Vergiss die Verknüpfungsgeschichte (WENN größer 20Uhr UND
Bewegungsmelder usw.) nicht, das läßt sich leichter mit einem zentralen
System machen, ohne zuvor die ganzen Daten erst erfragen zu müssen...
aber das ist wohl nur ein kleiner Punkt.

> spricht eigentlich was dagegen daten (1Byte Eingänge bspw.) direkt
> im Identifier mitzusenden? ist evt unschön,
ja, außer unschön isses nichts schlimmes.
Viele Busmonitore zeigen die CAN-Botschaften sortiert nach CanId an.
Damit erhältst du mit "jeder" Botschaft eine neue Zeile in der
Id-Übersicht... wenn dich das nicht stört.
Ich würde es dennoch nicht tun - das eine Byte reissts nicht. Unn wenn
du doch mal noch was (konzeptionell) erweitern willst...
(Geschmackssache).

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu den verknüpfungen:
naja wenn aber (wie du ja schon sagtest) jedem knoten die zeit bekannt
ist (minütliche aktualisierung reicht ja locker für zeitschaltaufgaben)
wird das problem aber auch schon wieder weniger...   damit blase ich
zwar immernoch die knotensoftware auf... aber es wäre immernoch ein
"standart-programmteil" den alle gemein haben... sowas gefällt mir
:-)

hast eigentlich mal über mein Vorschlag nachgedacht das betätigen der
taste und anschliessend das loslassen zu senden? wie in meinem
beispiel?

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich verfolge diesen Thread schon seit längerem und nun will ich auch
ein paar Fragen in den Ring werfen.

Was mir bei diesem Konzept nicht klar ist, warum muss jeder Knoten über
die ID direkt adressierbar/ansprechbar sein?
Ok, es gibt beispielsweise Diagnosebotschaften, die nur einen Knoten
betreffen, da leuchtet es mir auch ein. In anderen Branchen wird dies
so gelöst, dass beispielsweise Diagnosebotschaften ab einer bestimmten
(niderprioren) ID definiert sind. Jeder Knoten bekommt dann eine eigene
Diagnosenummer, die auf diese Basis-ID summiert wird.
Wenn ich mir jetzt einen Knoten vorstelle, der irgendwelche Taster
auswertet. Bei einem Tastendruck wird eine vordefinierte Botschaft mit
situationsabhängigem Inhalt (parametrierbar) verschickt. Der
Nummernkreis der ID bezieht sich auf eine bestimmte Etage oder
Unterverteilung (ID200-ID299 im 2. Stock). Über die ID kann nun die
dazugehörige Unterverteilung angesprochen werden (oder ein Gateway, das
dann die Nachricht in ein anderes Stockwerk weitervermitteln kann).
Aktuatoren besitzen doch nur die Knoten die im Schaltschrank sitzen,
nur diese können aktiv werden (Relais schliessen/öffnen usw.) Würde es
dann nicht Sinn machen, wenn die Knoten im Schaltschrank auf alle
Botschaften in einem bestimmten ID Bereich mithören und diese dann
auswerten? Warum sollte ein Knoten mit Tastern einen anderen mit
Tastern aktiv ansprechen können?
Informationen, die für alle interessant sind, werden in einem
Nummernkreis verschickt, der von allen Knoten eingelesen wird (Zeit,
Temperaturen, usw..)
Um bei einem Taster-Knoten zu bleiben, wenn dieser keinen Tastendruck
registriert, könnte dieser in einen Energiesparmodus fallen...

Es kann natürlich auch gut sein, dass ich wg. meiner beruflichen
Historie und meiner täglichen Arbeit hier etwas um das Eck denke :-)

Viele Grüsse
Volker

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Volker: also meine gedanken unterscheiden sich momentan nicht allzu
sehr von deiner darstellung, bis auf eine ausnahme:

ich möchte/werde nicht strikt nach Sensorlnoten und Aktorknoten
unterscheiden.
Wird an ein Knoten (an dem normal nur Taster hängen) doch mal ein LCD
angeschlossen und ne IR-LED um den TV zu steuern oder weiss der teufel
was möchte ich das es vorbereitet ist.
Und somit wird in jedem Knoten die Grundfunktion senden/empfangen zu
allem und jedem möglich sein müssen.

Auch Aktoren die ja eigentlich nix zu melden haben können aber einen
Sicherungsfall weitermelden (bspw. auch auf das eben erwähnte, am
Tasterknoten hängende Display) und somit wäre eine Kommunikation Aktor
-> Sendo nötig.

Und um diese flexibilität zu erhalten ist es m.m.n. nötig das auch zwei
Tasterknoten (eben alle) miteinander reden (können)

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dany P.
> das betätigen der taste und anschliessend das loslassen zu senden?
Spricht nix dagegen, klingt gut; so kann man das machen.


@Volker
> Was mir bei diesem Konzept nicht klar ist, warum muss jeder Knoten
> über die ID direkt adressierbar/ansprechbar sein?
Per Definition ist das bei diesem Konzept so. Man will gezielt
Informationen von einem Absende- an einen Zielknoten schicken. Das
bedingt nunmal, daß die CanIds als "Adressen" verwendet werden.
Andere Konzepte gehen da anders vor. Stichwort: Ereignisorientiert.
Dabei wird nur mitgeteilt, daß jetzt ein bestimmtes Ereignis vorliegt
(z.B. der Taster ist gedrückt oder die Tür ist geöffnet).

> In anderen Branchen
Von welchen Branchen sprichst du? Automobilindustrie? Da sind das ja
ganz andere Voraussetzungen. Da ist zum Entwicklungszeitpunkt schon
jede Funktion bzw. jeder Netzteilnehmer und jede CanBotschaft bekannt.
Da kommen nicht plötzlich noch 2 "Taster" dazu. (Stichwort:
nachträgliche Erweiterbarkeit). Außerdem ist jede Steuergerätesoftware
unterschiedlich - bei der Hausautomation will man viele gleiche Knoten
verwenden, die gleiche Aufgaben haben. Das führt zu anderen Konzepten.

Außerdem sagt ja niemand, daß man das nicht beides gleichzeitig
verwenden kann/darf. Für Ereignisse oder Broadcastnachrichten mach'
ich das ja auch.

> (ID200-ID299) Über die ID kann nun die dazugehörige Unterverteilung
> angesprochen werden
Wenn mehrere Taster die gleiche Lampe schalten wollen, und gleichzeitig
gedrückt werden, dann liegt zum gleichen Zeitpunkt, die gleiche CanId
auf dem Bus -> nix gut.

> Aktuatoren besitzen doch nur die Knoten die im Schaltschrank sitzen
Ich denke, daß es keinen Sinn macht, die Hardware nach Eingabe- und
Ausgabehardware zu trennen. Deshalb kann jeder Knoten alles (so wie
Dany P. das oben schon ausführt).

> Informationen, die für alle interessant sind, werden in einem
> Nummernkreis verschickt, der von allen Knoten eingelesen wird (Zeit,
> Temperaturen, usw..)
Ich filtere in der CAN-Hardware nicht nach bestimmten CanIds, das
passiert rein durch Software - diese soll entscheiden, ob interessant
oder nicht. Hab das mal eben grob überschlagen. Ich schätze, daß die
Software innerhalb von 20µs erkennen kann, ob das Telegramm interessant
ist oder nicht und dieses auch innerhalb dieser Zeit
'einlagert'/puffert. Bei _max._ 1000 eintreffenden Telegrammen pro
Sekunde (@100kBit/s) sind das 20ms. -> Das wären dann 2%
Prozessorauslastung. Wenn die CanRx-Interruptzeit noch kürzer sein
sollte, dann entsprechend weniger.

> Um bei einem Taster-Knoten zu bleiben, wenn dieser keinen
> Tastendruck registriert, könnte dieser in einen Energiesparmodus
> fallen...
Das ist ein weiteres interessantes Thema. Aber da 'wir' ja einmalige
Telegramme verschicken (nicht zyklisch wie im Auto), ist das mit dem
Energiesparmodus so eine Sache... Aufwachen durch das CanTelegramm: ja.
Aber auch gleichzeitig dieses CanTelegramm korrekt mitlesen: nein.
 D.h. man müsste ein Wecktelegramm schicken, bevor die eigentliche
Information übertragen wird. Heißt das, daß vor jeder Übertragung ein
Wecktelegramm stehen muß, damit ein evtl. eingeschlafener Knoten
rechtzeitig wach wird? Nein, das ist unpraktikabel.
Eine Alternative wäre alle Knoten gleichzeitig einschlafen zu lassen.
Das muß dann aber irgendwie sichergestellt sein, daß das sauber
funktioniert... wenn einer nicht mitmacht, dann schläft keiner jemals
ein. Außerdem ist da schon ein gewisser Aufwand erforderlich, damit die
Knoten sich da alle einig sind. Du weißt wahrscheinlich welcher Aufwand
da im Auto betrieben wird... :-)

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref: du arbeitest ja mit anderer hardware, ich hab mir nicht die
mühe geguckt nachzuschauen, hat dein integrierter can-controller auch
filter und du nutzt diese einfach nicht, oder hat er die gar nicht?

ich hab nämlich für mich entschieden: jeder can-controller gibt nur
dinge weiter die entweder direkt an ihn gerichtet sind oder broadcast
(adresse 0x00... willkürlich definiert).
die überlegung war:
das was der can-controller schon kann brauch ich nicht programmieren
(und weniger prozessorarbeit, nur prinzipiell, du hast ja schon
vorgerechnet das es gering ist)
und sollte ich mal andere telegramme haben wollen, kann ich das ja noch
per software ändern...

über nen energiesparmodus hab ich auch mal kurz nachgedacht, aber aus
den gleichen gründen wie du verworfen... war mir zu heikel und
unzuverlässig (und wenn zuverlässig dann zu zeitintensiv)

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Danny P.
> @Volker: also meine gedanken unterscheiden sich momentan nicht allzu
> sehr von deiner darstellung, bis auf eine ausnahme:

Ok, langsam synchronisiere ich mich auf :-)

@and_ref
> Per Definition ist das bei diesem Konzept so
Ich finde diesen Ansatz durchaus interessant die CAN IDs als Adressen
zu verwenden. In meiner Welt kam das bislang so nicht vor :-)

> Automobilindustrie?
Bingo! :-)

> Da ist zum Entwicklungszeitpunkt schon jede Funktion bzw. jeder     >
Netzteilnehmer und jede CanBotschaft bekannt.
Das wäre des Entwicklers Paradies :-) Problematisch ist immer der
Verbau von vielen Sonderausstattungen. Die Nachrichtenkataloge ändern
sich aber zum Glück nicht so dynamisch, während der Entwicklung ist das
aber durchaus normal.

> bei der Hausautomation will man viele gleiche Knoten verwenden, die >
gleiche Aufgaben haben
Ich glaube, das ist der zentrale Punkt der Diskussion

> Wenn mehrere Taster die gleiche Lampe schalten wollen, und         >
gleichzeitig gedrückt werden, dann liegt zum gleichen Zeitpunkt,   >
die gleiche CanId auf dem Bus -> nix gut.
Das wäre wirkich nicht gut, mein Ansatz ist aber der, dass im
Extremfall einem Taster eine CAN ID zugeordnet ist und somit
Eindeutigkeit herrscht. Ich würde also meine Informationen komplett im
Datenteil der Botschaft unterbringen. Bei 8Byte und der Möglichkeit
Multiplex Botschaften zu schicken ist das Ende nicht so schnell
erreicht.

Zum Energiesparmodus:
Wenn ein Knoten eingeschlafen ist, dann muss er erst wieder durch den
Bus geweckt werden. Der MCP2515 puffert doch die Botschaften solange
bis sie durch den uC abgeholt werden. Das sollte reichen um den
Controller aufwachen zu lassen (bei internem CAN kann das anders sein).
Also dürften keine Weck-Botschaften nötig sein? Wenn ich jetzt wieder an
den Taster-Knoten, meinetwegen mit Display, denke, dann würde das die
Funktion nicht beeinträchtigen. Die Frage ist, ob ich ständig
allgemeine Infos (die aus den Broadcast Nachrichten kommen) auf dem
Display aktualisieren muss... hmm...

Bei einfachen Taster-Knoten sollte das aber funktionieren, zumindest
sehe ich gerade keinen Grund warum das nicht klappen sollte :-) Wenn
der Knoten aber noch andere Aufgaben zu erledigen hat (das mit der
IR-Led war ein gutes Beispiel), muss ich mir das nochmal durchdenken.
Sobald ich meine reale Hardware auf dem Tisch habe werde ich das
probieren, mit CANoe ist das ja kein Problem :-)

Den Schuh eines kompletten Netzwerkmanagements würde ich mir nicht
anziehen. Das kann nur schief gehen... es gibt zwar tolle Konzepte im
Automobilbau, allerdings zeigen auch die wiederkehrenden
Pannenstatistiken des ADAC, dass eine leere Batterie einer der
Hauptgründe für Liegenbleiber ist... trotz NM :-)

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dany P.
> hat dein integrierter can-controller auch filter und du nutzt diese
> einfach nicht
So isses.

@Volker:
>> Da ist zum Entwicklungszeitpunkt schon jede Funktion bzw. jeder
>> Netzteilnehmer und jede CanBotschaft bekannt.
> Das wäre des Entwicklers Paradies :-)
Das ist Realität! :-)
Kommen neue Nachrichtenkataloge, so werden alle (betroffenen)
Netzteilnehmer neu parametriert. Oder deutlicher: Ohne Umflashen keine
Unterstützung der neuen CanBits... das wollen wir im Haus vermeiden.

> mein Ansatz ist aber der, dass im Extremfall einem Taster eine CAN
> ID zugeordnet ist
Macht aber Umkonfigurieren der Taster/Lampen-Zuordnung extrem
kompliziert. Außerdem kannst du so nicht "mehrstufige" "Schalter"
realisieren - à la: erster Tastendruck schaltet diese Lampen, zweiter
Tastendruck diese, dritter wieder aus... bzw. das wird extrem
undurchsichtig. Du könntest dir ein Generierungs-/Parametrierungstool
basteln, das den kompletten Bus für dich kennt und abstrahiert... dann
aber viel Spass beim CAN-Debuggen. Du weißt ja schließlich nicht, was
die gerade verschickte Botschaft eigentlich bedeuten soll, ohne den
genauen inneren Zustand aller beteiligten Lampenknoten zu kennen... und
dann das Problem, daß 'irgendwie' mal ein Lampenknoten resettet,
während der andere weiterläuft... das wird dann unsynchron. Im
schlimmsten Fall geht's Licht garnimmer aus, weil z.B. beide
beteiligten Lampenknoten die Info "Taster wurde gerade gedrückt" aus
unterschiedlichen Zuständen heraus, unterschiedlich bewerten... :-)

[Busruhe]
> Der MCP2515 puffert doch die Botschaften [...] (bei internem CAN kann
das anders sein)
Isses auch - zumindest wenn die CAN-Hardware im µC aus Stromspargründen
(schon) abgeschaltet ist.


In welchem Bereich arbeitest du? SG-Entwickler SW/HW? "AntriebsCAN"
oder "InnenraumCAN"? Und wie/was möchtest du schönes (hobbymäßig)
automatisieren?

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist Realität! :-)
Wo? :-) Meine Erfahrung zeigt, dass Nachrichtenkataloge durchaus nicht
vollständig sind=> kurzfristige Änderungen der SW aber ohne flashen
gehts dann nicht weiter, denn Funktions- und Schnittstellenänderungen
ziehen das so nach sich... Im Hausbereich schwebt mir eine
parametrierbare Tabelle für jede CAN Botschaft vor. Es könnten auch
mehrere situationsabhängige sein.

> Macht aber Umkonfigurieren der Taster/Lampen-Zuordnung extrem
kompliziert
Der Verdacht liegt nahe... ich glaube, ich laufe in ein Problem, wenn
ich über einen Taster Lampen in verschiedenen Etagen schalten möchte.
Zumindest kann ich das mit einer Botschaft nicht erschlagen. Im
Extremfall muss ich für jeden Tastendruck auch mehrere Telegramme
verschicken. In meinen Überlegungen kam bislang ein mehrfaches Tasten
drücken für unterschiedliche Szenarien nicht vor, mal von ein/aus
abgesehen... länger gedrückt wäre dann für ne Dimmer Funktionalität
vorgehalten, der Knoten wertet die Dauer des Tastendrucks aus und
übermittelt diesen zyklisch an den zuständigen Dimmerknoten im
Schaltschrank. Ich möchte aber in jedem Fall vermeiden, dass ich neben
jeden Taster einen Belegungsplan kleben muss... es muss einfach alles
bedienbar bleiben :-)
Ich seh schon, über das Nachrichtenkonzept muss ich mir noch eingehend
Gedanken machen. Die Komplexität meines Ansatzes war bei weitem noch
nicht so hoch :-))
Was habt/wollt ihr alles automatisieren, bzw. über den Bus steuern? Mit
der Knotenhardware bin ich soweit durch, ich muss mir aber noch auf
jeden Fall Gedanken über wohnzimmertaugliche Sensorik machen ... wie
habt ihr das gelöst (Bewegungsmelder, Temperatursensoren,
Fensterkontakte usw, der WAF lässt grüssen...)?
Die Parametrierung der einzelnen Knoten wollte ich mit CANoe erschlagen
(im Hinergrund steht dann ne CAN Datenbank, bzw Nachrichtenkatalog). Das
eignet sich auch prima dafür den Bus zu debuggen/tracen/simulieren und
aufzuzeichnen :-))
Mal schaun, wenn die Zeit bleibt, mach ich doch noch ne Requirement
Analyse mit DOORS und pflastere das Ganze danach in UML :-)

[Motivation]
Bei mir steht auch ein automatisiertes Haus im Vordergrund. Ideen gibt
es hierfür viele, aber bislang hab ich mich mehr mit der Umgebung und
den prinzipiellen Problemen beschäftigt (CAN Anbindung, Hardware, die
in ne UP Dose passt, usw...) So langsam rückt die SW in den Vordergrund
und ich muss versuchen meine Ideen und Gedanken zu strukturieren und in
SW zu pressen. In 3-4 Monaten sollte eine Basisfunktionalität
erreichbar sein (wenn nun mal die HW läuft), denn Ende September kommen
die Bagger :-)
Ich arbeite übrigens in der Automobilentwicklung =>
sicherheitskritische Funktionalität, die auch mit dem Antriebs-CAN
verbunden ist. Näheres erzähle ich dir gerne per PM :-)

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Volker: ein vorschlag um die länge des Tastendrucks auszuwerten:
Ich hatte weiter oben schon beschrieben das ich ein Telegramm beim
"drücken" und eines beim "loslassen" senden werde, also im prinzip
immer nur die -änderung- eines schalters (ähnlich "make"/"break"
bei der tastatur).
jeder knoten den es interessiert kann dann selbst mitzählen oder halt
auch nicht...

so kann man auf das zyklische senden der schalterstellung verzichten,
denn das werden da doch schon ne hand voll telegramme wen man schnelle
reaktionszeiten haben möchte.

klar das bringt den bus nicht an seine grenze... aber... naja..
vielleicht isses ja was für dich :)

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Danny P.
Das ist auch ne interessante Möglichkeit :-) Wenn dann aber mal eine
Botschaft nicht durchkommt, gibt es interessante Effekte :-) Ich werde
diese Möglichkeit bestimmt in Betracht ziehen.

>jeder knoten den es interessiert kann dann selbst mitzählen oder halt
auch nicht...
Das würde aber dann bedeuten, dass du deine einzelnen Knoten nicht
direkt adressierst? Also Informationen auf den Bus legen, die Knoten,
die es interessiert, sollen sich die Info holen?

Wie sieht dein Konzept bislang aus? Wie machst du alles Wohnzimmer
tauglich? Was möchtest du alles automatisieren/steuern?

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@volker: ich bin etwa im gleichen stadium wie du: hardware (busankoppler
für die up-dose) läuft, nun kommt die software :-)

zur wohnzimmertauglichkeit:
ich werde an jeder schaltstelle ein busankoppler (mega8 + mcp2515)
hinter den schalter in die up-dose setzen
ich stelle mir vor 2 4-fach-taster (doppeltaster, mit mittelstellung)
einzusetzen (8 tastkontakte sollten reichen g).
an der zimmertür die obligatorische steckdose unter die schalter.
an geeigneten stellen eine blindkappe zur aufnahme von ir-empfänger,
ir-sender, lichtsensor, temepraturfühler oder display... (nicht alle
überall)
somit wäre auch im wohnzimmer alles vom sofa per fernbedienung
schaltbar und man hat (finde ich) hohen komfort ohne weitere schalter
am sofa.

in einer uv (jede etage eine eigene) würden dann die schaltgeräte
sitzen und per 12/24 volt-relais den 230v-teil schalten.
zum dimmen suche ich noch geeignete hardware die ich einfach ansteuern
kann.
ich bin selbst auch elektroniker und habe sehr regelmässig auch mit
allen entsprechenden spannungen zu tun, dennoch  möchte ich (echt nur
aus versicherungsgründen etc.) den "leistungsteil" als vde-gerechte
geräte einsetzen.
normales relais wird dem ja gerecht, lediglich die dimmerhardware....
dimmbare (0-10v) elektronische vorschaltgeräte gibts ja, aber n
"normalen" dimmer... noch nix gescheites für hutschienenmontage
gefunden...

was will ich steuern:
rolläden, licht, steckdosen, zirkulationspumpe, garagentor, bad-lüfter,
alarm (alles auch in abhängigkeit mit tageszeit, anwesenheit,
schichtplan etc.) eigentlich alles was strom hat :-)   denn ich denke
wenn man sich schon die mühe mit so einem system macht dann auch zu
100%

rolläden und lichtleitungen werde ich direkt in die uv zu den
schaltgeräten ziehen. weiterhin werde ich aber leitungen "tot" mit
einziehen (z.b. schalter -> lampe etc.) um zu jederzeit auf
"standart"-elektrik zurückrüsten zu können.
und zwar nicht weil ich angst vor ausfällen habe (dann würd ichs gar
nicht erst machen) sondern weil ich bei einem evt. hausverkauf (man
weiss ja nie was man in 7 jahren will/kann... o.ä.) normale elektrik
verkaufen möchte und nicht mein can-eigenbau. (1. will ichs behalten
und 2. wer soll da mal was heile machen? g )

adressieren:
doch, ich würde (momentan g) direkt adressieren. lediglich allgemein
wichtige dinge (temp. zeit etc) würde ich an alle senden.
der mcp2515 hat in jedem empfangspuffer mindestens 2 filter, somit kann
den can-controller gleich filtern (direkte botschaften an eigene adresse
und "an-alle-meldungen", der rest wird dem Mega8 gar nicht gemeldet.
erleichtert die software ein wenig finde ich und wenn der das schon
kann, was soll ich mich noch drum kümmern :)

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir schauts gerade so aus, dass meine zum Teil fliegend aufgebaute
Schaltung zu funktionieren scheint. Einige Teile der Sensorik
funktionieren rudimentär in Einzelprojekten. Mein Layout für die UP
Hardware ist soweit auch fertig, ein letztes Review mach ich am
Wochenende und anschliessend will ich mir ein paar Prototypen fertigen
lassen (wo hast du wieviele machen lassen?). Nach hoffentlich
erfolgreicher Inbetriebnahme der HW (die übrigens auch mit nem MCP2515
arbeitet, aber als Controller entweder nen Mega16L oder Mega32L - je
nach Notwendigkeit bekommen wird) geht es daran die SW für die
Busknoten zu hacken. Meine Schalter, ebenfalls 4-fach Taster, hab ich
als max. 4x4 Matrix verschaltet, die bei Bedarf auch nen Interrupt auf
dem Mega generieren kann.

Der Aufbau ist ganz ähnlich wie bei dir. Die max. 4 4fach Schalter
hängen an einem UP-Busknoten (bei Bedarf könnte ich das über ne
Stifleiste erweitern, oder an diese eben die Sensorik verschalten). Die
Busknoten sind etagenweise verbunden, nur die HW im Schaltschrank (die
auf den UP-Busknoten basiert) hat zwei CAN Anschlüsse und fungiert
daher auch als Gateway zu den anderen Etagenverteilungen. Ich will auch
den 230V Teil komplett von meiner Bus Installation trennen und
dementsprechend lasse ich das auch vom Elektriker machen. Geplant ist,
dass er alle Steckdosen auf Einzelklemmen in der Unterverteilung führt,
somit habe ich auch später noch alle Freiheitsgrade. An eine redundante
Verkabelung hab ich bislang nicht gedacht, zudem wird alles in
Leerrohren verlegt, sodass eine ev. Rückrüstung auf eine
Standardverschaltung nicht ganz ausgeschlossen ist.

In der Etagenverteilung sitzen dann, wie bei dir, auch die Relais und
Dimmer. Die Relais sind ja kein Problem, aber an Dimmern hab ich auch
noch nichts passendes gefunden. Wenn dir da etwas über den Weg laufen
sollte... :-)
Einer der nächsten Schritte ist dann auch die Verteilung der Buskoppler
und Sensorik im Haus zu planen. Ich glaube, das wird nochmal ein
schwerer Schritt. Vor allem bei den Fensterkontakten und der
zusätzlichen Sensorik hab ich noch etwas Bauchschmerzen. Die Frage ist
immer, wie verteile ich die Buskoppler effektiv ohne zu den Sensoren
all zu lange Leitungen legen zu müssen. Eine stete offene Frage ist
immer auch die nach den Gehäusen. Der sichtbare Teil der Sensorik
(Bewegungsmelder etc.) darf keinesfalls gebastelt wirken... so suche
ich dahingehend auch noch ein "professionelles" Gehäuse für ein
240x128 Grafik Display, welches ich noch mit nem Touchpanel ausrüsten
möchte...

Ich hatte auch mal angefangen jeweils 8 Taster mit integrierter LED als
Schaltelement zu verwenden... gefällt mir ganz gut... nur kommt sofort
wieder das Gehäuseproblem hoch ...

Bei der Adressierung tendiere ich auch zu einer Mischung aus direkt-
und broadcast. Aber da ist der letzte Entschluss noch nicht gefasst,
momentan sammle ich noch meine Anforderungen, daher ist dieser Thread
hier wirklich Gold wert :-))

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich lese hier auch schon eine Weile still mit, sehr interessante
Diskussion. Mittelfristig bis längerfristig plane ich auch eine
Heim-Automatisierung, nur wird es bei mit etwas diffiziler da es ein
Altbau ist...

Aber jetzt habe ich erst mal eine Frage an Volker:

Was ist "DOORS"? Ist das eine Software oder ist es ein Konzept?

Ansonsten, zum eigentlichen Thema:

Ich würde die ganze Geschichte auch eher dezentral bauen, so dass sich
die verschiedenen Knoten direkt untereinander unterhalten. Den Master
als zentrale Schwachstelle würde mir auch nicht so sehr gefallen.

Auch wenn es noch weiterhin einzelne Teile gibt, von denen viele Knoten
abhängen, z.B. Verkabelung oder Netzteil, sind diese System aber auch
primitiver. Da ist viel weniger dran was kaputt gehen kann und sie sind
schneller geflickt. Und so könnte man z.B. auch nicht nur ein zentrales
Netzteil an einer Phase vorsehen, sondern im extremfall für jeden
Buskoppler ein separates Kleinnetzteil verwenden. Diese Netzteile
können dann auch noch an verschiedene Phasen hängen etc. So könnte man
schon einiges an Redundanz relativ einfach miteinbringen.

Ansonsten, wegen der Nachrichten hin- und herschickerei.

Ich denke, ihr konzetriert euch zu sehr auf die eigentlichen
CAN-Nachrichten. Ich sehe die CAN-Nachrichten eher als
Implemtierungsdetail und konzentriere mich mehr auf die abstrakteren
Zustände der verschiedenen Komponenten:

Ein Taster kann gedrückt oder nicht gedrückt sein oder ein Taster kann
lange gedrückt sein. Ein Bewegungsmelder stellt eine Person fest oder
auch nicht.

Jeder einzelne Sensor stellt seinen aktuellen Zustand der Allgemeinheit
zur Verfügung. D.h. wann immer sich der Zustand eines Sensors (Taster,
Zeitplan, Fenster, Regen...) ändert, macht er in einer einzigen
CAN-Botschaft seinen neuen Zustand allen Aktoren bekannt.

Die Aktoren wiederum verknüpfen verschiedene Zustände und schalten ihre
Ausgänge entsprechend. Also z.B. Lampe = "Schalter #1 an" ODER
"Schalter #2 an".

Wenn die Hardwarefilter der CAN-Transceiver nicht reichen, spielt das
ja keine große Rolle, da der Mikrocontroller in den Knoten eh kaum
etwas zu tun hat. Und ausserdem müssten viele Aktoren ja nur auf einige
wenige Sensoren hören.

Zusätzliche würde ich so eine Art "virtuelle Zustände" einführen.
D.h. mehrere Taster können sich zu einem "virtuelles Kippglied"
verbünden. D.h. Taster einmal gedrückt, bedeutet "Gruppe
Treppenhauslicht an", den Taster nochmals gedrückt bedeutet "Gruppe
Treppenhauslicht aus". Dabei kann die Gruppe Treppenhauslicht durch
mehrer Taster gesteuert werden. Unter der Vorraussetzung das allen
Tastern der aktuelle Zustand der Gruppe bekannt ist, kann ja jeder
Taster in der Gruppe den nächsten Zustand der Gruppe bestimmen, wenn er
gedrückt wurde, dass er einfach eine CAN-Botschaft sendet, mit dem
Inhalt "Gruppe Treppenhauslich an". Alle anderen Taster auf den Bus,
die diese Gruppe auch bedienen, lesen diese Nachricht ja auch mit, und
kennen so den neuen Zustand der Gruppe und können bei einem Tastendruck
entsprechend mit einer anderen Gruppennachricht reagiern (z.B.
Treppenhauslicht aus). Die Lampen im Treppenhaus hören natürlich auch
auf diese Nachricht und kennen so den Zustand der Gruppe, und
verknüpfen den Gruppenzustand mit ihren Ausgängen. Also: Lampe =
"Gruppe Treppenhauslicht an".

Mit diesem Konzept könnte man wiederum einen virtuellen Timer einbauen,
der nach einer bestimmten Zeit, wenn die Gruppe Treppenhauslicht lange
genug im Zustand "an" war, die Nachricht "Gruppe Treppenhauslicht
aus" versenden würde. Die Aktoren und die Taster selbst würden dann
alle den neuen Zustand kennen und dementsprechend reagieren.

So in etwa stelle ich mir mein dezentrales System vor. Die ganze
Verknüpfung findet nicht annhand von Nachrichten statt, sonden
verknüpft werden Zustände. Und mit den CAN-Nachrichten werden Zustände
übertragen.

Mir ist bis jetzt noch kein Anwendungsfall eingefallen, den man mit
dieser Technik nicht ganz einfach parametrieren könnte.

Was haltet ihr davon?

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@volker:
platinen habe ich gar nicht fertigen lassen, sondern ätze selbst.
ich habe alles auf eine einseitige platine bekommen und es ist mit
meinen mitteln sauber hinzubekommen.

ich werde aber meine komplette elektrik selbst installieren (wozu bin
ich sonst elektrofachkraft? g div. meßgeräte für die prüfung nach vde
nach erfolgter installation kann ich mir leicht leihen...)
nur die "schnittstelle" bus/leistung werde ich wie gesagt nicht
selbst "bauen" sondern auf geprüfte schaltgeräte zurückgreifen

zu den langen leitungen von kontakten zum buskoppler:
hast du deine eingänge hardwaremässig entstört? rc-gliec? optokoppler?
das habe ich bei meinen up-dosen-busankopplern nicht gemacht...
pullup und software-entprellung sollten reichen (bei stefan´s
busankoppler ja auch nicht anders).
daher werde ich es unbedigt vermeiden die leitungslänge zwischen
busankoppler und schalter länger als 20-30 cm (reicht im
3er-dosen-verbund) werden zu lassen.
ich habe ein wenig angst das der µC sich irgendwie doch mal was an
störimpulsen (grad bei gewitter) einfängt und je länger die antenne am
eingangspin.....

auch wenns durch die software-entprellung ausgeschlossen sein sollte,
da zahl ich lieber 12eur mehr für nen extra-busankoppler (auch bei nur
1mtr abstand zwischen beiden) statt mir hinterher sonstwohin zu
beissen, denn:

man kann alles testen, prüfen, messen... aber son orginal
"norm-gewitter" zum testen... schwer :-)

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Volker: 29.07.2005 9:30
> kurzfristige Änderungen der SW aber ohne flashen gehts dann nicht
> weiter,
na dann reden wir ja vom selben. :-)

@Dany P. 29.07.2005 10:30
[Tastendruck verschickt CAN-Telegramm]
> jeder knoten den es interessiert kann dann selbst mitzählen oder
> halt auch nicht...
Ich hab dabei Angst, daß die Knoten dann irgendwann unsynchron laufen -
wie willste das verhindern? Irgendwann muß irgendwie was definiertes zum
resynchronisieren kommen.

@Volker 29.07.2005 13:21
> wie verteile ich die Buskoppler effektiv ohne zu den Sensoren all zu

> lange Leitungen legen zu müssen.
Umgekehrt. Überlege wo gehäuft Sensoren/Aktoren benötigt werden und
plane danach einen Buskoppler mit all diesen Schnittstellen. z.B. am
Fenster (Rolladenmotor, Rolladentaster, Fensterkontakte, (Heizung))
oder an der Tür (Lichtschalter, ggf. Bedienpanel?, Türkontakt?,
Türöffner). Die Steckdosen und Lampen willst du ja sowieso von zentral
anfahren. Bleibt nicht mehr soo viel übrig, das wild verstreut ist.

> Ich hatte auch mal angefangen jeweils 8 Taster mit integrierter LED
> als Schaltelement zu verwenden... gefällt mir ganz gut... nur kommt
> sofort wieder das Gehäuseproblem hoch ...
Die EIB-Schaltereinsätze von diversen Schalterherstellern sollen dafür
geeignet sein (Anschlüsse auf mehrpoliger Stiftleiste). Das EIB-Modul
selbst gehört ja nicht zum Schalter dazu. Die sehen zumindest gescheit
aus. Such mal in diese Richtung.

@Unbekannter 29.07.2005 14:15
> Was ist "DOORS"?
Dokumentations-/Dokumentenverwaltung - braucht man nicht.

> Ich sehe die CAN-Nachrichten eher als Implemtierungsdetail und
> konzentriere mich mehr auf die abstrakteren Zustände der
> verschiedenen Komponenten:
Ack.

> Ein Taster kann gedrückt oder nicht gedrückt sein
Ja, aber gerade die Taster sind ja (wie man hier an der Diskussion
sieht) bisher nicht eindeutig so zuordenbar, d.h. es ist ein
Unterschied, ob er zum ersten Mal gedrückt ist, oder ob zuvor (in
deinem Konzept) ein anderer, virtuell verbundener Taster gedrückt wurde
usw..

Ich würde deine/unsere Ausführungen mal so zusammenfassen:
- Sensoren broadcasten ihre Statusmeldungen (Regensensor, Zeitschaltuhr
"Aktoren, bitte Szenario Nacht einnehmen", Taster)
- Bedienelemente (Taster...) schicken gerichtete Telegramme an die
Aktoren
- Aktoren reagieren/schalten in Abhängigkeit der Broadcasts und den
empfangenen Telegrammen der Bedienelemente. (selbst broadcasten diese
natürlich auch ihren aktuell eingenommenen Zustand, z.B. zur
Visualisierung; Rückmeldung)

Wobei man die Taster ja (noch?) nicht eindeutig einordnen kann?!


> Mir ist bis jetzt noch kein Anwendungsfall eingefallen, den man mit
> dieser Technik nicht ganz einfach parametrieren könnte.
Auch hier wieder das Problem: Wie synchronisieren sich die einzelnen
Taster im Betrieb? (wenn mal einer "später" dazukommt oder kurz
ausgefallen ist).

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref: "unsynchrones laufen"... ich würde die schalter lediglich
stati senden lassen. somit macht die eigentliche
"auswertung/verknüpfung" der aktor. und der is allein und kann so
nicht unsynchron werden.
daher hate ich doch mal gefragt ob es so schön ist die dimmwerte schon
im taster zu erzugen, weil ich möglichst viel teilprogramm in den aktor
packen würde und weniger in die taster
evt habe ich auch fälle übersehen...

aber wenn ich mal von einer realisierten "eltaco-schaltung" im flur
ausgehe:
ich würde einfach den aktor bei jedem tastvorgang den ausgang togglen
lassen. bei dieser art schaltung würd ich nicht die taster ein "ein"
und "aus" schicken lassen, dann könnten sie echt mal unsynchron
laufen wenn einer das vorherige telegramm verpasst hat...
aber wenn er nur "umschalten" schickt sollte es keine probleme geben

mit dem "selbst mitzählen oder auch nicht" meinte ich die zeit des
tastendruck für die knoten dies interessiert.
(wird im wohnzimmer der lichtschalter (aus) gedrückt geht sofort das
licht aus (1.aktor) und nach 2 sekunden werden alle steckdosen
freigeschaltet (2.aktor)...
so langsam aber sicher fürchte ich das ich mich damit anfreunde selbst
tastsignale als broadcast zu machen. dann würd ich nur noch auf den
aktoren ändern müssen...

aber nun zu fehlenden telegrammen:
wenns "make" fehlt": nicht schlimm, wenn der break als erstes
ankommt wird der tastvorgang als ungültig ignoriert o.ä.

anders wenn der break fehlt... dann dimmt er.. und dimmt... und dimmt
:)  da muss ich noch mal drüber nachdenken, guter tip

könntest du noch mal ein beispiel für "unsynchrones" laufen nennen?

zu den EIB-Tastern: ich habe nichts diesbezüglich gefunden, ich weiss
nur das die schaltelement eine (ich mein) 2x5polige stiftleiste haben.

das würde für nen 4fach-doppeltaster inkl. led schon nicht ausreichen.
von daher denke ich das die kontakte und led´s nicht nach aussen
geführt sind sondern per bus/seriell oder sonst wie dem eigentlichen
busankoppler zugeführt werden... aber wie gesagt nix gefunden :(

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mmh, noch mal eine sache über die wir noch gar nicht gesprochen haben:
Stromausfall... ich möchte das nach dem stromausfall die gleichen
schaltzustände herrschen wie vorher.

jeden zustand im eeprom ablegen um bei evt. stromausfall die vorherigen
zustände wieder herzustellen finde ich persönlich blöse, da bei 100.000
schreibzyklen (ok es dauert ne ganze zeit) das eeprom ja irgendwann mal
totgeschrieben ist (und einigen sachen werden ja oft geschaltet...)

also muss/soll der bus weiterlaufen.
ich wollte eigentlich ein zentrales netzteil und ein akku einsetzen.
ein 7Ah akku hält den bus laaaaange am laufen. evt reicht sogar ein
kleines solarmodul zum laden des akkus, damit hätte man auch wieder
eine gewisse ausfallsicherheit...

was haltet ihr davon? oder wollt ihr einfach ein netzabhängiges
netzteil einsetzen?

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref:

Also, die Sensoren würden nie einen Aktor direkt ansprechen, sondern
immer "broadcasten". D.h. die Aktoren würden sich die Nachrichten,
die sie benötigen, selbst heraussuchen.

Konkret, eine Eltaco-Schaltung würde ich wiederum die Taster selbst
verwalten lassen.

Also, wenn ein Taster gedrückt wird, werden folgende Nachrichten
verschickt:

1.) Ein Taster wird gedrückt -> "Taster 1, Zustand gedrückt"

2.) Der Taster ist einer Eltaco-Schaltung zugeordent, also wechselt der
gedrückte Taster seinen internen Eltaco-Zustand.

3.) Der gedrückte Taster teilt den neuen Eltaco-Zustand mit -> "Eltaco
Flurlicht, Zustand an"

4.) Alle Lampen im Flur hören auf "Eltaco Flurlicht, Zustand an" und
schalten das Relais.

5.) Alle anderen Taster im Eltaco-Verbund Flurlicht hören auf "Eltaco
Flurlicht, Zustand an" und aktualisiern ihren internen Zustand.

6.) Das Kind hat noch immer den Finger auf dem Taster, also verschickt
der Taster -> "Taster 1, Zustand lange gedrückt".

7.) Niemand interessiert sich für "Taster 1, Zustand lange gedrückt"

8.) Der Taster wird irgendwann losgelassen -> "Taster 1, Zustand nicht
gedrückt"

9.) Niemand interessiert sich für den losgelassenen Taster.

10.) Pause... ;-)

11.) Taster 2 wird vom Vater gedrückt -> "Taster 2, Zustand an"

12.) Taster 2 ist dem Eltaco-Verbund Flurlicht zugeordnet. Der letzte
bekannte Zustand dieses Verbundes war "an", gesetzt vom Taster 1.
Also ist der neue Zustand des Eltaco-Verbunds Flurlich "aus".

13.) Taster 2 teil den neuen Zustand des Eltaco-Verbunds mit ->
"Eltaco Flurlicht, Zustand aus".

14.) Alle Lampen die sich für "Eltaco Flurlicht, Zustand aus"
interessieren, schalten sich aus.

15.) Alle Taster, inkl. Taster 1, im Eltaco-Verbund Flurlich hören auf
"Eltaco Flurlicht, Zustand aus" setzen ihren internen Zustand
entsprechend.

16.) Taster 2 wird losgelassen -> "Taster 2, Zustand aus".


So in etwa stelle ich mir das vor. In dem Beispiel oben habe ich mal
weggelassen, dass die geschalteten Lampen auch wiederum ihren
geänderten Zustand der Allgemeinheit mitteilen würden.

Der Trick daran ist, wenn ein bestimmter (virtueller) Zustand von
mehreren Buskopplern kontrolliert wird, wird immer der Buskoppler, der
den Zustand als letztes geändert hat, zum temporären "Master" dieses
Zustandes. D.h. virtuelle Zustände werden über mehrer Knoten verteilt,
es gibt keinen festen Master.

Wenn jetzt ein Buskoppler im Verbund ausfällt, passiert gar nichts. Die
verbleibenden Buskoppler können den verteilten Zustand problemlos selber
weiter pflegen.

Wenn ein neuer Buskoppler dazu kommt, und den Zustand eines virtuellen
Verbundes nicht kennt, muss er den erst mal abfragen. Auch wenn er der
10. Taster im Verbund ist, bekommt er nur eine Antwort, da die anderen
9 Taster ja alle den gleichen Zustand (per Can-ID) übermitteln.

Um Übertragungsfehler auszuschliessen, kann eine Zustandsänderung ja
auch mehrmals gesendet werden und sogar periodisch wiederholt werden.
Mir schwebt in etwa folgendes vor:

Erst wird die aktuelle Zustandsänderung mit hoher Priorität gesendet.
Danach wird sie mit exponentiell immer größeren werdenden Zeitabständen
mit niedriger Priorität wiederholt, bis die Widerholungsrate z.B. 5
Sekunden erreicht hat.

Die Prioritäten würde ich in etwa so sortieren (von höchster zur
niedrigsten Priorität):

- System-Nachrichten (Software-Updates, Parametrierung, Debugging)
- Wichtige Sensoren (Feuer, Gas, Wasserrohrbruch, Einbruch etc.)
- Umweltsensoren (Regen, Sonne, Temperatur, etc.)
- Taster, Schalter
- Virtuelle Zustände (Eltaco-Verbünde, Uhrzeit etc.)
- Zustände der Aktoren (Lampe an/aus, Rollo-Motor an/aus, etc.)
- Wiederholungen...

So in etwas stelle ich mir mein verteiltes System vor.

Vor allem liessich sich das meiner Meinung nach leicht anpassen und
erweitern. Wenn in dem Flurlich-Beispiel z.b. noch ein virtuelles
Zeitrelais hinzukommen würde, würde das nur auf die Nachrichten
"Eltaco Flurlicht, Zustand an" hören, und nach einer weile, falls es
vorher nicht ein Taster macht, die Nachricht "Eltaco Flurlicht,
Zustand aus" verschicken. Von dem Timer müssten dann weder Taster noch
Lampen etwas wissen. Sie sehen nur die Nachrichten des virtuellen
Eltacos. Woher sie kommen, ob von einem Timer, einer Diagnose-Software
oder sonst woher, wäre alles egal.

So wären trotzdem umfangreiche Verknüpfungen möglich, ohne dass die
einzelen Teile (Taster, Timer, Lampen) jeweils die anderen Teile kennen
müssten.

Autor: Busmaster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr denkt alle viel zu kompliziert !

Kurze Vorstellung eines bestens funktionierendem - Bussystems (SEBUS):

1 Hardwaremodul für die Hutschiene das alle Funktionen abdeckt.
Mittels Dip-Schalter Auswahl ob als Jalousie, Schalt- oder als
Analogaktor. (8 IN/4 Out. Bestückbar mit div. Relaisen, Solid-State
oder Transistor). Keine Parametrierung erforderlich - wozu auch.

Busmedium egal. Ob CAN,RS485, RS232 alles geht ! MC egal !
Keine 9 Bit UART notwendig !

Netzgeräte soviel und welche man will. Keine Potentialprobleme da alle
Geräte potential-getrennnt mittels DC-Wandlern versorgt werden.
Keine Koppler, Drosseln, Stromschienen, Logikmodule, usw.

Software: Jeder Eingang schickt bei Betätigung ein
Bestätigungstelegramm. Diese sagt aus, ob pos/neg Flanke und ob lange
oder kurz gedrückt wurde.
Auch Ausgänge schicken bei Betätigung ein Zustandstelegramm.
Jeder Teilnehmer kann darauf reagieren oder nicht.

Programmierung: Es kann ein Master eingesetzt werden, ein PC der die
Visualisierung (VB) mit übernimmt, oder jedem Teilnehmer kann über den
Bus
gelernt werden, aus was er horchen soll. Dieser kann auch Telegramme
weiterreichen. Dimmaktoren reagieren auf lang/kurz Telegramme (Ein/aus
/Dimmen bei Langtelegrammen)

Programmierung über PDA, Internet, PC, Handy oder einfach Taster
drücken.

Wichtig: Auch ein Elektriker muss mit der Programmierung klar kommen.

Für die normale private Haustechnik ist der Bus weit unterfordert.

Seine Stärke ist eigentlich die Erfassung von Störmeldungen,
Alarmmeldungen, Zutrittskontrollen, Visualisierung, SPS usw. in der
Industrie. Kosten pro Multifunktionsmodul: ca 120.- €
( 8 IN/ 2 Analog 0 -10 V, 4 Out 230 V/16 A, 1  x 0 - 10 V Out, RTC, 1 x
PT100, 1 Analogpot /4 TE)

Ich würde alle Entwickler bitten, ihre Bus-Entwicklungen  zu
hinterfragen, ob sie mit diesen Vorgaben mithalten können. Falls
nicht - gibt es noch viel Arbeit zu tun.



SG Busmaster

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Busmaster:

a.) Google findet alles möglich zu "SEBUS", nur kein Bussystem.
Verschrieben? Hersteller? URL?

b.) Du diskutierst die Anwendung eines Bussystems. Wir dikustieren hier
die Implemtierung. Ein "kleiner" Unterschied...

c.) Parametrierung ist ein Oberbegriff für "Auswahl mittels
DIP-Schalter" und "Programmierung über PDA, Internet, PC, Handy oder
einfach Taster drücken".

d.) Dein "Hardwaremodul für die Hutschiene" ist das gleiche wie unser
"Buskoppler". Ein Stück Elektronik mit Ein- und Ausgängen an den
irgendwelche Sensoren (Schalter, Taster, Fensterkontakte) und Aktoren
(Licht, Rolläden, Klinkel) angeschlossen werden.


Vielleicht hättest Du wenigsten das letzte Drittel dieses Threads lesen
sollen, damit Du wüsstest, um was es hier geht...

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Busmaster: sinnvoll hin oder her. unterfordert hin oder her. was du
anscheinend vergisst:
Ich denke ich spreche hier für einige: Es ist ein HOBBY.
Und da macht das selbst durchdenken, planen, löten und programmieren
nun mal spaß.

Ausserdem bietet der Bus viiiele Reserven, wer weiss wie man die mal
nutzen kann...

Fertig kaufen klann ja jeder :-p

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dany 30.07.2005 10:20
> "unsynchrones laufen" [...]
> aber wenn er nur "umschalten" schickt sollte es keine probleme
geben
> könntest du noch mal ein beispiel für "unsynchrones" laufen
nennen?
Bsp. 2 Treppenhauslampen an einem Taster. 1 Lampe fällt kurz aus,
während der Taster gedrückt wird... dann kriegst du das Licht nie mehr
aus, da immer entweder L1 oder L2 brennt :-)
Aber wie man da umgeht hat ja "Unbekannter" heute 30.07.2005 12:52
schon geschrieben.

> zu den EIB-Tastern: [...] 2x5polige stiftleiste
ja so war auch mein Wissenstand - damit sollte das gehen.

> stromausfall; da bei 100.000 schreibzyklen das eeprom ja irgendwann
> mal totgeschrieben ist
naja, wenn du soo viel Wert auf diese Feature legst, dann kannst du dir
Strategien überlegen, daß du die max.Schreibzyklen der Zellen nicht
erreichst, z.B. rechzeitig auf eine andere Eepromzelle ausweichen...

@Unbekannter 30.07.2005 12:52
klingt alles sehr gut - neu (für mich) wäre dann, daß auch die
restlichen Taster im Verbund mithören müssen, wenn ein anderer
Verbundtaster 'was' meldet. Ok.
Hast du dir schon Gedanken über eine Parametriersoftware (PC) gemacht
und wie der Benutzer diese Kombinationen eingeben/einstellen kann?

Noch einen Einwurf: Spätestens wenn ich mit dem Wandtaster neben dem
normalen Licht auch noch das Badradio ein/ausschalten will, wirds (in
meiner Vorstellung?) wieder etwas komplexer... (Muss ich mir mal
genauer durchdenken).

[Nachrichtenprioritäten]
> 1. System-Nachrichten (Software-Updates, Parametrierung, Debugging)
das wäre bei mir die niedrigste Priorität :-)

Und das mit der Priorität ändern je nachdem wie lange das Ereignis her
ist, würde ich nicht machen, da extrem debugaufwändig. CanId würde sich
dann ja ständig ändern...

Den Prioritäten bei CAN würde ich allgemein keinen so hohen Stellenwert
zuordnen, da das nur interessant ist, wenn der Bus sehr stark
ausgelastet ist(!) und wenn 2 Knoten bitgenau zeitgleich anfangen zu
senden.


Was ganz Allgemeines:
Wie parametriert man eigentlich die Knoten am besten (zur Laufzeit)?
Indem man ihnen bestimmte (gerichtete) CanTelegramme zusendet, die
genau dieser eine Knoten auswertet. (Gibt's noch andere
Möglichkeiten?)
 Also braucht man doch auf jeden Fall eine Möglichkeit gezielt mit
einem Knoten kommunizieren zu können. Warum sollte man diese
Möglichkeit/Schnittstelle nicht auch (zusätzlich?) für den normalen
Betrieb verwenden können/sollen/dürfen?
Ich denke da z.B. an eine Zeitschaltuhr, die gezielt nachts um 3Uhr
alle 'vergessenen' Lampen abschaltet. Ich würde da nicht viele
verschiedene Verbundtaster-Ausmeldungen schicken, sondern gezielt jede
Lampe einzeln abschalten?!
Gibt's noch andere Fälle in denen gerichtete Kommunikation
einfacher/flexibler ist? Im jetzigen Verlauf der Diskussion
kristallisiert sich ja langsam heraus, daß man eigentlich alles was zum
Betrieb des Systems gehört (Aktoren schalten; Meßwerte mitteilen) über
Ereignisse/Broadcasts lösen kann. Sobald aber etwas parametriert werden
soll (zur Laufzeit), muß das über gerichtete, adressierte Telegramme
passieren. Kann man das so pauschal sagen?


Zum Schluß noch einen Hinweis an diejenigen, die die Eingänge und
Ausgänge strikt (topo)logisch trennen: Fällt der Bus aus (Kurzschluß
irgendwo im Haus), so fahren nicht mal die Rolläden... Deshalb habe ich
die Rolladentaster auch direkt an die Knoten angeschlossen, die die
Motoren schalten, oder Lichttaster an einen Knoten, der auch Dimmer
steuert. Fällt der Bus aus (wird im Knoten erkannt), so kann man
wenigstens noch die knotenlokalen Lampen mit den direkt angeschlossenen
Tastern bedienen.

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

kaum ist man mal nen Tag nicht da, schon muss man aufpassen den
Anschluss nicht zu verlieren :-)

@Unbekannter [DOORS]
Also DOORS ist schon mehr als ne Dokumentenverwaltung oder auch
Datengrab genannt. DOORT ist ne SW von Telelogic zur
Anforderungsanalyse, Pflichten- Lastenhefterstellung usw. Ich hab das
in den Raum geworfen, da wir den Einstieg, als die Anforderungsanalyse
eines Projektes damit aufsetzen. Ist ungemein hilfreich, vor allem, da
wir daraus weiterführend auch das SW Design (allerdings mit nem anderen
Tool) ableiten.

@ Danny P. [Stromausfall]
Darüber hab ich mir auch schon Gedanken gemacht. Ich habe bislang nicht
vor die internen Zustände eines Busknotens im EEPROM abzuspeichern. Dort
ist erstmal nur die Konfiguration eines jeden Knotens hinterlegt. Wie
Andre schon schrieb, es gibt verschiedene Möglichkeiten die Zyklenzahl
im EEPROM zu erhöhen, ich habs aber bislang nocht nicht vorgesehen. Ich
werde meine Spannungsversorgung der einzelnen Etagen lieber mit ner USV
absichern. Bei nem Reset des Systems wird dann eben eine sichere
"Grundstellung" angefahren, also meinetwegen die Beschattung des
Wintergartens eingefahren und anschliessend, eben je nach Situation,
auf die Umwelt reagiert.

@ All
Im Moment haben wir wohl zwei Konzepte die sich gegenüber stehen (oder
in gewisser Weise auch ne Schnittmenge bilden).

1. Direkte, adressierte Kommunikation
2. Broadcats
3. Eine Vermischung Broadcast/direkt. Broadcast für Statusmeldungen,
direkt für Diagnose/Update/Flashen

Ich habs leider noch immer nicht geschafft mir das mal konkret
durchzudenken.

Mal ganz grob, was mir dazu einfällt:

1. Direkt
- Jeder kann sich mit jedem ganz gezielt unterhalten
- Für jeden Empfänger muss ne Botschaft verschickt werden
- Der Sender bestimmt, wer welche Information bekommt, das heisst, der
Sender muss wissen, ob der Empfänger etwas damit anfangen kann
- Wenn ein Empfänger in nem Sleep Modus ist, dann verschläft u. U. die
Botschaft
- SW Update per CAN einfach möglich

2. Broadcast
- Jeder Teilnehmer hat am selben Bus die selben Informationen
- Der Empfänger entscheidet, ob er mit den Informationen etwas anfangen
kann
- Sleep Mode ist ebenso ein Problem
- Aktuatorknoten verwalten die Zustände
- Jeder Taster/Sensor/... bekommt ne eigene Botschaft
- SW Update nur über gezielte Kennung eines Knotens möglich

3. Broadcast / direkt
- Eben ne Mischung aus beiden :-)
- Ablauf in den Aktuatorknoten
- Zustandsänderung wird von den Knoten angefragt
- Jeder Knoten hat ne eigene BotschafsID, mit der er direkt
angesprochen werden kann.
- Tasterknoten können schlafen gelegt werden, wenn sie direkt
angesprochen werden sollen, können sie das dann aber auch verschlafen
- ...

irgendwie drängt die Zeit schon wieder. Vielleicht habt ihr Lust die
Gegenüberstellung weiter auszubauen? Das hier soll mal nur ein kleiner
Ansatz sein :-)

Autor: Danny. P (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref:
zum unsynchron werden: da hast recht. könnte theoretisch im einzelfall
passieren (halte ich zwar für seeeehr unwarscheinlich, aber die
möglichkeit sollte ganz ausgeschlossen werden)

daher hab ich mich grad damit angefreundet generell eine rückmeldung
des aktors einzubauen.
wird nicht innerhalb einer bestimmten zeit die zustandsänderung an den
initiator zurückgemeldet wird das telegramm wiederholt.
nach bspw. der 5. wiederholung erfolgt eine störmeldung.
dadurch wirds meiner meinung nach sehr sicher und sollte tatsächlich
mal ein knoten kurz nen blackout haben fällts evt. gar nicht auf

durch diese rückmeldung bin ich auch darauf gekommen das durch
spezielle can-botschaft das direkte schreiben bis zu 8Byte in den ram
eines anderen knotens möglich sein soll (ähnlich des Merkeraustausches
Simatic SPS <-> OP).
dadurch braucht an einigen stellen nicht auf eine bestimmte botschaft
gewartet werden sondern nur ein ram-bit gecheckt werden.
dadurch wird das "software-grundmodul" wieder umfangreicher aber die
spezifische einzelprogrammierung erleichtet (meiner meinung nach)
evt. werde ich aktor-schaltvoränge auch auf diese art übers ram
austauschen, mal sehen.. muss ich noch mal drüber nachdenken....

meinungen?

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwei Dinge:

Zum einen sehe ich in einem CAN-Bus nicht so sehr einen Unterschied
zwischen Broadcast und direkter Adressierung der Nachrichtenziele.

Denn CAN ist ja ein gemeinsam genutzter Bus. Alle knoten können immer
alles mithören, egal ob sie "direkt" oder per "broadcast"
angesprochen werden.

Für mich sind das eher zwei verschiedene Blickwinkel auf die gleiche
Sache. Bei der "direkten" Adressierung ist in der CAN-ID der
"Empfänger" kodiert, beim "broadcast" ist in der CAN-ID der
"Absender" kodiert.
Doch in beiden Fällen verhält sich die Sicht des Empfänger gleich,
nämlich auf eine bestimmte CAN-ID (mit Maske) reagiert der Empfänger.

Auch die Sicht des Senders ist für beide Fälle irgendwie gleich. Es
wird eine CAN-ID nach irgendeinem Schema erstellt, und die Nachricht
auf dem Bus verschickt. Ob nun sich nur ein Empfänger oder viele
Empfänger um die Nachricht kümmern, ist aus dem Blickwinkel des Senders
egal.

Von daher: Die strikte Unterscheidung in "Broadcast" und "direkter
Adressierung" existiert in meinem gedanklichen Konzept nicht. Darum
meinte ich auch in meinem Ursprungsposting, das eher aus dem
Blickwinkel des Gesamtsystems zu betrachten, und mehr über Zustände und
deren Änderungen nachzudenken. Und eine Nachricht auf dem Bus informiert
nur über eine Zustandsänderung. Nicht mehr, nicht weniger.

Zum zweiten (das wird hoffentlich kürzer):

Wegen der Fehlerfallbehandlung würde ich nichts zu kompliziertes
machen. Sich eher an Internetprotokollen orientieren. Pingelig beim
Versenden von Nachrichten sein, großzügig beim Empfangen von
Nachrichten. Und: Zeit heilt alle Probleme, und wenn Fehler auftreten,
es so lange versuchen bis keine Fehler mehr auftreten.

D.h. von Fehlerzähler, Störungsnachrichten, Bestätigungs-Nachrichten
etc. halte ich nicht viel.
Was nützt es, wenn ein Knoten feststellt, dass irgendeine Busstörung
vorliegt, weil er keine Antworten enthält und dann die "Störlampe"
leuchtet und der Knoten alle weiteren Versuche einstellt? Dann muss man
den Knoten wieder irgendwie entriegeln oder so.
Und wohin soll die "Störlampe"? An jeden Taster? Oder soll jeder
Koppler ein Summer bekommen der dann Nachts um 3:45 Uhr im Schlafzimmer
anfängt zu piepen, nur weil irgendein anderer Knoten im Flur nicht mehr
antwortet?
Oder soll die Störung per gestörten Bus an eine Zentrale eine Störung
melden?
Und was passiert, wenn aus irgendwelchen Gründen der Absender keine
Bestätigungsnachricht vom Empfägner bekommt, aber die Nachricht vom
Sender problemlos an den Empfänger durchgeht? Schaltet dann der
vermeintlich funktionierende Knoten das Licht nach immer 5 Sekunden
wieder ein, nachdem es von einem anderem Taster manuelle ausgeschaltet
wurde, nur weil er vermeintliche funktionierende Knoten keine
Bestätigungsnachricht vom Licht bekommt?

Ich denke, diese Konzepte machen mehr Problem als sie nützen.

Ich mache das so: Es muss nur gewährleistet sein, dass ein Knoten, der
z.B. erst nach 10 Minuten an den Bus online geht, sich alle nötigen
Informationen/Zustände besorgt oder von jemanden bekommt, so dass er
sich nahtlos einfügt.

Damit kann sich ein Knoten jederzeit wieder in das Gesamtsystem
einfügen, egal aus welchen Grund er eine Zeitlang nicht im Gesamtsystem
integriert war.

Eine Störung ist eine Ausnahme, die man eh nur sehr schwer
kontrollieren kann. Könnte man die Situation leicht kontrollieren,
würde die Störung sowieso nie auftreten.

Wie jemand anders in der Dikussion geschrieben hat: Wenn ein Koppler
von Bus getrennt ist, kann der Koppler eben nur noch die direkt
angeschlossenen Aktoren bedienen (Licht, Rollos) und nur auf die direkt
angeschlossenen Sensoren (Taster, Regenmelder) reagieren. D.h. man
sollte die Koppler so verteilen, dass beim Bus-Totalausfall, die
Koppler selbst wenigstens noch ein paar Lampen ein- und ausschalten
können. Und der mechanische Schalter für das Licht im Schaltkasten und
bei den Sicherungen, das auf ausschliesslich dafür abgesicherten Kreise
liegt, einschliesslich ein, zwei Steckdosen in jedem Zimmer, die fest
auf einer Phase hängen, ohne Elektronik etc. ist nie nicht verkehrt. So
das im Katastrophenfall (Blitzeinschlag) wenigstens noch ein paar
rudimentäre Sachen gehen...

So, jetzt ist's doch etwas mehr geworden. Nun aber wieder Schluss...

Autor: Neugieriger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Danny P.

Du verwendest den Mega8 für Deine Buskoppler.
Baust Du das in DIP oder verwendest Du SMD? Der Mega8 ist ja
hinreichend klein, um den DIP-Typen zu nehmen (Ich scheue mich noch
etwas vor SMD ;o) ).

Ist der Mega8 hinreichend "groß", um die oben diskutierten Aufgaben
zu übernehmen? Es sollte ja in jedem Buskoppler das gleiche Programm
(nur mit anderen Parametern) laufen, um nicht für jeden Teilnehmer eine
eigene Programmversion pflegen zu müssen.

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@neugierieger: ich habe ausschliesslich smd bauteile verwendet.
da ich die platine selbst ätze wollte ich auf doppelseitige verzichten.
und bei 2 grossen DIL-IC´s wär das wohl nix geworden.
Ich würde sogar fast behaupte mit DIL ist es enorm schwer zu layouten
(2 DIL IC, bustreiber noch mal ein 8füssler, die ganzen stiftleisten
zum anschluß, widerstände etc... )
stell dir mal die bauteile auf ner fläche von 50 x 50mm auf den tisch
:)

zum programm: ich bin mir noch nicht gnaz sicher ob es mit einer
parametrierbaren standartversion klappt. das wird sich nach und nach
rausstellen.

jetz hab ich erst mal wieder etwas mehr zeit und werde nun stück für
stück das "hauptprogramm" zusammenstellen und anschliessend nach und
nach über den eeprom parametrierbar machen

also ich denke das die 8K Flash des Mega8 ausreichen.
es werden ja standart-hardware-funktionen genutzt um die indormationen
einzusammeln. ok, der ir-empfang einer fernbedieung... aber laut atmel
AppNote auch nur 70 oder 80 words...


@unbekannter: für mich ist es schon ein grosser unterschied mit
direkter adressierung etc.
wen nich die direkte adressierung viel nutze und gleichzeitig die
filtermöglichkeiten meines MCP2515 erspare ich mir software und arbeit
des µC.
und egal wie wenig das am ende ausmacht: das was ein eingesetzter chip
von haus aus kann brauch ích nicht noch ein zweites mal per software
erfinden.

zu deiner störmeldegeschichte: ich schrieb ja ... ein knoten macht
mehrere versuche wenn das nicht geklappt hat -> Fehlermeldung.
wenn es nach 5 oder 10 versuchen schon nicht geklappt hat wird auch mit
200 versuchen nicht besser...
und schliesslich hat so ein ausfall ja ein grund und wenn einem knoten
das öfter passiert wird er ausgetauscht...
wenn man wie du beschreibst "auf crash" fährt dann is irgendwann
etwas so kaputt das nix mehr geht...

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Unbekannter:
[Broadcast und direkte Adressierung]
> Für mich sind das eher zwei verschiedene Blickwinkel auf die gleiche
> Sache.
genau, aber in der Knotensoftware bzw. deren Konzept/Aufbau
unterscheidet sich das dann doch schon erheblich.
Im einen Fall steckt die Intelligenz im Sender, um anderen Fall im
Empfänger.

@Dany P.
[Ausfallerkennung/Strategie]
> ein knoten macht mehrere versuche wenn das nicht geklappt hat ->
> Fehlermeldung. wenn es nach 5 oder 10 versuchen schon nicht geklappt

> hat wird auch mit 200 versuchen nicht besser...
Naja, da denke ich anders ähnlich wie "Unbekannter", entweder ich
schicke gezielt ein gerichtetes Telegramm einmal. Dann erwarte ich
keine Bestätigung, sondern muß anders sicherstellen, daß der Empfänger
darauf reagieren kann. Oder ich schicke ein Telegramm ständig/zyklisch,
damit ein kurzer Ausfall nix macht.
Empfangsbestätigungen, Mehrfach wiederholtes Senden usw. halte ich fuer
Unsinn und macht das Protokoll unnötig kompliziert.
Es muss nicht jeder Lichtschalter überprüfen, ob die mit ihm
"verbundenen" Lampen auch wirklich da sind - das kann eine ganz
andere Instanz übernehmen. z.B. durch Überprüfen, ob auch alle Knoten
schön ihre Broadcastmeldungen regelmäßig absetzen, und bei Ausbleiben
kann man das irgendwie global signalisieren. Wie gesagt, darum muß sich
der Lichtschalter nicht auch noch kümmern.

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Neugieriger,
@Danny,

>Ist der Mega8 hinreichend "groß"

Ich habe bis vor einigen Monaten den Mega8 für meinen Hausbus
eingesetzt. Allerdings musste ich feststellen, dass der MC zuletzt
immer enger wurde. Nun setze ich den Mega168 ein und habe wieder
entsprechend Luft.

@Unbekannter,
@Alle,
ich habe in meinem Bus auch streng auf Ereignisse gesetzt. Einzige
Ausnahme ist die Konfiguration der Knoten. Dabei wird die Sendung mit
der Adresse des Empfängers und einer entsprechenden Eventkennung
gesendet.
Alle Sendungen werden von jedem Modul über seine Compare-Liste geprüft
um gegebenenfalls die entsprechenden Actiondaten aus der Compareliste
an die Anwendungsschicht weiter zugegeben. Die Actiondaten bestehen aus
einem Zeiger auf eine Anwendung und die zu verarbeitenden Daten.
Damit lassen sich eigentlich alle Verknüpfungen, die ich bisher
gebraucht habe, erzielen.
Ich glaube nicht das es unkomplizierter geht.

Koopi

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref: ich will da mal auf deine erfahrung zurückgreifen :)
du hast anscheinend bisher keine "wiederholungen" oder
"rückmeldungen"  eingebaut.
ist denn schon mal irgendetwas ausgefallen (in bezug auf den bus) oder
ein telegramm nicht angekommen? oder unsynchron geworden o.ä.?
vielleicht mache ich mir da ja wirklich zu viele gedanken....

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig, kein weiteres Protokoll zur Datensicherung drübergestülpt. CAN
reicht da vollkommen aus. Und wenn CAN mal ausfällt (bisher auch noch
nicht passiert - zumindest ist mir nichts aufgefallen), dann schalten
die Knoten (bei mir) eh in den lokalen Betrieb...

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref: du hattest doch auch mal Atmel-µC eingesetzt. Weisst du noch
wie gross in etwa das übertragene Programm war. Ich frage weil ja grad
die Frage aufkommt ob nen Mega8 ausreicht (bin eigentlich der meinung
für den UP-Dosen-Knoten auf jeden Fall)...

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe von damals alles vergessen/verdrängt ;-). Heute brauche ich <10kB
mit "allen Schikanen"...
Ausschliesslich Grundfunktionalität sollte in 4kB zu programmieren sein
- aber man will ja sauber und modular programmieren, da sind Reserven
immer praktisch. Nach oben hin gibt's natürlich keine Grenzen ;-).
Gibt's keine AVRs, die kompatibel zum Mega8 sind und mehr als 8kB
Flash haben?

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich glaub nicht... ab mega16 ja... aber der mega8 im 32pin tqfp nicht...
naja ich denke dennoch ich werd damit auskommen, werd in den nächsten
tagen wie gesagt mal das programm zusammenschreiben...

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref,
@Danny P.,

>Gibt's keine AVRs, die kompatibel zum Mega8 sind und mehr als 8kB
>Flash haben?

Der Mega168 ist pinkompatibel, hat 16KB und ist zu fast 100%
SW-kompatibel. Einige Registernamen müssen geändert werden. Danach
läuft es fast immer sofort. Habe den Mega8 damit schon in mehreren
Projekten ersetzt.

Koopi

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref: mal wieder zum thema zu viel gedanken machen :)

du nutzt ja deine filter nicht.
mir ist grad mal aufgefallen, wenn ich eh teilweise mit broadcast
arbeite und somit die telegramme per software filter muss... dann
bringt es wohl doch keine so grosse änderung wenn ich vorher per
hardware in "broadcast" und "direkt" angesprochen unterscheide,
oder?

also würden meine hardwarefilter auch überflüssig bzw. bringen nicht
mehr so die dolle vereinfachung, kannst du das so bestätigen?

Autor: sparks (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich verfolge den Thread nun auch schon seit längerem mit großem
Interesse. Meine Frage zu der Realisierung eines solchen Hausbus ist,
ob sich jemand schon einmal Gedanken zu den duch den Hausbus
verursachten zusätzlichen Stromkosten gemacht hat. Mit irgendwas will
die ganze verbaute Elektronik ja versorgt werden. Hat da jemand schon
mal eine Hochrechnung gemacht, auf wieviel kW/h pro Jahr das an
zusätzlichem Verbrauch rausläuft?

Autor: Dumbo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Mit irgendwas will
die ganze verbaute Elektronik ja versorgt werden. Hat da jemand schon
mal eine Hochrechnung gemacht, auf wieviel kW/h pro Jahr das an
zusätzlichem Verbrauch rausläuft?"

Ich nutze zwar EIB, aber die Kosten sind deutlich gesunken. Dafür ist
der Bus schließlich da ;)

Im Winter werden bei Dunkelheit die Rolläden automatisch
runtergefahren, alleine das spart schon eine Menge Heizung.
Ebenso die anderen Systeme!

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habs mal überschlagen und bin auf etwa 20EUR im Jahr gekommen; waren
aber nur die knoten inkl. CAN (ohne Relais etc.).
Das ist auch der Grund warum mir SolidStateRelais lieber wären als
Standart-Relais, wegen des stromverbrauches auf dauer...

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, was die Relais verbrauchen, spielt ja nun wirklich eine
untergeordnete Rolle. Denn ein Relais benötigt nur dann Strom, wenn es
angezogen ist. Und wenn es angezogen ist, läuft da in der Regel ein
deutlich größerer Verbraucher mit. Kleine Koppelrelais liegen unter 0,2
Watt. Das macht bei einer 100 Watt Glühbirne nun nichts mehr aus...

Aber die Koppler sind schon interessant. Angenommen 15 Koppler, jeder
Koppler benötigt 0,5 Watt. Das macht dann 7,5 Watt. Rechnen wir mal mit
einem Schaltnetzteil mit 75% Wirkungsgrad, habe wir rund 10 Watt.

So: 10 Watt  24 Stunden  365 Tage = 87,6 kWh im Jahr.

Bei einem Strompreis von rund 0,20 €/kWh sind das 17,52 Euro im Jahr.

In meiner Rechnung sind die 0,5 Watt pro Koppler eher an der oberen
Grenze (ohne Relais) anzusiedeln, und die 15 Kopller in einem
kompletten Haus eher an der unteren Grenze.

Die Stromkosten sind also zu verkraften.

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch den Verbrauch der Relais kann man sehr niedrig halten, indem man
Sie mit einer kleinen Sparschaltung aus einem Widerstand und einem
Kondensator ansteuert. Damit läßt sich die Leistung auf ca. 1/4
reduzieren und sie schalten trotzdem mit voller Leistung ein. Dann
kommen die 20 Euro im Jahr gut hin. Ich habe insgesamt 33 Knoten, einen
kleinen Webserver und 5 Displaymodule und komme auf 22 Euro im Jahr.
Das verbraucht mein Nachbar mehrmals wöchentlich in der Kneipe.

Koopi

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref: soo, lang nerv ich nicht mehr, dann wirds konstruktiver :)
kann es sein das die parametrierbarkeit bei dir eine menge speicher
frisst?
bei tastendruck ein zugeordnetes telegramm ist ja nich so schwer.
aber mal will ich auch langen tastendruck melden mal nicht...
aber in nem anderen fall soll das ein ausgang sein und ne led steuern.
und in noch nem anderen fall ein lcd...
so flexibel möchte ich sein/bleiben... nur das bläst die knotensoftware
echt auf.
ist das in diesem umfang bei dir parametrierbar?

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rehallo,

ich will mich auch mal wieder zurückmelden, aber bei Euch kommt man ja
kaum beim Mitlesen mit, geschweige denn mitzuschreiben ;-)

@Danny:
Bei mir funktioniert das mit der Parametrisierung ungefähr so:

Ein Buskoppler besteht aus Software-Sicht aus 32 (30+1+1) virtuellen
Modulen. Ein Modul ist dabei für genau eine Basisfunktion zuständig,
z.B.:
* einen Taster auswerten
* 2 Jalousie-Relais ansteuern
* eine Lampe schalten / dimmen
* LCD (-Teilbereich) ansteuern
Jedes Modul hat einen Parameterblock (module_parm, module_parm_typ). In
diesem wird festgelegt, welche Funktion dieses Modul übernehmen soll
(z.B. Jal.-Relais-Funktion), welche Hardware-Nummer angesprochen werden
soll (z.B. Jal.-Relais 7 und 8) und auf welche CAN-Nachrichten reagiert
bzw. welche verschickt werden sollen (max. 12 je Modul).

Jeder Buskoppler kann also bis zu 30 unterschiedliche Aufgaben
erfüllen: es ist möglich, gleichzeitig Taster auszuwerten, Relais
anzusteuern und das LCD zu bedienen.

Die Buskoppler-Basissoftware besteht aus einem Scheduler, der
eingehende Nachrichten an die Module verteilt und gleichzeitig die
Timerfunktionen verwaltet (eine Art Mini-Betriebssystem also). Eine
Funktion (z.B. Jal.-Relais schalten) kann dadurch sehr einfach
aufgebaut werden:
* eine Init-Funktion
* eine Message-Receive-Funktion
* eine Timer-Funktion
Der Parameter Hardware-Nummer (hw_nr) gibt dabei im Beispiel des
Jal.Relais an, welche 2 Relais von diesem Modul benutzt werden. Nur
diese werden initialisiert und im Weiteren auch angesprochen.

Soweit erstmal, später mehr, viele Grüße, Stefan

Autor: Hardy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das ist alles sehr interessant, aber hat sich schon mal jemand
Gedanken über den (Ruhe-)stromverbrauch der einzelenn Koppler
sowie des gesamten Systems (incl. Nidervolt-Trafo) gemacht? Das ist ja
heutzutage ein nicht unwesentlicher Punkt!

Hardy

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hardy: hast du die postings 2 weiter oben nicht gelesen????

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Koopi:

Bei der Widerstand/Kondensatormehtode muss man allerdings aufpassen:
Denn wenn die Relais wärmer werden (davon kann man in einem
Schaltschrank ausgehen), brauchen die deutlich höhere Spannungen damit
sie noch zuverlässig halten.

Unbedingt Relais-Datenblatt genau lesen! Die Temperaturabhängigkeit ist
nicht zu verachten!

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus Gründen des Stromverbrauchs betreibe ich meine Buskoppler übrigens
bei 3,3V. Die CPU-Frequenz nur so hoch wählen, wie wirklich
erforderlich, und als Regler einen mit niedrigem Eigenstromverbrauch
wählen.
Die Relais sind wirklich der größte Stromverbraucher. Bei den Jalousien
ist es egal, die laufen eh fast nie, und die Lampen sollen mittelfristig
mit Dimmern angesteuert werden.

Gruß, Stefan

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@stefan: 2 Fragen :)

hast du schon geeignete dimmerhardware gefunden? ich möchte nämlich
gern (rein aus versucherungsgründen etc...) geprüfte (zugelassene)
dimmerhardware verwenden. dimmbare evg´s gibs ja... aber normale
steuerbare dimmer hab ich noch nicht gefunden...
hast du schon was im auge? oder willst diese selbst aufbauen?

kannst du grob abschätzen wieviel % deiner knotensoftware die
parametrierbarkeit ausmacht?
übers parametrieren zerbrech ich mir grad den kopf, nur muss man ja (um
alles nutzen zu können) eine ganze menge programmieren, was man nicht
benötigt bzw. was nötig ist um den knoten parametrierbar zu machen
auch überlege ich grad den sinn, da ja ein bootloader per can auch
läuft (oder laufen kann)...
und das beim neu flashen über den bus der knoten in dem moment nix tun
kann is ja nebensächlich, ausgänge würden eh über die serielle
porterweiterung gehalten...

Autor: Christian Wonschina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei conrad gibts welche um ca 50 eur,
ansteuerbar per i2c.

198369 i2c-leistungsdimmer

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@christian: danke für den Tip!

aber... ich sehe keinen unterschied zwischen eigenbau und diesem
conrad´zeug´s in bezug auf die VDE oder CE oder sonstiges... oder
täusche ich mich?

Ich habe nirgends entsprechende siegel gefunden, von daher kommen die
leider auch nicht in betracht - wie gesagt... der eigenbau wär auch
kein problem, aber aus versicherungstechnischer sicht o.ä. möchte ich
für die schnittstelle bus/leistung geprüfte und zugelassene hardware
nutzen...

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Danny,

genau das Problem habe ich auch - ich habe schon öfters gesucht, aber
noch nichts brauchbares gefunden :-(     ... als ich Dein Posting las,
hatte ich schon insgeheim gehofft, DU hättest schon sowas gefunden. Das
ist auch der Grund, warum die Lampen immer noch an (provisorisch
installierten) Relais hängen und noch nicht dimmbar sind.

Wenn ich nichts brauchbares finde, werde ich sie wohl doch noch selber
aufbauen - immerhin: Dimmer bauen darf ich mit meinem Studium ja, nur
nicht installieren ;-)

Zur Parametrisierbarkeit:
Die einzelnen Parameter der Module liegen im Moment in einer Tabelle -
das Ändern der Parameter über den Bus habe ich noch nicht
implementiert. Wieviel Platz mein Ansatz benötigt, kann ich so nicht
sagen, ist bei mir aber auch keine Frage: ich benutze den mega16 bzw.
mega32 und sehe keine Platzprobleme damit. Ohne die Fonts für das
Graphikdisplay würde es sicher auch noch in 8kb reinpassen. Der mega16
war für mich die 1.Wahl wegen der jtag-Debugmöglichkeit. Die mega32
benutze ich für Buskoppler mit LCD, da ich dessen Inhalt im RAM
komplett zwischenspeichere (LCD ist über SPI angebunden ohne
Rücklesemöglichkeit der Graphikdaten).

Übrigens, zum Thema Selbstbauplatinen:
Bist Du sicher, Dir das antun zu wollen? Immerhin hast Du bei
industriell gefertigten Platinen Stoplack drauf, und die Qualität ist
eine ganz andere als die Selbstbauteile. Ich habe mir 50 Stück
Buskopplerplatinen machen lassen und bin auf 3,80€ pro Stück (+Mwst.)
gekommen.

Viele Grüße, Stefan

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@stefan:
zur programmgrösse... mir gehts es nicht drum es in einen kleineren µC
quetschen zu wollen, sondern wie ich schon schrieb: ich habs mal
durchgespielt und kam auf 40% eigentliches programm und 60%
"overhead" für die parametrierbarkeit. (wenn dann würd ichs zu 100%
machen und denn muß auch TWI, UART, kurzer Druck, langer Druck, eben
alles mit rein...).
und die parameter müsste ich eh über den bus laden, da kann ich auch
gleich per bootloader neu flashen...

meinungen?

ihr seht schon, ich habe meine ansichten in bezug auf die
programmierung ziemlich geändert (dank dieser diskussion, es ist
dadurch einiges einfacher geworden g)

zu den platinen... naja ich habe alles auf einer einseitigen Platine
mit 0,3mm breiten leiterbahnen, ergebnis sieht sauber aus.
lötstopplack wird aufgesprüht... eigentlich alles schön :)

wo hast du denn die platinen machen lassen?

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, man muss etwas in anderen Gefilden (EIB, DALI, DMX, ...) wildern,
dann findet man z.B.:

http://www.eib-home.de/se_lightmanagement_eib-4fac...

(Dazu habe ich auf einer anderen Webseite mal ein Preis gesehen und
schnell wieder weggeklickt: rund 700,- Euro...)

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dany P.
> also würden meine hardwarefilter auch überflüssig bzw. bringen nicht
> mehr so die dolle vereinfachung, kannst du das so bestätigen?
kann ich bestätigen.

> SolidStateRelais lieber wären als Standart-Relais
Ich würde auf bewährte Technik setzen. Bei Rolläden z.B. garnicht gut,
wenn die SSR-"Kontakte" "zusammenkleben" (Kurzschluß im
Fehlerfalle). Außerdem gibt's keine UM-SSRs.
Und wg. Stromverbrauch... es gibt auch bistabile Relais - damit kann
dann das Netzteil wieder kleiner ausfallen, da der dauerhafte
Haltestrom entfällt... oder einfach überlegen, ob das Relais längere
Zeit eingeschaltet ist oder aus. Dann danach entsprechend das UM-Relais
anschließen.

@Unbekannter:
> was die Relais verbrauchen, spielt ja nun wirklich eine
> untergeordnete Rolle. [...] Denn wenn es angezogen ist, läuft da in
> der Regel ein deutlich größerer Verbraucher mit.
Naja, relativ betrachtet schon. Aber ob ich nun absolut 20EUR pro Jahr
weniger Strom brauche oder nicht, macht schon einen Unterschied.

@Dany P.
> kann es sein das die parametrierbarkeit bei dir eine menge speicher
> frisst?
Hm, ob ich jetzt mit einem konstanten Wert für etwas arbeite oder ob
ich etwas parametrierbar mache, ändert eigentlich nichts am
Speicherverbrauch. Ob Konstante aus ROM, Variable ausm Eeprom oder aus
RAM - das ist ziemlich egal.
> aber in nem anderen fall soll das ein ausgang sein und ne led
> steuern. und in noch nem anderen fall ein lcd...
Du darfst halt nicht diskret den Code reinprogrammieren, sondern alle
Fälle gleich behandeln (nämlich ein CanTelegramm versenden) und schon
ist das Code dazu sehr kurz. Ob das CanTelegramm jetzt ein Ausgang, ne
LED oder sonstwas schaltet ist ja egal.

Prinzipiell hab ich das ja anders aufgezogen... mit dieser
DataObjectTable. Das soll eine universelle Tabelle sein, in die alle
Parameter, Größen usw. eingetragen werden und auf die lesend und
schreibend über CAN zugegriffen werden kann - auch die Applikation
liest und schreibt da rein. Somit ist der Applikation selbst egal, ob
die Parameter von "innen", außen über CAN, oder Konstanten sind - sie
kann und will es nicht unterscheiden.

> knoten parametrierbar zu machen auch überlege ich grad den sinn, da
> ja ein bootloader per can auch läuft
Naja, ich will bei einer Umkonfiguration nicht den Compiler anfwerfen
und neu flashen müssen, sondern das komfortable Konfigprogramm starten
und die Umparametrierung mit der Maus vornehmen...

> wo hast du denn die platinen machen lassen?
privat und Prototypen bei mvpcb.de
für die "Serie" dann bei multipcb.de (Gewerbeschein)

Autor: Danny P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@and_ref:
es ist fürchterlich schwer meine gedanken dazu kurz aufzuschreiben
:)
aber wenn ich alle möglichkeiten µC´s vorbereiten möchte (damit diese
parametrierbar sind) ist das ein enormer umfang...

ein-/ausschalten oder sowas - kein thema...

und woher die variable kommt..
mal ein beispiel: ich frage den Taster an portb,1 ab

da müsste ich vor der abfrage erst "portb" ausm eeprom laden,
anschliessend "pin 1", dann abfragen... und das bei jedem
durchlauf...
da hab ich doch schon 2/3 der zeit nur parameter geladen um dann 1/3
abfrage zu machen... das übers ganze programm frisst doch auch ne menge
zeit (ja ich weiss bringt den µC nicht um)..

einfacher gehts doch nun nicht, oder?

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> es ist fürchterlich schwer meine gedanken dazu kurz aufzuschreiben
> :)
Na das ist doch nicht schlimm, dafür gibt's doch jetzt ein neues Forum
hier :-)... speziell zum Thema Hausbus - da kannst du deinen Gedanken
freien Lauf lassen...

http://www.mikrocontroller.net/forum/list-11-1.html

Andreas hat den Interessenten dieses Hausbus-Threads ein eigenes
Unterforum eingerichtet. Dorthin gelangt man (vorläufig) aber nur über
den angegebenen Link, also am besten ein Lesezeichen setzen.

...............................................................
Es wäre schön, wenn die Diskussion dort weitergeführt werden könnte.
Schauts euch einfach mal an (gehört ja schließlich auch zu
mikrocontroller.net).
...............................................................

@Danny P.
Ich werde mal meine Antwort auf deinen letzten Beitrag dort posten.

Autor: Radio (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mir gerade den gesamten Thread ,mit großem Interesse,
durchgelesen, und würde mich von daher eher als Noob bezeichnen. (wie
Ralf so nett Ausgedrückt hat). Ich selbst habe ein ähnliches Projekt
vor, und wollte mal fragen was ihr von dem Bussystem P-Net haltet?

www.p-net.dk

Unter diesem Link, findet ihr auch ein kleines Paper, welches den Bus
kurz beschreibt.

http://www.p-net.dk/download/590005.pdf

Autor: Hansi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für den Hausbus gibt es ein Selbstbauprojekt, das mit i2C läuft:
http://hauscomputer.gmxhome.de/
zwar mit Löten verbunden, läuft aber bei mir stabil. Meine Rollläden
und die ganze Extras (Lampen, Brunnen usw.) hängen daran. Kaum Wartung
erforderlich. Den Hochzeitstag kann ich jetzt auch nicht mehr vergessen
(Kalender ist dabei).

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist doch kommerziell!

Hier geht es es um Hobby-Projekte...

Autor: Hansi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Das ist doch kommerziell!"
- Stimmt so nicht, wenn du einmal die Woche den PC resetest, brauchst
du dich nicht anmelden. Trotsdem Entschuldigung Andreas für Link. Ich
suche aber noch eine Kopplung zum Fernsteuerungssystem FS20 von ELV,
gibt es jemanden, den das beschäftigt?

Autor: Günter Knöpfel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die vorherigen Beiträge habe ich mit Interesse gelesen, vielen Dank für
die vielfältigen Anregungen.
Habe in meinem Haus ein Bussystem seit über einem Jahr in Betrieb und
baue es ständig weiter aus.
1-wire ist extrem kostengünstig. Busadapter ca 40 €, Sensor 1,20 €
Aktor zur Ansteuerung einer LED auch 1,20 €. Ein paar Bauteile incl.
einem Relais, zur 220 V Anschaltung kosten ca 5 €.
Ja, es ist ein zentraler PC im Berieb. Wenn der ausfallen sollte, geht
nichts mehr. Ist aber noch nicht vorgekommen und wenn, dann habe ich
noch ein paar andere PC, die den Betrieb wieder aufnehmen können. An
den PC bestehen keine besonderen Anforderungen. Ich kann mir nicht
vorstellen, dass es einen PC gibt, der diesen Bus nicht steuern kann.

Die Programmierung habe ich mit Visual Basic realisiert.
Es gibt andere Ansteuerungsmöglichkeiten für den Bus aber für mich war
das kein Thema, da ich ohnehin einen Server für viele andere
Dinge(Videorekorder, Fotosammlung, MP3, Telefonarufüberwachung, FAX,
Outlook-Server usw.) laufen habe. Den Bus macht der nebenbei.

Es sind derzeit 30 Sensoren und 30 Aktoren in Betrieb (Rolläden,
Lampen, Bewegungsmelder, Heizungs- und Pumpen-
Betriebszeiten-Aufzeichnung usw.).

Als Bus-Leitung habe ich (entgegen anderen Empfehlungen) alte
vorhandene Telefonleitungen verwendet. Das Netz ist sternförmig
angelegt. Alle Leitungsabschnitte zusammen erreichen sicher eine Länge
von über 100 m.

Es sind 3 Kabeladern beschaltet (Masse, Datenleitung und eine +12V zur
Ansteuerung von Relais).

Die Sensoren werden ca. 8 - 10 mal pro Sekunde abgefragt. Es ist daher
keine Verzögerung beim Schalten festzustellen.

Ich habe lange nach einer solchen Lösung gesucht und bin nun begeistert
von dem sicheren, störungsfreien Betrieb.

Günter Knöpfel

Autor: hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi

eigentlich sollte man ja hier weiterdiskutieren:
http://www.mikrocontroller.net/forum/list-11-1.html

egal, Günter kannst du vieleicht bitte die schaltpläne deiner
buskoppler veröffentlichen?

Autor: Günter Knöpfel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hannes,
denke mit deiner Frage meinst du die Anschaltung der Sensoren und
Aktoren an den Bus. Bei den Sensoren ist nichts weiter als ein Schalter
oder besser Taster und der Busbaustein DS2401 erforderlich.
Die Aktoren haben einen Ausgang der nur einige mA bringt, daher ist
hier die Verstärkung eines Transistors angesagt. Ein kleines Beispiel
der Schaltung habe ich als Anlage beigefügt.

Ich hoffe, ich bin nicht der einzige, der Erfahrungen mit 1-Wire hat,
würde mich sehr über Beiträge anderer User freuen.

Gruß
Günter

Autor: stromi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Günter

Also, um deine Anknüpfung zu ELV-Systemen noch mal auf zugreifen:
www.ipsymcon.de und dann auch noch das Forum bietet das und noch viel
mehr.
Guckst du

Autor: stromi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag dazu : Man braucht nur die Soft, 39 Euro, wenn man die
ELV-Geräte nicht hat, weil die ser. Schnittstelle usw. unterstützt
wird.
Man braucht auch nicht die Prof.-Version bei FHT-Geräten,das funzt auch
mit der einfachsten Version. Und die anderen Möglichkeiten sollte man
mal schauen: ISDN Sprach Ansage Text sprechen lassen wenn ein Ereigniss
stattgefunden hat.

Autor: stromi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Günter
Sorry, die Antwort galt Hansi Müller, aber 'ne Frage:
Wie läuft den die Temperaturabfrage, über einen 1Wirer PC-Ankopplung am
PC oder wie muss ich mir das vorstellen?
Kann man fragen, wie aufwendig das PC-Programm ist, um ein Beispiel
bitten?

Autor: Günter Knöpfel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo stromi,
Beispiele gibts hier,

http://www.maxim-ic.com/products/ibutton/software/...

Es bestehen verschiedene Möglichkeiten über unterschiedliche
Treibersoftware und unterschiedliche Programmiersprachen. Ich habe mich
für TMEX als Treiber und Visual Basic als Programmiersprache
entschieden, weil ich damit ein wenig Erfahrung habe.

Gruß
Günter

Autor: Joachim Börke (joachimb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günter,

ich interessiere mich für den 1-wire-bus, um damit meine Heizung zu
steuern. Als Basis verwende ich den Webserver von Ulrich Radig auf der
Hardware von Holger Buss. Das Projekt ist soweit gediehen, das ich die
Temperaturen mehrerer DS1820 auf einer HTML-Seite ausgeben kann.
http://www.mikrocontroller.net/forum/read-4-248219.html#new
Das Einlesen eines Bits über das Zuschalten eines
Seriennummernbausteins sorgt im Schaltaugenblick für Störungen auf dem
Bus. Ich habe deshalb bisher davon Abstand genommen. Wie wirkt sich das
Problem bei Dir aus?

Gruß
Joachim

Autor: Günter Knöpfel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joachim,

die ds1820 frage ich nur alle 30 sekunden ab. Die Sensoren ds2401
werden 8 mal pro Sekunde abgefragt. Störungen sind bei mir nur durch zu
lange Leitungen bei weniger leistungsfähigen Busadaptern aufgetreten.

Kann man im www was zu deinen Komponenten "Als Basis verwende ich den
Webserver von Ulrich Radig auf der
Hardware von Holger Buss" nachlesen?


Gruß Günter

Autor: stromi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Günter
Und wie schliesse ich das Hardwaremässig an? Par. oder Ser.?
Kann man den Adapter selbst bauen?

Autor: Günter Knöpfel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es ist ein serieller Busadapter "LINK 45 (from ibuttonlink.com)
RS232-1-wire adapter from IButtonLink, Serial DB9/RJ45 connector, 300m
range, with ID-Chip".

Die Bauteile habe ich in Österreich bei
http://shop.medhost.at/index.html?1-wire.htm eingekauft.

Erst mit diesem Buskoppler habe ich eine angemessene
Übertragungsqalität auf dem Bus erreicht. Mit einfacheren Busadaptern
kam es insbesondere zu Fehlern bei der Statusabfrage der ds2405. Mit
einfachen Selbstbaulösungen wäre ich sehr unsicher, ob die von mir
genannten Anzahlen der Bauteile und Leitungslänge bei einer wie in
meinem Bus sehr schlechten Leitungsqualität (alte Telefonleitungen,
Flachband, Klingeldraht und in Abschnitten sogar Starkstomkabel NYM) zu
erreichen sind.

Gruß Günter

Autor: Joachim Börke (joachimb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günter,

die Webserversoftware stammt von Ulrich Radig:
http://www.ulrichradig.de/
Die Leiterplatte von Ulrich wird m. W. jedoch nicht zum Verkauf
angeboten. Ich verwende deshalb die Leiterplatte von Holger Buss, die
für 10€ zugügl. 2€ Versand erhältlich ist.
http://www.mikrocontroller.com/
Bei der Leiterplattenbeschreibung ist auch eine angepaßte Version des
Webservers erhältlich.
Ich habe die Webserversoftware um ein one-wire-Interface erweitert.
Damit kann ich drei Busleitungen gleichzeitig betreiben. Die
Interfacebeschaltung ist nur ein Pullup-Widerstand am Controllerpin.
Der Controller sorgt für einen aktiven Pullup, so daß ich gleichzeitig
mehrere Thermometer die Temperaturumwandlung machen lassen kann.
http://www.mikrocontroller.net/forum/read-4-248219.html#new
Im Zip-File findest Du eine ausführliche Anleitung.

Gruß
Joachim

Autor: Günter Knöpfel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle,
habe einen Fehler in meinem obigen Schaltplan entdeckt. Hab mich über
das Interesse gefreut und den plan etwas zu schnell gezeichnet. Dabei
habe ich den Transistor mächtig falsch dargestellt.

Nachgebaut hat ja wohl noch keiner, sonst hätte es bestimmt Proteste
geregnet.

Hier also nochmal die berichtigte Version.

Gruß
Günter

Autor: henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
finde rs 485 am besten, da strombus und daher wenig störanfällig.
meines wissens können bis zu 32 teilnehmer am draht hängen.

Autor: AllesEaSy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..hm..wenn ihr was von Haus-Elektro Installation wollt..kuckt mal die 
Lösungen von Moeller Easy..frei erweiterbar..über ein eAsy-link (2 
adern, jYsty 2x2x0,6) kann ein zusatzgerät angeschlossen werden, dass 
etwa 30 meter entfernt ist...oder wen nGeld keine Rolle Spielt..eine 
eAsy 800er mit NET..also ziest Netzwerkleitungen zum verbinden..und evlt 
das ganze an dein Router/PC, wo du drauf zugreifen kannst, alles 
Beobachten kannst, und fernschalten und natürlich die anlage 
Umprogrammieren..

http://www.moeller.net/de/industry/switchgear/swit...

Beitrag #3766676 wurde von einem Moderator gelöscht.

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.