Beiträge von sschuste

    Der Raspi verwendet normalerweise keine statische IP-Adresse. Er sollte ganz normal einen DHCP-Server fragen, wenn er nach einem Neustart eine IP-Adresse benötigt. Normalerweise fragt der Raspi alle 24 Stunden nach der Adresse (zumindest wenn es der Kabelmodem-DHCPd so vorgegeben hat). Aber nach einem Neustart?


    Es gibt viele Möglichkeiten, dem Raspi eine statische IP-Adresse zu verschaffen. Ich habe meinem eine verpasst, und ich habe das in /etc/dhcpcd.conf gemacht. Dazu musste ich extra ein paar Zeilen anfügen:


    # A sample configuration for dhcpcd.

    # See dhcpcd.conf(5) for details.


    # Allow users of this group to interact with dhcpcd via the control socket.

    #controlgroup wheel


    # Inform the DHCP server of our hostname for DDNS.

    hostname


    # Use the hardware address of the interface for the Client ID.

    clientid

    # or

    # Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.

    # Some non-RFC compliant DHCP servers do not reply with this set.

    # In this case, comment out duid and enable clientid above.

    #duid


    # Persist interface configuration when dhcpcd exits.

    persistent


    # Rapid commit support.

    # Safe to enable by default because it requires the equivalent option set

    # on the server to actually work.

    option rapid_commit


    # A list of options to request from the DHCP server.

    option domain_name_servers, domain_name, domain_search, host_name

    option classless_static_routes

    # Respect the network MTU. This is applied to DHCP routes.

    option interface_mtu


    # Most distributions have NTP support.

    #option ntp_servers


    # A ServerID is required by RFC2131.

    require dhcp_server_identifier


    # Generate SLAAC address using the Hardware Address of the interface

    #slaac hwaddr

    # OR generate Stable Private IPv6 Addresses based from the DUID

    slaac private


    # Example static IP configuration:

    #interface eth0

    #static ip_address=192.168.0.10/24

    #static ip6_address=fd51:42f8:caae:d92e::ff/64

    #static routers=192.168.0.1

    #static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1


    # It is possible to fall back to a static IP if DHCP fails:

    # define static profile

    #profile static_eth0

    #static ip_address=192.168.1.23/24

    #static routers=192.168.1.1

    #static domain_name_servers=192.168.1.1


    # fallback to static profile on eth0

    #interface eth0

    #fallback static_eth0

    interface wlan0

    static ip_address=192.168.1.22/24

    static routers=192.168.1.1

    static domain_name_servers=192.168.1.22


    Die letzten vier Zeilen sollten in deiner dhcpcd.conf fehlen.


    https://www.elektronik-kompend…/raspberry-pi/1912151.htm beschreibt, wie man auf welche Arten eine statische Adresse setzen kann. Möglicherweise kannst du diese Anleitung gebrachen, wenn du eine statische Adresse entfernen willst.


    Und wichtig: du solltest nur einen einzigen DHCP-Server in deinem Netzwerk betreiben. Schalt den auf dem Kabelmodem zur Not aus.

    Ich frag mich ständig wann genau ich die Taste an der Hue Bridge drücken soll....hab da gefühlt schon alles probiert.

    Wenn's im Log steht. Deine config.json weist keinen User-Eintrag auf - vielleicht muss da erstmal einer hin. Das Plugin versucht sich beim ersten Mal irgendwie an der Bridge anzumelden. Dazu nimmt es irgendeinen User und irgendein Passwort, sowas wie:

    Code
               "users": {
                    "karlheinz": "knacknwuppdich"
                }

    Die Anleitung von homebridge-hue schreibt sogar zwei User dahin. So hab ich übrigens angefangen: ich hab das erst einfach mal kopiert, in meine config.json eingesetzt und dann die Homebridge neu gestartet.

    Code
    "platforms": [
        {
          "platform": "Hue",
          "users": {
            "001788FFFExxxxxx": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
            "001788FFFEyyyyyy": "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
          },
          "lights": true
        }
      ]

    Auf keinen Fall wird sich das Plugin mit solchen Konfigurationen an der Hue-Bridge anmelden können, da die Hue-Bridge keinen dieser User kennt. Die Hue-Bridge schickt daher eine Fehlermeldung an homebridge-hue zurück. Also versucht das Plugin auf der Hue-Bridge einen User anzulegen. Dazu schickt es einen newuser-Request an die Hue-Bridge, den die Bridge aber nur dann ausführt, wenn du innerhalb der nächsten Sekunden den Link-Button drückst.


    Aus diesem Grund stoppt das Plugin den Start der Homebridge und wartet nun. Sobald der Button gedrückt ist, rückt die Hue-Bridge gültige Anmeldedaten an das Plugin heraus. Im Log steht dann der zu verwendende User und das zu verwendende Passwort. Die müssen dann in deine config.json eingetragen werden und die Homebridge neu gestartet werden.


    Sieht dann bei mir so aus:

    Code
           {
                "platform": "Hue",
                "host": "192.168.1.23",
                "lights": true,
                "users": {
                    "001788FFFE221980": "woDuc1QYLBBlfUGji453lKCpN11-39rUK0dhloVk"
                }
            },

    Danach kannst du dann anfangen, die Feinabstimmung zu machen und deiner homebridge-hue-Konfiguration das hinzuzufügen, was du brauchst.

    Die Warnungen bezüglich der Node-Version habe ich auch und sie spielen keine Rolle.


    Mich irritiert eher die fette Zeile:


    Nov 04 17:38:06 raspberrypi homebridge[1790]: [04/11/2020, 17:38:06] [Hue] npm registry: TypeError [ERR_INVALID_ARG_TYPE]: The "listener" argument must be of type function. Received an instance of Object
    Nov 04 17:38:06 raspberrypi homebridge[1790]: at checkListener (events.js:111:11)
    Nov 04 17:38:06 raspberrypi homebridge[1790]: at ClientRequest.once (events.js:435:3)
    Nov 04 17:38:06 raspberrypi homebridge[1790]: at new ClientRequest (_http_client.js:202:10)
    Nov 04 17:38:06 raspberrypi homebridge[1790]: at Object.request (https.js:313:10)
    Nov 04 17:38:06 raspberrypi homebridge[1790]: at Object.request (/usr/local/lib/node_modules/homebridge-fritz-platform/node_modules/http-proxy-agent/node_modules/agent-base/patch-core.js:25:22)


    Mich wundert, dass da irgendwie die homebridge-fritz-platform involviert ist. Lösungsvorschläge: keine (außer die temporär rauswerfen). Verstehe ich nicht.

    Entweder direkt in Homekit oder wenigstens über Hue in Homekit.

    Die Hue-Bridge überträgt alle Lampen und Sensoren an HomeKit, solange Hue oder Friends of Hue draufsteht. Alles andere taucht in HomeKit nicht auf.


    Ich verwende auch bevorzugt Hue, aber an einigen Stellen geht es leider nicht. Dazu müsste ich Leuchten auf den Müll werfen, an denen mein Herz hängt, und das findet nicht statt. Eine besteht beispielsweise aus 20 Glühbirnen à 15W. Diese 20 Birnen würde ich im Leben nicht durch 20 Hue-Birnen ersetzen. Für eine andere Leuchte gibt's von Philips keine Lampen. Da bleibt nichts anderes übrig, als anderer Leute Zigbee an die Hue-Bridge zu hängen und dann kommt man um eine zweite Bridge, also eine Homebridge, nicht herum.


    Natürlich bleibt das jedem selbst überlassen, wieviele Bridges er betrieben will. Aber auch ich bin der Meinung: je weniger Bridges oder Gateway, desto besser.

    1. Auf der suche nach passenden Gehäusen habe gelesen, dass Leute bei Aluminium Gehäusen von Reichweitenproblemen bzgl. Bluetooth und Wlan geschrieben haben. Kann das hier jemand bestätigen?

    Ich nicht.

    2. Mit aktiven Lüfter oder nicht?

    Ich halte "ohne Lüfter" immer für besser als "mit Lüfter". Eine passive Lösung mittels eines brauchbaren Gehäuse ist völlig ausreichend, beispielsweise https://www.amazon.de/gp/produ…DZR6/?tag=hktips-forum-21

    3. Welchen Stick um die Zigbee Geräte einzubinden?

    Keine Ahnung, ich habe nur Hue-Zigbee mit Hue-Bridge.

    Licht an/aus dimmen usw. Da dachte ich an Phillips Hue. Da muss ich nur noch Lampen finden die meiner Frau gefallen.

    Hue ist teuer, aber gut. Ich verwende das Zeugs selber und kann's nur empfehlen.


    Du kannst die Hue-Lampen ja in bestehende Leuchten reinschrauben. Allerdings habe ich mit den Lightstrips gute Erfahrung als indirekte Beleuchtung gemacht. Und in der Küche habe ich sie einfach unter die Oberschränke geklebt - perfektes Licht für die Arbeitsplatte.

    Und genau das geht nicht ...

    Ok. Ich dachte, es sei ein Versehen gewesen, aber vielleicht sollte ich erstmal präziser lesen lernen. Du willst es so. Warum auch immer.


    Ich kann da nur noch mutmaßen, aber vielleicht hast du recht mit deiner Annahme, da auch noch die Parameter


    "sensors": true,

    "lights": true


    zu setzen.

    "nativeHomeKitLights" : false,

    "nativeHomeKitSensors" : false,

    Dieses Setting sagt aus, dass du die Hue-Lampen und -Sensoren über Homebridge verwalten willst. Bei mir stehen diese Einträge auf true, weil ich nicht will, dass die Lampen und Sensoren über die Homebridge kommen, sondern nur von der Hue-Bridge.

    Welchen Port nehme ich da am besten? Oder kann ich mir da eine Nummer ausdenken ?

    Ja, eine zwischen 1024 und 65535 und sie darf nicht schon verwendet werden, beispielsweise 8888.


    So sieht meine Hue-Konfiguration aus:

    Code
     {
                "platform": "Hue",
                "host": "192.168.1.23",
                "lights": true,
                "users": {
                    "001788FFFA12345": "woxYx1QYLP1xYxGji123fKyXy10-35KLK3mblgRy"
                }
            },

    Die IP-Adresse, die man da sieht, ist die von meiner Hue-Bridge.

    Wenn ich das richtig verstanden habe funken die Geräte über wlan,bluetooth oder zigbee. Brauche ich an dem Pi dann drei Sticks?

    Nein, nein, ja.


    WLAN und Bluetooth sind im Raspi eingebaut, wobei die Bluetooth-Unterstützung nicht dolle ist. Ich habe es nur mit Aufwand hinbekommen, mit dem Raspi über Bluetooth Werte meiner Pflanzensensoren auszulesen, wobei das auch nicht immer funktioniert.


    Prinzipiell brauch man immer eine Bridge, um zwischen Zigbee und HomeKit zu übersetzen. Ich betreibe beispielsweise eine Hue-Bridge, die dann die Zigbee-basierten Hue-Lampen ansteuert oder Zigbee-basierte Hue-Sensoren ausliest und das alles für HomeKit aufbereitet. Wenn ich weitere Lampen oder Sensoren oder Schalter kaufe, kaufe ich die bei Philips oder deren Freunden, aber das mach ich halt so und das soll keine Empfehlung sein.


    Ich kann nichts zu den Zigbee-Erweiterungen für den Raspi sagen. Ich benötige sie nicht mit meinem Philips-Universum. Aber sie sind eben auch eine Bridge, so wie die Hue-Bridge oder das Trådfri-Gateway von IKEA oder der Aquara-Hub.


    Grundsätzlich ist nichts gegen einen Zoo von Hubs zu sagen, außer dass die halt alle Strom brauchen. Daher konsolidieren viele ihre Bridges auf eine Zigbee-Erweiterungen für den Raspi. Das hat auch Nachteile: man kann über diese Erweiterungen nicht an die Updates für die Lampen oder Sensoren kommen, das unterstützen nur die originalen Bridges.

    Die Liste kann ich schnell mal abarbeiten: kenne ich nicht, kenne ich nicht, kenne ich nicht, kenne ich nicht, kenne ich nicht, kenne ich nicht, kenne ich nicht. Da du schon den Aqara-Hub hast, lautet meine Empfehlung: bleib dabei.

    Gibt es unter den erfahrenen Nutzern eine Tendenz richtig Pod oder TV?

    Eigentlich nicht. Meine Musik kommt aus einer Sonos-Anlage, da war mir der HomePod zu viel. Aber der HomePod-Mini wird in Zukunft meine Alexa ersetzen (die habe ich nämlich so satt, das kann ich gar nicht beschreiben). Meine Steuerzentrale ist zur Zeit ein ATV, dass ich ohnehin benötige. Ich habe nirgendwo gelesen, dass der ATV dem HomePod überlegen wäre oder andersherum. Nur vom iPad als Steuerzentrale hört man immer wieder von Problemchen.


    Der HomePod würde dir natürlich die Möglichkeiten geben, das Smartzeugs bequem per Sprache zu steuern.

    Uiuiui. Sich erinnern? Ich glaube es war "sudo cat /var/log/syslog" oder "sudo cat /var/log/homebridge.log".

    Ja, sowas war's bestimmt. Du kannst die Ausgabe solcher Befehle einschränken, indem du sie nicht sofort auf den Bildschirm ausgibst (lach, ein geiler Satz, aber so was von richtig!). Also:


    Der Befehl cat zeigt den Inhalt einer Datei auf dem Bildschirm an. Du gibst ihn ein, fügst einen Dateinamen hinzu, drückst die Entertaste und schwups! steht der Sermon vor deinen erstaunten Augen. Sowas wie

    cat /var/log/syslog


    Du könntest aber die Ausgabe, die cat erzeugt, auch erstmal an ein anderes Programm umleiten, das dann mit den Daten erst irgendwas anstellt und das danach eine Ausgabe auf dem Bildschirm erzeugt. Um nur die Daten, die zur Homebridge gehören, anzuzeigen, bietet sich das Programm grep an. Um die Daten, die cat erzeugt, an grep umzuleiten, braucht man eine Pipe, und das ist ein vertikaler gerader Strich: |. Den erzeugt man auf einer Mac-Tastatur mit Option-7.


    Dann braucht man noch einen Suchbegriff. Da in (fast) jeder Zeile eines Homebridge-Logs der Begriff homebridge vorkommt, bietet der sich als Suchbegriff an. Also grep "homebridge". Das führt unweigerlich zu:

    cat /var/log/syslog | grep "homebridge"


    Jetzt werden nur noch Zeilen angezeigt, in denen der Begriff homebridge auftaucht. Nicht aber die Zeilen, in denen beispielsweise Homebridge oder hOmEbRiDgE steht. Wenn man die auch haben will, lautet der Befehl:

    cat /var/log/syslog | grep -i "homebridge"


    Wenn man alle Zeilen haben will, in denen der Begriff homebridge nicht vorkommt, dann heißt es:

    cat /var/log/syslog | grep -v "homebridge" und wenn gleichzeitig nicht auf Groß- und Kleinschreibung geachtet werden soll:

    cat /var/log/syslog | grep -vi "homebridge"


    Na schön. Wahrscheinlich ist es aber am einfachsten, es völlig anders zu machen, nämlich mit dem Befehl zum Anzeigen des Homebridge-Logs: sudo journalctl -au homebridge.

    aber nicht in Zusammenhang mit Personen im gleichen Haushalt!

    Jetzt hab ich's kapiert: Wird ein anderer Standort als "Wohnung" gewählt, werden andere Personen von dieser Automation entfernt. Ist ja saublöd gemacht. In meinem Haushalt befindet sich nur eine einzige Person und daher kenne diese HomeKit-Gemeinheiten nicht. Das bedeutet auch, dass ich keine Lösung weiß.

    Dein Fehler kommt daher, dass der User, unter dem die Homebridge läuft (weiß, nicht wer das bei dir ist), weder Rechte hat

    1. journalctl so aufzurufen noch
    2. journalctl mit sudo aufzurufen

    Eins der beiden Rechte muss erlaubt sein. Im ersten Fall könnte es wie beim Raspi reichen, den User, unter der die Homebridge läuft, der Gruppe systemd-journal hinzuzufügen, nur weiß ich nicht, ob es eine solche Gruppe bei deinem Debian überhaupt gibt. Im zweiten Fall muss diesem User in /etc/sudoers erlaubt werden, den Befehl journalctl als root auszuführen.


    Entweder das eine oder das andere. Ich kann dir keine genaue Vorgehensweise nennen, weil ich nicht weiß, wie weit sich Raspian von deinem Debian unterscheidet und weil ich nicht weiß, unter welchem User deine Homebridge läuft. Wenn du es auch nicht weißt, dann kannst du es mit

    ps aux | grep homebridge herausfinden.


    ps aux | grep homebridge

    homebri+ 22895 2.9 4.8 309168 188352 ? Sl Oct27 63:26 homebridge


    Links steht der User.

    Wie meinen?

    Aua :D Die gute Rechtschreibprüfung gepaart mit meinen Schreibkünsten. Ich wollte fragen:

    Kannst du mal den Befehl nennen, den du verwendest, um das Logfile anzuzeigen?

    Jep sklavisch nach der Forenanleitung hier.

    Ein guter Hinweis, denn jetzt wird der Fehler schon klarer:

    "cacheDir": "/var/lib/homebridge/logic"

    Das ist falsch. Es muss heißen:

    "cacheDir": "/var/homebridge/logic"


    Dann sollte es funktionieren. Alle CacheDirs von Plugins liegen in /var/homebridge, denn da darf die Homebridge hinschreiben. Falls Plugin-Entwickler etwas anderes behauptet, dann hör nicht drauf.