Во истину странно!
Переписал, заработало. Спасибо!
Русскую “С” от английской “C” на вид довольно сложно отличить, сам так попадался.
Предпринял новую попытку обновить wb-rules c 1.7.1 на 2.6.3 на «боевом» контроллере. Опять - неудача:
Первое
На этом контроллере кроме штатных сервисов Wiren работают дополнительные сервисы:
- Работают сервисы, которые опрашивают и управляют устройствами, работающие по протоколу SNMP. Родной драйвер WB мне использовать не удалось, ввиду его куцести и непредсказуемости.
- Работают сервисы, которые опрашивают и управляют устройствами по REST HTTP.
- Работает сервис, который проверяет, актуальны ли данные с устройств в MQTT БД, или уже “протухли” (на основе меняющих значений Uptime в регистрах датчиков и исполнительных устройств). Если данные протухли – сигнализирует или перезапускает wb-mqtt-serial
Всё это взаимодействует через wb-mqtt-db (через подписку и публикацию топиков по MQTT).
В старой версии wb-rules все виртуальные устройства были по умолчанию как бы “writable” и wb-rules реагировал на событие “whenChanged” , когда производилась публикация в mqtt топик вида /devices/DEV/controls/CONT/on
Параметр readonly: false в описании вирт устройств влиял только на возможность редактировать значение данного устройства в интерфейсе (WebUI)
В новой версии, для того чтобы wb-rules реагировал на событие “whenChanged” при записи в топик вида /devices/DEV/controls/CONT/on необходимо явно задавать параметр readonly: false и соответственно данные устройства становятся автоматически редактируемыми в WebUI ! Что для меня лично – совсем не желательно.
Мне нужно, что бы вирт. устройство отображалась в интерфейсе без возможности редактирования и реагировало на событие “whenChanged” при записи в топик вида /devices/DEV/controls/CONT/on
Мне непонятно - в чем логика того, что если устройство readonly, то оно не дожно реагировать на событие при записи в топик вида /devices/DEV/controls/CONT/on?
Второе
В версии wb-rules 1.7.1. при описании виртуальных устройств типа value и ряда других к нему приравненных (Temperature, Power, Voltage и прочих) допускалось указывать значение в кавычках. Движок автоматически преобразовывал текстовое значение в число. В новой же версии присвоение значения не происходит. Приходится убирать лишние кавычки (’ ')
В документации в разделе «Совместимость скриптов при обновлении wb-rules» об этом типе данных явно ничего не указано.
Было бы не плохо добавить эту информацию для тугих, как я.
PS
Прошу еще обратить внимание на виртуальные устройства типа «wo-switch». Они не реагируют на присвоение значений value: , да и вообще ,по-моему, ни на что не реагируют.
А для чего этот тип устройств нужен?
Добрый день!
Это мы поддерживать не будем. Собственно разделение на 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
Все возникшие проблемы были описаны в теме ниже
Если кратко
- Не поддерживались длиные OIDы
- Не поддерживались некоторые типы данных
- Падение сервиса, если при старте не мог “достучаться” до SNMP хоста
- Если SNMP хост во время опроса становился не доступен - это ни как не фиксировалось в виде ошибки (как это сделано у wb-mqtt-serial по modbus)
Делали так изначально. Путались все, включая разработчиков и авторов.
Так мне кажется это вполне логичным. Вот пишете вы на wb-rules, например, драйвер внешнего термостата. Температура с его датчика - это параметр с readonly: true, потому что поменять его никак нельзя. Зачем там whenChanged?
Ну то есть выглядит так, как будто вы пытаетесь связывать какие-то внутренние компоненты через логику правил, которая для этого не предназначена. Значит, их нужно связать как-то по-другому. Функцию там вызвать, флажок поставить.
Логика в том, что если вы можете поменять значение этого канала снаружи wb-rules (или другого сервиса - держателя соответствующего устройства), то этот канал не readonly.
readonly - это свойство канала, которое показывает, можно ли его менять. Это не управление отображением в веб-интерфейсе.
С точки зрения wb-rules, MQTT и конвенций, веб-интерфейс - это ровно такой же сервис, как и все другие. Поэтому он подчиняется всем тем же правилам. Если кому-то можно менять канал, то и веб-интерфейсу можно.
Я думаю, что решение вашей задачи лежит где-то вокруг настройки виджетов в веб-интерфейсе, чтобы readonly:false каналу можно было отключить возможность задавать в этом виджете данные.
На “переходной” период для чтения “readonly” можно вообще использовать trackMqtt.
Делали так изначально. Путались все, включая разработчиков и авторов.
Думаю, тут вопрос больше понятий и терминологии. Назвали параметр, например, editable - сразу путаться бы перестали 
Логика в том, что если вы можете поменять значение этого канала снаружи wb-rules (или другого сервиса - держателя соответствующего устройства), то этот канал не readonly.
Склонен подозревать, что вы, вероятно, решили ограничить нагрузку на wb-rules, уменьшив количество отслеживаемых событий.
Ну то есть выглядит так, как будто вы пытаетесь связывать какие-то внутренние компоненты через логику правил, которая для этого не предназначена. Значит, их нужно связать как-то по-другому. Функцию там вызвать, флажок поставить.
Стараюсь функцию whenChanged вообще не использовать (только как событие, того, что какой то контрол или уставки в интерфейсе изменили). Изменение значений с датчиков отслеживаю переодическим опросом. Так сказать - топор в бою надежней.
Я думаю, что решение вашей задачи лежит где-то вокруг настройки виджетов в веб-интерфейсе, чтобы readonly:false каналу можно было отключить возможность задавать в этом виджете данные.
Думаю, это было бы идеальным решением - задавать параметры вывода в настройках виджетов.
На “переходной” период для чтения “readonly” можно вообще использовать trackMqtt.
Вопрос касался перехода работающих скриптов со старой версии движка на новую с меньшими затратами на переделку. Потому, буду пока терпеть такой вид отображения значений. У меня это в основном отображаемые счетчики обратных таймеров для визуализации остатка времени работы исполнительных устройств.
И все же - почему в новом движке wb-rules “whenChanged” не реагирует на топики c /on на конце, если,
- они опубликованные из сторонних программ
- в вирт устройстве не выставлен флаг readonly: false
Но при этом, устройства созданные, например, wb-mqtt-serial визуально не имеют флага readonly: false - но они обрабатываются событием “whenChanged”
В чем логика?
Зачем создана такая путаница и “дискриминация” сторонних программ?
1 лайк
Так из bash через mosquitto_pub реагирует же!
Только контролы типа “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. Может, плохо мскал. Если его там и вправду нет, добавить было бы полезно.
А так то проблема решена, механизм заработал.
1 лайк
Тут надо для сначала понять логику.
В /on пишем желаемое состояние устройства. А из топика (который без /on) читаем текущее.
Простой пример: диммер. У него яркость меняется плавно Записали в /on новое значение, “уставку” и наблюдаем изменение реального значения.
Сделано как раз для того чтобы один и тот же топик можно было использовать как интерфейсом или правилами (источник изменений) так и драйвером устройства.
Подскажите, пожалуйста, как правильно удалять правило по аналогии с созданием defineRule. Мне надо менять условие срабатывания по cron и тут без удаления, видимо, никак.
Андрей, но там disable/enable вижу. А если поменять 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)
Теперь, я понимаю, что не должен писать в топик напрямую (это право только сервиса владельца данного вирт. устройства)
Но бесит 
Считаю, что необходимо это разжёвывать в документации с примерами, которые были приведены выше.
1 лайк