zampino

Help with pairing device with BlueHeron on Raspberry Pi Zero 2 W

Hello nervlers!

I’m trying to connect a bluetooth printer (thermal ESC/POS “driverless”) to a Raspberry Pi Zero 2 W.
Nerves on the RaspBerry and BlueHeron are working fine (at least with this commit ) and I can connect to the printer via the ATT Client (as per the govee lightbulb examples in BlueHeron repo).

But from there on I’m lost, and not sure if the ATT layer alone is sufficient for this task at all.
To start with, the Govee example uses a hardcoded handle (0x0015) in the BlueHeron.ATT.Client.write/3 which I don’t know where is coming from, so I tried the connection handle itself but that gave no outcome.

The point is: the printer peripheral requires an authentication step via a PIN to be paired with the central role.

Did anyone try/manage to pair a device via PIN with BlueHeron?
Does that correspond to integrate the SMP layer with the ATT client?
Can I convince my device to not require authentication?

In fact I can e.g. send data to the printer from mac OS only after first pairing it via its PIN:

This is an excerpt of the packet logs (via packetlogger) between macOS and the printer during pairing:

A lot of the mentioned packets (link policy, authentication requested, etc.) are present in the BlueHeron library but I wouldn’t know how/if they can be fitted into the ATT Client connection.

And these are the packets exchanged when I send data via a serial debugging tool from mac to the printer to have it print “hello”:

Mac OS seems to change the connection packet type (?) to RFCOMM, but the RFCOMM packet type is not mentioned at all in BlueHeron packets/modules, is there an alternative to that?

I’ll keep trying to integrate SMP, but any help around that would be much appreciated.
A big thank you to the maintainers of nerves and blue heron!!

2 comments

/nerves #bluetooth #blue_heron #raspberry-pi-zero

2 419 2

2024-05-09 08:47:00 UTC

Most Liked

ConnorRigby

Nerves Core Team

To start with, the Govee example uses a hardcoded handle (0x0015) in the `BlueHeron.ATT.Client.write/3

This handle came from the ATT table. When that example was written, we didn’t have GATT support yet, so the hardcoded value was used.

You’re on the right track with SMP. I know that BlueHeron doesn’t currently support SMP for the ATT client, but it shouldn’t be that hard to add. It’s been a while since i looked in there, but the spec is pretty readable on how it should work. I think all of the required algorithms should be implemented already.

Post #2

Last Post!

zampino

Turns out that was drastically false!

Again, it’s a matter of finding the correct characteristic handle as mentioned above.

I used a different bluetooth debugging tool (SmartBond for Mac OS) which is able to discover the services/characteristic tree of the device and send via ATT/L2CAP/ACL, bypassing SMP entirely.

I’m confused, but happy it worked.

I guess the missing link in the ATT Client in BlueHeron is implementing the ReadByTypeRequest/Response (hinted at here and here) messages to discover such a handle?

Hope this can turn out useful to others as well.

Post #3