Hausbusprojekte mit CAN

Hi Wewa,
ich arbeite derzeit an einem solchen Projekt. Finden wirst du derzeit 
keines, das deinen Anforderungen genügt -- ich beobachte das auch schon 
seit einiger Zeit: Entweder die Sache ist nicht ausgereift oder sie ist 
nicht wirklich OpenSource.

Vielleicht kann ich dich ja auch ein wenig für mein Projekt begeistern:
Oberstes Ziel ist es, daß das Projekt von mehreren Personen langfristig 
betreut und deshalb OpenSource wird.
Ich bin der festen Überzeugung, daß Interesse an einer Sache nur dann 
geweckt und auch dauerhaft erhalten werden kann, wenn das Konzept leicht 
zu verstehen (-> Neueinsteiger) und dennoch flexibel (-> komplexere und 
'zukünftige' Anwendungsgebiete sollen erschließbar sein) ist.

Ich lege mich nicht auf eine Mikrocontroller-Familie oder 
Betriebssystem-/ Software-Plattform fest. Selber verwende ich (zumindest 
für den Anfang) PIC18F****-µC's, als Compiler SDCC und C18, arbeite mit 
Debian Linux (soweit möglich) und schreibe Server (PC) Software in C++ 
und Java. Wesentlich an meinem Projekt ist die Spezifikation eines 
(L7-)Protokolls und die Erstellung von ein paar 
Referenz(!!)-Implementierungen. Weitere und Alternativen mögen folgen.

Ich arbeite z.Zt. neben den ersten Referenz-Knotenprototypen und einer 
Java-Referenzimplementierung der Serversoftware an vier oder fünf 
Übersichtsdiagrammen, die jeweils auf einen Blick klar machen sollen 
"wie das Ganze funktioniert". Fließtext gibt's aber auch noch noch -- 
keine Angst!

Veröffentlicht hab ich den aktuellen Stand der Entwicklung noch nicht, 
weil mir dazu einfach noch die Zeit gefehlt hat.

Sollte ich Interesse geweckt haben, so freue ich mich sehr über 
Rückmeldungen. Dann kann ich gerne auch konkreter werden, als dieser 
allgemeine Fluff... ;-)

MfG
 Tom

Wewa schrieb:
> Jedoch gefällt mir hier nicht, dass da alles von einer zentralen
> Steuereinheit gesteuert wird. Mir wäre es lieber, wenn das mehr auf die
> einzelnen Geräte verteilt würde.

Hi,

jede Control-Unit führt doch eigenständig Steueraufgaben durch. Nur wenn 
du komplexere Steuerungen duchführen willst, macht man dies optional 
über einen Linuxserver.

Gruß
Carsten

@Wewa

Prinzipiell stimme ich dir zu aber selbst beim Standard KNX/EIB-Bus wird 
in der Regel bei einem normalen Einfamilienhaus zum größten Teil auf 
zentrale Aktoren in der Unterverteilung zurückgegiffen. Nur die 
Lichttaster, Präsenzmelder usw. hängen in den Räumen an dem Buskabel.
Ist ein reines Rechenbeispiel, ob man in allen Schalterdosen Controller 
haben möchte oder z.B. einfach ein CAT5 Kabel zur Unterverteilung zieht.
Auf der 230V-Seite musst du ja auch eh für die verschiedenen Verbraucher 
getrennt abgesicherte Leitungen legen, da kannst du auch gleich in der 
Unterverteilung den Schaltaktor unterbringen.

Ich habe z.B. pro Etage/Unterverteilung etwa 4 Control-Units Zentral und 
für "Spezialschalter" (6-Fachtaster + 6 Leds) direkt am Taster noch 
Control-Units.

Gruß
Carsten

meiner Meinung nach müsste die Hardware kommerziell hergestellt sein 
(also z.b. "leere" Unterputz und Hutschienen-Module)

mit einer z.b. einfachen ref-implementierung
(so wie z.b. das Polin net-io nur halt ohne lan und mit rs485 oder can)

so funktionieren projekte recht gut (wie eben das net-io, dd-wrt, 
android, ... )


weil: jemand der sich für einen selberbastel-hausbus interessiert, tut 
das i.d.R nur einmal in seinem leben, 2-3 jahre bevor er ein haus baut, 
..
während dem hausbau hat er sowieso keine zeit, und nachher kein 
Interesse..

> meiner Meinung nach müsste die Hardware kommerziell hergestellt sein
> (also z.b. "leere" Unterputz und Hutschienen-Module)
> mit einer z.b. einfachen ref-implementierung
> (so wie z.b. das Polin net-io nur halt ohne lan und mit rs485 oder can)
> so funktionieren projekte recht gut (wie eben das net-io, dd-wrt,
> android, ... )

> weil: jemand der sich für einen selberbastel-hausbus interessiert, tut
> das i.d.R nur einmal in seinem leben, 2-3 jahre bevor er ein haus baut,
> ..
> während dem hausbau hat er sowieso keine zeit, und nachher kein
> Interesse..
das kann ich zu 100% unterschreiben...

leider wurde ich bisher noch nicht wirklich fündig (zumindest was 
entsprechende i/o-module für den CAN angeht). bei den ganzen 
hausbus-selbstbau-projekten packen die leute immer viel zu viel 
krimskrams auf die platinen mit drauf. es würde nämlich sehr helfen, 
wenn man sich zwischen zwei oder drei solcher can-hausbus-projekte 
beispielsweise auf eine gemeinsame hardware für 
standard-tasterschnittstellen, dimmer, etc. einigen könnte. was die 
software betrifft könnte dann ja jeder trotzdem noch sein eigenes 
süppchen kochen...

irgendwie umschleicht mich das gefühl, daß viele dieser projekte vom 
bastlergeist und dem spieltrieb einzelner enthusiasten leben und das 
interesse, mal über den tellerrand zu schauen oder zu suchen, was es 
schon gibt, bei den meisten eher eine untergeordnete rolle spielt.

ich beispielsweise mache derzeit was, worauf ich eigentlich null bock 
hab, nämlich eine primitive schalter-/tasterschnittstelle für den HS-CAN 
zu designen, die zwei hw-entprellte, optoentkoppelte ein- und zwei 
LED-ausgänge (für die kontrolleuchten am lichtschalter) hat und dabei 
noch eine einfache doppeltiefe up-dose passt. kennt hier zufällig jemand 
schon eine bestehende lösung (idealerweise PIC-basiert)?

sven schrieb:
> CARACA sieht ganz nett aus : http://caraca.sourceforge.net/
> scheint aber auch nicht mehr aktiv zu sein...
doch, die letzten commits im CVS sind gerade mal 20 tage her, nur ist 
sourceforge z.Zt. leider down (die hatten einen hacker-angriff und sind 
momentan am "wunden-lecken")

Hallo,
Tien schrieb:
> schau Dir mal die Threads
> Beitrag "Anforderungssammlung CAN Hausbus mit PIC µC"
> und
> Beitrag "Konzept zu einem Hausbus auf CAN-Bus Basis und die Enstehung des Konzeptes"
> an.
Die Threads kenne ich und auch den Busknoten habe ich -- zumindest 
oberflächlich -- schonmal begutachtet:
Ich will diesen knoten wirklich nicht schlechtreden, aber aus meiner 
Sicht ist er für das _was ich vorhabe_ nicht besonders geeignet bzw. 
ein wenig 'over the top', weil
1. hat die Platine eine Diagonale von 55mm. Die wird bestenfalls so 
gerade noch in eine UP-Dose passen; wenn man dann noch mit ein Paar 
störrischen Leitungen zu kämpfen hat, befürchte ich ernsthafte 
Schwierigkeiten.
2. Halte ich es für angebracht, daß ein Busknoten ein (zumindest 
rudimentäres) Gehäuse zu seinem Schutz und zum Schutz der umgebenden 
Gegenstände hat. Habt ihr dafür schon was im Blick?
3. Sind auf der Platine Bauteile drauf, bei denen man als Endverbraucher 
Schwierigkeiten haben dürfte, Sie herzubekommen (TJA1041A, LT1121,...).
4. Auf der Platine ist offenbar eine alternative Bestückungsmöglichkeit 
für den Fault-Tolerant CAN vorgesehen. Dazu habt ihr korrekterweise 
einen Choke vorgesehen, der eine Menge Platz braucht. Solang man kein 
Flugzeug oder eine Atomkraftwerk baut, braucht man allerdings keinen 
FTCAN.
5. Wie ich sehe sind zwar vier FETs offenbar für die Ausgänge 
vorgesehen, aber wo sind die Optokoppler für die Eingänge, um die es mir 
eigentlich geht?
6. Es sind fast rings um die Platine Pfostensteckverbinder vorgesehen. 
Habt ihr vor, da ein Piggyback draufzusetzen? Auch hierdurch geht sehr 
viel wertvoller Platz verloren.
7. Habt ihr schonmal durchgerechnet, welche Materialkosten bei dem Modul 
rauskommen (angenommen, man ätzt sich die Platine selber)?

Ich hab die Threads nicht 'auswendig gelernt', weil die sind ja 
mittlerweile ellenlang. Deshalb hoffe ich, nicht was wichtiges übersehen 
und das Modul deshalb unrechterweise als für mich nicht geeignet 
befunden hab.

Was mir an der Umsetzung gut gefällt ist unter anderem die Lösung mit 
den TVS-Dioden. Die werd' ich mir, wenn's auf meine Platine noch drauf 
passt, von euch abschauen.

> Als RTOS verwenden wir das FreeRTOS (http://www.freertos.org/).
> Desweiteren wird die Basis Software den COM Stack (Abbildung des
> Protokolls), einen EEPROM Treiber, einen Bootloader, einen CAN Treiber
> und eventl. noch einen Treiber für ADC, IO und den DS1820(1 Wire)
> enthalten.
Gut, das ist halt eure Design-Entscheidung, aber ich frage mich immer 
wieder (auch bei anderen Projekten, wie HAP und ISysBus): Warum tut ihr 
euch das an? Denkt doch mal fünf oder zehn Jahre weiter... So ein Taster 
oder was auch immer verschwindet in seiner Dose und tut da hoffentlich 
ewig seinen Dienst. Dabei wird's dann keine Sau mehr interessieren, was 
für super elegante Firmware auf den Busknoten ihren Dienst tut. 
Darüberhinaus verlasse ich mich doch immer dann drauf, daß die, die 
FreeRTOS entwickelt haben, keine Implementierungs- oder Denkfehler 
gebaut haben. Falls doch (Murphys Law) darf ich mich dann notfalls auch 
noch in deren Kram einarbeiten (zugegeben, das ist bei FreeRTOS für die 
PIC18F-Serie derzeit noch recht übersichtlich).

> In meinem Fall steht das Haus bereits und die EIB Bus Leitungen (2 x 2 x
> 0,8mm²) sind an allen möglichen Stellen vorhanden. Die Lichtsteuerung
> erfolgt derzeit per Steuerleitungen und Eltako Stromstoßschalter oder
> Tastdimmer.
Bei mir ist's derzeit so ähnlich. Ich hab auch 12V-Eltako-SSS eingebaut, 
weil ich damals beim Umbau noch nix in Richtung Bussystem in der Hand 
hatte. Die Eltakos für die wichtigsten Sachen bleiben dann im Verteiler, 
werden aber abgeklemmt, wenn der Bus mal fertig ist. Zum Schalten von 
Lasten, werd' ich vermutlich die schmalen Koppelrelais von Finder 
nehmen. Dann hab ich meinen Buskomponenten (SELV) galvanisch vom Rest 
getrennt.



Wewa schrieb im Beitrag #2052433
> Dem mit dem "Jeder kocht sein eigenes Süppchen" kann ich voll zustimmen.
> Selbst in diesem Thread haben schon 2 gepostet, die ihr eigenes Projekt
> verfolgen.
> Was haltet ihr davon, wenn wir uns zusammenschließen, ein gutes
> bestehendes Projekt aussuchen und aktiv daran mitarbeiten?
> Dann müsste man nicht von 0 starten und gemeinsam kommt man auch
> schneller weiter.
Das hätte ich liebend gerne getan und auch eine Menge Zeit investiert 
mich umzuschauen, was die anderen Projekte denn so alles schon haben. 
Leider bin ich, was die Realisierung angeht radikal anderer Meinung:
1. Mein System soll ein strukturierbares Netz sein, d.h. die Möglichkeit 
von (primitivem) Routing und separaten Netzsegmenten mit 
unterschiedlichen Busgeschwindigkeiten ist vorgesehen (...und ja, ich 
habe dafür Verwendung) habe.
2. Weiters glaube ich, daß man Steuerungsaufgaben solcher Art einem 
zentralen, hochsprachenprogrammierbaren Rechner (wie auch immer der dann 
konkret aussieht) überlassen sollte und nicht die Anwendersoftware (also 
z.B. TasterXYZ 2*n-mal gedrückt -> Lampe2...Lampe5 an, sonst selbige 
aus) nicht über mehrere Knoten verteilt unterbringen sollte (Gründe 
dafür ggf. auf Anfrage).

Ich lass mich aber auch gern eines Besseren belehren, falls jemand 
richtig Gute Argumente hat.

MfG
 Tom

Thomas W. schrieb:
> Ich hab die Threads nicht 'auswendig gelernt', weil die sind ja
> mittlerweile ellenlang. Deshalb hoffe ich, nicht was wichtiges übersehen
> und das Modul deshalb unrechterweise als für mich nicht geeignet
> befunden hab.

Naja, Markus entwirft ja derzeit eine neue Platine, welche etwas anders 
ausieht. Zum einen wird er einen Schaltregler darauf plazieren, zum 
anderen fallen einige der IO Geschichten raus. Lies nochmal ab hier:
Beitrag "Re: Anforderungssammlung CAN Hausbus mit PIC µC"

Als Verpackung sehe ich Schrumpfschlauch vor. Da ich Kaiser 
Elektronikdosen in der Wand habe (seperates, seitliches, abtrennbares 
Abteil für Elektronik) sehe ich hier kein Problem.


Thomas W. schrieb:
> Gut, das ist halt eure Design-Entscheidung, aber ich frage mich immer
> wieder (auch bei anderen Projekten, wie HAP und ISysBus): Warum tut ihr
> euch das an? Denkt doch mal fünf oder zehn Jahre weiter... So ein Taster
> oder was auch immer verschwindet in seiner Dose und tut da hoffentlich
> ewig seinen Dienst. Dabei wird's dann keine Sau mehr interessieren, was
> für super elegante Firmware auf den Busknoten ihren Dienst tut.

Doch, es geht ja nicht nur um mein Haus. Das Projekt soll ja OpenSource 
sein, daher denke ich, dass sich nach und nach der ein oder andere damit 
befassen wird. Und wenn eine gute Basis vorhanden ist, ist die 
Programmierung der Applikation deutlich einfacher.

Zum Warum: Hast Du schon mal ein µC mit RTOS programmiert?
Es gibt seine Tücken, ok, aber das schöne ist, dass man unterschiedliche 
Dinge implementieren kann, die voneinander nahezu unabhängig laufen. Da 
ich diesen Komfort beruflich bei der Steuergeräte Entwicklung habe, lag 
es nahe dies auch bei solch einem Projekt zu nutzen. Bei anderen 
Lösungen z.B. Endlosschleife muss man immer daran denken, dass sich 
alles verschiebt, wenn man irgendwo etwas kleines ändert. Das wird bei 
steigender Komplexität aufwändiger als das RTOS einmal anfänglich zu 
konfigurieren.

> Darüberhinaus verlasse ich mich doch immer dann drauf, daß die, die
> FreeRTOS entwickelt haben, keine Implementierungs- oder Denkfehler
> gebaut haben. Falls doch (Murphys Law) darf ich mich dann notfalls auch
> noch in deren Kram einarbeiten (zugegeben, das ist bei FreeRTOS für die
> PIC18F-Serie derzeit noch recht übersichtlich).

Das Problem hast Du bei Fremdsoftware immer. D.h. wenn es darum geht 
muss ich alles selber machen und darf auch keine Software von anderen 
Projektmitgliedern nutzen. Aber dann kommt man nicht weit. Und die 
Verbreitung von RTOS erhöht zumindest die Möglichkeit, das andere 
bereits die Fehler gefunden haben.


Grüße Timo

Timo E. schrieb:
> Naja, Markus entwirft ja derzeit eine neue Platine, welche etwas anders
> ausieht. Zum einen wird er einen Schaltregler darauf plazieren, zum
Welcher wirds dann eigentlich, der von Recom oder der MAX5035. Ich hab 
bei mir 'nen mc34063 drauf -> Platzbedarf inkl. Spule ist überschaubar 
und kostet nur'n Appel und'n Ei ;-)
> anderen fallen einige der IO Geschichten raus.
Gibts schon irgendwo einen (neuen) Schaltplan?

> Als Verpackung sehe ich Schrumpfschlauch vor.
Coole Idee, da denk ich auch mal drüber nach!

> Da ich Kaiser Elektronikdosen in der Wand habe (seperates, seitliches,
> abtrennbares Abteil für Elektronik) sehe ich hier kein Problem.
Hmm, ich hab nur konventionelle, doppeltiefe Dosen drin, ich denke das 
gilt aber auch für die meisten Leute.

Noch eine Frage: Was wollt ihr eigentlich mit dem Temperaturfühler? Habt 
ihr Angst, daß euch der µC zu heiß wird? ;-)

Gibts eigentlich eine Preisvorabschätzung? (Bei meinem Knotenmodul sind 
derzeit, mit allem was nötig ist <=20€, falls ich nix vergessen hab)

Btw. meines Wissens ist bei Verwendung eines normalen 
HS-CAN-Transceivers (á la PCA82C251/MCP2551) keine separate Wakeup 
Leitung zum Aufwecken des PIC notwendig, korrigiert mich bitte, wenn ich 
da falsch liege.

Interessanter wäre (da die Interrupteingänge des PIC ja recht beschränkt 
sind), wie man selbigen aufweckt, wenn's z.B. eine Flanke an einem 
Eingangspin gibt. Z.Zt. fallen mir da zwei Möglichkeiten ein:
1. gar nicht erst einschläfern (der Energieverbrauch ist bei moderaten 
Taktraten eh überschaubar)
2. Lösung mit Monoflops und OR-Gate.
Wie macht ihr das?

> Doch, es geht ja nicht nur um mein Haus. Das Projekt soll ja OpenSource
> sein, daher denke ich, dass sich nach und nach der ein oder andere damit
> befassen wird. Und wenn eine gute Basis vorhanden ist, ist die
> Programmierung der Applikation deutlich einfacher.
Nun, ich verfolge da andere Ansätze, aber das ist ja mittlerweile 
bekannt.

> Zum Warum: Hast Du schon mal ein µC mit RTOS programmiert?
Nein, ich habs mir vor kurzem mal runtergeladen und den Source 
überflogen bzw. ein paar Sachen draus geklaut. FreeRTOS ist eine 
wirklich coole Sache und ich will ihm seine Berechtigung für bestimmte 
Anwendungsgebiete wirklich nicht absprechen, aber preemtive Scheduling 
für einen Tasterknoten...? Naja, jeder wie er mag.

> Das Problem hast Du bei Fremdsoftware immer. D.h. wenn es darum geht
> muss ich alles selber machen und darf auch keine Software von anderen
> Projektmitgliedern nutzen.
> Aber dann kommt man nicht weit.
Jedermanns Erfahrung in Ehren. Meine Erfahrung war bisher immer daß man 
mit "keep it simple, keep it clean" sehr weit kommen kann. Aber daraus 
kann man vermutlich einen richtigen Glaubenskrieg machen, wenn man denn 
möchte.

Hi Thomas

> Welcher wirds dann eigentlich, der von Recom oder der MAX5035. Ich hab
> bei mir 'nen mc34063 drauf -> Platzbedarf inkl. Spule ist überschaubar
> und kostet nur'n Appel und'n Ei ;-)
Markus wird neben dem Schaltregler auch drei Pins für den Recom vorshen. 
Der ist eigentlich perfekt, aber eben recht teuer. Für welchen 
Schaltregler sich Markus entscheidet weiß nicht.

>> anderen fallen einige der IO Geschichten raus.
> Gibts schon irgendwo einen (neuen) Schaltplan?
Ne.


>> Als Verpackung sehe ich Schrumpfschlauch vor.
> Coole Idee, da denk ich auch mal drüber nach!
Zur Not kann man auch zwei übereinander Schrumpfen. Damit sollte ein 
rudimentärer Schutz gegeben sein.

>> Da ich Kaiser Elektronikdosen in der Wand habe (seperates, seitliches,
>> abtrennbares Abteil für Elektronik) sehe ich hier kein Problem.
> Hmm, ich hab nur konventionelle, doppeltiefe Dosen drin, ich denke das
> gilt aber auch für die meisten Leute.
Ja, wird wohl so sein. Generell gebe ich Dir recht, umso kleiner um so 
mehr Platz in der Dose.

> Noch eine Frage: Was wollt ihr eigentlich mit dem Temperaturfühler? Habt
> ihr Angst, daß euch der µC zu heiß wird? ;-)

Nein, der Controller nicht, aber ich will, sofern ich z.B. ein SSR in 
eine Dose baue eine Temperaturmessung machen. Sofern der Gradient oder 
die absolute Temperatur zu hoch ist wird abgeschaltet. Des weiteren gibt 
es einige Nodes, die u.a. die Raumtemperatur erfassen, da ist es nett, 
wenn man die Grundbeschaltung schon auf der Platine hat.

> Gibts eigentlich eine Preisvorabschätzung? (Bei meinem Knotenmodul sind
> derzeit, mit allem was nötig ist <=20€, falls ich nix vergessen hab)

Ohne den Recom sollte es bei <20 Euro liegen. Preistreiber ist die 
Platine, deshalb ist es interessant dort die Menge hoch zu halten.

> Btw. meines Wissens ist bei Verwendung eines normalen
> HS-CAN-Transceivers (á la PCA82C251/MCP2551) keine separate Wakeup
> Leitung zum Aufwecken des PIC notwendig, korrigiert mich bitte, wenn ich
> da falsch liege.

Kannst Du mir da eine Quelle geben?

> Interessanter wäre (da die Interrupteingänge des PIC ja recht beschränkt
> sind), wie man selbigen aufweckt, wenn's z.B. eine Flanke an einem
> Eingangspin gibt. Z.Zt. fallen mir da zwei Möglichkeiten ein:
> 1. gar nicht erst einschläfern (der Energieverbrauch ist bei moderaten
> Taktraten eh überschaubar)
> 2. Lösung mit Monoflops und OR-Gate.
> Wie macht ihr das?

Zunächst ist geplant nicht einzuschlafen, da es mit dem Aufwachen bzgl. 
verlorener CAN Message nicht ganz trivial ist.
Aber wenn, dann kann man direkt nach dem Aufwachen die Pins abpollen. 
Ein Tastendruck ist länger als man zum aufwachen benötigt.

> Jedermanns Erfahrung in Ehren. Meine Erfahrung war bisher immer daß man
> mit "keep it simple, keep it clean" sehr weit kommen kann. Aber daraus
> kann man vermutlich einen richtigen Glaubenskrieg machen, wenn man denn
> möchte.

Dann verstehe ich nicht, warum Du unterschiedliche Busgeschwindigkeiten 
fahren willst, auch das ist nicht wirklich simpel...

Grüße Timo

Timo E. schrieb:
> Ohne den Recom sollte es bei <20 Euro liegen. Preistreiber ist die
> Platine, deshalb ist es interessant dort die Menge hoch zu halten.
selber herstellen ist euch zu aufwendig?

> Kannst Du mir da eine Quelle geben?
Datenblatt vom 18fXX8
http://www.google.de/url?sa=t&source=web&cd=2&ved=0CCkQFjAB&url=http%3A%2F%2Fww1.microchip.com%2Fdownloads%2Fen%2Fdevicedoc%2F41159d.pdf&rct=j&q=pic18f458&ei=5y5RTe-uFovKswaq-ODeBg&usg=AFQjCNEVrqRm0R0DlSEughNqAEVpg_-snQ&cad=rja
such mal nach WAKFIL, WAKIE, WAKIF (ca. Seite 220)

> Dann verstehe ich nicht, warum Du unterschiedliche Busgeschwindigkeiten
> fahren willst,
Der Grund ist schlicht, daß beim CAN die maximal mögliche Leitungslänge 
bekanntlich u.A. von der Busgeschwindigkeit abhängt. Als Fernziel hab 
ich aber vor, meine Gegensprechanlagen in die Businfrastruktur zu 
integrieren. Um das machen zu können, brauche ich ein kürzeres Segment, 
das zu ziemlich hohem Datendurchsatz fähig ist. Andere Segmente dagegen 
werden z.T. über 100m lang, transportieren aber nur sehr wenige Daten. 
Um nicht für jedes Segment ein Gateway zum Server zu brauchen möchte ich 
eben einen 'Router' einsetzen.
> auch das ist nicht wirklich simpel...
Du wärst sicher erstaunt, wie einfach sowas sein kann!

@tien:
Eine andere Sache fällt mir grad noch ein: Ich meine mich zu erinnern, 
in einem eurer beiden Threads gelesen zu haben, den Stromverbrauch der 
Nodes messen und bei einer Grenzwertüberschreitung die jew. Node 
abschalten zu wollen. Habt ihr das immer noch vor und falls ja, wie 
wolltet ihr das machen? (Sowas hätte ich nämlich selber gern, allerdings 
umschleicht mich das Gefühl, daß das nicht so ganz einfach ist.)

Der Strom soll lokal gemessen werden. Dieser Strom wird mit dem 
erwarteten Strom verglichen und außerdem an einen Überwachungsknoten 
gemeldet. Sollte ein Node signifikant mehr als erwartet ziehen versucht 
er zunächst eventl. angesteuerte Aktoren abzuschalten. Wenn der Strom 
trotzdem ausserhalb dem erlaubten Bereich liegt wird nach einem 
Logfileeintrag der Bus vom Überwachungsknoten komplett vom 230V Netz per 
SSS getrennt. Das System geht damit in den Fallback Mode. Ebenso, wenn 
der Strom am Netzteil signfikant über der gemeldeten Stromaufnahme 
liegt.

Grüße Timo

Timo E. schrieb:
> Der Strom soll lokal gemessen werden. Dieser Strom wird mit dem
> erwarteten Strom verglichen und außerdem an einen Überwachungsknoten
> gemeldet. Sollte ein Node signifikant mehr als erwartet ziehen versucht
> er zunächst eventl. angesteuerte Aktoren abzuschalten. Wenn der Strom
> trotzdem ausserhalb dem erlaubten Bereich liegt wird nach einem
> Logfileeintrag der Bus vom Überwachungsknoten komplett vom 230V Netz per
> SSS getrennt. Das System geht damit in den Fallback Mode. Ebenso, wenn
> der Strom am Netzteil signfikant über der gemeldeten Stromaufnahme
> liegt.
Die Frage war eigentlich anders gemeint: Wie soll das 
Schaltungstechnisch gemacht werden, d.h. welche Bauteile wollt ihr dazu 
verwenden?

Hallo,

Da hier ein paar Leute lesen, die gerne etwas standardisiertes auf die 
Reihe bekommen wollen, möchte ich etwas dazusteuern.

Eine Standard-Schaltereinheit hat in der Regel maximal zwei Wippen, ist 
also nicht sonderlich viel. Ich habe mir was anderes ausgedacht.
Wenn man eine einfache "Blindzentralscheibe" kauft, also nur eine 
Blindabdeckung und da dahinter eine kleine Platine mit kapazitiven 
Tasten legt, dann sieht das gut aus und man hat viel mehr 
Tast-Möglichkeiten.
Anbei ein Bilder der Platine, allerdings ist die HW nicht fertig 
entwickelt. Drauf ist ein Schaltnetzteil mit bis zu 60V 
Eingangsspannung, STM32 und der Touch-Chip und CAN-Transceiver, 12 
Tasten mit LED's, alle LED's einzeln über PWM steuerbar.

Als zweites habe ich eine einfache Display-Einheit. Diese habe ich 
selbst in Betrieb. STM32, CAN, RS232, LCD 2x16 oder 3x16 oder 1x8, viele 
Extras die optional bestückt werden können wie Temp-Sensor, Feuchte, 
EEPROM, Relais, Analog-Eingänge, Portpins, RTC/Goldcap.

Die Software ist natürlich auf mein Bus abgestimmt. Aber ich denke die 
Hardware könnte für was nützlich sein.
Wenn jemand interesse hat, Mailen. Bedingung: nur Privat, nicht 
kommerziell.

PS: Die STM32 können auch mit Opensource-Programmen geproggt werden.