Anmerkungen/Fragen zum SDK für Kacheln

IP-Symcon
1

Ich finde es super, dass ihr euch dem Thema nun angenommen habt und eine Möglichkeit schafft, eigene schicke Kacheln zu entwerfen.

Sehr schöne Beispiele für Kacheln hat ja @da8ter bereits geschaffen.

Beim ersten Rumspielen mit den beiden Testbeispielen sind aber für mich noch einige Fragen zum weiteren Vorgehen aufgetaucht, die ich einmal hier stellen möchte.

Dazu nehme ich mal das Beispiel HTMLVisuTestHeatingPump.

Wenn ich eine Instanz erstelle und die Kachel einbinde, dann präsentiert sie sich wie erwartet:

image
image1261×959 108 KB

Schalte ich in die Listenansicht um, erhalte ich die Variablen in der gewohnten Darstellung:

image
image1274×977 44.9 KB

So weit, so gut.

Aber wie gehe ich nun damit um?

  • ich möchte natürlich meine eigenen Werte hier anzeigen lassen. Wenn ich es mit der Kachel Media Player vergleiche, dann würde ich erwarten, dass ich meine realen Variablen unter die Instanz verlinke.
    Ist das hier auch so vorgesehen? Das wäre konsequent.
    Das Beispiel lässt jedoch vermuten, dass man die Variablenwerte über Ereignisse und Automatismen füllen muss. Aber das ist meines Erachtens keine Option, da viel zu aufwendig für den Anwender.

  • momentan sind alle Werte schaltbar (z.B. Compressor Power). Wie kann ich das beeinflussen? Oder muss der Modulentwickler dafür eine Option anbieten?

  • was mache ich mit den Werten, die mein System nicht kennt (z.B. Lüfterdrehzahl)?

  • wie passe ich die Objektnamen und Profile an?

  • wie kann ich mir Archivwerte anzeigen lassen?

  • wie ergänze ich eigene Variablen?

Momentan wirft der Ansatz bei mir noch eine Menge Fragen auf. Und ich bin mir auch nicht sicher, ob der Modulansatz der richtige ist. Denn er setzt eine gehörige Portion Wissen bei dem jeweiligen Entwickler voraus. Er muss sowohl über Modulentwicklungs Know How als auch über HTML und JavaScript Wissen verfügen. Das ist schon heftig :slight_smile:

Es ist eine Menge Arbeit, um nur einen einzigen Kacheltyp neu zu entwerfen.

2

Sehe ich im großen und ganzen ähnlich. Auf der anderen Seite ist das hier eine erste Demo die zeigt wo wo es lang gehen kann. Klar, so kann das Modul nicht produktiv eingesetzt werden. Ohne Konfig-Möglichkeit für den User gehts halt nicht. Da gehört später auf jeden Fall ein ordentliches Formular ins Modul wo man die entsprechenden Daten mit seinen vorhandenen Variablen verknüpfen kann. Nicht benötigte Anzeigen müssen deaktivierbar sein und am Ende kann es natürlich auch nicht schaden wenn das Aussehen (Farben, Schriftgrößen etc.) einstellbar sind. Skalieren ist ja nicht ganz so trivial wie wir alle wissen…

Das Thema „gehörige Portion Wissen“ ist natürlich ein Punkt, ich hab z.B. noch nie ein Modul programmiert. Da muss ich mich erst mal ordentlich einarbeiten… Ausgang ungewiss. Wenns nach mir geht würde ich sofort alle meine HTML Boxen als Modul umsetzen. Ob ich das jemals schaffe? Auf der anderen Seite gibts hier aber auch genug Vollprofis von denen sicher der ein oder andere das umsetzen würde. Übernimmt halt einer den Designpart und der andere das Coden. Und ob ein Modul am Ende wirklich komplizierter ist als mein Chaos Spaghetti Code bezweifle ich etwas :wink: Da gehts schon deutlich strukturierter zu und die ganze Datenabfrage und Werteaktualisierungen ist auch erheblich einfacher gelöst…

Ich bin gespant wo das am Ende hinführt… Sehe da ziemlich viel Potenzial.

@paresy Hab es mir jetzt noch nicht im Detail angesehen. Sind wir hier platztechnisch genau so beschränkt wie die „normalen“ HTMLBoxen? Also immer weißer Rand drum rum und eine Headline? Oder kann ich hier schon die gesamte Kachel gestallten?

Viele Grüße
Stephan

3

So würde ich mir das auch vorstellen können, aber dann stände die heutige Listenansicht ohne Daten da :slight_smile: Und an meine Archivwerte komme ich dann auch nicht.
Von daher wäre es vielleicht besser, auch hier mit Links wie beim Media Player zu arbeiten. Dann wäre es einheitlich.

Ja, das ginge sicherlich. Aber ich frage mich, was denn da alles gecoded werden muss. Es scheint mir auf der einen Seite recht viel zu sein (Variablenauswahl, Attribute, Position, Verhalten etc.) und auf der anderen Seite dann doch vermutlich immer gleich. Dieser immer gleiche Teil sollte dann anders formuliert werden können.

4

Am Ende darf das der Entwickler machen wie er will. Für unser Beispiel haben wir einfach nur Variablen erstellt, damit man dies besser sehen/testen kann. Am Ende wäre diese Kachel besser, wie es @da8ter schon korrekt vermutet hat → Ein Konfigurationsformular in der man alle Variablen verknüpfen kann (und die Kachel hat am Ende gar keine Variablen) und je nachdem welche Variablen man verknüpft wird in der Kachel mehr oder weniger angezeigt. Das ist zumindest unsere Idee. Vielleicht sollten wir das Modul noch einmal überarbeiten und die Variablen über eine „virtuelle Wärmepumpe“ bereitstellen, um das Konzept besser zu verdeutlichen.

Ich denke, dass dies eigentlich alle Fragen beantwortet und zeigt auf, dass unser Beispiel noch nicht ganz optimal war :slight_smile:

Der Modulansatz ist wichtig, da wir dadurch das ganze Sicherheitsthema sauber abbilden können. Der Modulentwickler sendet Werte (die er haben will) und empfängt in RequestAction nur Befehle, die er auch verarbeiten will. Klar kann man damit Sicherheitslöcher bauen - aber wesentlich schwieriger. Und es lädt auch nicht wirklich dazu ein.

Da ist etwas dran. Und ja, am Ende muss man sich ein wenig mit RegisterProperty, den Formularen und RegisterMessge/MessageSink beschäftigen. Sobald wir aber eine kritische Masse an Kacheln erreichen, wird es unserer Meinung nach viel Copy&Paste im Backend und die Arbeit wird dann im Design liegen.

Auf jeden Fall ist einiges an Arbeit drin. Das meiste aber in der Kombination wie eine Kachel aussehen soll, wenn nicht alle Variablen im Formular gesetzt werden. Ansonsten ist es ein schicke Werte zur Kachel (HTML) und sende RequestAction an die verknüpfte Variable.

paresy

Aktuell ja, aber intern ist es bereits vorgesehen, dass ihr definitiv die ganze Kachel nutzen könnt. Evtl. wird auch die Headline ausblendbar in einer der späteren Iterationen. Wir wollten uns jetzt erstmal um die Basics kümmern und das Kachel-SDK mal an den Start bringen, damit ihr wisst, wie wir uns dies vorstellen :slight_smile:

Dem Modul (=Kachel) Entwickler steht frei die Variable zu verlinken unterhalb der Instanz. Auch könnten wir uns im Kachel-SDK vorstellen, dass man per Befehl direkt einen Graphen für eine Variable öffnet.

Das meinte ich mit Copy&Paste. Man muss die Properties definieren. Man muss das Formular erstellen und man muss den Klebstoff für RegisterMessage/MessageSink/RequestAction erstellen. Das ist immer die selbe Fleißarbeit - aber kann nicht reduziert werden, da die Anzahl und Namen je nach Kachel spezifisch sein werden. Im Backend (module.php) sehe ich aber langfristig wenig schwere Magie.

Der große Vorteil von dem PHP-Modul Ansatz sind:

  • Normale Module können Kacheln direkt mitbringen
  • Kacheln (wie die für die Wärmepumpe) können direkt über den Module Store angeboten werden
  • Alles war mit Update zu tun hat läuft den bekannte, geordneten Weg über den Module Store

paresy

5

Das wäre super, da es dann klarer wird, wohin die Reise gehen soll.

1 „Gefällt mir“
6

Vielleicht habe ich es überlesen, oder noch nicht verstanden, aber aktuell ist das immer die maximierte Darstellung einer Kachel?
Was ist mit der nicht maximierten Darstellung? Kann die auch beeinflusst werden?

Und können vorhanden Elemente, wie ein z.b. für einen VideoStream oder eine Playlist genutzt und erweitert werden?
Michael

7

Aktuell ist es immer die kleine Darstellung. Die maximierte Darstellung ist die Liste der Variablen unterhalb der Instanz.

Aktuell ist dies nicht möglich. Ich denke auch nicht, dass wir dies kurzfristig realisieren können in diesem Rahmen. Für die Zukunft wollen wir noch ein weiteres Kachel-SDK anbieten, welches näher an unseren PHP-Modul Formularen ist (und nativ gerendert wird ohne HTML-Boxen für eine bessere Performance) aber das ist noch weiter weg. Und die HTML Boxen liefern aktuell sehr viele Freiheiten.

paresy

8

Okay, dann bringt es mir aktuell nix für einige Module.
Idee war eine overlay PTZ Steuerung für einen Stream. Was ja…

… dadurch wieder der alte Streams wären (HTML Video Tag) und somit die neue WebRTC Streams torpediert.

Und jetzt extra z.b. andere Farbauswahl Elemente zu bauen möchte ich auch ungern; hoffe da kommen noch ein paar von euch :slight_smile:
Michael

9

Du könntest ja eine Kachel für PTZ bauen. Der Stream kann ja in der Kachel daneben sein.

paresy

10

Jein… Dann maximiert man die Kachel vom Stream und die Steuerung ist weg. Ich meinte wirklich overlay, so dass ich rechts in Bild klick und es wird nach rechts geschwenkt, oder noch besser:
Mausklick definiert den Nullpunkt und bei gedrückte Taste wird die Maus oder Wischbewegung als Richtung und Geschwindigkeit ausgewertet.
Michael
Edit: Okay, meine zig HTML Tabellen könnte ich damit jetzt viel besser umsetzen, dank Rückkanal und Pushen von Werten.

11

Ich würde die Listenansicht eigentlich erst mal leer lassen. Da kann doch dann jeder links unterhalb der Kachel Instanz einfügen mit den Inhalten die er haben möchte. Nicht alle Werte aus der Kachel müssen in der Listenansicht angezeigt werden. Dafür aber, wie du sagst, vielleicht ein oder zwei Diagramme, Heizkurven, Zeitpläne etc. Das alles über das Modul konfigurierbar machen ist ja unnötiger Aufwand. Im Prinzip müsste man beim vergrößern der Kachel eine normale Kachelseite bekommen die ganz normal eingerichtet werden werde kann.

Gruß
Stephan

12

Das ist was ich meine: eine Menge Arbeit. Neben dem Kopieren wird die meiste Arbeit sein, die Variablenzuordnungen zu prüfen und zu organisieren, die notwendig sind.

Auch aus Anwendersicht ist der jetzige Ansatz mühsam und ganz anders als es im Standard ist. Von der Visu ist er es gewohnt, dass die Darstellungsart automatisch erkannt wird. Er muss sich nur darum kümmern, dass die Voraussetzungen für eine Darstellungsart erfüllt sind. Die Voraussetzungen sind ja hier alle beschrieben :ok_hand:

Am Beispiel Mediaplayer:

image
image1393×942 57.9 KB

…

Kurz: er muss sich um die passenden Variablen kümmern und sie verlinken. Die Erkennung und Darstellung passiert im „Backend“ automatisch. Also nehme ich an, dass es bereits eine Art Regelwerk gibt, die für die Erkennung des Kacheltyps sorgt.

In der Richtung könnte man doch weiterdenken: einem Modul könnte es ermöglicht werden, dieses Regelwerk zu erweitern. Dann müssten im Modul die Regeln für die einzelnen Variablen definiert und die HTML Darstellung zur Verfügung gestellt werden.

Für den Anwender wäre es wie gehabt: Voraussetzungen studieren und verlinken etc.

Auch ganz simple Elemente könnte man als Modul entwickeln: eine Variable soll ein besonderes Aussehen haben? → Man kreiert das Layout und definiert die Voraussetzung (z.B. Typ Integer, mit Profil „Mein Modul.Volume“) wann eine Variable so angezeigt werden soll.

Wenn man es dann noch schafft, auch bestehende Kacheltypen als Voraussetzung zu benennen, um sie dann im Modul zu erweitern, dann wäre das ein Weg, z.B. den Mediaplayer um eine Playlist zu ergänzen.

Vielleicht habe ich meiner Phantasie zu viele Freiheiten gelassen :slight_smile:, aber ich würde mir aus Entwicklersicht einfachere Gestaltungsmöglichkeiten und aus Anwendersicht ein einheitliches Vorgehen wünschen.

2 „Gefällt mir“
13

Das mit den Profilen und dazugehörigen Aussehen nach Regelwerk wäre schön.

Äh, gibt es schon :grinning:
Mir fehlt da aber z.b. eine Baum/Ordnernavigation oder Multiselect.
Michael

14

Wie habe ich es denn geschafft, diesen Beitrag komplett zu übersehen? Aber jetzt mal:

Der aktuelle Ansatz ist, wie ihr schon erkannt habt, eine Darstellung pro Modul. So haben wir es ja auch bereits an mehreren Stellen in der Visualisierung: Energieverteilung, Energieoptimierer, Szenensteuerung, E-Mails, …

Das Anbieten allgemeingültiger Visualisierungen möchten wir auch gerne noch machen, das soll aber nicht die aktuelle Baustelle sein. Ein weiteres Zukunftsprojekt ist ein Darstellungs-SDK mit vorgefertigten Elementen, potentiell ähnlich wie die Formulardarstellung. Damit ist die Zielsetzung des HTML-SDK eine spezialisierte Ansicht, die nicht über vorgefertigte Elemente darstellbar ist, spezifisch für ein Modul.

Da es die weiteren Eckpfeiler aktuell noch nicht gibt, kann man natürlich das jetzige HTML-SDK auch weitgreifender nutzen. Via Verlinken von Variablen kann ein Darstellungs-Modul entwickelt werden oder natürlich auch allgemeingültigere Darstellungen erst einmal als HTML definiert werden.

Ich würde die nächsten Tage nochmal ein einfacheres Beispiel mit einer Variablenverlinkung bauen, das hilft vielleicht nochmal dem ein oder anderen.

Vergleiche es hier lieber mit der Energieverteilung. Hier wählst du im Konfigurationsformular die betroffenen Variablen aus. Das Modul müsste sich dann darum kümmern per MessageSink die dazugehörigen Variablenänderungen auszuwerten und an die Visualisierung schicken.

Wie gewohnt via EnableAction. Im Beispiel habe ich einfach alle schaltbar gemacht, damit man leichter damit rumspielen kann. Wenn du jetzt Variablen via Formular verlinkst und diese Aktionen haben können oder auch nicht, müsstest du das passend an deine Darstellung kommunizieren und die Darstellung anpassen.

Die Frage verstehe ich nicht ganz, daher beantworte ich mal zwei verschiedene Interpretationen:

  1. Wie kommuniziere ich der Visualisierung einen berechneten Wert, der nicht als Variable vorliegt? - Genau wie bei Variablenwerten kannst du per $this->UpdateVisualizationValue Nachrichten verschicken. Es gibt bewusst keine Vorgaben wie die Daten für $this->UpdateVisualizationValue aussehen müssen, das könnt ihr ganz an eurer Modul anpassen und komplexere Objekte ggfs. per JSON codieren.
  2. Ich habe die Variable/Information mal schon, aber nicht immer - Dann müsstest du deine Darstellung daraufhin anpassen und je nach Situation die Information darstellen oder nicht. Das würde ich sonst auch noch im neuen Beispiel zeigen

Ich vermute du meinst die entsprechenden Titel im HTML. Dafür könntest du analog zu Werten die Divs mit den Titeln mit IDs versehen und via Nachricht anpassen.

Du kannst natürlich wie alles andere auch die Logging-Werte per Nachricht verschicken. Für die Darstellung müsstest du dir aktuelle aber etwas eigenes bauen.

Weitere Variablen müssten (sofern sie dargestellt werden sollen) einmal als Variablen (oder Verlinkung/Eigenschaft/…) vorhandensein und dann in geeigneter Weise im HTML mit gehändelt werden. Man könnte Teile des HTML bei nicht-Vorhandensein unsichtbar schalten oder auch dynamische Formulare bauen, die via Javascript passend zu den Variablen generiert werden. Letzteres ist sicherlich nicht einfach, wird aber für einen hohen Grad an Flexibilität erforderlich sein.

Da war die Aussage von @paresy nicht korrekt. Das Margin ist im Standardstil direkt auf den body vom HTML gesetzt. Somit hast du die Möglichkeit diesen zu überschreiben und beispielsweise

body {
  margin: 0;
}

zu machen.

Aktuell ist die Darstellung fest für die nicht-maximierten Kacheln. Für maximierte Kacheln werden wir das sicherlich aber auch noch anbieten.

15

Das wäre sehr hilfreich. Gerne mal eine Verlinkungen, einen teil des html ausblenden und mal z.b. die Farbe im css ändern oder so… da kann man dann sicher gut drauf aufbauen.

Viele Grüße
Stephan

16

Das sind gute Ideen, die nehme ich gerne mal auf :+1:

17

Generell mal zum Thema CSS, könntet Ihr nicht das Farbschema im iFrame zur Verfügung stellen oder Abrufbar machen? Es ist einfach ein Unterschied ob man den hellen oder Dunklen Theme beackert.

Irgendwas nach dieser Art …

:root {
  --akzentfarbe: #c32e04;
  --akzentrahmen: solid
}

und man könnte dann das so nutzen

h1 {
  border: thin solid var(--akzentfarbe);
}
h1::before {
  color: var(--akzentfarbe);
  content: "Wichtig: ";
}

Nur als Beispiel!!!

1 „Gefällt mir“
18

PS: Genau wie die Schriftart halt!

1 „Gefällt mir“
19

Die Idee finde ich gut. Da passe ich das injezierte CSS gerne mal an, damit die Parameter einfach abgefragt werden können :+1:

1 „Gefällt mir“
20

Super, Danke!

Nochmal ne Frage zu dem „margin:0px;“ für body! Warum ist der eigentlich nicht standardmäßig gesetzt. Was ist der Hintergrund? Wäre doch vielleicht auch gut eh jeder das jetzt selber einbaut!?

Gruß HEiko