I’ve been working with custom BLE protocols on ESP32 devices, and one part of the development loop became surprisingly repetitive.

A typical test looked something like:

ESP32 connects → client writes an authentication packet → ESP32 sends a notification → bytes need to be extracted and decoded → the client generates another packet → ESP32 responds again.

None of those steps are difficult individually, but when I was changing packet formats, characteristics, authentication logic, or firmware behavior, I ended up repeating the same sequence dozens of times.

I initially used normal BLE scanner apps, but for this kind of ESP32 testing I still had to manually:

* write the same HEX commands
* watch notifications
* copy bytes out of packets
* convert UInt8 / UInt16 / ASCII values
* check whether a response matched the expected format
* send the next command

I also tried writing small test utilities, but maintaining a separate test app every time the ESP32 protocol changed became another thing to maintain.

So I built a reusable workflow system for my BLE tests. A workflow can now do things like:

`Write auth packet → wait for notify → slice bytes → parse UInt16 → check condition → automatically write response`

I eventually turned this into an iOS tool called BLECI, but the part I’m most interested in discussing here is the ESP32-side testing workflow rather than the app itself.

One thing I’m still thinking about is how far this kind of automation should go.

For people building custom BLE services on ESP32: how do you test stateful protocols today?

Do you mostly use nRF Connect / LightBlue manually, Python scripts, automated firmware tests, or a custom mobile test app?

I’m especially interested in cases involving authentication, multi-packet exchanges, notifications, or proprietary binary protocols.

I got tired of manually repeating ESP32 BLE protocol tests, so I built a reusable debugging workflow