Beiträge von sschuste

    Das nehme ich an. Die Dauer wird wahrscheinlich 24 Stunden betragen, es sei denn, die betroffenen Geräte werden neu gestartet. Das ist bei den Shelleys natürlich nicht so einfach.


    Die Dauer, wie lange ein DHCP lease gültig ist, wird im DHCP-Server eingestellt, ist aber nicht rückwirkend machbar.

    Allerdings ist dann meine Frage, wie ich die Plugins aktualisiere? Muss ich dann jedes Mal nach dem Update von node/npm über n manuell erst die veralteten Plugins anzeigen lassen und dann jedes einzeln aktualisieren?

    Nein. Es könnte theoretisch sein, dass wir das machen müssen, wenn es von Node 16 auf Node 18 geht, aber sonst musst du das nicht. Ich rechne auch nicht wirklich damit, dass es beim Wechsel auf Node 18 (in zehn Monaten!) nötig ist.


    Ich mach einfach nur das Node-Update, starte die Homebridge und homebridge-config-ui-x neu und falle danach wieder in meinen normalen Schlummermodus.

    Wie aktualisierst du in deiner Routine die Plugins, oder nutzt du die grafische Oberfläche im Browser? Ich bin eigentlich über alles froh, was ich gleich im Terminal mit erledigen kann.

    Die gesamte Plugin-Verwaltung mache ich nur noch über homebridge-config-ui-x, das ist einfaches Click & Go. Ich bin auch ein großer Fan vom Terminal, aber im Browser geht das Updaten der Homebridge und der Plugins doch deutlich bequemer. Die Oberfläche macht dabei nichts anderes als du im Terminal.

    Edit: Ggf. kann ich mir die letzte Frage selbst beantworten: Wenn ich npm-check nutze, dann sollte ich damit doch auch die Homebridge Plugins aktualisieren können (und npm einfach auslassen, da man damit ja auswählen kann, was aktualisiert werden soll und was nicht), richtig?

    Ich weiß es nicht genau, aber ich nehme an, das npm-check letztendlich auch wieder nur npm aufruft.

    Hallo zusammen , ich habe das Plugin auch mal implementiert. In der HomeApp wird mir ein Schalter angezeigt, dieser reagiert jedoch nicht wenn ich ihn betätige.

    Was soll er denn machen, wenn du ihn betätigst?


    Beim Einschalten:

    [ ] Irgendwas drucken.

    [ ] Seine LEDs blinken lassen.

    [ ] Bei Amazon irgendwas nachbestellen.

    [ ] Irgendwas anderes.


    Beim Ausschalten:

    [ ] Irgendwas nicht mehr drucken.

    [ ] Selbstzerstörung auslösen.

    [ ] Bei Amazon irgendwas nachbestellen.

    [ ] Irgendwas anderes.


    Wenn ich das Plugin richtig begreife, dann zeigt der Schalter nur an, ob der Drucker eingeschaltet ist oder nicht.

    Naja aber der S5 Chip ist schon recht schwach. Auf extremes Stromsparen wie bei der Uhr muss ja nicht geachtet werden. Das Produkt Homepod Mini soll ja auch bestmöglich viele Jahre halten. Ich hätte da lieber einen A11 Chip oder so gesehen, gerne auch undervolted oder einstellbar. Je nachdem wie viel Verzögerung man in kauf nehmen kann. Aber das neue Apple TV hat ja auch nur den alten A12 Chip bekommen. Leider spart Apple teilweise bei der grandiosen Hardware und manchmal wie im iPad Pro wird dann der M1 einfach so eingebaut.... Naja muss man wohl leider abwarten

    Ich glaube, das der Chip schnell genug ist. Das bisschen HomeKit macht der locker nebenbei, wenn er gerade MP3 streamt und dekomprimiert - und das ist deutlich prozessorlastiger.


    Nee, ich glaube, dass es an einer völlig verkorksten Programmierung liegt. Vor iOS 15 hat das gut genug funktioniert. Jetzt heißt es oft "tut mir leid, irgendwas klappt gerade nicht" oder "irgendwas ist gerade langsam", aber auch nicht immer. Ein Kurzbefehl wird mit iPhone-Siri immer sofort ausgeführt, aber HomePod-Siri kann's oftmals nicht. Für mich heißt das, dass nicht der Kurzbefehl selbst das Problem darstellt, sondern das Aufrufen des Kurzbefehls.


    "Tut mir leid, irgendwas klappt gerade nicht" wird dazu führen, dass hier bald irgendwas aus dem Fenster fliegt. Eine solche Fehlermeldung hat ja schon microsoftsche Qualitäten. Irgendwas funktioniert nicht und Apple ist nun aufgerufen, irgendwas zu reparieren. Und so scheint die HomePod/HomeKit/Siri-Abteilung bei Apple auch zu arbeiten. Die machen da ein Ticket auf mit dem Bug-Report "irgendwas geht nicht" und das wird dann mit der Lösung "irgendwas gefixt" abgearbeitet.


    Vermutlich habe ich etwas übersehen: Wie kann man denn erkennen, wer gerade die aktive Zentrale ist?

    In der Home-App oben links das Haus antippen, dann Einstellungen des Zuhauses, danach Steuerzentralen & Bridges.

    Ein sudo apt-get install -y mosquitto mosquitto-clients reicht schon. Das startet den Broker sogar gleich mit und enabled ihn im systemd (toller Satz).


    Der Broker kann dann nach der Installation gleich genutzt werden, wenn man auf sicherheitsrelevante Features wie User und Passwort oder Verschlüsselung verzichtet. Ich betreibe meinen mosquitto von jeglicher Sicherheit befreit im Bequemlichkeitsmodus ohne Passwort, aber das kann sich ja jeder zusammenkonfigurieren, wie er mag.

    Falls die nicht übereinstimmte, habe ich das Update so durchgeführt

    So kann man das machen. Warum auch nicht, wenn man auf den totalen Umstand steht. Es gibt aber deutlich einfachere Möglichkeiten.


    Ich empfehle die Verwendung von n. Nach einer Installation von Node kann das installiert werden mit dem Befehl sudo npm install -g --unsafe-perm n. Danach ruft man's mit dem leicht zu merkenden Befehl sudo n auf.


    Damit kann man dann folgendes machen:

    • sudo n ruft n in einer interaktiven Shell auf. Hier kann man alle installierten Node-Versionen sehen und zwischen ihnen wechseln
    • sudo n lts installiert die LTS-Version
    • sudo n 14.13.12installiert die Version 14.13.12
    • n --help zeigt an, was noch so geht.

    Ich benutze n seit langem ohne jede Probleme für alle Node-Updates.


    Auch ganz nett ist npm-check, das mit dem Befehl sudo npm-check -gu eine interaktive Shell zur Node-Modules-Pflege anbietet, sozusagen sudo npm outdated -g in Schön. Allerdings bin ich damit sehr vorsichtig und mache damit eigentlich nur Updates von Node Red, aber nie von Plugin-Bestandteilen (Angst essen Seele auf). Wenn ich das Zeugs nicht kenne und zweifelsfrei zuordnen kann, dann lasse ich die Finger von Updates.


    Installieren mitsudo npm install -g --unsafe-perm npm-check.


    Um den Node-Installer npm kümmere ich mich gar nicht, außer er fängt an, Mist zu bauen, weil er zu alt ist. Ich benutze einfach immer das npm, das die Node-Installation mitliefert. Oft genug habe ich npm auch gar nicht updaten können und dann heißt es bei mir nach kurzer Zeit: "mir doch egal".


    pm2 habe ich noch nie benutzt.

    Hat jemand irgendeine Idee, was hier falsch laufen könnte? Wie kann ich Node/npm/Homebridge sicher aktualisieren; oder liegt der Fehler woanders?

    Ich weiß es nicht. Wie gesagt, mache ich keine Updates von npm mehr und halte npm auch nicht für so superwichtig. Ist für mich halt nur ein Installer, der mit dem normalen Betrieb der Node-Programme nichts zu tun hat.

    Die Homebridge läuft auf einem Raspi. Gibt es dort irgendwo eine Tabelle, wo die IP-Adressen noch mal gespeichert sind, welche aus welchen Gründen auch immer eine fehlerhafte Zuweisung bekommen hat?

    Jein. Es gibt in Homebridge einen Cache, der möglicherweise falsche Adressen enthält. Siehe in homebridge-config-ui-x, oben rechts: 3-Punkte-Menü, dann Homebridge-Einstellungen, dann ganz unten Verwalten von Geräten im Cache.


    Die Adressen, die dem Raspi selbst bekannt sind, listet der Befehl arp -n auf.

    Mit anderen Worten - die FRITZ!Box stellt Geräte mit IP und MAC-Adressen zur Verfügung, der Raspi erkennt davon aber nicht alle. Hmm. Wie kann denn das nun wieder sein?

    Wenn die Shellys die Fritzbox nicht kontaktieren, dann passiert das. Es könnte glatt sein, dass sie sich ihre Adressen von einem anderen DHCP-Server holen - das fällt mir dazu als erstes ein, auch wenn ich für unwahrscheinlich halte.

    Man könnte aber die Festplatte ersetzen und gleich eine grössere einbauen. Ich weiss, ist ein gebastel...

    Das ist was für die Bastelprofis, die auch das passende Werkzeug haben. Auf jeden Fall ist das nix für mich Grobmotoriker. Ansonsten hätte ich in meine TimeCapsule längst eine neue Platte eingebaut. Siehe https://de.ifixit.com/Anleitun…estplattenaustausch/61924


    Alternativ könnte man eine externe Festplatte per USB an die TimeCapsule anschließen und diese für das Backup verwenden (hab ich nie gemacht, schätze aber, dass das geht). Das ist natürlich USB2 und somit langsam, aber würde für das Backup wahrscheinlich völlig ausreichen.

    Oder soll ich mehr Geld in die Finger nehmen und ein kleines NAS kaufen? Ist die Time Capsule noch zeitgemäss? Kann ich auch eine alte Generation Time Capsule nehmen für nur das Backup? Was meint ihr?

    Diese Frage kommt mir gerade recht. ich stehe vor einem ähnlichen Problem. Und ich würde auf keinen Fall eine Time Capsule nehmen, weil:


    https://www.golem.de/news/appl…-capsule-2107-157991.html


    Ich schätze, du wirst um das NAS nicht herumkommen (und ich auch nicht). Ich bekomme nur nirgendwo brauchbare Infos. Die einzige Frage, die ich nämlich habe ist: wie laut sind die Dinger?

    Das brachte dann auch schon spürbar was. Die Temperatur sank nach kurzer Zeit auf 60 Grad und die Last ging runter auf 35%. Seitdem sind die ganze Aissetuer zumindest nicht mehr aufgetreten. Könnt ihr solche "Phänomene" bestätigen und können diese tatsächlich mit der Auslastung bzw. der Prozessortemperatur zu tun haben?!

    Das kann sein. Über 70º ist viel zu heiß und führt zu einem thermal throtteling - das heißt, der Raspi wird runtergetaktet. Das zeigt der Raspi auf einem an ihn angeschlossenen Monitor sogar an, nur wer da einen Monitor dran? Ich hatte dieses Problem mit meinem Raspi 4, dessen Temperatur ich dann mit einem passiven Kühlgehäuse um mehr als 20º senken konnte.


    Tatsächlich hilft es auch, das Gehäuse oben offen zu lassen. aber das spezielle Gehäuse hat dann noch mehr gebracht. Das Originale-Plastikgehäuse eignet sich nicht für den Raspi 4 und sollte durch ein besseres Gehäuse ersetzt werden, beispielsweise sowas: https://www.amazon.de/Miuzei-Raspberry-Gehäuse-Netzteil-Aluminium/dp/B09CGY6B6Q/


    Mein Raspi ist lange mit 8-10% Auslastung gelaufen, obwohl auf dem Ding wirklich eine Menge Zeugs läuft. Inzwischen liegt die Auslastung bei 30-35% und zwar seit dem 8. Oktober 2021. Ich glaube, an dem Tag auch Homebridge 1.3.5 raus, aber ich führe die hohe Last auf meine Bastellösung zurück, mit der ich den Ausfall von homebridge-apple-tv-remote kompensiere. Die Temperatur schwankt zwischen 53 und 58º, aber er steht auch nicht an einem sonderlich gut belüfteten Ort.

    Will ich etwas schalten, verwende ich eine Automation und / oder Schalter und / oder einen Sprachassi. Alles muss für jeden im Haus ohne große Einweisung bedienbar sein.

    Das geht nicht immer. Ich habe hier Moving Heads, die brauchen ein ganzes Mischpult, um sie steuern zu können.

    ch wollte eigentlich nur wissen, ob die Hue Leuchtmittel auch als Repeapter dienen, wenn ich diese am Conbee Stick anlerne

    Zigbee-Lampen (also auch die Hue-Lampen) sind auch dann Repeater, auch wenn sie an keine Bridge angeschlossen sind. Wenn sie an keine Bridge angeschlossen sind, bekommen sie natürlich auch nichts gesendet und senden daher auch nichts weiter und verbrauchen völlig sinnfrei Strom.


    Nicht das Anlernen an eine Bridge macht die Lampe zum Repeater, sondern sie ist immer einer. Das Anlernen an die Bridge nimmt die Lampe in das Zigbee-Netz der Bridge auf. Die Lampe muss daher an eine Bridge angelernt werden. Dabei ist es egal, ob das eine Hue-Bridge oder eine Conbee-Bridge ist. Aber sie kann nur an eine Bridge zur gleichen Zeit angelernt werden. Entweder an die Hue-Bridge oder an die Conbee-Bridge. Beide gleichzeitig geht nicht.

    Oder dienen die Hue Lampen für den Conbee Stick bereits als Repeater obwohl die noch mit der Hue Bridge verbunden sind?

    Nein. Die Hue-Bridge baut ein Zigbee-Netz auf und die Conbee-Bridge baut ein Zigbee-Netz auf. Jede Bridge kennt die an sie angeschlossenen Geräte. Andere Geräte kennt sie nicht. Jedes Zigbee-Gerät kennt seine Bridge. Andere Bridges kennt es nicht (weil: kann ja nur an eine Bridge angelernt werden). Somit bauen zwei Zigbee-Bridges zwei unabhängige Zigbee-Netze auf, die nicht untereinander agieren können.