ich entwickle das HomeAssistant-Modul und überlege, ob ich – analog zum zigbee2mqtt-Modul – eigene HTML-SDK-Kacheln für die verschiedenen Gerätetypen (Licht, Thermostat, Rollladen, Sensor …) anbieten sollte.
Bevor ich da Aufwand investiere, würde ich das Konzept gerne grundsätzlich diskutieren, weil ich beim Mehrwert unsicher bin:
Symcon bringt mit den zusammengefassten Darstellungen (Licht, Thermostat, Rollladen, Media Player …) bereits gerätespezifische Kacheln mit – konsistent über alle Module hinweg. Eigene HTML-Kacheln für genau diese Domains würden das im Wesentlichen nachbauen, nur mit abweichendem Look.
Das HA-Modul bildet generische Domains ab, die sich mit Matter, Homematic usw. überschneiden. Wenn jedes Integrations-Modul seine eigene Licht-/Thermostat-Kachel mitbringt, wird die Visualisierung optisch uneinheitlich – und für den Anwender ist schwer nachvollziehbar, warum ein zigbee-Licht anders aussieht als ein Matter oder Homematic-Licht.
Bekannte HTML-Kacheln gibt es bereits integrationsunabhängig (z. B. TileKacheln von KaiS) – also variablenbasiert statt pro Modul.
Ist das HTML-SDK eher für Sonderfälle gedacht, und sollten Module für generische Geräte-Domains besser die Standard-Variablendarstellungen nutzen?
Wie sieht die Roadmap der zusammengefassten Darstellungen aus – kommen Weiterentwicklungen bestehender Gerätetypen oder wird es weitere Gerätetypen geben? (Dann würden eigene Kacheln bald obsolet.)
Gibt es Überlegungen, wiederverwendbare bzw. integrationsübergreifende Kacheln zu unterstützen – etwa damit mehrere Module eine einheitliche Darstellung gemeinsam nutzen können? Das fände ich für die Konsistenz der Visualisierung sehr spannend.
Mich interessiert auch die Sicht von @burki24 (zigbee2mqtt v6.0) und @KaiS (TileKacheln): Was hat euch zu eigenen Kacheln bewogen, und welche Möglichkeiten seht ihr darin gegenüber den Standard-Darstellungen? Eure Erfahrungen würden mir bei der Einschätzung sehr helfen.
Ich wollte einfach ein anderes Design haben und mir fehlten teilweise Variablen in den derzeitigen Kacheln.
Bzw. fehlen Kacheln komplett, wie zum Beispiel der Whirlpool.
Wobei ich es mega fände, wenn die Darstellungen irgendwie automatisch erkannt werden können, wie bei den Symcon Kacheln, sobald spezielle Variablen vorhanden sind.
Sofern du kein ausgefallenes Design möchtest, würd ich es lassen. Mich stört z.b., wenn man diese Kacheln maximiert, der Schirm schwarz (oder weiß, je nach Design) wird. Warum kann das nicht mitvergrößert werden. Bei den normalen Kacheln funktioniert das und ich habe die Möglichkeit Werte zu “verstecken” und nur in der maximierten Darstellung anzuzeigen. Ich bin keni Fan von solchen Kacheln und habe auch schon wieder viele zurückgebaut. Sie laden auch langsamer.
Nein, dann wird die Liste mit allen Kindobjekten dieser Instanz angezeigt.
Ich habe unter jeder Raumkachel Links zu den Variablen angelegt und kann die somit maximiert als Liste darstellen.
Auf so eine Art Baukasten warte ich auch noch.
Es fehlen aber auch noch immer einige Darstellung (z.b. ~Playlist) und das würde ich gerne auch unabhängig von einer Mediakachel nutzen wollen.
Michael
witzig Jemanden anzuschreiben, der genauso heißt wie ich und auch noch gleich geschrieben wird. Aber das nur am Rande.
Also, natürlich hat man mit den selbst entworfenen Kacheln einige Möglichkeiten. Aber ich gebe @KaiS und @Nall-chan recht, das da auf Symcon noch einiges an Entwicklung und Erweiterungsarbeit zukommt. Das unser Modul ab der 6.0 evtl. eigene Kacheln mitbringen wird ist noch absolut in der Testphase. Im Moment schaue ich eher, was uns Symcon an eigenen Kacheln anbietet, die das Modul (wie @KaiS es sich wünscht) anhand der Variablen erkennt, ob eine Standard-Kachel genutzt und den Parametern der Instanz angepasst werden kann. Das funktioniert auch schon recht gut, wird aber erst in der Testphase etwas später kommen. Das heißt, das Modul wird eher auf die vorhanden Standards zurückgreifen, ehe es eine individuelle Kachel nutzt.
Also sind die derzeitig in Testung befindlichen individuellen Kacheln in unserem Modul nur eine Möglichkeit zu zeigen, was ein Modul alle bewerkstelligen kann und auch, was ein Modul automatisch einrichten und nutzen kann.
Gerade innerhalb der Module finde ich es schon spannend, was möglich ist und in wie weit ein Modul standard-Kacheln individualisieren kann. (Danke @Nall-chan für denn Fingerzeig, dass manche Sachen nicht so wirklich Symcon konform sind und der Philosophie entgegen stehen).
Ich habe bereits jetzt schon eine so große Menge gelernt, was Module und Symcon betrifft.
Man darf aber auch nie vergessen: Standard ist immer nur Standard und entspricht nur selten den individuellen Wünschen und Vorstellungen der User.
Ich würde mir wünschen das symcon viele der HTML Kacheln die wir hier in letzter Zeit gebaut haben irgendwann obsolet macht. Sind wir mal ehrlich, aus Performance Gründen alleine sind die html Kacheln nicht das gelbe vom Ei. Alleine dass die immer komplett neu laden wenn man z.B. in eine andere Kategorie springt ist einfach nur ätzend. Denke html Kacheln sollten irgendwann rein für umfangreichere Kacheln genutzt werden wie z.B. meine todo liste etc. und nicht um irgendwelche bedienelemente abzubilden. Edgecases mal außen vor gelassen.
Also ich habe Geräte Instanzen in meinen Modulen, welche sowohl die Statusvariablen als auch eine individuelle Instanz Darstellung für die Visu bieten. (z.B. Onvif oder Bring)
Das kannst du jetzt von einer reinen Visu Kachel halt nicht erwarten.
Das als „Standard“ zu definieren halte ich falsch. Siehe auch die Belange von @bumaas und was @Burki24 gerade gebaut hat. Auch da gibt oder würde es Statusvariablen in der Liste geben.
Das schöne ist ja, dass man im Symcon sich seine Visu und den Objektbaum so aufbauen kann wie man es benötigt.
Somit kann man reine Visu Kacheln damit erweitern.
Dein fehlendes wissen Symcon als Fehler anzulasten ist hier ungerechtfertigt.
Vielen Dank für die Einschätzungen! Damit ist für mich die Richtung erst einmal klar.
Ich verzichte im HA-Modul auf Custom-HTML-Kacheln und konzentriere mich stattdessen darauf, dass die Entitäten die passenden Standard-Composite-Darstellungen (Licht, Thermostat, Rollladen, Media Player) korrekt erhalten und nutzen.
Das hat den zusätzlichen Vorteil: In der Kachel-Visualisierung fügen sich die Geräte einheitlich ins Standard-Look-and-Feel ein – unabhängig davon, aus welcher Integration sie stammen. Und wenn Symcon die Standard-Darstellungen später erweitert, profitiert das Modul direkt davon.
Für echte Sonderfälle, die kein Standard abbildet, bleibt das HTML-SDK eine Option – aber das wird sich vermutlich kaum stellen. Dafür mache ich dann eher eine Wunschliste mit den Dingen auf, die mir aktuell an den Standard-Darstellungen fehlen
Wenn ich mich richtig erinnere, basiert die Visu auf Flutter? Das ist OpenSource?
Gäbe es dann nicht theoretisch die Möglichkeit das z.B. Erfahrene Modulentwickler dann irgendwie zugriff darauf bekommen um eigene Kacheln zu entwerfen, nativ in Flutter?
Nur so eine Idee, ich selber kenne Flutter nicht und hab leider keine Ahnung wie gut man da abgekapselt so etwas erstellen könnte?
HTML Kacheln zeigen zwar schön wo die reisen hingehen können aber es wirkt halt immer zusammengepuzzelt. Und bei der ui muss es stimmig sein! Das HTML SDK ist zwar nett und ich sehe es absolut als sonderlösung. Wie @da8ter schon sagt, das variablen Änderungen immer zum flackern führen ist halt ein alpha zustand und nicht ernstzunehmend eine dauerlösung.
Es gibt halt soviele Baustellen in der (allmählich nicht mehr neuen) Visu.
Auch wenn es nicht unsere aktuelle Baustelle ist, wir sind bei den Darstellungen dran und erweitern diese weiterhin regelmäßig. Darüber hinaus haben wir vor längerer Zeit auf einem Event mal einen Ausblick gegeben, welcher weiterhin gültig ist. Zum einen möchten wir zusätzlich zum HTML-SDK ein Formular-SDK anbieten. Das funktioniert dann potentiell ähnlich wie die form.json bei Modulen. Hier kann dann die Kachel mit verschiedenen vorgefertigten Elementen definiert werden. Das coole daran ist ein einheitlicher Look, da diese Elemente natürlich super ins Design passen, und ein Performancegewinn, da wir HTML loswerden. Das soll aber nur eine Ergänzung sein. Für die volle Freiheit soll das HTML-SDK weiterhin nutzbar sein.
Außerdem sollen Darstellungen unabhängig vom direkten Modul definierbar werden. Ähnlich wie Aktionen, welche eine Bibliothek ja unabhängig von den Modulen anbieten kann, sollen also auch Darstellungen möglich werden (sowohl für HTML als auch Formular). Hier werden dann Bedingungen definiert, wann diese Darstellung angeboten wird.
Das ist aber alles noch Zukunftsmusik. Aktuell sind wir an anderen Baustellen dran. Das wird umfangreich. Rechnet also nicht zeitnah damit
Rechnet also nicht zeitnah damit => wie muss man das verstehen?
Noch 2026
im ersten Halbjahr 2027
im zweiten Halbjahr 2027
Deine Antwort ist für meine weitere Planung wichtig.
Lieber ausgereift später als schnell mal “verzettelt”. Der Supergau wäre ein Update was alles bestehende über Nacht unbrauchbar macht. Von meiner Seite aus vollstes Verständnis. Zustände wie bei Windows-Updates braucht man nicht.
