GATT database configuration in server

[Gil]

Hi,

I am developing smartphone controlled  BLE door lock based on nRF52840.

The door lock is a peripheral (also GATT server) and the smartphone is central (GATT client).

I am now planning the services and their charasteristics, but i am stuck with the pincodes.

The server stores pincodes in its database (that will be added/removed to door from smartphone) which later will be used with a keypad. 

If i define a "pincode" GATT service - i have a problem; Because every pincode that would be added to server will add a new characteristic to this service.

I am not sure if i can add characteristics on the fly.

I need an advice about how to organize the pincodes database in the GATT table.

Thanks,

Gil  

[cbd]

Hi,

Why would you need to add a new characteristic for every pin code?

Characteristics are just a means of passing data.

For a custom characteristic you decide how you wish to interpret the data passed. 

For example for a range of 0 to 999,999,999 you could pass the pin code as a 32bit unsigned integer taking 4 bytes or (not recommended) as ASCII  bytes taking 9 bytes.

It may be that you wish to use the same characteristic to set a new pin, in which case you could also pass the old pin as well as the new one and still use a byte to indicate the action. 

So your characteristic data could be something like:

typedef
{
    byte command;  //enter = 0, change = 1, read = 2, reset=3
    byte PIN_Current[4]
    byte PIN_New[4]
}pin_char_data_t;

I would suggest though that you need to seriously look at security here.

In particular I wouldn't pass PIN without some form of encryption and you need to make sure that the PIN is stored securely in flash as well.

[Gil]

I see.

So, in this case, i want the smartphone to read a list of all PIN codes stored in the door (which are stored in an indexed manner), it would probably require the characteristic struct pin_char_data_t to include an "PIN_Index" field.

Did i get it right?

[cbd]

Yes.

In your situation it may be easier to have two characteristics, one is used to send data from the smartphone to your device and the other is used to send data from your device to the 'phone. 

By doing this it is easier to follow and debug you code. You set the notification bit for the characteristic that you are using to send data with when you update it and the receiver just handles the Characteristic changed event without any need to regularly poll (read) the characteristic value.

The Nordic NUS example code uses this principle.

[cbd]

You could change the structure of the data that you send depending on the command value.

For example Command to Change PIN uses the structure as we've described (with an index field added).

Command to Get All PIN just has the current PIN for security and then, if you've extended the MTU, returns an array of PINs e.g. something along the lines of

typedef struct
{
    byte PIN_Value[4];
}single_pin_t;

typedef struct
{
    byte PIN_Count;
    single_pin_t PINs[];
} char_resp_get_all_pin_t;

[Gil]

Thanks for the insights, i will use them to plan the system's architecture.

You can close the issue

Gil