ich nutze bis jetzt nur wenige Skripte und ich frage mich ob es später bei der Wartung einfacher ist, wenn man gleiche Abläufe in Skripten verschiebt um
1. Automatitionen schlanker zu halten
2. Skript bearbeiten und es ändert einfach alle Automatitionen und man spart sich, dass man sich jede automation anschauen muss.
Als Beispiel:
Waschmaschine/Geschirspüler/Reiskocher etc. fertig:
→ TTS Benachrichtigung
–> Benachrichtung via Notification
–> WLED wird grün für X Sekunden
–> Balkonkraftwerk wird ausgeschaltet
Diese Schritte habe ich halt bei diesen 3 Geräte die sind alle gleich. Wenn ich jetzt das in einem Skript verpacke (natürlich muss TTS Text angepasst werden, damit ich weiß was fertig ist), erspare ich mir in Zukunft für weitere Geräte diesen Aufbau. Und wenn ich zB mein Smartphone wechsle, muss ich nur mehr das Smartphone im Skript ändern und es übernimmt für alle.
Oder habe ich was übersehen, was später als Nachteilig wird in der Automation? zB keine Flexibilität, Es muss zB immer eine TTS Ansage dabei sein, obwohl ich es für ein bestimmtes Gerät zB nicht brauche.
Noch besser wäre es, wenn man beim Skript Felder/Variablen nutzen kann, die man in der Automation mitgibt.
zB
TTS: Waschmaschine ist fertig
WLED wird blau
TTS: Geschirspüler ist fertig
WLED wird grün
Macht das überhaupt Sinn oder ist das eher umständlic. Hat wer sowas schon aufgebaut?
Für mich machen Skripte dann Sinn, wenn eine Aktivität mehrfach bzw. von verschiedenen Automatisationen oder Dashboard Karten ausgeführt werden sollen, zB. eine Sprachansage auf Boxen. Lautstärke, Text oder welche Boxen wird als Variable übergeben. Wiederholung ist das Stichwort.
In der (objektorientierten) Programmierung gibt es unter anderem den Grundsatz DRY - don’t repeat yourself
Daher ist es grundsätzlich schon sehr sinnvoll, wenn man wiederholt / mehrfach genutzte Dinge einmal festlegt und wiederverwendet.
Die Frage ist eher wie viele Probleme und Arbeit Dir dies spart und wie viel Du Dir damit machst.
Wenn Du es Dir in unter einer Minute quick & dirty neu zusammen klicken kannst ist eine Stunde und mehr mit Konzipierung und Entwicklung einer sauberen, wiederverwendbaren Methode zu verbringen ggf. wenig zielführend, wenn diese dann insgesamt 3x genutzt wird …
Hast Du komplexe Abläufe, die sich dann ggf. mal ändern, aber x-fach eingebunden sind, kann es ganz anders aussehen.
Ich nutze Skripte mittlerweile recht häufig, meistens auch mit Variablen.
Ich nutze für manche Aktionen z.B. MQTT publish (z.B. um eine externe Temperatur-Messung auf ein über Zigbee2MQTT eingebundenes Thermostat zu senden). Damit ich hier nicht in jeder Automation immer wieder das gleiche machen muss, wird hier z.B. jedes Mal das Skript mit den zur Automation passenden Variablen aufgerufen.
Gleiches habe ich für unsere beiden Saugroboter mit Valetudo gemacht, die man auch per MQTT ansprechen muss. Macht vieles einfacher.
Aber da bin ich noch am probieren, weil ich ab und zu mal noch andere Geräte hinzufügen möchte bei den Benachrichtigungen. Aber mal schauen. bzw. später TTS hinzufügen möchte im Skript
zB Sprachansage an Tablet (TTS). Da habe ich mit einem Skript kaum Vorteile, wenn ich nur 1 Gerät nutze. Erst bei mehreren Geräte erspare ich mir mit einem Skript in der Automation.
zB Wenn ich TTS nutze für Waschmaschine/Geschirspüler etc. sehe ich keinen Vorteil ein Skript zu nutzen. Vielleicht sehe ich den Vorteil noch nicht.
Oder anstatt einer Benachrichtigung, ein Skript zu verwenden, dass die Waschmaschine fertig ist…
Also macht Skripte nur Sinn, wenn man bestimmte Abläufe hat, die gleich sind und man in verschiedene Automationen nutzen kann Sinn.
zB
Start von Waschmaschine/Geschirspüler etc.
> Balkonkraftwerk einschalten
>LED einschalten etc.
Was mir zB weiter einfällt sind Benachrichtigung, wenn man später in Zukunft ein weiteres Gerät hinzufügen möchte oder wechselt etc. Dann muss man nur mehr das Skript bearbeiten, anstatt alle Automationen wo eine Benachrichtigung genutzt wird.
Sprich ich habe sehr viele Automation wo es nur um benachrichtgungen gehen zB
Briefkasten wurde geöffnet–> Benachrichtigung am Smartphone
Garage wurde ist um 20 Uhr noch offen –> Benachrichtigung am Smartphone.
Somit könnte ich es in einem Skript zusammenfassen und in Zukunft bei einem smartphone wechseln, muss ich nur mehr das Skript anpassen anstatt alle Automatitionen. Aber da sehe ich halt noch ein Problem, dass man dann nicht so flexibel ist mit den Benachrichtigungsabfragen wie Garage ist offen –> schließen?
Fernseher ist eingeschaltet –> Fernseher ausschalten? usw.
Zumindest sehe ich halt bei mir aktuell dass ich bei einigen Automationen zb 3 Benachrichtigungen sende und 2-3 TTS und diese versuche ich mal in einem Skript zusammen zufassen, damit es nur mehr ein Feld ist
Das mag sein… für den Moment aber das kommt schon noch. Mir gefiel Deine Frage weil sie in die richtige Richtung geht. Jeder braucht seine Zeit. Ich habe auch anfangs einfach losgemacht, weil es ging ja auch so. Nur wenn alles wächst, merkt man, daß eine saubere Struktur braucht und die einem auch hilft, das ganze noch warten zu können. Mein Tipp, probieren und Erfolgserlebnisse sammeln.
PS: Ich gebe meinen Ansagen-Script pro Text noch eine Prio 1,2 o. 3 mit. Das Script stellt zentral sicher, daß nur Prio 1 Ansagen Nachts durchkommen, Rest als Mail zum Nachlesen. Wenn ich die Uhrzeit anpassen will, mache ich das nur im Script egal wo der Text herkommt.
Skripte sind grundsätzlich keine Automationen. Skripte sind fest definierte Abläufe von Aktionen ohne einen Auslöser.
Man muss sie aktiv starten, das kann entweder manuell passieren oder wie bei meinen genannten Verwendungen aus einer Automation heraus.
Sie machen nicht nur bei Abläufen Sinn die gleich sind, sondern auch wenn sie ähnlich sind oder wenn man sie als Action Script aufrufen möchte.
Ähnliche Abläufe “modifiziert” man über Parameter (fields im Skript) und gibt die aktuellen Wert beim Aufruf mit. Hier z.B. eine Tastenbelegung für den Mini Media Player
Dem Script play_radio_station werden in diesem Beispiel die Werte für station, station_title und station_logo übergeben.
Der aufgerufenen Script sieht dann z.B. so aus:
alias: Play Radio Station
sequence:
- data:
source: Radio
enabled: true
target:
device_id: c407641e5c770a9efae6635033b4b912
action: media_player.select_source
- target:
entity_id: media_player.linn_wohnbereich_upnp_av
data:
media:
media_content_id: '{{ station }}'
media_content_type: audio/aac
metadata:
title: '{{ station_title }}'
thumbnail:
'[object Object]': null
media_class: music
children_media_class: null
navigateIds:
- {}
- media_content_type: app
media_content_id: media-source://radio_browser
- media_content_type: music
media_content_id: media-source://radio_browser/country/DE
action: media_player.play_media
mode: single
icon: mdi:radio
fields:
station:
selector:
text: null
name: Station
description: ID des Radiosenders der gestreamt werden soll
required: true
station_title:
selector:
text: null
name: Station Title
description: Name des zu streamenden Radiosenders
required: true
station_logo:
selector:
text: null
name: Station Logo
description: 'Logo-Adresse des Radiosenders '
Das ist richtig. Ich versuche halt eine saubere Struktur zu haben und auch Veränderungen später zu vereinfachen. Jetzt brauche ich nur mehr das Skript bearbeiten und alle Benachrichtigungen gehen dann auf das neue Smartphone und in Zukunft muss ich nicht mehr alle automationen abarbeiten, weil das Smartphone getausch wurde.
Ich probiere eh oft, aber manchmal überlegt man halt, ob man zb wie jetzt sowas umstellen soll, was ja haufenweise arbeit ist.
zB geht bei mir jetzt TTS nicht mit dem Skript. Da muss ich noch den fehler finden. Weil mein Smartphone erkent dass es ein TTS ist, aber er sagt, dass es noch nicht konfiguriert ist am Smartphone. Nur funktioniert TTS mit der Originale Benachrichtigung…naja mal schauen
Aber es sieht zumindest gut aus aktuell. Somit kann ich meine Automation etwas “bereinigen”
Ich weiß ja was ein Skript ist und was eine Automation. Deshalb war ja die Anfangsfrage, ob es Sinn machen würde, Teile einer Automation in einem Skript umzuwandeln, damit die Automation übersichtlicher wird.
