HA Kurzeinführung

[gbglace]

In Proxmox kannst jedes Ding einzeln als LxC Container laufen lassen oder baust einen größeren LXC Container mit Docker und Portainer drauf und hast dann da drinnen alle Optionen die man viel beschrieben in allen YT Anleitungen Installation unter Docker findet.

Ich sortiere das mittlerweile auch. Die ganzen MiniSwrvices landen in einer solchen Docker LxC Instanz. Bin da auch nicht so fit das auf den Konsolen per Hand zu machen. Die größeren haben dann ihren eigenen LXC, HA dann eben gar die eigene VM.

[scw2wi]

Wer bisher bei HA noch keinen MQTT-Broker installiert hat, der kann sich jetzt dieses Video ansehen: MQTT für Home Assistant einrichten

Simon erklärt hier ausführlich wie immer jeden einzelnen Schritt, und es ist, wie wir es von HA gewohnt sind, auch sehr einfach.

Das einzige was ich vermisst habe, aber vielleicht hab ich es auch überhört: Für die Installation vom MQTT-Explorer muss man vorher noch ein Repository hinzufügen.

Wer noch tiefer einsteigen möchte, es gibt eine sehr umfangreiche HA-Dokumentation zum Thema MQTT.

[scw2wi]

Wer so wie ich im Sidebar-Menü bereits zu viele Einträge hat, diese aber nicht ausblenden möchte um sie im raschen Zugriff zu behalten, für den kommt (wie für mich) diese neue Navigation Card wie gerufen.

Ich hab einfach in meinem Dashboard (das bereits aus 13 Seiten besteht) eine weitere Seite hinzugefügt, und diese sieht jetzt so aus.

HACS - Navigation Card V2025.11.1.png

Einerseits hab ich einige häufig verwendete Unterseiten in den Settings auf direkte Links gelegt (Protokolle, Backups, Storage), und hab diese damit noch schneller erreichbar, andererseits hab ich die am wenigsten verwendeten Seiten aus dem Sidebar-Menü entfernt, und damit hat es jetzt endlich keinen Scrollbalken mehr.

Den Code kann vermutlich niemand 1:1 übernehmen, da das Menü ja bei jedem anders aussieht, ich hab ihn aber (bis auf die Dashboard-Zeile) trotzdem unten attached, da ja viele Teile wiederverwendbar sind.

[scw2wi]

Wer so wie ich ständig über die verschiedenen timestamp und datetime Formate nachlesen muss, der kann diese kleine Anleitung sicher gut verwenden. In Date formatting wurde bereits viel über die Datumsformate in HA geschrieben, aber da ich immer noch etwas durcheinander komme, hab ich mal folgende Zeilen zusammengefasst.

Da es einfacher Jinja2-Code ist, kann man den Block so wie er ist in den Template-Editor von HA kopieren und sich die Ausgabe anzeigen lassen.
http://homeassistant.local:8123/deve...tools/template

{% set datetime_iso8601_ohneT = now() %}
{{ datetime_iso8601_ohneT }}

{% set datetime_iso8601_mitT = now().isoformat(timespec='auto') %}
{{ datetime_iso8601_mitT }}

{% set datetime_iso8601_ohneT_2 = datetime_iso8601_mitT | as_datetime %}
{{ datetime_iso8601_ohneT_2 }}

{% set timestamp1 = now().timestamp() %}
{{ timestamp1 }}

{% set timestamp2 = now() | as_timestamp %}
{{ timestamp2 }}

{# %a %A Weekday as en-Name | %d Day 2-digit | %-d Day 1/2-digit | %m Month 2-digit | %b %B Month as en-Name | %Y Year 4-digit #}

{% set timestamp_custom_short = now() | as_timestamp | timestamp_custom('%a %-d.%m.%y %H:%M') %}
{{ timestamp_custom_short }}

{% set timestamp_custom_long = now() | as_timestamp | timestamp_custom('%A %d.%b %Y %H:%M:%S') %}
{{ timestamp_custom_long }}

{% set days = ["Montag", "Dienstag", "Mittwoch", "Donnerstag", "Freitag", "Samstag", "Sonntag"] %}
{{ now().isoweekday() }}
{{ now().weekday() }}
{{ days[now().weekday()] }}

{% set months = ["Jan", "Feb", "Mär", "Apr", "Mai", "Jun", "Jul", "Aug", "Sep", "Okt", "Nov", "Dez"] %}
{{ months[now().month - 1] }}
​
​

Zu meiner Verwirrung trägt auch bei, dass es das ISO-8601 Format einmal mit T und einmal ohne T gibt.

mit T: 2025-11-07T13:16:00.057448+01:00
ohne T: 2025-11-07 13:16:00.057448+01:00

now() liefert die Zeit ohne T und damit kommt HA dann auch besser klar.

.isoformat wandelt in die Form mit T um und erlaubt als Parameter-Werte für timespec: auto | microseconds | milliseconds | seconds
as_datetime wandelt in die Gegenrichtung um

Man kann auch strptime zum parsen der Zeit verwenden, hab ich hier jetzt aber nicht.

.timestamp() oder as_timestamp wandelt von datetime in das Unix-Zeitformat um, das die Sekunden seit 1970 darstellt. Dieses Format wird intern nicht mehr wie früher als 32-Bit gespeichert, sonst hätten wir beim Überlauf ein Jahr 2038 Problem.

Zur lesbaren Formatierung eines timestamps kann man strftime oder auch timestamp_custom verwenden, beide verwenden dieselben Regeln.

%a %A Weekday as en-Name
%d Day 2-digit
%-d Day 1/2-digit
%m Month 2-digit
%b %B Month as en-Name
%Y Year 4-digit

Im PHP-Manual findet man noch viel mehr Regeln.

Leider kann diese Formatierung nur englische Namen ausgeben, für lokale Anpassungen sind daher Tricks notwendig, z.B. mit dem days- und months-Array.

Mit diesem kleinen Schummelzettel sollten jetzt die meisten Zeitformate in HA umgewandelt werden können.

[scw2wi]

Da wir gerade beim Thema Unit-Conversion sind.

In den meisten Fällen ist die Einheit von Sensoren ja bekannt und auch fix, dann kann man sie auch sehr einfach umrechnen.

Für den seltenen Fall, dass die Einheit doch dynamisch ist, gibt es jetzt mit dem Unit-Helper auch eine Lösung.

Das sieht dann z.B. so aus:

{{ with_unit('states.sensor.total_energy_kwh') | to_unit('MWh') | round(3) }}

[scw2wi]

Hier noch ein weiterer Beitrag zum Thema Conversion.

Jeder kennt ja die Darstellung relativer Zeiten in HA, z.B auf der Backup Seite: letzte Woche oder vor 11 Monaten.

Auch die Entities-Card beherrscht diese Form der Darstellung, wenn der Sensor als device_class: timestamp gesetzt hat.

Ich hätte mir schon öfters gewünscht, dass es so eine Umwandlung auch im Backend von HA gibt, damit ich das bei meinen Template Sensoren verwenden kann, aber bis jetzt ist sowas nur im Frontend verfügbar.

Das Macro Relative Time Plus kommt zwar schon sehr nah an meine Forderung heran (und kann sogar noch sehr viel mehr), aber die Ausgabe berücksichtigt nicht, ob ein Termin in der Vergangenheit oder Zukunft liegt.

Ich hab nun selbst ein Macro erstellt, das zwar nicht auf dem Time Plus Macro aufbaut, da mir dessen Code um Größenordnungen zu komplex war, dafür aber genau die Ausgabe erzeugt, die ich wollte.

Hier ein Vergleich von HA native (nur im Frontend), Relative Time DE (siehe Attachment) und Relative Time Plus (mit Standard Parametern).

In den meisten Fällen zeige ich den gleichen Text an wie HA, in einigen Fällen gibt es aber Abweichungen.

Testcase	HA native	relative_time_de	relative_time_plus
-1,5min	Vor 1 Minute	vor einer Minute	1 Minute
-22h	Gestern	vor 22 Stunden	22 Stunden
-23,5h	Gestern	gestern	23 Stunden
-5d	Letzte Woche	vor 5 Tagen	5 Tage
-26d	Letzten Monat	vor 4 Wochen	3 Wochen

HA macht den Übergang von einer Einheit zur nächsten (also z.B. von Tagen zu Wochen) sofort bei einem Wochenwechsel, ich erst ab 7 Tagen.

Wer also exakt das Verhalten von HA nachstellen möchte, der muss den Code noch etwas modifizieren.

Sekunden (wie bei der Native-Funktion) zeige ich gar nicht erst an, da HA die Backend-Funktionen ohnehin nur im Minuten-Intervall refreshed.

Relative Time Plus kann übrigens wesentlich mehr, z.B. die Anzeige von: 3 Wochen, 2 Tage und 7 Stunden

Zur Demonstration hab ich auch noch den Code einer simplen Card (AutoBackupStatus) hinzugefügt.

Bei mir liegen alle Macros im File custom_templates/macros.jinja, wer sie woanders liegen hat, muss sie halt von dort importieren.

[scw2wi]

Meine Backup-Manager-Ansicht ist jetzt noch umfangreicher geworden. Ziel war eine kurze Übersicht, ohne auf die Backup-Seite navigieren zu müssen.

Mit 2 command_line Sensoren hole ich mir die Größe des Backup-Folders (in MB) und eine Liste aller Backups darin.

# command_line:

- sensor:
    name: "Backup Folder Size"
    # entity_id: sensor:backup_folder_size
    unique_id: cdd73c80-734d-457b-afad-9f709b2dd17c
    icon: mdi:folder-outline
    unit_of_measurement: "MB"
    state_class: total
    device_class: data_size
    scan_interval: 3600 # 1h
    command: 'curl -X GET -H "Authorization: Bearer $SUPERVISOR_TOKEN" http://supervisor/backups'
    value_template: >
      {% set backups = value_json.data.backups %}
      {% set total_size = backups | map(attribute='size') | sum %}
      {{ (total_size) | round(0) }}​  

- sensor:
    name: "Backup Liste"
    # entity_id: sensor:backup_liste
    unique_id: 6b987c0d-f494-4d59-8970-4ae804731e68
    icon: mdi:file-multiple-outline
    scan_interval: 3600 # 1h
    command: >
      curl -s -X GET -H "Authorization: Bearer $SUPERVISOR_TOKEN" http://supervisor/backups
      | jq '.data.backups |= (sort_by(.date) | reverse | map(.name |= sub("Automatic backup "; "")))'
    value_template: "{{ value_json.data.backups | count }}"
    json_attributes:
      - data
​

Für die Abfrage der Backup-Daten wird die interne API bemüht, da eine direkte Abfrage nicht erfolgreich war.
Die Liste wird bereits absteigend sortiert, damit das nicht in der Card gemacht werden muss.
Wenn der Name mit "Automatic backup" beginnt, dann wird dieser Teil entfernt, das macht die Anzeige kompakter.
Der Hauptstatus des Sensors zeigt die Anzahl der Backups, als Attribut wird eine Liste mit allen Infos gespeichert.

Die Anzeige der letzten 5 Backups übernimmt dann die Flex-Table-Card, den Titel dazu stellt die markdown Card dar.

type: vertical-stack
cards:
  - type: markdown
    content: >
      ## 💾 Backups: {{ states('sensor.backup_liste') }} | Gesamt: {{ states('sensor.backup_folder_size') }} MB
    card_mod:
      style: |
        ha-card {
          margin-bottom: 0px;
          border-bottom: none;
          border-bottom-left-radius: 0px;
          border-bottom-right-radius: 0px;
        }
  - type: custom:flex-table-card
    card_mod:
      style: |
        ha-card {
          margin-top: -20px;
          border-top: none;
          border-top-left-radius: 0px;
          border-top-right-radius: 0px;
        }
    entities:
      - sensor.backup_liste
    columns:
      - name: Name
        data: data.backups
        modify: x.name
      - name: Datum
        data: data.backups
        modify: >
          const d = new Date(x.date); const options = { weekday: 'short', day:
          '2-digit', month: '2-digit', year: 'numeric' };
          d.toLocaleDateString('de-DE', options)
        align: right
      - name: MB
        data: data.backups
        modify: (x.size).toFixed(0)
        align: right
    max_rows: 5
​

Klein, kompakt und übersichtlich sehe ich so, ob mit den Backups alles in Ordnung ist.

Backup-Card.png

[scw2wi]

Wrapper Karten sind Karten ohne eigenes Aussehen, sie verändern das Aussehen anderer Karten.

card_mod setze ich sehr gerne ein, da man damit das Aussehen (fast) aller Karten über CSS statisch oder per Jinja2-Templating auch dynamisch ändern kann. Es ist aber nicht in allen Fällen immer einfach, den passenden Code zu finden, und manchmal gibt es auch Breaking-Changes, wo man dann nachbessern muss. Trotzdem würde ich nur ungern darauf verzichten.

Stacking Karten sind bei mir auch häufig im Einsatz, damit kann man mehrere Karten zu einer verbinden.

Die Standard Karten von HA lauten: Vertical stack card, Horizontal stack card, Grid card und können sehr wenig. Ein großer Nachteil ist, dass man damit den GUI-Mode verliert, auch wenn die gestackten Karten einen hätten.

Wesentlich besser ist die custom Layout Card, die für vertical, horizontal, grid und masonry Layouts verwendet werden kann. Man hat auch direkten Zugriff auf einige Layout Parameter wie z.B. margin, padding und weitere. Auch eine mediaquery Abfrage ist möglich. Wichtig: Die gestackten Karten behalten ihren GUI-Mode.

Teilweise noch besser ist die custom Vertical Stack In Card, die entgegen ihrem Namen sowohl vertical also auch horizontal (aber kein grid) beherrscht. Der Vorteil dieser Karte ist, dass sie sogar versucht, die gestackten Karten optisch zu einer Gesamtcard zu verbinden, wofür sie aber meist noch etwas card_mod Unterstützung benötigt. Trotzdem ist sie für diese Aufgabe am besten geeignet. Sie kann ebenfalls einige Styles direkt setzen (dies jedoch nur im YAML-Mode) und auch noch einen Titel anzeigen.

Es gibt auch noch die 5 Jahre alte custom Stack In Card, wo jedoch wieder der GUI-Mode verloren geht. Das Style kann man nur sehr rudimentär über boolsche Flags beeinflussen, was bei meinem Versuch nicht einmal funktioniert hat. Ich verwende sie daher auch nicht.

Die custom hui-element Card bietet ebenfalls Stacking Möglichkeiten, ich hab mich aber noch nicht mit ihr beschäftigt, vielleicht kann ja jemand anderer seine Erfahrungen berichten.

---

Es gibt noch weitere Anwendungsfälle, eine Wrapper-Card einzusetzen, z.B. wenn die Zielkarte kein Templating beherrscht.

Das Standard-Templating bei HA funktioniert mit Jinja2-Code und die bekannteste Wrapper-Card dazu ist die custom Auto Entities Card.

Sie generiert eine dynamische Liste an Entitäten, die dann von der eingebetteten Entities-Card angezeigt wird. Es muss natürlich nicht zwingend eine Liste sein, man kann sie daher auch als Umschalter verwenden und damit die Conditional-Card ersetzen.

Auch die custom: Mushroom Template Card verwendet Jinja2-Templating, ich würde sie jedoch nicht unbedingt als Wrapper-Card bezeichnen, da sie Standalone viele Möglichkeiten bietet.

Noch häufiger kommt bei HACS JavaScript-Templating vor, da es etwas performanter ist.

Bisher habe ich sehr häufig die custom Button Card eingesetzt, die sowohl als Stacking-Card mit grid Layout und auch als Standalone Card verwendet werden kann. Sie hat auch die gleichen decluttering Möglichkeiten wie die Original custom Decluttering Card, was vor allem dann praktisch ist, wenn man eine Card mit umfangreichem Code mehr als 1x verwenden möchte. Denn der Code steht dann nur 1x vor dem gesamten Dashboard und wird in der Card nur mehr referenziert.

Erst vor kurzem hab ich die custom Config Template Card kennengelernt, entsprechend wenig Erfahrung hab ich bisher damit. Sie ist deutlich mächtiger als die Auto Entities Card, da sie mit jeder Card zusammen arbeitet, nicht nur mit der Entities Card. ChatGPT kennt diese Card und hilft gerne bei der Erstellung des Codes.

Eine weitere Card mit JS-Templating ist die custom Bubble Card, die aber genauso wie die Mushroom-Cards eigentlich keine Wrapper-Card mehr ist. Mit dem Module-Store hat diese Card vor kurzem viele interessante neue Möglichkeiten bekommen, die ich erst einmal erkunden muss. Mein erster Versuch, das Aussehen der Bubble-Card über den Module-Store an das der Mushroom-Card anzupassen war jedenfalls schon mal erfolgreich. Im Code ist das dann ein 2-Zeiler.

modules:
  - home-assistant-default

Ich wollte diese Übersicht der Wrapper-Cards und Template-Cards schon lange mal machen, jetzt war grad der richtige Zeitpunkt dafür, da ich zum Stacken meiner neuen Stockwerke-Card verschiedene Vergleiche gemacht hab.

Update: Hier noch ein Tipp, wie man die Variablen einer Wrapper-Card vor der Verwendung testen kann.

type: custom:config-template-card
entities:
  - input_number.pos
variables:
  - POS: parseInt(states['input_number.pos'].state)
card:
  type: markdown
  content: |-
    ${
      "POS: " + parseInt(states['input_number.pos'].state)
    }
​