Hier in diesem wunderbaren Forum, gibt's eine eigene Rubrik Hausbus mit hunderten von Beiträgen. Manche eher unsinnig, manche aber auf wirklich verdammt hohen Niveau, wo man nur so staunen kann. Es ist auch wirklich toll zu sehen, was so alles entsteht und wie viel Herzblut in Projekte gesteckt wird. Auch die Übersichten über die verwirklichten Projekte finde ich sehr aufschlußreich, aber ... ... was mich wirklich wundert ist die Tatsache, daß es immer wieder Aufrufe gibt ein GEMEINSAMES System zu entwicklen, nur scheinbar alle zum Scheitern verurteilt sind ... warum ist das so ??? Woran scheitert das im Allgemeinen ??? Besteht vielleicht überhaupt kein Interesse an einem GEMEINSAMEN System, weil jeder nur SEINE individuellen Ideen durchsetzen möchte ??? Mich würde eure ehrliche Meinung zu diesem Thema interessieren und welche Erfahrungen ihr vielleicht mit GEMEINSAMEN Forumprojekten schon gemacht habt. liebe Grüße aus Wien Klaus
Mir gefällt Freebus recht gut und auch eine RS485 Lösung, habe den link jetzt nicht zur Hand. Can gefällt mir weniger. Jeder hat so seine persönlichen Vorlieben denke ich mal.
Robert L. schrieb: > Beitrag "Re: Hausbusprojekte mit CAN" Du meinst also, der Schlüssel zum Erfolg könnte wie bei AVR-NET-IO in detailierten Vorgaben und einer ref-Implementierung liegen? Ja das scheint plausibel zu sein, denn wenn man schon beim Protokoll jeden mitreden läßt, bekommt man ja schon das niemals durch, weil eben jeder SEINE Vorlieben hat. Man müßte also vermutlich das Protokoll und die erlaubten Übertragunsmedien exakt spezifizieren und jeder der will darf dann SEIN Modul designen und beitragen. Und sofern man sich an die ref-Implementierung gehalten hat, kann es jeder andere nachbauen und verwenden. So würden sich die besten Module autom. durchsetzen, verbreiten und könnten bei entsprechender nachfrage auch in größeren Stückzahlen als Bausatz gefertigt werden. Das Protokoll müßte nur wirklich unsiversell, leicht verständlich und leicht zu implementieren sein und zwar so leicht, daß es die Leute gerne annehmen und mitmachen. Und es müßte auch leicht erweiterbar sein, weil an ALLES kann man zu Beginn einfach nicht denken! Da wüßte ich zwar im Moment nichts fertiges, hätte aber gute Ideen (die bei mir teilweise schon brauchbar funktionieren) Ich selbst experimentiere mit dem AVR-NET-IO Board habe als Ergänzung bereits auf Basis USART/CAN-Transceiver auch einen zusätzlichen wired-bus und via RFM12 auch den Funk abgedeckt.
chris schrieb: > Mir gefällt Freebus recht gut und auch eine RS485 Lösung, habe den link > jetzt nicht zur Hand. Can gefällt mir weniger. Jeder hat so seine > persönlichen Vorlieben denke ich mal. Freebus ist doch der versuch EIB-Module selbst zu bauen, oder irre ich da? Und warum wollen immer alle RS485, das ja eindeutig NICHT Kollisionsfähig ist. Ein wired-Bus auf Basis USART ist natürlich OK, aber besser wäre es doch die bekannten CAN-Transceiver zu verwenden.
Ich glaube es liegt daran dass Komittees noch niemals etwas brauchbares entwickelt haben, das waren stets Individuen die vorangegangen sind, und der Rest folgte. Spricht ja nichts dagegen dass hier im Forum ein genialer Entwickler DAS hobby-Hausbussystem entwickelt, alle Pläne postet und alle Anderen bauen es nach.
>RS485, das ja eindeutig NICHT >Kollisionsfähig (IMHO) also RS485 ist schon zu kollisionen fähig ;-) sie können auch erkannt werden .. nur muss man alles in software machen ..
Martin schrieb: > Ich glaube es liegt daran dass Komittees noch niemals etwas > brauchbares entwickelt haben, das waren stets Individuen die > vorangegangen sind, und der Rest folgte. > > Spricht ja nichts dagegen dass hier im Forum ein genialer Entwickler DAS > hobby-Hausbussystem entwickelt, alle Pläne postet und alle Anderen bauen > es nach. Du magst mit Deiner Aussage schon bis zu einem gewissen Punkt recht haben, aber es kann doch nicht sein, daß einer alles entwickelt, die Pläne dann postet und alle anderen bauen es nach ... was hätte er denn davon. Nur GEBEN aber nicht BEKOMMEN? Wenn ich die Zeit und das Wissen hätte das alles alleine zu machen, würde ich ein System designen, bauen, programmieren und dann verkaufen, aber doch nicht verschenken? Solche Systeme sind heute dermaßen umfangreich, daß es einer alleine gar nicht schaffen kann! Es geht doch darum, die im Netz vorhandene Energie irgendwie zu bündeln und GEMEINSAM entwickeln. Und auch nicht JEDER kann ALLES. So bin ich z.B. sicher kein schlechter Designer und ein brauchbarer Programmierer, aber ich bin nun mal kein Elektroniker, kann keine Schaltungen brauchbar designen (nur abkupfern) und könnte mich auch nicht um einen entsprechenden Internetauftritt kümmern.
@Klaus M. ich bin hauptsächlich der meinung, dass das SELBER erstellen der hardware das hauptproblem ist, weil DAS die "verbreitung" einfach erheblich erschwehrt.. hardware muss in stückzahlen (mehrere tausend) hergestellt werden, damit es günstig und klein und .. ist da hilft auch eine sammelbestellung einiger privater alle paar jahre nix.. ausserdem werden kommerzielle systeme (allen voram EIB) ja quasi täglich billiger sodass immer weniger luft bleibt..
Robert L. schrieb: >>RS485, das ja eindeutig NICHT >>Kollisionsfähig > > (IMHO) > > also RS485 ist schon zu kollisionen fähig ;-) > sie können auch erkannt werden .. > > nur muss man alles in software machen .. Das stimmt nur bedingt. Klar müßtest du die Kollisionserkennung per Software machen, aber studier mal die genaue Spezifikation der Bausteine, dann wirst ja sehen, daß sie im Falle einer Kollision nicht "eindeutig" reagieren, was die CAN-Transceiver sehr wohl machen. Aber zu diesem Thema gibt es schon zahlreiche Diskussionen und es ist echt schade um die Zeit, das hier wieder mal aufzuwärmen. Das wäre dann so ein typischer Punkt, wo eben eine Vorgabe gemacht werden müßte und wen sie nicht paßt, der muß ja nicht mitmachen. Das klingt jetzt hart, wenn man das nicht tut, führt das nur zu endlosen Diskussionen und niemals zu einer sinnvollen Zusammenarbeit.
Robert L. schrieb: > @Klaus M. > > ich bin hauptsächlich der meinung, dass das SELBER erstellen der > hardware das hauptproblem ist, weil DAS die "verbreitung" einfach > erheblich erschwehrt.. > .......... > .......... > sodass immer weniger luft bleibt.. Da hast du natürlich 100% recht, wenn du es nur von der kommerziellen Seite betrachtest, aber darum geht es doch nicht. Es geht doch hier primär um die Freude am Basteln und SELBST etwas zu schaffen oder einen Beitrag zu leisten und sich danach daran zu erfreuen etwas geschaffen zu haben! Wenn du mit den Vorgaben von EIB, LON, HomeMatic oder wie die ganzen kommerziellen System heißen zufrieden bist, dann spricht ja für dich nichts dagegen so ein System zu installieren.
>Das wäre dann so ein typischer Punkt, wo eben eine Vorgabe gemacht >werden müßte und wen sie nicht paßt, der muß ja nicht mitmachen. es werden ja nicht EINE Vorgabe gemacht, sondern 20 da ist dann nicht schwer einen Punkt zu finden, der einem nicht passt
> wenn du es nur von der kommerziellen > Seite betrachtest, nicht nur man sollte vielleicht mal zusammenfassen: a) kosten: es wäre nicht billiger b) zeit: es würde jahre dauern, und man hat aber nur monate zeit c) gemeinsamer nenner: keiner will nachgeben "ich will CAN sonst mach ich nicht mit"
@Robert L. Na wegen einem Punkt mußt ja nicht gleich aussteigen. Wenn das Grundkonzept OK ist, kann man ja gewisse Kompromisse eingehen. Sicher gibt es für jeden das eine oder andere NO GO, aber das wird sich nicht vermeiden lassen. Aber vielleicht ist ja doch gerade DAS der Punkt, woran GEMEINSAME Projekte scheitern, weil die die es wirklich ernst meinen eben wahre Individualisten sind und zu KEINEN Kompromissen bereit. Aber vielleicht ist es eben gerade dann die Kunst die Vorgaben so zu gestalten, daß für JEDEN etwas dabei ist ???
> a) kosten: es wäre nicht billiger Darum geht's bei einem Hobby auch nicht !!! > b) zeit: es würde jahre dauern, und man hat aber nur monate zeit Wieso nur Monate? In meinem Haus habe ich es vor 15 Jahren wie es gebaut wurde verabsäumt mich gleich darum zu kümmern, darf ich deshalb jetzt keine Automatisierung mehr installieren? Ist doch mein Hobby und soll auch Spaß machen, egal wie lange es dauert und was mir immer wieder neues einfällt. Schau ich habe vor ein paar Wochen begonnen und könnte jetzt sofort auf Basis AVR-NET-IO meinen ersten Zimmercontroller in Betrieb nehmen und mit meinem iPhone oder jedem anderen Browser steuern. Und aufbauend auf diese Erfolgserlebnisse mache ich eben weiter. > c) gemeinsamer nenner: keiner will nachgeben "ich will CAN sonst mach > ich nicht mit" gegen so etwas kannst nichts machen, das ist nun mal so. Ich würde z.B. niemals bei einem CAN-projekt mitmachen ;-)
Klaus M. schrieb: > Aber vielleicht ist ja doch gerade DAS der Punkt, woran GEMEINSAME > > Projekte scheitern, weil die die es wirklich ernst meinen eben wahre > > Individualisten sind und zu KEINEN Kompromissen bereit. Definition von Ingeniör.
>Wieso nur Monate? weil ich (bisher) davon ausging, dass eine nachrüstlöung für ein konvntionell verkabeltes haus praktisch unmöglich wäre (vorallem für ein bastelprojekt) > könnte jetzt sofort auf >Basis AVR-NET-IO meinen ersten Zimmercontroller in Betrieb nehmen u alleine die unterbringung des (doch sehr großen) teiles, ist doch nur mit gröberen unbaumaßnahmen möglich? dazu noch dezentrale relais (die platz haben müssen, und auch nicht jeder haben will, weil zu laut)
Robert L. schrieb: >>Wieso nur Monate? > > weil ich (bisher) davon ausging, dass eine nachrüstlöung für ein > konvntionell verkabeltes haus praktisch unmöglich wäre (vorallem für ein > bastelprojekt) ist doch auch für kommerzielle Systeme nur schwer möglich und bedingt gewisse Umbauarbeiten. Ich mache es so, daß ich Raum für Raum neu gestalte und diese Gelegenheit eben nutze und das geht ohnehin nicht von heute auf morgen, sondern dauert Jahre! > alleine die unterbringung des (doch sehr großen) teiles, ist doch nur > mit gröberen unbaumaßnahmen möglich? ist ja nur ein Testaufbau um die Software zu entwickeln und im Keller wo ich es jetzt einsetze ist mir die Größe egal. Für die endgültige Version würde ich schon gerne eine neue Platine designen (lassen)! > dazu noch dezentrale relais (die platz haben müssen, und auch nicht > jeder haben will, weil zu laut) naja kannst dir ja was Besseres wie Relais einfallen lassen oder gleich einen entsprechende Hardwarevorschläge machen ;-)
Klaus M. schrieb: > Robert L. schrieb: >>>RS485, das ja eindeutig NICHT > Das stimmt nur bedingt. Klar müßtest du die Kollisionserkennung per > Software machen, aber studier mal die genaue Spezifikation der > Bausteine, dann wirst ja sehen, daß sie im Falle einer Kollision nicht > "eindeutig" reagieren, was die CAN-Transceiver sehr wohl machen. Kollisionserkennung brauch man aber nicht zwnagsweise. Von daher verstehe ich das Problem nicht ganz.
>Besteht vielleicht überhaupt kein Interesse an einem GEMEINSAMEN System, >weil jeder nur SEINE individuellen Ideen durchsetzen möchte ??? Ich denke, das Hauptproblem sind die unendlich vielen Umgebungen. Der eine hat eine zwei Zimmer Mietwohnung und möchte nur spielen, der nächste hat ein Altbau und möchte keine Strippen ziehen und ein anderer hat einen Neubau und alle Freiheiten. Dann kann man noch beliebig über die Protokolle streiten, Funk oder Kabel, Focus eher auf Performance, Wartbarkeit oder Stromverbrauch, und und und. Das Ganze noch kombiniert mit allen möglichen bereits vorhandenen Bruchstücken, die jeder irgendwie einbinden möchte. Viel zu viele Variablen, um auf einen Nenner zu kommen. Übrigens: Die Industrie bekommt es ja auch nicht hin. Gruss Axel
Jörg S. schrieb: > Kollisionserkennung brauch man aber nicht zwnagsweise. Von daher > verstehe ich das Problem nicht ganz. Wenn du es zuläßt, daß Aktoren auch spontan ihren Zustand übertragen, brauchst du das sehr wohl, aber wie gesagt, ist nicht wichtig und keine weitere Diskussion wert.
Axel du bringst es mit deiner Aussage leider auf den Punkt, GENAU DAS scheint das Problem zu sein und deshalb müßte es zuerst einmal ein sehr allgemeines Protokoll geben, daß die Übertragung auf beliebigen Medien zuläßt und den Ausbau von der kleinsten "Spielerei" bis zur komplexeren Haussteuerung ermöglicht. So betrachtet bietet ja die HomeMatic von ELV keinen schlechten Ansatz. Du bist mit einem Modul dabei, kannst zwischen Funk und wired wählen, es gibt Direktverknüpfungen zwischen den Modulen aber auch eine komplexere Steuerung über eine Zentrale. > Dann kann man noch beliebig über die Protokolle streiten, Funk oder > Kabel, Focus eher auf Performance, Wartbarkeit oder Stromverbrauch, und > und und. Es macht keinen Sinn über das Protokoll zu streiten, da müßten sich 2-3 Leute hinsetzen und das spezifizieren ... PUNKT! > Das Ganze noch kombiniert mit allen möglichen bereits > vorhandenen Bruchstücken, die jeder irgendwie einbinden möchte. Wenn das Protokoll paßt, kann ja jeder SEINE Bruchstücke einbinden und mit guten Beispielen sollte das kein Problem sein. Ich denke da nur an die vielen LED-Dimmer die bereits im Netz kursieren. Da wäre echt was brauchbares dabei nur hat ohne Standardprotokoll Niemand was davon.
Das mit dem Freebus Projekt, auch die Module ohne CPU-Modul sind interessant, da sie ja auch für andere Bussysteme verwendbar sind und auf bestimmte Gehäuse bereits abgestimmt sind. Klar, das sind kleine Standardmodule, aber wieso das Rad jedesmal neu erfinden ?
chris schrieb: > Das mit dem Freebus Projekt, auch die Module ohne CPU-Modul sind > interessant, > da sie ja auch für andere Bussysteme verwendbar sind und auf bestimmte > Gehäuse bereits abgestimmt sind. Klar, das sind kleine Standardmodule, > aber wieso das Rad jedesmal neu erfinden ? Keiner will das Rad neu erfinden, also kannst bitte etwas konkreter werden welche Module du genau meinst? Ich habe da keine rechte Vorstellung, was ich mit einem Modul ohne CPU anfangen soll, wie soll ich mit dem kommunizieren?
Wenn du dir das Projekt (HW) ansiehst, dann wirst du feststellen daß alles Modular aufgebaut wurde un eine Standardinterface zwischen Controller und Actor/Sensor definiert wurde. Sprich du kannst die Module/Applikationsboards nehmen und mit Can/RS485/RF Controllern dann verwenden. Gehäuseintegration wurde schon betrieben, also ziemlich simple.
Klaus M. schrieb: > Du magst mit Deiner Aussage schon bis zu einem gewissen Punkt recht > haben, aber es kann doch nicht sein, daß einer alles entwickelt, die > Pläne dann postet und alle anderen bauen es nach ... was hätte er denn > davon. Nur GEBEN aber nicht BEKOMMEN? Wenn ich die Zeit und das Wissen > hätte das alles alleine zu machen, würde ich ein System designen, bauen, > programmieren und dann verkaufen, aber doch nicht verschenken? Öhm, schon mal was von Open-Source Software gehört? Tausende Software-Entwickler machen genau das, sie "verschenken" ihr selbst entwickeltes Zeug. Einfach so.
adsada schrieb: > Öhm, schon mal was von Open-Source Software gehört? Tausende > Software-Entwickler machen genau das, sie "verschenken" ihr selbst > entwickeltes Zeug. Einfach so. Achso ich verstehe. Wenn ich also meine eine gute Idee habe, soll ich diese gefälligst auch umsetzen, perfekt aufbereiten, pipifein beschreiben und natürlich auch sofort alle Fehler umgehendst korrigieren, die die Anwender dann finden. So in etwa würdest du dir das vorstellen ??? Na ich denke dann bin ich sicher nicht der Richtige und eher fehl am Platz hier, weil ich würde gerne mit anderen GEMEINSAM was entwickeln und zum Laufen bringen und besonders schön wäre es natürlich, wenn man sich auch mal real treffen und persönlich kennenlernen könnte. Aber ich habe da wohl etwas "abgehobene" Vorstellungen :-(
Ja, es ist einfach die fehlende Kommunikation. Wobei es schon viel bringen würde, wenn man beispielsweise einen billigen, leicht verfügbaren WLAN Router so modifiziert, dass man eine Relaisplatine dran hängt und den in ein kleines Gehäuse bekommt. Ethernet/WLAN ist so denke ich ein brauchbarer Kompromiss, und es sollte nicht so schwierig sein auf einem WLAN-Router Software zu entwickeln.
Christian Berger schrieb: > Ja, es ist einfach die fehlende Kommunikation. Wobei es schon viel > bringen würde, wenn man beispielsweise einen billigen, leicht > verfügbaren WLAN Router so modifiziert, dass man eine Relaisplatine dran > hängt und den in ein kleines Gehäuse bekommt. Ethernet/WLAN ist so denke > ich ein brauchbarer Kompromiss, und es sollte nicht so schwierig sein > auf einem WLAN-Router Software zu entwickeln. Sag schießt du da nicht mit Kanonen auf Spatzen. Ich meine WLAN in Ehren, aber willst jedes Modul mit WLAN ausstatten? Das geht doch viel einfacher und billiger mit einem simplen RFM12 Funkmodul oder dergleichen und sicher auch stromsparender. Und prinzipiell ist es heute auch einfacher z.B. ein AVR-NET-IO-Modul zu modifizieren, wo alles super dokumentiert ist, als bei einem günstigen WLAN-Router rauszufinden wie der verdrahted ist ??? Also schön langsam verstehe ich, warum das mit GEMEINSACHFTSPROJEKTEN nicht so recht funktioniert :-)
Klaus M. schrieb: > Also schön langsam verstehe ich, warum das mit GEMEINSACHFTSPROJEKTEN > nicht so recht funktioniert :-) Richtig. Das nennt man auch das "Fahrradschuppenproblem". Stell Dir vor, eine Gruppe nicht-Techniker kommt zusammen um zu beschließen, dass man eine große technische Anlage baut. (z.Bsp. ein Kraftwerk) Die Leute haben nur sehr wenig Ahnung von der Anlage an sich, und vertrauen somit auf den Rat der Techniker. Alles läuft problemlos. Bis dann nach der Farbe des Fahrradschuppens gefragt wird. Da will sich dann jeder einbringen, weil sich jeder kompetent fühlt, und deshalb gibt es dabei Streit. Übrigens das mit dem "Kanonen auf Spatzen schießen" finde ich hier ein schwaches Argument. Wenn Du einfache Sendemodule verwendest, so hast Du das Problem, dass Du das nicht vernünftig an einen Rechner anschließen kannst. Wenn du hingegen ganz einfach IPv6 Webserver laufen hast, so kann sofort jeder das trivial einfach integrieren. Weil Webserver kann man einfach mit einem Browser testen, und per wget (o.Ä.) steuern. Es ist keine große Zusammenarbeit notwendig. Ich denke es ist da sinnvoll auf die Fälle zu schauen, bei denen es geklappt hat. Zum Beispiel beim Internet. Da war die Idee, Protokolle zu entwickeln, die sich möglichst von selbst erklären. Das ging so weit, dass früher die meisten Implementierungen von SMTP oder FTP einen "help" Befehl hatten, der Dir die Grundzüge des Protokolls erklärt hat. Ebenso war die Offenheit der Systeme ein wichtiger Punkt. Für jedes Protokoll kannst Du relativ einfach Gegenstellen finden, die dieses Protokoll sprechen. (Deshalb auch IPv6, da kann man trivial einfach eine Kiste freigeben)
Christian Berger schrieb: > Klaus M. schrieb: >> Also schön langsam verstehe ich, warum das mit GEMEINSACHFTSPROJEKTEN >> nicht so recht funktioniert :-) > > Richtig. Das nennt man auch das "Fahrradschuppenproblem". > > Stell Dir vor, eine Gruppe nicht-Techniker kommt zusammen um zu > beschließen, dass man eine große technische Anlage baut. (z.Bsp. ein > Kraftwerk) Die Leute haben nur sehr wenig Ahnung von der Anlage an sich, > und vertrauen somit auf den Rat der Techniker. Alles läuft problemlos. > Bis dann nach der Farbe des Fahrradschuppens gefragt wird. Da will sich > dann jeder einbringen, weil sich jeder kompetent fühlt, und deshalb gibt > es dabei Streit. dem habe ich nichts mehr hinzuzufügen, das trifft den Nagel auf den Kopf. Ich denke jetzt zu wissen, warum es nicht funktioniert. Sollte doch jemand ernsthaftes Interesse haben, so kann er sich ja gerne bei mir melden.
Klaus M. schrieb: > Hier in diesem wunderbaren Forum, gibt's eine eigene Rubrik Hausbus mit > hunderten von Beiträgen. Manche eher unsinnig, manche aber auf wirklich > verdammt hohen Niveau, wo man nur so staunen kann. > > Es ist auch wirklich toll zu sehen, was so alles entsteht und wie viel > Herzblut in Projekte gesteckt wird. Auch die Übersichten über die > verwirklichten Projekte finde ich sehr aufschlußreich, aber ... > > ... was mich wirklich wundert ist die Tatsache, daß es immer wieder > Aufrufe gibt ein GEMEINSAMES System zu entwicklen, nur scheinbar alle > zum Scheitern verurteilt sind ... warum ist das so ??? > > Woran scheitert das im Allgemeinen ??? > > Besteht vielleicht überhaupt kein Interesse an einem GEMEINSAMEN System, > weil jeder nur SEINE individuellen Ideen durchsetzen möchte ??? > > Mich würde eure ehrliche Meinung zu diesem Thema interessieren und > welche Erfahrungen ihr vielleicht mit GEMEINSAMEN Forumprojekten schon > gemacht habt. > > liebe Grüße aus Wien > > Klaus Und ich frage mich wieso wollen immer alle das Rad neu erfinden? Wahrscheinlich macht es den meisten einfach Spass, denn anders kann ich mir nicht erklären warum man sich nicht auf ein exisitierendes Projekt wie HAP oder HCAN einigt. HAP ist z.B. schon sehr weit mit vielen Features. Was noch fehlt sind IMHO komerziell hergestellte Knoten.
> Und ich frage mich wieso wollen immer alle das Rad neu erfinden? > Wahrscheinlich macht es den meisten einfach Spass, denn anders kann ich > mir nicht erklären warum man sich nicht auf ein exisitierendes Projekt > wie HAP oder HCAN einigt. Ich kann es dir nur aus meiner ganz persönlichen Sicht erklären ... ich mag CAN einfach nicht, das ist für mich in der Hausautomation einfach ein NO GO und sollte in dem Bereich bleiben, für den es ursprünglich entwickelt wurde. Und was du übersiehst ist ja die Tatsache, das solche Projekte und deren Entwicklung Spaß machen und darum geht es ja. Wenn ich ein fertiges System will, dann nehme ich eher die HomeMatic weil da gibt's schon verdammt viele Module und auch viele Anwender mit noch mehr Know How als HAP, HCAN oder wie sie alle heißen, zusammen! Aber wie gesagt, mir geht es ja um den Spaß an der Sache und ich würde auch gerne leute kennenlernen die eben auch diesem Hobby fröhnen ;-)
Klaus M. schrieb: > ... ich > mag CAN einfach nicht, das ist für mich in der Hausautomation einfach > ein NO GO ,,, Verständlich. Für mich kommt da noch der Punkt dazu, dass ich keine CAN-Bus Verkabelung habe. > Aber wie gesagt, mir geht es ja um den Spaß an der Sache und ich würde > auch gerne leute kennenlernen die eben auch diesem Hobby fröhnen ;-) Amen!
Klaus M. schrieb: >> Und ich frage mich wieso wollen immer alle das Rad neu erfinden? >> Wahrscheinlich macht es den meisten einfach Spass, denn anders kann ich >> mir nicht erklären warum man sich nicht auf ein exisitierendes Projekt >> wie HAP oder HCAN einigt. > > Ich kann es dir nur aus meiner ganz persönlichen Sicht erklären ... ich > mag CAN einfach nicht, das ist für mich in der Hausautomation einfach > ein NO GO und sollte in dem Bereich bleiben, für den es ursprünglich > entwickelt wurde. > > Und was du übersiehst ist ja die Tatsache, das solche Projekte und deren > Entwicklung Spaß machen und darum geht es ja. Wenn ich ein fertiges > System will, dann nehme ich eher die HomeMatic weil da gibt's schon > verdammt viele Module und auch viele Anwender mit noch mehr Know How als > HAP, HCAN oder wie sie alle heißen, zusammen! > > Aber wie gesagt, mir geht es ja um den Spaß an der Sache und ich würde > auch gerne leute kennenlernen die eben auch diesem Hobby fröhnen ;-) Das sage ich ja: Es macht Spass etwas zu entwickeln, das versteh ich. Sonst würde ich nicht den 1000. RGB Dimmer selber entwickeln :) Warum ist CAN ein No-Go? Das kann mir niemand erklären. Enwickeln macht Spass, aber bei einigen Sachen macht es doch keinen Sinn. Wieso ein neues Protokoll auf RS485 entwickeln mit imensem Aufwand wenn CAN schon alles bietet? Ich glaube die Ansprüche sind einfach zu verschieden. Viel Spass noch mit euren Projekten: Ich entwickel mal weiter an meinem Radio-Licht-Weckersystem :)
Matthias Keller schrieb: > Das sage ich ja: Es macht Spass etwas zu entwickeln, das versteh ich. > Sonst würde ich nicht den 1000. RGB Dimmer selber entwickeln :) Ich habe eben (wie so viele Andere auch) meine Ideen und die werde ich umsetzen, aber Du hast etwas, was mich sehr interessieren würde, weil ein RGB-Dimmer steht ganz oben auf meiner Wunschliste. Da ich aber selbst kein Hardwareentwickler sondern ein Software-Fuzzi wollte ich dich fragen, ob ich bei deinen RGB-Dimmer ein wenig abgucken darf. Gibt's da vielleicht einen Link, wo du deine Projekte vorstellst. Wäre echt super
Klaus M. schrieb: > Und was du übersiehst ist ja die Tatsache, das solche Projekte und deren > Entwicklung Spaß machen und darum geht es ja. Wenn ich ein fertiges > System will, dann nehme ich eher die HomeMatic weil da gibt's schon > verdammt viele Module und auch viele Anwender mit noch mehr Know How als > HAP, HCAN oder wie sie alle heißen, zusammen! > > Aber wie gesagt, mir geht es ja um den Spaß an der Sache und ich würde > auch gerne leute kennenlernen die eben auch diesem Hobby fröhnen ;-) und weiter unten: > Da ich aber selbst kein Hardwareentwickler sondern ein Software-Fuzzi > wollte ich dich fragen, ob ich bei deinen RGB-Dimmer ein wenig abgucken > darf. Gibt's da vielleicht einen Link, wo du deine Projekte vorstellst. > Wäre echt super Beide Posts zusammen heisst das wohl das Du jemanden suchst, der für Dich die Hardware baut, das ist nämlich der schwierige Teil der Veranstaltung. Bei Deinen Fähigkeiten ist FS20 oder Homematic geradezu ideal, es gibt eine Menge Module und die meisten Programmierschnittstellen sind offengelegt. Außerdem schon einige SW Projekte wie z.B. FHEM (auch für eine Fritzbox als Server), bei denen Du Dich ja einklinken könntest. Ein weiterer Grund zu $topic ist noch, das sich wohl kaum jemand der die Hardware bauen kann sich abhängig macht von jemand anderem der verspricht die Software zu entwickeln. IF
Ignatz-Finn schrieb: > Beide Posts zusammen heisst das wohl das Du jemanden suchst, der für > Dich die Hardware baut, das ist nämlich der schwierige Teil der > Veranstaltung. Naja wenn du meinst ... aber ich würde sagen, du solltest dich mal überraschen lassen ;-) Was ich wissen wollte, weiß ich jetzt wenigstens und mir ist nun etwas klarer geworden, warum es keine ernsthaften GEMEINSACHFTSPROJEKTE geben kann. In disem Sinne beende ich diesen Thread nun wieder. Vielen Dank für die ehrlichen Aussagen bis bald einmal
>Warum ist CAN ein No-Go? Das kann mir niemand erklären. Enwickeln macht >Spass, aber bei einigen Sachen macht es doch keinen Sinn. Wieso ein >neues Protokoll auf RS485 entwickeln mit imensem Aufwand wenn CAN schon >alles bietet? Weil CAN eine komplett neue parallele Verdrahtung neben den schon existierenden Bussen im Haus erfordert. Ich habe keine Lust, zusätzlich zum vorhandenen Ethernet/WLAN und Stromleitungen jetzt die Wände aufzukoppen und noch mal CAN Leitungen quer durchs Haus zu legen. Deswegen läuft bei mir der "Backbone" über Ethernet. Da habe ich schon alle möglichen Diagnosetools, kann auf Basis diverser offener Projekte Software und Hardware entwickeln, habe eine einfache Beutzeroberfläche, habe unendlich viele fertige Lösungen für die Einbindung anderer Protokolle, die Kabel liegen in (fast) allen Zimmern und wo nicht, kann man das auch gegenüber der Restfamilie gut begründen und und. Und wenn ein Zimmer renoviert wird, werden ausgehend von einem oder zwei Ethernet Knoten die Leitungen zu den Sensoren/Aktoren gezogen. Finde ich persönlich am praktischsten und zukunftssichersten. Bin ich aber hier wohl der einzige :-( Gruss Axel
Can ist für mich ein No-Go weil es empfindlicher als RS485 ist (elektrisch), mehr Strom braucht. Für dich ist 10W an zusätzlichen Stromverbrauch vielleicht irrelevant, für mich nicht. Für Alex ist es noch irrelevanter, da er Ethernet verwendet warscheinlich mit PoE und bei 100 Sensoren (12 Jalosien, 40 Schalter, 20 Aktoren, 10 Dimmer, Heizung ) sind die verheitzte Leistung immens, dafür aber warscheinlich IPv6.
Tja weisst Du Chris, da hast Du einen weiteren Grund, warum Gemeinschaftsprojekte schwierig sind. Leute, die nicht richtig lesen können. Gruss Axel
chris schrieb: > Can ist für mich ein No-Go weil es empfindlicher als RS485 ist > (elektrisch), > mehr Strom braucht. Für dich ist 10W an zusätzlichen Stromverbrauch > vielleicht irrelevant, für mich nicht. > Für Alex ist es noch irrelevanter, da er Ethernet verwendet > warscheinlich > mit PoE und bei 100 Sensoren (12 Jalosien, 40 Schalter, 20 Aktoren, 10 > Dimmer, Heizung ) sind die verheitzte Leistung immens, dafür aber > warscheinlich IPv6. Empfindlicher? Kannst du mir da Infos darüber geben? Ich kenn Anwendungen wo der CANBus direkt neben @Alex Also willst du eben Ethernet statt CAN. Hast du denn soviele Ethernetkabel verlegt oder nimmst du dann in jedem Raum ein Switch? Warum nicht. Beruflich entwickele ich an einem prop. Ethernet-basiertem Automationssystem und kenn die Vorteile. Wie du sagts ist eben schon alles da: Diagnose über Wireshark, Webserver und Fernsteuerung inklusve. Das einzige was mich daran stören würde sind die HW-Kosten und vor allem der Stromverbrauch. Der dürfte bei dann bei jedem Knoten auf jeden Fall im Wattbereich sein. Würde mich freuen wenn du dein Projekt weiterverfolgst und vielleicht irgendwo zumindest den Status mitteilen würdest. :)
Klaus M. schrieb: > Matthias Keller schrieb: > >> Das sage ich ja: Es macht Spass etwas zu entwickeln, das versteh ich. >> Sonst würde ich nicht den 1000. RGB Dimmer selber entwickeln :) > > Ich habe eben (wie so viele Andere auch) meine Ideen und die werde ich > umsetzen, aber Du hast etwas, was mich sehr interessieren würde, weil > ein RGB-Dimmer steht ganz oben auf meiner Wunschliste. > > Da ich aber selbst kein Hardwareentwickler sondern ein Software-Fuzzi > wollte ich dich fragen, ob ich bei deinen RGB-Dimmer ein wenig abgucken > darf. Gibt's da vielleicht einen Link, wo du deine Projekte vorstellst. > Wäre echt super Nein gibt bis jetzt nichts dergleichen. Sollte es mal in ferner Zukunft Richtung Fertigstellung gehen werde ich es dokumentieren. Ich hab auch SEHR viel abgeschaut. Hab die links nicht parat. Such aber mal hier nach: - HSV to RGB - Wakeuplight - SoftPWM - Ks0108 HW-mäßig ist es bis jetzt - Mega32 - ks0108 Display - RGB LED - Steckbrett - ganz viel 0,5mm Draht - 10x 100nF :) Ist aber Offtopic
>Das einzige was mich daran stören würde sind die HW-Kosten und vor allem >der Stromverbrauch. Der dürfte bei dann bei jedem Knoten auf jeden Fall >im Wattbereich sein. HW Kosten sehe ich nicht so eng. Ein AVR-NETIO kostet unter 20€, eine selbstgebaute Platine kommt da noch drunter. Da sind Kabel fast schon teurer und ich habe dank dreier Kinder sowieso Ethernet und Switches im ganzen Haus verteilt. Da kommt es nicht mehr drauf an. Und wenn dann aus irgendeinem Grund was in der Gartenhütte geschaltet werden soll (in der Strom liegt, aber keiner an Reserve gedacht hat) ist man mit ein paar Powerlineadaptern dabei. Sind zwar auch nicht billig, aber im Vergleich zum Aufbuddeln und Verlegen von 10 Metern Rasen eindeutig die kostengünstigere Lösung. Wobei man dann diesen Teil des Gartens auch zum Surfen nutzen kann. Und Leistungsaufnahme liegt so bei 300mW pro Knoten. Sicher geht das besser, aber es ist auch nicht katastrophal. Aber ich will hier auch gar nicht von meiner Lösung überzeugen. Ich wollte lediglich darlegen, dass es sehr unterschiedliche Bewertungen der Rahmenbedingungen gibt. Übrigens habe ich früher auch andere Lösungen genutzt (1-wire, UART basierende etc.) hatte da aber irgendwann keine Lust mehr zu. Als die Ansprüche stiegen, vor allem im Bereich Visualisierung (Stichwort WAF), habe ich den Schwenk auf Ethernet gemacht. Jetzt kann man z. B. von jedem PC/Touchpad im Haus problemlos das heisse Wasser für ein ausgiebiges Schwitzbad anfordern oder die Raumtemperaturen ändern. Gruss Axel
Axel Laufenberg schrieb: > HW Kosten sehe ich nicht so eng. Ein AVR-NETIO kostet unter 20€, eine > selbstgebaute Platine kommt da noch drunter. Also seit es AVR-NET-IO um 20.- gibt, bin ich ebenfalls von einer LAN-Lösung sehr angetan, weil ich das ja auch bereit's im ganzen Haus verlegt habe! Ist also mehr als naheliegend, das auch für die Haussteuerung zu verwenden. Trotzdem gibt's ein paar Anwendungen, wo eine kleine Funklösung mit z.B. RFM12 nicht ganz unpraktisch wäre und deshalb kombiniere ich das eben. Als Anzeige und Bedieneinheit verwende ich mein ohnehin vorhandenes iPhone bzw. meinen iPod und das klappt bereits prima. Trotzdem würde mich interessieren, über welches Protokoll deine Kontroller miteinander "reden". Sicher gibt's für LAN genügend Werkzeuge, aber irgend eine Art der Adressierung mußt ja auch gewählt haben?
RS485 Tranceiver haben generell höhere ESD (machine model) werte, auch das 30x ist nicht ungewöhnlich, sowie höhere max voltage für Transienten usw. Eine Isolierung (Stockwerke) ist auch einfacher und die Terminierung ist unkritischer. Von der Datenrate, Can kann mit 250Kbit fahren und RS485 nur mit 128Kbit (ca 250mt). Wenn man aber mit Nutzdaten rechnet, relativiert sich der Unterschied beträchtlich, muss aber jeder selbst eintscheiden. Ethernet Verkabelung. Zwei Adernpaare sind zur freien Benutzung. Z.B. Rs485 sowie analoges Telefon als Beispiel. Die Speisung kann ev. auch noch in den RX/TX des Ethernets eingebettet werden oder man könnte anstelle RS485 auch 25mA TTY verwenden für Schalter usw. Nur daß da "Ethernetkabel" verwendet werden heisst nicht daß man da dann Ethernet verwenden muss.
chris schrieb: > Nur daß da "Ethernetkabel" verwendet werden heisst nicht daß man da dann > Ethernet verwenden muss. Da hast natürlich recht! Ich verwende von den 8 Leitungen im Kabel ja auch nur 2 Paare für LAN (100 MBit) und die anderen beiden sind frei nutzbar. Und vom Prinzip ist es doch völlig egal ob man RS485- oder CAN-Transceiver für ein lokales kleines Netzwerk verwendet, das ist doch wie streiten um des Kaisers Bart. Schade finde ich persönlich ja nur, dass es scheinbar keine "gemeinsame" Sprache zwischen den so zahlreichen Modulen gibt. Jeder bastelt vor sich hin, kocht sein eigenes Süppchen und so kann Keiner die Module des Anderen auf einfache Art & Weise nutzen :-( Mir wurde hier vorgeworfen, daß ich nur jemanden suche der mir die Hardware baut, aber das ist doch Unsinn. Wenn ich nur gucke was da so alles an Testaufbaueten auf meinem Schreibtisch liegt, ich einen BootLoader entwickelt habe, der via USART (und egal ob RS485/CAN Transceiver) sowohl für AVR als auch PIC-Controller funktioniert und neuerdings auch auf einem AVR-NET-IO via LAN-UDP/IP und ich auch RFM12 Module habe, die munter miteinander plaudern, dann hätte ich ja Einiges zu bieten. Mein Problem ist nur, daß der Tag nun mal nur 24 Stunden hat, ich noch mitten im Berufsleben stehe und einfach nicht ALLES selbermachen kann! Ich kann sehr wohl auch Hardware entwickeln (ist ja nicht besonders schwer, braucht man ja nur abkupfern), aber als Softwaremann dauert das bei mir nun mal VIIIIIIIIIIIIIEl länger wie bei jemanden der das wirklich aus dem FF beherrscht und ich mache natürlich saublöde Fehler die erst wieder Zeit kosten. Aber egal, ich habe es eingesehen, daß kein Interesse an etwas GEMEINSAMEN besteht ... traurig aber leider wahr.
Klaus M. schrieb: > Aber egal, ich habe es eingesehen, daß kein Interesse an etwas > GEMEINSAMEN besteht ... traurig aber leider wahr. Das problem wird einfach auch sein, dass viele die sich eine eigene Hausautomation bauen dies tun, weil sie nichts gefunden haben, was ihren ansprüchen genügt (wie auch immer diese Ansprüche aussehen mögen ist ja zweitrangig). So jemand ist natürlich auch wenig kompromissbereit, da ihn ja gerade der Mangel an Kompromissbereitschaft von den verfügbaren Systemen (egal ob kommerzielle oder freie System) zum Selbstbau bewogen hat. Er sagt sich also: wenn ich das schon selbst baue, dann so wie ich das möchte und nicht wie jemand anderes es gerne hätte.
Gästle schrieb: > Klaus M. schrieb: >> Aber egal, ich habe es eingesehen, daß kein Interesse an etwas >> GEMEINSAMEN besteht ... traurig aber leider wahr. > > Das problem wird einfach auch sein, dass viele die sich eine eigene > Hausautomation bauen dies tun, weil sie nichts gefunden haben, was ihren > ansprüchen genügt (wie auch immer diese Ansprüche aussehen mögen ist ja > zweitrangig). > So jemand ist natürlich auch wenig kompromissbereit, da ihn ja gerade > der Mangel an Kompromissbereitschaft von den verfügbaren Systemen (egal > ob kommerzielle oder freie System) zum Selbstbau bewogen hat. Er sagt > sich also: wenn ich das schon selbst baue, dann so wie ich das möchte > und nicht wie jemand anderes es gerne hätte. Ja so ist es wohl, also werde auch ich mein ganz persönliches System designen und bauen und wer weiß, vielleicht werde ich es auch veröffentlichen ... mal sehen ;-)
Klaus M. schrieb: > Trotzdem würde mich interessieren, über welches Protokoll deine > Kontroller miteinander "reden". Sicher gibt's für LAN genügend > Werkzeuge, aber irgend eine Art der Adressierung mußt ja auch gewählt > haben? Ich verwende XPL (http://xplproject.org.uk/wiki/index.php?title=Project_documentation) für die Telegramme. Ist zwar etwas Aufwand in den Controllern, weil das ASCII basierend ist, dafür geht die Fehlersuche deutlich schneller, weil die Daten in einem lesbaren Format übertragen werden und z. B. Wireshark die direkt anzeigt. Ursprünglich hatte ich ein Hausnetz für die Heizungssteuerung basierend auf 1-Wire aufgebaut, über das endlos viele Daten übertragen wurden. Es war mir irgendwann zu blöd, dauernd die Adressen der Daten und die Werte in ein vernünftiges Format umzurechnen, wenn mal was nicht klappte. Und bei Ethernet spielt die Datenmenge dann auch keine relevante Rolle mehr. Gruss Axel
Dann spezifizier mal deine Anforderungen, eventuell kann dir mit fertigen Modulen geholfen werden. Anforderungen wie Was und in welcher Menge zu steuern ist, Kabel, Anzahl der Stockwerke, sonstige Wünsche, wie z.B. zentrale Musikanlage/FM-Sender, Sprechanlage, .... .
Axel Laufenberg schrieb: > Ich verwende XPL > (http://xplproject.org.uk/wiki/index.php?title=Project_documentation) > für die Telegramme. OK verstehe, ist im Prinzip wie das Protokoll zur HomeMatic wo mit XML-RPC gearbeitet wird. Ist keine blöde Sache, über Ehternet durchaus vertretbar und durch die gute Lesbarkeit sogar von Vorteil, aber z.B. für einen Funkverkehr via RFM12 doch eher ungeeignet. Wär doch blöd, wenn jeder deine Telegramme in Klartext mitlesen kann ;-)
chris schrieb: > Dann spezifizier mal deine Anforderungen, eventuell kann dir mit > fertigen > Modulen geholfen werden. Anforderungen wie Was und in welcher Menge > zu steuern ist, Kabel, Anzahl der Stockwerke, sonstige Wünsche, wie > z.B. zentrale Musikanlage/FM-Sender, Sprechanlage, .... . Von der Verkabelung gibt's keine Probleme, habe mein Haus mit LAN komplett vom Keller bis Dach nachgerüstet und das sogar doppelt wenn ich doch auch auf die Idee komme, einen zentralen Audio/Video-Server betreiben zu wollen. Die Kabel liegen im Moment nur teilweise sichtbar herum, was sich aber in Kürze ändern wird, sobald ich Raum für Raum renoviere. Ich denke an eine dezentrale Anlage, mit einigen Modulen wie das AVR-NET-IO, für das ich die ganze Basis ja schon implementiert habe. Ich habe kein Problem Temperaturen zu messen, Releais zu schalten, Licht zu dimmen, nur gehört das eben in brauchbare Module verpackt. So würde ich mir die Hardware des AVR-NET-IO auf eine andere Platine wünschen, wo eben auch gleich Relais, ein Dimmer etc. also das was man in etwa für 1 Raum braucht, drauf ist. Aber wenn du dir die vorhandenen Module anguckst, sind diese ja bewußt so ausgelegt, daß du mit einem Modul pro Raum nicht durchkommst. Strategisch betrachtet macht das Sinn, weil es sollen ja möglichst viele Module verkauft werden, aber mir gefällt das nicht. Und ein großes Anliegen wären mir Dimmer für LED's und auch RGB-Dimmer und die könnten via RFM12 oder eben USART angesteuert werden um möglichst flexibel zu sein. Mir schwebt also im Prinzip pro Raum ein Kontroller vor der autonom arbeitet und konfiguriert werden kann. Ich will KEINESFALLS ein zentrales System mit einem rund um die Uhr laufenden PC! Der PC soll nur dazu dienen, die Raumcontroller zu konfigurieren oder mit neuer Firmwar via LAN abzudaten. Und ein paar Stellen habe ich eben, wo ich wirklich verdammt schlecht mit einem Kabel hinkomme, da wären ein paar Module die via Funk erreichbar sind schon super. Aber bitte "stromsparen in Ehren" ich will keine Funkmodule die um Batterie zu sparen ständig "schlafen" und nicht erreichbar sind und sich nur alle heiligen Zeiten mal melden. Ich habe einige Module der HomeMatic und auch eine Zentrale im Testbetrieb laufen, aber manche Dinge machen mich einfach krank. Am meisten ärgert mich aber, daß man für jeden Schmarrn ein eigens Modul braucht, was letzt endlich ganz schön ins Geld gehen würde. Aber so abgefahren sind meine Wünsche doch nicht und die haben doch auch Andere, oder ???
Also ich bau ein Hausbus auf I²C-Bus Basis. Als Backbone wird aber auch Ethernet verwendet (mit ARM Cortex als Umsetzer auf I²C). Hat den Vorteil das die Aktoren dann einfach nur Standard I2C Bus Bausteine sind, also spart man sich da schon mal komplett die Software und das Protokoll. Den Ethernet Teil wollte ich vom Protokoll wenn möglich auf KNXnet Basis aufbauen. Falls einer interesse hat mitzumachen, kann er sich bei mir melden :)
Angehängte Dateien:
-
IMG_5788.jpg
67 KB -
IMG_5794.jpg
63 KB -
IMG_5835.jpg
59 KB
Klaus M. schrieb: > Ich habe eben (wie so viele Andere auch) meine Ideen und die werde ich > umsetzen, aber Du hast etwas, was mich sehr interessieren würde, weil > ein RGB-Dimmer steht ganz oben auf meiner Wunschliste. Ich bestätige zwar damit wohl die Ursprüngliche Aussage des Threads, aber ich hab mir auch mal mein eigenes RGB Modul für solche Kugel-Boden-Leuchten gebaut. Natürlich nicht CAN, nicht Ethernet und nicht RS485 sondern auf Basis eines RFM12s ;-) Aber wenn daran Interesse besteht, kann ich die Dateien gerne hier mal hochladen.
Klaus M. schrieb: > Ich denke an eine dezentrale Anlage, mit einigen Modulen wie das > AVR-NET-IO, für das ich die ganze Basis ja schon implementiert habe. Ich > habe kein Problem Temperaturen zu messen, Releais zu schalten, Licht zu > dimmen, nur gehört das eben in brauchbare Module verpackt. > ... weitere detaillierte Anforderungen... Also praktisch alles was Du hier beschreibst bietet doch das ELV System (FS20 und/oder Homematic) wobei alles was von Hand bedient wird (also bei persönlicher Anwesenheit) per FS20 deutlich günstiger ist. Hutschienenmodule mit Ethernet ähnlich AVR-Net IO hat Ulrich Radig auf seiner Seite, inkl. Layout zum selbst erweitern. Wo ist das Problem statt ein Modul für alles die einzelnen (Hutschinen? Module nebeneinanderzusetzen?) Einen großen Preisvorteil bekommst Du beim Selbstbau nicht (jedenfalls nicht gegen FS20 Module) bei den Markenherstellern kann das anders aussehen. Auch wenn der Preis gegenüber Deinen früheren Posts anscheinend doch eine Rolle spielt. Bei mir läuft ein AVR-Net IO mit Ethersex Software und FS20 Sender, in den Schalterdosen habe ich den ELV Funk Wechselschalter, so bleiben die Lampen auch per Handschaltung ganz normal bedienbar (WAF) Dimmer sind die Funk Zwischendeckendimmer. OK, für Deckenlicht und Jalousien habe ich ein eigenes Relaismodul gebaut (Hutschiene), aber nicht weil es das nicht einzeln gab, sondern weil es Spaß macht ;-) Bedienung per IR/FS20 Umsetzer und Universalfernbedienung (Philips SRT8215) sowie per iPad mit Casaremote SW (www.casalive.de) über das Net-IO. Außerdem im Raum noch Funkschalter (Interessantes neues Modell mit Display im aktuellen ELV Journal) Option für das ganze noch per Ethersex Software auf Wetterdatenempfang / Heizungssteuerung usw. zu erweitern, alternativ per EZ-Control XS1, da ist vieles schon integriert. Außerdem FHM in der Fritzbox als weitere Option. Also jede Menge Möglichkeiten zum "spielen". Nur zur Sicherheit, ich bin nicht bei ELV angestellt ;-) Mir ist klar das das FS20 System nicht gerade perfekt ist (Rückkanal, einige nicht ganz zu Ende gedachte Module) aber es ist Nachzurüsten ohne die Wände komplett aufzureißen und preislich noch im Rahmen. Nach einem Jahr Betrieb war Abends noch nie das Licht an oder die Markise ausgefahren, auch nicht bei dem Selbstbaumodul. Eindeutiger Vorteil: ist als one Man Show zu machen, und wenn man Basteln will kann man sich auf das Wenige konzentrieren was es doch noch nicht gibt. Und das dann zu Bauen braucht schon genug Zeit.
AVR-IO gefällt mir weniger, weil eben AVR, ein Router (Mips) mit SD-Card, I2C Treiber und RS232 kann eben viel mehr bei gleichem Aufwand. Ein Router mit USB welcher geeignet ist kostet 26€, hat mehrere Ethernetanschlüsse, ... . Probier mal z.B. Wetterprognosen, Steuerung sowei Kontrolle über Web (Flash) sowie logging der Zugriffe (php), Email konten mit RGB Moodlight als Beispiel zur Anzeige, grafische Aufbereitung des Stromverbrauchs (MRTG), Temperatur usw mit dem AVR zu machen, mit einem unix Router ist das Problemlos und innerhalb einem Tag alles fertig, mit AVR-IO würde ich da Wochen brauchen und wäre nicht flexibel. Zum Beispiel gibt es Perl Programme zur Ansteuerung für die Homematic Module usw. Wenn du eh HM einsetzt (FS20 nicht vergessen) wieso nicht das HS485 Protokoll von denen verwenden für deine eigenen Platinen. Aktoren für Dimmer usw auch RGB, einfach mitteilen was du brauchst, ist kein Thema. hs485 client Firmwäre müsste ich auch haben.
Verwirrter Anfänger schrieb: > Ich bestätige zwar damit wohl die Ursprüngliche Aussage des Threads, > aber ich hab mir auch mal mein eigenes RGB Modul für solche > Kugel-Boden-Leuchten gebaut. Natürlich nicht CAN, nicht Ethernet und > nicht RS485 sondern auf Basis eines RFM12s ;-) > > Aber wenn daran Interesse besteht, kann ich die Dateien gerne hier mal > hochladen. Klingt sehr interessant, würde ich mir sehr gerna mal näher anschauen. Ja bitte hochladen, das interessiert sicher Einige hier. Vielen Dank LG Klaus
N.N. schrieb: > Klaus M. schrieb: >> Ich denke an eine dezentrale Anlage, mit einigen Modulen wie das >> AVR-NET-IO, für das ich die ganze Basis ja schon implementiert habe. Ich >> habe kein Problem Temperaturen zu messen, Releais zu schalten, Licht zu >> dimmen, nur gehört das eben in brauchbare Module verpackt. >> ... weitere detaillierte Anforderungen... > > Also praktisch alles was Du hier beschreibst bietet doch das ELV System > (FS20 und/oder Homematic) wobei alles was von Hand bedient wird (also > bei persönlicher Anwesenheit) per FS20 deutlich günstiger ist. > Hutschienenmodule mit Ethernet ähnlich AVR-Net IO hat Ulrich Radig auf > seiner Seite, inkl. Layout zum selbst erweitern. Ja das Radig-Modul gefällt mir schon recht gut, darauf noch ISO-11898 Treiber und ein RFM12 und es wäre schon perfekt für mich. Habe daran gedacht darauf aufzusetzen. Aber bitte komme mir nicht mit FS20, das System ist doch Spielzeug. Würde NIEMALS etwas verwenden wo ich nie sicher sagen kann, ob mein Funkbefehl auch angekommen ist. Das klappt doch nur bei persönlicher Betätigung. Geht das Licht nicht an versuche ich es eben nochmals ... Hey Mann, würdest du so einem System dein Haus anvertrauen ??? Aber prinzipiell bin ich der HomeMatic nicht abgeneigt (auch wenn ich manche Module krank finde) und das BidCoS ist schon OK und vor allem bidirektional mit Rückmeldung genaus so wie deren RS485-wired System. Schicke mir eine Beschreibung BEIDER Protokolle und ich verwende sofort einige Module und bastel meine Wunschmodule selbst dazu. Das wäre echt super und eine wahnsinnige zeitersparnis, aber ELV bzw. EQ-3 lassen das ja bewußt nicht zu :-( Mit dem ELV RS485-Hausschaltsystem und deren offenen Protokoll hat damals alles so traumhaft begonnen und es wurde ja sogar angekündigt, das System um Funk zu erweitern (kannst im ELV nachlesen) doch dann kam die HomeMatic, das Protokoll wurde geändert und das was man hatte konnte man nicht einmal weiterverwenden. Damals habe ich mich bei ELV beschwert über deren Vorgehen, wurde aber mehr oder weniger ignoriert :-( Also ich bin schon auch etwas sauer auf ELV, das muß ich zugeben!
chris schrieb: > AVR-IO gefällt mir weniger, weil eben AVR, ein Router (Mips) mit > SD-Card, > I2C Treiber und RS232 kann eben viel mehr bei gleichem Aufwand. > Ein Router mit USB welcher geeignet ist kostet 26€, hat mehrere > Ethernetanschlüsse, ... . klingt interessant, aber fehlt mir die Erfahrung. So wie du eben auf so einem Router scheinbar zu Hause bist, bin ich es eben auf AVR-Controller. Aber zeige mir doch genauer ein Beispiel welchen Router du wie programmierst, ich bin nicht abgeneigt was neues zu erkunden. Bin sehr wohl kompromisbereit wenn man mir was wirklich GUTES und SINNVOLLES zeigt! > Wenn du eh HM einsetzt (FS20 nicht vergessen) wieso nicht das HS485 > Protokoll von denen verwenden für deine eigenen Platinen. Weil das Protokoll ja nicht bekannt ist, oder kennst es du vielleicht? Das RS485 der HomeMatic ist ja NICHT kompatibel mit dem vom RS485-Schaltsystem, was kurz vor der HomeMatic von ELV vorgestellt wurde. Was ich natürlich machen könnte, ist die Firmware der wired-HomeMatic-Module neu zu schreiben und deren Hardware zu verwenden, sind ja auch AVR-Controller. Daran habe ich auch schon gedacht. > Aktoren für Dimmer usw auch RGB, einfach mitteilen was du brauchst, ist > kein Thema. hs485 client Firmwäre müsste ich auch haben. Ja bitte, hätte gerne eine brauchbare Schaltung für einen RBG-Dimmer auf Basis eines AVR. Das ISO-11898, RS485 oder RFM12 Interface mache ich mir dann selbst dazu. Und ein Phasenabschnittdimmer wäre auch nicht schlecht. Und was meinst mit HS485-Client ??? Wenn du damit PC-Software für das HS485/USB-Interface von ELV meinst, sowas habe ich schon vor Jahren programmiert, mich aber von den vorhandenen Modulen wieder getrennt wie ich gemerkt habe, daß ELV das System wieder einschlafen läßt!
Klaus M. schrieb: > > Aber bitte komme mir nicht mit FS20, das System ist doch Spielzeug. > Würde NIEMALS etwas verwenden wo ich nie sicher sagen kann, ob mein > Funkbefehl auch angekommen ist. Das klappt doch nur bei persönlicher > Betätigung. Geht das Licht nicht an versuche ich es eben nochmals ... > Hey Mann, würdest du so einem System dein Haus anvertrauen ??? Na ja, in Deiner Beschreibung oben hab ich nichts gefunden was sinnvoll autonom läuft, oder dimmst Du Deine Hausbeleuchtung automatisiert bei Abwesenheit? Und ist das schlimm, wenn sie dann mal nicht angeht? Ausschalten kannst Du ja mehrmals programmieren. Das war auch ein Grund für mein Eigenbaumodul, da hab ich eine Schaltstellungserkennung drin. Den Herd oder den elektrischen Kamin kannst Du ja mit dem Net-IO steuern. > Aber prinzipiell bin ich der HomeMatic nicht abgeneigt (auch wenn ich > manche Module krank finde) und das BidCoS ist schon OK und vor allem > bidirektional mit Rückmeldung genaus so wie deren RS485-wired System. > Schicke mir eine Beschreibung BEIDER Protokolle und ich verwende sofort > einige Module und bastel meine Wunschmodule selbst dazu. Das wäre echt > super und eine wahnsinnige zeitersparnis, aber ELV bzw. EQ-3 lassen das > ja bewußt nicht zu :-( > Von RS485 hatte Chris angefangen, aber soweit ich mich erinnere sind in den Kabelmodulen doch auch AVR Controller drin, die kannst Du ja neu programmieren. http://www.elv-downloads.de/downloads/programme/HS485/HS485_Protokoll.pdf ist also obsolet? Ein USB Interface gibt es aber noch http://www.elv.de/USB-PC-Interface-HS485-PCI,-Komplettbausatz/x.aspx/cid_74/detail_10/detail2_8988 Aber das sind wohl die alten Module, oder? Ein BidCos "kompatibles" Protokoll ist soweit ich mich erinnere in FHEM drin, habs mir aber noch nicht angeschaut, mir reicht FS20 oder halt "verkabelt" Ein BidCos "kompatibles" Protokoll ist soweit ich mich erinnere in FHEM drin Allerdings gibt es derzeit wohl nur noch den Dimmer und ein Rolladenmodul, ist also wohl eher tot bei ELV ? Ein BidCos "kompatibles" Protokoll soll on FHEM integriert sein > Mit dem ELV RS485-Hausschaltsystem und deren offenen Protokoll hat
Ups, sorry für das Durcheinander oben, das iPad ist nicht ganz Forumskompatibel...
N.N. schrieb: > Na ja, in Deiner Beschreibung oben hab ich nichts gefunden was sinnvoll > autonom läuft, oder dimmst Du Deine Hausbeleuchtung automatisiert bei > Abwesenheit? Und ist das schlimm, wenn sie dann mal nicht angeht? Na das ist doch wohl selbstverständlich daß ich mit meinem Hausautomatisierungssystem dann auch Abwesenheitssimmulationen, Alarmanlage und sonstige autom. Aktionen wie Heizungssteuerung und dergleichen damit abfahren möchte! Hatte nicht erwartet, daß ich das extra erwähnen muß! > Ausschalten kannst Du ja mehrmals programmieren. Das ist aber jetzt nicht dein Ernst, oder doch? Solche System wie FS20 fallen für mich unter Spielzeug, sorry! Aber eine Strategie wo ich eben sicherheitshalber X-mal sende und dann noch immer keine Garantie habe ... grauenhaft daran überhaupt nur zu denken. Mag sein, daß das manche als "Dachschaden" ansehen würden, aber wenn schon, dann soll es auch wirklich funktionieren! Das ist auch einer der Gründe, warum ich generell NICHT so viel Freude mit einem Funksystem habe, weil gerade in den freigegebenen Frequenzbereichen die Störungen immer mehr zunehmen, muß aber zugeben, daß es für manche unkritische Anwendungen schon auch sehr praktisch ist. Aber eine kabel ist ein Kabel, egal ob jetzt LAN, ISO-11898 oder RS485 !!! > Von RS485 hatte Chris angefangen, aber soweit ich mich erinnere sind in > den Kabelmodulen doch auch AVR Controller drin, die kannst Du ja neu > programmieren. Ja daran habe ich schon gedacht. Habe zwei Testmodule der Homematic herumliegen und die Pins für den Programmieranschluß sind ja auf der Platine rausgeführt, vielleicht mache ich das sogar. Sollte mit der Basis die ich für AVR schon implementiert habe ehrlich keine Hexerei sein ... DAS kann ich ja wirklich gut, Übung fehlt mit mit EAGLE, da brauche ich einfach zu lange um was sinnvolles zusammenzubringen und Löten von SMD-Bauteilen ist auch nicht so mein Ding ;-) > http://www.elv-downloads.de/downloads/programme/HS485/HS485_Protokoll.pdf > ist also obsolet? > Ein USB Interface gibt es aber noch > http://www.elv.de/USB-PC-Interface-HS485-PCI,-Komplettbausatz/x.aspx/cid_74/detail_10/detail2_8988 wie schon erwähnt. Das hatte ich ja damals und sogar in JAVA am PC programmiert, aber so ein Modul aufzubauen schaffe ja sogar ich mit meinen geringen Hardware-Kenntnissen ... liegt ein Eigenbau übrigens da neben mir auf dem Schreibtisch und darüber teste ich ja meinen BootLoader ;-) > Aber das sind wohl die alten Module, oder? Korrekt! Und das hat mich sehr geärgert, daß ELV zuerst so ein Schaltsystem rausbringt und kurz danach die HomeMatic und das HS485 kannst entsorgen. Ich habe denen übrigens damal geschrieben, ob man die alten Module nicht umprogrammieren kann, damit sie auch für die HomeMatic laufen, aber sie meinten ich soll sie verkaufen und auf die HomeMatic umsteigen :-( > Ein BidCos "kompatibles" Protokoll soll on FHEM integriert sein FHEM kannte ich nicht, werde ich gleich mal ansehen ... Aber in den letzten Tagen habe ich verdammt viel nachgedacht und es bahnt sich an, daß ich jemanden gefunden habe, der mir beim Design der Hardware und Platinen hilft ... mal sehen ... ich studiere gerade das Datenblatt vom ATxmega...D3, weil es würde sich bei einem Neudesign ja anbieten, auch gleich einen "etwas" leistungsfähigeren Controller zu nutzen ;-) Hoffe nur, daß er auch genug Zeit findet mir zu helfen ???
Klaus M. schrieb: > Na das ist doch wohl selbstverständlich daß ich mit meinem > Hausautomatisierungssystem dann auch Abwesenheitssimmulationen, > Alarmanlage und sonstige autom. Aktionen wie Heizungssteuerung und > dergleichen damit abfahren möchte! Hatte nicht erwartet, daß ich das > extra erwähnen muß! Du hattest von RGB und anderen Dimmern sowie Relais geschrieben. Und natürlich kannst Du Dir das Leben so schwer wie möglich machen. Abwesenheitssimulation dient m.M. nach nur als Verkaufsargument wenn einem gar nichts sinnvolles mehr einfällt und um die Nachbarn zu erschrecken. Heizung würde ich auch nicht mit FS20 machen und den Herd wie gesagt ebenfalls nicht (aber auch nicht anders) > Das ist aber jetzt nicht dein Ernst, oder doch? Solche System wie FS20 > fallen für mich unter Spielzeug, sorry! Aber eine Strategie wo ich eben > sicherheitshalber X-mal sende und dann noch immer keine Garantie habe > ... grauenhaft daran überhaupt nur zu denken. > ... > Mag sein, daß das manche als "Dachschaden" ansehen würden, aber wenn > schon, dann soll es auch wirklich funktionieren! Das ist auch einer der > Gründe, warum ich generell NICHT so viel Freude mit einem Funksystem > habe... Gegen Vorurteile und generelle Gründe kommt man auch nicht an ;-) Und ja, die Anforderungen am Anfang sind am größten, danach wirds realistischer. Für Bastler ist das ELV Zeugs aber gut geeignet, gerade auch die Hutschinenmodule. >> Ein BidCos "kompatibles" Protokoll soll on FHEM integriert sein > FHEM kannte ich nicht, werde ich gleich mal ansehen ... Hab gerade selbst noch mal nachgeschaut, ist wohl noch nicht so ganz weit und benötigt entweder das ELV Ethernetmodul oder das von busware.de (übrigens auch ganz nette Module, basieren aber viel auf FS20...) Das HS485 Dimmer Modul hat mich gerade sebst auf die Idee gebracht, es umzuprogrammieren, hatte bisher nur das FS20 Teil im Auge, und das hat leider keinen ATmega drin. Gut das wir gesprochen hatten. > ..bahnt sich an, daß ich jemanden gefunden habe, der mir beim Design der > Hardware und Platinen hilft ... mal sehen ... ich studiere gerade das > Datenblatt vom ATxmega...D3, weil es würde sich bei einem Neudesign ja > anbieten, auch gleich einen "etwas" leistungsfähigeren Controller zu > nutzen ;-) > Hoffe nur, daß er auch genug Zeit findet mir zu helfen ??? Das und die hohen Ansprüche weil es nichts passendes gibt (und das meiste nur für wenige passt bzw. neu erfunden werden muß) sind auch die Gründe für $topic Deshalb besser Die Ansprüche auf das eigene Können anpassen oder viel Geld in die Hand nehmen und was fertiges kaufen. Aber das Forum gäbs ja nicht, wenn jeder so denken würde ;-) Schönes Wochenende.
Ach, doch noch was vergessen, die www.volkszaehler.org S0 Bus Hardware eignet sich m.M. nach auch ganz gut als Basis für eigene Basteleien.
N.N. schrieb: > Gegen Vorurteile und generelle Gründe kommt man auch nicht an ;-) Und > ja, die Anforderungen am Anfang sind am größten, danach wirds > realistischer. Wie sagt man so schön ... Du mußt dir das UNMÖGLICHE vornehmen um das MÖGLICHE zu schaffen! Natürlich habe ich hochgesteckte Ziele, aber ich bin als Softwareentwickler auch lange genug im Geschäft umzu wissen, daß ich das alleine NIEMALS schaffen kann, was mir so alles im Kopf vorschwebt. Wie ich begonnen habe, hat man die Hardware teuer verkauft und die Software quasi dazugeschenkt. Heute ist das umgekehrt. Hardware kostet fast nix mehr, aber gute Software zu entwickeln wird immer teurer! > Für Bastler ist das ELV Zeugs aber gut geeignet, gerade auch die > Hutschinenmodule. Ich bin von den Hutschienenmodulen nicht so 100% überzeugt, weil du damit gerade in fertigen Häuseren/Wohnungen oft Platzprobleme bekommst. Sind natürlich IDEAL, wenn du zu beginn die komplette Installation planen kannst und die nötigen Verteilerkästen vorsiehst, aber ansonsten ist diese Bausform nicht immer so optimal. > Das HS485 Dimmer Modul hat mich gerade sebst auf die Idee gebracht, es > umzuprogrammieren, hatte bisher nur das FS20 Teil im Auge, und das hat > leider keinen ATmega drin. Gut das wir gesprochen hatten. Ich glaube ich mache das mit meinen vorhandenen Modulen auch, einfach weil es Spaß macht. Zuerst schieß ich mal meinen eigenen Bootloader rein und dann kann ich ja die fertig installierten Module jederzeit umprogrammieren. > Das und die hohen Ansprüche weil es nichts passendes gibt (und das > meiste nur für wenige passt bzw. neu erfunden werden muß) sind auch die > Gründe für $topic Deshalb besser Die Ansprüche auf das eigene Können > anpassen oder viel Geld in die Hand nehmen und was fertiges kaufen. > > Aber das Forum gäbs ja nicht, wenn jeder so denken würde ;-) Na Gott sei Dank denken nicht alles so, weil dieses Forum ist SUPER! Und man kann sich schon vredammt viele Ideen, Anregungen und Tips holen.
N.N. schrieb: > Ach, doch noch was vergessen, die www.volkszaehler.org S0 Bus Hardware > eignet sich m.M. nach auch ganz gut als Basis für eigene Basteleien. Kein schlechter link danke, werde ich im Auge behalten, weil daß ich meine Zähler über kurz oder lang auch anschließen möchte ist klar ;-)
N.N. schrieb: > Du hattest von RGB und anderen Dimmern sowie Relais geschrieben. Und > natürlich kannst Du Dir das Leben so schwer wie möglich machen. Dazu möchte ich noch eine Kleinigkeit erwähnen. Das waren nur Beispiele wo es ja im Netz genug Schaltungen gibt, aber man kann ohne Umbau/Adaption nix damit anfanfen, weil diese Module eben nicht MITEINANDER reden können. Also mein größtes Anliegen wäre ein einfaches, allgemeines und leicht zu implementierendes Protokoll an das sich Viele gerne halten. Das muß jetzt nicht PERFEKT sein, aber zumindest so stabil und leicht verständlich, daß es ALLGEMEIN angenommen wird! Und dann kann jeder von jedem die Module übernehmen und in seiner Haussteurung nutzen. Und dann gibt's wieder Andere die eben gerne Software schreiben und diverse Bedienoberflächen gestalten ... oder APP's schreiben ... oder ... ... DAS WÄRE MEIN TRAUM !!!
Such mal nach DMX Dimmer. Habe selbst einen einfachen 8 Kanal Dimmer http://www-user.tu-chemnitz.de/~heha/Mikrocontroller/Triac8/ je Zimmer im Einsatz, für Rolladensteuerung, Licht usw. Keine Steckdose. Ein Zweiter Node überwacht die Stromaufnahme sowie kann die Spannung auch unterbrechen (Relais) und hat einen override (Relais-Umschalter, dauern an) für die Hauptbeleuchtung und kümmert sich auch um die Schalter, IR-Fernbedienung und Sachen wie Temperatur, Licht.
Wenn es jemanden interessiert, habe auch ein Layout mit RFM12, einem 8pin uC sowie 2 Triac-Kanäle nach derselben Schaltung (Link oben). Müsste aber vorher die Genehmigung des Autors der Schaltung erfragen, da ich die Sachen eigentlich ja nur kopiert habe.
chris schrieb: > Such mal nach DMX Dimmer. Habe selbst einen einfachen 8 Kanal Dimmer > http://www-user.tu-chemnitz.de/~heha/Mikrocontroller/Triac8/ > je Zimmer im Einsatz, für Rolladensteuerung, Licht usw. Keine Steckdose. > Ein Zweiter Node überwacht die Stromaufnahme sowie kann die Spannung > auch > unterbrechen (Relais) und hat einen override (Relais-Umschalter, dauern > an) für die Hauptbeleuchtung und kümmert sich auch um die Schalter, > IR-Fernbedienung und Sachen wie Temperatur, Licht. WHAU, ich bin nun wahrlich nicht der Elektronikexperte um diese Schaltung punkto Sicherheit beurteilen zu können, aber sowas MINIMALES habe ich noch nicht gesehen !!! Und wie schaut der zweite Node aus, mit dem du die Stromaufnahme überwachst? Und das Layout mit der RFM12_version würde mich schon auch sehr interessieren. Wäre nett wenn du um die Erlaubnis fragen könntest, das auch zeigen zu dürfen.
Klaus M. schrieb: > Also mein größtes Anliegen wäre ein einfaches, allgemeines und leicht zu > implementierendes Protokoll an das sich Viele gerne halten. Das muß > jetzt nicht PERFEKT sein, aber zumindest so stabil und leicht > verständlich, daß es ALLGEMEIN angenommen wird! Und dann kann jeder von > jedem die Module übernehmen und in seiner Haussteurung nutzen. Du hattest weiter oben so geschimpft, das ELV das offene HS485 Protokoll eingestellt hat. Die Spezifikation ist doch da, es fehlt doch nur an der Implementierung im AVR Controller. Aufbauend auf die fertigen Module kann man das doch dann gut auf die (neuen) RS485 Module übernehmen und die umprogrammieren. Wenn Du einen Command Stack für den AVR schreibst finden sich ja vielleicht Leute die den als Basis für eigene Hardware benutzen. Dazu braucht es halt eine entsprechende Umgebung Webseite Wiki / SVN usw. Da gibt es schon Beispiele, es muss halt mal einer vorgehen und sich die ganze Startarbeit machen. Linux hat auch mal klein angefangen. Projekte wie Ethersex und volkszaehler.org funktionieren ja auch. Hab gleich mal ein bischen gesucht: Beitrag "Hausschaltsystem HS485 von ELV" :-))) vielleicht lohnt auch mal ein Blick auf das dort erwähnte SNAP Protokoll: http://www.hth.com/snap/ Hab das nicht alles gelesen, nur mal als Tipp. So, jetzt aber wirklich schönes Wochenende!
N.N. schrieb: > Dazu braucht es halt eine entsprechende Umgebung Webseite Wiki / SVN > usw. > > Da gibt es schon Beispiele, es muss halt mal einer vorgehen und sich die > ganze Startarbeit machen. Linux hat auch mal klein angefangen. Projekte > wie Ethersex und volkszaehler.org funktionieren ja auch. Ja da hast du recht und vielleicht versuche ich das auch so. Nur alleine ist es etwas frustrierend und zeitraubend die ganze Vorarbeit zu leisten, aber wie du an den Beispielen ja richtig bemerkt hast, muß man nur wollen, dann kann das auch funktionieren. Ich werde mal alles zusammenschreiben und mache Referenzimplementierungen als Beispiel und vielleicht hilft mir dann jemand beim Wiki bzw. bei einer Webseite, weil davon habe ich nun wirklich keine Ahnung. Wie ist das denn mit diesem Wiki, gibt's da eine einfache Software um das erstellen zu können. Dann würde ich das gleich lokal so vorbereiten und wenn ich der Meinung bin es ist reif, dann eben einfach online stellen.
Klaus M. schrieb: > Wie ist das denn mit diesem Wiki, gibt's da eine einfache Software um > das erstellen zu können. Dann würde ich das gleich lokal so vorbereiten > und wenn ich der Meinung bin es ist reif, dann eben einfach online > stellen. Na das allereinfachste wird wohl sein es als Projekt hier zu veröffentlichen, da ist dann auch gleich ein SVN für die Software möglich. http://www.mikrocontroller.net/articles/Hauptseite Das schränkt den Startaufwand schon mal ganz schön ein. Alternativ gibt es noch sourceforge, berlios und anderes.
N.N. schrieb: > http://www.mikrocontroller.net/articles/Hauptseite > > Das schränkt den Startaufwand schon mal ganz schön ein. > > Alternativ gibt es noch sourceforge, berlios und anderes. Danke
Klaus M. schrieb: > WHAU, ich bin nun wahrlich nicht der Elektronikexperte um diese > Schaltung punkto Sicherheit beurteilen zu können, aber sowas MINIMALES > habe ich noch nicht gesehen !!! Überspannungsschutz sowie ein Watchdog (Opto zur Überwachungs-Platine) ist bei mir halt noch reingekommen. > > Und wie schaut der zweite Node aus, mit dem du die Stromaufnahme > überwachst? > Hall-Sensor zur Strommessung, zwei Relais sowie div. Opto für Schalter, ein Led (Ausgang zu dieser Minimalplatine), Temperatursensor, bicolor-Led welches auch als Lichtsensor dient, i2c sowie remote Temperatursensor (Si-Diode) sowie Schaltung zum Anschluss eines Thermoelements. > Und das Layout mit der RFM12_version würde mich schon auch sehr > interessieren. Wäre nett wenn du um die Erlaubnis fragen könntest, das > auch zeigen zu dürfen. Ich hab jetzt die Genehmigung. Soll ich die Daten hier reinstellen oder einen neuen Thread auftun ?
chris schrieb: > Hall-Sensor zur Strommessung, zwei Relais sowie div. Opto für Schalter, > ein Led (Ausgang zu dieser Minimalplatine), Temperatursensor, > bicolor-Led > welches auch als Lichtsensor dient, i2c sowie remote Temperatursensor > (Si-Diode) sowie Schaltung zum Anschluss eines Thermoelements. würdest da bitte auch die Schaltung herzeigen >> Und das Layout mit der RFM12_version würde mich schon auch sehr > Ich hab jetzt die Genehmigung. Soll ich die Daten hier reinstellen > oder einen neuen Thread auftun ? ich denke da zahlt sich ein eigener Thread aus mein Name beinhaltet ja ein völlig andere Thema. Vielen Dank Klaus
Klaus M. schrieb: > Ich werde mal alles zusammenschreiben und mache > Referenzimplementierungen als Beispiel und vielleicht hilft mir dann > jemand beim Wiki bzw. bei einer Webseite, weil davon habe ich nun > wirklich keine Ahnung. Ich empfehl github. Ich nehm mal an es soll sowiso OpenSource werden. Da hast du eine konfortable Verwaltung, git statt SVN, ein Wiki und ne Homepage.
> Ich empfehl github. Ich nehm mal an es soll sowiso OpenSource werden. Da > hast du eine konfortable Verwaltung, git statt SVN, ein Wiki und ne > Homepage. Danke für den Tip. Habe jetzt erst mal mit einer Referenzimplementierung und verschiedenen Tests begonnen, mal sehen was dabei rauskommen wird. Irgendwie spiele ich auch mit dem Gedanken meine vorhandenen HS485 und HomeMatic-Module umzuprogrammieren. Die haben ja auch alle einen ATMEL drinnen und die Dinger mag ich einfach ;-) Da ich mich aber weder jemans mit git noch mit SVN beschäftigt habe, ist das ein gewisser Hemmschuh und ich investiere die Zeit vorerst lieber in mein Projekt, aber es ist gut zu wissen, was es alles gibt.
Klaus M. schrieb: > Da ich mich aber weder jemans mit git noch mit SVN beschäftigt habe, ist > das ein gewisser Hemmschuh und ich investiere die Zeit vorerst lieber in > mein Projekt, aber es ist gut zu wissen, was es alles gibt. Keine Sorge, so viel Arbeit ist das nicht. Für Einrichtung und "normale" commits vielleicht eine Stunde Einarbeitungszeit. Klaus M. schrieb: > Wie ist das denn mit diesem Wiki, gibt's da eine einfache Software um > das erstellen zu können. Dann würde ich das gleich lokal so vorbereiten > und wenn ich der Meinung bin es ist reif, dann eben einfach online > stellen. Das Wiki wär dann schon integriert, allerdings ist das immer live, da kannst du nix lokal vorbereiten. (Es sei denn du benutzt nen normalen Texteditor + Copy&Paste)
Chris schrieb: > Das Wiki wär dann schon integriert, allerdings ist das immer live, da > kannst du nix lokal vorbereiten. Das ist störend, weil ich bin eher ein Chaot bei der Entwicklung und das würde alle die Mitlesen eher verwirren. Wenn, dann stell ich es erst ONLINE wenn es so läuft wie ich mir das vorstelle und das wird wohl kaum vor Ende des Jahres sein ... aber ich arbeite daran ;-)
chris schrieb: > AVR-IO gefällt mir weniger, weil eben AVR, ein Router (Mips) mit > SD-Card, > I2C Treiber und RS232 kann eben viel mehr bei gleichem Aufwand. > Ein Router mit USB welcher geeignet ist kostet 26€, hat mehrere > Ethernetanschlüsse, ... . hast du einen Link dazu?
naja es gibt auch Projekte die immer noch am Leben sind und bereits in vielen Häusern laufen... http://home-automation-project.netmb.net/
Jörn A. schrieb: > naja es gibt auch Projekte die immer noch am Leben sind und bereits in > vielen Häusern laufen... > > http://home-automation-project.netmb.net/ Diese Projekt ist für mich neben http://doku.canathome.de/ zweifelsohne das beste, was ich bisher gefunden habe. Kann man Einiges davon lernen, besonders die enthaltene autonome Steuerung finde ich recht gelungen und die Konfiguration über drag & drop ist ein verdammt guter Ansatz. Und sogar an Funkverbindungen wurde gedacht !!! Mich stört nur bei beiden Projekten die Verwendung von CAN, aber darüber zu diskutieren ist sinnlos, weil das eben meine ganz persönliche Ansicht ist. Manche mögen CAN und manche eben nicht. Mir persönlich ist einfach nicht klar wozu ich noch einen Controller verwenden soll, der mich noch dazu auf 8 Byte begrenzt, wenn ich ja eh schon einen Controller nutze, der USART hat. CAN macht zweifelsohne in einem Auto Sinn, wo wirklich extrem kritische Bedingungen herrschen, aber für so ein Haussteuerprojekt halte ich das schon für etwas übertrieben. Vielleicht findet sich ja doch noch irgendwann ein Projekt das alles vereinen kann und es egal ist, ob man nun USART über RS485 oder ISO1050, RFM12/22, C1101, CAN oder LAN verwendet. Aber das wird wohl ein Traum bleiben ;-)
genau, der elektor Hausbus. Schaut euch das mal an...
elektor schrieb: > genau, der elektor Hausbus. > > Schaut euch das mal an... würde ich ja gerne tun, nur finde ich nix im netz, hast bitte einen link also ich meine einen link wo man sich das ansehen kann OHNE zu bezahlen !!!
Ich hab jetzt nicht den ganzen Thread gelesen, aber ich schreib trotzdem mal. Wir bauen jetzt bald seitnem halben Jahr um, und davor schon ewig geplant ... Ich hab auch überlegt Hausbus selber machen, wenn man viel Zeit sicherlich möglich, aber die hat man beim Bauen eigentlich nie, wir bauen gerade mal nur das EG um und sind schon andauernd am werkeln. Sollte dieses Problem tatsächlich gelöst sein, kommt das nächste, es wird mit 230V gearbeitet, und die Meisten kennen sich zwar aus, sind aber keine Elektriker oder dergleichen, daraus ergibt sich nicht nur in Sachen Installation ein Problem bei einem eventuellen Schaden mit der Versicherung, sondern auch wegen den Geräten, es seidenn es wird nur auf Niederspannung gesetzt und dann mit Koppelrelais getrennt. Und dann der 3.te Punkt, die Kompabilität, da regt man sich immer über die x-verschiedenen Systeme die es bald von jeder Firma für jeden Mist gibt die alle insich geschlossen sind, und baut dann selber sowas? Wenn man mal selber nicht mehr ist, kann da kein Elektriker dieser Welt mehr was dran machen. Das hat uns zu KNX getrieben, es ist teuer, es ist überteuert, aber es ist das einzige System Weltweit was die meisten Elektriker bedienen können und womit es später bestimmt keine Kompabilitätsprobleme geben wird, es ist davon auszugehen dass es auch in 20 Jahren noch neue KNX-Komponenten geben wird. Das mal ein paar sätze dazu.
Hallo, Klaus M. schrieb: > Mir persönlich ist einfach > nicht klar wozu ich noch einen Controller verwenden soll, der mich noch > dazu auf 8 Byte begrenzt, wenn ich ja eh schon einen Controller nutze, > der USART hat. CAN macht zweifelsohne in einem Auto Sinn, wo wirklich > extrem kritische Bedingungen herrschen, aber für so ein > Haussteuerprojekt halte ich das schon für etwas übertrieben. Der CAN-Controller ist wirklich lästig, aber eine moderne MCU hat CAN onboard, ist billiger, kleiner und hat mehr bums. Ich habe auch schon Projekte mit einem extra CAN-Controller realisiert und bin nach Fertigstellung ganz schnell auf eine andere MCU gewechselt. Schon aus Platz- und Kostengründen. Der Vorteil von CAN liegt ganz klar an der vorhanden Spezifikation und das diese größtenteils schon in Hardware gegossen ist. Der Softwareaufwand ist bei CAN minimal und das scheinbare 8 Byte Problem ist bei einem Hausbus nur theoretischer Natur. Wenn z.B. Bilder von einer CAM oder ähnliches übertragen werden sollen wird die Busauswahl ohnehin etwas begrenzter, da scheidet USART und CAN direkt aus. > Vielleicht findet sich ja doch noch irgendwann ein Projekt das alles > vereinen kann und es egal ist, ob man nun USART über RS485 oder ISO1050, > RFM12/22, C1101, CAN oder LAN verwendet. Aber das wird wohl ein Traum > bleiben ;-) Soweit ich das gesehen habe werden Funkbrücken und Netzwerk schon unterstützt. Grüße.
Mathias K. schrieb: > Der Vorteil von CAN liegt ganz klar an der vorhanden Spezifikation und > > das diese größtenteils schon in Hardware gegossen ist. Diesen Vorteil kannst aber nur in reinen CAN-Systemen wirklich nutzen, in Mischsystemen mit Funk (und darum kommst ja heute kaum noch herum) bringen dir dieser (in Hardware gegossenen) Vorteile nichts mehr ... schon mal daran gedacht ???
Klaus M. schrieb: > Diesen Vorteil kannst aber nur in reinen CAN-Systemen wirklich nutzen, > in Mischsystemen mit Funk (und darum kommst ja heute kaum noch herum) > bringen dir dieser (in Hardware gegossenen) Vorteile nichts mehr ... > schon mal daran gedacht ??? Warum sollte es in einem Mischsystem diesen Vorteil nicht mehr geben? Grüße.
Weil du die Vorteile von CAN, also z.B. die zerstörungsfreie Arbitrierung nicht auf Funk übertragen kannst, also brauchst ohnehin andere Strategien um Kollisionen aufzulösen ... so meinte ich das.
Klaus M. schrieb: > Weil du die Vorteile von CAN, also z.B. die zerstörungsfreie > Arbitrierung nicht auf Funk übertragen kannst, also brauchst ohnehin > andere Strategien um Kollisionen aufzulösen Das ist klar. Es gibt aber auch Funksysteme die dieses Problem in Hardware lösen. Es sei denn man will unbedingt low cost (rfm,uart) und frickelt dann jahrelang an einer Softwarelösung bzw. kommt an die Grenzen der MCU. Grüße.
Mathias K. schrieb: > Das ist klar. Es gibt aber auch Funksysteme die dieses Problem in > Hardware lösen. Und an was denkst du da konkret, hast einen Link ?
(jedes? bidirektionale) http://de.wikipedia.org/wiki/Z-Wave oder EnOcean vielleicht? wobei ICH keine Ahnung hab, ob man sowas auch fürs "selber basteln" bekommt.?! (wobei "in Hardware lösen." natürlich relativ ist, ..)
wurde ja schon viel gesagt wieso es nicht klappt jeder hat andere Ansprüche. Ich habe an jedem Schalter, Steckdose... jeweils noch ein EIB-Kabel gelegt 2 Adern werde ich für die Stromversorgung (5V) meiner Module nutzen und 2 als Busleitungen, es werden CAN-Treiber zum Einsatz kommen aber ein eigenes Protokoll, da mir der Overhead bei CAN zu groß ist, die Atribitrierung finde ich hingegen sehr gut. Hard + Software ist für mich kein Problem nur die Umsetzung/Fertigung einer Platine(SMD) fällt mir schwer. Ich werde erstmal 2 verschiedene Module aufbauen. Eine Platine mit Anschlussmöglichkeit von 8 Tastern, die dann nur die Steuerbefehle auf den Bus gibt. z.B: Lampe1 50%...aussendet und eine Triac-Platine die dann entsprechend Lampen ein/ausschaltet oder dimmt. Mit der Zeit werden dann weitere Platinen dazukommen um z.B. die Rolläden/Raffstores Tageszeit/Helligkeitsabhängig zu steuern oder Signale Bewegungsmelder auf den Bus geben. Ich spare mir durch die 5V Versorgung auf jeder Platine den Spannungsregler + etwas Hühnerfutter, da das ganze möglichst klein und billig ausfallen soll. Die Schutzschaltung hat das Schaltnetzteil im Verteilerkasten. So das da keine Überspannung vom Schaltnetzteil durchkommt. Ich finde OpenSource gut, das bringt die Gesellschaft viel und schneller weiter als proprietäre Software oder Patente die sehr lange bestand haben. Schonmal überlegt wer die Zeche zahlt, für die Lizenzgebühren die sich die Firmen gegenseitig abknöpfen.
Thomas O. schrieb: > jeweils noch ein > EIB-Kabel gelegt 2 Adern werde ich für die Stromversorgung (5V) meiner > Module nutzen und 2 als Busleitungen, es werden CAN-Treiber zum Einsatz > kommen aber ein eigenes Protokoll, Juppi, da scheint mal jemand meiner Meinung zu sein, genau so habe ich das auch vor, nur nehme ich RFM12 als Funkmodule dazu und teste gerade eine wirklich brauchbare Library. Hast schon über dein Protokoll nachgedacht?
im Prinzip ein abgespecktes CAN auf Softwarebasis. Differentielle Übertragung, Identifier mit 10 Bit und 8 Bit Daten, ohne Stuffing Bit da Baudrate sehr gering, abgespeckte Fehlererkennung, ACK und einige Fehlerroutinen der Knoten, damit die den Bus nicht dauerhaft belegen können.
wenn du eh nur so langsam und wenig übertragen willst, warum dann:
>da mir der Overhead bei CAN zu groß ist,
Thomas O. schrieb: > im Prinzip ein abgespecktes CAN auf Softwarebasis. Differentielle Also nur Drahtgebunden! Naja, wenn man das Glück hat die richtigen Kabel schon verlegt zu haben, geht das natürlich, ich MUSS leider auch auf Funk zurückgreifen, brauche also eine universellere Lösung.
Thomas O. schrieb: > Identifier mit 10 Bit und 8 Bit Daten Jetzt verstehe ich erst ... du willst keinen UART verwenden, sondern die Bits per Software rausschieben und im Prinzip CAN nachprogrammieren? Da muß ich aber Robert L. recht geben !!!
per UART muss ich mich darum kümmern wer wann senden darf damit keiner dazwischensendet oder Ergebnisse anfordern. Mit Overhead meinte ich halt das für 8 Bit Daten das vielfache drumherum dazukommt. Mit einer Startsyncronisierung der Teilnehmer und niedriger Bitrate braucht man keine Angst haben das die Syncronisierung davonläuft auch ohne externen Quarz, deswegen ist auch das Bitstuffing nicht nötig.
Thomas O. schrieb: > niedriger Bitrate braucht man > keine Angst haben das die Syncronisierung davonläuft auch ohne externen > Quarz Beim Hardware-UART in simpler Ausführung - wie ihn auch die AVRs (ausgenommen evtl. ATxmega) haben - spielt die Bitrate für die Qualität der Synchronisierung keine Rolle: der Fehler tritt immer in Prozent auf, 5% bei 1200 Baud oder 5% bei 115200 Baud, egal. Der UART macht 16 (bzw. 8) Abtastungen in der Zeit, die ein Bit dauern soll. Dann entscheidet er, ob es eine 0 oder eine 1 war. Wenn die tatsächlichen Baudraten von Sender und Empfänger unterschiedlich sind, verschieben sich das Zeitfenster für das Abtasten schön langsam über den Bereich, in dem die gesendeten Bits liegen. Bei ununterbrochenem Senden kann es dann also passieren, dass (Sender schneller als Empfänger) die Verschiebung so groß wird, dass ein Bit aus dem nächsten (gesendeten) Byte in des gerade empangene Byte eingebaut wird (könnte auch das Parity-/Stop-Bit sein, egal). Damit ist dann die Synchronisation auf das Startbit des nächsten Bytes in Gefahr oder schon zum Teufel. Die Situation lässt sich (ohne Quarz) etwas entspannen, indem man * den OSCCAL-Wert laufend der Temperatur nachführt * mit zwei Stop-Bits sendet * zwischen dem Zeitpunkt, zu dem das letzte Bit eines Bytes den Sender verlassen hat und dem Eintragen des nächsten Bytes in das Senderegister etwas Zeit vergehen lässt, d.h. meherere Bit-Takte lang. Meine Meinung. Es mag auch andere Meinungen geben.
@Konrad S. Ich verstehe was du meinst. Zeitliche Verzug der Abtastung im Zeitfenster) z.B. jedesmal +1µSek aus dieser Fenstermitte. Ich werde mit voraussichtlich 9600 Bits/Sek arbeiten, habe also eine Bitzeit von 100µSek(Zeitfenster) jetzt taste ich in der Mitte dieses Zeitfenstern ab (sagen wir mal bei 50µSek +-5µSek) und dann wiederholt alle 100µSek( +1µSek Jitter) dann lande ich erst nach 45 Bits mit meiner Abtastung daneben, die Nachricht muss also kurz genug sein damit die Abtastung nicht aus dem Zeitfenster läuft. Außerdem kann man weitere Maßnahmen treffen um dieses Jittern zu korrigieren, z.B. Timermanipulation um Einsprungverzögerung des Interrupts wieder zu korrigieren...Flankenauswertung vor nach der Abtastung zum Nachsynchronisieren.
elektor schrieb: > genau, der elektor Hausbus. > > Schaut euch das mal an... OK, jetzt habe ich verstanden was der elektor Hausbus sein soll. Eine wirklich nette Artikelserie, verstreut auf das monatlich erscheinende Magazin, wo ein Bussystem erst langsam entwickelt wird und die Autoren erst in der Folge 7 !!! (nach Hinweisen von Lesern) doch langsam draufkommen, dass es vielleicht nützlich wäre auf ein und demselben Knoten verschiedene devices ansprechen zu können !?!?! Mann oh Mann ich lache mich schief! Vielleicht wäre es für die Autoren doch sinnvoll gewesen sich mal VORHER ein wenig zu informieren was es denn so alles gibt und wie die anderen das machen! Wenn sowas in einem Forum duskutiert wird ist das ja OK, aber in einer Artikelserie eines angesehenen Magazines, wo man teuer dafür bezahlen muß, ist das eher ein Witz. Und dann hier im Forum auch noch Werbung dafür machen, finde ich persönlich nicht OK ... ist aber wieder einmal MEINE GANZ PERSÖNLICHE Meinung!
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.