Home Assistant - Zeigt her eure Dashboards!

[meti]

Bei den Release-Partys auf YT dieses Jahr 😂

[Stoxn]

Same same - release notes…

[henfri]

Hm, das hätte ich jetzt nicht als besonders didaktisch erwartet...

[Springrbua]

Hier ein paar Screenshots meines aktuellen Mobile-Dashboards:
image.png image.png image.png image.png image.png image.png
Im Prinzip gibt es auf der Startseite eine Kachel pro Stockwerk, mit Temperatur + Luftfeuchte des "Hauptraumes".
Zusätzlich 4 kleinere Kacheln für Schnellzugriffe auf:
- Allgemein: Übersicht der eingeschalteten Lichtquellen, offenen Türen / Fenster, Kameras und Müll sowie Schnellzugriff auf Heizkörper, Zirkulationspumpe, Türöffner u.s.w.
- Rollläden: Die Rollläden werden noch immer manuell bedient. Hier habe ich einen Schnellzugriff auf die einzelnen Rollläden, sowie ein zentrales Hoch- und Runterfahren aller Rollläden.
- Musik: Steuerung der einzelnen Zonen und Möglichkeit diese zu gruppieren.
- Einkauf: Einkaufsliste

Zudem sind ganz oben die Chips mit dem aktuellem Datum (Klick = Kalender öffnen), Wetter + Temperatur (Klick = Wetter-Details öffnen) und Windgeschwindigkeit.
Die Views der einzelnen Stockwerke beinhalten dann wieder eine Kachel pro Raum, wieder mit Temperatur und Luftfeuchte, sowie eine Einfärbung, falls das Hauptlicht eingeschaltet ist. Per Long-Klick lässt sich dieses Ein-/Ausschalten.
In der Ansicht der Räume sind dann einfach nur die Entities dieses Raumes, also Licht, Rollläden, Alarmkontakte und Heizung) untereinander aufgelistet.
Ich nutze hauptsächlich die Community Erweiterungen "Mushroom" und "Layout Card".
Im Großen und Ganzen bin ich mit dem Dashboard zufrieden, es ist mMn sehr übersichtlich. Aber man benötigt auch relativ viele Klicks wenn man z.B. das Licht in einem gewissen Raum einschalten möchte.

Demnächst möchte ich endlich mein Wallpanel montieren, dafür muss ich dann aber erst noch ein Dashboard konfigurieren.

[Tom Bombadil]

Na gut - wenn alle show-off machen, muss ich auch mal.

Vorweg: Ich hatte erstmals Kontakt mit HA im Februar diesen Jahres - dann bis Mai ein bisschen entwickelt, dann Pause bis Anfang Oktober, jetzt wieder dran. Hier hatte ich schon mal skizziert, was ich aus meinem Altsystem übertragen will.

Ziel ist irgendwann die Ablösung meines viele Jahre laufenden smartHomeNG/smartVISU-Systems - voll interaktiv, alle Elemente klickbar (also nicht nur Anzeige langweiliger Bilder). Entsprechend auch meine Anforderungen an die Visu: PC- und Tablet-tauglich, Smartphone ist mir (noch) ziemlich egal. Druck mache ich mir keinen - wenn der Umzug fertig ist, ist er fertig. Auch reize ich gern mal die Möglichkeiten von HA und Lovelace ein bisschen aus - ohne massig Add-ons zu installieren (button-card, minigraph, cardmod und plotly müssen für die Visualisierung reichen - Risikominimierung für zukünftige Updates).

1. Begrüßung (nix besonderes)

1_hello.png

2. Mein erstes Projekt - Temperaturen wie in der smartVISU anzeigen. Die kommen per REST von ESP's mit ESPEasy. Alles natürlich klickbar für Historie.
Randnotiz: KWL von Helios muss ich noch machen und Temps hier einarbeiten, deren alte KWL-Version hat kein 100% Modbus konformes Protokoll --> schreit mal wieder nach eigenem 'Plugin', wie schon zu shNG-Zeiten.

3_raumklima.png

3. Mein zweites Projekt: Meinen Jahreskalender aus smartVISU/shNG übertragen.
Dafür habe ich jetzt einen dedizierten, ganz normalen Kalender in HA für wiederkehrende Termine. Die werden für das aktuelle Jahr rausgesammelt und pro Monat angezeigt. Es geht um wichtige Dinge wie TÜV, Heizungswartung, Abgabe Steuererklärung, Räderwechsel etc - Dinge, die sich alle 2/3/4/8/12/26/30 Monate wiederholen, die ich aber nicht in meinem täglichen Kalender haben will.
Randnotiz: Aus den einzelnen Punkten will ich noch eine abhakbare ToDo-Liste bauen, die sich jedes Jahr resetted - zur Zeit wird einfach nur angezeigt (=reminder).

2_jahreskalender.png

4. Mein drittes Projekt: Heizung aus shNG übertragen (Trovis-Regler per Modbus, siehe hier)
Randnotiz: Im HA-Discord wurde fleißig gelacht und viel Glück gewünscht, als ich geschildert habe, was ich vorhabe. Dies ist 'work in progress (Fertigstellung: derzeit ca 90%). Am Ende kriegen die im Discord dann von mir eine HACS-installierbare Trovis Custom Integration vor den Latz mit der Bemerkung: So, feddisch!

4_0_heizung.png

Alle Elemente sind klickbar, selbst die Buttons auf dem Regler (Heizkreisumschaltung), das Reglerdisplay (liefert ganzseitige Plots mit filterbaren Statistiken), das Hydraulikschema oben (liefert Einstellungsseite), die Plots (zoom, pan, annotations, markieren auffälliger Stellen mit Lasso vor dem Export, png/svg Export, xsl-Datenexport etc).

Hier mal einige Eindrücke (irgendwie zeigt er in der Vorschau die Videos nicht an - notfalls gern über die Links von Hand aufrufen):

Live-Visualisierung der Umschaltung von Heizung auf Warmwasser auf Aus im laufenden Heizungsbetrieb:

--> https://kramkiste.net/videos/4_1_hydraulik.mp4

Anzeige der Heizkurven und WW-Bereitung durch Klick auf die Reglerbuttons:

--> https://kramkiste.net/videos/4_2_regler.mp4

Bei Klick auf Hydraulik/Schema der Heizung = auf Einstellungsseite gehen (work in progress):

5_0_heizung-einstellungen.png

Dort dann Einstellungen an den Parametern vornehmen und live die Auswirkungen auf die Heizkurven und die WW-Einstellungen sehen:

--> https://kramkiste.net/videos/5_1_einstellungen.mp4

5. Mein nächstes Projekt nach Fertigstellung der Heizung: Die KWL. Dafür gibt es schon ein Python Plugin, ursprünglich für shNG/sV - muss mal sehen, wie ich das in HA integriert bekomme.

6. Mein übernächstes Projekt: Langzeitspeicherung auf MariaDB statt integriertem SQLite. Auf der einen Seite habe ich das Gefühl, dass externe DB's von HA etwas stiefmütterlich behandelt werden. Andererseits muss dafür erstmal ein neues NAS her - mein QNAP TS251+ mit Vollausbau von 8GB RAM für 1) shNG-Live-VM (nutzt MariaDB), 2) shNG-Dev-VM (nutzt MariaDB), 3) HA-Live-VM, 4) HA-Dev-VM, 5) Nextcloud-VM (nutzt MariaDB) sowie einigen weiteren 'Nach-Bedarf-Grabbel-VMs' geht langsam in die Knie.

So, genug geschrieben, weiter geht's mit dem Entwickeln ...

/tom

Edit/Nachtrag: Hier nochmal die ganze Heizungsseite - Ganzseiten-Plots und Einstellungsseite sind noch 'work in progress'. Das hilft vielleicht beim Verständnis der Einzelelemente oben. Viel Handarbeit, viel YAML (demnächst mit Jinja2 Makros aber deutlich weniger). Ich geb zu - sieht ziemlich '90er aus, aber ich steh halt drauf.

--> https://kramkiste.net/videos/6_heizung gesamt.mp4

[Neff]

Stoxn so viele Badges habe ich meistens gar nicht gleichzeitig aktiv, der Screenshot zeigt alle im Editiermodus. Ich benutze sie auch zur Navigation, z. B. komme ich bei Klick/Tap auf die Badge, die offene Fenster im EG meldet, auf die EG Seite, wo dann einzelne Bages pro Fenster sind. Wenn die Fenster geschlossen sind, werden sie auch nicht angezeigt.

Danke für den Tip mit den Bages in den Überschriften, das kannte ich noch nicht.

[henfri]

TomBombadiel Das ist echt beeindruckend. Da steckt viel Arbeit drin.
Es wäre toll, wenn du noch etwas dazu sagst, wie du das realisiert hast (nicht im Detail, sondern die genutzten Elemente).
Und erzähl mal, wie jinja helfen wird?

Gruß,
Hendrik

[Tom Bombadil]

Ja, ein 'bisschen' Arbeit steckt da drin. Ich halte mich für einen 'fortgeschrittenen Einsteiger' (meine aktiven Programmierzeiten sind mehr als 20 Jahre her, also vor YAML, Jinja, JS und diesen ganzen anderen Interpretersprachen). Vieles würden die echten 'Nerds' mit Sicherheit eleganter oder anders lösen - für mich zählt in erster Linie das Erreichen der gewünschten Funktionalität, nicht schöner oder kompakter Code.

Einen großer Teil des Codes und somit der Komponenten und Elemente ist im Original im verlinkten Trovis-Git zu finden. Da Du ja auch aus der SmartHomeNG/SmartVISU Ecke kommst, hier ein paar grundlegende Tips und Vergleiche, die mir am Anfang sehr geholfen und viel Zeit gespart hätten (ich könnte jetzt mehrere Seiten schreiben, versuche aber, mich auf das wesentliche zu konzentrieren):

• Systemkern: Wie shNG ist auch der Kern von HA in Python geschrieben. Das kann *sehr* bei der Übertragung von Modulen/Plugins shNG-->HA helfen; auch bei HA geht es mit der __init__.py los.
• YAML: Wie shNG wird HA mit YAML-Dateien konfiguriert. Diese können bei HA aber an bestimmten Stellen zusätzlich sogenannte 'templates' enthalten (am ehesten mit den User Functions von shNG vergleichbar). HA Templates sind ausführbarer Jinja2 Code, eingebettet in das YAML. Wer in der SmartVISU mal selbst mit der TWIG Template Engine (alle sV Seiten sowie Anzeigeelemente basieren darauf) gearbeitet hat, fühlt sich in Jinja sofort zu Hause - fast 1:1 Syntax.
• Bestimmte Karten für die HA-Seiten unterstützen in der YAML-Konfiguration die Nutzung von JS (bei der sV war es JQuery). Ab diesem Punkt gilt: Nichts ist unmöglich, da man beliebig in JS programmieren kann.
• Trick: Wenn eine Karte von Hause aus kein JS unterstützt, kann man sie in eine andere JS-fähige Karte einbetten - schwupps, ab geht's. Das ist der Grund, warum ich die custom:button-card massiv nutze. Damit lassen sich dann solche kleinen Nettigkeiten wie diese Kachel hier bauen:
  
  image.png
  
  Statt eine Konfigurationszeile wie zB `name: NUC` immer mit einem festen Wert zu bestücken, erlaubt es JS, den Inhalt durch Programmierung zur Laufzeit zu ermitteln, Dinge einzufärben (45°=gelbes Thermometer) etc etc.
• Must-have addons aus meiner Sicht: HACS, button-card, cardmod. Wenn gewünscht mini-graph-card und plotly (find ich mächtiger/stabiler als Apexcharts). Müllkalender mit waste-collection-schedule, Wetter mit Pirateweather. Das war's auch schon. Für fortgeschrittene Anwender ggf. noch die decluttering-card zum Code-Aufräumen und compacten in Lovelace.
• Zur Deiner Frage "Wie kann Jinja helfen?": Wie geschrieben, ist Jinja eine template-Engine wie Twig. Dort können auch Macros definiert werden - genau wie in Twig. Dadurch kann man wiederkehrende Dinge massiv verkürzen.
  
  Beispiel: Meine Heizkurven auf der Einstellungsseite (siehe Video mit den Schiebereglern). Jede Heizkurvenberechnung der 3 Heizkreise hat 25 Zeilen Code. Für jeden Heizkreis gibt es: Aktuelle_Kurve, Tag_wie_eingestellt, Nacht_wie_eingestellt, Tag_mit_veränderten_Werten, Nacht_mit_veränderten_Werten. Macht 3 Heizkreise x 5 identische Berechnungen x 25 Zeilen = 375 Zeilen YAML-Code für die Template Sensors. Stattdessen kann man auch die 25 Zeilen als Jinja-Macro schreiben und die zu benutzenden Sensoren als Parameter oder Attribute übergeben (beides geht). Ergebnis: 4 Zeilen YAML pro Heizkurve, Aufruf des Macros damit. Ergbit 60 übersichtliche YAML-Zeilen statt vorher 375.

Hoffe, das hilft Dir weiter - immer gern raus mit weiteren Fragen.

/tom


Edit/p.s. Die oben genannten 'Nerds' sind übrigens sehr hilfreich und Tag und Nacht hier zu finden. Da wurde mir schon oft und super kompetent geholfen.

[oefchen]

Sehr cool Tom !! ...das erste Mal das ich was von HA sehe und mir sage: OK...da könnt ,man von Edomi umsteigen. Schön zu wissen das es geht...auch wenn das für mich ne steile Lernkurve wäre. Wars bei Edomi aber auch.

[scw2wi]

Mir geht es genauso.

Bisher dachte ich immer, man kann in HA jeweils nur einen Wert je Kachel anzeigen, was halt die Anzeige von mehreren Werten sehr bescheiden aussehen lässt.

Aber mit genügend Kenntnis scheint es auch möglich zu sein, sich Kacheln zu bauen, die gleich alle Werte anzeigen die relevant sind, und das ganze auch noch wunderschön mit bunten Symbolen versehen.

Wenn man diese Werte dann auch noch mit einem proportionalen Balken hinterlegen kann
fehlt eigentlich nichts mehr zu einer Visu die mit Edomi mithalten kann,
und dann sogar noch den Vorteil der Skalierbarkeit für verschiedene Auflösungen bietet.

[Punker Deluxe]

Ich bin jetzt schon bissl neidisch... aber umsomehr motiviert mich in HA einzulernen. Leider hab ich noch nicht den Lehrgang von Mathias, würde am liebsten sofort loslegen.

Dumme Frage, bin echt noch Neuling: Die Einbindung KNX ist eine Entinität die ich erst noch im "nackigem" HA implementieren muß? Ich lese viel mit, hab diverse Videos durch, aber manche Begrifflichkeiten erschließen sich mir noch nicht da ich bisher nur trockene Theorie habe.

[scw2wi]

... bin echt noch Neuling: Die Einbindung KNX ist eine Entinität ...

Die Frage interessiert mich auch, dafür wäre aber ein eigener Thread viel besser geeignet.

[Tom Bombadil]

Bisher dachte ich immer, man kann in HA jeweils nur einen Wert je Kachel anzeigen, was halt die Anzeige von mehreren Werten sehr bescheiden aussehen lässt.

Einfach mal in Google `ha dashboards` oder `best ha dashboards`eingeben, auf 'Bilder' schalten und 2 Minuten srollen und klicken - dann staunen, was alles geht: Live Wetter auf Wetterkarten vom Onlinedienst, mehrere Kameras gleichzeitig (ggf. auch als Hintergrundbilder auf Kacheln), live Anzeige von Energieerzeugung/-verbrauch, Statusanzeigen auf etagenweisen Grundrissen des Hauses, schicke RTR's, Auto-Generierung von Listenanzeigen der Entitäten plus einfache Scripte für Gruppen (vereinfacht geschrieben: `button: on_tap: wohnzimmer.licht.*=toggle[on,off]) usw usw. Alles wahlweise statisch für bestimmte Auflösungen (wie bei mir), oder dynamisch für PC/Tablet/Phone View.

Nach all dem 'Pro' hier auch mal ein wenig 'Con', insbesondere im Vergleich zu shNG/sV:

• YAML als durchgängige Basis wird zur Dauerschreibübung. Wer spezielle Wünsche und Vorstellungen hat und sich nicht mit Makros (Backend, für die Definition von Entitäten) und Decluttering Templates (Frontent, für die Anzeige) beschäftigt, wird schnell feststellen, dass seine Dateien plötzlich hunderte oder gar tausende Zeilen haben. Die Datei mit den Einstellungen für den Trovis-Regler -siehe Video- hat zB ohne Makros ca. 3.500 Zeilen, davon 2.500 für die 24 Schieberegler. Mit Makros optimiert rechne ich immer noch mit mindetens 500-600 Zeilen YAML.
  Der 'Visual Editor' im Frontend ist wirklich nett und hilft am Anfang sehr. Aber bei komplexeren Seiten mit eigenen Definitionen steigt der irgendwann aus, und man muss das YAML 'zu Fuß' bearbeiten, um das gewünschte Ergebnis zu erhalten.
• Wer gewohnt ist, eine beliebige Struktur für seine Items festzulegen, muss sich umgewöhnen. Eben mal schnell einen eigenen Baum mit beliebigen Elementen definieren (wie die Item-Bäume von shNG) geht nicht. HA gibt dem Anwender schon im Root-Knoten eine feste Grundstruktur vor - sensors, binary_sensors, input_numbers usw. Klingt erstmal logisch, ist aber schnell hinderlich, wenn man wie ich eine funktions- und geräteweise 'Denke' hat. Eben mal schnell auf dem 3. Sublelvel ein Modbus-Coil (binary_sensor) neben ein Modbus-Register (sensor) zu legen, weil die beiden eben zusammengehören, geht schlicht nicht. Die beiden *müssen* zwingend in verschiedenen Strukturen untergebracht werden.
  Wie man das zumindest etwas umschiffen und der Übersichtlichkeit halber in separate Dateien auslagern kann, zeigt meine configuration.yaml im anderen Thread (aber auch das hat Grenzen).
• Zusätzliche Infos auf den vordefinierten Entitäten dauerhaft dynamisch zu hinterlegen (also nicht fest im YAML), ist schlicht nicht vorgesehen. Ich habe zB in shNG eine komplette Inventarisierung des gesamten Hauses, indem ich beliebigen Items einfach ein neues Zusatzattribut mit meinem Wunschnamen 'my_infos' gegeben habe. Beispiel: Auf der Heizkreispumpe steht in my_infos: `Grundfos Alpha 2 15/40, BJ 2010, getauscht auf Gewährleistung von Fa. xyz 2013. Modell abgekündigt, Weblink zum neuen Modell beim Hersteller [...10 Zeilen folgen...]`.
  Solch ein Attribut kann ich zwar auch in HA mit festem Inhalt im YAML hinterlegen; aber die Ausgabe in Lovelace, sofern das Attribut vorhanden ist, ist umständlich/aufwendig; und eine dynamische Ergänzung der Infos über das GUI mit Speicherung in der dB geht gar nicht; ich *muss* das in's YAML fest reinschreiben (hierzu gibt es schon mehrere Threads / Tickets / Vorschläge - ich denke mal, irgendwann kommt da was).

So, war wieder mehr Text als ursprünglich gewollt - aber da einige auf dem 'Schwenk' zu sein scheinen, sind die Infos vielleicht hilfreich.
Jetzt erstmal wieder etwas YAML in HA schreiben, damit ich mit meinen Seiten weiterkomme ...

/tom

[tsb2001]

Die Einbindung KNX ist eine Entinität die ich erst noch im "nackigem" HA implementieren

Die Frage interessiert mich auch,

Ich habe das mal zum Anlass genommen, einen eigenen Thread aufzumachen und mal meine Entitäten gepostet.
https://knx-user-forum.de/forum/proj...en#post1995174

[Tom Bombadil]

Kurzer Nachtrag (Schlaumeiermodus in Sachen Wording): Die Haupteinträge in der configuration.yaml nennt HA 'Domains' (sensor:, binary_sensor:, knx: ...). Diese können entweder fest eingebaut sein (wie sensor: ), oder aus einer Integration/Custom Integration stammen (sozusagen aus einem 'add-on' - KNX, Modbus usw).

Darunter definiere ich meine 'Items' (Variablen, Messpunkte, Zustände - wie auch immer man das nenen will, alles konkrete halt. HA nennt das 'Entitäten').

Tip:
--> Entwicklerwerkzeuge --> Zustände = filterbare Liste aller aktuellen Entitäten; wird eine Entität dort verändert, passiert das idR nur in der laufenden HA-Instanz und wird nicht auf das Gerät zurückgeschrieben (war sehr hilfreich bei meinen Modbus-Tests).
--> Einstellungen --> Geräte und Dienste --> Entitäten = dito, aber mit Zustand wie 'nicht erreichbar, verwaist' etc. Braucht man manchmal zum Aufräumen.

Beispielkarte: Liste aller Domains mit ihren Entitäten als Jinja (als benutzerdefinierte Karte hinzufügen, auf Code-Editor umschalten und copy/paste; erfordert card-mod addon zur Formatierung der Ausgabe):

title: Eigene Karte 3
type: markdown
content: |-
  {% for d in states | groupby('domain') %}
    {% if loop.first %} Domains: {{loop.length}}
    {% endif %} - {{ d[0] }} ({{ states[d[0]] | count }})
        - {{ states[d[0]] |map(attribute='entity_id')| list|join('\n      - ') }}
  {% endfor %}
card_mod:
  style: |
    ha-markdown {
      max-height: 300px;
      overflow-y: auto;
    }

image.png

KNX Integration bin ich ansonsten raus - (leider) nicht meine Baustelle, da wissen andere mehr ...

/tom