Siemens BCU Möglichkeiten

[BlackDevil]

Hallo Zusammen,

gibt es irgendwo eine Übersicht was mit dem Siemens BCU und den Standard ETS Bibliotheken möglich ist? Oder anders gesagt: was kann man mit der Siemens BCU und den Standardbibliotheken bauen?

Es gibt ja für die BCU verschiedene Dinge die man vorne abklemmen kann, ergo sollte da ja das ein oder andere möglich sein?

Danke und Gruß

[Masifi]

Diese spezielle Siemens BCU von der wir hier immer reden ist im "einfachen" Sinne gesagt nur ein "Umsetzer von UART auf KNX". Sie macht natürlich mehr, aber nicht das was du dir glaube erhoffst. Für diese Siemens BCU gibt es keine ETS-LIB, sie hat einfach keine "Funktionen" für die man überhaupt eine Lib brauchen würde :-)

[BlackDevil]

Richtig. Die Produktdatenbank ist abhängig von dem was auf die Anwenderschnittstelle aufgepflanzt wird und da gibt es ja schon eine Menge. Jetzt ist die Frage, ob das schon mal jemand analysiert hat?

Wenn ich die Produktdatenbank für einen 4 Fach Taster hernehme und vorne was anderes draufschnalle als den original Taster könnte ich ja dennoch die binären Signale und was die Datenbank sonst noch kann benutzen?

Man müsste nur wissen wie die Daten auf den BCU übertragen werden müssen damit die Datenbank das auch so versteht wie bei einem Taster.

[Albatros62]

Was Dir vorschwebt ist wahrscheinlich etwas wie das BAOS-Modul von Weinzierl. Dafür gibt es entsprechende Produkt-Dateien. Auf der Controller-Seite kann man dann die entsprechend konfigurierten Objekte per serieller Schnittstelle lesen und schreiben.

[Ing-Dom]

Wenn ich die Produktdatenbank für einen 4 Fach Taster hernehme und vorne was anderes draufschnalle als den original Taster könnte ich ja dennoch die binären Signale und was die Datenbank sonst noch kann benutzen?

Man müsste nur wissen wie die Daten auf den BCU übertragen werden müssen damit die Datenbank das auch so versteht wie bei einem Taster.

Klar geht das. Aber diese binären Signale sind sehr Low-Level. Da werden vereinfacht ausgedrückt einfach nur die Telegramme vom Bus durchgereicht.

Du kannst dir die BCU in etwas vorstellen wie eine Netzwerkkarte für einen PC... bildet im wesentlich die Physik ab, Intelligenz steckt im Treiber/Software.
Ein µC ist auf der BCU auch nicht drauf - der steckt bei dem Konzept im Frontend, also den Wippen...

[BlackDevil]

Mir ist klar was der Busankoppler macht und warum es die Konnekting Suite gibt. Auch ist klar, dass das Frontend einen Mikrocontroller braucht der seriell mit der BCU Kommuniziert. Klar kann ich mir damit alles mögliche bauen, in sofern ich die Produktdatenbank erstellen kann. Da kommt die Suite zum Einsatz. Deshalb die Überlegung die originalen Produktdatenbanken für Custom Frontends zu nehmen das Tasterbeispiel war ein Beispiel, es gibt ja auch komplexere Frontends.

[jentz1986]

Aber das hat doch nichts mit der BCU zu tun. D.h. wenn ich mir die MicroBCU nehme und die mit nem SAMD verheirate, dann kann ich da auch vier Taster dranlöten und dann habe ich einen vierfach Taster.
Das bedeutet noch lange nicht, dass ich dann eine Standard *.knxprod daraufbügeln kann. Die Siemens BCU und die MicroBCU sind wie VW Up und Skoda Fabia. Die Frage die Du stellst ist verkürzt übersetzt ein bisschen wie: Kann ich Android Auto auf dem VW Up nutzen. - Die Auswahl des Radios definiert das beim Auto-Beispiel.

Verlängert: Egal mit welcher BCU du unterwegs bist, wenn man eine Möglichkeit hätte die knxprod über das ETS Programmierprotokoll auf den MicroController zu bekommen, dann kann man die darin enthaltenen Informationen nutzen. Eine knxprod enthält IMHO aber keine Funktionen wie "digitalRead(3)" - also keine Firmware für den eigentlichen Hardwarezugriff, sondern eben Definitionen, wie der Speicherbereich mit Parametern gefüttert werden kann und Adresszuweisungen. Ein Bischen wie das Schreiben auf eine SD Karte, deren Informationen dann von einem Programm ausgewertet wird. Das Programm ist aber fix auf dem Gerät.

Um also nun einen Siemens Taster zu simulieren, müsstest Du die Firmware bauen, die den Physikzugriff realisiert, also z.B. den Pin x auf Masseschluss abfragt. Dann müsstest Du eine Speichertabelle so aufbauen, wie Siemens das macht. Dann müsste man das ETS Programmierprotokoll nachbauen um die parametrierte knxprod in die Speichertabelle zu bekommen. Dann müsste das alles zusammenspielen. - Es ist also einfacher, das Gerät direkt zu entwickeln...

[Sonnengruesser]

Hier gibt's einen KNX Stack von thesing, der theoretisch auch auf einem SAMD21 laufen könnte. Ist halt ein "Konkurrenzprodukt" zu KonnektING (und deutlich aufwendiger umzusetzen).
Außerdem müsste der KNX Stack auch noch auf die TP-Schnittstelle mittels BCU angepasst werden. Dann darfst du noch die Applikationssoftware basteln, die die ETS-Daten auch richtig verwendet.

Du kannst auch noch bei SelfBus reinschauen - die verwenden existierende knxprod und bauen "kompatible" HW dazu. Die kennen sich auch mit dem reverse-engineering der knxprod-files aus. Die Busanbindung ist aber sehr low-cost und mMn kagge. Außerdem wurde deren Lieblings-µC abgekündigt und auch nicht alle Projekte auf neue übertragen soweit ich weiß.

[Masifi]

Ist halt ein "Konkurrenzprodukt" zu KonnektING (und deutlich aufwendiger umzusetzen).

verstehe ich das richtig, du sagst das dieser Stack aufwendiger umzusetzen ist als KONNEKTING !? :-)

[BlackDevil]

Da war ein Denkfehler in meiner Überlegung .... die Prod ist ja das entscheidende auf dem Prozessor, nicht die Übertragung zwischen Prozessor und BCU.

So einfach kann’s gehen

[tuxedo]

Sobald die ETS zum Einsatz kommt wird man sich in einer mehr oder weniger dunklen Grauzone bewegen. Entweder weil man selbst KNXprod Dateien erzeugt hat die man mit Zertifikaten signiert hat die man nicht so einfach verwenden kann und darf (=extrahiert aus der ETS), oder weil man ein anderes Gerät imitiert/Nachbauten und damit ggf. die Rechte des Urhebers des nachgebauten Geräts verletzt.

Deshalb haben wir die Suite, und der Einfachheit wegen unser eigenes Programmierprozedere mit KNX Bordmitteln.

Da ich schon Kontakt mit der KNX Assoc. hatte und weiß wie die rechtlich drauf sind, gehe ich da kein Risiko ein. Nicht heute und nicht in Zukunft. Das Risiko dass das Projekt wegen rechtlicher Details stirbt ist mir persönlich zu heiß.

[Sonnengruesser]

verstehe ich das richtig, du sagst das dieser Stack aufwendiger umzusetzen ist als KONNEKTING !? :-)

Matthias ich vermisse deinen Ironie-smiley
Ehrlich gesagt hab ich mich nicht im Detail eingearbeitet, aber allein die offiziellen xml-files sehen kompliziert und umfangreich aus. Und dann die Kommunikationsebene umbauen mit den inkompatiblen Klassen und Funktionen....
Obwohl es schon nett wäre alles in der ETS zu haben.

[BlackDevil]

Ich weis davon las ich bereits. Ne klar, hab meinen Denkfehler entdeckt ... Danke

[BlackDevil]

Eine Frage schiebe ich hinterher: was unterscheidet den Weinzierl BAOS von Konnekting?

[Albatros62]

Konnekting ist Software und besteht aus der Konnekting Suite (analog zur ETS) und einer Bibliothek, die in das eigene Mikrocontroller-Programm integriert wird. BAOS-Module sind Hardware und beinhalten einen Controller, eine BCU und eine Schnittstelle zum eigentlichen Gerät, in das sie integriert werden sollen. M.W. sind sie KNX-Zertifiziert. Es gibt eine Produktdatenbank, mit deren Hilfe sie über die ETS konfiguriert und parametriert werden können. Ich hatte den Link Adhoc aus dem Internet geholt und habe mir dieses spezielle Modul nicht angeschaut. Vor einiger Zeit hatte ich mich mal mit einem Modul mit serieller Schnittstelle beschäftigt. Es funktionierte im Prinzip so, dass man im BAOS viele KO's hat, die über die ETS mit einem DPT und einer GA programmiert werden. Über die serielle Schnittstelle kann ich das KO über eine ID mit einem Wert beschreiben, der dann vom BAOS unter der entsprechenden GA auf den Bus geschrieben wird und umgekehrt. Man kann also ETS (KNX)-kompatible Geräte mit Zertifikat entwickeln. Konnekting nutzt dagegen das KNX-Protokoll zur Kommunikation zwischen den Geräten, funktioniert daher auch mit KNX-Aktoren und -Sensoren der verschiedenen Hersteller. Allerdings kann man Konnekting-Geräte nicht mit ETS konfigurieren und umgekehrt. Auch eine gemeinsame Dokumentation ist (noch?) nicht möglich. Es würde mich aber nicht überraschen, wenn es eines Tages sogar eine Schnittstelle zur Datenübernahme (benutzte GA's usw.) aus ETS geben würde. Ich finde es enorm, was Konnekting bereits in der Beta-Phase kann.