knxd mit Gira USB Schnittstelle

[lukluk]

Hallo. Ich brauche einen KNX IP Router und hab folgendes zu Verfügung:
Server mit ESXi mit noch ausreichend Kapazität für VMs
Gira USB KNX Schnittstelle
Wäre es denkbar daraus eine stabile Lösung zu konstruieren?
Die USB Schnittstelle ist momentan am HS direkt. Möchte diesen dann auch über knxd versorgen und für Testzwecke noch Edomi auf einer VM laufen lassen (läuft schon) und diese auch mittels knxd versorgen.

[makki]

Ehrlich oder Marketing?
Marketing: klar geht das.

Technik: du frägst nach "stabil"? die ganzen "alten" cEMI USB-Schnittstellen funktionieren nur mit einem dutzend Workarounds (man kann sicher noch ein dutzend weitere finden) - sehr leidig.
Ack's sind z.B. schlicht wegen Timing auch nicht zuverlässig möglich.
Tue dir einen gefallen, verkaufe sie bei eBay o.ä. und steck ne brauchbare Schnittstelle (TP-UART, IP) ausser du hast Spass daran Probleme zu debuggen, die die Welt nicht braucht
Also ja, es geht, ich würde es aber nicht ausprobieren, weil man Probleme entdeckt, die man garnicht wissen wollte!
Und das liegt übrigens nicht am eibd/knxd sondern daran, das die Dinger einfach trash sind.

Makki

[lukluk]

Hi. Vielen Dank für die Info. Dann werde ich mir einen ip Router zulegen irgendwann und die USB Schnittstelle für den hs allein weiter verwenden

[Smurf]

Und das liegt übrigens nicht am eibd/knxd sondern daran, das die Dinger einfach trash sind.

Konkret: in grauer Vorzeit, als die ETS erfunden wurde bzw. USB aufkam, haben sich die Leute gefragt, wie man eine solche Schnittstelle baut, ohne einen Treiber installieren zu müssen. Damals war das noch um Einiges spaßiger als heute und dem typischen Elektriker nicht wirklich zuzumuten, und generische FTDI-Treiber (für eine serielle Schnittstelle am anderen Ende) gab's auch noch nicht.

Folglich hat man sich gedacht, gut, wir basteln das Ding so, als wäre es ein HCI-Gerät (Human-Computer-Interface), also sowas wie eine Tastatur, für die braucht man auch keinen Treiber … und darauf pfropfen wir mal eben KNX auf, mit Umwegen (EMI1 oder EMI2 oder cEMI) weil's ansonsten zu langweilig wäre.

Ich muss mich nicht wundern, wenn mir mein Messer abbricht, wenn ich es auf Dauer als Schraubendreher-Ersatz verwende. So ähnlich ist das auch mit diesen USB-KNX-Dingern. Sie sind einigermaßen brauchbar, wenn es darum geht, mal eben ein Gerät zu "programmieren", aber für den Dauereinsatz? nicht wirklich. Für den Dauereinsatz will ich einen Router.

Ach ja: Direktzugriff auf USB ist mit VMs so eine Sache. Ich bevorzuge eine Lösung mit einem USB-via-TCP/IP-Treiber, wenn man sowas braucht.

[lukluk]

Ok Gut zu wissen! Das wusste ich so gar nicht. Werde dann eher auf lange Sicht Ausschau nach einem IP Router halten. Momentan läuft noch nebenbei Eibd auf einem Raspi 1 mit ROT.
Auch nicht die optimale Lösung. Hatte ich damals gekauft um auch 1-Wire auf den Bus zu bringen. Hat aber nie funktioniert....

[makki]

Das hat Matthias jetzt sehr schön um/beschrieben Ich bleibe bei "trash", das hat und hatte nie eine Zukunft, ich war schon vor Jahren dafür, den Support für USB, PEI16(bcu1) und ft12 komplett rauszunehmen, weil eine Schnittstelle, die "manchmal - öfters - hoffentlich - vielleicht - ein bisschen funktioniert" bringt doch keinem was.
Das hat was von Masochismus, wenn man auf Dinge aufsetzt von denen bekannt ist, das sie eigentlich so nicht funktionieren können (HID..)
Und USB aus VM's: das kann auch nur schieflaufen, essentielle Dinge wie ACKs werden damit Timing-mässig nichts werden.. Der nächste Post ist dann "Warum habe ich Telegrammwiederholungen auf dem Bus"

@lukluk: knxd mit ROT sollte aber eigentlich fein tun (besser als so manch zertifizierter IP/R mit Logo..)
Der dort verbaute 1w Master DS2482 ist jedoch - s.o. - auch trash, der kann keine 2meter, weil er schlicht nicht dafür gemacht ist. Dito: "das kann man zwar so machen, ist aber dann halt ka***"

genug gelästert für heute

Makki

[Klaus Gütter]

Also so schlimm wie das hier dargestellt wird, ist USB wirklich nicht. Über die alten USB/EMI1-Aufsätze brauchen wir nicht reden, das ist klar. Aber KNX-USB-cEMi ist ein sauber und angemessen definiertes Protokoll und die meisten Implementierungen laufen absolut stabil (konkret über die GIRA-Schnittstelle kann ich allerdings nichts sagen).

ACK-Timing ist gar kein Problem, weil das (LinkLayer-)ACK von der Schnittstelle selbst generiert wird (das ist bei IP auch nicht anders).

Wir haben im ETS-Support für USB-Schnittstellen wesentlich weniger Support-Cases als für IP.

Gruß, Klaus

[Smurf]

makki PEI16 ist bereits draußen, das hat nie richtig funktioniert.

cEMI kann man im Vergleich zu EMI1 akzeptieren, da gebe ich Klaus Gütter recht. Ist aber trotzdem nicht wirklich spaßig. Es hat einen Grund, dass der knxd früher alle drei Sekunden den USB-Empfang abgebrochen und neu aufgesetzt hat (das habe ich inzwischen entfernt). Typischerweise läuft die ETS aber auch nicht lang genug, um Probleme im Schaltschrank zu finden. USB zurücksetzen läuft gerade nach sporadischen Störungen zu oft auf Ausstecken-Einstecken-Geht-wieder hinaus.

Als nächsten Rant fangen wir mal mit IP-Tunnel-Schnittstellen an, die Pakete bestätigen, obwohl sie keinen Platz in ihrem Pufferspeicher dafür haben … und/oder die alle dreieinhalb Wochen durcheinanderkommen, weil ein interner 32-bit-msec-Timer überläuft und negativ wird …

[Klaus Gütter]

Typischerweise läuft die ETS aber auch nicht lang genug, um Probleme im Schaltschrank zu finden.

In unseren Elvis-Dauertests haben wir USB-Kommunikation mit ziemlich hoher Last über einige Tage ohne einen einzigen Fehler laufen.

Und ja, einzelne USB- wie IP-Implementierungen haben jeweils ihre - ähem - Eigenheiten. Kann man aber nicht aufs Protokoll schieben.

[makki]

Klaus Gütter das ist ja herzlich egal auf wen genau man da jetzt die ein andere Unzulänglichkeit schiebt, ob das jetzt die ETS, "der Standard", knxd (ja, auch der hatte einige Fehler in der Entwicklungs-Evolution, möchte ich garnicht wegwischen)
- Oder eben die Schnittstelle ist:
Das ist für den Anwender der Probleme hat IMHO relativ sekundär.

Was mich daran (immernoch) ärgert ist:
a) es wurden jahrelang zig Workarounds in ETS, HS (und zwangsläufig eibd/knxd) eingebaut, statt von den ganz einfach nicht Standardkonformen, also defekten Schnittstellen das Logo runterzukratzen und auszutauschen
b) das mit den LL-ACKs wird immernoch heruntergespielt: die USB-SS können es ja nicht - für genug GA's (warens >32?) in komplexen Geräten zumindest - also muss es der Host machen. Was er aufgrund des Timings, USB, ..... ja kaum kann/schafft.
Hinzu kommt das ziemlich viele Schnittstellen eines namhaften Herstellers ja mal auch noch das "klitzekleine" Problem (kompletter defekt Wochen/Monaten) mit der bcuaddrtab hatten - wir erinnern uns mit schmerzen..

Auch noch gut erinnern kann ich mich an den Rant, der mir 2010 in Pamplona entgegenschlug, als ich mir erlaubt habe auf gewisse Design-Schächen in KNXnet/IP hinzuweisen - wie z.B. das von Matthias angesprochene ACKen von Telegrammen, die garnichtnicht weitergeleitet wurden oder keinen Platz im Puffer haben Zuwas gibts dann nen ACK...

Jedenfalls waren USB-Schnittstellen (EMI und cEMI) in meinen automatisierten Testaufbauten seinerzeit oberhalb 15-25 tps nie "Vollgasfest"

Makki