Dimmer für den Verteilerschrank mit Steuerinterface

[Max M. (maxmustermann)]

Guten Tag allerseits!

Ich überlege mir schon seit längerer Zeit ein paar Möglichkeiten zur 
Gebäudeautomatisierung und möchte hierbei möglichst fertige Komponenten 
auf der Netzspannungsebene verwenden, welche ich mit Niederspannung 
(z.B. einem Mikrocontroller) ansteuern kann (zwecks Sicherheit und 
Versicherung).

Ich suche nun nach einem Dimmer, welcher für die Hutschienenmontage 
geeignet ist und über ein Steuerinterface mit Niederspannung verfügt.

Ich habe mir den FIN 15.61 von Finder 
(http://www.finder.de/comuni/pdf/S15DE.pdf) angesehen, welcher über 
Tasterimpulse gesteuert werden kann. Zuerst habe ich mir gedacht, ich 
könnte die Tasterimpulse künstlich mit einem Relais erzeugen, jedoch ist 
es dann aber schwer den Helligkeitszustand zu ermitteln. Wird z.b. ein 
Tasterimpuls nicht erkannt, dann kommt sowieso alles durcheinander.

Hat jemand Erfahrung mit dem Thema und kann mir vielleicht eine 
geeignete Komponente vorschlagen? Sollte auch halbwegs günstig sein wenn 
möglich.

Vielen Dank!

lg Max

[Sven (Gast)]

Schonmal bei ELV geguckt ?

http://www.elv.de/Bus-Haussteuerungssystem/x.aspx/cid_74/detail_1/detail2_1771

[Max M. (maxmustermann)]

Hallo Sven,

Danke für den Hinweis! Werd mich da mal umschaun!

lg Max

[Timo E. (tien)]

Hallo Max,

ich hab bei mir die Dimmer von Eltako eingebaut. Es sind konventionelle, 
halbwegs bezahlbare Tastdimmer. Mir war wichtig, dass ich zum einen 
fertige Komponenten für die Netzspannungsteile verwende, zum anderen die 
Grundfunktionen auch ohne meine Steuerung(Bus) funktioniert. Deshalb 
habe ich die EUD12Z-UC Dimmer eingebaut.

Paralell zum Lichttaster wird der µC angeschlossen. Dieser soll den 
Dimmer per Impulsdauer steuern. Um den aktuellen Zustand zu erfassen 
soll der X1/X2 Anschluss genutzt werden. Dieser gibt eine Spannung von 0 
bis 10 Volt aus, leider nicht potentialgetrennt. Eventl. werde ich die 
Dimmer auch modifizieren und per Optokoppler direkt die Impulse der 
Mosfets nach aussen liefern. Dies hätte den Vorteil, dass man direkt per 
Portpin den aktuellen Zustand messen kann. Allerdings hätte es auch den 
Nachteil, dass man den Dimmer öffnen und modifizieren muss, was dem 
ersten Anspruch, nach fertigen Komponenten entgegensteht.

Wenn Du nur über den Bus steuern willst wäre eventl. eine 
Lasterweiterung interessant: LUD12-230V
Dieser treibt in abhängikeit der Eingangsspannung X1/X2 bis zu 400W. 
Wobei ich denke, dass X1/X2 nicht potentialfrei sind.

Ich habe mal bei Eltako angefragt, ob es nicht interessant wäre ein 
Dimmer mit einem einfachen Interface anzubieten. Eine Antwort war so in 
etwa: "...nehmen Sie unsere RS485-Bus Dimmer z.B. FUD12NPN-12V DC..."
Die sind tatsächlich sehr interessant, aber leider würde dann der zweite 
Ansatz, dass die Grundfunktionen auch ohne eigene Steuerung 
funktionieren nicht gehen, ausser man nimmt noch den FTS12EM-UC dazu, 
aber dann wirds halt langsam wieder teuer...

[Max M. (maxmustermann)]

Hallo Timo!

Danke! Das ist ja genau sowas das ich gesucht habe! Der  EUD12Z von 
Eltako scheint wirklich sehr gut geeignet zu sein. Mir ist nur noch 
nicht ganz klar, welche Impulse der Mosfets du meinst, die du mittels 
Optokoppler herausführen willst? Ist die spannung von 0-10V eine 
Gleispannung oder? Die zentralen Steuereingänge sind natürlich auch sehr 
toll!

Kennst du zufällig eine günstige Bezugsquelle für die Dinger?

Danke nochmals für den Hinweis!

lg Max

[Timo E. (tien)]

Hi Max,

> Mir ist nur noch nicht ganz klar, welche Impulse der Mosfets du meinst,
> die du mittels Optokoppler herausführen willst? Ist die spannung von
> 0-10V eine Gleispannung oder?

An den Anschlüßen X1/X2 liegt eine Spannung 0-10 Volt, proportional zur 
aktuellen Dimmstufe an. D.h. bei 100% -> 10V, bei 0% -> 0 Volt. Gemessen 
hab ich das allerdings noch nicht, könnte ich aber bei Bedarf machen.

Das ganze ist natürlich nicht sehr komfortabel per µC zu messen, was 
aber notwendig ist, um den Kreis (µC -> Impulslängen -> Dimmer -> 0-10V 
-> µC) zu schliessen. Wenn die Spannung potentialfrei wäre, könnte man 
das ganze einfach per ADC messen. Da aber X1/X2 potentialbehaftet ist 
und ich mit einem µC alle Dimmer, welche an unterschiedlichen Phasen 
hängen in der Lichtsteuerung abfragen will gibts da Probleme.

Eine Lösung könnte sein, einen analogen Optokoppler je Dimmer zu nehmen.
Die andere Lösung wäre eben die Schraubklemmen X1/X2 zu nutzen, aber 
intern die Verbindung zu kappen und dafür den Ausgang eines Optokoplers 
anzuschliesen. Der Eingang des Optokoplers würde dann paralell zum 
MOSFET hängen. Damit würde man ein digital auswertbares galv. getrenntes 
Signal bekommen welches den Zustand des MOSFETs entspricht. Aus der 
Pulsweite sollte sich die derzeit eingestellte Dimmstufe erkennen 
lassen.
Ich hoffe das war verständlich beschrieben :-)

Ich habe einen der Dimmer geöffnet und derzeit offen rumliegen, da kann 
ich Dir bei Bedarf auch ein paar Bilder senden. Im inneren befindet sich 
ausserdem ein PIC (oder war es ein AVR?, in jedem Fall ein stinknormaler 
µC). Allerdings ist die SW darin das entscheidende. Wenn man die SW 
ändern könnte wäre es natürlich perfekt, dann könnte man Zentral ein/aus 
Eingang zu einem seriellen Interface umbauen :-) Ohne Umbau zwar nur in 
Steuerrichtung, aber das würde ja für den Anfang reichen.
Wenn da jemand Lust hätte sich reinzuknien wäre ich mit dabei!
Allerdings ist der Teil der HW Ansteuerung für unterschiedliche 
Lampentypen bestimmt nicht trivial.

> Kennst du zufällig eine günstige Bezugsquelle für die Dinger?
Schau mal hier:
http://www.eibmarkt.com/cgi-bin/eibmarkt.storefront/4cbda2890039997a27464debae3906f0/Product/View/NS0660267

Mittlerweile würde ich wohl doch eher zu der Lösung
FUD12NPN-12V DC Dimmer mit FTS12EM-UC Taster-Eingabemodul tendieren. 
Damit könnte man bei aktiver Steuerung den RS485 Bus zwischen Dimmer und 
Eingabemodul trennen (z.B. mit zwei Bistabile Ralais) und die Dimmmer 
direkt steuern. Somit hätte man alle Möglichkeiten inkl. 
Mehrfachbelegung der Taster (z.B. Doppelklick), was ja mit meiner Lösung 
nicht geht. Allerdings müsste man zunächst den Bus mal abhören und 
herausfinden welche Codes verwendet werden.

Allerdings hab ich zu Hause bereits 10 EUD12Z-UC Dimmer und die wären 
dann ja umsonst gekauft, da fällt einem der Umstieg schwer :-)


Grüße Timo

[Max M. (maxmustermann)]

Hallo Timo,

Danke für die genaue Erklärung, jetzt weiß ich was du meinst :-).
Ich finde den Ansatz gut, die Installation möglichst einfach und 
zuverlässig zu machen und die Steuerung als extra Featurezu betrachten, 
welches man notfalls auch abschalten kann. Wäre ja blöd, wenn auf einmal 
gar nix mehr geht nur wegen einem Bug.

Wenn du mal ein bischen übrige Zeit hast wäre es sehr nett, wenn du ein 
paar Bilder vom Innenleben des Dimmers hier uploaden könntest!

Andere Frage: hast du dir vielleicht auch schon mal gedanken darüber 
gemacht, wie man eine Rollosteuerung automatisieren könnte? Auch hier 
gilt wieder, man sollte den Rollo per Schalter bedienen und zusätzlich 
auch via Mikrocontroller steuern können. Auch hier ist es glaub ich 
schwierig herauszufinden, wie der aktuelle Stand des Rollos ist. 
Vielleicht würde es auch reichen, per Mikrocontrolle nur die Zustände 
komplett offen und komplett zu zur Verfügung zu stellen.

lg Max

[Ein Gast (Gast)]

Interessantes Thema,

ich beschäftige mich auch gerade damit.

Jetzt hab ich mal ne Frage an die Eltako Spezialisten:
Wenn der EUD12Z tatsächlich 0-10V Proportional zum Dimmwert  an X1 und 
X2 liefert (ist das wirklich so, ich konnte das nicht eindeutig finden); 
der Leistungszusatz LUD12 wird von diesem X1 und X2 gesteuert. Dann 
sollte es doch möglich sein, einfach den LUD12 als Dimmer zu verwenden 
und mit nem µC -> DA-Wandler die 0-10V erzeugen (der DA-Wandler machrt 
zwar erst mal nur 0-5V oder so, das sollte aber mit ner kleinen 
Verstärkerschaltung anzupassen sein) und ich kann damit jedes Profil 
fahren oder auch direkt auf jeden Dimmwert schalten.

Ist das so oder mach ich nen Denkfehler.

[Max M. (maxmustermann)]

Hallo Gast,

ich habe es genau so verstanden und glaube auch dass du richtig liegst 
mit deinen Annahmen. der 0-10V Ausgang wird soviel ich weis bei 
elektronischen Vorschaltgeräten (EVGs) verwendet. Es sollte also möglich 
sein den Dimmer so beliebig anzusteuern. Was mir selber wichtig war ist, 
dass ich zusätzlich die Taster der Elektroinstallation nutzen kann. Wenn 
du aber das ganze sowieso nur per Mikrocontroller steuern willst, dann 
kannst du den LUD12 super verwenden.

Bitte korrigiert mich wenn ich was falsches gesagt habe :-)
Kenne die Dinger bisher nur theoretisch und vom Datenblatt her.

[Timo E. (tien)]

Hallo Ein Gast & Max,

genau, ich hab es zwar nicht selbst getestet, aber es sollte genau so 
gehen. Das ganze ist nur nicht so einfach, da Du immer daran denken 
musst, dass die 0-10 Volt nicht potenzialgetrennt sind. D.h. wenn Du 
die an Deine µC Schaltung anschliesst könnte auf Deiner Schaltung 
Netzpotential liegen, was wiederum sehr unangehem ist und mit Sicherheit 
auch nicht den Vorschriften entspricht. Das kann man mit isolierten 
DC/DC Wandlern umgehen. Aber die sind wieder relativ aufwendig und 
teuer. Wenn es sich um einen Dimmer handeln würde ok, aber ich habe 10 
und eventl. werden es noch ein paar mehr.

Ich würde wirklich zu der Lösung mit den FUD12NPN-12V DC Dimmer mit 
FTS12EM-UC Taster-Eingabemodul tendieren. Das erfüllt eigentlich alle 
Anforderungen. Die Installation ist ohne selbstgebauten Komponenten 
funktionsfähig. Mit einem einzigen Schalter oder ein Relais lässt sich 
der "konventionelle" Betriebszustand herstellen, indem man den RS485 Bus 
zwischen den FUD12NPN-12V Dimmern und dem FTS12EM-UC Eingabemodul 
verbindet und gleichzeitig den eigenen µC vom Bus nimmt. Es ist kein 
Eingriff in die Aktoren notwendig. Und entgegen was ich vorher schrieb 
ist es mit ca. 48 Euro pro Dimmer und ca. 45 Euro je Eingabemodul nicht 
extrem viel teuerer (Warum hab ich das nur nicht so gemacht? Eventl. 
gabs das vor einem Jahr noch nicht?).

zum Thema Rolladen:
Da hab ich leider nichts gefunden was halbwegs günstig ist und meinen 
Anforderungen entspricht. Ich denke ich werde es wohl mit einem Eigenbau 
realisieren. Es wird ein SSR mit einem Relais werden.
Schaut mal in diesen Thread:
Beitrag "elektr. Rolladenschalter"
Hier hat Robert eine Schaltung veröffentlich. (P.S. der Timo, der den 
Beitrag eröffnet hatte bin nicht ich)
Ich will versuchen die Drehzahl über den jeweils freien Motoranschluss 
und die darüber induzierte Spannung zu messen, es sollte eigentlich eine 
Wechselspannung messbar sein. Alternativ habe ich die Möglichkeit einen 
Reedschalter mit einem Magnet auf der Achse zu schalten. Dies ergibt ein 
Impuls pro Umdrehung, damit lässt sich dann recht genau die Position 
bestimmen.
Ich habe derzeit je Rolo einen Rolladentaster (Doppeltaster mit 
Veriegelung) direkt mit dem Motor verbunden, so wie das eben ganz 
klassisch gemacht wird. Der Taster steckt in einer Kaiser 
Elektronikdose, d.h. ich habe genügend Platz für die Elektronik. 
Weiterhin führt durch die Dose ein EIB Kabel (auf dem mein CAN und die 
Busbetriebsspannung laufen wird). Per Taster werde ich dann direkt in 
die Kontrollerschaltung reingehen. Der steuert dann den Rollo. Eine 
Möglichkeit wäre natürlich ein weiteres Relais zu verwenden um zwischen 
Taster und µC umzuschalten. Somit wäre das System auch wieder ohne Bus 
funktionsfähig. Hmmm, wäre ein Gedanke wert. Nächster Vorteil: das Ralis 
trennt die Selbstbauschaltung für die Zeit in der der Rollo nicht bewegt 
werden soll.

Grüße Timo

P.S. Bilder folgen...

[Max M. (maxmustermann)]

Hallo Timo,

also was ich jetzt so gelesen habe ist das Thema mit den Rollos doch 
nicht so einfach und kann durchaus knifflig sein. Interessant zu lesen, 
dass du wie ich auch den CAN Bus verwenden willst. Ich dachte mir ein 
CAT5 Kabel und einer Datenrate von 125kBit/s dürfte ein guter Ansatz 
sein. Wie schauen deine Überlegungen aus? Des weiteren dachte ich an das 
Mitführen einer 24V Versorgungsspanung, für was hast du dich 
entscheiden?
Außerdem: Ich experimentiere im Moment mit den MCP2505X CAN I/O Expander 
von Microchip 
(http://ww1.microchip.com/downloads/en/DeviceDoc/21664D.pdf). Diese 
finde ich sehr interessant um einfache I/O Funktionen wie GPIO, PWM oder 
ADC über CAN zu realisieren und man braucht nicht mal einen 
Mikrocontroller für den entsprechenden Node. Falls du dieses Bauteil 
noch nicht kennst kann ich dir nur empfehlen mal einen Blick ins 
Datenblatt zu werfen :-).

lg Max

[Timo E. (tien)]

Und hier ein paar Bilder. Entgegen meiner Aussage oben habe ich nicht 
den EUD12Z-UC sondern den EUD12M-UC, der kann noch keine LEDs dimmen.

Auf dem Bild EUD12M-UC_01.jpg ist sind rechts die Klemmen zu sehen, 
welche im eingebauten Zustand oben sind. Gut zu sehen sind die jeweils 
zwei Optokoppler unten rechts und oben rechts für die Eingänge. 
Ausserdem der µC, ein PIC 16F690 oben links/mitte. Unten links sind die 
zwei MOSFETS zu sehen (hinter den Widerständen)

Auf der Platinen Unterseite findet sich ein 4011er.


Platz für einen Optokoppler hätte es also noch :-)
Aber eigentlich will ich keine 10 Dimmer öffnen und umbauen :-(
Da ich aber aufgrund der anderen offenen Arbeiten eh erst nächstes Jahr 
dazu komme hab ich ja noch Zeit mir etwas zu überlegen.

Grüße Timo

[Timo E. (tien)]

Hi Max,

> also was ich jetzt so gelesen habe ist das Thema mit den Rollos doch
> nicht so einfach und kann durchaus knifflig sein.

Ja, aber ich denke mit der Schaltung von Robert hat man zwei Fliegen mit 
einer Klappe geschlagen - stabil durch das Relais und Kontaktschonend 
durch das SSR. Ich werde mal die Schaltung aufbauen und an einem Rolo 
testen, der noch ein offenes Kabel hat, dann sind Änderungen recht 
einfach und man kann auch mal das Oszi ranhängen.

> Interessant zu lesen,
> dass du wie ich auch den CAN Bus verwenden willst.

Ja, CAN ist gesetzt, da er recht ideal für die Anwendung ist und ich 
beruflich damit genügend zu tun hab (Kfz Steuergeräteentwicklung).

> Ich dachte mir ein
> CAT5 Kabel und einer Datenrate von 125kBit/s dürfte ein guter Ansatz
> sein. Wie schauen deine Überlegungen aus?

Elektrisch gesehen ist CAT natürlich ideal.
Ich nutze allerdings EIB Leitung. Das hat zum einen den Grund, dass es 
zugelassen ist es direkt neben 230V Netzleitung zu installieren, zum 
anderen könnte man dann auch im Fall eines Falles auf EIB/KNX umsatteln 
(z.B. beim Verkauf des Haueses). Das ist zwar technisch genauso bei CAT 
möglich, aber ein Elektriker wird das eher ungern machen, da ja nicht 
100% zulässig.
Ein weiterer Grung gegen CAT war, dass die Leitung selbst recht 
unflexibel ist, die Adern hingegen recht dünn sind (IMO 0,6mm²). Die EIB 
Leitung ist mechanisch recht problemlos. Sie liegt in jeder 
Dose/Dosenkombination bei mir im ganzen Haus. Min eine Dose je 
Kombination ist eine Kaiser Elektronikdose. Die EIB Leitung geht von 
Dose zu Dose, d.h. ein echter Bus. Je Stockwerk geht die Leitung in den 
Keller an einen Zentralen Punkt.
Ich will auch um die 125kBit/s fahren, im Normalbetrieb dürften es auch 
weniger sein, nur der Download per CAN Bootloader dauert dann halt recht 
lange.

> Des weiteren dachte ich an das
> Mitführen einer 24V Versorgungsspanung, für was hast du dich
> entscheiden?
Ebenso! Eines der beiden 24Volt Schaltnetzteile ist schon eingebaut :-)
Lokal wird dann per Schaltregler auf die erforderl. Spannungen 
heruntergeregelt.

> Außerdem: Ich experimentiere im Moment mit den MCP2505X CAN I/O Expander
> von Microchip
> (http://ww1.microchip.com/downloads/en/DeviceDoc/21664D.pdf). Diese
> finde ich sehr interessant um einfache I/O Funktionen wie GPIO, PWM oder
> ADC über CAN zu realisieren und man braucht nicht mal einen
> Mikrocontroller für den entsprechenden Node. Falls du dieses Bauteil
> noch nicht kennst kann ich dir nur empfehlen mal einen Blick ins
> Datenblatt zu werfen :-).

Sieht spannend aus. Ich werde mir das morgen mal anschauen. Ich werde 
aber vermutlich überall den gleichen Controller inkl. gleicher SW 
einsetzen, das macht die Sache übersichtlicher. Ich habe mich für PIC 
18F entschieden. Eigentlich bin/war ich ein AVR Liebhaber, aber der PIC 
hat eben was Peripherie angeht speziell bei den kleineren Gehäusen mehr 
Auswahl. So bekommt man einen PIC inkl. CAN Controller bereits in SMD 
Bauformen mit wenig Pins (40?). Dazu hab ich mir vor einiger Zeit das 
EasyPIC5 von MikroE inkl. den C-Compiler gegönnt.

Heute habe ich (endlich) angefangen mit dem EasyPIC zu arbeiten 
(Entwicklungsumgebung installiert und ein paar Demoprogramme getestet). 
In den letzten Monaten habe ich mich ausschließlich mit Werkzeugen der 
härteren Art abgegeben, d.h mit Schlagbohrern, Akkuschrauber, Kreisäge 
usw... :-)
Leider sind noch zu viele Baustellen (Brennholzhütte, Garten, 
Dachgeschoß, usw...) offen, so dass ich mich nicht dauerhaft mit dem 
Thema beschäftigen kann. Allerdings will ich nach und nach eine 
Basisplatine entwickeln (µC, CAN, Schaltregler) auf die dann die 
jeweilige Ergänzung aufgesteckt werden kann. Softwaretechnische 
Voraussetzung ist ein Bootloader für CAN, da ich nicht jedesmal die 
Schalterdosen aufschrauben will :-) Und genau das habe ich mir für die 
nächsten Wochen vorgenommen - mal sehen...

Wie weit ist Dein Vorhaben?


Grüße Timo

[Christian B. (luckyfu)]

Zum Rollo kann ich auch was beitragen:

Ich hab es so gelöst (bzw bin noch dabei):
Die Rolladen werden via 2 normaler Taster gesteuert. Diese Taster 
arbeiten mit meiner Steuerspannung von 12V und sind direkt in die 
Unterverteilung gelegt. Dort hab ich ein kleines Hutschienengehäuse 
welches 6 1xUM Relais beherbergt (ich hab 3 Rolläden) Jeder Taster 
steuert einen Rolladen, ausserdem gibt es einen mit Dioden ver-oderten 
Masterschalter mit dem ich alle Rollos gleichzeitig auf und zu fahren 
kann. Die Rolladen sind dann von diesem Kasten mittels 5x 1,5mm² 
angefahren. Ich hab die Relais dabei so verdrahtet, daß sie eine 
Vorzugsrichtung haben, d.h. wenn beide Taster gleicheitig gedrückt 
werden fährt der Rolladen hoch. Somit ist sichergestellt, daß nicht 
beide Richtungen gleichzeitig bestromt werden.

Die Rückmeldung (daran arbeite ich derzeit noch) wird so aussehen: 
Mittels 2 Gabellichtschranken werde ich eine modifizierte Gurtscheibe 
(mit Schlitzen darin) (Bei meinem Rolladen sind auf beiden Seiten der 
Welle Gurtscheiben montiert, sodaß nach Rohrmotornachrüstung eine noch 
als Widerlager aktiv ist aber ohne Gurt) auslesen und dann via I²C an 
den Hauptcontroller die aktuelle Höhe des Rolladens melden (Ausserdem 
wird der I"C Controller noch die Fenstersensoren abfragen sowie die 
Helligkeit mittels Sensor aufnehmen und dann als Paket an den 
Hauptcontroller senden. Ich hoffe, daß ich so auf mindestens 5cm 
Auflösung komme. Wobei diese nur von der Anzahl und Breite der Schlitze 
abhängt. Eine gewisse Mindestbreite brauche ich aber für die 
Drehrichtungserkennung (Deshalb auch 2 Lichtschranken), da die ja der 
Sensor- wie auch der Hauptcontroller nicht kennt wenn jmd einen Taster 
drückt.

[Ein Gast (Gast)]

Hi Timo,

Timo E. schrieb:
> da Du immer daran denken
> musst, dass die 0-10 Volt nicht potenzialgetrennt sind.
Das wäre jetzt meine nächste Frage gewesen.

> Ich würde wirklich zu der Lösung mit den FUD12NPN-12V DC Dimmer mit
> FTS12EM-UC Taster-Eingabemodul tendieren. Das erfüllt eigentlich alle
> Anforderungen. Die Installation ist ohne selbstgebauten Komponenten
> funktionsfähig. Mit einem einzigen Schalter oder ein Relais lässt sich
> der "konventionelle" Betriebszustand herstellen, indem man den RS485 Bus
> zwischen den FUD12NPN-12V Dimmern und dem FTS12EM-UC Eingabemodul
> verbindet und gleichzeitig den eigenen µC vom Bus nimmt.

Den Gedanken habe ich auch gerade, aber:
- Ist der RS485 Potentialgetrennt (das lässt sich aber auch selbst noch 
bewerkstelligen)?
- Kennst Du das Protokoll und die Befehle, die hier über den Bus gehen 
um Dimmer bzw. weitere Aktoren zu steuern? Ich hab mal etwas auf der 
Etalko-Seite gesucht aber nichts gefunden.

[Timo E. (tien)]

Hi Christian,

> Die Rolladen sind dann von diesem Kasten mittels 5x 1,5mm² angefahren.
Das war einer der Gründe warum ich das nicht so machen wollte bzw. 
konnte. Ich habe einen Bestandsbau gekauft und teilw. umgebaut. Leider 
war die bisherige Verteilung nich im Keller und daher war der Platz 
begrenzt. Daher habe ich die Lösung mit den Kaiser Elektronikdosen 
gewählt. Aber letztlich ist das ja egal wo die Relais sind.

> Ich hab die Relais dabei so verdrahtet, daß sie eine
> Vorzugsrichtung haben, d.h. wenn beide Taster gleicheitig gedrückt
> werden fährt der Rolladen hoch. Somit ist sichergestellt, daß nicht
> beide Richtungen gleichzeitig bestromt werden.

Genau, das wird mit der bei mir irgendwann eingesetzten Schaltung 
genauso erfolgen, allerdings statt 2 Relais pro Rolladen ein Relais und 
ein SSR.

> Die Rückmeldung (daran arbeite ich derzeit noch) wird so aussehen:
> Mittels 2 Gabellichtschranken werde ich eine modifizierte Gurtscheibe

Das hat seine Vorteile, weil Du mehr Impulse pro Umdrehung bekommst. 
Aber denk daran, dass in so einem Rollokasten ausser dem normalen Staub 
auch noch nette Tierchen (Spinnen usw.) wohnen. Ich vermute Deine 
Lichtschranken werden nach ein paar Jahren nicht mehr ordentlich laufen.
Für mich scheint die Reedrelais Lösung die stabilere Lösung zu sein. 
Ausserdem benötigt diese Lösung keine zusätzliche Elektronik sonder kann 
direkt an einen µC oder ähnl. angeschlossen werden.
Wenn Du dann zwei oder drei Magnete an die Gurtscheibe klebst bekommst 
Du ja schon einige Impulse pro Umdrehung. Da jede Umdrehung eh eine 
unterschiedliche Entfernung darstellt (da der Umfang ja weniger wird je 
weiter unten der Rollo ist) muss man im µC eh eine "Umrechnung" 
vorsehen. Eine Zeitmessung vom letzten Impuls ausgehend sollte 
hinreichend genau sein um die Position gut zu ermitteln.

> Eine gewisse Mindestbreite brauche ich aber für die
> Drehrichtungserkennung (Deshalb auch 2 Lichtschranken), da die ja der
> Sensor- wie auch der Hauptcontroller nicht kennt wenn jmd einen Taster
> drückt.

Das ist mir nicht ganz klar. Die Steuerung könnte doch die Relais 
überwachen? Damit hast Du immer die Drehrichtung und die Dauer. Somit 
könntest Du Dir eine Drehrichtungserkennung sparen. Und wenn Du von 
einer Referenz ausgehst (unten oder oben) und die Umdrehungen zählst und 
die Zeit seit dem letztem Impuls misst kannst Du die Position recht 
genau ermitteln. Sinnvoll ist es beim kompletten Hochfahren bzw. 
kompletten Runterfahren den Motor länger anzusteuern bis der Enschalter 
aktiv ist, Du also für die Zeit von mind. einer Umdrehung keine 
Impulse mehr bekommst. Damit ist die Endlage wieder referenziert.

Ich bin gespannt, was meine Versuche die Induzierte Spannung der zweiten 
Wicklung zu messen. Eventl. kann man sich die ganze Sensorik sparen, da 
man erkennen sollte ob der Rollo sich dreht und wenn ja wie schnell. Ich 
denke eine reine Zeitmessung von den Endanschlägen sollte auch 
ausreichen. Die Reedschalter stellen für mich eigentlich nur eine 
Fallbacklösung dar, wenn die Rückmessung der Spannung nicht so 
funktioniert wie ich mir das vorstelle.

Grüße Timo

[Christian B. (luckyfu)]

Timo E. schrieb:
> Das ist mir nicht ganz klar. Die Steuerung könnte doch die Relais
> überwachen? Damit hast Du immer die Drehrichtung und die Dauer. Somit

Ja, dann müsste ich aber breitere Relais mit 2x UM einsetzen.
Momentan hab ich aus Platzgründen ganz schmale 1xUM verbaut (ca 5mm 
breit) sodaß das noch in annehmbaren Grenzen einbaubar ist. Prinzipiell 
hast du recht, somit ist das bei mir auch nurmehr ein Kompromiss.

Bzgl der Lichtschranken sehe ich keine Probleme, ich will ja 
Gabellichtschranken verwenden, sodaß der "Luftspalt" zwischen 
Gabellichtschranke und Gurtscheibe möglichst klein ist. Reed Kontakte 
sind auch eine Option, die sich vermutlich leichter realisieren lassen. 
Einfach aus dem Grund, daß man Magnete leichter gleich über die Scheibe 
verteilt aufkleben kann als man schlitze ohne Maschinen hinbekommt. Das 
muss ich mir noch überlegen, am Ende bleibt die Auswertung ja gleich, 
nur invertiert.

Ich könnte die Lichtschranken auch jetzt schon direkt auslesen, aber da 
ich "nur" ein 4x0,6mm² am Rolladenkasten anliegen habe gehen mir die 
Adern aus bei den Funktionen die ich gern hätte. daher der Controller 
der nur als "Portexpander mit Zusatzfunktionen" wirkt. So soll er den 
Absolutstand des Rollos auf Anfrage abgeben, eine Auflösung von max 8bit 
reicht hier vollkommen aus, evtl schon 6 bit. Weiters soll er die beiden 
Fensterkontakte prüfen (für eine rudimentäre Alarmanlage) und eben die 
Helligkeit messen, sodaß im Zweifel bei zu starker Sonneneinstrahlung 
das Rollo automatisch herunterfährt.

Die Endlage will ich mit dem Absolutwert angeben weil ich Rohrmotoren 
habe die bei einem Hinderniss abschalten. Sind sie jedoch so gestoppt 
muss erst die Endlage in entgegengesetzter Richtung erreicht werden 
bevor er wieder in die vorherige Richtung fahren kann. Somit sehe ich 
einen Absolutwert als sinnvoller an als eine reine "Aktivitätsangabe"
Mir ist klar, daß ich nach einem Stromausfall nat. im Zweifelsfalle 
nicht konsistente Werte erhalte, daß kann man aber mit einer einfachen 
Justierfahrt in die Endlage beheben. Da Hauptcontroller und "Satteliten" 
am selben Stromnetz hängen sind sie auch alle gleichzeitig down, hoffe 
ich :)

bzgl Messung: Das sehe ich als problematischer an, mit externen sensoren 
hat man permanent eine Galvanische Entkopplung der Steuerung von den 
gesteuerten Lasten, welche du dadurch ja aufgeben musst. Somit holst du 
dir evtl. unerwünschte Störungen in deine Steuerung.

Ich finde, wenn man die Möglichkeit des Sensoreinbaus hat ist die 
Vorzuziehen da sie störunempfindlicher reagiert.



p.s: evtl kann man sogar einen Hall Sensor nehmen der die "Kanten" der 
Rolladenwelle detektiert. Aber ich glaube, daß eine dafür notwendige 
Feinjustierung wohl etwas übers Ziel hinausschießt. Evtl ist auch ein 
einfacher Incrementalgeber möglich. Wenn man dazu mittels kleinem 
Getriebe einen Spindeltrimmer o.ä. verwendet häte man sogar eine 
Absolutwertmessung unabhängig vom Stromnetz. Aber das sind reine 
Gedankenexperimente. Ich denke, ich werde wohl auch die 
Reedkontaktversion adaptieren, aber vorher mach ich einen Test, ob sich 
damit die Drehrichtung sicher detektieren lässt und die von mir 
gewünschte Auflösung erreichbar ist.

p.p.s: Die Umfangreduzierung beim Auf-/Abrollen habe ich eigentlich vor 
zu ignorieren :) Ich nehme das als Linear an g

[Timo E. (tien)]

Hi Christian

> Timo E. schrieb:
>> Das ist mir nicht ganz klar. Die Steuerung könnte doch die Relais
>> überwachen? Damit hast Du immer die Drehrichtung und die Dauer. Somit
>
> Ja, dann müsste ich aber breitere Relais mit 2x UM einsetzen.
> Momentan hab ich aus Platzgründen ganz schmale 1xUM verbaut (ca 5mm
> breit) sodaß das noch in annehmbaren Grenzen einbaubar ist. Prinzipiell
> hast du recht, somit ist das bei mir auch nurmehr ein Kompromiss.

Du steuerst doch die Relais mit 12V an, oder? Somit könntest Du mit 
einem einfachen Spannungsteiler direkt in den µC. Wenn notwenig kannst 
Du auch ein Optokoppler verwenden.

> Bzgl der Lichtschranken sehe ich keine Probleme, ich will ja
> Gabellichtschranken verwenden, sodaß der "Luftspalt" zwischen
> Gabellichtschranke und Gurtscheibe möglichst klein ist.

Falls Du es umsetzen tust, wäre ich über eine Langzeiterfahrung von Dir 
dankbar.

> Die Endlage will ich mit dem Absolutwert angeben weil ich Rohrmotoren
> habe die bei einem Hinderniss abschalten. Sind sie jedoch so gestoppt
> muss erst die Endlage in entgegengesetzter Richtung erreicht werden
> bevor er wieder in die vorherige Richtung fahren kann. Somit sehe ich
> einen Absolutwert als sinnvoller an als eine reine "Aktivitätsangabe"

Naja, Du weißt ja im Normalbetrieb ohne Störung wo Dein Rollo ist bzw. 
wieviele Impulse zur Endlage noch fehlen. Wenn der Rollo also 
ausserplanmäßig anhält erkennst Du das ja daran, das der nächste 
erwartete Impuls ausbleibt, somit ist der Fall abgedeckt. Und wenn Du 
den Magneten so aufklebst, das er genau in der Endlage den Reed 
dauerhaft aktiviert hättest Du eine recht genaue Kontrolle der Endlage.

> Mir ist klar, daß ich nach einem Stromausfall nat. im Zweifelsfalle
> nicht konsistente Werte erhalte, daß kann man aber mit einer einfachen
> Justierfahrt in die Endlage beheben. Da Hauptcontroller und "Satteliten"
> am selben Stromnetz hängen sind sie auch alle gleichzeitig down, hoffe
> ich :)

Genau, ist ja bei meinem Prinzip genauso.

> bzgl Messung: Das sehe ich als problematischer an, mit externen sensoren
> hat man permanent eine Galvanische Entkopplung der Steuerung von den
> gesteuerten Lasten, welche du dadurch ja aufgeben musst. Somit holst du
> dir evtl. unerwünschte Störungen in deine Steuerung.

Naja, ich hätte das Signal auf Hochspannungseite so aufbereitet, dass 
ich ein "digitales" Signal über einen Optokoppler zum µC führen kann. 
Das ist dann nicht mehr galv. gekoppelt und macht daher keine Probleme. 
Aber ob das geht steht noch in den Sternen.

> Ich finde, wenn man die Möglichkeit des Sensoreinbaus hat ist die
> Vorzuziehen da sie störunempfindlicher reagiert.

Ja, der Sensoreinbau ist sicherlich gut, wenn man den Mehraufwand nicht 
betrachtet. Ich hab halt 10 Rollos, da will ich den Aufwand so gering 
wie möglich halten. Was mich aber beim direkten Messen reizt ist der 
Gewinn an weiteren Infos. z.B. kann ich damit das Nachlaufen des Rollos 
feststellen. Ok, könnte man ja leicht auch über eine Zeitkonstante 
machen. Aber auch das ausserplanmäßige Anhalten würde man sofort 
erkennen. Meine Rollomotoren haben z.B. keine Abschaltung und so läuft 
der Motor bei einem Hindernis einfach weiter. Das würde ich per Reed 
Relais max. nach einer Umdrehung merken (je nach Anzahl der Magnete). 
Aber mit der direkten Methode sofort. Naja, ist vielleich auch nur der 
Reiz sowas mal zu versuchen...

> p.s: evtl kann man sogar einen Hall Sensor nehmen der die "Kanten" der
> Rolladenwelle detektiert. Aber ich glaube, daß eine dafür notwendige
> Feinjustierung wohl etwas übers Ziel hinausschießt. Evtl ist auch ein
> einfacher Incrementalgeber möglich. Wenn man dazu mittels kleinem
> Getriebe einen Spindeltrimmer o.ä. verwendet häte man sogar eine
> Absolutwertmessung unabhängig vom Stromnetz. Aber das sind reine
> Gedankenexperimente.

Egal, Gedankenexperimente sind immer gut, die Abwägung der optimalen 
Lösung ist dann eine andere Sache. Man könnte auch eine Art Barcode am 
Rollo anbringen und diesen scannen :-) Je Lamelle ein Kleber, der beim 
Fahren von einer Reflexlichtschranke abgetastet wird. Aber auch hier 
denke ich, dass man nach 5-10 Jahren mit Verschmutzung Probleme bekommt.

> Ich denke, ich werde wohl auch die
> Reedkontaktversion adaptieren, aber vorher mach ich einen Test, ob sich
> damit die Drehrichtung sicher detektieren lässt und die von mir
> gewünschte Auflösung erreichbar ist.

Wenn Du zwei Reedkontakten nimmst solltest Du ja ebenfalls die 
Drehrichtung erkennen können, solange die Empfindlichkeit und 
Ausrichtung der Reeds in etwa gleich sind sollte der erste Kontakt auch 
als erstes geschlossen werden.
Aber wie gesagt, ich sehe dies als nicht notwendig an, da Du ja die 
Relais bzw. die Taster überwachen kannst. Das hätte auch den Vorteil, 
dass Du am lokalen Taster eine zusätzliche Komfortfunktion realisieren 
kannst: Drückt der Nutzer z.B. für mehr als 5 Sekunden drauf übernimmt 
der Controller die Ansteuerung der Relais und fährt den Rolladen bis in 
Endlage, es sei den der Nutzer drückt vorher auf die Taste mit der 
entgegengesetzten Richtung. Das könnte den Lauf dann stoppen, bzw. die 
Kontrolle wieder an den Nutzer abgeben. Mit je einer Diode pro Taster 
hast Du ja Taster und Relais entkoppelt und kannst die Tasterbetätigung 
messen unabhängig von der Relaisstellung.

> p.p.s: Die Umfangreduzierung beim Auf-/Abrollen habe ich eigentlich vor
> zu ignorieren :) Ich nehme das als Linear an *g*
Naja, man kann ja in Anzahl Umdrehungen rechnen, dann ist das Linear :-)

Grüße Timo

[Timo E. (tien)]

Aber eigentlich ist das OT :-)
Mir ist das ja wurscht, da auch interessant...

[Max M. (maxmustermann)]

Hallo Timo,

vielen Dank für die Fotos! Ja, ich hab früher auch nur AVRs 
programmiert, aber da die PICs einen integrierten CAN Controller haben 
verwende ich in diesem Zusammenhang nur mehr diese und hab schon einiges 
mit den Dingern angestellt. Verwende auch den PIC18F und hab mir dazu 
einen PICKit2 Programmr dazu gebaut (der kann nämlich auch die I/O 
Expander programmieren). Ich hab mich mit dem Thema 
Gebäudeautomatisierung vor einigen Jahren schon bechäftigt und das ganze 
ist nun wieder aktuell geworden, da meine Schwester dabei ist ein Haus 
zu bauen und mich als Elektrotechnik Student dazu befragt hat, was man 
da tolles machen könnte. Deshalb möchte ich das Ganze auch möglichst 
ausfallsicher machen und sehe die Steuerung als Zusatzfeature. D.h. 
Licht sollte auch bei Ausfall des Busses funktionieren. D.h. ich brauche 
so gesehen keinen Bus bei den Tastern sondern möchte alles im 
Verteilerkasten machen wo ja auch die Hauptsteuerung sitzt. Ich möchte 
ebenfalls auch die Fenster per Reedkontak überwachen sowie den Rollo 
steuern. Ich sehe die ganze Arbeit und Entwicklung als eine Investition 
in die Automatisierung bei meinem zukünftigen Haus :-). Ich wollte mir 
auch deshalb mal einen kleinen Verteilerkasten und die wichtigsten 
Komponenten (Dimmer, Stromstoßschalter etc) bestellen um das ganze auch 
mal in etwa  aufzubauen und Erfahrung zu sammeln. Finde es deshalb sehr 
interessant Erfahrungsberichte von allen die sowas schon mal gemacht 
haben zu lesen.

Für welche Aufgaben hast du alles einen Node Vorgesehen? Hast du das EIB 
Kabel durch alle Stockwerke geschleift oder hast du jeweils eine 
Steuerung pro Stockwerk geplant?

Zum Thema verdrahtung des EIB Kabels habe ich immer wieder von den Wago 
Klemmen gelesen, was verwendest du um die Kabel mit einem Node zu 
verbinden?

Hoffe das sind dir nich zu viele Fragen ;-)

lg Max

[Christian B. (luckyfu)]

Barcode am Rollo... das könnte man Manchastercodieren und hätte somit 
auch einen digitalen Absolutwert.

Die Relais überwachen wollte ich nicht, da war ich wohl insofern 
blockiert, als daß ich davon ausging zwingend Rückmeldekontakte zu 
benötigen, aber ich kann ja einfach die Spuleneingänge mit parallel auf 
meine Optokoppler legen. Soweit sogut.

Diese von dir genannten Komfortfunktionen wollte ich realisieren, 
allerdings hoffte ich es über das Rollo selbst hinzubekommen, bei 
genügend hoher Auflösung (256 Werte sind ja angestrebt als Maximum) ist 
es eigentlich egal, ob ich die Dauer des Tastendrucks am Relais messe 
oder nur messe, daß das Rollo meinethalben 5cm gefahren ist und dann 
kurze Zeit später nochmal 2cm. So könnte man es auch codieren. Die Zeit 
des Tastendrucks ist ja in diesem Fall wirklich linear zur 
Wellenumdrehung.

@Max
eine redundante Steuerung hat durchaus ihren Reiz, die Vorteile 
überwiegen bei mir auch und speziell beim Selbstbaubastelbus ist das 
meines Erachtens noch das Sinnvollste. Hat der Erbauer keine Lust mehr 
oder kann nicht mehr daran herumbauen und tritt dann ein Fehler auf kann 
man die Automation einfach abschalten und hat nur einen Komfortverlust, 
daß Gebäude ist aber weiterhin uneingeschränkt nutzbar. Bastelt man sich 
selbt einen Bus und irgendwas geht schief... nunja, darüber brauchen wir 
nicht philosophieren.

Was allerdings meine Erfahrung ist: beachte, daß du jede Menge Platz 
brauchst! Ich habe das anfangs komplett unterschätzt und so zwar eine UV 
je Stockwerk geplant, allerdings sind diese schlussendlich viel größer 
geworden als Geplant und haben weniger Funktionen, da alle gewünschten 
Funktionen zu viel Platz in Anspruch genommen hätten. Auf Dimmer habe 
ich z.B. komplett verzichtet. Aber vermutlich könnte ich sie Nachrüsten, 
da die Elektrik bei mir auf Stromstoßschaltern für die Hutschiene 
basiert. Ich hab somit im EG einen doppel Verteiler, 2x3 Reihen. Der 
linke Verteiler ist mit FI und LSS bestückt und der Rechte enthält die 
SSS, das Rolladensteuermodul und den Controller. (d.h. da soll er dieses 
Jahr noch hin, ich will nur mit dem Platinenbestellen solange wie 
möglich warten, damit evtl. notwendige Änderungen noch einfließen 
können) Selbst bei diesem durchaus Üppig erscheinenden Platzangebot hab 
ich Funktionen herausstreichen müssen weil es eben nicht genug Platz 
gibt um wirklich jede Steckdose einzeln abschalten zu können.

Ich für meinen Teil habe das gehörig unterschätzt und das böse Erwachen 
kam dann beim Beginn der Verdrahtung als ich den Berg an LSS und FI 
sowie SSS vor mir liegen sah.

[Max M. (maxmustermann)]

Hallo Christian,

ja das glaub ich dir, dass diese Dinge viel Platz benötigen. Mann muss 
sich vorher genau überlegen was wäre toll und was braucht man wirklich. 
Für was würdest du z.B. eine schaltbare Steckdose verwenden? Und ja, 
jede Lampe im Haus muss auch nicht schaltbar und schon gar nicht dimmbar 
sein. ICh glaube in meinem Fall ist es am besten das Wesentliche 
steuerbar zu machen. Nachrüsten kann man ja immer noch. Aud der einen 
Seite ist es gut alles zentral in einem Verteilerkasten zu machen, 
jedoch auf der anderen Seite wäre ein Verteilerkasten pro Stockwerk viel 
übersichtlich und man hätte auch nicht so lange Stromkabel. Immer diese 
Vor- und Nachteile :-)

sg Max

[Timo E. (tien)]

Hi Christian,

> Diese von dir genannten Komfortfunktionen wollte ich realisieren,
> ...
> kurze Zeit später nochmal 2cm. So könnte man es auch codieren. Die Zeit

Ja, ist natürlich auch möglich :-)

> eine redundante Steuerung hat durchaus ihren Reiz, die Vorteile
> überwiegen bei mir auch und speziell beim Selbstbaubastelbus ist das
> ...
> selbt einen Bus und irgendwas geht schief... nunja, darüber brauchen wir
> nicht philosophieren.

Ich sehe schon, wir 3 ticken genauso :-)

> Was allerdings meine Erfahrung ist: beachte, daß du jede Menge Platz
> brauchst!

Definitiv!

> Ich hab somit im EG einen doppel Verteiler, 2x3 Reihen. Der
> linke Verteiler ist mit FI und LSS bestückt und der Rechte enthält die
> SSS, das Rolladensteuermodul und den Controller. (d.h. da soll er dieses

So ähnlich sieht es bei mir auch aus. Ich habe im EG zwei 4 reihige 
Verteiler. Ein großer Schrank im Keller wäre mir lieber gewesen, war 
aber baulich nicht möglich. In dem einen Verteiler sind alle LS und FIs 
für das EG, OG und DG drin, im anderen ist nur die Lichtsteuerung mit 
Dimmer und SSS drin. Die SSS sind noch von meinem Vater und inzwischen 
35 Jahre alt (aber unbenutzt) und funktionieren prächtig.

> Selbst bei diesem durchaus Üppig erscheinenden Platzangebot hab
> ich Funktionen herausstreichen müssen weil es eben nicht genug Platz
> gibt um wirklich jede Steckdose einzeln abschalten zu können.

Das war für mich der Grund, warum ich auf Steckdosen komplett verzichte. 
Deshalb geht meine EIB Leitung auch konsequent von einer Dose bzw. 
Dosenkombination zur nächsten. In den Dosen bzw. Dosenkombinationen gibt 
es mit min. einer Kaiser Elektronikdose genügend Platz um ein 
Koppelrelais (z.B. auch von Eltako) und eine selbstgebaute CAN Bus 
Koppelplatine unterzubringen. D.h. ich kann nachträglich an jeder 
Steckdose eine Funktion (Schalten, Dimmen, Messen, ...) nachrüsten.

> Ich für meinen Teil habe das gehörig unterschätzt und das böse Erwachen
> kam dann beim Beginn der Verdrahtung als ich den Berg an LSS und FI
> sowie SSS vor mir liegen sah.

Ja, trotz sorgfältiger planung war ich vorallem überrascht wie lange die 
Verdrahtung gebraucht hat... Ich kann Euch mal ein Bildchen von den 
Verteilern knipsen.

Grüße Timo

[Timo E. (tien)]

Hallo Max

> vielen Dank für die Fotos! Ja, ich hab früher auch nur AVRs
> programmiert, aber da die PICs einen integrierten CAN Controller haben
> verwende ich in diesem Zusammenhang nur mehr diese und hab schon einiges
> mit den Dingern angestellt. Verwende auch den PIC18F und hab mir dazu
> einen PICKit2 Programmr dazu gebaut (der kann nämlich auch die I/O
> Expander programmieren).

Ich hab zu Hause ein PikKit2. Aber ich fand die MikroE 
Entwicklungsumgebung und die EasyPic5 Platine einfach genial und relativ 
preisgünstig zudem. Der Compiler ist bis 2k frei, ab dann kostet es 
etwas, aber das war ich bereit zu zahlen, vorallem weil alle Updates 
inkl. sind. Aber ob das Teil wirklich taugt wird sich in den nächsten 
Wochen / Monaten zeigen. Es gibt in jedem Fall viele Examples und Libs 
und Erweiterungsplatinchen. Das erspart mir wertvolle Zeit, auch wenn 
ich eigentlich der Typ bin gerne alles selbst zu machen...

> Gebäudeautomatisierung vor einigen Jahren schon bechäftigt und das ganze
> ist nun wieder aktuell geworden, da meine Schwester dabei ist ein Haus
> zu bauen und mich als Elektrotechnik Student dazu befragt hat, was man
< ...
> Verteilerkasten machen wo ja auch die Hauptsteuerung sitzt. Ich möchte
> ebenfalls auch die Fenster per Reedkontak überwachen sowie den Rollo
> steuern.

Das trifft in etwa das was ich mir auch überlegt habe. Denke noch an ein 
Türsteuerung (z.B. Zutritt über RFID Chips) und alle anderen üblichen 
Dinge wie TV, Sound, Telefon, Sprechanlage und Netzwerk. Ich habe in 
jedem Zimmer an der Decke eine Dose in der mein Bus vorbeigeht. Da kann 
ich Sensorik unterbringen (Temp, Feuchte, Bewegung, NotlichtLED, ...). 
An jeder Tür ist in der Höhe von 1,50m eine Dose für ein Touchdisplay 
(dogs102). Je nach Zimmer will ich hier verschiedene Dinge visualisieren 
und steuern. Am Tressen, an dem wir immer Frühstücken ist ein Kasten in 
der Wand eingelassen für einen 10" Touch Screen, der von einem PC im 
Keller (direkt unter dem Tressen) versorgt wird. Damit ist das ständig 
rumstehende Laptop überflüßig.
Nach aussen gehen zu allen 3 Aussenwände eine Sensorleitung, die aber 
nicht direkt mit dem Bus verbunden ist (ich will den Bus nicht aussen 
zugänglich haben).
Und leg Deiner Schwester ans Herz, dass sie sich mit der Heiztechnik 
intensiv befassen sollen! Da kann man meiner Meinung nach langfristig 
richtig sparen, vorallem im Neubau! Und zu einem guten Neubau gehört 
auch ein Lüftungskonzept. Aber das ist nun wirklich OT :-)

> Ich sehe die ganze Arbeit und Entwicklung als eine Investition
> in die Automatisierung bei meinem zukünftigen Haus :-). Ich wollte mir
> auch deshalb mal einen kleinen Verteilerkasten und die wichtigsten
> Komponenten (Dimmer, Stromstoßschalter etc) bestellen um das ganze auch
> mal in etwa  aufzubauen und Erfahrung zu sammeln. Finde es deshalb sehr
> interessant Erfahrungsberichte von allen die sowas schon mal gemacht
> haben zu lesen.

Ja, das ist sehr gut, die Fehler, die Du bei Deiner Schwester machst 
musst Du nicht bei Dir machen - klingt gemein, ist aber so :-)

> Für welche Aufgaben hast du alles einen Node Vorgesehen? Hast du das EIB
> Kabel durch alle Stockwerke geschleift oder hast du jeweils eine
> Steuerung pro Stockwerk geplant?

Es führt von dem Installationsschacht rund ums Stockwerk durch jede 
Schalter und Steckdose, an jeder Decke, an jedem Fenster, an der 
dezentralen Lüftung und an jedem Türschloss vorbei und geht zurück in 
den Keller. Hier kann ich dann entscheiden ob ich ein Gateway einbaue 
oder das gesamte Haus zu einem Bus zusammenschalte.

> Zum Thema verdrahtung des EIB Kabels habe ich immer wieder von den Wago
> Klemmen gelesen, was verwendest du um die Kabel mit einem Node zu
> verbinden?

Genau, bei mir findest Du in jeder Dose vier Wago Miniklemmen. Das ist 
vermutlich nicht ideal, weil ich immer einen geringen 
Übergangswiderstand habe (ich hab es noch nicht gemessen wieviel ich je 
Stockwerk habe) aber die Klemmen haben den Komfort, dass ich einen 
Knoten einfach anstecken kann.

> Hoffe das sind dir nich zu viele Fragen ;-)

Nö! :-)

Grüße Timo

[Max M. (maxmustermann)]

Hi Timo,

au jaa, ein Bildchen wäre nett damit wir mal sehn wie das so aussieht 
:-)

Hast du dich mit dem CAN Bootloader für den PIC18F schon 
auseinandergesetzt? Ich habe bei Microchip eine Application Note 
(http://ww1.microchip.com/downloads/en/AppNotes/00247a.pdf) gefunden, 
jedoch wäre mir ein Tutorial mit Sourcecode lieber, da ich den Code zur 
Appnote niergends finden konnte. Eine weitere interessante Seite ist 
http://mrmackey.no-ip.org/elektronik/ds30loader/screenshots.php. Dieser 
Bootloader soll ebenfalls CAN unterstützen und soll recht fähig sein. 
Ich fand jedoch auf die Schnelle keinen genauen Hinweis darauf, mit 
welcher HArdware auf den Bus zugegriffen wird. Hast du in die Richtung 
schon mal was zu laufen gebracht?

sg Max

[Timo E. (tien)]

Hier noch ein Link zu dem DevBoard (Nachfolger zum EasyPic5:
http://www.mikroe.com/eng/products/view/297/easypic6-development-system/

Und hier zum Compiler:
http://www.mikroe.com/eng/products/view/7/mikroc-pro-for-pic/

Ich hoffe das fällt nicht in die Rubrik Werbung....

[Timo E. (tien)]

Max Mustermann schrieb:
> Hi Timo,
>
> au jaa, ein Bildchen wäre nett damit wir mal sehn wie das so aussieht
> :-)
>
> Hast du dich mit dem CAN Bootloader für den PIC18F schon
> auseinandergesetzt? Ich habe bei Microchip eine Application Note
> (http://ww1.microchip.com/downloads/en/AppNotes/00247a.pdf) gefunden,
> jedoch wäre mir ein Tutorial mit Sourcecode lieber, da ich den Code zur
> Appnote niergends finden konnte. Eine weitere interessante Seite ist
> http://mrmackey.no-ip.org/elektronik/ds30loader/screenshots.php. Dieser
> Bootloader soll ebenfalls CAN unterstützen und soll recht fähig sein.
> Ich fand jedoch auf die Schnelle keinen genauen Hinweis darauf, mit
> welcher HArdware auf den Bus zugegriffen wird. Hast du in die Richtung
> schon mal was zu laufen gebracht?
>
> sg Max

Nö, ich hab ja gestern erst wieder angefangen. Ich wollte eigentlich ein 
Haus bauen und das hätte noch ein paar Jahre gedauert. Eigentlich wollte 
ich auch, wie Du erst mal etwas Beispielhaft zum Laufen bekommen. Aber 
dann kam es anders :-) Und wir haben ein nettes Häuschen gebraucht (13 
Jahre) kaufen können. Und dann war ich (und bin ich eigentlich immer 
noch) geerdet mit den Umbaumaßnahmen. Ausserdem will die Firma auch Zeit 
von mir (und ich ihr Geld) und die Familie will auch noch beachtet 
werden. Aber so langsam will ich mal mit der Buskopplerplatine anfangen 
und der Bootloader ist das erst was gehen muss.

Den Microchip Bootloader hab ich mir kurz angeschaut. Aber intensiv noch 
nicht. Den anderen Link kannte ich noch nicht. Sollen wir uns da 
zusammen tun? Der Compiler sollte eigentlich keine zu große Rolle 
spielen.
Eventl. hättest Du ja auch interesse eine Basisplatine zusammen zu 
entwickeln.


Grüße Timo

[Max M. (maxmustermann)]

Hi Timo,

das glaub ich das du voll eingespannt bist! Ich bin zwar Student und 
kann mir die Zeit relativ gut einteilen. Ich versuch deshalb auch 
diverse private Interessen bei Projekten unterzubringen die ich für die 
Uni machen kann :-). Ja klingt gut! Ich kann dich gerne auf dem 
Laufenden halten und geb dir Bescheid wenn ich was neues über den 
Bootloader in Erfahrung bringe!

Grüße Max

[Christian B. (luckyfu)]

Timo E. schrieb:
> (z.B. Zutritt über RFID Chips)

Hab ich auch, ist aber autark von "effeff (anykey)". Nicht ganz billig 
aber Versicherungskonform (und damit mit ausreichend WAF, was die 
Selbstbaulösung nicht hatte die hier im Forum herumgeistert.

Zu den Steckdosen: Ich hab bis auf Keller, Herd, Kühlschrank und 
Geschirrspüler alle Steckdosen abschaltbar ausgeführt. Allerdings nicht, 
wie anfänglich geplant, jede Seperat sondern in Gruppen. Sind aber 
dennoch recht viele geworden. Auch bei den Verteilern hab ich nicht alle 
erwähnt, die 2x3 Reihen sind eigentlich nur Erdgeschoss, da ist halt 
Küche (Extrem viele Steckdosen) und Wohnzimmer (Display ist hier 
vorgesehen).
im OG hab ich einen 4 reihigen Verteiler für OG und DG und im Keller den 
großen HAK mit ebenfalls 6 Reihen die alle gut voll sind. (Ist aber noch 
Luft, wenngleich nicht immer die VDE Konformen 20%, im OG der ist 
ziemlich ausgelastet)

Ich hab somit keinerlei Verteilerdosen, alles sind Sternleitungen direkt 
zum Verteiler. Das sorgt dann dort für Armdicke Kabelbündel welche 
ebenfalls einen enormen Platzbedarf haben.

[Timo E. (tien)]

Hi Christian

> Hab ich auch, ist aber autark von "effeff (anykey)". Nicht ganz billig
> aber Versicherungskonform (und damit mit ausreichend WAF, was die
> Selbstbaulösung nicht hatte die hier im Forum herumgeistert.

Ich habe (bisher erst die Kellertür, da die neu ist) das System Genius 
EB
http://www.kfv.de/de/product/electronic_locking_systems/genius/
in der Tür eingebaut. In der Haustür wird das nächsten Sommer 
nachgerüstet. Allerdings nur der Antrieb mit Mehrfachveriegelung, ohne 
Leser, Sender oder ähnlich. Die Aktivierung mache ich dann mit einem 
RFID System. Ich wollte das selber machen, damit ich auch an der 
Garagentür mit herkömlichen Türöffner die gleichen Chips verwenden kann.

> Ich hab somit keinerlei Verteilerdosen, alles sind Sternleitungen direkt
> zum Verteiler. Das sorgt dann dort für Armdicke Kabelbündel welche
> ebenfalls einen enormen Platzbedarf haben.

Uff, ich weiß ganz genau was Du meinst :-)

Grüße Timo

[Timo E. (tien)]

Hi Max,

> das glaub ich das du voll eingespannt bist! Ich bin zwar Student und
> kann mir die Zeit relativ gut einteilen. Ich versuch deshalb auch
> diverse private Interessen bei Projekten unterzubringen die ich für die
> Uni machen kann :-).

Geniese die Zeit! Ich bereue manchmal, dass ich damals nicht mehr Zeit 
in meine Hobbys gesteckt habe sondern viel zu oft z.B. vor der Klotze 
saß.

> Ja klingt gut! Ich kann dich gerne auf dem
> Laufenden halten und geb dir Bescheid wenn ich was neues über den
> Bootloader in Erfahrung bringe!

Ich hab mir die Homepage des ds30 Bootloaders angeschaut. Das sieht ja 
genau nach dem aus, was wir brauchen - oder? Und das PC Programm in c# 
kommt mir auch sehr entgegen, das ist meine Lieblingssprache auf dem PC 
:-)

Ich bin sehr gespannt - am liebsten würde ich sofort loslegen.

Also wenn Du willst können wir uns einfach locker austauschen über die 
Buskoppler/Basisplatine. Und dort wo unsere Meinungen auseinander gehen 
machen wir dann halt unser eigenenes Ding - was hälts Du davon?

Ich sende Dir mal per PM meine Mailadresse.


Grüße Timo

[Timo E. (tien)]

Hi Max,

danke für Deine Mail, werde heute Abend mal antworten.
Was ich gerade gefunden habe:
Beitrag "Eingabepanel mit CAN-Bus Entwicklung"

Ist ganz nett um mal zu schauen was andere mit dem PIC in Richtung 
Hausautomation gemacht haben. Sobald der Bootloader läuft werde ich mich 
an die Hardware machen.

Aber wir könnten hier schon mal die Anforderungen sammeln, oder sollen 
wird das in einem neuen Thread machen bzw. lieber per Mail - was meinst 
Du?


Grüße Timo

[Max M. (maxmustermann)]

Hi Timo,

Interessanter Link, werd ich mir mal durchlesen!

>Aber wir könnten hier schon mal die Anforderungen sammeln, oder sollen wird das 
>in einem neuen Thread machen bzw. lieber per Mail - was meinst
>Du?

Gute Frage! Tja, nur mit dem steuerbaren Dimmer alleine hat das schon 
länger nichts mehr zu tun :-). Also ich glaube um Ideen und 
Anforderungen zu sammeln sollte schon ein neuer Thread her. Klar, im 
Forum finden sich viele ähnliche Threads, aber ich fänd es blöd sich 
dort dran zu hängen, da es dann schnell unübersichtlich wird. Per Email 
können wir das gerne auch machen, nur haben dann die lieben 
Forenteilnehmer nichts davon und ich denke es können sich hier sicher 
einige positiv einbringen.

Gruß Max

[Timo E. (tien)]

Ok, ich mach mal einen Thread auf...

[Timo E. (tien)]

Bitte schön:
Beitrag "Anforderungssammlung CAN Hausbus mit PIC µC"

Ich hoffe das ist so halbwegs gut formuliert.

Grüße Timo

[Max M. (maxmustermann)]

Timo E. schrieb:
> Ich hoffe das ist so halbwegs gut formuliert.

Ja, finde passt super so! Dann kanns ja los gehn :-)

[Ein Gast (Gast)]

Timo E. schrieb:
> Deshalb
> habe ich die EUD12Z-UC Dimmer eingebaut.

Hi Timo,

da Du ja den Dimmer schon verwendest habe ich ein kurze Frage dazu: 
Erfolgt das Dimmen damit Stufenlos oder dimmt der EUD12Z stufenweise, 
wenn man den Taster gedrückt hält?

[Timo E. (tien)]

Der Dimmer dimmt stufenlos. Wenn man das so sagen darf :-)
Wenn man genau hinschaut vorallem wenn man kurz vor "Licht aus" dimmt 
erkennt man schon Stufen. Oder man stellt die Dimmgeschwindigkeit auf 
sehr langsam, auch dann sieht man die einzelnen Stufen. Aber im 
Alltagsbetrieb fällt dies nicht negativ auf.
Entgegen meiner Aussage oben habe ich ausserdem nicht den EUD12Z-UC 
sondern den EUD12M-UC. Ich denke der Z ist ein Nachfolger. Der Z kann 
z.B. mit LEDs umgehen.

[Stefan (Gast)]

Habe gerade den LUD12 offen gehabt. X1 und X2 müssten Potentialfrei 
sein. Scheint, als gänge dies auf einen Optokoppler. Werde mal in 
Kombination mit dem SUD12 rausmessen was da passiert und dann den LUD12 
als Single vom PIC ansteuern. Das wäre meiner Meinung die beste 
Variante, da ich die Helligkeit vom PIC direkt vorgeben kann.
Gruß Stefan

[Stefan (Gast)]

Hallo nochmal.
Der Eingang X1 X2 ist beim LUD12 (Preis 30-50Euro) mit einem Optokoppler 
EL817 versehen.
http://www.everlightindia.com/upload/product_pdf/EL817-G.pdf
Der Eingang wird mittles PWM 100Hz (siehe Photo) getaktet.
Kein Tasten hell..... Tasten dunkel..... oder Umwege über DA-Wandler und 
Verstärker. Direkt mit dem PIC.
So werd ich diesen auch ansteuern. Man könnte den Vorwiderstand im LUD 
ändern so das die Regelung mit 5V geht, müsste aber jeden Dimmer öffnen.
Da ich sowieso Optokoppler als Ausgang meiner Platine nutze (EMV...) 
takte ich halt 10V. Und ich verliere nicht die Garantie.......
Viele Grüße

Stefan

BEi fragen via Email, da ich nicht regelmässig hier reinschaue

[Max M. (maxmustermann)]

Hallo Stefan!

Wenn denn da eine Email Adresse wäre ;)

Interessant was du da herausgefunden hast. Ich dachte immer, dass an den 
Ausgängen ein analoges Steuersignal von 0 bis 10V anliegt aber scheinbar 
ist das doch ein PWM. Bei mir ist es so, dass ich die Helligkeit des 
Dimmers mit einem µC messen will, von da her wär es nicht so schlecht 
gewesen, wenn ich einfach ein 0-10V Analogsignal mit einem ADC auswerten 
hätte müssen. Die meisten µCs haben ja schon über 10 ADC Kanäle. 10 PWM 
Kanäle auszuwerten scheint mir da etwas aufwändiger zu sein.

Grüße Max

[Stefan (Gast)]

Hallo Max

Meine Email ist [e-mail]

Schau Dir mal den SUD12 an, der Funktioniert auch andersrum und gibt 
1-10 V raus. Ob dies Potentioalfrei ist weiß ich allerdings nicht.
Oder warum nicht einfach eine Diode und einen Elko an das PWM. PWM rein 
Analog raus. Spannungsteiler dahinter und los gehts. Und wenn du einen 
Optokoppler noch davor setzt, ist es auf alle Potentialfrei.

Ich werde zur Ansteuerung den TLC59116 probieren. Der lässt sich via I²C 
einstellen und ich habe keine Arbeit mit der PWM.

Ich nutze übrigens nicht CAN sondern RS485 für meinen allgemeinen BUS.
Somit lassen sich auch recht einfach PC`s mit einbinden und ich kann auf 
meine SMA Wechselrichter zugreifen.

Gruß Stefan

[Max M. (maxmustermann)]

Hallo Stefan!

Ja das mit der Diode und dem Elko hab ich mir auch schon überlegt. 
Jedoch wenn ich dann danach noch ein Optokopler schalte, ist dann das 
Signal auf der anderen Seite noch linear? Ein anderer Ansatz den ich mir 
überlegt habe wäre ein I²C I/O Expander der einen Interrupt Ausgang hat, 
so hätte ich 8 Kanäle und kann die Änderung der Pins mit Timestamps 
versehen und daraus das Tastverhältnis berechnen. Das Ganze scheint mir 
aber um einiges mehr "Stress" für den µC zu sein als einfach alle 8 ADC 
Kanäle nacheinander zu wandeln. Werd aber glaub beides mal testen und 
schauen was besser funktioniert. Hast du sonst noch eine Idee wie man 
sowas machen könnte?

Gruß Max

[Stefan (Gast)]

Hallo Max
Der Optokoppler muß in das PWM-Signal.
Erst nach dem Optokoppler kommt die Diode mit dem C.

Gruß Stefan

[Tien (Gast)]

Stefan schrieb:
> Der Eingang X1 X2 ist beim LUD12 (Preis 30-50Euro) mit einem Optokoppler
> EL817 versehen.
> http://www.everlightindia.com/upload/product_pdf/EL817-G.pdf
> Der Eingang wird mittles PWM 100Hz (siehe Photo) getaktet.

Das ist ja eine gute Neuigkeit!
D.h. im Umkehrschluss, dass meine EUD Dimmer ja auf X1/X2 ein PWM Signal 
ausgeben sollten. Somit kann ich an X1/X2 einen Optok hängen und dann 
per PIC die PWM messen. Das ist mir sehr viel lieber als irgendeine 
Analogspannung, zumal die dann nicht Potentialgetrennt ist.
Ich glaub ich muss doch mal mein Oszi an den Dimmer anschließen.

Alternativ wäre natürlich eine lokal abgeschlossene Einheit aus lauter 
LUD12 Dimmern und einer PIC Controllereinheit mit Taster Eingängen für 
die Taster, damit die Grundfunktion auch ohne Bus funktionieren. Das 
könnte im Bedarfsfall auch ein Elektriker gegen die vollständige Eltako 
Version ersetzen. In der PIC Controllereinheit könnte man dann auch den 
(CAN)Busanschluß vorsehen um dann, sofern Busspannung vorhanden ist die 
zusätzlichen Komfortfunktionen zu bedienen.

Vorteil gegenüber meiner derzeitigen EUD12 Lösung:
Man hat, wenn der Bus aktiv ist volle Gewalt über die Taster und kann 
ausserdem die Leuchtstärke direkt gezielt anfahren.

Nachteil: Inertialer Entwicklungsaufwand (sollte also vor dem Bau/Umbau 
des Hauses schon laufen)


Ich werde eine Mischlösung umsetzen und nach und nach die EUDs gegen die 
LUDs austauschen. Wer also in nächster Zeit ein paar EDs braucht darf 
sich bei mir melden :-)

Grüße Timo

[Stefan (Gast)]

Hallo Timo

Habe mein erstes Projekt (Industriegebäude -> 3 Hallen + Werkstätten + 
Lager + Bürotrackt) mit meiner RS485 Variante umgesetzt. Ich habe kleine 
runde Platinen gemacht, die ich jeweils in die Schalterdose mit reinlege 
und eine Sendeadresse einstellen kann. In der Hauptverteilung sitzt dann 
das Netzteil und die Masterplatine, die die Ausgangsrelais schaltet. 
Funktioniert einwandfrei soweit. Jetzt kommt die Stelle wo ich auch 
dimmen will. Ich bin gerade beim zeichnen einer neuen Masterplatine die 
16 Ausgänge hat (für Dimmer und Relais) ca. 8 Eingänge und 2 Poti für 
schnelle Analoge Einstellungen ( Zeitschaltung etc.) vielleicht auch 3. 
Was nicht vergessen werden darf, ist der Netznulldurchgangseingang, da 
das PWM-Signal synchron mit der Netzspannung sein muß beim LUD12 (Danke 
nochmal an Carsten und Robert) Das hätte ich in meiner Freude fasst 
übersehen. Ich kann auch mit dem PC auf die RS485 super zugreifen, so 
dass man im Büro alles im Blick hat und steuern kann.

Ich muß zugeben, wir waren mit dem Bau fertig und es war noch keine 
Zeile programmiert. :) Etwas nervös war ich dann schon, da dies das 
erste Projekt dieser Art war........und klein zudem auch nicht. Die 
Verteilung ist 2m hoch und 1,2m breit. Voll bis zum Anschlag...... 
Allerdings, die Angst, dass Busleitungen kaputt gemacht wurden beim Bau 
war doch größer.

Das interresanteste bei der Bestückung waren die Busteilnehmer für die 
Schalter, da ich diese eigentlich im Nutzen haben wollte und dann 
einzeln bekommen habe. Da diese Rund sind mussten wir erst eine Aufnahme 
für den Bestückungsautomaten bauen.

Grüße
Stefan

[Tien (Gast)]

Hi Stefan,

> Habe mein erstes Projekt (Industriegebäude -> 3 Hallen + Werkstätten +
> Lager + Bürotrackt) mit meiner RS485 Variante umgesetzt. Ich habe kleine
> runde Platinen gemacht, die ich jeweils in die Schalterdose mit reinlege
> und eine Sendeadresse einstellen kann. In der Hauptverteilung sitzt dann
> das Netzteil und die Masterplatine, die die Ausgangsrelais schaltet.
> Funktioniert einwandfrei soweit.

Ja, das geht bestimmt gut. Und bei meiner CAN Umsetzung würde das 
genauso gut gehen. Aber ich will ein System haben, das die 
Grundfunktionen OHNE Bus erledigt. Ich will einfach nicht, dass meine 
Familie sich nicht helfen kann, wenn ich aus irgendwelchen Gründen die 
Anlage nicht warten kann. Das kann im einfachsten Fall die mehrtägige 
Abwesenheit aus beruflichen Gründen sein, im schlimmsten Fall der Tod. 
Oder auch wenn ich das Haus mal verkaufe will ich nicht erst viel 
zurückbauen. D.h. Licht an/aus, Rollo runter/hoch müssen mit Elektriker 
kompatibler Technik aufgebaut sein. Alles weitere bzgl. Komfort kann 
dann der Bus obendrauf setzen. Aber das ist natürlich meine persönliche 
Zielsetzung. Und ich finds gut wenn Dein System funktioniert.

> Jetzt kommt die Stelle wo ich auch
> dimmen will. [...]
> Was nicht vergessen werden darf, ist der Netznulldurchgangseingang, da
> das PWM-Signal synchron mit der Netzspannung sein muß beim LUD12 (Danke
> nochmal an Carsten und Robert) Das hätte ich in meiner Freude fasst
> übersehen.

Dann wäre doch der FUD12NPN-12V DC Dimmer was für Dich. Der läuft auch 
über RS485, wenn auch bestimmt mit einem anderen Protokoll. D.h. Du 
müsstest halt eine Art Gateway RS485privat <-> RS485eltako bauen, was 
aber bestimmt kein größeres Problem sein dürfte. Aber dann bist Du auf 
der absolut sicheren Seite und muss auch keine Netzspannung beachten, 
sonst musst Du ja auch noch wissen auf welcher Phase der Dimmer sitzt.

Mit dieser Info (Phasensynchron) wird für mich eher wieder die Kombi 
FUD12NPN-12V DC Dimmer mit FTS12EM-UC Taster-Eingabemodul die beste 
Lösung um meine Anforderung nach Grundfunktion UND Automation zu 
sichern. Wenn es bei mir mal ruhiger ist werde ich mir mal so eine Kombi 
kaufen und mit dem Oszi anschauen. Weiterer Vorteil: Ich könnte dann die 
alten Eltakos Schritt für Schritt gegen FSR12-12V DC ersetzen in denen 
zwei Schlieser drin sind und hätte dann sogar wieder etwas mehr Platz im 
Schaltschrank. Hmm, scheint mir weiterhin die ideale Lösung zu sein.  So 
einen OpenSource Hutschienen Controller, der die Eltako RS485 Teile 
ansteuert wäre echt ein nettes Projekt hier fürs Forum. Das wäre die 
ideale Brücke für Bus Eigenbau mit zugelassener Leistungselektronik. 
Bleibt nur die Frage offen ob Eltako da was dagegen hat. Ich hoffe nur, 
dass das Protokoll recht einfach ist, eventl. werde ich mal bei Eltako 
anfragen ob es dazu eine Beschreibung gibt.

> Ich kann auch mit dem PC auf die RS485 super zugreifen, so
> dass man im Büro alles im Blick hat und steuern kann.

Das ist mit dem CAN Bus genauso möglich. Entweder man kauft sich für ein 
paar Euro ein Interface, z.B. von Peak oder baut einfach eines aus zwei 
PICs (USB <-> CAN). Das Interface muss ja nicht viel können, es reicht 
ja genau die Baudrate und Adressierungsart zu implementieren, die der 
Bus verwendet. Damit ist das an einem Wochenende erledigt und kosten 
weniger als 40 Euro inkl. kleinem Gehäuse und Kabel.

Aber auch hier ist der CAN ja nur eine der vielen möglichen Lösungen. 
Ich kenn mich halt gut mit dem CAN aus und hab auch genügend Messtechnik 
dafür zur Verfügung. RS485 ist mit Sicherheit eine weitere recht gut 
geeignete Lösung (im Vergleich zu den IMO ungeeigneten RS232 Lösungen).

Grüße Timo

[Max M. (maxmustermann)]

Hallo Timo!

Was spricht gegen die Version die wir anfangs schon besprochen haben? 
EUD12Z Dimmer, bei welchen die Ausgänge X1 und X2 dazu verwendet werden 
die PWM auszuwerten um die aktuelle Helligkeit festzustellen. Zusätzlich 
noch ein Relais parallel zu den Tastern und schon kein ein Tastendruck 
simuliert werden um eine vorgegebene Helligkeit anzufahren oder das 
Licht ein- und auszuschalten. Dies funktioniert dann auch ohne Bus.

ICh muss sagen, dass ich die Idee mit dem Tastereingabe modul über RS485 
auch gut finde.

Gruß Max

[Tien (Gast)]

Hallo Max,

generell ist die Lösung natürlich auch möglich. Hat aber mehere 
Nachteile:

1. Man benötigt mehr Leitungen zw. Dimmer und Controller (zwei für 
X1/X2) und mind eine für die Tastersimulation.

2. Man kann keinen Helligkeitswert direkt anfahren. D.h., wenn Du direkt 
von 0% nach 60% willst ist das nur in der am Dimmer vorgegeben 
Dimmgeschwindigkeit möglich. Somit ist z.B. ein ganz langsames Dimmen im 
Schlafzimmer am Morgen, als "Sonnenaufgangs" Simulation möglich.

3. Der µC mus wenn zuvor hochgedimmt wurde erst kurz runter dimmen um 
danach weiter hochzudimmen, da die Tasterlogik ja immer 
hoch,runter,hoch,runter ist, das sieht eventl. nicht sehr schön aus.

4. Ohne die Tasterleitung aufzutrennen hast Du keine Herrschaft über die 
Taster. D.h. ein Doppeltclick oder Tasterkombinationen oder ähnl. kannst 
du nicht verwenden. Dies könnte man durch Auftrennen der Taster 
erledigen, aber dann wirds langsam recht unübersichtlich. Das muss ja 
für jeden Dimmer gemacht werden und ich hab z.B. 10 Stück, da kommt 
einiges Material zusammen.

Deshalb finde ich die Lösung mit den RS484 Dimmern ganz gut. Dann 
schließt man die Taster an das Eingangsmodul an und danach gehts per 
RS485 auf die Dimmer. Sobald der Bus mit Spannung versorgt wird (was ja 
der Indiz dafür sein soll, dass der Komfortmodus aktiv ist) wird die 
RS485 Verbindung getrennt und eine selbsgebaute Controllereinheit 
eingeschleift. Diese wertet die Taster aus und kann die Dimmer steuern. 
Damit hat man die komplette Kontrolle ohne auf den Fallback zu 
verzichten.

Ich hab ausserdem Eltako eine Mail geschrieben, mal sehe was da raus 
kommt.


Grüße Timo

[Stefan (Gast)]

Hallo Timo

Ich habe schon mit Eltago telefoniert. Da sind wir viel zuklein.....ab 
2000 Stück oder so wäre das machbar.
Ich bin gerade drüber eine neue Masterplatine (PIC18F4520) mit RS485; 
I²C Nullspannungserkennung; 9 Eingänge; 3 Poti für Zeiteinstellung und 
16 Ausgänge wahlweise für den LUD12 oder Relais zu zeichnen. Netzteil 
kommt diesmal auch gleich mit drauf. Als Relais nutze ich Finderrelais 
mit zusätzlicher Handbetätigung. Im schlimmsten Fall kann beim Ausfall 
das Licht etc. von der Verteilung geschalten werden. Ein Elektriker 
könnte das System im schlimmsten Fall auf EIB umbauen, da ich auch EIB 
Leitung als Bus verwende. Ja... das kostet der Nachwelt dan richtig 
Geld, aber ich bin nicht derjenige, der die Bezeichnung auf den IC`s 
runterschleift. Einem Elektroniker sollte die Reparatur gelingen. 
Außerdem gehört zu einer ordenlichen Dokumentation Schaltplan und 
Software dazu.
Ausserdem kann ich mit der jetzigen Lösung auch die Relais nahe am 
Nulldurchgang schalten um die Relais zu schonen.

Viele Grüße bis dahin.

Stefan

[Stefan (Gast)]

Hallo zusammen

Hier mal ein paar Bilder vom Oszi noch zum LUD12.
Beim Bild "nicht_100Hz" stammt X1/X2 aus einem Rechteckgenerator. Man 
sieht das nur im "1" Zustand der LUD durchschaltet. Bild 1-4 ist in 
Stellung "zusätzliche Leuchten" Bild 5-8 in Stellung Leistungszusatz. 
Als Last habe ich eine 12V Halogenlampe mit konventionellen Trafe 
gehabt.
Ich denke, die 100Hz Quelle muß zwar in der Frequenz aber nicht im 
Nulldurchgang synchron sein. Das erleichter zumintest die 
Programmierung.

Viele Grüße dahin.

Stefan

[Robert B. (robertb)]

Hallo Stefan,

auf diesem Wege auch noch einmal vielen Dank für Deine Arbeit! Toll wie 
viel Zeit Du da für uns reinsteckst!

Ich behaupte, dass - wie von mir erhofft - in der Stellung "zusätzliche 
Leuchten" nur die Impulslänge gemessen wird, der LUD aber bedingt durch 
den unbekannten Lasttyp am "Geber" (SUD o.Ä.) und durch seinen eigenen 
evtl. zu diesem verschiedenen Lasttyp zwangsweise eine eigene 
Synchronisation zum Nulldurchgang macht.

In den Bildern 1-4 erkennt man einen sauberen Phasenanschnitt, in den 
Bildern 5-8 wird eben wohl das Eingangssignal X1/2 direkt an den Mosfet 
weitergereicht, was sowohl zu einer Phasenverschiebung als auch eben 
langfristig zu einer Schwebung (Lampe dimmt hoch und runter) aufgrund 
der unvermeidlichen Frequenzversatzes führt. In den Bildern 1-4 erkennt 
man, dass die Flankenwechsel absolut nichts mit dem durchschalten der 
Mosfets zu tun haben. Auf den anderen Bildern ist das harte Umschalten 
aufgrund der starren Kopplung sichtbar.

Für mich heißt das: Ein LUD einzeln kann galavnisch getrennt durch den 
X1/2 Eingang gesteuert werden, sofern man im erlaubt sich selbst zu 
synchronisieren (Stellung "zusätzliche Leuchten"). Wenn man nun eine 
Leistungserweitwerung vornehmen will wird man nicht umhin kommen eine 
LUD (in der Stellung "zusätzliche Leuchten") zu modifizieren, ihre 
Ansteuerung der Mosfets nach außen zu führen. Daran kann man dann normal 
LUDs im Erweiterungsmodus betreiben.

Schönen Abend!
Robert

[Stefan (Gast)]

Hallo Robert

Ich möchte aber nochmals anmerken. Die Frequenz muß 100 Hz sein. exakt 
doppelt so hoch wie die Netzfrequenz. (wegen nagiver und positiver 
Halbwellen) Ist die Frequenz 99,9 Hz. wird das Licht die Hellikeit 
selbstständig ändern. In beiden Stellungen!!! (siehe Bild nicht 100Hz). 
Was ich noch nicht getetstet habe ist, wenn der SUD an einer anderen 
Phase liegt. Das aber erst in 14 Tagen wenn ich die Platinen da habe und 
bestückt sind. Ich habe auf meiner Masterplatine einen Netzimpuls zum 
Pic geführt. der Impuls löst einen Interrupt aus. Dort schaltet ich den 
Ausgangsimpuls ein und nach variabler Zeit wieder aus. So bin ich 
sicher, dass ich die 100Hz exakt habe. Außerdem kann ich meine normalen 
Relais in der Nähe des Nulldurchgangs schalten. Das will ich zu einem 
späterern Zeitpunkt mal testen wie lange die Verzögerung ist vom Impuls, 
bis die Kontakte des Relais geschlossen sind. Softwaremässig könnte man 
dann die Relais soweit hinbekommen.

Grüße Stefan

[LUD12 (Gast)]

Mit anderen Worten:
Der LUD12 MUSS mit einer 100Hz PWM gespeist werden. Analog 0-10V wird 
nicht funktionieren?!
Das Netz ist ja nicht immer genau 50 Hz. Flackert dadurch die Lampe da 
die 100 Hz ja in den meisten Fällen quarzstabil sein werden?!

[David .. (david1)]

auf paar HZ kommts nich an, dazu is das Auge zu träge.

[Robert (Gast)]

Aufgrund des Optokopplers muss der LUB mit einer PWM gespeist werden. 
Ein konstanter Analogwert wird nicht helfen. Das mit der Trägheit des 
Auges ist natürlich Quatsch - bei einem (nicht kompensierten) 
Frequenzversatz kommt es zu einer Schwebung und das Licht dimmt 
unfreiwillig wie von Stefan bereits beschrieben periodisch von hell nach 
dunkel und wieder zurück. Die Frage ist ob dies in einem gewissen Maße 
vom LUD kompensiert wird. Ich versuche das heute abend mal zu ermitteln.

Grüße
Robert

[David .. (david1)]

Achso jetz hab ichs erst verstanden.

Hab gedacht es geht um die Frequenz des Ausgangs

[Robert (Gast)]

Hallo!

Habe heute mal einen LUD12 auf 3,3V "umgebaut" (einfach den 8,2kOhm 
durch 1,5kOhm ersetzen) und mit einem AVR angesteuert. Am Ausgang hatte 
ich eine konventionelle 100W Glühlampe. Der LUD war auch "zusätzliche 
Lampen" eingestellt.

Bei 100 Hz scheint alles zu funktionieren - auch ohne 
Netzsynchronisation. Die Dimmung läßt sich von 0-100% regeln. 
Gelegentlich - und das gibt mir ein wenig zu denken - flackert die Lampe 
1-3mal kaum merklich. Allerdings nicht regelmäßig und vor allem nicht in 
Form einer Schwebung. Könnte daher auch an meiner PWM (allerdings über 
Timer und Output Compare...), dem recht langen (1,5m) Kabel vom AVR zum 
LUD oder evtl. doch noch zu hohem Vorwiderstand liegen.

Darüber hinaus habe ich auch mit 60, 80 und 120 Hz getestet: 
Funktioniert interessanter Weise auch. Kein Auf-und-Abdimmen zu 
erkennen. Ob das gelegentliche Flackern häufiger vorkommt mag ich nicht 
beurteilen.

Werde evtl. mal mit anderen Lasten weitertesten.

Grüße
Robert

[Robert (Gast)]

Nachtrag:

Im Modus "einzelne Leuchte" beobachte ich auch bei 100 Hz die Schwebung. 
D.h. aber im Umkehrschluß dass der PIC das Signal in beiden Modi 
definitiv unterschiedlich interpretiert.

Alternativ wäre natürlich eine eigene Firmware für den PIC genial. nicht 
nur dass die Nulldurchgangserkennung zu 100% sicher wäre, auch könnte 
man eine unidirektionale serielle Kommunikation realisieren und sich so 
im Hauptcontroller die Generierung der PWMs sparen (ab 4 aufwärts ist 
das ja bei den meisten Controllern nicht mehr ganz so leicht in Hardware 
zu realisieren).

Grüße
Robert

[Robert (Gast)]

Nachtrag 2:

Das kaum wahrnehmbare Flackern bleibt leider sowohl bei leicht unter 100 
Hz als auch leicht über 100 Hz (98 Hz, 102 Hz). Hatte gehofft den LUB 
überlisten zu können. Was auffällig ist: Der LUD scheint nicht mal das 
Verhältnis der PWM zu bestimmen, sondern nur die Länge der high-Phase. 
Wenn ich die High-Phase auf 30ms setze kann ich die Gesamtfrequenz von 
100 Hz bis 33 Hz variieren ohne das sich die Helligkeit ändert. Leider 
leider scheint jedoch irgendwo noch der Nulldurchgang drin zu stecken.

Evtl. liegt das daran dass der PIC keinen Input-Capture benutzt. Wenn 
jetzt die Interrupt von Nulldurchgang und PWM zusammenfallen könnten 
sich Messungenauigkeiten ergeben die das Flackern verursachen.

Weitere Möglichkeit die mir einfiel: Anstelle den PIC neu zu 
programmieren (inkl. Lasterkennung etc.) könnte man einen zweiten uC 
(z.B. ATtiny13) einbauen. Diesen dann in die Leitung zwischen 
Optokoppler und PIC einsetzen und zusätzlich an die Spannungsversorgung 
von PIC und an die Nulldurchgangserkennung anschließen. Damit könnte man 
den LUD dann auch wieder per serieller Schnittstelle steuern.

Grüße
Robert

[Tien (Gast)]

Aber wenn Du den PIC umprogrammierst kannst Du gleich den Eltako RS485 
Dimmer nehmen. Ok, kostet etwas mehr, aber dafür bleibt das Teil 
original und es spart Entwicklungszeit. Ich werde mir von den RS485 
Dimmern mal einen kaufen und analysieren.

Grüße Timo

[FUD12NPN-12V (Gast)]

Ich denke auch, dass man mit dem FUD12NPN-12V  glücklicher wird wenn den 
Leistungsteil mit "industrieller Ware" umsetzen will.
Wenn ich jetzt anfange, den uC im LUD12 umzuflashen oder gar einen 
weiteren uC einzubauen, dann habe ich im Gegensatz zu einer kompletten 
Selbstbaulösung nicht viel gewonnen, muss aber den im Verhältnis relativ 
teuren LUD12 bezahlen. Trotzdem bezahlt meine Versicherung nicht wenn 
die Hütte brennt da ja wieder rumgepfuscht wurde.

Bekommt man allerdings das Protokoll des FUD12NPN-12V heraus (was 
wahrscheinlich nicht ganz so einfach sein wird), so hat man einen 
fertigen Dimmer für 46 EUR, den man via RS485 ansprechen kann. Das wäre 
zumindest für mich der ideale Mittelweg.

Zudem gibt es im Hausgebrauch nichts ärgerlicheres, als einen nicht 
100%ig funktionieren Dimmer. Gerade im Wohnbereich wenn man ein Buch 
liest, fällt jede noch so kleine Schwebung irgendwann auf. Und wenn dann 
noch ein unregelmäßiges Flackern dazukommt dürfte sich der WAF ganz 
schnell ganz weit unten befinden. Da nehme ich doch lieber 10 EUR mehr 
pro Dimmkanal in die Hand und habe ein Produkt was von der 
Leistungsseite her 100% durchdacht und erprobt ist.

VG

FUD12NPN-12V

[FUD12NPN-12V (Gast)]

Wobei ich gerade nach Studium der FUD12NPN-12V Doku leichte Zweifel 
habe, ob sich der FUD12NPN-12V überhaupt direkt mit absoluten 
Dimmerwerten über den 485 Bus ansprechen läßt. Ich befürchte fast nicht, 
zumindest werden Szenen etc scheinbar im Dimmer gespeichert. Ebenso wird 
im Dimmer abgelegt, wie er sich bei einem Tastendruck zu verhalten hat.
Im schlimmsten Fall nimmt er also über den 485 Bus nur Informationen wie 
"Taste gedrückt" entgegen und interpretiert diese. Dann hätten wir 
gegenüber einem normalen, dummen 0815 Hutschienendimmer auch nichts 
gewonnen.

[Robert (Gast)]

Das mit dem Abfackeln ist - wenn man ehrlich ist - nicht nur extrem 
unwahrscheinlich nur weil man einen uC hinzufügt, sondern auch im falle 
des Falles mit 5000 Euro gedeckelt für den schier unwahrscheinlichen 
Fall, dass wegen eines durchgeschmorten Dimmers das ganze haus abbrennt. 
Hier würde wohl ein feuerfester Installationskasten mehr helfen.

Ungeachtet davon macht es natürlich ab einer gewissen Stückzahl schon 
einen Unterschied (z.B. ob ich 30x 30 Euro oder 30x 46 Euro zahle).

Zudem ist der FUD unnötig groß, was mir bei der Planung von 
Etagenverteilern auch nicht so gefällt. Pro Etage kommen ja mal schnell 
10 Dimmer zusammen.

Was allgemein die Abgrenzung zum Selbstbau angeht: Wenn ich mir den LUD 
so anschaue zweifel ich ob man das selber günstiger gebaut bekommt. Da 
ist doch wirklich EINIGES auf der zweiseitigen, gemischt bestückten 
Platine. Platine, Gehäuse, Mosfets, Drossel, PIC, Anschlußklemmen - 
schätze mal die teile zu kaufen käme für die mesiten auf 20 Euro - dazu 
noch das löten und Funktionstest. Da ist der LUD echt günstig.

[Tien (Gast)]

Robert schrieb:
> Zudem ist der FUD unnötig groß, was mir bei der Planung von
> Etagenverteilern auch nicht so gefällt. Pro Etage kommen ja mal schnell
> 10 Dimmer zusammen.

Der LUD12-230V und der FUD12NPN-12V DC sind doch gleich groß.
Nur der FUD12/800W-12V DC mit bis zu 800W benötigt 2 Einheiten.

Grüße Timo

[Dimmer (Gast)]

Wo kauft ihr den LUD12 denn?
Preise bei eibmarkt:
LUD12        = 42,00€
FUD12NPN-12V = 46,80€

Beide Geräte 1TE.

Da finde ich den Unterschied nicht der rede wert.

[DIM (Gast)]

Keine neuen Erkenntnisse im neuen Jahr?

[Tien (Gast)]

Hi Max,

magst Du kurz von den Neuigkeiten erzählen?

Grüße Timo

[Max M. (maxmustermann)]

Wie Timo schon erwähnt hat, habe ich mir vor zwei Wochen ein Eltako 
FTS12EM Taster-Eingabemodul, einen FSA12 4-fach Schaltaktor und einen 
FUD12NPN Dimmaktor bestellt. Habe diese Module nun über den RS485 Bus 
zusammengeschaltet, eingelernt und das Protokoll am Bus unter die Lupe 
genommen. Der Bus wird mit den Porteinstellungen 9600,N,1 betrieben. Am 
RS485 Ausgang des FTS12EM ist nun jedes Drücken und jedes Loslassen 
eines Tasters als Nachricht am Bus zu sehen. Die Nachricht besteht dabei 
aus zwei Synchronisationsbytes, einem Datalengthbyte, einem Nachrichten 
ID Byte, 4 Datenbytes, 4 Transmitter ID Bytes, einem Statusbyte und 
einem Quersummenbyte (Summe vom Datalengthbyte bis zum Statusbyte) zur 
Fehlererkennung. Durch Einspeisen solcher Nachrichten am RS485 Eingang 
des FTS12EM, welcher meiner Ansicht nach nur eine Bridge zum RS485 
Ausgang darstellt, kann nun jeder Tastendruck simuliert werden. Somit 
kann der Schaltaktor ein- bzw ausgeschaltet werden und der Dimmaktor 
auf- und abgedimmt sowie auch ein- und ausgechaltet werden. Zusätzlich 
gibt es fürs Dimmen noch ein sogenanntes Central Dimming Command, mit 
welchem der Dimmer direkt auf einen festen Helligkeitswert eingestellt 
werden kann. Entweder von 0-100% oder absolut von 0 bis 255. Ich bin 
derzeit noch auf der Suche nach einer Möglichkeit die Relais des FSA12 
Schaltaktors direkt über ein ähnliches Command zu schalten und eventuell 
auch den internen Zustand eines Aktors auszulesen.

Anbei noch der Schaltplan wie ich die Module zusammengeschaltet habe und 
wie der Aufbau ausgesehen hat. Wer sich für den detaillierten Aufbau des 
Protokolls interessiert oder mehr Informationen haben möchte einfach per 
PN melden!

Gruß Max

[Gerd (Gast)]

@Max
herzlichen Dank für diese Info.
Ist der Tastaktor und der Dimmaktor auch ohne PC anlernbar bzw. 
bedienbar?
Gruß Gerd

[Max M. (maxmustermann)]

@Gerd
Ja, der Aktor wird durch einen Drehschalter in den Lernmodus (LRN) 
gebracht und anschließend durch Betätigen des entsprechenden Tasters 
welche zugeordnet werden soll, eingelernt. Ich vermute, dass das 
Einlernen aber auch durch ein sogenanntes Teach-In Telegramm 
durchgeführt werden kann.

Gruß Max

[Ulrich (Gast)]

Gibt es schon neuigkeiten bezüglich des zurücklesens?

[Elyot (Gast)]

Zurücklesen ist nicht möglich. Selbst die Eltako-Software überwacht nur 
die gesendeten Befehle, muß also 24/7 laufen, damit sie synchron bleibt. 
Aktive Komponenten (Schaltuhr, Tastereingabemodule usw.) besitzen immer 
Bus-Ein- und Ausgänge. Das Signal wird nur durchgeschliffen. 
Idealerweise setzt man also einen µC zwischen das letzte Eingabemodul 
und das erste Schalt-/Dimmermodul und überwacht die Signale aktiv bzw. 
generiert diese selbst. Das Protokoll bekommt man zumindest teilweise 
auch direkt von Eltako.

Gruß Jan

[Max M. (maxmustermann)]

Hallo Jan,

ich bin soweit zu den selben Erkenntnissen gekommen wie du! Habe im 
Moment ein System am laufen, welches den Schaltzustand mitlogged und 
intern speichert. Was mich noch etwas stört ist die Synchronisation des 
Schaltzustandes. Eine Idee wäre z.B. beim Verlassen des Hauses das 
Zentral Aus (ZA) des Schaltaktors (z.B. FSA12) zu verwenden, dann kann 
man wenigstens sichergehn dass alles aus ist.

lg Max

[Elyot (Gast)]

Hallo Max,

in den Schaltaktor kann man ja auch Richtungstaster einlernen. Somit 
wird das entsprechende Relais nicht getoggelt, sondern kann gezielt 
geschaltet werden. Dein Logger sollte also nicht einfach die Signale der 
Tastermodule weiterreichen, sondern auf eigene Codes umsetzen. Dann 
kannst Du die Schaltzustände auch gezielt setzen. Nach Stromausfall 
setzt Du dann einfach eine gespeicherte Initialsequenz ab und hast einen 
definierten Zustand. Oder Du stellst den zuletzt gespeicherten Zustand 
wieder her. Ob letzteres sinnvoll ist, hängt auch von der Dauer des 
Stromausfalls ab. Nach 10 h ist es vielleicht schon hell und das Licht 
im Bad bleibt besser ausgeschaltet.
Ich lerne in meine Aktoren übrigens die Schaltercodes und die eigenen 
ein. Somit kann ich im Fehlerfall den RS485-Bus einfach direkt 
durchschalten (kleiner Schalter am "Master-Modul") und alles bleibt 
bedienbar. So kann ich auch noch nachträglich Änderungen an der 
Master-Software vornehmen und muß zwischenzeitlich nur auf 
Komfortfunktionen (Webinterface, Monitoring usw.) verzichten, kann aber 
alles normal weiterbenutzen.

Gruß Jan

[Max M. (maxmustermann)]

Hallo Jan,

ja das mit den Richtungstastern hab ich auch gelesen, jedoch noch nicht 
ausprobiert! Werd ich aber demnächst mal machen wenn ich wieder etwas 
mehr Zeit habe! Das mit mehreren Schaltercodes einlernen scheint mir 
eine gute Idee zu sein! Was hast du alles für Module im Einsatz? 
FTS12EM, FSA12 und FUD12?

lg Max

[Elyot (Gast)]

Ja, genau die Module habe ich im Einsatz und zusätzlich noch eine 
Schaltuhr FSU12.

[michaels (Gast)]

Kennt jemand einen Hutschienenbaustein der mit Galvanischer Trennung den 
Zustand einer 220V Leitung überprüft und diesen Status an einen 
Microsontroller übermitteln kann, z.B. über RS485 ?
Sowas hab ich bei Eltako bisher nicht finden können. Damit könnte man 
den Zustand der FSA's von Eltako sicher abfragen. Das Mitlesen des 
Busverkehrs birgt immer das Risiko daß mein Mikrocontroller und der FSA 
aus der Syncronität kommen.

Ist zwar auch kein Akt sich sowas zu bauen, aber ich habe die FSA12's 
benutzt um versicherungstechnisch auf der sicheren Seite zu sein, falls 
es doch mal zum Brand käme.

Michael

[ulrich (Gast)]

Und woher weißt du dass der Eingang nicht defekt ist?

[Jan X. (elyot)]

Laß nicht den FTS / die Funksensoren den Schaltimpuls senden, sondern 
Deinen µC. Damit bleibst Du sicher synchron.

Gruß Jan

[michaels (Gast)]

@ ulrich:
Dann hab ich sicher ein größeres Problem

@ Jan
Das Problem kann ja auf dem Bus liegen. Z.B. decodiert der FSA12 evtl. 
einen Befehl nicht richtig, weil es zu einer Kollision auf dem Bus 
gekommen ist. Oder das Signal ist am Ende der Busleitung nicht mehr ganz 
sauber und wird nicht immer zuverlässig erkannt. Zumindest für manche 
Lasten würd ich dann schon lieber eine Möglichkeit der Fernabfrage 
haben.
Es gibt auch manche Verbraucher, die sollen nur dann einzuschalten sein 
wenn eine bestimmte Bedingung erfüllt ist.

Gruß Michael

[Jan X. (elyot)]

michaels schrieb:
> Das Problem kann ja auf dem Bus liegen. Z.B. decodiert der FSA12 evtl.
>
> einen Befehl nicht richtig, weil es zu einer Kollision auf dem Bus
>
> gekommen ist.

Kollisionen sind eigentlich auf dem Bus ausgeschlossen. Die Aktoren sind 
alle rein passiv, empfangen also nur. Die Eingabemodule schleifen den 
Bus durch (per Software), so daß es immer nur 1 Sender geben kann. 
Klemmt man seine eigene Hardware an den Bus, sollte man ebenso 
verfahren.

michaels schrieb:
> Es gibt auch manche Verbraucher, die sollen nur dann einzuschalten sein
>
> wenn eine bestimmte Bedingung erfüllt ist.

Diese Bedingungen sollte Dein µC kennen, wenn nur er selbst die FSA 
schaltet. Ansonsten einfach noch ein FTS12 installieren und vom µC 
auswerten lassen. Aber damit bekommst Du nur die Pegeländerungen mit. Du 
mußt also auch hier den Bus überwachen und die Zustände speichern.

[Gerd (Gast)]

Hallo Max,
gibt es wo ein PDF mit den Befehlen, oder würdest du es mal posten?
LG Gerd

[Max M. (maxmustermann)]

Hallo Gerd,

mittlerweile hat Eltako informationen über den Telegrammaufbau 
öffentlich in den Eltako Funk Katalog gepackt. Der Katalog ist auf 
http://www.eltako.com/fileadmin/downloads/de/Katalog/eltako_funk_low_res.pdf 
zu finden und ab Seite 198 gehts los mit den Commands.

Hoffe es hilft dir weiter!
LG Max

[Robert L. (lrlr)]

zitat seite 194: "Die LED blinkt aufgeregt."

lol

[Helmut (Gast)]

Gibt es von jemanden eine Anbindung von den Eltako Geräten in den 
CAN-Bus von Hugo aus dem von Timo erwähnten Projekt?

Timo E. schrieb:
> Bitte schön:
>
> Beitrag "Anforderungssammlung CAN Hausbus mit PIC µC"
>
>
>
> Ich hoffe das ist so halbwegs gut formuliert.
>
>
>
> Grüße Timo
>
>
>
>     Beitrag melden | Bearbeiten | Löschen |

[Max M. (maxmustermann)]

Hallo Helmut,

ich habe so einen CAN Knoten in Betrieb, der die CAN Messages direkt auf 
den RS485 der Eltakos weiterleitet und umgekehrt. Ist im Prinzip nicht 
so aufwändig. Ich hab das mit einem PIC18F mit ECAN Modul, einem CAN 
Transceiver und einem RS485 Transceiver realisiert. Die Software leitet 
die Nachrichten dann weiter.

lg Max

[Helmut (Gast)]

Jo,
das habe ich auch:
PIC's als Schalterdosennodes und eine Zentrale mit den Relais, 
abgekupfert von dem Beitrag von Hugo.
Nur mit den Dimmern .......   hatte ich selbst schon mal mit Fet's 
gemacht, wie auf der Freebusseite vorgestellt.
Aber um es einigermaßen VDE Konvorm zu machen wollte ich es mal mit den 
Eltakomodulen versuchen.

Hättest Du mal so "reine" Befehlsfolgen für mich, speziell Dimmer, die 
zum Steuern auf den 485er Bus kommen? Hat keine Eile, ist Hobby :-)

Ich programmiere in Mikroebasic, iM die Anbindung des TouchTFT's an den 
CAN-Bus.
http://www.youtube.com/watch?v=1RDTWekhzto&feature=mfu_in_order&list=UL
Gruß Helmut

[Torsten (Gast)]

Hallo Max,
ich habe mir auch die entsprechenden Hutschienenelemente von Eltako mit 
dem RS485 Bus eingerichtet. Jetzt habe ich erstmal eine 
Basis-Funktionalität die ich über den RS485 Bus erweitern möchte.
Leider scheiter ich mit Hyperterminal bzw. FreeSerialPortMonitor den 
RS485 Bus abzuhören.
Welches Programm verwendest du dafür? Wie hast du es konfiguriert?
Ich habe einen USB-TO-RS485 Converter (PAUB003), dieser wird auch 
korrekt vom Windows7 erkannt.
Aber ich kann noch so viele Taster drücken, bei mir kommt kein 
RS485-Telegram im Programm an.
Wäre total nett, wenn du mir etwas Starthilfe geben könntest.
Danke und Gruß
Torsten

[Ulrich E. (ulrich_e)]

Wo greifst du das Signal ab? Du darfst das nicht am Eingang vom 
Tastermodul abgreifen.

[Torsten B. (torsten123)]

Nein, ich greife auf den RSA und RSB Ausgang nach dem Elkako-Taster 
Modul zu. Von der Verkabelung hänge ich wie die Eltako-Dimmer am RSA/RSB 
Bus.

[Robert L. (lrlr)]

warum hast du das so komisch angeschlossen?

Gnd und 9+ braucht man nicht

rein von der Beschriftung her hätte ich gesagt:

RSA würde ich bei A (T-)
RSB bei B (T+) anschließen

aber die Anleitung hilft das sicher weiter..


(ich hatte aber auch schon rs485 -> rs232 converter wo das die chinesen 
falsch beschriftet haben (also A und B vertauscht)

[SPSuser (Gast)]

auch wenn es schon ein paar Tage her ist, bei der Suche nach einem 
RS485-Hutschienendimmer bin ich nun auf diesen Thread gestoßen.

Ich möchte Eltako RS485 Dimmer über eine SPS ansteuern und bin etwas 
ratlos ob das was wird.
Meine Anliegen wäre, über RS485 einen Dimmwert vorzugeben auf den sich 
der Dimmer dann einstellt. Ich möchte keine Effekte wie 
Kinerzimmerschaltung, Memoryeffekte etc. Hat das jemand von euch 
hingekriegt?

Die zweite Frage wäre das Protokoll: hat es jemand von euch die 
RS485-Eltako-Dimmer im Einsatz und steuert die über SPS oder uP 
erfolgreich an?

Vielen Dank für wertvolle Tipps!

[Thomas T. (thomas_t33)]

Hallo,

habe die Eltako RS485 Dimmer FUD12NPN im Einsatz. Funktioniert soweit 
sehr gut und zuverlässig. Das Protokoll ist bekannt, wenn du willst kann 
ich Dir Dateien mit Details zusenden. Die Ansteuerung mache ich über 
eine selbst entwickelte uC Platine, die über CAN mit einem Server 
verbunden ist, auf dem openHAB läuft.

Grüße Thomas

[H. F. (forellengarten)]

Thomas T. schrieb:
> Hallo,
>
> habe die Eltako RS485 Dimmer FUD12NPN im Einsatz. Funktioniert soweit
> sehr gut und zuverlässig. Das Protokoll ist bekannt, wenn du willst kann
> ich Dir Dateien mit Details zusenden. Die Ansteuerung mache ich über
> eine selbst entwickelte uC Platine, die über CAN mit einem Server
> verbunden ist, auf dem openHAB läuft.
>
> Grüße Thomas


Hallo Thomas,

das wäre eine Riesenhilfe! Danke. (siehe PM)

[Thomas T. (thomas_t33)]

Hallo,

habe das angefügte Dokument von einen anderen User aus dem Forum 
bekommen, habe damit in meinem Hausbaus die Ansteuerung hinbekommen.

Steuere damit derzeit bis zu 4 Dimmer an einem Bus an, es sollten aber 
noch viel mehr möglich sein (4 Byte SenderID). Wichtig ist, dass man für 
jeden Dimmer eine eigene Sender-ID einlernt.

Grüße Thomas

[Andreas S. (emc2)]

> Ich habe einen USB-TO-RS485 Converter (PAUB003), dieser wird auch
> korrekt vom Windows7 erkannt.
> Aber ich kann noch so viele Taster drücken, bei mir kommt kein
> RS485-Telegram im Programm an.

diesen USB-TO-RS485 Converter hatte ich auch und es war unmöglich damit 
meinen Bus abzuhören/zu steuern. Habe da immer nur wirre Zeichen 
empfangen, jedoch wusste ich, dass es funktioniert, da die Controller 
untereinander problemlos kommunizierten.

Der einzige wirklich perfekt funktionierende Aufbau für USB => UART => 
RS485 war für mich die Kombination aus FT232RL-Chip (da gibts bei ebay 
gute Angebote ab 6 Euro) und MAX487 (bzw MAX485)-Chip

[Robert L. (lrlr)]

oder man kauft es fix-fertig ?

http://www.ebay.de/itm/DIGITUS-USB-2-0-auf-Seriell-Adapter-DB9-Serial-RS232-Nullmodem-RS485-/261050884380?pt=DE_Computing_Parallel_Seriell_PS_2&hash=item3cc7d8611c

[Andreas S. (emc2)]

auch eine Möglichkeit, nur gibt es diese nicht mit MAX487 Chips, aber 
für "Torsten" wirds wohl funktionieren!

[forellengarten (Gast)]

Hsbe mir eben diesen bestellt "USB-RS485 USB to RS485 Interface Module" 
und kann in ein paar Wochen berichten, momentan habe ich aber noch keine 
passende Eltako-Hardware dafür.

Momentan tun sich mir noch ein paar Fragen auf und wäre sehr dankbar 
wenn vielleicht jemand ein paar Antworten bei der Hand hätte:

 - was ist der Unterschied zw. FUD12 und FUD14. Scheinen beide sehr 
ähnlich zu sein

 - Ich habe intensiv die Arbeit von J.Fritsche studiert. Ich komme 
einfach nicht dahinter wie genau die Checksumme errechnet wird. Könnte 
mir da jemand weiterhelfen?

 - Stichwort anlernen: wie genau funktioniert das und was passiert 
dabei? Der Eltako wird auf LRN gestellt - was muß ich dann für Daten 
senden?

 - Wie funktioniert die Adressierung. Ich meine, wie sage ich dem 
Eltako-Dimmer Nr. 4 daß er gemeint ist und nicht ein anderer.

Ich möchte wirklich nicht die mühselig erarbeiteten Programmzeilen von 
jemand klauen - doch wenn wer ein paar rohentwurf-Programmzeilen oder 
Beispiele bei der Hand hätte wäre ich dafür sehr dankbar.

Vielen Dank,
Forellengarten

[Max M. (maxmustermann)]

Hallo forellengarten,

forellengarten schrieb:
> - Ich habe intensiv die Arbeit von J.Fritsche studiert. Ich komme
> einfach nicht dahinter wie genau die Checksumme errechnet wird. Könnte
> mir da jemand weiterhelfen?

schön dass du es gelesen hast! Die Checksum wird durch einfaches 
Aufsummieren der Datenbytes berechnet, z.b. bei "A5 5A 0B 05 70 00 00 00 
00 00 00 0B 00 8B" einfach "0B 05 70 00 00 00 00 00 00 0B 00" byteweise 
aufsummmieren und du erhälst 0x8B.

>
>  - Stichwort anlernen: wie genau funktioniert das und was passiert
> dabei? Der Eltako wird auf LRN gestellt - was muß ich dann für Daten
> senden?
Schau am besten mal in die Bedienungsanleitung von einem Eltako Modul. 
Das ausgewählte Modul auf LRN setzten und dann das Telegramm für einen 
Tastendruck senden. Dann ist das Modul eingelernt und blinkt einmal kurz 
auf.

>
>  - Wie funktioniert die Adressierung. Ich meine, wie sage ich dem
> Eltako-Dimmer Nr. 4 daß er gemeint ist und nicht ein anderer.

Beim Einlerntelegramm sendest du ein ID Byte mit (ID_BYTE0). Den genauen 
Aufbau des Telegramms findest du im pdf.

Hoffe ich konnte dir weiterhelfen!

Gruß,
MAX

[Forellengarten (Gast)]

> Die Checksum wird durch einfaches
> Aufsummieren der Datenbytes berechnet, z.b. bei "A5 5A 0B 05 70 00 00 00
> 00 00 00 0B 00 8B" einfach "0B 05 70 00 00 00 00 00 00 0B 00" byteweise
> aufsummmieren und du erhälst 0x8B.

Klaro, geht jetzt. Die ersten ZWEI Bytes werden nicht in die Checksumme 
aufgenommen. Danke!

> Schau am besten mal in die Bedienungsanleitung von einem Eltako Modul.
> Das ausgewählte Modul auf LRN setzten und dann das Telegramm für einen
> Tastendruck senden. Dann ist das Modul eingelernt und blinkt einmal kurz
> auf.

Will ich lediglich erreichen, dass mein Eltako nach SPS-Vorgabe einen 
bestimmten Dimmwert ansteuert, so würde ich dann vermutlich wie folgt 
vorgehen(?): 1) -Eine Taste wird angelernt.
             2) -Zum Dimmen gaukle ich dann dem FUD einen Tastendruck 
mit gewünschten Dimmwert/Dimmgeschwindigkeit vor. Das wars.


> Beim Einlerntelegramm sendest du ein ID Byte mit (ID_BYTE0). Den genauen
> Aufbau des Telegramms findest du im pdf.

Danke Max, mir ist nun wieder einiges klarer. Vielen Dank!

[Max M. (maxmustermann)]

Forellengarten schrieb:
> Will ich lediglich erreichen, dass mein Eltako nach SPS-Vorgabe einen
> bestimmten Dimmwert ansteuert, so würde ich dann vermutlich wie folgt
> vorgehen(?): 1) -Eine Taste wird angelernt.
>              2) -Zum Dimmen gaukle ich dann dem FUD einen Tastendruck
> mit gewünschten Dimmwert/Dimmgeschwindigkeit vor. Das wars.

exakt! beim Einlernen wird dem Modul mitgeteilt auf welche IDs es 
künftig hören soll.

Gruß,
Max

[Robert B. (robertb)]

Da hier im Thread ja auch einige den Eltako LUD12-230V verwenden: 
Beitrag "[V] 2x Eltako LUD12-230V Leistungszusatz 500W"

[forellengarten (Gast)]

Max Mustermann schrieb:
> Forellengarten schrieb:
>> Will ich lediglich erreichen, dass mein Eltako nach SPS-Vorgabe einen
>> bestimmten Dimmwert ansteuert, so würde ich dann vermutlich wie folgt
>> vorgehen(?): 1) -Eine Taste wird angelernt.
>>              2) -Zum Dimmen gaukle ich dann dem FUD einen Tastendruck
>> mit gewünschten Dimmwert/Dimmgeschwindigkeit vor. Das wars.
>
> exakt! beim Einlernen wird dem Modul mitgeteilt auf welche IDs es
> künftig hören soll.
>
> Gruß,
> Max

wow, 3xFUD12NPN über RS485 und HTERM. und nach senden des ersten Codes 
geht auf Anhieb die Lampe an. Da freut sich doch Edison :-).
Es wird weitergeforscht. Vielleicht hat ja jemand eine Antwort bei der 
Hand und kann mir so endlose String-Eingaben in HTERM ersparen.
Die Frage: Muß einem Tastendruck einem Taste Loslassen folgen? Würde 
sonst immer nur einfach einen Tastendruck mit dem gewünschten Dimmwert + 
Dimmgeschwindigkeit senden. Oder klappt die logik so nicht?

[forellengarten (Gast)]

ok, sieht so aus als bräuchte jeder Tastendruck ein Tasten-Loslassen, 
damit wieder weitere Befehle angenommen werden.

Sonst komme ich momentan nicht so richtig weiter: Ich habe bisher 
folgendes gemacht: Anlernen im Modus 3 (Universcaltaster ein/aus und 
dimmen).

Mit jedem über HTERM simulierten Tastendruck(und loslassen) dimmt der 
Dimmer, jeweils in die andere Richtung. Momentan fehlt mir noch der Plan 
warum es kein Ausschalten gibt und wie ich Ihm sagen soll einen 
bestimmten Dimmwert anzufahren.... Vielleicht hat wer schnell die 
entscheidende Info bei der Hand.

danke.

[Thomas T. (thomas_t33)]

Es gibt ein Kommando für die Ansteuerung aus der Eltako-Software. Damit 
sollte es gehen, Details anbei.

VG Thomas

[forellengarten (Gast)]

Thomas T. schrieb:
> Es gibt ein Kommando für die Ansteuerung aus der Eltako-Software. Damit
> sollte es gehen, Details anbei.
>
> VG Thomas

Danke Thomas,
nach dieser Vorlage probiere ich es ja, aber es klappt irgendwie nicht.

Meine Vorgehensweise:
Im LRN-Modus Nr. 3 schicke ich folgenden Code:

A5 5A 0B 05 02 00 00 00 00 00 00 0B 00 1D
bisher scheint es noch zu funktionieren. Aber dann sende ich zum Dimmen:

(dimmer an, 100%, max dimmspeed)
A5 5A 0B 07 02 64 01 09 00 00 00 0B 00 8D
hier passiert jedoch nichts. andere Versuche sind auch gescheitert. Wo 
liegt der Fehler oder hättest du evtl. ein Beispiel das funktioniert?

Danke!

[unknown (Gast)]

Hallo,

hat die Serie 14 von Eltako das gleiche Protokoll?

[Thomas T. (thomas_t33)]

Versuch es mal mit
A5 5A 0B 07 02 64 01 0F 00 00 00 0B 00 93

VG Thomas

[H. F. (forellengarten)]

Thomas T. schrieb:
> Versuch es mal mit
> A5 5A 0B 07 02 64 01 0F 00 00 00 0B 00 93

Hallo Thomas,
vorweg, geht nicht. Deine 0F kommen von JohannesFritsche, meine 09 aus 
dem Eltako-Datenblatt. Scheint aber egal zu sein weil es nur um ein Bit 
geht und das wird beidemale gesetzt.

Könnte vielleicht noch jemand den Ablauf checken ob da wo der Hund 
drinnen steckt:
1) Eltako komplett gelöscht.
2) Eltako LRN auf "3", und wie oben folgenden Code gesendet:
   A5 5A 0B 05 02 00 00 00 00 00 00 0B 00 1D
   LED hört auf zu blinken => Code angenommen
   Angeschlossene Lampe ist aus
3) Drehschalter raus aus dem LRN-Modus
4) Folgenden Code gesendet (wie oben):
   A5 5A 0B 07 02 64 01 09 00 00 00 0B 00 8D
   keine Funktion. Danach von Thomas
   A5 5A 0B 07 02 64 01 0F 00 00 00 0B 00 93
   auch keine Funktion.

Was funktioniert:
   Anlernen einen Taster Drückens im Mode 3. Danach Auf.- und Abdimmen
   durch simuliertes Drücken/Loslassen.

[H. F. (forellengarten)]

Ist es eigentlich korrekt den FUD12 mit dem ORG-Byte 05 anzulernen. 
Müßte eigentlich 07 sein. Allerdings nimmt der Eltako dann meine 
Zeichenfolge im Lernmodus garnicht an.

Help me if you can!

[unknown (Gast)]

H. Forellengarten schrieb:
> Thomas T. schrieb:
>> Versuch es mal mit
>> A5 5A 0B 07 02 64 01 0F 00 00 00 0B 00 93
>
> Hallo Thomas,
> vorweg, geht nicht. Deine 0F kommen von JohannesFritsche, meine 09 aus
> dem Eltako-Datenblatt. Scheint aber egal zu sein weil es nur um ein Bit
> geht und das wird beidemale gesetzt.
>
> Könnte vielleicht noch jemand den Ablauf checken ob da wo der Hund
> drinnen steckt:
> 1) Eltako komplett gelöscht.
> 2) Eltako LRN auf "3", und wie oben folgenden Code gesendet:
>    A5 5A 0B 05 02 00 00 00 00 00 00 0B 00 1D
>    LED hört auf zu blinken => Code angenommen
>    Angeschlossene Lampe ist aus
> 3) Drehschalter raus aus dem LRN-Modus
> 4) Folgenden Code gesendet (wie oben):
>    A5 5A 0B 07 02 64 01 09 00 00 00 0B 00 8D
>    keine Funktion. Danach von Thomas
>    A5 5A 0B 07 02 64 01 0F 00 00 00 0B 00 93
>    auch keine Funktion.
>
> Was funktioniert:
>    Anlernen einen Taster Drückens im Mode 3. Danach Auf.- und Abdimmen
>    durch simuliertes Drücken/Loslassen.

Hallo,

ich würde nach Studium der mir zur Verfügung stehenden Doku vermuten das 
die mit dieser Nachricht A5 5A 0B 07 02 00 00 00 00 00 00 0B 00 1F 
angelernt werden muss.

Allerdings würde ich behaupten das in dem Datenblatt das bei deinem 
FUD12 mitgeliefert wurde steht das du dazu LRN auf "8" gestellt werden 
muss statt auf "3"

Gruß

[H. F. (forellengarten)]

> ich würde nach Studium der mir zur Verfügung stehenden Doku vermuten das
> die mit dieser Nachricht A5 5A 0B 07 02 00 00 00 00 00 00 0B 00 1F
> angelernt werden muss.
>
> Allerdings würde ich behaupten das in dem Datenblatt das bei deinem
> FUD12 mitgeliefert wurde steht das du dazu LRN auf "8" gestellt werden
> muss statt auf "3"

Da gebe ich dir Recht, laut Doku würde ich auch das ORG-Byte auf 07 
stellen. Allerdings wie ich es auch mache, das Einlernen funktioniert 
dann nicht.

Habe soeben mal den von dir vorgeschlagenen LRN-Mode "8" getestet. Geht 
auch nicht. Laut Bedienungsanleitung des FUD12 gilt:"...Die Positionen 6 
bis 10 sind nicht belegt".

[hauptschalter (Gast)]

Hallo,

ich habe im Internet diese Anleitung für den FUD12 gefunden.

Bei dem gibt es den LNR 8.

Zitat:
8 = Einlernen eines PC mit der Funk-Visualisierungs-
Software FVS. Die prozentuale
Helligkeit kann dort zwischen 0 und 100
Prozent eingestellt und gespeichert werden.
Mehrere Dimmschalter können zu Lichtszenen
verknüpft werden.

Vielleicht bedeutet das das Dein FUD12 diese Funktion gar nicht hat.

Poste doch mal Deine Anleitung des FUD12 denn anscheinend hast du eine 
andere Version als ich hier im Internet gefunden hab.

Gruß

[unknown (Gast)]

Hallo,

hab hier noch ein weiteres Datenblatt gefunden.

Laut diesem Datenblatt gibt es LRN 6-10 nicht.

Der kann wohl tatsächlich diese Art des Dimmens nicht.

Der Unterschied ist dabei das wohl wirklich 2 verschiedene FUD12 mit 
unterschiedlichen Bestellnummern gibt.

Gruß

[Robert L. (lrlr)]

im PDF von "hauptschalter" ist ja auch eine Skizze
dort gibt es aber keine 8  (im Gegensatz zur Beschreibung)
irgendwie "chaotisch"

[H. F. (forellengarten)]

Jungs (und Mädels), es gibt Antworten.

Vorerst danke an die Vorredner. Und den Hinweis mit den verschiedenen 
Bedienungsanleitungen. Ich habe jetzt kurzer Hand bei Eltako angerufen 
und möchte mal die wesentlichen Infos weitergeben:

Am FUD12 wird immer weitergearbeitet, entsprechend gibt es mehrere 
Software-Versionen. Man braucht mindestens Herstellungsdatum 2010, 
ansonsten kann das Protokoll für fixe Dimmwerte nicht eingelernt werden 
(ORG=0x07). Da scheitert meiner schon mal, denn der wurde vermutlich 
2008 hergesetellt (Datum der Bedienungsanleitung). Im Übrigen haben alle 
FUD12 die gleiche Bestellnummer, egal ob alt oder neu.

Was das angeht verabschiede ich mich für ein weilchen aus dem Forum, bis 
andere Hardware am Tisch liegt und neue fragen auftauchen :-)

Und weil oben "Gast" fragt bezüglich Kompatibilität zu FUD14, und ich da 
auch tausend Fragezeichen im Kopf habe:
Der FUD14 ist laut Aussage des Technikers kompatibel zu FUD12, hat 
jedoch Steckbrücken, und muß daher nicht so aufwendig querverdrahtet 
werden. Zum Einspeisen des Signals braucht man dann den FBA14. Der hat 
keine Elektronik drinnen, sondern ist lediglich der mechanische Übergang 
vom Drahtanschluß auf das "Brückensystem". Soweit ich in der Anleitung 
gesehen habe enthält der FUD14 auch Distanzhalter, Brücken etc., sodaß 
ich persönlich dann wohl eher zum FUD14 greifen werde.  Grundsätzlich 
ist der FUD14 ein verbesserter FUD12, kann noch viel mehr, was man aber 
nicht braucht wenn man direkt auf den RS485-Bus Daten schickt. Der Preis 
FUD12 und FUD14 ist außerdem gleich.

Hoffe ich kann mich mit diesen Infos für Eure Hilfe revanchieren.

[Ulrich (Gast)]

Baureihe 12 und Baureihe 14 können nicht miteinander kompatibel sein, 
ansonsten gäbe es zwischen diesen Systemen keinen Gatewaybaustein.

Kennt jemand die Baudrate von Baureihe 14?

[rk (Gast)]

"Mit 6-facher Taktrate des neuen RS485-Bus werden ein gehende und 
ausgehende Informationen wesentlich schneller verarbeitet."

6*9600=57600

[Jan X. (elyot)]

Auch wenn der ursprüngliche Beitrag schon älter ist, hier mal eine 
Rückmeldung.
Die 12er Serie von Eltako (vermutlich aber auch die 14er) wird von FHEM 
unterstützt. Läuft bei mir inzwischen auf einem TL-WR703N unter OpenWRT 
auch ohne CUL/TCM-Modul. Anbindung an den RS485-Bus erfolgt mit 
Pegelwandler (z.B. LT485) und FTDI-Kabel. Benötigt komplett nur 2-3 
Teilungseinheiten auf der Hutschiene, Leistungsaufnahme ohne WLAN unter 
1W. Durch einen RS485-Bypass (Schalter) kann ich FHEM komplett 
deaktivieren, da alle Lichtschalter etc. auch direkt in die Aktoren 
eingelernt sind. Mit AndFHEM steht auch ein kostenloses Frontend für 
Smartphones/Tablets zur Verfügung. Alternativ ist auch die Bedienung 
über Webfrontend möglich.
FHEM läuft übrigens auch auf einigen Fritzboxen.

[anonym (Gast)]

Ich verwende die FUD14-Dimmer uns spreche diese von einer SPS aus direkt 
an (über eine RS485-Schnittstelle). Funktioniert tadellos und ist das 
beste was ich bisher an Dimmern eingebaut hatte.

[Helmut (Gast)]

@Jan,
ist FHEM dann auf dem TP-Link drauf?

Gruß Helmut

[joE (Gast)]

@anonym

Interessant, welche SPS verwandtest du und wie läuft da die 
Kommunikation ? Resp. das Protokoll ?

Danke für die Infos.

[anonym (Gast)]

@joE

hallo joE, ich verwende eine Beckhoff-SPS mit einer RS485-Schnittstelle 
(KL6041-Klemme). Ein Max485 an einem uP funktioniert ebenso problemlos.

Bezüglich Protokoll hatte ich viel mit Eltako kommuniziert. Allerdings 
dort von verschiedenen Stellen viel unterschiedliche und unrichtige Info 
erhalten. Verwendet wird letztendlich das EnOcean-Protokoll, welches du 
aus dem Netz beziehen kannst. Such dort den Punkt "2.5.3 Description of 
serial data structure" -> genau hier steht der verwendete 
Protokollaufbau (Beginnt immer mit A5-5A-.... . Jetzt hast du das 
Protokoll, aber welche Daten mußt du senden? Dazu holst du dir von 
Eltako das PDF der FUD14-Dimmers. Dort oder irgendwo im technischen 
Anhang stehen die Infos was die einzelnen Bytes für Infos enthalten 
müssen. Eine Stolperfalle ist auch die Baudrate der FUD14. Sie werden 
(glaube ich) 5x schneller getaktet als die FUD12. Daher sind die auch 
gemeinsam nur zu betreiben mit einem Eltako-Koppler dazwischen.

So, hoffe das hilft dir und ich hab nicht allzuviel Blödsinn 
geschrieben. Ist schon eine Weile her dass ich mich damit beschäftigt 
habe. Wie erwähnt kann ich diese Dimmer 100% empfehlen. Wenns mal 
garkein Weiterkommen mehr gibt kann ich dir evtl. auch per Tel 
weiterhelfen.

[joE (Gast)]

@anonym

danke für deine Ausführung. Ich hab eine CX9001 im Einsatz. Hättest du 
interesse, deinen Code hier zu posten?

Ich danke dir!

[Jan X. (elyot)]

@Helmut
Ja, fhem läuft auf dem TP-Link. Ich wollte ja extra einen möglichst 
kleinen Rechner mit minimaler Leistungsaufnahme. Zudem sind die TP-Link 
mit unter 20€ (frei Haus) auch noch sehr günstig.

[anonym (Gast)]

joE schrieb:
> @anonym
>
> danke für deine Ausführung. Ich hab eine CX9001 im Einsatz. Hättest du
> interesse, deinen Code hier zu posten?
>
> Ich danke dir!

Sorry, dieses Interesse besteht nicht. Du hast nun wirklich viele Tipps 
gekriegt und deine Copy-Paste-Anfrage ist schon sehr dreist von dir. 
Scheinbar haben dich die Infos hier aus diesem Threat und meine Infos 
nicht sonderlich interessiert. Hol dir eine Firma die das ganze für dich 
erledigt.

[joE (Gast)]

War ja nur eine Frage, ich hätte jedenfalls den Code gepostet, falls er 
von mir geschrieben wurde.

Aber ist ok, ich danke dir für deine Erklärungen.

[Max H. (mh182)]

Hallo an alle,

mein erstes Post hier :-)

Nach langem herumprobieren habe ich es endlich geschafft und ich kann 
meine FUD14/FSG14 über mein Raspberry Pi via USB/RS485 dimmen.

Jetzt meine Gretchenfrage: kann ich den gespeicherten Dimmwert ändern, 
ohne zu dimmen?

Was ich bereits versucht habe, ist den Dimmwert mit einem Aus-Telegram 
zu setzen. Das funktioniert aber nicht.

Meine Idee war meiner "dummen" Eltako-Anlage ein bischen übergeordnete 
Intelligenz einzuhauchen. Beispiel: ab Mitternacht (bis Sonnenaufgang) 
sollen die von den Bewegungssensoren gesteuerten Ganglichter (zum Klo) 
auf 30% gedimmt werden.

Die einzige Möglichkeit die ich bis jetzt gefunden habe ist die 
Beleuchutung kurz auf 30% einzuschalten, dann wieder ausschalten. Finde 
das aber nicht als sehr elegant.

Habt ihr eine andere Idee, wie ich das machen könnte.

lg Max

[Grafiksucher (Gast)]

Hallo,

von der Logik her würde ich sagen Du bekommst doch von den 
Bewegungssensoren das Telegramm Ein.

Dann brauchst Du das doch nur auszuwerten, zu schauen wie viel Uhr es 
ist und eine Dimm-Telegramm mit 30% oder 100% hinterherzuschicken.

Ausprobiert habe ich das noch nicht, bei mir steht das ganze in Kürze 
erst auch noch an.

Gruß

[Max H. (mh182)]

Werde ich ausprobieren und checken, wie schnell die 30% den 100% 
nachfolgen (reagieren).

Sinn und Zweck ist ja, dass ich in der Nacht nicht den "Scheinwerfer" 
ins die Augen bekomme. Mal sehen wie ich das warnehme, wenn das ganze 
bei 100% einschaltet und ich dann auf 30% runterdimme.

Aber die Idee ist schon mal gut. Hat mir geholfen. Danke

lg Max

[egal (Gast)]

vielleicht versteh ich's ja falsch:

du musst den Dimmer nicht auf 100% einschalten. Du kannst ihm einfach 
30% als Dimmwert senden und das wars. Für den Dimmer bedeutet das 
einfach von 0 auf 30% aufdimmen.

[egal (Gast)]

und noch was, für den Fall dass du etwas umständlich unterwegs sein 
solltest (evtl. hab ich deinen Beitrag auch nicht genau genug gelesen): 
Das einzige was du brauchst ist ein FUD14, sonst nichts (also auch kein 
FSG14 oder was auch immer). Du steuerst den FUD14 einfach direkt über 
eine x-beliebige RS485-Schnittstelle an. Einfach den Dimmwert auf den 
FUD14 senden und staunen.

[Grafiksucher (Gast)]

Max H. schrieb:
> Werde ich ausprobieren und checken, wie schnell die 30% den 100%
> nachfolgen (reagieren).

Musst halt schauen das Du die Dimm-Geschwindigkeit auf Maximum stellst.


egal schrieb:
> vielleicht versteh ich's ja falsch:
>
> du musst den Dimmer nicht auf 100% einschalten. Du kannst ihm einfach
> 30% als Dimmwert senden und das wars. Für den Dimmer bedeutet das
> einfach von 0 auf 30% aufdimmen.

egal schrieb:
> und noch was, für den Fall dass du etwas umständlich unterwegs
> sein
> solltest (evtl. hab ich deinen Beitrag auch nicht genau genug gelesen):
> Das einzige was du brauchst ist ein FUD14, sonst nichts (also auch kein
> FSG14 oder was auch immer). Du steuerst den FUD14 einfach direkt über
> eine x-beliebige RS485-Schnittstelle an. Einfach den Dimmwert auf den
> FUD14 senden und staunen.

Sorry aber Du hast das Problem wohl grundsätzlich falsch verstanden.

Max hat einen Bewegungsmelder der ihm ein Telegramm Ein schickt sobald 
er eine Bewegung erkannt hat. Im Dimmer FUD14 ist der Dimmwert 
hinterlegt der aber vom Bewegungsmelder nicht geändert werden kann.


Wenn ich jetzt im Katalog richtig geschaut hab hat der FUD14 spezielle 
Funktionen (Lichtszenensteuerung, Konstantlichtregelung, 
Lichtweckschaltung, Kinderzimmerschaltung und Schlummerschaltung gemäß 
Bedienungsanleitung). Um die mit Dämmerungsschalter und Bewegungsmelder 
kombiniert zu nutzen muss man wohl mal genau ins Datenblatt schauen.

Ich muss mir wohl mal schnellstens die ersten Eltako-Geräte zum testen 
bestellen.


Gruß

[Max H. (mh182)]

Grafiksucher schrieb:
> Sorry aber Du hast das Problem wohl grundsätzlich falsch verstanden.
>
> Max hat einen Bewegungsmelder der ihm ein Telegramm Ein schickt sobald
> er eine Bewegung erkannt hat. Im Dimmer FUD14 ist der Dimmwert
> hinterlegt der aber vom Bewegungsmelder nicht geändert werden kann.
>
>
> Wenn ich jetzt im Katalog richtig geschaut hab hat der FUD14 spezielle
> Funktionen (Lichtszenensteuerung, Konstantlichtregelung,
> Lichtweckschaltung, Kinderzimmerschaltung und Schlummerschaltung gemäß
> Bedienungsanleitung). Um die mit Dämmerungsschalter und Bewegungsmelder
> kombiniert zu nutzen muss man wohl mal genau ins Datenblatt schauen.

Exakt, das ist meine Situation. Der Bewegunsgsmelder sendet das "schalt 
dich ein", der Dimmwert ist im FUD14 hinterlegt. Und diesen Dimmwert 
kann ich nur ändern, wenn das FUD14 eingeschaltet ist.

Ich benutzte die obgenannten "Special Features" des FUD14 eigentlich 
nicht.

Die Diskussion hat mich auf 2 weitere Ideen gebracht:
* ich fahre grundsätzlich auf 30% und erhöhe auf 100%, wenn ich im 
Normalbetrieb bin (früh Abendes). Dann umgehe ich das Problem, dass ich 
zuerst hell habe und abdunkle.
* ich schaue mir einmal die Lichtszenen an. Vielleicht ist der Dimmwert 
pro Lichtszene hinterlegt und ich kann meine 2 Szenarien über die 
Lichtszenen steuern.

Bevor ich aber weitertesten kann, werde ich mir mal erst einen kleien 
Daemon schreiben, das das Protokoll ausliest und das ganze steuert.

Danke für die Diskussion.

lg Max

[Frank H. (fh_)]

Kennt jemand die Pinbelegung der 4Pin Brücke vom Eltako FUD14 ?
Gruß
Frank

[elTacco (Gast)]

Zuerst einmal, ein GROSSES Dankeschön (!) an die ersten, die diese 
Eltako Dimmer unter die Lupe genommen haben!!!

Zunächst einmal zu meinem Kenntnisstand bzgl. des Eltakosystems, alles 
was ich weiß ist rein theoretisch hier aus dem Forum und natürlich die 
Dokumentationen von Eltako.

egal schrieb:
> Das einzige was du brauchst ist ein FUD14, sonst nichts (also auch kein
> FSG14 oder was auch immer). Du steuerst den FUD14 einfach direkt über
> eine x-beliebige RS485-Schnittstelle an. Einfach den Dimmwert auf den
> FUD14 senden und staunen.

Hast du das so realisiert?

Ich frage deshalb, weil in der Beschreibung immer ein FAM14 bzw. FTS14KS 
vorangestellt wird. Das verwirrt alles!

laut 'egal' muss/kann man das so anschließen:


 ,-->[µC mit RS485]
|
|
|
+-->[Eltako-RS485-Bus: z.B. FTS14EM]
|
|
|
+-->[Eltako-RS485-Bus: z.B. FUD14]
|
|
|
`-->[Eltako-RS485-Bus: weitere Geräte der 14er Serie]



ist das richtig?
Oder muss wirklich ein FAM14 vorangeschaltet sein?

Wie sieht es aus mit den Anschlüssen:
da sind ja spezielle Anschlüsse für Spannungsversorgung und den Bus, die 
'normalen' Geräte-Brücken sind soweit ich verstanden habe mit einem 
Gerät dabei.
- Wie habt ihr die Verbindung zum µC hergestellt?
- Und die Abschlusswiderstände 120 Ohm am Anfang und am Ende?



Ich weiß das sind viele Fragen, vielleicht hat jemand (oder mehrere) 
Zeit einige oder auch alle :-) zu beantworten.

Ich wäre sehr dankbar für eure Hilfe!!!

[elTacco (Gast)]

edit:

elTacco schrieb:
> - Wie habt ihr die Verbindung zum µC hergestellt?

Oder habt ihr den Busankoppler FBA14 benutzt siehe Skizze(Var1),
zur Einspeisung der 12VDC mittels eines Netzteils und
zur Anbindung an den Bus

Eine andere Möglichkeit gäbe es wenn man den Draht-Brückenverbinder 
BBV14 auftrennt und ihn laut Skizze(Var2) anschließt.

Die Farben der Drahtbrücke ist bei meinen Skizzen müssen nicht 
übereinstimmen, weil ich es nur willkürlich angenommen habe, so dass
Frank H. schrieb:
> Kennt jemand die Pinbelegung der 4Pin Brücke vom Eltako FUD14 ?

immer noch ein Thema ist

[Lars S. (kallipeter)]

>Kennt jemand die Pinbelegung der 4Pin Brücke vom Eltako FUD14 ?
>Gruß
>Frank

Hi Frank,

ich habe vor etwa einem Jahr vom Eltako Service das angehängte Bild 
bekommen. Als Hinweis dazu:

*ACHTUNG: Wenn RSA/RSB mit +12V/GND vertauscht werden, werden die 
RS485-Treiber in den Geräten zerstört!*

[elTacco (Gast)]

Danke für die Pinbelegung!

[Max H. (mh182)]

elTacco schrieb:
> Hast du das so realisiert?
>
> Ich frage deshalb, weil in der Beschreibung immer ein FAM14 bzw. FTS14KS
> vorangestellt wird. Das verwirrt alles!
Ich hatte (habe) das gleiche Problem wie du. Ich habe nicht verstanden, 
wie ich meinen Rechner (RasPi) an den RS485 anschließen soll.

Da ich in meiner Installation ein FAM14 habe (hat ein USB Port), habe 
ich gemerkt, dass ich alle Telegramme über den USB Port abfragen/senden 
kann. Somit hat sich mein Problem damit gelöst, indem meine Installation 
so aussieht:

RasPi ---(USB)---> FAM14 ---(RS485)--> FUD14 ---> FUD14 ---> FSB14 ---> 
...

>
> laut 'egal' muss/kann man das so anschließen:
>
>
>  ,-->[µC mit RS485]
> |
> |
> |
> +-->[Eltako-RS485-Bus: z.B. FTS14EM]
> |
> |
> |
> +-->[Eltako-RS485-Bus: z.B. FUD14]
> |
> |
> |
> `-->[Eltako-RS485-Bus: weitere Geräte der 14er Serie]
>
>
> ist das richtig?
Falls du die Antwort darauf findest, bitte posten, weil mich das selber 
interessieren würde.

> Oder muss wirklich ein FAM14 vorangeschaltet sein?
Solange du keine Funktelegramme senden/empfangn willst, brauchst du kein 
FAM14.

lg Max

[elTacco (Gast)]

Laut Beschreibung kann man den PC mit FAM14 per USB anschließen und über 
die mittgelieferte Software PCT14 programmieren, steuern, und Zustände 
auslesen.

Max H. schrieb:
> Da ich in meiner Installation ein FAM14 habe (hat ein USB Port), habe
> ich gemerkt, dass ich alle Telegramme über den USB Port abfragen/senden
> kann.

Das ist sehr interessant, mich interessiert vor allem wie die 
Kommunikation zustande kommt. Für mich hört es sich so an:
- einerseits hast du die Software auf dem RasPi installiert (was ich
  nicht glaube, aber möglich wäre es bestimmt)
- andererseits findet die Kommunikation via 'virtuellem Com-Port' statt,
  sodass du die Telegramme einfach per serielle Schnittstelle versenden
  kannst also bspw.:

       [µC: UART]<-->[FTDI]<---+
                               |
                             (USB)
                               |
   +-->[FAM14]<----------------+
   |
(RS485)
   |
   +-->[FTS14EM]
   |
   |
   |
   +-->[FUD14]
   |
   |
   |
   +-->[weitere Geräte der 14er Serie]


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Max H. schrieb:
>> Oder muss wirklich ein FAM14 vorangeschaltet sein?
> Solange du keine Funktelegramme senden/empfangn willst, brauchst du kein
> FAM14.

Das wollte ich wissen, danke! Ich habe deshalb gefragt, weil in diesem 
Beitrag zu Beginn bzw. der Eltako-RS485-Bus nicht die 14-er Serie 
sondern die 12-er Serie gab, und in den Beschreibungen der 14-er Serien 
immer Beispiele nur in Verbindung mit dem FAM14 gibt.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Max H. schrieb:
>> laut 'egal' muss/kann man das so anschließen:
>>
>>
>>  ,-->[µC mit RS485]
>> |
>> |
>> |
>> +-->[Eltako-RS485-Bus: z.B. FTS14EM]
>> |
>> |
>> |
>> +-->[Eltako-RS485-Bus: z.B. FUD14]
>> |
>> |
>> |
>> `-->[Eltako-RS485-Bus: weitere Geräte der 14er Serie]
>>
>>
>> ist das richtig?
> Falls du die Antwort darauf findest, bitte posten, weil mich das selber
> interessieren würde.

Hast du das nicht schon realisiert?:

Max H. schrieb:
> Nach langem herumprobieren habe ich es endlich geschafft und ich kann
> meine FUD14/FSG14 über mein Raspberry Pi via USB/RS485 dimmen.

[Max H. (mh182)]

elTacco schrieb:
> Laut Beschreibung kann man den PC mit FAM14 per USB anschließen und über
> die mittgelieferte Software PCT14 programmieren, steuern, und Zustände
> auslesen.
>
> Max H. schrieb:
>> Da ich in meiner Installation ein FAM14 habe (hat ein USB Port), habe
>> ich gemerkt, dass ich alle Telegramme über den USB Port abfragen/senden
>> kann.
>
> Das ist sehr interessant, mich interessiert vor allem wie die
> Kommunikation zustande kommt. Für mich hört es sich so an:
> - einerseits hast du die Software auf dem RasPi installiert (was ich
>   nicht glaube, aber möglich wäre es bestimmt)
Damir wir uns klar sind, die Software ist von mir selber geschrieben (in 
Python). Es handelt sich nicht um das PCT14 oder dem GVFS.

Normalen USB Kabel ans FAM14 angeschlossen, mit minicom die 
Baudrate/Start-Stop Bits eingestellt und schon hatte ich alle 
Telegramme. Dann einige Tage damit verbracht das Protokoll zu verstehen 
und mit Python Twisted einen Daemon geschrieben, mit dem ich den Status 
meiner Anlage logge (persistiere) und Kommandos senden kann.


   RasPi <----------------------+
                                |
                              (USB)
                                |
    +-->[FAM14]<----------------+
    |
 (RS485)
    |
    +-->[FTS14EM]
    |
    |
    |
    +-->[FUD14]
    |
    |
    |
    +-->[weitere Geräte der 14er Serie]



>>> ist das richtig?
>> Falls du die Antwort darauf findest, bitte posten, weil mich das selber
>> interessieren würde.
>
> Hast du das nicht schon realisiert?:
Nein, wie oben erklärt, bin ich mit dem USB Kabel direkt am FAM14 und 
nicht direkt auf den RS485 Bus. Mich interessiert wie du dich ohne FAM14 
direkt auf den RS485 Bus schaltest und Daten ausliest.

[SpsUser (Gast)]

Daten zurücklesen geht meines Wissens nicht über RS485. Lediglich auf 
den Bus schreiben. Ich mache das erfolgreich mit einer SPS und steuere 
damit direkt von der RS485-Schnittstelle Eltako Dimmer an.
So wie ich das verstehe hast du keine RS485-Schnittstelle. Ist trotzdem 
kein Problem. Geh einfach vom TTL-Out deines Raspberries oder 
Mikrocontrollers auf einen MAX485 und legst die Ausgänge auf den 
Eltako-Bus. Oder versteh ich dein Problem nicht?

[elTacco (Gast)]

Max H. schrieb:
> Damir wir uns klar sind, die Software ist von mir selber geschrieben (in
> Python). Es handelt sich nicht um das PCT14 oder dem GVFS.

Alles klar!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Max H. schrieb:
> ... mit Python Twisted einen Daemon geschrieben, mit dem ich den Status
> meiner Anlage logge (persistiere) ...

Achso...
D.h. du kriegst den Status auch nicht direkt aus der FAM14, mit einem 
Befehl der bspw. so lauten könnte:

getStatus(all);
getStatus(fud14_1);
...

sondern du loggst alle Telegramme, die der FAM14 per USB sendet und dann 
hast du die aktuellen Zustände.
Es funktioniert also bspw. wie folgt:

Taster betätigt
 |
 |
 V
FTS14EM schickt Telegramm
 |
 |
 +-------------------------> FAM14 hört mit und schickt Telegramm
 |                           via USB an RasPi der das Telegramm
 |                           weiterverarbeitet
 V
FSR14-2x
 |
 |
 V
Licht geht an

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Max H. schrieb:
>>>> ist das richtig?
>>> Falls du die Antwort darauf findest, bitte posten, weil mich das selber
>>> interessieren würde.
>>
>> Hast du das nicht schon realisiert?:
> Nein, wie oben erklärt, bin ich mit dem USB Kabel direkt am FAM14 und
> nicht direkt auf den RS485 Bus. Mich interessiert wie du dich ohne FAM14
> direkt auf den RS485 Bus schaltest und Daten ausliest.

Ich glaube das ist genau DAS was wir alle suchen!
Ohne die ganze Zeit den Bus oder den FAM14 mithorschen/auszulesen ...

SpsUser schrieb:
> Daten zurücklesen geht meines Wissens nicht über RS485. Lediglich auf
> den Bus schreiben ...

:-(

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Aber in der Beschreibung vom FAM steht, dass Statustelegramme von 
Aktoren abgefragt werden können.
Kann man nicht mit dem FAM14 Statustelegramme abfragen und dabei den Bus 
abhören, damit man die Statustelegramme bekommt?

[SpsUser (Gast)]

Ich hatte damals bei Eltako einige technische Anfragen gestellt und 
unter anderem folgende Info per Mail erhalten:
....Die Baureihe 14 hat den Vorteil das sie sogar den Status meldet, 
aber dies geht nur über ein Gateway FGW14 über RS232...

[elTacco (Gast)]

Frank H. schrieb:
> Kennt jemand die Pinbelegung der 4Pin Brücke vom Eltako FUD14 ?
> Gruß
> Frank

elTacco schrieb:
> ... Pinbelegung ... immer noch ein Thema ...

BTW: diese Fragen erübrigen sich wenn man in der Planungshilfe (Seite 8 
oder 9) nachgeschaut shame



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



SpsUser schrieb:
> ....Die Baureihe 14 hat den Vorteil das sie sogar den Status meldet,
> aber dies geht nur über ein Gateway FGW14 über RS232...

richtig! Danke für den Hinweis !!!
Aber durch Umwege über den FGW14.

In der Bedienungsanleitung vom FGW14 steht u.a.
"... Antworttelegramme von BR14-Aktoren ...
... Dazu muss der Hold-Ausgang des FGW14 mit dem Hold-Eingang des FAM14 
verbunden werden, um einen störungsfreien Bus-Betrieb zu gewährleisten."

Es klingt doch so, als ob FAM14 und FGW14 in diesem Betriebsmodus das 
gleiche Telegramm an die Aktoren senden um deren Status zu erhalten.


Dann war meine Idee doch nicht so schlecht:

elTacco schrieb:
> Kann man nicht mit dem FAM14 Statustelegramme abfragen und dabei den Bus
> abhören, damit man die Statustelegramme bekommt?

Die Bestätigungstelegramme die man erhält stehen im Katalog auf Seite 
251 (siehe Anhang oder als Download : 
http://www.eltako.com/fileadmin/downloads/de/Katalog/eltako_funk_high_res.pdf)

[elTacco (Gast)]

@ Max H.

benutzt du beim FAM14 den Funk bzw. hast du Funk-Geräte die mit dem 
FAM14 kommunizieren?

[Lars S. (kallipeter)]

Moin zusammen,

ich habe seid etwa 3 Jahren die 12er Reihe von Eltako im Schaltschrank. 
Ich hatte großes vor was Visualisierung und Bedienung mit PC/Handy 
angeht, aber wie es nun einmal so ist, habe ich nie die Zeit gefunden. 
Jetzt, wo ich mich damit beschäftigen kann und ich mich entsprechend mit 
dem Raspberry auseinander gesetzt habe (den ich zur ansteuerung 
verwenden möchte), stehe ich vor der Wahl die 12er Reihe weiterhin zu 
benutzen oder  mein System zu upgraden.

Ich möchte kurz erläutern, was ich probiert habe:
- Zuerst habe ich mir zwei USB <-> RS485 Adapter gebastelt (je ein 
FT232RL und ein RS481 Baustein)
- Dank dem wunderbaren Dokument von Johannes Fritsche und der 
Busbeschreibung von Eltako war es kein Problem weder die 12er noch die 
14er Reihe (FSR14-4x) zu schalten.
- Die beiden USb-Adapter habe ich jeweils so angeschlossen, das ich mit 
einem die Telegramme gesendet habe und mit dem anderen die Ausgabe 
kontrolliert habe bzw auf eine Antwort gewartet habe.

Genau da ist jetzt aber mein Problem: Kann mir bitte jemand erklären, 
was das FAM14 in der Schalterstellung "1" macht, bzw wie der gesammte 
Prozess der Geräte-ID vergabe bei der 14er Reihe funktioniert? Ich würde 
es gerne ausprobieren, aber ich habe noch kein FAM14. Hat von euch schon 
mal jemand die Kommunikation zwischen einem FAM14 und bspw. einem 
FSR14-4x mitgesnifft?

Wenn ich es richtig verstanden habe, dann erwartet der Aktor für die 
Geräte-ID vergabe doch ein bestimmtes Telegramm vom FAM und generiert 
daraufhin eine ID aus verschieden Parametern und schickt diese zurück, 
damit das FAM die Geräteliste erstellen kann. Damit ist dem FAM bekannt, 
mit wem er es zu tun hat und kann dann gezielt nach dem Status des 
Aktors fragen.

Ich würde gerne alles testen, aber wie gesagt fehlt mir im Moment das 
Modul FAM14 bzw ein Stück mehr Dokumentation um es zu verstehen.

Für Anregungen wäre ich sehr dankbar.

Gruß
Lars

[Max H. (mh182)]

elTacco schrieb:
> @ Max H.
>
> benutzt du beim FAM14 den Funk bzw. hast du Funk-Geräte die mit dem
> FAM14 kommunizieren?
Ich habe ein Funk-Fernbedienung, mit der ich verschiedene Teile steuere 
(Beschattung, Handtuchtrockner, ...). Aber im großen und ganzen ist mein 
Bussystem im Verteilerkasten (Aktoren und Sensore).

Mit Ausnahme der Fernbedienung habe keine Sensoren/Aktoren, welche auf 
Funk basieren.

[Max H. (mh182)]

Lars Schröder schrieb:
> Moin zusammen,
>
> ich habe seid etwa 3 Jahren die 12er Reihe von Eltako im Schaltschrank.
> Ich hatte großes vor was Visualisierung und Bedienung mit PC/Handy
> angeht, aber wie es nun einmal so ist, habe ich nie die Zeit gefunden.
> Jetzt, wo ich mich damit beschäftigen kann und ich mich entsprechend mit
> dem Raspberry auseinander gesetzt habe (den ich zur ansteuerung
> verwenden möchte), stehe ich vor der Wahl die 12er Reihe weiterhin zu
> benutzen oder  mein System zu upgraden.
Die Visualisierung wird schwer mit der 12er Reihe, da diese nicht 
bi-direktional sind. D.h. die senden kein Status Telegramm zurück, wenn 
etwas geschaltet/verändert wurde. Beispiel: du hast ein Taster, der das 
Licht ein/aus-schaltet. Du bekommst mit wann der Taster betätigt wurde, 
aber der aktuelle Zustand des Lichts (ob an oder aus) hast du nicht am 
Bus.

> Genau da ist jetzt aber mein Problem: Kann mir bitte jemand erklären,
> was das FAM14 in der Schalterstellung "1" macht, bzw wie der gesammte
> Prozess der Geräte-ID vergabe bei der 14er Reihe funktioniert? Ich würde
> es gerne ausprobieren, aber ich habe noch kein FAM14. Hat von euch schon
> mal jemand die Kommunikation zwischen einem FAM14 und bspw. einem
> FSR14-4x mitgesnifft?
Die ID-Vergabe ist ein "einmaliger" Prozess, der einem "Item" im 14 Bus 
eine eindeutige IDs zuweist. Die ID-Vergabe kann auf zwei wegen 
erfolgen:
1. die komfortable: ein USB Kabel und PCT14 Software (am PC)
2. die weniger komfortable: ein Schraubenzieher und viel Geduld um mit 
LRN das einsprechenden Modul einzulernen (FAM14 auf Pos 1, LRN drehen 
etc.). Das Kapitel in den Bedienungsanleitungen "Geräteadresse für den 
FSB14 vergeben" bei den einzelnen Eltako-Modulen beschreibt genau dieses 
Szenraio.

Egal ob du 1. oder 2. machts, am Ende hat der Sensor/Aktor eine 
eindeutige Adresse.

Ich ändere meine Konfiguration mit Hilfe der PCT14 Software (Variante 
1). Und das geht so:
* PC mit USB an FAM14 anschließen
* PCT14 am PC starten und mit FAM14 verbinden (!!! in diesem Zustand 
geht nichts am Bus. D.h. deine ganze Anlage lässt sich nicht mehr normal 
steuern)
* mit dem PCT14 nach neuen Geräten suchen (die noch keine Adresse 
haben), neue ID zuweisen.

Vorteil der Variante 1:
- ich kann die IDs selber wählen (mit Variante 2. wird die nächste freie 
vom FAM14 selber gewählt).
- es gibt sehr viele EInstellungen, die nur über PCT14 Software möglich 
ist
- man kann die gesamte Konfiguration in einer Datei speichern. Hatte vor 
kurzem ein Blitzeinschlag, das FAM14 war kaputt. Neues geholt, alte 
Datei eingspeielt, alles war OK. Die gesamte Konfiguration hat genau 5 
Minuten gedauert.

Der Eltako Bus war vielleicht früher mit LRN konfigurierbar. Aber um 
Vernünftig damit arbeiten zu können muss man PCT14 benutzen. Wenn man 
das ganze auch noch über Software selbst ansteuern will, kommt man nicht 
drum herum, da die meisten Einstellungen dafür nur über das PCT14 
einstellbar sind (siehe Bepsiel weiter unten)

Zum mitsniffen: habe ich. Daraufhin habe ich folgendes entschieden. Die 
Konfiguration mache ich mit dem PCT14 (kostet ja nichts - eine Open 
Source Variante wäre mir lieber). Die Steuerung im Normalbetrieb 
schreibe ich selber (dazu gibts ja gute Dokumentation der Telegramme).

> Wenn ich es richtig verstanden habe, dann erwartet der Aktor für die
> Geräte-ID vergabe doch ein bestimmtes Telegramm vom FAM und generiert
> daraufhin eine ID aus verschieden Parametern und schickt diese zurück,
> damit das FAM die Geräteliste erstellen kann. Damit ist dem FAM bekannt,
> mit wem er es zu tun hat und kann dann gezielt nach dem Status des
> Aktors fragen.
Ich glaube da liegst du auf dem Holzweg. Das FAM fragt nie einen Status 
ab und hat auch keine Information über den Status der einzelnen Geräte 
(mit Ausnahme der IDs, welche am Bus vorkommen). Das FAM14 ist ein 
Gateway zwischen Funk und dem RS485 Bus. Das FAM14 scannt Aktivitäten am 
485-Bus und falls ein (Status)telegramm entdeckt wird, wird dieses über 
Funk weitergegeben (falls die enstprechenden Position am FAM eingestellt 
ist). Den aktuellen Status der Teile muss deine Software über die 
Bestätigungstelegramme der Aktoren ermitteln. Wenn deine Software 
hochfährt, weiss sie nichts über den aktuellen Status des Systems.

Meine größte Verständnis-Hürde war, wie ich die einzelnen Teile 
ansteuere. Im Normalfall sind die Aktoren auf ein Sensor programmiert. 
Beispiel:
* ein FUD14 mit ID 10 horcht auf den Taster mit ID 200. Die Betätigung 
dieses Tasters generiert ein "ein Telegramm", kurz gefolgt mit einem 
"aus Telegramm" mit ID 200.
* mein Ziel: ich wollte nun das FUD14 gezielt mit Software steuern (d.h. 
ein/aus, Dimmwert senden). Dafür gibts es zwei Lösungen:
1. simulere eine Taster Betätigung, indem dieselben Telegramme gesendet 
werden. Damit konnte ich ein/ausschalten, aber keinen direkten Dimmwert 
(z.B. 50%) senden. Eine Dimmung konnte ich machen, indem ich die 
Zeitspanne wischen ein/aus Telegrammen verlängert habe.
2. weise dem FUD14 eine zusätzliche Adresse zu auf die es horchen soll 
und konfiguriere diese Adresse als "Ansteuerung durch FVS" (FVS ist die 
Eltako-Visuallsierungs-Software). Ich benutzte dieselbe ID wie der Aktor 
hat (dem Beispiel folgende ID=10). Somit kann ich nun ein "Dimm 
Telegramm" mit ID=10 mit Dimmwert z.B. 50% senden und das FUD14 reagiert 
darauf. Du kannst aber X-beliebige, nicht vergebene IDs konfigurieren.

Wie oben schon erwähnt, braucht man für die Einstellung des FUD14 auf 
"Ansteuerung durch FVS" die PCT14 Software (es geht auch mit den LRN 
Drehschaltern aber das habe ich bald aufgegeben).

Ich hoffe das hat geholfen.

Lg Max

[Max H. (mh182)]

elTacco schrieb:
> Max H. schrieb:
>> Damir wir uns klar sind, die Software ist von mir selber geschrieben (in
>> Python). Es handelt sich nicht um das PCT14 oder dem GVFS.
>
> Alles klar!
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Max H. schrieb:
>> ... mit Python Twisted einen Daemon geschrieben, mit dem ich den Status
>> meiner Anlage logge (persistiere) ...
>
> Achso...
> D.h. du kriegst den Status auch nicht direkt aus der FAM14, mit einem
> Befehl der bspw. so lauten könnte:
>

getStatus(all);
> getStatus(fud14_1);
> ...

> sondern du loggst alle Telegramme, die der FAM14 per USB sendet und dann
> hast du die aktuellen Zustände.
Exakto - ich möchte nochmals betonen. Das FAM14 hat keinen Status der 
einzelnen Teile. Es gibt nur die Statustelegramme weiter.

> Es funktioniert also bspw. wie folgt:
Ja, genauso. Habe das ganze ergänzt um das Statustelegramm (das ist ja 
das neue Feature vom 14er Bus gegenüber dem 12er).

Taster betätigt
 |
 |
 V
FTS14EM schickt Telegramm
 |
 | (Taster ein + Taster aus)
 +-------------------------> FAM14 hört mit und schickt Telegramm
 |                           via USB an RasPi der das Telegramm
 |                           weiterverarbeitet (FTS14EM)
 V
FSR14-2x
 |
 | (Ein)
 +-------------------------> FAM14 hört mit und schickt Telegramm
 |                           via USB an RasPi der das Telegramm
 |                           weiterverarbeitet (FSR14-2x)
 V
Licht geht an



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> SpsUser schrieb:
>> Daten zurücklesen geht meines Wissens nicht über RS485. Lediglich auf
>> den Bus schreiben ...
>
> :-(
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Aber in der Beschreibung vom FAM steht, dass Statustelegramme von
> Aktoren abgefragt werden können.
> Kann man nicht mit dem FAM14 Statustelegramme abfragen und dabei den Bus
> abhören, damit man die Statustelegramme bekommt?
Die Statustelegramme bekomme ich am FAM14 schön mit. Aber ich kann nicht 
den aktuellen Status eines z.B. FSR14-2x abfragen.

Das mithorchen am FAM14 wird dir nicht erspart bleiben.

[Lars S. (kallipeter)]

@Max: Besten Dank für diese sehr ausführliche Beschreibung, das hat 
viele Vertändnisfragen bei mir klären können. Das wichtigste was ich nun 
Verstanden habe ist, dass das FAM nicht die Statusmeldungen speichert 
sondern diese scheinbar sporadisch von den einzelnen Aktoren versendet 
werden.

Zwei Fragen noch (werde es testen, aber vielleicht weißt du es ja):
- Werden nur Staustelegramme vom z.B.FSR12-2x gesendet, wenn er einmal 
über den FAM registriert wurde oder schickt er fröhlich drauf los?

- Werden die Statustelegramme in Richtung "Bus-Anfang" geschickt oder 
durch den bidirektionalen Bus auch an die nachgeschalteten Module?

Ich frage, weil meine Idee dann wäre einfach zwei RS485 Adapter an den 
Raspberry anzuschließen. Ein Adapter vor dem Eingangsmodul um Telegramme 
zum schalten/dimmen/usw auf den Bus zu schicken und einen weiteren nach 
dem letzten Aktor um die auf dem Bus verschickten Telegramme und 
Statusmeldungen abzufangen. Dann sollte doch nichts verloren gehen, 
oder?

Max schrieb:
>Das FAM14 scannt Aktivitäten am
>485-Bus und falls ein (Status)telegramm entdeckt wird, wird dieses über
>Funk weitergegeben (falls die enstprechenden Position am FAM eingestellt
>ist). Den aktuellen Status der Teile muss deine Software über die
>Bestätigungstelegramme der Aktoren ermitteln.

und

>Die Statustelegramme bekomme ich am FAM14 schön mit. Aber ich kann nicht
>den aktuellen Status eines z.B. FSR14-2x abfragen.

Du schreibst, das ein Statustelegramm entdeckt werden muss. Bedeutet 
das, dass es auch wirklich keine Möglichkeit gibt um ein Statustelegramm 
gezielt aus einem Aktor herauszukitzeln? Was macht dann die 14er Reihe 
für einen großen Unterschied zu der 12er Reihe? Wenn ich dann eh alles 
mitsniffen muss um eine Statusübersicht erstellen zu können?

Ok, zugegeben, Statustelegramme vereinfachen die Sache, aber permanent 
am Bus hängen muss ich trotzdem..

Nochmal besten Dank für die Ausführliche Nachricht,
gruß
Lars

[Max H. (mh182)]

Lars Schröder schrieb:
>
> Zwei Fragen noch (werde es testen, aber vielleicht weißt du es ja):
> - Werden nur Staustelegramme vom z.B.FSR12-2x gesendet, wenn er einmal
> über den FAM registriert wurde oder schickt er fröhlich drauf los?
Ich habe leider kein FSR12-2x sondern den FSR14-2x. Der FSR12 wird gar 
nichts senden, weil die 12er reihe kein Status zurücksendet. Das ist der 
Unterschied zur 14er Reihe. Beim 12er Bus weisst du ausschließlich vom 
Steuerbefehl, was eigentlich passieren sollte. Du bekommst aber keine 
Bestätigung (Status), dass das auch passiert ist. Du bekommst also nur 
indirekt (Feedback am realen Objekt - z.B. Licht) wenn du die Anlage 
falsch konfiguriert hast. Beim 14er Bus könnte ich in Indien sitzen und 
mitbekommen, dass der Aktor X nicht schaltet, obowhl Taster Y gedrückt 
wurde.

> - Werden die Statustelegramme in Richtung "Bus-Anfang" geschickt oder
> durch den bidirektionalen Bus auch an die nachgeschalteten Module?
Wie weiter oben schon erklärt, habe ich ein FAM14 und bin mit USB daran 
angeschlossen. Also habe ich keine Ahnung was du als "Bus-Anfang/Ende" 
siehts. Das FAM14 erkennt ein Steuertelegram bzw. ein Statustelegramm (= 
Antwort auf das Steuertelegramm) und gibt mir das am USB aus.

> Du schreibst, das ein Statustelegramm entdeckt werden muss. Bedeutet
> das, dass es auch wirklich keine Möglichkeit gibt um ein Statustelegramm
> gezielt aus einem Aktor herauszukitzeln? Was macht dann die 14er Reihe
> für einen großen Unterschied zu der 12er Reihe? Wenn ich dann eh alles
> mitsniffen muss um eine Statusübersicht erstellen zu können?
Definition "Statustelegramm": ein Telegramm, dass von einem "Gerät" 
gesendet wird, wenn eine Statusänderung vorliegt (im Normalfall als 
Resultat eines Ansteuer-Telegramms).

Unterschied zur 12er (siehe oben): kein Statustelegramm.

Es gibt MEINES WISSENS keine Möglichkeit, den aktuellen Status eines 
Gerätes abzufragen. Um eine korrekte Aussage darüber treffen zu können, 
müsste man sich das Protokoll des GVFS mit dem Bus genauer ansehen. Da 
ich diese Software aber nicht habe (und ein Reverse-Engineering mit 
Sicherheit nicht erlaubt ist), kann ich dazu keine 100% Aussage machen.

Man könnte aber Eltako anrufen und Fragen ob das GVFS nach Systemstart 
den Systemstatus kennt. Die Antwort darauf sollte dann Aufschluss 
darüber geben.

> Ok, zugegeben, Statustelegramme vereinfachen die Sache, aber permanent
> am Bus hängen muss ich trotzdem..
Naja, wenn du in Real-Time etwas mitbekommen willst (und normalerweise 
willst du das in der Wohnung), musst du immer am Bus hängen.

Meine "Langzeit-Vision" (die Zeit, die Zeit ... fehlt uns allen) ist ein 
Eltako-Binding zu OpenHAB zu machen. Damit bekomme ich eine 
Visualisierung und die Möglichkeit meine Wohnung intelligent zu steuern 
(Komfort-Funktionaliät). Sollte der Rapsi (mit OpenHAB) ausfallen, 
funktionieren die Basisfunktionalitäten immer noch. Meine Frau würde 
mich sonst erschießen ;-)

Zur Zeit bin ich noch in der "Protokoll-Geräte-Kennenlern-Phase". Mit 
OpenHAB-Internals habe ich mich noch gar nicht beschäftigt (außer dem 
Auslesen der 1-Wire-Temperatur-Fühler).

[Lars S. (kallipeter)]

Sorry, ich meine auch das FSR14-2x und nicht das FSR12-2x...

Aber nichts desto trotz hast du mir sehr geholfen. Ich muss noch ne 
Hausarbeit fertig machen und dann gehts hier weiter. Ich hoffe am 
Sonntag mal ein paar Statusmeldungen und vorallem eine Beschreibung 
meines Aufbaus posten zu können.

Ich würde gerne das Dokument von Johannes Fritsche um die Infos zu der 
14er Baureihe erweitern. Ich habe einem Freund, der jetzt ein Haus baut, 
vom Eltako-Bus vorgeschwärmt und der hat ordentlich aufgerüst (siehe 
Bild im Anhang). Nun möchte wäre naürlich cool zu wissen wie die ganze 
Kommunikation läuft bevor man mit dem Anlernen anfängt...

Schönes WE

[elTacco (Gast)]

@ Max H.

Danke für deine ausführliche Schilderung!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Max H. schrieb:
> Meine "Langzeit-Vision" (die Zeit, die Zeit ... fehlt uns allen) ist ein
> Eltako-Binding zu OpenHAB zu machen.

Das ist doch mal ne Ansage!
So was wäre echt gut, aber meinst du Eltako würde da mitspielen?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Lars Schröder schrieb:
> Zwei Fragen noch (werde es testen, aber vielleicht weißt du es ja):
> - Werden nur Staustelegramme vom z.B.FSR12-2x gesendet, wenn er einmal
> über den FAM registriert wurde oder schickt er fröhlich drauf los?

Diese Frage hab ich mir auch gestellt, jedoch bezogen auf die 14 
Baureihe, also:
- Werden nur Staustelegramme vom z.B.FSR14-2x gesendet, wenn er einmal
  über den FAM registriert wurde oder schickt er fröhlich drauf los?

Ist es nicht so:

Taster betätigt
 |
 |
 V
FTS14EM schickt _Steuertelegramm_
 |
 |
 |                               FAM14 hört _Steuertelegramm_
 | (Taster ein + Taster aus)     von FTS14EM und leitet
 +-----------------------------> _Steuertelegramm_ via USB zur
 |                               Weiterverarbeitung weiter an:
 |                               Raspi, µC, etc.
 |
 |
 V
FSR14-2x schickt _Bestätigungstelegramm_
 |
 |
 |                               FAM14 hört _Bestätigungstelegramm_
 | (Ein)                         von FSR14-2x und leitet
 +-----------------------------> _Bestätigungstelegramm_ via USB zur
 |                               Weiterverarbeitung weiter an:
 |                               Raspi, µC, etc.
 |
 V
Licht geht an


Das Bestätigungstelegramm wird nur gesendet, wenn der Aktor seinen 
Zustand ändert sonst nicht. --> Ist das richtig?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Aber was mir nicht aus dem Kopf geht ist der folgende Satz:

Sobald BR14-Aktoren eine Geräteadresse erhalten haben,
kann das FAM14 Bestätigungstelegramme von den Aktoren abfragen.

                                                           .
                                                          /|\
                                                           |
                                                   genau das "abfragen"

Oder ist es so, wie von Max H. beschrieben hat, dass die GVFS an den 
FAM14 'funkt' --> 'frage Status ab' ...

Naja solange keiner eine GVFS hat wird das ein Geheimnis bleiben oder 
man fragt bei Eltako an (wie Max H. schon gesagt hat).

[Max H. (mh182)]

elTacco schrieb:
> Max H. schrieb:
>> Meine "Langzeit-Vision" (die Zeit, die Zeit ... fehlt uns allen) ist ein
>> Eltako-Binding zu OpenHAB zu machen.
>
> Das ist doch mal ne Ansage!
> So was wäre echt gut, aber meinst du Eltako würde da mitspielen?
Eltako kann entweder helfen oder zuschauen. Eltako kann mir ja 
schließlich nicht verbieten, eine Open-Source Anbindung zu schreiben. 
Solange ich nicht deren Software zum Reverse-Engeneering benutze (und 
genau deshlab schaue ich mir das GVFS nicht an), können sie nicht viel 
machen.

Ich denke mal positiv und hoffe, dass Eltako eher helfen wird. Aber 
solange ich keine Zeit dazu habe ist das ganze nur "Schall und Rauch" 
;-)

>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Lars Schröder schrieb:
>> Zwei Fragen noch (werde es testen, aber vielleicht weißt du es ja):
>> - Werden nur Staustelegramme vom z.B.FSR12-2x gesendet, wenn er einmal
>> über den FAM registriert wurde oder schickt er fröhlich drauf los?
>
> Diese Frage hab ich mir auch gestellt, jedoch bezogen auf die 14
> Baureihe, also:
> - Werden nur Staustelegramme vom z.B.FSR14-2x gesendet, wenn er einmal
>   über den FAM registriert wurde oder schickt er fröhlich drauf los?
So, habe mir das FAM genauer angesehen und ich könnte mich %"$/&%§/!.

OK, ich war am falschen Dampfer. Ich hatte bisher das FAM auf Position 
2, d.h. es werden nur Status Telegramme erzeugt, wenn etwas passiert.

Folgendes Verhlaten war in Position 2: wenn ich das FAM über die USB 
auslese bekomme ich eine kontinuierliche Flut an Messages mit "ORG=FC" 
("ORG" = 2. Byte nach SYNC). Das FAM schein den Bus abzupollen und 
liefert dabei einen "Status" alle registrierten IDs. Der Inhalt dieses 
FC Status Telegramms ist, mit Ausnahme der ID im "STATUS" Byte, immer 
derselbe (natürlich ändert sich auch die Checksumme, da sich das STATUS 
Byte geändert hat).

2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x01\xa8'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x02\xa9'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x03\xaa'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x04\xab'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x06\xad'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x07\xae'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x08\xaf'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\t\xb0'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\n\xb1'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x0b\xb2'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x0c\xb3'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\r\xb4'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x0e\xb5'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x0f\xb6'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x10\xb7'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x12\xb9'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x13\xba'
2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x14\xbb'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x15\xbc'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x16\xbd'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x17\xbe'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x18\xbf'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x19\xc0'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1a\xc1'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1b\xc2'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1c\xc3'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1d\xc4'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1e\xc5'
2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1f\xc6'

An diesen Status Telegrammen erkenne ich:
- ob ich noch am FAM hänge und alles OK ist
- ein Gerät defekt oder nicht konfiguriert ist (die ID wird nicht mehr 
geliefert).

Es enthält aber keine Status Informationen des jeweiligen Geräts. 
Solange kein Sensor/Aktor betätigt wird, passiert sonst nichts am Bus.


Habe nun auf Position 4 gedereht und nun bekomme ein kontinuirlichen 
Stream von Statusmeldungen (ORG=fe,...)

2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:0000003d]
2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:0000003e]
2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:0000003f]
2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:00000040]
2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:00000041]
2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:00000042]
2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:41+0200 [-] recv [ORG:05, DATA:50000000, ID:00000001]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000002]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000003]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000004]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000006]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000007]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000008]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000009]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:0000000a]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:0000000b]
2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000]
2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:0000000c]

Das Verhalten, wie das FAM die Daten am USB Port ausgibt ist 
konfigurierbar. Wieder etwas gelernt.

Position 5, 6 und 7 sind identisch zu Position 2,3 und 4 mit einer 
slebst definierten Liste, die man im FAM mit dem PCT14 definieren kann. 
Das soll angeblich bei sehr großen Installatioen nötig sein, wo viele 
IDs vorhanden sind. Mit der Liste könnte man bestimmte IDs öfters 
(schneller) am Bus ausgeben, bevor der gesamte Poll-Zyklus vorbei ist.

>
> Ist es nicht so:
Ja, dein Diagramm ist ausführlicher als meines und ist korrekt.

> ...
> Das Bestätigungstelegramm wird nur gesendet, wenn der Aktor seinen
> Zustand ändert sonst nicht. --> Ist das richtig?
Nein. Wenn ich z.B. ein "Software generiertes" Dimm-Kommando zu einem 
FUD14 absetze "dimme auf 50%" dann bekomme ich ein Status zurück 
"Dimmung auf 50%". Setze ich das selbe Kommando nochmals ab, bekomme ich 
dieselbe Statustelegramm nochmals zurück. D.h. der Status am FUD hat 
sich nicht geändert, und ich bekomme trotzdem ein Status.

Lg Max

[Max H. (mh182)]

Habe die Bedienungsanleitung des FAM nochmals durchgelesen. Folgendes 
ist zu unterscheiden, damit man nicht ganz durcheinander kommt:
* Funktelegram (= Ansteuertelegram): ein Sensor/Software gibt ein 
Kommando
* Bestätigungstelegramm: Telegramm als Antwort des Funktelegramms
* Statustelegramm: Antwort (mit Status) auf ein Statusanfrage (durch das 
FAM).

FAM Positionen:
* 2: sendet nur Funk- mit entsprechenden Bestätigungstelegrammen
* 3: wie 2 aber ohne Senden über Funk
* 4: wie 3, aber inkl. Statustelegramme der Aktoren
* 5,6,7: wie 2,3,4 aber einer zusätzlichen Geräteliste
* 9,10: Einlernen von Funkschlaturen

Wenn man keine Funkaktoren hat macht Position 2 bzw. 5 kein Sinn (außer 
man will die NSA mithören lassen ;-)

Was ich noch nicht getestet habe: ob ich ein Statustelegramm mit Hilfe 
meiner Software absetzen kann (ohne des FAM14). Falls das gehen sollte, 
werde ich mein FAM auf Position 3 fahren und beim Startup der Software 
am Raspi einfach den Status aller Aktoren einmalig abpollen.

[elTacco (Gast)]

Habe z.Z. viel zu tun und kann mich leider nicht intensiv damit 
beschäftigen.

@ Max H. :

Hört sich gut an!

Max H. schrieb:
> Was ich noch nicht getestet habe: ob ich ein Statustelegramm mit Hilfe
> meiner Software absetzen kann (ohne des FAM14).

Wenn das gehen würde wäre das echt cool!
Mfg

[elTacco (Gast)]

@ Max H.

Du hast doch anfangs mal schon mal geschrieben, dass du deine 
Flur-/Treppenbeleuchtung mittels eines Bewegungsmelders auf einen 
bestimmten Dimmwert aufdimmst und zusätzlich mittels Taster ein- und 
ausschaltest:

                               Leuchte aus   0% Dimmwert
Bewegungsmelder (1min ein) --> Leuchte ein  30% Dimmwert (Beispiel Wert)
Bewegungsmelder (aus)      --> Leuchte aus   0% Dimmwert
Taster (aus - ein - aus)   --> Leuchte ein 100% Dimmwert
Taster (aus - ein - aus)   --> Leuchte aus   0% Dimmwert


Meine Frage ist: realisierst du das mit
- dem PasPi + Bewegungsmelder
- oder Bewegungsmelder + FTS14EM

oder ganz anders?

MFG

[Max H. (mh182)]

elTacco schrieb:
> @ Max H.
>
> Du hast doch anfangs mal schon mal geschrieben, dass du deine
> Flur-/Treppenbeleuchtung mittels eines Bewegungsmelders auf einen
> bestimmten Dimmwert aufdimmst und zusätzlich mittels Taster ein- und
> ausschaltest:
>
>                                Leuchte aus   0% Dimmwert
> Bewegungsmelder (1min ein) --> Leuchte ein  30% Dimmwert (Beispiel Wert)
> Bewegungsmelder (aus)      --> Leuchte aus   0% Dimmwert
> Taster (aus - ein - aus)   --> Leuchte ein 100% Dimmwert
> Taster (aus - ein - aus)   --> Leuchte aus   0% Dimmwert
>
>
> Meine Frage ist: realisierst du das mit
> - dem PasPi + Bewegungsmelder
> - oder Bewegungsmelder + FTS14EM
>
> oder ganz anders?
Aktueller Aufbau:
* 1 Bewegungsmelder der das Licht schaltet
* Rapsi (mit OpenHAB) - der leider noch nichts macht

Ich habe keinen Taster.

Der Proof-of-Concept zum zeitbasierten dimmen (Beispiel: zwischen 22 Uhr 
und 06 Uhr) habe ich gemacht. Aber noch nicht integriert (sprich in die 
openHAB integriert).

Das ganze soll dann so ausschauen:
Bewegungsmelder (1min ein) --> Leuchte ein  100% Dimmwert (Beispiel 
Wert)
Bewegungsmelder (aus)      --> Leuchte aus    0% Dimmwert
--- (erste Betätiguing des BM, ab 22 Uhr) ---
Bewegungsmelder (1min ein) --> Leuchte ein  100% Dimmwert
Setze Dimmwert auf 30%     --> Leuchte ein   30% Dimmwert (Beispiel 
Wert)
Bewegungsmelder (aus)      --> Leuchte aus   0% Dimmwert
Bewegungsmelder (1min ein) --> Leuchte ein  30% Dimmwert
Bewegungsmelder (aus)      --> Leuchte aus   0% Dimmwert
--- (erste Betätiguing des BM, ab 06 Uhr) ---
Bewegungsmelder (1min ein) --> Leuchte ein  30% Dimmwert
Setze Dimmwert auf 100%    --> Leuchte ein 100% Dimmwert
Bewegungsmelder (aus)      --> Leuchte aus   0% Dimmwert
Bewegungsmelder (1min ein) --> Leuchte ein 100% Dimmwert
Bewegungsmelder (aus)      --> Leuchte aus   0% Dimmwert
----------------

Leider habe ich (bis jetzt) keine Möglichkeit gefunden, den Dimmwert des 
FTS14EM im ausgeschalteten Status zu setzen. Deshalb wird beim ersten 
Schalten nach 22 Uhr kurz auf 100% gedimmt, dann auf 30% runter.

Bin mir aber sicher, dass ich mit Lichtszenen, das ganze eleganter lösen 
könnte (wie allen hier im Forum habe ich immer zu wenig Zeit um mich 
einzulesen/testen ;-)

Das zeitbasierte dimmen (so wie die gesamte darüberliegende komplexere 
Automatsierungslogik) mache ich mit Software am Raspi mit openHAB.

Zur Zeit beschäftige ich mich aber mit der Heizung. Das hat höhere Prio, 
da die Heizsaison bald ansteht.

Hoffe das hilft dir.

Lg Max

[elTacco (Gast)]

@ Max

Danke für die Antwort!

Bei meinem Vorhaben ist das Licht im Flur unabhängig von der Uhrzeit.

Ich will das es so, wie oben erklärt funktioniert.

Muss mir was einfallen lassen oder eher ausprobieren, werde das 
wahrscheinlich
frühestens Mitte Oktober anfangen zu testen.

Denn du hast recht, jeder leidet an 'Zeitmangel' ;-)


Viel Erfolg bei der Heizungssteuerung!

MFG

[Andre (Gast)]

Hallo zusammen,

ich möchte meine bestehende Eltako Installation(nicht Busfähig) auf das 
Eltako RS485 System umbauen. Dazu bin ich gerade dabei einen Gateway zu 
bauen, der die Taster aus den Zimmern zusammen fasst und als Telegramm 
an die Eltako's schickt. Außerdem hat der Gateway ein Webinterface für 
die Steuerung.

Soweit so gut....

Nun mein Problem. Ich möchte keinen FAM14 verbauen, da ich die 
Funktionen die er bietet eigentlich nicht brauche.
Wie kann ich OHNE FAM14 Geräteadressen in die Aktoren einlernen? Weiß 
jemand wie das Telegramm aussehen muss?

Gruß André

[irgendwer (Gast)]

dazu brauchst du auch keinen fam irgendwas. ich kanns dir nur nicht mehr 
genau sagen weil schon lange her. steuere selbst die Dimmer direkt von 
einer RS485-Schnittstelle aus an. Glaube es war so: drehschalter auf 
"LRN", dabei schickst ihm irgendeine adresse mit (siehe irgendwo im 
protokoll) und damit hört er immer auf diese adresse.
sorry wegen ungenau - wie erwähnt schon lange her.
Eigentlich findest du alle nötigen Infos hier im thread.

[Max H. (mh182)]

Andre schrieb:
> Nun mein Problem. Ich möchte keinen FAM14 verbauen, da ich die
> Funktionen die er bietet eigentlich nicht brauche.
> Wie kann ich OHNE FAM14 Geräteadressen in die Aktoren einlernen? Weiß
> jemand wie das Telegramm aussehen muss?
Zwei Varianten:
* mittels Konfiguration an den Aktoren selber (und betätigen der 
Tasten). Die Bedienungsanleitungen dazu haben alle Infos dazu (siehe 
dazu 
http://www.eltako.com/at/bedienungsanleitungen/der-gebaeudefunk.html)
* über Funktelegramme - sie dazu 
http://www.eltako.com/fileadmin/downloads/de/Datenblatt/Funktelegramme.pdf

lg Max

[Andre (Gast)]

Hallo zusammen,

erst einmal Danke für die Infos, aber mein eigentliches Problem ist noch 
nicht gelöst. (vielleicht stehe ich aber auch auf dem Schlauch..)

Nehmen wir folgendes Szenario an...

Der Schaltkasten ist umgebaut und diverse Dimmer, Rollladen und 
Schaltaktoren sind verbaut. Ab Werk sind diese nicht konfiguriert.
Jetzt müsste ich einzeln jeden Aktor in den "LRN" Modus bringen und die 
ID's einlernen. (nach meinem Verständnis ist dies das Verfahren welches 
in dem Eltako Dokument beschrieben ist.)

Was ich mir Vorstelle ist folgendes...

Nach einem Powerup erfolgt ein Busscan. Alle Aktoren melden sich und 
Geräte ohne gesetzte Geräteadresse bekommen von meinem Controller diese 
gesetzt. Danach kann jedem Aktor gezielt ein Kommando geschickt werde.
(Was ich bisher in diesem Thread gelesen habe, ist es möglich dieses 
Verhalten über FAM14 + PC Software zu realisieren.)
Vielleich kann mir jemand den Ablauf dazu skizzieren.

Gruß André

[André (Gast)]

Hallo zusammen,

ich bin jetzt etwas weiter voran gekommen. Im Moment programmiere ich 
die Steuerung eines FSB14 (Rollladen Aktor). Ich habe meine Steuerung 
auf die ID 180 und 200 eingelernt. Der Aktor fährt wie gewollt in die 
entsprechende Richtung.
Was ich aber vermisse, ist das Bestätigungstelegramm. Eigentlich sollte 
der Aktor in jedem Fall ein Telegramm schicken.
Muss da noch etwas spezielles gemacht werden?


Gruß André

[tic (Gast)]

André schrieb:
> Hallo zusammen,
>
> ich bin jetzt etwas weiter voran gekommen. Im Moment programmiere ich
> die Steuerung eines FSB14 (Rollladen Aktor). Ich habe meine Steuerung
> auf die ID 180 und 200 eingelernt. Der Aktor fährt wie gewollt in die
> entsprechende Richtung.
> Was ich aber vermisse, ist das Bestätigungstelegramm. Eigentlich sollte
> der Aktor in jedem Fall ein Telegramm schicken.
> Muss da noch etwas spezielles gemacht werden?
>
> Gruß André

Hallo,

ein Aktor kann erst dann Bestätigungstelegramme versenden wenn ihm eine 
AktorID vergeben wurde.

lg tic

[Andre (Gast)]

Hallo zusammen

tic schrieb:
> ein Aktor kann erst dann Bestätigungstelegramme versenden wenn ihm eine
> AktorID vergeben wurde.

Kann mir jemand sagen, wie dass ohne FAM14 geht?

Gruß André

[tic (Gast)]

Andre schrieb:
> Hallo zusammen
>
> tic schrieb:
>> ein Aktor kann erst dann Bestätigungstelegramme versenden wenn ihm eine
>> AktorID vergeben wurde.
>
> Kann mir jemand sagen, wie dass ohne FAM14 geht?
>
> Gruß André

Hallo,

ich kann Dir das sagen, aber dafür dürfte ich hier eine ewiglange 
Dokumentation posten. Ob Du es dann verstanden hast, und nicht gleich 
danach an der nächsten Stelle hängst, kann ich Dir nicht sagen.

Was spricht dagegen das FAM14 zu kaufen und das Log zu analysieren wie 
ich es gemacht habe?

Dadurch bekommst gleich die Software PCT14 mit der Du dann die ganzen 
Aktoren wirklich konfigurieren kannst. Den FAM14 kannst dann später auch 
als Gateway benutzen (er hat ne USB-Schnittstelle die sich beim PC dann 
als serielle Schnittstelle anmeldet).

lg tic

[tic (Gast)]

Hallo,

ich mache mal einen Versuch ...

Der FAM14 scannt die gesamten Busadressen von AktorID 0 - 127.

Sobald er einen Aktor im Bereich 1-127 findet weiß er das die ID 
vergeben ist.

Findet er einen Aktor auf der ID 0 dann vergibt er dem Aktor eine neue 
ID.

Ein Aktor antwortet nur dann auf die ID 0 wenn er im Modus AktorID 
einlernen ist, wobei maximal ein Aktor gleichzeitig in diesem Modus sein 
darf.

Je nach Aktortyp kann ein Aktor auch mehr als eine AktorID belegen. Dies 
trifft auf die von Dir verwendeten Rolladenaktoren zu. Sobald ein Aktor 
mehr als eine AktorID belegt wird der Scannbereich erweitert.

Scan der Adresse 0
-> A5 5A AB F0 00 00 00 00 00 00 00 00 00 9B
A55A = SYNCWORD
AB = HSEQ + LENGTH = Transmit Command Telegramm, Länge 11 Byte
F0 = ORG
00 = DATA[3]
00 = DATA[2]
00 = DATA[1]
00 = DATA[0]
00 = ID[3]
00 = ID[2]
00 = ID[1]
00 = ID[0]
00 = Status = an Adresse 0
9B = CRC = AB + F0 + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 00 = 19B

Antwort von dem Baustein LRN
<- A5 5A 8B F0 00 02 7F 08 04 02 11 00 00 1B
A55A = SYNCWORD
AB = HSEQ + LENGTH = Transmit Command Telegramm, Länge 11 Byte
F0 = ORG
00 = DATA[3] = von Adresse
02 = DATA[2] = Baustein benötigt 2 Adressen
7F = DATA[1]
08 = DATA[0]
04 = ID[3] = Vermutlich FSR14-2x
02 = ID[2]
11 = ID[1]
00 = ID[0]
00 = Status
1B = CRC = 8B + F0 + 00 + 02 + 7F + 08 + 04 + 02 + 11 + 00 + 00 = 21B

Setze Addresse 1
-> A5 5A AB F8 00 00 00 00 00 00 00 00 01 A4
A55A = SYNCWORD
AB = HSEQ + LENGTH = Transmit Command Telegramm, Länge 11 Byte
F8 = ORG
00 = DATA[3]
00 = DATA[2]
00 = DATA[1]
00 = DATA[0]
00 = ID[3]
00 = ID[2]
00 = ID[1]
00 = ID[0]
01 = Status = übernehme Adresse 1
A4 = CRC = AB + F0 + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 00 = 1A4

Antwort von dem Baustein - ACK
<- A5 5A 8B F0 01 02 7F 08 04 02 11 00 00 1C
A55A = SYNCWORD
AB = HSEQ + LENGTH = Transmit Command Telegramm, Länge 11 Byte
F0 = ORG
01 = DATA[3] = von Adresse
02 = DATA[2] = Baustein benötigt 2 Adressen
7F = DATA[1]
08 = DATA[0]
04 = ID[3] = Vermutlich FSR14-2x
02 = ID[2]
11 = ID[1]
00 = ID[0]
00 = Status
1C = CRC = 8B + F0 + 01 + 02 + 7F + 08 + 04 + 02 + 11 + 00 + 00 = 21C

Ich hoffe das hilft Dir weiter.

lg tic

[Andre (Gast)]

Hallo tic,

besten Dank für die Infos. Das ist genau das, was ich gesucht habe.
Ich werde leider erst am WE. zum Testen kommen.

Ich melde mich dann nochmal.

Gruß André

[Andre (Gast)]

Hallo tic,

ich bin jetzt endlich dazu gekommen, das Setzen der Device ID zu testen.
Allerdings scheint das Ganze noch nicht zu funktionieren.
Hier ist ein Log:

>send
>dump 14 bytes
>0xA5 0x5A 0xAB 0xF0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x9B
>
>read
>dump 14 bytes
>0xA5 0x5A 0x8B 0xF0 0x00 0x02 0x7F 0x08 0x04 0x06 0x22 0x00 0x00 0x30
>
>device type = 0x04062200
>device need 2 addresses
>
>send
>dump 14 bytes
>0xA5 0x5A 0xAB 0xF8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0xA4
>
>read
>dump 14 bytes
>0xA5 0x5A 0x8B 0xF0 0x01 0x02 0x7F 0x08 0x04 0x06 0x22 0x00 0x00 0x31

Es sieht so aus, als würde der FSB14 die Adresse nicht bestätigen.
Über einen Tip wäre ich sehr dankbar.

Gruß André

[tic (Gast)]

Andre schrieb:
> Es sieht so aus, als würde der FSB14 die Adresse nicht bestätigen.
> Über einen Tip wäre ich sehr dankbar.

Hallo,

wie kommst Du da drauf?

Ich hab jetzt nicht jedes Bit kontrolliert aber so auf den ersten Blick 
sieht das erst mal gut aus.

Einen FSB14 hab ich jetzt auch nicht hier um das direkt nachstellen zu 
können. Ich müsste es anhand meiner Notizen und Logfiles nachschauen.

Nach der Programmierung muss der FSB14 wieder von LRN auf seine 
Betriebsposition zurückgestellt werden um seine normalen Funktionen zu 
erfüllen.

lg tic

[Andre (Gast)]

Hi,

tic schrieb:
> wie kommst Du da drauf?

Naja.. Ich hatte erwartet, dass die Sequenz nur einmal ausgeführt werden 
kann. Weil der Aktor nach erfolgreicher Ausführung ja eine AktorID != 0 
haben sollte.
Auf der anderen Seite erlischt die LED am Aktor, was darauf hin deutet, 
dass die Sequenz vollständig ist.

Ich bekomme jedoch noch immer keine Bestätigungstelegramme. :-(
Zur Sicherheit habe ich den Aktor auch nochmal zurück gesetzt. Aber ohne 
Erfolg.

Was meintest Du eigentlich mit dem erweiterten Scan, bei Aktoren mit 
mehr als einer Adresse? Wird da die Sequenz einfach mehrfach aufgerufen?

Gruß André

[tic (Gast)]

Andre schrieb:
> Naja.. Ich hatte erwartet, dass die Sequenz nur einmal ausgeführt werden
> kann. Weil der Aktor nach erfolgreicher Ausführung ja eine AktorID != 0
> haben sollte.

Der FSB14 Aktor hat die von Dir gesetzte ID 1 für den ersten Kanal und 
die ID 2 für den zweiten Kanal.
Dies wird in der letzten Nachricht (Byte 5 = 0x01 = ID und in Byte 6 = 
0x02 = Belegt 2 ID's) bestätigt.

Andre schrieb:
> Auf der anderen Seite erlischt die LED am Aktor, was darauf hin deutet,
> dass die Sequenz vollständig ist.

Korrekt.

Andre schrieb:
> Ich bekomme jedoch noch immer keine Bestätigungstelegramme. :-(
> Zur Sicherheit habe ich den Aktor auch nochmal zurück gesetzt. Aber ohne
> Erfolg.

Normalerweise wird zuerst die ID des Aktors gesetzt und danach die 
restliche Konfiguration.

Andre schrieb:
> Was meintest Du eigentlich mit dem erweiterten Scan, bei Aktoren mit
> mehr als einer Adresse? Wird da die Sequenz einfach mehrfach aufgerufen?

Ich hab nichts von einem ERWEITERTEN Scan geschrieben. Der FAM14 scannt 
in der Betriebsart 1 den gesamten Bus nach Aktoren (ID 0-127). Wenn er 
eine Antwort von einer ID bekommt weiß der FAM14 das diese ID vergeben 
ist und wieviele folgenden ID's durch diesen Aktor belegt werden.


Ich würde an Deiner Stelle nach der Vergabe der ID 1 einfach mal die ID 
1 scannen um zu schauen ob der FAM14 auf dieser ID antwortet.

lg tic

[tic (Gast)]

tic schrieb:
> Ich würde an Deiner Stelle nach der Vergabe der ID 1 einfach mal die ID
> 1 scannen um zu schauen ob der FAM14 auf dieser ID antwortet.

ups Fehler ... ich meinte ob der FSB14 antwortet.

lg tic

[Andre (Gast)]

Hallo tic,

der Scan des Buses verhält sich wie erwartet. Ich habe dem FSB14 die 
Adresse 4 vergeben. Während des Scans kam bei Adresse 4 die Antwort vom 
FSB14. Alles gut.

Nun zu den Bestätigungstelegrammen...
Bisher hatte ich das so verstanden, dass der Aktor die Bestätigung 
automatisch verschickt. Dies scheint aber nicht so zu sein. Laut 
Datenblatt des FAM14 werden die Bestätigungen abgefragt.
Wenn dem so ist, wie sieht das Telegramm zur Abfrage aus?

Vielen Dank im Voraus.

Gruß André

[tic (Gast)]

Andre schrieb:
> der Scan des Buses verhält sich wie erwartet. Ich habe dem FSB14 die
> Adresse 4 vergeben. Während des Scans kam bei Adresse 4 die Antwort vom
> FSB14. Alles gut.

Prima

Andre schrieb:
> Nun zu den Bestätigungstelegrammen...

Ich würde vor den Bestätigungstelegramen gerne erst mal wissen ob beide 
Rolladenmotoren schon fahren und ob sie richtig eingestellt sind.

Poste doch bitte mal Deine Einstellungen am Aktor und die Nachrichten 
mit denen Du die beiden Motoren steuerst.

Eventuell wäre es auch sinnvoll wenn Du postest wie du diese Telegramme 
eingelernt hast ... dann hat es jemand anderes der das nachvollziehen 
will einfacher.

lg tic

[Andre (Gast)]

Hallo tic,

tic schrieb:

> Poste doch bitte mal Deine Einstellungen am Aktor und die Nachrichten
> mit denen Du die beiden Motoren steuerst.

Einstellung am Aktor:
Oben: 10 (minimal Einstellung da Fahrzeit über Telegramm)
Mitte: 2 (willkürlicher Wert)
Unten: 2 (keine Wendeautomatik)

Follgende Telegramme schicke ich an den FSB14

Fahre nach oben:
0xA5 0x5A 0x0B 0x07 0x00 0x50 0x01 0x08 0x00 0x00 0x07 0xD0 0x00 0x42

Fahre nach unten:
0xA5 0x5A 0x0B 0x07 0x00 0x50 0x02 0x08 0x00 0x00 0x07 0xD0 0x00 0x43

Stop:
0xA5 0x5A 0x0B 0x07 0x00 0x50 0x00 0x08 0x00 0x00 0x07 0xD0 0x00 0x41

Die Sender ID ist 0x7D0 (2000) habe ich frei gewählt.
Eingelernt habe ich die ID mit folgendem Telegramm:

0xA5 0x5A 0x0B 0x07 0xFF 0xF8 0x0D 0x80 0x00 0x00 0x07 0xD0 0x00 0x6D

Dabei oberen Drehschalter auf 180 und Mitte auf "LRN".

Den 2. Motor habe ich im Moment nicht eingelernt.

Ich kann hören, dass der Aktor schaltet. Ich weiß nicht ob es eine Rolle 
spielt, aber es ist kein Motor angeschlossen. Im Moment liegt der FSB 
neben mir auf dem Schreibtisch.

Gruß André

[Andre (Gast)]

Hallo tic,

kleiner Nachtrag... Ich habe mal schnell 2 LED's anstelle eines Motors 
angeklemmt. Je nach dem welchen Befehl ich schicke, leuchtet eine der 
Beiden.

Gruß André

[tic (Gast)]

Hallo,

Andre schrieb:
> kleiner Nachtrag... Ich habe mal schnell 2 LED's anstelle eines Motors
> angeklemmt. Je nach dem welchen Befehl ich schicke, leuchtet eine der
> Beiden.

Super.

Jetzt musst Du Dich leider ein paar Tage gedulden, denn ich habe leider 
aktuell keinen FSB14 mehr hier um da mal genau zu schauen. Aber ich 
komme die nächsten Tage auf eine Baustelle und kann da mal schauen. Der 
FSB14 hat einige Einstellungen die man ohne PCT14 Software nicht ändern 
kann.

Ich melde mich wieder.

lg tic

[Andre (Gast)]

Hallo tic,

ich habe jetzt noch einen FSR14-2x an meinen Testaufbau gehängt.
- Aktor ID vergeben
- Kanal 1 eingelernt

Der Kanal lässt sich schalten, aber Bestätigungstelegramme kommen keine.
In dem Eltako Dokument 
http://www.eltako.com/fileadmin/downloads/de/Datenblatt/Funktelegramme.pdf 
steht, "Sobald BR14-Aktoren eine Geräteadresse erhalten haben, kann das 
FAM14 Bestätigungstelegramme von den Aktoren abfragen.".

Auch in der Bedienungsanleitung des FAM14 steht, "Nachdem der 
Drehschalter auf Pos. 2 gedreht wurde, oder nach Zuschalten der 
Versorgungsspannung, wird ein Bus-Scan durchgeführt und eine Scanliste 
erstellt. Anschließend werden eingehende Funktelegramme auf den Bus aus 
gegeben, Bestätigungstelegramme von Aktoren nach Scanliste zyklisch 
abgefragt und in den Eltako-Gebäudefunk gesendet."

Hast Du einen Sniffer für dem RS485 Bus? Wenn ja, könntest Du den ja mal 
mitlaufen lassen, wenn bei einem FAM14 auf Betriebsart 2 geschaltet 
wird.

Gruß André

[tic (Gast)]

Andre schrieb:
> Hallo tic,
>
> ich habe jetzt noch einen FSR14-2x an meinen Testaufbau gehängt.
> - Aktor ID vergeben
> - Kanal 1 eingelernt
>
> Der Kanal lässt sich schalten, aber Bestätigungstelegramme kommen keine.
> In dem Eltako Dokument
> http://www.eltako.com/fileadmin/downloads/de/Daten...
> steht, "Sobald BR14-Aktoren eine Geräteadresse erhalten haben, kann das
> FAM14 Bestätigungstelegramme von den Aktoren abfragen.".
>
> Auch in der Bedienungsanleitung des FAM14 steht, "Nachdem der
> Drehschalter auf Pos. 2 gedreht wurde, oder nach Zuschalten der
> Versorgungsspannung, wird ein Bus-Scan durchgeführt und eine Scanliste
> erstellt. Anschließend werden eingehende Funktelegramme auf den Bus aus
> gegeben, Bestätigungstelegramme von Aktoren nach Scanliste zyklisch
> abgefragt und in den Eltako-Gebäudefunk gesendet."
>
> Hast Du einen Sniffer für dem RS485 Bus? Wenn ja, könntest Du den ja mal
> mitlaufen lassen, wenn bei einem FAM14 auf Betriebsart 2 geschaltet
> wird.
>
> Gruß André

Hallo,

dann weiß ich bescheid, ich melde mich sobald ich die Abfrage-Nachricht 
herausgesucht habe. Ich dachte bisher das man mir den Drehstromzähler 
DRSZ14 abfragen muß.

lg tic

[Andre (Gast)]

Hallo tic,

hast Du schon Erkenntnisse zum Thema Bestätigungstelegramme bekommen? 
Ich habe mir alle möglichen Beiträge im Netz angesehen, aber in keinem 
eine Lösung gefunden.
Du bist meine letzte Hoffnung. ;-)



Gruß André

[Max H. (mh182)]

Also ich bekomme die Bestätigungtelegramme vom FSB14.

Habe aber ein FAM14 (Position 2). Ich lese die Telegramme am USB Ausgang 
des FAM 14. Sofern ich mich erinnern kann (muss das ganze heute Abend 
kontrollieren) bekomme ich bei einer Betätigung mit einem Taster (+ 
eingestellte Laufzeit) 2 Telegramme:
* Motor start (Richtung wird angegeben - rauf oder runter)
* Motor hat Endstellung erreicht

Habe aber noch nicht probiert den FSB direkt anzusteuern, sondern habe 
diese immer nur mit den eingelernten Tastern gemacht. Bin leider noch 
nicht so weit, dass ich die Beschattung über meine Software steuere.

lg Max

[Andre (Gast)]

Hallo MAX,

Max H. schrieb:
> Habe aber ein FAM14 (Position 2). Ich lese die Telegramme am USB Ausgang
> des FAM 14.

Das ist genau der Punkt. Der FAM14 muss in Pos 2 zyklisch ein Telegramm 
an die einzelnen Aktoren schicken, worauf diese mit dem 
Status,Bestätigung Antworten. Soweit ist mein Verständnis der FAM14 
Bedienungsanleitung zu Folge.
Mich würde ein Log der Telegramme auf dem RS485 Bus interessieren. Dort 
müsste man den Request des FAM14 sehen.

Gruß André

[tic (Gast)]

Andre schrieb:
> Hallo MAX,
>
> Max H. schrieb:
>> Habe aber ein FAM14 (Position 2). Ich lese die Telegramme am USB Ausgang
>> des FAM 14.
>
> Das ist genau der Punkt. Der FAM14 muss in Pos 2 zyklisch ein Telegramm
> an die einzelnen Aktoren schicken, worauf diese mit dem
> Status,Bestätigung Antworten. Soweit ist mein Verständnis der FAM14
> Bedienungsanleitung zu Folge.
> Mich würde ein Log der Telegramme auf dem RS485 Bus interessieren. Dort
> müsste man den Request des FAM14 sehen.
>
> Gruß André

Hallo,

der FAM14 macht in Stellung 2 einen zyklischen Busscan. Er scannt den 
gesamten Bus. Versuche es mal mit einem fortlaufenden Scan der ID des 
FSB14.

Ich bin jetzt leider auch noch nicht dazugekommen das zu kontrollieren, 
da ich selbst aktuell in den Vorbereitungen meines Heizungsumbaus bin.

lg tic

[Andre (Gast)]

Hallo zusammen,

Ich habe es hinbekommen...

Für die Abfrage der Bestätigungstelegramme muss follgendes Telegramm an 
den entsprechenden Aktor geschickt werden.

-> A5 5A AB FC 00 00 00 00 00 00 00 00 00 9B
A55A = SYNCWORD
AB = HSEQ + LENGTH = Transmit Command Telegramm, Länge 11 Byte
FC = ORG
00 = DATA[3]
00 = DATA[2]
00 = DATA[1]
00 = DATA[0]
00 = ID[3]
00 = ID[2]
00 = ID[1]
00 = ID[0]
02 = Status = Aktor mit Device Adresse 2
A9 = CRC = AB + FC + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 02 = 1A9

Zu beachten ist, dass die Aktoren nur antworten, wenn sich etwas 
geändert hat.

Gruß André

[Bernd (Gast)]

Hallo André,

ich habe zwei FUD14 und die antworten immer!
Also auch, wenn sich nichts geändert hat.

Gruß Bernd

[Karl (Gast)]

Hallo zusammen, vielen Dank vorab für die voran gegangene Arbeit. Der 
Thread hat mir bei meiner Projektierung bis lang sehr geholfen.

Mein System besteht aus einer Siemens S7-1212 mit einem CB1241 als 
serielle RS485-Schnittstelle, einem FBA14 als "Gateway" von der S7-1212 
zum "Eltako-Bus" welches dann über Steckbrücken zum FUD14 verbunden ist.

Adressvergabe, Ansteuerung des FUD14 via S7-1212 funktioniert erst 
einmal einwandfrei.
Nur bekomme ich leider keine Statusmeldung von FUD14 an meine Steuerung.
Wenn ich hier alles richtig verstanden sollte der FUD14 doch automatisch 
ein Bestätigungstelegramm senden, sobald er ein Steuertelegramm 
verarbeitet hat und die rote LED am FUD14 kurz aufblinkt?

Hat evtl. eine Idee bzw. hat es jemand evtl. schon ein ähnliches System 
mit einer S7-Steuerung am laufen und kann mir evtl. den entscheidenden 
Tipp geben. Bin über jegliche Hilfe dankbar.  ;-)

Gruß Karl

[Helmut H. (der_andere)]

Zumindest mit dem PCTool soll man es einstellen können:
Laut PDF:
FUD14/800W konfigurieren:
Folgende Punkte können mit dem PCTool
konfiguriert werden:
■ Einlernen von Tastern mit Einzel- oder
Doppelklick
■ Verhalten nach Stromausfall
■ Minimal- und Maximalhelligkeit
■ Memory
■ Dimmgeschwindigkeiten
■ Ein- und Ausschaltgeschwindigkeit
■ Bestätigungstelegramme
■ Parameter für den Betrieb mit FAH60
und FBH

[Karl (Gast)]

Ich habe leider nicht das PCTool von Eltako.
Haben sie evtl. Information darüber ob die Statusmeldung standardmäßig 
gesendet wird?

[elTacco (Gast)]

Hi,

bin dabei die Eltako Steuerung einzurichten.
Ich habe in den Fluren Bewegungsmelder und Taster und soll 
folgendermaßen funktionieren:
Bei Bewegung schaltet der Bewegungsmelder das Licht auf 40% nach Ablauf 
der eingestellten Zeit schaltet er das Licht auch wieder aus.
Mit den Tastern schaltet man das Licht auf 100% ein und auch aus.
Wenn der Bewegungsmelder das Licht auf 50% eingeschaltet hat und man 
betätigt den Taster, der das Licht auf 100% einschaltet, soll nach 
Ablauf der Zeit des Bewegungsmelders das Licht nicht ausgeschaltet 
werden, erst nach Betätigung des Tasters, der das Licht ausschaltet, 
soll das Licht ausschalten.

Bei mir funktioniert der letzte teil leider nicht wie oben beschrieben, 
sondern so:
Bewegungsmelder ein, Licht 50%
Taster ein, Licht 100%
Bewegungsmelder aus, Licht 0%

Weiß jemand wie man das Problem lösen kann?

Zur Anlage:
fam14 für die Verbindung mit pc
fts14em für die Taster
fts14kem für den Bewegungsmelder
fud14 für die leuchten


Mfg

[RobertoBlanco (Gast)]

Hallo,

hat es hier jemand geschafft einen FUD14 direkt über den RS485-BUS 
anzusprechen? Oder nur im Verbund mit einem FAM14?

Alle meine Versuche den Dimmer direkt (ohne FAM14) anzusprechen waren 
erfolglos: Die Adressvergabe klappt einwandfrei und wird auch vom FUD14 
erfolgreich bestätigt. Bei einem Dimmtelegram hingegen passiert gar 
nichts (keine Reaktion und auch keine Bestätigung).

Bin etwas verzweifelt. Bin dankbar für jeden Hinweis.

[rs485-gast (Gast)]

servus roberto,
bei mir läuft das seit vielen jahren - aus einer sps heraus steuere ich 
die FUD14 direkt an.
was mir damals extrem geholfen hat ist im prinzipp diese info:

https://www.mikrocontroller.net/attachment/169818/Eltako_Funk_Inspektion_pub.pdf

im prinzip ist die ganze kommunikation nach dem enocean-protokoll 
aufgebaut, so hat mir das damals eltako bestätigt.

was bei mir allerdings nicht klappt ist dass die eltakos ein 
bestätigungsprotokoll über den RS485-bus zurücksenden. ich kann aber 
damit leben, da ich noch nie erlebt habe dass ein FUD14 nicht wie 
gewünscht gedimmt hätte. evtl. wäre es im falle eines sps-neustarts 
interessant die werte abzufragen. bin mir allerdings bis heute nicht 
sicher ob es vorgesehen/parametriebar ist dass die FUD14 eine antwort 
über den RS485-bus senden....

[RobertoBlanco (Gast)]

Servus rs485-gast,

danke für die Antwort.

rs485-gast schrieb:
> servus roberto,
> bei mir läuft das seit vielen jahren - aus einer sps heraus steuere ich
> die FUD14 direkt an.
> was mir damals extrem geholfen hat ist im prinzipp diese info:
>
> https://www.mikrocontroller.net/attachment/169818/Eltako_Funk_Inspektion_pub.pdf

Das Dokument kenne ich, allerdings wird auch hier ein "BUS-Master" 
(FTS12-EM) verwendet. Du bist sicher, dass bei Dir kein "BUS-Master" im 
Spiel ist?


Bei mir will das direkte Ansteueren des FUD14 nicht klappen. Hier meine 
Vorgehensweise:

1. FUD14: oberen Drehsteller auf PCT / mittleren Drehsteller auf LRN --> 
LEDs blinken

2. Telegramm an FUD14 (Bus Scan):
A5 5A AB F0 00 00 00 00 00 00 00 00 00 9B

3. Antwort-Telegramm von FUD14:
A5 5A 8B F0 00 01 7F 0C 04 04 42 00 00 51

4. Telegramm an FUD14 (Adressvergabe 0x0D):
A5 5A AB F8 00 00 00 00 00 00 00 00 0D B0

5. Antwort-Telegramm von FUD14:
A5 5A 8B F0 0D 01 7F 0C 04 04 42 00 00 5E

6. LEDs am FUD14 blinken nicht mehr

7. FUD14 oberen Drehsteller auf AUTO / mittleren Drehsteller auf Max


Alle weiteren Versuche den FUD14 anzusprechen scheitern (sehr vieles 
probiert), FUD14 zeigt keine Reaktion....

z.B. folgende Dimmtelegramme

- A5 5A AB 07 02 32 00 0F 00 00 00 0D 00 02
- A5 5A AB 07 02 32 00 09 00 00 00 0D 00 FC
- A5 5A 0B 07 02 32 00 0F 00 00 00 0D 00 62
- A5 5A 0B 05 02 32 00 0F 00 00 00 0D 00 60
- A5 5A 3B 07 02 32 00 0F 00 00 00 0D 00 92


Hat irgendjemand eine Idee was ich falsch mache bzw. wo mein Denkfehler 
liegt??

[rs485-gast (Gast)]

ja klar bin ich mir sicher. ich habe das system damals über den PC 
getestet (per hand bytes an den dimmer gesendet) - nachdem das ging 
wurde die sps entsprechend programmiert. von einem RS485-Ausgang geht es 
über einen FBA14 (einspeisung für BUS+Spannungsversorgung) direkt auf 
die Dimmer. Details sind schon Jahre her - soviel gibt meine Doku von 
damals noch her.

ich weiß wie es sich anfühlt wenn garnichts geht. ich hänge dir mal den 
für dich relevanten ausschnitt aus meinem sps-programm an, so wie er bei 
mir tagtäglich problemlos arbeitet. die dimmer im schaltschrank stehen 
(von oben nach unten) in der stellung auto-min-3. (beim anlernen jedoch 
stellung lt Herstellerdatenblatt).

IF teachIn THEN (Protokoll zum Anlernen des Dimmers)
  stEltakoRS485.Byte01_Sync1:=  16#A5(FIX);
  stEltakoRS485.Byte02_Sync0:=  16#5A(FIX);
  stEltakoRS485.Byte03_Headr:=  16#0B(FIX);
  stEltakoRS485.Byte04_ORG:=    16#07(FIX für Dimmer);
  stEltakoRS485.Byte05_DB3:=    16#02(*FIX?*);
  stEltakoRS485.Byte06_DB2:=    16#00;
  stEltakoRS485.Byte07_DB1:=    16#00;(*01=Max Dimmspeed - im TeachIn 
nicht relevant*)
  stEltakoRS485.Byte08_DB0:=    16#00;
  stEltakoRS485.Byte09_ID3:=    16#00;
  stEltakoRS485.Byte10_ID2:=    16#00;
  stEltakoRS485.Byte11_ID1:=    16#00;
  stEltakoRS485.Byte12_ID0:=    USINT_TO_BYTE(FUD14_ID)(*Address, hier 
wird die einzuprogammierende Adresse angegeben*);
  stEltakoRS485.Byte13_STS:=    16#00(FIX);
ELSE      (Dimmwert senden)
  stEltakoRS485.Byte01_Sync1:=  16#A5(FIX);
  stEltakoRS485.Byte02_Sync0:=  16#5A(FIX);
  stEltakoRS485.Byte03_Headr:=  16#0B(FIX);
  stEltakoRS485.Byte04_ORG:=    16#07(FIX für Dimmer);
  stEltakoRS485.Byte05_DB3:=    16#02(*FIX?*);
  stEltakoRS485.Byte06_DB2:=    REAL_TO_BYTE(DimmY);
  stEltakoRS485.Byte07_DB1:=    16#01(*01=Max Dimmspeed*);
  stEltakoRS485.Byte08_DB0:=    16#0F(sinnvoll laut Datenblatt);
  stEltakoRS485.Byte09_ID3:=    16#00;
  stEltakoRS485.Byte10_ID2:=    16#00;
  stEltakoRS485.Byte11_ID1:=    16#00;
  stEltakoRS485.Byte12_ID0:=    USINT_TO_BYTE(FUD14_ID)(*Address;*);
  stEltakoRS485.Byte13_STS:=    16#00(FIX);
END_IF;

[RobertoBlanco (Gast)]

Tausend Dank! Damit klappt es einwandfrei... Ohne Deine Hilfe wäre ich 
wahrschl. noch länger auf dem Holzweg gewesen.

Einziger Unterschied zu dem was ich gemacht habe ist das Telegramm für 
die Adressvergabe.

Meine Adressvergabe:
A5 5A AB F8 00 00 00 00 00 00 00 00 01 A4

Deine Adressvergabe:
A5 5A 0B 07 02 00 00 00 00 00 00 01 00 15


Beides mal ist der Anlernvorgang erfolgreich, aber anscheinend sind das 
unterschiedliche Dinge. Nur mit der Adressvergabe von Dir schluckt der 
Dimmer hinterher das Dimmtelegramm.

Bestätigungstelegramm bekomme ich auch nicht. Da ich jetzt neugierig 
bin, werde ich mir noch einen FAM14 zulegen und der Geschichte auf den 
Grund gehen. Wenn ich was rausgefunden habe melde ich mich natürlich 
wieder.

Viele Grüße
Roberto

[Tim (Gast)]

Da wäre ich auch sehr daran interessiert. Bitte in jedem Fall deine 
Erkenntnisse hier posten. DANKE!

[rs485-gast (Gast)]

roberto, freue mich wenn es läuft! wenn du noch etwas rasufindest bin 
auch ich immer daran interessiert :-). erwähnenswert finde ich noch, 
dass eltako selbst kein betriebsgeheimnis aus ihren komponenten macht 
sondern meine bisherigen anfragen immer nett und kompetent beantwortet 
hat. für mich immer wieder grund genug gerne zu eltako-komponenten zu 
greifen.

[Ruben P. (drled)]

I am struggeling to teach-in an Eltako FUD14 dimmer (together with 
FBA14) bus coupler. I'm sending the telegram directly over RS485 
(baudrate 57600).

I created a small python program to send the telegram, but doesn't seem 
to function. Also sending it directly trough a terminal program 
(realterm) doesn't work.

The FUD14 doesn't react to the teach-in telegram, and red led keeps 
blinking after sending the telegram.

I tried following telegrams:
0xA5, 0x5A,0x0B, 0x07,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x15]

According to Eltako documentation, the teach in telegram should look 
like this:
0xA5,0x5A,0x0B, 0x07,0xE0,0x40,0x0D,0x80,0x00,0x00,0x00,0x0B,0x00,0xCA

 
import serial                          # import the module 

#com port settings for eltako
#tested with moxa uport usb to rs485 adapter
ComPort = serial.Serial("COM5")
ComPort.baudrate = 57600
ComPort.bytesize = 8
ComPort.parity = 'N'
ComPort.stopbits = 1

     
#set fud14 address to "0B"
teachTelegram = [0xA5,0x5A,0x0B, 0x07,0xE0,0x40,0x0D,0x80,0x00,0x00,0x00,0x0B,0x00,0xCA]

#set dimmer on(0X09), dim with max speed (0x01) & to 100% dim val (0x64)
dim100 = [0xA5,0x5A,0x0B,0x07,0x02,0x64,0x01,0x09,0x00,0x00,0x00,0x0B,0x00,0x8D]

#convert to an array of bytes
data = bytearray(teachTelegram)
print("raw data: ",data)
No = ComPort.write(data)
print(No,"bytes written")

#close com port when finished       
ComPort.close()

Any ideas?