BLE auf ESP32 mit MicroPython

Entwicklung / Development Funkinfrastruktur / Wireless infrastructure
, ,
21

The problem was not with the content (that will be tackled next) but with the advertisement. Unbeknownst to me there is a 37 byte length limit to the advertisement (in the BT standard). Shortening the name from ‘hiveeyes’ to ‘h’ solved the problem.

I think I’ve been through every (free) BLE app in the Appstore by now. :slight_smile:
Apart from “nRF Connect” “BLE Hero”, “BLE”, “LightBlue” & “BLE Scanner” are suitable for our cause.

1 Like
22

Short update: I have successfully advertised the existence of an ESP32 node to a GPy central, connected them and sent weight and battery level from the ESP32 to the GPy.

TODO:

  • add temperature and humidity
  • add non-standard services for more sensors
  • add a means to give an unique name to a node through a service
  • handle several nodes on the central
  • synchronise time between central and node
  • synchronize sleep between devices

The code is behind the link below. Its a standalone test and not integrated into the firmware, yet. That speeds up debugging.

3 Likes
23

I need some help. I’m reading a service uuid with service.uuid() on the GPy (GATTCService).

The uuid should be ‘04500100-39fd-49ec-b565-b5d6dc31b6ae’. I’m getting back this bytes object:

b'\xae\xb61\xdc\xd6\xb5e\xb5\xecI\xfd9\x00\x01P\x04'

I’m through all struct.unpack permutations but failed to get back anything sensible.
Does anyone know what to do with those bytes?

24

Hi there,

Cool thing. Thanks for letting us know.

Do you use the code at BLE-uPy-Pycom/uPy/main.py at master · poesel/BLE-uPy-Pycom · GitHub to actually encode and send this data?

With kind regards,
Andreas.

25

Yes. The uPy is the sender and Pycom the receiver. The code is in the respective folder.
So encoding on ESP32, decoding on GPy.

26

In fact, it’s just the UUID reversed ;]. @jcaron from the Pycom Forum helped out here, see BLE - decoding service UUID | Pycom user forum.

>>> UUID(bytes=b'\xae\xb61\xdc\xd6\xb5e\xb5\xecI\xfd9\x00\x01P\x04'[::-1])
UUID('04500100-39fd-49ec-b565-b5d6dc31b6ae')
1 Like
27

@poesel made some progress at BLE - decoding service UUID | Pycom user forum, so I have been able to wrap it up into two convenience functions which complement each other

>>> from terkin.network.ble.util import BluetoothUuid
>>> BluetoothUuid.from_bytes_le(BluetoothUuid.to_bytes_le('04500100-39fd-49ec-b565-b5d6dc31b6ae'))
'04500100-39fd-49ec-b565-b5d6dc31b6ae'

There’s also some background information about this big-endian / little-endian BLE UUID mixup within hiveeyes-micropython-firmware/util.py at a8249fd8e9895623de8047ca2d6478dba1351aa8 · hiveeyes/hiveeyes-micropython-firmware · GitHub. If someone knows about these details and sees where I have been wrong, I will be happy to receive appropriate corrections to my conclusions.

28

The ESP IDF recently ported nimble to IDF v3.3.

29

Just found this gem on the Pycom user forum. Might be interesting for some. While this might be specific to Pycom devices, the general idea might also work on Genuine MicroPython.

30

Starting with Pycom’s recent update to ESP-IDF 3.3.1, pycom-esp-idf/components/nimble at idf_v3.3.1 · pycom/pycom-esp-idf · GitHub became part of its ecosystem through Updating submodules to correct commit · pycom/pycom-esp-idf@a2f6952 · GitHub.

However, the implementation of BLE on Pycom didn’t switch over and is still based on Bluedroid.

31

It looks like Genuine MicroPython 1.12 already offers builds based on ESP-IDF v4.x (which probably includes the NimBLE stack) and Mauro Riva is already building upon that. Enjoy!

32

Hierzu auch noch ein weiteres Juwel, das gerade in der Mache ist: