Helfer / Blaupause für zwei zu kombinierende Sensoren

[detlan]

Bei mir hat jedes Fenster zwei Sensoren, genauer ein Fenstergriffsensor HmIP-SRH (1) und einen Fensterkontakt HmIP-SWDO-I (2). Der Fenstergriffsensor allein reicht mir nicht, da dieser nur die Griffstellung erkennt. Wird das Fenster aufgehebelt, wird der Griff i.d.R. gar nicht betätigt, das Fenster ist jedoch offen. Jetzt möchte ich gern eine Funktion, vermutlich Helfer, erstellen, welche mir eine Kombination der Zustände als eigenständige Entität darstellt. Dies sind die Bedingungen, die Zahlen 1 und 2 spiegeln den jeweiligen Sensor wieder:

• 1 = geschlossen, 2 = geschlossen => geschlossen
• 1 = geschlossen, 2 = gekippt => angelehnt
• 1 = geschlossen, 2 = offen => angelehnt
• 1 = offen, 2 = geschlossen => Achtung!
• 1 = offen, 2 = gekippt => gekippt
• 1 = offen, 2 = offen => offen

Daraus ergibt sich, dass anstatt drei jetzt ein Helfer für fünf Zustände gebaut werden muss. Nur habe ich keinen Plan wie ich dies realisieren kann, bzw. habe auch nichts dazu finden können.

Wie kann man so etwas realisieren? Vielleicht auch als Blaupause, in welche man für ein Fenster die beiden Sensoren einträgt, welche dann einen entsprechenden Helfer anlegt? Wer kann mir hier weiterhelfen?

Nach längerer Abstinenz bin ich erst jetzt wieder dazu gekommen, mich um eine Home Assistent Installation zu kümmern. Ich habe Home Assistent jetzt auf einem Proxmox Server laufen – meine Server Empfehlung

[Bacardi]

Ich könnte mir unteres als Kern eines Templatesensors vorstellen, wobei Du aber noch die Stati anpassen mußt, je nachdem was die Sensoren wirklich zurückgeben.

{% if is_state('sensor.fenstergriff', 'geschlossen') and is_state('sensor.fensterkontakt', 'geschlossen') %}
  geschlossen
{% elif is_state('sensor.fenstergriff', 'geschlossen') and (is_state('sensor.fensterkontakt', 'gekippt') or is_state('sensor.fensterkontakt', 'offen')) %}
  angelehnt
{% elif is_state('sensor.fenstergriff', 'offen') and is_state('sensor.fensterkontakt', 'geschlossen') %}
  Achtung!
{% elif is_state('sensor.fenstergriff', 'offen') and is_state('sensor.fensterkontakt', 'gekippt') %}
  gekippt
{% elif is_state('sensor.fenstergriff', 'offen') and is_state('sensor.fensterkontakt', 'offen') %}
  offen
{% else %}
  unbekannt
{% endif %}

Das wäre dann pro Fenster ein Sensor.
Mit Blaupausen kenne ich mich leider nicht aus.

Gutes Gelingen

[Osorkon]

Blueprints sind vorgekaute Automatisierungen.

Was Du aber brauchst ist ein Template Sensor, bzw. mehrere Template Sensoren.
Wenn Du vorgekaute Template Inhalte in Deinen templates verwenden willst, dann wären das Macros

Templating

BTW. Template Sensoren dieser Art kannst Du auch ganz bequem in der GUI entstellen als Helfer → Template

Eine Template Vorlage hat @Bacardi ja bereits geliefert.

Gruß
Osorkon

[detlan]

Vielen lieben Dank, dass kann ich so nachvollziehen - prima
Nur wie kann ich dies einer neuen Entität, einem Helfer zuweisen. Aktuell steht das Ergebnis in der Luft. Die Automation muss ja von selbst anspringen, wenn Fenstergriff oder -Kontakt eine Änderung erfahren und dann das Ergebnis irgend wo speichern?

[detlan]

@Osorkon

Template Sensoren dieser Art kannst Du auch ganz bequem in der GUI entstellen als Helfer → Template

Oh, dass wuste ich garnicht, dass gucke ich mir mal an. Hört sich ersteinmal einfach an

[Bacardi]

@detlan

Aktuell steht das Ergebnis in der Luft. Die Automation muss ja von selbst anspringen, wenn Fenstergriff oder -Kontakt eine Änderung erfahren

Das kannst Du doch dann als Trigger definieren

platform: state
entity_id:
  - binary_sensor.fenster1
from: "geschlossen"
to: "offen"

Die Stati müssen von Dir noch angepaßt werden

[alexsaas]

M. E. nach ist eine Automatisierung nicht nötig.

Wie @Osorkon schon schrieb:
Helfer > Template > Template für einen Sensor erstellen und den Template Code von @Bacardi dort einfügen, dann natürlich noch den Namen der Sensoren und den jeweils korrekten state eintragen.

Der Template Sensor überwacht die im Template Code verwendeten Sensoren und setzt automatisch den entsprechenden state für den (Helfer) Template Sensor.

Natürlich müsste so je Fenster ein eigener Template Sensor angelegt werden.

[Osorkon]

Um auf das Thema Template Vorlagen bzw. Macros zurück zukommen.

Das könnte dann z.B so aussehen.

Das macro liegt im Ordner config/custom_templates

#window.jinja
{% macro window_entity(window_handle, contact_sensor) %}
{% if states(window_handle) == "closed" and states(contact_sensor) == "off" %}
Geschlossen
{% elif states(window_handle) == "tilt" and states(contact_sensor) == "off" %}
Angelehnt
{% elif states(window_handle) == "closed" and states(contact_sensor) == "on" %}
Achtung!
{% elif states(window_handle) == "tilt" and states(contact_sensor) == "on" %}
Gekippt
{% elif states(window_handle) == "open" and states(contact_sensor) == "on" %}
Offen
{% else %}
Unbekannt
{% endif %}
{% endmacro %}

Das Template für den Template Sensor sieht dann so aus.
Musst nur noch die jeweiligen Entitäten für den Fenstergriff und den Kontaktsensor angeben.

{% from 'window.jinja' import window_entity %}
{{ window_entity('sensor.fenstergriff_bad', 'binary_sensor.fenster_bad') }}

Ob der Fenstergriff Sensor bei Dir auch die Staus open, closed und tilt ausgeben, weiss ich nicht, ggf. musst Du diese noch anpassen.

Nach dem du ein neues macro erstellt hast, musst Du ALLE Konfigurationen neu laden, oder einfach Home Assistant Neustarten.

Hier ein weiteres Bsp. für ein macro “Wetter Bedingungen”

Gruß
Osorkon

[detlan]

Vielen lieben Dank an @Bacardi und @Osorkon, Ihr habt meinen Wunsch Wirklichkeit werden lassen. Hätte ich mir die letzte Nacht sparen können, wenn ich gleich gefragt hätte

Macro für Fenstergriff (HmIP-SRH) & Fensterkontakt (HmIP-SWDO-I):

#window.jinja
{% macro window_entity(window_handle, contact_sensor) %}
{% if states(window_handle) == "closed" and states(contact_sensor) == "off" %}
Geschlossen
{% elif states(window_handle) == "tilted" and states(contact_sensor) == "off" %}
Angelehnt
{% elif states(window_handle) == "open" and states(contact_sensor) == "off" %}
Angelehnt
{% elif states(window_handle) == "closed" and states(contact_sensor) == "on" %}
Sabotage
{% elif states(window_handle) == "tilted" and states(contact_sensor) == "on" %}
Gekippt
{% elif states(window_handle) == "open" and states(contact_sensor) == "on" %}
Offen
{% else %}
Unbekannt
{% endif %}
{% endmacro %}

Template für Fenstergriff (HmIP-SRH) & Fensterkontakt (HmIP-SWDO-I):

{% from 'window.jinja' import window_entity %}
{{ window_entity('sensor.treppenabsatz_fenstergriff', 'binary_sensor.treppenabsatz_fenster') }}

Ich habe noch eine Abwandlung erstellt, um unsere Haustür inkl. Türschloss abzubilden.

Macro für Türkontakt (HmIP-SWDO-PL) + Türschloss (HmIP-SCI):

#door.jinja
{% macro door_entity(contact_sensor1, contact_sensor2) %}
{% if states(contact_sensor1) == "off" and states(contact_sensor2) == "off" %}
Verschlossen
{% elif states(contact_sensor1) == "off" and states(contact_sensor2) == "on" %}
Geschlossen
{% elif states(contact_sensor1) == "on" and states(contact_sensor2) == "off" %}
Sabotage
{% elif states(contact_sensor1) == "on" and states(contact_sensor2) == "on" %}
Offen
{% else %}
Unbekannt
{% endif %}
{% endmacro %}

Template für Türkontakt (HmIP-SWDO-PL) + Türschloss (HmIP-SCI):

{% from 'door.jinja' import door_entity %}
{{ door_entity('binary_sensor.haustur', 'binary_sensor.haustur_verschluss') }}

[Osorkon]

Nur um sicherzustellen, dass Du es nicht missverstanden hast.

Ein macro würde ich nur nutzen, wenn ein und das gleiche Template wiederholt Verwendung findet. So kannst Du es immer wieder verwenden ohne immer dutzende Zeilen neu schreiben zu müssen. Auch bittet es den Vorteil, dass eine Änderung des macros bei allen Templates die das macro verwenden übernommen werden.

Für einen einzelnen Template Sensor, macht es eher wenig Sinn und Du kannst gleich direkt das Template verwenden ohne den Umweg über das macro.

Gruß
Osorkon

[detlan]

Habe Dich schon verstanden. Habe es so gemacht, wie Du bereits weiter oben geschrieben hattest - mehrere Templates greifen auf ein und dasselbe Makro zu.

Für die Haustür habe ich auch ein Makro erstellt, auch wenn ich hier aktuell nur ein Template habe. So kann ich später bei Bedarf dann bereits darauf zugreifen. Oder belastet dies das System unnötig?

[Osorkon]

@detlan

Oder belastet dies das System unnötig?

Keineswegs, dafür ist das System designed worden.

So viele templates kannst gar nicht erstellen, damit sich dieser Performance technisch negativ auswirken.

Gruß
Osorkon

[detlan]

Darf ich noch mal eine Frage loswerden? Mir ist gerade folgendes aufgefallen:

Ich habe mit dem Template ja eine neue Sensor-Entität erstellt. Aber wenn ich jetzt über die UI eine Abfrage stelle, dann werden die verfügbaren Werte gar nicht aufgezählt. Ich habe “Template für einen Sensor erstellen” gewählt. Was mache ich falsch? DANKE

[Bacardi]

Versuch doch mal im YAML Code direkt den State zu schreiben.
Im unteren Beispiel wäre das das Wort “sommer” (Groß-/Kleinschreibung beachten). Wird bei mir in der UI der Bedingungskarte auch nicht angezeigt aber es funktioniert.

type: conditional
conditions:
  - condition: state
    entity: sensor.jahreszeiten_ventilator_steuerung
    state: sommer
card:
...

[detlan]

Danke, aber ich hatte nicht zu Ende gedacht.

Für Abfragen in der UI kann ich einfach die beiden einzelnen Sensoren nehmen:

Für die Darstellung auf dem Dashboard, dann den erstellten Sensor:

        - type: custom:mushroom-template-card
          entity: sensor.wc_fensterstatus
          primary: Fenster
          secondary: '{{ states(entity) }}'
          icon: |-
            {% set mode = states(entity) %}
            {% if mode == 'Geschlossen' %}
            phu:lift-in-window-closed
            {% elif mode == 'Angelehnt' %}
            phu:lift-in-window-closed
            {% elif mode == 'Sabotage' %}
            mdi:alert
            {% elif mode == 'Gekippt' %}
            phu:lift-in-window-open1
            {% elif mode == 'Offen' %}
            phu:lift-in-window-open2
            {% else %}
            mdi:alert-box
            {% endif %}
          icon_color: |-
            {% set mode = states(entity) %}
            {% if mode == 'Geschlossen' %}
            disabled
            {% elif mode == 'Angelehnt' %}
            orange
            {% elif mode == 'Sabotage' %}
            red
            {% elif mode == 'Gekippt' %}
            purple
            {% elif mode == 'Offen' %}
            pink
            {% else %}
            blue
            {% endif %}

[Osorkon]

Die vorauswahl der Zustände gibt es nur für Entitäten mit einer defienrten Dvice Class. Du hast dagegen einen Template Sensor erstellt, mit von Dir frei definierten Zuständen. Als Zustand tippst Du einfach einen der Zustände, den Du für den Sensor definiert hast. Groß- und Kleinschreibung beachten!

Wäre ja ziemlich sinn frei, wenn Template Sensoren sich nicht genau so in Automatisierungen, Skripten oder eben auch nicht Karten verwenden ließen.

Gruß
Osorkon

[detlan]

Ich wusste gar nicht, dass man in das Feld auch einen eigenen Wert eintippen kann. Funktioniert perfekt. Danke!

[detlan]

Ich hätte da noch eine Anschlussfrage, wie kann ich Icon und Farbe nach Zustand ändern? Aktuell nutze ich Mushroom dafür, möchte aber von den externen Templates weg. Hat da jemand eine Idee?

- type: custom:mushroom-template-card
          entity: sensor.wc_fensterstatus
          primary: Fenster
          secondary: '{{ states(entity) }}'
          icon: |-
            {% set mode = states(entity) %}
            {% if mode == 'Geschlossen' %}
            phu:lift-in-window-closed
            {% elif mode == 'Angelehnt' %}
            phu:lift-in-window-closed
            {% elif mode == 'Sabotage' %}
            mdi:alert
            {% elif mode == 'Gekippt' %}
            phu:lift-in-window-open1
            {% elif mode == 'Offen' %}
            phu:lift-in-window-open2
            {% else %}
            mdi:alert-box
            {% endif %}
          icon_color: |-
            {% set mode = states(entity) %}
            {% if mode == 'Geschlossen' %}
            disabled
            {% elif mode == 'Angelehnt' %}
            orange
            {% elif mode == 'Sabotage' %}
            red
            {% elif mode == 'Gekippt' %}
            purple
            {% elif mode == 'Offen' %}
            pink
            {% else %}
            blue
            {% endif %}

[bigmirror]

Wenn du den Sensor in der configuration.yaml definierst, dann kannst du das Icon genauso wie den state per Template definieren.
Ob das auch mit der icon_color geht, weiß ich nicht.

[detlan]

Wie würde das aussehen? Könntest Du bitte ein Beispiel geben?

Ich habe hier was gefunden, blicke ich aber nicht durch.