Github Devices Community Docs Blog

BLE gateway software architecture

Continuing the discussion of

From @floyddotnet

Maybe for the feature it would be a good idear in my opinion to split the communication and the parsing / processing into seperate files like:

// communication / platform related source in this files:
main/BLE/module/ESP32.ino
main/BLE/module/HM10.ino

// ble device related source into this file
main/BLE/device/general.ino
main/BLE/device/xiaomi.ino

// high level source (like module init, call device related source)
main/ZgatewayBT.ino

during this process we could add an abstraction layer for the communication / platform into main/BLE/module/abstraction.ino

        +-------------------+           +--------------------------------------------------+
+-------+main/ZgatewayBT.ino| +-------> |compile with one of the communication device files|
|       +-------------------+           +--------------------------------------------------+
|
|                 ^                                  +
|                 |                                  |
|                 |                           +------+-----------+
|                 |                           v                  v
|                 +
|                                       +---------+          +-------+
|         +-----------------+           |ESP32.ino|          |M10.ino|      Both are abstractions
|         |callback with new|           +---------+          +-------+      with has exactly the
|         |de^ice date      |          +                              +     same methods
|         +-----------------+          +--------------+---------------+
|                                                     |
|                ^                                    |
|                |                                    |
|                +------------------------------------+
|
|
|
|
|
|          +------------------------------+
+--------> |call ble device related source|
           +------------------------------+
           |xiaomi.ino                    |
           |.....                         |
           +------------------------------+

From @floyddotnet

i don’t know if you confirm with the concept of interfaces and polymorphy.

the goal:

  1. separation of concerns & single-responsibility (each file should do only one job (a single part of the functionality))
  2. better readability (no file has more functions as it needed, avoiding spaghettification of the source in one file, avoiding to large files)
  3. following the open-close-princip (it is simple to add a new ble communication module without needing to modify the existing ones by creating a new file ‘main/BLE/module/HC05.ino’ and register it in main/ZgatewayBT.ino ; the same for supporting a new ble device)

From @floyddotnet

i mean something like this:

// main/BLE/module/ESP32.ino
ble_module_init(){ /* ... */ }
ble_module_register_advertised_device_callback(void (*callback)(JsonObject &BLEdat)){ /* ... */ }

// main/BLE/module/HM10.ino
ble_module_init(){ /* ... */ }
ble_module_register_advertised_device_callback(void (*callback)(JsonObject &BLEdat)){ /* ... */ }

// main/ZgatewayBT.ino
#ifdef ESP32
  #include <main/BLE/module/ESP32.ino>
#else
    #include <main/BLE/module/HM10.ino>
#endif

void advertised_device_callback(JsonObject &BLEdat) {
  if ((!oneWhite || isWhite(device)) && !isBlack(BLEdat))
  {
   //..
   PublishDeviceData(BLEdata);
  }
}

ble_module_init();
ble_module_register_advertised_device_callback(*advertised_device_callback);

@floyddotnet,
Thanks for these interesting proposals,
Added to that, does it makes sense in your point of view to use vectors of structure for the white and black list management?

I’m thinking on expanding this functionality to the other gateways and I’m asking myself if it is the best way to manage these restrictive lists.
Maybe a vector of Json Object would be easier to maintain and more coherent with the other functions.

topic white and blacklist:

I needed some time to thinking about the implication of this changes. At first, i think JsonObject should only used if it needed. because its consums muth more memory as an struct and accessing a field consumse more time and energy too.

in my opinion, two simple array’s of ids for white and blacklist or a simple array of struct is all we need and the best what we can do in terms of memory and performance. but i confirm with this point that a vector (or two) of ids / structs are easyer to maintence.

adopting this concept could be done by adding a prefix to the id’s or a type-flag. like:

blacklist: [ “BT_00:22:fa:17:00:00”, “IR_ dcba003dd00aa”, “…”]