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>
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>
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>
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>
