Beiträge von sschuste

    Ach komm. Manche kommen mit der App gut zurecht. Andere nicht. Ich hab sie ja auch. Und wenn ich bedenke, was mir die SmartHome-Hersteller schon abgeknöpft haben...


    Viele im Forum empfehlen die manuelle Installation von Homebridge. Und das ist auch nicht sonderlich schwierig. Ich hab das hier mal beschrieben. Mit hammergeilen farbigen Abbildungen. Und zum Schluss konfiguriert man die App so, dass sie mit der manuellen Installation übereinstimmt, und voilà: schon hat man ein schönes Monitoring-Tool auf dem iPhone.


    Stefan

    Homebridge-Plugins können dann Verlaufskurven erstellen, wenn sie fakegato-history unterstützen. Das ist ein Node-Modul, dass die Werte speichert und EVE-fähig macht. Programmierer von Plugins müssen das in ihren Code einbauen. Von allein geht das leider nicht.


    Stefan

    Mit kurzfristig meine ich: bis die App diese Installation ausgeführt hat. Was installiert wurde, weiß ich selber nicht.

    Das ist doch das Schöne an der App. Wird nur noch übertroffen durch eine Autofahrt über die Todesstraße der Anden mit verbunden Augen:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    Stefan

    Ich hatte letzte Woche einen Issue eröffnet, aber es gab leider keinerlei Reaktion darauf. :(
    Es scheint wohl nicht mehr gepflegt zu werden.

    Abwarten. Programmierer von Plugins müssen gelegentlich auch mal arbeiten gehen. Oder Urlaub machen. Plugins werden in wahrscheinlich allen Fällen von einzelnen Menschen gemacht und nicht von Unternehmen mit angeschlossenem Callcenter.


    Stefan

    Hinzu kommt das meine HB einmal am Tag abstürzt und ich weis nicht warum..

    Ich auch nicht.


    Da steht nur, dass deine HUE-Bridge nicht zu erreichen ist (timeout). Die IP-Adresse sieht ja auch komisch aus.


    Stefan

    Error found at /usr/local/etc/mosquitto/mosquitto.conf:0.

    Error: Unable to open configuration file.

    Das steht, dass die Datei /usr/local/etc/mosquitto/mosquitto.conf nicht geöffnet werden konnte. Das wird sicherlich daran liegen, dass die Datei nicht an dieser Stelle existiert.


    Kann ich auch löschen? /usr/local/etc/mosquitto/mosquitto.conf

    Es ist so wie auf allen Computern: man kann nichts löschen, das nicht existiert.


    Die von dir erwähnte Anleitung beschreibt zwar, dass du eine Datei namens /etc/mosquitto/mosquitto.conf anlegen sollst, sagt aber auch gleichzeitig, dass du da was Falsches reinschreiben sollst (es muss natürlich bind_address mit dd heißen). An dieser Stelle muss ich zugeben, dass ich mosquitto nicht einsetze, aber ich hab's mir gerade mal installiert.


    Nachdem man mosquitto installiert hat, befindet sich das Programm in /usr/sbin. Es wird also mit /usr/sbin/mosquitto aufgerufen.


    Die Konfigurationsdatei ist noch nicht vorhanden. Man kann sie anlegen, wo man will, aber eigentlich gehört sie nach /etc/mosquitto/conf.d/mosquitto.conf. Dort habe ich sie angelegt mit


    sudo nano /etc/mosquitto/conf.d/mosquitto.conf


    Dort habe ich hineingeschrieben:

    Code
    bind_address 192.168.1.22


    und dann die Datei gespeichert. Wer das nachmachen will, kann die obige Zeile kritiklos übernehmen. Ich würde allerdings empfehlen, die IP-Adresse hineinzuschreiben, die der eigene Raspi hat. Ist besser, echt jetzt.


    Dann habe ich das vorhandene Startscript für mosquitto verschwinden lassen. Es wurde bei der Installation von mosquitto angelegt. Ich will das weghaben, weil es sonst beim Booten den Service starten würde. Ich möchte aber den Service auf eine andere Art und Weise beim Booten starten, und zwar per systemd. Solange das mitgelieferte Startscript also existiert, würde mosquitto beim Booten zweimal gestartet, was aber nicht geht und was daher blöde Fehlermeldung in den Logs hinterlässt. Also:


    sudo mv /etc/init.d/mosquitto . (ja, da steht tatsächlich ein einsamer Punkt am Ende)

    sudo rm /etc/rc3.d/*mosquitto*


    Dann habe ich das systemd-Startscript erstellt:


    sudo nano /etc/systemd/system/mosquitto.service


    und dort hineingeschrieben:


    Abgespeichert und dann:

    sudo systemctl daemon-reload

    sudo systemctl enable mosquito

    sudo systemctl start mosquito


    Ein Blick ins Log:

    sudo journalctl -fau mosquitto


    Und siehe:

    Code
    Nov 03 10:52:00 raspberrypi systemd[1]: Started Mosquitto MQTT Broker daemon.

    Cool. Wenn man soweit gekommen ist, dann geht's an die Installation des homebridge-Moduls. Nur nicht bei mir, weil ich kein MQTT einsetze und daher die Geschichte nicht weiterfolgen kann und will.


    Du bist daran gescheitert, weil du sämtliche Pfade, die falsch zu setzen waren falsch gesetzt hast. Du hast keinen ausgelassen. Das ist immerhin konsequent. Aber es ist nicht deine Schuld. Es liegt eher an nicht ganz so präzisen Anleitungen. Möglicherweise hilft dir der Sermon da oben weiter. Ich hab den jetzt aus dem Kopf dahin geschrieben und er hat hoffentlich keine Teppfihler und ich hab hoffentlich nix vergessen.


    Gruß,

    Stefan

    Ist dieser Befehl dann richtig? was führt mosquitto.conf aus?


    ExecStart=/usr/sbin/mosquitto/mosquitto -c /usr/local/etc/mosquitto/mosquitto.conf -d

    Nichts führt mosquitto.conf aus. Das ist eine unausführbare Konfigurationsdatei. Mosquitto lädt sie während seines Starts.


    which mosquitto hat also /usr/sbin/mosquitto ergeben. Dann schreib das auch so in deine mosquitto.service, bei dir steht nämlich mosquitto doppelt da.

    Code
    ExecStart=/usr/sbin/mosquitto -c /usr/local/etc/mosquitto/mosquitto.conf -d


    Wo kommt diese Konfigurationsdatei /usr/local/etc/mosquitto/mosquitto.conf her? Was passiert wenn du


    sudo /usr/sbin/mosquitto -c /usr/local/etc/mosquitto/mosquitto.conf -d


    auf der Shell eingibst?


    Stefan

    ExecStart=/usr/local/sbin/sudo mosquitto -c /usr/local/etc/mosquitto/mosquitto.conf -d

    Nö, so nicht. Es heißt

    Code
    ExecStart=/usr/local/sbin/mosquitto -c /usr/local/etc/mosquitto/mosquitto.conf -d

    Das sudo muss raus, und es hätte an der Stelle eh nix zu suchen gehabt. Wenn schon: sudo /usr/local/sbin/mosquitto -c /usr/local/etc/mosquitto/mosquitto.conf -d. Aber du brauchst das sudo eh nicht, weil du den Service startest mit sudo systemctl start mosquitto.


    Wenn du die Änderung vorgenommen hast, musst du sie noch dem systemd bekanntgeben mit

    sudo systemctl daemon-reload und dann

    sudo systemctl restart mosquitto


    Mich wundert der Pfad /usr/local/sbin/mosquitto. Falls du weiterhin Probleme hast, stelle bitte fest, wo mosquitto liegt mit dem Befehl


    which mosquitto


    und passe deine mosquitto.service dementsprechend an.


    Stefan

    Und wieder bin ich es, der die App vor Pauschalverrissen in Schutz nimmt und das Gegenteil behauptet 8) Bei mir seit knapp 1 Jahr Nutzung ergaben sich bis heut keinerlei Probleme.

    Fantastisch. Das Problem liegt heutzutage auch wahrscheinlich weniger an der App als an node. In den 90ern gab es unter Windows die sogenannte DLL-hell). Die Älteren unter uns werden sich erinnern). Verglichen zu node ist diese DLL-hell das gelobte Land.


    So was wie node denken sich Entwickler aus, die die Nase voll davon haben, dass ihnen ihr Systemadministrator ständig vorschreibt, sich doch gelegentlich mal an Strukturen zu halten. Installiert man ein Modul mit -g, dann landet es im globalen Pfad für Module, lässt man das weg, dann landet es im Homeverzeichnis. Manche Module können wegen Schreibrechten nicht installiert werden, selbst wenn man root ist, und dann muss man mit --unsafe-perm installieren. Dazu. Fällt. Mir. Nichts. Ein.


    Homebridge lässt sich voll auf diese Tradition des Unfassbaren ein und installiert seine config.json in einem versteckten Verzeichnis im Home-Directory (.homebridge). Hätte man den lästigen Admin gefragt, hätte der gesagt, dass das nach /etc/homebridge/config.json gehört. Das hätte der im Schlaf gesagt. Das hätte der sogar in volltrunkenem Zustand gesagt. Daraus hättest du einen weltweiten Admin-Chor machen können. Aber nö.


    Die persist- und accessories-Verzeichnisse hätten nach /var/homebridge gehört. Aber nö. Um den Braten richtig fett zu machen, installiert jedes node-module alle Module, die es braucht, um zu funktionieren, einfach nochmal in seinen eigenen Bauch. Also findet man manches Zeugs doppelt und dreifach und vierfach und fünffach, meist in verschiedenen Versionen, mal im globalen node-modules-Verzeichis, mal im Homeverzeichnis von pi, mal im Homeverzeichnis von root, je nachdem, wie der Anwender drauf war.


    Der Anwender. Der weltweite Admin-Chor setzt gerade zu einem schmetternden "Gnade! Herr, gib uns Gnade!" an, da kommt ein Haufen von ganz speziellen Anwendern um die Ecke, nämlich die, die schon gar keinen Plan haben. Das kann man zwar diesen Anwendern wirklich nicht vorwerfen, aber sie werden konfrontiert mit einem Haufen [die Forensoftware hat hier 27 aufeinanderfolgende obszöne Kraftausdrücke gelöscht]. Die armen Schlucker nehmen oft den ersten Kontakt zu Linux auf und kriegen erstmal den Hintern versohlt, und zwar so, dass sie tagelang nicht sitzen können. Das ist im Jahre 2018 überhaupt nicht notwendig, aber dank node und der darauf basierenden Software geht es hier nur auf die ganz harte Tour.


    Da kommt die App gerade richtig, wirklich. Nur: was die treibt, bleibt absolut im Dunkeln. Wohin installiert die nun alles? Da hat man schon eine hochunstrukturierte Umgebung und dank App bewegt man sich auch noch im Blindflug darauf.


    Und auf dieser ganzen Melange basiert unsere Home Automation, die uns alle einen Haufen Geld kostet. Das ist alles höchst unprofessionell. Ich habe meine Anleitung geschrieben, um etwas Ordnung in das Chaos zu bringen, aber ich scheitere daran. Ich hab keine Chance. Manche Plugins brauchen bestimmte node-Versionen. Andere mehr Rechte. Manchmal kapier ich selbst nicht, was gebraucht wird.


    Am Ende, wenn's dann läuft, und man durchflutet ist von einem tiefen Gefühl von Demut und Dankbarkeit, dann kommt HomeKit und tritt einem in den Allerwertesten. Na schön, aber dafür sind wir jetzt alle Pioniere :D


    Stefan

    Als ich mit der Thematik SmartHome begonnen habe war dies mit einer einzigen Hue Lampe. Dachte nicht das es sich so weiter entwickelt.

    Das dachte hier keiner. Das hier ist auch kein normales Forum, sondern eine Selbsthilfegruppe für AutomatenAutomationssüchtige.

    Da ist ein Fehler drin. Das accessory FakeBulb muss innerhalb der accessories-Definitionen stehen, steht aber außerhalb. Der seltene Fall einer gültigen JSON-Syntax, aber ungültigen homebridge-Konfiguration. So sollte es aussehen (ungetestet):


    Gruß

    Das Ergebnis ist exakt wie das obige. Und nun weiß ich wirklich absolut nicht mehr weiter.

    Das passiert ja offenbar beim Starten von homebridge. Du solltest mal versuchen, die Homebridge als root zu starten. Was passiert dann?


    sudo -i

    homebridge -U <PFAD_ZUM_VERZEICHNIS_IN_DEM_config.json_LIEGT>


    Gruß,

    Stefan

    Ergebnis: Es funktioniert. AAAAABer: Ich würde gerne verstehen, was ich nun in die sudoers.d/pi eintragen muss, damit der user pi keine kompletten root rechte hat, sondern nur für die funktionen verwendet werden darf, die in diesem falle benötigt werden.:D

    Du fummelst da auch an einer Stelle herum, die eine gewisse Kenntnis eines Linux- oder Unix-Systems verlangt. Rechteverwaltung für User ist schon kompliziert und man muss aufpassen, dass man sich nicht selber aussperrt. Ich könnte da mit peinlichen Vorfällen, in denen ich im Mittelpunkt stand, aufwarten ^^


    Zunächst: in einer Standardinstallation von Raspbian hat der User pi bereits die ALL-Rechte. Das steht bereits in /etc/sudoers drin. In meiner sudoers steht unter anderem (und ich hab da nix geändert):

    Code
    # Allow members of group sudo to execute any command
    %sudo	ALL=(ALL:ALL) ALL

    Erlaube den Mitgliedern der Gruppe sudo jedes Kommando auszuführen. Und pi ist Mitglied dieser Gruppe:

    Code
    pi@raspberrypi:~ $ id
    uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),997(gpio),998(i2c),999(spi)

    Achtung: Don't do this alone at home!

    Du entziehst dem User pi die Rechte, indem du in sudoers festlegst, was er als root ausführen darf. Im Zweifel darf er gar nichts. Ganz schlechte Idee. Oder er darf vielleicht einfach nur die Homebridge starten oder stoppen. Immer noch schlecht. Oder er darf wenigstens den Befehl /bin/su ausführen. Damit kann man schon leben.


    Warum ist das so? Sobald der User pi keine Befehle mehr als root ausführen darf, kannst du solche Befehle nur noch als User root ausführen. Dazu musst du dich anstatt mit pi auf deinem Raspi als root einloggen. Je nachdem, wie der ssh-Server konfiguriert ist, wird er dir den Login verweigern. Heutiger Standard ist, dass sich root nicht über ssh auf die Maschine einloggen darf. Mit dem User root kannst du dich dann nur noch an der Konsole einloggen, und das bedeutet, einen Monitor und ein Keyboard an den Raspi anzuschließen.


    OK, das ist mal echt supersicher. Aber wer will denn einen Monitor und ein Keyboard an den Raspi anschließen? Ich würde auf keinen Fall dem User pi irgendwelche Rechte entziehen.


    Ich habe deshalb einen neuen User mit dem Namen homebridge angelegt und ihm nur die grundlegenden Rechte gegeben. In meiner Anleitung steht, wie man das macht.


    Stefan

    Klar kannst du auch machen, sehe den Vorteil darin nur nicht. Zumal dieses Plugin auch nicht den Anyone Sensor hat, wenn ich das richtig im Kopf noch habe.

    Ich finde, das Plugin hat einen gewaltigen Vorteil. Es erspart einem nämlich eine Menge Arbeit.


    In den meisten Netzen werden IP-Adressen den angeschlossenen Geräten durch einen DHCP-Server zugewiesen. Wie geht das? Als Beispiel nehme ich mal ein iPhone, aber genauso geht das auch mit allen anderen Geräten im Netz: Computer, Sonos-Zeugs, Hue-Bridges, you name it.


    Der DHCP-Server versorgt ein iPhone, das per WLAN ins Netz kommt, mit einer IP-Adresse, mit der Gateway-Adresse, mit der Adresse des DNS-Servers, kurz: mit allen relevanten Netzwerkinformationen. Während die Adresse des Gateways/Routers und des DNS-Servers in nahezu allen Fällen immer gleich bleibt, kann der DHCP-Server dem iPhone unterschiedliche IP-Adressen geben: heute diese, morgen eine andere.


    Der DHCP-Server vergibt eine IP-Adresse immer dann, wenn ein Gerät danach fragt. Das iPhone schickt also seine MAC-Adresse ins Netz und bekommt die Netzwerkdaten, darunter seine IP-Adresse, zurück. Damit das iPhone nicht ununterbrochen danach fragt, schickt der DHCP-Server auch eine so genannte lease mit. Darin steht, wie lange er sich merken wird, welche IP-Adresse er dem iPhone gegeben hat (er hat die Adresse sozusagen verleast) und wie lange diese IP-Adresse somit für das iPhone reserviert ist.


    Steht in der lease, dass sie für 24 Stunden gültig ist, dann fragt das iPhone in den nächsten 24 Stunden nicht mehr nach einer IP-Adresse. Wenn es wieder danach fragt, bekommt es die gleiche IP-Adresse wie zuvor, aber nur dann, wenn die nicht inzwischen einem anderen Gerät gegeben worden ist. In so einem Fall bekommt das iPhone einfach eine andere IP-Adresse aus einem Pool freier IP-Adressen. Das sollte normalerweise nicht passieren, aber was ist, wenn das iPhone erst nach 28 Stunden danach fragt?


    Denn manchmal verlässt ein Gerät das Netz, weil sein Besitzer mit ihm in den Urlaub fährt oder weil er es nachts ausschaltet. Wenn sich das Gerät wieder "einbucht", stellt es fest, dass die lease abgelaufen ist, schickt seine MAC-Adresse ins Netz und nun passiert es: der DHCP-Server kennt die MAC-Adresse noch und gibt dem Gerät die gleiche IP-Adresse wie vorher oder aber der DHCP-Server hat die Adresse einem anderen Gerät vergeben. Und zack: das iPhone bekommt eine neue IP-Adresse.


    Eine neue IP-Adresse ist kein Beinbruch, aber für homebridge-people ist das ziemlich blöd.


    Der DHCP-Server läuft in unseren Home-Netzen auf dem Router. Man kann ihm dort sagen, dass er einer bestimmten MAC-Adresse immer eine bestimmte IP-Adresse zuweisen soll. Um sicherzugehen, dass ein Gerät wie ein iPhone immer die gleiche IP-Adresse hat, muss man dort die Verknüpfung MAC-Adresse <-> IP-Adresse vornehmen. Das bedeutet Arbeit.


    Daher finde ich die die Idee, statt nach der IP-Adresse nach der MAC-Adresse zu scannen, deutlich eleganter. Die MAC-Adresse ändert sich nämlich nie und sie ist gleichzeitig für jedes Gerät einzigartig.


    Ihr könnt übrigens mit dem Befehl arp -a auf eurem Raspi die MAC-Adressen in eurem Netzwerk scannen. Und noch was: zwei DHCP-Server sollten nie gleichzeitig in einem Netz laufen.


    Stefan