ElabNET Technik Forum

Hallo zusammen,

da die VISU im großen Teil in Browsern oder als PWA angezeigt wird habe ich mir überlegt, dass es eventuell hilfreich wäre, wenn man ein customizable hidden Widget hätte in dem man CSS und/oder JS eintragen kann. Toll wäre noch wenn man auswählen könnte, ob es auf der aktuellen Seite oder global "angezeigt" werden soll.

So kann man relativ leicht (sofern man js und css beherrscht) z.b. Hintergrundfarbe anpassen oder Widgetgrößen optimieren, bzw. Schriften etwas angleichen, sofern nötig.

Das würde euch ein bisschen Druck aus dem Kessel nehmen direkt soviele Widgets zu designen und würde den "Cracks" deutlich mehr Spielraum beim Design bieten.

Mir ist klar, dass es wieder nur einen "kleinen" Teil der Leute ansprechen würde, aber sind wir mal ehrlich, kein "normaler" Mensch baut sich mit dem Timberwolf eine Visu, das sind alles "Verrückte" bzw. Enthusiasten, die Spaß am Tüfteln und Ausprobieren haben.

Als Systemintegrator würde ich mir ein solches Widget wünschen um schneller und effizienter auf Kundenwünsche einzugehen.

Hi Sebastian,

wir wollen die VISU sobald als möglich als APP bereitstellen. Ob dann solche Einflussmöglichkeiten durch "Kundencode" überhaupt noch funktionieren ist fraglich, weil durch die App-Stores streng reglementiert ist, was nachgeladen werden darf.

Grundsätzlich sehen wir "ladbaren Code" innerhalb des Timberwolf Servers als kritisch für die Stabilität. Es gibt Marktteilnehmer, da sind die Server so limitiert ausgestattet, dass man für vieles Plugins - also lauffähigen Code - nachladen muss. Das knirscht dann aber auch bei einem Firmware-Update.

Diesen Nachteil der limitierten Vorhersage über die Stabilität nach Firmwareupdate durch zig fremde Module wollen wir für den Timberwolf Server nicht.

Wir haben auf der Liste stehen, dass man Bilder hochladen kann und die Farbe des Hintergrund frei bestimmen kann, vielleicht schaffen wir auch die Auswahl aus weiteren Schriftarten.

lg

STefan

Hallo Sebastian,

bitte füge deinem Post noch die Versionnummer der aktuell auf dem TWS installierten Software hinzu, siehe Forenregeln.

Danke

Beste Grüße
Jens

Eine solche freie Designfreiheit gibt es bei KaufServern nur im Gira HS und den denke ich mal muss man sich nicht unbedingt als Vorbild nehmen, außer das er auch gut viele Jahre ein Fach läuft und tut.

Aber eben auch keine wirklichen Funktions und Softwareupdates bekommt.

Alle anderen Systeme die das so zulassen sind OpenSource Systeme und das agilste ist HA, aber da darf man nicht überrascht sein das die halbe Visu mit jedem dritten vierten Update anzupassen ist weil sich Inkompatibilitäten zum Kernsystem ergeben. Die Beispielliste ist da sehr lang.

Und am Ende hoffe ich mal das es nicht mehr nur die Freaks und Nerds sind die nen TWS im Haus haben werden.

Ich bin froh ne Visum aus einem klar definierten Elementbaukasten zusammenbasteln zu können. Alles andere würde mich auch wieder abschrecken, weil viel zu komplex.

Aber ja für Konner des ganzen wäre es ein tolles Spielzeug.

Ich Frage mich nur was Dir da selbst gebaute Widgets bringen sollen? Als reines Grafik overlay über die bestehenden Widgets fehlen dann ja Reaktionen auf die Interaktion und Werte.

Wenn dann müsste man ja alle fertigen Widgets für solch einen Editormodus der Grafikelemente freigeben die Definitionen der Funktionseigenschaften und Ankerpunkte in den Dispatcher freizugeben würde wohl wirklich im absoluten Chaos enden. Das wäre dann eine komplett freie Visu.

Für die Individualisierung der Hintergründe ist ja noch was in der Pipeline.

Edit:

ich sehe grade: im V4.8 IP1 wurde das offensichtlich bereits gefixt, und die widgets sind jetz bei 1.0x tatsächlich schon zu klein für das Display, mit 1.4x sind sie genau passend. - Damit ist mein Praxisbeispiel natürlich nur für die Release Version relevant.

Aktuelles Praxisbeispiel:

Wenn ich bei meiner VISU den Zoom auf 1.0x stelle, sind die Widgets in 2er Reihen minimal zu groß für das Iphone 16 Pro Display. Ich muss es also auf 0.9xZoom stellen, nur dann sind sie etwas zu klein und es werden ein paar Pixel rechts und links verstellt. (Vielleicht ist es auch nur ein Konfigurationsfehler, aber wahrlich etwas ärgerlich).

Mit einem CSS Widget könnte man einfach serverseitig ein CSS defineren, welches die Widgetbreiten korrekt anpasst und anzeigt. Ausserdem könnte man sie dynamisch via media queries an den viewport anpassen, so dass sie z.b. die volle breite einnehmen und nicht fix sind. Nachgeladen werden muss dabei nichts, wenn man das CSS automatisch beim rendern in den <head> einträgt. Es soll ja keine Datei verwendet werden sondern inline css / js.

So ein bisschen wie im Dashboard von node-red.

Stelle ich dafür das Layout auf "responsiv" ist die Anordnung der Widgets nicht mehr so wie ich sie haben will sondern so wie ich sie ursprünglich angelegt habe. Lustigerweise passt dann auch die Widgetgröße auf dem Telefon.





Das sind nur Kleinigkeiten und vermutlich einfach auch derzeit Bugs, nur würde ich sie selbst schnell fixen können.

Ich bin da zu wenig Programmierer um das zu verstehen.

Wie willst Du mit genau einem CSS-Widget all das abbilden was die Visu nun schon als Funktionswidgets bietet?

Wenn dann muss man doch alle Widgets (inkl. der Detailansichten) mit und ohne einer solchen Konfigurations-Option anbieten.
Also den ganzen Katalog an Widgets duplizieren.

Oder sehe ich da was falsch?

Mal davon abgesehen wie sollte dann so ein UI aussehen, um diese abweichenden Werte zu erfassen / konfigurieren?

CSS ist nicht dafür da irgendwelche Widgets zu bauen, es geht darum ein "Widget" zu haben welches nur CSS/JS auf die aktuelle seite Oder eben global injeziert.
das ganze würde dann so aussehen im browser (als BEISPIEL):
dieser block darf ÜBERALL auf der seite stehen und gilt dann generell für die gesamte seite. Darüber kann dann jemand der sich damit auskennt die bestehende Elemente designtechnisch überarbeiten oder z.b. auch hintergründe anpassen.
Analog dazu via JS:
auch hier kann man via auf der seite injiziertem JS das bestehende design anpassen oder neue funktionalitäten ergänzen. je nach verwendetem framework könnte man vermutlich auch via event system daten abfragen/bekommen, aber das ist sekundär.

Technisch würde das widget so umgesetzt werden müssen, dass der Codeblock 1:1 an der stelle in das html gerendert wird, an der das widget im backend angelegt wurde. das widget selbst ist dabei unsichtbar und verändert auch nicht das bestehende kachel design.

Hierbei ist jedoch zu sagen, dass timberwolf dann natürlich dem User vertrauen muss, keinen Unsinn in das Widget zu schreiben, darüber kann man sehr schnell die gesamte VISU zerschießen. Aber jeder der CSS/JS schonmal verwendet hat (z.b. im Wordpress kontext) kennt das.

Sicherheitstechnisch ist es natürlich auch etwas kritischer, aber am ende ist ja die VISU für einen selber und nicht für ausserhalb des lokalen Netzwerkes gedacht, dementsprechend ist natürlich auch die Sinnhaftigkeit von malicious code in der eigenen VISU nicht gegeben. (Selbstverständlich gibt es hier Außnahmen, z.b. indem man für andere VISUs baut und dort dann schadcode hinterlegt, ob man dann natürlich noch weiterempfohlen oder beschäftigt wird steht dann natürlich auf einem anderen Blatt)

Hi Sebastian,

chtonian hat geschrieben: ↑Fr Okt 31, 2025 2:12 pmHierbei ist jedoch zu sagen, dass timberwolf dann natürlich dem User vertrauen muss, keinen Unsinn in das Widget zu schreiben, darüber kann man sehr schnell die gesamte VISU zerschießen. Aber jeder der CSS/JS schonmal verwendet hat (z.b. im Wordpress kontext) kennt das.

womit wir beim Hauptproblem mit ausführbarem Code sind: Dem Aufwand für Support und Entwicklung.

Zwei Beispiele

Beim WireGate Server damals hatten wir einen für jedermann freischaltbaren Rootzugriff eingebaut. Man musste anklicken, dass man für die Folgen selbst verantwortlich ist. In der Folge kam es dann zu vielen Problemen mit verkonfigurierten Servern und hohem Supportaufwand. Viele konnten sich dann nicht mehr erinnern, dass Sie mit dem Klick auch die Verantwortung für die installation hatten (der Mensch vergisst durchaus solche "Klick-Vereinbarungen", vor allem wenn diese schon Monate / Jahre zurückliegen). Wir hatten dann mehr Aufwand für Diskussionen als für die Reparatur. Zwei Kunden haben uns sogar erpresst, dass wenn wir das nicht kostenlos reparieren, würden wir schlechte Bewertungen auf Google bekommen.

Nach diesen Erfahrungen war klar, das wollen wir nie mehr wieder, weil solche Freiheiten werden am Ende gegen uns ausgelegt

Beim Timberwolf Server hatten wir den "Code" für Custom Logiken eigentlich nur für uns intern geschaffen, also für die Entwickler. Auf mehrfachen Wunsch der Kundschaft hatten wir dann das freigegeben, dass dies von allen genutzt werden kann. Nur war das nicht gut darauf ausgelegt, es fehlte an Doku, der Editor hatte zu große Freihheitsgrade. Am Ende mussten wir mit großem Aufwand diese, eigentlich für Spezialisten gedachte Möglichkeit, entsprechend endkundentauglich machen. Zuletzt, weil viele die KI haben Code schreiben lassen, den sie gar nicht verstanden haben und dann bei Fehlern um Support nachgesucht hatten, entsprechend mussten wir den Editor tunen, damit es detaillierte Fehlermeldungen mit Deep-Links gibt.

Bitte nicht falsch verstehen, ich will mich nicht beklagen, es ist nur die Erfahrung, dass es mit Freischaltungen für selbst geschriebenen Code nicht getan ist, sondern letztlich wir dann auch dafür sorgen müssen, damit mögliche Folgen eingegrenzt werden, weil das die allgemeine Erwartungshaltung an Software ist, dass man nichts mehr falsch machen kann.

Bei einem solchen CSS-"Widget" kann man aber sehr viel falsch machen. Ich sehe nicht, wie wir den Support dafür leisten können und wie eine ausreichende Absicherung erfolgen könnte.

Wir wollen zudem keinesfalls, dass damit jemand eine komplett verrückte VISU baut und dann Screenshots davon im Internet kursieren.

Ich verstehe Deinen Wunsch, aber ich bitte auch zu verstehen, das dies aus Herstellersicht schwierig ist. Wir werden das bei einem der nächsten Entwicklermeetings kurz besprechen, allerdings gibt es auch andere Themen, die für einen sehr viel größeren Nutzerkreis wichtig sind.

lg

Stefan

chtonian hat geschrieben: ↑Fr Okt 31, 2025 2:12 pm es geht darum ein "Widget" zu haben welches nur CSS/JS auf die aktuelle seite Oder eben global injeziert.

Mit dem Wort injezieren >> injizieren war für mich eigentlich direkt klar das man so etwas nicht in den TWS einbauen sollte und warum es keine kommerziellen-Server gibt die das so anbieten.

Und nein man gewinnt damit auch keinen Preis es als erster Server anzubieten.

Extreme Designfreaks gehen auf opensource Anwendungen.

In ein paar Jahren und der TWS ist auf dem Weg das globale Synonym für Smarthome-Server statt des Gira-HS zu sein, dann kann und sollte man darüber nachdenken auch eine ganz freie Designversion der Visu anzubieten.

Ich bin immer wieder erstaunt wie fragil Browser-Software ist.

Nur meine persönliche Meinung, aber ich vermute auch, dass sich nur wenige der TWS User mit CCS oder JS auskennen. Deshalb halte ich persönlich ein solches Widget für nicht nötig. Ich, und ich denke auch viele andere, wünschen sich dann eher andere Widgets oder Funktionen.