[TOP 10 FR] Reverse Workflow - oder von hinten durch den Server in die ETS

[StefanW]

Bitte mit Live-Anlegen einer neuen GA ohne hier Dialog-Boxen oder gar Seiten wechseln zu müssen! Und diese GA sollte dann über den TWS-Importer natürlich in der ETS gleich mit angelegt werden.

Genau so ist es gedacht.

Im DOS einfach "neue GA / neues Objekt" dann die GA eingeben und fertig.

Das Objekt dazu macht er sich im Hintergrund selbst, mit der GA-Verknüpfung und programmiert sich gleich. Ich hoffe, wir bekommen das ohne Restart des KNX Stacks hin.

Den Sync mit der ETS macht der Kunde dann, sobald er Lust und Laune daran hat.

lg

Stefan

[FabKNX]

das finde ich auch echt gut, dann verliert man sich beim Anlegen von Logiken nicht immer in der ETS. Sondern bleibt bei der Sache.

[StefanW]

Hallo zusammen,

wow, 31 Reactions und eine lebhafte Teilnahme, sieht ja fast so aus, dass wir das Feature umsetzen müssen

Nun, war eh geplant, weil Ziel des Timberwolf Servers ist es, dass alles so einfach wird wie finanziell sinnvoll machbar und dabei möglichst auch Zeit eingespart wird, damit ihr mehr Zeit habt für Eure Familien.

Das Transplantationszentrum reibt sich auch schon die Hände... 19 frische Nieren..

lg

Stefan

[bluegaspode]

Ich habe jetzt auch dafür gevotet.

Denn ich fange jetzt an Logiken zu schreiben und natürlich ist nicht jede GA, die ich spannend finde verknüpft.
Also Workaround anwenden (app.php/kb/viewarticle?a=94).

Währenddessen schreibt und liest die CometVisu ohne Probleme fleißig auf dem Bus und mir ist erneut nicht klar, welche Vorteile dieses Konzept mit der ETS-App für mich haben soll, wenn ich über mehr Nachteile stolpere als ich bisher Vorteile für mich ausmachen würde.

Ich bin daher sogar für einen "radikaleren" Ansatz:
Denke den letzten Schritt ''mit der ETS synchronisieren" komplett anders.

Grundthese:
Wenn du den 4ten Schritt "mit ETS synchronisieren Schritt" weglässt, haben 80% der Nutzer keinen Nachteil. Der Timberwolf liest und schreibt auf den Bus, wie er lustig ist (sogar zertifiziert). Und für Kunden sind Schritt 1-3 total intuitiv und super elegant.

Wer sind die letzten 20%, denen das nicht reicht?
Alle diejenigen, die etwas komplexere Topologie haben und wo die ETS die Applikation/Gruppenadressenzuordnung braucht, um die Linienkoppler korrekt zu programmieren.
Diese Nutzer würden nun normalerweise ein Dummy-Objekt anlegen und dabei viel falsch machen können, bzw. hohen Aufwand damit haben.

Und jetzt kommts:
Objekt 1-8999 des Timberwolf werden nie in der ETS angelegt (und auch nicht hin- und hersynchronisiert mit all den potenziellen Problemen).
Dafür gibt es Objekt 9000-9020 mit klassischer "Dummy" Funktionalität, die der Timberwolf zwar besitzt aber eigentlich komplett ignoriert. Zzgl. einen Importer, der alle GAs passend zu ihrem Typ auf die paar Dummy-Objekt packt.

Die ETS ist dann glücklich. In der Folge sind die Linienkoppler auch glücklich. Der Timberwolf Nutzer sind glücklich. Und deine Entwickler auch, denn du bist den Großteil der sich gegenseitig beeinflussenden Synchronisationsprobleme los.

[bluegaspode]

Oh und ganz vergessen: die ETS Performance Probleme wäre auch weg, denn die ETS sieht nur noch die 20 Dummy-Objekte (9000-9020).
Wieviel Nerven (bei dir, weil das Problem weg vom Tisch ist und du nicht mehr von den ETS-Entwicklern abhängig bist) und allen Nutzern könnten hier gespart werden?