freebus.org
http://freebus.org/phpBB3/

FTS: Entwicklung eingeschlafen?
http://freebus.org/phpBB3/viewtopic.php?f=8&t=2021		 Seite 2 von 2
Autor:  StefanT [ 5. Januar 2013 22:03 ]
Betreff des Beitrags:  Re: FTS: Entwicklung eingeschlafen?
tuxedo hat geschrieben:
...Scheint so als ob FTS den Service-Type "Routing" nicht kennt. Bin offenbar der erste der einen Hardware KNX IP Router einsetzt und damit auf den EIBD verzichtet :-)
...
Werde nach möglichkeit heute versuchen FTS für's Routing aufzubohren. Zumindest was den Busmonitor betrifft. Mal sehen ob ich auf das gleiche Problem stoße.


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

Das steht im KNX Standard zum Thema Routing:

Zitat:
KNXnet/IP Routing is defined as a set of KNXnet/IP Routers communicating over a one-to-many
communication relationship (multicast), in which KNX data shall be transferred from one device to one
or more other devices simultaneously over an IP network. A set of KNXnet/IP Routers can replace KNX
Line- and Backbone Couplers and connected Main Lines respectively Backbone Lines, allowing usage of
existing cabling (e.g. Ethernet) and faster transmission times (and simultaneousness) between KNX
subnets. The IP network acts as a fast backbone that connects KNX subnets and is a high-speed
replacement for the KNX backbone.
Autor:  StefanT [ 5. Januar 2013 22:18 ]
Betreff des Beitrags:  Re: FTS: Entwicklung eingeschlafen?
tuxedo hat geschrieben:
Hmm, bei mir meldet FTS immer dass das was da kommt nicht unterstützt/erkannt wird. die exakte Fehlermeldung hab ich grad nicht da...Kann ich aber nachliefern.


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.

Zitat:
Das XML Format ist weitgehend dokumentiert. Allerdings gibt's da Blöcke mit Rohdaten (als Hex-String oder Base64 ... weiß nicht genau) die wohl die Applikationssoftware für die KNX Komponenten darstellen. Dieser Punkt ist leider nicht mehr dokumentiert.

Meine Hoffnung: FTS kann prinzipiell KNX Komponenten programmieren. D.h. jemand hat sich schon mit dem Senden solcher Rohdatenblöcke beschäftigt. Dann wäre es wohl nicht allzuschwer die Rohdaten statt aus dem alten ETS3 Format nun aus dem neuen ETS4-XML-Format auszulesen.


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.

Zitat:
Es gibt ja eine freie KNX Net/IP Library: Calimero ... Aber ob man damit tatsächlich KNX Geräte programmieren kann... Kein Plan. Wenn ja wäre das toll. Denn es gibt eine Konvertierungsmöglichkeit von ETS4-XML-Format in das Calimero-XML-Format...


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.

Zitat:
Bin aktuell noch dran das Protokoll genauer zu verstehen... Von den 17 Bytes die mein KNX-Tastendruck sendet, hab ich 12 entschlüsselt/identifiziert. Wenn ich fertig bin fasse ich das mal in eine Doku zusammen. Hab im netz nur vielerlei Einzelinfos gefunden. Aber nichts das das gesamte UDP-Paket komplett beschreibt...


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 :)

Zitat:
Bzgl. der geforderten Produktdatenbank:
hat mich auch ein wenig Zeit gekostet das heraus zu finden: ETS3 benutzen, die Produktdatenbank dort laden. Während des Ladevorgangs findet man die "entpackte und entsperrte" Produktdatenbank (ist ja ein passwortgeschütztes ZIP) als .vd_ irgendwo im ETS3 Verzeichnisast.


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.
Autor:  StefanT [ 5. Januar 2013 22:22 ]
Betreff des Beitrags:  Re: FTS: Entwicklung eingeschlafen?
tuxedo hat geschrieben:
Habs auf Anhieb nicht geschafft FTS dazu zu bewegen mal auf dem Bus zu lauschen.
Hab noch nicht genauer in den Source geschaut, aber könnte es sein dass FTS von einem IP-Interface, und demnach von TCP ausgeht?


Implementiert ist bisher nur die UDP Verbindung. Und getestet habe ich es mangels passender Hardware nur mit dem eibd.
Autor:  tuxedo [ 6. Januar 2013 18:11 ]
Betreff des Beitrags:  Re: FTS: Entwicklung eingeschlafen?
StefanT hat geschrieben:
Routing ist nicht was Du denkst. Die FTS braucht kein Routing.


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.

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


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


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

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

Code:
16:56:50.848 [Thread-15] DEBUG o.f.knxcomm.link.netip.KNXnetLink - IP-RECV: 06 10 02 06 00 08 00 23
java.lang.IllegalArgumentException: Invalid KNXnet/IP protocol type: 168
   at org.freebus.knxcomm.link.netip.types.ProtocolType.valueOf(ProtocolType.java:48)
   at org.freebus.knxcomm.link.netip.blocks.EndPoint.readData(EndPoint.java:117)
   at org.freebus.knxcomm.link.netip.frames.ConnectResponse.readData(ConnectResponse.java:150)
   at org.freebus.knxcomm.link.netip.frames.FrameFactory.createFrame(FrameFactory.java:46)
   at org.freebus.knxcomm.link.netip.frames.FrameFactory.createFrame(FrameFactory.java:65)
   at org.freebus.knxcomm.link.netip.KNXnetLink.processData(KNXnetLink.java:380)
   at org.freebus.knxcomm.link.netip.KNXnetLink$1.run(KNXnetLink.java:431)
   at java.lang.Thread.run(Thread.java:636)


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 ...

Zitat:
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.


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?

Zitat:
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.


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 ...

Zitat:
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.


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/
Autor:  StefanT [ 6. Januar 2013 18:33 ]
Betreff des Beitrags:  Re: FTS: Entwicklung eingeschlafen?
tuxedo hat geschrieben:
...
Deswegen wäre es mir ein anliegen FTS beizubringen, auch mit Paketen umzugehen, welche den Service-Typ "Routing" haben.


Hmm, ok, mach mal.

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

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

Code:
16:56:50.848 [Thread-15] DEBUG o.f.knxcomm.link.netip.KNXnetLink - IP-RECV: 06 10 02 06 00 08 00 23
java.lang.IllegalArgumentException: Invalid KNXnet/IP protocol type: 168
   at org.freebus.knxcomm.link.netip.types.ProtocolType.valueOf(ProtocolType.java:48)
   at org.freebus.knxcomm.link.netip.blocks.EndPoint.readData(EndPoint.java:117)
   at org.freebus.knxcomm.link.netip.frames.ConnectResponse.readData(ConnectResponse.java:150)
   at org.freebus.knxcomm.link.netip.frames.FrameFactory.createFrame(FrameFactory.java:46)
   at org.freebus.knxcomm.link.netip.frames.FrameFactory.createFrame(FrameFactory.java:65)
   at org.freebus.knxcomm.link.netip.KNXnetLink.processData(KNXnetLink.java:380)
   at org.freebus.knxcomm.link.netip.KNXnetLink$1.run(KNXnetLink.java:431)
   at java.lang.Thread.run(Thread.java:636)


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.

Zitat:
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?


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.

Zitat:
Zitat:
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.


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?


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.

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


Danke. Ich auch :)
Seite 2 von 2 Alle Zeiten sind UTC + 2 Stunden
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/