Forum: Haus & Smart Home Hausbus


von Unbekannter (Gast)


Lesenswert?

@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.

von Busmaster (Gast)


Lesenswert?

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

von Unbekannter (Gast)


Lesenswert?

@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...

von Danny P. (Gast)


Lesenswert?

@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

von and_ref (Gast)


Lesenswert?

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.

von Volker (Gast)


Lesenswert?

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 :-)

von Danny. P (Gast)


Lesenswert?

@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?

von Unbekannter (Gast)


Lesenswert?

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...

von Neugieriger (Gast)


Lesenswert?

@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.

von Danny P. (Gast)


Lesenswert?

@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...

von and_ref (Gast)


Lesenswert?

@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.

von Koopi (Gast)


Lesenswert?

@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

von Danny P. (Gast)


Lesenswert?

@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....

von and_ref (Gast)


Lesenswert?

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...

von Danny P. (Gast)


Lesenswert?

@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)...

von and_ref (Gast)


Lesenswert?

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?

von Danny P. (Gast)


Lesenswert?

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...

von Koopi (Gast)


Lesenswert?

@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

von Danny P. (Gast)


Lesenswert?

@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?

von sparks (Gast)


Lesenswert?

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?

von Dumbo (Gast)


Lesenswert?

"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!

von Danny P. (Gast)


Lesenswert?

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...

von Unbekannter (Gast)


Lesenswert?

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.

von Koopi (Gast)


Lesenswert?

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

von Danny P. (Gast)


Lesenswert?

@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?

von Stefan Kleinwort (Gast)


Lesenswert?

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

von Hardy (Gast)


Lesenswert?

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

von Danny P. (Gast)


Lesenswert?

@hardy: hast du die postings 2 weiter oben nicht gelesen????

von Unbekannter (Gast)


Lesenswert?

@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!

von Stefan Kleinwort (Gast)


Lesenswert?

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

von Danny P. (Gast)


Lesenswert?

@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...

von Christian Wonschina (Gast)


Lesenswert?

bei conrad gibts welche um ca 50 eur,
ansteuerbar per i2c.

198369 i2c-leistungsdimmer

von Danny P. (Gast)


Lesenswert?

@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...

von Stefan Kleinwort (Gast)


Lesenswert?

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

von Danny P. (Gast)


Lesenswert?

@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?

von Unbekannter (Gast)


Lesenswert?

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...)

von and_ref (Gast)


Lesenswert?

@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)

von Danny P. (Gast)


Lesenswert?

@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?

von and_ref (Gast)


Lesenswert?

> 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.

von Radio (Gast)


Lesenswert?

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

von Hansi Müller (Gast)


Lesenswert?

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).

von Andreas (Gast)


Lesenswert?

Das ist doch kommerziell!

Hier geht es es um Hobby-Projekte...

von Hansi Müller (Gast)


Lesenswert?

"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?

von Günter Knöpfel (Gast)


Lesenswert?

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

von hannes (Gast)


Lesenswert?

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?

von Günter Knöpfel (Gast)


Angehängte Dateien:

Lesenswert?

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

von stromi (Gast)


Lesenswert?

@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

von stromi (Gast)


Lesenswert?

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.

von stromi (Gast)


Lesenswert?

@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?

von Günter Knöpfel (Gast)


Lesenswert?

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

von Joachim B. (joachimb)


Lesenswert?

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

von Günter Knöpfel (Gast)


Lesenswert?

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

von stromi (Gast)


Lesenswert?

@Günter
Und wie schliesse ich das Hardwaremässig an? Par. oder Ser.?
Kann man den Adapter selbst bauen?

von Günter Knöpfel (Gast)


Lesenswert?

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

von Joachim B. (joachimb)


Lesenswert?

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

von Günter Knöpfel (Gast)


Angehängte Dateien:

Lesenswert?

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

von henne (Gast)


Lesenswert?

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.

von AllesEaSy (Gast)


Lesenswert?

..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
Noch kein Account? Hier anmelden.