freebus.org

Routing ist nicht was Du denkst. Die FTS braucht kein Routing.

Das steht im KNX Standard zum Thema Routing:

Es werden die ACK Bytes am Bus als Fehler gemeldet (ein einzelnes 0xcc). Die Freebus FT1.2 Software unterdrückt diese ACKs, alle anderen senden sie. Im Standard steht das nicht so klar dass diese ACKs überhaupt gemeldet werden. In irgend einer Version auf meiner Platte habe ich das schon behoben. Kann aber sein dass es diese Version bisher nicht ins GIT geschafft hat.

Auf jeden Fall könnt ihr diese Meldungen getrost ignorieren, sie schränken die Funktionalität nicht ein.



Es ist leider sehr komplex wie man von einer VD Datei zu der zu programmierenden Bytefolge kommt. Wir können das gerne noch im Detail besprechen.

Ein erster Schritt ist es die Gruppenadressen richtig zu schreiben, das ist klar dokumentiert und nicht sehr schwierig.



Also vor zwei Jahren sagte mal wer von den damaligen Freebus Leuten zu mir: Du kannst schon Calimero verwenden, vielleicht funktioniert es ja. Du musst halt leidensfähig sein.



Leider ist das Verstehen dieses Protokolls für das was bei der FTS fehlt nur wenig interessant. Aber Hilfreich ist es sicher, also mach ruhig weiter



Stimmt. Sonst mich mal im IRC auf das Thema anreden, dann kann ich euch eine kürzere Methode sagen.

Das weitere Ziel ist natürlich auch die ETS4 Dateien zu lesen. Aber mMn ist primär wichtig dass FTS mit dem bestehenden Funktionsumfang Geräte parametrieren kann. Das Verarbeiten von ETS4 Dateien ist für mich klar danach angesiedelt.

Implementiert ist bisher nur die UDP Verbindung. Und getestet habe ich es mangels passender Hardware nur mit dem eibd.

Routing ist exakt das was ich denke. Und mir ist bewusst dass man die Routing-Funktionalität für FTS nicht unbedingt braucht. Dennoch habe ich mir einen Router gekauft. Gründe:

* Ein normales IP Interface kann im Normalfall nur einen "IP-Client" bedienen.
* Um das zu umgehen, bräuchte man EIBD als Proxy. Ich möchte jedoch keine weitere Software-Abhängigkeit haben wenn sich das per Hardware sauber erledigen lässt.
* Ich möchte am Ende aber mehrere "IP KNX Teilnehmer" einsetzen, weswegen ich in diesem Fall auf einen IP Router setze, auch wenn ich nicht von einer KNX Linie auf's IP-netz und wieder zurück auf eine zweite KNX Linie "route".

Deswegen wäre es mir ein anliegen FTS beizubringen, auch mit Paketen umzugehen, welche den Service-Typ "Routing" haben. Sonst müsste ich entweder doch EIBD einsetzen, oder jedesmal wenn ich FTS benutzen möchte, den Router vorher umkonfigurieren und später wieder zurück konfigurieren...Und das möchte ich nicht.



Gut dass wir jetzt jemanden mit IP Router haben *mit dem zaunpfahl wink*. Dann kann man FTS dementsprechend erweitern...



Das von dir beschriebene scheint etwas anderes zu sein. Wenn ich den Bus-Monitor einschalte, dann seh ich nix außer das hier:



Schränkt mich schon etwas ein Der Servicetype 0206h --> "Service type identifier for a connect response." --> Scheint im Routing-Modus nicht zu funktionieren Sagte ich ja bereits mehrfach ...



Gerne. Aber vielleicht eins kurz vorab zum Verständnis: Kann FTS in der aktuellen Fassung denn schon irgendwas parametrisieren außer der Bus-Adresse? Sprich: Wertet FTS schon (ansatzweise) die VD File aus und macht daraus eine Byte-Folge zum programmieren?



Mag sein. Aber dort scheint schon jede Menge implementiert zu sein. Der Source-Code liest sich recht gut. Sauber und strukturiert. Vielleicht kann man sich da das eine oder andere abschauen ...



Hab da ein kleines gegenargument, welches du ggf. noch entkräften könntest:

Bieten denn _alle_ Hersteller noch das alte Dateiformat an? Hab bei vielen Herstellern auf Anhieb nur noch .knxprod Files gefunden... Was mach ich also mit Komponenten die nur mit .knxprod daherkommen?

Gruß
Alex

P.S. Hab nen Jenkins-Build-Server laufen, welcher ebenfalls FTS automatisch baut: http://jenkins.root1.de/job/Freebus%20FTS/

Hmm, ok, mach mal.



Ich bilde mir ein das kam bei mir auch in dem Fall wenn die ETS die Verbindung belegt hat. Es könnte bei der neuen Version (seit gestern) korrigiert sein. Dann sollte eine Fehlermeldung stattdessen kommen. Nämlich das er nicht verbinden kann weil das Gerät belegt ist.



Die Gruppenadressen und die Zuordnung zu den Com-Objekten ist sehr weit aber noch nicht getestet, das sollte passen.

Die Parameter in Bytefolgen umwandeln ist schon implementiert aber hat sicher noch Fehler, und ist noch ungetestet.



Es war viel Aufwand den Import von Produktdatenbanken so schnell hinzubekommen wie es jetzt ist. Das XML Format benötigt einiges Hirnschmalz damit es auch wieder so schnell funktioniert.

Wenn da was gemacht wird dann hätte ich andere Pläne: alle Produkt-Files in ein Cache Verzeichnis übernehmen und Indexdaten irgendwo abspeichern. Das hätte einige Vorteile.

Aber so lange FTS nicht hinten raus fertig ist macht es keinen Sinn den funktionierenden Import der Produktdaten umzureißen.



Danke. Ich auch