Thingy53: use of Bluetooth mesh sensor model

Dear community,

I am working on the Sensor Server bluetooth mesh model that I have implemented on the Thingy53.

Code is based on the existing sensor server sample available in nRF Connect SDK 3.2.99. i.e. github.com/.../

My questions concerns

(1) the sensor data that can be retrieved from the Thingy53 (for instance from bme680 sensor, or other existing sensor?)

(2) the number of sensor data readings that can be achieved with the sensor server model.

****************************************

Résumé of my problem

****************************************

(1) type of Sensor Data

Currently I manage to get the following 4 sensor readings from Thingy53 :

Temperature, Relative Humidity, air Pressure & presence (presence is actually detected not from a sensor, but with a button press). 

However I have difficulty to get the VOC concentration.

And I wonder also how to get readings from the light sensor (this reading does not come with BME680).

(2) Number of Sensor Data

I do not manage to read more than 4 sensor types/channels at a time. If I try to add & read a fifth one, it does not manage.

(1) type of sensor data

************************************************************

The Sensor Server model (sensor_srv) requires a list of bt_mesh_sensor pointers.

Here is the list of 5 sensor instances I am using.

Then each bt_mesh_sensor  is defined as such (example with Temperature), with a type and a get function to read data.

Each sensor type is assigned its own Device Property ID, as specified in the Bluetooth mesh device properties specification. Here bt_mesh_sensor_present_dev_op_temp corresp to the property ID 0x0054.

And each sensor type may consist of one or more channels. Sensor_channel_get() function enables to retrieve the data corresponding to the channel(s) of the sensor type.

The only channel corresponding to the type bt_mesh_sensor_present_dev_op_temp is SENSOR_CHAN_AMBIENT_TEMP

My first Question is about VOC concentration that should be read from bme680. Here is the corresponding table I use between the sensors pointers, the type and the channel attached.

This is working well except for VOC.

In nRF SDK documentation, for gas sensor, I see only two types = {bt_mesh_sensor_present_amb_voc_concentration; bt_mesh_sensor_present_amb_co2_concentration}

To try to get VOC, I am using the first one, i.e. bt_mesh_sensor_present_amb_voc_concentration.

As for channel, I try to use either SENSOR_CHAN_VOC or SENSOR_CHAN_GAS_RES.

The combination bt_mesh_sensor_present_amb_voc_concentration / SENSOR_CHAN_VOC provides me with empty result.

The combination bt_mesh_sensor_present_amb_voc_concentration / SENSOR_CHAN_GAS_RES provides me with FE FF result, which looks strange. No?

(It is worth mentionning that I read FE FF result from 3 different sensor clients, the nRF mesh app, and two others nodes/nRF5280DK programmed with sensor client model).

=> I am interested in knowing how to retrieve correct VOC values.

Also as Temperature, Relative Humidity, VOC relate to BME680 sensor.

=> I am also interested in knowing how to read data from other sensor(s) present on Thingy53? Would it be possible ot read data from the light sensor for instance?

(2) Number of data readings (limited to 4?)

************************************************************

I am surprised also that I manage to read (only) 4 sensors at a time. It means I can defined the sensors[] list with 4 sensors instances maximum.

Here with 5 instances, it will returns only the four first ones.

Would you know any reason for this?

Thank you very much for any tips on these observations !

Parents
  • Hi BesbarJB,

    My apology for the late follow-up. My team is facing high loading due to some unavailability. Unless someone from the community had already helped you then, one our support engineer will be with you next week.

    Thank you for your patience.

    Hieu

  • Hi Hieu, 

    No worries, getting help (according to your timing) is already very precious.

    Good luck and speak to you soon! 

  • Hi BesbarJB,To my understanding, you have the following two questions left:

    BesbarJB said:
    It looks like no bt_mesh_sensor_type is yet available to manage correctly the gas resistance data, or did I miss something?

    I don't think you missed anything. I will send a feedback to our development team, as bt_mesh_sensor_type is a nRF library. However, I don't know when they can get to it.

    BesbarJB said:
    I still am interested in knowing why for the BME680 sensor, we can use sensor_channel_get(), but not for the bh1749 sensor, which requires I2C functions.

    I see that the API is implemented for the BH1749 driver here: https://github.com/nrfconnect/sdk-nrf/blob/v2.3.0/drivers/sensor/bh1749/bh1749.c#L102-L139.

    Do you have any trouble using the API?

    Once again, my apology for the late follow-up. Thank you very much for the patience.

    Hieu

  • Dear Hieu, thanks a lot.

    1. Regarding BH1749 driver, I have added CONFIG_BH1749=y in prj.conf - [looks like a rookie mistake, but I am a rookie Slight smile]. Now sensor_channel_get() is also working for bh1749.

    #include <zephyr/drivers/sensor.h>
    
    #define BH_NODE DT_NODELABEL(bh1749)
    static const struct device *bh1749rgbDev = DEVICE_DT_GET(BH_NODE);
    
    uint8_t init_bh1749(void)
    {
    	if (!device_is_ready(bh1749rgbDev)) 
    	{
    		printk("Sensor device not ready\n");
    	}
    	return 1;
    }
    
    static int color_get(struct bt_mesh_sensor_srv *srv,
    			 struct bt_mesh_sensor *sensor,
    			 struct bt_mesh_msg_ctx *ctx,
    			 struct sensor_value *rsp)
    {
    	sensor_sample_fetch(bh1749rgbDev);
    
    	int err = sensor_channel_get(bh1749rgbDev, SENSOR_CHAN_IR, rsp);
    	printk("IR: %d.%06d\n", rsp->val1, rsp->val2);
    	if (err) 
    	{
    		printk("sensor_channel_get failed err %d\n", err);
    	}
    }
    
    static struct bt_mesh_sensor color = {
    	//https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/libraries/bluetooth_services/mesh/sensor_types.html#ambient-temperature-sensor-types
    	.type = &bt_mesh_sensor_present_amb_light_level, // 0x0078(120) This property represents the light level as measured by a light sensor measuring illuminance (Lux).
    	.get = color_get,
    };
    
    

    2. Regarding bme680 gas data. Indeed if the Nordic Developer team could integrate a bt_mesh_sensor_type that would be appropriate to correctly retrieve VOC and eCO2 data, that would be excellent.

    I am already using Thingy52 as a BLE sensor in my network with all environmental data available incl. VOC and eCO2.

    And now I can use Thingy53 as a BLE MESH sensor, but I miss only VOC and eCO2 data.

    Last but not least, just a very minor suggestion, the Thingy53 sample Mesh_sensor_server v2.3.0 could actually be updated with possibly two sensors server model instances, that would allow retrieving full data from both sensors (bme680 and bh1749), as well as battery level => so that users may have a Thingy52 equivalent set of data sensor, but in mesh protocol.

    Anyway this is what I wanted to do, and thanks to your genuine help, I've managed.

    Thanks Nordic teams !

  • Hi BesbarJB,

    Sorry I got feedback on this a couple of days ago but have been out of office till now.

    If I understand correctly, you are using a different SDK for the Thingy52, right?

    bt_mesh_sensor_type is setup with respect to the Bluetooth Mesh Device Properties specification (which in turns depend on the GATT Specification Supplement), so if a sensor type is not supported in the spec, it cannot be setup.

    However, if what you wants are VOC and CO2, then aren't they already in the file? Did I misunderstand you or the kind of gas these types are for?
    VOC: https://github.com/nrfconnect/sdk-nrf/blob/v2.3.0/include/bluetooth/mesh/sensor_types.h#L315-L324
    CO2: https://github.com/nrfconnect/sdk-nrf/blob/v2.3.0/include/bluetooth/mesh/sensor_types.h#L304-L313

    For the other kind of gases that the BME680 can measure, the Bluetooth spec simply doesn't support them right now.

    We think it makes sense to submit a spec update for this point. If you wish to join our request, you can send me your job contact via the private message and I will relay the information to our engineers.

    Hieu

Reply Children
  • Dear Hieu, 


    Indeed I looked at the bt mesh properties specifications, and I did not see any gas resistance property. 

    Actually the BME680 from Thingy53 only measures the gas resistance in ohm as raw value.

    Without a driver/library to convert this resistance raw value into equivalent VOC and CO2 data, the use of the existing VOC and CO2 bt_mesh_sensor_types is not possible.

    For the other kind of gases that the BME680 can measure, the Bluetooth spec simply doesn't support them right now.

    We think it makes sense to submit a spec update for this point.

    Which spec update would you like to submit? to my understanding BME680 is only measuring gas resistance.
    Otherwise I agree to join your request, if I can be of help, it will be with pleasure.

    If I understand correctly, you are using a different SDK for the Thingy52, right?

    I use Thingy52 just a BLE only sensor. When I buy it I tried to install old Thingy52 SDK but I gave up. So I do not use any SDK for Thingy:52. However Thanks to Thingy52 I learn how to connect to BLE device and read services and characteristics.

    Thingy52 gas sensor is not bme680, but CCS811. I guess a driver is available for CCS811, that is why I get VOC and eCO2.

    I bought after Thingy:53 to train on BT mesh sensor model, and because it is easy to flash.

    Thanks a lot, 

    JB

  • Dear JB,

    BesbarJB said:

    Actually the BME680 from Thingy53 only measures the gas resistance in ohm as raw value.

    Without a driver/library to convert this resistance raw value into equivalent VOC and CO2 data, the use of the existing VOC and CO2 bt_mesh_sensor_types is not possible.

    Yes, you will need to integrate a driver to convert the raw value to equivalent VOC and CO2.

    BesbarJB said:
    Which spec update would you like to submit? to my understanding BME680 is only measuring gas resistance.
    Otherwise I agree to join your request, if I can be of help, it will be with pleasure.

    It's a change request for the Bluetooth Mesh Device Properties specification. As you have noted, there is not a property for gas resistance in Ohm. that is one thing that can be considered.

    We also see that the BME680 marketing documents claim to be capable of measuring gases such as carbon monoxide and hydrogen, so properties for those can also be considered.

    Regards,

    Hieu

  • I fully agree. I am well volonteer and interested to help you in making this request.
    Tell me how I can do this?

    Have a great week end

  • Thanks JB. I will contact the relevant engineer and get back to you with more info. It is a holiday here this week and I will be out of office for a few extra days, so I will likely be back sometime next week.

  • Enjoy Hieu these holidays. Speak to you once you are back.

Related