Hi, Is there any news?
I may purchase a tuma comfort if necessary.
Do we get the information just with a bluetooth proxy? What are the limitations?
are you able to make the wireshark ble trace available?
I let analyse ChatGPT the wireshark file with succes. Chat did found some commands, but has to be tested and further sniffed like chat proposes.
The wireshark file is available above in this thread, uploaded by another user.
Another way of working can be reverse engineering the android app.
This is the chat response in Dutch, you can Google translate it.
Top — ik heb het btsnoop HCI-bestand (geberit_duofresh_hci_snoop.cfa) ingelezen en geanalyseerd. Hieronder vind je wat ik concreet uit de trace heb gehaald, welke GATT-handvatten en ATT-PDUs het meest voorkomen, welke mogelijke sensoren je kunt maken en welke commando’s je waarschijnlijk kunt sturen met de twoenter/geberit_home_bt integratie. Ik heb ook concrete hex-payloads en Home-Assistant/bleek-implementatie-suggesties toegevoegd zodat je direct aan de slag kunt.
> Kort: het bestand is een standaard btsnoop HCI capture en bevat vooral BLE ACL/ATT verkeer. De repo twoenter/geberit_home_bt is bedoeld als custom component en bevat momenteel vooral diagnostische sensoren (README).
---
Samenvatting van de parsing (wat ik vond)
Bestandsformat: btsnoop (ble HCI snoop).
Aantal HCI-records in jouw capture: 1548.
De trace bevat voornamelijk ACL/ATT pakketten (ATT CID 0x0004) en een paar SMP-berichten (CID 0x0005).
Meest voorkomende ATT-opcodes:
0x1B — Handle Value Notification (888 keer) — ziet ernaar uit dat het apparaat veel status naar de client pusht.
0x52 — Write Command (no response) (604 keer) — de client (app) stuurt veel commando’s.
Daarnaast: Read By Type / Read By Group Type en enkele write/read responses.
Belangrijkste GATT handles uit de capture:
Handle 0x0030 — dominant in notifications (veel notificaties met verschillende payloads). Dit lijkt de belangrijkste status/telemetrie characteristic te zijn.
Handle 0x002e — dominant voor Write Command (0x52); dit lijkt de control/write characteristic te zijn waar de app commando’s naartoe stuurt.
Verder zie je diverse discovery/metadata responses (andere handles) maar die zijn minder frequent.
---
Concrete hex-voorbeelden uit de capture (meest voorkomende)
(ik geef hex-bytes zoals die in de ATT PDU verschijnen: PDU opcode + handle + waarde; hieronder zijn alleen de waarde-payloads getoond - dus de bytes die daadwerkelijk op de characteristic geschreven of genotificeerd werden)
Meest voorkomende notificatie-waardes op handle 0x30 (waarde-payloads, met frequenties):
00 04 21 8b 30 00 — veel voorkomens (variaties en herhalingen)
00 04 41 8d 53 00
00 04 61 8f 72 00
00 04 81 81 95 00
00 04 a1 83 b4 00
(er zijn ook langere blobs aanwezig — waarschijnlijk firmware/identificatie / cryptodata / grotere telemetryblokken)
Meest voorkomende write-commando’s naar handle 0x2e (waarde-payloads, met frequenties):
00 04 a1 83 b4 00 (48x)
00 04 41 8d 53 00 (47x)
00 04 e1 87 f6 00 (46x)
00 04 61 8f 72 00 (45x)
00 04 81 81 95 00 (44x)
00 04 c1 85 d7 00 (44x)
00 04 01 89 11 00 (43x)
00 04 21 8b 30 00 (39x)
Daarnaast enkele grotere/andere writes (bijv. 00 04 2f f5 d9 00, 00 01 01 01 01 00) die mogelijk mode/flag sets zijn.
Let op: veel van de payloads hebben een duidelijke herhalende structuur: ze beginnen vaak met 00 04 gevolgd door 3 of 4 bytes en een 00-terminator. Dat wijst op een TLV/commandId + parameters patroon of meerdere korte velden achter elkaar.
---
Wat kun je praktisch maken voor de integratie?
1) Status-sensoren (recommended)
Algemene status / telemetry sensor: subscribe (enable notifications) op handle 0x0030. Dit levert regelmatig notificaties; parse deze payloads en maak er sensoren van:
fan_speed — waarschijnlijk één byte in de payload verandert als je snelheid aanpast (test: verander snelheid in de app en kijk welke byte(s) veranderen).
light_on/off — bit of byte in dezelfde notificatie is vaak verantwoordelijk voor lamp-status.
filter_life / filter_alert — langere blobs of een specifiek bytepaar dat zelden verandert kunnen filterstatus zijn.
device_id / fw_version — de langere blobs die af en toe komen kunnen identificatie/firmware zijn — 1 sensor tekst.
Technisch: in de component maak je een notificatie-callback op handle 0x30 en parse de waarde naar verschillende HA sensors (numeric, binary_sensor, sensor tekst). De integratie repo momenteel noemt “diagnostic sensors” — uitbreiding naar parsed state is dus een logische volgende stap.
2) Acties / commando’s
Schakel / stel in door writes naar handle 0x002e met Write Command (Write Without Response) — dat is exact wat de Android app doet in je capture.
Mogelijke acties die je kunt toevoegen in de integratie (gebaseerd op de voorbeelden die terugkomen in de capture):
set_fan_speed(<0..n>) → schrijf specifieke payload (zie tabel hieronder).
toggle_light(on/off) → schrijf payload(s) bij light aan/uit (moet je verifiëren door in app te togglen en te kijken welke bytes veranderen).
reset_filter of clear_alarm → waarschijnlijk een write met een specifieke command-id.
start_boost / stop_boost / set_mode → sommige korte commands lijken mode-bytes te bevatten.
Belangrijk: de app gebruikt Write Command (0x52) in jouw trace — dat betekent write without response. Voor Home Assistant/bleak: gebruik write_gatt_char(handle, bytes, response=False) of de equivalente functie in de integratie.
---
Concrete mapping-uggestie (voorbeeld hoe je het in code/action toevoegt)
1. Subscribe to notifications op handle 0x30 en log elke inkomende notification (hex). Maak één sensor geberit.status_raw met de hexpayloads zodat je binair kan analyseren.
2. Voeg parsing rules toe (voorbeeld pseudo-code):
# PSEUDO (Python) — in de custom component
def handle_notification(handle, data: bytes):
# data = bytes van notification (zoals b'\x00\x04\x21\x8b\x30\x00' of langere)
# voorbeeld: als byte 2 verandert volgens een set van waarden -> fan speed
b = list(data)
# heuristiek:
fan_speed = b[2] & 0x0f # voorbeeld extract
light_flag = (b[2] >> 4) & 1 # voorbeeld
# update HA entities
hass.states.set("sensor.geberit_fan_speed", fan_speed)
hass.states.set("binary_sensor.geberit_light", "on" if light_flag else "off")
# store raw for further analysis
hass.states.set("sensor.geberit_raw", data.hex())
3. Voorbeeld write (commando) — met bleak of integratie:
# schrijf naar handle 0x2e (little endian handle address passed to library)
# voorbeeld: zet fan naar 'X' (payload uit capture)
await client.write_gatt_char(0x2e, bytes.fromhex("0004218b3000"), response=False)
> De hexes hierboven zijn voorbeelden rechtstreeks uit je capture. Voer testen uit (druk in app, observeer notificaties) om te koppelen welke hex welk gedrag veroorzaakt.
---
Concrete next-stappen / experimentplan (zodat je snel exacte betekenis kunt bepalen)
1. Reproduceer en log: zet je telefoon met de app naast de geberit en voer één actie tegelijk uit (bijv. lamp uit → aan, fan 1→2→3, filter reset). Neem telkens een korte btsnoop. Vergelijk welke bytes veranderen in de notifications en writes.
2. Map bytes to functions: noteer per actie welke byte(s) in:
notification (handle 0x30) veranderen → dit is status
write (handle 0x2e) die de app stuurt → dit is commando
3. Update integratie:
Voeg notificatie subscription op 0x30 toe en parse naar meerdere HA entities.
Voeg service calls of entities (switch/select) die write_gatt_char(0x2e, <hex>, response=False) uitvoeren bij user action.
---
Wat ik concreet voor je kan doen nu (zonder dat jij iets hoeft te doen)
(A) Maak een lijst met de top 25 unieke write-payloads en top 25 unieke notificatie-payloads (inclusief aantallen) — zodat je snel ziet welke payloads vaak voorkomen (heb ik al deels gedaan hierboven).
(B) Schrijf een voorbeeld Python/HA-custom_component snippet waarmee:
subscribes naar 0x30 en parsed notificaties publiceert als sensoren;
exposes services geberit.set_fan_speed, geberit.toggle_light die writes naar 0x2e doen;
(C) Maak een kort test-protocol (wat je in de app moet doen terwijl je capture draait) en een parser-template die byte-changedetection automatisch rapporteert (dus: “veranderde byte 2 bij fan speed change”).
Wil je dat ik (nu meteen) optie (A) en (B) uitvoer en je de resultaten + ready-to-paste code geef? Ik kan die direct genereren (ik heb de capture al geparseerd en kan de top-payload tabellen + een codevoorbeeld uitschrijven).
---
Veiligheid & voorzichtigheid
Ik heb alleen de BLE sniffed data geanalyseerd die jij uploadde — geen interactie met je apparaat zelf.
Gebruik de exacte write-payloads alleen op je eigen apparaat. Sommige payloads kunnen veiligheids-of firmware-instellingen wijzigen; test voorzichtig en op eigen risico.
---
Als je wilt dat ik direct verder ga (ik kan nu meteen):
geef ik een volledige tabel met de TOP-25 write-payloads + counts en TOP-25 notificaties + counts (volledig hex en frequentie),
en produceer ik een concrete Python/HA snippet (custom component-stijl) die notificaties op 0x30 verwerkt en services maakt die writes op 0x2e uitvoeren.
Wil je dat ik dat nu voor je uitwerk? (ik kan het direct doen en je krijgt een copy-paste klaar voorbeeld).```
1 Like