"Sanfter" Umstieg von Homebridge auf Homeassistant

Und lasst ihr die als Blueprint erstellen?

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen. Aber melde dich gerne bei uns an und werde Teil der Community!

Das sind quasi fertig konfigurierte Eingabemasken für Automationen und Co., die sich sehr einfach in HA importieren lassen.

Ich befürchte, HA und ich werden keine dicken Freunde. Hab's heute mal mit einer KI-generierten Automation versucht. Ich geb's zu, das war nicht ganz trivial, aber für trivial brauche ich auch keine KI. Also, was habe ich Gemini 2.5 Pro als Aufgabe mitgegeben?

Zitat

Bitte erstelle mir eine Automation für Home Assistant, die beispielhaft folgendes macht:

• Ofen oder Kochfeld Programm läuft → LED-Streifen leuchtet mit einstellbarer Farbe (default: hue = 30, saturation = 100) und Helligkeit (default: 30 %).
• Ofen oder Kochfeld Programm fertig → LED-Streifen blinkt mit einstellbarer Häufigkeit (default: 10 Mal) und Helligkeit (default: 60 %).
• Geschirrspüler Programm läuft → LED-Streifen leuchtet mit einstellbarer Farbe (default: hue = 120, saturation = 100) und Helligkeit (default: 30 %).
• Geschirrspüler Programm fertig → LED-Streifen blinkt mit einstellbarer Häufigkeit (default: 10 Mal) und Helligkeit (default: 60 %).
• Waschtrockner Programm läuft → LED-Streifen leuchtet mit einstellbarer Farbe (default: hue = 240, saturation = 100) und Helligkeit (default: 30 %).
• Waschtrockner Programm fertig → LED-Streifen blinkt einstellbarer Häufigkeit (default: 10 Mal) und Helligkeit (default: 60 %).
• Mindestens zwei der Geräte an → LED-Streifen wechselt alle 30 Sekunden zwischen den entsprechend eingestellten Farben, bis eines der betreffenden Geräte ausgeschaltet wurde.
• Ein Gerät wird ausgeschaltet → betreffende Farbe wird ausgeschaltet.
• Letztes Gerät wird ausgeschaltet → LED-Streifen aus.

Für den Zustand des jeweiligen Geräteprogramms dient die Entität „sensor.<Gerätename>_betriebszustand“. Eine laufendes Programm hat den Betriebszustand „Run“. Ein beendetes Programm hat den Betriebszustand „Inactive“ oder „Ready“. Die jeweiligen Zustandparameter sollen als Textfeld frei wählbar sein, da sie für die einzelnen Geräte unterschiedlich sein können.

Der LED-Streifen hat die Entität „light.kuche_licht_sockel“ und soll mit dem Attribut „color_mode: hs“ sowie den oben definierten bzw. einstellbaren Attributen für „brightness“ und „hs_color“ gesteuert werden.

Als Antwort bekam ich dann, dass das doch etwas komplex für eine reine Automation wäre und daher zusäztlich ein YAML-Skript empfohlen wird. Das habe ich dann nach Einleitung eingefügt, aber der erste Test ergab: NICHTS.

Dann habe ich die KI gebeten, doch einen Testmodus für den anzusteuernden Lichtsensor einzufügen, so dass ich sehen kann, ob die Ansteuerung als solche schon mal funktioniert. Wie immer lobt einen die KI dann für diese Idee über den grünen Klee, als hätte man das Rad neu erfunden und implementiert das Ganze auch ruckzuck. Was kam dann beim Veruch, das Skript zu speichern?

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen. Aber melde dich gerne bei uns an und werde Teil der Community!

Also habe ich es mal durch zwei unterschiedliche YAML Code Checker gejagt und die gaben mir als Antwort, dass alles in Ordnung sei. Also wieder mal drei große Fragezeichen???

Und nicht genug, hatte mich heute morgen schon die MQTT-Übertragung geärgert. Siehe hier.

Ja, muss da wohl etwas kleinere Brötchen backen. Aber wozu hat man denn schließlich die KI?

Trotzdem frage ich mich, warum der HA eine Meldung auswirft und mir externe YAML-Checker sagen, dass alle in Ordnung sei.

Das zweite Problem mit MQTT konnte ich mittlerweile lösen. Es war ein simpler Schreibfehler bzw. ein vergessener Slash "/". Sowas nennt man dann wohl Betriebsblindheit.

Zitat von Holger

Lass doch erstmal was bauen mit den von dir genannten "Default" Werten.

Klappte übrigens auch nicht so richtig. So 08/15-Automationen klicke ich mir ja mittlerweile recht simpel mit dem virtuellen Editor zusammen. Herausfordernd sind die komplexeren Sachen mit vielen Nebenbedingungen und Verschachtelungen.

Vor Jahren hatte ich mal ein Skript für die Beschattung per HomeMatic erzeugt, das folgende Features unterstützte:

• Aufruf beliebiger Beschattungsgeräte mit beliebigen Behanghöhen bzw. Ausfahrwerten und ggf. Lamellenpositionen.
• Unterstützung aller HM- und HMIP-Rollladen- und -Jalousieaktoren sowie -Fenstersensoren (mit Einschränkungen werden auch EnOcean-Rollladenaktoren als CUxD-Geräte unterstützt).
• Sicheres Vermeiden von Aktoraufrufen zur Relaisschonung, wenn deren Soll-Zustand bereits vorliegt.
• Nahezu gleichzeitiges Ansprechen von z.B. Rollläden und/oder Markisen (rein optischer Effekt für synchrone Fahrprozesse).
• Möglichkeit zum zeitverzögerten Ansprechen der Beschattungsgeräte.
• Optionale Definition globaler Werte für alle angesteuerten Beschattungsgeräte.
• Optionale Berücksichtigung gekippter und geöffneter Fenster und Türen mit individuellen Korrekturwerten (relativ oder absolut).
• Optionale globale oder individuelle Frostschutzfunktion.
• Einfache Vermeidung von Schließvorgängen bei geöffneten und/oder gekippten Fenstern und Türen.
• Möglichkeit zum Sperren und Entsperren der lokalen Bedienung am Aktor (HM und HMIP).
• Möglichkeit zum Setzen individueller Sperr- und Entsperrwerte für HMIP-Aktoren.
• Einfaches Setzen einer minimalen oder maximalen Behanghöhe bei HMIP-Aktoren, die auch für die lokale Tasterbedienung gilt (z.B. Frostschutzfunktion).
• Möglichkeit von Testläufen ohne Ansteuerung der Beschattungsgeräte im Life-Betrieb.
• Möglichkeit zur Statusabfrage des vollständigen Beschattungsgewerks inkl. Verschlusszustand der zugehörigen Fenster und Türen.
• Möglichkeit zur Priorisierung der Behanghöhe oder der Lamellenstellung für Jalousieaktoren.
• Einfache Möglichkeit zum Aufruf des gesamten Beschattungsgewerks inkl. oder exkl. Markisen.
• Möglichkeit zum Ansteuern von Markisen mit inversen Werten (100 -> 0, 0 -> 100, 80 -> 20, etc.).
• Optionale Definition unterschiedlicher Auslöseschwellen beim Soll-Ist-Vergleich.
• Möglichkeit zum Abspeichern einer Beschattungswerteliste und zum späteren Aufruf dieser Liste innerhalb eines global oder individuell festlegbaren Zeitfensters.
• Möglichkeit zum Ergänzen der abgespeicherten Beschattungswerteliste innerhalb eines festlegbaren Zeitfensters.
• Möglichkeit zum Aufruf gespeicherter Listen mit einer abweichenden, globalen Auslösebedingung.
• Absolute Unabhängigkeit von IDs, Kanalnamen und Seriennummern der einzelnen Geräte. Damit ist jederzeit ein einfacher Gerätetausch möglich.
• Sehr einfache Integration neuer Beschattungsgeräte sowie Fenster- und Türsensoren ohne Änderung am Skript.
• Möglichkeit zur Benachrichtigung über die geänderten Werte und Status per Push-Nachricht.
• Einfache Erkennung von Fenster- und Türzuständen per Farbcodierung (yellowgreen: geschlossen, royalblue: gekippt, orange: offen) in den Push-Nachrichten.
• Möglichkeit zur vollständigen Unterdrückung von Push-Nachrichten (sinnvoll z.B. bei wiederkehrenden, zeitabhängigen Auslösungen).

Sowas über Automationen im HA umzusetzen ist sicherlich möglich, aber eine KI würde sich daran vermutlich die Zähne ausbeißen. Mein Anspruch bei der HomeMatic war auch immer, dass andere User meine Skripte für ihre Setups nutzen und sehr leicht individuell anpassen können. Also quasi eine Blueprint-Funktion.

Zitat von djiwondee

Wow! nur ein Skript?

Im Wesentlichen ja (klick). Allerdings habe ich für die Push-Nachrichten dann noch ein weiteres geschrieben, das von diversen anderen Programmen bzw. Skripten aufgerufen werden kann.

Ich selbst kann das Beschattungsskript so leider nicht mehr nutzen, weil ich mangels motorgetriebener Rollläden keine HomeMatic-Aktoren in meiner Mietwohnung nutzen kann.

Zitat von BenSisko

Aber vermutlich nicht so leicht zu testen, wenn es bei dir nicht mehr live läuft.

So ist es. Zudem habe ich keinerlei Ambitionen, Vorgänge, die gut in OpenCCU laufen, auf ein externes System auszulagern. Der Home Assistant soll bei mir primär eine Plattform sein, um Dinge miteinander zu verknüpfen, die mit "nativen Bordmitteln" nicht verknüpfbar wären.

Zitat von djiwondee

Für viele Homematic-Taster lasse ich mir durch ein zusammengelicktes "Dummy-Programm" die Key-Press-Events senden. Wer weiss, was damit mal passiert...

Wenn du die HomeMatic(IP) Local Integration nutzt, brauchst du das meines Wissens nach nicht, denn die bekommt die eh mit. Ich nutze drei HmIP-WRCn, um darüber meine per Matter mit dem HA verknüpften Rollos und Leuchten direkt steuern zu können.

Im ioBroker hatte ich mir ein kleines Javaskript geschrieben, das ich einmal ausführen musste, damit die Keypress-Events ausgelesen werden konnten.

// Dieses Skript nur ein Mal für jeden Taster-Kanal ausführen
const inst = 'hm-rpc.1'; // Instanz anpassen
const channel = '000B5D8995CA16:1'; // Kanal-Adresse anpassen
const channelType = 'PRESS_SHORT'; // Kanal-Typ anpassen

sendTo(inst, 'reportValueUsage', {ID: channel, paramType: channelType, params: 1}, res => {
    log(JSON.stringify(res));
});