eibga.conf, Import-Tool (suche)

[emax]

Noch was: Die 'Namen' der GAs, also z.B. "Küche, Licht ein", die hab ich so allerdings auch nicht raus ziehen können.

Für diese Resultat musste ich schon zwei verschiedene Exports machen, weil die ETS3 zu blöde ist, das in einer Datei zu liefern, jedenfalls hab ich keine solche Möglichkeit gefunden. Wenn ich die GA-"Namen" haben möchte, müsste ich noch einen dritten Export machen.

Bevor nun ein Schlaumeier auf den Export für das gedruckte Projekt verweist: Ich rede von XML Exports. Die gedruckte Version, z.B. als EXCEL-Sheet, ist eine Zumutung, um nicht zu sagen, eine Straftat.


NACHTRAG: Ich habe eben noch mal geschaut. Es wäre nicht ein dritter Export, sondern für jede MIttelgruppe jeder Hauptgruppe ein extra Export ...

[makki]

...
Vielleicht meinte makki das, wobei es kein Export-Problem im eigentlichen Sinne wäre.

Genau das meine ich und ich sage JA: das ist ein Export-Problem, kein Layer8-Fehler!
Es ist im Prinzip nämlich grösstenteils völlig überflüssig den DPT manuell zu definieren weil ETS3-5 in der DB auch ohne manuelles geklicke hinterher aus der PDB und/oder eben den Daten in der DB/XML eigentlich sehr genau(!) weiss/wissen sollte (siehe interner Busmonitor OHNE Angabe des DPT!?!) ob es sich bei der GA 1/2/3 nun um einen 1Bit-Schaltstatus, einen 8bit-Percent, 16Bit IEEE 754 oder einen 32bit Counter handelt. Weil das steht nämlich in der PDB des Produkts + Config in der ETS doch eh schon drin.
Woher sollte das Gerät sonst wohl wissen, welchen DPT es verschicken oder lesen soll..Zefix, sorry..

Genau an diese Sachen komme ich aber selbst beim .knxproj nicht voll-umfänglich ran (zumindest nicht schmerzfrei ohne sehr detaillierte Kenntnis des XML-Formats, PDB, .. und der internas).
Nochmal: die manuelle Definition des DPT's für KO's ist (von sehr wenigen oder sehr alten Geräten mal abgesehen) eine völlig überflüssige ABM! Das war 2007 mit der ETS3 so und das ist auch 2016 mit der ETS5 so.

Um das zu bekommen muss ich nach wie vor a bisserl hacken!
Ja warum hat denn wohl Gira ein ETS-Plugin (geht garnicht!) extra für den ETS-Export gemacht?
a) weil ihnen grad langweilig war oder b) weil das Export-Fomat der ETS (inkl. .knxproj) halt einfach kacke ist? Hmm..

Also lustige DB und ZIP-Passwörter benutzen, ja wenn die Konnex das nicht will: dann macht einen Menüpunkt "Datei-> CSV-Export" der mir einfach ein CSV mit GA, Name, möglicher DPT auf die Platte schreibt. Fertig.

Ich rege mich darüber jetzt gerne seit >8J als Anwender, Hersteller und beratender Systemintegrator auf und werde auch ins 9. Jahr damit gehen!

Das ist EPIC FAIL!

Beim WireGate/Timberwolf bin ich wie ihr ja wisst raus und da halte ich mich auch raus, aber das hat damit eigentlich auch nur peripher zu tun: denn das Problem ist für alle immanent dasselbe, die den Krempel importieren wollen oder müssen: die ETS hat bis heute einfach keinen vernünftigen, brauchbaren Export der GA's/KO mit DPT (nochmal: ohne diese vorher unnötigerweise hundert oder tausendfach manuell zu beklicken!)
Beim WG hat man sich (ich) halt "Lösungen" ausgedacht, das irgendwie zusammenzufummeln (inkl. Lesen der PDB, das hochgeheime PW will die Konnex aber hier bestimmt auch ned lesen [präventiv: siehe Footer, ich antworte nicht auf PNs]) das wird übernommen worden sein, ändert aber nichts an der völlig unnötigen Inkompetenz der ETS: bekannte, vorhandene, meine Daten sauber zu exportieren.
Und, liebe Konnex: wenn ihr schon dabei seit: bitte fixed das mit dem ETS-Import aus CSV, XML, whatever (Format frei wählbar) (GA, Name, HG/MG/GA, +DPT) bitte auch gleich
Das funktioniert nämlich auch bis heute ned.

@emax: pack das bitte irgendwo auf Github (Openautomation oder meiner unter knxd oder eigener Account) sonst gehts verloren...


beste, entspannte Grüsse von jemandem der wegen dieser Unfähigkeit der ETS seit Jahren hunderte GA's teils manuell zwischen ETS, WG, CV, linknx, mh, edomi, EibPC, HS uvm. synced und schon sicher ein paar dutzend Scripts nur für diesen Mist geschrieben hat..

Makki

[Gast]

Hi Makki,

seit über 20 Jahre muß ich mir auch immer wieder mal Dateiformat-Konverter bauen. Eine Erfahrung: Schimpfen nutzt gar nix.

Ja, die ETS sollte den DPT herausfinden und eintragen können, wenn man ein Geräte-KO mit definiertem DPT verknüpft. Das KO des ersten verknüpften Gerätes legt das fest, und meistens funktioniert das auch, aber in einigen Fällen bleibt es undefiniert. Bei mir scheint es immer dann schief zu gehen, wenn ich als erstes Gerät ein Visu-KO verknüpfe.

Die ETS sucht nicht nachträglich in den KO-Definitionen der verknüpften Gerät rum, was es sein könnte/müsste. Das war deine Idee, die ich auch verstehe, aber die ETS macht das nicht und deshalb fehlt der ETS an mancher Stelle der DPT. Und weil es schon in den Eigenschaften nicht drinsteht halte ich es eben für ein ETS-Problem, aber nicht für ein spezifisches Export-Problem.

Thema Busmonitor: da wird der Datentyp genau so eingestellt/angezeigt, wie man ihn in den Eigenschaften sieht. Bei undefiniert bleibt's im GUI ein generisches Telegramm, der tatsächliche DPT steht im Header des Telegramms.

Woher sollte das Gerät sonst wohl wissen, welchen DPT es verschicken oder lesen soll..

Das ist doch idR im Gerät hardcodiert, ohne daß man es von der ETS ändern könnte.

Ja warum hat denn wohl Gira ein ETS-Plugin (geht garnicht!) extra für den ETS-Export gemacht?
a) weil ihnen grad langweilig war oder b) weil das Export-Fomat der ETS (inkl. .knxproj) halt einfach kacke ist? Hmm..

Ich weiß nicht, was für Plugins Gira mal gebaut hat, aber der aktuelle Gira Projektassistent liest die *.knxproj direkt und das Ergebnis ist brauchbar.

Cheers,
Volker

PS: Da das aktuelle Problem nur noch in den undefinierten DPT besteht, wäre das eine schöne Aufgabe für eine ETS-App, das zu vervollständigen anhand der verknüpften Geräte-KOs. Dann klappt's mit dem Export und andere Stellen in der ETS (z.B. Gruppenmonitor) profitieren auch.

[heckmannju]

seit über 20 Jahre muß ich mir auch immer wieder mal Dateiformat-Konverter bauen. Eine Erfahrung: Schimpfen nutzt gar nix.

Kommt immer daraf an wer schimpft....

[Gast]

Kommt immer daraf an wer schimpft....

Das vielleicht auch (bei mir sind die Kunden Philips, Intel usw.) aber vor allem muß sauber argumentiert werden.

[makki]

...
Und weil es schon in den Eigenschaften nicht drinsteht halte ich es eben für ein ETS-Problem, aber nicht für ein spezifisches Export-Problem.
...

Ehrlich: das ist mir total wurscht, ob man das jetzt als "ETS-Problem" oder als "ETS-Export-Problem" klassifiziert wird!
Fakt bleibt: die ETS ist unfähig bekannte, *meine Daten* vernünftig zu exportieren (ohne die DB "a bisserl" zu hacken) = kaputt.

Das ist doch idR im Gerät hardcodiert, ohne daß man es von der ETS ändern könnte.

Eben.

Ich weiß nicht, was für Plugins Gira mal gebaut hat, aber der aktuelle Gira Projektassistent liest die *.knxproj direkt und das Ergebnis ist brauchbar.

Wenn man vorher manuell den DPT nochmal definiert hat, was völlig überflüssig ist, weil z.B. sowohl das Gerät als auch die ETS aus der PDB eigentlich 100% "weiss" das es sich z.B. bei diesem KO eines Tempfühlers oder RTR xy wohl ziemlich sicher um einen DPT9.001 handeln wird
(und selbst bei komplexerem wie einem Universal-Analogeingang wirds im Prinzip schon in der ETS-Applikation bestimmt, was da rauskommt, also warum muss ich das nach dem Export nochmal sep. definieren??)

PS: Da das aktuelle Problem nur noch in den undefinierten DPT besteht, wäre das eine schöne Aufgabe für eine ETS-App, das zu vervollständigen anhand der verknüpften Geräte-KOs. Dann klappt's mit dem Export und andere Stellen in der ETS (z.B. Gruppenmonitor) profitieren auch.

Das macht ja mein ETS-Export-Tool mit Cheats und Tricks..

Aber genau das sehe ich eben anders: dafür darf es keine APP oder so einen Sch**** für eine ohnehin teure Software brauchen, sondern ein sauber spezifiziertes, stabiles Datenformat, das sich bitte nicht bei jedem zweiten Update grundlegend ändert.
Das (Export) sind Basics, keine "Features" die der Anwender dann per kostenpflichtiger APP nachkaufen muss.
Darum gehts..

[Gast]

Ehrlich: das ist mir total wurscht, ob man das jetzt als "ETS-Problem" oder als "ETS-Export-Problem" klassifiziert wird!

Ich hoffe, daß die Softwareentwicklung nur dein Hobby ist und du damit kein Geld verdienen musst. Du stehst dir mit deiner oberflächen Analyse, falschen Annahmen und Vorurteilen (XML) selbst im Weg, und schuld sind dann natürlich die anderen.

[makki]

Dem ist in der Tat so, Hauptberuflich bin ich damit befasst Lösungen für Probleme zu finden und nicht die Schuldfrage mit Erbsenzählern zu erörtern :-)
Jetzt wirds dann aber lustig (oberflächlich, XML) und wir schweifen drastisch vom Thema (war ETS3-Export), daher hab ich da auf eine Antwort am Samstag in der stillen Zeit echt keine Lust.

Das ganze hat eine seeehr laaaange Vorgeschichte die man hier zwar irgendwo nachlesen kann, was aber kaum einer machen wird.

Makki

[emax]

> Ich hoffe, daß die Softwareentwicklung nur dein Hobby ist und du damit kein Geld verdienen musst.

Da spricht, was Deine Einschätzung von Makki anbelangt, der Nicht-Wissende. Das überaus hervorragende Wiregate-Konzept mitsamt der darauf laufenden KNX/Onewire Infrastruktur ist Makkis Werk. Ebenso das bereitgestellte Repository und die Webmin Integration. Ich bin selber Entwickler, und weiß ebenso wie Makki, dass man immer alles etwas besser machen könnte. Meistens weiß man das aber erst hinterher. Und im Falle Wirgate war die erreichte Lösung bereits auf Anhieb von hoher Qualität.

Ein "Hobbyist" kann so eine Lösung nicht bieten, weil zwischen "funktioniert" und "stabil, verkäuflich, wartbar, und supportfähig" ein sehr weiter Weg liegt. Deshalb würde ich mal sagen: Voll daneben.


> Du stehst dir mit deiner oberflächen Analyse, falschen Annahmen und Vorurteilen (XML) selbst im Weg

Und das finde ich nun geradezu kühn. Denn wenn man weiß (was bei Dir u.U. nicht der Fall ist), wie Makki zu dieser Erkenntnis gekommen ist, würde man solchen Unfug nicht in ein Forum schreiben. Vielleicht warst Du da aber auch einfach nur etwas, nunja, oberflächlich.

Sei's drum.

Die "Vorurteile" zu XML teile ich übrigens auch. Ich kenne die Vorteile, und nutze sie (unter Zwang) auch immer wieder mal. Aber die Flüche die ich dabei zuweilen ausstoße darf niemand hören. Im eingeengten Windows-Horizont mag so eine Datenhaltung zuweilen "alternativlos" erscheinen. Im Linux-Umfeld gibt es aber ausgesprochen leistungsfähige Alternativen, die durch den Einsatz von XML jedoch leider ausgehebelt werden. Als da z.B. wären grep, awk, sed & friends. Von der Lesbarkeit mal ganz zu schweigen.

Da diese Tools unter Windows nicht zum Standard-Repertoire gehören, scheinen XML, json und andere komplexe Textformate dort häufig das Format der Wahl zu sein. Auf diesem Weg kontaminieren sie so leider auch häufig das Linux-Umfeld. Diese Sicht, oder besser gesagt Erfahrung, teile ich mit ungezählten anderen Entwicklern, und eben auch mit Makki. Das sind keine Vorurteile, sondern Erfahrungen.

Bei der Comet-Visu z.B. hat die Verwendung von XML aufgrund der vorliegenden Komplexität sehr handfeste Gründe, die ich gut akzeptieren kann. Aber warum nun ein paar hundert lausige Textzeilen unbedingt in hippem XML gespeichert werden müssen, das konnte mir bis heute noch niemand erklären. Da kostet die zu ladende XML-Library mehr Resourcen als jeder Bulk-Read mit nachfolgender Regexp-Verarbeitung.

Wenn auch ein ETS-Export mehr als ein paar hundert Zeilen umfasst, so wäre auch dort ein transparenteres Resultat zu begrüßen. Das eine DB normalisiert ist, hat oft gute Gründe. Ein simpler Export muss aber nicht unbedingt der reinen Lehre entsprechen. Und weil die XML-Export-Dateien der ETS das sowieso nicht tun, weil eben einfach eine Reihe von Informationen fehlen, hätte man das auch gleich ganz lassen können. Die zeilenweise Ausgabe relevanter Informationen wäre eine gute Alternative gewesen, von mir aus auch gerne mit Satztyp-Kennzeichnern: Da hätte jeder per primitivstem grep-Befehl z.B. auf Anhieb alle DPT pro Objekt rausholen können. Oder die PA jedes einzelnen Gerätes. Oder die davon verwendeten GAs. Oder oder oder ...

Weiter will ich hier aber nicht einsteigen.

[Gast]

Vielleicht warst Du da aber auch einfach nur etwas, nunja, oberflächlich.

Aha. Ich würde behaupten, daß ich mir im Gegensatz zu makki für die aktuelle ETS angeschaut habe, wann und warum die DPT-Zuordnung fehlt (was der seltene Ausnahmefall ist), und wann/warum es beim Export funktioniert oder auch nicht.

Als da z.B. wären grep, awk, sed & friends.

Oh Gott, dann werden Änderungen im Dateiformat bei Funktionserweiterungen tatsächlich zum Problem. Genau um das zu vermeiden nimmt man doch XML.

[emax]

> Oh Gott, dann werden Änderungen im Dateiformat bei Funktionserweiterungen tatsächlich zum Problem. Genau um das zu vermeiden nimmt man doch XML.

Wieso das denn ??

Les doch mal weiter: Da steht was von Satztypen. Funktionserweiterungen können problemlos in neue Satztypen gefasst werden. Und da außerdem die ETS genau das Qualitätsmerkmal der portablen Weiterentwicklung nicht garantiert, greift das Argument m.E. sowieso nicht: Die Konnex beweist seit langem nachhaltig das Gegenteil.