forked from fritob/Camper-Monitor
BiasFandClaude Opus 5
0e05ca22d7
Zwei Dinge in einem Commit, weil sie sich dieselben Dateien teilen: project.pbxproj und WatchRootView.swift tragen beides. **Komplikation.** Neues Target CamperMonitorComplication, auf watchOS sind Komplikationen WidgetKit-Widgets. Es wird in die Watch-App eingebettet (PlugIns) und bietet die vier Zubehör-Familien an. Ein Tipp öffnet die App direkt auf der Nivellierung statt in der Geräteliste: Die Komplikation hängt eine Adresse an, die Watch-App führt dafür jetzt einen Navigationsweg, den sie von aussen setzen kann. Die Adresse steht in Shared/WatchDeepLink.swift, weil beide Seiten sie brauchen – ein Tippfehler auf einer Seite bliebe sonst stumm. Bewusst ohne Messwert: Eine Komplikation läuft in einem eigenen Prozess und käme an die Werte nur über eine App-Gruppe, und die verlangt eine bezahlte Mitgliedschaft. Ein Wert, der beim Blick aufs Zifferblatt Stunden alt sein kann, wäre ohnehin schlimmer als keiner – man glaubt ihm. Die Komplikation tut deshalb genau eine Sache, und die zuverlässig. **Rebranding.** Der sichtbare Name ist überall VanControl Pro: CFBundleDisplayName beider Apple-Targets, Android-Label, die Texte in beiden Apps, beide READMEs und der Name der APK im Gitea-Ablauf. Die Kennungen bleiben, wie sie sind – Bundle-IDs, Android-Paket, Target-, Ordner- und Schemanamen. Eine geänderte Bundle-ID ist für iOS eine neue App: Geräte, Fahrzeugprofile und Victron-Schlüssel wären weg, dazu neue Profile und eine neu zu koppelnde Watch-App. Sichtbar ist davon nichts, also gibt es dafür auch keinen Grund. Geprüft: alle drei Apple-Targets bauen, die Erweiterung liegt im Watch-Bundle unter PlugIns, die Anzeigenamen stimmen im gebauten Bundle, Tests grün. Die neue Bundle-ID der Erweiterung braucht beim ersten Lauf aus Xcode ein Profil, das Xcode selbst anlegt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
96 lines
3.6 KiB
Markdown
96 lines
3.6 KiB
Markdown
# VanAlign Pro – Neigungsmessung für den Camper
|
||
|
||
ESP32-S3 mit MPU6050, der Längs- und Querneigung des Fahrzeugs misst und über
|
||
Bluetooth bereitstellt. Zum Ausrichten beim Parken: die Anzeige zeigt, welche
|
||
Seite höher steht und wie weit es noch ist.
|
||
|
||
> Teile dieses Projekts wurden mit KI-Unterstützung erstellt.
|
||
|
||
## Firmware
|
||
|
||
`esp32_ble.yaml` – die einzige Datei, die für den Betrieb gebraucht wird.
|
||
|
||
```bash
|
||
cd firmware/vanalign
|
||
esphome run esp32_ble.yaml
|
||
```
|
||
|
||
### Bluetooth-Schnittstelle
|
||
|
||
Dienst `2a24b789-7aab-4535-af3e-ee76a35cc42d` (wird beworben, das Gerät ist
|
||
darüber auffindbar).
|
||
|
||
| Charakteristik | UUID (Ende) | Zugriff | Inhalt |
|
||
|---|---|---|---|
|
||
| Pitch | `…3424` | lesen | Längsneigung, Float32 little-endian, Grad |
|
||
| Roll | `…3425` | lesen | Querneigung, Float32 little-endian, Grad |
|
||
| Kalibrieren | `…3427` | schreiben | ein Byte: `0` setzt zurück, alles andere kalibriert |
|
||
|
||
Der Client fragt Pitch und Roll im Takt ab; VanControl Pro tut das zweimal je
|
||
Sekunde.
|
||
|
||
Positiver Pitch heißt: das Heck steht höher. Positiver Roll: die rechte Seite
|
||
steht höher.
|
||
|
||
### Kalibrierung
|
||
|
||
Fahrzeug eben stellen, dann ein beliebiges Byte ungleich `0` auf `…3427`
|
||
schreiben – oder in VanControl Pro auf *Auf aktuelle Lage kalibrieren* tippen.
|
||
Die Offsets werden dauerhaft gespeichert und überstehen einen Neustart.
|
||
|
||
## Was sich gegenüber 1.0 geändert hat
|
||
|
||
Bewusst wenig – siehe unten.
|
||
|
||
* **Kalibrierung funktioniert jetzt überhaupt.** Die Charakteristik `…3427` war
|
||
zwar beschreibbar, hatte aber keine Aktion hinterlegt und tat nichts. Der
|
||
Kalibrier-Knopf war nur über den Webserver erreichbar, der auskommentiert
|
||
ist – kalibrieren war damit auf keinem Weg möglich.
|
||
* **Der ESP-NOW-Rest ist entfernt.** Er schickte bei jedem einzelnen Messwert
|
||
ein `"hallo"` an eine fest eingetragene MAC-Adresse.
|
||
|
||
## Was bewusst nicht geändert wurde
|
||
|
||
Eine weitergehende Fassung hatte `notify` auf Pitch und Roll, setzte die Werte
|
||
aktiv bei jeder Messung und stellte die Kalibrier-Offsets zum Auslesen bereit.
|
||
Sie liess sich mit `esphome config` prüfen und fehlerfrei übersetzen – auf dem
|
||
Gerät blieb sie danach jedoch stumm, ohne jede Ausgabe über die serielle
|
||
Schnittstelle.
|
||
|
||
Woran genau es lag, ist offen. Verdächtig sind das Setzen der Werte aus dem
|
||
`on_boot`-Ablauf heraus, bevor der BLE-Server bereit ist, sowie zwei
|
||
Benachrichtigungen zehnmal je Sekunde. Weil sich das nur am Gerät klären lässt,
|
||
bleibt es beim bewährten Aufbau: Pitch und Roll sind reine Lesewerte mit
|
||
hinterlegtem Ausdruck, der Client fragt ab.
|
||
|
||
Die verworfene Fassung ist in der Projektgeschichte unter *Neigungsmesser
|
||
VanAlign einbinden* nachlesbar, falls jemand daran weiterarbeiten will.
|
||
|
||
Die UUIDs sind unverändert, die vorhandene WebApp läuft weiter.
|
||
|
||
## Clients
|
||
|
||
* **VanControl Pro** (iOS) – die App in diesem Projekt. Geräteart
|
||
*Nivellierung*: grafische Libelle, Kalibrierung aus der App, zusammen mit
|
||
den übrigen Geräten im Fahrzeug.
|
||
* Die ursprüngliche WebBLE-Oberfläche liegt weiterhin im Projekt
|
||
`VanAllign-Pro` unter `WebAPP/`.
|
||
|
||
## Weitere Dateien
|
||
|
||
Unter `experimente/` liegen `esp32_switch.yaml` (Umschalten zwischen WLAN und
|
||
BLE) und `esp32_EspNow-rec.yaml` (ESP-NOW-Empfänger). Beide gehören nicht zum
|
||
Neigungsmesser und werden für den Betrieb nicht gebraucht – sie sind nur
|
||
aufgehoben, weil sie Ideen aus der Entstehungszeit festhalten.
|
||
|
||
## Herkunft
|
||
|
||
Übernommen aus dem eigenständigen Projekt `VanAllign-Pro`. Dort liegen
|
||
weiterhin die WebBLE-Oberfläche (`WebAPP/`, durch die iOS-App abgelöst) und
|
||
unter `bin/` die gebauten Binärdateien der Version 1.0.
|
||
|
||
## Voraussetzungen
|
||
|
||
* ESP32-S3, MPU6050 an I²C (SDA GPIO8, SCL GPIO9)
|
||
* ESPHome (geprüft mit 2026.6.5)
|