Beiträge von David Andel

    Nein, das muss aber nichts heißen, da es bei diesem höllischen System ja oft mehrere Herangehensweisen gibt, die allesamt komplett verwirrend und vor allem brutal unzuverlässig sind (eine kleine Änderung reicht da schon).


    Was ich gemacht habe, ist das da:


    a) „Admin Menu“ der Moronix :cursing: aufrufen

    b) Unter „Übertragungsprofile“ das Untermenü „Profile für Netzwerkmeldungen“ aufrufen

    c) Dann ganz unten auf der Seite ein neues Profil mit „Neues Profil hinzufügen“ erstellen und z. B. Homebridge nennen

    d) Im Pulldown-Menü „Benutzerdefinierte Konfiguration“ auswählen

    e) Als Zieladresse die Homebridge-IP samt Port für camera-ffmpeg (Beispiel oben: 6412) eintragen: ww.xx.yy.zz:6412

    f) Im Pulldown-Menü darunter „Bei Fehler weiter“ wählen

    g) Unter Datenprotokoll im Pulldown-Menü HTTP/1.0-Request auswählen

    h) Im Textfeld darunter Deine URL gemäß Deines Wunschnamens aus camera-ffmpeg angeben: /doorbell?Wunschname

    i) Unter Datentyp im Pulldown-Menü Nur Text wählen

    j) Auf Setzen klicken, dann zurück ins „Admin Menu“

    k) Unter der Rubrik Video-Türstation auf Klingelverhalten und Video-Mailbox klicken

    l) dort kannst Du dann unter Adressat-spezifische Einstellungen für jeden Klingeltaster (= Adressat) per cmd-Klick die Option Homebridge (Netzwerkmeldung) ergänzen

    m) Dann Setzen und Schließen klicken und gegebenenfalls testen (besser ist es allemal)


    Es funktioniert hier. Aber wie schon erwähnt, reicht eine kleine Veränderung und neues Testen ist angesagt …


    Viel Glück!

    Ich verwende mittlerweile wieder das camera-ffmpeg-Plug-In und binde den Türöffner separat per http-switch ein. Der Rest sieht so aus:

    Natürlich musst Du Deiner Mobotix-Türstation dazu auch den Port beibringen (in meinem Fall Port 6412). Das musst Du dann unter Profile für Netzwerkmeldungen mitsamt der IP Deines Homebridge-Gerätes im Feld Zieladresse eintragen und außerdem unter Datenprotokoll die Option HTTP/1.0-Request auswählen, dann unter CGI-Pfad den entsprechenden Pfad, /doorbell?Wunschname gemäß obigem Beispiel also und schließlich als Datentyp die Option Nur Text wählen. Ja ja, ich weiß, kompliziert, nervtötend. Aber so sind die Produkte dieses Herstellers (von dem ich garantiert niemals wieder etwas kaufen werde) ja leider.


    Ach ja, die sehr spezifischen ffmpeg-Filter in obigem Beispiel geschehen dem HomeKit zuliebe und wurden durch lästiges Ausprobieren ermittelt, damit das Kamerabild nicht rund oder verzerrt ist.


    Hoffe, dass Dir das irgendwie hilft.

    Gibt es Einschränkungen? meine Steuerzentrale (iPad Air 1) läuft noch mit iOS 12. mein iPhone mit iOS 13, das keiner Frau mit iOS 14. zumindest auf dem 14er sollte es sich doch einstellen lassen oder?

    Ohne es genau zu wissen, gehe ich mal davon aus, dass auch Deine Steuerzentrale auf einem Stand sein sollte, der Adaptive Lighting unterstützt. Ich hatte ähnliche Fälle in der Vergangenheit u. a. mit dem Läuten der HomePods, so jemand an der Tür klingelt. Erst wenn die Steuerzentrale das unterstützt, machen auch die Endgeräte mit. Es reicht also nicht, wenn nur ein Endgerät auf dem aktuellem Software-Stand ist.

    Habe im Changelog gesehen, dass nun adaptive lightning unterstützt wird. Ich habe dies allerdings nicht bei mir zur Auswahl.

    Es erscheint de facto nach der Aktualisierung von homebridge-hue auf v0.12.2 in der Home-App (iOS, iPadOS usw.) die Adaptive-Lighting-Option, so man diese verwenden will. Dies geht sowohl mit einer Phoscon- als auch mit der Hue-Bridge (ich lasse beide unter homebridge-hue laufen).


    Wenn man die Adaptive Lighting nicht aktiviert, dann verschwindet auch der Hinweis kurz später. Es bleibt jedoch weiterhin möglich, Adaptive Lighting in den Einstellungen des jeweiligen Leuchtmittels zu aktivieren – das ist die Taste mit der stilisierten Sonne innerhalb der Farbauswahl (siehe Bildschirmfoto) und klappt natürlich nur mit Leuchtmitteln, die über die Möglichkeit zur Veränderung der Farbtemperatur verfügen.


    Also wie jetzt updaten?

    Sorry für die späte Antwort. Ich wollte nicht sagen, dass n generell nicht funktioniert, nur dass das Homebridge-Team es bei einer Installation nach deren Anleitung nicht empfiehlt. Bei mir kam es mit n konkret bei einer meiner mittlerweile drei Homebridge-Installationen (zweimal 3B+, einmal 4B) zu einem Pfad-Wirrwarr, weshalb ich auf den beiden anderen Installationen anstelle von n eben den Befehl sudo hb-service update-node verwendet habe, der völlig problemlos verlief. Da ich homebridge nun auch schon wieder seit gut vier Jahren einsetze (zuerst noch auf dem Mac Pro, da darauf sowieso das gute alte macOS Server lief), weiß ich nur zu gut, dass ein Pfad-Durcheinander zu starkem Kopfweh führen kann, daher ist es für manchen vielleicht besser, strikt nach Homebridge-Anleitung vorzugehen, vor allem dann, wenn man sich selbst später nicht zu helfen weiß und bei smartapfel.de gerade mal keiner wach ist.

    Na schön, du weist dir ja zu helfen, und danke für den Tipp. Verstehen tue ich das alles aber nicht.

    Es ehrt Dich, das zumindest zu wollen (ich nicht mehr). Mir ist übrigens zum ersten Mal aufgefallen, dass es einen Verweis zum Update-Prozedere von Node.js auch via homebridge-config-ui-x gibt, wenn man mit dem Mauszeiger über die Versionsnummer fährt. Dann öffnet sich eine Seite mit weiteren Infos, so auch der Hinweis, dass man n nicht verwenden sollte (sorry!).

    n hat mit homebridge nichts zu tun.

    War ein Missverständnis, siehe oben:


    1) Installation von n und Update auf Node.js-Version 14.15.0

    2) homebridge startete nicht mehr, Verzeichnis /home/pi/.homebridge/ wurde angelegt

    3) Logs wiesen auf Inkompatibilität mit homebridge-config-ui-x hin


    Auf den beiden anderen homebridge-Installationen habe ich daher kein n installiert und wie gehabt mit hb-service update-node aktualisiert. Dort traten keine Inkompatibilitäten mit homebridge-config-ui-x auf.

    Auf einem Raspi ist eigentlich /usr/local/lib/node_modules der richtige Pfad.

    Bin verwirrt, da es das Verzeichnis /usr/local/lib/node_modules auf keinem meiner Raspis gibt, nie gab. Erst die Installation von n und die anschließend fehlgeschlagene Update-Prozedur führten scheinbar dazu, dass dieses Verzeichnis angelegt wurde.


    Davon abgesehen keine weiteren Probleme mit Node.js-Version 14.15.0 sowie homebridge-camera-ffmpeg, homebridge-fritz, homebridge-harmony, homebridge-http-switch und homebridge-hue.

    Das könnte sein. An meiner Hue-Bridge hängt eine reine Hue-Umgebung plus zwei Paulmann-Zigbee-Controller. Bei mir treten keine Probleme auf. Es wäre sicherlich gut, wenn diejenigen, deren Konfiguration ständig gestört wird, mal die angeschlossenen Geräte benennen. Vielleicht kann man so den Fehler eingrenzen.

    Beim Thread-Ersteller mag es andere Ursachen gegeben haben, hier ging der Stress mit den LivingWhites los. Philips lagerte seine Lichtabteilung aus und Signify ist generell unlustig, was Altlasten anbetrifft. Die LivingWhites wurden kurzerhand in einen nicht existierenden HomeKit-Raum umsortiert – mit jedem Update erneut. Ich hatte daher testweise auch einen Paulmann-Dimmer erworben, nur ist dessen elektrische Installation weit entfernt vom Komfort der alten Philips-Dimmer.

    sschuste: n scheint homebridge im Verzeichnis /home/pi/.homebridge/zu erwarten, wohingegen die Installation nach der Anleitung auf der offiziellen Homebridge-Seite von GitHub in /var/lib/homebridge stattfindet. Wie löst man diesen Konflikt?


    Ergänzung nach weiterer Analyse:

    Aktualisiere ich auf node 14.15.0 mittels sudo hb-service update-node, läuft alles einwandfrei und meine drei homebridge-Installationen arbeiten nach Neustart freundlich weiter. Verwende ich allerdings n, beschwert sich homebridge:

    Code
    Error: The module '/usr/lib/node_modules/homebridge-config-ui-x/node_modules/node-pty-prebuilt-multiarch/build/Release/pty.node'
    was compiled against a different Node.js version using
    NODE_MODULE_VERSION 72. This version of Node.js requires
    NODE_MODULE_VERSION 83. Please try re-compiling or re-installing
    the module (for instance, using `npm rebuild` or `npm install`).

    Daraufhin startet homebridge nicht mehr, sucht nach Konfigurationdateien und legt das Verzeichnis /home/pi/.homebridge/ an, was zu weiterer Verwirrung führt. Erst wenn ich homebridge-config-ui-x deinstalliere und wieder installiere, klappt wieder alles:

    Code
    # cleanup
    sudo npm uninstall -g homebridge-config-ui-x
    # reinstall
    sudo npm install -g --unsafe-perm homebridge-config-ui-x

    Auch merkwürdig: nach der Installation von n hatte sich der npm-Pfad geändert:

    Code
    npm -g root
    /usr/local/lib/node_modules

    Das kann man so ändern:

    Code
    sudo npm -g config set prefix /usr

    Irgendwie habe ich mit n Pech. Dies daher als kleiner Hinweis an diejenigen, denen es vielleicht ähnlich geht …

    Dem schließe ich mich an, aber ich drücke auch nie wieder auf "Hue - Siri" synchronisieren.

    Hielt ich auch so, ungewollte Veränderungen fanden trotzdem statt. Konfigurationen sind aber auch selten so ähnlich, dass alle Ergebnisse und Fehlverhalten von allen reproduzierbar wären. In meinem Fall hatte ich die von Signify ungeliebten LivingWhites in Verdacht, deren Hersteller-ID Signify zwar umbenannt, sie dann aber nur sehr halbherzig wieder integriert hat.

    Sehr nervtötend, weshalb ich die Anwendung schon seit längerem nicht mehr einsetze und alles per homebridge-hue ansteuere. Bin gerade außerdem im Begriff, den ganzen Signify-Mist auszulagern und auf den Rasbee II umzusteigen. Die Hue-Basis habe ich damit zum ausschließlichen Steuern meiner alten LivingWhites-Dimmer verdammt, da dies der einzige Weg ist, sie in den HomeKit zu integrieren. Philips/Signify bastelt nun seit über einem Jahr auf Kosten seiner Kunden vor sich hin, nein danke.


    Spy: Schön für Dich!

    Eine Frage noch mal an alle Betroffenen. Nutzt ihr eine FRITZ!Box?

    Sehr berechtigte Frage!


    Hier kam es zu diversen HomeKit-Statusproblemen nach dem Update der 7590 auf FRITZ!OS 7.20/7.21. Diese verschwanden erst nach dem Trennen der FRITZ!Box vom Netz und anschließendem Neustart (so mehrfach empfohlen unter ip-phone-forum.de). Gleiches habe ich dann sicherheitshalber auch mit den beiden 1750-Repeatern getan. Seither alles wieder im grünen Bereich!


    HTH,

    D.

    [...] aber das Plugin übermittelt die credentials nicht mit irgendwie....

    Yep, Credentials in URLs mag Apple (WebKit? HomeKit?) generell nicht. Das konnte ich aber umgehen, da ich einen lokalen Webserver betreibe, auf dem der „Link Shortener“ YOURLS läuft. Ich habe die entsprechende URL mit Login und Passwort somit in eine sehr komplizierte Zahlen-/Buchstabenfolge gewandelt. Sobald ich diese dann aufrufe, klappt es perfekt.

    als buttenSid habe ich die aus dem Plugin stehen lassen, glaube "158d00029088e3"

    Alles klar, habe ich dann ebenso gehandhabt.

    Zitat

    bei axis kann man unter Ereignisse auch "Empfänger" anlegen, hier habe ich die IP der Homebridge-Instanz mit zugehörigem Port eingetragen (http://192.168.1.X:4343) als "Klingel Homekit" und als Event "wenn Anruf / Call > ringing" dann "Klingel Homekit"

    Hier muss ich in meinem Fall leider noch experimentieren, da Mobotix bekanntermaßen mit großer Hingabe das schlimmste Interface aller Zeiten pflegt …

    Zitat

    edit: der türöffner geht nur, wenn ich die sicherheitseinstellungen der kamera runter nehme...

    dann gibt es aber einen fehler in der app des herstellers...da bin ich noch am tüfteln.

    Auch nicht schön. Bei der Mobotix läuft das relativ leicht über eine URL, die Login und Passwort enthält (natürlich nicht, wenn man das irgendwo außerhalb des eigenen Netzwerkes anwendet).


    Danke jedenfalls für die Rückmeldung – so hat man jedes Wochenende (oder bei jedem neuen Virus ;)) was zum Experimentieren …

    Code
    "event": {
    "buttonSid": "XXXXXXXXXXXXX",
    "motion": false,
    "switch": {
    "name": "Klingelsensor"

    Kannst Du mir eventuell mal detaillierter erklären, was es genau damit auf sich hat und was unter „buttonSid“ konkret einzutragen wäre?


    Und welches Event von Deiner Axis sendest Du genau an Deinen Homebridge-Server? Soweit ich verstehe muss es Port 6412 sein, korrekt?


    Als Event meiner Türstation (Mobotix T25) stehen mir beispielsweise folgende Optionen zur Verfügung:


    - Nur TCP/IP

    - HTTP/1.0-Request

    - HTTP/1.0-Request mit Bestätigung


    Ich habe mich für die erste Option entschieden und zusätzlich als Datentyp „Live- oder Alarmbild“ ausgewählt. Den HTTP-Trigger für den Türöffner meiner Türstation konnte ich übrigens finden. Jeder Hersteller kocht da natürlich sein eigenes Süppchen … Wie aber sieht das bei Dir aus? Immerhin läuft es ja scheinbar.


    Danke!

    Du hast den Post definitiv missverstanden, denn ich sage nirgends das alles hingenommen werden muss.

    Nein, ich habe Deinen Post nicht missverstanden. Du magst Dich aber missverständlich ausgedrückt haben.

    Was offiziell Unterstützt wird und was nicht, ist das einzige was zählt.

    Das spielt wie gesagt keine Rolle. Unternehmen heutiger Prägung geben in den seltensten Fällen noch Funktionsgarantien für irgendwas. Es gibt meines Wissens keine verbindlichen (weder rechtlich noch moralisch) Listen unterstützter Funktionen/Produkte der Firma Signify. Kritik übern kann und muss ich gerade deswegen in solchen Fällen.

    Sich aber über eine gestrichene Funktion zu beschweren, die es Offiziell nie gab empfinde ich als Kindisch. Denn es ist ja nicht so, dass diese Hue Living White Steckdose in der Hue App selber nicht mehr alles macht wie vorher. Nur in der Home App funktioniert sie nicht mehr so wie früher und früher würde sie dort nie offiziell unterstützt und auch jetzt wird sie nicht offiziell unterstützt, sondern nur der neue Hue Plug.

    Fakt ist, dass Signify ohne Ankündigung Bestandteile einer Firmware entfernt hat, die zuvor enthalten waren. Und das geschah just zu dem Zeitpunkt, als man ein schlechteres Produkt vermarkten wollte.

    Ziemlich verdrehte Logik, bei Philips beschweren aber von Apple alles hinnehmen....

    ?


    Nun, ich mutmaße, dass ich über die Jahrzehnte hinweg Apple oft und deutlich genug kritisiert habe, vermutlich mehr als jeder andere. Aber die Details dazu müssen Dich nicht interessieren. Wie gesagt, das Kapitel Apple habe ich zwischenzeitlich sehr auf ein Minimum reduziert, das der Firma Signify ebenso.

    Du verdrehst hier ziemlich die Updates, aus den Kontext oben erkennt Mann/Frau klar das ich die Update für das Smarthome meine. Dazu meine ich das Instant auf Update klicken wenn das Update erscheint. Niemand zwingt euch einen auf Early Adaptor zu machen, ihr klickt alle freiwillig auf den Update Button und installiert auch alle freiwillig die neuen Plugins Updates.

    Was ich alles so verdrehe: Logik, Updates …

    Und bei den Smarthome Updates muss überhaupt nicht geschickt vorgegangen werden, denn die kann niemand einfach so aus versehen Installieren. Die ganzen Apps müssen nur auf 1nem Gerät sein und bei diesen kann die Auto Update Funktion abgeschaltet werden. Bsp. die Eve App muss nicht auf allen Geräten im Haushalt installiert sein, gleiche mit der Hue App.

    Du weißt einfach nicht, wovon Du sprichst/schreibst! Selbst bei abgeschalteter Update-Funktion gibt es eine permanente Update-Aufforderung auf sämtlichen Hue-Klienten. Das lässt sich nur mit Pi-hole sperren und führt dann unter Umständen dazu, dass gewisse Funktionen fehlen. Es ist aber unmöglich vorauszuahnen, wer was wann aus welcher Firmware entfernt, ob offiziell oder nicht, denn selbst die Release Notes von Signify erscheinen wiederholt mit starker Verspätung. Und Deine sinngemäße Aussage, man solle einfach keine Updates machen, ist unverändert dummes Zeug.

    Bei mir zum Beispiel sind all diese Apps nur auf dem iPad installiert, welches früher als Steuerzentrale verwendet wurde bis das ATV gekommen ist. Alle anderen Devices haben nur die Home App drauf und können bei bedarf so die Szenen und Automationen so ausführen lassen. Brauchen sie aber nicht, denn dafür sind die Automationen ja da, die Automatisch die Dinge eben ausführen.

    Nicht alle Anwender haben die gleichen Konfigurationen, weshalb sich Deine Standpunkte auch nicht verallgemeinern lassen. Auch ich erhebe gewiss nicht den Anspruch, universelle Aussagen zu treffen. Aber ich will Dir hier doch gerne mal entgegnen: Deine Installation ist einfach kindisch!

    Wenn Ihr nun Hue meiden wollt, ist es euer gutes Recht, kann euch sogar ein wenig verstehen. Da Ihr vom Support einfach wirklich nun enttäuscht werdet. Jedoch finde ich persönlich, den Grund dafür ein bisschen seltsam, will nicht sagen Kindisch.

    Nachdem ich mich nun mehrere Wochen über diesen unnützen Kommentar geärgert habe, hier eine Antwort: „kindisch“ ist doch wohl eher, wer alles hinnimmt, was man ihm nach der „Friss oder stirb“-Taktik vorwirft – jedenfalls ein nach autoritären Prinzipien verunstaltetes Kind handelte derart.

    Ihr habt einen Philips Living White Produkt mit einer Philips Hue Bridge gekoppelt, wo die Kompatibilität nie offiziell bestätigt wurde und nun beschwert Ihr euch dass es nicht mehr zu 100% alles Funktioniert... Würdet Ihr euch auch bei Apple Beschweren, wenn die mit einen Update mal schnell die Homebridge Unterstützung komplett killen würden? Und noch wichtiger, würdet Ihr dann keine Apple Produkte mehr kaufen?

    Ob das offiziell oder nicht der Fall war, spielt keine Rolle, da es perfekt funktionierte und die Tatsache, dass dies überhaupt jemals bekannt wurde, Philips-Mitarbeitern zu verdanken war. Diese Funktion nun in der „Ära“ (?) Signify sang- und klanglos genau dann zu entfernen, wenn der von Philips ausgelagerte Firmen-Wurmfortsatz selbst erst nach Jahren Wartezeit und unter Vorgabe absurder Argumente eine funktionsärmere Schaltsteckdosen-Variante vermarktet, dann ist das einfach nur eine tiefe Verachtung Bestandskunden gegenüber. Und ich brauche Dir ja kaum zu verdeutlichen, dass sich statistisch belegt einmal verlorene Bestandskunden so gut wie überhaupt nicht mehr wiedergewinnen lassen.


    Signify ist wie viele andere verkorkste Unternehmen momentan in einer sinnfreien Expansionslaune. Schau Dir nur mal Luceplan aus dem Signify-Repertoire (leider!) und beispielsweise deren sehr populäre Leuchte Titania an. Das darin verwendete Leuchtmittel kannst Du bis heute durch absolut gar nichts aus der Hue-Reihe ersetzen, was schnell verdeutlicht, dass hinter Signify keinerlei Strategie erkennbar ist. Bis die überhaupt wissen, was sie mit all ihren Zukäufen machen wollen, sind die Kunden wahrscheinlich bei Trådfri & Co. gelandet. Oder was versteckt sich hinter der Tatsache, dass Hue-Lichtschalter zwar in den Niederlanden entwickelt wurden, jedoch US-amerikanischen Dimensionen entsprechen? Oder weshalb gibt es Leuchtmittel wie diese hier überhaupt nur in den USA?


    Nein, bei Apple beschwere ich mich aufgrund deren völliger Ignoranz überhaupt nicht mehr, auch den Kauf von deren Produkten habe ich nach vielen schmerzlichen Erfahrungen (Aperture, Mac Pro und macOS Server unter anderem) radikal eingeschränkt. Die meisten der Funktionalitäten, die einst ausschließlich Apple-Hardware erledigte, verrichten nun NAS und diverse Raspberry Pi – der Mac ist damit vorwiegend zum Allerweltskram-Nichtsnutz geworden. Und falls Apple eines Tages Homebridge verunmöglichen sollte – was mich überhaupt nicht mehr überraschte –, dann werden eben weitere Apple-Gerätekategorien gestrichen.

    Vielleicht bringt euch das aber nun mal von euren ständigen Update drang weg und lässt das System einfach laufen und Updatet nur wenn es Probleme, neue Funktionen etc. gibt. Mir hat ein Plugin, als noch alle Plugins in eine Instanz waren, mal alles zusammen gehauen. Seit dem weiß ich, dass ich erst dann Update wenn ich muss oder es für mich neue wichtigen Funktionen gibt.

    Klasse Hinweis, herzlichen Dank! Du meinst also, wir sollen gar nicht mehr updaten, damit wir nicht negativ überrascht werden? Versuche das mal alleine in Sachen iOS/iPadOS/macOS/tvOS! Nervende Aufforderungen ohne Ende, genau wie eben bei Hue. Kaum eine Woche vergeht mehr ohne irgendwelche Firmware-Updates (gestern beispielsweise die batteriebetriebenen Schalter). Wer das nicht mehr haben und sehen will, der muss schon sehr geschickt vorgehen, damit wirklich keiner aus dem Haushalt unfreiwillig irgendwas doch installiert. Da muss dann zumindest Pi-hole herhalten, damit man das überhaupt noch irgendwie durchsteht – ohne Nebenwirkungen geht das aber nie. Und was ist mit den ach so relevanten Sicherheitsupdates? Einfach ignorieren?

    Um noch einmal konkret auf deine Frage zurückzukommen: Wie oft startest Du die homebridge neu? In meinen eigenen Setups höchstens einmal im Monat. Von daher habe ich es bislang nicht für wichtig erachtet da mehr Zeit reinzustecken.

    Zunächst danke für die Erklärung – das hilft ungemein beim Verstehen solcher Vorgänge. Auch ich starte Homebridge eher selten neu, schon der gewöhnliche Aufruf der iOS-Home-Anwendung führt halt leider dazu, dass sämtliche Module aktualisiert werden und es dann immer an „homebridge-ranger“ liegt, dass alles insgesamt stark verlangsamt wird.


    Hier zum Vergleich, jeweils bei normal laufender Homebridge:


    1) Mit installiertem homebridge-ranger und nur einem „Eve Degree“-Modul in zwei Meter Entfernung vom iMac (2017) dauert es 55 (!) Sekunden bis alle Daten angezeigt werden.


    2) Ohne homebridge-ranger dauert es lediglich eine knappe Sekunde bis alle Daten angezeigt werden.


    Installiert habe ich neben homebridge-ranger v0.3.2 derzeit homebridge-harmonyhub v0.1.1, homebridge-camera-ffmpeg v0.1.3, homebridge-config-ui-x v2.6.0, homebridge-fritz v0.6.0, homebridge-hue v0.6.4 und homebridge-netatmo v0.2.0. Das Ganze läuft unter der Homebridge-Version 0.4.38 mit node-v9.5.0.


    Mag sein, dass das ein Bug in meiner Konfiguration ist, nur zeigt sich dieser halt nicht in den Logfiles und nur wenn homebridge-ranger läuft. Es dauert übrigens noch länger, wenn ich das zweite „Eve Degree“-Modul in die Konfiguration eintrage, es steht allerdings auch ein Stockwerk höher und ist daher laut Log nicht immer erreichbar. Ich habe homebridge-range nun vor einigen Tagen aus der config.json entfernt, andernfalls konnte Siri oft auch die anderen Geräte nicht mehr zeitnah ein- und ausschalten. Vielleicht bremst da irgendwas im Bluetooth-Untergrund, keine Ahnung. Wenn Du noch irgendwas näheres wissen willst, dann nur zu.