BLE auf ESP32 mit MicroPython

Entwicklung / Development Funkinfrastruktur / Wireless infrastructure
, ,
8

CircuitPython unterstützt den ESP32 (noch?) nicht, was schade ist, denn die Implementierung sieht gut aus.
Hardware wäre wohl dann das:


bzw.:

Beim “offiziellen” MicroPython wird daran gearbeitet:

oder eben ein WiPy.

Das Ding von Adafruit sieht ganz nett aus. Der Preisunterschied zum WiPy (ohne Expansionboard) ist ca. 0. Da aber die Implementierung ein bisschen anders als bei pycom ist, lohnt sich der Mehraufwand wohl eher nicht.
Sollten die ESP32 mal direkt unterstützt werden, wäre das eine andere Sache. Die bekommt man deutlich günstiger.

1 Like
9

Die ItsyBitsy’s haben aber keinen Nordic Bluetooth Eumel drauf…

10

Das liest sich doch schonmal nicht schlecht?

Hier drüben bei GitHub - aykevl/micropython at bluetooth kommt die Entwicklung her.
Erst frisch im letzten Monat gebaut scheint modbluetooth.c der letzte Stand der Implementierung zu sein.

11

D’oh - das hab ich glatt übersehen… :slight_smile:

1 Like
12

Wenn das eine Option für dich ist, wäre das super, da die anderen Geschichten (Waage, Temperatur, Feuchte) intensiv von uns beackert wurden, du statt BLE auch alternativ später mit einem FiPy oder GPy/LoPy LTE nutzen könntest oder LoRa! Wenn wir dich irgendwie dazu “überreden” können wäre das prima! ;-)

1 Like
13

Erstmal wäre das wirklich praktisch und da BLE GATT für den ESP32 im MicroPython Universum von Pycom ordentlich erschlossen zu sein scheint (wir werden sehen ;]), will das unbedingt eine weitere mögliche Telemetrie- und Steuerungseinheit für die genannte Firmware werden – sehr gerne früher als später, nachdem wir kürzlich ja auch erst bei Erschließung von LTE Cat M1 und NB1 mit dem Pycom FiPy endlich Land sehen konnten ;].

Mittelfristig wäre es toll, wenn wir die Angelegenheit gemeinsam auch auf andere MicroPython-Plattformen als die von Pycom bringen könnten [1].

  1. Momentan ist die Firmware durch die Benutzung einiger systemnaher Module bislang vermutlich ausschließlich auf Pycom MicroPython lauffähig. Die Anpassungen werden jedoch für die wichtigsten Funktionalitäten nicht dramatisch sein und wir werden demnächst die Gelegenheit haben, die Firmware auf einem pyboard-D ausprobieren zu können. ↩︎

14

Diesmal ganz ohne MicroPython, dafür aber u.U. für eine hostseitige Integration mit SBCs oder Workstations.

Andere sind:

15

Bei bluetooth — low-level Bluetooth — MicroPython latest documentation ist die kanonische Inline-Dokumentation zu finden. Vielleicht hilft Dir das beim Einstieg weiter, @poesel.

16

Recht frisch kam hier auch vor drei Tagen examples/bluetooth: Add basic BLE peripheral examples. · micropython/micropython@25a228a · GitHub dazu. Die Beispiele finden sich unter micropython/examples/bluetooth at master · micropython/micropython · GitHub.

17

@poesel: As we talked about the nitty gritty details of this the other day, I would like to point you out to [1] and [2], where we have outlined our findings regarding implementing custom characteristics on top of the Bluetooth software stack of Pycom MicroPython.

  1. Implementing BLE GATT ESS characteristics with MicroPython ↩︎

  2. BLE custom service/characteristics handles and descriptors | Pycom user forum ↩︎

1 Like
18

BLE is not too terribly difficult. You can piece most parts together from examples and the documentation. My current problem is proper debugging. I’m not sure if its the code, uPy or iOS whos at fault.
I’m running the temperature example and it shows up as battery level on iOS and as temperature on macOS but without the correct value. Hmmm…
I’m trying to borrow an Android phone. The BLE apps there are much better.

I have a first draft on my github ESP32 branch if anyone is interested.
https://github.com/poesel/hiveeyes-micropython-firmware/tree/esp32/terkin/network

1 Like
19

Dear Markus,

Right, not in general ;].

Are we talking about the BLE GATT “Temperature Measurement 2A1C” characteristic here? If so, the encode_ieee11073 function might help you along.

We have been using nRF Connect for Mobile recently, see Implementing BLE GATT ESS characteristics with MicroPython.

Good luck!

Cheers,
Andreas.

20

Please note this has been superseded by

It looks like the implementation for the MicroPython ESP32 port will be based on NimBLE.

About Apache NimBLE

See also

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.