* Demo-Modus-Abschnitt an den tatsächlichen Code angeglichen: Schalter in
den Einstellungen (für lokal installierte Builds ohne Xcode) und
Umgebungsvariable, beide dokumentiert.
* Quelle für den Votronic-Solarregler ergänzt (syssi/esphome-votronic),
eigener Abschnitt analog zu Kühlbox/WattCycle.
* Persönlichen Pfad aus der Bauanleitung entfernt (open VanControl.xcodeproj
statt eines lokalen Nutzerpfads); Beispiel-Bundle-ID im Demo-Modus-Befehl
durch Platzhalter ersetzt.
Zusätzlich: Symbolliste für Fahrzeugprofile auf Wunsch exakt auf die aus
solar-integration zurückgesetzt (car, car.side, suv.side, truck.pickup.side,
box.truck, bus), statt sie mit dev_watchs Liste zusammenzuführen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Drei vom Nutzer im Testbuild gefundene Fehler:
* DeviceStore.save() schrieb auch im Demo-Modus in UserDefaults. Jede
Änderung während aktivem Demo-Modus (z.B. Fahrzeuggrafik oder
Einbaulage ändern) persistierte damit die erfundenen Fahrzeuge/Geräte
dauerhaft – sie blieben nach dem Deaktivieren des Demo-Modus stehen.
save() ist jetzt im Demo-Modus ein no-op.
* Die Kühlbox-Schalter (Ein/Aus, Eco/Max, Solltemperatur, Sperre) liefen
über sendFridgeSettings(), das eine echte Bluetooth-Verbindung
voraussetzt (`managed`-Eintrag) – im Demo-Modus gibt es die nie, die
Schalter taten also nichts. Im Demo-Modus wird der angezeigte
AlpicoolState jetzt direkt geändert, ohne den Umweg über einen
Stellbefehl.
* Der Live-Activity-Schalter liess sich nicht einschalten, weil dem
Haupt-App-Target der Info.plist-Schlüssel NSSupportsLiveActivities
fehlte – Activity.request() wirft ohne ihn, wird aber vom Aufrufer
stillschweigend abgefangen, sodass der Schalter beim Antippen einfach
auf Aus zurückspringt.
Build (App + Watch) und Tests grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Drei Dateien aus solar-integration wurden beim Zusammenführen mit
dev_watch übersehen, weil sie fälschlich als "identisch zwischen den
Branches" eingestuft wurden:
* DemoData.isEnabled kannte nur noch den Umgebungsvariablen-Weg
(CAMPER_DEMO=1). Der Schalter in den Einstellungen – der einzige Weg,
Demo-Daten auf einem lokal installierten Build ohne Xcode-Verbindung
einzuschalten – fehlte ganz, SettingsView.swift war nie zusammengeführt
worden.
* LevelSetupView.swift fehlte der komplette Abschnitt "Fahrzeuggrafik" –
die Kachel-Auswahl zwischen den VehicleGraphicStyle-Varianten
(Vanster/California). Das Feld existierte im Modell und wurde beim
Rendern gelesen, war aber nirgends einstellbar.
* DeviceCard.swift zeigte die Nivellierungs-Kachel wie jedes andere
Gerät (Hauptwert + Nebenwerte) statt der grossen Front/Heck- und
Links/Rechts-Anzeige mit Richtungsbuchstaben.
Anlass: Im Testbuild fehlte deshalb sowohl der Demo-Modus als auch die
Fahrzeuggrafik-Auswahl. Als Konsequenz systematisch alle beim Merge als
"bereits identisch" eingestuften Dateien erneut gegengeprüft – keine
weiteren Lücken gefunden.
Build (App + Watch) und Protokoll-Tests grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
LevelActivityManager.update() stiess bei jeder Messung sofort
activity.update() an – der Neigungsmesser liefert per Notify oder
0,5s-Poll deutlich öfter als einmal pro Sekunde. Bei dieser Frequenz
drosselt iOS lokale Live-Activity-Aktualisierungen zunehmend selbst,
was in CarPlay auffiel: Das Dashboard zeigt neue Werte dort spürbar
verzögert an, weil es ohnehin zurückhaltender aktualisiert als
Sperrbildschirm oder Dynamic Island und die Drosselung dadurch sichtbar
wird.
Jetzt wird höchstens einmal pro Sekunde tatsächlich aktualisiert;
Messungen innerhalb der Sperrfrist werden nicht verworfen, sondern der
neueste Stand fürs Fristende vorgemerkt (wie schon beim
Verbindungsabbruch mit `pendingEnd` gehandhabt).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nach dem Entfernen der Beispiel-Widget/-Control-Dateien enthielt
VanControlWidget(Extension) nur noch die Live Activity – der Name war
damit irreführend. Jetzt VanControlLiveActivity(Extension) durchgängig:
Ordner, Target, Produkt, Bundle-ID-Suffix, Dateien
(VanControlLiveActivity.swift, VanControlLiveActivityBundle.swift) und
Anzeigename ("VanControl Live Activity").
Build (App Debug+Release, Watch) und Protokoll-Tests grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
VanControlWidget.swift, VanControlWidgetControl.swift und AppIntent.swift
waren unverändertes Xcode-Vorlagenmaterial ("Favorite Emoji", "This is
an example widget", ein Timer-Control ohne echte Funktion) – nie an die
App angebunden. Die Extension bleibt bestehen, weil die Live Activity
(VanControlWidgetLiveActivity, echte Neigungswerte) dort hinein muss;
das Bundle enthält jetzt nur noch sie.
Build (Debug + Release) grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CamperMonitor (Haupt-Repo) und VanAligneiOS (aus dem gemergten
solar-integration-Branch) liefen unter zwei verschiedenen internen
Namen, obwohl die App nach aussen längst einheitlich "VanControl Pro"
heisst. Jetzt durchgängig VanControl:
- Ordner: CamperMonitor/, CamperMonitorWatch/, CamperMonitorComplication/,
VanAligneiOSWidget/ → VanControl/, VanControlWatch/,
VanControlComplication/, VanControlWidget/
- Xcode-Projekt: CamperMonitor.xcodeproj → VanControl.xcodeproj, alle
Targets/Schemes/Produktnamen entsprechend umbenannt
- Bundle-Identifier auf Wunsch mitgeändert: de.s0.fototeddy.VanControl*
(App noch nicht veröffentlicht); dabei auch die
WKCompanionAppBundleIdentifier-Werte korrigiert, die noch das alte
de.fritob-Präfix statt des tatsächlichen de.s0.fototeddy-Präfixes
trugen
- Swift-Dateien/Typen: CamperMonitorApp → VanControlApp,
VanAligneiOSWidget* → VanControlWidget*
- Config/*-Info.plist umbenannt, README.md/Tools/README.md/run-tests.sh
auf die neuen Pfade angepasst
Bewusst unverändert: firmware/vanalign und alle Bezüge auf "VanAlign"
als Namen der Neigungsmesser-Hardware (eigenständiges Produkt, kein
App-Name) sowie der komplette Android/-Ordner.
Build (App, Watch, Debug) und Protokoll-Testlauf grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
.solarCharger und .solar sahen im Code zu ähnlich aus, um auf einen
Blick zu erkennen, welches der Victron-Solarladeregler (passives
BLE-Advertisement) und welches der Votronic-Solarladeregler (aktive
GATT-Verbindung über die ESP32-Bridge) ist. Jetzt .victronSolarCharger
und .votronicSolar, samt allen abgeleiteten Bezeichnern in DemoData,
WatchDemo und Tests. Die rawValues bleiben "solarCharger"/"solar", damit
bereits gespeicherte Geräte beim Decodieren nicht auf einen unbekannten
Rollen-Wert treffen.
VictronAdvertisement.RecordType.solarCharger (das rohe Protokollfeld)
bleibt unverändert – schon durch den Typnamen eindeutig, und passend
zur offiziellen Victron-Bezeichnung des Datensatztyps.
run-tests.sh fehlten VehicleGraphicStyle.swift und VehicleTilt.swift,
seit ConfiguredDevice sie referenziert – ergänzt, Testlauf grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
solar-integration (aus dem separaten VanAligneiOS-Repo) und dev_watch
haben unabhängige Git-Historien, decken aber überlappende und sich
ergänzende Funktionen ab. Übernommen aus solar-integration: Votronic-
Solar-ESP-Anbindung samt Geräterolle, die Live-Activity/Widget-Extension
fürs Sperrbildschirm/Dynamic-Island/CarPlay, das Querformat-Layout für
Libelle/Fahrzeug-Ansicht und Ausrichtungs-Assistent, sowie die
mehreren Fahrzeuggrafik-Stile (Vanster/California). Beibehalten aus
dev_watch: alle zusätzlichen Geräteprotokolle (Daly-/JBD-BMS, Alpicool-
Kühlbox, WattCycle, Victron), die dort zwischenzeitlich entstanden.
Die Xcode-Projektdatei wurde von Hand um die neue Widget-Extension samt
SharedActivity-Gruppe erweitert (Datei-synchronisierte Gruppen, kein
App-Group-Entitlement nötig). Build für App, Watch und Widget-Extension
geprüft (Debug und Release).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
