День добрый!
Прошу привести шаблоны config-wbe2-i-ebus и config-wbe2-i-opentherm-fw1.4/1.7.3 к единому виду в части наименования топиков и типов полей.
Ниже указана разница в названиях и типах:
ebus /devices/wbe2-i-ebus_12/controls/Hot Water Temperature (TEMPERATURE)
opentherm /devices/wbe2-i-opentherm_11/controls/Hot Water Temperature (VALUE)
ebus /devices/wbe2-i-ebus_12/controls/Heating Temperature (TEMPERATURE)
opentherm /devices/wbe2-i-opentherm_11/controls/Heating Temperature (VALUE)
ebus /devices/wbe2-i-ebus_12/controls/Heating Return Water Temperature (TEMPERATURE)
opentherm /devices/wbe2-i-opentherm_11/controls/Heating Return Water Temperature (VALUE)
ebus /devices/wbe2-i-ebus_12/controls/Hot Water Setpoint Max (TEMPERATURE)
opentherm /devices/wbe2-i-opentherm_11/controls/Hot Water Setpoint Max (VALUE)
ebus /devices/wbe2-i-ebus_12/controls/Room Temperature (TEMPERATURE)
opentherm /devices/wbe2-i-opentherm_11/controls/Room Temperature (VALUE)
ebus /devices/wbe2-i-ebus_12/controls/Room Temperature Setpoint (TEMPERATURE)
opentherm /devices/wbe2-i-opentherm_11/controls/Room Temperature Setpoint (VALUE)
Необходимо (очень) для унификации интеграции с другими системами, в частности СпрутХаб.
Можете уточнить, что именно вы планируете реализовать и с какой конкретно проблемой столкнулись? Если я правильно понимаю, во время создания интеграции вы всё равно будете работать с привязкой к нужным MQTT-топикам и их именованию.
Пожалуйста, опишите вашу задачу более конкретно:
Что вы хотите достичь?
Какие ошибки или сложности возникают?
Если возможно, приведите примеры проблем или сообщений об ошибках.
Это поможет нам предложить обходное решение или найти способ устранить проблему.
Хочу сделать универсальный шаблон в СпрутХаб для управления котлами, который будет поддерживать как openterm, так и EBUS, в зависимости от типа подключения котла.
В этом случае, будет значительно проще (правильнее, красивее) если передаваемые топики будут одинаковыми по названию и типам данных. Кроме критичного для наблюдения топика уровня модуляции, еще температура передается в EBUS как temperature, а в ОТ как value. Различия, которые есть в настоящее время, привел в первом сообщении.
Готов сделать все самостоятельно и передать через git wb-community. Если такой вариант подойдет, сообщите, пожалуйста.
Ошибок и проблем нет. Это работа по улучшению пользовательского взаимодействия с ВБ и СХ.
Добрый день.
Существующие шаблоны мы не можем изменять, т.к нужна обратная совместимость.
У меня есть вопрос, как в шаблоне на Спрутхабе может повлиять разный тип данных? Насколько я понимаю, в Спрутхабе шаблон для конвертации из нашей конвенции mqtt в Спрутовскую используется только наименование топика. В данном случае из представленных вами данных вижу только в одном месте отличие: “Burner Modulation Level” и “Burner Modulation Level (%)”. Я думаю, что это не составит труда это обработать в шаблоне.
Будем рады вашему участию в нашем коммьюнити. Заранее спасибо за ваш вклад.
Как раз это и составляет большую проблему, т.к при обработке я могу использовать переменную имени устройства, но при получении названия топика необходимо использовать одно и тоже наименование, чтобы не увеличивать количество устройств, лишние из которых потребуется скрывать пользователям вручную.
Приведу пример.
//получаем общее имя для модуля котла для использования в дальнейшем в переменной
"modelId": "/devices/(wbe2-i-(opentherm|ebus)_[0-9]{1,3})/controls/Boiler Status/meta",
// здесь сокращение кода сценария
// получаем состояние устройства, когда горелка работает
{
"type": "CurrentHeatingCoolingState",
"link": {
"type": "Double",
"topicGet": "/devices/(1)/controls/Burner Modulation Level",
"map": {
"OFF": "0",
"HEAT": "1~100"
}
},
"validValues": "OFF, HEAT"
}
В коде выше описан вариант только для EBUS, который не будет работать для ОТ и придется дублировать его с названием топика для ОТ.
Т.е. надо описывать два устройства, одно из которых будет “висеть” в интерфейсе в неработающем виде.
Если сделать название топиков одинаковыми, достаточно будет описать устройство один раз не зависимо от типа OT или EBUS.
Поэтому и прошу привести названия топиков к единому виду в openterm и ebus устройствах. Готов сделать это и представить для ревью.
Формат шаблонов изменился, теперь вместо topicSearch используется modelId в заголовке шаблона.
Проверки (if-else) в шаблонах нет.
Как я и писал, если не привести к одному виду, то это будет два разных устройства и в зависимости от подключенного модуля одно из них будет просто неработающем. Учитывая, что сейчас и так уже 5-ть устройств и это будет перебором, причем просто из-за того, что топики кто-то назвал по-разному у устройств одного типа и одного производителя.
Почему их не привести к одному виду? На работу устройств в ВБ это никак не повлияет. В дальнейшем можно будет легко отслеживать их идентичность.
Добрый день.
Повторюсь. Для обратной совместимости существующие шаблоны изменять не можем, чтобы не навредить пользователям, которые уже давно их используют.
З.Ы. Можно сделать как угодно. И разными шаблонами и десятком устройств, половина из которых просто болтается неактивными. Все это обосновать совместимостью, нехватной времени, другими приоритетами и будет все вроде бы как логично. Но должна быть простая красота решения. К ней надо идти через последовательную работу и, если надо, корректируя прошлое. Если это не делать, то все постепенно скатится вникуда.
Нельзя менять сущности, в том числе и наименования в существующих шаблонах. Такое изменение просто положит существующие инстралляции. Поэтому и есть для приличного количества устройств разнобой.
И да, в новый версиях устройств - стараемся это учитывать и приводить к общему виду.