KNX Kommandline options?

[thewhobox]

Ich weiß nicht woher dein Groll her kommt...
Du hattest ein Problem, welches mit deinem Weg nicht lösbar ist.
Wir zeigen dir mehrere Wege auf, wie du das lösen kannst. Dass es eine kostenlose Möglichkeit sein muss, hast du nie definiert.

Ich weiß nicht wie es für die anderen ist, aber für mich werde ich nicht mehr in einen Thread von dir Antworten.

Viel Erfolg noch.

Gruß Mike

[derneugierige]

Ich weiß nicht woher dein Groll her kommt...

Sorry, wenn das als "Groll" rübergekommen sein sollte. War eher als Sarkasmus gedacht. Und schon gar nicht gegen die Benutzer hier sondern gegen die KNXA gerichtet. Schliesslich sind die Benutzer ebenfalls Leidtragende dieses zweifelhaften Vorgehens der KNXA (auch wenn den allermeisten das Problem noch nicht einmal bewusst ist).

Du hattest ein Problem, welches mit deinem Weg nicht lösbar ist.

Zunächst einmal hatte ich kein Problem, sondern will vorbeugen, dass ich igendwann ein Problem bekommen könnte.

Dieses Problem wurde von der KNXA vorsätzlich geschaffen. Es gibt weder technisch noch rechtlich irgendeine Notwendigkeit, dass die ETS die Arbeit an einem von wo auch immer kopierten Verzeichnisbaum verweigert.

Wir zeigen dir mehrere Wege auf, wie du das lösen kannst.

Mehrere Wege? Ich sehe nur einen: den kostenpflichtige Autoexport.
Oh, und dann gibt es ja noch den anderen von mir selbst erwähnten Weg, das Schutzgeld an die KNXA zu bezahlen.

Dass es eine kostenlose Möglichkeit sein muss, hast du nie definiert.

Nun, ich habe hier ein Backup-System, das alle meine Netzwerke (ja, es sind mehrere) gesamthaft vollautomatisch sichert und off-site verfrachtet. Nur macht KNXA diese Backups leider nutzlos, sofern kein aktueller Export existiert.

Wo soll es enden, wenn ich darüber hinaus noch für jedes dahergelaufene Programm eine kostenpflichtige Spezial-Lösung installieren muss, damit die Daten im Falle eines Desasters auch wieder eingespielt werden können?

Ich weiß nicht wie es für die anderen ist, aber für mich werde ich nicht mehr in einen Thread von dir Antworten.

Ist Deine freie Entscheidung. Bleibt Dir unbenommen. Ebenfalls bleibt Dir unbenommen, das Schutzgeld an die KNXA zu bezahlen.

Die Projektdaten sind nicht Eigentum der KNXA sondern Eigentum der Benutzer. Vergleichbar mit zB einer Excel-Datei, an der Microsoft auch keinerlei Rechte hat sondern dem gehört der die Berechnungen in dieser Datei erstellt hat.

Die KNXA schränkt in erheblichem Masse das Recht des Benutzers ein, über die eigenen Daten frei zu verfügen.

Die Backup-Geschichte ist nur ein Beispiel für diese Einschränkungen.

Weiterhin schränkt die KNXA zB das Recht ein, die eigenen Daten zu manipulieren. zB mit selbst erstellten Scripten.

Auch ist das Recht eingeschränkt, die Daten mit einer Versionsverwaltung zu verarbeiten. Und nein, das was als ETS-Versionsverwaltung angeboten wird ist bestenfalls eine Lachnummer.

[Klaus Gütter]

Es gibt weder technisch noch rechtlich irgendeine Notwendigkeit

Leider doch. Es gibt Plugins, bei denen bei einem einfachen Kopieren des Projektspeichers die Daten unvollständig oder gar kaputt sind. Nur durch einen Projektexport ist sichergestellt, dass alle Daten mitgenommen werden.

[Cepheus73]

Die KNXA schränkt in erheblichem Masse das Recht des Benutzers ein, über die eigenen Daten frei zu verfügen.

Nö. Du kannst ja auf die Daten beliebig zugreifen, sie transfomieren und was auch immer. Es kann dann halt nur sein, dass die ETS mit diesen manipulierten Daten nicht zurecht kommt. Dadrauf hast du auch keinen Anspruch.

Weiterhin schränkt die KNXA zB das Recht ein, die eigenen Daten zu manipulieren. zB mit selbst erstellten Scripten.

Siehe oben. Es verbietet dir keiner, die Daten mit den Scripts zu manipulieren.

Auch ist das Recht eingeschränkt, die Daten mit einer Versionsverwaltung zu verarbeiten.

Würde mich interessieren, was für solch ein Recht die Rechtsgrundlage sein soll. Es sei denn du verwendest in deinem Post den Begriff "Recht" nicht im juristischen Sinn. Dann solltest du das aber kennzeichnen.

Die von dir angesprochenen Unzulänglichkeiten mögen ärgerlich sein, insbesondere wenn man die Vorzüge von modernen Versionskontrollsystemen zu schätzen weiß, es gibt hierauf aber kein Recht im juristischen Sinne.

[derneugierige]

Leider doch. Es gibt Plugins, bei denen bei einem einfachen Kopieren des Projektspeichers die Daten unvollständig oder gar kaputt sind. Nur durch einen Projektexport ist sichergestellt, dass alle Daten mitgenommen werden.

Kannst Du das mal näher ausführen? Am besten an einem konkreten Beispiel?

Seit wann gehen Daten beim kopieren kaputt? Der einzig denkbare Fall wäre, dass (wie im Fall der ETS) vorsätzlich die Verwendung kopierter Daten verweigert wird.

Und wieso unvollständig? Dann sind die Daten wohl nicht im Projektverzeichnis enthalten?

[derneugierige]

Nö. Du kannst ja auf die Daten beliebig zugreifen, sie transfomieren und was auch immer.

Zwar kann ich die Daten beliebig transformieren. Nur wird die ETS danach nicht mehr mit diesen transformierten Daten arbeiten wollen, wenn zB der ets5hash nicht stimmt. Und nochmal: hier liegen keine technischen Gründe vor. Das ist schlicht Willkür der KNXA.

Es kann dann halt nur sein, dass die ETS mit diesen manipulierten Daten nicht zurecht kommt.

Dass man bei den Änderungen wissen sollte was man tut hatte ich stillschweigend vorausgesetzt.

Wir setzen also voraus, dass die XML-Daten exakt in derselben Weise manipuliert werden wie die ETS das auch tun würde. Trotzdem wird ETS diese Daten nicht mehr anfassen wollen, sofern zB der ets5hash nicht stimmt. Das hat nichts damit zu tun dass die Daten nicht konsistent wären.

Dadrauf hast du auch keinen Anspruch.

In dem Fall dass mein Script zB die Struktur der Daten kaputtmachen würde gebe ich Dir recht. Das ist dann aber auch mein eigenes Problem. Dass man wissen sollte was man tut wenn man Daten direkt bearbeiten will, ist schon klar.

Sofern mein Script aber die Daten so hinterlässt wie sie auch von der ETS erzeugt werden könnten, dann gibt es keinen (technischen) Grund, diese Daten abzulehnen.

Siehe oben. Es verbietet dir keiner, die Daten mit den Scripts zu manipulieren.

Doch. Die ETS wird diese im Anschluss nicht mehr akzeptieren, sofern zB ein ets5hash falsch ist.

Würde mich interessieren, was für solch ein Recht die Rechtsgrundlage sein soll.

Die ETS gehört der KNXA. Hier darf KNXA gerne Vorkehrungen treffen dass diese nicht kopiert und/oder manipuliert wird. Das tut die KNXA ja auch in Form eines kleinen grünen Stückes Elektroschrott, das dauerhaft einen USB-Port blockiert.

Die mit der ETS erstellten Projekt-Daten hingegen gehören nicht der KNXA sondern dem Benutzer. Hier sehe ich nicht woher die KNXA sich das Recht herausnimmt dem Benutzer das Kopieren und/oder Manipulieren dieser Daten zu unterbinden.

Die von dir angesprochenen Unzulänglichkeiten mögen ärgerlich sein, insbesondere wenn man die Vorzüge von modernen Versionskontrollsystemen zu schätzen weiß, es gibt hierauf aber kein Recht im juristischen Sinne.

Woher nimmt KNXA (in juristischem Sinne) das Recht, dem Benutzer die Verwendung der eigenen Daten -- in welcher Form auch immer -- einzuschränken?

[TabSel]

wenn die ETS die Daten binär speichern würde könntest Du ohne reverse engineering auch nix dran ändern. So war und ist das mit so ziemlich jeder Software. Die verhashung ist m.E. nachvollziehbar, da nur so sichergestellt werden kann das die ETS die Daten ändert, und die KNXA keinen (kostspieligen) Support leisten muss (und har nicht kann): wenn ein Projekt nicht mit der ETS bearbeitbar ist MUSS die ETS allein schuld sein und Support ist zu leisten und eine Wartung eines Softwareproblems ist nötig. Nur weil Du die XML (nach entzippen) lesen kannst heißt das nicht dass Du die ETS reverse engineered hast und weißt wie sie Daten strukturiert und (de)serialisiert und da scripten kannst.

das ist hahnebüchen was Du hier forderst.

scriptkiddies… 🙄

[Cepheus73]

Die mit der ETS erstellten Projekt-Daten hingegen gehören nicht der KNXA sondern dem Benutzer. Hier sehe ich nicht woher die KNXA sich das Recht herausnimmt dem Benutzer das Kopieren und/oder Manipulieren dieser Daten zu unterbinden.

Hier muss man halt zwischen den Dateninhalten und den Datenstrukturen unterscheiden. Die Struktur der Daten ist in der freien Entscheidung der KNXA im Rahmen ihrer Produktgestaltung.

Du hast im Rahmen deines ETS-Produktkaufs nur ein Anrecht auf das Funktionieren der zugesicherten Produkteigenschaften.
Hierzu gehört das Manipulieren der Daten im Rahmen der von der KNXA vorgesehenen Benutzer-Schnittstellen:

• Über die Produkt-GUI
• Über die offiziellen Import-/Export-Schnittstellen (z.B. Projektexport als knxproj-Datei)

Hierzu gehört nicht:

• Das Manipulieren von beliebigen Daten über von der KNXA hierfür nicht vorgesehene interne Schnittstellen und Datenstrukturen

Oder kannst du eine Rechtsgrundlage (Gesetz, Verordnung oder einschlägige Gerichtsurteile) nennen, auf Grund derer dir ein Anbieter eines SW-Produkts Zugriff auf diese internen Strukturen geben müsste?

[derneugierige]

Die verhashung ist m.E. nachvollziehbar, da nur so sichergestellt werden kann das die ETS die Daten ändert, und die KNXA keinen (kostspieligen) Support leisten muss (und har nicht kann):

Sorry, aber das ist Unsinn:

1. Um sich vor ungerechtfertigten Support-Anfragen zu schützen reicht es vollkommen zu erkennen, dass Änderungen vorgenommen wurden (und dann ggf die Hand aufzuhalten). Dazu ist es in keinster Weise erforderlich, die weitere Bearbeitung zu unterbinden.
2. Im vorliegenden Fall war keinerlei Fremdsoftware involviert. Sowohl auf dem vorherigen Rechner war eine ETS5.7.7 Professional mit Dongle im Einsatz als auch danach. Nochmal: keinerlei Fremdsoftware, alles hochoffiziell lizenzierte Original-Software. Die ETS ging an dieser Stelle sogar so weit, den BCU-Key aus den Projektdaten rauszuwerfen.

Nur weil Du die XML (nach entzippen) lesen kannst heißt das nicht dass Du die ETS reverse engineered hast und weißt wie sie Daten strukturiert und (de)serialisiert und da scripten kannst.

Woher kennst Du mich so gut dass Du glaubst beurteilen zu können was ich kann und was ich nicht kann? Du solltest keine voreiligen Schlüsse ziehen über Leute die Du nicht einmal ansatzweise kennst...

Nur nebenbei: Entgegen Deiner Annahme sind die Daten im Projektverzeichnis nicht gezipped. Nicht dass das einen nennenswerten Unterschied machen würde. Es zeigt aber, wie "gründlich" Du Dich mit der Thematik befasst hast bevor Du Deinen Beitrag verfasst hast...

scriptkiddies… 🙄

Du solltest Leute die Du nicht kennst nicht mit Begriffen titulieren, deren Bedeutung Dir offensichtlich vollkommen unbekannt ist.
Hint1: Ich schrieb von eigenen Scripten. Offensichtlich hat Dir noch niemand verraten, dass es Leute gibt die in der Lage sind Scripte (oder allgemeiner Software) selbst zu schreiben.
Hint2: Ich verwende diese nicht um in fremde Systeme einzubrechen oder anderweitig Schaden anzurichten, sondern um meine eigenen Daten zu bearbeiten.

[TabSel]

stimmt, Du hast vollkommen Recht. Ich bitte um Entschuldigung.