Neues Plugin für Tesla mit Vehicle Command API

[blaess]

Die Wake-Up Funktion ist übrigens im Plugin mittlerweile enthalten, allerdings habe ich die noch nicht intensiv getestet, weil ich diverse Probleme mit der Stabilität auf dem Orange PI hatte. Das liegt aber nicht am Loxberry oder Plugin, sondern aus meiner Sicht an den Treibern für BLE.
...

Meine Installation auf dem Pi Zero 2 läuft sehr stabil.
In welcher Version ist die Wake-Up Funktion enthalten? Ich finde nur 0.1.9.

[Jan W.]

Ja, genau 0.1.9. Mit der Funktion Test-Query kann man das auch aus der GUI testen, z.B. mit PING und den Haken bei Wake-Up setzen.

[blaess]

Habe es heute getestet, leider ohne Erfolg.
Ich kann den Charge Port nur öffnen, wenn ich vorab ein "BLE_WAKE" schicke und 6 Sekunden warte vor dem "CHARGE_PORT_DOOR_OPEN".

[Jan W.]

Die 'wake up' Funktion via 'force=true' hatte noch ein Problem, welches hoffentlich mit der 0.2.1 beseitigt ist.

blaess: Geht es jetzt bei Dir?

[blaess]

Bin noch am Testen. Gestern hatte ich Probleme. Tesla wird geweckt, Charge Port ging aber nicht auf.
Heute Morgen hat es funktioniert.

[blaess]

Hier wieder ein Feedback. Funktionierte in den letzten Tagen sehr zuverlässig.
Vielen Dank für Deine Arbeit!

In den Logs sehe ich, dass das Plugin alle 60min etwas macht. Manchmal läuft es in einen Timeout Error. Denke aber, dass dies nur kosmetisch ist.

13:10:01.805 INFO: LoxBerry Version 3.0.1.2 ( is_arch_aarch64.cfg is_hwmodel_raspberry_pi_3_3+_zero_2.cfg is_raspberry.cfg )
13:10:01.805 INFO: Tesla Command Version 0.2.1
13:10:01.805 INFO: Loglevel: 6
13:10:01.811 INFO: Check token.
13:10:01.817 OK: MQTT: Connection successful.
13:10:01.826 OK: MQTT: Connection successful.
13:10:01.830 OK: Token valid (2024-10-29T19:10:21).
13:10:01.831 INFO: Read ID to VIN, API mapping, and BLE command.
13:10:01.831 INFO: Query: VEHICLE_SUMMARY: start
13:10:06.877 ERROR: tesla_curl_send: Resolving timed out after 5000 milliseconds
13:10:06.885 OK: MQTT: Connection successful.
13:10:06.887 OK: Query: VEHICLE_SUMMARY: success

[Jan W.]

Hallo blaess,
alle 60min prüft das Plugin, ob der Token noch gültig ist, prüft die MQTT Verbindung und liest die VIN via Owners API mit dem Befehl „vehicle summary“. Früher war die ID wichtig, heute kann die VIN in der Owners API verwendet werden. Die neue vehicle command API verwendet die VIN.

Aus Kompatibilitätsgründen habe ich im Plugin die ID beibehalten (einheitlich für alle Befehle) und daher wird die zugehörige VIN gelesen.

Es sieht bei Dir in Log so aus, als ob der DNS Name manchmal nicht aufgelöst werden kann. Welche DNS Server hast Du im LoxBerry hinterlegt?

[Jan W.]

Ja, das WLAN wäre eine mögliche Ursache. Da DNS via UDP ohne eine gesicherte Verbindung läuft, kommen eher Timeouts, als bei TCP (http Abfrage über curl).

[blaess]

Habe den Pi um 90 Grad gedreht. Der Empfang ist besser und ich habe ich auch weniger Errors/Timeouts im Log.
Seit dem Update auf 2024.38.4 geht der Chargeport nicht mehr auf. Auto wird geweckt, dann muss ich aber noch einmal den Befehl schicken um den Port zu öffnen. Denke aber liegt an Tesla.

[blaess]

Seit ein paar Tagen funktioniert es wieder ohne Probleme.

[verdammt]

Hi, danke für das Plugin, was mache ich den mit dem Standard BLE Command? Das leuchtet mir noch nicht so ganz ein. Ich frage für einen Freund, ich selber hab keinen Tesla zum testen da, werde das Plugin nur einrichten helfen.

Grüße Markus

[Jan W.]

was mache ich den mit dem Standard BLE Command?

Ich verstehe die Frage nicht.

[verdammt]

Das meine ich, es muss ja jetzt noch der Schlüssel erzeugt werden wie im Wiki steht, der muss ja dann auf auto.
Aber was mache ich mit dem Standard BLE Kommando.

[Jan W.]

Das kann i.d.R. so bleiben. Die „custom ble command“ Option ist gedacht, falls Du debugging aktivieren möchtest, eine andere Ordnerstruktur oder andere Namen verwendest.

[Jan W.]

Das liegt daran, dass Tesla bisher nur für Aktionen (Vehicle Control) die API umgestellt hat und (fast) alle Statusabfragen nur über die alte Owner's API möglich sind. Das Plugin verwendet daher die Token für die Owner's API und die Public-/Private-Keys für die Aktionen via BLE. Wenn Du ein Token installiert hast, kannst Du alle Befehle ohne BLE (siehe Queries und Testqueries Menü) verwenden. Der Status wach (online) / schlafend (offline) wird z.B. über Vehicle Summary (ein Befehl der Owner's API) geliefert.

Lediglich ein Befehl (body-controller-state) liefert über BLE sehr begrenzte Statusinformationen. Ladeinformationen, SoC etc. sind weiterhin nur über die Owner's API (Internet) abrufbar. Ich hoffe, dass sich das noch ändern wird, aber das wird wohl eher Jahre als Monate dauern. So üpprig sprudelt das Geld bei Tesla derzeit nicht.

[verdammt]

Ladet ihr eure FZ zuhause mit dem Wallboxbaustein oder ladet ihr an den Tesla Ladestationen, so wie ich meinen Kumpel verstanden hatte, ist bei Tesla z.B. das 1 Jahr laden frei und dann gibt es wohl noch so Pakete.
Dann wird sich ja eine Ladebox zuhause nicht lohnen oder?

[Jan W.]

Ich lade i.d.R. zu Hause und nutze im Sommer PV-Überschuss. Das Laden an Superchargern ist teurer als zu Hause, aber wenn ich 1 Jahr kostenlos laden könnte, dann würde ich die Option sicherlich nutzen.

Es gibt wohl gerade wieder eine begrenzte Aktion: https://www.handelsblatt.com/mobilit...100087569.html

[verdammt]

Vielen Dank, jetzt wird ein Schuh draus.

[Jan W.]

Gestern war ich noch pessimistisch, dass die Statusabfrage via BLE wohl noch dauern würde, aber fast zeitgleich gab es einen Pull-Request zu diesem Thema: https://github.com/teslamotors/vehicle-command/pull/330

Man kann jetzt den Status via BLE abfragen und zwar sehr detailliert! Dafür gibt es in dem Tool 'tesla-contol' den neuen Befehl 'state <category>', der eine der folgenden Kategorien erfordert: charge-schedule, precondition-schedule, media-detail, software-update, climate, drive, tire-pressure, media, parental-controls, charge, closures

Damit wird die alte Owner's API wahrscheinlich kaum noch benötigt. Zumindest zum Laden, wenn das Auto in der Nähe ist, kann man jetzt alles via BLE abfragen und steuern.

Das Plugin ist zwar noch nicht angepasst (wird wohl noch ein paar Tage dauern), aber nachfolgend sind ein paar Ausgaben vom neuen "state" Command zu sehen. Das Kommando funktioniert nur, wenn das Auto wach ist. Daher sollte man den Status nicht ständig abfragen, sondern nur, wenn man z.B. den SoC benötigt.

loxberry@loxberry:~ $ tesla-control -ble -vin LRW30123456789012 -key-file /opt/loxberry/config/plugins/teslacmd/LRW30123456789012-private.pem body-controller-state
{
  "vehicleLockState": "VEHICLELOCKSTATE_LOCKED",
  "vehicleSleepStatus": "VEHICLE_SLEEP_STATUS_ASLEEP",
  "userPresence": "VEHICLE_USER_PRESENCE_NOT_PRESENT"
}
loxberry@loxberry:~ $ tesla-control -ble -vin LRW30123456789012 -key-file /opt/loxberry/config/plugins/teslacmd/LRW30123456789012-private.pem state
Error: context deadline exceeded
loxberry@loxberry:~ $ tesla-control -ble -vin LRW30123456789012 -key-file /opt/loxberry/config/plugins/teslacmd/LRW30123456789012-private.pem wake
loxberry@loxberry:~ $ tesla-control -ble -vin LRW30123456789012 -key-file /opt/loxberry/config/plugins/teslacmd/LRW30123456789012-private.pem body-controller-state
{
  "vehicleLockState": "VEHICLELOCKSTATE_LOCKED",
  "vehicleSleepStatus": "VEHICLE_SLEEP_STATUS_AWAKE",
  "userPresence": "VEHICLE_USER_PRESENCE_NOT_PRESENT"
}
loxberry@loxberry:~ $ tesla-control -ble -vin LRW301234567890123 -key-file /opt/loxberry/config/plugins/teslacmd/LRW301234567890123-private.pem state
Invalid number of command line arguments: 1 (1 required, 0 optional).
Usage: state CATEGORY
Fetch vehicle state over BLE.
CATEGORY: One of charge-schedule, precondition-schedule, media-detail, software-update, climate, drive, tire-pressure, media, parental-controls, charge, closures
Failed to execute command: invalid command line arguments
loxberry@loxberry:~ $ tesla-control -ble -vin LRW301234567890123 -key-file /opt/loxberry/config/plugins/teslacmd/LRW301234567890123-private.pem state charge
{
  "chargeState": {
    "chargingState": {
      "Disconnected": {}
    },
    "chargeLimitSoc": 100,
   "chargeLimitSocStd": 80,
   "chargeLimitSocMin": 50,
   "chargeLimitSocMax": 100,
   "maxRangeChargeCounter": 2,
   "fastChargerPresent": false,
   "batteryRange": 211.37184,
   "estBatteryRange": 165.01318,
   "idealBatteryRange": 211.37184,
   "batteryLevel": 85,
   "usableBatteryLevel": 84,
   "chargeEnergyAdded": 0,
   "chargeMilesAddedRated": 0,
   "chargeMilesAddedIdeal": 0,
   "chargerVoltage": 2,
   "chargerPilotCurrent": 16,
   "chargerActualCurrent": 0,
   "chargerPower": 0,
   "tripCharging": false,
   "chargeRateMph": 0,
   "chargePortDoorOpen": false,
   "scheduledChargingPending": false,
   "chargeEnableRequest": true,
   "chargePortLatch": {
     "Engaged": {}
   },
   "chargePortColdWeatherMode": false,
   "chargeCurrentRequest": 16,
   "chargeCurrentRequestMax": 16,
   "timestamp": "2024-11-17T20:26:33.697Z",
   "preconditioningTimes": {
     "weekdays": {}
   },
   "offPeakChargingTimes": {},
   "scheduledChargingMode": "ScheduledChargingModeOff",
   "chargingAmps": 16,
   "preconditioningEnabled": false,
   "scheduledChargingStartTimeApp": -1,
   "superchargerSessionTripPlanner": false,
   "chargeRateMphFloat": 0,
   "managedChargingState": {
     "chargeOnSolarState": {
       "notAllowed": {}
     },
     "chargeOnSolarGatewayDin": "",
     "teslaElectricAssetId": ""
   },
   "chargeCableUnlatched": false,
   "homeLocation": {
     "latitude": 53.123456,
     "longitude": 10.123456
   },
   "workLocation": {
     "latitude": 53.123456,
     "longitude": 10.123456
   }
  }
}
loxberry@loxberry:~ $ tesla-control -ble -vin LRW301234567890123 -key-file /opt/loxberry/config/plugins/teslacmd/LRW301234567890123-private.pem state climate
{
  "climateState": {
    "insideTempCelsius": 5.5000005,
    "outsideTempCelsius": 3.5,
    "driverTempSetting": 21.5,
    "passengerTempSetting": 21.5,
    "leftTempDirection": 0,
    "rightTempDirection": 0,
    "isFrontDefrosterOn": false,
    "isRearDefrosterOn": false,
    "fanStatus": 0,
    "isClimateOn": false,
    "minAvailTempCelsius": 15,
    "maxAvailTempCelsius": 28,
    "seatHeaterLeft": 0,
    "seatHeaterRight": 0,
    "seatHeaterRearLeft": 0,
    "seatHeaterRearRight": 0,
    "seatHeaterRearCenter": 0,
    "batteryHeater": false,
    "steeringWheelHeater": false,
    "wiperBladeHeater": false,
    "sideMirrorHeaters": false,
    "isPreconditioning": false,
    "remoteHeaterControlEnabled": false,
    "climateKeeperMode": {
      "Unknown": {}
    },
    "timestamp": "2024-11-17T20:26:43.267Z",
    "defrostMode": {
      "Off": {}
    },
   "isAutoConditioningOn": false,
    "autoSeatClimateLeft": true,
    "autoSeatClimateRight": true,
    "allowCabinOverheatProtection": false,
    "supportsFanOnlyCabinOverheatProtection": true,
    "cabinOverheatProtection": "CabinOverheatProtectionOn",
    "cabinOverheatProtectionActivelyCooling": false,
    "copActivationTemperature": "CopActivationTempHigh",
    "autoSteeringWheelHeat": true,
    "steeringWheelHeatLevel": "StwHeatLevel_Off",
    "hvacAutoRequest": "HvacAutoRequestOn",
    "copNotRunningReason": "COPNotRunningReasonNoReason"
  }
}

[Jan W.]

Es gibt eine neue Version 0.2.4 des Plugins, die das Abfragen von Statusinformation über BLE ermöglicht. Die Beschreibung in der LoxWiki ist ebenfalls aktualisiert, siehe https://wiki.loxberry.de/plugins/teslacmd/start

Wg. eines Fehlers in der verwendeten Golang Bluetooth Library (go-ble), habe ich die Library gewechselt auf rigado/ble und dafür den Code des SDKs entsprechend angepasst. Siehe auch https://wiki.loxberry.de/plugins/tes...etooth_library. Der angepasste Code ist unter https://github.com/Jan21493/vehicle-command/ und https://github.com/Jan21493/ble veröffentlicht.

Da meine Entwicklungsumgebung auf einem Raspberry PI 4 mit der 64-Bit Version von Bookworm aus dem DietPI Projekt basiert, ist nur eine angepasste Version des Tools tesla-control für 64-Bit enthalten. Wer das Plugin in einer anderen Umgebung verwendet, muss die Tools neu erstellen. Mit der angepassten Funktion funktioniert z.B. auch die Abfrage, ob der Wagen in der Nähe ist, stabil.

[schindi77]

Hallo!
Ich habe es soweit geschafft, das Plugin zum Laufen zu bringen und Werte vom Fahrzeug abzufragen.

Hier bspw. die Innenraumtemperatur:


Was ich aber nicht schaffe, ist Befehle an das Fahrzeug zu senden. Nachdem ich ein "permission denied" Problem gelöst habe, bekomme ich jetzt folgende Fehlermeldung, egal, ob ich bspw. die Türen versuche zu verschliessen oder den Ladeport zu öffnen:


Fehler ist immer ein "Context deadline exceeded"

Könnt ihr mir helfen rauszufinden, woran das liegen könnte?
Vielen Dank!

[Jan W.]

Ist Dein Fahrzeug wach? Hast Du die Temperatur über BLE abgefragt? Du kannst weiterhin Statusinfos über das Internet (Owner's API) abfragen, aber zum Senden von Befehlen wird BLE verwendet.

In der GUI kannst Du im Tab "Testqueries" die Befehle auswählen und ausführen. Hilfreich wäre noch die Hardware und Version Deines Loxberries inkl. der Info ob es eine 32- oder 64-Bit Version ist. Der Fehler "Context deadline exceeded" kommt immer wenn der Befehl mit einem Timeout abbricht.

Trage bitte "tesla-control -ble -vin {vehicle_tag} -key-file /opt/loxberry/config/plugins/teslacmd/{vehicle_tag}-private.pem -command-timeout 10s -connect-timeout 30s -debug {command}" (ohne Anführungszeichen) in den Settings unter custom BLE command ein. Dann werden Debug-Ausgaben erzeugt. Interessant ist u.a. der Wert "RSSI" der die Empfangsstärke des BLE Signals von Deines Tesla anzeigt. Der Wert wird aber nur angezeigt, wenn es überhaupt eine BLE Verbindung zum Fahrzeug gibt.

Welche "Permission denied" Meldung hattest Du am Anfang gehabt?

[schindi77]

Ist Dein Fahrzeug wach? Hast Du die Temperatur über BLE abgefragt? Du kannst weiterhin Statusinfos über das Internet (Owner's API) abfragen, aber zum Senden von Befehlen wird BLE verwendet.

hmmm....ja...denke ich schon. Ich habe einen virtuellen Eingang in der Loxone mit diesem Befehl, den ich aus dem MQTT-Protokoll vom Loxberry kopiert habe:


Ob Fahrzeug wach oder nicht, machte keinen Unterschied.

Teilweise habe ich es dann doch noch zum Laufen gebracht. Was ich herausgefunden habe und zum Erfolg geführt hat, ist folgendes:
Den http-Sendebefehl muss ich, entgegen der Anleitung zum Plugin, folgendermaßen eingeben, OHNE den "/" vor "admin/plugins/"



So habe ich es, über die Loxone, einige male Geschafft, die Türen zu verriegeln und wieder zu öffnen.

Warum es bis zu einem gewissen Punkt funktioniert hat und dann nicht mehr, kann ich leider nicht sagen, DENN:
Auch zu dem Zeitpunkt, wo es über die Loxone NICHT mehr funktioniert hat, konnte ich über das Plugin-Webinterface ("Testqueries") auf den Wagen zugreifen, womit klar war, dass er online war. Ein Senden des Befehls über den Browser hat ebenfalls zum Erfolg geführt, nicht aber über die Loxone.

Wobei auch das irgendwann nicht mehr funktioniert hat....was mich nun dazu bringt zu denken, daß die Status-Kommandos über das Internet und nicht über ble übertragen werden, weswegen diese funktionieren, nicht aber das Senden von Befehlen?
Vielleicht tatsächlich ein Bluetooth-Empfangsproblem? Siehe weiter unten, dein custom-ble-Kommando muss ich erst testen. Der Wagen steht allerdings nur 3m vom Raspberry 4B entfernt...

In der GUI kannst Du im Tab "Testqueries" die Befehle auswählen und ausführen. Hilfreich wäre noch die Hardware und Version Deines Loxberries inkl. der Info ob es eine 32- oder 64-Bit Version ist. Der Fehler "Context deadline exceeded" kommt immer wenn der Befehl mit einem Timeout abbricht.

Trage bitte "tesla-control -ble -vin {vehicle_tag} -key-file /opt/loxberry/config/plugins/teslacmd/{vehicle_tag}-private.pem -command-timeout 10s -connect-timeout 30s -debug {command}" (ohne Anführungszeichen) in den Settings unter custom BLE command ein. Dann werden Debug-Ausgaben erzeugt. Interessant ist u.a. der Wert "RSSI" der die Empfangsstärke des BLE Signals von Deines Tesla anzeigt. Der Wert wird aber nur angezeigt, wenn es überhaupt eine BLE Verbindung zum Fahrzeug gibt.

Versuche ich sobald ich Zeit habe, ich melde mich.

Welche "Permission denied" Meldung hattest Du am Anfang gehabt?

Ich hatte die Schlüssel blöderweise als root angelegt, somit hatte der user loxberry standardmäßig keinen Zugriff darauf...mein Fehler.

[Jan W.]

In allen Beispielen von HTTP Outputs, die ich gefunden habe, fing der Befehl bei EIN mit einem / an. Bei mir ist der ebenfalls mit dem Slash konfiguriert. Vielleicht fügt Loxone den Slash automatisch hinzu, wenn der HTTP Get Befehl erzeugt wird, so dass beide Varianten erlaubt sind? Es wundert mich daher, warum es bei Dir mit dem vorangestellten / nicht funktioniert hat.

Es gibt einen Monitor in Loxone Config, der die gesendeten HTTP Befehle anzeigt. Wireshark ist etwas besser zur Diagnose geeignet, weil man sieht, was tatsächlich im Netz gesendet wird. Du kannst auch im Browser überprüfen, ob der HTTP Befehl prinzipiell funktioniert, indem Du die Adresse vom virtuellen Ausgang mit dem Befehl kombinierst (ggf. den / ergänzen) und das ganze in einem Browser eingibst. Der Browser sollte ein unformattiertes JSON Objekt zurückgeben, wenn es funktioniert hat.

[schindi77]

Die debug-Ausgabe zeigt mir rssi Werte von -83 bis -96 an, was eher schlecht zu sein scheint nach erster google-Recherche, richtig?

Den Befehl vom Browser aus abgesendet funktioniert meistens, wenn auch der response immer relativ lange dauert, im Bereich 40-50Sekunden.
Ich vermute, daß der Loxberry/Loxone schneller "aufgibt" und den Befehl nicht weitersendet, im Gegensatz zum Browser.
Wenn ich in der Loxone-Config im http-Sendebefehl eine Wiederholung nach 5sek und einen Abstand für die Wiederholung von 5sek eingebe, funktionert es manchmal.

Ich führe es aktuell auf eine schlechte Bluetooth-Verbindung zurück und versuche, hier Besserung zu schaffen. Der Raspberry ist aber wie gesagt nur etwa 3m vom Auto entfernt und "nur" hinter einer Plastikabdeckung versteckt, was ich jetzt als nicht so kritisch sehen würde. Vielleicht ist aber auch das Bluetooth am Raspi selber defekt/schlecht. Ich versuche hier ein anderes Gerät zum Testen aufzutreiben....

[Jan W.]

Die debug-Ausgabe zeigt mir rssi Werte von -83 bis -96 an, was eher schlecht zu sein scheint nach erster google-Recherche, richtig?

Ja, das ist ziemlich schlecht. Ich habe ein Raspberry PI 4 im Metallgehäuse mit externer Antenne, siehe https://geeks-r-us.de/2019/08/31/wla...uer-den-rpi-4/ Die integrierte WLAN / Bluetooth Antenne ist übrigens die kleine Leiterbahn auf der Platine, die auf dem Bild durchtrennt wird. Das Löten des Antennensteckers ist ziemlich frickelig und nur für geübte Bastler zu empfehlen. Ich verstehe nicht, warum die PI Foundation das nicht besser gelöst hat.

Mein Tesla ist ca. 6 Meter entfernt und hinter einer Außenwand. Die Werte schwanken zwischen -65dBm und -74dBm. Wenn ich z.B. den Status in der GUI im Menü Testqueries mit dem Befehl body-controller-state via BLE abfrage, dann dauert es 1-2 Sekunden, bis die Antwort geliefert wird.

Den Befehl vom Browser aus abgesendet funktioniert meistens, wenn auch der response immer relativ lange dauert, im Bereich 40-50Sekunden.
Ich vermute, daß der Loxberry/Loxone schneller "aufgibt" und den Befehl nicht weitersendet, im Gegensatz zum Browser.
Wenn ich in der Loxone-Config im http-Sendebefehl eine Wiederholung nach 5sek und einen Abstand für die Wiederholung von 5sek eingebe, funktionert es manchmal.

In der Loxone Config solltest Du keine kürzeren Intervalle einstellen, als die max. Laufzeit der Befehle, also eher 60 sekunden, denn das BLE Interface wird exklusiv von einem Task bei der Ausführung belegt. Wenn Du den Befehl über den Miniserver sendest, dann wird zwar eine andere URL mit "send.php" verwendet, aber der eigentliche Befehl ist das Utility "tesla-control", welches als ausführbare Datei auf dem Loxberry installiert wird. Der Overhead für das Senden via HTTP vom Miniserver an den Loxberry sollte minimal sein (deutlich unter 1s), sofern die IP-Verbindung stabil ist. Falls der Raspberry via WLAN angeschlossen ist, dann solltest Du die Verbindung prüfen. Mein Raspberry ist via LAN angeschlossen. Du kannst die Befehle auch testweise in einer SSH Sitzung auf dem Loxberry ausführen:

tesla-control -ble -vin LRW30123456789012 -key-file /opt/loxberry/config/plugins/teslacmd/LRW30123456789012-private.pem -debug body-controller-state

Ich frage den Status mit dem Befehl body-controller-state alle 60 Sekunden ab und sende den Wert von "vehicleNearby" an einen Tracker. Bei 1560 Abfragen am Tag gibt es an einigen Tagen ein paar Aussetzer, d.h. Probleme mit der Bluetooth Verbindung. Insgesamt läuft es aber sehr stabil.

Wg. der externen Antenne hatte ich mir ein Orange PI Zero 3 besorgt, aber der BLE Stack ist grottenschlecht und ich bin daher wieder zurück auf einen PI 4 gewechselt.