Friday, December 7, 2018

blessTags release

      In a few days, prepare you for a new release for the blessTags application - the version The new release will bring support to the Nordic Semiconductor Thingy:52 SensorTag.

      It is a wonderful news, but it also means that only a few days remain left to check the following functionalities (that are activated in the Lite version – the free version of the blessTags): events, warnings, activities, developer mode, application configuration and the save function.

Please visit blessTags online:

Wednesday, November 21, 2018

blessTags application Privacy Policy

Network Usage:

       The blessTags application uses the internet to send an email when an event will take place – the desired sensor value (instantaneous, mean or the variance) is lower or higher than a threshold value or is inside or outside of a specific range of values. But, this email will be sent only to the people indicated by the user of the blessTags application! No one else will know, use or store the email address or the email body message.

Data Collected:

      The blessTags program does not collect any kind of personal data from users.  It does not ask for your name or email address and does not knowingly send them back to the developer. No your IP address (or your gateway’s IP address) will be collected or transmitted to the developer.
      blessTags shares this information with the following parties:
  • No data will be shared using this application and the application doesn't have abilities to collect personal user information.

More info about:

     You are always welcome to write to me about the application. If you would like to have further information, use the following email:
  • mdobrea at
     This policy is subject to change without notice. Please check this page for the latest privacy policy. If you disagree with this policy, please discontinue use of the application.

Thursday, November 1, 2018

How many hours do you spend on the development of the blessTags application?

       This is a very hard question. I have never been counting how much time I spent in developing the blessTags application. With the release of each new version, the number of code lines that the new version of the application has it is counted and presented to the users - please see the blessTags version history section. This indicator, the number of code lines of the blessTags application, it is a very good reference for the efforts made in developing the application. But that's not all. Testing the newly developed features, testing their integration with the rest of the application also takes a lot of time.
       In order to highlight these efforts (made in the testing phase of the application), but also those deployed in the development of the blessTags application, I think an image is much more exciting. 
       In the below figure, I present all the coins batteries (CR2032) depleted in the last 6-8 months in the development phase and testing phase of the blessTags application with different types of the SensorTags.

Q&A (question and answer) section

      In this section of this blog, I will answer the various questions from users of the blessTags application. So, if you have questions on which do you have not found answers in the pages of this blog, please email me at mdobrea at - I will answer at each of them. If a question is repeated constantly by many users or the response to a specific question concerns more users of the blessTags application, I will post the answer to it on this page.

  1. Howmany hours do you spend on the development of the blessTagsapplication?

Tuesday, August 28, 2018

Services, Characteristics, Descriptors and Declarations in Bluetooth BLE

      When we interact with a SensorTag device, we interact with a specific element named Attribute. Services, Characteristics, Descriptors, and Declaration are different types of Attribute.
      The behavior of a BLE device (a SensorTag) is given by the different Services that encapsulate different parts of this behavior. Mainly, a service is a container for different data items – these data items can be read (e.g. a sensor value from a SensorTag) or write (e.g. we must write a value in order to configure a sensor – for example, to set the dynamic range for the accelerometer sensor). For example, the behavior of the ThunderBoard Sense SensorTag is encapsulated in the following services
  • Generic Access Service (UUID = 0x1800);
  • Generic Attribute Service (UUID = 0x1801);
  • Device Information Service (UUID = 0x180A);
  • Battery Service (UUID = 0x180F);
  • Environment Sensing Service (UUID = 0x181A);
  • Power Management Service (UUID = EC61A454-ED00-A5E8-B8F9-DE9EC026EC51);
  • Indoor Air Quality Service (UUID = EFD658AE-C400-EF33-76E7-91B00019103B);
  • User Interface Service (UUID = FCB89C40-C600-59F3-7DC3-5ECE444A401B);
  • Automation IO Service (UUID = 0x1815) and
  • Acceleration Orientation Service (UUID = A4E649F4-4BE5-11E5-885D-FEFF819CDC9F).
     As a conclusion, a service represents a specific hardware feature of a SensorTag (or to other type of Bluetooth device) – e.g. in ThunderBoard Sense SensorTag the sensors values related with the air quality (these sensors can detect the existence of ethanol and hazardous gases such as carbon monoxide and a wide range of volatile organic compounds) are grouped in Indoor Air Quality Service. The complete table with all information regarding the services for ThunderBoard Sense SensorTag can be found here. The blessTags software gives the possibility to interrogate different types of unknown BLE devices – in order to be able to obtain the complete GATT attribute table for an unknown BLE device several steps must be done, such example can be found here.

     In a Bluetooth device, a service contains, at least, one or more characteristics. A characteristic owns none or more descriptors. The descriptors are completely optional, but a service must contain at least one characteristic. Each service, characteristic and descriptor must be identified by a unique identifier (UUID). UUIDs can be 16- or 128-bit values. For example, the Generic Access Service (presented above) have a UUID on 16 bits value (0x1800) while the service Acceleration Orientation Service (presented above) have a UUID on 128 bits value (A4E649F4-4BE5-11E5-885D-FEFF819CDC9F).
     A characteristic of a service is related to an internal state of a BLE device – e.g. a value that quantifies the volatile organic compounds from the air, obtained from the CCS811 digital gas sensor embedded inside the ThunderBoard Sense SensorTag. Also, Characteristics contain various properties. A property describes what another device (a client) can do with a characteristic over Bluetooth.  The operations such as READ, WRITE, NOTIFY or INDICATE are permitted or not, functions of specific value defined by a property associated with a characteristic. For a deep description of properties please visit the post “Reading vs. notifying”

Example 1: So, let’s take an example. The Service Automation IO Service (with the short UUID = 0x1815 and with the long UUID = 00001815-0000-1000-8000-00805F9B34FB) have two Characteristics. The first one with UUID_0 = 0x2a56 and the second one with UUID_1 = 0x2a56. The first Characteristics owns three Descriptors, with UUIDs: 0x2902, 0x2904 and 0x2909. The second Characteristics owns only two descriptors with the UUIDs: 0x2902 and 0x2909. See the figure from below (the figure was obtained with the developer function of the blessTags application).

     The characteristics UUID can be predefined ones - like the ones presented above with the UUID = 0x2a56. These predefine UUIDs have specific functions associated by the Bluetooth BLE standard.  The Characteristic’s UUIDs defined by Bluetooth BLE standard always follow the formats: (a) 0x2A[xx] – where the [xx] are two hex values and (b) 0x2B[yy] – where the [yy] are hex values.
     The Descriptors are special types of attributes that describe a characteristic value (they contain different type of metadata, based on this information they augment a characteristic) with which they are associated. A very important descriptor is the Client Characteristic Configuration Descriptor (abbreviated to CCCD) – based on this descriptor the notification messages can be switched on or off.  Up to now, descriptors have associated only short UUIDs (16 bits value). The descriptor’s UUIDs identifiers always follow the format: 0x290[y] – where the [y] value is a hex number.
     A special type of attribute is the declarations. The declarations are used to separate distinct group of attributes: in services and inside a service in characteristics. A Service Declaration attribute has always the standard UUID the 0x2800 value. The Characteristic Declaration have the standard UUID the 0x2803 value. Please see this in the figure presented above. The declaration’s UUIDs identifiers always follow the format: 0x280[z] – where the [z] value is a hex number as follow {0, 1, 2, 3}.

Example 2: In ThunderBoard Sense, the service Indoor Air Quality Service has three characteristics – the service attribute table is presented in the above picture. A service starts with a Service Declaration attribute (UUID = 0x2800) and each characteristic is separated by the other characteristics with a Characteristic Declaration (UUID = 0x2803). All the characteristics UUIDs, of this service, are not defined in Bluetooth BLE standard – have UUIDs different from 0x2A[xx] and 0x2AB[yy] format. In this case, the UUIDs values are defined by the producer of the ThunderBoard Sense SensorTagthe Silicon Labs company. The third characteristic has associated only one descriptor – the CCCD. To access the data from the first two characteristics, a READ operation must be initiated – the [R] property in the figure.

      Starting with the version of the blessTags application all the characteristics (more than 200 characteristics) defined by the Bluetooth BLE standard are identified and presented to the user.

Example 3: To understand better the advantage of knowing the characteristics defined by the Bluetooth BLE standard, below are presented: (a) the attribute table for the Device Information Service (UUID = 0x180A) knowing the characteristics defined by the Bluetooth BLE standard – the first figure presented below and (b) the same table unknowing the characteristics defined by the Bluetooth BLE standard – the second image presented below.

The blessTags application can be downloaded from the Windows Store Apps:
The blessTags Lite application (the free version of blessTags) can be downloaded from the Windows Store Apps:

Thank you very much for reading this article and your interest in Bluetooth LE technology!

Tuesday, July 31, 2018


     An activity is a specific action that the blessTags application will execute when a specific event will take place. Here we have two key concepts: event and action.
     Events are things that happen within your blessTags app. environment at which you might want to take a specific action. An event is triggered from a specific value (a numerical value presented in black color on the blessTags user interface) obtained from an active sensor placed inside a SensorTag.

     The values types able to generate events are the instantaneous value, the mean value or the variance value of the data flow from a specific sensor or a specific channel from a specific sensor (e.g. channel Z of the gyroscopic sensor). If the desired value (instantaneous, mean or the variance) is lower or higher than a threshold value or is inside or outside of a specific range of values an event will be generated.


Execute an action

     After an event has taken place, an action will be executed. At this moment, on blessTags app., several actions are implemented: run an application selected by the user, send an email, quit the blessTags application, lock, hibernate, sleep, logoff or shutdown the system (the device on which the blessTags application is running). 

     Since the application allows the user to select up to 2 actions to be executed, there must be a clear priority between these actions (which action will be executed first, and which action will be executed second). So, regardless of the selected sequences, the execution priorities are the following ones:
  1. Send an email;
  2. Run a user selected application;
  3. Hibernate, sleep, lock, logoff, restart, and shutdown;
  4. Quit the blessTags application.
     In the video presented below, I will show you this new product feature (starting from version) of the blessTags application: activities.

Sending an email

     The blessTags application can send emails when a specific event occurs. However, in order for this feature to work properly, we need to configure correctly the mail engine of the blessTags. To do this, a special panel was developed – see below.

     In the upper part of the panel are placed the SMTP (Simple Mail Transfer Protocol) server settings. The SMTP server is the server that will take care of the delivery of your emails. Here you have 2 edit boxes (Host and Port) and one ring control (Security type) to set the SMTP server. The Host is the DNS name of your SMTP server - you can find it consulting the web page of your provider. The Port is the endpoint of your computer connection – different number are associated with different types of protocols. The default SMTP port (default transmission channel for internet email) is 25. The mail engine of the blessTags application support SSL connection on 465 (25025) port or TLS connection on 587 (2525 - it is an alternate port, which mirrors port 587 and also supports TLS encryption) port. In any case, the email provider may decide to use a custom port to establish the connection – in such case please consults the web information of your provider. The security type ring control allows you to configure the encryption of your transfer: no encryption or to use an encrypted communication like STARTTLS or SSL/TLS.
     You can manually enter the SMTP settings for your server or you can use the fourth ring control that encapsulates SMTP server settings for nine of the commonly used email services: Google (Gmail), Microsoft (Outlook/Hotmail), Yahoo (Yahoo! Mail), Zoho, AOL (AOL Mail), GMX, Lycos, Yandex, and All the setting information, for these SMTP servers, were collected from the official sources (namely, the official websites of these company) and were tested previously. But you may consider that the email service provider may change its mail server settings without any prior notification. I suggested you to contact your email service provider in case you encounter any error during the account setup.
     In the following fields, you must enter the username and the password. These information are specific for each mail server. A bit lower you must enter the email addresses, select the priority of your email, the email’s subject and the body of your email. All these fields are constrained to 60 chars, apart from email’s body which is limited to 90 characters.
    The test button lets you send an email when you click on it. If this email arrives well, then it means that everything is set up correctly and when an event will occur the email that will be sent will certainly arrive also. In this panel as long as your blessTags application sends a message, the LED will be red and the “Send a test email” button disabled.
     A very nice feature specific to the mail engine of the blessTags is that you can include two types of specific strings (in the body text of your email) that will be replaced by the date (%d) and by the time (%t) of the device on which the blessTags application is running.
     For example, an email sent in this form:

will arrive at the destination in this form:

     A small problem that may occur from time to time is that some email providers accept the user's name in the username field, while others want the full email address. For example, the Gmail email provider accepts mdobrea or as a username, while others, like GMX, accepts only as a username.
     The entire configuration process if the mail engine of the blessTags is presented in the following movie.