Beiträge von sschuste

  • Homempod Mini zurückgesetzt - Automationen werden weiterhin nicht ausgeführt!

    Controller for Homekit, EVE, Home, Home+, HomeSpy und viele andere HomeKit-Apps sind Frontends für HomeKit. Sie sind alle abhängig davon, was HomeKit kann. Die Entwickler kochen hier also nicht nur mit Wasser, nein, sie kochen auch noch alle mit demselben Wasser im gleichen Topf.


    HomeKit kann deutlich mehr, als Apples Home-App anbietet. Was es genau kann, weiß ich allerdings auch nicht, aber ich habe beispielsweise feststellen müssen, dass Automationen nicht liefen, wenn sie zwischen Sonnenuntergang und Sonnenaufgang stattfinden sollten. Es erschien mir so, als würde HomeKit nur einen einzigen Tag betrachten, und es gibt an einem Mittwoch, den 27. Januar, zwischen 0:00 und 24:00 Uhr keinen einzigen Moment, der zwischen Sonnenuntergang (abends am Mittwoch) und Sonnenuntergang (morgens am Mittwoch) liegt.


    Automationen, die nach Sonnenuntergang stattfinden sollen, tun das zuverlässig, und zwar bis Mitternacht. Komme ich nachts um 1:00 Uhr nach Hause, geht das Licht in meiner Wohnung nicht mehr an. Saublöd, aber das könnte ein Grund für deine Probleme mit deinen Automationen sein.


    Und ich bin mir nicht mal sicher, ob es richtig ist, was ich hier schreibe.

  • MQTTHING - Homebridge - PH Wert Messung

    Zitat von mpkomodo

    Ich habe nun MQTTHING installiert und die Wetterstation ausgewählt um den PH Wert anzeigen zu lassen.

    Habe Tampered ausgewählt - er zeigt mir 0,0 an

    Temperatursensor hat auch nichts gebracht.

    Über Node Red bekomme ich den Wert 7,00

    Weiß ich nicht. Ich schlage vor, du machst aus Node Red eine HomeKit-Bridge, indem du die Palette node-red-contrib-homekit-bridged installierst. Damit bringe ich meine MQTT-Werte nach HomeKit.


    Achtung: es kommt vor, das man Node Red neu starten muss, wenn man Änderungen an den HomeKit-Nodes macht.

  • HomeBridge für alle Komponenten?

    Zitat von Frische_Milch

    Ich habe schon gelesen, dass man einen Raspberry pi 3 als Home Bridge einrichten kann. Werden dann trotzdem noch z.B. für Ikea, Phillips Hue oder Shelly die jeweilige separate Bridge benötigt, oder reicht die einzelner Bridge, wie den Raspi 3 für alle Komponenten aus?

    Geile Frage. Die Antwort lautet ja oder nein, gerade wie's einem so gefällt. Das hängt vom eigenen Wissen und auch vom eigenen Geschmack ab. Ich bin davon überzeugt, dass dir diese Antwort keinen Millimeter weiterhilft, aber so ist das nun mal ^^.


    Zunächst muss man mal raffen, was überhaupt eine Bridge ist und wozu sie benötigt wird. Hersteller von smarten Geräten verwenden zur deren Steuerung irgendeinen (Funk)standard. Dieser Standard kann so einiges sein: Z-Wave, Zigbee, KNX, Homematic, aber auch weniger Bekanntes wie, ähm, keine Ahnung, nennen wir das mal Blafasel. Allen gemein ist, dass die einzelnen Geräte (also die Lampen, Sensoren, Ventile, whatever) genau einem dieser Standards folgen und nicht etwa mehreren.


    Weiterhin sind die Charakteristiken dieser Geräte sehr unterschiedlich: Lampen kann man ein- oder ausschalten oder dimmen, Ventile kann man öffnen oder schließen, Motoren starten oder stoppen, Sensoren kann man nur abfragen. Gleichzeitig baut die Hersteller nicht mordsmäßige Technologie in jedes dieser Geräte ein, sondern verlagern die Intelligenz auf eine Bridge.


    Möchte ein Hersteller nun die Funktionalität seines Systems etwa dadurch erweitern, dass er zukünftig eine programmierbare Schnittstelle anbieten will, muss er dafür nur die Software seiner Bridge ändern, nicht aber die Software der einzelnen Geräte. Das vereinfacht die Aufgabe für jeden: je nach Größe deines Anwesens und der Anzahl deiner Geräte wärst du sonst möglicherweise Tage damit beschäftigt, allen smarten Geräten ein Update zu verpassen.


    Zigbee-fähige Geräte brauchen eine Zigbee-Bridge, Z-Wave-fähige Geräte eine Z-Wave-Bridge und Blafasel-fähige-Geräte eine Blafasel-Bridge. Allen gemein ist, dass sie nicht untereinander kompatibel sind: eine Z-Wave-Bridge kann beispielsweise keine Zigbee-fähigen Geräte ansteuern. Gleichzeitig brauchst du dazu eine eigene Fernbedienung oder App für jedes dieser Systeme. Um die Verwirrung zu steigern, nennt Philips seine Bridge eine Bridge, Ikea nennt seine Bridge Gateway und Homematic nennt die Bridge CCU, wobei man da zwischen CCU2 und CCU3 unterscheiden muss oder zwischen der runden und der eckigen Philips-Bridge. Hurra! So lieben wir es!


    Hat man sich also entschieden, zukünftig zu der bestehenden HomeMatic-Installation auch noch IKEA Trådfri zu verwenden, hat man schon mal zwei Bridges da herumstehen, und dann bekommt man zu Weihnachten von Tante Mia auch noch diese formschöne Lampe geschenkt, die dem Z-Wave-Standard folgt und benötigt prompt eine dritte Bridge.


    Nun gibt es wunderbarerweise HomeKit, das alle Standards zusammenfasst. Das hört sich an wie das Versprechen eines Lebens, in dem Milch und Honig fließen (oder besser: Bier und Gin Tonic). Das hört sich so an wie: kauf einfach ein iPhone und du hast nie wieder Probleme. Die Wahrheit ist: das hört sich so an, aber ist nicht so.


    Natürlich kann ein iPhone HomeKit, aber um etwas mit HomeKit zu steuern, müssen auch das Etwas HomeKit können. Glücklicherweise muss man das jetzt nicht jeder der 120 Glühbirnen in der Garagenauffahrt beibringen, aber zumindest die Bridge muss HomeKit können. Die Bridge übersetzt dann HomeKit nach Zigbee oder nach Z-Wave oder nach Blafasel.


    Philips und IKEA haben sich entschieden, HomeKit ihren Bridges beizubringen. HomeMatic hat sich dazu bislang nicht durchringen können. Hier kommt die Homebridge ins Spiel: sie kann HomeKit nach HomeMatic übersetzen. Und dafür ist die Homebridge da: sie übersetzt nicht-Kompatibles in was Kompatibles. Dazu wird sie durch Plugins erweitert, die einen bestimmten Standard jeweils verstehen. Das heißt nicht, dass die Homebridge damit die anderen Bridges einfach ersetzen kann. Die werden weiterhin benötigt, die Homebridge steuert diese Bridges dann an.


    Will man auf die einzelnen Bridges verzichten, weil man nicht einen Geräte-Zoo betreiben will, dann kann man einen RaspberryPi erweitern durch Hardware. Beispielsweise könnte man Zigbee-Hardware von Dresden Electronik einbauen, die die Bridges von IKEA, Aqara und Philips ersetzt. Das hat den unschätzbaren Vorteil, das man weniger Strom verbraucht und alles zentral konfigurieren kann, und den unschätzbaren Nachteil, dass man seinen smarten Geräten keine Updates mehr verpassen kann. Und hier kommen wir dann wieder zu deiner Frage, und die Antwort lautet: wenn du es einfach haben willst, dann kaufe HomeKit-kompatible Bridges und betreibe dein SmartHome damit. Wenn du gerne bastelst, dann bau einen Raspi um, sei es durch die Erweiterung von Zigbee/Z-Wave-Hardware oder durch die Installation einer Homebridge, die dir sogar das Blafasel-Protokoll in HomeKit übersetzt.


    Ich hab's gemischt: ich betreibe eine Homebridge und eine Hue-Bridge und kaufe möglichst kompatibel ein. Die Homebridge übersetzt mit den entsprechenden Plugins übrigens auch Sachen in HomeKit, die mit Smarthome erstmal nichts zu tun haben, beispielsweise die Ergebnisse einer Anfrage an einen Wetterserver oder den Google-Kalender.


    Tatsächlich gibt es auch HomeKit-fähige Geräte, die keine Bridge benötigen. Dazu gehören beispielsweise die Produkte von EVE, aber auch die Steckerleisten von KooGeek und bestimmt noch so einige andere. Diese Geräte können nur HomeKit und damit wird dann dein AppleTV oder deine HomePod oder ein iPad sozusagen zur Bridge für diese Geräte.

  • Pi-hole | Werbeblocker für das Heimnetz auf dem Raspberry Pi

    Zitat von buzz-dee

    Alle Clients in meinem Netz nutzen für ihre DNS-Anfragen den Pihole Server, weil sie das per DHCP so beigebracht bekommen haben.

    Wenn Pihole eine Anfrage NICHT selbst beantworten kann (z.b. mit seiner Gravity-Liste der geblockten Domains), leitet er die Anfrage an die UPstream DNS Server zur Beantwortung weiter. Da die FRITZ!Box hier auch als Upstream eingetragen ist UND die Fritz.Box-Adressen auflösen kann, kommt von der FRITZ!Box die Antwort an den Client zurück und die Namensauflösung klappt.

    Genau so funktioniert das.

    Zitat von buzz-dee

    Wenn die FRITZ!Box dort nicht drinstehen würde, müssten die OPenDNS Server die Anfrage beantworten und das können sie nicht.

    Doch, das können sie.

    Zitat von buzz-dee

    Bei dir funktioniert es weil du unter DNS die local Domain Fritz.Box eingetragen hast und deinen ip Adressbereich. Wenn du meine Einstellungen ausprobierst müsstest du Domain wieder rausnehmen UND den Haken bei „Never forward reverse lookups for private ip Ranges“ ebenfalls entfernen. Nach der Beschreibung die darunter steht verhindert dieses option genau die Art der Namensauflösung über den Upstream Server wie ich sie oben beschrieben habe.

    Ein reverse lookup übersetzt eine IP-Adresse in einen Hostnamen. Normalerweise macht man nur einen lookup: welche Adresse hat homepi.lan (Ergebnis ist so was wie 192.168.178.22)? Welche Adresse hat http://www.apple.com (Ergebnis ist so was wie 95.101.185.4)?


    Pi-hole soll diese Fragen beantworten, und wenn pi-hole das nicht weiß, dann leitet es die Anfrage an den upstream DNS server weiter. Das kann der eigene Router sein, der es möglicherweise auch nicht weiß und die Anfrage weiterleitet an seinen upstream DNS server - mit hoher Wahrscheinlichkeit und voreingestellt ist das dann ein DNS beim Provider.


    Oder: pi-hole leitet die Anfrage anstatt an den eigenen Router gleich weiter an einen externen DNS wie OpenDNS oder Google. Dann bekommt pi-hole die Antwort von dort.


    Beim reverse lookup aber lautet die Frage: welchen hostname hat 95.101.185.4? Für eine solche Anfrage gibt es vielleicht eine Antwort. Das hängt ganz davon ab, wie gut der DNS gepflegt ist, und zwar nicht der pi-hole-DNS und auch nicht der Router-DNS und auch nicht der Provider-DNS, sondern der DNS von den Leuten, die die IP-Adresse 95.101.185.4 verwalten.


    "Never forward reverse lookups for private ip Ranges" bedeutet, dass pi-hole die Anfrage "welchen hostname hat 192.168.178.22?" nicht an irgendeinen upstream DNS server weiterleiten soll. Im Allgemeinen weiß ein upstream DNS server das auch gar nicht, es sei denn, er ist unser eigener Router und unser eigner DHCP-Server! Ist der upstream DNS server für pi-hole der eigene Router, dann würde ich den Haken nicht setzen. Erst wenn der upstream DNS server ein externer ist wie OpenDNS, würde ich den Haken setzen.


    Ein reverse lookup wird eher selten gebraucht. Für den Betrieb unserer Maschinen und Services ist er unerheblich.


    Der Vollständigkeit halber bleibt noch die Frage: wtf ist FQDN? FQDN ist die Abkürzung für full qualified domain name. Damit ist der vollständige Name einer Maschine gemeint. Beispiele für solche FQDNs sind http://www.apple.com, http://www.google.com, forum.smartapfel.de oder homebridge.lan. Die unvollständigen hostnames für die gerade genannten Beispiele sind www, www, forum und homebridge. Nicht-vollständige Namen (non-FQDNs) sollen nicht an upstream DNS server weitergeleitet werden. Hier gilt das gleiche wie oben: ist der upstream DNS server der eigene Router, dann leite es weiter, ist es ein externer, dann leite es nicht weiter.

  • Philips Hue Bewegungssensor

    Zitat von djsunz

    Die Umsetzung ist doch ganz einfach: Licht soll 2 min im Bad bei Erkennung einer Bewegung an sein. Erfasst der Bewegungsmelder eine Bewegung innerhalb der 2 min, verlängert sich die Zeit, die 2 min laufen erneut. Und genau das ist eben z. B. Mit Apple HomeKit Sonos und hue Bewegungsmelder nicht möglich.

    Bei mir geht das, aber ich habe das nicht über Home, sondern über die Hue-App konfiguriert.

  • IP-Teilnehmer als Schalter

    Beyon Wenn du gerade mitliest: ich ärgere mich schon lange über eine Einstellung in homebridge-people, und alle Forks schleppen die mit, nämlich das berühmte "cacheDirectory": "./.node-persist/storage.


    Die Verwendung dieses Pfades wird mit großer Sicherheit zu einem Fehler führen, denn offensichtlich soll der Cache im Plugin-Verzeichnis angelegt werden. Bei den meisten Installationen ist dieses Verzeichnis aber nicht beschreibbar. Der Pfad taucht aber trotzdem sowohl in der Beispiel-config.json auf als auch in der Dokumentation. Dort steht fälschlicherweise auch noch optional, default: "./.node-persist/storage", was nicht richtig ist, denn der Default ist das Homebridge-Verzeichnis.


    base/platform.js

    this.cacheDirectory = config.cacheDirectory || homebridge.user.persistPath();


    Die Doku ist von Anfang an schon im Original-Plugin falsch gewesen und alle kopieren es fleißig weiter.


    Ich bin ganz sicher nicht der einzige, dem erstmal die Homebridge um die Ohren geflogen ist, aber ich bin einer der wenigen, die dann auch verstehen, was da los ist und wie man das beheben kann. Mir könnte es also egal sein, wenn hier nicht alle paar Tage einer um Ecke käme und fragte: wasndas? Und die Antwort lautet jedesmal: lösch die Zeile mit dem cacheDirectory, das isn Bug. Leicht enervierend.


    Meinst du, das könntest du ändern? Oder spricht etwas dagegen?

  • Plugin Installation über Command (git)

    Zitat von suxus

    Sieht es dann so aus als ob ich ein Problem mit dem npm-Cache hatte, war da was Altes drin?

    Ich weiß es nicht. Gelegentlich passiert sowas. Der npm-Installer hat da auch noch irgendwie ein eigenes Rechtesystem, wozu auch immer, und manchmal macht's dann bumm.


    Du solltest hier eines mitnehmen: wenn in Installationsanweisungen so etwas steht wie npm install homebridge-blafasel, dann ist das für dich immer:

    sudo npm install -g --unsafe-perm homebridge-blafasel

    Immer. Ausnahmslos. Egal was die Entwickler dahin schreiben.


    Und: wenn es geht, dann installiere alle Plugins über die Web-Oberfläche. Die macht genau das, was ich gerade aufgeschrieben habe und die macht's immer richtig. Das ging ja in deinem Fall nicht, und so kann's schon mal zu Gebastel kommen. Ist aber eher selten. Es kann tatsächlich auch passieren, dass man es gar nicht zum Laufen bekommt, aber das ist dann ganz selten.


    Einfach hier fragen.

  • Plugin Installation über Command (git)

    Der Entwickler hat dich angewiesen, das Plugin in dein Homeverzeichnis zu installieren, was du nicht willst. Du willst es lieber dort installieren, wo auch die anderen Plugins sind, also global, und so wird aus npm install schon mal gleich ein npm install -g, und weil du nicht die erforderlichen Rechte hast, das auszuführen, wird aus dem npm install -g ein sudo npm install -g.


    sudo npm install -g git+https://github.com/rloomans/homebridge-unifi-kids-cry.git