@and_ref: Also, die Sensoren würden nie einen Aktor direkt ansprechen, sondern immer "broadcasten". D.h. die Aktoren würden sich die Nachrichten, die sie benötigen, selbst heraussuchen. Konkret, eine Eltaco-Schaltung würde ich wiederum die Taster selbst verwalten lassen. Also, wenn ein Taster gedrückt wird, werden folgende Nachrichten verschickt: 1.) Ein Taster wird gedrückt -> "Taster 1, Zustand gedrückt" 2.) Der Taster ist einer Eltaco-Schaltung zugeordent, also wechselt der gedrückte Taster seinen internen Eltaco-Zustand. 3.) Der gedrückte Taster teilt den neuen Eltaco-Zustand mit -> "Eltaco Flurlicht, Zustand an" 4.) Alle Lampen im Flur hören auf "Eltaco Flurlicht, Zustand an" und schalten das Relais. 5.) Alle anderen Taster im Eltaco-Verbund Flurlicht hören auf "Eltaco Flurlicht, Zustand an" und aktualisiern ihren internen Zustand. 6.) Das Kind hat noch immer den Finger auf dem Taster, also verschickt der Taster -> "Taster 1, Zustand lange gedrückt". 7.) Niemand interessiert sich für "Taster 1, Zustand lange gedrückt" 8.) Der Taster wird irgendwann losgelassen -> "Taster 1, Zustand nicht gedrückt" 9.) Niemand interessiert sich für den losgelassenen Taster. 10.) Pause... ;-) 11.) Taster 2 wird vom Vater gedrückt -> "Taster 2, Zustand an" 12.) Taster 2 ist dem Eltaco-Verbund Flurlicht zugeordnet. Der letzte bekannte Zustand dieses Verbundes war "an", gesetzt vom Taster 1. Also ist der neue Zustand des Eltaco-Verbunds Flurlich "aus". 13.) Taster 2 teil den neuen Zustand des Eltaco-Verbunds mit -> "Eltaco Flurlicht, Zustand aus". 14.) Alle Lampen die sich für "Eltaco Flurlicht, Zustand aus" interessieren, schalten sich aus. 15.) Alle Taster, inkl. Taster 1, im Eltaco-Verbund Flurlich hören auf "Eltaco Flurlicht, Zustand aus" setzen ihren internen Zustand entsprechend. 16.) Taster 2 wird losgelassen -> "Taster 2, Zustand aus". So in etwa stelle ich mir das vor. In dem Beispiel oben habe ich mal weggelassen, dass die geschalteten Lampen auch wiederum ihren geänderten Zustand der Allgemeinheit mitteilen würden. Der Trick daran ist, wenn ein bestimmter (virtueller) Zustand von mehreren Buskopplern kontrolliert wird, wird immer der Buskoppler, der den Zustand als letztes geändert hat, zum temporären "Master" dieses Zustandes. D.h. virtuelle Zustände werden über mehrer Knoten verteilt, es gibt keinen festen Master. Wenn jetzt ein Buskoppler im Verbund ausfällt, passiert gar nichts. Die verbleibenden Buskoppler können den verteilten Zustand problemlos selber weiter pflegen. Wenn ein neuer Buskoppler dazu kommt, und den Zustand eines virtuellen Verbundes nicht kennt, muss er den erst mal abfragen. Auch wenn er der 10. Taster im Verbund ist, bekommt er nur eine Antwort, da die anderen 9 Taster ja alle den gleichen Zustand (per Can-ID) übermitteln. Um Übertragungsfehler auszuschliessen, kann eine Zustandsänderung ja auch mehrmals gesendet werden und sogar periodisch wiederholt werden. Mir schwebt in etwa folgendes vor: Erst wird die aktuelle Zustandsänderung mit hoher Priorität gesendet. Danach wird sie mit exponentiell immer größeren werdenden Zeitabständen mit niedriger Priorität wiederholt, bis die Widerholungsrate z.B. 5 Sekunden erreicht hat. Die Prioritäten würde ich in etwa so sortieren (von höchster zur niedrigsten Priorität): - System-Nachrichten (Software-Updates, Parametrierung, Debugging) - Wichtige Sensoren (Feuer, Gas, Wasserrohrbruch, Einbruch etc.) - Umweltsensoren (Regen, Sonne, Temperatur, etc.) - Taster, Schalter - Virtuelle Zustände (Eltaco-Verbünde, Uhrzeit etc.) - Zustände der Aktoren (Lampe an/aus, Rollo-Motor an/aus, etc.) - Wiederholungen... So in etwas stelle ich mir mein verteiltes System vor. Vor allem liessich sich das meiner Meinung nach leicht anpassen und erweitern. Wenn in dem Flurlich-Beispiel z.b. noch ein virtuelles Zeitrelais hinzukommen würde, würde das nur auf die Nachrichten "Eltaco Flurlicht, Zustand an" hören, und nach einer weile, falls es vorher nicht ein Taster macht, die Nachricht "Eltaco Flurlicht, Zustand aus" verschicken. Von dem Timer müssten dann weder Taster noch Lampen etwas wissen. Sie sehen nur die Nachrichten des virtuellen Eltacos. Woher sie kommen, ob von einem Timer, einer Diagnose-Software oder sonst woher, wäre alles egal. So wären trotzdem umfangreiche Verknüpfungen möglich, ohne dass die einzelen Teile (Taster, Timer, Lampen) jeweils die anderen Teile kennen müssten.
Ihr denkt alle viel zu kompliziert ! Kurze Vorstellung eines bestens funktionierendem - Bussystems (SEBUS): 1 Hardwaremodul für die Hutschiene das alle Funktionen abdeckt. Mittels Dip-Schalter Auswahl ob als Jalousie, Schalt- oder als Analogaktor. (8 IN/4 Out. Bestückbar mit div. Relaisen, Solid-State oder Transistor). Keine Parametrierung erforderlich - wozu auch. Busmedium egal. Ob CAN,RS485, RS232 alles geht ! MC egal ! Keine 9 Bit UART notwendig ! Netzgeräte soviel und welche man will. Keine Potentialprobleme da alle Geräte potential-getrennnt mittels DC-Wandlern versorgt werden. Keine Koppler, Drosseln, Stromschienen, Logikmodule, usw. Software: Jeder Eingang schickt bei Betätigung ein Bestätigungstelegramm. Diese sagt aus, ob pos/neg Flanke und ob lange oder kurz gedrückt wurde. Auch Ausgänge schicken bei Betätigung ein Zustandstelegramm. Jeder Teilnehmer kann darauf reagieren oder nicht. Programmierung: Es kann ein Master eingesetzt werden, ein PC der die Visualisierung (VB) mit übernimmt, oder jedem Teilnehmer kann über den Bus gelernt werden, aus was er horchen soll. Dieser kann auch Telegramme weiterreichen. Dimmaktoren reagieren auf lang/kurz Telegramme (Ein/aus /Dimmen bei Langtelegrammen) Programmierung über PDA, Internet, PC, Handy oder einfach Taster drücken. Wichtig: Auch ein Elektriker muss mit der Programmierung klar kommen. Für die normale private Haustechnik ist der Bus weit unterfordert. Seine Stärke ist eigentlich die Erfassung von Störmeldungen, Alarmmeldungen, Zutrittskontrollen, Visualisierung, SPS usw. in der Industrie. Kosten pro Multifunktionsmodul: ca 120.- ( 8 IN/ 2 Analog 0 -10 V, 4 Out 230 V/16 A, 1 x 0 - 10 V Out, RTC, 1 x PT100, 1 Analogpot /4 TE) Ich würde alle Entwickler bitten, ihre Bus-Entwicklungen zu hinterfragen, ob sie mit diesen Vorgaben mithalten können. Falls nicht - gibt es noch viel Arbeit zu tun. SG Busmaster
@Busmaster: a.) Google findet alles möglich zu "SEBUS", nur kein Bussystem. Verschrieben? Hersteller? URL? b.) Du diskutierst die Anwendung eines Bussystems. Wir dikustieren hier die Implemtierung. Ein "kleiner" Unterschied... c.) Parametrierung ist ein Oberbegriff für "Auswahl mittels DIP-Schalter" und "Programmierung über PDA, Internet, PC, Handy oder einfach Taster drücken". d.) Dein "Hardwaremodul für die Hutschiene" ist das gleiche wie unser "Buskoppler". Ein Stück Elektronik mit Ein- und Ausgängen an den irgendwelche Sensoren (Schalter, Taster, Fensterkontakte) und Aktoren (Licht, Rolläden, Klinkel) angeschlossen werden. Vielleicht hättest Du wenigsten das letzte Drittel dieses Threads lesen sollen, damit Du wüsstest, um was es hier geht...
@Busmaster: sinnvoll hin oder her. unterfordert hin oder her. was du anscheinend vergisst: Ich denke ich spreche hier für einige: Es ist ein HOBBY. Und da macht das selbst durchdenken, planen, löten und programmieren nun mal spaß. Ausserdem bietet der Bus viiiele Reserven, wer weiss wie man die mal nutzen kann... Fertig kaufen klann ja jeder :-p
Dany 30.07.2005 10:20 > "unsynchrones laufen" [...] > aber wenn er nur "umschalten" schickt sollte es keine probleme geben > könntest du noch mal ein beispiel für "unsynchrones" laufen nennen? Bsp. 2 Treppenhauslampen an einem Taster. 1 Lampe fällt kurz aus, während der Taster gedrückt wird... dann kriegst du das Licht nie mehr aus, da immer entweder L1 oder L2 brennt :-) Aber wie man da umgeht hat ja "Unbekannter" heute 30.07.2005 12:52 schon geschrieben. > zu den EIB-Tastern: [...] 2x5polige stiftleiste ja so war auch mein Wissenstand - damit sollte das gehen. > stromausfall; da bei 100.000 schreibzyklen das eeprom ja irgendwann > mal totgeschrieben ist naja, wenn du soo viel Wert auf diese Feature legst, dann kannst du dir Strategien überlegen, daß du die max.Schreibzyklen der Zellen nicht erreichst, z.B. rechzeitig auf eine andere Eepromzelle ausweichen... @Unbekannter 30.07.2005 12:52 klingt alles sehr gut - neu (für mich) wäre dann, daß auch die restlichen Taster im Verbund mithören müssen, wenn ein anderer Verbundtaster 'was' meldet. Ok. Hast du dir schon Gedanken über eine Parametriersoftware (PC) gemacht und wie der Benutzer diese Kombinationen eingeben/einstellen kann? Noch einen Einwurf: Spätestens wenn ich mit dem Wandtaster neben dem normalen Licht auch noch das Badradio ein/ausschalten will, wirds (in meiner Vorstellung?) wieder etwas komplexer... (Muss ich mir mal genauer durchdenken). [Nachrichtenprioritäten] > 1. System-Nachrichten (Software-Updates, Parametrierung, Debugging) das wäre bei mir die niedrigste Priorität :-) Und das mit der Priorität ändern je nachdem wie lange das Ereignis her ist, würde ich nicht machen, da extrem debugaufwändig. CanId würde sich dann ja ständig ändern... Den Prioritäten bei CAN würde ich allgemein keinen so hohen Stellenwert zuordnen, da das nur interessant ist, wenn der Bus sehr stark ausgelastet ist(!) und wenn 2 Knoten bitgenau zeitgleich anfangen zu senden. Was ganz Allgemeines: Wie parametriert man eigentlich die Knoten am besten (zur Laufzeit)? Indem man ihnen bestimmte (gerichtete) CanTelegramme zusendet, die genau dieser eine Knoten auswertet. (Gibt's noch andere Möglichkeiten?) Also braucht man doch auf jeden Fall eine Möglichkeit gezielt mit einem Knoten kommunizieren zu können. Warum sollte man diese Möglichkeit/Schnittstelle nicht auch (zusätzlich?) für den normalen Betrieb verwenden können/sollen/dürfen? Ich denke da z.B. an eine Zeitschaltuhr, die gezielt nachts um 3Uhr alle 'vergessenen' Lampen abschaltet. Ich würde da nicht viele verschiedene Verbundtaster-Ausmeldungen schicken, sondern gezielt jede Lampe einzeln abschalten?! Gibt's noch andere Fälle in denen gerichtete Kommunikation einfacher/flexibler ist? Im jetzigen Verlauf der Diskussion kristallisiert sich ja langsam heraus, daß man eigentlich alles was zum Betrieb des Systems gehört (Aktoren schalten; Meßwerte mitteilen) über Ereignisse/Broadcasts lösen kann. Sobald aber etwas parametriert werden soll (zur Laufzeit), muß das über gerichtete, adressierte Telegramme passieren. Kann man das so pauschal sagen? Zum Schluß noch einen Hinweis an diejenigen, die die Eingänge und Ausgänge strikt (topo)logisch trennen: Fällt der Bus aus (Kurzschluß irgendwo im Haus), so fahren nicht mal die Rolläden... Deshalb habe ich die Rolladentaster auch direkt an die Knoten angeschlossen, die die Motoren schalten, oder Lichttaster an einen Knoten, der auch Dimmer steuert. Fällt der Bus aus (wird im Knoten erkannt), so kann man wenigstens noch die knotenlokalen Lampen mit den direkt angeschlossenen Tastern bedienen.
Hallo zusammen, kaum ist man mal nen Tag nicht da, schon muss man aufpassen den Anschluss nicht zu verlieren :-) @Unbekannter [DOORS] Also DOORS ist schon mehr als ne Dokumentenverwaltung oder auch Datengrab genannt. DOORT ist ne SW von Telelogic zur Anforderungsanalyse, Pflichten- Lastenhefterstellung usw. Ich hab das in den Raum geworfen, da wir den Einstieg, als die Anforderungsanalyse eines Projektes damit aufsetzen. Ist ungemein hilfreich, vor allem, da wir daraus weiterführend auch das SW Design (allerdings mit nem anderen Tool) ableiten. @ Danny P. [Stromausfall] Darüber hab ich mir auch schon Gedanken gemacht. Ich habe bislang nicht vor die internen Zustände eines Busknotens im EEPROM abzuspeichern. Dort ist erstmal nur die Konfiguration eines jeden Knotens hinterlegt. Wie Andre schon schrieb, es gibt verschiedene Möglichkeiten die Zyklenzahl im EEPROM zu erhöhen, ich habs aber bislang nocht nicht vorgesehen. Ich werde meine Spannungsversorgung der einzelnen Etagen lieber mit ner USV absichern. Bei nem Reset des Systems wird dann eben eine sichere "Grundstellung" angefahren, also meinetwegen die Beschattung des Wintergartens eingefahren und anschliessend, eben je nach Situation, auf die Umwelt reagiert. @ All Im Moment haben wir wohl zwei Konzepte die sich gegenüber stehen (oder in gewisser Weise auch ne Schnittmenge bilden). 1. Direkte, adressierte Kommunikation 2. Broadcats 3. Eine Vermischung Broadcast/direkt. Broadcast für Statusmeldungen, direkt für Diagnose/Update/Flashen Ich habs leider noch immer nicht geschafft mir das mal konkret durchzudenken. Mal ganz grob, was mir dazu einfällt: 1. Direkt - Jeder kann sich mit jedem ganz gezielt unterhalten - Für jeden Empfänger muss ne Botschaft verschickt werden - Der Sender bestimmt, wer welche Information bekommt, das heisst, der Sender muss wissen, ob der Empfänger etwas damit anfangen kann - Wenn ein Empfänger in nem Sleep Modus ist, dann verschläft u. U. die Botschaft - SW Update per CAN einfach möglich 2. Broadcast - Jeder Teilnehmer hat am selben Bus die selben Informationen - Der Empfänger entscheidet, ob er mit den Informationen etwas anfangen kann - Sleep Mode ist ebenso ein Problem - Aktuatorknoten verwalten die Zustände - Jeder Taster/Sensor/... bekommt ne eigene Botschaft - SW Update nur über gezielte Kennung eines Knotens möglich 3. Broadcast / direkt - Eben ne Mischung aus beiden :-) - Ablauf in den Aktuatorknoten - Zustandsänderung wird von den Knoten angefragt - Jeder Knoten hat ne eigene BotschafsID, mit der er direkt angesprochen werden kann. - Tasterknoten können schlafen gelegt werden, wenn sie direkt angesprochen werden sollen, können sie das dann aber auch verschlafen - ... irgendwie drängt die Zeit schon wieder. Vielleicht habt ihr Lust die Gegenüberstellung weiter auszubauen? Das hier soll mal nur ein kleiner Ansatz sein :-)
@and_ref: zum unsynchron werden: da hast recht. könnte theoretisch im einzelfall passieren (halte ich zwar für seeeehr unwarscheinlich, aber die möglichkeit sollte ganz ausgeschlossen werden) daher hab ich mich grad damit angefreundet generell eine rückmeldung des aktors einzubauen. wird nicht innerhalb einer bestimmten zeit die zustandsänderung an den initiator zurückgemeldet wird das telegramm wiederholt. nach bspw. der 5. wiederholung erfolgt eine störmeldung. dadurch wirds meiner meinung nach sehr sicher und sollte tatsächlich mal ein knoten kurz nen blackout haben fällts evt. gar nicht auf durch diese rückmeldung bin ich auch darauf gekommen das durch spezielle can-botschaft das direkte schreiben bis zu 8Byte in den ram eines anderen knotens möglich sein soll (ähnlich des Merkeraustausches Simatic SPS <-> OP). dadurch braucht an einigen stellen nicht auf eine bestimmte botschaft gewartet werden sondern nur ein ram-bit gecheckt werden. dadurch wird das "software-grundmodul" wieder umfangreicher aber die spezifische einzelprogrammierung erleichtet (meiner meinung nach) evt. werde ich aktor-schaltvoränge auch auf diese art übers ram austauschen, mal sehen.. muss ich noch mal drüber nachdenken.... meinungen?
Zwei Dinge: Zum einen sehe ich in einem CAN-Bus nicht so sehr einen Unterschied zwischen Broadcast und direkter Adressierung der Nachrichtenziele. Denn CAN ist ja ein gemeinsam genutzter Bus. Alle knoten können immer alles mithören, egal ob sie "direkt" oder per "broadcast" angesprochen werden. Für mich sind das eher zwei verschiedene Blickwinkel auf die gleiche Sache. Bei der "direkten" Adressierung ist in der CAN-ID der "Empfänger" kodiert, beim "broadcast" ist in der CAN-ID der "Absender" kodiert. Doch in beiden Fällen verhält sich die Sicht des Empfänger gleich, nämlich auf eine bestimmte CAN-ID (mit Maske) reagiert der Empfänger. Auch die Sicht des Senders ist für beide Fälle irgendwie gleich. Es wird eine CAN-ID nach irgendeinem Schema erstellt, und die Nachricht auf dem Bus verschickt. Ob nun sich nur ein Empfänger oder viele Empfänger um die Nachricht kümmern, ist aus dem Blickwinkel des Senders egal. Von daher: Die strikte Unterscheidung in "Broadcast" und "direkter Adressierung" existiert in meinem gedanklichen Konzept nicht. Darum meinte ich auch in meinem Ursprungsposting, das eher aus dem Blickwinkel des Gesamtsystems zu betrachten, und mehr über Zustände und deren Änderungen nachzudenken. Und eine Nachricht auf dem Bus informiert nur über eine Zustandsänderung. Nicht mehr, nicht weniger. Zum zweiten (das wird hoffentlich kürzer): Wegen der Fehlerfallbehandlung würde ich nichts zu kompliziertes machen. Sich eher an Internetprotokollen orientieren. Pingelig beim Versenden von Nachrichten sein, großzügig beim Empfangen von Nachrichten. Und: Zeit heilt alle Probleme, und wenn Fehler auftreten, es so lange versuchen bis keine Fehler mehr auftreten. D.h. von Fehlerzähler, Störungsnachrichten, Bestätigungs-Nachrichten etc. halte ich nicht viel. Was nützt es, wenn ein Knoten feststellt, dass irgendeine Busstörung vorliegt, weil er keine Antworten enthält und dann die "Störlampe" leuchtet und der Knoten alle weiteren Versuche einstellt? Dann muss man den Knoten wieder irgendwie entriegeln oder so. Und wohin soll die "Störlampe"? An jeden Taster? Oder soll jeder Koppler ein Summer bekommen der dann Nachts um 3:45 Uhr im Schlafzimmer anfängt zu piepen, nur weil irgendein anderer Knoten im Flur nicht mehr antwortet? Oder soll die Störung per gestörten Bus an eine Zentrale eine Störung melden? Und was passiert, wenn aus irgendwelchen Gründen der Absender keine Bestätigungsnachricht vom Empfägner bekommt, aber die Nachricht vom Sender problemlos an den Empfänger durchgeht? Schaltet dann der vermeintlich funktionierende Knoten das Licht nach immer 5 Sekunden wieder ein, nachdem es von einem anderem Taster manuelle ausgeschaltet wurde, nur weil er vermeintliche funktionierende Knoten keine Bestätigungsnachricht vom Licht bekommt? Ich denke, diese Konzepte machen mehr Problem als sie nützen. Ich mache das so: Es muss nur gewährleistet sein, dass ein Knoten, der z.B. erst nach 10 Minuten an den Bus online geht, sich alle nötigen Informationen/Zustände besorgt oder von jemanden bekommt, so dass er sich nahtlos einfügt. Damit kann sich ein Knoten jederzeit wieder in das Gesamtsystem einfügen, egal aus welchen Grund er eine Zeitlang nicht im Gesamtsystem integriert war. Eine Störung ist eine Ausnahme, die man eh nur sehr schwer kontrollieren kann. Könnte man die Situation leicht kontrollieren, würde die Störung sowieso nie auftreten. Wie jemand anders in der Dikussion geschrieben hat: Wenn ein Koppler von Bus getrennt ist, kann der Koppler eben nur noch die direkt angeschlossenen Aktoren bedienen (Licht, Rollos) und nur auf die direkt angeschlossenen Sensoren (Taster, Regenmelder) reagieren. D.h. man sollte die Koppler so verteilen, dass beim Bus-Totalausfall, die Koppler selbst wenigstens noch ein paar Lampen ein- und ausschalten können. Und der mechanische Schalter für das Licht im Schaltkasten und bei den Sicherungen, das auf ausschliesslich dafür abgesicherten Kreise liegt, einschliesslich ein, zwei Steckdosen in jedem Zimmer, die fest auf einer Phase hängen, ohne Elektronik etc. ist nie nicht verkehrt. So das im Katastrophenfall (Blitzeinschlag) wenigstens noch ein paar rudimentäre Sachen gehen... So, jetzt ist's doch etwas mehr geworden. Nun aber wieder Schluss...
@Danny P. Du verwendest den Mega8 für Deine Buskoppler. Baust Du das in DIP oder verwendest Du SMD? Der Mega8 ist ja hinreichend klein, um den DIP-Typen zu nehmen (Ich scheue mich noch etwas vor SMD ;o) ). Ist der Mega8 hinreichend "groß", um die oben diskutierten Aufgaben zu übernehmen? Es sollte ja in jedem Buskoppler das gleiche Programm (nur mit anderen Parametern) laufen, um nicht für jeden Teilnehmer eine eigene Programmversion pflegen zu müssen.
@neugierieger: ich habe ausschliesslich smd bauteile verwendet. da ich die platine selbst ätze wollte ich auf doppelseitige verzichten. und bei 2 grossen DIL-IC´s wär das wohl nix geworden. Ich würde sogar fast behaupte mit DIL ist es enorm schwer zu layouten (2 DIL IC, bustreiber noch mal ein 8füssler, die ganzen stiftleisten zum anschluß, widerstände etc... ) stell dir mal die bauteile auf ner fläche von 50 x 50mm auf den tisch :) zum programm: ich bin mir noch nicht gnaz sicher ob es mit einer parametrierbaren standartversion klappt. das wird sich nach und nach rausstellen. jetz hab ich erst mal wieder etwas mehr zeit und werde nun stück für stück das "hauptprogramm" zusammenstellen und anschliessend nach und nach über den eeprom parametrierbar machen also ich denke das die 8K Flash des Mega8 ausreichen. es werden ja standart-hardware-funktionen genutzt um die indormationen einzusammeln. ok, der ir-empfang einer fernbedieung... aber laut atmel AppNote auch nur 70 oder 80 words... @unbekannter: für mich ist es schon ein grosser unterschied mit direkter adressierung etc. wen nich die direkte adressierung viel nutze und gleichzeitig die filtermöglichkeiten meines MCP2515 erspare ich mir software und arbeit des µC. und egal wie wenig das am ende ausmacht: das was ein eingesetzter chip von haus aus kann brauch ích nicht noch ein zweites mal per software erfinden. zu deiner störmeldegeschichte: ich schrieb ja ... ein knoten macht mehrere versuche wenn das nicht geklappt hat -> Fehlermeldung. wenn es nach 5 oder 10 versuchen schon nicht geklappt hat wird auch mit 200 versuchen nicht besser... und schliesslich hat so ein ausfall ja ein grund und wenn einem knoten das öfter passiert wird er ausgetauscht... wenn man wie du beschreibst "auf crash" fährt dann is irgendwann etwas so kaputt das nix mehr geht...
@Unbekannter: [Broadcast und direkte Adressierung] > Für mich sind das eher zwei verschiedene Blickwinkel auf die gleiche > Sache. genau, aber in der Knotensoftware bzw. deren Konzept/Aufbau unterscheidet sich das dann doch schon erheblich. Im einen Fall steckt die Intelligenz im Sender, um anderen Fall im Empfänger. @Dany P. [Ausfallerkennung/Strategie] > ein knoten macht mehrere versuche wenn das nicht geklappt hat -> > Fehlermeldung. wenn es nach 5 oder 10 versuchen schon nicht geklappt > hat wird auch mit 200 versuchen nicht besser... Naja, da denke ich anders ähnlich wie "Unbekannter", entweder ich schicke gezielt ein gerichtetes Telegramm einmal. Dann erwarte ich keine Bestätigung, sondern muß anders sicherstellen, daß der Empfänger darauf reagieren kann. Oder ich schicke ein Telegramm ständig/zyklisch, damit ein kurzer Ausfall nix macht. Empfangsbestätigungen, Mehrfach wiederholtes Senden usw. halte ich fuer Unsinn und macht das Protokoll unnötig kompliziert. Es muss nicht jeder Lichtschalter überprüfen, ob die mit ihm "verbundenen" Lampen auch wirklich da sind - das kann eine ganz andere Instanz übernehmen. z.B. durch Überprüfen, ob auch alle Knoten schön ihre Broadcastmeldungen regelmäßig absetzen, und bei Ausbleiben kann man das irgendwie global signalisieren. Wie gesagt, darum muß sich der Lichtschalter nicht auch noch kümmern.
@Neugieriger,
@Danny,
>Ist der Mega8 hinreichend "groß"
Ich habe bis vor einigen Monaten den Mega8 für meinen Hausbus
eingesetzt. Allerdings musste ich feststellen, dass der MC zuletzt
immer enger wurde. Nun setze ich den Mega168 ein und habe wieder
entsprechend Luft.
@Unbekannter,
@Alle,
ich habe in meinem Bus auch streng auf Ereignisse gesetzt. Einzige
Ausnahme ist die Konfiguration der Knoten. Dabei wird die Sendung mit
der Adresse des Empfängers und einer entsprechenden Eventkennung
gesendet.
Alle Sendungen werden von jedem Modul über seine Compare-Liste geprüft
um gegebenenfalls die entsprechenden Actiondaten aus der Compareliste
an die Anwendungsschicht weiter zugegeben. Die Actiondaten bestehen aus
einem Zeiger auf eine Anwendung und die zu verarbeitenden Daten.
Damit lassen sich eigentlich alle Verknüpfungen, die ich bisher
gebraucht habe, erzielen.
Ich glaube nicht das es unkomplizierter geht.
Koopi
@and_ref: ich will da mal auf deine erfahrung zurückgreifen :) du hast anscheinend bisher keine "wiederholungen" oder "rückmeldungen" eingebaut. ist denn schon mal irgendetwas ausgefallen (in bezug auf den bus) oder ein telegramm nicht angekommen? oder unsynchron geworden o.ä.? vielleicht mache ich mir da ja wirklich zu viele gedanken....
Richtig, kein weiteres Protokoll zur Datensicherung drübergestülpt. CAN reicht da vollkommen aus. Und wenn CAN mal ausfällt (bisher auch noch nicht passiert - zumindest ist mir nichts aufgefallen), dann schalten die Knoten (bei mir) eh in den lokalen Betrieb...
@and_ref: du hattest doch auch mal Atmel-µC eingesetzt. Weisst du noch wie gross in etwa das übertragene Programm war. Ich frage weil ja grad die Frage aufkommt ob nen Mega8 ausreicht (bin eigentlich der meinung für den UP-Dosen-Knoten auf jeden Fall)...
Habe von damals alles vergessen/verdrängt ;-). Heute brauche ich <10kB mit "allen Schikanen"... Ausschliesslich Grundfunktionalität sollte in 4kB zu programmieren sein - aber man will ja sauber und modular programmieren, da sind Reserven immer praktisch. Nach oben hin gibt's natürlich keine Grenzen ;-). Gibt's keine AVRs, die kompatibel zum Mega8 sind und mehr als 8kB Flash haben?
ich glaub nicht... ab mega16 ja... aber der mega8 im 32pin tqfp nicht... naja ich denke dennoch ich werd damit auskommen, werd in den nächsten tagen wie gesagt mal das programm zusammenschreiben...
@and_ref, @Danny P., >Gibt's keine AVRs, die kompatibel zum Mega8 sind und mehr als 8kB >Flash haben? Der Mega168 ist pinkompatibel, hat 16KB und ist zu fast 100% SW-kompatibel. Einige Registernamen müssen geändert werden. Danach läuft es fast immer sofort. Habe den Mega8 damit schon in mehreren Projekten ersetzt. Koopi
@and_ref: mal wieder zum thema zu viel gedanken machen :) du nutzt ja deine filter nicht. mir ist grad mal aufgefallen, wenn ich eh teilweise mit broadcast arbeite und somit die telegramme per software filter muss... dann bringt es wohl doch keine so grosse änderung wenn ich vorher per hardware in "broadcast" und "direkt" angesprochen unterscheide, oder? also würden meine hardwarefilter auch überflüssig bzw. bringen nicht mehr so die dolle vereinfachung, kannst du das so bestätigen?
Hi! Ich verfolge den Thread nun auch schon seit längerem mit großem Interesse. Meine Frage zu der Realisierung eines solchen Hausbus ist, ob sich jemand schon einmal Gedanken zu den duch den Hausbus verursachten zusätzlichen Stromkosten gemacht hat. Mit irgendwas will die ganze verbaute Elektronik ja versorgt werden. Hat da jemand schon mal eine Hochrechnung gemacht, auf wieviel kW/h pro Jahr das an zusätzlichem Verbrauch rausläuft?
"Mit irgendwas will die ganze verbaute Elektronik ja versorgt werden. Hat da jemand schon mal eine Hochrechnung gemacht, auf wieviel kW/h pro Jahr das an zusätzlichem Verbrauch rausläuft?" Ich nutze zwar EIB, aber die Kosten sind deutlich gesunken. Dafür ist der Bus schließlich da ;) Im Winter werden bei Dunkelheit die Rolläden automatisch runtergefahren, alleine das spart schon eine Menge Heizung. Ebenso die anderen Systeme!
ich habs mal überschlagen und bin auf etwa 20EUR im Jahr gekommen; waren aber nur die knoten inkl. CAN (ohne Relais etc.). Das ist auch der Grund warum mir SolidStateRelais lieber wären als Standart-Relais, wegen des stromverbrauches auf dauer...
Also, was die Relais verbrauchen, spielt ja nun wirklich eine untergeordnete Rolle. Denn ein Relais benötigt nur dann Strom, wenn es angezogen ist. Und wenn es angezogen ist, läuft da in der Regel ein deutlich größerer Verbraucher mit. Kleine Koppelrelais liegen unter 0,2 Watt. Das macht bei einer 100 Watt Glühbirne nun nichts mehr aus... Aber die Koppler sind schon interessant. Angenommen 15 Koppler, jeder Koppler benötigt 0,5 Watt. Das macht dann 7,5 Watt. Rechnen wir mal mit einem Schaltnetzteil mit 75% Wirkungsgrad, habe wir rund 10 Watt. So: 10 Watt 24 Stunden 365 Tage = 87,6 kWh im Jahr. Bei einem Strompreis von rund 0,20 /kWh sind das 17,52 Euro im Jahr. In meiner Rechnung sind die 0,5 Watt pro Koppler eher an der oberen Grenze (ohne Relais) anzusiedeln, und die 15 Kopller in einem kompletten Haus eher an der unteren Grenze. Die Stromkosten sind also zu verkraften.
Auch den Verbrauch der Relais kann man sehr niedrig halten, indem man Sie mit einer kleinen Sparschaltung aus einem Widerstand und einem Kondensator ansteuert. Damit läßt sich die Leistung auf ca. 1/4 reduzieren und sie schalten trotzdem mit voller Leistung ein. Dann kommen die 20 Euro im Jahr gut hin. Ich habe insgesamt 33 Knoten, einen kleinen Webserver und 5 Displaymodule und komme auf 22 Euro im Jahr. Das verbraucht mein Nachbar mehrmals wöchentlich in der Kneipe. Koopi
@and_ref: soo, lang nerv ich nicht mehr, dann wirds konstruktiver :) kann es sein das die parametrierbarkeit bei dir eine menge speicher frisst? bei tastendruck ein zugeordnetes telegramm ist ja nich so schwer. aber mal will ich auch langen tastendruck melden mal nicht... aber in nem anderen fall soll das ein ausgang sein und ne led steuern. und in noch nem anderen fall ein lcd... so flexibel möchte ich sein/bleiben... nur das bläst die knotensoftware echt auf. ist das in diesem umfang bei dir parametrierbar?
Rehallo, ich will mich auch mal wieder zurückmelden, aber bei Euch kommt man ja kaum beim Mitlesen mit, geschweige denn mitzuschreiben ;-) @Danny: Bei mir funktioniert das mit der Parametrisierung ungefähr so: Ein Buskoppler besteht aus Software-Sicht aus 32 (30+1+1) virtuellen Modulen. Ein Modul ist dabei für genau eine Basisfunktion zuständig, z.B.: * einen Taster auswerten * 2 Jalousie-Relais ansteuern * eine Lampe schalten / dimmen * LCD (-Teilbereich) ansteuern Jedes Modul hat einen Parameterblock (module_parm, module_parm_typ). In diesem wird festgelegt, welche Funktion dieses Modul übernehmen soll (z.B. Jal.-Relais-Funktion), welche Hardware-Nummer angesprochen werden soll (z.B. Jal.-Relais 7 und 8) und auf welche CAN-Nachrichten reagiert bzw. welche verschickt werden sollen (max. 12 je Modul). Jeder Buskoppler kann also bis zu 30 unterschiedliche Aufgaben erfüllen: es ist möglich, gleichzeitig Taster auszuwerten, Relais anzusteuern und das LCD zu bedienen. Die Buskoppler-Basissoftware besteht aus einem Scheduler, der eingehende Nachrichten an die Module verteilt und gleichzeitig die Timerfunktionen verwaltet (eine Art Mini-Betriebssystem also). Eine Funktion (z.B. Jal.-Relais schalten) kann dadurch sehr einfach aufgebaut werden: * eine Init-Funktion * eine Message-Receive-Funktion * eine Timer-Funktion Der Parameter Hardware-Nummer (hw_nr) gibt dabei im Beispiel des Jal.Relais an, welche 2 Relais von diesem Modul benutzt werden. Nur diese werden initialisiert und im Weiteren auch angesprochen. Soweit erstmal, später mehr, viele Grüße, Stefan
Hallo, das ist alles sehr interessant, aber hat sich schon mal jemand Gedanken über den (Ruhe-)stromverbrauch der einzelenn Koppler sowie des gesamten Systems (incl. Nidervolt-Trafo) gemacht? Das ist ja heutzutage ein nicht unwesentlicher Punkt! Hardy
@Koopi: Bei der Widerstand/Kondensatormehtode muss man allerdings aufpassen: Denn wenn die Relais wärmer werden (davon kann man in einem Schaltschrank ausgehen), brauchen die deutlich höhere Spannungen damit sie noch zuverlässig halten. Unbedingt Relais-Datenblatt genau lesen! Die Temperaturabhängigkeit ist nicht zu verachten!
Aus Gründen des Stromverbrauchs betreibe ich meine Buskoppler übrigens bei 3,3V. Die CPU-Frequenz nur so hoch wählen, wie wirklich erforderlich, und als Regler einen mit niedrigem Eigenstromverbrauch wählen. Die Relais sind wirklich der größte Stromverbraucher. Bei den Jalousien ist es egal, die laufen eh fast nie, und die Lampen sollen mittelfristig mit Dimmern angesteuert werden. Gruß, Stefan
@stefan: 2 Fragen :) hast du schon geeignete dimmerhardware gefunden? ich möchte nämlich gern (rein aus versucherungsgründen etc...) geprüfte (zugelassene) dimmerhardware verwenden. dimmbare evg´s gibs ja... aber normale steuerbare dimmer hab ich noch nicht gefunden... hast du schon was im auge? oder willst diese selbst aufbauen? kannst du grob abschätzen wieviel % deiner knotensoftware die parametrierbarkeit ausmacht? übers parametrieren zerbrech ich mir grad den kopf, nur muss man ja (um alles nutzen zu können) eine ganze menge programmieren, was man nicht benötigt bzw. was nötig ist um den knoten parametrierbar zu machen auch überlege ich grad den sinn, da ja ein bootloader per can auch läuft (oder laufen kann)... und das beim neu flashen über den bus der knoten in dem moment nix tun kann is ja nebensächlich, ausgänge würden eh über die serielle porterweiterung gehalten...
@christian: danke für den Tip! aber... ich sehe keinen unterschied zwischen eigenbau und diesem conrad´zeug´s in bezug auf die VDE oder CE oder sonstiges... oder täusche ich mich? Ich habe nirgends entsprechende siegel gefunden, von daher kommen die leider auch nicht in betracht - wie gesagt... der eigenbau wär auch kein problem, aber aus versicherungstechnischer sicht o.ä. möchte ich für die schnittstelle bus/leistung geprüfte und zugelassene hardware nutzen...
Hallo Danny, genau das Problem habe ich auch - ich habe schon öfters gesucht, aber noch nichts brauchbares gefunden :-( ... als ich Dein Posting las, hatte ich schon insgeheim gehofft, DU hättest schon sowas gefunden. Das ist auch der Grund, warum die Lampen immer noch an (provisorisch installierten) Relais hängen und noch nicht dimmbar sind. Wenn ich nichts brauchbares finde, werde ich sie wohl doch noch selber aufbauen - immerhin: Dimmer bauen darf ich mit meinem Studium ja, nur nicht installieren ;-) Zur Parametrisierbarkeit: Die einzelnen Parameter der Module liegen im Moment in einer Tabelle - das Ändern der Parameter über den Bus habe ich noch nicht implementiert. Wieviel Platz mein Ansatz benötigt, kann ich so nicht sagen, ist bei mir aber auch keine Frage: ich benutze den mega16 bzw. mega32 und sehe keine Platzprobleme damit. Ohne die Fonts für das Graphikdisplay würde es sicher auch noch in 8kb reinpassen. Der mega16 war für mich die 1.Wahl wegen der jtag-Debugmöglichkeit. Die mega32 benutze ich für Buskoppler mit LCD, da ich dessen Inhalt im RAM komplett zwischenspeichere (LCD ist über SPI angebunden ohne Rücklesemöglichkeit der Graphikdaten). Übrigens, zum Thema Selbstbauplatinen: Bist Du sicher, Dir das antun zu wollen? Immerhin hast Du bei industriell gefertigten Platinen Stoplack drauf, und die Qualität ist eine ganz andere als die Selbstbauteile. Ich habe mir 50 Stück Buskopplerplatinen machen lassen und bin auf 3,80 pro Stück (+Mwst.) gekommen. Viele Grüße, Stefan
@stefan: zur programmgrösse... mir gehts es nicht drum es in einen kleineren µC quetschen zu wollen, sondern wie ich schon schrieb: ich habs mal durchgespielt und kam auf 40% eigentliches programm und 60% "overhead" für die parametrierbarkeit. (wenn dann würd ichs zu 100% machen und denn muß auch TWI, UART, kurzer Druck, langer Druck, eben alles mit rein...). und die parameter müsste ich eh über den bus laden, da kann ich auch gleich per bootloader neu flashen... meinungen? ihr seht schon, ich habe meine ansichten in bezug auf die programmierung ziemlich geändert (dank dieser diskussion, es ist dadurch einiges einfacher geworden g) zu den platinen... naja ich habe alles auf einer einseitigen Platine mit 0,3mm breiten leiterbahnen, ergebnis sieht sauber aus. lötstopplack wird aufgesprüht... eigentlich alles schön :) wo hast du denn die platinen machen lassen?
Also, man muss etwas in anderen Gefilden (EIB, DALI, DMX, ...) wildern, dann findet man z.B.: http://www.eib-home.de/se_lightmanagement_eib-4fach-dimmer.htm (Dazu habe ich auf einer anderen Webseite mal ein Preis gesehen und schnell wieder weggeklickt: rund 700,- Euro...)
@Dany P. > also würden meine hardwarefilter auch überflüssig bzw. bringen nicht > mehr so die dolle vereinfachung, kannst du das so bestätigen? kann ich bestätigen. > SolidStateRelais lieber wären als Standart-Relais Ich würde auf bewährte Technik setzen. Bei Rolläden z.B. garnicht gut, wenn die SSR-"Kontakte" "zusammenkleben" (Kurzschluß im Fehlerfalle). Außerdem gibt's keine UM-SSRs. Und wg. Stromverbrauch... es gibt auch bistabile Relais - damit kann dann das Netzteil wieder kleiner ausfallen, da der dauerhafte Haltestrom entfällt... oder einfach überlegen, ob das Relais längere Zeit eingeschaltet ist oder aus. Dann danach entsprechend das UM-Relais anschließen. @Unbekannter: > was die Relais verbrauchen, spielt ja nun wirklich eine > untergeordnete Rolle. [...] Denn wenn es angezogen ist, läuft da in > der Regel ein deutlich größerer Verbraucher mit. Naja, relativ betrachtet schon. Aber ob ich nun absolut 20EUR pro Jahr weniger Strom brauche oder nicht, macht schon einen Unterschied. @Dany P. > kann es sein das die parametrierbarkeit bei dir eine menge speicher > frisst? Hm, ob ich jetzt mit einem konstanten Wert für etwas arbeite oder ob ich etwas parametrierbar mache, ändert eigentlich nichts am Speicherverbrauch. Ob Konstante aus ROM, Variable ausm Eeprom oder aus RAM - das ist ziemlich egal. > aber in nem anderen fall soll das ein ausgang sein und ne led > steuern. und in noch nem anderen fall ein lcd... Du darfst halt nicht diskret den Code reinprogrammieren, sondern alle Fälle gleich behandeln (nämlich ein CanTelegramm versenden) und schon ist das Code dazu sehr kurz. Ob das CanTelegramm jetzt ein Ausgang, ne LED oder sonstwas schaltet ist ja egal. Prinzipiell hab ich das ja anders aufgezogen... mit dieser DataObjectTable. Das soll eine universelle Tabelle sein, in die alle Parameter, Größen usw. eingetragen werden und auf die lesend und schreibend über CAN zugegriffen werden kann - auch die Applikation liest und schreibt da rein. Somit ist der Applikation selbst egal, ob die Parameter von "innen", außen über CAN, oder Konstanten sind - sie kann und will es nicht unterscheiden. > knoten parametrierbar zu machen auch überlege ich grad den sinn, da > ja ein bootloader per can auch läuft Naja, ich will bei einer Umkonfiguration nicht den Compiler anfwerfen und neu flashen müssen, sondern das komfortable Konfigprogramm starten und die Umparametrierung mit der Maus vornehmen... > wo hast du denn die platinen machen lassen? privat und Prototypen bei mvpcb.de für die "Serie" dann bei multipcb.de (Gewerbeschein)
@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?
> es ist fürchterlich schwer meine gedanken dazu kurz aufzuschreiben > :) Na das ist doch nicht schlimm, dafür gibt's doch jetzt ein neues Forum hier :-)... speziell zum Thema Hausbus - da kannst du deinen Gedanken freien Lauf lassen... http://www.mikrocontroller.net/forum/list-11-1.html Andreas hat den Interessenten dieses Hausbus-Threads ein eigenes Unterforum eingerichtet. Dorthin gelangt man (vorläufig) aber nur über den angegebenen Link, also am besten ein Lesezeichen setzen. ............................................................... Es wäre schön, wenn die Diskussion dort weitergeführt werden könnte. Schauts euch einfach mal an (gehört ja schließlich auch zu mikrocontroller.net). ............................................................... @Danny P. Ich werde mal meine Antwort auf deinen letzten Beitrag dort posten.
Hallo, ich habe mir gerade den gesamten Thread ,mit großem Interesse, durchgelesen, und würde mich von daher eher als Noob bezeichnen. (wie Ralf so nett Ausgedrückt hat). Ich selbst habe ein ähnliches Projekt vor, und wollte mal fragen was ihr von dem Bussystem P-Net haltet? www.p-net.dk Unter diesem Link, findet ihr auch ein kleines Paper, welches den Bus kurz beschreibt. http://www.p-net.dk/download/590005.pdf
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).
"Das ist doch kommerziell!" - Stimmt so nicht, wenn du einmal die Woche den PC resetest, brauchst du dich nicht anmelden. Trotsdem Entschuldigung Andreas für Link. Ich suche aber noch eine Kopplung zum Fernsteuerungssystem FS20 von ELV, gibt es jemanden, den das beschäftigt?
Die vorherigen Beiträge habe ich mit Interesse gelesen, vielen Dank für die vielfältigen Anregungen. Habe in meinem Haus ein Bussystem seit über einem Jahr in Betrieb und baue es ständig weiter aus. 1-wire ist extrem kostengünstig. Busadapter ca 40 , Sensor 1,20 Aktor zur Ansteuerung einer LED auch 1,20 . Ein paar Bauteile incl. einem Relais, zur 220 V Anschaltung kosten ca 5 . Ja, es ist ein zentraler PC im Berieb. Wenn der ausfallen sollte, geht nichts mehr. Ist aber noch nicht vorgekommen und wenn, dann habe ich noch ein paar andere PC, die den Betrieb wieder aufnehmen können. An den PC bestehen keine besonderen Anforderungen. Ich kann mir nicht vorstellen, dass es einen PC gibt, der diesen Bus nicht steuern kann. Die Programmierung habe ich mit Visual Basic realisiert. Es gibt andere Ansteuerungsmöglichkeiten für den Bus aber für mich war das kein Thema, da ich ohnehin einen Server für viele andere Dinge(Videorekorder, Fotosammlung, MP3, Telefonarufüberwachung, FAX, Outlook-Server usw.) laufen habe. Den Bus macht der nebenbei. Es sind derzeit 30 Sensoren und 30 Aktoren in Betrieb (Rolläden, Lampen, Bewegungsmelder, Heizungs- und Pumpen- Betriebszeiten-Aufzeichnung usw.). Als Bus-Leitung habe ich (entgegen anderen Empfehlungen) alte vorhandene Telefonleitungen verwendet. Das Netz ist sternförmig angelegt. Alle Leitungsabschnitte zusammen erreichen sicher eine Länge von über 100 m. Es sind 3 Kabeladern beschaltet (Masse, Datenleitung und eine +12V zur Ansteuerung von Relais). Die Sensoren werden ca. 8 - 10 mal pro Sekunde abgefragt. Es ist daher keine Verzögerung beim Schalten festzustellen. Ich habe lange nach einer solchen Lösung gesucht und bin nun begeistert von dem sicheren, störungsfreien Betrieb. Günter Knöpfel
hi eigentlich sollte man ja hier weiterdiskutieren: http://www.mikrocontroller.net/forum/list-11-1.html egal, Günter kannst du vieleicht bitte die schaltpläne deiner buskoppler veröffentlichen?
Hallo Hannes, denke mit deiner Frage meinst du die Anschaltung der Sensoren und Aktoren an den Bus. Bei den Sensoren ist nichts weiter als ein Schalter oder besser Taster und der Busbaustein DS2401 erforderlich. Die Aktoren haben einen Ausgang der nur einige mA bringt, daher ist hier die Verstärkung eines Transistors angesagt. Ein kleines Beispiel der Schaltung habe ich als Anlage beigefügt. Ich hoffe, ich bin nicht der einzige, der Erfahrungen mit 1-Wire hat, würde mich sehr über Beiträge anderer User freuen. Gruß Günter
@Günter Also, um deine Anknüpfung zu ELV-Systemen noch mal auf zugreifen: www.ipsymcon.de und dann auch noch das Forum bietet das und noch viel mehr. Guckst du
Nachtrag dazu : Man braucht nur die Soft, 39 Euro, wenn man die ELV-Geräte nicht hat, weil die ser. Schnittstelle usw. unterstützt wird. Man braucht auch nicht die Prof.-Version bei FHT-Geräten,das funzt auch mit der einfachsten Version. Und die anderen Möglichkeiten sollte man mal schauen: ISDN Sprach Ansage Text sprechen lassen wenn ein Ereigniss stattgefunden hat.
@Günter Sorry, die Antwort galt Hansi Müller, aber 'ne Frage: Wie läuft den die Temperaturabfrage, über einen 1Wirer PC-Ankopplung am PC oder wie muss ich mir das vorstellen? Kann man fragen, wie aufwendig das PC-Programm ist, um ein Beispiel bitten?
Hallo stromi, Beispiele gibts hier, http://www.maxim-ic.com/products/ibutton/software/tmex/index.cfm Es bestehen verschiedene Möglichkeiten über unterschiedliche Treibersoftware und unterschiedliche Programmiersprachen. Ich habe mich für TMEX als Treiber und Visual Basic als Programmiersprache entschieden, weil ich damit ein wenig Erfahrung habe. Gruß Günter
Hallo Günter, ich interessiere mich für den 1-wire-bus, um damit meine Heizung zu steuern. Als Basis verwende ich den Webserver von Ulrich Radig auf der Hardware von Holger Buss. Das Projekt ist soweit gediehen, das ich die Temperaturen mehrerer DS1820 auf einer HTML-Seite ausgeben kann. http://www.mikrocontroller.net/forum/read-4-248219.html#new Das Einlesen eines Bits über das Zuschalten eines Seriennummernbausteins sorgt im Schaltaugenblick für Störungen auf dem Bus. Ich habe deshalb bisher davon Abstand genommen. Wie wirkt sich das Problem bei Dir aus? Gruß Joachim
Hallo Joachim, die ds1820 frage ich nur alle 30 sekunden ab. Die Sensoren ds2401 werden 8 mal pro Sekunde abgefragt. Störungen sind bei mir nur durch zu lange Leitungen bei weniger leistungsfähigen Busadaptern aufgetreten. Kann man im www was zu deinen Komponenten "Als Basis verwende ich den Webserver von Ulrich Radig auf der Hardware von Holger Buss" nachlesen? Gruß Günter
@Günter Und wie schliesse ich das Hardwaremässig an? Par. oder Ser.? Kann man den Adapter selbst bauen?
es ist ein serieller Busadapter "LINK 45 (from ibuttonlink.com) RS232-1-wire adapter from IButtonLink, Serial DB9/RJ45 connector, 300m range, with ID-Chip". Die Bauteile habe ich in Österreich bei http://shop.medhost.at/index.html?1-wire.htm eingekauft. Erst mit diesem Buskoppler habe ich eine angemessene Übertragungsqalität auf dem Bus erreicht. Mit einfacheren Busadaptern kam es insbesondere zu Fehlern bei der Statusabfrage der ds2405. Mit einfachen Selbstbaulösungen wäre ich sehr unsicher, ob die von mir genannten Anzahlen der Bauteile und Leitungslänge bei einer wie in meinem Bus sehr schlechten Leitungsqualität (alte Telefonleitungen, Flachband, Klingeldraht und in Abschnitten sogar Starkstomkabel NYM) zu erreichen sind. Gruß Günter
Hallo Günter, die Webserversoftware stammt von Ulrich Radig: http://www.ulrichradig.de/ Die Leiterplatte von Ulrich wird m. W. jedoch nicht zum Verkauf angeboten. Ich verwende deshalb die Leiterplatte von Holger Buss, die für 10 zugügl. 2 Versand erhältlich ist. http://www.mikrocontroller.com/ Bei der Leiterplattenbeschreibung ist auch eine angepaßte Version des Webservers erhältlich. Ich habe die Webserversoftware um ein one-wire-Interface erweitert. Damit kann ich drei Busleitungen gleichzeitig betreiben. Die Interfacebeschaltung ist nur ein Pullup-Widerstand am Controllerpin. Der Controller sorgt für einen aktiven Pullup, so daß ich gleichzeitig mehrere Thermometer die Temperaturumwandlung machen lassen kann. http://www.mikrocontroller.net/forum/read-4-248219.html#new Im Zip-File findest Du eine ausführliche Anleitung. Gruß Joachim
Hallo alle, habe einen Fehler in meinem obigen Schaltplan entdeckt. Hab mich über das Interesse gefreut und den plan etwas zu schnell gezeichnet. Dabei habe ich den Transistor mächtig falsch dargestellt. Nachgebaut hat ja wohl noch keiner, sonst hätte es bestimmt Proteste geregnet. Hier also nochmal die berichtigte Version. Gruß Günter
finde rs 485 am besten, da strombus und daher wenig störanfällig. meines wissens können bis zu 32 teilnehmer am draht hängen.
..hm..wenn ihr was von Haus-Elektro Installation wollt..kuckt mal die Lösungen von Moeller Easy..frei erweiterbar..über ein eAsy-link (2 adern, jYsty 2x2x0,6) kann ein zusatzgerät angeschlossen werden, dass etwa 30 meter entfernt ist...oder wen nGeld keine Rolle Spielt..eine eAsy 800er mit NET..also ziest Netzwerkleitungen zum verbinden..und evlt das ganze an dein Router/PC, wo du drauf zugreifen kannst, alles Beobachten kannst, und fernschalten und natürlich die anlage Umprogrammieren.. http://www.moeller.net/de/industry/switchgear/switch_control/easy/index.jsp#800
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.