[FR] 1.6.0, IP2: KNX-Objekt-Editor

[fechter65]

Wunsch für ein Nice to have:
Beim Einlesen aus der ETS können, tw. aus historischen Gründen, Abweichungen bei den DPT auftreten.
Diese werden im KNX-Objekt-Editor in der Spalte "Zustand" als "Diskrepanzen" angezeigt. Das ist eine nützliche und wertvolle Feature.

Da aber das Korrigieren der Fehler sehr aufwendig ist, vor allem wenn die DPT-Einstellung des Universal-Objekts der TWS-Applikation geändert werden muss (und damit die Zuordnung zur GA verloren geht), wäre es wertvoll, wenn die Diskrepanzen priorisiert werden könnten:

• "Kosmetische" Diskrepanzen ohne funktionale Auswirkungen (bspw. DPT 1.001 zu DPT 1.002) sollten von

• "Schwerwiegenden" Diskrepanzen, die zu abweichenden Darstellungen führen (bspw. DPT 17.001 zu DPT 5.005)

unterschieden werden können, damit die Fehlerbehandlung priorisiert werden kann.

Ansonsten wird die Einführung des TWS zu einem Marterweg, der einem rasch die Freude an der Neuanschaffung nehmen kann.

[gbglace]

Die zwei + bitte nicht falsch verstehen, da ich quasi nicht aus einem gewachsenen Projekt auf den TWS umziehe brauche ICH das Feature nicht (hab den TWs ja auch schon). Aber Neukunden mit laufender KNX-Installation denen ist das sicher ein guter Mehrwert.

[StefanW]

Guten Morgen Diego und Göran,

nur für alle Mitleser: Es ist kein Fehler des TWS. Die ETS lässt unterschiedliche Einstellungen zu und es wäre eigentlich Sache der ETS, den Kunden darauf hinzuweisen. Das wir hier nun eine Analyse auf Diskrepanzen implementiert haben, ist somit der Unfähigkeit der ETS an dieser Stelle geschuldet.

Dass nun die Behauptung im Raum steht, eine diesbezügliche Anzeige auf Unstimmigkeiten im ETS Projekt würde das Nutzungserlebnis im TWS stören, macht mich nachdenklich. Shoot the messenger?

Ich kann mit meinen Entwicklern darüber sprechen, dass wir das eine in rot und das andere in gelb einfärben, aber im Moment müssen wir priorisieren, was den Verkauf des Servers fördert. Für die vielen Details, die wir ohnehin schon in den Server einbauen, zahlt uns niemand etwas, solange wichtige Leistungsmerkmale auf der Liste fehlen.

Wenn die Community solch eine abgestufte Meldung möchte, dann bitte macht uns eine Liste, welche Diskrepanzen wie bewertet werden sollen. Wenn dann noch mehr als 20 Stimmen dafür voten, dann können wir uns das ansehen. Kommt aber frühestens nach MODBUS / MQTT Umsetzung mit V 2.5

lg

Stefan

[Robert_Mini]

Ich muss da Stefan beipflichten, auch wenn der Vorschlag gut ist.
Ehrlicherweise ist aber auch aus meiner Sicht jede Diskrepanz wichtig, mit Ausnahme der DPT1. Damit ist der Wunsch schon realisiert, wenn man Diskrepanz sieht UND <> DPT1.

Auch gibt es mit dem Importer die Möglichkeit, die TWS Applikation zu befüllen, wenn man erstmal aufgeräumt hat.

Aber im Sinne von „don’t shoot the Messenger“ würde mich interessieren wieviele Diskrepanzen @fechter65 du hast?

Ich habe bei >1000 GA keine Warnungen mehr beim import. Die meisten Probleme waren fehlende DPT an der GA, nicht falsche.
Bei falschen DPT warnt die ETS auch aktiv, wenn man die GA verknüpft! Da sollte man nicht ignorieren drücken, sondern den Fehler unmittelbar beheben.

Auch im Sinne für Best Practice zu lernen: wie war dein Vorgehen bez. GA Anlage, DPT, etc.?

Lg
Robert

[gbglace]

Naja schuld an einer solchen Konstellation hat mit Sicherheit nicht der TWS. Werden einem solche Sachen bewusst will man das ja aber meist korrigieren. Laufen tut der TWES ja auch mit den Unschärfen. Nur wer sich das alles ganz hübsch korrigieren möchte der kommt da sicher mit ner Sortierung schneller ans Ziel.

Eile ist da jetzt sicher auch nicht angebracht und ja ein echtes Verkaufsargument wird es auch nicht werden, dafür ist es zu abstrakt. Und ein SI, naja der sollte im Gedanken das er nen TWS im Projekt verbauen will da besser gleich ein ordentliches ETS-Projekt anlegen. Übernimmt ein Si ein bestehendes Projekt und pflanzt einen TWS ein, hmm der könnte den Mehrwert für sich erleben.

[Sun1453]

Ich kann mich den anderen (Stefan, Robert und Göran) nur anschließen. Es ist kein Must Have und außerdem sollte man immer Ordnung in seiner KNX Anlage haben. Das ist kein Fehler des TWS, sondern ich finde das ist ein Super Feature, was einen sofort aufzeigt, wo die Fehler sind. Das hat mir in meiner Installation perfekt weitergeholfen und seit dem gibt es keine Warnings / Fehler mehr.

Also wenn dann in Version 2.5 oder gar 3.0. Modbus und MQTT sind jetzt erstmal die Zugpferde und ich warte schon sehnsüchtig auf die IP1 von V 2.0. Ich hoffe das die 1.6 bald Final wird und man die neue Version bekommen kann.

[StefanW]

Ich verstehe das Argument von Diego schon.

Sollte sich eine Unordnung im Projekt eingeschlichen haben, welche die ETS (damals) zugelassen hat, könnte ein Kunde, beim Blick in den TWS zunächst einmal "rot" (im wahrsten Sinne des Wortes) sehen. Da nicht wenige Nutzer den Fehler nicht bei sich sondern bei anderen sehen wollen, könnten die vielen Hinweise durchaus zu einem Frust beim Kunden führen und die erste Ansicht mag sein, dass der TWS "kompliziert" ist, nur weil er in der Lage ist, dies aufzuzeigen.

Einem Profi dürfte klar sein, dass er hier wertvolle Hinweise zur Fehlersuche findet, ein Amateur könnte sich genervt fühlen. Weil er hat den "teuren" TWS gekauft, weil ihm versprochen wurde, dass alles ganz einfach geht und er sich viel Zeit spart und wird nun mit der Realität konfrontiert, dass der Server zwar einfach zu benutzen ist, aber wenn "man hunderte Geräte anschließt und tausende von Funktionen" nutzt, das am Ende jede davon bis auf das einzelne Bit genau eingestellt werden muss und der Server das auch noch frech anzeigt und zur Anpassung auffordert. Mit dieser Aufgabe hat der Nutzer nicht gerechnet, der mal "eben schnell" über das Wochenende den Server in Betrieb nimmt und nun mit den Unzulänglichkeiten im Projekt konfrontiert wird.

In dieser Hinsicht verstehe ich, dass der Wunsch besteht, dass der Server das übersichtlicher und mit Priorität darstellt.

Aber deswegen nun die wichtige MODBUS / MQTT Entwicklung (wieder) zurück stellen um die Oberfläche schöner zu machen ohne jeden funktionellen Fortschritt? Irgendwie müssen wir es auch finanzieren und das ist schwieriger, als es bei dem Feuerwerk, das wir hier abbrennen, am Ende aussieht. Wir haben damals den Care nicht für diese Vielzahl der Wünsche kalkuliert. Auch wenn dem einzelnen der Care teuer vorkommen mag, ist es doch auch so, dass wir im Durchschnitt damit nur etwa 4 - 7 Codezeilen pro zahlenden Care-Kunden pro Monat finanzieren können. Deshalb kann ich nicht solange Entwickler einstellen, bis alle gewünschten Funktionen umgesetzt sind, auch wenn ich nichts lieber täte als das zu tun. Das mag in Zukunft besser werden, aber im Moment müssen wir haushalten mit dem was wir haben.

Bitte weiter diskutieren und abstimmen, weil ich finde die Diskussion schon interessant und natürlich muss der Server den Kunden auch emotional ansprechen, weil am Ende sind es die emotionalen Dinge, die entscheidend sind und dazu führen, ob der Server in den entsprechenden sozialen und asozialen Medien empfohlen wird. Wobei mein Eindruck ist, dass dies noch nicht wirklich stattfindet - und das muss sich ändern.


lg

Stefan

[gbglace]

Naa das Modbus und MQTT und DMX überholen würde ich da auch nicht sehen.

[fechter65]

Naa das Modbus und MQTT und DMX überholen würde ich da auch nicht sehen.

Ich schrieb, mein Wunsch sei ein Nice-to-have; damit erhebe ich explizit nicht den Anspruch, dass mit diesem FR andere Entwicklungsschritte überholt werden müssten.

Aber im Sinne von „don’t shoot the Messenger“ würde mich interessieren wieviele Diskrepanzen @fechter65 du hast?
Ich habe bei >1000 GA keine Warnungen mehr beim import. Die meisten Probleme waren fehlende DPT an der GA, nicht falsche.
Bei falschen DPT warnt die ETS auch aktiv, wenn man die GA verknüpft! Da sollte man nicht ignorieren drücken, sondern den Fehler unmittelbar beheben.
Auch im Sinne für Best Practice zu lernen: wie war dein Vorgehen bez. GA Anlage, DPT, etc.?

Ich habe im Moment noch ca. 106 Diskrepanzen bei 3'077 importierten GA (gestern Nacht waren es anfänglich 186).
Der letzte Import einer ETS-Projektdatei erfolgte - wahrscheinlich (ich vermute dies aufgrund der im TWS gespeicherten Projektdatei) - am 13. Juli 2019; ich kann mich nicht erinnern, dass damals Fehlermeldungen ausgegeben worden sind, ansonsten hätte ich diese wohl behoben (eine blosse Behauptung, ich kann es nicht beschwören).

Es ist möglich, dass ich seither in der ETS DPT geändert habe, ich kann mich aber nicht erinnern, was der Anlass dafür gewesen wäre. Wahrscheinlich wurde der Importprozess des TWS seither verbessert und macht detailliertere Überprüfungen (auch dies ist eine blosse Vermutung von meiner Seite). Ich finde es auch richtig und gut, dass diese Diskrepanzen angezeigt werden, damit der TWS-Nutzer sie beheben kann.

Weil aber der Prozess
1. TWS-Applikation in der ETS anpassen (d.h. entsprechendes Universalobjekt definieren, dann GA zuordnen)
2. TWS programmieren
3. Projektdatei importieren
viel Zeit in Anspruch nimmt (wie Ihr alle aus eigener Erfahrung wisst), wäre es für den User hilfreich, wenn er rasch erkennen könnte, ob die Behebung der angezeigten Fehler sofort (weil zwingend nötig) oder später (weil bloss nice to see, aber für die Funktionalität nicht erforderlich) erfolgen muss.
Meistens dürfte das Bedürfnis für eine Neuprogrammierung immer dann auftreten, wenn man "rasch" eine neue Logik im Logikeditor erstellen möchte und dann feststellt, dass eine benötigte GA im TWS-Objektsystem noch nicht vorhanden ist (dies war jedenfalls der Auslöser meines Problems; da ich mehr als 2'000 GA in der ETS habe, kann ich dieses Problem auch nicht elegant umgehen, indem ich alle GA in das TWS-Objekt-System einlese).

Bei der Fehlerbehebung gestern Nacht konnte ich über Anpassungen in der ETS relativ rasch von 180 auf 130 Fehler reduzieren (bspw. indem ich bei Temperatur-GA von DPT 7.013 auf 9.004 umstellte. Bei gewissen Anpassungen machte ich mir die (vermeintliche) Fehlerbehebung zu einfach, indem ich in der ETS im Gruppenadressen-Fenster den DPT-Wert des TWS angepasst habe. Das geht aber - wie ich nach einem zeitraubenden Importvorgang feststellen musste - so nicht (was eigentlich logisch ist, aber nett wäre). Die korrekte Vorgehensweise ist es, in der TWS-Applikation der ETS zuerst unter Parameter die DPT des entsprechenden Universalobjekts anzupassen (was wie gesagt eigentlich logisch ist) aber dazu führt (was ebenfalls nachvollziehbar ist), dass die Zuordnung der GA zum entsprechenden Kommunikationsobjekt verloren geht und erneut zugeordnet werden muss (auch wenn die DPT nur von 1.001 auf 1.002 geändert wird). Diese Schritte können - soweit ich dies erfasst habe - in der ETS nur einzeln durchgeführt werden, d.h. hier besteht m.W. innerhalb der ETS, resp. der TWS-Applikation keine Massenananpassungsfunktionen.

Der KNX-Objekt-Editor verfügt über hervorragende Filterfunktionen. Damit kann (resp. könnte man, wenn man es als unbedarfter Anwender wissen würde) sehr rasch durch die Selektion des Zustandes "Diskrepanz" und der Länge "8 bits" erkennen, dass nur drei GA wirklich ein kritisches Problem darstellen. Darauf muss man aber erst kommen; als Neuling fehlt Dir möglicherweise diese Erkenntnis. Genau dies und nur dies war der Anlass meines FR.

Möglicherweise könnte ich mein Problem auch über die ETS-Importer-App und eine entsprechend aufgebaute Steuerdatei lösen. Ich hatte gestern Abend einiges dazu recherchiert und bin zum Schluss gekommen, dass ich mich hierfür ziemlich einarbeiten müsste, resp. dass es nicht sicher wäre, dass ich auf diesem Weg auf jeden Fall Erfolg haben würde.

Im Moment betreffen bei mir 103 Diskrepanzen "1bit"-DPT-Objekte. Dies ist für die Funktionalität nicht relevant. Hier warnt m.W. auch die ETS nicht, wenn "falsche" Zuordnungen gemacht werden. M.E. ist es auch Geschmackssache, ob man bspw. einen Präsenzmelder über 1.001, über 1.002 oder über eine andere 1bit-DPT melden lässt. [BTW: Sollte man übrigens sein GA-System ändern wollen und bspw. 40 Präsenzmelder nicht mehr über 1.001 sondern über 1.002 melden lassen, müsste man in seiner TWS-Applikation 40x ein Universalobjekt anpassen und 40x erneut eine GA zuordnen]. Der unbedarfte Anwender muss aber zuerst erkennen, dass der TWS zwar - richtigerweise - einen (roten) Fehler anzeigt, dass die Behebung dieses Fehlers aber nicht dringend ist.

Ich hoffe, dass ich Dir - @Robert_Mini mit diesen Ausführungen einen Einblick in die Hintergründe meines Anliegens geben konnte und danke Dir herzlich für Dein Interesse.
Zusammengefasst: Der Zustand, die zu diesem Thread geführt hat, spricht für die Funktionalität des TWS, indem minutiös auf die Einhaltung der KNX-Anforderungen geachtet wird. Für den Anwender ist dies zeitintensiv (dies ist eine nüchterne Feststellung, keine Kritik) und setzt eine eigene Beurteilung voraus, welche der gemeldeten Fehler rasch und zwingend behoben werden müssen.

[StefanW]

Hallo Diego,

danke sehr für den sehr interessanten Einblick aus Sicht des Nutzers, weil den haben wir als Entwickler so nicht ganz. Wir nutzen zwar auch unsere Server in unseren Häusern, aber wir haben einen anderen Wissenstand über die Möglichkeiten unserer Editoren und Filterfunktionen.

Es gibt viele Funktionen, da ist der TWS einfach sehr mächtig und wir haben das noch nicht alles rüber bringen können.

An letzterem arbeiten wir ja durchaus. Wie Du an der aktuellen "Alpha 2 der IP 3 der V 1.6" gesehen hast, gibt es ein neues Hilfesystem. Das ist nun erstmals bei Docker verwirklicht worden, soll aber stückweise für alle Funktionsbereiche kommen und damit wollen wir diese Informationen dann auch im schnellen Zugriff haben. Zudem sind Videos geplant, die in wenigen Minuten diese speziellen Dinge zeigen.

Nicht zuletzt wollen wir die KB in ein leichter durchsuchbares Wiki-Format bringen und alle Anzeigen werden auch noch verbessert.

Das Thema der abgestuften abgestuften Anzeige von Fehlern ist verstanden. Es ist klar, dass ein Nutzer mit 180 Diskrepanzen gestresst wird, zumal viele davon nicht so kritisch sind und auch nur mit gelb statt mit rot eingefärbt werden können. Müssen wir nachdenken.

Danke für das Thema. Die schlechten Texte beim Import müssen auch noch überarbeitet werden, danke für den Hinweis (im anderen Thread).

Viel Spaß wünsche ich und bitte weiter so, nur Kritik bringt uns weiter

lg

Stefan