www.mikrocontroller.net

Forum: Haus & Smart Home Hausbusprojekte mit CAN


Autor: Wewa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle miteinander,

ich bin auf der Suche nach einem openSource Hausbusprojekt, da ich plane 
so etwas bei mir einzusetzen und gegebenenfalls auch dabei mitzuwirken. 
Ich denke CAN bietet sich am besten dazu an.

Ich habe auch schon einige Projekte gefunden (auch hier -> 
http://www.mikrocontroller.net/articles/CAN_als_Hausbus).

Nun möchte ich nicht bei einem Projekt ansetzten dass nicht wirklich 
umgesetzt bzw. weiter entwickelt wird.

Könnt ihr mir ein ziemlich ausgereiftes Projekt nennen, dass auch aktiv 
weiterentwickelt wird?

Danke

MFG Wewa

Autor: lrlr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Könnt ihr mir ein ziemlich ausgereiftes Projekt nennen, dass auch aktiv
>weiterentwickelt wird?

ich beobachte das Forum hier schon sein ein paar Jahren, mir wäre noch 
keines untergekommen ...

Autor: Thomas W. (tomiondrums)
Datum:

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

Autor: Wewa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht es mit diesem Projekt aus: 
http://home-automation-project.netmb.net/

Das scheint mir schon ein wenig weiter gediegen.

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.

Autor: Carsten W. (carsten_w)
Datum:

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

Autor: Wewa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir die Hardware dieses Projektes jetzt ein wenig angeschaut.

Die Aktoren (wie z.B. Relaisstufe, Jalousieansteuerung) werden ja gar 
nicht über einen CAN angesteuert! Diese ganzen werden ja Aktoren nur 
über die Ausgänge der Control-Unit angesteuert.
Dann brauche ich ja mindestens eine CU pro Raum und dann Unmengen von 
Kabel von der CU zu den Aktoren/Sensoren.

Wäre es nicht sinnvoller, die Aktoren usw. bekommen die Befehle mittels 
CAN übermittelt?
Kurz gesagt CAN sollte nicht nur in der Leitebene sondern auch in der 
Feldebene eingesetzt werden (für was er ja eigentlich gedacht ist).

Autor: sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CARACA sieht ganz nett aus : http://caraca.sourceforge.net/
scheint aber auch nicht mehr aktiv zu sein...

Autor: Carsten W. (carsten_w)
Datum:

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

Autor: Robert L. (lrlr)
Datum:

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

Autor: Thomas W. (tomiondrums)
Datum:

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

Autor: Thomas W. (tomiondrums)
Datum:

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

Autor: Tien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

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. Hier im speziellen die Posts von Markus B. p. (mbp-bayern).
Er ist derzeit dabei eine universelle Buskoppler Platine zu entwerfen.
Eckdaten:
- PIC18F mit CAN Controller (z.B. PIC18F4685 od. pin kompatibel)
- Schaltregler oder eventl. Recom DC/DC Wandler für 24V DC Versorgung
- CAN Transceiver
- Grundlegende Peripherie (siehe Threads)

Ich denke das könnte genau die von Dir angesprochene Platine sein, auf 
der dann unterschiedliche SW Lösungen laufen können. Das ganze wollen 
wir als OpenSource anbieten, d.h. Markus will die Schaltplan und 
Layoutdaten auf seiner Homepage veröffentlichen. Parallel dazu werden 
wir diese Daten auch auf der Projektseite von techHomeAutomation
http://code.google.com/p/tech-home-automation/
anbieten. Eventl. macht es dann auch Sinn die Platinen in einer 
Sammelbestellung zu ordern, aber zunächst sind erstmal ein paar 
Prototypen wichtig.

Auf der Softwareseite läuft auch schon einiges. Christian hat bereits 
einiges der Basis Software umgesetzt. Die Basis Software soll all das 
beinhalten, um damit am Bus kommunizieren zu können und auch um den 
Knoten reprogrammieren zu können. Derzeit ist die Software aber noch 
nicht so weit, dass sie bereits für Applikationen eingesetzt werden 
könnte.

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.

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. Dies soll später eine Fallbacklösung sein, wenn der Bus 
abgeschaltet wird oder defekt ist. Das entzerrt die Problematik Hausbau 
und Elektronik/SW-Entwicklung extrem und läßt daraus wieder ein Hobby 
werden und nicht Notwendiges Übel.

Dann gibt es weitere Neuigkeiten. Max hat das Protokoll der Eltako RS485 
Dimmer und Relais angeschaut. Es ist laut seinen Berichten möglich die 
Eltakos zu steuern und zwar absolut. D.h. man kann dem Dimmer per RS485 
z.B. den Befehl geben auf 45% zu dimmen. Das sind meiner Meinung nach 
die idealen Aktoren für den Eigenbau. Um dennoch ein Fallbacksystem zu 
haben lässt sich das RS485 Eingangsmodul nutzen (10 Eingänge). Immer 
wenn der Bus ok und aktiviert ist trennt man dann die RS485 Verbindung 
zw. Eingangsmodul und Dimmer bzw. Relais per Reed Relais auf und fängt 
per µC die Botschaften des Eingangsmoduls ab und sendet die Befehle zu 
den Dimmern bzw. Relais.
Infos zu diesem Thema: Beitrag "Dimmer für den Verteilerschrank mit Steuerinterface"

Soweit mal kurz zum Stand der Dinge,
eventl. ist das ja auch was für Dich.

Grüße Timo

Autor: Wewa (Gast)
Datum:

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

Autor: Tien (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darfst Dich gerne dem Projekt anschließen.

Autor: Thomas W. (tomiondrums)
Datum:

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

Autor: Timo E. (tien)
Datum:

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

Autor: Thomas W. (tomiondrums)
Datum:

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

Autor: Timo E. (tien)
Datum:

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

Autor: Thomas W. (tomiondrums)
Datum:

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

Autor: Thomas W. (tomiondrums)
Datum:

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

Autor: Timo E. (tien)
Datum:

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

Autor: Thomas W. (tomiondrums)
Datum:

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

Autor: Markus Müller (mmvisual)
Datum:
Angehängte Dateien:

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

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.