Also, dann sieht es so aus:
Deine Homebridge-Installation befindet sich in /usr/lib. Daher scheinen die beiden n und npm in /usr/local/lib überflüssig zu sein. Hübscher Satz: sie scheinen überflüssig zu sein.
Ob sie es sind, findest du heraus mit
ls -l $(which n) und
ls -l $(which npm)
Was kommt dabei heraus?
Dann geht noch npm -g root, das zeigt an, wohin npm überhaupt was hininstallieren will.
Google sagt nein und spuckt das hier aus: https://www.l2h-rev.de/forum/topic/iobroker/
Habe mir jetzt den Befehl „@reboot sudo mosquitto“ in die crontab -e geschrieben. So startet Mosquitto beim reboot. Läuft doch aufs gleiche raus, oder??
Ja, aber so wird's nun mal nicht gemacht 
. Wenn's für dich so funktioniert, warum nicht. Ich wusste nicht einmal, dass man das so machen kann und ich wäre auch nie auf diese Idee gekommen. Und wenn, dann nicht mit sudo mosquitto. Das ist zwar alles ganz schön, aber es ist übles Gebastel, so wie den Reservereifen deines Autos auf die Windschutzscheibe zu kleben: man sieht zwar nix mehr, aber Hauptsache, der Reservereifen ist dabei.
Dass du Mosquitto nicht mehr vernünftig stoppen kannst, scheint dir auch egal zu sein. Gut, da kann man sich dann auf mich berufen, der ständig behauptet: ich starte nicht irgendwas, um es wieder zu stoppen. Trotzdem ist deine Vorgehensweise gleichbedeutend mit Kontrollverlust.
Läuft eben nicht aufs gleiche raus. Weiß der Geier, welche Config der lädt. Startet auch nicht im insecure-Mode für Alexa.
Falsches Programm. Hier soll MQTT gestartet werden und das braucht keinen Insecure-Modus für Alexa, weil
Du startest deinen Mosquitto mit /usr/sbin/mosquitto -c /usr/etc/mosquitto/mosquitto.conf
Das weiß ich, weil ich das oben lesen kann. Und das funktioniert, wenn du das auf der Shell eingibst, vor allem, wo du nach Anleitung diese Datei ganz woanders angelegt hast? Das ich glaube nicht. Ich würde es mal versuchen mit
/usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
Noch was zum Lesen von Anleitungen:
Das ist alles nicht immer so einfach. Das kann ich gelegentlich sogar nachvollziehen. Komischerweise versteht jeder auf seinem Desktop und per Maus, wie man einen Ordner namens etc anlegen kann, und in diesem Ordner einen Unterordner namens mosquitto und darin eine Datei namens mosquitto.conf. Und jeder versteht, wie man mit der Maus in diesen Ordnern navigieren kann, und jeder versteht, dass das alles eine Struktur bildet. Kaum geht es um /etc/mosquitto/mosquitto.conf, machen viele den Kopp zu, obwohl es genau das gleiche ist, und ziehen sich darauf zurück, dass sie ja keine Experten sind.
Jeder hier hat auf seinem PC oder auf seinem Mac schon mal ein Programm gestartet. Jeder hier hat schon mal Einstellungen in einem Programm gemacht. Beispielsweise habe ich mal Word gestartet und in den Einstellungen angegeben, wo der Standardordner zum Speichern von Worddateien ist. So etwas Ähnliches hat hier schon jeder gemacht. Dass solche Angaben irgendwo gespeichert werden müssen, ist vielleicht dem einem oder anderen nicht so klar, weil das mit diesem Computer alles irgendwie magic ist, und zwar much magic. Denjenigen, denen das logisch vorkommt, werden sicherlich auch begreifen, dass solche Einstellungen auch wieder geladen werden müssen.
Wir haben hier auf unseren Raspis meist keine grafische Benutzeroberfläche oder eine Maus. Hier wird kein Programm per Doppelklick gestartet, sondern per Eingabe auf der Tastatur. Und irgendwo müssen auch die Einstellungen abgelegt werden, im vorliegenden Fall in die Datei mosquitto.conf. Und dann startet man das Programm mosquitto und das will wissen, wo denn diese Einstellungsdatei liegt. Und weil man sie zufälligerweise mit dem Befehl nano /etc/mosquitto/mosquitto.conf erstellt hat, liegt der Verdacht nahe, dass man Mosquitto mit dem Befehl mosquitto -c /etc/mosquitto/mosquitto.conf starten muss.
Ja, du kriegst das jetzt ab, dabei sind viele gemeint. Dafür schulde ich dir jetzt mindestens ein Bier. Absolut einforderbar. Ich gebe auch zu, dass viele Anleitungen völlig beschissen geschrieben sind und natürlich gebe ich erst recht zu, dass ich schon oft gescheitert bin, die falschen Pfade angegeben habe, mein Blick auf dem Bildschirm herumlungerte.
Macht euch die Mechanismen klar. Ein Programm, dass nicht auf der Shell gestartet werden kann, weil irgendwas nicht nicht stimmt, wird sich auch nicht automatisch starten lassen.
Deine Analyse ist schon mal großartig. Ich will noch was hinzufügen:
Das sind also zwei völlig unterschiedliche Sachen. Du kannst sie nachprüfen mit dem Befehl file. Dieser Befehl zeigt dir, um was für einen Dateityp es sich handelt.
Nun weichen die Pfade in oznus Homebridge-Installation von den Pfaden der Smartapfel-Installation ab. Ich kann sehen, dass bei oznu das Homebridge-Verzeichnis /var/lib/homebridge ist, bei Smartapfel dagegen /var/homebridge. Das haben wir hier damals so gemacht, um kompatibel zu den Tools von det zu sein. Dass diese Pfade unterschiedlich sind, spielt für die Funktion der Homebridge keine Rolle außer zur Verwirrung beizutragen: bei dem einen liegt die config.json hier, bei dem anderen dort und es gibt in diesem Forum sogar noch dritte Pfade (/home/pi/.homebridge/config.json) und vierte (/root/.homebridge/config.json). Und Hoobs hat es noch anders gemacht.
Was ein Durcheinander. Hier ist es nur wichtig, dass man seinen eigenen Pfad weiß, in deinem Falle /var/lib/homebridge, und darauf immer alles bezieht, auch wenn die Installationsanleitungen der Plugins was anderes behaupten wollen. Ich muss mich halt immer auf /var/homebridge beziehen.
Eine wichtige Frage aber ist: wo befinden sich die Plugins? Dieser Pfad wird von npm gewählt, und hier haben hier in letzter Zeit zunehmend Fälle, bei denen die Plugins an zwei verschiedenen Orten installiert werden, wo es doch nur einer sein sollte. Wo sind deine Plugins?
Meine liegen ausnahmslos in /usr/local/lib/node_modules. Die sind deshalb dort, weil ich nach Smartapfel-Anleitung das benötigte Programm node in /usr/local installiert habe. Wie die Pfade bei oznus Installation sind, weiß ich nicht.
Solange die Plugins an einer bestimmten Stelle installiert sind, und zwar alle, ist gegen diese Stelle nichts einzuwenden. Aber wenn sie an zwei verschiedenen Orten liegen, wird es blöd. Sie sollten entweder
hier: /usr/local/lib/node_modules oder
hier: /usr/lib/node_modules liegen
Aber nicht an beiden Orten. Wo sind deine?
ls -ld /usr/local/lib/node_modules/homebridge*
pi@homepi:~ $ ls -ld /usr/local/lib/node_modules/homebridge*
drwxr-xr-x 5 root root 4096 May 17 14:41 /usr/local/lib/node_modules/homebridge
drwxr-xr-x 4 root root 4096 May 3 10:18 /usr/local/lib/node_modules/homebridge-alexa
drwxr-xr-x 6 root root 4096 May 11 00:45 /usr/local/lib/node_modules/homebridge-apple-tv-remote
drwxr-xr-x 6 root root 4096 Jan 27 23:51 /usr/local/lib/node_modules/homebridge-broadlink-rm
drwxr-xr-x 5 root root 4096 Aug 23 2019 /usr/local/lib/node_modules/homebridge-calendar
drwxr-xr-x 2 root root 4096 May 27 14:41 /usr/local/lib/node_modules/homebridge-cmdswitch2
drwxr-xr-x 3 root root 4096 Aug 23 2019 /usr/local/lib/node_modules/homebridge-cmdtrigger
drwxr-xr-x 6 root root 4096 May 27 14:38 /usr/local/lib/node_modules/homebridge-config-ui-x
drwxr-xr-x 2 root root 4096 May 2 09:01 /usr/local/lib/node_modules/homebridge-delay-switch
drwxr-xr-x 3 root root 4096 Aug 23 2019 /usr/local/lib/node_modules/homebridge-http
drwxr-xr-x 5 root root 4096 May 18 00:19 /usr/local/lib/node_modules/homebridge-hue
drwxr-xr-x 10 root root 4096 May 19 13:55 /usr/local/lib/node_modules/homebridge-mqttthing
drwxr-xr-x 4 root root 4096 Aug 23 2019 /usr/local/lib/node_modules/homebridge-omxplayer
drwxr-xr-x 3 root root 4096 Apr 7 16:35 /usr/local/lib/node_modules/homebridge-people
drwxr-xr-x 6 root root 4096 May 28 08:47 /usr/local/lib/node_modules/homebridge-weather-plus
drwxr-xr-x 4 root root 4096 May 6 14:22 /usr/local/lib/node_modules/homebridge-website-to-camera
drwxr-xr-x 5 root root 4096 May 23 15:26 /usr/local/lib/node_modules/homebridge-zp
ls -ld /usr/lib/node_modules/homebridge*
pi@homepi:~ $ ls -ld /usr/lib/node_modules/homebridge*
ls: cannot access '/usr/lib/node_modules/homebridge*': No such file or directory
/usr/local/sbin/mosquitto: No such file or directory
Da steht's doch. Das soll gestartet werden und das gibt es nicht. Setze in /etc/systemd/system/mosquitto.service das ein, was du mit which mosquitto herausbekommst.
Danach ein sudo systemctl daemon-reload
Hmmm. Bei mir läuft homebridge-weather-plus ohne weitere Probleme auf meiner [email protected].
{
"platform": "WeatherPlus",
"name": "WeatherPlus",
"service": "darksky",
"key": "ca933f129----------527efxa0",
"displayName": "Wetterdaten",
"location": [
50.1014,
8.6817
],
"language": "de"
}Also diese Datei habe ich gemäß Vorgehen der obigen Anleitung nicht erstellt.
Klar hast du die erstellt. Die Anleitung beschreibt das ja:
sudo cp mosquitto_unit_file/mosquitto.service /etc/systemd/system/mosquitto.service
was soviel bedeutet wie: kopiere mit root-Rechten die Datei mosquitto.service nach /etc/systemd/system.
Habe lediglich systemctl mitgeteilt, diese Datei auszuführen. Was aber dann ja keinen Sinn macht
Doch, das macht absolut Sinn. Der Befehl sudo systemctl enable mosquitto (das .service am Ende kann man weglassen) sorgt dafür, dass der Mosquitto-Server beim Booten automatisch gestartet wird. Dieser Befehl muss nur einmal eingegeben werden.
Der Befehl sudo systemctl start mosquitto startet den Server
Der Befehl sudo systemctl stop mosquitto beendet den Server
Der Befehl sudo systemctl restart mosquitto beendet den Server und startet ihn neu
Ein Logfile habe ich mit sudo less /var/log/mosquitto/mosquitto.log anzeigen können.
Da ich von dieser Anleitung keinen blassen Schimmer hatte, habe ich meinen Mosquitto einfach installiert und die Datei /etc/systemd/system/mosquitto.service selber ausgedacht.
Diesen Pfad gibt es ja nicht. Oder passt der Pfad aus Sicht des "homebridge" Services eh und ich sehe ihn nur noch als User "pi"?
Lass das einfach leer oder setze /var/lib/homebridge/node-persist/storage ein. Also entweder:
"cacheDirectory": ""
oder
"cacheDirectory": "/var/lib/homebridge/node-persist/storage"
Sieh das noch mal genau nach, der Homebridge-Pfad steht in homebridge-config-ui-x als "Speicherpfad".
Okay, woher weiß ich denn welche Pfade ich ändern muss?
Du musst keine ändern.
Achso, der Service muss quasi erst erstellt werden? Hatte nach der installation einfach wie es in der Anleitung stand „enable“ mosquitto.service angegeben.
Welche Anleitung schreibt enable mosquitto.service?
Der Service muss nicht erstellt werden. Der Service ist nämlich mosquitto. Was möglicherweise erstellt werden muss, ist /etc/systemd/system/mosquitto.service. Diese Datei wird von systemd verwendet, und systemd dient dem Starten und Stoppen von Services (in diesem Fall mosquitto). Also: welche Anleitung?
kann mir jemand sagen wo hier der Fehler liegt, bekomme mein Homebridge nicht mehr zum laufen. habe auch weatherPlus deinstalliert
Was wahrscheinlich nicht geholfen hat, da der Fehler von homebridge-rpi ausgelöst wird. Hast du mal den Raspi neu gestartet?
Am besten vor jeden Befehl ein sudo schreiben.
Fährt der Robo dann nach 4,5h wieder selbstständig in seine Station
Ich würde vorschlagen, dass du dir zur Beantwortung deiner Frage einfach mal 4,5 Stunden Zeit nimmst.
Du willst den Wert eines Sensors auslesen (beispielsweise "22"), ihn dann umwandeln (beispielsweise in "Die Pooltemperatur beträgt 22º C. ") und das umgewandelte Ergebnis dann an die Awtrix senden. Da kommst du um Programmierung nicht herum. Es gibt da keine fertige Lösung.
HomeKit oder Homebridge wären eh der falsche Ansatz. HomeKit ist nicht dafür gedacht, einen Sensorwert zu manipulieren und irgendwo hinzusenden. Mit HomeKit kann man nur Werte erhalten und darauf basierend irgendwelche HomeKit-Automationen erstellen. Vielleicht könnte man die Kurzbefehle zur Programmierung verwenden. Ich verwende die allerdings nicht.
Besonders gut dafür eignet sich für eine solche Programmierung Node Red. Das ist genau dafür gemacht. Ich empfehle dazu mal in YouTube ein paar Videos anzuschauen. Da fragt zwar keiner Pooltemperaturen ab, aber das Prinzip wird damit ganz schnell klar.
Für Node Red sind minimale Javascript-Kenntnisse von Vorteil. Wenn man das nicht kann, muss man es lernen. Für deine eher simple Aufgabe ist da nicht viel Lernerei vonnöten. Immerhin willst du keine komplexen Programme schreiben, sondern nur eine simple Stringmanipulation bauen. Ich verwende es zusammen mit einer Lametric: ich frage den Fahrplan der Bundesbahn ab, ob die S4 in Frankfurt Süd pünktlich ist und lasse einen Hinweis ausgeben, wenn das nicht der Fall ist. Das ist etwas aufwändiger als eine Pooltemperatur, aber im Großen und Ganzen das gleiche: ein Wert wird abgefragt, manipuliert und ausgegeben.
Ein Javascript-Programm für die Pooltemperatur würde in Node Red wahrscheinlich nur aus zwei Zeilen bestehen, die ungefähr so aussehen könnten (ich hab keine Ahnung von der Abfrage deiner Sensoren und spekuliere mal wild herum):
msg.payload = "Die Pooltemperatur beträgt " + msg.payload.temperature + "º C.";
return msg;
Auch wenn das obige Beispiel bestimmt nicht so aus der Box funktioniert, dürfte es am Ende kaum mehr sein. Den kompletten Rest wie Sensor abfragen und Awtrix ansprechen stellt Node Red bereit. Ohne Gewähr: ich habe nie solche Sensoren wie die deinen eingesetzt und habe auch keine Awtrix).
Node Red kann gleichzeitig mit der Homebridge auf deinem Raspi betrieben werden. Bei mir liefen beide problemfrei auf einem Raspi 3 (jetzt Raspi 4). Eine Installation von Node Red stört die Homebridge nicht. Ein Versuch kann nicht schaden.
Achtung: wer Node Red einsetzt und Javascript programmieren kann, dem steht dann die smarte Welt komplett offen. Was unweigerlich dazu führen wird, das man selbst die krudesten Ideen umsetzen will. Extrem geringer WAF.
Hier meine conifg.json. Hatte ich ohne Fehler getestet.
Ja, die sieht gut aus. Versuche jetzt bitte folgendes: markiere deine oben gepostete config.json, kopiere sie und verwende sie statt der jetzt aktuellen. Dazu gehst du so vor:
Einloggen per ssh auf dem Raspi, dann:
sudo mv /var/homebridge/config.json /var/homebridge/config.json.old
sudo nano /var/homebridge/config.json
Ein leerer Editor wird angezeigt. Jetzt führt du hier deine kopierte Konfiguration ein. Abspeichern und Homebridge neu starten:
sudo systemctl restart homebridge
Wir hatten tatsächlich schon ganz ähnliche Fälle hier, die sich so lösen ließen. Vielleicht klappt das bei dir auch.
Irgendwas drüberinstallieren geht zwar, wird aber nicht helfen.
Kann es noch an was anderem liegen?
In 99% aller Fälle liegt es an einem Sytaxfehler in deiner config.json. Das letzte Prozent ist was Hässliches, das früher gelegentlich auftrat. Dabei handelt es sich um einen nicht sichtbaren Fehler in der config.json. Kein Witz.
Kann man fixen, aber dazu solltest du erstmal deine config.json hier posten. Komplett von oben nach unten. Du kannst sie dir anzeigen lassen mit dem Shell-Befehl cat /var/homebridge/config.json. Bitte keinen Screenshot davon machen.
was kann ich noch tun?
Wahrscheinlich gibst du zum Starten der Homebridge den Befehl homebridge ein. Das könntest du beispielsweise lassen, aber wie schon von @carsten_h bemerkt: bitte mehr Info. Wie hast du die Homebridge installiert?
Folgenden Befehl: "cache_directory": "/var/homebridge/persist/" hatte ich auch schon ausgetauscht, läuft aber auch nicht.
Versuch mal das:
"cache_directory": ""
Die Pfade bei den Docker-Containern unterscheiden sich von denen, die wir hier auf den Raspis benutzen. Letztendlich musst du den Pfad nehmen, der das Home von Homebridge ist und den kannst du sehen, wenn du homebridge-config-ui-x verwendest. Da steht er auf der linken Seite als "Speicherpfad".
Also, ich lass mir die Adressen mit sudo hcitool lescan anzeigen. Hab ich was übersehen, dass ihr das alle nicht benutzt? Das hakelt manchmal ein bisschen, dann mit control-c (ctrl-c, strg-c) abbrechen und erneut starten.
pi@homepi:~ $ sudo hcitool lescan
LE Scan ...
37:BF:D4:92:31:07 (unknown)
C8:69:CD:5B:6B:30 (unknown)
C8:69:CD:5B:6B:30 (unknown)
DD:BA:5D:2B:91:F9 (unknown)
DD:BA:5D:2B:91:F9 Hue Lamp
E4:FC:66:1E:5E:3E (unknown)
B8:09:8A:D3:5F:B2 (unknown)
B8:09:8A:D3:5F:B2 (unknown)
D3:9C:6A:AB:1B:27 Eve
D3:9C:6A:AB:1B:27 Eve Energy 1698
E4:FC:66:1E:5E:3E (unknown)
C4:7C:8D:67:3E:5B (unknown)
C4:7C:8D:67:3E:5B Flower care
Du hast Glück. Ich kann hier nicht Herzchen und Trophäe gleichzeitig vergeben. Das würdest Du sonst nicht aushalten.
Lol, da bin ich ja noch einmal gerade so davon gekommen 
Mir fällt leider auch nichts ein, aber ich betreibe sogar drei Raspis mit Homebridges, alle auf 1.1.0 und habe diese Probleme nicht. Ich glaube oft, dass es weniger an der Homebridge liegt als an HomeKit selbst, was das Debugging sehr schwer machen sollte.
