Beacon

  • https://github.com/vhiribarren/beacon-simulator-android?tab=readme-ov-file — Симулятор маяка
  • https://habr.com/ru/articles/278689/ — iBeacon. Мифы и реальность
  • https://vc.ru/services/1098953-ispolzovanie-tehnologii-ble-pri-rabote-s-beacon-mayachkom-v-react-native — Использование технологии BLE при работе с beacon-маячком в React Native
  • https://stackoverflow.com/questions/58004370/different-interval-time-between-ble-device-advertising-and-the-callback-from-sta — Разный интервал времени между рекламой устройства BLE и обратным вызовом из startScan телефона Android
  • https://habr.com/ru/companies/navigine/articles/269735/ — Как работают маяки: Физика технологии iBeacon
  • https://habr.com/ru/articles/245325/ — Навигация в помещениях с iBeacon и ИНС
  • https://www.dusuniot.com/ru/blog/angle-of-arrival-bluetooth-gateways/ — Как технология Bluetooth с определением угла прихода (AoA) модернизирует мир
  • https://moitvivt.ru/ru/journal/pdf?id=821 — Позиционирование в трехмерном пространстве внутри помещений по данным Bluetooth-маяков

Термины:

  • Magor и Minor — это идентификаторы пространства, например здание и помещение.
  • RSSI — мощность сигнала (например на расстоянии 1 метр)
  • PPS — количество пакетов в секунду (сканирование не менее 30 секунд)

Для расчета расстояние между BLE устройством и маячком на основе значения RSSI используем данную формулу:где:

d — расстояние до устройства (маячка),

TX Power — мощность сигнала, измеренная на стандартном расстоянии (обычно 1 метр) от маячка

RSSI — мощность сигнала,

n — коэффициент затухания сигнала (environmental factor), отражающий потери сигнала в среде; типичные значения находятся в диапазоне от 2 до 4.

Эта формула позволяет оценить расстояние между двумя устройствами, используя логарифмическую зависимость изменения мощности сигнала от расстояния.

Значение коэффициента затухания сигнала n зависит от конкретных условий окружающей среды, в которой происходит передача сигнала.

Открытое пространство без препятствий: Значениеnоколо 2. Это условие предполагает минимальное затухание сигнала, когда между устройствами нет значительных препятствий, и сигнал может распространяться прямолинейно.

Внутри помещений с препятствиями: Значениеnможет варьироваться от 2.5 до 3.5 или даже выше. В помещениях сигнал может отражаться от стен, потолков и других объектов, что увеличивает затухание. Более высокие значенияnиспользуются для учета этого дополнительного затухания.

Сложные условия с множеством препятствий: В помещении с высокой плотностью препятствий, таких как склады, производственные помещения или городские условия с множеством отражающих поверхностей, значение n может быть установлено в диапазоне от 4 до 5. Эти условия требуют более высокого коэффициента затухания для компенсации значительных потерь сигнала.

Важно понимать, что определение наиболее подходящего значения n часто требует эмпирического подхода. Это означает проведение тестов в целевой среде для измерения реального распределения сигнала и адаптации коэффициента затухания для достижения наилучшей точности в оценке расстояния.

Автоматическое документирование базы данных

Для документирование базы данных применяется открытое решение Autodoc.

Инструкция по установке и настройке на сайте appcode.pw

Основной скрипт для запуска генерации документации.

cd autodoc
postgresql_autodoc -d cic-dev-db -h 192.168.17.111 -u postgres --password=<pw> -t html -s "core|dbo" -f /var/www/html/cic-dev-db

Демонстрационный вариант документации можно посмотреть на сайте http://cic.it-serv.ru/cic-dev-db.html

Обновление

Актуализирована информация по базе данных, обновлена статусная схема маршрутов.

Статусная схема храниться в формате Visio 2019 и увидеть ее можно тут. В формате PNG ниже.

Обновленная Схема базы данных тут.

Читать далее «Обновление»

Интеграция

Информация актуальна для пилотной версии МРСК ЦиП на 08.10.2020

В пилотной версии МРСК ЦиП информация может быть импортирована в следующие таблицы:

  • dbo.ed_input_meter_readings — текущие контрольные показания
  • dbo.ed_registr_pts — точки учета
  • dbo.ed_device_types — типы прибора учета

Примечание: информацию по таблицам можно посмотреть тут

Точка учета

Информация о точках учета должна храниться в таблице dbo.ed_registr_pts. Здесь может храниться любая информация, но при этом должны быть заполнены следующие поля:

  • c_address: text — полный адрес
  • n_longitude: numeric — долгота
  • n_latitude: numeric — широта
  • f_division: integer — филиал/отделение
  • f_subdivision: integer — участок

Показания

Информация о показаниях храниться в двух таблица:

  • dbo.ed_input_meter_readings — входящие показания. Первоначальные показания в нашей системе. Если показания и дата неизвестны, то можно указать null. При этом информация о тарифной зоне и разрядности должна быть указана обязательно.
  • dbo.ed_output_meter_readings — исходящие показания, результат обхода.

Первичные показания должны быть загружены в систему в обе таблицы, так как генерация показания для новых обходов производится на основе предыдущих данных.

-- пример наличия первичных показаний
INSERT INTO dbo.ed_input_meter_readings(f_point, n_value_prev, d_date_prev, n_digit, f_time_zone, f_registr_pts, n_tariff)
VALUES ('b17c5973-615c-49c6-976f-7a491a41a160', null, null, 5.0, 2, '028d65a4-3621-408b-af0a-230242f41702', 1); -- создано показание с тарифом 1 и показанием "Сутки"

INSERT INTO dbo.ed_output_meter_readings(fn_meter_reading, fn_point, fn_route, fn_user_point, n_value, d_date)
VALUES ('394fb071-7d9f-4c13-ada6-3c45b0f1643b', 'b17c5973-615c-49c6-976f-7a491a41a160', 'c68b1a77-0a13-4c05-bc3e-c2504868f0ac', '547c39bd-d171-4cae-bf64-c30fae16210a', null, '2020-05-01');

Алгоритм обработки показаний тут.

Работа с WebSocket

Мобильные сервисы для передачи мгновенных сообщений использует протокол websocket.

Передача уведомлений осуществляется при помощи «пакетной» передачи данных — механизм аналогичный синхронизации.

NML175.........0{"stringSize":29,"binarySize":0,"attachments":[],"bufferBlockToLength":207,"bufferBlockFromLength":0,"transaction":false,"dataInfo":"mail","version":"v2","id":"1599022001522"}[{"name":"to0","length":207}]{"action":"cd_notifications","method":"Add","data":[[{"fn_user_to":null,"fn_user_from":null,"c_message":"Hello","c_title":"Уведомление","d_date":"2020-09-02T04:46:39.785Z"}]],"tid":0,"type":"rpc"}

Выше показан пример пакета для отправки уведомлений.

Создание слушателя в NodeJS

Переходим в каталог modules/socket и находим там файл main.js В этом файле выполняется регистрация нового слушателя.

Файл для регистрации слушателя
Читать далее «Работа с WebSocket»

Механизм хранения ошибок от клиентских приложений

Для хранение клиентских ошибок от клиентских приложений используется нижеуказанная таблица.

sd_client_errors

  • id: uuid — первичный ключ;
  • c_message: text — текст ошибки;
  • c_code: text — код ошибки;
  • d_created: timestamp with time zone — дата возникновения ошибки на клиенте;
  • fn_user: integer — идентификатор пользователя чьё приложение вызвало ошибку;
  • c_version: text — номер версии;
  • c_platform: text — тип платформы, например, Android, iOS, Sailfish OS;
  • jb_data: jsonb — Прочая информация. Например: ОС, версия, Архитектура или модель и т.д.;
  • dx_date: timestamp with time zone — Дата сохранения на сервере. Вычисляется при вставке;
Читать далее «Механизм хранения ошибок от клиентских приложений»

Чтение серверных настроек

Для чтения настроек доступна удаленная функция PN.setting.getSettings

Данная функция вернёт объект настроек предназначенный для пользователя, который был авторизован в системе.

Пример запроса

[{
"action": "setting",
"method": "getSettings",
"data": [{ "params": ["MBL_"] }],
"type": "rpc",
"tid": 1
}]
Читать далее «Чтение серверных настроек»

Peer authentication failed for user

Если при сохранении файла (cf_save_file) выдается ошибка

could not connect to server "fs"
Peer authentication failed for user "mobnius"

то нужно перейти на сервер и изменить настройки pg_hba.conf

Все значения peer заменить на md5.

Примечание: для пользователя postgres менять не нужно.

Читать далее «Peer authentication failed for user»

b_current и b_check

Некоторые таблицы содержать две колонки:

  • b_current: boolean – текущая актуальная запись для одного элемента object_id;
  • b_check: boolean – подтвержденная запись, была проверена диспетчером или пользователь является доверенным.

АЛГОРИТМ ПРИМЕНЕНИЯ ПОЛЕЙ

  • b_current проставляется только после установки b_check – диспетчер подтверждает результат работы, говоря тем самым, что запись является последней актуальной;
  • для нескольких записей в рамках одной точки (см. object_id) b_current может быть установлен, только у одного;
  • по установленным значениям b_check можно просматривать историю точки.