Fortsetzung von: http://www.mikrocontroller.net/forum/read-1-66019.html#216025 > Autor: Danny P. > Datum: 04.08.2005 20:49 > @and_ref: > es ist fürchterlich schwer meine gedanken dazu kurz aufzuschreiben > :) aber wenn ich alle möglichkeiten µC´s vorbereiten möchte (damit > diese parametrierbar sind) ist das ein enormer umfang... > > ein-/ausschalten oder sowas - kein thema... > > und woher die variable kommt.. > mal ein beispiel: ich frage den Taster an portb,1 ab > > da müsste ich vor der abfrage erst "portb" ausm eeprom laden, > anschliessend "pin 1", dann abfragen... und das bei jedem > durchlauf... > da hab ich doch schon 2/3 der zeit nur parameter geladen um dann 1/3 > abfrage zu machen... das übers ganze programm frisst doch auch ne > menge zeit (ja ich weiss bringt den µC nicht um).. > > einfacher gehts doch nun nicht, oder? Die Geschichte mit "erst portb aus eeprom laden, dann pin1 abfragen" hab ich noch nicht ganz verstanden. Du wirst so oder so einen Task brauchen, der zyklisch in festen Zeitabständen aufgerufen wird. (z.B. alle 10ms). Innerhalb von 10ms kannst du seeehr viele Dinge erledigen, da spielt es keine Rolle, ob die "erst portb aus eeprom laden, dann pin1 abfragen" genau einmal in 10ms ausführst, oder 1000x. Die meiste Zeit wird die Software sowieso nur warten. 10ms sind länger als du denkst :-) Wenn du die zu erledigenden Aufgaben geschickt aufteilst und modular und unabhängig voneinander programmierst, dann kannst du weite Teile der Software nicht nur "im" Lichtschalter sondern auch "in" der Lampe, der Steckdose oder der Heizung einsetzen. Mit unabhängigen Dingen meine ich z.B.: - Einlesen der Eingänge - Abarbeiten der eingetroffenen CanBotschaften - Auswerten der Telegramme - Einstellen der Werte/Parameter für die Applikation - ... - Applikation ausführen - (z.B. Reaktion auf erkannten Tastendruck vorbereiten) - ... - Versenden der CanBotschaften (falls nicht IRQ-getrieben) - (ggf. ums Eeprom kümmern) - Setzen der Ausgänge Danach wird diese Abfolge wieder von vorne abgearbeitet. Die Liste läßt sich beliebig verfeinern, bis du dann daraus direkt deinen Scheduler ableiten kannst.
@and_ref: gute sache hier mit nem eigenen Forum für´n Hausbus :) mh.. ich versuchs nochmal anders zu beschreiben: Die Pin´s des µC sind ja fast alle doppelt belegt. Somit brauche ich ja feste programmteile (taster auswerten, analogwert zyklisch senden, ausgang schaltet.....) jeder dieser programmteile (falls verwendet) wird mit gewissen parametern versehen (welcher eingang, welches telegramm....) beim reinen taster- oder analogwertsenden kein thema.... leicht das blöde ist (und da häng ich gedanklich) da ich noch nicht weiss wie mal alles an jeder stelle kommt kann ichs jetzt nicht parametrierbar machen... bzw muss jede nur erdenkliche funktion möglich machen (bis hin zum twi, uart, lcd) und wenn ich es mal weiss (und somit alles abgeschlossen ist) brauch ich nix mehr parametrieren.... das mit einer komfortablem parametrier-software is natürlich echt n argument.. aber der weg ist weit :-) mh.. nochmal zu deinem zyklischen task/sheduler... den sinn hab ich auch schonmal versucht zu verstehen... ich hätte einfach die eingänge abgefragt, entprellt, anschliessend das telegramm verschickt, dann geguckt ob ich ne nachricht empfangen habe, falls ja ausgewertet und die schleife wieder von vorn...
@Danny: Vergiss am Anfang TWI, UART, LCD, usw. Konzetriere Dich auf das wesentliche: Digitale Eingänge an die Taster oder Schalter kommen. Digitale Ausgänge an die Lampen oder Motoren kommen. Du machst Dir ein Konzept, in dem es nur solche "primitiven" Signale gibt. Du musst Dir nun überlegen, wie Du die Schalter, Taster, Lampen, Rollomotoren, Regensensoren, Bewegungsmelder etc. miteinander verknüpfen will. Am besten planst Du Dir ein Modell-Haus auf dem Papier, mit Fenster, Tastern türen. Dann überlegst Du Dir verschiedene Abläufe. Also nach Hause kommen und Haustüre aufschliessen, durchs Treppenhaus gehen, im Keller etwas suchen, usw. Nun überlegst Du Dir, wie Du in Deinem einfachen Konzept das alles implementieren kannst, so dass es übersichtlich bleibt, und Du wenig Aufwand damit hast. So. Und wenn das geklappt hat, probierst Du Dein Konzept um solche Sachen wie Temperaturmeßwerte etc. zu erweitern. An dieser Stelle merkst Du dann schnell, ob Dein Konzept flexibel genug ist und problemlos erweiterbar wird. Nicht einfach "ins Blaue rein entwickeln", sondern Du musst anhand konkreter Aufgaben und Szenarien entwickeln. Hast Du noch keine konkreten Szenarien, musst Du Dir welche schaffen, z.B. mit einem virtuellen Modellhaus. Wenn Dir der Überblick fehlt: Klein anfangen, nicht alles auf einmal lösen wollen. Iterrativ vorgehen. Du brauchst für die optimale Lösung viel Erfahrung. Hast Du keine, musst Du Dir solche Erfahrung selbst schaffen. Und Software-Prototypen kann man weg werfen. Bei mir wird das ganze Hausbus-Zeuch frühesten Mittelfristig konkret, aber dennoch habe ich erstmal begonnen, mir einen kleines Simulationssystem auszudenken. Nichts kompliziertes, nur um ein paar virtuelle Knoten von meinem virtuellen Haus zu simulieren. Einfach damit ich einige Szenarien mir realer Software simulieren kann.
@unbekannter: das ist es ja, ich will nicht ins blaue programmieren. aber ich will mich momentan nicht mit dingen beschäftigen die leicht zu machen sind. wie gesagt "normale verknüpfungen" Taster->Lampe usw. sind überhaupt nicht das Problem. Auch mit dem parametrieren nicht. Das habe ich halb auf dem papier und halb im kopf zu ende gedacht. aber ich sehe es so: wenn ich mir schon die mühe mache alles parametrierbar zu machen, dann auch zu 100% mir bringt eine tolle parametriersoftware nichts wenn jeder knoten der was besonderes hat ein unparametrierbarer exot ist. (bspw. knoten hat rs232-verbindung zur heizung, oder nen windmesser bei dem takte gezählt und in eine grösse gerechnet werden müssen) will sagen: parametrierbarkeit macht arbeit (knotensoftware auf viele fälle ausgelegt, software für den pc muss gemacht werden usw.) und diese arbeit bin ich nicht bereit in kauf zu nehmen wenn sie nicht zu 100% für alles verwendbar ist (und zwar im vorhinein, sonst macht sie m.m.n. kein sinn) für einfache verknüpfungen ist es perfekt: knoten zusammenlöten, software rauf, einsetzen und anschliessend nach belieben taster und lampen verknüpfen. so, nun soll aber plötzlich rc5 empfangen werden. also doch wieder "hart programmieren" du sagst "konzentrier dich aufs wesentliche", natürlich ist es einfacher jetzt die "sonderfälle" aussen vor zu lassen; nur denke ich sind genau diese sonderfälle (und davon wird es viiiele geben)später die dinger die das schöne gerüst der einheitlichen parametrierung einstürzen lassen... dafür sind die unterschiedlichen möglichkeiten einfach zu groß der bisher einzige genannte vorteil ist der komfort beim um-verknüpfen o.ä. durch einfache software/tabelle, kein compiler, kein flashen nötig - wirklich gut aber meiner meinung nach steht der aufwand (zumindest bei mir) für die parametrierbarkeit in keinem verhältnis zum nutzen, denn so oft wird sicher später nicht mehr dran rumgespielt... kann mich denn keiner ein kleines bisschen verstehn? :-)
> das mit einer komfortablem parametrier-software is natürlich echt n > argument.. aber der weg ist weit :-) Der Weg ist weit und das Ziel. :-) > ich hätte einfach die eingänge abgefragt, entprellt, anschliessend > das telegramm verschickt, dann geguckt ob ich ne nachricht > empfangen habe, falls ja ausgewertet und die schleife wieder von > vorn... Prinzipiell ist das ja auch nicht mehr. Außer, daß du eine definierte Zeit wartest, bis du wieder die Schleife von vorne beginnst... dann kannst du z.B. sehr einfach Zaehler/oder Softwaretimer aus diesem zyklischen (z.B. 10ms)-Task ableiten. Du weisst dann, daß nach 100 Durchlaeufen, genau eine Sekunde rum ist (-> Uhrzeit/Sekundenzaehler erhoehen), oder daß du nach 5 Zyklen die Tasteneingänge entprellt hast... Wichtig ist, daß du z.B. "Einänge abfragen" und anschließend "Telegramme verschicken" von einander trennst (d.h. verschiedene Funktionen oder gar verschiedene C-Module), sonst wird der Code nur für diese eine Funktion brauchtbar, während bei sauberer Trennung, kannst du das Modul Tastenabfragen auch für alle anderen Knotentypen/Hardwaretypen verwenden. Wir sollten uns nochmal klar werden, was mit Parametrieren eigentlich gemeint ist. Ich verstehe darunter Werte/Größen zur Laufzeit vorzugeben oder einzustellen, die das Verhalten der Software auf vorgesehene Weise verändern/variieren. Als parametrierbare Größen stelle ich mir z.B. bei einem Dimmer die Zeit vor, die er braucht, um von 0% auf 100% zu dimmen bei Softstartfunktion. Oder die logische Adresse eines Knotens oder dessen Busübertragungsrate oder ob der IR-Empfänger im Knoten aktiv geschaltet sein soll oder nicht (z.B. weil er nicht bestückt ist)... Aber als parametrierbare Größen zählen auch z.B. die Telegramme, die ein Taster bei Tastendruck verschicken soll. Durch Parametrieren kann ich eine nicht vorbereitete (d.h. ausprogrammierte) Funktionalität nicht nachträglich einbringen, allenfalls freischalten. Nachträglich Funktionalitäten nachzurüsten läuft immer auf eine Neuprogrammierung oder gar Neuentwicklung/Weiterentwicklung der Knotensoftware raus. > nun soll aber plötzlich rc5 empfangen werden. also doch wieder > "hart programmieren" genau, eine andere Möglichkeit gibt's nicht. > natürlich ist es einfacher jetzt die "sonderfälle" aussen vor zu > lassen versuche die Gemeinsamkeiten den Sonderfälle rauszufinden, z.B. ob das jetzt einen Taster, einen Reedkontakt oder einen Regensensor einliest, ist prinzipiell erstmal egal. Alle werden auf gewisse Eingangswerte bestimmte Reaktionen auslösen (z.B. bestimmtes CanTelegramm schicken). D.h. deine Software, die daraufhin ein CanTelegramm verschickt ist für all diese Sensoren identisch, nur das Einlesen unterscheidet sich ggf. Aber darauf bist du ja vorbereitet, da du diese Teile im Code schön getrennt hast. > die das schöne gerüst der einheitlichen parametrierung einstürzen > lassen... wenn du die Schnittstelle der Parametrierung, d.h. also WIE werden die Daten in den Knoten übertragen, universell formulierst, dann kannst du nachträglich noch so viele Parameter dazuerfinden wie du willst. Diese Schnittstelle mußt du ja nicht mehr anfassen. Daß du dann noch Code dazuprogrammieren mußt, der mit die neue Funktionalität erzielt/ausführt ist ja klar. Ich mache mir weniger Gedanken über die Konfiguration/Parametrierung im Knoten selbst, sondern eher wie man dem Benutzer eine möglichst einfach und intuitive Oberfläche/Schnittstelle dazu bereitstellen kann... aber das ist ein anderes Thema :-) > aber meiner meinung nach steht der aufwand (zumindest bei mir) für > die parametrierbarkeit in keinem verhältnis zum nutzen, denn so oft > wird sicher später nicht mehr dran rumgespielt... Nein, denn es ist eigentlich egal, ob du die zu versendenden Telegramme (bei Tasterdruck) jetzt aus einem const-Array (=ROM) oder aus einem Eeprom (das du von außen zum parametrieren/konfigurieren "erreichen" kannst) verschickst. Das ändert am eigentlichen Code prinzipiell nix!
@and_ref: hm... bisher habe ich es immer so gemacht das das eigentliche "programm / abfragen etc." ständig lief und nur per timer-interrupt zähler (zeiten, schritte usw.) inkrementiert wurden... werd ich diesma auch so machen... festgelegte funktionen per parameter frei schalten is klar, aber diese auch noch pin-flexibel zu machen... okay auch noch denkbar... aber wie gesagt... die jetzt nicht bekannten funktionen :-) aber ich glaub beim thema parametrierung kommen wir nicht mehr zusammen ;-) werd nun das "hauptprogramm" für die UP-Knoten scheiben, dann laufen die schonmal die nächsten tage... anschliessend werd ich dann mal 10stk zusammenbraten (hab bisher nur 2 Testdinger)....
Geile Sache das mit dem neuen Forum. (Den Namen würde ich aber noch ändern) :) Aber: Kann mir eventuell mal jemand in einer Kurzfassung sagen, was die letzten 130 Beiträge über Diskutiert wurde? Möchte mir nähmlich auch Gedanken machen über das ob und wie eines Hausbusssystems. Nur diese geschätzt 150 Seiten durchlesen wird rein Zeitlich ein kleines Problem bei mir, .... :( Danke schon mal. AiM
@Michael, in welcher Sprache hättest Du es denn gerne?? Koopi
Naja Michael, ich denke schon, dass Du Dir diese Mühe selbst machen musst. Wenn Du selbst einen Hausbus bauen willst, ist das Lesen dieser rund 250 Beiträge des anderen Threads nur vielleicht 1% der Arbeit die auf die zukommt...
Und man muss sagen das die Lektüre sehr interessant ist ;)
Den Thread hier mit - ich glaub 800 Postings gilt es noch zu übertreffen: http://www.mikrocontroller.net/forum/read-1-29525.html
Hallo, ich habe ein ähnliches System bereits realisiert. (ist noch nicht fertig.) Beschreibung: * 4-adriges Telefonkabel überall wo Strom liegt * 10kBit/s CAN Protokoll + 24V Versorgung für die Knoten * Sternverkabelung * ca. 500m - 1000m Kabel verbaut. * zentrale 24V Stromversorgung * CANOpen als High level Protokoll * CAN als Software auf einem M8, M16 oder M128 AVR Controller. Wie bei Caraca allerdings in C als ISR geschrieben. * Die Hardware besteht auch einem sehr soliden CAN Level Shifter und dem Controller. Sollte komplett verpolungssicher sein. * Alle Knoten verfügen über einen Bootloader, wo ich die Applikation, incl. CAN Protokoll im System über den Bus austauschen kann. Die Bootloader werden über eine Prozedur bei dem Stromanschalten aktiviert. * Wenn sich richtige CAN Controller an die Bootprozedur halten, dann kann man auch diese mit verbauen. * Alle Knoten sollten Ihre Grundfunktion (z.B. Rolladen mit lokalem Schalter hoch/runter) auch ohne Buskommunikation verrichten können. * HardWare - Rollladensteuerung für 1 Motor (passt zusätzlich in eine 7cm Schalterdose) - 2*Relais für 1 Motor (passt zusätzlich in eine 7cm Schalterdose) - Dimmerknoten - Rollladensteuerung für 5 Motoren - Bewegungsmelder - Funkuhrknoten * Insgesamt möchte ich 10-20 Knoten im Haus vernetzen. Status: * CAN funktioniert, hat noch einen Bug * CANOpen funktioniert rudimentär * Hardware ist super Wer interesse hat sich an der Arbeit und an den Ergebnissen zu beteildigen, der möge sich bei mir melden. Mfg Maik
@Maik: Hallo, zu Deiner Hardware hätten mich noch ein paar Details interessiert: wie genau hast du die Rollladensteuerung implementiert? Ist die 7cm Schalterdose von der du schreibst eine Unterputz-Dose, in der normalerweise Steckdosen oder Lichtschalter eingeklemmt werden? Du hast also für jeden einzelnen Motor eine Schaltung in einer Dose vorgesehen - direkt in dem Raum in dem sich auch der Rollladen befindet? Mfg Anton
Hallo Anton, die Rollladensteuerung wird einfach mit zwei Relais implementiert. Die Rolladen schalten von selber am Anfang und Ende aus. Der Strom wird dann nach einem Timeout ausgeschaltet. Ich habe in dem V2 Bilder Verzeichnis ein Bild zusammen mit einem Schalter gemacht. Eine passende Dose hatte ich gerade nicht. Die Schaltung besteht immer aus zwei Platinen. Einer Busankopplung (AVR + CAN) und der eigendlichen Interface Hardware (z.B. zwei Relais oder Dimmerschaltung). beide Platinen sollten zusammen in einem sehr kleinen Plastikgehäuse von Conrad in eine 7cm Unterputz-Dose passen. In den meinen Räumen habe ich mehr als ein Fenster, somit ist eine größere Hardware (wie in einem Bilder_V1 Bild gezeigt) in der Raumverteilerdose. Ich möchte aber auch Dimmer und Schalter hinter Steckdosen platzieren, deshalb habe ich meine Schaltung so klein gemacht. Ja es wäre möglich eine solche Schaltung für einen Motor in eine Unterputsdose zu packen. Da brauch man nicht einmal eine tiefe Dose.
@Danny P. So ich habe die beiden Can-Bus Platinen fertig bestückt und möchte nun in Bascom programmieren. Deine Anleitung durchschaue ich einigermassen. Nur bei der Hardware kommen mir Zweifel: wie oder nach welchen Kriterien müssen dir Quarzfrequenzen der beiden Kontroller sein. Hard- oder Software-SPI kann man bei Bascom wählen. Nur schätze ich mal das der CS-Pin immermal auf High bzw Low gesetzt werden muss. Würde es besser sein ihn extra zu schalten? Meine Platinen sind nach : http://www.kreatives-chaos.com/index.php?seite=mega8can gebaut. Vielen Dank für deine Antwort schonmal
Für den Hausbus gibt es ein Selbstbauprojekt, das mit i2C läuft: http://hauscomputer.gmxhome.de/ zwar mit Löten verbunden, läuft aber bei mir stabil. Meine Rollläden und die ganze Extras (Lampen, Brunnen usw.) hängen daran. Kaum Wartung erforderlich. Den Hochzeitstag kann ich jetzt auch nicht mehr vergessen (Kalender ist dabei). Mir fehlt aber noch die Kopplung zum FS20 System von ELV. Gibt es da schon irgendein fertiges µPC- System?
Schau mal bei www.ipsymcon.de, oder geh auf den Link http://www.ipsymcon.de/forum/showthread.php?t=79&highlight=fs20+modul
"Für den Hausbus gibt es ein Selbstbauprojekt, das mit i2C läuft: " Ist aber leider kommerziell...
Hi! Bin zwar bereits gestern auf diesen Thread (also eigentlich auf den "original" Thread...) gestoßen - hat aber ein bißchen gedauert, bis ich ganz durch war... Für's Erste ein paar "kleine" Fragen: Habt Ihr Euch darüber gedanken gemacht, wie lange die selbstgebaute Elektronik hält / Wie man zu Ersatz in sagen wir mal 10-50 Jahren kommt? Wie das Hausbussystem gewartet wird, wenn Ihr das (aus welchem Grund auch immer) nicht mehr könnt? (Dazu hab ich so bei ein zwei Beiträgen zumindest den Hinweis bezüglich Zusatzkabel gelesen...) Ach ja, wo kriegt man günstig (gute, robuste, ...) Aktoren her? So Dinger wie Mischer/Ventile für die Heizung bzw. Lüftungsanlage, steuerbare Heizungspumpen mit geringem Stromverbrauch. Und was auch immer mir noch gar nicht eingefallen ist, daß man brauchen könnte :-) PS. Mein Hausbau-Vorhaben startet erst gegen Ende nächsten Jahres, hab also noch ein bißchen Zeit :-)
@Bernhard: Die Aktoren für die Heizungsanlage liefert und baut Dein Heizungsbauer ein. Pumpen gibt's bei einem Ein- oder kleinem Mehrfamilienhaus zwei bis drei an einer Heizungsanlage. Aktoren für Heizkörperventile oder Fußbodenheizungsventile gibt es von den Ventilherstellern. Die laufen mit 24 Volt oder 230 Volt (es gibt beide Varianten).
In 50 (!) Jahren bekommst Du auch von keinem normalen Hersteller mehr Ersatz - garantiert nicht. Gerade in der heutigen Zeit, wo die Produktlebensdauer immer weiter sinkt. In 10-30 Jahren vielleicht noch, aber dann auch nur von den großen und teuren Herstellern... Über 30 Jahre kompatible Hausbuselektronik zu bezahlbaren Preisen von einem Hersteller zu bekommen wäre wohl schon ein Glücksfall. Macht also keinen großen Unterschied ob man nu selbst baut oder was von der Stange kauft. Daher muss man wohl etwas auf Vorat kaufen und herstellen damit man später schnell und einfach was ersetzten kann. Also wenn man z.B. 20 Module im Haus hat, sollte man besser 10 - oder mehr - fertig bestückte Module auf Reserve halten, und von einigen speziellen Bauteilen wie Controller (falls die mal vom Hersteller abgekündigt werden) und Leerplatinen besser auch noch welche gut geschützt lagern... Und wenn man sichergehen will das jeder später am System was ändern/ersetzten kann, muss natürlich zumindest ne rudimentäre Doku (=Schaltpläne + Grundrisszeichnungen mit Positionen der Module und Pläne wie die Leitungen verlegt sind + Doku wie man die Dinger umprogrammiert und anschließt, etc. (wenn man ganz sicher gehen will, alles noch mit nem guten Drucker auf gutem Papier ausdrucken - wer weiss schon ob in 10 Jahren noch jemand nen PDF Reader aufm Computer hat... na und für die Archäologen in 500 Jahren sollte man noch alles in Stein meißeln ;) :P )) Naja - also wenn man mal ne gute Steuerungssoftware für die Module hat, können die auch von Laien umprogrammiert werden. Man muss nur immer einen passenden Computer haben wo die Software mit läuft. (gleiches Problem wie oben bei PDF - läuft die Software noch in 20 Jahren auf üblicher PC Hardware? Wohl nur auf Umwegen wie Emulatoren...) ... Aber mal ganz unabhängig davon: Wenn man die Module so anbringt, dass man die leicht gegen was moderneres austauschen kann, kann man ja alle 30 Jahre mal ein komplettes "Hardwareupdate" durchführen (lassen)...
Möglichst konventionelle Verkabelung, d.h. zu den Lichtschaltern eben entweder irgendein Buskabel (mind. 2x2Adern) oder noch besser: wie früher diskret mit 3x1,5mm² oder 5x1,5mm² (230V~-tauglich). Die Lampen/schaltb.Steckdosen usw. ebenfalls sternförmig mit Einzelleitungen verlegen. Diese Kabel in einen "zentralen" Unterverteiler ziehen. Ob dieser Unterverteiler jetzt pro Zimmer/Stockwerk oder Haus ausgelegt ist, spielt keine Rolle. Die ankommenden Kabel dort optimalerweise auf Eingangklemmen legen (teuer!). Wenn jetzt die Hardware kaputt geht und kein schneller Ersatz greifbar ist, kann man relativ einfach die Taster wieder konventionell auf die Lampen legen/patchen oder alternativ die ganzen Busmodule im Schaltschrank durch EIB (oder was in 25Jahren aktuell ist) ersetzen. Rück- oder Umrüsten ist somit jederzeit möglich. Hat nebenbei auch den Vorteil, wenn zum Zeitpunkt des Einzugs noch nicht alles fertig sein soll/ist, kann man einfach um-/nachrüsten. > PS. Mein Hausbau-Vorhaben startet erst gegen Ende nächsten Jahres, > hab also noch ein bißchen Zeit :-) Zu diesem Zeitpunkt hatte ich schon erste (funktionierende) Prototypen der Busknoten auf dem Tisch. Am Ende war alles gerade so fertig geworden. Also unterschätz den Aufwand nicht, wenn das solide und nicht nur bis zum nächsten "Stromausfall" halten soll. Mach dir auch Gedanken über Stromaufnahme, Wärmeentwicklung, Bauteilbeschaffbarkeit usw.. Nimm keine Bauteile, die du nicht neu kaufen kannst (billige Ausbauteile irgendwoher; keine Spezialbauteile/Exoten)...
Bis auf den Zeitpunkt der Fertigstellung liegt and_ref schon richtig. Ich habe mein gesamtes Haus mit über 5000m Leerrohre ( Termitenbau ) ausgestattet und in jeder Etage 1 - 2 Unterverteilungen gesetzt. Von dort aus gehen alle Leerrohre zu den Leerdosen, Fenstern, Heizungsverteilern usw.. Somit kann ich beruhigt in 5 - 30 Jahren meine dann lahmenden KHBus durch die aktuellen Techniken ersetzen. Also Leerrohre nicht vergessen!!!! Koopi
Hi Zusammen ! Möchte mich auch mal wieder zu wort melden :) die Zeit war in den letzten Wochen mehr als knapp, aber das kennt Ihr sicher... Wir haben mal über das ansteuern von Dimmermodulen o.ä. gesprochen (fertig gekauft wegen der ganzen versicherungstechnischen Ängste ;)... Ich weiss nich ob jemand schon was besseres weiss, aber ich hab heute rausgefunden das man "Standart"-UP-Dimmer von BuschJäger Busch-Universal-Drehdimmer® Einsatz 6591 U-101 bzw. Busch-Universal-Zentraldimmer®- Leistungsbaustein 6594 U per EIB mittels eines Steuerbausteines steuern kann. Dieser Steuerbaustein macht aber nichts anderes als PWM auf eine geheimnisvolle Datenleitung ;) zu legen. Da müsste doch was gehen... Hat jemand zufällig mit sowas schon experimentiert? Oder ne bessere Lösung für die 230V-Seite? greetz Danny
Bitte 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.