Und wenn du dich ununterbrochen 60 Sekunden im Bad bewegst, bleibt das Licht an?
Ja. Auch wenn ich da 30 Sekunden bewegungslos stehe und mich dann wieder bewege.
Und wenn du dich ununterbrochen 60 Sekunden im Bad bewegst, bleibt das Licht an?
Ja. Auch wenn ich da 30 Sekunden bewegungslos stehe und mich dann wieder bewege.
Die neuen Log-Files werden aber auch ziemlich schnell groß, ich habe auch einige Geräte (Fritz! und Shelly) eingebunden. Kann ich irgendwo den Log-Level senken, damit die Files nicht so schnell so groß werden?
Linux-Betriebssysteme bieten oft einen Mechanismus an, der Logfiles automatisch nach einer bestimmten Zeit oder bei einer bestimmten Größe automatisch komprimiert und nach einer Weile löscht. Dieser Mechanismus heißt logrotate.
Dabei handelt es sich um ein Programm, das man auf ein oder mehrere Logs ansetzen kann und das je nach Konfiguration entweder
Beispielsweise wird dabei wird das Log /var/log/homebridge.log in /var/log/homebridge.log.1 umbenannt. Danach wird es mit gzip komprimiert und heißt dann /var/log/homebridge.log.1.gz. Gleichzeitig wird ein neues, leeres /var/log/homebridge.log angelegt, damit die Homebridge weiter loggen kann.
Ist der Augenblick gekommen, dass das Log erneut zu groß oder zu alt wird, wird /var/log/homebridge.log.1.gz in /var/log/homebridge.log.2.gz umbenannt und danach passiert dann das gleiche wie im vorherigen Absatz beschrieben.
Gleichzeitig werden diese komprimierten Logs aufbewahrt, entweder
Danach werden sie gelöscht. Ein Blick mit ls -l /var/log zeigt solche komprimierten Logs an. Konfiguriert wird das in /etc/logrotate.d.
sudo nano /etc/logrotate.d/homebridge
Ein leerer Editor wird angezeigt. Dort hineinschreiben:
/var/log/homebridge.log
/var/log/homebridge.err
{
rotate 7
daily
compress
size 100M
nocreate
missingok
postrotate
/usr/bin/killall -HUP homebridge
endscript
}
Alles anzeigen
Das sollte (und ich habe es nicht ausprobiert) die beiden Logs täglich rotieren, sieben komprimierte Dateien aufheben und dann löschen. Sollte eine Größe von 100 MB erreicht werden, bevor 24 Stunden vergangen sind, dann werden die Logs halt schon früher als daily rotiert.
Abspeichern und das war es auch schon. Der Befehl logrotate -d /etc/logrotate.d/homebridge zeigt an, was passieren würde, wenn das Betriebssystem ihn automatisch ausführt.
Stefan
Ich bin so vorgegangen: ich hab das Teil gekauft, ausgepackt, aufgestellt und mit der Hue-App eingerichtet. Danach habe ich nichts weiter getan. Über irgendeine Zehn-Sekunden-Duration habe ich nicht nachgedacht, weil ich nichts davon wusste.
Ich geh ins Bad und das Licht geht an. Und bleibt an, solange ich mich bewege. Es kommt vor, dass ich bewegungslos vor dem Spiegel stehe, um mich verzückt darin zu bewundern, dann dimmt der Lightstrip 30 Sekunden, bevor er ganz ausgeht, herunter und ich muss mit der Hand herumwedeln. Dann geht das Licht sofort wieder auf 100 Prozent.
Ich verstehe das mit den zehn Sekunden nicht. Wenn ich ins Bad gehe, soll der Sensor auslösen. Wenn ich mich dort bewege und der Sensor löst erneut aus, kann mir das doch völlig wurscht sein. Das Licht bleibt an, und das ist doch das, was ich will. Wie und wann der Sensor Bewegung erkennt, kann man live verfolgen, wenn man in der Hue-App unter Einstellungen - Zubehör einrichten - Badsensor - Bewegungsempfindlichkeit aufruft und dort zusieht. Bewege ich mich, steht dort "Bewegung erkannt". Bewege ich mich nicht, steht dort "keine Bewegung". Und diese Statusänderung passiert sofort.
Da steht, dass du im obersten Verzeichnis des Raspis ein Verzeichnis anlegen willst und dass das verboten ist (/.node-persist). Also musst du das Verzeichnis dort anlegen, wo es erlaubt ist. Und das ist abhängig davon, wie du deine Homebridge installiert hast. Vielleicht könntest du dich dazu noch äußern, dann biegen wir das schon hin.
Im obersten Verzeichnis legt man genau dann ein Verzeichnis an, wenn... ähm, also, wenn... uh... genau: eigentlich gar nicht.
allerdings werden mir keinerleih geräte angezeigt die in der huebridge installiert sind wie zb. die osram steckdosen....
Hab keine Osram-Steckdosen.
"nativeHomeKitLights": true,
Was passiert, wenn das auf false steht?
Der Bewegungsmelder löst brav aus, sobald ich den Raum betrete und dann geht auch zügig das Licht an, aber wenn ich in der Küche arbeite geht das Licht irgendwann (zwischen 1:30 Minuten und 4:00 Minuten) einfach aus - egal wie aktiv ich in der Küche bin. Ich muss dann für etwa eine halbe Minute rausgehen und den Raum erneut betreten, damit das Licht wieder angeht. Manchmal bleibt es auch länger an, aber es passiert immer wieder, dass das oben beschrieben passiert.
Ich habe ein ähnliches Setup: ein Hue Motion-Melder, der einen Hue Lightstrip einschaltet. Ich habe den Motion-Sensor so eingestellt, dass er nach drei Minuten den Lightstrip wieder ausschalten soll. Das funktioniert ganz hervorragend, der Strip geht nicht wieder aus, solange ich in der Küche wirke.
Die gleiche Konstruktion habe ich im Badezimmer, aber dort wird der Lightstrip nach einer Minute ausgeschaltet, wenn keine Bewegung entdeckt wird. Das funktioniert ebenfalls - sogar beim Duschen, das Licht bleibt an. Ich habe in beiden Fällen ein bisschen herumfummeln müssen, bis der Sensor möglichst viel vom Raum abgedeckt hat.
Schätze schon. Probier's aus.
alle anderen Sachen sind davon ja unangetastet oder ?
Das würde ich erwarten.
hatte ich doch bereits mehrfach erwähnt, das es auf einem normalen debian server installiert ist.
Sorry, für mich ist ein Raspi auch ein normaler Debian-Server.
Entweder wird die Homebridge per systemd gestartet oder per init. Beides ist ein Mechanismus des Betriebssystems, um einen Service zu starten oder zu stoppen. Dieser Mechanismus wird auch genutzt, um einen Service beim Booten zu starten. Der systemd ist die moderne Variante, init ist die alte. Ich weiß nicht welche du nutzt.
Versuchen wir also, einfach beide abzustellen. Da ich nicht weiß, wie dein System aufgesetzt ist, schieße ich hier mal so ins Blaue.
systemd:
sudo systemctl stop homebridge
sudo systemctl disable homebridge
Vielleicht kommen da Fehlermeldungen, vielleicht nicht.
init:
sudo /etc/init.d/homebridge stop
sudo rm /etc/rc3.d/*homebridge
Auch hier: entweder gibt's Fehlermeldungen oder nicht.
Möglicherweise läuft danach die Homebridge nicht mehr und wird auch nicht mehr beim Booten gestartet.
Stefan
Du hast ja immer noch nicht verraten wo HB derzeit bei dir läuft!
pillemats: genau das ist die Frage. Wie sieht dein Setup aus, und nach welcher Anleitung hast du es aufgesetzt?
Fazit: ich bleibe bei Homebridge! Native HomeKit Geräte gibt es zu wenig/zu teuer.
So sieht es aus. Aber ob es nun Homebridge ist oder Home Automation oder FHEM oder OpenHAB, spielt keine so große Rolle. Viel interessanter ist die Tatsache, dass die Opensource-Gemeinde das möglich macht, was die Hersteller nicht hinbekommen oder nicht hinbekommen wollen oder nicht hinbekommen können - Kompatibilität.
Der Smarthome-Markt wächst und diejenigen, die über ein simples "geil! ich kann die Lampe auf meiner Toilette mit dem Handy einschalten!" hinaus wollen, kommen zur Zeit um Opensource-Lösungen gar nicht herum. Die Community scheint inzwischen so groß geworden zu sein, dass die Key-Player Apple, Google und Amazon darauf mit ihrer Allianz reagieren.
Es ist überhaupt bemerkenswert, dass Apple die Homebridge überhaupt zugelassen hat. Erst machen die ein riesiges Bohei mit Zertifizierungen und Security-Chips, lassen dann aber zu, dass man auch eine nicht zertifizierte Bridge ansteuern kann. Jeder Homebridge-Nutzer hat es selber gesehen: beim Verbinden von HomeKit und Homebridge wird eine Warnung angezeigt, dass die Homebridge nicht zertifiziert sei - an der Stelle hätte Apple es auch so programmieren können, dass eine Verbindung unmöglich gemacht wird. Haben sie aber nicht gemacht! Und ich bin mir sicher, dass es an diesem Punkt Diskussionen bei Apple darüber gegeben hat und dass dann die Entscheidung getroffen wurde: nein, das programmieren wir lieber so, dass es geht. Denn ob da nun einer programmiert, dass es eine Warnung gibt oder eine Ablehnung, ist wirklich kein großer Unterschied beim Coden.
Sie haben auch nie ein Veto gegen das Re-Engineering des HomeKit Accessory Protocols (HAP) eingelegt - ihre Anwälte sind schön in ihren Käfigen geblieben. Es würde mich nicht mal wundern, wenn sie dabei sogar ihre Finger dringehabt hätten.
Tja. Warum haben die das gemacht? Warum preschen sie jetzt vor und legen das HAP offen? Entweder, weil sie die Opensource-Gemeinde brauchen, um gegen Google und Amazon anstinken zu können. Oder aber, weil sie es los werden wollen, aber Millionen von smarten HomeKit-Geräten nicht einfach die Unterstützung entziehen können. Warten wir es ab.
Stefan
da ich HB unter debian installiert habe liegt mein ordner hier /root/.homebridge
Das ist der Ordner, der die config.json enthält. Du scheinst deine Homebridge als User root zu starten.
[2019-12-22 1:53:02 PM] [Hue] masked debug info dumped to /root/.homebridge/homebridge-hue.json.gz
Dort schreibt auch homebridge-hue hinein. Und dort liegt auch der Cache:
/root/.homebridge/persist und
/root/.homebridge/accessories
Wenn du irgendwas löschen willst, dann da.
Stefan
Du must den Usernamen in config.json verändern, wenn du die Bridge erneut hinzufügen willst. Achtung: das kostet dich alle Automationen, die auf Homebridge-Geräten basieren.
{
"bridge": {
"name": "Homebridge",
"username": "CC:22:3D:E3:CE:30",
"port": 51826,
"pin": "031-45-128"
},
"description": "Home Smart Home",
"platforms": [
{
Ändere beispielsweise den Usernamen von "CC:22:3D:E3:CE:30" auf "CC:22:3D:E3:CE:31".
Nach der gefühlten 5. Installation der Homebridge
Jetzt bist du ein Experte
(ich wurde auf dem gleichen Wege einer)
Nun möchte ich den Shelly-Dimmer einbauen. Das klappt aber nicht so wie ich mir das gedacht habe.
So, wie du das hier schreibst, hört es sich so an, als hättest du Probleme bei der Wandmontage. Vielleicht könntest du das Problem etwas genauer beschreiben?
Was kann das X Plus mehr? ... Sonst noch was?
Ich habe mir für dich mal die Anleitung des Plugins durchgelesen. Ich kann dort nichts entdecken, das darauf hinweist, was das Plugin überhaupt kann, geschweige denn besser kann.
Ich muss gestehen, dass ich bislang darauf verzichtet habe, beide Plugins zu installieren und dann per diff -qr eine erste Sourcecode-Analyse durchzuführen.
Sendet der Philips Hue auch Updates wenn es keine Bewegung gibt?
Ja.
Ich überlege das mittels Conbee 2 einzubinden. Eine Hue Bridge hab ich nicht...
Da kann ich nicht helfen. Bei mir hängt der an der Hue Bridge und ich bekomme die Werte ja von der Bridge, nicht vom Sensor. Mir ist nicht klar, ob die Bridge den Sensor alle fünf Minuten abfragt oder ob er selbstständig die Werte sendet.
Stefan
Bei Eurer weitergeführten Diskussion habe ich als blutiger Anfänger allerdings nur "Bahnhof" verstanden.
Joa, war ein bisschen Hardcore und geht weit über das hinaus, was man wissen muss, um seine Homebridge zu betreiben. Viel Spaß weiterhin.
Warum das die bessere Lösung sein soll erklärst du aber damit trotzdem nicht...
Weil ich mich dann um nix mehr kümmern muss. geht dann von allein.
Verstehe deine Logik nicht ganz, warum du dann glaubst, dass es am besten wäre, es leer zu lassen.
Aus dem Sourcecode von homebridge-people:
function PeoplePlatform(log, config){
this.log = log;
this.threshold = config['threshold'] | | 15;
this.anyoneSensor = config['anyoneSensor'] | | true;
this.nooneSensor = config['nooneSensor'] | | false;
this.webhookPort = config["webhookPort"] | | 51828;
this.cacheDirectory = config["cacheDirectory"] | | HomebridgeAPI.user.persistPath();
this.pingInterval = config["pingInterval"] | | 10000;
this.ignoreReEnterExitSeconds = config["ignoreReEnterExitSeconds"] | | 0;
this.people = config['people'];
this.storage = require('node-persist');
this.storage.initSync({dir:this.cacheDirectory});
this.webhookQueue = [];
}
Da steht: fülle die Variable this.cacheDirectory mit dem, was du in der config.json findest, und wenn da nix ist, dann nimm den HomebridgeAPI.user.persistPath. In letzterem könnte /var/homebridge stehen. Muss man mal ausprobieren.