ElabNET Technik Forum

Naja hier diskutieren wir ja die inhaltlich fachlichen Features einer ZSU und wie man das in einer Admin-Oberfläche mit den individuellen Werten definiert / aktiviert.

Das Problem ist, viele sehen immer einen Server und Logik-Engine aus der Sicht einer VISU. Der TWS ist halt erstmal gerade alles nur keine VISU.
(Docker Container Visus sind ja erstmal nichts TWS-natives)

Wenn also das Grundgerüst zur Definition einer ZSU im TWS internen ZSU-GUI-Editor erledigt ist, dann gibt es entweder noch eine Ausbaustufe, mit der man via externe Objekte dann eine definierte ZSU modifiziert oder gar generiert. Oder diese ZSU-GUI ist so schön und hat im TWS ne eigene URL, dass man die dann ggf. direkt als Remote-Zugriff auf so ein Visu-Tablet bringt. (Ähnlich eines Grafana-Dashboards was man sich in eine Visu integriert)

Eigenbau ZSU als Coustom-Baustein mit externen Eingängen sind dann natürlich noch eine Variante.

Oder diese ZSU-GUI ist so schön und hat im TWS ne eigene URL, dass man die dann ggf. direkt als Remote-Zugriff auf so ein Visu-Tablet bringt.

Das wollte ich mit dem Beitrag weiter oben sagen: Wenn die GUI - perspektivisch - so schön ist, dass sie Komfort und optische Ansprüche einer Visu erfüllt, kann man sich den Aufwand für eine komplizierte Schnittstelle sparen, um Daten zur Anlage einer ZSU bzw. Pflege eines Kalenders auszutauschen.

Ja, aber der Knackpunkt ist der Zugriff auf diese GUI. Die TWS Oberfläche per se ist Passwort geschützt. Der Zugriff auf eine native TWS ZSU aus einer Visu heraus muss irgendwie funktionieren. Der eine will ggf. sogar eine Authentifizierung, der anderen evtl. nicht. Der nächste Punkt ist der Sprung zurück in die Visu. Keine unlösbaren Probleme, müssen aber bedacht werden.

Was UserInterface Design angeht bin ich eher anachronistisch unterwegs mir gefallen aber die Entwürfe von Matze76 im Thread viewtopic.php?f=9&t=1760&start=10#p18701

Klasse fände ich es noch, wenn zB ein Feiertagskalender per CalDav-Format via URL/Upload importiert werden könnte.

Die Anforderung, die TWS USZU in eine andere VISU einzubetten halte ich für sportlich.
Zukünftig soll ja noch die TWS-Rest-API kommen. Die würde ich dann auch für die USZU erwarten, so dass im Design der jeweiligen VISU eine Integration möglich wird.

In der VISU wären meine Anforderungen auch minimal:
- Wochentag
- Start
- Ende

Weitere Definitionen (Astro, Feiertagskalender,...) würde ich in der TWS Oberfläche sehen, halt als semantischen Teil der Logiken.
VG Alex

alexbeer hat geschrieben: ↑Mi Dez 18, 2019 10:20 am Weitere Definitionen (Astro, Feiertagskalender,...) würde ich in der TWS Oberfläche sehen, halt als semantischen Teil der Logiken.

Genau das würde mir gar nicht gefallen, dann habe ich einen Mix an Stellen, wo etwas eingestellt werden muss.

Derzeit habe ich einige recht kleine und einfache Logiken am Laufen, deren Parameter direkt im Logikeditor eingestellt werden. Und schon jetzt - kurz nach der Entwicklung der Logiken - mache ich die Erfahrung, daß es mir schwerfällt, die richtigen Stellen zu finden wenn ich einen Parameter ändern möchte.

terseek hat geschrieben: ↑Mi Dez 18, 2019 10:44 amDerzeit habe ich einige recht kleine und einfache Logiken am Laufen, deren Parameter direkt im Logikeditor eingestellt werden. Und schon jetzt - kurz nach der Entwicklung der Logiken - mache ich die Erfahrung, daß es mir schwerfällt, die richtigen Stellen zu finden wenn ich einen Parameter ändern möchte.

Bitte einen separaten FR machen und Beispiele posten. Je GENAUER wir etwas verstehen, desto besser können wir darauf eingehen


@all:
Allerdings wäre die Erwartung, dass man alles was man im TWS einstellen kann auch per Objekten von außen einstellen kann um das von einer Visu auszuführen doch ein bisschen sportlich. Wieviele werden das nutzen?

lg

Stefan

StefanW hat geschrieben: ↑Mi Dez 18, 2019 12:33 pm

terseek hat geschrieben: ↑Mi Dez 18, 2019 10:44 amDerzeit habe ich einige recht kleine und einfache Logiken am Laufen, deren Parameter direkt im Logikeditor eingestellt werden. Und schon jetzt - kurz nach der Entwicklung der Logiken - mache ich die Erfahrung, daß es mir schwerfällt, die richtigen Stellen zu finden wenn ich einen Parameter ändern möchte.

Bitte einen separaten FR machen und Beispiele posten. Je GENAUER wir etwas verstehen, desto besser können wir darauf eingehen

Hi StefanW, da hast Du mich wohl mißverstanden; ich wollte hier nur gegen einen Split der ZSU Parameter wie von alexbeer vorgeschlagen in einen Teil, der in einer schönen neuen App gesetzt wird (wohl nur Wochentag sowie Start- und Stopzeitpunkt), und einen anderen Teil (alles weitere), der innerhalb des Logikeditors gesetzt wird, argumentieren.

Ich würde gerne alle Parameter der ZSU an einer Stelle einstellen können weil ich befürchte, daß es mir schwerfallen wird, die dann innerhalb des Logikeditors "versteckten" weiteren Parameter mit angemessen Aufwand zu finden.

Ein Featurerequest (allerdings nicht im Zusammenhang mit der ZSU) könnte allenfalls sein, die innerhalb des Logikeditors benutzten Parameter benennen zu können.

Ich glaube viele sehen die Option der ZSU Verstellung oder gar Generierung als auch zwingend via Visu zu realisieren an. Denn dafür bauen sich ja viele diese Visus um mal eben schnell den Zeitplan für den Rasen-Robo anzupassen. Aber auch als Bedienung durch diejenigen im Haushalt, die nicht-häuslicher SI sind.

Da der TWS erstmal selbst keine Visu hat ist es natürlich eine Frage über welche Objektstrukturen sich die üblichen Software-Visu-Varianten mit Objektstrukturen einer TWS-ZSU verlinken lassen, sowas muss so eine Visu ja auch unterstützen und der häusliche SI auch beherrschen.

Insgesamt werden es dann wohl immer versteckte ZSU und eben jene in der Hausbedienzentrale zu modifizierenden.

Allerdings wäre die Erwartung, dass man alles was man im TWS einstellen kann auch per Objekten von außen einstellen kann um das von einer Visu auszuführen doch ein bisschen sportlich. Wieviele werden das nutzen?

Ja, sportlich... ich habe diese Erwartung nicht!

Die Visu soll 1.) wie der Name schon sagt, die Zustände in meinem Smart-Home visualisieren und 2.) will ich Automatiken übersteuern, oder Dinge schalten, die ich nicht automatisch gesetzt haben möchte oder kann. Alles andere gehört für mich nicht in die Visu. (Es würde ja auch keiner auf die Idee kommen, die ETS in einer Visu abzubilden).

Am Beispiel ZSU:
- Einrichtung und Konfiguration einer Zeitschaltuhr (oder Kalendern) auf einer TWS-Oberfläche (ggf. per URL-Aufruf aus der Visu aufrufbar, aber kein Datenaustausch per Schnittstelle)
- Bedienung weniger alltäglich erforderlicher Änderungen oder manuelle Übersteuerung (ZSU generell stoppen/starten, Einschaltzeit, Ausschaltzeit... ) über die Visu, d.h. nur dafür entsprechende Objekte.

Der Wunsch von terseek nach Bedienung über die Visu wird wahrscheinlich obsolet, wenn eine spezielle, intuitive ZSU/Kalender-Oberfläche dafür zur Verfügung steht? Sehe ich das richtig?

Matze76 hat geschrieben: ↑Mi Dez 18, 2019 1:08 pm... eine spezielle, intuitive ZSU/Kalender-Oberfläche dafür zur Verfügung steht? Sehe ich das richtig?

richtig