Nach einigem Experimentieren habe ich nun eine befriedigende Darstellung gefunden. Die Visualisierung ist im Moment für 16:9 Darstellung auf einem in der Wand eingelassenen Display optimiert,

Die Icons zeigen alle den Zustand des jeweiligen Geräts an. Bei den Storen und beim Vorhang sogar während sie sich bewegen. Zwar nur 7 Schritten und mit 3 Öffnungswinkeln, aber immer noch besser als nix.

Alle auf dem Plan angezeigten Icons sind mit der custom:button-card realisiert. Da gibt es wirklich kaum Grenzen!

Da mir die Cards für die Storensteuerung nicht gefallen (optisch und funktionell), habe ich selber etwas zusammengebastelt. Die Buttons sind ebenfalls custom:button-card Elemente die in einem Popup angezeigt werden.

Auch die Bilder der Kameras werden in Popup angezeigt und können durch anklicken in einer separaten Subview in gross angeschaut werden.

Wenn Fenster geöffnet sind, dann ist das ebenfalls ersichtlich.

Daneben gibt es für jeden Raum eine separate View mit allen Details für diesen Bereich. Ist wenig raffiniert und fast alles normale Lovelace Cards.

Auch hier gibt es bei den Storen und beim Thermostat eine Subview mit mehr Details. Die Knöpfe sind auch hier custom:button-card Elemente. Die Grafiken sind custom:apexcharts-card Elemente.

Da für jeden Thermostat, jeden Storen und einiges anderes je eine spezifische Subview existiert kommt das Ganze auf über 30 Subviews.

Hier die Subview mit den Charts für die Photovoltaik und Strombezug/ und Verbrauch (Ja, der Tag war nur grau und wir haben heute kaum etwas produziert).

Subview für nicht erreichbare Geräte. Die Liste kann auch länger sein. Vergleichbare Subviews gibt es auch mit einer Liste offener Fenster oder für Geräte bei denen die Batterie fast leer ist.

Es fehlen noch einige Dinge, aber so langsam aber sicher wird es so wie es sein soll. Mein bislang nicht lösbares Hauptproblem ist der blaue Balken am oberen Rand. Lovelace lässt hier sowohl bei der Optik (Eigene Icons wären cool), wie auch bei der Funktionalität (Wieso kann ich keine Submenus haben? ) zu wünschen übrig.

@theknut
Im Hintergrund der Deviceerkennung ist der ioBroker Type Detector aktiv. Der Detector erkennt zwar diverses Devicetypen automatisch, aber zum Teil ist es (zumindest für mich) schwer das Verhalten der Komponente nachzuvollziehen.

Bei Deiner Lampe müssten Datenpunkte gemäss folgendem Link vorhanden sein: https://github.com/ioBroker/ioBroker.type-detector/blob/master/DEVICES.md#light-switch-light (für Lampen mit Dimmer gibts eine etwas andere Definition witer oben).
Zumindest auf den ersten Blick dürfte eine der Ursachen Deines Problems die Rolle des SET Datenpunkts sein. Bei Dir ist die Rolle sensor.light, gemäss Tabelle müsste dort switch.light stehen.

Ob es ausreicht, wenn die Funktion und der Raum nur indirekt bzw. vom übergeordneten Folder übernommen werden weiss ich nicht sicher. Wenn die Korrektur der Rolle nicht hilft, ev. mal versuchen Rolle und Funktion direkt auf dem Channel Folder anzugeben.

Bei den Ordnerstrukturen für die Devices/Channels bin ich immer wieder überrascht was funktioniert and was nicht, z.B. schien es bei mir einen Unterschied zu machen ob in einem anderen Folder ein weiteres Device mit gleichem Namen (nicht ID) vorhanden war. Eine vollständige Erklärung dieser Logik habe ich bis jetzt nicht gefunden und zum analysieren des ganzen Codes war ich bislang zu faul. D.h. wenn obige Ideen nicht helfen, dann ev. mal hier ansetzen.

Last but not least, ev. mal den Devices Adapter installieren. Dort drin kann man sehen was, wie erkannt wird und welche Datenpunkte einem Device von der Erkennung zugewiesen wurden und auch ob die Zuweisung stimmt.

Hallo

Bei meinen Lovelace-Versuchen bin ich an 2 Problemen, verursacht durch meine Datenstrukturen, hängen geblieben:

• Nicht alle Daten in meinem Alias Bereich sollen nach möglichen Lovelace Entities abgesucht werden, da einiges für Lovelace unwesentlich, aber zum Teil trotzdem erkannt wird (aber mit falschem Enititytype). Die aktuelle Möglichkeit die Suche auf Alias.0. einzuschränken het daher nicht ganz ausgreicht.
• Zum Teil wurden Datenpunkte die bereits über Custom als Entity definiert sind zusätzlich auch noch bei der automatischen Erkennung ein zweites Mal als Entity mit einem anderen Namen registriert. War etwas verwirrend.

Habe darum mal den Code geforkt und ein paar Ergänzungen gemacht:

• Die aliasOnly Option habe ich durch eine Option aliasPattern ergänzt. Per Default ist aliasPattern "alias.0." (auch wenn aliasPattern leer bleibt), d.h. die Kompatibilität mit der Vorversion sollte daher gegeben sein.
• Es gibt eine neue ignoreCustomIds Option. Wenn sie aktiviert ist, dann werden die Ids von Datenpunkten die in per Custom definierten Eintities auftauchen bei der automatischen erkennung nicht berücksichtigt. Hier bin ich nicht sicher, ob ich den ganzen Suchvorgang wirklich richtig verstanden habe und die Codeänderungen wirklich in allen Fällen so schlau, wie ich es hoffe, sind.

Zumindest auf meinem Testsystem funktioniert beides wie erhofft.

Sofern die Changes von Interesse sind mache ich gelegentlich einen Pull Request, aber ich muss zuerst noch die Translations machen/anpassen (da habe ich noch nicht ganz verstanden, wie ich da am besten Vorgehe resp. ob und wie mir das Weblate System da helfen kann). Für den Moment ist der Code unter https://github.com/lizardking/ioBroker.lovelace zu finden.

Hallo

Da ich ich Forum keine Angaben gefunden habe, wie die Iphone Visu App über die normalen Iphone VPN Funktionen mit dem ioBroker verbunden werden kann, folgt hier eine kleine Anleitung wie dies mit mit der Visu App, Kurzbefehlen und Automationen realisiert werden kann.
Ich benutze ausschliesslich eine Lovelace Visualisierung und habe darum keine Versuche mit Vis usw. gemacht, aber zumindest aus logischer Sicht sollte dies keinen Unterschied machen.

1. Voraussetzungen damit die folgende Lösung umgesetzt werden kann, ist eine konfigurierte, funktionierende VPN Verbindung vom Iphone zum lokalen Netz. D.h. es muss möglich sein, mit dem VPN Switch in den Einstellungen eine VPN Verbindung aufzubauen.
   
   Die VPN Verbindung kann unter Einstellungen - Allgemein - VPN und Geräteverwaltung konfiguriert werden. Wie die VPN Konfig aussieht, hängt von der verwendenten VPN Lösung ab. Bei mir ist ein L2TP Tunnel zu einer Ubiquity USG 3P Security Appliance konfiguriert.

2. ioBroker Visu aus dem Appstore installieren: https://apps.apple.com/ch/app/iobroker-visu/id1673095774?platform=iphone
   Anschliessend Visu konfigurieren. Wesentlich sind die Einstellungen unter Lokal, Extern und Allgemein:

   • Bei Lokal wird die IP, plus Port (z.B. aus dem Webbroser kopieren) der Visualisierung und allenfalls User und PAsswort angegeben. Im unten folgenden Bild sind das die Angaben für meine Lovelace Instanz, d.h. mit anderen Visualisierungen siegt es wohl anders aus.
   • Unter Extern muss bei Zugriffsart Url ausgewählt, sowie ebenfalls IP und Port angebebven werden. WLAN SSIDs bleibt leer, Die VPN Funktiionen müssen ausgeschaltet sein, d.h. Schalter für VPN Erkennung ausschalten.
   • Bei Allgemein folgenden die Angaben zur benutzen Visualisierung. Wie diese Aussehen hängt vor der jeweiligen Visualisierungslösung ab. Bei mir hat es gereicht einfach Lovelace auszuwählen.

   Visu Config
   
   Nachdem alle Einstellungen gemacht sind, muss ganz unten auf Speichern geklickt werden.

3. Um bei Bedarf, d.h. wenn das Iphone nicht im Heimnetz ist, den VPN Tunnel auf- und später wieder abzubauen, werden 2 Kurzbefehle benötigt. Dazu die Kurzbefehl App starten und mit mit dem + (Plus) Zeichen rechts oben 2 neue Kurzbefehle für VPN verbinden und VPN trennen (die Namen können bei Bedarf auch anders lauten) anlegen.
   Die Kommandos für die Kurzbefehle sind in folgenden Grafiken ersichtlich. Mit Ausnahme des Konmmandos zum Verbinden/Trennen der Verbindung und der abschliessenden Mitteilung (kann auch weggelassen werden) sind beide Kurzbefehle identisch.
   VPN verbinden
   
   VPN trennen
   
   Nach dem Einrichten der Kurzbefehle sollten in der Kurzbefehl App die folgenden Befehle sichtbar sein.
   
   Die Kurzbefehle können direkt gestartet und so die Funktionalität geprüft werden (Wlan im Iphone ausschalten damit die VPN Verbindung aufgebaut wird).

4. Als letztes werden noch 2 Automationen, welche beim Öffnen und Schliessen der Visu App die eben definierten Kurzbefehle ausführen benötigt.
   Die Automationen werden ebenfalls in der Krubefehl App angelegt. Dazu unten in der Mitte Automation auswählen und mit dem + (Plus) ob rechts 2 Automationen wie in den folgenden Grafiken sichtbar anlegen.
   Automation zum Verbinden
   
   Autmation zum Trennen
   
   Nach dem Einrichten der Automationen sollte das wie folgt aussehen:
   

Wenn alles wie erklärt konfiguriert ist, dann wird bei Öffnen, Schliessen und auch bei Wechseln von oder zu einer anderen App automatisch die VPN Verbindung auf- und abgebaut, wenn sich das Iphone ausserhalb des lokalen Netzwerks befindet. Der Aufbau der VPN Verbindung kann etwas Zeit in Anspruch nehmen. Während dieser Zeit in in Visu nur das drehende Logo zu sehen oder wenn aus einer anderen App zu Visua zurückgewechselt wird, dann reagiert Visu nicht bis die Verbindung steht. Wenn das Wlan des Iphones ausgeschaltet wird kann dies einfach getestet werden.

Innerhalb des lokalen Netzes werden die Kurzbefehle ebenfalls ausgeführt, aber dank der Erkennung der SSID, wird keine VPN Verbindung aufgebaut. D.h. Visu startet inner kürzester Zeit (zumindest bei mir).

@mickym
Habs grad nochmal ausprobiert.

• Neuen Datenpunkt angelegt unter userdata und neuen Alias dazu angelegt.
• ID des Alias wird wie erwartet aufgelistet.
• Datenpunkt unter userdata gelöscht (per Abfalleimersymbol). Alias nicht modifiziert.
• ID des Alias wird vom Code nicht aufgelistet. Im Log gibt es keine Warnng.
• Objektdaten des Alias modifiziert (common.name um ein x ergänzt).Alias zeigt aber immer noch ins leere,
• ID des Alias wird vom Code aufgelistet.

Etwas merkwürdig

@xbit
Ja, die Anpassung funktioniert für den ganzen Objektbaum. Sowohl die igonoreCustomIds, wir auch die aliasOnly Geschichte.

Die Namen für die Optionen sind teilweise etwas irreführend (kann ja in den Translations anders angeschrieben werden), aber zumindest aliasOnly wollte ich beibehalten um die Rückwärtskompatibilität zu gewährleisteten.

Mittlerweile bin ich etwas schlauer geworden und habe mich durch viel Code des Lovelace Adapters und the type-detectors des iobrokers gekämpft.
Hier einige Infos, dfamit bei ählichen Fragen das Rätselraten zumindest nicht wieder ganz bei Null beginnen muss.

Die automatische Erkennung von Lovelace läuft über den iobroker.type-detector. Der Type Detector versucht über eine Liste von States (Details dazu in Dokument iobroker device types or natürlich im Code des Type Detectors) die zu einem Gerät gehören können, auf das Device zu schliessen. Bei den einzelnen States werden die Rolle, Type usw. berücksichtigt (steht alles im erwähnten Dokument). Zumindest bei Geräten die mehr als einen State haben, z.B. Lamellenstoren, ist es wichtig, dass der Ordner die die States enthält vom Type Channel oder Device ist (hier muss ich den Code noch etwas genauer studieren).

Aus den von Device Detector erkannten Geräten generiert Lovelace im Anschluss die erkannten Entities. Das funktioniert meistens recht gut, vorausgesetzt die Datenpunkte sind so organisiert wie der Type Detector das erwartet. Zum einen müssen die Datenpunkte mit Rollen usw. gemäss der oben erwähnten Tabelle angelegt sein. Zum anderen sollten wirklich nur Datenpunkte eines einzigen Geräts innerhalb eines Ordners vorhanden sein und der Ordner muss vom Typ Channel oder Device sein. Was ebenfalls zu Problemen führen kann, ist wenn im übergeordneten Ordner neben den Device Ordnern noch weitere lose Datenpunkte (z.b. für Devices die nur 1 Datenpunkt haben) vorhanden sind. Dies wurden zumindest bei mir teilweise mit dem ersten erkannten Gerät in einem Unterordner zusammengemischt (das ergab bei mir z.B. einen Blind mit diversen zusätzlichen Feueralarmattributen), was natürlich ein unbrauchbares Result bewirkt.

Habe bereits einen Teil meines Codes der meine schön organisierten Aliases generiert umgebaut, damit das ganze besser funktioniert. Bei den Lamellenstoren klappt das nun wie gewünscht. Der Rest der Geräte ist in Arbeit und wird wenn sie nach dem erwähnten Schema angelegt werden wohl kaum weitere Probleme machen.

Last but not least, ein grosser Freund der automatischen Deviceerkennung werde ich kaum werden. Eine Variante bei der ich explizit Angeben könnte, was wie zusammengehört, würde zumindest für mich ein vorhersehbareres Result bringen (insbesondere mit der Namensgeneierung für die Lovelaceentities kann ich mich schlecht anfreunden).

@ofbeqnpolkkl6mby5e13

Danke für die Nachfrage. Doch ich habe natürlich auch versucht über den ioBroker zu schalten. Deine Antwort hat mich aber dazu gebracht, den Versuch nochmal zu wiederholen und nun hat es funktioniert.

Ursache des Problems war, dass ich beim Ändern der Werte jeweils Acknowldge gesetzt habe. Damit funktioniert es nicht.
Wenn Acknowldge nicht angewählt wird, dann wird der Wert vom Adapter übernommen und an die Geräte, sowohl Schaltaktor, wie auch Wandthermostat (auch direkt nicht nur in der Gruppe) gesendet. Das ack macht der Adapter nach der Übermittlung.

Auch im Log erscheinen nun die gesuchten Einträge.

2022-02-16 13:25:05.913 - debug: hmip.0 (13915) state change - switchState - id "3014F711A000101D89936D47" - value true
2022-02-16 13:25:18.188 - debug: hmip.0 (13915) state change - switchState - id "3014F711A000101D89936D47" - value false
2022-02-16 13:27:03.081 - debug: hmip.0 (13915) state change - setPointTemperature - id ["1907a34d-fe76-45f7-9d54-ca25bd049dbc"] - value rounded to 22 (step=0.5 )
2022-02-16 13:27:08.086 - debug: hmip.0 (13915) setPointTemperature - id ["1907a34d-fe76-45f7-9d54-ca25bd049dbc"] - Send debounced value 22 now to HMIP
2022-02-16 13:27:19.124 - debug: hmip.0 (13915) state change - setPointTemperature - id ["1907a34d-fe76-45f7-9d54-ca25bd049dbc"] - value rounded to 19 (step=0.5 )
2022-02-16 13:27:24.127 - debug: hmip.0 (13915) setPointTemperature - id ["1907a34d-fe76-45f7-9d54-ca25bd049dbc"] - Send debounced value 19 now to HMIP

Nachmal Danke fürs Nachfragen . Sonst würde ich wohl immer noch rumprobieren und mich wundern warum nix geht.

@paul53
Issue erfasst.

@garfonso

Das mit den in Lovelace nicht existierenden Submenus wäre eine Möglichkeit die Einträge im Menubalken auf die wirklich wichtigen Hauptpunkte zu beschränken und weniger häufig benötigte Dinge über ein Untermenu zugreifbar zu machen. Hilfreich wäre da z.B. auch wenn man bei Subviews statt des Zurückpfeils einfach das normale Menu anzeigen könnte. Diese Dinge gibt es halt nicht und drum versuche ich mich irgendwie im das ganze rumzuwursteln.

Popups und Subview benutze ich schon reichlich um das ganze zu strukturieren. Der Ansatz wird aber sobald mehr als ein Unterlevel vorhanden resp. von einem Popup/Subview zum nächsten navigiert wird etwas unübersichtlich.

Werde wohl mal Versuchen ob ich die custom:sidebar-card oder die custom:circle-menu-card zum laufen kriege. Damit liesse sich ev. etwas zusätzliche Struktur ins ganze bringen oder der obere Menubalken ablösen.

Deine Lösung für die nicht erreichbaren Geräte ist definitiv eleganter und schlauer als meine! Beim mir ist das im Moment ein entity-filter mit einer Liste aller Senor Entities, Muss ich mal umbauen, obwohl bei mir sicher nie etwas vergessen geht, da die View mit der Liste (und auch die vielen Subviews mit Charts oder Storenbuttons, wie auch die meisten Alias-Datenpunkte samt Entitydefinitionen) per Script angelegt und nachgeführt werden.

Hallo

Ich habe einige Funktionen die ich immer wieder einsetze in ein Script unter Global gepackt. Wenn ich innerhalb der Scripts Seite von IoBroker Scripts die unter Common oder einem Unterverzeichnis davon gespeichert sind editiere, dann funktioniert Intellisiense wunderbar und ich kriege meine globalen Funktionen angezeigt.

Beim Entwickeln von Scripts mit der Visual Studio Code Extension möchte ich die gleiche Funktion haben und so wie ich alles was ich gelesen habe, sollte das auch gehen. Leider habe ich die Funktion bis jetzt trotz viel Suchen im Forum und ausprobieren aller Hinweise unter [Tester gesucht] Visual Studio Code Extension für ioBroker nicht zum laufen gebracht.

In tsconfig.json habe ich diverse Varianten, die meisten stammen aus dem erwähnten Thread, ausprobiert, u.a. mit explizitem include der Datei mit den globalen Funktionen oder auch über Files. Habe auch versucht für js eine separate jsconfig.json einzurichten und dort die selben Dinge ausprobiert. VS Code habe ich nach den Änderungen immer wieder neu gestartet. Leider alles ohne Erfolg.

Aktuell sieht meine tsconfig.json Datei wie folgt aus:

{
  "compileOnSave": true,
  "compilerOptions": {
    "noEmit": true,
    "allowJs": true,
    "checkJs": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "strict": true,
    "noImplicitAny": false,
    "target": "es2018",
    "typeRoots": [
      ".iobroker/types",
      "node_modules/@types"
    ]
  },
  "files": ["global/global_functions.js"],
  "include": [
    "global/**/*.js",
    "**/*.js",
    "**/*.ts",
    ".iobroker/types/javascript.d.ts"
  ],
  "exclude": [
    "node_modules/**"
  ]
}

Wo stehe ich auf dem Schlauch? Wäre für zweckdienliche Hinweise sehr dankbar!

@garfonso

Ich muss gestehen, dass ich die browser mode Geschichte nicht in allen Details recherchiert habe. Hatte das erwähnte Problem mit den überlangen Popups auf Mobile Devices. Bei der Suche nach einer Lösung bin ich auf den weiter oben mal verlinkten Pullrequest gestossen und habe die Ansatz erfolgreich ausprobiert. Da ich noch eine Reihe weiterer Issues und Pull Requests aus der gleich Zeit gesehen habe, die mit dem Kommentar, dass keine Übernahme gemacht wird weil wegen Browser Mod 2 eine neue Codebasis da ist, habe ich ganz naiv angenommen, dass auch dieser Pullrequest in dieses Kapitel gehört.

Wie auch immer, für mich ist das Problem gelöst und die Popups erscheinen in der richtigen Grösse.

An dieser Stelle ein grosse Dankeschön für das Maintainen des Adapters. Einen eigenen Fork zu Maintainen war und ist eigentlich nicht mein Plan , aber wenn ich Code in die Finger kriege, dann dauert es meist nicht lange bis ich dran rumbastelte und eigene Anpassungen mache. Mit dem Fork ist es am einfachsten die Changes aus Deiner Implementierung zu übernehmen.

By the way, ich müsste wohl noch etwas aufräumen um Dinge die nur für mich relevant sind von anderem in separate Branches abzutrennen, aber ich bin bei Interesse gerne bereit meine Changes als PR zur Verfügung zu stellen. Am ehsten Interesant sind allenfalls die Ergänzungen bei den Settings (nehme an der Screenshot ist selbsterklärend) und ev. die Changes/Fixes beim Cover Converter (ist allerdings kaum getestet und darum eher WIP, da ich im Moment keine Cover Entities benutze).

@garfonso

Das mit den in Lovelace nicht existierenden Submenus wäre eine Möglichkeit die Einträge im Menubalken auf die wirklich wichtigen Hauptpunkte zu beschränken und weniger häufig benötigte Dinge über ein Untermenu zugreifbar zu machen. Hilfreich wäre da z.B. auch wenn man bei Subviews statt des Zurückpfeils einfach das normale Menu anzeigen könnte. Diese Dinge gibt es halt nicht und drum versuche ich mich irgendwie im das ganze rumzuwursteln.

Popups und Subview benutze ich schon reichlich um das ganze zu strukturieren. Der Ansatz wird aber sobald mehr als ein Unterlevel vorhanden resp. von einem Popup/Subview zum nächsten navigiert wird etwas unübersichtlich.

Werde wohl mal Versuchen ob ich die custom:sidebar-card oder die custom:circle-menu-card zum laufen kriege. Damit liesse sich ev. etwas zusätzliche Struktur ins ganze bringen oder der obere Menubalken ablösen.

Deine Lösung für die nicht erreichbaren Geräte ist definitiv eleganter und schlauer als meine! Beim mir ist das im Moment ein entity-filter mit einer Liste aller Senor Entities, Muss ich mal umbauen, obwohl bei mir sicher nie etwas vergessen geht, da die View mit der Liste (und auch die vielen Subviews mit Charts oder Storenbuttons, wie auch die meisten Alias-Datenpunkte samt Entitydefinitionen) per Script angelegt und nachgeführt werden.

Nach einigem Experimentieren habe ich nun eine befriedigende Darstellung gefunden. Die Visualisierung ist im Moment für 16:9 Darstellung auf einem in der Wand eingelassenen Display optimiert,

Die Icons zeigen alle den Zustand des jeweiligen Geräts an. Bei den Storen und beim Vorhang sogar während sie sich bewegen. Zwar nur 7 Schritten und mit 3 Öffnungswinkeln, aber immer noch besser als nix.

Alle auf dem Plan angezeigten Icons sind mit der custom:button-card realisiert. Da gibt es wirklich kaum Grenzen!

Da mir die Cards für die Storensteuerung nicht gefallen (optisch und funktionell), habe ich selber etwas zusammengebastelt. Die Buttons sind ebenfalls custom:button-card Elemente die in einem Popup angezeigt werden.

Auch die Bilder der Kameras werden in Popup angezeigt und können durch anklicken in einer separaten Subview in gross angeschaut werden.

Wenn Fenster geöffnet sind, dann ist das ebenfalls ersichtlich.

Daneben gibt es für jeden Raum eine separate View mit allen Details für diesen Bereich. Ist wenig raffiniert und fast alles normale Lovelace Cards.

Auch hier gibt es bei den Storen und beim Thermostat eine Subview mit mehr Details. Die Knöpfe sind auch hier custom:button-card Elemente. Die Grafiken sind custom:apexcharts-card Elemente.

Da für jeden Thermostat, jeden Storen und einiges anderes je eine spezifische Subview existiert kommt das Ganze auf über 30 Subviews.

Hier die Subview mit den Charts für die Photovoltaik und Strombezug/ und Verbrauch (Ja, der Tag war nur grau und wir haben heute kaum etwas produziert).

Subview für nicht erreichbare Geräte. Die Liste kann auch länger sein. Vergleichbare Subviews gibt es auch mit einer Liste offener Fenster oder für Geräte bei denen die Batterie fast leer ist.

Es fehlen noch einige Dinge, aber so langsam aber sicher wird es so wie es sein soll. Mein bislang nicht lösbares Hauptproblem ist der blaue Balken am oberen Rand. Lovelace lässt hier sowohl bei der Optik (Eigene Icons wären cool), wie auch bei der Funktionalität (Wieso kann ich keine Submenus haben? ) zu wünschen übrig.

@garfonso
Ja klar, auf jeden Fall!

Habe mich da selber (noch) nicht rangetraut, da mir der Überblick über die ganze Lovelace implementierung und das Zusammenspiel mit dem ioBroker Adapter fehlt. Mein Fix ist nur eine Lösung damit mit dem altuellen Release Popups auf Mobiles genutzt werden können.

@garfonso
Die browser_mod Datei habe ich bereits angepasst und das Problem so gelöst. Einfach die Datei aus dem Pullrequest zu kopieren war suboptimal, da damit ein anderes kleines Problem auftrat.

Der Fix aus dem Pullrequest wird nie in den browser_mod Release reinkommen - gleich wie viele andere Dinge aus diser Zeit. Grund ist, dass die ursprüngliche browser_moder Variante für die der Fix ist, nicht mehr gepflegt wird. Mittlwerweile ist browser_mod 2 aktuell (dort scheint es das Problem nicht zu geben), aber wir sind zumindest im Moment noch beim ursprünglichen browser_mod.

Falls jemand den Fix übernehmen möchte, dann liegt die bei mir funktionierende Datei hier: https://github.com/lizardking/ioBroker.lovelace/blob/master/hass_frontend/static_cards/browser_mod.js (Achtung! Besser nicht das ganze Repo übernehmen, da sind noch div andere Anpassungen/Erweiterungen von mir drin).

Im ioBroker-lovelace ist die browser_mod Erweiterung drin. Leider ist es eine Version bei der auf mobilen Endgeräten die Popup viel zu hoch/lang dargestellt werden.

Ist ein bekannter Bug (https://github.com/thomasloven/hass-browser_mod/pull/619) und es gibt auch einen Fix dazu. Wäre cool, wenn der Fix ins iobroker.lovelace integriert werden könnte.

raymercury created this issue in thomasloven/hass-browser_mod

open mobile popup fix for HA 2023.7.3 #619

@garfonso
Ja, mehrere Dashboards wären natürlich ein Hit!

Wenn "Dashboard bearbeiten" aktiv ist, dann gibt es beim Menu mit den 3 Punkten einen Eintrag "Dashboards verwalten".
Wenn ich diesen Anwähle, dann passiert gar nix.

• Ist das normal oder nur bei mir so?
• Was sollte die FUnktion eigentlich machen?

@tomwarrent1
Ich mogle mich mit Javascript um das Problem rum resp. ich erzeuge die ähnlichen Views per Script. Unter lovelace.0.configuration sind die ganzen Views abruf- und auch änderbar (per getObject und setObject).