Um ein Feedback zu erhalten wäre es schön, wenn jeder, der das MDCSS v2 nutzt, den 1.Beitrag des Themas positiv bewertet (Pfeil nach oben oder unten ). Ich kann dann auch abschätzen, ob sich die weitere Pflege lohnt. Thx!

Da das Ursprungsthema MD CSS v1 mit über 600 Antworten schon recht voll ist, starte ich hier zur Version 2 ein neues Thema.

Beim Material Design CSS v2 handelt es sich nicht um einen Adapter mit eigenen Widgets, stattdessen erhalten die Standard-Widgets basic und jqui nur "neue Kleider" und erweiterte Funktionen. Heißt, sie stellen sich im Material Design Style dar.

Bilder sagen mehr, also:

Einen Demo-Film gibt es hier: Video (MP4-Datei, ca. 64 MB, dort downloaden)

Ein Demo-Projekt für den Import in ioBroker.vis hier: MD_Demo

Ein Simple-Projekt als Basis für eigene Projekte hier: MD_Simple

Das Handbuch wir noch von der v1 auf v2 überarbeitet.

Das GitHub-Projekt gibt es hier GitHub.

Links zu weiteren Beiträgen/Vorlagen hier im Forum zum MD CSS v2:

• Forenthemensuche nach "MDCSS v2"
• [Vorlage] MDCSS v2: ioBroker Log in vis anzeigen
• [Vorlage] MDCSS v2: ping-Adapter in vis anzeigen
• [Vorlage] MDCSS v2: tr-064/devices-Adapter in vis anzeigen
• [Vorlage] MDCSS v2: Homatic-Log in vis anzeigen
• [Vorlage] MDCSS v2: ical Kalendar in vis anzeigen
• [Vorlage] MDCSS v2: Adapter-Instanzen in vis anzeigen
• [Vorlage] MDCSS v2: Backitup Log in vis anzeigen

Hinweis: Dieses Projekt hat nichts mit den tollen Material Design Widgets von @Scrounger zu tun. Dabei handelt es sich um einen eigenen vis-Adapter, beim Material Design CSS nur um CSS und Skriptanweisungen, welche direkt im Projekt verwendet werden.

Um ein Feedback zu erhalten wäre es schön, wenn jeder, der diese Vorlagen nutzt, den 1.Beitrag des Themas positiv bewertet (Pfeil nach oben oder unten ). Ich kann dann auch abschätzen, ob sich die weitere Pflege lohnt. Thx!

Dieses Script überwacht den ical-Adapter und erzeugt bei Änderungen an dessen States HTML-List States für die Anzeige als
Kalender in Listform mit

• Tagesauflösung von "von/bis"-Terminen, inkl. Berücksichtigung der Uhrzeiten
• Tagesdatum, Kalendarfarben aus ical oder optional aus dem Script
• Termintext und -ort
• optionalem Icon je Kalendar
• optionalem "ignore", wenn ein Kalendar unberücksichtigt bleiben soll

Es werden States für n-Logs erzeugt, jedem, Log kann ein Standardfilter mitgegeben werden. In jedem Log-Ordner
befindet sich ein list-HTML State, welcher direkt in der vis angezeigt werden kann (jeweils im basic-string (unescaped) Widget).
Über optionale Filter als string (Bsp:':Abfall:') oder als RegExp (Bsp:'/Feiertag|Geburtstag/') kann festgelegt werden,
welche Einträge beim Aufbau der list-HTML States berücksichtigt werden.
Bsp.:
log0 Filter: "abfall" oder ":Abfall:" (=Kalendarname) -> Zeigt nur Abfalltermine
log0 Filter: "ferien" oder ":Ferien:" (=Kalendarname) -> Zeigt nur Ferientermine

Datei-Download: MduiShowIcal

Installation

Einfach als serverseitiges Script installieren und starten-5 Sek warten-stoppen-starten. Beim 1.Start werden
die notwendigen States unter STATE_PATH = '0_userdata.0.mdui.showIcal.' erzeugt. Erst beim 2.Start
instanziiert das Script die Event-Handler und läuft dann.

Konfiguration

Eigentlich ist keine notwendig.
Optional in der Funktion MduiShowIcal|doInit() eine Anpassung der KONFIGURATION vornehmen
Optional Anpassung der tmpList.

States

Unter dem STATE_PATH werden die folgenden States erzeugt:
version : Script-Version, wird verwendet um Script-Updates zu erkennen
updatePressed : auf true setzen, wenn ein table/list update außerhalb des Intervals erfolgen soll

Weiterhin werden MAX_LOG_FOLDER Unterordner im STATE_PATH erzeugt (N=0-9):

• LogN.table : enthält die table-HTML für ein basic-string (unescaped) Widget
• LogN.list : enthält die list-HTML für ein basic-string (unescaped) Widget
• LogN.count : Anzahl der Log-Zeilen (wenn das Log mit '/:error:|:warn:/' gefiltert ist, dann ist es die Anzahl der Fehler/Warnungen)
• LogN.filter : Filter, der auch die logCache angewendet wurde im .table/.list zu erzeugen (siehe Filter)
• LogN.lastUpdate : Timestamp des letzten Updates

Filter

In den filter-States können sowohl strings (Bsp:'error') als auch RegExp-Strings (Bsp:'/warn|error/')
hinterlegt werden. RegExp-Strings werden an den einschließenden '/' erkannt. Über den ':' kann der Anfang
eines Feldes mit in den Filter einbezogen werden.
Beispiele:
'/Feiertag|Geburtstag/' (RegExp) zeigt alle Zeilen an, in denen 'Feiertag' oder 'Geburtstag' in irgendeinem Feld vorkommen
':Abfall:' (string) zeigt alle Zeilen an, welche derKalendar 'Abfall' lautet
'Arzt' (string) zeigt alle Zeilen an, in denen 'Arzt' in irgendeinem Feld vorkommt

Lizenz

(c) 2020 by UH, MIT License, no warranty, use on your own risc

weitere Bilder

Um ein Feedback zu erhalten wäre es schön, wenn jeder, der diese Vorlagen nutzt, den 1.Beitrag positiv bewertet (Pfeil nach oben oder unten ). Ich kann dann auch abschätzen, ob sich die weitere Pflege lohnt. Thx!

Dieses Script dient der Visualisierung des ioBroker-Logs in der vis im Material Design CSS Style als
table- bzw. list-Anzeige. Dazu wird ein onLog()-Handler instanziiert, welcher bis zu MAX_LOG_CACHE
Log-Einträge zwischenspeichert und daraus dann alle BUILD_TABLE_TIMER Sekunden bis zu MAX_LOG_FOLDER
Log-Ordner erzeugt. In jedem Log-Ordner befindet sich ein table- und list-HTML State, welcher direkt in
der vis angezeigt werden kann (jeweils im basic-string (unescaped) Widget). Je Log-Ordner kann ein filter
als string (Bsp:'error') oder als RegExp (Bsp:'/warn|error/') festgelegt werden, welcher beim Aufbau der
table-/list-HTML States berücksichtigt wird. Weiterhin können über clearPressed die table-/list-States
gelöscht werden, beim nächsten Build werden sie dann nur solche Log-Eintäge berücksichtigen, die später hinzu kamen.

Danke an @Mic für seinen Beitrag Vorlage JS Log, dort habe ich einige Ideen abgegriffen.

Wichtig! Der Javascript-Adapter muss mindestens Version 4.3.0 haben, da onLog() erst ab dann verfügbar ist.

Installation

Einfach als serverseitiges Script installieren und starten-5 Sek warten-stoppen-starten. Beim 1.Start werden
die notwendigen States unter STATE_PATH = '0_userdata.0.mdui.logIOBroker.' erzeugt. Erst beim 2.Start
instanziiert das Script die Event-Handler und läuft dann.

Konfiguration

Optional im constructor die const anpassen, wie z.B. die IGNORE_LIST
Optional Anpassung der tmpTable und tmpList.
Bei Anpassung der tmpTable und tmpList auch ohne MD CSS Style nutzbar.

States

Unter dem STATE_PATH werden die folgenden States erzeugt:
version : Script-Version, wird verwendet um Script-Updates zu erkennen
logCache : Cache der Log-Einträge als JSON
logCount : Anzahl der Log-Einträge in logCache
updatePressed : auf true setzen, wenn ein table/list update außerhalb des Intervals erfolgen soll

Weiterhin werden MAX_LOG_FOLDER Unterordner im STATE_PATH erzeugt (N=0-9):

LogN.table : enthält die table-HTML für ein basic-string (unescaped) Widget
LogN.list : enthält die list-HTML für ein basic-string (unescaped) Widget
LogN.count : Anzahl der Log-Zeilen
LogN.filter : Filter, der auch die logCache angewendet wurde im .table/.list zu erzeugen (siehe Filter)
LogN.lastUpdate : Timestamp des letzten Updates
LogN.lastClear : Timestamp des letzten manuellen "clearPressed", d.h. anschließend werden nur
noch neuere Einträge aus der logCache berücksichtigt
LogN.clearPressed: auf true setzen, um die .table/.list zu löschen

Filter

In den filter-States können sowohl strings (Bsp:'error') als auch RegExp-Strings (Bsp:'/warn|error/')
hinterlegt werden. RegExp-Strings werden an den einschließenden '/' erkannt. Über den ':' kann der Anfang
eines Feldes mit in den Filter einbezogen werden.
Beispiele:
'error' (string) zeigt alle Zeilen an, in denen 'error' in irgendeinem Feld vorkommt
':error:' (string) zeigt alle Zeilen an, welche den Typ 'error' besitzen (dito für: error, warn, info, silly, debug)
'/error|warn/' (RegExp) zeigt alle Zeilen an, in denen 'error' oder 'warn' in irgendeinem Feld vorkommen
'/:error:|:warn:/' (RegExp) zeigt alle Zeilen an, welche dem Typ 'error' oder 'warn' entsprechen
'tr-064' (string) zeigt alle Zeilen an, in denen 'tr-064' in irgendeinem Feld vorkommt
':tr-064' (string) zeigt alle Zeilen an, in welchen ein Feld mit 'tr-064' beginnt, z.B. als Adapterfilter

Beschreibung (Github)
Datei-Download (Github)

Um ein Feedback zu erhalten wäre es schön, wenn jeder, der diese Vorlagen nutzt, den 1.Beitrag des Themas positiv bewertet (Pfeil nach oben oder unten ). Ich kann dann auch abschätzen, ob sich die weitere Pflege lohnt. Thx!

Dieses Script dient der Visualisierung des Logs des BackitUp-Adapters in der vis im Material Design CSS Style als table- bzw. list-Anzeige. In jedem Log-Ordner

• befindet sich ein table- und list-HTML State, welcher direkt in der vis angezeigt werden kann (jeweils im basic-string (unescaped) Widget).
• kann ein filter als string (Bsp:':hasupdate:') oder als RegExp (Bsp:'/warn|error/') festgelegt werden, welcher beim Aufbau der table-/list-HTML States berücksichtigt wird.
• kann die Sortierreihenfolge festgelegt werden, in der table-Ansicht auch via Klick auf die Header

Datei-Download: MduiLogBackitup

Voraussetzungen

Nutzung der MDCSS v2.x (siehe: https://forum.iobroker.net/topic/30363/projekt-mdcss-v2-material-design-css-version-2), für die Sortierdarstellung im Header MDCSS v2.5

Installation

Einfach als serverseitiges Script installieren und starten. Beim 1.Start werden die notwendigen States
unter STATE_PATH = '0_userdata.0.mdui.logIOBroker.' erzeugt und es findet automatisch ein erneuter Start nach 10 Sek statt. Erst nach diesem 2.Start instanziiert das Script die Event-Handler und läuft dann.

Konfiguration

Eigentlich ist keine notwendig.
Optional in der Funktion MduiLogBackitup.doInit() eine Anpassung der KONFIGURATION vornehmen, zB wenn eine andere backitup Instanz überwacht werden soll (Vorgabe: backitup.0.history.json). Optional Anpassung der tmpTable und tmpList.

Dokumentation

https://github.com/Uhula/ioBroker-Material-Design-Style/wiki/3.7-MduiLogBackitUp

States

Unter dem STATE_PATH werden die folgenden States erzeugt:
version : Script-Version, wird verwendet um Script-Updates zu erkennen
updatePressed : auf true setzen, wenn ein table/list update außerhalb des Intervals erfolgen soll

Weiterhin werden MAX_LOG_FOLDER Unterordner im STATE_PATH erzeugt (N=0-9):

• LogN.table : enthält die table-HTML für ein basic-string (unescaped) Widget
• LogN.list : enthält die list-HTML für ein basic-string (unescaped) Widget
• LogN.count : Anzahl der Log-Zeilen (wenn das Log mit '/:error:|:warn:/' gefiltert ist, dann ist es die Anzahl der Fehler/Warnungen)
• LogN.filter : Filter, der auch die logCache angewendet wurde im .table/.list zu erzeugen (siehe Filter)
• LogN.lastUpdate : Timestamp des letzten Updates
• LogN.sortBy : Sortierung nach welchem Feld
• LogN.sortAscending: true=aufsteigend sortieren

Filter

In den filter-States können sowohl strings (Bsp:'error') als auch RegExp-Strings (Bsp:'/warn|error/')
hinterlegt werden. RegExp-Strings werden an den einschließenden '/' erkannt. Über den ':' kann der Anfang eines Feldes mit in den Filter einbezogen werden.
Beispiele:
'/error|warn/' (RegExp) zeigt alle Zeilen an, in denen 'error' oder 'warn' in irgendeinem Feld vorkommen
'/:error:|:warn:/' (RegExp) zeigt alle Zeilen an, welche dem Typ 'error' oder 'warn' entsprechen
'rssi' (string) zeigt alle Zeilen an, in denen 'rssi' in irgendeinem Feld vorkommt
':rssi:' (string) zeigt alle Zeilen an, in welchen ein Feld den Inhalt 'rssi' hat

Lizenz

(c) 2020 by UH, MIT License, no warranty, use on your own risc

Changelog

2020.05.01 UH

• Geburt

Um ein Feedback zu erhalten wäre es schön, wenn jeder, der diese Vorlagen nutzt, den 1.Beitrag des Themas positiv bewertet (Pfeil nach oben oder unten ). Ich kann dann auch abschätzen, ob sich die weitere Pflege lohnt. Thx!

Dieses Script dient der Visualisierung der TR-064/devices in der vis im Material Design CSS Style als
table- bzw. list-Anzeige. Dazu wird ein onChange()-Handler instanziiert, welcher alle active-States
aller TR-064/devices überwacht und bei Änderungen die list/table-HTML neu aufbaut. Diese können direkt
in der vis verwendet werden (jeweils im basic-string (unescaped) Widget).
Weiterhin gibt es die Möglichkeit die Ausgabe nach den einzelnen Columns (ip, name, mac, ts, active)
zu sortieren, auf- und absteigend.

Installation

Einfach als serverseitiges Script installieren und starten-5 Sek warten-stoppen-starten. Beim 1.Start werden
die notwendigen States unter STATE_PATH = '0_userdata.0.mdui.logTR064Devices.' erzeugt. Erst beim 2.Start
instanziiert das Script die Event-Handler und läuft dann.

Konfiguration

Optional im MduiLogTR064.doInit() die const anpassen.
Optional Anpassung der tmpTable und tmpList (z.B. fpr eigene Icons & Colors)
Bei Anpassung der tmpTable und tmpList auch ohne MD CSS Style nutzbar.

States

Unter dem STATE_PATH werden die folgenden States erzeugt:

• version : Script-Version, wird verwendet um Script-Updates zu erkennen
• table : enthält die table-HTML für ein basic-string (unescaped) Widget
• list : enthält die list-HTML für ein basic-string (unescaped) Widget
• count : Anzahl der Log-Zeilen
• countUnreached : Anzahl der Log-Zeilen, welche den Zustand FALSE haben
• lastUpdate : Timestamp des letzten Updates
• sortBy : Name des Feldes/Column, nach der sortiert werden soll (ip, name, mac, ts, active)
• sortAscending : true -> aufsteigend sortieren, sonst absteigend

Beschreibung (Github)
Datei-Download (Github)

Um ein Feedback zu erhalten wäre es schön, wenn jeder, der diese Vorlagen nutzt, den 1.Beitrag des Themas positiv bewertet (Pfeil nach oben oder unten ). Ich kann dann auch abschätzen, ob sich die weitere Pflege lohnt. Thx!

Vorweg: Dank an diejenigen, die hier schon eine Visualisierung der HM-States realisiert haben. Dort habe ich einige Ideen abgegriffen und mit einem neuen Script und erweiterten Funktionen passend ins MDCSS übertragen.

Dieses Script dient der Visualisierung des Zustände der Homematic-Komponenten in der vis im Material Design CSS Style als table- bzw. list-Anzeige. Die HM-States werden nicht aktiv mit on-Handler überwacht, sondern es findet im Intervall BUILD_SCHEDULER eine Aktualiserung der bis zu MAX_LOG_FOLDER Log-Ordner statt.
In jeder log-Zeile werden bis zu zwei Balken (bargraphs) dargestellt wenn es sich z.B. um RSSI, VOLT o.ä. Daten handelt.
Der Aufbau der table/list HTML arbeitet intensiv mit flex-Optionen um bei jeder Darstellungsbreite eine optimale Anzeige zu erstellen. In jedem Log-Ordner

• befindet sich ein table- und list-HTML State, welcher direkt in der vis angezeigt werden kann (jeweils im basic-string (unescaped) Widget).
• kann ein filter als string (Bsp:':rssi:') oder als RegExp (Bsp:'/warn|error/') festgelegt werden, welcher beim Aufbau der table-/list-HTML States berücksichtigt wird.
• kann die Sortierreihenfolge festgelgt werden.

Datei-Download: Download

Installation

Einfach als serverseitiges Script installieren und starten-5 Sek warten-stoppen-starten. Beim 1.Start werden
die notwendigen States unter STATE_PATH = '0_userdata.0.mdui.logHMDevices.' erzeugt. Erst beim 2.Start
instanziiert das Script die Event-Handler und läuft dann.

Konfiguration

Eigentlich ist keine notwendig.
Optional in der Funktion MduiLogHMDevices|doInit() eine Anpassung der KONFIGURATION vornehmen
Optional Anpassung der tmpTable und tmpList.
Bei Anpassung der tmpTable und tmpList auch ohne MD CSS Style nutzbar.

Dokumentation

Beispiel vis-view beschrieben in:

States

Unter dem STATE_PATH werden die folgenden States erzeugt:
version : Script-Version, wird verwendet um Script-Updates zu erkennen
updatePressed : auf true setzen, wenn ein table/list update außerhalb des Intervals erfolgen soll

Weiterhin werden MAX_LOG_FOLDER Unterordner im STATE_PATH erzeugt (N=0-9):

• LogN.table : enthält die table-HTML für ein basic-string (unescaped) Widget
• LogN.list : enthält die list-HTML für ein basic-string (unescaped) Widget
• LogN.count : Anzahl der Log-Zeilen (wenn das Log mit '/:error:|:warn:/' gefiltert ist, dann ist es die Anzahl der Fehler/Warnungen)
• LogN.filter : Filter, der auch die logCache angewendet wurde im .table/.list zu erzeugen (siehe Filter)
• LogN.lastUpdate : Timestamp des letzten Updates
• LogN.sortBy : Sortierung nach welchem Feld
• LogN.sortAscending: true=aufsteigend sortieren

Filter

In den filter-States können sowohl strings (Bsp:'error') als auch RegExp-Strings (Bsp:'/warn|error/')
hinterlegt werden. RegExp-Strings werden an den einschließenden '/' erkannt. Über den ':' kann der Anfang
eines Feldes mit in den Filter einbezogen werden.
Beispiele:
'/error|warn/' (RegExp) zeigt alle Zeilen an, in denen 'error' oder 'warn' in irgendeinem Feld vorkommen
'/:error:|:warn:/' (RegExp) zeigt alle Zeilen an, welche dem Typ 'error' oder 'warn' entsprechen
'rssi' (string) zeigt alle Zeilen an, in denen 'rssi' in irgendeinem Feld vorkommt
':rssi:' (string) zeigt alle Zeilen an, in welchen ein Feld den Inhalt 'rssi' hat

Lizenz

(c) 2020 by UH, MIT License, no warranty, use on your own risc

Beschreibung (Github)
Datei-Download (Github)

Weitere Bilder

Vorab-Info:
Ich habe das Material Design CSS/Script bei mir etwas erweitert, es kann nun auch "Chips" darstellen (Alternative zu Radio-Buttons). Wenn ich es auf Github aktualisiert habe, gibt es einen Hinweis hier im Forum.

V2.5 30.04.2020

CSS

• mdui-table erweitert, so dass dort in der Kopfzeile Sortiersymbolesymbole angezeigt werden können (wird in einigen Mdui-Templates verwendet). In <th> wird ein "onclick" interpretiert und führt beim mouseover zu einem highlighting
• mdui-sortable: Kann in <th> gesetzt werden, zeigt an, dass hiernach sortiert werden Kann
• mdui-sort-ascending: Kann in <th> gesetzt werden, zeigt aufsteigende Sortierung an
• mdui-sort-descending: Kann in <th> gesetzt werden, zeigt absteigende Sortierung an
• CSS Klassen aufgenommen um die jqui-ctrl-Input Datetime Widgets im MD Style darstellen zu können, inkl dark/light-Theme Unterstützung
• mdui-swipe-left?..., mdui-swipe-right?..., mdui-swipe-up?..., mdui-swipe-down?...: Kann gesetzt werden um Widgets mit swipe-Möglichkeiten zu versehen. ZB um in durch das swipen eines ListItems nach links dieses zu löschen. Beim Swipe wird temporär ein DOM-Element für die Anzeige des Icons/Farbe erzeugt, nach erfolgreichem Swipe wird eine vis-Action ausgeführt. Näheres in der Dokumentation. Bsp: mdui-swipe-left?dist:48;background:red;icon:delete;text:Löschen;action:setValue(0_userdata.0.mdui.mystate,my_value)
• mdui-show-touch: Anzeige zur Laufzeit, wenn es sich um ein Touch-Gerät handelt
• mdui-show-notouch: Anzeige zur Laufzeit, wenn es sich um ein No-Touch-Gerät handelt
• mdui-hide-touch: Keine Anzeige zur Laufzeit, wenn es sich um ein Touch-Gerät handelt
• mdui-hide-notouch: Keine zur Laufzeit, wenn es sich um ein No-Touch-Gerät handelt
• mdui-tooltip?...: Hierüber kann dem Widget ein Tooltip-Text zugewiesen werden, welcher beim MouseEnter nach 700 ms unterhalb des Widgets für 1.5 Sek angezeigt wird, keine Funktion auf Touch-Geräten. Der Text sollte keine Sonderzeichen enthalten, Leerzeichen sind als + zu setzen. Die Angabe eines Hintergrundes ist optional. Bsp: mdui-tooltip?text:Mein+Tootip+für+das+Widget mdui-tooltip?text:Mein+Tootip+für+das+Widget;background:red
• mdui-click?...: Kann gesetzt werden um bei einem click-Ereignis auf einem Widget eine vis-Action ausführen zu lassen. Z.B. auf listitems. Dieses ist der direkten Zuweisung von onclick() vorzuziehen, da es sonst bei zeitgleichem mdui-swipe zu Problemen kommt da das onclick() Ereignis auch beim swipe ausgeführt wird. Näheres in der Dokumentation. Bsp: mdui-click?action:changeView(pageStart)
• mdui-list mdui-list-striped: muss nun als "mdui-list mdui-striped" angegeben werden
• mdui-list: hat per Vorgabe keinen Border und keine Item-Trennlinien mehr, wenn gewünscht, "mdui-list mdui-bordered" bzw. "mdui-list mdui-divided" angeben
• mdui-table-striped: muss nun als "mdui-table mdui-striped" angegeben werden
• mdui-table-bordered: muss nun als "mdui-table mdui-divided" angegeben werden
• mdui-vis-info: kann einem basic HTML-Widget zugewiesen werden und zeigt zur Laufzeit eine Tabelle mit Informationen zur vis an

vis-Editor

• Schriftgröße der Attribut-Eingabe um 10% verkleinert, kann über die CSS Variable --design-fontsize (siehe Konfiguration) gesetzt werden
• die MDCSS Version wird neben "Eigenschaften" angezeigt - bewegt man den Mauszeiger darüber, wird eine kleine mdui-Klassenübersicht angezeigt

script

• ui-datepicker wird beim Page-Wechsel behanldet um eine Anpassung an der dark/Light-Theme vornehmen zu können
• Eventhandler für TouchStart, ...Move und ...End für die Auswertung der mdui-swipe-xxx hinzugefügt
• Eventhandler für MouseDown, ...Move und ...Up für die Auswertung der mdui-swipe-xxx hinzugefügt. Damit wird auch auf No-Touch-Geräten ein swipe (mit der Maus) möglich
• Eventhandler für MouseEnter/-Leave für die Anzeige der Tooltips mdui.tooltip hinzugefügt
• Eventhandler für click() mdui-click hinzugefügt

MD_Demo

• Beispiele für die Swipe-Anwendung hinzugefügt
• Beispiele für Tooltip hinzugefügt
• Statt der Verwendung der temporären States in der Form "demo_(variable)" wird nun "0_userdata.0.mdui.vis.(variable)" verwendet. Damit ist es leicht möglich aus den temporären States persistente zu machen. Dazu müssen unter "0_userdata.0.mdui.vis" lediglich die States als Datenpunkte (string) manuell angelegt werden (geht leider nicht via Runtime-Script). Bsp: "demo_content_color" -> "0_userdata.0.mdui.vis.content_color"

MD_Simple

• Erweiterung um die Konfigurationsdialoge

Die Dokumentation wurde angepasst, insbesondere für Klick, Swipe und Tooltip.

Tooltip

Swipe

DateTime

VIS Info

Hinweis: Die mdui-Templates (Infos, Listen) habe ich noch nicht angepasst, das passiert in den nächsten Tagen. Sie funktionieren aber weiterhin.

Material Design CSS V2.0

Its done ! (fast, Doku usw. fehlt noch)

Wer gerne reinschauen möchte, was mit dem Material Design CSS V2.0 so geht, der kann sich dieses als MP4-Film (ca. 1 min, 63 MByte) ansehen, oder sich das neue Demo-Projekt als ZIP herunter laden. Beim Import muss dieses als MD_Demo benannt werden, da sich in der CSS Datei eine Pfadangabe für den Icon-Font darauf bezieht, wählt man einen anderen Projekt-Namen, muss der Pfad in der CSS angepasst werden.

Und wer dann noch Freude dran hat, kann sich weiter unten die Änderungen durchlesen ... es hat sich sehr viel verändert. Zwar ist das Prinzip mit card/aber/lnav/content usw. erhalten geblieben, trotzdem müssen in eigenen Projekten deutliche Anpassungen an den Widgets vorgenommen werden. Mag sich aber für den einen oder anderen lohnen.

MD_Demo V2 als MP4 Film (Download, 1:08 min, 62 MByte)

MD_Demo V2 Projekt (als MD_Demo aufnehmen)

Wenn ich alles fertig habe, erstelle ein neues Thema und verlinke dort alles rein.

Änderungen V2.0

Stimmt, bin im Moment nicht aktiv im Forum, dafür aber umso aktiver beim Erstellen der Material Design for ioBroker 2.0 CSS Styles - dann natürlich inkl. der Chips.

• Basis ist dann ein helles Design, das dunkle ist dann optional, auch jederzeit umschaltbar (wenn denn eigene Komponenten das auch mitmachen, die mdui- können es)
• optionales Setzen der Farben für abar, tnav, lnav, rnav, bnav und content, inkl. automatischer Anpassung der Schriftfarbe (wenn Kontrast zu "schwarz" zu gering, dann "weiß") über mdui-config Elemente
• die linke Navigation (lnav) kann als feste Site-Navigation arbeiten (optional ab x-Pixel Breite des Screens). Also auf dem Smartphone weiterhin als modale, sich öffnende Nav, auf dem Tablett dann als feste Nav, aber auch wegblendbar
• Unterstützung des material-icons Fonts - d.h. images braucht man eigentlich nicht mehr. Vorteile: Sehr gute Skalierung und automatische Anpassung an die Schriftfarbe
• alle material design Farben werden nun namentlich unterstützt
• Anpassung der MD_Demo und MD_Simple Projekte
• Anpassung der Dokumentation
• ...

Dauert alles noch etwas, schaut aber schon gut aus, eben wie 2019 und nicht mehr wie 2017. Screenshots liefere ich mal nach.

Schöne Adventszeit noch!

@Issi Super, funktioniert. Habe mein Script schon deaktiviert. Mal sehen, ob der Wallpanel-App Programmierer noch weitere Optionen einbaut. Insbesondere das temporäre Einschalten der Kamera wäre gut - denn wenn man die dauerhaft aktiviert lässt, geht es nicht ohne feste Stromversorgung.

Danke dir!

Anbei ein kleines Script um die browse_results des HEOS Adapters in einer Liste darstellen zu können. Im folgenden Beispiel ist es im modalen Dialog zu sehen (die am Anfang zu sehenden Cards usw. gehören nicht dazu, die entstammen dem MDCSS). Das Script benötigt keine weiteren ui's sondern erzeugt reines HTML/CSS. Viel Freude - und danke an @withstu für seinen Adapter.

HEOS Media-Browser-Script

Der HEOS Adapter (https://github.com/withstu/ioBroker.heos) erlaubt neben der Steuerung der HEOS Geräte auch das
Navigieren durch die Musikquellen. Allerdings muss hierzu noch ein serverseitiges Script laufen, welches die
Navigationsergebnisse in eine HTML Darstellung überträgt, so dass diese in einem basic-string(unescaped)-Widget
darstellbar und bedienbar werden.

Genau macht dieses Script.

Installation

• HEOS-Adapter installieren und starten (https://github.com/withstu/ioBroker.heos)
• HTML-State "0_userdata.0.heos.browse_result_html" als Zeichenkette anlegen (alternativ eigener State, dann in der Konfiguration anpassen)
• dieses Script im Admin unter Skripte als neues Script hinzufügen.
• dieses Script starten
• in der ioBroker-vis ein basic-string(unescaped)-Widget in einem View einfügen, den HTML-State zuweisen
• View ausführen

(c) Uhula, MIT License, no warranty, use on your own risc

Script: heos_browse.js

@withstu Danke für die Rück-Änderungen.

Das mit den Playern werde ich bei mir anders lösen. Ich werde neben dem 0_userdata.heos.browse_result_html-State noch ein 0_userdata.heos.browse_result_player führen und mir dort via vis die PIDs der Player eintragen, welche die play-Befehle erhalten sollen. Im Script patch ich dann den command-Befehl und sorge dafür, dass die play-Befehle dann nur in die command-States der Player und nicht in den globalen command-State geschrieben werden.

Das hat auch den Vorteil, dass man die Browse-View nur einmal haben muss und vorher beim jqui-container-HTML-View vor dem Öffnen des Browser-Views noch automatisch die korrekten PIDs setzen kann. Müsste funktionieren, teste ich morgen mal.

Hier ein Beispiel:

@sveni_lee Und genau deswegen ist es die Sache des Servers (Quelle) die Daten zu sortieren, nicht die des Clients - denn der kennt nur einen Ausschnitt. Wenn du deine Daten z.B. auf einer NAS liegen hast, dann wird dort ein Mediaserver laufen. Dort müsstest du die Standard-Sortierung einstellen können.

@withstu Ich benutze nun auch deinen Adapter (v1.3.4) statt des Scripts. Funktioniert prima, danke für deinen Entwicklungsaufwand!

Aus Neugier habe ich auch die neue Browse-Funktionalität getestet - auch diese funktioniert grundsätzlich prima. Drei Anmerkungen habe ich aber dazu:

• Sortierung: Ich halte es für unglücklich die Ergebnislisten nach dem Namen zu sortieren, das ist Sache der Quelle. Sonst kommen wie unten dargestellt komische Ergebnisse heraus
• Available-Sourcen: Hier fragst du mit einer der letzten Änderungen den available State ab und liefert nur solche zurück, die true besitzen. Der state hat aber nicht immer den korrekten Wert. Bei mir ist z.B. Amazon-Music als false gesetzt, obwohl ich darüber browsen kann (command manuell gefüllt)
• beim Abspielen wird immer ein player-broadcast durchgeführt. Wird hierbei der jeweilige State heos.0.players.xxx.ignore_broadcast_cmd berücksichtigt?

Hier die Sortierung der Top-Playlists von Amazon (alphabetisch korrekt, sinnhaft falsch):

Ich nutze ein eigenes Script für die Navigation, nicht table-basiert:

• die globalen Navigationsflächen kommen in eine Kopfzeile, so dass sie nicht mit wegscrollen
• Kopfzeile mit Infos über Anzahl / geladene Zeilen
• nur der listview-Bereich scrollt
• nur Nutzung von Standard HTML-Symbolen, keine PNGs usw.
• reines HTML/CSS, benötigt kein weiteres vis-ui oder MDCSS-ui

Selbstverständlich werde ich das Script dann hier zur Verfügung stellen, wenn es fertig ist.

Preview:

@mrFenyx Lass mal die Character abschließenden ; weg

{v:deconz.0.sensors.00158d00045244ad.info.battery; (v<30) ? 
     "<i class='mdui-mdi'>&#xF12A1</i>": 
     "<i class='mdui-mdi'>&#xF12A2</i>"}

Eigentlich ist das ; als Endzeichen Pflicht, aber die Browser sind da teilweise sehr tolerant und erkennen das Char auch so (wenn nicht gerade direkt ein anderes Zeichen 0-9,A-F folgt).

Da der Fully Kiosk Browser unter Android Go auf meinen (Billig-) Geräten (Cubot Note7 - als Simpel-Remote eingesetzt) nicht mehr funktioniert (draw over apps - Recht fehlt), habe ich nach alternativen Android Apps gesucht und bin auf die Wallpanel-App gestoßen. Diese ist völlig ausreichend für meinen Anwendungsfall. Um die MQTT Daten der App in der vis direkt verarbeiten zu können, habe ich ein Server-Script geschrieben, vielleicht hilft es auch anderen.

Bleibt gesund!

MduiUpdateWallpanelMQTT

Die Android-App "Wallpanel" bietet, ähnlich wie Fully Kiosk Browser, die Möglichkeit Web-Seiten als Vollbild darstellen
zu lassen. Weiterhin kann sie Sensorwerte des Android-Devices via MQTT Client an einen MQTT Broker übertragen. Wenn
unter iobroker der Adapter "MQTT Broker/Client" installiert und als Broker (Server) konfiguriert wurde, kann dieser die
MQTT Medlungen empfangen und speichert sie z.B. unter mqtt.0.wallpanel.<devicename> ab.
Bsp:

mqtt.0.wallpanel.<devicename>.sensor.batterie = {"value":51,"unit":"%","charging":false,"acPlugged":false,"usbPlugged":false}
mqtt.0.wallpanel.<devicename>.sensor.light = {"value":80,"unit":"lx","id":"EPL_SENSOR ALS\/PS EPL_SENSOR"}

Diese Daten kann man in derForm in der vis nicht direkt weiter verwenden, sondern die JSON Angaben müssen erst in
eigene States überführt werden. Diesen Zweck erfüllt dieses Script. Es erzeugt aus dem obigen Beispiel die Struktur/States:

0_userdata.0.mdui.wallpanel.<devicename>.sensor.batterie.value = 51
0_userdata.0.mdui.wallpanel.<devicename>.sensor.batterie.unit = "%"
0_userdata.0.mdui.wallpanel.<devicename>.sensor.batterie.charging = false
0_userdata.0.mdui.wallpanel.<devicename>.sensor.batterie.acPlugged = false
usw.

Diese können in der vis direkt verwendet werden.
Weiterhin richtet es einen subscriber auf die MQTT States ein und hält die selbst erzeugten States aktuell.

Voraussetzungen

(a) Android Device mit installierter App "Wallpanel" und dort konfiguriertem MQTT Client.
(b) Installierter Adapter "MQTT Broker/Client" in IOBroker

Installation

Einfach als serverseitiges Script installieren und starten. Beim 1.Start werden die notwendigen States
erzeugt und es findet automatisch ein erneuter Start nach 10 Sek statt. Erst nach diesem 2.Start instanziiert das Script
die Event-Handler und läuft dann.

Konfiguration

Eigentlich ist keine notwendig.
Optional im Absatz KONFIGURATION vornehmen

Tipps zur Wallpanel-App

• Zum Steuern der Wallpanel-App: iobroker Adapter "Wallpanel" (https://forum.iobroker.net/topic/36438/test-adapter-wallpanel/10)
• "Camera on" nur, wenn das Android Device eine Stromversorgung hat
• die "Bildschirm-Ausschaltzeit" kann nicht kürzer als die unter Android eingestellte sein; also die auch verringern;
  wirkt sich auch auf "screenOff" aus

Lizenz

(c) 2020 by UH, MIT License, no warranty, use on your own risc

Changelog

2020.09.26 UH

• Geburt

/*
*** MduiUpdateWallpanelMQTT
Die Android-App "Wallpanel" bietet, ähnlich wie Fully Kiosk Browser, die Möglichkeit Web-Seiten als Vollbild darstellen
zu lassen. Weiterhin kann sie Sensorwerte des Android-Devices via MQTT Client an einen MQTT Broker übertragen. Wenn
unter iobroker der Adapter "MQTT Broker/Client" installiert und als Broker (Server) konfiguriert wurde, kann dieser die
MQTT Medlungen empfangen und speichert sie z.B. unter mqtt.0.wallpanel.<devicename> ab.
Bsp: 
mqtt.0.wallpanel.<devicename>.sensor.batterie = {"value":51,"unit":"%","charging":false,"acPlugged":false,"usbPlugged":false}
mqtt.0.wallpanel.<devicename>.sensor.light = {"value":80,"unit":"lx","id":"EPL_SENSOR ALS\/PS EPL_SENSOR"}
.
Diese Daten kann man in derForm in der vis nicht direkt weiter verwenden, sondern die JSON Angaben müssen erst in
eigene States überführt werden. Diesen Zweck erfüllt dieses Script. Es erzeugt aus dem obigen Beispiel die Struktur/States:
.
0_userdata.0.mdui.wallpanel.<devicename>.sensor.batterie.value = 51
0_userdata.0.mdui.wallpanel.<devicename>.sensor.batterie.unit = "%"
0_userdata.0.mdui.wallpanel.<devicename>.sensor.batterie.charging = false
0_userdata.0.mdui.wallpanel.<devicename>.sensor.batterie.acPlugged = false
usw.
.
Diese können in der vis direkt verwendet werden.
Weiterhin richtet es einen subscriber auf die MQTT States ein und hält die selbst erzeugten States aktuell.
.
.
**** Voraussetzungen
(a) Android Device mit installierter App "Wallpanel" und dort konfiguriertem MQTT Client.
(b) Installierter Adapter "MQTT Broker/Client" in IOBroker 
.
**** Installation
Einfach als serverseitiges Script installieren und starten. Beim 1.Start werden die notwendigen States 
erzeugt und es findet automatisch ein erneuter Start nach 10 Sek statt. Erst nach diesem 2.Start instanziiert das Script 
die Event-Handler und läuft dann.
.
**** Konfiguration
Eigentlich ist keine notwendig.
Optional im Absatz KONFIGURATION vornehmen
.
**** Tipps zur Wallpanel-App
* Zum Steuern der Wallpanel-App: iobroker Adapter "Wallpanel" (https://forum.iobroker.net/topic/36438/test-adapter-wallpanel/10)
* "Camera on" nur, wenn das Android Device eine Stromversorgung hat
* die "Bildschirm-Ausschaltzeit" kann nicht kürzer als die unter Android eingestellte sein; also die auch verringern;
  wirkt sich auch auf "screenOff" aus
*   
.
.
**** Lizenz
(c) 2020 by UH, MIT License, no warranty, use on your own risc
.
*** Changelog
2020.09.26 UH 
* Geburt
*/

// ------------------------------------------------------------------------------------- 
// KONFIGURATION
// ------------------------------------------------------------------------------------- 
// state-Pfad unter dem die States angelegt werden sollen
const CONFIG_STATE_PATH   = '0_userdata.0.mdui.wallpanel'; 
// zu überwachender MQTT Pfad
const CONFIG_MQTT_PATH    = 'mqtt.0.wallpanel';


// ------------------------------------------------------------------------------------- 
// MduiBase
// ------------------------------------------------------------------------------------- 

class MduiBase {

constructor() {
  this.init();
}

//
init() {
    // const
    this.DEBUG      = false;
    this.VERSION    = '1.0/2020-01-01';
    this.NAME       = 'mduiBase';
    this.STATE_PATH = '0_userdata.0.mdui.base.';
    this.STATE_UNKNOWN    =  0;
    this.STATE_INSTALLING = 10;
    this.STATE_INSTALLED  = 11;
    this.STATE_STARTING   = 20;
    this.STATE_STARTED    = 21;
    this.STATE_STOPPING   = 30;
    this.STATE_STOPPED    = 31;

    // var
    this.installed = false;
    this.states = [];
    this.state = this.STATE_UNKNOWN;
    this.subscribers = [];
    this.schedulers = [];

    this.doInit();

    // init der states
    this.states.push( { id:'version',     common:{name:'installed script-version', write:false, def:this.VERSION} } );
}

//
// start the script/class
//
start() {
    // beim 1.Start nur die States erzeugen
    if ( !this.existsState("version") || (this.getState('version').val!=this.VERSION) ) {
        for (let s=0; s<this.states.length; s++) { this.createState( this.states[s].id ); }
        this.logWarn('first script start, creating states for version '+this.VERSION+', automatic restarting script again in 10 sec ...');
        setStateDelayed(this.STATE_PATH + 'version', this.VERSION, 3000);
        setTimeout( this.start.bind(this), 10000 );
        this.state = this.STATE_INSTALLED; 
        return;
    }
    switch (this.state) {
        case this.STATE_UNKNOWN : ;
        case this.STATE_INSTALLING : ;
        case this.STATE_INSTALLED : ;
        case this.STATE_STOPPED : {
            this.state = this.STATE_STARTING; 
            if (this.doStart()) {
                this.log('script started');
                this.state = this.STATE_STARTED;
            }
            break;    
        }
        case this.STATE_STARTING : ;
        case this.STATE_STARTED : {
            this.logWarn('script already starting/started');
            break;    
        }
        case this.STATE_STOPPING : {
            this.logWarn('script is stopping, pls start later again');
            break;    
        }
  
    } 
}

//
// stop the script/class
//
stop() {
    switch (this.state) {
        case this.STATE_STARTED : {
            this.state = this.STATE_STOPPING; 
            if (this.doStop()) {
                for (let i=0; i<this.subscribers.length; i++) if (this.subscribers[i] !== undefined) unsubscribe( this.subscribers[i] );
                this.subscribers = [];
                for (let i=0; i<this.schedulers.length; i++) if (this.schedulers[i] !== undefined) clearSchedule( this.schedulers[i] );
                this.schedulers = [];
                this.state = this.STATE_STOPPED; 
                this.log('script stopped');
            }
            break;    
        }
        default : {
            this.log('cant stopp script, because not startet');
        }
    } 
}

// --------------------- virtual functions, overwrite it 

doInit() { return true; }
doStart() { return true; }
doStop() { return true; }

// --------------------- helper functions 

logDebug(msg,func='') { if (this.DEBUG) console.log(`[${this.NAME}.${func}] ${msg}`); }
log(msg,func='') { console.log(`[${this.NAME}.${func}] ${msg}`); }
logWarn(msg,func='') { console.warn(`[${this.NAME}.${func}] ${msg}`); }
logError(msg,func='') { console.error(`[${this.NAME}.${func}] ${msg}`); }

// einen on-Handler registrieren
subscribe( handler ) {
    this.subscribers.push( handler );
}

// einen timer registrieren
schedule( handler ) {
    this.schedulers.push( handler );
}

// über den $-Operator nachsehen, ob der state bereits vorhanden ist
// getState().notExists geht auch, erzeugt aber Warnmeldungen!
existsState(id) {
    return existsState(this.STATE_PATH + id);
//    return ( $(this.STATE_PATH+id).length==0?false:true);
}

// wrapper, adds statepath to state-ID
getState(id) {
    return getState(this.STATE_PATH + id);
}

// like setState(), but adds statepath to state_ID and checks if state exists, when not, creates it
setState(id,value) {
    if ( !this.existsState(id) ) this.createState(id,value,undefined);
    else setState( this.STATE_PATH + id, value);
}

// like cresteState(), but adds statepath to state_ID and checks if state exists, when not, creates it
createState(id,value,common) {
    if ( !this.existsState(id) ) {

        if (common===undefined) {
            // id im states-Array suchen
            for (var i=0; i<this.states.length; i++) { 
                if (this.states[i].id==id) {
                    if (this.states[i].hasOwnProperty('common'))
                        common = this.states[i].common;
                   break;
                }   
            }
        }
        if ( (typeof value === 'undefined') && (typeof common !== 'undefined') && (common.hasOwnProperty('def'))) value = common.def;
        // unter "0_userdata.0"
        let obj = {};
        obj.type = 'state';
        obj.native = {};
        obj.common = common;
        setObject(this.STATE_PATH + id, obj, (err) => {
                if (err) {
                    this.log(`cant write object for state "${this.STATE_PATH}${id}": ${err}`);
                } else { 
                    this.log(`state "${this.STATE_PATH}${id}" created`);
                }
        });

        setTimeout( setState, 3000, this.STATE_PATH + id, value );
    }
}


// true, if str contains filter string or regexp 
fitsFilter(str, filter) {
    if ( (filter===undefined) || !filter || (filter=='') )
        return true;
    if ( filter instanceof RegExp )  {
        if (str.match( filter ) != null) return true;
    } else if (typeof filter == 'string') {
        if(str.includes(filter)) return true;
    }
    return false;        
}

//
escapeRegExp(str) {
    return str.replace(/[.*+?^${}()|[]\]/g, '\\$&'); 
}

}

// ------------------------------------------------------------------------------------- 
// MduiUpdateWallpanelMQTT
// ------------------------------------------------------------------------------------- 

class MduiUpdateWallpanelMQTT extends MduiBase {

constructor() {
    super();
}

// init
doInit() {
  super.doInit();

  // const
  this.DEBUG = false;
  this.VERSION = '1.0/2020-09-26';
  this.NAME = 'mduiUpdateWallpanelMQTT';
  this.STATE_PATH      = CONFIG_STATE_PATH; 
  this.MQTT_PATH       = CONFIG_MQTT_PATH;
  if (this.STATE_PATH.slice(-1)!='.') this.STATE_PATH += '.';
  if (this.MQTT_PATH.slice(-1)!='.') this.MQTT_PATH += '.';
  return true;  
}

// start the script/class
doStart() {
    super.doStart();
    
    // subscriber erzeugen
    this.subscribe( on( new RegExp( `${this.MQTT_PATH}*` ), obj => { this.onChangeMQTT(obj.id) } ));

    this.initMQTT();
    return true;
}

// stop the script/class
doStop() {
    super.doStop();
    return true;
}

onChangeMQTT( id ) {
//    this.log(id,'onChangeMQTT');
    if (id.indexOf(".command")!=-1) return;

    if ( existsState(id) ) {
        let state = getState(id);
        let o = JSON.parse(state.val);
        for (var prop in o) {
            let name = id.slice(this.MQTT_PATH.length,1000);
            name += '.' + prop;
//            this.log(`${name} = ${o[prop]}`,'onChangeMQTT');

            if (this.existsState(name) )
              this.setState(name,o[prop]);
            else this.createState(name, o[prop]); 
        }
    }
}

initMQTT() {
    $(`channel[state.id=${this.MQTT_PATH}*]`).each( (id, i) => {
//        this.log(id,'initMQTT');
        this.onChangeMQTT( id );
    });
}

}


// create instance and start
var mduiUpdateWallpanelMQTT = new MduiUpdateWallpanelMQTT( );
mduiUpdateWallpanelMQTT.start();

// on script stop, stop instance too
onStop(function () { 
    mduiUpdateWallpanelMQTT.stop(); 
}, 1000 );

@Issi Ich habe mit die Wallpanel-App nun auch als Ersatz für Fully Kiosk installiert, da dieser mittlerweile soviel Rechte benötigt, dass er unter Android Go nicht mehr korrekt läuft - und eigentlich für den Einsatz in der HomeAuto auch zu mächtig ist.

Dein Adapter gefällt mit deswegen gut. Zwei Anregungen dazu.

(1)
Ein einziges Mal hat der Adapter bisher etwas unerwartetes gemacht: er hat 110 neue States, durchnummeriert von 0 bis 115 erzeugt, jeweils mit einem ein-Zeichen Wert. Senkrecht gelesen ergibt das einen HTTP Header.

Bilder dazu

![1c623304-a602-49c4-9460-f5c6787fdba9-image.png] (/assets/uploads/files/1601049244177-1c623304-a602-49c4-9460-f5c6787fdba9-image.png)

(2)
Wenn du den Adapter noch deutlich aufwerten möchtest, dann wäre eine Verknüpfung zum MQTT Adapter sinnvoll - und auch leicht umsetzbar. Der MQTT Adapter hat eigene iobroker-States, in denen er die vom Wallpanel gesendeten Daten in JSON Form ablegt. Eigentlich müsstest du in deinem Adapter je Panel nur eine Konfig-Eingabe hinzufügen um die iobroker-States überwachen zu können. ALso keine direkte MQTT Verbindung, sondern nur ein iobroker Zugriff auf die States. Man muss die MQTT States ohnehin noch interpretieren, wenn man sie in der vis verwenden will.
Bei Änderungen an den States, dann selbst die entsprechenden States anlegen und die Werte übernehmen. Ich mache das im Moment via Script.

States, die der MQTT-Adapter (Server) erzeugt:

Und hier die States, die du erzeugen könntest:

// start the script/class
doStart() {
    super.doStart();
    
    // subscriber erzeugen
    this.subscribe( on( new RegExp( 'mqtt.0.wallpanel.*' ), obj => { this.onChangeMQTT(obj.id) } ));

    this.initMQTT();
    return true;
}

// stop the script/class
doStop() {
    super.doStop();
    return true;
}

onChangeMQTT( id ) {
    this.log(`onChangeMQTT: ${id}`);
    if (id.indexOf(".command")!=-1) return;

    if ( existsState(id) ) {
        let state = getState(id);
        let o = JSON.parse(state.val);
        for (var prop in o) {
            let name = id.slice(17,1000);
            name += '.' + prop;
            this.log(`onChangeMQTT: ${name} = ${o[prop]} `);

            if (this.existState(name) )
              this.setState(name,o[prop]);
            else this.createObject(name, o[prop]); 
        }
    }
}

initMQTT() {
    $('channel[state.id=mqtt.0.wallpanel.*]').each( (id, i) => {
        this.log(`initMQTT ${id}`);
        this.onChangeMQTT( id );
    });
}

@chrissi1 Handelt es sich um eine INSTAR oder eines der Derivate (das /tmpfs/snap.jpg weist daraufhin)? Wenn ja, dann erlaubt das API die Übergabe von Benutzer/Kennwort auch in der Form

http://IP-Address:Port/tmpfs/snap.jpg?usr=admin&pwd=instar

das umgeht die @-Browserbeschränkungen.

Siehe auch: https://wiki.instar.de/1080p_Serie_CGI_Befehle/

Both ways to authenticate are valid - e.g. for user = admin and password = instar:

http://admin:instar@IP/CGI-COMMAND
http://IP/CGI-COMMAND?usr=admin&pwd=instar

@sveni_lee Mag sein, wenn denn das API das her gibt. Trotzdem bleibt immer noch der Aufwand dieses dann zu visualisieren. Manchmal sind die nativen Apps doch besser geeignet als nachgebaute Eigenentwürfe. Ich nutze das HEOS Script nur für die grundsätzliche Steuerung (für meine Frau). NDR2, Playlist Johannes Oerding, ... Lautstärke. Alles andere findet dann in der HEOS App bzw. in der Spotify App statt.