HACS - Bewässerung

[scw2wi]

Rechtzeitig vor Masifis Präsentation seines GardenControl bin ich soweit, meine Arbeit der letzten Wochenenden vorzustellen.
Da es in KNX scheinbar nicht so einfach ist, eine Sequenz zu erstellen, hab ich diese Aufgabe in HA ausgelagert.
Es gibt zwar Lösungen auf Basis des OpenKNX Logik-Moduls mit gegenseitigen Verriegelungen zur Vermeidung von Überlappungen,
aber das sind im Vergleich zu der Sequenz die ich im Kopf hatte nur umständliche Workarounds, die ich vermeiden möchte.

Damit die Posts hier übersichtlich bleiben, werde ich die gesamte Beschreibung aufteilen.

Teil 1: Beschreibung der Smart-Irrigation Integration
Teil 2: Beschreibung der erstellten Variablen (bzw. Entitäten)
Teil 3: Beschreibung der Automation
Teil 4: Beschreibung der Cards

Die Kernfrage, die ich mir gestellt habe ist, was muss mein Code alles können.

• Ich möchte die Anzahl der Zonen möglichst dynamisch handhaben. Nicht weil sie sich so oft ändern können, sondern weil es den Code übersichtlicher und wartbarer macht, wenn man Wiederholungen vermeidet.
• Ich möchte je Monat und auch je Zone definieren, wie viel ich sprengen möchte und wie oft pro Woche gesprengt werden soll.

Allein die letzte Forderung machte mir klar, dass ich ohne eine übersichtliche Verwaltung der benötigten Variablen rasch den Überblick verlieren könnte, aber ich hab Lösungen gefunden, die mich überzeugt haben.

Update: Da die Frage weiter unten aufgekommen ist, hier einige weitere Lösungen, die ich (obwohl sie im Prinzip nicht schlecht sind) wieder verworfen habe: Irrigation-V5, Irrigation Unlimited

Basis meines Entwurfs war das Video von Simon42, wo er eine Smart-Irrigation Integration verwendet, die in der Lage ist, die optimale Bewässerungsdauer basierend auf dem ETo zu ermitteln.
ETo - Referenz-Evapotranspiration / Referenzverdunstung

Es ist jedoch mMn nicht wirklich notwendig, diese Integration einzusetzen. Ich könnte mir vorstellen, stattdessen auch eine eigene Logik zu entwickeln, wenn ich Zeit dazu habe. Aktuell setzt meine Lösung zwar noch darauf auf, das könnte sich aber im Laufe der Zeit noch ändern.

Mittlerweile gibt es diese Integration in der V2, hier die Diskussion in der Community dazu.

Nach der Installation über den HACS und einem Neustart von HA kann man die Integration hinzufügen, ich verwende die Anbindung an OpenWeatherMap. Es wird eine neue Page hinzugefügt mit folgenden Tabs: Allgemein, Zonen, Module, Sensor-Gruppen, Hilfe

Automatische Aktualisierung der Wetterdaten:
Die Wetterdaten sollte man nicht viel häufiger als 1x pro Stunde laden, sonst wird es irgendwann mal kostenpflichtig, 1000 API-Calls pro Tag sind aber frei.

Automatische Berechnung der Bewässerungsdauer: hab ich auf 23 Uhr belassen
Automatisches Löschen der Wetterdaten: hab ich auf 23:59 belassen

Bei Zonen hab ich testhalber mal 2 Zonen angelegt, da das OpenKNX Garden-Control 12 Zonen ansteuern kann, hab ich da noch einiges an Reserve.
Mein Code ist an den meisten Stellen dynamisch und zeigt automatisch so viele Felder an, wie es Zonen gibt. Nur das Variablen-Set dazu muss man händisch kopieren.
Für jede Zone wird ein Sensor erstellt mit dem Namen: sensor.smart_irrigation_<Name der Zone>

HACS Bewässerung - Zone01.png

Um die Erstellung des Triggers zu vereinfachen, vergebe ich definierte Sequenz-Namen in der Form: Zone01, Zone02, ...
Leider kann man den sensor.name und den sensor.friendly_name nicht getrennt voneinander definieren, sonst wäre es deutlich einfacher, die Übersicht zu behalten, indem der Friendly_Name einen sprechenden Namen bekommt.

Achtung: Die Zonen müssen zwingend immer Zone01, Zone02, usw. benannt werden. Mein gesamter Code baut auf diesen Namen auf!

Die Drainage Rate ist mit 50,8 mm/h (2 Zoll pro h) vorbestückt, sollte aber eigentlich am Anfang besser auf 0 gesetzt und nur vorsichtig erhöht werden. Viele Böden haben z.B. nur 5 mm/h und daher viel weniger als die vorbestückten 50.

Der Vorrat wird eigentlich durch die Regenmenge berechnet (oder gemessen), aber der maximale Vorrat ist mit 50 mm wieder sehr hoch vorbestückt. Laut Doku soll je nach Boden (Sand/Lehm) ein Wert von 12 bis 30 mm passender sein.

Lead Time wird benötigt, wenn eine Pumpe zuerst noch den Wasserdruck aufbauen muss.
Maximale Dauer von 3.600 Sekunden entspricht 1 h, die Bewässerungsdauer wird immer in Sekunden ermittelt.
Der Multiplikator sollte den Bewuchs berücksichtigen, empfohlen ist ein Wert von 0,6 bis 0,8 (hier nimmt HA jetzt mal das deutsche Komma-Zeichen), den optimalen Wert muss man wohl erst ermitteln.
Ich verwende diesen Wert als Max-Wert, der dann noch je Monat mit einem zusätzlichen Faktor von 0 bis 100% weiter reduziert werden kann.
Die Dauer wird dann wieder berechnet, leider werden die berechneten Felder nicht speziell gekennzeichnet.

Es gibt 4 Aktionen für alle Zonen:

Alle Zonen aktualisieren: Aktualisierung der Wetterdaten
Alle Zonen berechnen: erfolgt per Default-Einstellung automatisch um 23 Uhr
Alle Vorräte zurücksetzen
Alle Wetterdaten löschen

und unterhalb von jeder Zone auch noch Buttons für Einzel-Aktionen:

Wetterdaten aktualisieren
Bewässerungsdauer berechnen: Achtung, in diesem Fall werden die Wetterdaten für die Sensorgruppe dieser Zone gelöscht!
Vorrat zurücksetzen: erfolgt per Trigger nach jeder Bewässerung
Löschen

Berechnungs-Module muss man nicht so viele erstellen, da man jedes Modul gleich für mehrere (oder alle) Zonen verwenden kann.
Es gibt 3 verschiedene Modul-Typen, wobei PyETO (das ist die Python Library für ETo) sicher die interessanteste ist.
Im Prinzip geht es darum, die Verdunstungsrate auf Basis von Temperatur, Sonneneinstrahlung oder anderen Faktoren zu ermitteln.

Ich hab den Artikel bisher noch nicht durchgelesen: FAO Irrigation and Drainage Paper No. 56

Coastal: für einen Standort in Küstennähe
Solrad behavior - steht wohl für Solar radiation (also Sonneneinstrahlung) und diese kann unterschiedlich ermittelt werden.
Basierend auf der Temperatur, den Sonnenstunden, Sonnenstunden & Temperatur,
nicht berechnet (das ist jetzt etwas missverständlich und meint eigentlich gemessen, denn in diesem Fall ist ein Sensor-Wert dafür notwendig)
Forecast days: Das kommt jetzt darauf an, wie sehr man seiner Wettervorschau trauen kann, ich halte 1 Tag bereits für gewagt.

Die Sensorgruppen sind für mich auf den ersten Blick mal etwas unübersichtlich, aber wer einzelne Feuchtesensoren einsetzt, der wird wohl nicht um sie herumkommen, auch wenn der Luftdruck und viele andere Werte bei jeder Gruppe gleich sind.
Trotz der Unübersichtlichkeit kann man erkennen, dass nur 2 Werte nicht vom Wetterservice abhängen, und das sind Verdunstung und Sonnenstrahlung.
Die Verdunstung benötigt man nur dann, wenn man ein Modul vom Typ Passthrough einsetzt.
Die Sonnenstrahlung könnte eigentlich eine KNX-Wetterstation liefern, wenn nicht, wird auch diese laut Modell ermittelt.
Ich hab jetzt einfach mal jede Zone mit dem PyETO-Modul und der Standard-Sensorgruppe verbunden.

Zusätzlich zu den Sensoren, die für jede Zone erstellt werden, gibt es noch 8 Services:

update_zone / all_zones: Aktualisiert die Wetterdaten, hab ich bisher noch nicht verwendet.
calculate_zone / all_zones: Zur Berechnung von Zonen - erfolgt per Default-Einstellung eigentlich automatisch um 23 Uhr
set_bucket / all_buckets: Damit könnte man den gespeicherten Vorrat auf einen bestimmten Wert setzen.
reset_bucket / all_buckets: Damit wird der gespeicherte Regen-Vorrat gelöscht, was nach jeder Bewässerung (per Trigger) erfolgen soll.

Beispielcode:

service: smart_irrigation.reset_bucket
data: {}
target:
  entity_id: sensor.smart_irrigation_zone01

Zusätzlich zu diesen Services wird auch noch ein Event erstellt: smart_irrigation_start_irrigation_all_zones
Wenn man mit diesem Event startet, dann wird die Bewässerung aller Zonen genau zum Sonnenaufgang fertig.
Da man die Automation zum Start der Bewässerung ohnehin selbst erstellen muss, kann man natürlich auch beliebig früher starten.

[scw2wi]

Die Integration aus Teil 1 liefert mir nur die empfohlene Bewässerungsdauer, kümmert sich aber nicht um die Häufigkeit der Bewässerung.
Teil 2 beschreibt, welche Variablen ich noch zusätzlich definiert habe, um für jede Zone eine Häufigkeit und Dauer auch in Abhängigkeit der Jahreszeit festlegen zu können.

input_number.irrigation_number_of_zones => Anzahl der Zonen

input_boolean.irrigation_enabled_global => globaler Ein/Aus-Schalter
input_boolean.irrigation_enabled_zone01 => Ein/Aus-Schalter je Zone
input_boolean.irrigation_enabled_zone02 => Ein/Aus-Schalter je Zone

input_number.irrigation_factor_mar_zone01 => Faktor für Zone 1 der Bewässerungs-Dauer für März
input_number.irrigation_factor_apr_zone01 => Faktor für Zone 1 der Bewässerungs-Dauer für April

input_boolean.irrigation_schedule_mar_mon_morning_ zone01 => Aktivierung der Zone 1 für Montag morgen im März
input_boolean.irrigation_schedule_mar_mon_evening_ zone01 => Aktivierung der Zone 1 für Montag abends im März
usw. für alle Zonen, alle Wochentage und alle Monate bis November (Dez, Jan, Feb bleiben bei mir ohne Bewässerung)

Angedacht hatte ich auch noch folgende Variablen, das ist bis jetzt aber noch nicht umgesetzt.
input_boolean.irrigation_skip_holidays_global => Feiertage global auslassen
input_boolean.irrigation_skip_holidays_zone01 => Feiertage für Zone 1 auslassen
input_number.irrigation_skipped_holidays_zone01 => Anzahl der übersprungenen Feiertage je Zone

Wenn man sich also ausrechnet, wie viele Variablen ich benötige, dann wird rasch klar, dass dafür ein gutes Konzept hilfreich wäre.
Hier ist mein Konzept.

Bis jetzt habe ich alle input_boolean in einem file input_booleans.yaml definiert, das gleiche gilt für input_number. Das habe ich nun geändert.
Es gibt nun in meinem config Ordner stattdessen einen subfolder input_booleans/ und darin liegt sowohl das alte file input_booleans.yaml als auch neue files für die Bewässerung. Das gleiche gilt für input_numbers.
Die includes in der configuration.yaml musste ich dafür natürlich anpassen.

input_boolean: !include_dir_merge_named input_booleans/
input_number: !include_dir_merge_named input_numbers/

Für die Bewässerung erstelle ich je Zone 2 Files, derzeit sind das also folgende.

input_booleans_zone01.yaml, input_booleans_zone02.yaml - beide im Folder input_booleans/
input_numbers_zone01.yaml, input_numbers_zone02.yaml - beide im Folder input_numbers/

Zusätzlich dazu hab ich aktuell noch folgende Variablen, die nicht zu einer Zone gehören.

input_boolean.yaml

# Dummy-Boolean zur Ansteuerung eines Motor-Haupt-Ventils, muss durch den echten Aktor ersetzt werden.
irrigation_valve_main:
  name: "Bewässerungs-Hauptventil"
  icon: mdi:valve

# globaler Ein/Aus-Schalter, aktuell verhindert dieser Schalter nur den Start, um eine bereits laufenden Bewässerung zu unterbrechen muss das Haupt-Ventil ausgeschaltet werden
irrigation_enabled_global:
  name: "Bewässerung global enabled"
  icon: mdi:sprinkler

input_number.yaml

# Der initial-Wert bewirkt, dass diese Variable nach jedem Neustart zurückgesetzt wird. Sie muss eigentlich auch nie verstellt werden, aber ich hab in HA keine Constants gefunden.
irrigation_number_of_zones:
  name: "Anzahl der Bewässerungs-Zonen"
  initial: 2
  min: 0
  max: 12
  icon: mdi:sprinkler

# Das Motor-Haupt-Ventil ist den Magnetventilen der einzelnen Zonen vorgeschaltet und soll vermeiden, dass die Magnetventile unter Druck öffnen oder schließen.
irrigation_valve_main_delay:
  name: "Bewässerungs-Hauptventil Schließzeit"
  initial: 10
  min: 1
  max: 20
  icon: mdi:valve

Wenn ich nun weitere Zonen anlegen möchte, dann muss ich nur 2 Files kopieren und die Nummern mit replace ersetzen: input_booleans_zone02.yaml => zone03.yaml und input_numbers_zone02.yaml => zone03.yaml
und natürlich den initial Wert von irrigation_number_of_zones anpassen.

Achtung: Es gibt Cards wo die Zonen nicht dynamisch sind, siehe dazu Teil 4.

irrigation_height_zone01, 02, usw. hab ich vorgesehen für eine Statistik-Auswertung, der Code dazu fehlt aber noch. Die Umsetzung möchte ich mit dem Utility_Meter realisieren.

utility_meter.yaml

  irrigation_height_zone01:
    source: input_number.irrigation_height_zone01
    name: Bewässerungshöhe für Zone 1 in mm
    cycle: weekly
    delta_values: true

[scw2wi]

Teil 3 beschreibt nun eine Automation, die alle Werte aus Teil 1 und 2 berücksichtigt.

Es gibt eine Liste von Automations-Beispielen, von denen ich mir das Example 4 und 5 herausgesucht und für meine Wünsche angepasst habe.

Ja, ich geb's ja zu, ich hab es nicht selbst angepasst, sondern von DeepSeek anpassen lassen. ChatGPT hat mir auch ein Beispiel generiert, aber das war komplett unbrauchbar.

Da ich derzeit noch keinen Garden-Control besitze (es fehlen ja auch noch Haus und Garten), verwende ich wie bei den meisten meiner Beispiele auch hier Dummy-Entitäten.
input_boolean.irrigation_valve_zone01, 02

Leider kann der Garden-Control keine Treppenlicht-Automatik mit variabler Zeit, sonst könnte ich einfach die Bewässerungsdauer übergeben und die Abschaltung würde KNX übernehmen.
So bin ich darauf angewiesen, dass der HA-Trigger das Ventil nach der ermittelten Zeit verlässlich wieder schließt.

Ich beschreibe hier einzelne Ausschnitte, der komplette Code ist unten attached.

  triggers:
    # Morgens: Bewässerung laut Smart-Irrigation vor Sonnenaufgang starten
    - trigger: event
      event_type: smart_irrigation_start_irrigation_all_zones
      id: morning
    # Abends: Bewässerung 1 Stunde nach Sonnenuntergang starten
    - trigger: sun
      event: sunset
      offset: "01:00:00"
      id: evening

Der Trigger zündet 2x pro Tag, morgens und abends. Der Morgen-Zeitpunkt wird von der Smart-Irrigation Integration ermittelt, den Abend-Zeitpunkt hab ich auf 1h nach Sonnenuntergang eingestellt.

  conditions:
    # Nur von März bis November starten
    - condition: template
      value_template: >
        {{ now().month in [3, 4, 5, 6, 7, 8, 9, 10, 11] }}
    # Nur starten, wenn die globale Bewässerung aktiviert ist
    - condition: state
      entity_id: input_boolean.irrigation_enabled_global
      state: "on"

In 2 Fällen schaltet der Trigger sofort wieder ab, im Winter (Dez bis Feb) wir nicht gegossen und wenn global abgeschaltet ist auch nicht.

  actions:
    - action: persistent_notification.create
      data:
        title: 'Trigger-Nachricht'
        message: >
          Bewässerung gestartet: {{ trigger.id }}
          {{- '\n' -}}
          Zeitpunkt: {{ now().strftime('%Y-%m-%d %H:%M') }}

In der Testphase des Triggers hab ich noch ein paar Benachrichtigungen belassen, die kann man dann auch löschen, wenn das ganze mal läuft.

    # dynamische Erstellung der Liste aller Zonen mit Regex (smart_irrigation_zone01, 02, ... )
    - variables:
        zones: >
          {% set ns = namespace(zone_list=[]) %}
          {% set zone_entities = states.sensor | selectattr('entity_id', 'match', '^sensor\.smart_irrigation_zone\d{2}$') | list %}
          {% for entity in zone_entities %}
            {% set zone_id = entity.entity_id | regex_replace('^sensor\.smart_irrigation_zone(\d{2})$', '\\1') %}
            {% set month = now().strftime('%b').lower() %}
            {% set day = now().strftime('%a').lower() %}
            {% set factor_value = states('input_number.irrigation_factor_' ~ month ~ '_zone' ~ zone_id) %}
            {% set factor = 0 if factor_value == 'unknown' else factor_value | float / 100 %}
            {% set duration_value = states(entity.entity_id) %}
            {% set duration = 0 if duration_value == 'unavailable' else duration_value | float * factor %}
            {% set size = state_attr(entity.entity_id, 'size') | float %}
            {% set throughput = state_attr(entity.entity_id, 'throughput') | float %}
            {% set irrigation_height = ((throughput * duration) / (60 * size)) | round(2) %}
            {% set zone_data = {
              'zone': entity.entity_id,
              'zone_id': zone_id,
              'valve': 'input_boolean.irrigation_valve_zone' ~ zone_id,
              'enabled': states('input_boolean.irrigation_enabled_zone' ~ zone_id),
              'schedule': states('input_boolean.irrigation_schedule_' ~ month ~ '_' ~ day ~ '_' ~ trigger.id ~ '_zone' ~ zone_id),
              'factor': factor,
              'duration': duration,
              'size': size,
              'throughput': throughput,
              'irrigation_height': irrigation_height
            } %}
            {% set ns.zone_list = ns.zone_list + [zone_data] %}
          {% endfor %}
          {{ ns.zone_list }}

Hier wird die Variable zones mit eine Liste aller Zonen und allen benötigten Daten dazu befüllt. Ich bin froh, dass mir DeepSeek diesen Code erstellt hat, denn mein Know-How hat gerade mal dafür gereicht, die Fehler darin zu finden und zu beheben.

    # Repeat-Schleife über die erstellte Liste
    - repeat:
        for_each: "{{ zones }}"
        sequence:
          - if:
              - "{{ repeat.item.enabled == 'on' }}"
              - "{{ repeat.item.schedule == 'on' }}"
              - "{{ repeat.item.duration | int > 0 }}"

Hier beginnt nun die Schleife über alle Zonen, wobei je Zone geprüft wird, ob die Bewässerung dafür gestartet werden soll.
enabled ist der Ein/Aus-Schalter für jede Zone,
schedule ist jenes Flag, das in Kombination mit Monat, Wochentag und morgens/abends gesetzt sein kann oder auch nicht.
Wenn die duration 0 ist, dann gibt es keinen Bedarf zur Bewässerung.

              # Speichern der Bewässerungshöhe in einer Variablen (z.B. input_number.irrigation_height_zone01)
              - action: input_number.set_value
                data:
                  entity_id: "input_number.irrigation_height_zone{{ repeat.item.zone_id }}"
                  # value: "{{ repeat.item.irrigation_height }}"
                  # Höhe wird jedesmal dazugezählt
                  value: "{{ states('input_number.irrigation_height_zone' ~ repeat.item.zone_id ) | float + repeat.item.irrigation_height }}"
              - action: input_boolean.turn_on
                data:
                  entity_id: "{{ repeat.item.valve }}"
              # zuerst das Magnetventil öffnen, dann das Motor-Ventil
              - action: input_boolean.turn_on
                data:
                  entity_id: input_boolean.irrigation_valve_main
              # Bewässerungszeit wurde ermittelt laut max. Bedarf * Faktor laut Jahreszeit
              - delay: >
                  {% set duration = repeat.item.duration %}
                  {{ duration | int }}
              - action: input_boolean.turn_off
                data:
                  entity_id: input_boolean.irrigation_valve_main
              # zuerst das Motor-Ventil schließen, dann (nach der Schließzeit) das Magnet-Ventil
              - delay: "{{ states('input_number.irrigation_valve_main_delay') }}"
              - action: input_boolean.turn_off
                data:
                  entity_id: "{{ repeat.item.valve }}"

Hier geht's nun wirklich los.
irrigation_height_zone soll später mal für Statistiken verwendet werden, der Code dazu fehlt aber noch.
Beim Öffnen kommt zuerst das Magnet-Ventil dran, dann das Motor-Haupt-Ventil, dann wird bewässert.
Beim Schließen ist es umgekehrt, hier wird zuerst das Motor-Haupt-Ventil geschlossen, und erst wenn dieses zu ist kommt das Magnet-Ventil dran.

              # Bucket für die aktuelle Zone muss nach der Bewässerung auf 0 gesetzt werden
              - action: smart_irrigation.reset_bucket
                data:
                  entity_id: "{{ repeat.item.zone }}"

Im letzten Schritt müssen wir der Integration noch mitteilen, dass jetzt bewässert wurde und das bucket gelöscht werden soll.

Das war's. Im Trockentest läuft der Trigger bereits und wer einen Garten mit Bewässerungs-Steuerung hat, kann ihn ja mal im Feldversuch ausprobieren.

[scw2wi]

In Teil 4 zeige ich meinen Entwurf von Cards, um die Parameter aus Teil 2 verwalten zu können.
In Zukunft soll auch noch eine grafische Überwachung der tatsächlich durchgeführten Bewässerung ergänzt werden.

Es geht hier um die Einstellung von eigentlich nur 2 Parametern, die aber gleich in vielfacher Menge vorkommen.

Parameter 1 lautet: input_number.irrigation_factor_<Monat>_<Zone>
Es gibt ihn daher für jede Zone 9x für die Monate März bis Nov (zum testen im Feb hab ich noch ein Monat dazugenommen, das fliegt aber dann wieder raus).
Die aktuelle Einstellung zeigt im Juli 100% Bewässerung mit kontinuierlicher Abnahme in beide Richtungen.
Da ich hier je Zone sehr flexibel bin, könnte ich mir vorstellen, sogar nur mit Regenmessung und ohne das ETo-Modell der Integration auszukommen, das wird aber dann die Erfahrung zeigen.

Parameter 2 lautet: input_boolean.irrigation_schedule_<Monat>_<Wochent ag>_<Zeitpunkt>_<Zone>
Ja, den Parameter gibt es jetzt etwas häufiger, je Zone und je Monat auch noch 14x für jeden Wochentag morgens und abends.
Der Sinn dahinter ist der, dass ich im Sommer häufiger sprengen möchte und im Frühling und Herbst weniger oft.

Die Karten habe ich soweit generisch erstellt, sodass mithilfe der auto-entities card automatisch alle Zonen dargestellt werden, für die es Variablen (bzw. Entitäten) gibt.


HACS Bewässerung - Cards - Juli.png
Zusätzlich gibt es noch folgende Karten, die jedoch nicht generisch die Anzahl der Zonen berücksichtigen. Hier ist es jeweils nur eine Zeile, die je Zone ergänzt werden muss.
Mit Wildcards wäre es sogar generisch machbar, aber ich bestehe in solchen Fällen auf die sichere Methode von regulären Ausdrücken, und das hat bei mir leider nicht funktioniert.


HACS Bewässerung - Daten.png
Die Daten zeigen sowohl die Parameter der Integration als auch die gesammelten Statistikdaten, wobei ich schon geschrieben hab, dass dieser Teil noch fehlt.

Zuletzt gibt es noch den globalen Ein/Aus-Schalter und die Anzeige der Ventile, auch diese sind nicht generisch und müssen daher händisch an die Anzahl angepasst werden.

HACS Bewässerung - Global.png

Den Code beschreibe ich hier nicht im Detail, er ist (hoffentlich vollständig) attached. Sollte jemand Fragen dazu haben, werde ich sie natürlich schon beantworten.

Ich hab 2x die Decluttering-Card eingesetzt, wie ich es auch beim Reminder und der Wetter-Card gemacht habe. Man kann damit sehr viele Code-Dubletten einsparen.
Wer das noch nie verwendet hat - man muss im Dashboard-Edit-Mode rechts oben beim Hamburger-Menü den Punkt "{} Raw-Konfigurationseditor" auswählen.
Vor dem Bereich views werden die decluttering_templates eingefügt, das sieht dann so aus:
(Wer den Decluttering-Code genauer ansieht wird feststellen, dass HA die Einrückungen kaputt macht. Der Code funktioniert jedoch trotzdem, er ist nur leider nicht mehr so gut lesbar)

decluttering_templates:
  irrigation_schedule_card:
    alias: zeigt 14 Schedule Termine für Mo bis So
    default:
      - MONTH: jan
    card:
      # usw.

  irrigation_zone_card:
    alias: zeigt die Anzahl der Bewässerungen pro Woche für den gewählten Monat
    default:
      - MONTH: jan
    card:
      # usw.

views:
  # usw.

Damit bin ich am Ende meiner Beschreibung. Jetzt hoffe ich nur, dass irgendjemand diesen Code verwenden kann und hier über Erfahrungen damit berichtet.

Weitere Beiträge dieser Serie:

HACS Wetterkarte
HACS Sonne & Mond (inkl. Tipps zur configuration.yaml)
HACS Schieberegler (inkl. Möglichkeiten der Icon Farbanpassung & erste Vorstellung Farbschema)
HACS Gauges (Tachoanzeigen, inkl. senkrechte Balken-Cards)
HACS stack-in-card für Raum-Card
HACS Graph-Cards
HACS Thermostat-Cards
HACS Entity Cards (inkl. stacking Beispiele mit der custom:button-card)
HACS Reminder (trash-card, atomic-calendar-revive)
HACS Person- & Öffi-Card (inkl. Geschichte zu ChatGPT)
HA-Behaglichkeits-Diagramm
HA Kurzeinführung
HACS Sidebar & Dashboard-Entwurf

HA & Node-Red
HA Notifications
HA Recorder, SQLite, InfluxDB, Grafana
HA Python Scripts

[Masifi]

das alles zu lesen dauert wahrscheinlich noch länger als mein Vortrag.
Aber krass wie viel Arbeit du hier reinsteckst 👍

[BadSmiley]

Ich finde die T-Fighter Ventile süß.

[scw2wi]

Aber krass wie viel Arbeit du hier reinsteckst

Ich bin sicher, es ist nicht annähernd so viel wie du in OpenKNX investierst, aber da sich halt unser Hausprojekt nach hinten geschoben hat, verwende ich die gewonnene Zeit für solche Themen.

Ich kenne viele Berichte hier im Forum, dass Leute die ersten Jahre noch ohne Home-Server Steuerung (und damit auch Visu) ausgekommen sind, was ja bei KNX im Prinzip machbar ist, aber bei mir ist es halt genau umgekehrt, da ist das HA-Dashboard bereits Jahre "zu früh" fertig, bzw. der erste Entwurf, denn ein fertig gibt es bei mir vermutlich nicht so schnell.

Die meisten Ideen hab ich aber damit jetzt eigentlich umgesetzt, die Bewässerung war sicherlich das komplexeste von allen bisherigen.
Influx-DB & Grafana sind noch auf meiner Agenda.
Music Assistant ebenfalls, möglicherweise in Kombination mit Jellyfin oder Kodi.
MQTT ist noch ein wichtiges Thema, ebenso ESPHome.
Node-RED könnte noch interessant sein, mehr aber eher noch Python Scripts.

Und bei all diesen HA-Themen sollte ich auch nicht vergessen, mal die ersten OpenKNX Geräte in real kennenzulernen.
Es gibt in dieser Liste eigentlich kein Gerät, das mich nicht interessieren würde.
So schnell wird mir also nicht langweilig.

[Tom Bombadil]

scw2wi Da Du Dich ja sowieso mit Python Scripten befassen willst, kann ich auf Wunsch nochmal meine alten Scripte durchwühlen. Da ist ein Stand-Alone Script dabei, das folgendes tut (fertig):

• Login morgens um 00:10 bei wunderground.com (habe leider mittlweile keinen funktionierenden Key mehr),
• Alle Stationen im Umkreis von ~2km abgrasen und dabei den Niederschlag des Vortages in mm (=l/m²) abholen (waren damals ca. 10 Stationen),
• Ggf. Ausreißer oben und unten ermitteln und entfernen (für den Fall von Ausfällen/Defekten einzelner Stationen),
• Durchschnitt aller verbleibenden Wetterstationen bilden und in die Datenbank schreiben = Basis für spätere Zielmenge der Beregnung.

Daraufhin habe ich dann einen 4-Kreis-Wasserverteiler auf Relaisbasis in einen A4-großen Abzweigkasten eingebaut, Klickfix-Anschlüsse für die Schläuche montiert, mit einem im Schuppen befindlichen 4 Kanal Sonoff Aktor (WLAN-fähig) verkabelt und den Verteiler mit Harz vergossen (da Außeneinsatz). Gemütlich per WLAN oder von Hand auf Knopfdruck steuerbar.

Was ich nie fertiggestellt habe, war folgendes:

• Der Garten soll laut verschiedenen Empfehlungen konstant 15mm Niederschlag pro zurückliegende 7 Tage bekommen (täglich zu ermitteln, ~2mm/Tag),
• Dazu vor der Beregnung die für jeden Kreis benötigte Differenzmenge ausrechnen (gefallene Regenmenge der letzten 7 Tage bis einschlielich gestern 24:00 ist ja schon in Datenbank),
• Entsprechende Menge je Kreis morgens zwischen 2 und 4 Uhr beregnen (da Wasserdruck hier tagsüber im Sommer grottenschlecht ist) und Menge zusätzlich in die Datenbank schreiben. Oder eben auch nicht beregnen, wenn's eh vom Himmel geströmt hat. Oder viel, oder wenig - je nachdem, was benötigt wird halt ...

Die finale Steuerung sollte damals SmartHomeNG übernehmen - aber irgendwie hab ich mich nie dazu aufraffen können, das ganze zu Ende zu bringen. Falls Du sowas brauchen kannst - das erste Script ist wie geschrieben fertig und lungert hier noch irgendwo auf der Festplatte herum ...

/tom

[scw2wi]

Das mit dem Python Skript klingt interessant.
Aktuell reicht mir die native HA-Automatisierung über YAML-Syntax zwar noch, aber wenn es komplexer wird, hat Python sicher viel mehr Möglichkeiten.
Die Empfehlung mit den 15mm pro Woche kann wohl kaum für alle Monate gelten, aber da greift ja dann mein Korrektur-Faktor pro Monat.

Ich hab mit der Smart-Irrigation Integration halt noch keine Erfahrung, möglicherweise macht sie ja genau das, was dein Skript macht, nur ein bisschen anders.
Der Vorteil des Skripts wäre, dass man den Code leichter selbst anpassen kann als bei einer Integration, wo zwar auch der Code verfügbar ist, aber die Einstiegshürde etwas höher liegt.

[henfri]

Ein TL;DR wäre gut.

Was macht dein Skript, was smart_irrigation nicht macht?

[scw2wi]

War das wirklich unklar?

Bei einer Bewässerung gibt es einen Trigger der die Bewässerung startet (siehe Post 3) und entweder eine fixe Dauer oder eine möglichst gute Schätzung (siehe Smart Irrigation).

Smart Irrigation benötigt also irgendeine Form von Trigger und dieser verlässt sich wiederum auf die Schätzung. Insofern arbeiten diese Komponenten optimal zusammen und keiner übernimmt irgendeine Funktion des anderen. Daher hab ich auch deine Frage nicht verstanden.

Du kannst das alles auch weglassen und einfach jeden Tag jeden Sprenger die gleiche Zeit lang einschalten. Das ist dann aber das genaue Gegenteil von smart.

Mein Ziel war jedoch hohe Flexibilität. Es ginge zwar auch mit etwas weniger, da der Code aber weitgehend generisch ist, würde er dadurch nicht signifikant kürzer werden.

[henfri]

Smart Irrigation benötigt also irgendeine Form von Trigger und dieser verlässt sich wiederum auf die Schätzung. Insofern arbeiten diese Komponenten optimal zusammen und keiner übernimmt irgendeine Funktion des anderen. Daher hab ich auch deine Frage nicht verstanden.

Smart irritation ist doch der Trigger, der auch die Dauer berechnet.
Zonen macht bei mir irritation unlimited.

Was fehlt da?

[scw2wi]

Wenn die Irrigation Unlimited Integration genau das macht was du möchtest, dann fehlt da mit Sicherheit gar nichts.
Deine erste Frage hat sich aber auf smart irrigation bezogen, und daher habe ich auch darauf geantwortet.

Irrigation Unlimited ist vermutlich noch etwas komplexer als meine Lösung und wer darauf Wert legt, der wird damit sicher zum Ziel kommen.
Im Prinzip geht es um drei Dinge

1. Bewässerungsdauer - z.B. auf Basis von Wetterdaten, gemessenem Niederschlag
   oder auch auf Basis gemessener Bodenfeuchte (das kann smart irrigation aber nicht)
2. Bewässerungs-Zeitpunkt und Sequenz für Zonen - z.B. mit Irrigation Unlimited, oder mit dem Trigger aus Post 3.
3. Karten zur Anzeige und Überwachung - z.B. mit den Irrigation Unlimited Cards, denen aus Post 4 oder halt einer anderen Lösung.

Ich bin sicher nicht der einzige, der eine Lösung dafür anbieten kann, und von einer funktionierenden Lösung umzusteigen, das würde ich mir sehr genau überlegen.

Es gibt ja auch noch andere Lösungen (z.B. Irrigation-V5) wo alle 3 Teile integriert sind. Muss sich halt jeder das aussuchen, was am besten zu den eigenen Vorstellungen passt.

Seit wann hast du Smart Irrigation bereits im Einsatz und wie sind deine Erfahrungen damit?
In der Community sind ja nicht alle voll Zufrieden mit der Ermittlung der benötigten Menge.

[noize]

Smart irritation ist doch der Trigger, der auch die Dauer berechnet.
Zonen macht bei mir irritation unlimited.

Was fehlt da?

Hallo henfri.

Ich versuche die Integration irrigation unlimited mit anderen Dashboard karten ans laufen zu bringen. Leider vergebens. Die Installation usw. hab ich hinter mir auch dass das python läuft. Aber die beigestellten Karten gefallen mir überhaupt nicht. Wie hast du das umgesetzt?