Beiträge von sschuste

Zitat von peterro

Wenn ich richtig informiert bin bräuchte ich die Hue Bridge nicht mehr zwingend, wenn ich Apple Home verwende.

Diese Information ist falsch. Die einzelnen Leuchten und Lampen von Philips können null HomeKit. Das kann nur die Bridge.

Zitat von peterro

Ist das richtig? Gibt es denn keine "smarte" Lösung, die keine oder maximal eine Bridge für alles benötigt?

Gibt es von diesem PKW-Hersteller, dessen Fahrzeuge keinen Sprit mehr oder maximal irgendetwas Flüssiges benötigen - was halt so da ist.

Um ein smartes Gerät anzusteuern, benötigt man das smarte Gerät, eine Fernsteuerung und ein Protokoll. Das Protokoll ist die Sprache zwischen der Fernsteuerung und dem Gerät. Die Fernsteuerung ist ein separates Gerät, das diese Sprache versteht und auch "sprechen" kann. Das kann dein iPhone sein oder Alexa oder irgendein Progrämmchen auf deinem Raspi oder deine Kaffeemühle.

Mir fallen auf Anhieb verschiedene Protokolle ein, die man verwenden könnte, um eine simple Lampe ein- und auszuschalten. Unterschiedliche Protokolle könnten sein:

• Die Lampe geht an, sobald sie die Zahl 1 empfängt und sie geht aus, sobald sie die Zahl 0 empfängt
• Die Lampe geht an, sobald sie den String on empfängt und sie geht aus, sobald sie den String off empfängt
• Die Lampe geht an, sobald sie den String ein empfängt und sie geht aus, sobald sie den String aus empfängt
• Die Lampe geht an, sobald sie den String true empfängt und sie geht aus, sobald sie den String false empfängt
• Die Lampe geht an, sobald sie den String on:true empfängt und sie geht aus, sobald sie den String on:false empfängt

Nimm dir 15 beliebige Programmierhansels, fordere sie auf, eine Lampensteuerung zu erfinden, und du bekommst 15 verschieden Protokolle. Da kannst du dir sicher sein.

Klar kann man jetzt eine smarte Bridge bauen, die die 15 Protokolle versteht, aber ich verspreche dir, dass kaum dass sie auf deinem Tisch steht, drei weitere Programmierhansels drei weitere Protokolle kreiert haben.

Philips Hue "spricht" Zigbee. Alle Hue-Lampen können das. Schade nur, dass Apple HomeKit es nicht kann und es auch nicht will. Philips hätte also allen Lampen und Leuchtmitteln die HomeKit-Sprache beibringen müssen. Da hatten sie aber keinen Bock drauf, viel zu umständlich und wahrscheinlich lizenz-finanziell der pure Selbstmord. Also haben sie eine Bridge gebaut. Die Bridge kann beides und übersetzt. Und braucht nur eine Lizenz.

Exakt das gleiche macht IKEA Trådfri. Auch die verwenden eine Bridge. Auch die machen alles in Zigbee. Deshalb kann man auch die Hue-Bridge für die IKEA-Lampen nehmen. Oder für die von Paulmann. Oder für noch ganz andere Hersteller, die Zigbee-kompatibles Zeugs anbieten. Weil Philips aber Apple fest versprochen hat, dass sie die HomeKit-Lizenz nur für für Philips-Leuchtmittel und -lampen einsetzen werden, tauchen die Lampen der Fremdhersteller zwar in der Hue-App auf, aber nie in der Home-App, halt, weil's Apple nicht erlaubt hat.

Dann gibt es noch ganz andere Protokolle als Zigbee, beispielsweise MQTT oder Z-Wave oder Homematic und noch viele andere. Die sind nicht kompatibel zu Hue und brauchen ihre eigene Bridge. Tja. Wie will man da eine "smarte" Lösung bauen, mit Plug&Play und einschalten und glücklich sein. Ist nicht.

Also geht die Bastelei los. Homebridge ist eine gute Sache dafür, aber man könnte auch Hass.io oder FHEM einsetzen. Die bieten tausende von Möglichkeiten, der babylonischen Sprachvielfalt zu entkommen. Und so kommt man dann zu Automationen wie "Spiele Red Hot Chilli Peppers, wenn die Küchenbeleuchtung auf rot wechselt, aber nur, wenn ein Emirates-Flieger in Frankfurt landet und gleichzeitig das Garagentor aufsteht". Geil, nicht wahr?

Weil wir's können

Stefan

Ich mach's in EVE.

Versuchen wir das mal.

Der Fehler tritt auf in at /home/pi/lametric-hue-temperature/dist/hueService.js:30:55. Es hat also offenbar mit der Hue-Bridge zu tun. Ich hab mal da reingeschaut und das gefunden:

function addSensorName(temperatureSensors, sensors) {
    return temperatureSensors.map(function (temperatureSensor) {
        var sensorId = parseInt(temperatureSensor[0]);
        var siblingSensor = sensors[sensorId + 1];
        temperatureSensor[1]['sname'] = siblingSensor.name;
        return temperatureSensor;
    });
}

Das property "name" taucht hier auf als Teil von siblingSensor.

Was passiert, wenn du im Browser https://192.168.1.23/api/oSwE6…WXh97n-KeHdVXUFlm/sensors aufrufst?

Zitat von recovery

HI kann mir einer sagen wie ich die status url einfügen müsste.

Am besten per Tastatur.

Zitat von recovery

Benute das plugin um meine Funk steckdosen zu Steuern habe insgesamt 3 befehle On OFF und toggle.

Sind das möglicherweise die gleichen Funksteckdosen, die auch meine Tante verwendet? Wenn nicht, dann wäre eine etwas präzisere Auskunft über Modell und den Hersteller sicherlich hilfreich. Wo hast du die drei Befehle her und wie lauten sie?

Stefan

Nein. Ich kann es ja nicht ausprobieren. Der Fehler TypeError: Cannot read property 'name' of undefined weist oft darauf hin, dass ein Parameter nicht gesetzt wurde und das Programm dadurch einen Wert verarbeiten muss, den es als undefiniert ansieht.

Möglicherweise liegt der Fehler hier:

#!/usr/bin/env bash
HUE_API_KEY=xxxxxx \
HUE_BRIDGE_IP=192.168.1.2 \
LAMETRIC_ACCESS_TOKEN=xxxxxx \
LAMETRIC_PUSH_URL=https://developer.lametric.com/api/v1/dev/widget/update/com.lametric.xxxxxx \
node /home/user/lametric-hue-temperature/dist/app.js 2>&1

Hast du da alles korrekt ausgefüllt?

Stefan

Doch. Wo scheitert es denn? Was hast du versucht? Was hast du nicht verstanden?

Wenn du http://192.168.1.23/debug/clip.html aufrufst, wobei du natürlich die IP-Adresse deiner Hue-Bridge benutzt, dann erscheint so was hier:

Dort sollst du, wenn ich es richtig verstanden habe, als URL /api eintragen und als Message Body {"devicetype":"lametric-hue-temp#server"}. Dann sollst du den Knopf auf deiner Hue-Bridge drücken und dann im Browser auf POST. Damit sollst du einen kryptischen Usernamen bekommen. Den kopierst du dir und speicherst mal zwischen.

Dann sollst du auf https://developer.lametric.com/applications/create irgendwas einrichten. Dort bekommst du offenbar auch irgendwelche access_tokens und push_urls, was das immer sein mag.

Danach sollst du das Git-Repo klonen:

git clone https://github.com/anhem/lametric-hue-temperature.git

Danach:

cd lametric-hue-temperature/

npm install

npm run build

cd ..

cp lametric-hue-temperature/lametric-hue-temperature.cron.sh .

nano lametric-hue-temperature.cron.sh

Hier musst du die gesammelten Daten einsetzen: Hue-Username, Lametrics-Zeugs. Als <path> setzt du /home/pi ein. Abspeichern. Dann ein:

chmod +x lametric-hue-temperature.cron.sh

Dann kannst du das testen mit ./lametric-hue-temperature.cron.sh

Klappt das? Ich habs nicht ausprobiert.

Stefan

Zitat von Staub

kennt jemand eine geschickte Lösung um Werte, welche von Geräte an homebridge gesendet wurden, wie als Variablen zu behandeln und mit diesen weiter zu rechnen?

Ja, diese "geschickte Lösung" wird gelegentlich auch als Programmierung bezeichnet. Ohne auch nur ein einziges Mal in Leben einen Aqara-Sensor in meinen Händen gehalten zu haben geschweige einen zu betreiben, würde ich versuchen, die Werte des Sensors mittels eines eigenen Programms zu ermitteln und dann weiterzuverarbeiten.

Ich mache das in meinem Setup immer dann, wenn es keine vernünftige Homebridge-Lösung gibt oder eine eigene Programmierung weniger aufwändig und übersichtlicher ist. Dabei bin ich beim besten Willen kein guter Programmierer. Auch habe ich kein tieferes Verständnis für die Mechanismen von HomeKit oder anderem Zeugs. Ich bin kläglich bei der Programmierung eines einfachen Homebridge-Plugins gescheitert. Ich kann's also nicht richtig, und trotzdem habe ich einen Haufen Zeugs selber gemacht.

Dabei hat mir Node Red geholfen. Node Red ist ein grafisches Framework zur Programmierung, das durch Plugins (die dort Nodes heißen) erweitert werden kann. Es gibt beispielsweise eine Erweiterung für Aquara-Zeugs (oder vielleicht das hier) und eine für HomeKit. Diese Nodes zieht man einfach in den Node Red-Editor und verbindet sie mit Linien (bei YouTube gibt es genug Beispiele, wie das aussieht). Links der Aqara-Node, rechts der HomeKit-Node und in der Mitte dazwischen ein Function-Node, der die Programmierung enthält.

Vielleicht kannst du was damit anfangen.

Stefan

Zitat von Kohle_81

Hab ich was verpasst???

node 12.13.0 lts

Ja. gemeinsam mit mir

Ja, bei mir auch so. Ich würde mir keine Gedanken darüber machen, denn die dem Ganzen zugrunde liegende Regel heißt mit Sicherheit nicht "Letze Person verlässt". Immerhin gibt's HomeKit und EVE auch in anderen Sprechen, und funktioniert auch weiterhin, wenn du auf andere Sprachen umstellst. Dann stehen da an der gleichen Stelle ganz andere Buchstaben, nämlich ausländische

Stefan

Ja, sehr schön. Leider ist noch ein Fehlerchen drin, aber grundsätzlich ist es so richtig. Eine platform nach der nächsten.

Deine Konfiguration wird perfekt, wenn du deinen Fehler in Zeile 22 verbesserst durch

"command": "journalctl -o cat -n 500 -f -u homebridge"
}},
{
"platform": "HomeMatic",

Es fehlt bei dir eine abschließende geschweifte Klammer.

Sehr gut geraten! Leider völlig falsch. Das ist eine platform, was man daran erkennt dass dort "platform": steht, und als solche muss sie natürlich komplett zwischen die "[ ]" der "platforms": gesetzt werden.

Lies noch mal hier den Abschnitt Plugins: Accessories und Plattforms und sieh dir die Beispiele an.

Stefan

Ja. Du hast da einiges zusammengeworfen: die Konfiguration für die Platform HomeMatic steht mitten in der Konfiguration Config. Sie muss aber dahinter oder davor stehen, nur nicht mittendrin.

Zitat von LeBaron90

Mein ungefährer Wissensstand: HomeKit, Homebridge sowie Kurzbefehle sind meistens kein Problem. Ich habe aber noch nie mit MQTT, IFTTT oder weiteren Plattformen gearbeitet.

Ich schon. Dafür noch nie mit einem Mikrofon am Raspi oder einer anderen Linux-Maschine

Zitat von carsten_h

... und demnächst wird dazu eine Klasse Anleitung von Dir existieren. .-)

Null.

Zitat von carsten_h

Hat der Umstieg eigentlich etwas gebracht? Geht z.B. das Atualisieren in den Apps schneller etc.?

Nein. Das verhält sich alles genauso performant wie auf dem Raspi 3. Der Raspi 4 war gleichzeitig der 4. Raspi in meinem Haushalt, und weil er so viel RAM hat, habe ich gleich noch anderes Zeugs auf ihn draufgepackt:

• Node Red Server: damit erstelle ich mit vor allem Szenen und Animationen für meine Moving Heads im Wohnzimmer, aber auch Progrämmchen zum Monitoren meines Setups.
• Mosquitto MQTT Broker: habe ich gebraucht für die Xiaomi Mi Flora Flower Care-Sensoren, von denen aber der eine nach fünf Wochen kaputt ging und der andere nach sechs. Tolles Zeugs. Im Augenblick spiele ich mit dem MQTT Broker nur ein bisschen herum.
• InfluxDB: zum Speichern von Langzeitdaten wie beispielsweise Temperatur und CPU-Auslastung der Raspis. Totaler Nerdkram, den keiner braucht.
• Grafana Server: Zum Visualisieren der Daten aus der InfluxDB.

Irgendwann verfrachte ich noch pi-hole darauf und dann habe ich zwei Raspis eingespart.

Mal ein bisschen Off-topic: hier ist eine Grafik aus Grafana, die Temperatur, CPU-Auslastung und Speicherverbrauch der letzten 90 Tage zeigt:

Da kann man sehr schön erkennen, wie im August (8/24) der Raspi 4 dazukommt. Er übernimmt den Namen homepi vom alten Raspi 3 (der ab da bluepi heißt und seitdem meinen Bluetooth-Experimente dient). Die Temperatur geht rauf, der Raspi 4 wird zwischen 70º und 80º warm. Kurz vor 10/8 habe ich den Gehäusedeckel entfernt und ihn offen betrieben, bei 10/16 ist das neue Passivkühlgehäuse eingetroffen und die Temperatur liegt jetzt nur noch bei 55º.

Bei der CPU sieht man, wie die Node Red-Installation, die InfluxDB und der Grafana-Server vom redpi auf den homepi umzieht. Die Last des einen geht rapide herunter, die des anderen deutlich rauf.

Wie gesagt: Nerdkrempel.

Stefan

Das ist kaum gänzlich zu beantworten. Ich bin aber neulich auch umgezogen, von einem 3er auf einen 4er.

Ich habe einfach eine neue Homebridge nach dieser Anleitung aufgesetzt. Dann habe ich alle Plugins neu installiert. Danach habe ich die config.json von dem alten Gerät auf das neue kopiert. Das habe ich einfach mit copy&paste im Webinterface gemacht.

Ich habe auch die beiden Ordner persist und accessories im homebridge-Ordner kopiert. Dazu habe ich scp verwendet.

Dann habe ich die alte Homebridge gestoppt und die neue gestartet, das Log auf Fehler überprüft und dann in der Home-App geschaut, was noch geht und was nicht. Was mir fehlte, waren unzählige von selbst geschriebene oder heruntergeladenen Scripts und Programmen. Die habe ich alle vom alten Raspi kopiert oder neu installiert.

Das war alles ziemlich aufwändig.

Stefan

Deine Fehlermeldung sagt aus, dass der User homebridge ein Passwort eingeben muss, um den Befehl npm zusammen mit sudo benutzen zu dürfen. Was bedeutet das?

Im Grunde gibt es zwei verschiedene Usertypen auf Unix- und Linux-Maschinen. Ob Linux oder MacOSX, aber auch Android, iOS, tvOS und iPadOS, verwenden Unix- oder Linux-Systeme, und für alle gilt diese Regel. Ebenfalls für jede Spezialhardware mit Unix-Betriebssystemen. Ich weiß nicht, ob Betriebssysteme wie Solaris (Sun) oder AIX noch eingesetzt werden, aber es gilt auch für die.

Zwei Usertypen. Der eine darf alles: jede Datei verändern, löschen, duplizieren, lesen und schreiben. Er darf jederzeit mit unbedachten Handlungen das System ruinieren. Er darf die Festplatten löschen oder auch Fehler bereinigen, und das auf dem ganzen System. Er darf jedes Programm starten. Er darf jeden Port benutzen. Dieser User wird root genannt. Er ist der super user. Das Passwort für diesen User haben daher nur wenige.

Der andere Typ darf fast nichts. Er darf zwar fast alle Programme starten, aber er darf nur an sehr wenigen Stellen im System Dateien schreiben, und schon gar nicht darf er außerhalb dieser Stellen etwas löschen, verändern oder "verbessern". Er darf nur an ganz bestimmten Stellen im System Software installieren. Er darf nicht mal die Ports 1-1023 nutzen. Die User wurde früher von den arroganten Administratoren luser genannt (ein Kunstwort aus den Begriffen User und Loser), sagt man aber heutzutage nicht mehr, weil nicht pc. So einer darf nicht mal den Rechner ausschalten.

Linux- und Unix-Systeme haben immer einen root, der alles darf, und viele User, die fast nix dürfen. Einer dieser User heißt pi, ein anderer nach der Installation der Homebridge homebridge. Was dürfen diese unprivilegierten User auf dem System anstellen?

Sie dürfen Dateien schreiben und löschen in den Verzeichnissen /tmp und /home/<username>, also beispielsweise /home/pi oder /home/homebridge. Sonst nirgendwo. Letzteres Verzeichnis wird Home-Verzeichnis genannt, da landet man nach dem Login, und jeder User darf nur in sein eigenes Homeverzeichnis schreiben. Das Betriebssystem Raspbian nimmt's nicht ganz so genau und lässt es zu, dass alle User in das Homeverzeichnis der anderen User schauen können, was privatsphärisch ein Mist ist, aber es soll uns auf unseren Homebridge-Dingern egal sein.

Der User homebridge darf sogar noch in ein anderes Verzeichnis neben /tmp und /home/homebridge schreiben, nämlich nach /var/homebridge. Wenn der User homebridge ein Programm startet, dann läuft das mit den Rechten des Users homebridge, und seine Rechte erlauben es ja nicht, woanders hinzuschreiben als nach /tmp oder /home/homebridge. Daher gehört das Verzeichnis ihm. Dort legen das Programm homebridge und alle seine Plugins ihre Dateien ab. Wenn der User homebridge da nicht hinschreiben darf, dann darf es das von ihm gestartete Programm homebridge auch nicht und dann läuft die Homebridge nicht mehr.

Admins sind das faulste Pack auf diesem Planeten, ich muss das wissen, denn ich bin einer von denen. Irgendwann hat man die Nase voll von irgendwelchen lusern, die ständig um die Ecke geschlichen kommen und einen anbetteln, man möge doch dieses hier installieren oder jenes anders konfigurieren. Man braucht also Hilfssheriffs, die das auch dürfen, wobei es geil wäre, wenn die nur ein bisschen mehr können und nicht gleich die ganze Schüssel platt machen können. Also haben wir das Programm sudo (super user do) erfunden.

Mit sudo darf ein normaler User Befehle so ausführen, als würde das root tun. Dazu wird in der Datei /etc/sudoers festgelegt, welche Befehle welcher User als root ausführen darf und ob er dazu vorher sein Passwort eingeben muss oder nicht. Für den User pi ist festgelegt, dass der alle Befehle als root ausführen darf, ohne dass er dazu sein Passwort eingeben muss:

pi ALL=(ALL) NOPASSWD: ALL

Der User pi ist also faktisch root: er darf auch alles machen, muss aber seinen Kommandos den Befehl sudo voranstellen. Wenn der User pi ein Plugin auf der Shell installieren will, dann muss er zwingend ein sudo voranstellen, denn ein npm install -g homebridge-plugin will das Plugin nach /usr/local/lib/node_modules installieren und dorthin darf nur root schreiben. Der User pi muss das Kommando also als sudo npm install -g homebridge-plugin angeben.

Davon kann der User homebridge nur träumen. Der darf nämlich nix. Da er aber das Programm homebridge-config-ui-x startet, mit dem Plugins installieren kann, muss er zumindest ein paar erweiterte Rechte haben, damit das Programm auch tun kann. Und daher hat er auch einen Eintrag in der sudoers-Datei:

homebridge ALL=(root) SETENV:NOPASSWD: /usr/local/bin/npm, /bin/systemctl restart homebridge, /usr/local/bin/node

Bedeutet: der User homebridge darf dem Befehl /usr/local/bin/npm, dem Befehl /bin/systemctl restart homebridge und dem Befehl /usr/local/bin/node ein sudo voranstellen. Gleichzeitig soll die Eingabe eines Passortes nicht notwendig sein. Deine Fehlermeldung weiter oben behauptet aber das Gegenteil: sie sagt aus, dass er eins eingeben muss und daher glaube ich, dass dort ein Fehlerchen steckt.

Log dich also als Hilfssheriff pi ein und gib dann ein: sudo visudo -f /etc/sudoers.d/homebridge

Das Programm visudo ist extra dafür gemacht, dass es dich die sudoers-Datei nicht speichern lässt, wenn darin grobe Fehler sind. Sowas kann dazu führen, dass sich niemand, nicht einmal mehr root, auf dem System einloggen kann. Immer, immer, immer, immer visudo zum Bearbeiten der suoders-Datei nutzen! So was lernt man nur auf die harte Tour, zumindest ich. Ätzend. Nimm lieber meinen Rat an.

Ich hoffe, es ist etwas klarer geworden mit den ganzen Usern. Tatsächlich sind die Zugriffsrechte heutzutage noch feiner granuliert und es geht auf manchen Systemen soweit, dass nicht einmal root etwas verändern kann, ohne Handstände zu machen, aber das würde jetzt viel zu weit führen. Auf unseren Raspis gilt das, was ich oben detailliert monologisiert habe.

Zitat von Hoffi

Bauschmerzen habe ich gerade mit den Ports. Ich glaube dass Shelly 8080 verwendet und mein Remote Desktop 8081 deshalb habe ich 8082 in der config.json gesetzt.

Meine Weboberfläche von homebridge-config-ui-x läuft auch nicht auf dem Standardport, sondern auf Port 8088. Du kannst jeden Port verwenden, der größer ist als 1023. Es bietet sich an, gleich 8888 und 9999 zu nehmen, halt irgendwas, was man sich leicht merken kann. Den Shelly-Port würde ich nicht verändern. Du machst das schon richtig.

Zitat von Hoffi

Aber die reolink Kamera kriege ich nicht ans laufen.

Ich verwende keine Kameras. Deshalb kann ich dazu wenig sagen. Ein kurzer Scan über das Internet per Google sagt mir, dass die Kamera grundsätzlich funktioniert. Dazu braucht man das Programm ffmpeg, dass du mit sudo apt-get install ffmpeg installierst. Sobald man es hinbekommen hat, die Kamera mit diesem Programm zum Laufen zu bekommen, kann man sie mit homebridge-camera-ffmpeg in HomeKit einbinden. Diese Angaben sind völlig ohne Gewähr.

Stefan

Zitat von meistermolli

Wie bekomme ich nodejs jetzt auch auf die 10er version?

Sowas gibt's gar nicht bei mir. Ignorieren.

BalenaEtcher funktioniert auf Catalina auch nicht richtig.

Gute Idee. Der Raspi müsste ein Hotspot sein, und ich verbinde dann mein iPhone nicht mit meinem Standard-WLAN, sondern mit dem Raspi-Hotspot. Per LAN-Kabel geht's dann weiter zu meinem Router. Allerdings habe ich vom HomeKit-Protokoll wenig Plan, ich müsste also erstmal ausprobieren, wie das Netzwerk konfiguriert werden muss. Ich schätze mal, dass der Raspi eine Netzwerkbridge sein muss und nicht selber ein Router.

Oh Mann. Ich hab überhaupt keine Zeit dafür.

Ich habe drei Koogeek-Mehrfachsteckdosen, die mit HomeKit keine Probleme machen, aber Alexa kriegt's oft nicht hin.