OBI Energy Tracker отвязали от облака: IR-счётчик → 868 МГц LoRa → ESP32-C3 gateway
Штатный шлюз OBI Energy Tracker удалось подключить к собственному MQTTS-брокеру, сохранив оптический считыватель и субгигагерцовый радиоканал комплекта. Для этого bridge получает по BLE новый адрес брокера и собственную PKI, после чего телеметрия электросчётчика остаётся в локальной сети. Более глубокая модификация добавляет замену прошивки ESP32-C3 через штатный OTA-механизм.
OBI Energy Tracker, продававшийся примерно за €15, оказался устройством с вполне самостоятельной измерительной частью: оптический датчик считывает данные цифрового электросчётчика, передаёт их по LoRa в субгигагерцовом диапазоне, а домашний bridge публикует телеметрию по MQTT поверх TLS. Реверс-инжиниринг комплекта позволил перенести этот маршрут с облачного backend на локальный MQTTS-сервер.
В считывателе установлен микроконтроллер BAT32G135 с ядром ARM Cortex-M0+. Он обслуживает оптический интерфейс счётчика и радиоканал до шлюза. Проект декодирует передаваемые через оптический порт регистры OBIS/IEC 62056; состав показаний зависит от конкретной модели счётчика, его конфигурации и прав доступа к интерфейсу. Двухсторонняя радиочасть построена вокруг SX1262-совместимого модуля Ra-03SCH. Для исследованной прошивки указана частота 869.5 МГц, хотя сам комплект относится к диапазону 868 МГц. Параметры LoRa следует снимать с SPI-обмена конкретной ревизии: частота сама по себе не определяет SF, полосу и скорость кодирования.
Шлюз собран на ESP32-C3, оснащён Wi-Fi, BLE и тем же радиотрактом SX1262. Заводская логика отправляет JSON-телеметрию на MQTT endpoint через TLS, используя схему, близкую к AWS IoT fleet provisioning. Документация производителя также указывает MQTT, JSON и шифрованную передачу в backend. Именно этап provisioning стал точкой перенастройки: bridge принимает по BLE корневой сертификат CA, клиентский сертификат, claim certificate и URL брокера. Затем устройство получает учётные данные у локального сервера и устанавливает защищённое MQTT-соединение на порту 8883.
Для этой процедуры в опубликованной документации проекта используется 16-байтный ключ TEA, то есть 128-битное значение. Ранние пересказы ошибочно называли его 32-битным, вероятно приняв 32 шестнадцатеричных символа за размер ключа. Операции с provisioning уместны только для принадлежащего владельцу оборудования: исследователь указывает, что в изученной версии API могло возвращать параметры, критичные для привязки bridge, при недостаточной проверке владения. Состояние этой уязвимости после публикации проекта неизвестно.
Локальная схема допускает сохранение оригинальной прошивки bridge. Для более глубокой переделки подготовлена прошивка ESP32-C3, самостоятельно спаривающая считыватель, принимающая и расшифровывающая LoRa-пакеты и публикующая данные в выбранную MQTT-инфраструктуру. Тот же стек можно перенести на собственную плату ESP32 с SX1262, если штатный gateway не требуется.
Проводная перепрошивка серийного bridge затруднена: ROM download mode и JTAG отключены eFuse. Зато исследованный OTA-процесс допускает загрузку альтернативного образа после перенаправления устройства на локальный MQTTS-сервер. В опубликованной версии разбора отмечена проверка хеша образа при отсутствии криптографической подписи; это свойство может отличаться между ревизиями и быть закрыто обновлениями. Ценность работы состоит в сохранении готового оптического измерительного тракта и радиоканала при полном контроле над хранением данных, сертификатами и маршрутом телеметрии.