Добавление в Web UI в SVG Dashboard обновления data атрибутов

Программное обеспечение Web UI
1

Для SVG Dashboard есть всего 4 способа обновление параметров

Чтение, Запись, Видимость и Стили.
Я со стороны UI разработчика (и пользователя WB) могу сказать что менять стили напрямую не очень гибко. Не раскрывается вся мощь CSS (особенно анимацию) и приходится много дублировать стилевой информации.

Очень удобно делать на тегах наборы data атрибутов которые бы так же читались с MQTT каналов как сейчас это можно сделать для стилей. Подробнее про data атрибуты тут Using data attributes - Learn web development | MDN

Плюсом такого разделения является то что данные с разных каналов можно композировать независимо. Например цвет обводки отвечает за включенность автоматизации, а цвет заливки за фактическое включение реле. А css анимацию активировать для ошибок

Есть ли в планах расширить SVG Dashboard пятым типом? Чтобы можно было писать что-то типо вот такой секции в css (при условии маппинга MQTT топика атрибут data-turn=“on | off”, или прям сырое значение из топика 1 | 0)

  <style>
    #light rect,
    #light path,
    #light circle {
      stroke: lightblue;
      stroke-width: 2px;
    }

    #light *[data-turn="on"] {
      fill: gold;
    }
    
    #light *[data-turn="off"] {
      fill: darkgrey;
    }
  </style>

Беглый анализ кода показывает что добавить

appendDataAttribute(element, param) {

не так сложно. Он фактически будет таким же как style только даже проще.
В конфигурации это выглядело бы

"data": {
    "enable": true,
    "channel": "wb-mr6c_142/K3",
    "attribute-name": "turn"
    "value": "((val + 0) > 0) ? 'on' : 'off'"
}

или вообще без value (значение запишется напрямую)
Как можно двигать эту идею до реализации? Готов поучаствовать в разработке, если подскажете как запускать home ui в виртуальном режиме (на своем живом контролере страшновато вести разработку)

3 лайка
2

Добрый день. Спасибо большое за предложение, передал информацию коллегам.

1 лайк
3

В догонку кстати. Хотел реализовать на SVG что-то отличное от Вкл Выкл. Например панель для задания температур. И вот столкнулся с тем что реализовать 2 стрелочки (+1 и -1) градус не получается адекватно. так как в write нет возможности писать что-т типо

"write": {
                            "enable": true,
                            "channel": "wb-mr6c_161/K4",
                            "value": "(val + 0) + 1"
                        },

Беглый взгляд показывает что

    appendWrite(element, param) {
        element[0].classList.add('switch');
        element[0].addEventListener('click', (e) => {
            var cell = this.deviceData.cell(param.channel);
            cell.value = (cell.value == param.value.on) ? param.value.off : param.value.on;
        });
    }

тут 1 строку поправить. Если влоб через eval делать. Что-то типо

cell.value = eval(param.value.replace("val,"cell.value"));

Ну или чуть сложнее для сохранения обратной совместимости

1 лайк
4

Это прямо сейчас можно сделать через виртуальное устройство на wb-rules. Но пожелание запишем, спасибо.

5

Можно, но это костыль. Не хотелось бы виртуальные устройства превращать в кумулятивные регистры для переноса значение. Так что да хотелку запишите.

А вам можно как-то это допилить и предложить через Gihub MR? Мне только поныть как запускать это добро локально на вируталке какой-нибудь или в докер образе. Можете описать процесс?

1 лайк
6

Вот тут описано как. Но именно запускать внутри сервисы - пожалуй никто не пробовал, это без реального железа скорее бесполезно.

7

Смотря какое добро… Если сам WebUI, то он лежит тут GitHub - wirenboard/homeui: Wiren Board web interface и его можно запускать прямо на том сервере, где производится сборка, указав в Settings->WebUI IP и port либо собственного сервера, где запущен Mosquitto MQTT broker, либо контроллера WB. В обоих случаях можно моделировать любое устройство, публикуя данные “от его имени” утилитой mosquitto_pub. Только в первом случае не будет риска что-нибудь сломать “на живом контроллере”, но и не будет работать часть функционала, который обеспечивается разными процессами на WB, обрабатывающими специфичные mqtt запросы (типа обращения к базе, обработки правил, редактирования конфигов и пр.). А во втором - всё будет “по-настоящему”. Но если не работать с настоящими устройствами, а только со своими виртуальными, и соблюдать минимум осторожности, то риск повреждений - минимален.

P.S. Я не настоящий сварщик.
P.P.S. А вообще, идея иметь докер с эмулятором и “виртуальным WB” внутри - весьма продуктивна…

8

Закрою тему, раз больше не обсуждаем.

Пожелания в табличку занесли, учтём при планировании будущих доработок SVG-панелей.

11

Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.