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
Schonmal bei ELV geguckt ? http://www.elv.de/Bus-Haussteuerungssystem/x.aspx/cid_74/detail_1/detail2_1771
Hallo Sven, Danke für den Hinweis! Werd mich da mal umschaun! lg Max
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...
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
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
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
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.
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.
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...
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
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
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
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.
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.
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
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
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
Aber eigentlich ist das OT :-) Mir ist das ja wurscht, da auch interessant...
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
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.
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
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
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
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
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....
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
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
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.
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
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
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
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
Bitte schön: Beitrag "Anforderungssammlung CAN Hausbus mit PIC µC" Ich hoffe das ist so halbwegs gut formuliert. Grüße Timo
Timo E. schrieb: > Ich hoffe das ist so halbwegs gut formuliert. Ja, finde passt super so! Dann kanns ja los gehn :-)
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?
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.
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
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
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
Hallo Max Meine Email ist Stefan@DL4NSC.de 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
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
Hallo Max Der Optokoppler muß in das PWM-Signal. Erst nach dem Optokoppler kommt die Diode mit dem C. Gruß Stefan
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
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
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
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
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
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
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
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
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
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?!
auf paar HZ kommts nich an, dazu is das Auge zu träge.
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
Achso jetz hab ichs erst verstanden. Hab gedacht es geht um die Frequenz des Ausgangs
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
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
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
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
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
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.
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.
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
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.
Hi Max, magst Du kurz von den Neuigkeiten erzählen? Grüße Timo
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
@Max herzlichen Dank für diese Info. Ist der Tastaktor und der Dimmaktor auch ohne PC anlernbar bzw. bedienbar? Gruß Gerd
@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
Gibt es schon neuigkeiten bezüglich des zurücklesens?
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
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
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
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
Ja, genau die Module habe ich im Einsatz und zusätzlich noch eine Schaltuhr FSU12.
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
Und woher weißt du dass der Eingang nicht defekt ist?
Laß nicht den FTS / die Funksensoren den Schaltimpuls senden, sondern Deinen µC. Damit bleibst Du sicher synchron. Gruß Jan
@ 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
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.
Hallo Max, gibt es wo ein PDF mit den Befehlen, oder würdest du es mal posten? LG Gerd
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
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 |
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
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
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
Wo greifst du das Signal ab? Du darfst das nicht am Eingang vom Tastermodul abgreifen.
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.
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)
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!
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
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)
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
> 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
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
auch eine Möglichkeit, nur gibt es diese nicht mit MAX487 Chips, aber für "Torsten" wirds wohl funktionieren!
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
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
> 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!
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
Da hier im Thread ja auch einige den Eltako LUD12-230V verwenden: Beitrag "[V] 2x Eltako LUD12-230V Leistungszusatz 500W"
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?
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.
Es gibt ein Kommando für die Ansteuerung aus der Eltako-Software. Damit sollte es gehen, Details anbei. VG Thomas
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!
Hallo, hat die Serie 14 von Eltako das gleiche Protokoll?
Versuch es mal mit A5 5A 0B 07 02 64 01 0F 00 00 00 0B 00 93 VG Thomas
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.
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!
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ß
> 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".
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ß
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ß
im PDF von "hauptschalter" ist ja auch eine Skizze dort gibt es aber keine 8 (im Gegensatz zur Beschreibung) irgendwie "chaotisch"
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.
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?
"Mit 6-facher Taktrate des neuen RS485-Bus werden ein gehende und ausgehende Informationen wesentlich schneller verarbeitet." 6*9600=57600
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.
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.
@Jan, ist FHEM dann auf dem TP-Link drauf? Gruß Helmut
@anonym Interessant, welche SPS verwandtest du und wie läuft da die Kommunikation ? Resp. das Protokoll ? Danke für die Infos.
@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.
@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!
@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.
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.
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.
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
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ß
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
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.
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.
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ß
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
Kennt jemand die Pinbelegung der 4Pin Brücke vom Eltako FUD14 ? Gruß Frank
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!!!
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
>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 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
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.
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.
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?
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:
1 | getStatus(all); |
2 | getStatus(fud14_1); |
3 | ...
|
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?
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...
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)
@ Max H. benutzt du beim FAM14 den Funk bzw. hast du Funk-Geräte die mit dem FAM14 kommunizieren?
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
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.
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
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: >
1 | getStatus(all); |
2 | > getStatus(fud14_1); |
3 | > ... |
> 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.
@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
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).
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
@ 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:
1 | Sobald BR14-Aktoren eine Geräteadresse erhalten haben, |
2 | 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).
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).
1 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x01\xa8' |
2 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x02\xa9' |
3 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x03\xaa' |
4 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x04\xab' |
5 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x06\xad' |
6 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x07\xae' |
7 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x08\xaf' |
8 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\t\xb0' |
9 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\n\xb1' |
10 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x0b\xb2' |
11 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x0c\xb3' |
12 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\r\xb4' |
13 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x0e\xb5' |
14 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x0f\xb6' |
15 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x10\xb7' |
16 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x12\xb9' |
17 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x13\xba' |
18 | 2014-08-15 14:20:28+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x14\xbb' |
19 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x15\xbc' |
20 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x16\xbd' |
21 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x17\xbe' |
22 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x18\xbf' |
23 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x19\xc0' |
24 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1a\xc1' |
25 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1b\xc2' |
26 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1c\xc3' |
27 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1d\xc4' |
28 | 2014-08-15 14:20:29+0200 [-] recv '\xa5Z\xab\xfc\x00\x00\x00\x00\x00\x00\x00\x00\x1e\xc5' |
29 | 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,...)
1 | 2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
2 | 2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:0000003d] |
3 | 2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
4 | 2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:0000003e] |
5 | 2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
6 | 2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:0000003f] |
7 | 2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
8 | 2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:00000040] |
9 | 2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
10 | 2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:00000041] |
11 | 2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
12 | 2014-08-15 14:42:41+0200 [-] recv [ORG:07, DATA:00807f0f, ID:00000042] |
13 | 2014-08-15 14:42:41+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
14 | 2014-08-15 14:42:41+0200 [-] recv [ORG:05, DATA:50000000, ID:00000001] |
15 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
16 | 2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000002] |
17 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
18 | 2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000003] |
19 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
20 | 2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000004] |
21 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
22 | 2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000006] |
23 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
24 | 2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000007] |
25 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
26 | 2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000008] |
27 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
28 | 2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:00000009] |
29 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
30 | 2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:0000000a] |
31 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
32 | 2014-08-15 14:42:42+0200 [-] recv [ORG:05, DATA:50000000, ID:0000000b] |
33 | 2014-08-15 14:42:42+0200 [-] recv [ORG:fe, DATA:00000000, ID:00000000] |
34 | 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
:
Bearbeitet durch User
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.
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
@ 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
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
@ 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
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é
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.
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
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é
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é
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
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é
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
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.
1 | Scan der Adresse 0 |
2 | -> A5 5A AB F0 00 00 00 00 00 00 00 00 00 9B |
3 | A55A = SYNCWORD |
4 | AB = HSEQ + LENGTH = Transmit Command Telegramm, Länge 11 Byte |
5 | F0 = ORG |
6 | 00 = DATA[3] |
7 | 00 = DATA[2] |
8 | 00 = DATA[1] |
9 | 00 = DATA[0] |
10 | 00 = ID[3] |
11 | 00 = ID[2] |
12 | 00 = ID[1] |
13 | 00 = ID[0] |
14 | 00 = Status = an Adresse 0 |
15 | 9B = CRC = AB + F0 + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 00 = 19B |
16 | |
17 | Antwort von dem Baustein LRN |
18 | <- A5 5A 8B F0 00 02 7F 08 04 02 11 00 00 1B |
19 | A55A = SYNCWORD |
20 | AB = HSEQ + LENGTH = Transmit Command Telegramm, Länge 11 Byte |
21 | F0 = ORG |
22 | 00 = DATA[3] = von Adresse |
23 | 02 = DATA[2] = Baustein benötigt 2 Adressen |
24 | 7F = DATA[1] |
25 | 08 = DATA[0] |
26 | 04 = ID[3] = Vermutlich FSR14-2x |
27 | 02 = ID[2] |
28 | 11 = ID[1] |
29 | 00 = ID[0] |
30 | 00 = Status |
31 | 1B = CRC = 8B + F0 + 00 + 02 + 7F + 08 + 04 + 02 + 11 + 00 + 00 = 21B |
32 | |
33 | Setze Addresse 1 |
34 | -> A5 5A AB F8 00 00 00 00 00 00 00 00 01 A4 |
35 | A55A = SYNCWORD |
36 | AB = HSEQ + LENGTH = Transmit Command Telegramm, Länge 11 Byte |
37 | F8 = ORG |
38 | 00 = DATA[3] |
39 | 00 = DATA[2] |
40 | 00 = DATA[1] |
41 | 00 = DATA[0] |
42 | 00 = ID[3] |
43 | 00 = ID[2] |
44 | 00 = ID[1] |
45 | 00 = ID[0] |
46 | 01 = Status = übernehme Adresse 1 |
47 | A4 = CRC = AB + F0 + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 00 + 00 = 1A4 |
48 | |
49 | Antwort von dem Baustein - ACK |
50 | <- A5 5A 8B F0 01 02 7F 08 04 02 11 00 00 1C |
51 | A55A = SYNCWORD |
52 | AB = HSEQ + LENGTH = Transmit Command Telegramm, Länge 11 Byte |
53 | F0 = ORG |
54 | 01 = DATA[3] = von Adresse |
55 | 02 = DATA[2] = Baustein benötigt 2 Adressen |
56 | 7F = DATA[1] |
57 | 08 = DATA[0] |
58 | 04 = ID[3] = Vermutlich FSR14-2x |
59 | 02 = ID[2] |
60 | 11 = ID[1] |
61 | 00 = ID[0] |
62 | 00 = Status |
63 | 1C = CRC = 8B + F0 + 01 + 02 + 7F + 08 + 04 + 02 + 11 + 00 + 00 = 21C |
Ich hoffe das hilft Dir weiter. lg tic
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é
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é
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
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é
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 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
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é
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
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é
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é
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
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é
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
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é
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
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é
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
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é
Hallo André, ich habe zwei FUD14 und die antworten immer! Also auch, wenn sich nichts geändert hat. Gruß Bernd
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
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
Ich habe leider nicht das PCTool von Eltako. Haben sie evtl. Information darüber ob die Statusmeldung standardmäßig gesendet wird?
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
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.
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....
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??
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;
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.