Beiträge von sschuste

    Das Projekt ist bereits beendet. Trotzdem danke für den Link. Da darf ich eigentlich gar nicht reinschauen :D. Unter der Decke hängen jetzt billige China-Kracher (ein Lixada Washer und vier PicoSpots). Deren Lüfter habe ich durch bessere ersetzt, man hört sie aber trotzdem. Als Traverse nutze ich zwei DecoTruss, die sich aber als etwas zu schwach erwiesen haben.


    An der Traverse hängt auch ein Raspi namens Lichtmaschine, der die erforderliche Software bereitstellt. An den Strom angeschlossen sind alle Komponenten über zwei Koogeek-Mehrfachsteckdosen.


    Die Steuerung der Moving Heads erfolgt über Szenen. Dabei aktiviere ich eine Szene und belasse sie dann über Stunden so. Beispielsweise drehen sich die Lampen so, dass sie meine Gitarrensammlung beleuchten, oder wenn mal wieder Kino-Abend ist, dann gehen alle aus bis auf eine, die sich dann so dreht, dass sie mit nur 10 Prozent Helligkeit den Wohnzimmertisch anleuchtet, damit ich meinen Drink wiederfinde. Es gibt noch eine Handvoll anderer Szenen, die alle Lampen oder nur einzelne ansteuern.


    Die Lampen einzeln zu steuern ist nicht so einfach: über die Regler in der Home-App für Tilt und Pan ist es ein Geduldsspiel und über Siri ist es auch nicht einfach: "Hey Siri, stelle wz-p1-tilt-26 auf 63%" überfordert hier gleich zwei - erst mich beim Aussprechen und danach Siri. Da ich nicht ständig die Lampen bewegen will, so wenig wie andere ständig die Farbe ihrer Lightstrips ändern wollen, läuft halt alles über voreingestellt Szenen, wie bei den anderen Kindern auch.


    Um Programmierung kommt man nicht herum. Die Treiber der Lampen sind in Javascript programmiert. Hier habe ich die Vorlagen von homebridge-dmxuniverse so angepasst, dass sie auf meine Moving Heads passen. Weiterhin habe ich Node Red verwendet, damit ich Szenen auch über Alexa aufrufen kann. Ich habe festgestellt, dass die Lichtleistung für ein Wohnzimmer unerheblich ist. Tatsächlich dimme ich sie auf Parties herunter (per Hue Dimmschalter).


    War ein tolles Projekt und hat eine Menge Spaß gemacht und macht es immer noch. Die billigen Moving Heads tun ihre Arbeit, und da sie sich ja auch nicht allzusehr bewegen, werden die wohl eine Weile halten. Richtig Rambazamba mit voll Power machen die nur auf meiner Silvesterparty. Wenn ich das ganze noch mal machen sollte, würde ich eine stabilere Aufhängung wählen. Leider bin ich ein wirklich mieser Handwerker. Bessere Moving Heads sollten lüfterlos sein oder über einen Temperatur gesteuerten Lüfter verfügen, was aber in der Billig-Preisklasse nicht zu bekommen ist. Und natürlich muss man auch über den Stromverbrauch nachdenken: die fünf Moving Heads brauchen um die 180 Watt.


    Gekostet hat mich das Ganze etwa 900€ (fünf Moving Heads + Traverse + Raspi + DMX-Interface + Koogeeks + Kabelgedöns).


    Stefan

    Gibt es aktuell eine Empfehlung für Versionsnummer?

    Ich nutze die (long time support)LTS-Version von node. Das ist zur Zeit die 10.16.3.


    Ich verwalte meine node-Versionen mit n. Mit n kann man leicht zwischen verschiedenen Node-Versionen wechseln. Installiert wird n mit:

    sudo npm install -g -unsafe-perm n


    Dann kann man n aufrufen, um sich die installierten Versionen anzuschauen. Mit n --help sieht man alle Optionen.


    sudo n lts installiert die letzte LTS-Version von node.

    sudo n latest installiert die neueste node-Version.


    Für Module und npm nehme ich npm-check. Einfach installieren mit

    sudo npm install -g --unsafe-perm npm-check


    Dann npm-check -gu aufrufen.


    Stefan

    Oder hab ich das falsch verstanden?

    Nö, völlig fast richtig :D. Die Container werden aus Images erstellt, und diese Images werden zentral in einer sogenannten Registry gespeichert. Richtig: du würdest diese Images auf dem Mac erstellen, dort testen und dann in eine Registry uploaden. Von dort lädt Docker auf dem Raspi sie herunter, verwandelt sie in Container und lässt diese laufen.


    Diese Registry kann sonstwo sein: auf deinem Mac, auf einem extra-Raspi, auf einem Server in einem Rechenzentrum oder in einer öffentlichen Registry wie DockerHub. Hier ist eine kleine Anleitung, wie es geht: https://docs.docker.com/get-started/


    Stefan

    Auf dem Mac ein Terminal öffnen:

    scp config.json [email protected]: (wobei du die IP-Adresse deines Raspis verwenden musst)


    Auf den Raspi einloggen:

    sudo cp config.json /var/homebridge

    sudo chown homebridge:homebrigde /var/homebridge/config.json

    sudo systemctl restart homebridge


    Stefan

    Docker, das ich selbst nicht nutze, hat viele Vorteile bei solch kleinen Serversystemen, wie wir sie betreiben. Ein Docker-Container enthält oft nur eine Minimalinstallation des Betriebssystems und natürlich die benötigte Software, hier: node plus homebridge plus irgendein Plugin plus anderes benötigtes Zeugs.


    Der Docker-Container braucht Docker, damit er laufen kann. Die Container werden in einer Registry gespeichert. Diese könnte beispielsweise auf einem Mac oder PC laufen. Ein Raspi lädt dann den Container aus dieser Registry und lässt ihn laufen. Wenn man den Container auf einem anderen Raspi laufen lassen will, dann installiert man dort Docker und startet man den Container halt da. Und: wenn man ihn auf einem Mac laufen lassen will, dann installiert man halt Docker auf einem Mac und startet ihn dort. Und wenn man ihn auf einem Windows-PC laufen lassen will, dann installiert Docker auf dem PC und... ich glaube, es ist klar, was ich sagen will. Der Container lässt sich leicht transportieren. Du baust den Container und ich lass ihn laufen und zwar da, wo es mir passt.


    Damit es ganz klar wird: man hat dann einen Haufen dieser Container, und jeder enthält node, homebridge und ein einziges Plugin.


    Man könnte sogar so weit gehen, solche Container auf mehreren Computern zu installieren und einen Loadbalancer davor zu stellen, so dass einer dieser Computer ausfallen könnte, ohne dass der Homebridge-Service irgendwie davon beeinträchtigt würde. Willkommen in der wunderbaren Welt des totalen over engineerings des eigenen Zuhauses ;). Lassen wir das lieber.


    Der Container mit der neusten Version von homebridge läuft nicht richtig? Dann nimm wieder den alten. Bluetooth und noble brauchen node 8, aber du hast node 12 und dir fliegen die Fehlermeldungen um die Ohren? Dann lass in dem einen Container node 8 laufen und in allen anderen node 12.


    Das wirklich Feine aber wäre die Registry auf dem Mac, die per Time Machine gesichert würde. Nie wieder Backup-Probleme mit der Raspi-Installation. Wow. Betriebssystem auf die SD-Card flashen, Docker drauf, Container laden, weiter geht's.


    Man hätte also statt der vielen Instanzen viele von einander getrennte Container, die man verteilen kann, wie man will und die sich nie auch nur irgendwie gegenseitig beeinflussen, und die gar unterschiedlichste Softwarestände erlauben.


    Toll, toll, toll. Das Goldene Zeitalter[TM] hat begonnen. Und warum mache ich das nicht so? Der Lernaufwand erhöht sich natürlich erst einmal. Man muss nicht nur "Linux lernen", sondern auch noch Docker. Wie wird ein Container erstellt? Wie funktioniert die Registry? Wie automatisiert man Installationen? Wie bearbeitet man config.json? Wieso geht das jetzt nicht? Leck mich, noch mehr Software, die aus irgendwelchen Gründen nicht funktioniert, noch mehr Debugging, noch mehr Aufwand. Super, ich bin mit Docker zwar die Speerspitze der technischen Evolution, aber dafür gibt es immer weniger Cracks, die noch meine Fragen beantworten können.


    Ich bin sicher, dass Docker plus homebridge einen hohen Mehrwert bedeutet, aber bislang hatte ich nicht die geringste Lust, mich da so richtig reinzusetzen. Und es würde natürlich in der nächsten fetten Anleitung enden. Ich bin zu alt für diesen modernen Schnickschnack X/.


    Trotzdem: auf Dauer werde ich mich ganz klar damit beschäftigen, aber das ist ein Projekt für 2020. Dann wird herumgedoktertgedockert.


    Stefan

    dass der Arbeitsspeicher nahezu gesamt belegt ist.

    Wenn du tief in dich gehst, wirst du bemerken, dass du den Arbeitsspeicher ja nicht gekauft hast, damit er unbenutzt vor sich hingammelt, oder? Arbeitsspeicher ist dazu da, dass er benutzt wird, ansonsten kann man auch ein Stück davon absägen und in die Tonne werfen.


    Die Frage ist nur: wofür wird der Arbeitsspeicher benutzt? Der Befehl free im Terminal kann einem Auskunft geben:


    free -m


    Code
    pi@redpi:~ $ free -m
                  total        used        free      shared  buff/cache   available
    Mem:            927         337          96          83         493         456
    Swap:            99           0          99

    Das ist mein Raspi 3B+. An Speicher stehen mir insgesamt 927 MB zur Verfügung. Davon sind 337 benutzt und 96 frei. Klingt komisch, nicht wahr? Da fehlt doch was... ah, da werden noch 493 MB für buff/cache verwendet. Das Betriebssystem macht nämlich folgendes: es nimmt den freien Speicher, den die Maschine noch hat und speichert darin alles mögliche, meist alles das, was für einen schnellen Dateizugriff nötig ist und noch irgendeinen anderen Schnickschnack. Warum auch nicht?


    Wenn der Raspi mehr Speicher braucht für laufende Software, dann wird buff/cache wieder freigegeben. Die Rechnung oben lautet also:


    377 MB benutzter Speicher durch laufende Software +

    96 MB völlig unbenutzter Speicher (kann man absägen) +

    493 MB temporär benutzter Speicher =

    926 MB Gesamtspeicher (passt nicht so ganz, ist aber ähnlich zu 927 MB in der Anzeige)


    Der wirklich freie Speicher, den du noch nutzen kannst steht ganz rechts: 456 MB. Dämlicherweise zeigen alle grafischen Oberflächen, Monitorprogramme und sonstwas immer den Wert von free an (96 MB) statt den von available (456 MB). Die 83 MB shared übrigens werden vom Betriebssystem für sich benutzt und die Rechnung lautet am Ende 927 MB total + 83 shared = 1009 MB Gesamtkapazität des Raspis. Die Zahlen sind immer als ungefähr zu betrachten.


    Es wird erst bitter, wenn der Wert unter available immer auf 0 steht und dafür der Wert neben swap auf 99. Dann lagert der Raspi nämlich Daten auf die SD-Card aus und dann braucht man zwingend mehr RAM. Im Swap kann bei dir jetzt ein Wert stehen, der dir aber egal sein kann, solange available genug anzeigt. Manchmal schreibt der Raspi was in den Swap hin, frag mich nicht, was das ist.


    Auf meinem Raspi 4 sieht die Situation völlig trostlos aus:

    Code
    pi@homePi:~ $ free -m
                  total        used        free      shared  buff/cache   available
    Mem:           3906         306        2327          32        1272        3419
    Swap:            99           0          99


    2,327 GB RAM werden überhaupt nicht genutzt, verfügbar sind gar 3,419 GB: rausgeschmissenes Geld, aber es gab leider keinen kleineren Vierer, als ich ihn gekauft habe. Völlig überdimensioniert.


    Stefan

    Hmmm. Bei mir läuft das Plugin auch nicht mehr, schmiert aber mit einer anderen Fehlermeldung ab. Ich habe das nicht mal bemerkt, weil ich so selten drauf schaue. Ich habe nicht mal bemerkt, dass ich nach meinem Umzug von einem Raspi 3 auf einen Raspi 4 sogar vergessen hatte, den chromium-browser überhaupt zu installieren :sleeping:.


    Das habe ich jetzt nachgeholt und prompt geht's nicht mehr. Das muss ich erstmal debuggen. Ich nehme ja an, dass du auch Buster als Betriebssystem einsetzt - möglicherweise liegt es daran. Kann noch nix sagen.


    Stefan

    Hallo, also wenn ich es richtig verstehe sollte man den cmtrigger lieber nehmen?

    Wenn man einen Schalter braucht, der ein Kommando ausführen kann und der sich nach einer gewissen Zeit wieder ausschaltet: ja. Auf das Bluetooth-Geraffel hat das aber keinen Einfluss.


    Fliegt die Bluetooth Verbindung nur ab wenn man auf den Raspberry noch was anders mit Bluetooth laufen hat ?

    Ich bin mir noch nicht so ganz sicher, aber ich habe das Gefühl, dass Bluetooth auf meinem Raspi nicht zuverlässig läuft. Dazu kommt das Desaster mit dem Node-Framework noble. Plugins, die dieses benutzen, um die Bluetooth-Verbindung herzustellen, laufen nicht mehr, wenn man eine Node-Version > 9 verwendet. Ich habe daher noble wieder entfernt und schlage mich mit gatttool herum.


    Stefan

    Ich verwende homebridge-cmdtrigger. Das Plugin führt ein Kommando aus, wie es auch cmdswitch2 macht, aber es stellt den Schalter nach einer konfigurierbaren Zeit wieder aus.


    Das könnte dann so aussehen:

    Das erzeugt einen Schalter namens "Vorheizen", der, nachdem er gedrückt wurde und nun auf on steht, nach 30000 Millisekunden wieder zu off wechselt. Dieser Wechsel zu off könnte durch eine Automation in der Home App abgefragt werden: wenn Schalter Vorheizen auf off schaltet, dann schalte Schalter "Kaffee läuft" an.


    Stefan

    Der Weg ist ja:


    Strom -> Schalter -> Paulmann -> Lampe. Den Paulmann kannst du nicht per Schaltdimmer mit mehr oder weniger Strom versorgen. Den kannst du nur an und ausmachen.


    Bei mir läuft der unter Dauerstrom, und die Steuerung läuft über

    Zigbee -> Hue Bridge -> Homebridge mit homebridge-hue-Plugin -> HomeKit und

    Zigbee -> Hue Bridge -> Alexa mit Hue-Skill


    Ich bin jetzt dabei, meine Schalter auszubauen und mit Hue Dimmschaltern zu ersetzen. Ich kann's bei mir leider nicht anders lösen, weil es die Verkabelung meiner Altbauwohnung nicht erlaubt, einen smarten Schalter direkt in die Wand einzubauen. Ich hätte es nämlich sonst so gemacht.


    Der Paulmann SmartHome Zigbee Cephei Dimm/Schalt Controller, den ich einsetze, ist ein ganz schön fettes Teil. Ich war erstaunt, dass der so groß sein muss. Die Maße sind Höhe: 5,3 cm x Breite: 6 cm x Länge: 16,3 cm.


    Hier sind noch zwei Threads dazu:

    Paulmann Zigbee Cephei Dimm/Schalt Controller

    12V Controller: Paulmann YourLED Switch / Dimm Controller - ZERLEGT-


    Stefan