Это мы поддерживать не будем. Собственно разделение на readonly и не readonly каналы и было введено, чтобы убрать бардак.
В вашем случае правильное решение проблемы - это создавать устройства и наполнять их данными в одном сервисе. Это может быть либо wb-rules, в который переедет лоигка из сервиса опроса SNMP, либо, наоборот, внешний сервис опроса SNMP, в котором нужно будет создать структуру устройств.
Я буду очень признателен, если вы найдёте 10 минут и напишите подробно про куцесть и непредсказуемость родного драйвера SNMP. Нам это важно, чтобы понять, что чинить и улучшать. Вы свою проблему уже решили, но другим пользователям это будет полезно. Спасибо!
И создали новый бардак - свалив все в одну кучу. Т.е. одним параметром и канал в не readonly включаем и одновременно в WebUI поле редактируемым делаем. Нельзя, хотябы это отдельными параметрами задавать?
В вашем случае правильное решение проблемы - это создавать устройства и наполнять их данными в одном сервисе. Это может быть либо wb-rules,
Даже если все делать в wb-rules (версии 2.x.x), то для того что бы произошло событие “whenChanged” в результате каких то вычислений и присвоение значений вирт. устройству - это вирт устройство должно быть readonly: false. И оно опять же становится редактируемым в интерфейсе.
либо, наоборот, внешний сервис опроса SNMP, в котором нужно будет создать структуру устройств.
Видимо, к этому все и прийдет - прийдется забыть про wb-rules и WebUI и использовать стороние сервисы.
И да - вы так и не ответили - в чём же логика. Почему readonly канал (по вашей терминологии) не может вызвать событие “whenChanged” путем записи в топик через MQTT типа /devices/DEV/controls/CONT/on
Делали так изначально. Путались все, включая разработчиков и авторов.
Так мне кажется это вполне логичным. Вот пишете вы на wb-rules, например, драйвер внешнего термостата. Температура с его датчика - это параметр с readonly: true, потому что поменять его никак нельзя. Зачем там whenChanged?
Ну то есть выглядит так, как будто вы пытаетесь связывать какие-то внутренние компоненты через логику правил, которая для этого не предназначена. Значит, их нужно связать как-то по-другому. Функцию там вызвать, флажок поставить.
Логика в том, что если вы можете поменять значение этого канала снаружи wb-rules (или другого сервиса - держателя соответствующего устройства), то этот канал не readonly.
readonly - это свойство канала, которое показывает, можно ли его менять. Это не управление отображением в веб-интерфейсе.
С точки зрения wb-rules, MQTT и конвенций, веб-интерфейс - это ровно такой же сервис, как и все другие. Поэтому он подчиняется всем тем же правилам. Если кому-то можно менять канал, то и веб-интерфейсу можно.
Я думаю, что решение вашей задачи лежит где-то вокруг настройки виджетов в веб-интерфейсе, чтобы readonly:false каналу можно было отключить возможность задавать в этом виджете данные.
Делали так изначально. Путались все, включая разработчиков и авторов.
Думаю, тут вопрос больше понятий и терминологии. Назвали параметр, например, editable - сразу путаться бы перестали
Логика в том, что если вы можете поменять значение этого канала снаружи wb-rules (или другого сервиса - держателя соответствующего устройства), то этот канал не readonly.
Склонен подозревать, что вы, вероятно, решили ограничить нагрузку на wb-rules, уменьшив количество отслеживаемых событий.
Ну то есть выглядит так, как будто вы пытаетесь связывать какие-то внутренние компоненты через логику правил, которая для этого не предназначена. Значит, их нужно связать как-то по-другому. Функцию там вызвать, флажок поставить.
Стараюсь функцию whenChanged вообще не использовать (только как событие, того, что какой то контрол или уставки в интерфейсе изменили). Изменение значений с датчиков отслеживаю переодическим опросом. Так сказать - топор в бою надежней.
Я думаю, что решение вашей задачи лежит где-то вокруг настройки виджетов в веб-интерфейсе, чтобы readonly:false каналу можно было отключить возможность задавать в этом виджете данные.
Думаю, это было бы идеальным решением - задавать параметры вывода в настройках виджетов.
На “переходной” период для чтения “readonly” можно вообще использовать trackMqtt.
Вопрос касался перехода работающих скриптов со старой версии движка на новую с меньшими затратами на переделку. Потому, буду пока терпеть такой вид отображения значений. У меня это в основном отображаемые счетчики обратных таймеров для визуализации остатка времени работы исполнительных устройств.
Только контролы типа “switch” и “range” по умолчанию активны для изменения в виртуальном устройстве. Для остальных нужно указывать опцию readonly: false. По историческим причинам.
Только если в вирт. устройстве задано - readonly: false
В то время, как устройства созданные через wb-mqtt-serial реагируют на события WhenChnged даже без этой опции (в мета опциях readonly 0 отсутствует или даже напротив - устанвлена 1 “…/meta/readonly 1” )
Только контролы типа “switch” и “range” по умолчанию активны для изменения в виртуальном устройстве. Для остальных нужно указывать опцию readonly: false. По историческим причинам.
Вообще-то, wb-rules ver 1.7.1 реагирует на публикацию значений и величин в топиках …/on без всяких опций readonly: false. О каких исторических причинах идет речь?
@vugluskr Виталий, добрый день! Мне кажется, мы это уже обсуждали в другой теме и не уверен, что есть смысл начинать сначала.
В нашей MQTT-конвенции у каждого устройства есть драйвер-владелец. Только он может писать в топик без /on на конце - таким образом он сообщает всему остальному миру значение определённого канала. Этот же владелец подписывается на топик с /on на конце: в этом топике он ждёт новые значения канала от внешних по отношению к нему сервисов. В топик с /on могут писать все остальные. Топик с /on предназначается только для сервиса - владельца устройства.
readonly:true маркирует каналы, на которые внешние сервисы повлиять не могут. Это, например, показания датчика температуры. Эти показания сервис (драйвер) - владелец устройства считывает с физического датчика и публикует в сервис без /on.
Единственно, на что я хотел обратить внимание, что в текущей реализации без readonly и без /on можно через командную строку писать в топик, данные в неё попадают (если верить web интерфейсу) но не вызывают срабатывания триггера.
Было бы логично, если бы данные не принимались вовсе, или наоборот, триггер срабатывал. Просто сейчас получается неопределённое промежуточное поведение, и как результат - недоумение :).
Ну и, вдогонку, я не нашёл описания именно этого расклада у вас в wiki. Может, плохо мскал. Если его там и вправду нет, добавить было бы полезно.
Тут надо для сначала понять логику.
В /on пишем желаемое состояние устройства. А из топика (который без /on) читаем текущее.
Простой пример: диммер. У него яркость меняется плавно Записали в /on новое значение, “уставку” и наблюдаем изменение реального значения.
Сделано как раз для того чтобы один и тот же топик можно было использовать как интерфейсом или правилами (источник изменений) так и драйвером устройства.
Подскажите, пожалуйста, как правильно удалять правило по аналогии с созданием defineRule. Мне надо менять условие срабатывания по cron и тут без удаления, видимо, никак.
Хотел было прекратить дискуссию, но не смог, потому что все эти условности меня лично тоже вводят в недоумение:
По вашей логике WUI, как и остальные сервисы/драйверы WB должен быть подписан только на топики предназначенные для него.
Или реагировать, хотя бы только на все топики …/on (старая версия WebUI так и поступала). Но он, черт возьми, выводит все подряд, т.е. все значения, которые пишутся напрямую в device/control (без …/on на конце).
Таким образом, если через MQTT опубликовать напрямую в топик типа /devices/vdev/controls/vctrl определенное значений - в UI я вижу это значение вирт. устройства.
А когда пытаюсь прочитать значение этого вирт. устройства напрямую с помощью wb-rules, например,
var A = dev[“vdev”][“vctrl”]) -
то там совсем другое значение, которое он (wb-rules) получил в древности по подписке на …/on (/devices/vdev/controls/vctrl/on)
Теперь, я понимаю, что не должен писать в топик напрямую (это право только сервиса владельца данного вирт. устройства)
Но бесит
Считаю, что необходимо это разжёвывать в документации с примерами, которые были приведены выше.
