Beiträge von HKuser

  • homebridge-knx

    YEAH! :D


    Bei der Raffstore liegt es vermutlich an den GA. Das ist am Anfang ein bisschen undurchsichtig, welche GA wo in der _config.json eingetragen werden müssen.


    Im knx-user-forum gibt es noch einen Thread speziell zu diesem Plugin in Verbindung mit KNXD. Evtl dort noch Inspiration für das Aufsetzen der knx_config.json holen, falls es hakt.


    Gutes Gelingen! :)

  • homebridge-knx

    Ne, die sind mit Symlinks "verbunden".


    Also der KNXD wurde vom User "root" installiert. Das homebridge-knx Plugin wurde (natürlich) vom User "homebridge" installiert. Wer installiert hat, dem "gehört" die Datei und hat die entsprechenden Rechte.


    Ich hab jetzt mal bei mir auf dem Raspi nachgesehen. Der KNXD wurde bei mir vom User "pi" installiert und das Plugin natürlich auch vom User "homebridge". Allerdings gehört bei mir die knx_config.json (auch) dem User "pi". Und das ist der Unterschied zwischen unseren beiden Installationen.


    Ich würde daher die knx_config.json mal Deinem User "root" vererben. Mach mal:


    Code
    chwon root /var/lib/homebridge/knx_config.json

    Anschliessend nochmal überprüfen mit:


    Code
    ls -l /var/lib/homebridge/knx_config.json

    Und dann müsste da "root" als Eigentümer stehen.


    Danach mal den Raspi rebooten (sudo reboot). Und anschliessend:


    Code
    sudo systemctl status knxd.service

    Was dann einen funktionierenden KNXD signalisieren sollte. Evtl nochmal mit einem einzelnen KNX-Befehl nochmal testen, ob das Device schaltet. Wenn alles OK, dann in die Homebridge und dort das Device mit der "Kachel" schalten.


    Uuuund? 8|

  • homebridge-knx

    OK, das hab ich mir schon fast gedacht. Homebridge und der KNXD scheinen von verschiedenen Usern installiert worden zu sein.


    Mach mal:


    Code
    find / -name knxd.service

    Als Ergebnis sollte Dir als Ausgabe angezeigt werden, wo/in welchem Pfad der KNXD installiert wurde. Dann den Befehl von oben nochmal mit dem gesamten Pfad eingeben:


    Code
    ls -l /kompletter-Pfad-zum-KNXD/knxd.service

    Ich vermute, der ist vom User root installiert. Deswegen werden auch die Schaltvorgänge zu den KNX-Devices, die Du direkt per Befehlszeile an den KNXD geschickt hast, funktioniert haben.


    So weit ich mich erinnern kann, muss der KNXD Schreibrechte für die knx_config.json haben. Also muss der User, der den KNXD installiert hat, auch Schreibrechte für die knx_config.json haben. Wenn das so ist, müsstest Du den Owner für die knx_config.json auf den User ändern, der die Homebridge installiert hat. Das versuchen wir jetzt herauszufinden.


    Linux-Experts kommen da vermutlich viel schneller zum Ziel als ich. Ich beschäftige mich mit dem Linux nur gezwungenermassen für Homebridge. ;)

  • homebridge-knx

    Hmmm... versuch es mal so. Also ohne die ganzen Parameter in der KNX-platform section. Du siehst ja oben aus meinem Beispiel, dass diese ganzen zusätzlichen Parameter, die Du da hast, eigentlich nicht notwendig sind.


    Der Standard-Dateiname ist übrigens eigentlich knx_config.json. (Unterstrich, nicht Bindestrich).


    Sehr gut, dass der KNXD funktioniert. Das ist eigentlich die grössere Herausforderung. ;) Und mit der Homebridge-Config (eben nur mit name und platform) sollte es eigentlich direkt laufen.


    Wenn Du die Homebridge-Config geändert hast, auf jeden Fall die Homebridge (nicht notwendigerweise den Raspi) neu starten. Beim Start wird die knx_config.json eingelesen und die (beiden bei Dir testweise eingegebenen Devices) in die Homebridge eingebaut. Die siehst Du dann auch im Web-IF unter "Geräte". Hmmm... und jetzt fällt mir gerade auf, dass Du die ja sehen musst, um zu schalten... X) Wie auch immer. Versuch mal ohne diese zusätzlichen Parameter. Eigentlich sollte es dann direkt laufen, weil die Homebridge via homebridge-knx Plugin ja nur auf den KNXD zugreift


    Wenn es dann immer noch nicht geht, ist vermutlich die knx_config.json nicht OK. Überprüfen auf jsonlint.com. Und Du musst Dir sicher sein, dass die Gruppenadressen stimmen.


    EDIT

    Und jetzt sehe ich gerade, dass die Parameter, die Du in der Homebridge-config hast, eigentlich (zum Teil) in die knx_config.json reingehen. Meine knx_configjson (liegt in /var/lib/homebridge/) fängt so an:


    Code
    {
    "knxd_ip": "127.0.0.1",
    "knxd_port": 6720,
    "AllowWebserver": true,
    "AllowKillHomebridge": true,
    "Devices": [

...

    Natürlich unter der Voraussetzung, dass der KNXD auf demselben device (Raspi) läuft wie die Homebridge.


    Und der Eigentümer der Datei knx_config.json ist der user "pi". (herauszufinden mit dem Befehl ls -l /var/lib/homebridge/knx_config.json). Unter der Voraussetzung, dass Du die Homebridge gemäss hiesiger Smartapfel-Beschreibung installiert hast.


    Funktioniert es?

  • homebridge-knx

    Hast Du diesen Eintrag in der config.json Deiner Homebridge?

    Code
     {
            "name": "KNX",
            "platform": "KNX"
        },

    Die Geräte, die Du jetzt mit Deiner Homebridge schalten möchtest, funktionieren aber mit den direkt via KNXD abgesetzten Gruppenadressen?

  • homebridge-knx

    Hier ein gedimmte Licht:



    Hier eine Raffstore:

    Der Parameter "ServiceName" ist dann hinterher in Apple Home die Bezeichnung die erscheint, wenn Du den Namen des Gerätes löscht. Da eben die "Siri-sinnvolle" Bezeichnung manuell vergeben (siehe Hinweis von mir oben).


    Bei den Gruppenadresse musst Du natürlich Deine eigenen finden und eintragen.


    Sag Bescheid, wenn Du noch ein anderes Beispiel als für die beiden Gerätekategorien brauchst. Ich schau dann mal nach, ob ich bei mir was passendes finde.


    Lies Dir bitte unbedingt den Artikel bzw. das Wiki auf Github zum Plugin Homebridge-KNX durch. Auch damit Du die passenden GAs findest. Und nicht aufgeben, wenn es nicht direkt auf Anhieb beim ersten Mal klappt. Ich habe damals meine .json x Mal bearbeitet, immer wieder neu in Homebridge eingelesen, ausprobiert um mehrere Male festzustellen, dass ich doch wieder einen Fehler im Syntax oder einer GA hatte. Wenn Du mit der Fleissarbeit der .json aber mal durchbist, kannst Du Dich an die Raumzuordnung in Apple Home machen. Bevor nicht alles passt, lohnt es sich nicht.


    Automatisierungen am besten in "Controller für Homekit" und Apple Home "nur" für die Visualisierung und direkte Steuerung nutzen.


    Viel Erfolg! :)

  • homebridge-knx

    Supi, schön, dass es jetzt läuft. :)


    Nächster Schritt, knx_config.json. Und ja, das ist leider Handarbeit. Zumindest habe ich noch keinen automatisierten Weg gefunden. Ich habe mir überlegt, welche gleiche Arten von Geräten (Storen/Jalousinen, Licht an/aus, Dimmer etc.) ich habe und dann per copy/paste eine Rohfassung der .json angelegt. Im nächsten Schritt dann überall die Gruppenadressen eingetragen und am Ende die komplette .json auf jsonlint.com überprüft (und x "," etc. ergänzt, korrigiert X) ).


    Danach dann ins Apple Home über Homebridge einbringen, auch wiederum manuell gruppieren/den Räumen zuordnen. Hierfür hilft es, in der .json sinnvolle Gerätenamen zu verwenden, was bei der Zuweisung hilft, weil der Name nämlich in Home hinterher "grau hinterlegt" ist, wenn man den Namen manuell ändert. Dafür also am besten so etwas nehmen wie "Jalousie1WZ". Der Name wird dann in Home so neu vergeben, dass eine "natürlich" Sprachwendung für Siri & Co möglich ist. ;) Ich habe für diesen Schritt auch nochmal einige Anläufe gebraucht und musste den Cache immer wieder mal leeren und die Geräte neu einlesen, weil doch wieder eine Gruppenadresse in der .json falsch war.


    Wenn man dann mal fertig ist, unbedingt Backup machen und die .json nochmal separat absichern. :D


    Dieser ganze letzte Teil ist anscheinend mit HKKNX automatisiert, zumindest habe ich das so gelesen. Anscheinend kann man da die KNX-Projektdatei einlesen.

  • homebridge-knx

    Stimmt nicht:


    Zitat von Github homebrdige-knx

    Prerequisites

    This node module requires either

    • a running (and properly configured) knx daemon (knxd). You can find the latest version here.

    Und HKNX ist mWn nichts anderes als ein vorgepacktes bzw. eine vorinstallierte Homebridge mit KNX-Packages - ohne die Freiheiten einer Homebridge, aber dafür zahlbar.

  • homebridge-knx

    Das hat aber nichts mit Homebridge zu tun. ;) Anscheinend kannst Du noch nicht einmal einen KNX-Befehl (zum Einschalten Deiner WZ-Lampe) abesenden. Das heisst, Du musst erst einmal Deinen KNXD zum Laufen bekommen. Danach kommt die Homebridge-Integration.


    Was sagt denn:

    sudo systemctl status knxd


    Abhängig von der Art des "IP-Interface", sind unteschiedliche Settings notwendig. Bei den Parametern gab es einen Unterschied, ob IP-Router oder Schnittstelle. Ist schon ein paar lange Jahre her, dass ich es bei mir aufgesetzt habe. Im Nachhinein weiss ich nur noch, dass KNXD zum Laufen zu bringen die grösste "Herausforderung" war. :) Alles andere war "piece of cake". Bei meinem ABB-Router ist die Einstellung:

    KNXD_OPTS="-e 7.0.1 -E 7.0.2.90 -u /tmp/eib -b ipt:192.168.2.18


    bei IP vs IPT kommt es darauf an, ob die KNX-Hardware Muticast kann.


    Ich empfehle bei der Installation von KNXD genau nach Anleitung von Github bzw. deutschprachiger Anleitung SmarthomeNG vorzugehen.

  • 1Home Bridge geänderte IP im Netzwerk

    Das ABB-Device kostet in DE so um die 150 - im Grunde genommen sollte aber jedes KNX-IP-Interface funktionieren. Das ist ja gerade der Vorteil bei KNX, dass alle Geräte von den Funktionen universell einsetzbar sind.


    Ja genau, diese von dir beschriebenen Phänomene bei Szenen hatte ich anfangs auch. Das Interface "verschluckt" dabei Befehle, die auf den Bus gesendet werden. Ich bin mir nicht mehr ganz sicher, weil es jetzt schon ein paar Jahre her ist, dass das heute funktionierende System aufgesetzt habe, ob es bei mir am KNX-IP-Interface lag (ich hab das ABB einfach mal gekauft um auszuprobieren) oder an Einstellungen/Parametern vom KNXD. Meine grössere Vermutung ist der KNXD, weil ich genau in dem Punkt am längsten herumprobiert habe und zwischendurch ziemlich genervt war. Im KNX-Forum ist der User, der den KNXD veröffentlich hat, sehr aktiv. Und ich meine auch, dass das Problem der verschluckten Befehle auf den Bus mehrere Personen hatten. Es war, so weit ich mich erinnern kann, eine Kombination aus Hardware des KNX-IP-IF und der Parameter des KNXD. Jetzt läuft es aber bei mir. Ich kann Dir dann mal, wenn Du Dich für die Lösung entscheidest, Beispieldateien und Parameter schicken.


    Ich finde es enttäuschend zu hören/lesen, dass 1Home das Problem auch hat, obwohl sie ja sowohl Hardware als auch vorinstallierte Software zusammen verkaufen. Und so weit ich weiss sind die Anbieter 1Home, HKKNX und wie die alle heissen, nichts anderes als ein Bundle aus Hardware (Raspi/KNX-IP-IF) und Software (Homebridge, KNXD, homebridge-knx Plugin plus evtl ein selbst erstelltes Interface, um die ETS-Programmierung/Gruppenadressen für die Homebridge lesbar zu machen).


    Bei allen anderen teilweise KNX-fokussierten Lösungen mit irgendwelchen Servern und Internetgateways, favorisiere ich die Apple Home-Lösung, weil man damit ohne Umwege Fernzugriff auf sein Zuhause hat.

  • 1Home Bridge geänderte IP im Netzwerk

    :) Genau deswegen hab ich gefragt und ich hab mich für die alleinige Homebridge-Lösung entschieden. Das ist einfacher zu pflegen und man weiss selber, wie alles zusammengreift, was wie warum funktioniert. ;)


    Also grob erklärt:

    Die Homebridge bindet bei mir ebenfalls mit Conbee Zigbee-Devices/Hue an. Conbee, weil ich den Raspi in einem Serverschrank habe und per USB-Verlängerung den Conbee nach aussen lege. Ein Raspbee hatte ich vorher und da war die Sende-/Empfangsleistung nicht gut. Auf der Homebridge läuft alles, damit sämtliche Devices, auch KNX und Shellies, ins Apple Home kommen. Einen 1Home, HKKNX und wie die Plug and Play Lösungen alle heissen, um KNX anzubinden, brauch man dann nicht. Dafür ist der selbst programmierte Raspi mit Homebridge da.


    Voraussetzungen:

    - KNX-IP Router

    - Raspbee

    - Alle Gruppenadressen der KNX-Komponenten


    Installationsbeschreibung:

    KNX-IP-Router (zB ABB IPS/S 3.1.1) installieren. Manuell die IP in ETS eintragen/programmieren oder im Router Adressreservation auf Basis MAC-Adresse einstellen. Weitere Arbeiten am KNX-IP sind nicht notwendig. Wichtig: Die IP-Adresse darf sich hinterher nicht mehr ändern. Auf dem Raspi Homebridge nach der hiesigen Smartapfel-Beschreibung installieren. Damit der Raspi über die KNX-IP-Schnittstelle mit dem KNX-Bus sprechen kann, muss der Raspi KNX-Sprache lernen. Das macht man mit dem kleinen Hilfsprogramm KNXD. KNXD muss wissen, wohin er schreiben und wo er zuhören muss. Dafür wird die IP-Adresse des KNX-IP im Programm hinterlegt (eine Datei auf dem Raspi, die man mit einem Texteditor bearbeitet).


    Ferner werden in einer Datei namens knx_config.json alle KNX-Devices mit den relevanten Gruppenadressen eingetragen. Das ist eigentlich die Hauptarbeit! Falsch machen kann man einiges, es geht aber nichts kaputt, höchstens funktioniert nicht. Kann man aber testen über jsonlint.com. Die Beschreibung hierzu ist auf der GitHub-Site vom KNXD, es gibt auch im Netz genug Beispiele. Wenn Du nur Lichter in KNX hast, geht es schnell. Ein kleines bisschen komplexer wird es bei Lamellenraffstoren, wegen der Lamellenwinkelverstellung und den damit zusammenhängenden vielen Gruppenadressen. Das ist dann einfach nur noch mehr Fleissarbeit. Diese Datei ist das Herzstück, kann einfach als Backup gesichert werden und bei einem späteren Umzug auf einen anderen Raspi oder bei einer Neuinstallation einfach zurückgespielt werden.


    Damit die Homebridge und damit Apple Home mit allen KNX-Devices sprechen kann, wird in der Homebridge das Plugin "Homebridge-knx" benötigt. Wenn Du Jalousien/Raffstoren in KNX hast, dann verwende Version 0.3.27, die sich einfach über die Gui in Homebridge installieren lässt. Alle späteren Versionen haben einen Fehler in der Behandlung von Jalousien/Storen. Es funktioniert zwar, aber im Homebridge-Log taucht immer wieder ein Error auf. Ich habe den Fehler gerade erst wieder auf der Github-Site unter issues gemeldet. In der Homebridge muss einfach nur ein Zusatz in die config, damit KNX läuft:

    Code
    {
            "name": "KNX",
            "platform": "KNX"
        }

    Fertig.


    Das Ganze hat den Vorteil, dass man sämtliche Applikationen auf einem Raspi fährt und nicht mehrere brauch. Man weiss selber, was man da warum installiert hat und weiss sich mit der Open-Source Community zu helfen, wenn mal was nicht so läuft, wie es soll. Man kann jederzeit auf dem Raspi mit der Homebridge etc. noch einen Werbeblocker installieren, VPN, etc. Nachteil: Man muss sich wirklich damit beschäftigen und darf sich nicht vor Fleissarbeit scheuen, um die knx_config.json zu erstellen. Die einzelnen Installationsbeschreibungen, siehe Github zu KNXD, sind zuverlässig und wenn man da der Reihe nach durchgeht, klappt das auch. Also keine Angst davor.


    Ferner ist mir mit dieser Konstellation die Austauschbarkeit der Komponenten wichtig gewesen. Raucht mir mal ein KNX-IP-Router ab, nehme ich einfach irgendeinen anderen. Weise dem Neuen die alte IP-Adresse zu und schon "fluppt" es wieder. Der Raspi stirbt? Kein Problem. Neuer gekauft, Backup installiert, schon fertig.


    Und meiner Meinung nach könntest Du noch einen zusätzlichen Broker für Automatisierungen auf demselben Raspi installieren. Das ist eins meiner nächsten Projekte. Aber bis hierhin läuft bei mir mittlerweile alles recht gut. Tagesabhängige Automationen, solche für Ankommen/Gehen, sonnenstandsbedingte, etc. ;)

  • 1Home Bridge geänderte IP im Netzwerk

    Ich hab mich mit dem 1Home nur ganz am Anfang kurz auseinandergesetzt, als ich meine KNX-Devices auf ein smarte GUI bringen wollte (also die Visualisierung). Die Frage ist ja bei KNX, ob man einfach so damit zufrieden ist oder mit mehr Komfort eine (smarte) Visualisierung haben möchte. Dann steht man vor der Wahl ob KNX stand-alone oder mit der Möglichkeit auch andere Smart-Devices unterzubringen. Bei mir war letzteres der Fall, da ich mir die Möglichkeiten mit originären AppleHome-Devices und anderen wie zB Hue kombinieren wollte. Aus der Überlegung heraus hat sich für mich als Apple-User dann ganz klar die Homebridge herauskristallisiert. (Längere Einleitung die nichts mit dem Thema von Momo zu tun hat, aber falls später doch mal Cross-Platform Themen dazukommen).


    Der 1Home ist m.E. nichts anderes als eine Homebridge mit integriertem KNX-IP-Router. Der Router hat eine Übersetzungsfunktion zwischen IP (das ist die AppleHome-Seite) und dem KNX-Bus (die KNX-Komponenten, die sich untereinander mit Befehlen auf Gruppenadressen unterhalten). In dem Moment, wo AppleHome etwas auf den Bus schreiben soll "Schalte Lampe XY auf 75%" wird der IP-Befehl von Home vom Router (1Home) in das KNX-Protokoll übersetzt. Im Gegenzug bekommt Home vom KNX-Bus den Zustand (Lampe an auf 75%) zurückgemeldet, was zur entsprechenden grafischen Darstellung in der HomeApp führt.


    Damit das Ganze funktioniert, muss die Homebridge (1Home) wissen, auf welcher (IP-)Adresse der Router mithört. Wo das genau eingestellt wird, kann ich Dir leider nicht sagen, weil ich 1Home nicht kenne. Es kann sein, dass es einfach in einem User-Interface eingestellt wird. Bedienungsanleitung? Hast Du eigentlich den 1Home als Apple Device in Home eingefügt, der Dir dann wiederum alle (KNX-)Devices importiert hat? Da muss es etwas geben, was Du selber als User machen musst. Denn der 1Home im Auslieferungszustand muss ja erst einmal ins Heimnetzwerk eingefügt werden (bekommt dann eine automatisch zugewiesene IP, dann musst Du vermutlich einen Bar-Code mit dem iPhone scannen, damit das Home angelegt wird) und Du müsstest ja eigentlich Deine gesamte KNX-Konfiguration in den 1Home einlesen, damit der überhaupt weiss, welche Devices vorhanden sind.


    Hast Du die ursprüngliche Inbetriebnahme selber gemacht, oder ein Elektriker/Systemintegrator o.ä.?


    Und wofür hast Du noch eine Homebridge auf einem Raspi? Ich frage, weil ich irgendwie die Vermutung habe, dass entweder der 1Home oder die Homebridge auf dem Raspi überflüssig ist. Der 1Home ist, so weit ich das verstanden habe, halt eine Plug-and-Play Lösung für KNX -> Apple Home.


    Konkret auf Deinen Verdacht und Deine Frage: Ja genau. Die KNX-Devices reagieren nicht, weil 1Home bzw. der eingebaute Router sehr wahrscheinlich eine neue IP bekommen hat.


    Und nochmal JA auf Deine Befürchtung, dass man bei neuer Netzwerkstruktur/IP-Adressen (Deine beabsichtigte Umstellung) uU nochmal alles in Home neu den Räumen etc. zuweisen muss. Deswegen besser vorher nochmal strukturiert überlegen, wie die Netzwerktopographie aussehen soll und dann die Arbeit 1x machen. ;) (Auf "uU" gehe ich jetzt erst einmal nicht ein, weil es sehr technisch werden kann, Stichworte UID in knx_config.json).


    LG

  • 1Home Bridge geänderte IP im Netzwerk

    Hab bei mir ebenfalls eine Anbindung ans KNX-System und ich vermute, Du vergisst noch etwas: Den KNX-IP-Router. Das sind dann ein paar Devices, die sich auf feste bzw. reserviert IP beziehen, sonst funktioniert es nicht.


    Heisst:

    Du kannst entweder mit festen (in den Geräten hinterlegten) IP-Adressen oder mit IP-Reservierung auf Basis MAC-Adresse arbeiten. Alles dynamisch geht in diesem Fall nicht. Wegen des Umzugs bzw. dem neuen UmFeld brauchst Du aber auch nicht alles neu installieren.


    Wenn mich nicht alles täuscht, müsstest Du für die Homebridge und das KNX-IP-Interface definierte IP haben. Auf dem Raspi, auf dem die Homebridge läuft, muss die IP des KNX-IP-Interface im knxd hinterlegt werden.


    Und doch, sobald Du die Homebridge bzw. das eher AppleHome neu aufsetzt, wirst Du Deine KNX-Devices neu zuordnen müssen.

  • ConBee Phoscon deCONZ Setup

    Hi Ihr


    Nach irgendeinem Update des RPi vor geraumer Zeit habe ich mir eine Fehlermeldung von deconz eingehandelt. Das führt dazu, dass nach jedem Reboot des RPi deconz nicht (richtig) gestartet wird. Folglich kann sich die Homebridge nicht verbinden. Auf das WebIF von deconz kann ich ebenfalls nicht zugreifen. Also drauf auf den RPi per SSH und der Sache versuchen auf den Grund zu gehen:


    Aha, OK, einen daemon-reload durchführen.


    Hm, daemon-reload durchgeführt, deconz läuft aber immer noch nicht. Also stoppe ich per systemctl stop deconz und starte nochmal per systemctl start deconz. Dann läuft es. So weit so gut, nur habe ich das "Hängen" von deconz bei jedem Restart.


    Ich habe soeben ein komplettes Update des RPi gemacht. Es bleibt dabei. Nach jedem Restart.


    Hat jemand eine Idee, wie ich den Fehler dauerhaft wegbekomme?

  • Homekit Akku Lampe/Leuchte

    Ich möchte Dir keine Illusionen nehmen oder verneinen, dass es "irgendwo irgendwelche Akkulampen" gibt - nur grenzt das tendenziell an der Unmöglichkeit. ;) Akku, lange Laufzeit, Homekit (und selbst wenn es Zigbee oder was auch immer via Homebridge sein darf) soll es vermutlich am Ende noch ansprechend aussehen oder eine gewisse Helligkeit (oder gar Farbe?) haben. Da fangen gewisse Sachen an, sich auszuschliessen, ohne selber am Ende eine Autobatterie dranzulöten. ;)


    Am Ende würde ich mir eher überlegen, ob ein Elektriker nicht eine Leitung zur richtigen Stelle legen kann. Das geht eigentlich recht komplikationslos. Da wird ein feiner Schlitz in die Wand/Decke eingefräst, die Leitung verlegt, drübergespachtelt und gemalt und Du siehst nichts mehr am Ende. Staub (hier stand mal "Dr3ck", aber das ist ein böses Wort, welches die Boardsoftware nicht mag und mir dann nicht erlaub, den Beitrag zu posten X-) ) macht es eigentlich auch nicht. Kostet mMn auch nicht die Welt, aber das ist ja "relativ". :) Und dann hast Du alle Möglichkeiten - alle Geräte, Formen und Farben, wenn man Hue&Co möchte halt so oder sonst herkömmliche Geräte, die per Zwischenstecker, Shelly o.ä. versmartet werden.

  • HomeKit funktioniert nicht von unterwegs

    Diese "Ideen" dienen dazu, eine möglicherweise funktionierende Lösung zu schaffen und/aber zumindest die mögliche Fehlerursache so weit wie möglich einzuschränken.


    Und diese Informationen können hilfreich für den Apple-Support sein. An die Genius-Bar glaube ich weniger, weil die "nur" aufs physisch gezeigte Geräte zugreifen können. Ich an Deiner Stelle würde eher an den Support per Email gehen. Mit all den Informationen, Lösungsansätzen und Wegen, die Du bereits versucht hast. Und je strukturierter die Infos an den Apple-Support, desto grösser die Wahrscheinlichkeit der schnellen Hilfe. Sonst wirst Du Dich sehr lange mit "starten Sie mal neu", "setzen Sie mal alle Einstellungen zurück" etc. zunächst beschäftigen müssen. Das kannst Du auch direkt vorwegnehmen.


    Ich finde das Apple-Ökosystem u.a. so gut, weil es "eigentlich" narrensicher ist, nichts kaputt gehen kann. "Eigentlich"... und uneigentlich passiert dann so etwas wie bei Dir oder das bei mir nach wie vor (trotz sschuste präferierte Warten-Methode ;) ) die "Zuhause Ankommen-Automation" aus Home heraus einfach nicht funktionieren will, obwohl das mal der Fall war. Das testweise verlegen auf eine andere Geolocation war ebenfalls nicht erfolgreich. Die neu per "Controller" App angelegte Automation hat jetzt 2x funktioniert, ich werde weiter beobachten.