Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation

[Tirador]

Hallo Community,

in Ermangelung eines passenden Bereichs poste ich mal hier

Das Dokument im Anhang entstand nach längerer Suche/Recherche/Ausprobieren und soll zukünftigen Benutzern als Hilfsmittel dienen einen schnellen aber doch auch tiefgreifenden Einstieg in Lovelace zu finden. Die Bezeichnung "ultimativ" im Leitfaden ist eher "scherzhaft" gemeint, da zum Zeitpunkt der Erstellung dieses Dokuments "bruchstückenhafte" Dokumentationen existieren, die der Autor nun versucht hat in diesem Leitfaden "ultimativ" zusammenzuführen. Daher erhebt dieser Leitfaden keine absolute Vollständigkeit und Richtigkeit und kann garantiert kontinuierlich erweitert werden. Gerne nehme ich weitere Ergänzungen vor, wenn jemand weitere Lösungswege beschreibt.

Viel Spass damit!

Version 1.3
Der ultimative ioBroker Lovelace - Guide.pdf

[David G.]

@Tirador

Finde ich sehr cool.

Habe eine Idee die man evtl. noch einbauen kann. Das meiste habe ich mir anhand der geposteten Beispiele beigebracht. Oder von der offiziellen lovelace Demo die es online gibt.

Evtl kann man in deiner Doku einen Abschnitt "Beispiele" oder "Vorlagen" einbauen.
Dort dann einen Screenshot der Karte mit dem Code. Ggf noch eine kleine Beschreibung.
Einreichen könnte man es per Post in diesem Beitrag oder per PN.

[Garfonso]

@Tirador
Sehr gute Initiative.

[Tirador]

@David-G said in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

@Tirador

Finde ich sehr cool.

Habe eine Idee die man evtl. noch einbauen kann. Das meiste habe ich mir anhand der geposteten Beispiele beigebracht. Oder von der offiziellen lovelace Demo die es online gibt.

Evtl kann man in deiner Doku einen Abschnitt "Beispiele" oder "Vorlagen" einbauen.
Dort dann einen Screenshot der Karte mit dem Code. Ggf noch eine kleine Beschreibung.
Einreichen könnte man es per Post in diesem Beitrag oder per PN.

Beispeile finden sich verlinkt im Abschnitt "Beispiele / Anwendungsfälle".
Weitere Lovelace-Beispiele / Konfigurationen können wir nun hier sammeln:

https://forum.iobroker.net/topic/35950/zeigt-her-eure-lovelace-visualisierung

[KNXbroker]

@Tirador: Super Leitfaden, obwohl ich mich schon einige Zeit mit LoveLace auseinander setze, habe ich einiges noch nicht gewusst.

Stimme @Garfonso aber überein, der muss unbedingt in die offizielle Doku, zumindest der allgemeine Teil. Damit hätte man immer Zugriff auf die neuste Version und jeder würde gleich draufstoßen. Bin mir nicht sicher, ob jeder immer zuerst das Forum liest.

[Tirador]

Ich habe das Kapitel ergänzt, wie man lokale Bilder einbindet!

[Garfonso]

@Tirador

Nochmal vielen Dank für deine Arbeit. Cooler Guide. Ist für den Start sicherlich sehr hilfreich!

Hab jetzt mal etwas Zeit gefunden zum lesen und ein paar Anmerkungen:
Also "lock" entity wird schon unterstützt -> basierend auf Gerät "Schloss". Was nicht (so gut?) geht ist eine Schloss was neben aufschließen noch ein "öffnen" hat (IIRC kann das lovelace selber nicht).

"climate" wird auch unterstützt, da werden die Thermostate aus ioBroker hin übersetzt. Da gibt es aber immer wieder Fehlermeldungen zu und ich hab mich bisher noch nicht intensiv damit beschäftigt, ggf. ist da noch etwas kaputt.

(bzw. was meinst du genau mit "werden nicht unterstützt?" -> im Kapitle Entitäten)

In deinem Beispiel, wo du die Rollen anpassen musstest (Thermostat) könntest du noch ergänzen, dass man so etwas, falls noch nicht geschehen, am besten in Github als issue für den betroffenen Adapter postet (wenn es eindeutig ist, dein Fall ist es, "value.*" ist immer nur zur Anzeige, nicht zum schreiben)

Zu Fenster "gekippt": States muss "richtig" gesetzt werden, so dass es zu den Werten passt, die da stehen können! Der Adapter nutzt das states-Feld um die Zahl in einen String zu verwandeln. Die Zahlen können im Grunde beliebig sein.

Zu umbenannten Entitäten: da gibt es noch eine Schwachstelle im Adapter. Entitäten werden nicht gelöscht -> bis zum Neustart des Adapters bleiben sie auch unter dem alten Namen erhalten (schlimmer ist, wenn tatsächlich was gelöscht wird, das kann auch zu Fehler führen, wobei ich die, meine ich, mittlerweile alle abfange).

Zu manuellen Datenpunkten: Wenn möglich würde ich bei "Sensor" bzw. "binary sensor" auch die automatische Erkennung bevorzugen (also type-detector & lovelace müssen den Typ kennen/unterstützen) -> dann wird auch die richtige "device_class" in der Entität gesetzt und aus z.B. on/off kann auch "Offen / Geschlossen" werden oder Lovelace weiß, dass ein Sensor eine Temperatur ist usw.

Zu deiner Tabelle: die Werte für alles was "binär" ist, sind in HomeAssistant immer "on/off", auch wenn die UI das übersetzt. Also auch, wenn für ein Fenster da geschlossen / offen steht, müsste man z.B. nach on oder off filtern (leider gilt das nicht für die gekippten Fenster -> aber die sind ja auch nicht binär).

"Hinweis: Die Bezeichner des Raums und der Funktion dürfen in diesem Fall nicht abweichendvergeben werden!" -> woher hast du das? Das stimmt m.E. nicht.. bei mir klappt es jedenfalls mit "Wetter / Überall" bzw. "Wetter / Unterwegs" ganz gut.

Zu accuweather wäre vielleicht (bis es ein Update der Karte gibt) noch der Hinweis ganz gut, dass die Karte mit der aktuellsten Version von Lovelace nicht mehr schön formatiert ist (und sich der Aufwand daher vermutlich nicht lohnt).

Zu den Bildern: Die können, wie die custom cards auch, per Drag & Drop auf der Konfigurationsseite der Instanz hochgeladen werden (also da, wo die Liste der custom cards ist).

Den Hinweis mit den Karten würde ich persönlich eher streichen. Mir ist bisher noch keine Karte untergekommen, die gar nicht funktioniert hätte. Eigentlich funktionieren die meisten sogar recht gut. Wichtiger wäre ein Hinweis, dass die Karten zur "Lovelace Version" passen müssen, die ggf. etwas anders sein kann als die aktuell in HomeAssitant genutzte. Das ist leider etwas intransparent... hm.. Jedenfalls gibt es einige Karten, die man nach einem Update auf 1.2.* aktualisieren muss.
Ansonsten hätte ich noch dies Karten als Ergänzung deiner Liste:

• button entity row
• flex table
• auto entities
• card mod
• slider entity row
• slideshow

Zur Banner-Card:
sicher, dass true / false da stimmen? Ich würde eher vermuten, dass es on / off sein müsste? Habe es aber nicht selber ausprobiert.

[Tirador]

@Garfonso Besten Dank für die Rückmeldung. Ich habe die Punkte in einer neuen Version einfliessen lassen.

[Garfonso]

@Tirador
wie im test-thread rausgekommen ist, ist vielleicht ein Absatz zu call_service ganz hilfreich. Da bin ich, muss ich zugeben, auch noch nicht so richtig firm. (Man kann ja, wenn ich es richtig verstanden hab, auch call_service in eine Elements-Card tun... ggf. auch interessant).

[KNXbroker]

@Garfonso sagte in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

wie im test-thread rausgekommen ist, ist vielleicht ein Absatz zu call_service ganz hilfreich

Ich übernehme das.

Die Services selbst sind hier grob erklärt:
https://www.home-assistant.io/docs/scripts/service-calls/

Für detailierte Dokumentation wird auf die Entwicklertools verwiesen:
https://www.home-assistant.io/docs/tools/dev-tools/

Die Entwicklertools sind allerdings nur auf einer lokalen HASS Installation einsehbar. Deshalb habe ich mir kurzerhand eine VM mit Hyper-V aufgesetzt: https://www.home-assistant.io/hassio/installation/

Anmerkung falls das jemand anderes nachmacht: Die VM wie in der Anleitung starten und anschließend auf dem Host (Windows) einfach diese Adresse im Browser eingeben:http://homeassistant.local:8123/

Nun haben wir eine lokale HASS Installation und können unter Entwickleroptionen die detaillierten Service Beschreibungen einsehen.

Wie sich bei der nachfolgenden Dokumentation gezeigt hat, sind viele Services sehr HomeAssistant spezifisch. Nachfolgend die wichtigsten Services, mit welchen wahrscheinlich 95% aller Anforderungen erfüllt werden können. Ich habe nicht alle Services im IOBroker getestet. Bitte um Info sollte irgendwas nicht funktionieren, dann werde ich es vermerken.

HOMEASSISTANT SERVICES

https://www.home-assistant.io/docs/scripts/service-calls/

Es gibt folgende allgemeingültige Services, welche auf beliebige Entitys angewendet werden können (sofern von diesen unterstützt). Beispiele sind Switch, Light, etc.

Service	Beschreibung	Service Data
homeassistant.turn_on	Entity einschalten	entity_id
homeassistant.turn_off	Entity ausschalten	entity_id
homeassistant.toggle	Entity umschalten	entity_id
homeassistant.update	Entity(s) aktualisieren	entity_id(s)

Statt homeassistant kann auch das jeweilige Entity verwendet werden (wie z.B. switch.turn_off)

Beispiel: Zentraler Ausschaltknopf

type: button
name: Alles aus
tap_action:
  action: call-service
  service: homeassistant.turn_off
  service_data:
    entity_id: switch.Zentral_Reset_Wohnen
entity: switch.Zentral_Reset_Wohnen

INPUT_SELECT SERVICES

https://www.home-assistant.io/integrations/input_select/

Folgende Services werden von INPUT_SELECT zur Verfügung gestellt:

Service	Beschreibung	Service Data
input_select.select_next	Nächste Option	entity_id
input_select.select_previous	Vorherige Option	entity_id
input_select.set_options	Optionen definieren	entity_id; options
input_select.select_option	Option auswählen	entity_id; option
input_select.reload	Entitys neu laden

Beispiel: Fernsehsender auswählen

type: button
name: ARD anschauen
entity_id: input_select.TV_Sender
tap_action:
  action: call-service
  service: input_select.select_option
  service_data:
    entity_id: input_select.TV_Sender
    option: ARD

INPUT_NUMBER SERVICES

https://www.home-assistant.io/integrations/input_number/

Folgende Services werden von INPUT_NUMBER zur Verfügung gestellt:

Service	Beschreibung	Service Data
input_number.decrement	Wert verringern	entity_id
input_number.increment	Wert erhöhen	entity_id
input_number.set_value	Wert setzen	entity_id; value
input_number.reload	Entitys neu laden

Beispiel: Rollladen beschatten

type: button
name: Rollladen beschatten
entity_id: input_number.Rollladen_Position
tap_action:
  action: call-service
  service: input_number.set_value
  service_data:
    entity_id: input_number.Rollladen_Position
    value: 80

INPUT_TEXT SERVICES

https://www.home-assistant.io/integrations/input_text/

Folgende Services werden von INPUT_TEXT zur Verfügung gestellt:

Service	Beschreibung	Service Data
input_text.set_value	Wert setzen	entity_id; value
input_text.reload	Entitys neu laden

Beispiel: Passwort zurücksetzen

type: button
name: Passwort zurücksetzen
entity_id: input_text.Passwort
tap_action:
  action: call-service
  service: input_text.set_value
  service_data:
    entity_id: input_text.Passwort
    value: 1234567890

[Tirador]

@KNXbroker said in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

@Garfonso sagte in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

wie im test-thread rausgekommen ist, ist vielleicht ein Absatz zu call_service ganz hilfreich

Ich übernehme das. Werde diesen Post in den nächsten Tagen entsprechend erweitern.
Vorab vielleicht schon mal wie man an die Infos kommt.

Die Services selbst sind hier grob erklärt:
https://www.home-assistant.io/docs/scripts/service-calls/

Für detailierte Dokumentation wird auf die Entwicklertools verwiesen:
https://www.home-assistant.io/docs/tools/dev-tools/

Die Entwicklertools sind allerdings nur auf einer lokalen HASS Installation einsehbar. Deshalb habe ich mir kurzerhand eine VM mit Hyper-V aufgesetzt: https://www.home-assistant.io/hassio/installation/

Anmerkung falls das jemand anderes nachmacht: Die VM wie in der Anleitung starten und anschließend auf dem Host (Windows) einfach diese Adresse im Browser eingeben:http://homeassistant.local:8123/

Nun haben wir eine lokale HASS Installation und können unter Entwickleroptionen die detaillierten Service Beschreibungen einsehen.

AUFLISTUNG FOLGT...

Ich sage schonmal vorab: Klasse für deine Unterstützung! Könnte man zu jedem CallService auch ein Praxisbeispiel machen.

[Garfonso]

@KNXbroker
Ok, da hast du die Beschreibungen gefunden? Gut.
Wenn davon was nicht funktioniert (also im Lovelace Adapter), dann muss ggf. der Adapter angepasst werden. Wenn ich es richtig sehe, sollte aber schon relativ viel gehen.

[KNXbroker]

Habe oben nun alle wichtigen Call-Services zusammengefasst, damit sollte man schon relativ viel umsetzen können. Mein größtes Problem war, mich mit Markdown anzufreunden Aber ich bin ja froh, wenn ich dadurch meinen Teil zu diesem Projekt beitragen kann.

[Tirador]

@KNXbroker said in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

Habe oben nun alle wichtigen Call-Services zusammengefasst, damit sollte man schon relativ viel umsetzen können. Mein größtes Problem war, mich mit Markdown anzufreunden Aber ich bin ja froh, wenn ich dadurch meinen Teil zu diesem Projekt beitragen kann.

Sehr schön. Ich würde deine Passagen dann in den Leitfaden übernehmen, wenn du nichts dagegen hast.

[KNXbroker]

@Tirador
Klaro, dafür habe ich es ja gemacht. Habe auch schon überlegt, alles Mal ins englische zu übersetzen, aber ich weiß nicht wie man sowas am besten versionstechnisch steuert. Unterstützt das GitHub Wiki mehrere Sprachen?
Überlegst du noch das ins GitHub Wiki einzupflegen? @Garfonso hat ja schon ein erstellt, aber weiss nicht wie man das bearbeiteten kann.

[Garfonso]

@KNXbroker
Das Problem am Github Wiki ist, dass es nur Kollaborateure bearbeiten können, also Github User, die Rechte an dem Adapter haben. Ich vermute, dass bluefox das nicht ganz recht ist, wenn das zu viele Leute nur für die Doku kriegen.

Es gibt ja eine ioBroker zentrale Doku, da gibt es für jeden Adapter auch eine Seite: https://www.iobroker.net/#de/adapters/adapterref/iobroker.lovelace/README.md
Aktuell wird da einfach die README.md aus dem Repository hingepackt (und in den verschiedenen Übersetzungen mit automatischer Übersetzung angeboten...). Der Adapter kann das, soweit ich weiß, per io-package.json auf ein anderes Verzeichnis, z.B. docs im Repository umbiegen und dann da auch mehrere Sprachen anbieten. Das wäre vielleicht das einfachste?
Dann könntet ihr, wenn ihr was an der Doku machen wollte, auf github einen PR machen und ich übernehme das dann.

Hier dazu die Erklärung: https://www.iobroker.net/#de/documentation/dev/adapterdocstyleguide.md
Ich würde die entsprechende Struktur dann im Adapter erstellen, wenn ihr das so machen wollt.

@Tirador das könnte man dann, wenn wir da was hingetan haben vielleicht auch promininter in der Doku unter Visualisierungen verlinken (wobei wir dafür vermutlich lovelace erstmal im stable updaten sollten.... der Unterschied ist doch aktuell zu krass - aber dafür will ich noch den blöden Editor Bug fixen, bei dem ich leider irgendwie hänge... seufz).

[Tirador]

@Garfonso said in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

@KNXbroker
Das Problem am Github Wiki ist, dass es nur Kollaborateure bearbeiten können, also Github User, die Rechte an dem Adapter haben. Ich vermute, dass bluefox das nicht ganz recht ist, wenn das zu viele Leute nur für die Doku kriegen.

Es gibt ja eine ioBroker zentrale Doku, da gibt es für jeden Adapter auch eine Seite: https://www.iobroker.net/#de/adapters/adapterref/iobroker.lovelace/README.md
Aktuell wird da einfach die README.md aus dem Repository hingepackt (und in den verschiedenen Übersetzungen mit automatischer Übersetzung angeboten...). Der Adapter kann das, soweit ich weiß, per io-package.json auf ein anderes Verzeichnis, z.B. docs im Repository umbiegen und dann da auch mehrere Sprachen anbieten. Das wäre vielleicht das einfachste?
Dann könntet ihr, wenn ihr was an der Doku machen wollte, auf github einen PR machen und ich übernehme das dann.

Hier dazu die Erklärung: https://www.iobroker.net/#de/documentation/dev/adapterdocstyleguide.md
Ich würde die entsprechende Struktur dann im Adapter erstellen, wenn ihr das so machen wollt.

@Tirador das könnte man dann, wenn wir da was hingetan haben vielleicht auch promininter in der Doku unter Visualisierungen verlinken (wobei wir dafür vermutlich lovelace erstmal im stable updaten sollten.... der Unterschied ist doch aktuell zu krass - aber dafür will ich noch den blöden Editor Bug fixen, bei dem ich leider irgendwie hänge... seufz).

Also ich kann einen Pull Request mit der Readme.md und den Bildern auf GitHub machen. Es ist dann nur klar, dass die bisherige Doku in Englisch durch die Deutsche ersetzt wird.

[KNXbroker]

@Garfonso sagte in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

Es gibt ja eine ioBroker zentrale Doku, da gibt es für jeden Adapter auch eine Seite: https://www.iobroker.net/#de/adapters/adapterref/iobroker.lovelace/README.md

Das kannte ich noch gar nicht. Dort ist auch ein sehr hilfreicher Editor zum Übersetzen vorhanden. Lustig: Lovelace wird mit Liebesspiel automatisch übersetzt

Denke eine finale Übersetzung macht erst Sinn, wenn sich am Leitfaden nicht mehr viel ändert. Vielleicht könnte man zwischenzeitlich auch auf eine automatische Übersetzung zurückgreifen?

@Tirador: Wenn man die fehlenden Punkte noch in deiner Doku aufnimmt, dann könnte doch die bereits vorhandene Doku komplett ersetzt werden, oder?

• Viele Punkte sind ja bereits doppelt vorhanden
• Einige Punkte wären auch in deiner Doku hilfreich: Notification, Voice, etc. (da habe ich mich auch noch nicht auseinander gesetzt, hat schon jemand Erfahrung?)
• Viele Punkte der vorhanden Doku sind ja nur für Entwickelter wichtig (Definition der Datenpunkte, etc.). Könnte man am Schluss in deine Doku unter Development mit reinpacken.

Viele Grüße

[Tirador]

@KNXbroker said in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

@Garfonso sagte in Der "ultimative" ioBroker Lovelace Leitfaden/Dokumentation:

Es gibt ja eine ioBroker zentrale Doku, da gibt es für jeden Adapter auch eine Seite: https://www.iobroker.net/#de/adapters/adapterref/iobroker.lovelace/README.md

Das kannte ich noch gar nicht. Dort ist auch ein sehr hilfreicher Editor zum Übersetzen vorhanden. Lustig: Lovelace wird mit Liebesspiel automatisch übersetzt

Denke eine finale Übersetzung macht erst Sinn, wenn sich am Leitfaden nicht mehr viel ändert. Vielleicht könnte man zwischenzeitlich auch auf eine automatische Übersetzung zurückgreifen?

@Tirador: Wenn man die fehlenden Punkte noch in deiner Doku aufnimmt, dann könnte doch die bereits vorhandene Doku komplett ersetzt werden, oder?

• Viele Punkte sind ja bereits doppelt vorhanden
• Einige Punkte wären auch in deiner Doku hilfreich: Notification, Voice, etc. (da habe ich mich auch noch nicht auseinander gesetzt, hat schon jemand Erfahrung?)
• Viele Punkte der vorhanden Doku sind ja nur für Entwickelter wichtig (Definition der Datenpunkte, etc.). Könnte man am Schluss in deine Doku unter Development mit reinpacken.

Viele Grüße

Ja, die fehlenden Punkte müssten noch ergänzt werden und dann auch getestet und mit Beispielen ausgearbeitet.
Die Notifications habe ich mal ausprobiert im Zuge des MessageHandlers-Projekts. Dazu kann ich etwas beisteuern.
Mit Voice habe ich keine Erfahrung.

[Garfonso]

@Tirador
ich würde einen ordner \docs neu anlegen und da in den Unterordnern de\ bzw. en\ den Leitfaden (und Bilder sollen nach der Beschreibung dann da jeweils in \media) tun. Die Haupt-Readme würde ich dann potentiell deutlich verkürzen und da prominent einen Link auf die "User-Doku" setzen und darunter dann die Sachen, die für Entwickler wichtig sind sammeln. Ggf. bei der Gelegenheit das Chagenlog aussortieren.

Kannst du mir das Markdown mal zukommen lassen? Dann würde ich das die Woche angehen und etwas experimentieren.