Core Module as timestamp source

TOWER
3

OK, so there is no support for sending timestamps in SDK/stack yet.

I’ve changed this proposal every time I dig deeper inside your code. Now I understand it enough to think about enhancing your BC stack as follows:

  • node (using SDK function) will pack multiple values of the same type with timestamps into one radio packet.
    • Structure can be defined by Hardwario, something like you proposed: [<timestamp>;<period>;<count>;<buffer...>;].
      bool bc_radio_pub_temperature_buffer(uint8_t channel, uint32_t timetamp, uint16_t period, float *celsius_buf, uint8_t count)
{
    uint8_t buffer[3                            // header
                   + sizeof(uint32_t)           // timestamp
                   + sizeof(uint16_t)           // period
                   + sizeof(uint8_t)            // samples count
                   + sizeof(*celsius)*count];   // samples values

    buffer[0] = BC_RADIO_HEADER_PUB_BUFFER;     // message type identification
    buffer[1] = BC_RADIO_HEADER_PUB_TEMPERATURE;// one sample type identification
    buffer[2] = channel;
    ...
    return bc_radio_pub_queue_put(buffer, sizeof(buffer));
}
  • bcf-gateway-usb-dongle will:
    • unpack data into separate measurements and calculate timestamp for each one
    • publish all measurement to the bcg in json format
      • with proper timestamp assigned as part of payload
      • to different topic ‘…/temperature/cached’ (because of different payload structure)
  • bcg will publish raw payload to mqtt broker like it does now
  • mqtt2influxdb will use timestamp provided in mqtt payload and force timestamp of inserted measurement into influxdb

    • Configuration may look like this:

      points:
  - measurement: temperature
    topic: node/+/thermometer/+/temperature/cached
    fields:
      value: $.payload.value
    tags:
      id: $.topic[1]
      channel: $.topic[3]
    timestamp: $.payload.timestamp

Few notes:

  • I think this feature will keep mqtt2influxdb as flexible as it is now and adds one more new feature.

  • I find adding new message format between node and dongle to the SDK useful not only for NB applications.

  • As far as I know, it is only up to you (hardwario) to define what data and in what format will be transferred from node to bcg and to which topics will dongle publish that data.

  • This change will not break any backward compatibility.

  • The only drawback will be the difference in topic between single measurement and multiple (cached/buffered) measurements because of timestamps. But I don’t see any advantage in subscribing both topics and mixing actual and historical data…

  • Another approach I’ve considered was to send timestamp from bcg as MQTT MessageID to preserve usage of same topic like single measurement. In this case mqtt2infuxdb.yml should be like:

      points:
    - measurement: temperature
      ...
      timestamp: $.id

    But ID has only 16bits :frowning:

  • Maybe bc_data_stream can be used to provide collection of measurements?

    bool bc_radio_pub_temperature_from_stream(uint8_t channel, uint32_t timetamp, uint16_t period, bc_data_stream_t stream);

    Bc_data_stream documentation

  • Temperature
  • 0.1 °C
  • Sampling period alters between two states:
    1. After trigger event I want to sample every 10 seconds for about 10 minutes.
    2. If no trigger within 10 minutes then sample only once per 5 minutes.
  • Transmission period is based on two conditions, whichever happens first:
    1. Once buffer is full (buffer size based on maximum TX packet size).
    2. At least one time per hour.