HACS Sonne & Mond

[scw2wi]

Nachdem ich hier bereits meine HACS Wetterkarte vorgestellt habe folgt nun eine andere Dashboard-Darstellung, die sogar noch schneller fertig war.

HA-Sonne-Mond.png

Den Sonnenverlauf zeigt die horizon-card mit den Standard-Einstellungen.
Die Mondphasen werden von der lunar-phase-card dargestellt, mit compact_view: true

Die Sun Integration wird von HA automatisch installiert, eine Moon Integration gibt es im Store, sie kann aber recht wenig (eigentlich fast gar nichts).
Die wesentlich umfangreichere Lunar Phase Integration, die für die obige Card notwendig ist, muss über ein Custom-Repository installiert werden.

Damit der typ in der Liste nach dem Import auch korrekt angezeigt wird, muss er entsprechend ausgewählt werden: Template | Dashboard (lovelace) | Integration | Theme

Leider ist die Horizon Card so wie viele andere HACS cards nur in YAML editierbar. Es gibt hier im Forum Leute, die das gleich als KO-Kriterium werten. Ich sehe das weniger kritisch.

Den UI-Mode verwende ich bei einer neuen Karte zwar auch recht gerne, um sie mal mit ihren wichtigsten Optionen kennenzulernen,
spätestens wenn ich dann aber versuche, die Icon-Farbe oder Schriftgröße zu verändern, ist der Umstieg auf YAML Code notwendig.
Selbst bei einigen Cards mit UI bietet der UI-Mode auch nur eine Auswahl der möglichen Optionen, der Rest ist dann auch nur wieder über YAML erreichbar.
In manchen Fällen lasse ich mir die Karte auch von ChatGPT konfigurieren und auch dann ist die Bearbeitung in YAML die beste Lösung.

Wie ich bei all den vielen HACS Cards die Icon-Farbe oder Schriftgröße anpassen kann, funktioniert gefühlt bei jeder Card anders.
ChatGPT ist leider oft genauso verloren wie ich, der generierte Code funktioniert in den wenigsten Fällen ohne Anpassung.
Es ist sogar noch schlimmer, dadurch dass HA öfters mal die Struktur des YAML Codes ändert, bessert ChatGPT mir sogar meinen richtigen Code auf alten legacy code aus, hier ein Beispiel.

neue Syntax:
triggers:
- trigger: trigger_name

alte legacy Syntax:
triggers:
- platform: trigger_name

Aktuell funktioniert zwar noch beides, Studio Code Server zeigt es aber trotzdem rot an mit dem Hinweis: String does not match the pattern of "LEGACY_SYNTAX^".

Noch ein Tipp: Wer immer noch seine configuration.yaml mit dem File Editor bearbeitet sollte sich einen Umstieg auf den Studio Code Server überlegen, es geht einfach alles viel flotter.

Er zeigt eine wesentlich übersichtlichere Ordner Struktur, viel bessere Warnungen bei falschem oder legacy code, hat eine Auto-Save Funktion, und er kann das bei YAML so wichtige indenting (also die Einrückung) fehlerfrei.

Block markieren und mit TAB oder SHIFT+TAB um 2 char nach rechts oder links verschieben, der File Editor verschiebt hier gerne mal um 4 char, was unbrauchbar ist.

Da wir gerade bei der configuration.yaml sind. In meiner stehen nur include statements, sonst nichts. Damit bleibt dieses File (und auch alle anderen) immer schön übersichtlich.

Hier ein Auszug:

cover: !include covers.yaml
input_boolean: !include input_booleans.yaml
input_number: !include input_numbers.yaml
input_select: !include input_selects.yaml
light: !include lights.yaml
notify: !include notify.yaml
sensor: !include_dir_merge_list sensors/ # Einbettung aller files aus dem Ordner "sensors"
template: !include templates.yaml

In den include files habe ich mir angewöhnt, neue Blöcke oben anzufügen statt unten, denn dort editiere ich ja am meisten, darüber steht bei längeren Files ein Inhaltsverzeichnis, auch das erhöht die Übersichtlichkeit.

Aufpassen! Im include file fehlt das Schlüsselwort, also kein cover: mehr im covers.yaml
Um sicher zu sein, dass ich dir_merge_list nicht mit dir_merge_named verwechsle, hilft mir diese Anleitung: Splitting up the configuration

Das werden natürlich noch viel mehr includes, aber ich bin ja erst am Anfang und kratze bei HA gerade mal an der Oberfläche.

Hinweis: Es gibt noch eine weitere Möglichkeit, include-Files zu strukturieren, das ist über Packages. Da ich dazu aber noch keine Erfahrung habe, kann ich noch nicht aus der Praxis darüber berichten.


Hier geht's zum nächsten Beitrag:

HACS Schieberegler (inkl. Möglichkeiten der Icon Farbanpassung & erste Vorstellung Farbschema)

hier zur HA Kurzeinführung
und hier zur Liste aller Beiträge dieser Serie

[scw2wi]

Achtung: Beim Default-include gibt es eine Falle, in die ich erst jetzt getappt bin.

Ich hab bis heute noch nie eine Automation, ein Script oder Scene über das UI erstellt, da mir das einfach zu aufwändig war.
Heute hab ich meine erste UI-Automation erstellt, da ich nur dafür eine Beschreibung gefunden habe.

Was passiert in so einem Fall?

Alle meine manuellen Automationen (und das waren viele) werden im automation.yaml File neu geschrieben und alle Kommentarzeilen werden sauber (und dauerhaft) entfernt.

Na super!

Bin ich froh, dass mein letztes Backup brandaktuell war. Restore läuft gerade.

Man kann dieses Desaster auch ganz einfach verhindern, wenn man vorher dran denkt, und so geht's.

Der Default-Eintrag in configuration.yaml lautet so

automation: !include automations.yaml

und den ändert man einfach auf:

automation: !include automations.yaml
automation manual: !include_dir_merge_list automations_manual/

automations.yaml gehört HA und dort landen alle GUI-Automationen (natürlich ohne Kommentare)

Der Folder automations_manual/ gehört dem YAML-Programmierer und das hat gleich noch einen weiteren Vorteil, denn jetzt kann man seine Automationen auch noch in mehrere Files übersichtlich aufteilen.

Das gleiche macht man dann auch noch mit scripts und scenes und dann sollte niemandem hier mehr das passieren was ich gerade erlebt habe.

Und während ich das hier tippe läuft mein Restore immer noch, aber falls da was schief geht hab ich auch noch einen Snapshot der VM.

Update zum Restore:
Ich hab zwar schon einmal einen HA-Restore-Test gemacht, der ging damals auch glatt durch, dieses HA-Restore ist aber über die ganze Nacht gelaufen und war dann trotzdem (zumindest laut Dialog) noch nicht fertig. In einem Parallel-Window hat das Dashboard wieder vollständig funktioniert, der Folder homeassistant/ war aber komplett leer. Ein Restart von HA hat nicht geholfen, ein Restart der VM hat geholfen. Jetzt ist wieder alles Up&Running. Leider zeigt der Restore-Dialog absolut keine Info was da gerade läuft.

Update zum Include:
Ich hab jetzt auch meine (wenigen) Integrationen mit YAML-Config übersichtlich ausgelagert, das sieht dann z.B. so aus:

influxdb: !include integrations/influxdb.yaml

Nur logger und recorder sind weiterhin in der configuration.yaml, damit ich sie im Fokus behalte.

=> siehe dazu auch eine alternative Aufteilung über Packages von Tom Bombadil Verwendung von Packages

[Noschvie]

Sind ja super, coole Ideen, die du umsetzt und hier teilst!
Nur aus Neugierde: in welcher Umgebung läuft deine HA VM ?

[scw2wi]

Aktuell spiele ich nur mit HA und hab es auf meinem Windows-PC im Hyper-V-Manager tagsüber laufen.

Geplant ist ein ASUS NUC mit N100 CPU und Proxmox, davon dann 2 Stk für Produktiv und Fallback.

Dieses Setup wird auch noch spannend werden und ich stelle es hier sicher auch vor, sobald es läuft.

[Noschvie]

Proxmox, davon dann 2 Stk für Produktiv und Fallback

unkompliziert, praktisch und nützlich :-)

[scw2wi]

Es gibt ja viele Karten zur Darstellung des Sternenhimmels. Ich hab aktuell den AstroViewer bei mir eingeblendet, eine andere Möglichkeit wäre ha_skyfield.

Vor kurzem bin ich dann über eine minimalistische Darstellung der Planeten gestolpert, die ich mit Hilfe des Autors jetzt nachgebaut habe.

HACS - Sonne, Mond und Planeten mit der plotly-graph Card.png

Sonne und Mond zeigen den Verlauf, die Planeten zeigen nur die Position. In der Nacht ist die Karte daher etwas weniger "schön", dafür aber interessanter.

Als Basis wird die plotly-graph Card mit type: scatter eingesetzt, aber ganz so einfach ist es dann doch wieder nicht.

Es sind schon ein paar Schritte notwendig, um zum Ziel zu kommen, aber mich hat es gereizt, wieder mal was Neues (in diesem Fall den command_line sensor) kennenzulernen.

Hier die Schritte im einzelnen, für jene, die das nachbauen wollen.

Schritt 1:

Auf der Seite AstronomyAPI zuerst mal einen User erstellen und dann am Dashboard eine Applikation registrieren.

Aus Application-Id und Application-Secret erstellt man dann den später benötigten API-Key.

Auf der Website sind mehrere Wege beschrieben, wie das geht, ich hab einfach das Terminal in Studio Code Server dafür verwendet:

echo -n "Application-Id:Application-Secret" | base64

Das Ergebnis wird zwar mehrzeilig ausgegeben, wir benötigen den Key dann aber in einer einzigen Zeile.

Schritt 2:

Für meinen ersten command_line Sensor hab ich das File command_line.yaml erstellt und in configuration.yaml eingebunden.

command_line: !include command_line.yaml

Hier nun der Sensor

# command_line:
sensor:
  name: Planetary Positions
  # sensor.planetary_positions
  unique_id: a990f402-e5bf-4d70-9cae-63b22fba786a
  command: >
      curl -X GET 'https://api.astronomyapi.com/api/v2/bodies/positions?latitude=BREITENGRAD&longitude=LÄNGENGRAD&elevation=HÖHE&from_date={{ now().date() }}&to_date={{ now().date() }}&time={{ now().strftime('%H:%M:%m') }}'
      -H 'Authorization: Basic API-KEY'
      | jq '{"planets": .[].table.rows}'
  value_template: "{{ now().isoformat(timespec='seconds') | as_datetime }}"
  json_attributes:
      - planets
  scan_interval: 600 # 10 min

Wer wissen möchte, was der Befehl genau macht: Copy&Paste zur nächsten KI liefert die exakte Beschreibung, daher spare ich mir das hier.

Achtung: Die Parameter BREITENGRAD, LÄNGENGRAD, HÖHE, API-KEY muss hier jeder selbst einsetzen, und beim API-KEY das Hochkomma am Ende nicht löschen!

Schritt 3:

Ich hab diesen Sensor noch in einzelne Template-Sensoren zerlegt. Der Autor der Original-Card hat das etwas anders gelöst, da die plotly-graph Card auch auf Attribute zugreifen kann. Der Status eines Sensors ist jedoch auch in der History besser sichtbar, daher hab ich diese Lösung gewählt.

Für Sonne, Mond und jeden sichtbaren Planeten hab ich 2 Template-Sensoren (jeweils für Altitude und Azimuth) erstellt. Da der Code aber immer derselbe ist, bietet es sich an, diesen in ein Makro auszulagern.

custom_templates/macros.jinja

{% macro get_astro_position (planet_name, field) %}
  {# holt das field altitude oder azimuth aus dem command_line sensor Planetary Positions #}
  {% set planets = state_attr('sensor.planetary_positions', 'planets') %}
  {% if planets is not none %}
    {% for p in planets %}
      {% if p.entry.name == planet_name %}
        {% for c in p.cells %}
          {% if c.name == planet_name %}
            {{ c.position.horizontal[field].degrees | float }}
          {% endif %}
        {% endfor %}
      {% endif %}
    {% endfor %}
  {% else %}
    unknown
  {% endif %}
{% endmacro %}

template_sensors.yaml

- sensor:
    - name: "Astro Position Mercury Altitude"
      unique_id: 3dd7bb91-8405-466b-880d-8ccdbbe696c6
      icon: mdi:sun-angle
      unit_of_measurement: "°"
      state_class: measurement
      availability: "{{ states('sensor.planetary_positions') not in ['unknown', 'unavailable'] }}"
      state: >
        {% from 'macros.jinja' import get_astro_position %}
        {{ get_astro_position ('Mercury','altitude') }}
    - name: "Astro Position Mercury Azimuth"
      unique_id: 89758bda-b76a-4260-99f6-23b69b832988
      icon: mdi:sun-compass
      unit_of_measurement: "°"
      state_class: measurement
      availability: "{{ states('sensor.planetary_positions') not in ['unknown', 'unavailable'] }}"
      state: >
        {% from 'macros.jinja' import get_astro_position %}
        {{ get_astro_position ('Mercury','azimuth') }}

Dieser Sensor wiederholt sich jetzt einfach für Sun, Moon, Venus, ...
Achtung: Die unique_id sollte man besser nicht wiederholen, sonst ist sie nicht mehr unique - ist mir selbst passiert.

Schritt 4:

Jetzt können wir endlich die Card bauen.

Hier nur ein Teil vom Code, die gesamte Card ist im Unicode-File attached.

type: custom:plotly-graph
hours_to_show: 12
entities:
  - entity: sensor.astro_position_moon_azimuth
    internal: true
    fn: $fn ({ ys, vars }) => vars.astro_position_moon_azimuth = ys
  - entity: sensor.astro_position_moon_altitude
    internal: true
    fn: $fn ({ ys, vars }) => vars.astro_position_moon_altitude = ys
  - entity: ""
    x: $fn ({ ys, vars }) => vars.astro_position_moon_azimuth
    "y": $fn ({ ys, vars }) => vars.astro_position_moon_altitude
    mode: lines+markers
    text: Moon
    name: 🌙 Moon
    line:
      color: cyan
      width: 3
    marker:
      color: cyan
      size: 4
    type: scatter
title: ""
raw_plotly_config: true
config:
  displayModeBar: false
layout:
  annotations:
    - alias: moon
      text: |
        $ex (function() {
          const phase = hass.states["sensor.moon_phase"].state;
          const symbols = {
            "new_moon": "🌑",
            "waxing_crescent": "🌒",
            "first_quarter": "🌓",
            "waxing_gibbous": "🌔",
            "full_moon": "🌕",
            "waning_gibbous": "🌖",
            "last_quarter": "🌗",
            "waning_crescent": "🌘"
          };
          return symbols[phase] || "🌙";
        })()
      x: $ex hass.states["sensor.astro_position_moon_azimuth"].state
      "y": $ex hass.states["sensor.astro_position_moon_altitude"].state
      font:
        size: 25
      showarrow: false
  showlegend: false

Da die Card zu groß für mein Übersichts-Dashboard ist, ich sie dort aber auch haben wollte, hab ich sie noch etwas kleiner gemacht und via custom:swipe-card mit meiner oben bereits vorgestellten custom:horizon-card kombiniert.