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
>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 ...
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
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.
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
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).
CARACA sieht ganz nett aus : http://caraca.sourceforge.net/ scheint aber auch nicht mehr aktiv zu sein...
@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")
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
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.
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?
Angehängte Dateien:
-
Dsc00365_k.jpg
77 KB -
Dsc02909_k.jpg
12 KB -
Dsc02560_k.jpg
69 KB
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.