Conclave Access

[jdeath]

The device

Edit: AI was able to get a persistent connection going. I'll post code. Might be a nicer way to control this and get instant updates

@Expl0dingBanana

Do you have any recent mitmproxy logs? I cannot intercept the app any more beyond the login protocol. Back in the day, I found some direct TCP traffic, which would allow you to receive pushes of state changes instead of polling. I never could figure it out. With the advent of AI I have gotten further, but the login information changed. Can you see any traffic like this in your logs:

It will be a TCP connection.

⇒ {}
⇐ 0000000000 78 01 aa 56 ca 48 cd c9 c9 57 b2 aa 56 2a 4b 2d   x..V.H...W..V*K-
⇐ 0000000010 2a ce cc cf 53 b2 52 4a ce cf 4b ce 49 2c 4b 55   *...S.RJ..K.I,KU
⇐ 0000000020 30 d2 33 d7 33 56 d2 51 ca 48 4d 2c 2a 49 4a 4d   0.3.3V.Q.HM,*IJM
⇐ 0000000030 2c 51 b2 32 33 d0 51 4a 2a 4d 4b 4b 2d 0a ce ac   ,Q.23.QJ*MKK-...
⇐ 0000000040 4a 55 b2 32 35 32 31 b2 b0 a8 ad e5 02 08         JU.2521.......
⇐
⇐ {"hello":{"version":"conclave 2.7.3","heartbeat":60,"bufferSize":524288}}
⇒
⇒ {"login":{"channelId":"XXXXX","accessToken":"XXXXX","type":"android","version":"1.0.0","protocol":2,"trace":true}}

This log is from 4 years ago, so I think they changed the login protocol. If you have any recent traffic, can you post it here? I can receive the hello message thanks to Claude, but my login is rejected.

If you have a version of the app and a mitm method that allows this to work, please let me know too. Just thought I would mess with it.

Features

push access

Datadump

none

Additional information

No response

[jdeath]

@Expl0dingBanana Sorry for the spam, but this is so awesome.

I attached a script I worked with Claude.

• First run it generates a config file. Enter your hubspace user/password.
• 2nd run it logs in to hubspace, using the code I wrote years ago to get the Conclave tokens. These will be cached in the config file because each run logs you in and triggers an email.
• It then establishes a direct TCP connection to hubspace
• Toggle a device manually with the app. Hubspace sends a message back to the socket confirming the change
• If you click "t", it will then toggle that device back (via regular rest interface)

Probably very parallel to json based commands, but this way you get near instant response and do not need to poll. I am not sure how to integrate into aiohubspace, but I think this will add some good capability.

Finally figured out after 4 years (with help of claude)!

ws_listener.py
Note: userID and mobileDeviceId can be commented out in the login, it is not needed

[Expl0dingBanana]

@jdeath I am hoping to be able to look into this stuff in the coming weeks once I get approval to work on this with the new job (I forgot to declare it prior to joining :( )

With that said, I would look into the 2FA auth as that may get you in.

from aioafero import v1
import logging
logging.getLogger("aioafero").setLevel(logging.DEBUG)
USERNAME="" # Afero IOT username
PASSWORD="" # Afero IOT password
POLLING_INTERVAL=30 # Number of seconds between polling cycles
# Create the bridge
bridge = v1.AferoBridgeV1(USERNAME, PASSWORD, polling_interval=POLLING_INTERVAL, hide_secrets=False)
# Query the API and populate the controllers
await bridge.initialize()
# If OTP is enabled on the account, it will need to be provided here
await bridge.otp_login("<OTP_CODE>")

[jdeath]

Sorry, I edited the post. Working TCP socket script is posted. This could be a game changer.

I just do not know how to integrate into aiohubspace . congrats on new job! It can definitely wait!

[Expl0dingBanana]

I have new data, update the models: https://github.com/Expl0dingBanana/aioafero/blob/main/src/aioafero/v1/controllers/event.py#L223

I want to send new data to hubspace: https://github.com/Expl0dingBanana/aioafero/blob/main/src/aioafero/v1/controllers/base.py#L488

I need a keep alive (there is logic to auto-refresh the token when needed though):
https://github.com/Expl0dingBanana/aioafero/blob/main/src/aioafero/v1/controllers/event.py#L142

[Expl0dingBanana]

Honestly, I think you just update the "i want to send new data to hubspace" then have it emit an event (https://github.com/Expl0dingBanana/aioafero/blob/main/src/aioafero/v1/controllers/base.py#L528) it should all work correctly. The hard part will be if it doesnt respond with the devices full payload the update logic may not work (due to how device splits work)

[jdeath]

The aiohubspace is a little too complicated for me. Way more advanced (and better) than the simple code I wrote years back!

It only responds with the change of the specific attribute, not the whole payload. Hopefully not a deal breaker:

[recv] {"private":{"sessionId":0,"event":"attr_change","data":{"id":"YYY","attribute":{"id":2,"data":"01","value":"1","updatedTimestamp":XXXXXXXXX},"sourceHubId":"XXXXXXX","state":0,"reason":2,"requestId":-48},"xid":"XXXXXX"}}

Also the conclave only sends an attribute index (which is also returned in the REST API) but not the name the API uses. The YYY id is the device id, so at least that comes back ok. You cannot send commands via conclave.

[Expl0dingBanana]

I can look into this after I clean up the other issues.

[Expl0dingBanana]

I got mitmproxy setup again. How did you trigger anything via conclave before? I still just see typical PUTS in the log

EDIT: Nevermind, I have the full capture. I will try to decipher this (well, cursor will through the whole dump) after I fix up a few more things.

## Conclave capture notes (2026 — Hubspace Android, mitmweb WireGuard)

Captured with **mitmweb in WireGuard mode** + rooted emulator + system CA injection. Conclave is still active; the protocol shape matches the 2022 trace, but transport and auth bootstrap changed.

### Setup required to see Conclave

Default mitmweb WireGuard mode only shows HTTP/HTTPS. Enable TCP/TLS interception:

    mitmweb --mode wireguard --tcp-hosts ".*"

Without `--tcp-hosts`, the Conclave socket is invisible in the UI even though traffic passes through the tunnel.

### What changed since the old capture

| Then (~2022) | Now (2026) |
|--------------|------------|
| Raw TCP | **TLS on port 443** to `conclave-stream1.afero.net` |
| Unknown auth for login | **`POST .../conclaveAccess`** mints a short-lived token |
| Plain zlib on wire | Still zlib for `hello`, then JSON frames inside TLS |

Cert SANs on the Conclave host include: `conclave-stream1.afero.net`, `conclave-api1.afero.net`, `conclave-internal1.afero.net`, `cdn1.afero.net`, etc.

### Auth bootstrap (likely cause of rejected login)

Before opening the socket, the app calls:

    POST https://api2.afero.net/v1/accounts/{accountId}/conclaveAccess
    Authorization: Bearer {oauth_access_token}
    Content-Type: application/json

    {"user": true, "softHub": false}

Example response structure:

    {
      "conclave": {
        "host": "conclave-stream1.afero.net",
        "ssl": true,
        "compression": true,
        "port": 443
      },
      "tokens": [{
        "token": "<short-lived-uuid>",
        "channelId": "<accountId>",
        "type": "account",
        "expiresTimestamp": 1780876821586,
        "client": {"type": "user", "userId": "<user-uuid>"}
      }],
      "conclaveHosts": [
        {"type": "socket", "host": "conclave-stream1.afero.net", "protocol": "https", "port": 443},
        {"type": "http",   "host": "conclave-api1.afero.net",     "protocol": "https", "port": 443}
      ]
    }

**Important:** the socket `login.accessToken` is **`tokens[0].token` from this response**, not the OAuth bearer JWT. Using the JWT for login likely explains "hello works, login rejected."

- `channelId` = **account UUID** (same as `{accountId}` in the URL path)
- Tokens may be **single-use** — a failed first connect was followed by a fresh `conclaveAccess` call and a second token before login succeeded

### Socket handshake (TLS to `conclave-stream1.afero.net:443`)

| Step | Direction | Payload |
|------|-----------|---------|
| 1 | client → server | `{}` |
| 2 | server → client | zlib blob (`78 01 …`) |
| 3 | server → client | `{"hello":{"version":"conclave 2.7.3","heartbeat":60,"bufferSize":524288}}` |
| 4 | client → server | `{"login":{"channelId":"<accountId>","accessToken":"<conclaveAccess-token>","type":"android","version":"1.0.0","protocol":2,"trace":true}}` |
| 5 | server → client | `{"tunnel":{...}}` |
| 6 | server → client | `{"welcome":{"sessionId":643,"seq":0,"generation":...,"channelId":"<accountId>","accountId":"<accountId>","heartbeat":60}}` |
| 7 | server → client | `{"join":{"timestamp":...,"sessionId":643,"type":"client","mobileDeviceId":"<uuid>","version":"1.0.0"}}` |
| 8+ | both | `\n` heartbeat every ~60s |
| 9+ | server → client | `{"private":{"event":"attr_change",...}}` — live state pushes |

### ID mapping — Conclave vs REST

Conclave and REST use **different IDs**:

| Layer | ID type | Example role |
|-------|---------|--------------|
| REST writes / metadevices | `metadeviceId` (UUID) | `PUT .../metadevices/{uuid}/state` |
| Conclave `private` events | `deviceId` (16 hex chars) | Physical radio / ASR identifier |
| Underlying radio | BLE MAC (in device state) | Related to `deviceId` |

For at least one WiFi-direct ceiling fan, `deviceId` = **4-char prefix + BLE MAC** (no colons), e.g. `81e1` + `{ble-mac}`. Other product types used different prefixes (`8ad8`, `8993`, `8ea6`, …) — prefix may vary by device class.

Split metadevices (fan + light on the same physical unit) **share one `deviceId`**. Conclave events are keyed by `deviceId`; the attribute key tells you which function changed.

Because the device was WiFi-direct (`direct: true`), `sourceHubId` equaled the same `deviceId` (no separate hub box).

### Push events — `private` / `attr_change`

Example (fan toggled off, then on via app):

Fan off — two attributes update:

    {"private":{"sessionId":0,"event":"attr_change","data":{
      "id":"<deviceId>",
      "attribute":{"id":1,"data":"00","value":"0","updatedTimestamp":...},
      "sourceHubId":"<deviceId>","state":0,"reason":1,"requestId":0
    },"xid":"<hex>"}}

    {"private":{"sessionId":0,"event":"attr_change","data":{
      "id":"<deviceId>",
      "attribute":{"id":3,"data":"00","value":"0","updatedTimestamp":...},
      "sourceHubId":"<deviceId>","state":0,"reason":2,"requestId":-113
    },"xid":"<hex>"}}

Fan on — same attributes, value `"1"`:

    {"attribute":{"id":1,"data":"01","value":"1",...}}
    {"attribute":{"id":3,"data":"01","value":"1",...}}

REST write that triggered this (single PUT):

    {
      "metadeviceId": "<metadevice-uuid>",
      "values": [{
        "functionClass": "power",
        "functionInstance": "fan-power",
        "value": "off"
      }]
    }

Push arrived ~0.7s after each PUT — no polling needed.

### Attribute ID → semantics mapping (ceiling fan profile)

`attribute.id` in Conclave matches **`deviceValues[].key`** in metadevice semantics:

| Attr ID | `functionClass` / `functionInstance` | Meaning |
|---------|--------------------------------------|---------|
| 1 | `power` / `primary` | Device primary power |
| 2 | `power` / `light-power` | Light on/off |
| 3 | `power` / `fan-power` | Fan motor on/off |
| 4 | `brightness` / — | Light brightness |
| 5 | `color-temperature` / — | Color temperature |
| 6 | `fan-speed` / `fan-speed` | Fan speed |
| 7 | `fan-reverse` / `fan-reverse` | Direction |
| 8 | `toggle` / `comfort-breeze` | Comfort breeze |

Toggling `fan-power` via REST produced Conclave pushes for **both** attribute 1 (primary) and 3 (fan-power) — the firmware couples them on this device class.

### Field glossary (`private` / `attr_change`)

| Field | Notes |
|-------|-------|
| `id` | Physical `deviceId` (not metadevice UUID) |
| `sourceHubId` | Reporting hub/device; equals `id` for WiFi-direct devices |
| `attribute.id` | Semantics attribute key (see table above) |
| `attribute.data` | Raw hex string (`"00"`, `"01"`, …) |
| `attribute.value` | Decoded string value (`"0"`, `"1"`, …) |
| `attribute.updatedTimestamp` | ms epoch; aligns with REST `lastUpdateTime` |
| `reason` | `1` for attr 1, `2` for attr 3 in this capture — likely subsystem/source enum |
| `requestId` | Internal correlation (`0`, negative values seen) |
| `state` | Always `0` in this capture |
| `xid` | Event transaction ID (hex) |

### Suggested client implementation sketch

1. `POST /v1/accounts/{accountId}/conclaveAccess` with OAuth bearer + `{"user": true, "softHub": false}`
2. TLS connect to `conclave-stream1.afero.net:443`
3. Send `{}` → read zlib `hello` → send `login` with `channelId` (= account UUID) + `token` from step 1
4. Handle `welcome`, `\n` heartbeats, and `private` / `attr_change`
5. Map pushes to REST state: index metadevices by `deviceId`, resolve `attribute.id` via semantics, update `(functionClass, functionInstance)`

### Timeline (representative session)

    +0s     GET metadevices
    +0s     conclaveAccess #1 → token A
    +0.4s   TCP connect #1, login with token A → no welcome (7 messages, dies)
    +8s     conclaveAccess #2 → token B
    +9s     TCP connect #2, login with token B → welcome + join
    +18s    PUT fan-power OFF  →  ~0.7s later: attr 1→0, attr 3→0
    +28s    PUT fan-power ON   →  ~0.7s later: attr 1→1, attr 3→1

[Expl0dingBanana]

More poking and I am getting updates extremely quickly from conclave when using the RF remote. Cursor does seem to have the mapping figured out so after the light changes are verified I will make sure this gets implemented for aioafero==8.0.0

These changes will enable a very long "sanity check" poll (maybe once every 10-15m) then just use HA's socket handling to ensure that we get our pub / sub correct.

[jdeath]

It was from one of my original mitm's years ago. I just never could figure out the websocket until AI!

I have not been able to get mitm working on any recent apps even with magisk and modules to trust user certs. Do you have any tricks? I tried wiregaurd mode, but didn't work for me. Looks like that is what you are doing.

[Expl0dingBanana]

Its not refined and ill classify it as AI slop for now, but this is how I mostly set it back up, https://github.com/Expl0dingBanana/aioafero/blob/docs/mitm/docs/mitm_testbed.rst.

I did not want to re-install Ubuntu so I slowly got AI to clobber together something that ran with Windows + WSL + Docker.

Edit: I asked cursor how much AI slop there was and it told me " slop is moderate, mostly repetition and over-explaining the same concepts, not buzzword filler."

[Expl0dingBanana]

You can see RTD @ https://aioafero.readthedocs.io/en/api-break-8.0.0/mitm/index.html. May make it easier to read.

[Expl0dingBanana]

Making good progress on this. This is me adjusting the light via RF remote and getting responses in near real-time.

TRACE event handled: DeviceController RESOURCE_UPDATED device_id=8866648e-ef12-47b1-a7af-16c86214933e
TRACE controller→subscriber: LightController RESOURCE_UPDATED Ceiling Light (light) id=8866648e-ef12-47b1-a7af-16c86214933e
TRACE subscriber callback: Ceiling Light (light) id=8866648e-ef12-47b1-a7af-16c86214933e
[16:08:35] Ceiling Light (light, 8866648e-ef12-47b1-a7af-16c86214933e)
  • brightness: 60% → 40%
INFO aioafero.v1-hubspace[chris.dohmen11+accounts.hubspaceconnect.com@gmail.com].conclave: Conclave attr_change: device=81e130c9228b043a attr=4 value='20' data='14'
DEBUG aioafero.v1.conclave.events: Conclave attr_change applied on 8866648e-ef12-47b1-a7af-16c86214933e: brightness/None=20
DEBUG aioafero.v1.conclave.events: Ignoring Conclave attr_change for unknown attribute id=4 on 77b1c8c0-f530-4e90-b373-c2c4e8a1af07
DEBUG aioafero.v1.conclave.events: Ignoring Conclave attr_change for unknown attribute id=4 on 9aefd01c-2e4c-4775-8bcc-cc779a42f9e7
TRACE dropped: DeviceController RESOURCE_UPDATED id=8866648e-ef12-47b1-a7af-16c86214933e (device not found or no model diff)
TRACE event handled: DeviceController RESOURCE_UPDATED device_id=8866648e-ef12-47b1-a7af-16c86214933e
TRACE controller→subscriber: LightController RESOURCE_UPDATED Ceiling Light (light) id=8866648e-ef12-47b1-a7af-16c86214933e
TRACE subscriber callback: Ceiling Light (light) id=8866648e-ef12-47b1-a7af-16c86214933e
[16:08:38] Ceiling Light (light, 8866648e-ef12-47b1-a7af-16c86214933e)
  • brightness: 40% → 20%