BLE GATT notifications working on first connect but stop after phone reconnects — what resets the CCCD?

Yes, the CCCD is getting wiped — that's exactly what's supposed to happen, and it's the source of a lot of confusion.

Why CCCD resets on disconnect

The CCCD (Client Characteristic Configuration Descriptor, UUID 0x2902) stores the client's subscription state: 0x0001 for notifications enabled, 0x0002 for indications enabled, 0x0000 for neither. The BT Core Spec defines this as per-connection state when bonding is not in use. The moment the link drops, the server clears the CCCD back to 0x0000. A new connection starts with all CCCDs disabled, regardless of what the previous connection had configured.

This is by design — if a client disconnects and a different client connects later, you don't want the GATT server to start blasting notifications at an unknown peer that never subscribed.

Diagnosing it

Add a ccc_changed callback to your service and log the value:

static void sensor_ccc_changed(const struct bt_gatt_attr *attr, uint16_t value)
{
    bool subscribed = (value == BT_GATT_CCC_NOTIFY);
    LOG_INF("Sensor notifications %s", subscribed ? "enabled" : "disabled");
}

BT_GATT_SERVICE_DEFINE(sensor_svc,
    BT_GATT_PRIMARY_SERVICE(&sensor_svc_uuid),
    BT_GATT_CHARACTERISTIC(&sensor_char_uuid,
        BT_GATT_CHRC_NOTIFY,
        BT_GATT_PERM_NONE, NULL, NULL, NULL),
    BT_GATT_CCC(sensor_ccc_changed,
        BT_GATT_PERM_READ | BT_GATT_PERM_WRITE),
);

After reconnect, watch your serial console. If you see "Sensor notifications disabled" immediately after connect, the CCCD got cleared on disconnect as expected — but then you should see "enabled" shortly after when the client re-subscribes. If you never see "enabled" after the reconnect, your phone app is not re-writing the CCCD after reconnection, and that's the actual problem.

Fix option 1 — fix the client (phone app)

The correct behaviour for a BLE central is to re-enable CCCD notifications after every new connection, not just the first one. The generic GATT explorer you're using may not do this correctly — it may assume CCCD state persists across connections. For production, your central app must explicitly re-write 0x0001 to the CCCD handle in the connection event handler, every time a new connection is established. You can't rely on the server to remember the subscription.

Fix option 2 — enable bonding on the peripheral

With bonding enabled, the Zephyr BT stack stores CCCD subscriptions in non-volatile storage (via Settings) and restores them automatically when a bonded peer reconnects. The central does not need to re-write CCCD after each reconnect. Add to prj.conf:

CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
CONFIG_BT_BONDABLE=y

And in your application, initialise the settings backend before calling bt_enable():

int main(void)
{
    settings_load();

    int err = bt_enable(NULL);
    if (err) {
        LOG_ERR("bt_enable failed: %d", err);
        return err;
    }
    /* ... */
}

With this in place, after the phone bonds with the device (pairing occurs on first connect), subsequent reconnections by the same peer automatically restore the CCCD state from flash. Notifications resume without the phone needing to re-subscribe.

The bonding route also has the advantage that it works correctly with iOS and Android system BLE caches — both platforms re-use the bonding state and will generally restore CCCD without user interaction after a reconnect. See BLE security and pairing for the bonding setup details if you haven't been through that yet.

If you're not ready to implement bonding, ask whoever owns the phone app to fix the reconnect path — it's one additional write to the CCCD handle in the connect callback.