Здравствуйте! Сегодня выходной день, поэтому сотрудники техподдержки ответят вам в рабочий день.
Пока что я, автоматический помощник, проанализировал ваш вопрос и постарался найти решение:
Разберу ваши предложения по пунктам, с прицелом на то, что можно сделать уже сейчас на Wiren Board (контроллеры WB6/WB7/WB8 и счётчики/модульные измерители, такие как WB-MAP, WB-MAP3E/MAP6S и т.п.), а что — очевидно зона доработки прошивок/ПУ.
1. Дополнительный множитель для коэффициента трансформации
Сейчас типовой механизм — один коэффициент трансформации (для ТТ/ТН) в настройках устройства (через веб-интерфейс или шаблоны /etc/wb-mqtt-serial.conf и .json-шаблоны) и дальше возможна «надстройка» через виртуальные устройства и правил wb-rules (как вы и делаете). Это действительно создаёт лишние топики и нагрузку.
Полноценное решение — именно то, про что вы пишете: второй множитель в прошивке самого счётчика/модуля, чтобы:
- измерительные регистры × (коэф. ТТ/ТН) × (доп. множитель);
- наружу в MQTT сразу выходили «правильные» значения без создания виртуальных каналов.
Сейчас это можно лишь эмулировать:
- оставить в устройстве «базовую» конфигурацию;
- домножать значения в
wb-rules и публиковать в отдельные топики (виртуальные устройства через /etc/wb-rules/ и /etc/wb-mqtt-confed.d/).
Но да, это только обходной путь, а не замена аппаратной/прошивочной функции. Ваше пожелание логичное и как минимум хорошо стыкуется с уже имеющейся болью с коэффициентами и лимитом публикаций.
2. «Публиковать при изменении на Δ» для каждого значения
То, что вы описали (дельта + периодическое обновление), сейчас частично можно реализовать только на уровне контроллера:
Вариант через wb-rules:
- Отключить/уменьшить частоту публикации «сырого» значения (если позволяет устройство/драйвер).
- Делать свой «фильтр по дельте»:
- хранить последнее опубликованное значение в переменной;
- по приходу новых данных проверять
if (Math.abs(new - prev) >= delta), и только тогда публиковать в отдельный топик (виртуальное устройство).
Пример скелета правила:
defineRule('filtered_voltage', {
whenChanged: 'wb-map6s_123/Voltage_L1', // пример топика
then: function (newValue, devName, cellName) {
var delta = 1.0; // публиковать при изменении >= 1 В
var key = 'last_voltage_L1';
var prev = global.get(key);
if (prev === undefined || Math.abs(newValue - prev) >= delta) {
global.set(key, newValue);
dev['virt_power/Voltage_L1_filtered'] = newValue;
}
}
});
Но:
- это опять ведёт к виртуальным устройствам и дополнительным топикам;
- не уменьшает поток «сырых» данных от драйвера к MQTT, а только ограничивает «пользовательские» топики.
Для системной разгрузки действительно нужен параметр на уровне устройства/драйвера (внутри wb-mqtt-serial или прошивки счётчика), как вы описали — отдельный параметр «минимальное изменение для публикации» плюс, возможно, отдельный периодический опрос. Аналог KNX-подхода — хорошая идея.
3. События, которые сам счётчик мог бы отслеживать
Многие из перечисленных событий сейчас приходится реализовывать на стороне контроллера через правила:
-
Обрыв нуля / фазы, отсутствие напряжения
По факту — анализ фазных напряжений (Urms) и состояния фаз:
- если одна фаза просела ниже порога и/или пропало напряжение — событие «обрыв фазы»;
- все фазы одновременно ниже порога — «отсутствие напряжения».
-
Отсутствие потребления на всех фазах
Анализ суммарного тока/мощности близкой к нулю в течение заданного времени.
-
Превышение/понижение напряжения/нагрузки в течение времени
Сейчас это типично делается в wb-rules: при превышении порога старт таймера, если условие держится N секунд — генерируем событие (MQTT-топик, уведомление, лог).
-
Нарушение чередования фаз, неверное направление ТТ
Здесь уже нужны либо специализированные вычисления на стороне счётчика (анализ векторной диаграммы токов/напряжений и cos φ по фазам), либо достаточно сложные сценарии в контроллере. В прошивке счётчика такую логику реализовать значительно надёжнее и однозначнее.
На текущем уровне:
- большую часть списка можно реализовать как правила на контроллере с публикацией «событийных» топиков (например,
/events/power/phase_loss, /events/power/voltage_over и т.п.);
- но то, что вы предлагаете, — именно перенести эту логику (или её ядро) в прошивку счётчиков/измерительных модулей, чтобы контроллер получал уже готовые флаги/состояния. Это ощутимо разгрузит и MQTT, и
wb-rules, и упростит конфигурацию.
4. Числовой параметр «степени угрозы»
С точки зрения реализации на сегодня:
- можно завести виртуальное устройство
power_status с каналом severity (0…4):
- 0 — всё ОК,
- 1 — критическое,
- 2 — требуется внимание,
- 3 — информационное,
- 4 — возможная ошибка конфигурации.
- правилами
wb-rules выставлять это значение в зависимости от сработавших условий (из п.3);
- на уровне интерфейса (Dashticz, встроенный UI, внешняя SCADA, Home Assistant и т.п.) сделать цветовую индикацию по этому полю.
Но более стройное решение — если такие коды будет выдавать сам счётчик или модуль, а в MQTT будет просто один канал severity (как вы и описали). Это хорошо ложится на концепцию «интеллектуального измерительного устройства», где контроллер больше занимается интеграцией, чем низкоуровневой логикой.
5. Цвет шапки виджета устройства при ошибке
Сейчас базовый веб-интерфейс Wiren Board:
- отображает состояние каналов, иногда статус устройства в виде иконок/текста;
- при большом количестве устройств и свёрнутых виджетах действительно сложно быстро увидеть, какие в ошибке.
То, что вы предлагаете — подсветка шапки виджета устройства при наличии ошибки (например, device/controls/…/error или по состоянию драйвера) — можно частично реализовать кастомизацией фронтенда (если проект позволяет менять шаблоны UI), но это уже зона доработки веб-интерфейса контроллера.
С инженерной точки зрения идея хорошая:
- быстрая визуальная диагностика без разворачивания всех устройств;
- особенно полезно при системах с десятками/сотнями модулей.
Что можно сделать уже сейчас (на уровне пользователя)
Пока функциональность не реализована в прошивках/драйверах, вы можете:
-
Собрать свою «надстройку»:
- виртуальные устройства для «отфильтрованных» значений (дельта-публикация);
- отдельные MQTT-топики для событий (обрыв фазы, перенапряжение и т.п.);
- единый канал
severity с вашей градацией 0–4.
-
Минимизировать нагрузку:
- уменьшить частоту опроса по менее важным каналам (часть параметров можно опрашивать реже через настройки опроса в wb-mqtt-serial);
- объединять несколько «логических» событий в один «статусный» регистр/топик (как вы и предлагаете с кодами 0–4).
-
UI-уровень:
- использовать внешний интерфейс (например, Home Assistant / SCADA), где можно гибко настроить цветовую индикацию по полю
severity или по ошибочным флагам;
- в стандартном UI Wiren Board можно хотя бы сгруппировать проблемные устройства на отдельной странице/вкладке.
Ваши предложения очень системные: они уменьшают нагрузку (MQTT, правила), повышают диагностику и лучше соответствуют практике, которую вы упомянули (KNX). По сути, это набор требований к «новому поколению» прошивок счётчиков/модулей и драйверов на WB.
Когда инженеры подключатся в рабочий день, они смогут:
- прокомментировать планы по введению дополнительного множителя;
- сказать, планируются ли параметры «дельта-публикации» в драйверах/устройствах;
- оценить возможность добавления перечисленных событий и статусного кода угрозы в прошивки конкретных моделей счётчиков / модулей;
- передать ваши пожелания по UI (цвет шапки виджета при ошибке) в план развития интерфейса.
Примечание: Я — искусственный интеллект, а не человек. В моих ответах могут быть неточности.