Спасибо за ваш труд, коллеги!
Из любопытсва хочется поинтересоваться: а вариант написания собственной утилиты для мониторинга/управления зоопарком устройств не расматривался?
По моему скромному опыту, NETCONF очень выручает, особенно если имеется оборудование малоизвестных вендоров, для которого нет готовых модулей Ansible. Но которое хотя бы минимальным образом поддерживает RFC 6241.
При этом можно написать своего рода «единый API» для единообразной работы со всем железом. Например, условный «get_osfp_neighbors» который может отличаться нюансами реализации для разных устройств.
Идеальной для вендора была бы ситуация, когда разброс моделей устройств на руках у пользователей минимален, а производители Bluetooth чипов взаимодействуют с разработчиками решения. Насколько я понимаю, именно такая ситуация складывается с продукцией Apple и именно поэтому базой для решения был выбран iBeacon, а не Eddystone.
К сожалению, остаётся не ясным, какая именно математика работает внутри данного решения. Из общения с вендором и инженерами в community Aruba известно лишь, что ПО сканирует эфир и последовательно определяет три маячка с самыми мощными сигналами, после чего работает только с ними. Как именно происходит вычисление координат точек знают только программисты Meridian. При этом задержка при позиционировании составляет около двух секунд.
К слову, вышеописанная последовательная выборка начинает сильно усложнять планирование расположения маячков, если помещение является многоуровневым (например, ТЦ с галереями над атриумом). Вполне возможна ситуация, когда на галерее второго этажа устройство принимает сигналы с двух маячков галереи и одного-атриума, что может приводить к «телепортации» вычисленной позиции между этажами.
Из любопытсва хочется поинтересоваться: а вариант написания собственной утилиты для мониторинга/управления зоопарком устройств не расматривался?
По моему скромному опыту, NETCONF очень выручает, особенно если имеется оборудование малоизвестных вендоров, для которого нет готовых модулей Ansible. Но которое хотя бы минимальным образом поддерживает RFC 6241.
При этом можно написать своего рода «единый API» для единообразной работы со всем железом. Например, условный «get_osfp_neighbors» который может отличаться нюансами реализации для разных устройств.
К слову, вышеописанная последовательная выборка начинает сильно усложнять планирование расположения маячков, если помещение является многоуровневым (например, ТЦ с галереями над атриумом). Вполне возможна ситуация, когда на галерее второго этажа устройство принимает сигналы с двух маячков галереи и одного-атриума, что может приводить к «телепортации» вычисленной позиции между этажами.