Передавать таймстамп в рекламе

[maximko]

Добрый день, возможно ли добавить время в рекламу в кастомном формате рекламы? Я собираю метрики с датчиков в режиме рекламы, дома на блютус на сервере и хочу еще сделать сбор на телефоне. Данные записываются в базу, и в случае нескольких приемников данные будут записываться несколько раз. Можно перед записью смотреть есть ли такие показания в базе, например за последнюю минуту, либо вычислять вероятность по счетчику, но это усложняет код. Еще есть проблема когда одно сообщение приходит по несколько раз, тестировал на маке и на малине, соответственно приходится фильтровать повторные сообщения. Уникальное поле в рекламе упростило бы оработку этих особенностей.

[pvvx]

Еще есть проблема когда одно сообщение приходит по несколько раз,

Для откидывания дублирующих сообщений передается measurement count.

добавить время в рекламу в кастомном формате рекламы

Время приема сообщения и является временем измерения и оно и записывается в базу и т.д.

[maximko]

Для откидывания дублирующих сообщений передается measurement count.

Это усложняет обработку.

Время приема сообщения и является временем измерения и оно и записывается в базу и т.д.

Сообщения приходят не в одно и то же время, таймстамп может отличаться на секунду, соответственно нужна такая же обработка как и для measurement_count.
Есть ли возможность реализовать мою фичу на платной основе?

[pvvx]

Для откидывания дублирующих сообщений передается measurement count.

Это усложняет обработку.

Других вариантов в BLE рекламе нет, т.к. для уверенного приема производится дублирование передачи сообщений. Обратной связи или подтверждения успешной передачи у устройства передающего BLE рекламу нет (до дополнения в стандарте Bluetooth 5.4).
Можете включить паузу передач BLE рекламы на максимум по стандарту в 10 сек и одно измерение за 10 сек. Тогда каждое измерение будет иметь одно событие BLE рекламы (каждый раз новый measurement count) и не будет дублей у типовых BLE адаптеров (но сканер даст 3 - по одному на каждом из 3-х основных каналах BLE).

Время приема сообщения и является временем измерения и оно и записывается в базу и т.д.

Сообщения приходят не в одно и то же время, таймстамп может отличаться на секунду, соответственно нужна такая же обработка как и для measurement_count.

1. Это потребует изменения всего внешнего ПО.
2. Счет времени в термометре, кроме варианта MJWSD05MMC, нестабилен - уход несколько секунд в час. MJWSD05MMC имеет дополнительный чип RTC.
3. Типичный период измерения (по умолчанию) - 10 сек. Передача дублируется 4 раза, по 3-м каналам. Т.е. итого до 12 передач на одно измерение. Само измерение уже отстает от реального из-за времени реакции датчика (долгий нагрев/охлаждение печатной платы где установлен датчик и малая конвекция в корпусе, да сам датчик, и рядом большая массивная батарейка, ...). По этим условиям нет смысла уточнения точности времени измерения к менее десятку сек от времени изменения внешних условий температуры и влажности.
   Для быстрой реакции системы, где показания датчика и время реакции исполнителя запаздывают, используют ПИД регулирование...

Есть ли возможность реализовать мою фичу на платной основе?

Код программ полностью открыт - можете нанять кого захотите,