ElabNET Technik Forum

Ich denke auch das man mal die V1 raus hauen sollte (wie ich euch kenne gebt ihr euch auch bei der V1 nicht mit etwas nur gutem zufrieden) und dann in gewohnter agiler Art und Weise auf die Nutzeranforderungen eingehen.
Ich denke es hat jeder von euch und auch jeder Nutzer etwas verschiedene Anforderungen, was so eine Visu können und abdecken soll.
Ich denke auch, wie oben schon beschrieben, dass das Leistungsmerkmal „Visu“ an sich die Verkaufszahl antreiben wird und damit auch mehr Budget zur Verfügung steht um alle Leistungsmerkmale weiter zu entwickeln.
Deshalb am Anfang evtl. Etwas mehr im die Visu investieren um dann aus den Mehrverkäufen zu profitieren.

StefanW hat geschrieben: ↑Fr Feb 10, 2023 8:39 am Meine Einschätzung wäre auch, dass die Nutzer damit einverstanden sind, wenn wir ein Drittel bis zur Hälfte des Upgrade-Budgets dafür einsetzen.

Würde ich voll und ganz zustimmen, da die Visu auch als Zugpferd für den TWS zu sehen ist und damit langfristig strategisch der richtige Weg, weil damit später mal auch wieder Geld für die Weiterentwicklung anderer Features zurück kommt.
Man muss später mal sehen (Scrum), wie viel man wirklich in die Visu stecken muss => was braucht der Markt damit der TWS besser angenommen wird vs. "die beste Visu". Da bin ich eher erstmals beim "notwendigen" und dann sehen wir weiter im Sinne KVP.

lg
Robert

Wenn ich die letzten Posts zusammen fasse stellt es sich mir so dar, dass es einen Konsens über die Wichtigkeit der Visu gibt und auch darüber, dass von den bestehenden Mitteln einiges dafür verwendet werden soll.
Aber bereits bei Stefans Auflistung der geplanten Features war zu sehen, dass das nicht günstig wird und auch die Kostenschätzungen in den anderen Posts zeigen das. Daher hat Micha schon recht: Macht es so wie bei anderen Features auch und bringt eine erste Version, die zeigt wo die Reise hin geht/gehen kann/gehen soll. Dazu habe ich jetzt noch folgende ergänzenden Gedanken:

Welche Teilbereiche der Visu kosten besonders viel?

Ich vermute mal:
- Die Kernkomponenten, die unter der Haube notwendig sind, die aber niemand zu sehen bekommt bilden einen größeren Block.
- Alle Kacheln und anderen Darstellungen werden für sich genommen überschaubar sein, aber in Summe ebenfalls einen größeren Block bilden.
- Web-App, Android-App und iOS-App dürften ebenfalls einigen Aufwand beinhalten.
Was sind vielleicht noch weitere große Blöcke?

Welche Teilbereiche der Visu dürfen auf gar keinen Fall fehlen?

Wieder meine eigenen Gedanken als Vorschlag:
- Alles was zur "Bedienung" des Hauses notwendig ist muss in V1 enthalten sein. Eben vergleichbar mit dem, das in der X1-App geht. (Oder auch in der Loxone-App, aber die kann deutlich mehr)
- Instant! In einer V1 kann sicher auf Anpassbarkeit der Optik und auf individuelle Anordnung der Elemente verzichtet werden, aber was nicht fehlen darf ist der "no effort"-Ansatz. Die Visu muss also irgendwie auf Knopfdruck aus dem erzeugt werden, was im TWS vorhanden ist. Alternative Optik oder individuelle Anordnung einzelner Elemente können zB in V2 kommen, wenn Anwender es wünschen. Die einheitliche Optik schadet scheinbar weder dem X1, noch der Loxone, sondern im Gegenteil. Die vorgegebene Optik stellt ein Gesicht der Server dar und hat einen Wiedererkennungswert. Im Sinne der Werbung kann es zunächst also sogar sinnvoll sein, dass die Visu immer im gleichen Design erscheint. (Außerdem vereinfacht es Anwendung/Einrichtung und spart Elabnet die Entwickliung.)
- Eine "Unterstützung" aller Plattformen muss bereits in V1 drin sein. Ich schreiben absichtlich Unterstützung, weil ich weiß, dass drei Apps teurer sind als eine. Ich denke, dass es in der V1 reicht, wenn die Web-App auf allen Bildschirmgrößen funktioniert und sich selbst (instant) darauf einstellt. Das erhöht zwar den Aufwand für die Web-App und die automatische Generierung der Darstellung der Inhalte, aber es fokusiert die Entwicklung auf einen Zweig und spart die Kosten für die zwei anderen Apps.

Welche Teilbereiche der Visu sind besonders werbewirksam?

- Einheitliche Optik mit Wiedererkennungswert (siehe oben) die besonders oft und möglichst über all zu sehen ist, Die von jedem TWS-Besitzer gerne genutzt und anderen gezeigt wird. Dieses Vorzeigen geht besonders gut am Smartphone, weil es jeder überall jedem zeigen kann. (Aktuell werden gerne PV-Erträge und ähnliches gezeigt. Es sollte also schon in V1 die passende Kachel+Detailseite mit grafischer Darstellung vorhanden sein. )
- Auch die Präsenz in den wichtigsten App-Stores wäre zwar ein weiterer Faktor, jedoch würde ich den geringer einschätzen, als den vorherigen Punkt. Und auch aufgrund des Aufwands und der Kosten würde ich den tatsächlich zurückstellen, sofern die WebApp einen guten Ersatz besonders auf Smartphones darstellt.
- Viele werden ein VPN nutzen, aber im Sinne der einfachen Vorzeigbarkeit bei den Kollegen im Büro etc wäre in der Rangliste für den Werbeeffekt vermutlich nach den Smartphne-Apps der nächste Punkt das Thema Relay-Server/Proxy oder ähnliches. Wobei das dann vielleicht schon die nativen Apps benötigt, damit es instant funktionieren kann? Versteht mich nicht falsch: ich selbst brauche das nicht, ich überlege nur, was für die Werbewirkung gut sein könnte.
Der erste dieser drei Punkte sollte mMn in der V1 drin sein. iOS und Android App-Stores und eine instant remote Verbindung sind vermutlich erst in der V2 wichtig. Denn die V1 wird sicher erstmal das technisch versiertere und interessiertere Publikum erreichen müssen. Die AppStores und remote-Verbindung sind dann wohl im zweiten Schritt um die noch breitere Masse anzusprechen.

EDIT: Robert hat weniger getippt und war darum schneller, aber im Kern schreiben wir wohl das gleiche.

Das Feature, was muss in V1 an Funktion alles dabei sein, mit alles was man im haus bedienen kann wird nicht sinnvoll sein, weil dann stehst mit einem bei bei der Frage nach Türko/Video-Bimmel, Und das kann den Start gewaltig verzögern.

Grafen und Charts hingegen sollten unbedingt in V1 dabei, sein denn das ist gerade im IST eines der Features wo der TWS super funktioniert, das wäre ein Armutszeugnis wenn sowas dann nicht in der Visu abbildbar wäre. Auch wenn es ggf "nur" eingebundene Grafana-Dashboards sind.

Aber ansonsten ja an Bedienelementen braucht es das was man mit nativ KNX anstellen kann.

Und man muss den Überblickbehalten was ist Visu und was ist wegen Visu nah an der Schnittstelle zu weiteren Systemen (Bedienung Multiroom Audio) und Logiken (Zeitschaltuhr) und oder beides (Nachrichten). Am Ende verbindet die Visu alles auf der Roadmap nochmal in einem anderen Gewand.

Hi Lukas,

Parsley hat geschrieben: ↑Fr Feb 10, 2023 10:53 am- Instant! In einer V1 kann sicher auf Anpassbarkeit der Optik und auf individuelle Anordnung der Elemente verzichtet werden, aber was nicht fehlen darf ist der "no effort"-Ansatz. Die Visu muss also irgendwie auf Knopfdruck aus dem erzeugt werden, was im TWS vorhanden ist.

das war unser Vorhaben, aber je tiefer wir in die Sache eintauchen, desto mehr stellen wir fest, dass gar nicht soviel vorhanden ist, weil wir den Nutzern die bestehenden Funktionen mit minimalem Aufwand zur Verfügung stellen. Da sind Angaben zu Orten, Funktionen gar nicht so vorhanden.

Wir denken, dass es wenig Sinn hat, nun Voraussetzungen anzufordern, was in welchen Tags oder sonstigen Objekten stehen muss, damit eine Visu auf Knopfdruck funktioniert. Es gibt so Visu-Geräte, die werben damit, dass sich die Visu aus dem ETS Projekt erzeugt, aber die Wahrheit ist, dass man dann sein ETS Projekt dafür soweit anpassen muss, dass man gar keinen Vorteil hat und dann bedeutet das für den Kunden, dass er zwingend KNX benutzen muss. Wir haben aber auch Kunden, die nutzen nur den Modbus Anteil oder MQTT im Server und haben mit KNX gar nichts am Hut.

Daher haben wir uns entschieden, dass man die Visu zwar sehr einfach einrichten können wird, aber dass das Hauptmerkmal "Voraussetzungslos" ist. Also keine Abhängigkeit von KNX oder der ETS oder von sonstigen Einstellungen. man muss nur das Objekt für die Kommunikation haben, das kann dann auch von jedem Subsystem sein.

Die Widgets erhalten eine individuelle Applikation, in der man Angaben machen KANN. Je mehr Angaben man macht, desto mehr kann das Widget angepasst werden.

Das Augenmerk wird weiterhin sein, dass man sowenig Eingaben machen muss wie nötig und dass die neue Visu dann auch "Instant" funktioniert und einfach nur per URL (bei der Web-App) aufgerufen wird. Aber wir wollen es nicht erfordern, dass man an anderen Stellen im System erst irgendwas in TAGs oder so hinterlegen muss, damit die Visu sich dann "automatisch" generiert, weil das führt zu einem Hin- und Hergespringe, was nicht smart wäre.

Darum, einfach öffnen, Widgets aussuchen, Funktionen aussuchen und Objekte zuweisen. Speichern. Nutzen.

lg

Stefan

Hallo Göran,

gbglace hat geschrieben: ↑Fr Feb 10, 2023 12:23 pmAber ansonsten ja an Bedienelementen braucht es das was man mit nativ KNX anstellen kann.

Und das ist schon eine Menge.

Bei näherer Betrachtung ist ein Glastaster bereits eine kleine Visu. Und eine Visu nur ein sehr flexibler Glastaster (plus Grafen und Sonderanzeigen). Wir werden uns also, was die Funktionalität betrifft, schon auch danach richten müssen, was die gängigen Tastsensoren am Markt so anbieten, damit die Nutzer / Integratoren ausreichend Funktionalität vorfinden. Das ist leider in Summe nicht trivial

lg

Stefan

Parsley hat geschrieben: ↑Fr Feb 10, 2023 10:53 am Welche Teilbereiche der Visu kosten besonders viel?

Die Komplexität. Die skaliert nicht linear mit den Features sondern exponentiell.

Wenn Du Pech hast, dann ist der Einbau eines neuen Features genau so aufwändig wie alles bisher erzeugte. Und beim nächsten darfst Du das soeben verdoppelte Projekt gleich nochmal doppeln.
Aber zum Glück liegt der Faktor bei den meisten Features nicht bei 2 sondern ist ein gutes Stück kleiner. Aber nach ein paar kleinen, weiteren Features ist man trotzdem wieder bei der zwei Angekommen.

Ja die MDT GT2 sind da schon gewaltig, für nen Taster.

Aber am Ende sind es nur Recht wenige Funktionen die an der Anzeige selbst zur Verfügung stehen. Bit und Byte Datentypen und 14-Byte Text. Kurzer langer Tastendruck. Alles andere wäre im TWS schon nicht mehr Aufgabe der Visu sondern einfach das durchreichen an Objekte und Auswerten in Logiken. Da muss man schon auch aufpassen nicht das man den halben LE in die Widget-Definition verbaut.

Hi Göran,

keine Sorge, Logik hat in der Visu nichts zun suchen (auch wenn es Visus gibt, die das tun).

Aber wir müssen eben auch mit den unterschiedlichen Datentypen und Rückmeldeobjekten zurecht kommen, die benutzt werden, nicht nur in KNX. Details arbeiten wir gerade aus.

ich wollte nur darauf hinaus, dass man das Sendeverhalten einiger Widgets auch einstellen wird können / müssen.

lg

Stefan

Ja da bin ich wieder dabei, hatte ich ja auch schon am Thema ERR Solltemperatur skizziert, dass man dem Widget mitgeben muss nach welcher Geschmacksrichtung es arbeiten soll