Если в вашем доме система резервного питания или альтернативной энергии собрана на компонентах Xantrex/Schneider Electric, то эта статья может быть полезна. Собственно, у меня как раз инвертор Xantrex XW 6048, панель управления Conext SCP, солнечный контроллер Conext MPPT 60 150. И всё это связано проприетарной сетью Xanbus. Система работает с 2010 года, солнечный контроллер с 2014г. В 2016г. я начал заниматься умным домом и возникла потребность получения электрических параметров системы для контроля и использования в алгоритмах. Например, для ограничения мощности электрического котла при наличии других потребителей. Часть этих правил описана здесь, но с тех пор их стало больше и они стали сложнее. На сайте производителя к моменту написания этой статьи ссылки на использованный мною Conext ComBox, я найти уже не смог, но изображение этого устройства — на заставке к статье, причем это реальная фотография моей установки.

В 2024г. ComBox перестал работать без объяснения причин. Оживить его известными способами не получилось. Нового такого же на рынке в России ни у кого в наличии по понятным причинам не оказалось, несмотря даже на вывешенные цены. Покупка по параллельному импорту оказалась такой дорогой, что проще отказаться от умного дома :). Однако, без электрических параметров DIY-энтузиасту и любителю умных домов жить совершенно некомфортно.

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

Базовые требования к разрабатываемому шлюзу:

1. Использование промышленного качества датчиков с точностью не хуже ±1%. Измерять будем переменный ток на входе в и выходе из инвертора, постоянный ток на входе в, выходе из солнечного контроллера и на пути от батарей к инвертору. Обязательные физические величины для измерения: напряжение и ток. Мощность — величина вычисляемая.

2. Датчики тока «неизвазивные», не должны ставиться в разрыв электрической цепи для создания разницы потенциалов. Другими словами выбор ограничиваем датчиками Холла.

3. Подключение разрабатываемого шлюза к локальной сети проводом. Никаких WiFi.

4. Разумная стоимость закупаемых компонентов.

Все компоненты, кроме корпуса, закуплены на Aliexpress.

Далее работала такая логика: измерение переменного тока — дело довольно накладное в вычислительном смысле, к тому же возникает необходимость разделения активной и реактивной мощности. И измерять все это надо в двух точках: на входе в и на выходе из инвертора. Это наводит на мысль о необходимости использования законченных устройств для измерения параметров переменного тока, которые выполняют черновую измерительную работу сами. И такие есть: PZEM016. Измеряют всё что нужно, с хорошей заявленной точностью и с помощью внешнего датчика Холла. Интерфейс — Modbus/RS-485.

Далее. Раз у нас интерфейс Modbus, то измерители параметров постоянного тока будем выбирать также под Modbus. Однако, здесь все предлагаемые законченные устройства — со встраиваемыми в разрыв резисторами для измерения падения напряжения. Это не соответствует первоначальным требованиям. Следовательно, придется подбирать датчики Холла и датчики напряжения отдельно. Стандартным выходом датчиков Холла является токовый, 4-20 mA или 0-20 mA. Следовательно, необходим еще измеритель тока. Самое интересное, что и датчики постоянного напряжения также имеют токовый выход. Итого: ищем промышленный считыватель токовых выходов с интерфейсом Modbus для передачи показаний в контроллер. И такой тоже есть, 8-канальный считыватель, может работать в нескольких разных режимах и передавать считанные показания по Modbus. К этому остается добавить промышленный же источник стабилизированного питания для работы датчиков и считывателя.

Следует обратить внимание на корректный подбор датчиков Холла, да и остальных тоже. Если в измеряемой цепи ток не превышает 10А, не следует брать датчик с диапазоном измерения 0-100А. Следует подобрать датчик с небольшим запасом, например 0-15А или 0-20А. Иначе не будет доверия к точности измерения.

Итак, измерители подобраны, интерфейс определён (Modbus). Остается преобразовать считанные значения в физические величины, собрать все измеренные величины вместе и отправить в OpenHAB. Для этого есть множество разных решений. Например, есть платы ESP32 со встроенным Ethernet-контроллером. Однако, я остановил свой выбор на минималистичном Linux-устройстве: Rock Pi S с оперативной памятью 512 Mb, без видеоконтроллера.

Последнее, что осталось подобрать из аппаратной части — это конвертер RS-485 для подключения к Rock Pi S. Поскольку у Rock Pi S есть 1 USB-порт, то самым очевидным решением будет конвертер USB/RS-485, причем его можно купить в комплекте с PZEM016 или 8-канальным считывателем. На фото выше такой конвертер лежит на PZEM016. Применение USB/RS-485 преобразователя позволит писать и отлаживать программу на обычном ПК. Это немаловажно, учитывая неспешность работы Rock Pi S. Да и делает спектр возможного применения разрабатываемого шлюза шире.

До настоящего момента все компоненты собираются без пайки. В моем случае пайка потребовалась для обеспечения питания Rock Pi S. Установлен обычный импульсный преобразователь постоянного тока на микросхеме LM2596, понижающий напряжение с 24В до 5В. На фото ниже виден под Rock Pi S.

В итоге получилась вот такая конструкция:

За пределами монтажной коробки установлены два PZEM016, и датчики Холла. В самой коробке оставлено место под какое-либо будущее расширение.

В закрытом виде выглядит пожалуй даже солиднее оригинального шлюза :)

Теперь софт. Поиск быстро приводит к мощной библиотеке libmodbus, которая помимо USB/Modbus-конвертеров поддерживает также TCP/Modbus-конвертеры, что также вполне рабочий вариант и позволяет обойтись без отдельного вычислителя, а использовать, например, сервер умного дома для считывания параметров Modbus.

Исходный код шлюза с комментариями, инструкцией по сборке находится здесь. Его разбирать смысла нет, там всё просто. Стоит отметить только некоторые нюансы, с которыми пришлось повозиться. В интерфейсе умного дома хочется видеть, не только мгновенные значения напряжения, тока, мощности, но и накопленные за день данные по потребленной от сети энергии, полученной от Солнца энергии, отправленной на батареи энергии. Видеть в динамике, в процессе накопления. PZEM016 хранит потребленную мощность нарастающим итогом с момента запуска. Ну а считыватель не хранит ничего, а только считывает показания датчиков. Кроме этого, в случае перезапуска программы или целиком Rock Pi S, необходимо сохранять накопленные данные, иначе при рестарте отсчет пойдет с нуля. Для этих целей в классах Modbus-устройств реализованы методы load() и save(), а также вспомогательные классы loadData и saveData. Сохранять будем при окончании работы программы, а также при переходе через полночь. Чтобы можно было видеть накопленные за весь вчерашний день данные. В случае с PZEM016 я решил не сбрасывать ежедневно итоговый счетчик Вт.ч, а вычислять смещение для расчета дневного накопления. Это полезно для сравнения потребленной мощности за длительный период, например за год, на входе в инвертор и выходе из него. Разница будет показывать реальную работу Солнечной энергии на полезной нагрузке в доме, без учета зарядки аккумуляторов.

При написании systemd-юнита для автозапуска шлюза необходимо убедиться, что при остановке/перезапуске сервиса, шлюз заканчивает работу естественным образом. Иначе не получим сохраненные значения. Я решил эту задачу вводом задержки в юнит и параметром ExecStop, запускающим скрипт stop.sh. Но, это не единственный способ, конечно.

Еще один нюанс связан со скоростью чтения Modbus-устройств. Она ограничена PZEM016 и это всего 9600 бод. В итоге три устройства, по 6 параметров в каждом, считываются за примерно 350 мс. Т.е. быстрее, чем 3 раза в секунду данные получить невозможно. Добавление новых Modbus-устройств на единую шину еще ухудшит картину. Впрочем, пока этого достаточно. Более того, в OpenHAB, данные отправляются раз в 3 секунды, это настраивается в конфигурационном файле. Это время можно уменьшить, но быстрее, чем 3 раза в секунду данные обновляться всё равно не могут. Кроме всего сказанного, для обеспечения непрерывности измерения отправка данных в OpenHAB осуществляется в отдельном потоке. Данные отправляются одной строкой со всех устройств, с разделителем «;». Правило в OpenHAB уже распределяет эти данные по необходимым items. Для передачи данных в HomeAssistant необходимо существенно переработать логику отправки данных. Или делать парсер на стороне HomeAssistant.

И, наконец, последний нюанс связан с программным сглаживанием показаний. PZEM016 - устройство законченное и осуществляет сглаживание само, а вот данные, считываемые 8-канальным считывателем необходимо сглаживать, чтобы убрать наводки и случайные отклонения. Это есть в программном коде.

Работает Rock Pi S под Armbian. Рекомендованный производителем Debian не подошел, на нем были проблемы с работой библиотеки libmodbus, с которыми я не стал разбираться.

Вот пример часового графика электрических параметров на Android-приложении OpenHAB, большая часть которых получена с разработанного шлюза:

На верхнем графике — "мощность сети" и "мощность нагрузки" измерены с помощью PZEM016, а "мощность на выходе" — произведение постоянного напряжения и постоянного тока на выходе солнечного контроллера, измеренные с помощью 8-канального считывателя. Видим, что к вечеру Солнце уже мало помогает питанию дома. На среднем графике "напряжение на солнечных панелях" и "напряжение на батареях" измерены датчиками постоянного напряжения, подключенными к 8-канальному считывателю. На нижнем графике "напряжение на нагрузке" измеряется PZEM016, остальные параметры двумя другими самодельными устройствами. Видим, что напряжение на выходе близко совпадает с напряжением на нагрузке. Так и должно быть. По сути, в текущем режиме работы инвертора (байпас) это измерено в одной точке. Видим, что измерения, сделанные разными методами, дают близкий результат. Конечно, показания всех устройств калибровались с помощью цифрового мультиметра.

Итого:

1. Решена проблема получения параметров электрического хозяйства после выхода из строя импортного шлюза. Причем решена очень доступными средствами.

2. Весь разработанный шлюз со всеми датчиками работает более 1 года без перезагрузок, зависаний и прочих проблем, показывает высокую стабильность.

3. В случае замены силового оборудования, шлюз можно будет легко перенести на новую систему, так как он не привязан ни к протоколу устройств, ни к карте адресов параметров Modbus конкретных устройств. В последнем случае его можно будет использовать для сравнения получаемых от устройств параметров.

Что не получилось:

1. Изначально не ставилась задача управления силовыми устройствами, несмотря на то, что Conext ComBox это умел делать и я этим пользовался. Поскольку Xanbus — проприетарный и закрытый протокол, с самого начала пришлось отказаться от этого.

Хочется отдельно заметить, что конечной точностью измерений я совершенно удовлетворен и не гнался за идеальным измерением. Поэтому не принимал во внимание влияние колебаний напряжения питания, точность стабилизации напряжения питания, линейность датчиков, сокращение точности при последовательных преобразованиях (например: датчик Холла→считыватель) и т.д. Полученный результат полностью удовлетворяет заказчика и, возможно, даже точнее, чем получаемый ранее через оригинальный шлюз Conext ComBox. По крайней мере при солнечной мощности менее 100Вт я получил однозначно более точный результат.

Послесловие. Описанный шлюз заработал в сентябре 2024 года. На момент написания статьи, июнь 2026, в сети нашёлся проект чтения параметров силовых устройств по сети Xanbus. Я его не собирал, но, возможно сделаю второй шлюз на базе этого проекта. Замечу, что на текущий момент проект также только читает параметры, устанавливать не может.