[DISKUSSION] UMFRAGE: Nutzung bestehender Visualisierungen für InstantVisu

[Parsley]

Moin zusammen,

danke für den smartapfel-Link, den muss ich mir mal ansehen. In meinem Umfeld gibt es >50% Äpfel aber bisher habe ich HomeKit noch nicht betrachtet, weil mein letzter Kenntnisstand war, dass man dafür zwangsweise einen AppleTV oder HomePod benötigt. Wenn sich das inzwischen geändert haben sollte sind die potenziellen Vorteile, die Stefan aufgezählt hat natürlich schon ein echtes Argument. Insbesondere Push-Nachrichten wären ohne native Apps afaik ja gar nicht machbar, sodass die CV alleine nicht reichen würde.
Andererseits ist es mMn unerlässlich eine Visu zu haben, die direkt in jedem beliebigen Browser aufgerufen werden kann und das spricht afaik dann doch wieder für gegen HomeKit und für CV.

[CHD]

Bezüglich der Optik in der CV ist doch schon was im Hintergrund am "laufen"...

Wie ist da der Stand der Entwicklung? Kann man da nicht drauf aufbauen und ggf. noch das Farbkonzept etc. an den TWS anpassen. Zeitgemäß wäre das damit dann mM nach schon mal.

Und top, wenn man das dann noch manuell erweitern und pflegen kann. Vor allem wäre man nicht limitiert auf bestimmte Vorgaben.

Bei Homekit kann man doch nur auf die exitsierende Optik setzten, oder? Sieht erst mal gut aus und kann man schnell den Nachbarn zeigen, aber dann?!? Klar, wird man vielleicht auch brauchen, weil das viele zufrieden stellt, aber mit der optisch ansprechenden CV kommt man wohl einfacher weiter.

Christian

[Dragonos2000]

Wie sich der Aufwand "CV Generator vs. Homebridge Implementierung" grob ergibt, wird vermutlich keiner abschätzen können, oder? Davon würde ich es abhängig machen.
Bei CV wären alle Architekturen (Smartphones, Desktop PC,...) adressiert, da Web basiert und es gibt eine etablierte und ausgereifte Grundlage. Darüber hinaus kann das, was der Generator ausspuckt leicht customized werden.

Homekit kenne ich zu wenig und kann die o.g. Punkte nicht beurteilen. Wenn ich "Broadcast basiert" lese, kommen mir als erstes Probleme via VPN in den Sinn. Gibt es eine breite Auswahl an Visualisierungen, oder sind das nur wenige Anbieter, von denen man dann abhängig wäre?

Es muss fancy sein und der Aufwand überschaubar, ohne das Rad neu zu erfinden.

[danik]

Ein Vorteil bei HomeKit sehe ich halt u.a. im direkten einbinden von weiteren Geräten (bei mir z.B. HUE-Lampen), ohne über eine Gateway gehen zu müssen. Im Moment habe ich HUE in KNX eingebunden über die TWS-Funktionen, einfachheitshalber aber auch nur Ein/Aus und Szenen.

Wichtig wäre für mich halt den Visu-Zugriff auf alle TWS-Objekte zu haben, ohne diese Vorher konvertieren zu müssen (z.B. 1Wire auf KNX oder MQTT).

Zurzeit nutze ich Edomi, CV, Homekit/HUE-App parallel, bin aber nicht happy damit.

Gruss
Dani

[SchlaubySchlu]

Mir geht es da wie @danik, am wichtigesten wäre es für mich das eine "Verbindung" zwischen der Visu und dem TWS existiert ohne das alles auf den KNX Bus geschrieben werden muss (das stört mich aktuell sehr).

Ansonsten finde ich die Optik der CometVisu durchaus ansprechend und wenn man mit dem Code etwas per "Du" ist dann geht das programmieren meiner Meinung auch schnell (schneller als wenn man etwas mit der Maus zeichnen müsste).
Daher hätte ich mit einer Code-Bassierenden Lösung kein Problem.
Eigentlich wollte ich mal edomi testen aber bis jetzt habe ich mir nur ein paar Videos angeschaut, weiter bin ich nicht gekommen. Gestört hat mich bei diesem Ansatzt das dann z.b. die Logik doppelt ist, also im TWS und Edomi. So etwas sollte vermieden werden wenn ihr etwas neuen plant. Somit schon mal ein Punkt für die CometVisu.

Für mich wäre weiter wichtig, das es eine Schnittstelle zu (in meinem Fall) Apple Homekit gibt, damit ich direkt etwas schalten kann ohne das auf die Visu gegeangen weden muss (so als "Schnelltaster").

[peuter]

Bezüglich der Optik in der CV ist doch schon was im Hintergrund am "laufen"... viewtopic.php?f=96&t=3720&p=41452&hilit ... ign#p41452

Der Link geht auf einen Post, den ich im Entwicklerforum geschrieben habe, daher wird den nicht jeder hier öffnen können. Inhaltlich gibt's das aber seit heute auch hier nachzulesen: https://knx-user-forum.de/forum/support ... esign-tile.

Wie ist da der Stand der Entwicklung? Kann man da nicht drauf aufbauen und ggf. noch das Farbkonzept etc. an den TWS anpassen. Zeitgemäß wäre das damit dann mM nach schon mal.

Mittlerweile ist das in der Entwicklungsversion der CometVisu (und damit auch in den Nighty-Builds) verfügbar und kann getestet werden, Ist aber noch nicht für den produktiven Einsatz geeignet, weil es eben noch mehr in der Breite getestet werden muss. Farblich anpassbar ist das sehr einfach, es gibt z.B. einen eingebauten Light-Mode (Dark-Mode ist default) der aus lediglich 8 Zeilen CSS besteht.

Und top, wenn man das dann noch manuell erweitern und pflegen kann. Vor allem wäre man nicht limitiert auf bestimmte Vorgaben.

Sobald man da selbst Hand anlegt wird man keine Instant-Visu mehr haben. Man kann entweder was automatisch generiertes oder etwas mit eigenen Anpassungen haben, beides gleichzeitig wird nur sehr schwer / gar nicht umsetzbar sein. Aber die automatisch generierte Config als Basis zu nehmen und dann mit eigenen Anpassungen weiter zu machen geht natürlich, Man muss dann nur in Zukunft alles was da noch hinzukommt selbst auch manuell nachtragen.

[blaubaerli]

Hallo Tobias,

das sieht ja sehr vielversprechend aus. Hut ab!

Danke.

Beste Grüße
Jens

[gbglace]

Insbesondere Push-Nachrichten wären ohne native Apps afaik ja gar nicht machbar, sodass die CV alleine nicht reichen würde.

Da muss ich mal gerade nachfragen was haben Push-Nachrichten mit einer Visu zu tun? Das es and er Tür gebimmelt hat und ein dazu passendes Bild auf dem Handy ankommt kann man auch mit einem Telegramm-Bot bauen.

Ich frage mich daher was ist da der Anwendungszweck von solchen Push-Funktionen der Visu?

(Ich habe halt keine Visu bei mir im Haus am Laufen daher frage ich da)

[gbglace]

Wichtig wäre für mich halt den Visu-Zugriff auf alle TWS-Objekte zu haben, ohne diese Vorher konvertieren zu müssen.

Den Zahn wird man wohl ziehen müssen. Weil im Sinne der modularen Konstruktion des TWS wirst jedes gewünschte Element im TWS einem Visuelement zuordnen müssen (Dispatcher).

Aber das der TWS dann im Hintergrund ggf ein eigenes MQTT Subsystem installiert und diese Visu-Elemente dann da als MQTT Element speichert um sie dann via MQTT-Backend in die CV zu bekommen, ja das würde ich dann auch als black-box Funktion im TWS erwarten.

Die Anbindung von allen sonstigen IoT Gerätschaften die per Homekitt grundsätzlich erreichbar sind müssen ja vorab erstmal in ein TWS-Objekt gepackt werden um sie dann auch per Dispatcher in ein Visuelement zu bringen. Die bisherige Architektur aufzugeben und in der Homekit-Visu-App irgendwelches Homekitt-natives direkt einzubinden ohne das das durch den TWs gelaufen ist sollte nicht das Ziel sein.

Insofern ja wenn man auf eine Homekit-basierte Lösung setzt dann hat man zuvor mit dem TWS ein Homekitt-GW gebaut. Allein das würde für mich dagegen sprechen, denn eine solche Entwicklung bedeutet das die Visu erst an Stelle zwei kommen wird da man zuvor ein Homekitt-GW als TWS Subsystem bauen muss. Da aber wiederum frage ich mich ob es da nicht schlauer wäre direkt Matter zu implementieren. Und wenn die Visu wichtiger ist dann doch beim Web-basierten Ansatz zu verbleiben. Browser gibt es soweit auf allen Plattformen.

[gbglace]

Gestört hat mich bei diesem Ansatzt das dann z.b. die Logik doppelt ist, also im TWS und Edomi.

Das hat aber nichts mit der VISU in EDOMI zu tun. man kann eine DOMI.Visu auch ohne Logik bauen.

Hier vermischen zu viele Leute Logik, Integration von IoT Zeugs via anderer Protokolle (Home-Kitt) und reine Anzeige/Bedienung von existierenden Funktionen >> VISU.

Für mich wäre weiter wichtig, das es eine Schnittstelle zu (in meinem Fall) Apple Homekit gibt, damit ich direkt etwas schalten kann ohne das auf die Visu gegeangen weden muss (so als "Schnelltaster").

Das ist wieder nix was zum Thema Visu gehört.
Eine Visu ist eine Visu und kann einfache bis hochkomplexe Dashboards und Befehls-Knöpfe beinhalten. eben genau das was die CV tut.

Irgendwelche nativen Apple-Funktionen zu nutzen wäre keine Visu sondern eine Protokollanbindung an den TWS. Das kann man gerne als Wunsch haben. Aber sehe ich als ein anderes Feature an.

Wenn man jetzt meint, der TWS baut nur eine Home-Kitt Protokoll Anbindung und dann kann sich jeder mit jeder Homekit-App sich seine Visu zusammenbasteln. Dann sehe ich da allerdings das Ziel einer TWS-Instantvisu nicht als erfüllt an.
Ich würde es da eher so sehen, dass in der TWS-UI das Layout und der Funktionsumfang der Visu definiert wird.