RS 232 Daten an KNX interfacen

[swiss]

Hallo Robert

Diese Variante ist wieder für Leute die auch selber Programmieren.


Ich persönlich wäre immer noch dafür (da auch in deiner Version ein uC benötigt wird) mit i2c die Qt auszulesen und über RS232 (braucht einen MAX232) oder USB (braucht eine ftdi platine von UART auf USB) an das WG übertragen.

Das macht im uC ein paar Zeilen und ein Miniplugin für die Logik und das senden der gewünschten Werte an KNX.

.Ich habe momentan auch nur beschränkt Zeit und bin im programmieren auch kein Profi.

Vor allem kommt es dann auch noch auf die Pogrammiersprache an. Bei uC habe i h bis jetzt nur mit BASCOM Basic und ATMEGA was gemacht. Geht aber recht gut.

[Robert]

Hallo Patrik,

mal ehrlich: Wenn du selber schon sagst, dass es dafür auch einen uC braucht - warum nicht einfach ein "Tastermodul" für einen BCU bauen?

So:
- hat man alle Features eines "echten" Tasters (wie gesagt - Flankensteuerung, Jalo-Programm, Dimmen, etc - out-of-the-box und zu 100% konform)
- kann man per ETS parametrieren (wahnsinniger Vorteil)
- können es auch Leute nutzen die kein Wiregate haben
- läuft es stabil und zuverlässig, da kein "Minicomputer" dazwischen
- kann man den Koppler sogar hinter den Taster packen und quasi normal benutzen
- muss kein extra Kabel für den RS232 gelegt werden...

Gäb für mich überhaupt keine Überlegung?

Gruß
Robert

[swiss]

Naja die anbindung über das WG ist multifunktionaler. Da kannst du auch sehr einfach z.B. eine Codetastatur machen. Klar hat jede Variante ihre Vorzüge und wenn du scheinbar Spezialist in sachen uC-> BCU bist, wärst du warscheinlich der beste Kontakt für joc.

[joc]

Hört sich ja auch sehr interessant an, der Vorschlag von Robert. - Die Idee per uC direkt auf eine BCU hatte ich ja zumindest auch schon mal geäußert. Allerdings bin ich mir jetzt nicht ganz sicher, ob Robert nun ein uC und eine BCU meint, die zusammen dann alle 8 der 10-fach Sensortaster ans KNX interfacen? Für den uC sollte das ja kein Problem sein, anhand der aus den einzelnen Räumen kommenden Change Flags zuzuordnen, welcher Taster in welchem Raum nun gerade welchen Befehl sendet. Dem uC müsste man dann ja beim Flashen die GA mitteilen und auf ETS verzichten. Für mich wäre dies trotzdem die eleganteste Lösung, wobei Makki hier ja meinte, dass das wohl nur wenige Experten programmieren könnten.
Das man in der ETS dann irgendwie mit Dummys arbeiten muss, war mir schon klar, nur will ich ja nicht ständig die Funktionen der Taster ändern.
Was das eventuell noch für Nachteile hat, ist mir aber vielleicht noch nicht ganz klar.
Einen "echten" KNX-Taster zu nehmen, dessen PEI-Output vom uC emulieren zu lassen und auf eine BCU zu geben eröffnet dann ETS Parametrierung, aber können auf diesem Weg dann wirklich alle 80 Schaltmöglichkeiten übermittelt werden? Ich glaube hier waren dann wohl 8 uC und 8 einzelne BCU's hinter jedem Taster gemeint, wobei ich dann aber auch KNX Verkabelung bräuchte, die leider nicht überall verlegt ist?? (Teils "normales" 5-adriges ungeschirmtes 1,5Quadrat)
Sehe ich das so richtig - Bin jetzt auch etwas verwirrt, da leider doch offensichtlich zu wenig Ahnung...
Danke aber nochmals für Eure guten Ideen! Ohne so ein super Forum wäre jemand wie ich ja komplett aufgeschmissen!

[swiss]

Hmmm...

Wenn ich das richtig im Kopf habe kann ein BCU für Taster maximal 8 Schaltbefehle (Taster) haben. Da hätte das WG den Vorteil, dass es keine Limitation gibt.

Ich kann mit einem Plugin auch problemlos 200 oder mehr Taster/Befehle auf den KNX BUS bringen. Allerdings ist das mit dem auswerten mehrerer QT's mit nur einem uC und deinen vorhandenen RS232 QT's nicht möglich, da meistens nur 1 UART am uC zur Verfügung stehet und RS232 eigentlich nur für Punkt zu Punkt Verbindungen spezifiziert ist. RS232 ist kein BUS der für mehrere Teilnehmer gedacht ist. Das Problem wäre also wenn man die einfach paralell an RS232 anschliesst und mit dem uC ein P sendet alle antorten und nur unauswertbarar Müll rauskommt.

Desshalb am besten I2C dann reicht 1 uC vollkommen aus und der kann auch mehrere hunder Tasten auswerten wenn es sein muss, und die dann über einen USB-Seriellwandler an das WG senden

[joc]

jetzt will ich aber auch mal für Verwirrung sorgen und nochmal meinen ursprünglichen Plan posten, der mir doch mittlerweile auch wieder gar nicht mehr so schlecht gefällt. Bitte dazu auch mal eine Meinung abgeben.
Ich hatte ja schonmal gepostet, dass eine Verteilmatrix-Schaltung fast fertig ist, die immer nur den ersten 1103, der gerade ein Change meldet mit dem Empfänger verbindet. Gleichzeitige Tastmeldungen unterschiedlicher Sender werden auf Hold gelegt und da der 1103 seine Tastmeldung ja zwischenspeichert, spuckt er sie dann eben kurz später aus, wenn er dann als nächstes durchgeschaltet wird.
Diese schaltung sollte dann einfach vor den Empfänger uC des 1103-Evaluation Board (ein darauf zugeschnittener ASIC) der für jede Taste eine korrespondierende LED ansteuert. Also ich drücke Taste 1 und LED1 leuchtet dann solange, wie ich drücke, etc...
Statt der LED's wollte ich dann Optokoppler anschließen, die mit 10 Binäreingängen eines 32-fach KNX Moduls verbunden sind und außerdem auch die Change-Leitung der 8 verschiedenen 1103 aus den einzelnen Räumen auf 8 weitere Kanäle des 32-fach KNX Moduls durchschleifen.
So weiß dann also der EIB schonmal, aus welchem Raum welche Taste gesendet wird und eine Logik im HS sollte dann daraus den gewünschten Befehl generieren. Hierzu nochmal die Frage, mit wieviel Verzögerung hier wohl zu rechnen wäre und ob Ihr das für machbar haltet?
Da ich mir wegen 1-Wire Temp Sensoren und (hoffentlich) der WP-Anbindung sowieso ein WG zulegen will, ließe sich dieses Prinzip doch vielleicht auch per 3 Parallelport-USB Interfaces wieder mit WG-plugin lösen?
Also Empfänger uC- Parallel -Output und durchgeschliffene Change-Outputs auf 3 USB-Parallelport-Interfaces (da eines von diesen meines Wissens ja nur 8 Leitungen verarbeiten kann?!) und ein WG Plugin macht dann die entsprechende Zuordnungslogik.
Ist dieses auch machbar und evtl. besser/schneller als mein erster Vorschlag?

[makki]

Es führen - wie immer - viele Wege nach Rom
Der eine nimmt lieber dies oder das, BCU ist halt eher was für dicke geschlechtsteile..

Jedenfalls, was ich sagen will: wenn wir QFN-Chips löten usw. dann machen wir HW, eher im DIY-Forum, weil für 99,99% ist das nix- wenns das dann via RS232 "aktiv" ausgibt ists im Plugin easy..
Vielleicht sollte man "Featurewusch RS232" im WG Forum (das geht, ganz einfach) dann aber bitte doch von krassem HW-Design trennen und BCU-Assembler - das geht bestimmt auch - ist aber nicht meine Welt

Makki

[joc]

Mit dem Hardware DIY wollte ich hier Niemanden belästigen - habe meine Pläne hierzu ja nur auf Nachfrage zur Diskussion gegeben.
Da für Makki ein "aktiver" RS232 Output für ein "easy" Plugin wohl Voraussetzung ist und auch Swiss Probleme sah, den RS232 Output des 1103 direkt an den WG RS232 Port anzuschließen, fällt diese Lösung dann wohl schonmal weg.
Muss mich ja nun jetzt für einen der anderen "Wege nach Rom" entscheiden. Übrig geblieben sind dann also:

A: Touch-Sensor->uC->KNX Buskoppler->KNX Event
B: Touch-Sensor->Arduino uC->USB->WG->Plugin->KNX Event
C: Touch-Sensor->Testboard-uC->"analoger" LED-Einzeloutput->KNX Multich.Bin.Input->HS Logik->KNX Event
D: Touch-Sensor->Testboard-uC->"analoger" LED-Einzeloutput->3xParallelport-USB Adapter->WG->Plugin->KNX Event

In C und D ist ja bereits bis zum LED Output alles funktionierend vorhanden. Ob Lösung D mit dem Parallelport-USB Adapter überhaupt sinvoll ist, bzw. mit einem "easy" Plugin zu lösen ist, kann mir Makki ja bestimmt verraten. Wie schon im letzten Post geschrieben, fehlt mir der Weitblick, hier jetzt die Entscheidung zu treffen und es wäre hilfreich, hierzu nochmal ein paar Meinungen zu bekommen.
Wenn sich jemand findet, der die Software für den elegantesten direkten Weg "A" im Rahmen von ein paar Hundert € Honorar zu schreiben, wäre das aber doch mein Favorit.

[Robert]

für "ein paar hundert Euro" mach das... *g* Ich guck mir morgen mal die Spec von dem Touchsensor an.

Grüße
Robert

[joc]

Hallo Robert,
Hier gibts das Datasheet:
QT1103 datasheet pdf datenblatt - Quantum Research Group - QTOUCH
Wie schon weiter oben im Thread geschrieben, wären bei dieser Lösung die "change"-leitungen aller 8 sensorchips auf 8 pins eines uC geschaltet und wenn ein Tastendruck von einem der 1103 erkannt wird, setzt dieser das change-flag und wartet auf ein ASCI "P" auf einer RS232- Rx Leitung, welches den Poll auslöst. Dadurch wird das Flag auch wieder gelöscht.
Ein bereits im Bau befindlicher Multiplexer verbindet hierbei nur den RS232 Port des jeweils ersten Chip, der gerade einen Tastendruck meldet mit dem uC.
Aus der Logik-Verbindung aus Poll (=welche Taste) und erkanntem Change-Pin (=welcher Raum) sollte dann eine im uC Code definierte GA auf den KNX Bus rausgehen.
Das sollte dann so grob umrissen die Aufgabe definieren.
Bin gespannt, ob Du den Job annimmst - selbst Makki hielt das ja für die beste Lösung, nur halt seiner Meinung nach in der Königsklasse des Programmings denen mit den "dicken Geschlechtsteilen" vorbehalten ;-)

[Robert]

Hi joc,

ich will noch mal kurz ein paar Sachen zu bedenken geben:
Einen "Tasteraufsatz" für eine bestehende BCU mit einem bestehenden Applikationsprogramm/Produktdatenbank erlaubt es, völlig KNX-konform bis zu 9 Tasten und 8 LEDs anzusteuern. Bitte schaue dir dazu dieses http://www.merten.de/uploads/tx_seqd...URZ_6227xx.pdf Datenblatt an bzw. lade dir falls möglich die Produktdatenbank runter und probier sie in der ETS aus.

Alles, was über diese 9 Tasten/8 LEDs hinaus geht erfordert ein eigenes BCU-Programm (noch evtl. machbar - aufwendig) und eine eigene Produktdatenbank (für nicht-KNX-Mitglieder unmöglich) um das ganze in der ETS parametrieren zu können. (es sei denn wir finden ein Aufsteckgerät was mehr Tasten hat)

Das "Einsammeln" der Daten über den propriertären Bus des QT1103 erfordert pro Teilnehmer 3 Datenleitungen(CHANGE + 2W, damit Push-Pull genutzt werden kann - aufgrund der Leitungslänge ratsam) + Versorgung . Damit fällt 2x2 Klingeldraht schon raus, abgesehen von den möglichen Störungen. Zudem braucht es passende Stecker, den "Multiplexer", sternförmige Verkabelung etc. Was machst du mit Status-LEDs? Dein QT1103 kann da nichts ansteuern, d.h. du brauchst dafür noch einen Controller am Panel zzgl. evtl. eigenem Bus bzw. man muss das Protokoll erweitern - da sind wir fast beim EIB!

Eine gebrauchte BCU kostet ca. 15 Euro. Die hinter jedem Panel, so wie es auch vom Hersteller und der EIBA gedacht ist, funktioniert das sicher. Ein Aufsteckmodul ohne noch weitere Busleitungen. Du kannst völlig nach belieben "das Grüne" zu den Tastern ziehen. Spannungsversorgung ist in einem gewissen Rahmen auch mit drin (müssen wir gucken vom Powerbudget), sonst auch standard-konform per gelb-weiß. Du hast elektrisch keinen "single-point-of-failure", was für die Beleuchtungssteuerung und den WAF vielleicht auch von Vorteil ist. Und mit 9 Tasten haben wir eine realistische Größenordnung pro Touchfeld.

Überleg es dir!

Grüße
Robert

[joc]

Hi Robert,
ich denke, die EIB konforme Methode scheitert bei mir an den Kabeln. Teils 5-adrig unverdrillt NYM 5x1,5 und teils geschirmtes unverdrilltes 4-adriges Tel.Kabel. Das Ganze bei Längen um die 20Meter sternförmig. Oder läuft damit der EIB eventuell trotzdem stabil. Beim Bau/Umbau wurde leider zu spät an ein "echtes" Bus-System gedacht :-(
Status Led's wären mir nicht so wichtig.
Grüße,
Joc

[Robert]

Hi!

An das NYM würde ich per se nichts, aber auch gar nichts anderes als 230V anschließen. Oder DALI etc - wo ich aber nie an andere Kleinspannungsgeräte gehe.

Was das 2x2 Telefonkabel angeht: Persönlich würde ich auf jeden Fall sagen: Ist einen Versuch wert! Perfekt ist es sicher nicht, aber was ich so wahrnehme ist, dass der EIB sehr robust ist.

Falls du schon teilweise KNX hast, würde ich an deiner Stelle einfach mal den Versuch mit ein paar einfachen Tastern machen und den ganzen Bus zusammenführen. Schätze mal robuster aus ein serielles Protokoll sowieso, zumal bei 4 Adern das sowieso unglücklich ist (siehe vorheriger Beitrag).

Gruß
Robert

[makki]

Jetzt muss ich doch nochmal als VDE-Laie:
irgendwas - jedwedes im NYM mit 230V ist versuchter totschlag, illegal, mordversuch, kernschrott, whatever!
Der KNX funzt darüber IMHO noch eher wie RS232, wie Robert schon schrieb, aber das ist trotzdem totaler mumpitz, das darf man nicht und dafür gibt es auch 1000 gute Gründe!

Daher ja auch die initialen Fragen: "Was ist das Ziel?" Machen kann man viel, nicht alles davon ist immer unbedingt sinnvoll
Wenn man versucht aus sch* (falsche Verkabelung) Gold zu machen - wirds halt schierig; man könnte das auf beiden Seiten mit 1,5kv isolieren, dann werden wir langsam wieder legal aber dann ist die Schlitzfräse günstiger

Makki

[joc]

Ich weiß, das das mit der Verkabelung blöd ist, hab mich auch schon selbst genug geärgert, erst zu spät von KNX erfahren zu haben.
Die NYM Kabel sind aber schon getrennt vom 230V Netz verlegt und mit Leitungstreibern à la SN75LBC184 und evtl. zusätzlichen Optokopplern sollte der RS232 Output auch sicher und sauber am anderen Ende ankommen.
Aber wenn Ihr nun meint, dass KNX auch mit meiner Verkabelung klarkäme und sich eine 10er Lösung findet, wäre das auch mein Favorit. Nur brauche ich dann aber auch je einen uC zwischen einzelnem Sensor und Buskoppler, oder?
Zweite Wahl wäre dann meine Lösung "A", wenn Robert das hinbekommen sollte:
Touch-Sensor->Schaltmatrix->uC->KNX Buskoppler->KNX Event
Da wäre ich mit der Einschränkung, hier in der ETS keinen Einfluss zu haben, schon zufrieden. Denke nicht, dass ich meine Tasterbelegung oft ändern werde und notfalls könnte man da ja auch nur die Aktoradressen anpassen oder eben nochmal den uC neu flashen.

In Sachen WP scheint sich ein Weg gefunden zu haben. An das Protokoll zwischen Konfigurationsprogramm und WP komme ich wohl nicht ran, aber ich bekomme in Kürze ein Angebot zur Programmerweiterung der SLS500 um eine definierte RS232 Kommunikation, was hoffentlich bezahlbar ausfällt.
Einen RS232 Sniffer habe ich aber testweise auch schon mal dazwischengehängt und kann z.B. sehen, was das Konfigurationsprogramm ausspuckt, wenn ich Betriebswerte der Anlage ändere.
Wenn es jemanden interessiert, kann ich ja mal per PN den Teamviewer Zugang vom WP Kontrollrechner schicken, auf dem dieses Setup gerade läuft.