Beiträge von loonypac

Der selbständige HomeKit Multitasking Wecker – Das Ende launenhafter HomeKit-Zeitschaltungen

HomeKit funktioniert nach meinen Erfahrungen umso zuverlässiger, je weniger (komplexe) Automationen über diverse Steuerzentralen ausgeführt werden müssen. In den Jahren hatte ich wiederholt Probleme mit zeitbasierten Automationen, die ich inzwischen nahezu vollständig aus HomeKit herausgenommen habe.

Im Folgenden werde ich anhand eines praktischen Beispiels einer zeitbasierten Heizungssteuerung eine alternative Zeitschaltungmöglichkeit im RavenSystem erläutern.

In HomeKit gibt es bekanntermaßen Zeitautomationen nach folgenden Prinzipien:

• Schalte beliebige Geräte/Szenen ab Datum um Uhrzeit Stunde:Minute und wiederhole diese Zeitautomation wahlweise wöchentlich, täglich, stündlich, minütlich oder nie.
• Führe beliebige Automationen statisch innerhalb einer Zeitdauer zwischen Stunde:Minute und Stunde:Minute aus.
• Führe beliebige Automationen dynamisch vor, zwischen oder nach der örtlichen Sonnenauf-/untergangszeit wahlweise inklusive wählbarem Zeitversatz aus.

Das ist zwar ausreichend gut über die Home App und diverse Drittanbieterlösungen einzurichten, jedoch wurden in meinem Fall manche Automationen willkürlich auch gerne mal von HomeKit unterschlagen, was mitunter sehr ärgerliche Konsequenzen besonders zu nachtschlafender Zeit haben kann.

In RavenSystem haben wir ja bereits frei konfigurierbare Timer kennengelernt, die nach beliebiger Zeit in den Grundzustand zurückschalten und damit schonmal eine Zeitdauer definieren können. Zudem erlaubt RavenSystem sogenannte "Timetable Actions", durch die konkrete statische Datums-, Wochentags- und/oder Uhrzeit-Angaben beliebige Schaltzustände bei beliebigen internen Service Types auslösen können.

ESPs verfügen "ab Werk" zwar über keine batteriegepufferte Uhr (RTC), jedoch können sie vordefinierte sogenannte NTP (Network Time Protocol) Server nach der Uhrzeit fragen. Wir kennen das u.a. aus unseren Computern, bei deren Einstellungsoption "Datum und Uhrzeit automatisch einstellen" die Eingabe einer Serveradresse wie bspw. time.apple.com möglich ist.

Beim ESP ist das nicht anders. Wir brauchen diesem in dessen optionaler "General Configuration" lediglich per NTP Server Key "ntp" eine Serveradresse nach unserer Wahl und zudem die korrekte Zeitzone per Key "tz" mitteilen und schon weiß der ESP, was die Stunde schlägt. Das sieht dann ausschnittweise so aus:

"c":{"ntp":"time.apple.com","tz":"CET-1CEST,M3.5.0,M10.5.0/3"}

Hierzu sei erwähnt, dass auch ganz ohne Angabe eines NTP Servers standardmäßig bereits ein Solcher in Raven vorgegeben ist. Über pool.ntp.org kann jeder Raven ESP also bereits nach dem ersten Booten mit der Zeit gehen. Der Vorteil einer selbst gewählten Adresse ist eine integrierte Fallback-Funktion: Sollte der im Beispiel genannte Apple Server mal nicht erreichbar sein, lässt der ESP sich automatisch von seinem Standardserver die Zeit flüstern.

Die Zeitzonenangabe sieht zugegebenermaßen ordentlich kryptisch aus. Es handelt sich beim benötigten Format um eine sogenannte POSIX Zeitangabe, die wir für unseren Standort nicht selbst erstellen müssen, sondern sehr leicht über https://github.com/nayarsystem…_db/blob/master/zones.csv ermitteln und per Copy/Paste nach oben dargestelltem Prinzip einsetzen können. Somit weiß der ESP die korrekte Uhrzeit für unseren Standort.

Das besagte Beispiel einer einfachen Heizautomation geht von 3 Schaltzuständen aus (Weitere sind natürlich möglich):

1. Tägliche Standby-Temperatur
2. Tägliche Nachtabsenkung
3. Temperaturanhebung nur werktags

Hierfür sollen zwei einfache Schalter "Nachtabsenkung" und "Morgenanhebung" entsprechende Heizungsszenen in HomeKit durch simple Automationen schalten.

• Wenn Nachtabsenkung AN -> Heizungsszene Nachttemperaturen
• Wenn Nachtabsenkung AUS -> Heizungsszene Standby-Temperaturen
• Wenn Morgenanhebung AN -> Heizungsszene Morgentemperaturen
• Wenn Morgenanhebung AUS -> Heizungsszene Standby-Temperaturen

Die Schalter selbst sind bekanntermaßen simpelst für HomeKit im ESP wie folgt anzulegen. Zusammen mit der anfangs vordefinierten "General Configuration" ergibt das:

{"c":{"ntp":"time.apple.com","tz":"CET-1CEST,M3.5.0,M10.5.0/3"},"a":[{"t":1},{"t":1}]}

Der komplette Zeitplan soll nun im ESP festgelegt und von diesem ausgeführt werden. Die folgenden Anforderungen sollen dabei umgesetzt werden:

• Die Nachtabsenkung soll täglich zwischen 23:45 bis 6:30 ausgeführt werden.
• Die Morgenanhebung soll werktags zwischen 7:45 bis 9:15 ausgeführt werden.

Hierfür müssen wir dem ESP innerhalb seiner "General Configuration" also noch mitteilen, welche Aktionen wann ausgeführt werden sollen.

Ich beginne mit den "Device Actions", von denen bereits einige in RavenSystem zwischen "0" und "7" vordefiniert sind. Diese wollen wir allerdings nicht nutzen, sondern statt dessen einfache "Service Notifications" zum Ein- und Ausschalten der besagten Schalter "Nachtabsenkung" und "Morgenanhebung" selbst definieren. Das ist ohne Weiteres möglich, da für Timetable Actions bis zur Zahl "50" eigene Definitionen vorgenommen werden können. Es bleiben abzüglich der besagten vordefinierten 7 Device Action immerhin noch 43 freie Definitionen übrig.

Im Beispiel benötigen wir allerdings weitaus weniger, denn besagte zwei Schalter sollen jeweils Ein- und Ausgeschaltet werden, weshalb hierfür 4 Definitionen reichen. Das korrekte Format solcher Actions kennen wir bereits aus meinen vorherigen Projektbeschreibungen. Für das heutige Beispiel werden also 4 Actions diesmal in die "General Configuration" eingetragen, die die zwei besagten virtuellen Temperaturschalter schalten sollen:

// TimeTable Action Nachtabsenkung (Schalter 1) aktivieren
"10":{"m":[[1,1]]},
// TimeTable Action Nachtabsenkung (Schalter 1) deaktivieren
"11":{"m":[[1,0]]},
// TimeTable Action Morgenanhebung (Schalter 2) aktivieren
"12":{"m":[[2,1]]},
// TimeTable Action Morgenanhebung (Schalter 2) deaktivieren
"13":{"m":[[2,0]]},

Fehlen noch die Schaltzeiten, die durch besagte "Timetable Actions" ebenfalls in der "General Configuration" eingetragen werden müssen. Hierfür stehen verschiedene Optionen zur Verfügung. Wie erwähnt soll die Nachtabsenkung jeden Tag zu festen Zeiten ein- und wieder ausschalten. Dazu benötigen wir also ausschließlich eine Uhrzeitangabe und können auf Wochentags- und Datumsangaben verzichten. Das Format für die Timetable Actions ist bestimmt durch die Nummer der einleitenden Aktion, die wir im vorherigen Schritt bereits definiert haben. Für das Einschalten der Nachtabsenkung beginnen wir also mit einer 10, gefolgt von der Stundenangabe 23 Uhr, gefolgt von der Minutenangabe 45 Minuten, das Ganze kommagetrennt:

[10,23,45]

Ausschalten soll die Absenkung um 6:30:

[11,6,30]

Weiter geht’s mit der Morgenanhebung. Hier soll zusätzlich der Wochentag berücksichtigt werden. Unter der Annahme, dass am Wochenende die Anhebung zu unterschiedlichen Zeiten manuell ausgeführt wird, soll also nur von Montag bis Freitag die Zeitschaltung erfolgen und am Wochenende ruhen. Nach dem vorherigen Prinzip brauchen wir also noch eine Wochentagsangabe, die ganz einfach an die Uhrzeit angehängt wird. Dabei beginnt die Woche mit dem Montag = 1. Schalter 2 für die Anhebung soll hierbei täglich werktags um 7:45 eingeschaltet werden:

// Morgenanhebung aktivieren um 7:45 Montags
[12,7,45,1],
// Morgenanhebung aktivieren um 7:45 Dienstags
[12,7,45,2],
// Morgenanhebung aktivieren um 7:45 Mittwochs
[12,7,45,3],
// Morgenanhebung aktivieren um 7:45 Donnerstags
[12,7,45,4],
// Morgenanhebung aktivieren um 7:45 Freitags
[12,7,45,5]

Das erneute Herunterregeln erfolgt an denselben Wochentagen jeweils um 9:15. Den nachfolgenden Codeschnipsel könnten wir uns im Falle der gleichen Zeiträume auch sparen und den Morgenanhebungsschalter kurzerhand zum Timer umdefinierten, der sich dann seinerseits nach 90 Minuten selbsttätig abschaltet. Nichtsdestotrotz soll diesmal eine Uhrzeit ausschalten, wodurch wir bei Bedarf verschiedene Schaltzeiten und Schaltdauern pro Wochentag realisieren könnten:

// Morgenanhebung deaktivieren um 9:15 Montags
[13,9,15,1],
// Morgenanhebung deaktivieren um 9:15 Dienstags
[13,9,15,2],
// Morgenanhebung deaktivieren um 9:15 Mittwochs
[13,9,15,3],
// Morgenanhebung deaktivieren um 9:15 Donnerstags
[13,9,15,4],
// Morgenanhebung deaktivieren um 9:15 Freitags
[13,9,15,5]

Fertig ist die ESP basierte Heizungs-Zeitschaltung:

{"c":
{"z":0,
// NTP Server
"ntp":"time.apple.com",
// POSIX Zeitzone Europe/Berlin
// https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv
"tz":"CET-1CEST,M3.5.0,M10.5.0/3",


// TimeTable Action Nachtabsenkung (Schalter 1) aktivieren
"10":{"m":[[1,1]]},
// TimeTable Action Nachtabsenkung (Schalter 1) deaktivieren
"11":{"m":[[1,0]]},
// TimeTable Action Morgenanhebung (Schalter 2) aktivieren
"12":{"m":[[2,1]]},
// TimeTable Action Morgenanhebung (Schalter 2) deaktivieren
"13":{"m":[[2,0]]},
// Anfang der Timetable-Zeitschaltungen
"tt":[
// Nachtabsenkung aktivieren um 23:45
[10,23,45],
// Nachtabsenkung deaktivieren um 6:30
[11,6,30],


// Morgenanhebung aktivieren um 7:45 Montags
[12,7,45,1],
// Morgenanhebung aktivieren um 7:45 Dienstags
[12,7,45,2],
// Morgenanhebung aktivieren um 7:45 Mittwochs
[12,7,45,3],
// Morgenanhebung aktivieren um 7:45 Donnerstags
[12,7,45,4],
// Morgenanhebung aktivieren um 7:45 Freitags
[12,7,45,5],


// Morgenanhebung deaktivieren um 9:15 Montags
[13,9,15,1],
// Morgenanhebung deaktivieren um 9:15 Dienstags
[13,9,15,2],
// Morgenanhebung deaktivieren um 9:15 Mittwochs
[13,9,15,3],
// Morgenanhebung deaktivieren um 9:15 Donnerstags
[13,9,15,4],
// Morgenanhebung deaktivieren um 9:15 Freitags
[13,9,15,5]
]
},
"a":[
// Schalter Nachtabsenkung (1)
{"t":1,
"0":{"m":[
[7001,-10001]
]},
"1":{"m":[
[7001,0],
[7001,-10000],
]}},
// Schalter Morgenanhebung (2)
{"t":1}
]
}

Oder komprimiert und damit Speicheroptmiert:

{"c":{"z":0,"ntp":"time.apple.com","tz":"CET-1CEST,M3.5.0,M10.5.0/3","10":{"m":[[1,1]]},"11":{"m":[[1,0]]},"12":{"m":[[2,1]]},"13":{"m":[[2,0]]},"tt":[[10,23,45],[11,6,30],[12,7,45,1],[12,7,45,2],[12,7,45,3],[12,7,45,4],[12,7,45,5],[13,9,15,1],[13,9,15,2],[13,9,15,3],[13,9,15,4],[13,9,15,5]]},"a":[{"t":1,"0":{"m":[[7001,-10001]]},"1":{"m":[[7001,0],[7001,-10000],]}},{"t":1}]}

Hinzugefügt wurde für die Nachtabsenkung noch eine bereits beim Blink-Generator eingesetzte Option, den Schalter für die Morgenanhebung auszuschalten und komplett zu deaktivieren, um versehentliches Schaltens desselben während der Nachtabsenkung auszuschließen.

Ich sehe spätestens an dieser Stelle meines Beitrag einige Forumsteilnehmende bereits wieder mit dem Kopf schütteln, weil all die beschriebenen Zeitschaltungen viel "einfacher" in der Home App als Automationen angelegt werden können oder weil diverse Heizthermostat-Anbieter in ihren Apps noch schönere grafische Zeitautomationstabellen zur Verfügung stellen. Die Gründe für ein angestrebtes Outsourcing diverser Automationen aus HomeKit sind jedoch vielfältig und von den persönlichen Erfahrungen abhängig. Ich zumindest bin seit Monaten beeindruckt vom schweizerischen Timing meiner ESP-Zeitschaltungen im Vergleich zu den vorher durch HomeKit ausgeführten Automationen. Ich erahne außerdem durch die "Automationsentlastung" von HomeKit eine insgesamte verbesserte Stabilität meines gesamten Systems.

Einer geht noch:

Das obige Beispiel folgt in seiner Einfachheit einer starren Zeitlogik, die nicht unbedingt immer lebensnah ist. Wenn mein Heim mal mehrere Tage verwaist, sollten die Automationen natürlich ausgesetzt werden. Ich könnte nun wieder in HomeKit die oben genannten, bewusst einfachst gehaltenen Heizungsszenen-Automationen durch Bedingungen erweitern, also wenn loonypac nicht daheim -> dann schalte nicht die Morgenanhebungs-Szene, jedoch wäre es schöner, wenn ich bei Bedarf manuell die Zeitautomationen deaktivieren könnte – im optimalen Fall per zusätzlicher HomeKit Schalter für alle Wochentage samt der Nachtabsenkung.

In der Tat habe ich eine solche Schaltmöglichkeit ergänzt, was es nun möglich macht, dass ich für die verschiedensten Bedürfnisse beliebige Tagesautomationen zu ebenso beliebigen Zeiten de-/aktiveren kann, was die Schaltoberfläche laut Abbildung zu Anfang des Beitrags wiederspiegelt.

// Multitasking Wecker in HomeKit wählbar
{"c":
{"z":0,
// NTP Server
"ntp":"time.apple.com",
// POSIX Zeitzone Europe/Berlin
// https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv
"tz":"CET-1CEST,M3.5.0,M10.5.0/3",


// TimeTable Actions Morgenanhebung Mo bis So aktivieren
"11":{"m":[[1,2],[1,1]]},
"12":{"m":[[2,2],[2,1]]},
"13":{"m":[[3,2],[3,1]]},
"14":{"m":[[4,2],[4,1]]},
"15":{"m":[[5,2],[5,1]]},
"16":{"m":[[6,2],[6,1]]},
"17":{"m":[[7,2],[7,1]]},


// TimeTable Actions Morgenanhebung Mo bis So deaktivieren
"21":{"m":[[1,3],[1,0]]},
"22":{"m":[[2,3],[2,0]]},
"23":{"m":[[3,3],[3,0]]},
"24":{"m":[[4,3],[4,0]]},
"25":{"m":[[5,3],[5,0]]},
"26":{"m":[[6,3],[6,0]]},
"27":{"m":[[7,3],[7,0]]},


// TimeTable Action Nachtabsenkung aktivieren
"30":{"m":[[8,2],[8,1]]},
// TimeTable Action Nachtabsenkung deaktivieren
"31":{"m":[[8,3],[8,0]]},


// Anfang der Timetable-Zeitschaltungen
"tt":[
// Morgenanhebung aktivieren um 7:45 Montags
[11,7,45,1],
// Morgenanhebung aktivieren um 7:45 Dienstags
[12,7,45,2],
// Morgenanhebung aktivieren um 7:45 Mittwochs
[13,7,45,3],
// Morgenanhebung aktivieren um 7:45 Donnerstags
[14,7,45,4],
// Morgenanhebung aktivieren um 7:45 Freitags
[15,7,45,5],
// Morgenanhebung aktivieren um 9:45 Samstags
[16,9,45,6],
// Morgenanhebung aktivieren um 9:45 Sonntags
[17,9,45,7],


// Morgenanhebung deaktivieren um 9:15 Montags
[21,9,15,1],
// Morgenanhebung deaktivieren um 9:15 Dienstags
[22,9,15,2],
// Morgenanhebung deaktivieren um 9:15 Mittwochs
[23,9,15,3],
// Morgenanhebung deaktivieren um 9:15 Donnerstags
[24,9,15,4],
// Morgenanhebung deaktivieren um 9:15 Freitags
[25,9,15,5],
// Morgenanhebung deaktivieren um 11:15 Samstags
[26,11,15,6],
// Morgenanhebung deaktivieren um 11:15 Sonntags
[27,11,15,7],


// Nachtabsenkung aktivieren täglich um 23:45
[30,23,45],
// Nachtabsenkung deaktivieren täglich um 6:30
[31,6,30]
]
},


"a":[
// Unsichtbarer Auslöser Morgenanhebung Mo bis So
{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},
{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},
{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},
{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},
{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},
{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},
{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},


// Unsichtbarer Auslöser Nachtabsenkung
{"h":0,"0":{"m":[[18,0]]},"1":{"m":[[18,1]]}},


// Einzelautomationen Morgenanhebung Mo bis So
{"xa":0,"s":1,"0":{"m":[[1,-10000]]},"1":{"m":[[1,-10001]]}},
{"xa":0,"s":1,"0":{"m":[[2,-10000]]},"1":{"m":[[2,-10001]]}},
{"xa":0,"s":1,"0":{"m":[[3,-10000]]},"1":{"m":[[3,-10001]]}},
{"xa":0,"s":1,"0":{"m":[[4,-10000]]},"1":{"m":[[4,-10001]]}},
{"xa":0,"s":1,"0":{"m":[[5,-10000]]},"1":{"m":[[5,-10001]]}},
{"xa":0,"s":1,"0":{"m":[[6,-10000]]},"1":{"m":[[6,-10001]]}},
{"xa":0,"s":1,"0":{"m":[[7,-10000]]},"1":{"m":[[7,-10001]]}},


// Einzelautomationen Nachtabsenkung
{"xa":0,"s":1,"0":{"m":[[8,-10000]]},"1":{"m":[[8,-10001]]}},


// Schalter Morgenanhebung (17)
{"t":1},


// Schalter Nachtabsenkung (18)
{"0":{"m":[[-1,-10001]]},"1":{"m":[[-1,0],[-1,-10000],]}}
]
}

Oder komprimiert:

{"c":{"z":0,"ntp":"time.apple.com","tz":"CET-1CEST,M3.5.0,M10.5.0/3","11":{"m":[[1,2],[1,1]]},"12":{"m":[[2,2],[2,1]]},"13":{"m":[[3,2],[3,1]]},"14":{"m":[[4,2],[4,1]]},"15":{"m":[[5,2],[5,1]]},"16":{"m":[[6,2],[6,1]]},"17":{"m":[[7,2],[7,1]]},"21":{"m":[[1,3],[1,0]]},"22":{"m":[[2,3],[2,0]]},"23":{"m":[[3,3],[3,0]]},"24":{"m":[[4,3],[4,0]]},"25":{"m":[[5,3],[5,0]]},"26":{"m":[[6,3],[6,0]]},"27":{"m":[[7,3],[7,0]]},"30":{"m":[[8,2],[8,1]]},"31":{"m":[[8,3],[8,0]]},"tt":[[11,7,45,1],[12,7,45,2],[13,7,45,3],[14,7,45,4],[15,7,45,5],[16,9,45,6],[17,9,45,7],[21,9,15,1],[22,9,15,2],[23,9,15,3],[24,9,15,4],[25,9,15,5],[26,11,15,6],[27,11,15,7],[30,23,45],[31,6,30]]},"a":[{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},{"h":0,"0":{"m":[[17,0]]},"1":{"m":[[17,1]]}},{"h":0,"0":{"m":[[18,0]]},"1":{"m":[[18,1]]}},{"xa":0,"s":1,"0":{"m":[[1,-10000]]},"1":{"m":[[1,-10001]]}},{"xa":0,"s":1,"0":{"m":[[2,-10000]]},"1":{"m":[[2,-10001]]}},{"xa":0,"s":1,"0":{"m":[[3,-10000]]},"1":{"m":[[3,-10001]]}},{"xa":0,"s":1,"0":{"m":[[4,-10000]]},"1":{"m":[[4,-10001]]}},{"xa":0,"s":1,"0":{"m":[[5,-10000]]},"1":{"m":[[5,-10001]]}},{"xa":0,"s":1,"0":{"m":[[6,-10000]]},"1":{"m":[[6,-10001]]}},{"xa":0,"s":1,"0":{"m":[[7,-10000]]},"1":{"m":[[7,-10001]]}},{"xa":0,"s":1,"0":{"m":[[8,-10000]]},"1":{"m":[[8,-10001]]}},{"t":1},{"0":{"m":[[-1,-10001]]},"1":{"m":[[-1,0],[-1,-10000],]}}]}

Zitat von meistermolli

Vielleicht war es aus Sicht von Smartapfel aber nicht die intelligenteste Lösung alle anderen Systeme aus dem Forum zu reglementieren.

Obwohl ich die Entscheidung einerseits nachvollziehen kann, empfinde ich die selbstgewählte "Eingrenzung" auch als etwas zu streng. Dadurch werden sicherlich manche Chancen verpasst.

Zitat von meistermolli

So Läuft bei mir die Homebridge für Kleinigkeiten immer noch auf Homeassistant als Addon.

Wobei sich die (unerlaubte) rhetorische Frage stellt: Was kann Homebridge, das HomeAssistant nicht (alleine) kann bzw. wofür brauchts eine Homebridge in HomeAssistant?

Tatsächlich ist in diesem Zusammenhang für mich nach einer neulichen HomeAssistantOS Test-Installation klar geworden, dass dadurch eine Homebridge vollständig ersetzbar wird, selbst ohne eine einzige Automation darüber abzufeuern. Ich kann mich täuschen, würde aber trotzdem nicht mehr zur Homebridge zurückkehren.

Zitat von meistermolli

Ich wünsche mir eigentlich mit einer Plattform wie dieser hier, dass wir die arme aus der Apple Wolke in alle Richtungen strecken können.

Ich erlebe Apples HomeKit seit anno 2018 als ungeliebtes Apple Adoptivkind, das in einer dunklen Besenkammer der Ufo förmigen "Infinite Loop" bei Wasser und Brot sich selbst überlassen wird, um quotenmäßig ab und zu hervorgeholt zu werden nach dem Motto: Smarthome haben wir bei Apple auch.

Bezogen auf den Beitragstitel stellt sich für mich in diesen Tagen eher die bange Frage, ob Apples HomeKit überhaupt noch in den nächsten 5 Jahren eine Rolle spielen wird.

Zitat von Edward J. Nately III

Ansonsten knicke ich das Projekt "Doorbell" und weise vielleicht besser allen Klingeltastern den AccessoryTyp "Contact-Sensor" zu? Da wären Automationen dann überhaupt kein Problem.

… oder Anwesenheitssensor.

Wie du selbst schreibst, brauchst du für die oben angestrebten Automationen kein explizites Doorbell-Accessory und kannst über besagte zahlreichen Alternativen bis auf den individuellen HomePod-Klingelton alle oben erwähnten Automationen sehr einfach umsetzen. Wobei die Lichtschalte sogar mit deiner jetzigen Türklingeldefinition möglich sein sollte.

Verstehe ich das richtig? Die Türklingel schickt an alle HomeKit-Teilnehmer eine Nachricht und kann nicht einzeln über "Status und Mitteilungen" de-/aktiviert werden wie es dies bei Sensoren möglich ist?

Hab’s grad getestet: Ist tatsächlich so = sinnfrei

Beim HomePod bin ich in Ermangelung eines Solchen raus. Gibt es dafür denn überhaupt eine Möglichkeit, um einzelne Audiofiles gezielt (wodurch auch immer) abzufahren? Rein technisch sollte das für so’n Ding ja ein Leichtes sein.

Zitat von Edward J. Nately III

Den Typ hab ich noch nicht verstanden.

Ich rudere zurück, macht beim Rauchmelder auch nur bedingt Sinn, da der ja immer anschlagen soll. Der Security Switch ist eher für Einbruchalarme gedacht. Also reicht für deinen Fall "t":8 (Smoke Sensor).

Zitat von Edward J. Nately III

Immer her damit (siehe Grabinschrift). Am besten als Privatissimum per Konversation

Danke, komme drauf zurück

Zitat von Edward J. Nately III

Beim Shelly geht's doch auch.

Wie sieht denn für’s Shelly das Skript aus? Oder haste andere Firmware drauf?

Zitat von Edward J. Nately III

Was Stromsparendes. Der MQ-2 zieht bis zu 850 mW

Das ist in der Tat üppig

Zitat von Edward J. Nately III

Nee, die sind ausgesprochen genügsam, zumal oft nur gepulst betrieben.

Ich hatte nur was von Relais gelesen. Ok, dann wäre doch deine perfekte Lösung, solch einen opto-Elektrischen in sehr Baumarkt günstig zu erwerben, um dessen Schaltimpuls für Alarm auf einen GPIO des ESP zu führen. Im ESP kannst du dann sinnigerweise den Service Type "Security System" bemühen, um es richtig krachen zu lassen, sobald Rauch entdeckt wird.

Schließlich erlebe ich dich hier als Elektrogeräte-Kompetenz (auf die ich bei Gelegenheit in eigener Sache nochmal zurückkomme), dem ich eine solche Lötarbeit zutraue

Zitat von Edward J. Nately III

Ich vermute mal, Raven läßt eine Klingel ausschleißlich als stateless button zu, weil Homekit mittlerweile eine Doorbell grundsätzlich nur noch als Videogerät betrachten will.

Weswegen ich davon ausgehe, dass nicht Raven sondern Apple es nicht "zulässt".

Zitat von Sequoia

Nach 30 Minuten schaut ja die Automation: ah, es ist kälter als 21°, also mache ich die Heizung mal wieder an.

Unter der Bedingung Tür = geschlossen macht sie das nicht und legt sich wieder hin

Anderer Ansatz mit identischem Ziel. (Allerdings vermutlich zu kompliziert )

+++ Nachtrag als Kurzfassung für Lesefaule, die an einer Automation für alle Eventualitäten interessiert sind:

Man benötigt dafür pro Fenster/Tür 1 Timer + 1 Statusschalter. Details sind im oberen Link ausführlich erklärt. Diese Automation läuft bei mir seit mehreren Monaten absolut zuverlässig.

Automation 1

Auslöser: Fenstersensor öffnet, Heizung wird aktiviert

Bedingungen: Fenstersensor offen, Heizung aktiviert

Schaltergebnisse: Timer AN, Status AN

Automation 2

Auslöser: Timer AUS

Bedingungen: Fenstersensor ist offen

Schaltergebnisse: Szene Heizung AUS

Automation 3

Auslöser: Fenstersensor schließt

Bedingungen: Statusschalter ist an

Schaltergebnisse: Szene Heizung AN, Status AUS

Automation 4

Auslöser: Heizung wird deaktiviert, Timer schaltet an

Bedingungen: Heizung deaktiviert, Timer ist an

Schaltergebnisse: Status AUS

Zitat von Edward J. Nately III

Der MQ-2 soll ein thermolektrischer Sensor sein. Empfindlich, aber eben auch stromhungrig.

Was hätten’s denn gern?

Hab mal recherchiert und zumindest eine Beschreibung über Rauchmelderfunktionsweisen gefunden.

Die klassischen opto-elektronischen werden vermutlich noch stromhungriger sein?!

Wolltest du den ESP denn per Akku betreiben?

Zitat von Edward J. Nately III

Gibt es nicht irgendwo ne Übersicht, welche Hardware, welchen Service Type, an welchem GPIO, mit welchem Skript unterstützt?

Bei der Vielfalt an Sensoren, Modulen und Bauteilen wäre das sicherlich ein endloses Unterfangen und eigentlich unnötig, denn im Prinzip sind die GPIOs doch sehr übersichtlich zu benutzen, bspw. beim D1 Mini:

• Alle I2C-Gerätschaften an GPIO 4 + 5 (D02 + D01)
• Alle Analog-Gerätschaften an ADC (A0)
• Alles, was schaltet an beliebige GPIOs (unter Beachtung der Besonderheiten, die ich in der LED Bastelstunde per Bild und Tabelle aufgelistet habe)
• Stromversorgung je nach Bauteil und Betriebsspannung an 3V3 oder 5V

Zitat von Edward J. Nately III

Frage an die Raver mit HAA-Home-Manager v3.4.3:

Ich komme per App nicht mehr in den Setup-Mode. Ist das bei Euch auch so?

Kann ich leider bestätigen. Interessanterweise funktioniert der Setup Mode bei Firmwareversionen 11.8.0 noch tadellos und nur bei der aktuellen 11.9.1 nicht. Ich denke, dass das hoffentlich zeitnah nachgebessert wird.

EDIT: Ist bereits gefixt und wartet derzeit auf Apple-Freigabe 

Zitat von Edward J. Nately III

Mein erster Entwurf für den D1mini schaut so aus:

Habe mal dein Skript (theoretisch) analysiert und im Folgenden kommentiert:

{
  "c":{"z":0},
  // Deaktivierung des Setup Modes durch mehrfaches Toggeln
  "a": [
    {"t": 13,
    // Türklingel 1
     "f0": [{ "g": 14, "t": 1 }],
     "f1": [{ "g": 14, "t": 2 }],
     "f2": [{ "g": 14, "t": 3 }]
     // Schalter an GPIO 14 mit Single/Double/Long Press
    },
    {"t": 13,
    // Türklingel 2
    "f0": [{ "g": 16, "t": 1 }],
    "f1": [{ "g": 16, "t": 2 }],
    "f2": [{ "g": 16, "t": 3 }]
    // Schalter an GPIO 16 mit Single/Double/Long Press
    },
    {"t": 4,
    // Schließmechanismus
    "xa":0,
    // KEIN Schaltbefehl nach Boot
    "i": 3,
    // Schließt ("0") 3 Sekunden, nachdem geöffnet ("1") wurde
    "0": { "r": [{ "g": 4, "v": 1, "i": 3 }] },
    // Schließen setzt GPIO 4 auf high
    // WICHTIG: "i" im Aray GPIO ist NICHT Inching, sondern Inverted Binary Input mit möglichen Werten 0 oder 1
    "1": { "r": [{ "g": 4 }] },
    // Öffnen setzt GPIO 4 auf low
    "b": [{"g":12,"p":0,"i":1,"t":0}]
    // Schalter an GPIO 12, Pullup Widerstand deaktiviert (GPIO hat keinen internen Widerstand), invertierte Schaltung, Single Press Opposite
     },
     {"t": 1,
     // Einfacher Schalter
      "xa":0,
      // KEIN Schaltbefehl nach Boot
      "d": 1,
      // Bleibt maximal 1 Sekunde eingeschaltet
      "0": { "r": [{ "g": 5, "v": 0 }] },
      // Schalter AUS = GPIO 5 auf low
      "1": { "r": [{ "g": 5, "v": 1 }] }
      // Schalter AN = GPIO 5 auf high
     },
     {"t": 12,
     // Bewegungssensor
     "i": 10,
     // Schaltet nach Bewegungserkennung nach 10 s zurück
     "f1": [{ "g": 13 }]
     // Sensor an GPIO 13
     },
     {"t": 2,
     // Virtuelle Steckdose
     "1":{"s":[{"a":1}]}   
     // Aktiviert beim Einschalten den ESP Setup Mode
     }

       ]
}

Bei hektischen Dauerklinglern kann es passieren, dass der ESP in den Setup Mode geschaltet wird und damit den kompletten ESP für HomeKit deaktiviert. Um das auszuschließen, habe ich eine Ergänzung in der Konfiguration "c" des ESP eingetragen. Außerdem eine virtuelle Steckdose ergänzt zum bequemen Aktivieren des Setup Mode In der Home App (solange der HAA Manager noch nicht funzt)

Hinweise:

• Derzeit hast du 2 unabhängige Klingeln definiert. Soll das so sein, oder ist 1 Klingel mit 2 verschiedenen Schaltern gemeint?
• Schließmechanismus beinhaltet ungültige Werte für "i" (s. Kommentare im Skript), außerdem ist der Schalter an GPIO 12 quasi 2x invertiert, ist das so gewollt?
• Auch der Schließmechanismus schaltet derzeit invertiert, also beim Schließen wird er GPIO 4 auf high gesetzt und umgekehrt.

Zitat von Edward J. Nately III

Die beiden 13er Schalter melden sich leider nicht als Doorbell. Hat jemand ne Idee, wie das aussehen muß, damit sie als Klingeldingel in Homekit auftauchen?

In der Raven Doku wird nur erwähnt, dass die Türklingel im Unterschied zum Stateless Button eine Nachricht absenden kann. Ohne das ausprobiert zu haben nehme ich an, dass die Türklingel also nicht als Türklingel sondern als Schalter in HomeKit angezeigt wird und nur zusätzlich nach Aktivierung eine Message abschicken kann?!

Zitat von Raven System

"Doorbell service works like a stateless button, and it sends a notification when single press type is triggered"

Zitat von Edward J. Nately III

PS: Da noch GPIOs frei sind, könnte ich noch einen Rauchmelder für das Treppenhaus dranhängen. Gibt es Empfehlungen für geeignete Sensoren? Der darf gern auch etwas kosten, solange er keine Fehlalarme liefert und trotzdem hinreichend empfindlich ist.

Rauchsensor wäre dieser vielleicht geeignet. Der hat den Vorteil, dass die Empfindlichkeit für den Digital Out per Trimpoti "justiert" werden kann. Ob das zuverlässig läuft, kann ich nicht sagen.

Ggf. könnte für den Zweck statt dessen auch der Service Type "Air Quality" genutzt werden, um den analogen Ausgang des Sensors auszulesen, was dann sicherlich präzisere Schaltungen zuließe.

Wobei ich persönlich dann lieber genau das Ding einmal in einer Drittanbieter-App einrichten würde, als dieses ganze Rumgefummel mit Kurzbefehlen und HomeKit-Automation als Funktionsfalle für das nächste HomeKit-Update aufzubauen. Ist natürlich jedem überlassen.

Nur mal für‘s Protokoll eine Frage an die erfahrenen Homebridge-Hasen und Häsinnen:

Gibt es tatsächlich kein Delayswitch-PlugIn, das einen Delayswitch auf Wunsch selbsttätig innerhalb der Plugin-Logik per Endlos-Schleife reaktiviert? Also ohne HomeKit- und Kurzbefehl-Gefummel?

Bevor gleich Spy wieder nachvollziehbarerweise alles löscht, empfehle ich tatsächlich eine Fortsetzung der derzeit erneut entgleitenden Automationsthematik im ursprünglichen Beitrag, um dich hier auf die Konfiguration des Delay-Switches zu konzentrieren (am besten nachdem deine wilde These der grundsätzlichen Auslöser-Löschung geklärt wurde).

Ich bin bis auf Weiteres raus.

Zitat von Sequoia

ein no-go, bzw. ein großer Pluspunkt für die Homebridge.

Versteh ich nicht. Es ist also von Vorteil, wenn für einen banalen DelaySwitch eine Synology NAS 24/7 laufen muss, statt eines kleinen D1 Mini mit einem Energiebedarf im Milliwatt-Bereich?

… wobei wir wieder zum Anfang zurückkehren können mit meiner Anmerkung, wie du deine ursprünglichen Automationen umgestalten kannst.

Zitat von loonypac

Du solltest deine ursprünglichen Automationen nutzen können und ersetzt einfach den Auslöser "beliebige Temperatur" durch den neuen "Delayswitch EIN", sodass immer dann, wenn derselbe sich nach 30 Minuten neu einschaltet, die gewünschte Automation anstößt und überprüft, ob der Bedingungswert der Temperaturgrenzen über- bzw. unterschritten wird. Du brauchst natürlich für jede Temperatur 1 separate HomeKit-Automation.

Zitat von Sequoia

Braucht man denn, um das ins Home einzupflegen, noch Hardware in Form von irgendwelchen Microkontrollern?

Ein ganz klares JEIN

Wenn du deine Shellys nicht auf Raven umflashen willst, dann ja. Wenn doch, dann nein.

Zitat von Edward J. Nately III

Nachdem ich zunächst gar nicht begriffen hatte, was das ist und wie das geht, finde ich Raven mittlerweile extrem geil!

Das freut nochmal mehr

Zitat von Sequoia

Das ist ja das Problem an der neuen Homekit Architektur, dass sie die Bedingungen raus wirft, sobald die Zentrale wechselt, oder die Homepods mal vom Strom genommen wurden.

Moment, moment: Ist das so? Ich verstehe es die ganze Zeit so, dass nur ein "Auslöser" in der Form "beliebige Temperaturänderung" rausgeworfen wird. Da sind dann nochmal jene gefragt, die das Architektur-Update gemacht haben. Ich bin auf 16.3 ohne dieses Update und kann alle Bedingungen einstellen, die ich will, ohne dass irgendwas gelöscht wird.

Titanicberlin war schneller

HolgerKR ich nehm das mal stellvertretend für uns (bislang 4) Raver als Kompliment Freut mich, dass ein gewisser Wert im gesamten Geschreibsel rauszulesen ist. Ich werde erstmal dabeibleiben und noch ein paar Ideen ausprobieren.

Das, was ich aus deinem ursprünglichen Beitrag von @Kohle_81 finden kann, ist das PlugIn Homebridge-automation-switches, dabei speziell den Automation Switch. Hast du ein anderes? Nochmal: Link wär hilfreich.

Die Automation selbst würde ich in deinem ursprünglichen Beitrag weiterführen. Dann könntest du die beiden Beiträge auch sehr hilfreich für andere zueinander verlinken.

Aber schon jetzt sei verraten: Ohne Bedingungen, die in der Home App nicht einzugeben sind, wird’s nach meiner Einschätzung knifflig bis unmöglich.

Ist das jetzt eine Frage, wie du den Delayswitch einstellen musst, oder eine Frage wie die Automationen damit in HomeKit angelegt werden müssen?

Für Ersteres wäre es schonmal hilfreich zu wissen, welches PlugIn genau du verwendest, indem du einen Link dazu postest, damit wir die notwendige config.json beurteilen können.

Für Letzteres bist du hier im falschen Forum, da es sich um eine Automation handelt.

Trotzdem eine Antwort dazu:

Du solltest deine ursprünglichen Automationen nutzen können und ersetzt einfach den Auslöser "beliebige Temperatur" durch den neuen "Delayswitch EIN", sodass immer dann, wenn derselbe sich nach 30 Minuten neu einschaltet, die gewünschte Automation anstößt und überprüft, ob der Bedingungswert der Temperaturgrenzen über- bzw. unterschritten wird. Du brauchst natürlich für jede Temperatur 1 separate HomeKit-Automation.

War das verständlich genug erklärt?

Zitat von Sequoia

Alles klar. Das tut mir leid.

Dann lass uns das doch mal versuchen.

Was muss ich genau machen, um den Switch in Home zu bekommen?

Entschuldigung angenommen.

Ich schlage dennoch vor, dass du dich erstmal entscheidest, was du machen willst, denn wie ich sehe bist du zeitgleich in Homebridge zum gleichen Thema unterwegs.

Ich finde es nicht sonderlich fair, alle Hühner für ein vergleichsweise simples Problem aufzuscheuchen, um gleichzeitig 2 Äcker von engagierten Forumsteilnehmenden bewirtschaften zu lassen, damit du dann das Bequemste abernten kannst. Sorry