knd als Linienkoppler

[ITler]

Eine ausreichend einfache Möglichkeit, mit dem knxd zu reden, wird es demnächst geben (sämtliche existierenden Methoden sind … eher anstrengend). Bin noch am Nachdenken, wie ich das konkret integrieren mag.

Ich wollte mal vorsichtig nachfragen, ob demnächst vielleicht schon einen Zeit-Stempel bekommen hat :-)
Jetzt wo die Tage kürzer und die Abende dadurch länger werden, findet sich wieder Zeit das eine oder andere Projekt voran zu treiben.
Und viele hängen irgendwie mit dem KNXD zusammen :-)

[ITler]

Eine ausreichend einfache Möglichkeit, mit dem knxd zu reden, wird es demnächst geben (sämtliche existierenden Methoden sind … eher anstrengend). Bin noch am Nachdenken, wie ich das konkret integrieren mag.

Wenn Du hier einen Tester brauchst, darfst Du dich gerne melden, gerne auch in einer sehr frühen Phase schon.
Ich bin gerade dabei eine HCL-Simulation zu bauen und bevor ich hier unnötig in die falsche Richtung laufe, würde mir das entgegen kommen!

[Smurf]

Es sei denn jemand baut einen Software-Serial-Treiber für KNXD.

Bitbang-Seriell mit 19200 Baud sollte eigentlich kein Problem sein, das hat vor ein paar Jahren jemand sogar in Python geschafft.
Das würde ich aber auf keinen Fall in den knxd selber einbauen, sondern als externes Programm auf einer PTY aufsetzen und den knxd damit so reden lassen wie mit jeder anderen Seriellen auch.

Eine Integration in KNXD erscheint mir trotzdem zielführender.

Das auf jeden Fall!

Wobei man sich dafür wahrscheinlich tiefer einarbeiten muss.

Nicht unbedingt. Filter sind eigenständige Klassen und es gibt ein paar Beispiele (zB "pace"-Filter), die viel aufwändiger sind als die Entscheidung ob man ein Paket weiterschickt oder nicht.

[SirSydom]

Coole Ideen. Ich bastle auf jeden Fall gerade an einer RasPi Aufsatzplatine, auf der 2 BCUs (MicroBCUs) Platz finden und ein 12-30V DCDC Netzteil.
Hat dann einem REG Gehäude Platz und KNX und Versorgung kann regulär von oben eingespeist werden.

Die zweite BCU wrd aber nur auf einem RasPi 4 ansprechbar sein. Es sei denn jemand baut einen Software-Serial-Treiber für KNXD.


2021-01-17 22_38_18-3D Viewer.png

Kann man machen, aber bitte mit einem brauchbaren Programm das direkt mit den beiden knxd-Prozessen redet.

Eine Integration in KNXD erscheint mir trotzdem zielführender. Wobei man sich dafür wahrscheinlich tiefer einarbeiten muss.

[ITler]

Das wollte ich so jetzt nicht schreiben
Habe 2 Anläufe genommen direkt gegen den knxd zu entwickeln und bin 2 Mal gescheitert. Bin zwar nicht der Programmierer vor dem Herrn, empfand das jedoch Recht sperrig.

Wenn Du hier Abhilfe schaffst würde mir das bei meinem aktuellen Plan sehr entgegen kommen!

Das Parsen von Groupsocketlisten ist auch nicht immer angenehm

[Smurf]

Argl. Ja, von hinten durch die Brust ins Auge. ;-)

Kann man machen, aber bitte mit einem brauchbaren Programm das direkt mit den beiden knxd-Prozessen redet.

Eine ausreichend einfache Möglichkeit, mit dem knxd zu reden, wird es demnächst geben (sämtliche existierenden Methoden sind … eher anstrengend). Bin noch am Nachdenken, wie ich das konkret integrieren mag.

[ITler]

Ich hatte auch mal so eine Idee, sie jedoch nicht bis zuende verfolgt:

Der Plan war 2 Raspberries in verschiedenen Linien zu platzieren.
Dann jeweils ein Script welches Groupsocketlisten lokal parsed, und abhängig von der Gruppenadresse auf dem jeweils anderen Raspberry ein group(s)write mit dem jeweiligen Wert absetzt.

Wenn man es schafft, den knxd 2 mal laufen zu lassen, geht es vielleicht auch mit nur einem Raspberry.
Oder wenn man HIP sein will schafft man es vielleicht mit Docker :-)

Wie gesagt, war nur ein Ansatz der nie umgesetzt wurde, daher nur in der Theroie funktional.

[Smurf]

Zum Beobachten physisch adressierter Pakete musst du ein Interface in den Busmonitormodus schalten, das bekommt dann alles ab was der knxd überhaupt sieht. Rein theoretisch. Praktisch geht das aktuell nicht, aus einem einfachen Grund: knxtool hat keine Möglichkeit, dem knxd zu sagen, *welche* Schnittstelle der Busmonitor sein soll. Früher, als das Ding geschrieben wurde, war das einfach, weil knxd da nur eine konnte …

Für GroupRead/Write gilt das natürlich nicht, die haben ja keine physischen Zieladressen. Gefiltert wird aber auch nach Quelladressen: wenn ein Paket bei A ankommt, obwohl der knxd Daten dieses Geräts auf B gesehen hat, dann wird es weggeschmissen, weil höchstwahrscheinlich Schleife im Bus oder ähnliche Schmutzeffekte. Nein, dieser Cache hat keine Timeouts, das ist auch auf der TODO-Liste …

Ja, ein Filter wäre für Außenlinien etc. sehr sinnvoll. Mach mal. *g*

[SirSydom]

Es gibt keine Linien. Linien sind Wachträume der Leute, die sich KNX ausgedacht haben, aber sie haben keinerlei praktischen Nutzwert.

Naja, du musst beachten wie alt das System ist! EIB (KNX-TP1) ist wie alt? 1990 veröffentlicht. Ursprünglich dienten die Linien zur Reduktion der Buslast und auch zur Segmentierung bzgl. Energieversorgung. Und eine statische Filtertabelle ist halt mit nur wenigen huntert byte ram/flash einfacher umzusetzen also etwas dynamisches.

Früher gabs ja auch bei Ethernet "Hubs" die alle Pakete überall rausgeblasen haben. Der Switch hingegen hat sich gemerkt wo wer sitzt.. Dafür brauchts aber mehr Rechenpower, die ersten Switches waren unerschwinglich.

Aber heute - da gebe ich dir recht - brauchts eine zweite Linie idR nicht.
Aber eine Außenlinie, auf der nur die Telegramme laufen, die es dort unbedingt braucht, und von der aus man z.B. nicht programmieren kann, kann einem etwas gefühlte Sicherheit geben. Die galvanische Trennung ist auch nicht verkehrt, aber die kann man auch ohne LK haben.
Mit einem RasPi / KNXD der man ggf. sowieso als günstigen KNX-Router Ersatz hat, könnte man dieses Außenlinienfeature dann günstig umsetzen.

Warum braucht man das nicht? Weil sich der knxd merkt, welche phys.Adresse er hinter welcher Schnittstelle gesehen hat. Wenn nun jemand ein Datenpaket da hinschickt ("jemand" = "die ETS", weil außer der ETS niemand Pakete physisch adressiert), dann hat er sich gemerkt wo er das Gerät gesehen hat und schickt die Daten nur dort hin.

Das gilt nur für physikalisch addressierte Telegramme? PropertyRead etc... ? Oder auch für GroupWrite / Read
Kann man dieses Verhalten auch abschalten?
Man will ja ggf. auch mal beobachten, da wäre dieses Feature hinderlich.

[Smurf]

Es gibt keine Linien. Linien sind Wachträume der Leute, die sich KNX ausgedacht haben, aber sie haben keinerlei praktischen Nutzwert.

Ja, du kannst sowas wie einen Linienkoppler basteln. Das ist ein KNX-Router, der davon ausgeht, dass alle physischen Adressen X.Y.Z hinter dem Draht sind, den du X.Y nennst, und alle anderen sind woanders. Das könnte man dem knxd auch beibringen, wenn der nach physischen Adressen filtern könnte. Kann er aktuell aber nicht. Braucht man in der Praxis auch nicht.

Warum braucht man das nicht? Weil sich der knxd merkt, welche phys.Adresse er hinter welcher Schnittstelle gesehen hat. Wenn nun jemand ein Datenpaket da hinschickt ("jemand" = "die ETS", weil außer der ETS niemand Pakete physisch adressiert), dann hat er sich gemerkt wo er das Gerät gesehen hat und schickt die Daten nur dort hin.

Ja, du kannst seit 0.12 den knxd mit mehr als einer KNX-Schnittstelle betreiben. Die sind alle sind gleichberechtigt; wenn ein Paket von Schnittstelle A kommt, wird es überall dorthin weitergeschickt, wo es gebraucht werden könnte.

Filter: ja, gerne. Sollte mal jemand implementieren … ist kein Hexenwerk. Nur ein bisschen Arbeit / relativ harmlose C++-Programmierung.

[SirSydom]

Hallo,

ich frage mich grad ob man ein knxd als Linienkoppler einsetzen kann. Nach Studium der Doku erscheint mit das möglich, wollte aber trotzdem nochmal nachfragen.

Idee: RasPi mit 2 KNX-Tp Interfaces (2x uart beim Raspi 4 oder uart + usb2serial)

Einsatz z.B. zum Abkoppeln einer Außenlinie.
Ich hab zwar was von Filtern gelesen, aber das bezieht sich NICHT auf GA / PA Adressen, oder etwa doch?

Wenn man das noch weiter spinnt, wäre sogar 2 tp linien denkbar, wenn man per ipt zur "Hauptlinie" verbindet (wenn es dort ein IP INnerface gibt)

Und Routing geht dann sowieso immer "on top" oder?