Tweet
Ich habe mir einen neuen Orange PI zero 3 besorgt, um via Loxberry mit BLE meinen Tesla in Loxone einbinden zu können. Bei der Entwicklung des Plugins habe ich den Loxberry intensiv genutzt und möchte meine Erfahrungen teilen.
Den Loxberry habe ich neu mit dem passenden Image "DietPi_OrangePiZero3-ARMv8-Bookworm.img.xz" installiert - DietPi v9.7.1, Orange Pi Zero 3 (aarch64), Kernel 6.6.31-current-sunxi64 mit Loxberry Version v3.0.1.2.
1. Das Verzeichnis /lib/firmware/uwe5622 fehlte nach der Installation der Loxberry Software (wget .../Loxberry_Installer/main/install.sh ...). Das Verzeichnis ist bei dem verwendeten Orange PI zero 3 für den Bluetooth Treiber erforderlich. Ich habe das DietPI Image daraufhin neu installiert, das Verzeichnis gesichert und nach der Installation des Loxberry Skriptes wieder hergestellt.
2. Mosquitto MQTT Broker: der Dienst lief, aber im Skript (/lib/systemd/system/mosquitto.service) werden Leserechte nur für den User "mosquitto" vergeben. Das ist wahrscheinlich der Grund, dass in der GUI im Loxberry im Menü "MQTT - Log Files" die Logs nicht angezeigt werden können und fehlten. Ich habe dann Rechte auf Linux CLI geändert, allerdings erhalte ich noch immer eine Fehlermeldung mit dem Befehl journalctl -u mosquitto.service (als root):
Oct 14 00:17:17 loxberry systemd[1]: Starting mosquitto.service - Mosquitto MQTT Broker...
Oct 14 00:17:18 loxberry mosquitto[870]: 1728857838: Loading config file /etc/mosquitto/conf.d/mosq_mqttgateway.conf
Oct 14 00:17:18 loxberry mosquitto[870]: 2024-10-14T00:17:18: Error: Unable to open log file /var/log/mosquitto/mosquitto.log for writing.
Oct 14 00:17:19 loxberry systemd[1]: Started mosquitto.service - Mosquitto MQTT Broker.
Der Dienst läuft wohl mit dem User "mosquitto" und es gibt einen link vom o.a. Verzeichnis auf /opt/loxberry/log/system_tmpfs/mosquitto.log.
3. Mosquitto MQTT Broker: nachdem ich in der GUI in den Basic Settings (MQTT Basics) die Einstellung "Use custom ..." gewählt hatte, fehlte plötzlich der "localhost". Wahrscheinlich fehlte der localhost Eintrag schon vorher, aber es wurde ein anderer Wert im Loxberry im Default hinterlegt (z.B. IP-Adresse ?). Ich meine, dass ein Ändern in "Use and automatically ..." das Problem nicht mehr gelöst hat, aber da bin ich mir nicht mehr sicher. Ich bekam Fehlermeldungen in meinem Plugin, weil kein MQTT Connect mehr funktionierte und vermutete zunächst ein Problem mit dem Kennwort, allerdings stellte sich heraus, dass der Loxberry den "localhost" nicht kannte. Ein manueller Eintrag "127.0.0.1 localhost" in der /etc/hosts hat das Problem behoben, aber es hat länger gedauert, bis ich die Ursache fand. Ein "ping localhost" auf der Linux CLI zeigte mir am Ende die Ursache.
4. MQTT: Im Menü "MQTT Gateway - Incoming Overview" wurden alle Elemente als "not send yet (cached)" angezeigt, obwohl Werte bereits im MS angekommen waren. Ursache ist wohl, dass das 'switch / case Statement' in /opt/loxberry/templates/system/mqtt-gateway.html nicht richtig lief, weil der Wert der Variable [I]toMSarr.code als String ankam, aber in den case-Statements nur Werte abgefragt wurden und daher immer der Default ausgewählt wurde. Die folgenden Befehle (mit der hinzugefügten Variablen toMScode) ab Zeile 584 haben das korrigiert:
Vielleicht kann man das Problem auch anders lösen, aber seitdem werden alle Elemente richtig mit HTTP 200 oder 404 Antworten und den entsprechenden Symbolen bei mir angezeigt.
5. Min Memory: Im Menü "Loxberry Services, Watchdog" werden per Default 10.000 Seiten als Free Memory mit dem Hinweis: Minimum free memory. Note that this is in pages (1 page = 4096 kB). So 10000 here is 40 MB. Das ist nicht richtig, denn 1 Seite sind 64KB, d.h. 640MB müssten per Default mindestens frei sein, da ansonsten ein Reload ausgelöst wird. Den Wert habe ich auf 1000, also 64MB reduziert, aber es sollte die Hilfe und der Default angepasst werden. Das von mir angeschaltete Log zeigte nähere Infos zur Größe einer Seite:
Insgesamt noch einmal vielen Dank an alle Entwickler des Loxberrys! Ich nutze den jetzt seit einigen Jahren und konnte mit dem die Funktionalität des Miniservers erheblich erweitern! Da mich das Parsen von Inputs schon immer ziemlich umständlich und aufwändig fand, nutze ich MQTT immer stärker, um Werte vom Loxberry an meinen MS über virtuelle Eingänge bzw. Texteingänge weiterzugeben. Virtuelle HTTP Eingänge mit zugehörigen HTTP Eingangsbefehlen gehen auch, aber leider nicht für Texte. Dafür sind die einzelnen Elemente gruppiert.
Am Rande noch meine Meinung zum Orange PI zero 3: den hatte ich als günstiges Device mit LAN-Schnittstelle und BLE v5.0 Interface mit Antenne ausgewählt, um einen eigenen dedizierten Loxberry zu haben, der in der Nähe des Autos installiert wurde. Über das von mir weiterentwickelte Loxberry Tesla Plugin kommuniziert der Loxberry mit meinem Tesla via BLE. Ich bin allerdings sehr enttäuscht von der Stabilität des Orange PI.
Anfänglich hatte ich massive Probleme mit dem o.a. aktuellen Image vom DietPI die BLE Schnittstelle überhaupt zum Laufen zu bekommen, danach Probleme mit der BLE Bibliothek von Golang, die von der Software des Tesla SDK verwendet wird. Die BLE Bibliothek hat sich auf dem Orange PI anders verhalten, als auf einem Raspberry PI 3 mit BLE v4.2 Interface. Ob es am Treiber liegt oder der Hardware, das kann ich nicht sagen, aber der Hersteller scheint wenig / gar keinen Support für aktuelle Linux Distributionen zu liefern. Der OrangePI hängt sich des öfteren auf, so dass ich ihn jede Nacht neu starte. Trotzdem kommt es gelegentlich vor, dass sich das Webinterface mit Fehler 403 forbidden "aufhängt". SSH funktioniert dann ebenfalls nicht mehr.
Beim Lesen diverser Berichte zu Raspi Alternativen hatte ich Probleme mit der Stabilität und Treibern nicht so richtig wahrgenommen. Bei gezielter Suche finden sich diverse Beiträge (z.B. im Armbian Forum), wo die fehlende Unterstützung der Hersteller für aktuelle Linux Distributionen bemängelt wird. Ein 'dirty-hack' Image einer alten Linux Version auf der Webseite des Herstellers und zugehörige Treiber helfen einem nicht weiter, wenn man eine aktuelle Linux Version wünscht. Vielleicht wechsle ich noch auf einen Raspi zero 2, auch wenn der kein LAN-Interface und keine externe WLAN/BLE Antenne hat?
Den Loxberry habe ich neu mit dem passenden Image "DietPi_OrangePiZero3-ARMv8-Bookworm.img.xz" installiert - DietPi v9.7.1, Orange Pi Zero 3 (aarch64), Kernel 6.6.31-current-sunxi64 mit Loxberry Version v3.0.1.2.
1. Das Verzeichnis /lib/firmware/uwe5622 fehlte nach der Installation der Loxberry Software (wget .../Loxberry_Installer/main/install.sh ...). Das Verzeichnis ist bei dem verwendeten Orange PI zero 3 für den Bluetooth Treiber erforderlich. Ich habe das DietPI Image daraufhin neu installiert, das Verzeichnis gesichert und nach der Installation des Loxberry Skriptes wieder hergestellt.
2. Mosquitto MQTT Broker: der Dienst lief, aber im Skript (/lib/systemd/system/mosquitto.service) werden Leserechte nur für den User "mosquitto" vergeben. Das ist wahrscheinlich der Grund, dass in der GUI im Loxberry im Menü "MQTT - Log Files" die Logs nicht angezeigt werden können und fehlten. Ich habe dann Rechte auf Linux CLI geändert, allerdings erhalte ich noch immer eine Fehlermeldung mit dem Befehl journalctl -u mosquitto.service (als root):
Oct 14 00:17:17 loxberry systemd[1]: Starting mosquitto.service - Mosquitto MQTT Broker...
Oct 14 00:17:18 loxberry mosquitto[870]: 1728857838: Loading config file /etc/mosquitto/conf.d/mosq_mqttgateway.conf
Oct 14 00:17:18 loxberry mosquitto[870]: 2024-10-14T00:17:18: Error: Unable to open log file /var/log/mosquitto/mosquitto.log for writing.
Oct 14 00:17:19 loxberry systemd[1]: Started mosquitto.service - Mosquitto MQTT Broker.
Der Dienst läuft wohl mit dem User "mosquitto" und es gibt einen link vom o.a. Verzeichnis auf /opt/loxberry/log/system_tmpfs/mosquitto.log.
3. Mosquitto MQTT Broker: nachdem ich in der GUI in den Basic Settings (MQTT Basics) die Einstellung "Use custom ..." gewählt hatte, fehlte plötzlich der "localhost". Wahrscheinlich fehlte der localhost Eintrag schon vorher, aber es wurde ein anderer Wert im Loxberry im Default hinterlegt (z.B. IP-Adresse ?). Ich meine, dass ein Ändern in "Use and automatically ..." das Problem nicht mehr gelöst hat, aber da bin ich mir nicht mehr sicher. Ich bekam Fehlermeldungen in meinem Plugin, weil kein MQTT Connect mehr funktionierte und vermutete zunächst ein Problem mit dem Kennwort, allerdings stellte sich heraus, dass der Loxberry den "localhost" nicht kannte. Ein manueller Eintrag "127.0.0.1 localhost" in der /etc/hosts hat das Problem behoben, aber es hat länger gedauert, bis ich die Ursache fand. Ein "ping localhost" auf der Linux CLI zeigte mir am Ende die Ursache.
4. MQTT: Im Menü "MQTT Gateway - Incoming Overview" wurden alle Elemente als "not send yet (cached)" angezeigt, obwohl Werte bereits im MS angekommen waren. Ursache ist wohl, dass das 'switch / case Statement' in /opt/loxberry/templates/system/mqtt-gateway.html nicht richtig lief, weil der Wert der Variable [I]toMSarr.code als String ankam, aber in den case-Statements nur Werte abgefragt wurden und daher immer der Default ausgewählt wurde. Die folgenden Befehle (mit der hinzugefügten Variablen toMScode) ab Zeile 584 haben das korrigiert:
Code:
var toMShighest = 0;
var toMScode = 0;
if( typeof resp.http[topic].toMS != 'undefined' && typeof resp.http[topic].regexfilterline == 'undefined' && typeof resp.doNotForward[topic] == 'undefined' ) {
toMSarr = resp.http[topic].toMS;
var httpSubmitAdvTabInfRow = "";
for( i in toMSarr ) {
// console.log( topic, i, toMSarr[i].code );
if( isNaN(toMSarr[i].code) )
toMScode = 0;
else
toMScode = parseInt(toMSarr[i].code);
if( toMScode > toMShighest )
toMShighest = toMScode;
switch( toMScode ) {
case 404:
httpSubmitIcon = 'icon-notfound.png'; httpSubmitText = 'MS'+i+': HTTP 404 Input not available';
break;
case 401:
5. Min Memory: Im Menü "Loxberry Services, Watchdog" werden per Default 10.000 Seiten als Free Memory mit dem Hinweis: Minimum free memory. Note that this is in pages (1 page = 4096 kB). So 10000 here is 40 MB. Das ist nicht richtig, denn 1 Seite sind 64KB, d.h. 640MB müssten per Default mindestens frei sein, da ansonsten ein Reload ausgelöst wird. Den Wert habe ich auf 1000, also 64MB reduziert, aber es sollte die Hilfe und der Default angepasst werden. Das von mir angeschaltete Log zeigte nähere Infos zur Größe einer Seite:
2024-10-14T00:00:35.344900+02:00 loxberry watchdog[1077]: starting daemon (5.16):
2024-10-14T00:00:35.345069+02:00 loxberry watchdog[1077]: int=10s realtime=yes sync=no load=80,60,40 soft=no
2024-10-14T00:00:35.345196+02:00 loxberry watchdog[1077]: memory: minimum pages = 1000 free, 0 allocatable, max swap 0 (65536 byte pages)
2024-10-14T00:00:35.345069+02:00 loxberry watchdog[1077]: int=10s realtime=yes sync=no load=80,60,40 soft=no
2024-10-14T00:00:35.345196+02:00 loxberry watchdog[1077]: memory: minimum pages = 1000 free, 0 allocatable, max swap 0 (65536 byte pages)
Am Rande noch meine Meinung zum Orange PI zero 3: den hatte ich als günstiges Device mit LAN-Schnittstelle und BLE v5.0 Interface mit Antenne ausgewählt, um einen eigenen dedizierten Loxberry zu haben, der in der Nähe des Autos installiert wurde. Über das von mir weiterentwickelte Loxberry Tesla Plugin kommuniziert der Loxberry mit meinem Tesla via BLE. Ich bin allerdings sehr enttäuscht von der Stabilität des Orange PI.
Anfänglich hatte ich massive Probleme mit dem o.a. aktuellen Image vom DietPI die BLE Schnittstelle überhaupt zum Laufen zu bekommen, danach Probleme mit der BLE Bibliothek von Golang, die von der Software des Tesla SDK verwendet wird. Die BLE Bibliothek hat sich auf dem Orange PI anders verhalten, als auf einem Raspberry PI 3 mit BLE v4.2 Interface. Ob es am Treiber liegt oder der Hardware, das kann ich nicht sagen, aber der Hersteller scheint wenig / gar keinen Support für aktuelle Linux Distributionen zu liefern. Der OrangePI hängt sich des öfteren auf, so dass ich ihn jede Nacht neu starte. Trotzdem kommt es gelegentlich vor, dass sich das Webinterface mit Fehler 403 forbidden "aufhängt". SSH funktioniert dann ebenfalls nicht mehr.
Beim Lesen diverser Berichte zu Raspi Alternativen hatte ich Probleme mit der Stabilität und Treibern nicht so richtig wahrgenommen. Bei gezielter Suche finden sich diverse Beiträge (z.B. im Armbian Forum), wo die fehlende Unterstützung der Hersteller für aktuelle Linux Distributionen bemängelt wird. Ein 'dirty-hack' Image einer alten Linux Version auf der Webseite des Herstellers und zugehörige Treiber helfen einem nicht weiter, wenn man eine aktuelle Linux Version wünscht. Vielleicht wechsle ich noch auf einen Raspi zero 2, auch wenn der kein LAN-Interface und keine externe WLAN/BLE Antenne hat?
Kommentar