Jede Verbindung meldet sich am Display der Box an – sie piept, und wer
gerade davorsteht, wird gestört. Dauerhaft verbunden zu sein ist dort
also nicht unsichtbar wie beim BMS, sondern lästig.
Die Kühlbox wird deshalb nur noch verbunden, solange ihre Ansicht offen
ist: am iPhone über die Detailansicht, an der Uhr über einen eigenen
Befehl, den sie beim Öffnen und Schliessen schickt. Ein Stellbefehl geht
weiterhin immer durch – ist die Box nicht verbunden, wird er gemerkt und
löst den Verbindungsaufbau aus.
Abgeriegelt sind alle drei Wege, über die bisher verbunden wurde: beim
Start, im Takt des Wiederverbindens, und – das war das eigentliche Loch –
sobald das Gerät in den Werbedaten auftaucht. Da die App dauerhaft
scannt, hätte allein dieser Weg die Box weiter angefunkt. Dass sie in
Reichweite ist, ist kein Grund, sie anzufassen.
Auf der Übersicht steht dafür der zuletzt gestellte Stand statt der
Messwerte: Sollwert, Ein/Aus, Eco oder Max, dazu wann er gestellt wurde.
Das bleibt richtig, auch wenn es von gestern ist – ein Sollwert ändert
sich nur, wenn jemand ihn ändert. Eine Innentemperatur von gestern sähe
dagegen aus wie eine von jetzt, und man würde ihr glauben. Genau das
sichern die neuen Prüfungen ab: Hauptwert ist der Sollwert, gemessene
Temperatur und Bordspannung kommen nicht vor.
Der Stand liegt in den Einstellungen (FridgeSettings) mit einem
Zeitstempel, der „zuletzt geändert" bedeutet und nicht „zuletzt gesehen" –
sonst behauptete die Kachel Frische, wo sich nichts getan hat. Die Uhr
bekommt dasselbe Bild: WatchFridge trägt jetzt ein Kennzeichen isLive.
BMS und Neigungsmesser bleiben dauerhaft verbunden. Sie stören nicht, und
ihre Werte will man laufend sehen.
Nicht nachgezogen ist die Android-App – dort verbindet der
BluetoothManager weiterhin dauerhaft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Alles auf einem Bildschirm hiess scrollen, und auf dieser Grösse ist das
der falsche Handgriff: Einen Wisch trifft man beim Rangieren auch ohne
hinzusehen, eine Scrollposition nicht. Was gerade zählt, hängt ausserdem
vom Arbeitsschritt ab.
Jetzt drei Seiten zum Wischen:
* Neigung – Fahrzeugansicht oder Libelle, was zu tun ist, Herkunft der
Werte
* Keile – die Höhe je Rad. Fehlen Spurweite und Radstand, steht das dort,
statt dass die Seite leer wirkt.
* Ausrichten – der Assistent, vorher hinter einem Knopf
Der Assistent ist dabei enger gesetzt: kleinere Zahl, zwei Zeilen Rat mit
Skalierung, kleinere Libelle, und kein ScrollView mehr. Beim Rangieren
schaut man kurz hin, da darf nichts ausserhalb des Bildes liegen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beim Registrieren lehnte Apple `…watchkitapp.complication` ab: „cannot be
registered to your development team because it is not available." Das
heisst dort immer, die Kennung gehört bereits jemandem – vergebene
Kennungen gibt Apple nie wieder frei, auch nicht nach dem Löschen.
Jetzt `…watchkitapp.levelwidget`. An der Erweiterung hing noch nichts,
das kostet also nichts. Der Anfang muss die Kennung der Watch-App
bleiben, das verlangt iOS für App-Erweiterungen; frei wählbar ist nur
der letzte Teil.
Geprüft: Bau läuft durch, die Erweiterung trägt die neue Kennung und den
Erweiterungspunkt com.apple.widgetkit-extension. Auf der Uhr liegt sie
samt Watch-App und startet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Die Kalibrier-Nullpunkte lagen schon immer im ESP und wurden dort auch
abgezogen – nur verriet die Firmware sie niemandem. Die Einbaulage lag
dagegen in jeder App einzeln, und damit stand sie bei drei Endgeräten
dreimal da, im Zweifel dreimal verschieden. Sie beschreibt aber den
Einbau und nicht das Telefon.
Zwei neue Charakteristiken:
...3426 Nullpunkte, zwei Floats, nur lesen
...3428 Einbaulage, acht Byte, lesen und schreiben
0 Version, 1 = gültig gesetzt, 0 = nie geschrieben
1 Längsachse: 0 = Pitch des Sensors, 1 = Roll
2 längs umgekehrt (0/1)
3 quer umgekehrt (0/1)
4..7 Verdrehung um die Hochachse, float32, Grad
Das Versionsbyte löst die Umstellung: Steht dort 0, hat nie jemand
geschrieben – dann gilt weiter, was die App örtlich gespeichert hat, und
beim nächsten Bestimmen wandert sie hinauf. Mit älterer Firmware ohne die
Charakteristik passiert schlicht nichts.
Angewandt wird die Lage weiterhin in den Apps. Der Sensor verwahrt sie
nur: Meldete er die Winkel bereits umgerechnet, rechnete jede ältere App
die Korrektur ein zweites Mal ein.
Beim Verbinden liest jede App die Lage und übernimmt sie; nach dem
Einbaulage-Assistenten schreibt sie sie hinauf. Die Uhr braucht das
iPhone dafür nicht mehr – sie holt sie sich selbst. Die Android-App
bekommt dabei auch die Verdrehung, die ihrer Fassung bisher ganz fehlte:
Modell, Erkennung und Persistenz nachgezogen.
Geprüft: Firmware übersetzt, im erzeugten Code stehen beide
Charakteristiken mit den richtigen Rechten und der Schreib-Handler;
iPhone- und Watch-Ziel bauen; sieben neue Prüfungen in run-tests.sh
nageln das Byte-Format fest, samt Rundlauf und der Bedeutung von
Version 0. Nicht geprüft ist die Android-Fassung: Auf dieser Maschine
liegt nur Java 8, Gradle verlangt mindestens 11.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sitzt der Sensor schräg statt längs im Fahrzeug, verteilt sich eine reine
Querneigung auf beide Achsen: Das Fahrzeug kippt zur Seite, und die
Längsanzeige kippt sichtbar mit – bei 20° Verdrehung mit gut einem
Drittel des Werts. Achsentausch und Vorzeichen halfen dagegen nicht, die
springen in 90°-Schritten.
SensorOrientation bekommt deshalb "twist", einen stufenlosen Winkel. Der
Einbaulage-Assistent misst ihn ohne zusätzlichen Handgriff mit: Beim
Kippen der Front nach unten dürfte sich nur die Längsneigung ändern;
wandert die Querneigung mit, ist das der gesuchte Winkel. Unter zwei Grad
gilt es als Wackeln der Hand. Angezeigt wird er in der Zusammenfassung
("um 20° verdreht"), herausgerechnet bei jeder Anzeige.
Beim Kalibrieren liesse sich das grundsätzlich nicht ermitteln: Es misst
eine einzige Lage und zieht sie als Nullpunkt ab. Eine Drehung um die
Hochachse steckt darin nicht – eben sieht in jeder Verdrehung gleich aus.
Das neue Feld hat beim Aufspielen sämtliche eingerichteten Geräte
gekostet, und der Grund gehört hierher: Swifts erzeugte Codable-Umsetzung
verlangt beim Lesen jedes Feld, Standardwerte im Code zählen nicht.
Gespeicherte Einbaulagen hatten kein "twist", also scheiterte das Lesen
der Einbaulage, damit des Geräts, damit der ganzen Liste – und das
nächste Speichern schrieb die leere Liste über den Bestand.
Zwei Vorkehrungen dagegen:
* SensorOrientation liest jetzt von Hand und nachsichtig, mit
decodeIfPresent und Rückfallwerten, wie Profile und ConfiguredDevice es
längst tun. Jedes künftige Feld gehört dort hinein.
* DeviceStore liest die Liste zweistufig: scheitert sie als Ganzes, wird
jedes Gerät einzeln versucht und behalten, was lesbar ist. Die
Rohdaten wandern zusätzlich in einen eigenen Schlüssel, statt beim
nächsten Speichern überschrieben zu werden.
Beides in run-tests.sh abgesichert: die Erkennung und Rückrechnung der
Verdrehung samt Gegenprobe ohne Korrektur, und das Lesen gespeicherter
Geräte ohne "twist", ganz ohne Einbaulage und mit unbrauchbarer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Uhr hatte Hänger und wurde von watchOS wegen Speicherverbrauch
abgeschossen. Ursache war eine Schleife ohne Bremse: Ist der Sensor
gerade nicht zu haben, folgte auf jeden Verbindungsversuch sofort der
Abbruch, auf den Abbruch sofort die nächste Suche – so schnell, wie das
Funkmodul es zulässt. Jeder Durchlauf schiebt Arbeit auf den
Hauptthread; die Uhr war dann mit Verbindungsaufbau beschäftigt statt
mit Anzeigen.
Drei Änderungen:
* Nach einem Fehlschlag wird gewartet, beginnend bei einer Sekunde und
verdoppelnd bis acht. Kommen wieder Werte, beginnt die Wartezeit von
vorn.
* Fundmeldungen, die nach dem Abschalten der Suche noch nachkommen,
werden verworfen. Sie lösten je einen weiteren Verbindungsversuch aus.
* Messwerte gehen höchstens fünfmal je Sekunde an die Oberfläche. Der
Sensor meldet zehnmal je Sekunde und für zwei Achsen getrennt, das
waren bis zu zwanzig Neuzeichnungen pro Sekunde.
Dazu die Fahrzeugbilder der Watch-App von iPhone-Auflösung (925x600 und
600x600) auf Bildschirmgrösse gebracht. Auf einem 40-mm-Display wurden
sie in voller Grösse entpackt, ohne dass davon etwas zu sehen war.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seit dem Neubau mit ESPHome 2026.6.5 lieferte der Sensor bei jeder Abfrage
denselben Wert. Der Grund steht im erzeugten Code: Ein getemplatetes
"value:" an einer Charakteristik wird von der neuen Fassung in eine
Aktion übersetzt, die genau einmal in setup() abläuft.
void setup() {
...
esp32_ble_server_..._setvalueaction_id->play(); // Pitch
esp32_ble_server_..._setvalueaction_id_2->play(); // Roll
Danach stand in der Charakteristik für immer der Wert vom Start – beim
Hochfahren ist das NAN oder die erste Messung. Die Apps lasen also
gewissenhaft eine Zahl, die sich nie mehr änderte; in der Einbaulage-
Bestimmung sah das aus, als merke sich die App sofort einen Wert.
Jetzt setzt jeder Sensor seinen Wert selbst, über on_value. Das
getemplatete "value:" an den Charakteristiken entfällt – ESPHome lehnt
beides nebeneinander ohnehin ab. Im erzeugten Code steht set_value
dadurch nicht mehr in setup(), sondern an den Auslösern der beiden
Sensoren.
Notify bleibt bewusst aus: Die Apps fragen im Takt ab, das funktioniert,
und eine frühere Fassung mit notify liess das Gerät verstummen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher standen dort zwei Angaben nebeneinander, etwa "rechts 8 cm" und
"vorne 4 cm". Das liest sich wie zwei Aufgaben, ist aber eine: Unter
"rechts" liegen zwei Räder, unter "vorne" auch, und eines davon ist
dasselbe. Ausführen lässt sich das so nicht.
Gerechnet wird jetzt über alle vier Aufstandspunkte auf einmal. Aus
Spurweite, Radstand und den beiden Winkeln ergeben sich deren Höhen;
angehoben wird auf das höchststehende Rad, das liegen bleibt. Aus dem
Beispiel oben werden damit 12 cm vorne rechts, 8 cm hinten rechts, 4 cm
vorne links und nichts hinten links – dieselbe Geometrie, nur richtig
zusammengesetzt.
Angezeigt wird das als Draufsicht auf das Fahrzeug (WheelLiftPlan), auf
iPhone und Uhr dieselbe Ansicht, auf der Uhr kompakt. LevelingWedge
entfällt.
Abgesichert in run-tests.sh: reine Querneigung, reine Längsneigung,
beides zusammen (16,1 / 9,2 / 7,0 / 0 cm), gespiegelte Vorzeichen und
die Fälle ohne Fahrzeugmasse.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Uhr funkt den Neigungsmesser jetzt selbst an, statt die Werte vom
iPhone weiterreichen zu lassen. Bei diesem einen Gerät geht das, und nur
bei ihm: Es bewirbt seinen Dienst, ist also ohne Einrichtung auffindbar,
und es ist unverschlüsselt – es gibt keinen Schlüssel, der auf der Uhr
ein zweites Mal lagern müsste. Damit steht die Nivellierung am Handgelenk
ohne geöffnetes iPhone, und genau dafür hebt man beim Rangieren den Arm.
Batterie, Solar und Kühlbox bleiben beim Weg über das iPhone: Sie lassen
nur eine Verbindung zu, und die Victron-Schlüssel liegen in dessen
Keychain. Die Einbaulage des Sensors reist einmal mit dem Datensatz
herüber und bleibt auf der Uhr gespeichert – ohne sie stünden längs und
quer je nach Einbau vertauscht.
LevelSession und VanAlignProtocol wandern nach Shared/Bluetooth; beide
sind reines CoreBluetooth und laufen auf watchOS unverändert. Die
Fahrzeugansicht gibt es jetzt auch auf der Uhr, umschaltbar zur Libelle;
Überhöhung und Farbregeln stehen in Shared/VehicleTilt.swift, damit
iPhone und Uhr nicht auseinanderlaufen.
Kalibrieren fällt auf der Uhr weg, samt Befehl. Das gehört einmalig ans
iPhone mit ebenem Fahrzeug; ein Knopf dafür am Handgelenk wäre vor allem
eine Gelegenheit, die Nullage aus Versehen zu verstellen.
Zwei Fehler dabei behoben:
* Beim Start meldete die Uhr dem iPhone nie, dass jemand hinschaut –
onChange(of: scenePhase) feuert beim ersten Erscheinen nicht. Der
schnelle Sendetakt blieb aus, bis die App einmal im Hintergrund war.
* Ein einmal direkt gemessener Wert hatte für immer Vorrang. Blieb der
Sensor stehen, ohne die Verbindung zu trennen, klebte die Anzeige
daran. Jetzt gilt er drei Sekunden als frisch, danach übernimmt der
Stand des iPhones – mit Alter und Grund daneben.
Ausserdem WATCHOS_DEPLOYMENT_TARGET auf 10.0 (Xcode hatte 11.6 gesetzt)
und die Bluetooth-Begründung für das Watch-Target.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neues Target CamperMonitorWatch, eingebettet in die iPhone-App. Die Uhr
zeigt je Gerät den Hauptwert, die Nivellierung mit Libelle und Keilhöhen,
den Ausrichtungs-Assistenten und stellt die Kühlbox.
Die Uhr funkt nicht selbst, obwohl watchOS das könnte. BMS, Kühlbox und
Neigungsmesser lassen jeweils nur eine Verbindung zu – eine mitlesende Uhr
würde dem iPhone die Verbindung wegnehmen, statt sie zu ergänzen. Und die
Victron-Schlüssel liegen in der Keychain des iPhones; sie ein zweites Mal
auf der Uhr aufzubewahren brächte nichts. Das iPhone bleibt also das
Funkgerät und reicht fertige Messwerte über WatchConnectivity weiter.
Gesendet wird in zwei Takten: ein halber Sekundentakt als Nachricht,
solange die Watch-App im Vordergrund ist und das über eine Frist meldet,
sonst alle zwei Sekunden als Anwendungskontext und nur bei Änderungen.
Läuft die Frist ab, hört das iPhone von selbst wieder auf.
Solange die Uhr hinschaut, hält die App das Funkgerät auch im Hintergrund
am Leben (UIBackgroundModes in Config/CamperMonitor-Info.plist) – beim
Rangieren liegt das iPhone sonst mit dunklem Bildschirm in der Halterung
und die Anzeige am Handgelenk wäre genau dann tot. Die verbundenen Geräte
liefern dabei weiter, die Victron-Werbedaten nicht: ungefiltertes Suchen
lässt iOS im Hintergrund nicht zu.
Der plattformneutrale Modellcode wandert nach Shared/ und wird in beide
Targets übersetzt; LevelState ist dafür aus VanAlignProtocol.swift
herausgelöst. Datensatz und Befehle stehen in Shared/WatchLink und sind
in run-tests.sh abgesichert: Rundlauf, Schutz gegen fremde Formatversion,
Vergleich ohne Zeitstempel und die Auflösung der Zeitangaben.
Geprüft sind der Bau beider Targets samt Einbetten und der Testlauf; auf
echter Hardware noch nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Instanz gefragt statt geraten. Ihre Liste erlaubter Dateitypen für
Anhänge enthält .apk nicht - daran scheitert das Hochladen. An der Grösse
liegt es nicht, die Grenze steht bei 100 MiB und die APK bei 11.
Der Quelltext als zip und tar.gz ist etwas anderes: den hängt Gitea an jedes
Release automatisch, erzeugt aus dem Etikett. Das ist nichts Hochgeladenes
und lässt sich auch nicht abschalten.
RELEASE.md nennt jetzt beides und zwei Wege. Der richtige ist eine Zeile in
der app.ini, die .apk erlaubt - für Release-Anhänge sind je nach Fassung
[attachment] oder [repository.release] zuständig, deshalb beide.
Ohne Serverzugriff hilft die Paket-Registry: die nimmt beliebige Dateien
ohne Typenliste und ist auf dieser Instanz eingeschaltet. Dafür ein Skript,
das den Zugangsschlüssel aus einer Datei liest und nirgends ausgibt, und
das die üblichen Fehlschläge benennt statt nur einen Statuscode zu zeigen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Release-Build lieferte bisher app-release-unsigned.apk - und die
installiert Android nicht, auch nicht per Sideload. Ohne Signatur kann das
System nicht feststellen, ob ein Update vom selben Absender stammt wie die
Erstinstallation; das ist unabhängig davon, woher die Datei kommt.
Der Build signiert jetzt. Liegt Android/keystore.properties vor, mit dem
eigenen Schlüssel; sonst wird aus der Umgebung gelesen, damit ein Bauknecht
sie aus seinen Geheimnissen setzen kann, ohne dass ein Passwort im Verlauf
landet. Fehlt beides, wird mit dem Debug-Schlüssel signiert - der Build
sagt das dann deutlich, denn eine so signierte Release-APK sieht sonst aus
wie eine richtige, lässt sich aber vom nächsten Rechner aus nicht mehr
aktualisieren. Schlüssel und Passwörter sind ausgeschlossen.
Version und Versionszähler lassen sich beim Bauen setzen, damit sie aus
einem Etikett kommen können.
Dazu ein Ablauf für Gitea Actions: ein Etikett hochschieben baut die APK,
legt das Release an, falls es noch nicht besteht, und hängt sie an. Beides
muss gehen - sonst scheitert es je nachdem, ob man das Release vorher von
Hand angelegt hat.
Android/RELEASE.md erklärt beide Wege und sagt auch, warum die APK nicht
ins Repository gehört: Release-Anhänge liegen in Gitea neben dem
Repository. Eine 11-MB-Binärdatei je Version im Verlauf wäre unwiderruflich
- Git vergisst nichts, ein späteres Löschen bringt den Platz nicht zurück.
Geprüft: die signierte APK installiert sich im Emulator, meldet sich mit
der übergebenen Version und trägt keine Debug-Kennzeichnung mehr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Dinge, die erst am laufenden Bild auffielen.
Die dynamischen Systemfarben ab Android 12 sind wieder raus. In dieser App
trägt Farbe Bedeutung - grün heisst eben, orange knapp daneben, rot
schief. Eine vom Hintergrundbild abgeleitete Akzentfarbe stand daneben und
liess die App je nach Telefon anders aussehen als ihr eigenes Logo.
Die Libelle sprengte ihren Rahmen. `aspectRatio` koppelt die Höhe an die
Breite und hebelte damit die Deckelung aus; auf grossen Anzeigen schob sie
sich über die Umschalter. Jetzt eine feste Höhe - der Kreis wird darin
ohnehin passend gezeichnet.
Der Ratschlag im Ausrichtungs-Assistenten blieb auf "Warte auf Messwerte"
stehen, obwohl daneben schon Werte standen. Compose überspringt einen
Aufruf, dessen Argument dieselbe Instanz ist, und der Assistent ist
bewusst kein Compose-Zustand. Sein Stand wird jetzt bei jeder Messung in
ein Wertobjekt gezogen.
Und die Zahlen, die die Ansichten selbst rechnen, standen mit Punkt statt
Komma - `String.format` ohne Sprachangabe nimmt die des Systems. Das
läuft jetzt über eine gemeinsame Stelle, wie schon bei den Messwerten.
Durchgeklickt: Dashboard, Gerätedetails mit Verlauf, Kühlbox-Steuerung,
Libelle, Fahrzeugansicht, Einrichtung des Neigungsmessers,
Ausrichtungs-Assistent, Einbaulage-Assistent und Fahrzeuge. Die
Kühlbox-Anzeige greift dabei auch hier richtig: der Demo-Datensatz trägt
den Fühlerplatzhalter, und die Box wird als einzonig geführt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Emulator hat kein Bluetooth. Damit sich die Ansichten trotzdem
ansehen und durchklicken lassen, füttert ein Demo-Modus fertige Werte
ein - dasselbe Vorgehen wie in der iOS-Fassung.
Nur in Debug-Bauten und nur, wenn beim Start das Extra gesetzt ist:
adb shell am start -n de.fritob.campermonitor/.MainActivity --ez demo true
Im Demo-Modus funkt nichts und es wird nichts abgelegt; die echten Geräte
und Fahrzeuge bleiben unberührt. Der Kühlbox-Zustand kommt dabei aus
einem echten Einzonen-Datensatz, wie ihn die Box im Fahrzeug schickt -
inklusive des Fühlerplatzhalters, damit die Anzeige auch im Demo zeigt,
was sie im Fahrzeug zeigen würde.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Alle Ansichten der iOS-Fassung in Jetpack Compose: Dashboard mit Kacheln,
Gerätedetails samt Messwerten, Verlauf, Zellspannungen und Diagnose,
Kühlbox-Steuerung, Nivellierung mit Libelle und Fahrzeugansicht,
Ausrichtungs-Assistent, die beiden Einrichtungsassistenten, Fahrzeuge,
Gerät hinzufügen, Schlüsseleingabe und Einstellungen.
Mitgenommen ist auch, was wir uns in der Oberfläche erarbeitet haben. Die
Geräteliste beim Einrichten sortiert nach Fundreihenfolge, nicht nach
Signalstärke - danach zu sortieren macht sie unbenutzbar, weil sie
sekündlich springt. Empfangspegel und Alter der Werte erscheinen nur mit
eingeblendeter Diagnose. Der Victron-Schlüssel liegt auf einer eigenen
Seite und meldet sich nur, wenn er fehlt oder nicht passt. Einbaulage und
Nullpunkt liegen eine Ebene tiefer, damit ein Fehlgriff beim Ablesen nicht
den Nullpunkt verstellt. Der Ausrichtungs-Assistent verlangt eine stehende
Verbindung und sagt es, wenn sie abreisst.
Drei Dinge sind auf Android anders:
Die Berechtigungsabfrage ist eigenständige Arbeit. Bis Android 11 lief ein
BLE-Scan über die Standortfreigabe, seither gibt es eigene
Bluetooth-Rechte; beide Wege werden bedient, und die App erklärt vorher,
wozu sie fragt.
Die Fahrzeugauswahl sitzt als Titel mit Aufklappen in der Leiste statt als
runder Knopf in der Ecke - so ist es hier üblich.
Die Symbole sind Material-Entsprechungen der SF-Symbole. Ausgewählt ist
jeweils das, was dieselbe Sache meint, nicht das ähnlichst aussehende.
Der Verlauf ist selbst gezeichnet; für eine Linie mit Fläche lohnt keine
Diagrammbibliothek.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Damit steht der erste Teil vollständig: Protokoll, Funk und Ablage
übersetzen sich, die 50 Prüfungen laufen.
Die Funkschicht folgt der iOS-Fassung samt allem, was wir uns dort erst
erarbeiten mussten. Ein eigener Thread für alles, was Bluetooth anfasst;
Android ruft Scan- und GATT-Rückmeldungen auf Binder-Threads auf. Die
Wartesperre nach Fehlschlägen, die zwischen einem Abbruch einer stehenden
Verbindung und einem echten Fehlschlag unterscheidet. Stellbefehle, die
aufgehoben statt verworfen werden, wenn die Kühlbox gerade weg ist. Die
Zwanzig-Byte-Grenze beim Schreiben an die Kühlbox. Die stabile Reihenfolge
der Kandidaten, damit nicht der Zufall die Schreibart bestimmt.
Vier Dinge sind auf Android anders und im Quelltext vermerkt:
Die Herstellerdaten kommen ohne die zwei Bytes der Company-ID - die steht
im Schlüssel der Tabelle. Sie werden wieder davorgesetzt, damit derselbe
Rahmen ankommt wie unter iOS und dieselben Prüfungen gelten.
Notify muss über einen Deskriptor eingeschaltet werden; das Einschalten auf
unserer Seite allein genügt nicht.
Geräte werden über ihre MAC-Adresse angesprochen statt über eine
systemvergebene Kennung - iOS gibt die Adresse gar nicht heraus.
Die Victron-Schlüssel liegen in app-privater Ablage statt im
Schlüsselbund. Das schützt gegen andere Apps, ist aber nicht
hardwaregestützt. Ohne zusätzliche Bibliothek gibt es unter Android kein
gleichwertiges Gegenstück.
Als Nächstes die Oberfläche.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Erster Teil der Android-Fassung. Portiert ist die Schicht, in der die
ganze Erfahrung aus unseren Fehlersuchen steckt: Victron-Entschlüsselung,
Daly klassisch und Modbus, JBD, WattCycle, Alpicool, der Neigungsmesser
samt Einbaulage, Ausrichtungs-Assistent und Keilrechner.
Sie liegt in einem eigenen Gradle-Modul aus reinem Kotlin, ohne
Android-Abhängigkeiten. Das ist keine Förmlichkeit: nur so laufen ihre
Prüfungen auf der Kommandozeile, ohne Emulator und ohne Android SDK -
genau wie das run-tests.sh der iOS-Fassung. 50 Prüfungen, alle grün.
Dieselben Vektoren wie unter iOS, darunter die, die uns Tage gekostet
haben: der AES-Vektor aus NIST SP 800-38A, der echte Orion-XS-Rahmen aus
der Diagnoseansicht, das mitgeschnittene Ausschaltpaket der IceCube Dual
und die 30-Byte-Antwort der Box im Fahrzeug, an der sich zeigt, dass ein
Fühlerplatzhalter von -128 keine zweite Zone ist.
Zwei Dinge weichen bewusst ab. AES-CTR kommt aus der JVM statt aus
CommonCrypto - der Zähler wird dort ebenso big-endian gezählt. Und
Zeitstempel sind Millisekunden statt Date-Objekten: das läuft ohne
Rücksicht auf die Android-Version und lässt sich in Prüfungen vorgeben,
statt von der Uhr abzuhängen.
Die Werkzeugkette steht in Android/env.sh: JDK 17, Gradle 8.11.1 über den
Wrapper, Android SDK 35.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Vollbildschirm hing an einer `Section`. SwiftUI zeigt Blätter und
Vollbildschirme dort nicht zuverlässig an - genau der Fehler, an dem
schon der Bestätigungsdialog der Kühlbox scheiterte. Dass es "irgendwie
nicht immer" auftrat, passt dazu. Er hängt jetzt am Knopf selbst. Alle
übrigen Blätter und Dialoge der App sitzen bereits an einer Liste oder
einem Stapel; nur diese Stelle nicht.
Dazu die zweite Hälfte: der Assistent war freigegeben, sobald irgendwann
einmal ein Messwert angekommen war. Nach einem Verbindungsabbruch blieb
der letzte Stand stehen, der Knopf also offen - und der Assistent zeigte
Zahlen, die längst nicht mehr galten. Er verlangt jetzt eine stehende
Verbindung, und der Abschnitt sagt, warum er sonst grau ist.
Reisst die Verbindung während des Rangierens ab, steht das jetzt oben im
Assistenten. Vorher stand die Anzeige einfach still, was von einer
hängenden App nicht zu unterscheiden war.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kalibrierung und Einbaulage standen direkt unter der Libelle. Wer im
Fahrzeug die Anzeige abliest und dabei scrollt, verstellt so leicht den
Nullpunkt - und merkt es nicht, weil die Anzeige danach schlicht null
zeigt. Beides liegt jetzt hinter "Neigungsmesser einrichten".
In der Geräteansicht bleibt, was im Betrieb gebraucht wird: die Libelle,
die Werte und der Ausrichtungs-Assistent. Die Einrichtungszeile nennt den
Stand, damit man nicht erst hineinschauen muss - fehlt der Nullpunkt,
steht das dort.
Die Namen sagen jetzt, was geschieht. "Auf aktuelle Lage kalibrieren"
klang nach einer Messung, gemeint ist das Festlegen des Nullpunkts: jetzt
"Aktuelle Lage als eben übernehmen", das Zurücksetzen entsprechend
"Nullpunkt verwerfen". Aus dem Hauptwort "Einbaulage" wird "Einbaulage
bestimmen".
Die beiden Schritte stehen in der Reihenfolge, in der sie gehören: erst
die Einbaulage, sonst legt der Nullpunkt sich auf die falsche Achse.
Beide Knöpfe bleiben stumm, solange keine Werte ankommen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Oben in der Geräteansicht stand, was zur Diagnose taugt, aber im Alltag
nichts sagt.
Der Empfangspegel ist raus - er hilft beim Aufspüren eines Geräts, sonst
nie - und erscheint jetzt nur noch mit eingeblendeter Diagnose. Ebenso das
Alter der Werte: solange sie frisch sind, sagt es nichts, was der
Verbindungspunkt nicht schon zeigt. Bleiben sie stehen, ist es die
eigentliche Nachricht und wird gezeigt.
Der Victron-Schlüssel stand mit Eingabefeld und Anleitung ganz oben,
obwohl er einmal eingetragen und danach nie wieder angefasst wird. Er hat
jetzt eine eigene Seite, erreichbar aus den Einstellungen - dort, wo auch
die Bluetooth-ID steht. In der Übersicht bleibt nur eine Zeile mit dem
Stand: hinterlegt, fehlt oder passt nicht.
Fehlt der Schlüssel wirklich oder gehört er zu einem anderen Gerät, steht
weiter ganz oben ein Hinweis - dann ist er ja das Einzige, was zu tun ist.
Kommen Werte an, passt er offensichtlich, und es wird nichts gemeldet.
Der Vergleich der ersten Schlüsselbytes ist aus der Diagnose auf die
Schlüsselseite gewandert. Dort wird er gebraucht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deine Diagnose hat es gezeigt. Die Box sendet 30 Byte Nutzlast, also den
langen Datensatz - hat aber nur einen Fühler. Für den fehlenden zweiten
meldet sie -128, den üblichen Platzhalter, und die Einstellungen der
rechten Zone stehen auf lauter Nullen.
Meine Erkennung hat diesen Platzhalter für einen Messwert gehalten und die
Box deshalb für zweizonig gehalten. Damit ging der lange Stellbefehl raus,
31 Byte statt 20 - und den verwirft sie wortlos. Die Solltemperatur ging
weiter, weil sie ein eigenes, kurzes Kommando hat und von der Zonenfrage
nicht berührt wird. Genau dieses Bild stand im Bericht.
Als zweite Zone gilt jetzt nur noch, wo der zweite Fühler auch wirklich
misst. Für diese Box heisst das: 20 Byte, ein Schreibvorgang.
Nebenbei fiel auf, dass die Anzeige eine rechte Zone mit -128 Grad geführt
hat. Auch das ist damit weg.
Die echte Antwort der Box steht als Prüfung im Testlauf, mitsamt der
Möglichkeit, die Erkennung in den Geräteeinstellungen zu übersteuern.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Dein Befund grenzt es ein: die Solltemperatur lässt sich stellen, also
kommen Schreibvorgänge an. Es scheitert nur am Einstellungsblock.
Das mehrfache Piepen war meine Schuld. Beantwortet die Box die Anmeldung
nicht, habe ich sie vor jedem Stellbefehl erneut angemeldet - und die Box
quittiert jede Anmeldung mit einem Ton. Jetzt geschieht das höchstens
einmal je Verbindung.
Weiter komme ich nicht ohne die Antwort deiner Box. Ihre Länge entscheidet
darüber, wie lang der Stellbefehl sein muss, und sie steht jetzt als
"Statusdaten der Box" in der Diagnose. Dazu ein Knopf, der alles zusammen
in die Zwischenablage legt - Merkmalsbaum, Weg, Schreibart, letzten Befehl
und letzte Antwort. Das abzutippen wäre zuviel verlangt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Anläufe ohne Erfolg heisst: die Annahme, der Schreibvorgang komme an,
trägt nicht mehr. Also wird sie geprüft, statt weiter darauf zu bauen.
Drei Dinge am Schreibweg waren wirklich falsch.
Die Reihenfolge der Kandidaten war nicht festgelegt. Bietet ein Merkmal
beide Schreibarten an, sind beide Einträge gleichwertig - und `sorted`
sichert für gleichwertige Einträge keine Reihenfolge zu. Ob mit oder ohne
Bestätigung geschrieben wurde, entschied damit der Zufall, von Start zu
Start womöglich verschieden. Jetzt bleibt die Fundreihenfolge erhalten.
Ein Schreibvorgang ohne Bestätigung wird von iOS stillschweigend verworfen,
wenn der Sendepuffer voll ist. Das wurde nirgends beachtet. Jetzt wartet,
was nicht sofort rausgeht, auf die Bereitschaftsmeldung.
Schreibfehler waren unsichtbar: für Schreibvorgänge mit Bestätigung gab es
gar keine Rückmeldung. Jetzt werden sie gezählt und Fehler gemeldet, beides
steht in der Diagnose.
Dazu bessert die Sitzung selbst nach. Nach einem Stellbefehl wird geprüft,
ob sich die Einstellungen der Box überhaupt geändert haben - an den
Einstellungsbytes, nicht an Temperatur und Spannung, die ohnehin schwanken.
Bleibt alles gleich, wird einmal mit der anderen Schreibart nachgesetzt.
Nimmt die Box nur eine der beiden an, findet die App das jetzt allein.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Ursache, belegt statt vermutet. Im Referenzprojekt gibt es einen
Bericht von genau dieser Box - einer Maentum/Plug-in Festival IceCube Dual
(Gruni22/alpicool_ha_ble#20). Dort galt: Solltemperatur ändern geht,
Ein- und Ausschalten nicht. Genau unser Bild.
Der Grund ist nicht das Paket, sondern der Schreibvorgang. Die Box nimmt
nur die 20 Nutzbytes der Standard-MTU je Schreibvorgang an. Der kurze
Temperaturbefehl hat sieben Byte und geht durch, der Einstellungsblock hat
31 und wird abgelehnt. Wir haben bisher nach der ausgehandelten MTU
aufgeteilt - und die ist unter iOS weit grösser als 20, also wurde nie
aufgeteilt. Jetzt gilt für die Kühlbox die Grenze der Box, nicht die der
Verbindung: 31 Byte gehen als 20 und 11 raus, mit der üblichen Pause
dazwischen.
Das mitgeschnittene Paket aus dem Bericht steht als Prüfung im Testlauf.
Unsere Erzeugung trifft es byteweise - Längenbyte, Datenblock, rechte
Zone, Prüfsumme -, es scheiterte also wirklich nur am Schreiben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diesmal gegen die Referenzimplementierung geprüft statt geraten. Rahmen,
Längenbyte, Prüfsumme, Anmelde- und Abfragepaket stimmen dort byteweise
mit unseren überein. Ein Unterschied blieb: die Länge des Einstellungs-
blocks.
Ich hatte sie an die Zonenerkennung gehängt. Sendet eine Box den langen
Datensatz, füllt den zweiten Block aber mit Nullen, galt sie als einzonig
und bekam den kurzen Befehl - während sie den langen erwartet. Die Box
verwirft ihn dann wortlos, und Ein- und Ausschalten blieb wirkungslos.
Die Referenz hängt die Länge an die Antwort der Box, nicht an eine
Deutung davon. Jetzt auch hier. Für die Anzeige bleibt die Erkennung
unverändert: ein leerer zweiter Block wird weiterhin nicht als zweite
Zone gezeigt.
Zweitens die Anmeldung. Abfragen beantwortet die Box teils auch
unangemeldet, Stellbefehle nicht. Ob die Anmeldung je bestätigt wurde,
wurde bisher nicht verfolgt. Jetzt schon: fehlt die Bestätigung, wird vor
dem Stellbefehl noch einmal angemeldet. In der Diagnose steht der Stand
als eigene Zeile.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Fehler aus dem letzten Stand, beide von mir eingebaut.
Die Kühlbox liess sich nicht mehr bedienen. Die Wartesperre gegen den
Verbindungssturm hat nicht unterschieden, warum eine Verbindung endete:
ein Abbruch einer Verbindung, die stand, wurde genauso lange gesperrt wie
ein Fehlschlag. Im Fahrzeug ist so ein Abbruch der Normalfall, und die Box
war danach bis zu einer Minute nicht erreichbar. Ein Tippen ging in dieser
Zeit lautlos verloren, weil es ohne Sitzung ins Leere fiel.
Jetzt zählt die Dauer: was mindestens drei Sekunden stand, gilt als
zustandegekommen und wird nach zwei Sekunden wieder aufgenommen. Nur was
sofort wieder abbricht, zählt als Fehlschlag und wird gestaffelt gesperrt -
gegen das Wechselspiel, wenn eine andere App das Gerät belegt.
Dazu gehen Stellbefehle nicht mehr verloren. Fehlt die Verbindung, wird der
Befehl aufgehoben, die Sperre für dieses Gerät aufgehoben und sofort ein
Versuch angestossen; sobald der Kanal steht, geht er raus. Ein Befehl, der
älter als eine halbe Minute ist, verfällt - ein verspätetes Ausschalten
würde nur überraschen. Die Ansicht sagt es, statt den Schalter stumm
zurückspringen zu lassen.
Zweitens der Assistent für die Einbaulage. Er hat die zweite Bewegung von
der gekippten Lage aus gemessen statt von der Ruhelage. Damit steckte in
jeder zweiten Messung das Zurückkippen aus der ersten, und es schlugen
immer beide Achsen aus. Die Ruhelage ist jetzt der Bezug für beide
Bewegungen, und ein eigener Schritt dazwischen nimmt sie neu auf.
Auch die Auswertung war zu streng: sie hat jede Bewegung für sich
beurteilt und abgelehnt, sobald die andere Achse mitlief. Von Hand gekippt
läuft sie aber immer mit. Beurteilt werden jetzt beide Bewegungen
gemeinsam - es gewinnt die Zuordnung, die zusammen am meisten erklärt.
Zweimal um dieselbe Achse gekippt wird weiterhin erkannt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Dinge.
Die Kühlbox piepte dauernd und die Bedienung wurde zäh. Ursache war ein
Fehler in der Verbindungslogik: nach einem fehlgeschlagenen Versuch wurde
der Eintrag freigegeben, und das nächste Advertisement löste sofort den
nächsten aus - bei laufendem Scan bis zu einmal je Sekunde. Geräte
quittieren jeden Versuch, Kühlboxen mit einem Piepton. Nebenher wechselte
der Verbindungszustand im selben Takt, was die Oberfläche in eine
Dauerneuzeichnung trieb.
Ein Versuch wird jetzt für eine Weile gesperrt, mit wachsendem Abstand von
fünf bis sechzig Sekunden. Auch nach einem Trennen durch die Gegenseite
wird nicht sofort neu angeklopft - trennt ein Gerät von sich aus, etwa
weil eine andere App verbunden ist, entstünde sonst ein Wechselspiel aus
Verbinden und Trennen. Beim Umkonfigurieren werden die Sperren
zurückgesetzt, damit ein neu eingerichtetes Gerät sofort drankommt.
Dazu entlastet: bei jeder Antwort wurden alle fünf Protokollparser
durchprobiert, auch wenn längst feststand, welches Protokoll gilt. Steht
der Dialekt, läuft nur noch dieser.
Zweitens der Neigungsmesser: je nach Einbaulage meldet er längs und quer
vertauscht oder mit falschem Vorzeichen. Statt die Lage aus einer Liste
raten zu lassen, misst der neue Assistent sie - zweimal kippen, einmal um
jede Achse, und aus der Reaktion ergibt sich die Zuordnung. Schräges oder
zu schwaches Kippen wird erkannt und gemeldet, statt eine zufällige
Zuordnung zu liefern. Die Sitzung führt die Rohwerte des Sensors weiter
mit, weil der Assistent sie unumgerechnet braucht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Geräteansichten zeigten dauerhaft die technischen Angaben: erkanntes
Protokoll, Bluetooth-Merkmale samt vollständigem Merkmalsbaum, gesendete
Befehle und die Rohdaten der letzten Antwort. Das war zum Einrichten der
Geräte nötig - für den Alltag ist es nur Ballast zwischen den Messwerten.
Sie sind jetzt ausgeblendet und über Einstellungen → Diagnose anzeigen
wieder einzublenden. Die Einstellungen sind neu und sitzen im
Fahrzeugmenü des Dashboards.
Eine Ausnahme: Meldet ein Gerät einen Fehler oder fehlt ein
Victron-Schlüssel, erscheinen die Angaben unabhängig von der Einstellung.
Genau dann sind sie das Einzige, was weiterhilft - und niemand denkt in
dem Moment daran, sie erst irgendwo einzuschalten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neben der Libelle gibt es jetzt eine zweite Darstellung: die Neigung am
Fahrzeug selbst, mit den Zeichnungen aus dem Ursprungsprojekt. Umschaltbar
und über Starts hinweg gemerkt.
Seitenansicht für längs, Heckansicht für quer. Die Heckansicht ist bewusst
gewählt, nicht die Frontansicht: sie teilt die Blickrichtung des Fahrers,
links im Bild ist also links am Fahrzeug. Von vorne betrachtet wäre es
seitenverkehrt und damit beim Ausrichten irreführend.
Die Zeichnungen sind weiss gefüllt mit dunklen Linien. Als Schablone
eingefärbt wurde daraus eine massive Fläche, weil alles Deckende zur
Tintfarbe wird - Fenster, Räder und Konturen verschwanden. Tools/
make-vehicle-art übersetzt deshalb die Helligkeit in Deckkraft: dunkle
Linien voll deckend, helle Karosserie nur angedeutet. Eingefärbt bleibt
die Zeichnung erhalten und passt sich Hell- wie Dunkeldarstellung an.
Die Neigung wird dreifach überhöht gezeigt, sonst wären zwei Grad am
Fahrzeug kaum auszumachen. Das steht als Hinweis darunter, zusammen mit
der Klarstellung, dass die Gradzahlen echt sind - sonst nähme man den
Bildwinkel für den tatsächlichen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Begleitet das Einparken: verfolgt die Neigung über die Zeit, meldet ob es
besser oder schlechter wird, und erinnert an den flachsten Punkt - "vor 4
Sekunden stand das Fahrzeug 0,8 Grad flacher". Bei Erreichen der Toleranz
gibt es eine Vibration, das Display bleibt währenddessen wach.
Bewusst ohne Positionsbestimmung. Aus einem MEMS-Sensor lässt sich keine
brauchbare Strecke ableiten: der Fehler wächst beim zweifachen Integrieren
quadratisch mit der Zeit, und im Schritttempo gehen die tatsächlichen
Beschleunigungen im Rauschen unter. Gebraucht wird sie auch nicht - beim
Einparken lautet die Frage nie "wo stehe ich", sondern "wird es besser".
Das steckt vollständig im zeitlichen Verlauf der Neigung, ohne jede
Annahme über das Gelände. Die vorhandene Verlaufsaufzeichnung war mit
einem Punkt alle fünf Sekunden zu grob; der Assistent führt einen eigenen
Ringpuffer, der nur läuft solange die Ansicht offen ist.
Sind Spurweite und Radstand hinterlegt, kommt die nötige Höhe der
Auffahrkeile dazu. Das ist reine Geometrie und damit exakt. Die Masse
stehen im Fahrzeugprofil.
Dabei fiel auf, dass sich vorhandene Fahrzeuge praktisch nicht bearbeiten
liessen: das ging nur über eine Wischgeste, die niemand findet - erst
recht nicht, wenn dort jetzt die Masse einzutragen sind. Die Zeile hat nun
einen sichtbaren Knopf dafür, wie bei den WLAN-Einstellungen: antippen
wählt aus, das Zeichen daneben öffnet die Bearbeitung.
Ausserdem übernimmt der Assistent den anliegenden Messwert beim Öffnen.
Sonst stand dort bis zur nächsten Messung "Warte auf Messwerte", obwohl
längst welche vorlagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die überarbeitete Firmware liess sich prüfen und fehlerfrei übersetzen,
blieb auf dem Gerät aber stumm - keine Werte, keine Ausgabe über die
serielle Schnittstelle. Der Umbau war zu gross für das, was sich ohne
Gerätezugriff absichern lässt: config und compile sagen nichts über das
Laufzeitverhalten.
Die Firmware setzt jetzt wieder auf dem bewährten Stand 1.0 auf und ändert
daran nur zweierlei: die Kalibrierung über Bluetooth funktioniert (die
Charakteristik war beschreibbar, hatte aber keine Aktion hinterlegt und
tat nichts), und der ESP-NOW-Rest ist entfernt, der bei jedem Messwert ein
"hallo" an eine feste MAC schickte. Kein notify, kein aktives Setzen der
Werte, kein Zugriff auf den BLE-Server aus dem Boot-Ablauf heraus.
In der App fällt damit ein Denkfehler auf: fehlende Kalibrier-Offsets
galten als "nicht kalibriert" statt als "unbekannt". Bei Firmware, die
sie nicht meldet, stünde dauerhaft eine Warnung, die sich nicht abstellen
lässt. Gewarnt wird jetzt nur, wenn das Gerät ausdrücklich Nulloffsets
meldet. Der Rücksetz-Knopf hing an derselben Bedingung und wäre sonst
unerreichbar gewesen.
Das Abfragen im Takt war bereits als Rückfallebene eingebaut und trägt
diesen Aufbau ohne Änderung.
Ausserdem nimmt die .gitignore jetzt virtuelle Python-Umgebungen aus. Eine
solche war versehentlich mitversioniert worden - über 14000 Dateien, die
maschinenabhängig sind und im Repo nichts zu suchen haben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die ESPHome-Firmware lag bisher im eigenständigen Projekt VanAllign-Pro.
Da die App der einzige Client ist, gehören Firmware und App zusammen:
ändert sich die Bluetooth-Schnittstelle, muss beides gemeinsam angefasst
werden.
Übernommen sind die Firmware selbst und die beiden Experimente zu
WLAN/BLE-Umschaltung und ESP-NOW, letztere nach experimente/ einsortiert
und als nicht betriebsnotwendig gekennzeichnet. Die WebBLE-Oberfläche
bleibt im Ursprungsprojekt - sie ist durch die App abgelöst und bringt
2 MB Bilder mit, die in einem iOS-Projekt nichts zu suchen haben.
Die .gitignore schliesst jetzt die ESPHome-Build-Verzeichnisse aus; im
Ursprungsprojekt fehlte das, dort liegen inzwischen 233 MB Bauartefakte
neben den Quellen.
Am neuen Ort mit esphome config gegengeprüft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das ESPHome-Projekt VanAlign Pro misst über einen MPU6050 die Längs- und
Querneigung des Fahrzeugs und stellt sie über Bluetooth bereit. Damit
lässt sich der Camper beim Parken ausrichten.
Der Neigungsmesser bewirbt seinen Dienst, wird beim Einrichten also
sicher erkannt und die Geräteart vorbelegt. Anders als bei den übrigen
verbundenen Geräten gibt es hier kein Rahmenprotokoll: jede Messgrösse
liegt in einer eigenen Charakteristik als Float. LevelSession ist deshalb
eine eigene, deutlich einfachere Sitzungsart neben BMSSession - ohne
Protokollerkennung und ohne Kandidatensuche.
Bevorzugt werden die Werte abonniert; bietet das Gerät das nicht an, wird
im Takt abgefragt. Damit läuft die App auch mit der alten Firmware 1.0,
die nur Lesen kennt.
Die Detailansicht zeigt eine Libelle: die Blase wandert dorthin, wo das
Fahrzeug höher steht. Grün bis 0,5 Grad, orange bis zwei, darüber rot -
die Akzentfarbe der App ist selbst grün, "schief" hätte sonst genauso
ausgesehen wie "eben". Die Ringe sind ein echter Massstab (Toleranz und
zwei Grad), sonst sagt die Blasenlage nichts über die verbleibende
Abweichung. Dazu die Ansage in Worten, welche Seite höher steht.
Die Winkel werden fest little-endian gelesen. Die Web-Oberfläche des
Ursprungsprojekts probiert zusätzlich die umgekehrte Reihenfolge, falls
die erste unplausibel wirkt. Das ist nicht nur unnötig, sondern
schädlich: ein vertauschter Float von 4,25 Grad liest sich als etwa 0,0
und wirkt damit völlig plausibel - der Fehler bliebe unbemerkt. Ein Test
hält das fest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CoreBluetooth lief auf dem Hauptthread, also demselben, der die
Oberfläche zeichnet. Gescannt wird mit Duplikaten über alle Geräte in
Reichweite, weil Victron seine Werte im Advertisement mitschickt - jedes
einzelne davon kam als Rückruf dort an, samt Entschlüsselung und
Neuzeichnung. Das war die Ursache der trägen Bedienung.
CoreBluetooth arbeitet jetzt auf einer eigenen seriellen Queue. Daraus
folgt eine strikte Trennung:
* Verbindungen, Puffer und Zeitgeber werden ausschliesslich auf dieser
Queue angefasst. Die Zeitgeber sind deshalb DispatchSourceTimer statt
Timer, denn auf einer DispatchQueue gibt es keine RunLoop.
* Die veröffentlichten Werte werden ausschliesslich auf dem Hauptthread
geschrieben, gebündelt über publish().
* Die Geräteliste wird nicht mehr aus der Funk-Queue heraus im Speicher
nachgeschlagen. Stattdessen zieht refreshConfiguration auf dem
Hauptthread eine Momentaufnahme - Kennung, Transportart, Zonenwahl und
den bereits ausgelesenen Victron-Schlüssel - und reicht sie hinüber.
Damit greift kein Hintergrundthread mehr auf den beobachteten Speicher
zu.
Die Stellbefehle der Kühlbox bauen ihren Einstellungsblock ebenfalls auf
der Funk-Queue, weil der zugrundeliegende Zustand dort lebt.
Geprüft im Simulator: der Statuswechsel von CoreBluetooth kommt über die
Funk-Queue und erreicht die Anzeige korrekt, beide Startpfade laufen ohne
Absturz.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Umbenennen war zwar möglich, aber praktisch unauffindbar: das Eingabe-
feld trug nur einen Platzhalter, und übernommen wurde erst über einen
zusätzlichen Knopf. Jetzt steht "Name" als Beschriftung davor, der Knopf
ist weg, gesichert wird beim Abschluss der Eingabe und beim Verlassen der
Ansicht. Der Funkname steht darunter als "Gefunden als", damit das Gerät
weiter zuzuordnen ist.
Beim Einrichten wird nicht mehr der Funkname vorgeschlagen - Namen wie
"WTaEaAA25342229" taugen nicht als Anzeigename -, sondern die Art des
Geräts, sofern der Funkname kryptisch wirkt.
Die Detailansicht arbeitete auf einer Momentaufnahme des Geräts. Nach dem
Umbenennen oder nach dem Umstellen der Kühlzonen zeigte sie deshalb
weiter die alten Werte; sie liest den Stand jetzt aus dem Speicher.
Gegen die träge Oberfläche: CoreBluetooth meldet jedes Advertisement
einzeln und auf dem Hauptthread, und gescannt wird mit Duplikaten über
alle Geräte in Reichweite. Victron sendet mehrmals je Sekunde, dazu
kommt alles andere in Funkreichweite. Ausgewertet wird jetzt höchstens
einmal je Sekunde und Gerät, die Geräteliste beim Einrichten alle zwei
Sekunden, die Rohdaten der Diagnose alle drei. Ein Advertisement mehr
ändert die Anzeige ohnehin nicht, kostet aber Entschlüsselung und eine
Neuzeichnung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ausschalten blieb wirkungslos. Zwei Ursachen, beide behoben.
Die Länge des Einstellungsblocks hing an der Länge des empfangenen
Datensatzes statt an der Zonenzahl. Einzonen-Boxen, die den langen
Datensatz trotzdem senden, bekamen so einen 25-Byte-Block für zwei Zonen
und nahmen ihn offenbar nicht an. Jetzt entscheidet die erkannte
Zonenzahl: eine Zone ergibt 20 Byte und passt damit ohne Aufteilen in
einen Schreibvorgang.
Der Bestätigungsdialog beim Ausschalten hing an einer Section, und dort
zeigt SwiftUI ihn nicht zuverlässig an - der Schalter tat dann gar
nichts. Ein und Aus laufen jetzt beide direkt über denselben Weg, ohne
Rückfrage.
Die Diagnose zeigt zusätzlich den zuletzt abgeschickten Stellbefehl mit
Zeitstempel, damit sich unterscheiden lässt, ob ein Befehl das Gerät
nicht erreicht oder von ihm verworfen wird.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das Logo liegt als fertige Kachel vor: weißer Rand, eingebrannte runde
Ecken. iOS maskiert die Ecken selbst und verbietet einen Alphakanal,
unbearbeitet säße also ein weißer Rahmen um das Icon. Tools/make-app-icon
schneidet den Rand weg, macht den Ausschnitt quadratisch und versetzt ihn
so weit nach innen, bis die Ecken im Hintergrund liegen, und skaliert
dann auf 1024x1024 ohne Alpha. Das erzeugte Icon liegt mit im Repo, das
Skript wird nur bei einem neuen Logo gebraucht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Fehler am Gerät gefunden.
Einzonen-Boxen als Doppelzone erkannt: Manche senden den langen
Datensatz einer Zweizonen-Box mit, füllen den zweiten Block aber mit
Nullen. Die Nutzlastlänge allein taugt deshalb nicht als Kriterium. Als
zweizonig gilt jetzt nur, wo dieser Block überhaupt Inhalt hat, und in
den Geräteeinstellungen lässt sich die Erkennung auf "Eine Zone" oder
"Zwei Zonen" festnageln.
Einschalten reagierte nicht: Ein/Aus und Betriebsart schicken den
kompletten Einstellungsblock, der mit dem langen Datensatz auf 31 Byte
kommt. Ohne ausgehandelte MTU nimmt BLE aber nur 20 Nutzbytes je
Schreibvorgang an, der Rest wurde stillschweigend verworfen. Die
Solltemperatur ging als kurzes Paket durch, alles Längere nicht. Lange
Pakete werden jetzt anhand von maximumWriteValueLength aufgeteilt und
versetzt geschrieben; die Statusabfrage danach wartet entsprechend
länger. Aus dem kurzen Datensatz ist der Befehl übrigens genau 20 Byte
groß und hätte gerade noch gepasst - deshalb trat es nur an dieser Box
auf.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die IceCube-Boxen von Plug-in Festivals sind umgelabelte Alpicool-Boxen –
der Hersteller verweist selbst auf die App "Alpicool T-Series". Bestätigt
am Gerät: die Charakteristiken 00001235 und 00001236 tauchen im GATT-Baum
auf. Dasselbe Protokoll sprechen BrassMonkey und Ocean Comfort.
AlpicoolProtocol baut und liest die Rahmen (FE FE, Länge, Kommando,
Daten, Bytesummen-Prüfsumme) und wertet die Statusantwort aus: Ist- und
Solltemperatur je Zone, Betriebsart, Kompressorstatus, Bedienfeldsperre,
Bordspannung und Batterieanzeige. Zweizonen-Boxen werden an der
Nutzlastlänge erkannt. Auf Stellbefehle antwortet die Box mit Echo und
Status in einer einzigen Benachrichtigung, weshalb der Rahmenleser
weitersucht statt nach dem ersten Treffer abzubrechen; das Echo läuft
mangels Statuslänge ins Leere.
Als bisher einziges Gerät ist die Box auch stellbar: Ein/Aus, Eco/Max,
Solltemperatur je Zone und Bedienfeldsperre. Nach jedem Stellbefehl wird
der Zustand neu abgefragt, sodass die Schalter dem Gerät folgen und nicht
der Eingabe. Ausschalten fragt einmal nach, weil dabei die Kühlung
stoppt. Ein/Aus und Betriebsart brauchen den kompletten
Einstellungsblock: er wird aus dem letzten Status neu aufgebaut und nur
im betroffenen Byte geändert, sonst überschriebe die Box eigene
Einstellungen mit Nullen. Ohne bekannten Status entsteht gar kein
Stellbefehl.
Die Namensprüfung in der Geräteliste hiess bisher looksLikeDaly und
hätte Kühlboxen aus der Vorauswahl geworfen; sie deckt jetzt alle
unterstützten Geräte ab und belegt die Art beim Einrichten vor.
Protokoll und Feldbelegung nach Gruni22/alpicool_ha_ble. Die festen
Anmelde- und Abfragepakete der Referenz sind byteweise abgesichert und
belegen zugleich, dass die allgemeine Prüfsummenregel auch für sie gilt.
139 Prüfungen laufen durch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
WattCycle spricht weder Daly noch JBD, sondern ein eigenes Modbus-artiges
Protokoll – und verlangt vor der ersten Abfrage eine Freischaltung: der
Text "HiLink" muss auf die Charakteristik FFFA geschrieben werden, sonst
bleibt der Akku auf alles stumm. Genau daran scheiterte die Erkennung;
die Charakteristik war im GATT-Baum sichtbar, wurde aber nur als weiterer
Schreibkandidat behandelt.
Neu ist WattCycleProtocol mit Rahmenbau (1E … 0D für Anfragen, 7E … 0D für
Antworten), Prüfsummen und der Auswertung des Messwert-Datensatzes
0x008C. Der ist selbstbeschreibend: Zellenanzahl, Zellspannungen,
Fühleranzahl, MOSFET- und Platinentemperatur, Zellfühler, dann Strom,
Spannung, Kapazitäten, Zyklen und Ladezustand. Der Strom hat ein eigenes
Format, bei dem Bit 15 das Vorzeichen und Bit 14 die Nachkommastelle
angibt. Aus Datenpunkt 0x0092 kommen Modell, Hersteller und Seriennummer,
die einmalig gelesen und in der Detailansicht gezeigt werden.
BMSSession kennt die Freischaltung jetzt als Teil eines Kandidaten: liegt
im selben Dienst eine FFFA-Charakteristik, wird nach dem bestätigten Abo
kurz gewartet, freigeschaltet, nochmal gewartet und dann erst abgefragt.
Für die anderen Protokolle ist das unschädlich.
Protokoll und Feldbelegung stammen aus frabnet/esphome-wattcycle-ble. Die
dortige Tabellen-Prüfsumme ist gegen den klassischen Modbus-CRC
nachgerechnet (identisch über 3063 Testfälle), sodass die vorhandene
CRC-Funktion genügt und die 512 Byte Tabellen entfallen. Die
Anfragerahmen sind byteweise abgesichert, die Auswertung an einem
vollständigen Datensatz – 107 Prüfungen laufen durch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Suche nach dem richtigen Verbindungsweg blieb auf dem ersten
Kandidaten stehen: gesendet wurde erst, nachdem iOS das Abonnieren der
Notify-Charakteristik bestätigt hat. Bestätigt ein Modul das nie – bei
der WattCycle-Batterie auf FFF1 der Fall –, wurde weder je eine Anfrage
geschickt noch zum nächsten Kandidaten gewechselt. Die Diagnose zeigte
dauerhaft "1 von 16" und "0 Anfragen / 0 Byte".
Die Aktivierung eines Kandidaten hat jetzt ein Zeitlimit von vier
Sekunden. Läuft es ab, geht es zum nächsten; ist es der einzige Weg,
wird trotzdem gesendet – manche Module antworten auch ohne bestätigtes
Abonnement. Ein Token verhindert, dass verspätete Rückmeldungen eines
bereits verworfenen Kandidaten den aktuellen durcheinanderbringen.
Damit sich Fortschritt überhaupt beobachten lässt, wird die Diagnose
jetzt bei jeder gesendeten Anfrage aktualisiert statt nur am Ende einer
Runde, und zeigt zusätzlich Verbindungszustand, ob der Empfang abonniert
ist, und wann zuletzt gesendet wurde. Die Suche ist enger getaktet, damit
alle Wege in gut zwei Minuten durch sind.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die WattCycle-Batterie meldete sich am FFF0-Dienst, nahm aber keine
Kommandos an. Grund: dort ist FFF1 die erste beschreibbare
Charakteristik, sie sieht schreibbar aus und bleibt trotzdem stumm –
Kommandos gehören auf FFF2.
Statt die richtige Charakteristik zu raten, stellt BMSSession jetzt alle
Paare aus schreibbarer und benachrichtigender Charakteristik zusammen,
jeweils mit und ohne Schreibbestätigung, und arbeitet sie ab, bis eines
antwortet. Bekannte Paare (FFF2/FFF1, FF02/FF01, Nordic UART) kommen
zuerst dran; ein Kandidat, der sich nicht abonnieren lässt, wird sofort
übersprungen. Auf jedem Weg werden weiterhin Daly klassisch, Daly Modbus
und JBD angefragt.
Die Diagnose zeigt dazu den vollständigen GATT-Baum des Geräts, den
gerade versuchten Weg samt Position in der Kandidatenliste sowie Zähler
für gesendete Anfragen und empfangene Bytes. Damit lässt sich
unterscheiden, ob das BMS die Kommandos gar nicht annimmt oder ein
unbekanntes Protokoll spricht.
Nebenbei: "caravan" existiert nicht als SF-Symbol und ließ SwiftUI
stillschweigend auf Text zurückfallen – in den Demodaten ersetzt.
README auf Profile und WattCycle/JBD nachgezogen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
