https://github.com/HomeSmartMesh/sdk-hsm-thingy53
What problem does this project solve ?This Thingy53 is the only ready to use DevKit that integrates the BME688, operates in low power mode with a rechargeable battery and supports low power openthread mesh network. Unfortunately there was no existing project so far that allowed Thingy53 to use the BME688, the only existing BME680 Zephyr driver could not read the BME688 gas values.
Also integrating an I2C driver and reading register values is not enough, because the IAQ require an advanced algorithm that Bosch only released in a .a library.
SolutionThis project consists of
- Zephyr integrations of the BME688 driver and .a binary library with Bosch's BSEC2 algorithm for IAQ (Indoor Air Quality) measurements.
- Mesh Network with OpenThread broadcasting UDP packets as client and running a sensors server.
- C++ application with json inputs for config and outputs for sensors enables a server endpoint and a direct mapping of the broadcast to MQTT
before we start with the detailed steps description, let's have a look of what you can expect as end result from this project.
This is a screenshot from MQTT explorer, the Thingy53 posts on x3 different topics state, light and env
the details of the env are as follow including breath_voc, co2_eq, iaq and iaq_accuracy computed by the BSEC2 vendor library, and also the raw gas value in gas0, humidity, pressure, temperature, if the run in is finished (first long use period), and if the stabilization is finished after power on finally the sample count since power on.
Below is an open box Nordic Thingy53 attached to USB and j-Link debugger
- Nordic's Thingy53 IoT Prototyping platform
- Segger's j-Link Edu mini (optional)
Used Sensors in this repo's samples
BME688 Digital nose : low power gas, pressure, temperature & humidity sensor with AI
- BME688 Product page
- BME688 Datasheet
- BME688 Digital nose : low power gas, pressure, temperature & humidity sensor with AIBME688 Product pageBME688 Datasheet
Color sensor BH1749NUC
- BH1749NUC Datasheet
- Measures Red, Green, Blue and IR
- Illuminance Detection Range 80 klx (0.0125 lux/count)
- Color sensor BH1749NUCBH1749NUC DatasheetMeasures Red, Green, Blue and IRIlluminance Detection Range 80 klx (0.0125 lux/count)
The following drivers and libraries have been created in this repo
BME688 Zephyr Driver : in drivers/sensor/bme688
BME68x-Sensor-API
vendor driver integration https://github.com/boschsensortec/BME68x-Sensor-API- Using Zephyr's Sensor API in C language for usage in BME688 simple forced mode
- Driver extension functions to use BME688 in Parallel mode and get all x10 gas measures
BME688 Server : in subsys/bme688_server
- C++ wrapper to configure the BME688 usage in json structure (temperatures profile and durations)
- handler delivers the sensor results in a json structure (temperature, humidity, pressure, gas-0..gas-9)
Bosch-BSEC2-Library
.a vendor's binary integration for IAQ (Indoor Air Quality) measurements https://github.com/boschsensortec/Bosch-BSEC2-Library
BME688 Components and Data
mkdir thingy53
cd thingy53
>west init -m https://github.com/HomeSmartMesh/sdk-hsm-thingy53 --mr main
>west update
building a sample
cd hsm/samples/20_sensors_server
west build
west build -- -DOVERLAY_CONFIG="overlay-logging.conf"
flashing using an attached debugger
>west flash
flashing manually
- connect to USB
- power on while holding SW2 down, see details on updating thingy53 through USB
- with nRFConnect Programmer flash
hsm\samples\20_sensors_server\build\zephyr\dfu_application.zip
Serial Port
- USB Serial Port : with the config
CONFIG_STDOUT_CONSOLE=y
this board creates a UAB virtual COM port of stdout. Note using the nRFSDK Connect Serial Terminal allows auto detection and reconnect of serial ports, very useful to recover automatically after flashing - RTT Debugger Serial Port : using
CONFIG_USE_SEGGER_RTT=y
it is possible to have logs with the attached debugger and without using the board USB device, this needs rebuild the sample differently though.
sample with joiner config CONFIG_OPENTHREAD_JOINER_PSKD
are 13_ot_joiner, 14_ot_udp_echo_server, 15_udp_json_endpoint and 20_sensors_server Note: Make sure to press the Thingy53 button after the raspberry pi commissioner is started. The button will reset the device and try to join thread networks on the new startup.
joining info:
- the
eui64
can be known by first flashing the logging version withoverlay-logging.conf
- without knowing the
eui64
it is also possible to commission with '*' aseui64
parameter
on the raspberry pi
sudo ot-ctl
commissioner start
commissioner joiner add * ABCDE2
Note: in a real deployment project, the joiner code is the critical info that must be kept secret to prevent devices hijacks.
for more details on the raspberry pi border router install see the section 'Raspberry pi server'
Now to create a full fledged sensors server you can jump to sample 20 right away
20_sensors_server- OpenThread Joiner device
- OpenThread mesh client broadcasts udp json packet with Voltage, Alive counter, Charging status, ambient light RGB IR, Temperature, pressure, humidity and Indoor Air Quality
- OpenThread server endpoint can receive json commands and send back responses
This section consist of hints for those willing to create a similar project with Zephyr for their own application.
- step one is to get familiar with Zephyr a good reference is https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/develop/index.html
- second is to focus on the subsection for west https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/develop/west/index.html
This repository is targetting an nRF dev kit, thereforeit is safer to derive it from nRF's fork of Zephyr and other dependencies. the steps are :
- west.yml dependencies taken from https://github.com/nrfconnect/sdk-nrf/blob/main/west.yml
- the default remote is hsm instead of ncs, therefore in the
projects:
the remote ncs needs to be added where applicable - in the application
zephyr
, thename-allowlist
helps reduce the dependencies from Zephyr - note also some Zephyr dependencies can be replaced with top level projects such as mbedtls which is then taken from nRF fork and not from Zephyr
- in case of Kconfig wanrings, it is necessary to compare with the original repo (ncs/nrf) and find the directory (dependency) where that flag is used e.g. missing config for
NRF_MODEM_LIB_SHMEM_CTRL_SIZE
which default isNRF_MODEM_SHMEM_CTRL_SIZE
defined innrfxlib\nrf_modem\Kconfig
that shows a dependency fromnrfconnect/nrf
tonrfconnect/nrfxlib
The thingy53 comes with a current sensing extension board, it is possible to use the Nordic PPKII (Power Profile Kit) to measure realtime current consumption https://www.nordicsemi.com/Products/Development-hardware/Power-Profiler-Kit-2
example measure
we notice how the Thingy53 operates, it loads a capacitance in a short current pulse then maintains a decreasing consumption. Although on startup we notice a peak around 50 mA, the average cycle duration is around 5 mA.
Note this is of course highly dependent on used sensors and wireless peripherals usage frequency, that's why it is important to profile every application in its real life conditions.
Raspberry pi serverThis repo provides code and helpers to setup a raspberry pi openthread boarder router that forwards the udp packets to MQTT
note that with openthread, the Thingy53 gets its own ip based communication capability, the rest is up to the user which application protocol to use on top. Although Matter is an option, it is quite challenging for small projects and does not always provide the required flexibility to pass custom sensor structures. If all you need is a json structure on your application then you might not require a dedicated binary encoding of that json structure, because that's what common application protocols are there for.
Here a direct link to the script that forwards json udp packets to MQTT, it is quite simple and can be customized as necessary like to handle friendly names in case you change sensors location from one room to another.
https://github.com/HomeSmartMesh/raspi/blob/master/py/thread_tags/thread_tags_mqtt.py
Grafana dashboardNow that our packets are connected to MQTT, the rest on how to bring them in Grafana is quite common. For example the Raspberry pi server linked about provides all necessary to setup an own influxDB to record the data.
Here below a screenshot from the Dashboard
Note : this screenshot is part of the sensor Calibration phase, yes, as this is a DevKit and not a final product the calibration has to be done by you so that you can understand how IAQ sensors operate, Bosch provides an excellent documentation and even an AI-Studio to play with machine learning and gas odors recognition (which might be the scope of a future post). Here a link to the BME AI-Studio Manual https://www.bosch-sensortec.com/media/boschsensortec/downloads/application_notes_1/bst-bme688-an001.pdf
BME688 parallel modein the Parallel mode, the BME688 provides up to x10 measures with a so called temperature profile, see details in the datasheet page 16 https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme688-ds000.pdf
Below is the Thingy53 broadcasting the gas-0 till gas-9 as json packet that are continuously stored in the database.
Although up to now, nothing useful has been made with this precious information, this open up the possibilities to have the intelligence of gas identification running on the server, and as every ML project starts by observing the data, this can give a great insight on how the sensor operates.
Zephyr-RTOS why not Arduino or microPython ?Note that, this project is based on Zephyr-RTOS which is an advanced environment compared to Arduino but nevertheless it can be considered as the lower layer that can run under an Arduino application framework. The application is also written in C++ so once the project is setup, it can also have a similar accessibility at app level as Arduino, nevertheless I would like to connect with community members that help me port these BME688 drivers and Thingy53 Zephyr-RTOS environment to Arduino and microPython, I'm sure that can expand the scope of this hardware to a larger community.
Comments