Hallo Leute,
in letzter Zeit beschäftigt mich ein fundamentales Problem:
Ich habe in jedem Raum eine "Lichtautomatik", welche bei Anwesenheit je nach gemessener Helligkeit im Raum meine dimmbaren Lampen auf einen angemessenen Dimm-Wert einstellt. Allerdings möchte ich auch gelegentlich das Licht manuell überschreiben (über Funktaster, Siri oder Alexa). Tue ich das nun während meine Automatik aktiv ist, wird dieser Zustand wieder von meiner Automatik zurückgesetzt.
Wie handhabt ihr das?
Gibt es eine Möglichkeit, zu detektieren, welcher Trigger gerade das Licht gesetzt hat, sodass ich entsprechend meine Lichtautomatik abschalten kann wenn es ein "manual overwrite" war?
Vielen Dank im Voraus für jegliche Tipps,
Mathea
Hi Mathea,
das könnte man z.B. mit einem DOIF lösen.
Deine Lichtautomatik triggert nicht mehr direkt den dimmer, sondern über das DOIF, kommt nun dein manueller Eingriff, läuft der Trigger der Automatik ins leer, bis, jetzt bist du wieder gefragt, irgend ein Ereignis das DOIF wieder dazu bringt den Trigger der Lichtautomatik durchzureichen. Das kann ne Zeit sein, ein deutlicher Wechsel in den Lichtverhältnissen etc etc etc :-)
Erzähl doch mal ein bisschen mehr dann lässt sich sicher was grobes zusammenschnippseln, das Feintuning kannste dann ja am Objekt machen :-)
Grüße
Achim
Ich Frage immer einen Dummy vorher ab. Ist der on geht es über Automatik ist der off greift keine Automatik.
Brauche ich aber eher selten.
Vielen Dank für die Antworten bisher.
Ein paar mehr Infos: Ich habe pro Raum einen dummy "Lichtautomatik", der auch in meiner DOIF-Funktion zum Setzen der Helligkeitswerte abgefragt wird. Ist dieser dummy aus, passiert kein automatisiertes schalten, ist er an, dann schon (CoolTux, so wie es bei dir auch ist, oder?). Ich könnte jetzt natürlich hingehen und diesen dummy jedes mal bevor ich einen manuellen Schaltbefehl absetze abschalten, aber das finde ich unnötig kompliziert.
Meine Vorstellung war es also, irgendwie zu detektieren, welche Quelle gerade meine Lampe geschaltet hat. Mit einem weiteren DOIF könnte ich im Falle eines "manuellen Schaltbefehls" (Taster am Lichtaktor / Sprachbefehl / App / ...) dann auf diesen Trigger reagieren und dementsprechend automatisch den dummy "Lichtautomatik" abschalten, damit keine automatische Veränderung mehr stattfindet. Das einzig fehlende Puzzlestück scheint zu sein, aus den fhem Events herauszufiltern, welches Triggersignal meine Lampe gerade geschaltet hat.
Mein Arbeitskollege nutzt IP-Symcon und laut seiner Aussage bekommt man in einem Event auch immer die Information mit, wodurch ein Schaltbefehl gerade ausgelöst wurde. Wäre das also z.B. meine Automatikfunktion, würde dort irgendwas in dieser Art stehen: "Lichtautomatik -> Deckenleuchte bri 200".
In FHEM bekomme ich in meinem Eventmanager allerdings nur ein separates Event für das Feuern meiner DOIF Funktion und ein separates Event für den Helligkeitszustand meiner Lampe.
Schalte ich eine Philips Hue Lampe nun beispielsweise über die Philips App, sehe ich lediglich: "Deckenleuchte bri 200". Das reicht aber nicht aus, um zu ermitteln, ob das Gerät gerade durch einen externen Schaltbefehl oder meine Lichtautomatik-Funktion geschaltet wurde, oder unter Umständen sogar einfach nur eine zyklische Statusmessage sendet. Ich habe also nichts was ich sicher als Trigger zum Abschalten meines Automatik-dummys nutzen könnte.
Hat hier jemand eine Idee?
Das wird wohl nicht so einfach gehen.
Die Frage ist ja auch, brauch man für jeden Raum eine Automatik für das Licht?
Die Frage kannst natürlich nur Du beantworten. Bei mir gibt es eine komplette Automatic für Licht. Nur die eine. Damit wird Wohnzimmer und Flur geschalten. Mehr nicht. Nun habe ich ein Dummy für AutomaticKomplett und eine für AutomagicFlur. Die Flur auch nur weil mal im Schlaf oder Kinderzimmer zur Nacht die Türen aufbleiben. Alles andere muss nicht nach Zeit oder Azimut und Wetter geschalten werden. Ausnahme Weihnachtsbeleuchtung. Die hängt noch mit drin.
Davon unberührt ist natürlich das automatische ausschalten wenn alle ausser Haus sind oder es hell genug draussen ist. Oder das ein schalten des Lichts auch im Kinderzimmer wenn das passende Kind im Dunkeln nach Hause kommt.
Meine Empfehlung nicht alles bunt und farbenfroh nach Temperatur und Sonnenstand schalten. Nur da wo es Sinn macht ;D
Danke für deine Antwort, CoolTux,
ich sehe das so, dass man sich mit dem großen Aufwand der Heimautomatisierung viele Freiheiten erkauft, die ich auch optimal nutzen möchte. Für mich gehört dabei das automatische Schalten des Lichtes in jedem Raum abhängig von den äußeren Gegebenheiten dazu.
Und der Einfachheit und Konsequenz halber möchte ich das Verhalten jedes einzelnen Raumes identisch halten. Dementsprechend hat jeder Raum bei mir zuhause eine Lichtautomatik :D Wenn es jetzt noch eine Möglichkeit gäbe, diese ohne Zusatzaufwand des Bedieners (temporär) manuell zu überschreiben, wäre das meiner Meinung nach das Optimum (ob ich es jeden Tag nutzen werde sei dahingestellt). Eine Heimautomation soll ja letztendlich das Leben angenehmer und nicht komplizierter machen.
Mich wundert es allerdings, dass das in fhem wohl kein leichtes Unterfangen wird.
Und wie machst du es mit Räumen wo sich keiner drin befindet? Was bringt Licht im Schlaf oder Kinderzimmer wenn keiner drin ist.
Leider fällt mir nicht wirklich eine Idee ein wie man das mache kan. Was Du willst.
In Räumen, in denen sich niemand befindet wird das Licht ab- bzw. erst gar nicht eingeschaltet. Das ist bei mir aktuell alles per Bewegungsmelder gesteuert (wobei ein Bewegungsmelder natürlich auch Limits hat, wie wenn ich z.B. regungslos in einem Raum bin, aber das ist eine andere Geschichte).
Hm, das ist natürlich schade. Aber vielleicht fällt ja noch jemandem etwas ein.
Ansonsten werde ich vielleicht das Feature in unsere fhem-Wunschliste einreichen, dass das Schalten eines Devices durch die DOIF Funktion einen entsprechenden Vermerk im Event erzeugt.
Kapsel doch den Aktor in eine Perl Funktion
Braindump not tested
Sub SetAktor($Name, $Sender, $Value) {
...
}
dann musst Du "nur" noch überall den Schaltbefehl gegen Deine Funktion austauschen
eigentlich ganz einfach *duckundweg*
Ralf
Zitat von: Wuppi68 am 05 Dezember 2016, 15:20:24
Kapsel doch den Aktor in eine Perl Funktion
Braindump not tested
Sub SetAktor($Name, $Sender, $Value) {
...
}
dann musst Du "nur" noch überall den Schaltbefehl gegen Deine Funktion austauschen
eigentlich ganz einfach *duckundweg*
Ralf
Hi Ralf,
danke, das klingt interessant, aber ich bin mir nicht sicher, ob das mein Problem vollständig lösen kann.
Ich kann den Aktor ja nur über die Perl Funktion schalten, sofern ich das in meiner DOIF Automatik tue. Schalte ich das Gerät über die native App / Alexa / was auch immer, bekomme ich diesen Vorgang nur über ein Event im Eventmonitor mit, das in etwa so aussieht: "Deckenleuchte bri 200". Würde ich nun eine Perl Funktion nutzen, um den Aktor in meiner DOIF Automatik zu schalten, hätte ich doch das gleiche Event dort stehen, oder?
Mir ist ansonsten folgender Ansatz eingefallen: Ich könnte eine Funktion schreiben, die meine Events durchsucht, ob sich der Ist-Zustand eines Gerätes von dem nach Automatik erwarteten Soll-Zustand unterscheidet. Diesen Soll-Zustand würde ich zum Beispiel in einem dummy Hinterlegen, der von meiner Automatik jedes Mal beim Schalten gesetzt wird. Wäre das möglich?
Gruß,
Mathea
Zitat von: Mathea am 05 Dezember 2016, 15:51:25
Hi Ralf,
danke, das klingt interessant, aber ich bin mir nicht sicher, ob das mein Problem vollständig lösen kann.
Ich kann den Aktor ja nur über die Perl Funktion schalten, sofern ich das in meiner DOIF Automatik tue. Schalte ich das Gerät über die native App / Alexa / was auch immer, bekomme ich diesen Vorgang nur über ein Event im Eventmonitor mit, das in etwa so aussieht: "Deckenleuchte bri 200". Würde ich nun eine Perl Funktion nutzen, um den Aktor in meiner DOIF Automatik zu schalten, hätte ich doch das gleiche Event dort stehen, oder?
Mir ist ansonsten folgender Ansatz eingefallen: Ich könnte eine Funktion schreiben, die meine Events durchsucht, ob sich der Ist-Zustand eines Gerätes von dem nach Automatik erwarteten Soll-Zustand unterscheidet. Diesen Soll-Zustand würde ich zum Beispiel in einem dummy Hinterlegen, der von meiner Automatik jedes Mal beim Schalten gesetzt wird. Wäre das möglich?
Gruß,
Mathea
nene,
Alexa --> FHEM --> [Notify| DOIF] --> Aktor setzen
und wenn Du am Aktor "irgendetwas" an FHEM vorbei änderst bekommst Du die Statusmeldung vom Aktor --> override
Zitat von: Wuppi68 am 05 Dezember 2016, 15:59:33
nene,
Alexa --> FHEM --> [Notify| DOIF] --> Aktor setzen
und wenn Du am Aktor "irgendetwas" an FHEM vorbei änderst bekommst Du die Statusmeldung vom Aktor --> override
Das ist auf jeden Fall eine gute Idee, aber ich hätte hier drei Probleme:
- Ich müsste für jedes Device einen dummy / readingsproxy /notify oder ähnliches einrichten (viel Aufwand, aber machbar)
- In der Apple Home App zum Beispiel sieht man eine Statusübersicht der Geräte und soweit ich weiß kann man Alexa auch fragen was der jeweilige Zustand ist. Ich müsste also den Zustand der physikalischen Geräte wieder zurück auf den dummy / readingsproxy / etc. mappen, damit es synchron bleibt. Und dann habe ich die Befürchtung, dass das wiederum die Funktion triggert, die meine Automatik abschaltet
- Die Philips Hue App kann ich dann immer noch nicht gescheit nutzen
Oder gibt es eine Möglichkeit, dies mit deiner Methode zu lösen?
Gruß,
Martin
noch nen Gedankenansatz:
bei jeder Aktor/Status Änderung setzt Du z.B. per Notify ein "inhibit" (setreading) auf die Automatik ...
wenn die Automatik zugeschlagen hat, nimmst Du nach einer Wartezeit (10Sek?) das Inhibit wieder raus
Und ob die Automatik dann entsprechend zuschlagen kann, prüfst Du ganz am Anfang der Automatik
PS.: Um das ganze Konstrukt besser durchdenken zu könne, wäre es hilfreich zu wissen:
Welche Automatik steuert welche(n) Aktor(en)?
Was sind Automatik an/aus Bedingungen?
Über welche Wege wird das Device (noch) gesteuert?
Am besten mal aufmalen - dann wird so manches einfacher und strukturierter ;-)
Zitat von: Wuppi68 am 06 Dezember 2016, 15:39:34
noch nen Gedankenansatz:
bei jeder Aktor/Status Änderung setzt Du z.B. per Notify ein "inhibit" (setreading) auf die Automatik ...
wenn die Automatik zugeschlagen hat, nimmst Du nach einer Wartezeit (10Sek?) das Inhibit wieder raus
Und ob die Automatik dann entsprechend zuschlagen kann, prüfst Du ganz am Anfang der Automatik
PS.: Um das ganze Konstrukt besser durchdenken zu könne, wäre es hilfreich zu wissen:
Welche Automatik steuert welche(n) Aktor(en)?
Was sind Automatik an/aus Bedingungen?
Über welche Wege wird das Device (noch) gesteuert?
Am besten mal aufmalen - dann wird so manches einfacher und strukturierter ;-)
Leider verstehe nicht genau die Funktion deines Gedankenansatzes.
Aber zu deinen Fragen:
Ich habe pro Raum eine lange DOIF Funktion namens "Lichtautomatik_DOIF", welche unter folgenden Bedingungen schaltet: [dummy "Lichtautomatik" an? Jemand im Raum anwesend? Helligkeitsschwelle unter bestimmtem Wert?]. Sind diese Bedingungen alle wahr, rechnet die Automatik abhängig von den "Brightness" Werten meiner Bewegungsmelder einen optimalen Dim-Wert aus und schickt sie jedes Mal wenn eine Helligkeitsänderung passiert zu meinen dimmbaren Lampen (do always). Also kurze Antwort: eine "Lichtautomatik" DOIF Funktion pro Raum steuert alle Lichtaktoren in einem Raum.
Über welche Wege wird das Device noch gesteuert?
- Aktuell über keine anderen Wege weil es nicht richtig funktioniert. Schalte ich eine Lampe manuell auf irgendeinen Wert, wird das spätestens bei einer Helligkeitsänderung im Raum von meiner Automatik wieder auf den automatisch berechneten Wert gesetzt.
Aber mein Wunsch ist es, dass ich die einzelnen Lampen über alle möglichen Wege schalten kann und dann automatisch mein dummy "Lichtautomatik" des jeweiligen Raumes abgeschaltet wird, damit meine Automatik nicht wieder den manuell eingestellten Wert überschreibt. Das beinhaltet: Schalten meiner Lampen über Siri, über Alexa, über die jeweilige App (in meinem Fall Philips Hue).
Ich male das ganze mal auf und füge das hier an. Aber ehrlich gesagt finde ich nicht, dass mein Wunsch so komplex ist. In meinem Kopf ist es ganz einfach:
- Default Status: Lichtautomatik ist immer aktiv und setzt automatisch permanent alle Lampen je nach Anwesenheits- und Helligkeitsstatus auf optimale Dim-Werte
- Ich suche z.B. meine Autoschlüssel und sage Alexa, dass sie das Licht im Wohnzimmer auf 100% stellen soll
- Die Lampen werden auf 100% gedimmt
- fhem erkennt irgendwie, dass die Lampen gerade manuell bedient wurden
- fhem schaltet den dummy "Lichtautomatik" ab
- Lampen bleiben so lange auf 100% bis ich den dummy wieder manuell einschalte (zum Beispiel über: "Alexa, schalte meine Lichtautomatik wieder ein"
- Ich habe meine Schlüssel gefunden und schalte die Lichtautomatik wieder ein
- Die Lichtautomatik ist wieder aktiv und fhem dimmt meine Lampen automatisch auf optimale Helligkeitsstufe
So wie ich die Sache sehe fehlt mir nur eine Lösung für Schritt 4. FHEM muss mitbekommen, dass der Zustand der Lampen gerade geändert wurden, und dass fhem selbst nicht der Auslöser war.
So, im Anhang nun das Bild.
Der Weg mit den schwarzen Pfeilen funktioniert aktuell schon:
Aktueller Helligkeitswert wird von Bewegungsmelder an FHEM gesendet, je nach Anwesenheit berechnet FHEM in meiner Lichtautomatik einen optimalen Dim-Wert und schickt den an meine Lampen (Homematik, Philips Hue, MySensors, etc..)
Der rote Weg funktioniert im Moment zwar natürlich, aber was nicht passiert, ist das setzen des roten X beim Pfeil zwischen Lichtautomatik und meinen Leuchtmitteln. Sprich: Ich kann zwar meine Lampen steuern, aber die Helligkeitswerte werden wieder von meiner Lichtautomatik überschrieben. Das soll aber nicht passieren! Die Automatik soll in dem Fall disabled werden.
Ich hab mich mit dem gleichen Problem beschäftigt, hab es aber noch nicht konsequent zuende gedacht (hatte ähnliche Gedanken wie Wuppi68). Mein Ansatz war:
Lichtautomatik wird per DOIF geschaltet -> funktioniert alles reibungslos.
Szenario A: eine per Automatik ausgeschaltete Lampe wird manuell eingeschaltet und soll auch eingeschaltet bleiben (die wiederkehrende Automatikschaltung soll sie nicht wieder abschalten)
Ansatz 1: Dazu setze ich ein Reading bei dem zu schaltenden Device namens "manuell" eq "ja". Die Automatikabfrage erweitere ich derart, dass ich dieses Device nur schalte, wenn Reading "manuell" ne "ja" ist.
Im Ergebnis nimmt die manuelle Schaltung das Device aus der Automatik heraus. Um es wieder hinein zu bekommen, setze ich das Reading "manuell" auf "nein", wenn ich das Device wieder ausschalte.
Ansatz 2: nicht zuende gedacht, aber gewissermaßen logisch geschlußfolgert -> ein automatisch geschaltetes Device soll anders geschaltet werden. Hier würde ich neben dem Reading "manuell" noch ein weiteres Reading "auto" definieren, in dem ich den Schaltzustand VOR der manuellen Schaltung abspeichere. Da die Automatikschaltung nach Schalten des Devices das Reading "auto" setzt, kann ich über eine Abfrage in der Automatik (hier: ist "state" eq "auto") prüfen, ob die Automatik das Device schalten darf oder nicht. Wenn ich weiter denke, lässt sich mit dem 2. Ansatz auch der erste Ansatz lösen.
Ich probier das mal aus ... ;)
Hier das erste Ergebnis:
Die Definition
define Osram09.manuell dummy
define xyz DOIF ([?16:00 - 23:00] and [A] eq "on") (IF ([Osram09.manuell] eq "nein") (set Osram09 dim5%,set Osram09.manuell nein)) DOELSE (set Osram09 off)
attr xyz do always
attr xyz repeatcmd 10
attr xyz room Test
define A dummy
attr A room Test
attr A setList on off
define AA notify A:on set Osram09.manuell nein
define Osram09manuellSchalten notify Osram09 IF ([Osram09] ne "off") (set Osram09.manuell ja) ELSE (set Osram09.manuell nein)
Bedeutet:
- dummy Schalter A schaltete den Test ein. Der Abfragedummy Osram09.manuell steht auf nein, die DOIF-Automatik greift.
- Nach jeder Schaltung (also auch bei den manuellen Schaltungen) wird der abfragedummy Osram09.manuell auf ja gesetzt.
- In der DOIF-Automatik wird er anschließend auf nein zurückgesetzt. Die Automatik-Schaltung löst weiterhin aus.
- Eine manuelle Schaltung setzt den Abfragedummy auf ja - die Automatik ändert dann diesen Schalter nicht mehr.
- Beim manuellen Ausschalten wird der Abfragedummy auf nein gesetzt ("set Osram09.manuell nein") und damit für die Automatik wieder zugänglich gemacht. Diese schaltet auf den ursprünglichen Wert zurück.
Ein paar Mal - nein, eigentlich immer - habe ich bei mir beobachtet, dass trotz des Befehls "set Osram09.manuell nein" in der Automatik im Anschluß an den Schaltvorgang der Wert der Abfragevariable auf "ja" stand - das konnte ich mir nicht erklären. Mir kommt es so vor, als ob der Befehl gar nicht abgearbeitet wird. Weiß da jemand eine Lösung?
Hi Yil,
dein Ansatz gefällt mir ziemlich gut. Was du damit nämlich machen kannst ist das Automatik- / Manuell Handling individueller Geräte. In meiner aktuellen Programmierung kann ich ja nur die Automatik eines gesamten Raumes ein / ausschalten.
Aber leider löst das nicht ganz mein Problem, da immer noch der Baustein fehlt, zu ermitteln welcher Trigger ein Gerät gerade gesetzt hat :(
Allerdings hat justme1968 (Entwickler der Homebridge und Alexa Fhem Module) mir einen super Vorschlag zur Umsetzung gemacht. Man kann das Attribut "homebridgemapping" so anpassen, dass das Schalten mittels Alexa oder Siri einen anderen Schaltbefehl absetzt, auf den ich reagieren kann. So kann ich zwar immer noch nicht auf das Schalten einer Lampe via Philips Hue App reagieren, aber eine funktionierende Sprachsteuerung reicht mir erst mal vollkommen.
Gruß,
Mathea
Ja, das ist natürlich sehr schick mit der Sprachsteuerung. Ich meine auch, dass da der Weg hinführen sollte, wenn man langfristig auf eine elegante Steuerung aus ist:
Automatik, wo es geht - ohne manuelle Interaktion. Manuelle Interaktion über Sprache - idealerweise mittels Fernmikrofone (Google Home, Amazon Echo o.ä.) und ohne irgendein Device in der Hand (Handy, Tablet o.ä.).
Ich hatte Homebridge gut am Laufen, hab mir die Installation auf dem Raspi aber so verschlimmbessert, dass es jetzt nicht mehr laufen will :-[
Da stimme ich dir voll zu. Ein großer fehlender Baustein ist da leider noch eine 100% sichere Anwesenheitserkennung pro Raum, aber das ist ein anderes Thema :D
Was genau stimmt denn nicht mit deiner Homebridge? Ich hatte anfangs auch riesen Probleme aber irgendwann lief es dann. Die Einbindung von Alexa war da aber trotzdem irgendwie einfacher.
Tja, wenn ich das wüsste. Ich vermute, es hat etwas mit der NodeJS-Installation zu tun und Inkompatibilitäten zu den npm-Modulen. Wenn Du "node -v" auf dem Terminal eingibst, welche Version bekommst Du?
Zitat von: Yil am 10 Dezember 2016, 01:00:11
Tja, wenn ich das wüsste. Ich vermute, es hat etwas mit der NodeJS-Installation zu tun und Inkompatibilitäten zu den npm-Modulen. Wenn Du "node -v" auf dem Terminal eingibst, welche Version bekommst Du?
Leider bin ich im Moment auf Dienstreise und kann das erst frühestens Dienstag prüfen. Falls du dann aber noch nicht weiter gekommen bist, kann ich dann noch mal gucken.
Soweit ich aber weiß hatte ich damals auch ein Problem mit der NodeJS Version...
Ich hab mir ne halbe Nacht um die Ohren gehauen und die Installation gerade gezogen - jetzt geht alles bis auf den Auostart von Homebridge über systemd (ich nutze Jessie). Ist aber noch mal ein ganz neues Thema, denn nur Homebridge zu haben ist eine Sache, aber intelligente Kommandos für geräte und Szenen zu entwickeln und die zum Laufen zu bringen die andere, und gerade hab ich den WAF leicht überzogen ... ::) Muss also etwas kürzer treten.
Bist Du warm geworden mit Homebridge und Alexa? Da will ich auch hin, sobald Amazon seinen Echo dot mal liefert ...
Bei mir läuft der Autostart ohne Probleme. Ich habe das wie im Wiki beschrieben mit dem Startscript in init.d und das starten über update-rc.d gemacht. Was allerdings irgendwie nicht funktioniert ist das Anzeigen des Homebridge Status in fhem und das Starten / Stoppen über einen dummy.
Wirklich warm geworden bin ich mit beiden ehrlich gesagt noch nicht. Die Barriere, Homekit zu benutzen ist, dass man dazu jedes mal das Handy zücken muss. Das ist nicht wirklich intuitiv. Alexa wiederum kann aktuell mit dem nativen Smart Home Skill nur zwei Gerätetypen (Licht & Temperatur), was einfach zu wenig ist. Außerdem ist da ja noch das Problem, dass meine Automatik die Schaltbefehle aktuell noch bekämpft ;D Ich hoffe stark, dass Amazon den Smart Home Skill bald erheblich erweitert (Rolläden, Vorhänge, Ventilatoren, TV- & andere Entertainment Geräte, abfragen von Fenstern und Türen, ...)
Allerdings habe ich auch noch Probleme, meine nicht-Standard-Geräte einzubinden, weil ich das homebridgemapping noch nicht so ganz verstehe. Ich kann im Moment meine Homematik und Philips Hue Sachen ansteuern, aber nicht meine MySensors Devices.
Sehe ich genauso, Homekit ist nur ein Zwischenschritt, und an Alexa wage ich mich erst, wenn das Dingens mal geliefert wird ... keine Ahnung, ob ich mir die Zeit gönne, mich mit homebridgemapping zu beschäftigen. Handy zücken ist auch nicht so mein Ding und reinzurufen taugt auch nur, um Besucher zu verblüffen ;)
In Sachen Devicevielfalt hatte ich anfangs auch gedacht, es ist lustig, über den RPi alles mögliche anzubinden, aber irgendwann habe ich mich von Philips und F20 verabschiedet und nutze nur noch Osram, Homematik und Z-Wave - das läuft stabil, auch jetzt über Homekit.