После обновления на контролере wb-6.5 командами apt-get update; apt-get upgrade, без всяких предупреждений, произошла замена мажорной версии wb-rules 1.7.1 на 2.2.2 !
В результате этого действа, многие контролы были преобразованы с мета тегом readonly. В том числе и контрол Rule debugging:
Сделал полное обновление софта (apt upgrade) на контроллере со старой версией wb-rules (1.7.1) и обнаружил, что обновление вероломно и без всяких объявлений заменило мне wb-rules 1.7.1 на wb-rules 2.2.2 !!!
После чего у меня в Web-интерфейсе все контролы созданные старым движком стали readonly !
Откатил версию обратно. Сижу теперь все мета-контролы через mosquitto_pub переправляю на перезаписываемые и вовсю матерю недальновидных программистов.
Версия 2.x публично тестировалась с декабря, то есть больше трёх месяцев. К сожалению, в какой-то момент мы должны считать новую версию достаточно проверенной и помещать её в стабильный дистрибутив.
Мне не известно механизма, который бы мог выдать предупреждения при обновлении. Думаю, что даже если он есть, то большинство пользователей просто это предупреждение проигнорирует при установке.
По делу:
Про Rule debugging понял
какие ещё контролы были преобразованы? Речь про системные контролы или про контролы, которые создавались внутри ваших правил? Если второе - пожалуйста выложите сюда нужный кусок правил и прокомментируйте, как именно вы пользовались виртуальными устройствами.
Ну это как раз выглядит правильно: теперь им writable надо задать через сам движок правил.
и это тоже правильно, старая делала точно так же. Только старая про writable ничего не знала и поэтому вообще это игнорировала, новая знает и не игнорирует.
Я бы послушал вас, когда у вас перестанет работать какая то программа после очередного обновления Windows - правильно это или нет?
и это тоже правильно, старая делала точно так же. Только старая про writable ничего не знала и поэтому вообще это игнорировала, новая знает и не игнорирует.
Значит и та и другая версия действуют неправильно. Сообразно логики работы всего софта контроллера, в центре его взаимодействия должен быть обмен и хранения данных через протокол MQTT.
Чем wb-rules лучше другого ПО контроллера?
Зачем wb-rules ведет свою отдельную историю в отдельной БД, а не использует для этого MQTT?
По крайней мере, почему нельзя было в новой версии сохранить те-же умолчания, что и в старой?
А в идеале - новая версия при первом запуске и отсутствия собственного файла данных, должна была считать данные старой программы. - ВОТ ЭТО БЫЛО БЫ ПРАВИЛЬНО.
Кстати, новая версия движка не реагирует на сообщения с мета /on , например:
/devices/erd4yamka/controls/temp_indoor/on 8.00
/devices/erd4yamka/controls/temp_outdoor/on 6.00
Старая версия при получении этих сообщений записывала данные в непосредственный контрол, например
/devices/erd4yamka/controls/temp_indoor 8.00
/devices/erd4yamka/controls/temp_outdoor 6.00
cells: {
'working on battery' : {
type : "switch",
value : false,
readonly : true
},
А теперь содержание соответсвующих mqtt топиков:
/devices/power_status/controls/working on battery 0
/devices/power_status/controls/working on battery/meta/type switch
/devices/power_status/controls/working on battery/meta/order 2 /devices/power_status/controls/working on battery/meta/writable 1
Ну как вы его тестировали?
Как сырое изделие в продакшн смеете запускать?
Обмен - да, хранение - нет. MQTT - не база данных. retained значения - просто удобный способ получать последние значения каналов с датчиками. Именно такая задача стояла перед разработчиками MQTT и именно так относятся к retained-значениям разработчики брокеров.
Когда-то мы хранили настройки в retained-топиках MQTT. Этот подход показал себя очень плохо: это ненадёжно, это плохо работает с синхронизацией между брокерами, плохо работает при пропадании питания, тяжело использовать из скриптов и из средств управления конфигурацией.
Поэтому последние несколько лет мы избавляемся от всех настроек и состояния в MQTT. Именно следуя этой логике, в новом wb-rules сохраняется в собственной БД, например, значение виртуальных контролов виртуальных девайсов, которое записали снаружи.
Что касается конкретно случая, который обсуждаем сейчас, т.е. создания топиков по описанию виртуального устройства - то так работал весь наш софт с момента основания. По локальной конфигурации соответствующего сервиса в MQTT создаются устройства и каналы, за которые отвечает этот сервис.
это ошибка, исправим
про это я не очень понял. Нет никаких данных старой программы, есть топики, которые вы создавали снаружи вручную.
Пожалуйста выложите полный пример кода правила сюда с описанием того, как воспроизводить проблему.
Я понимаю ваше негодование, но решению проблемы помогает максимально полная информация, а не особо эмоциональные выражения.
про это я не очень понял. Нет никаких данных старой программы, есть топики, которые вы создавали снаружи вручную.
Тем не менее wb-rules хранит данные этих топиков в своей БД и после перезагрузки отображает их, а не то что установлено при инициализации в js-скриптах.
версия 1.7 хранит это, видимо в
/mnt/data/var/lib/wirenboard/wbrules-vcells.db
А версия 2.2 в
/mnt/data/var/lib/wirenboard/wbrules-vdev.db
Пожалуйста выложите полный пример кода правила сюда с описанием того, как воспроизводить проблему.
Пожалуйста - простенький код для тестирования ситуации:
В старой версии движка я наблюдаю как меняется значение контрола , а также сообщение о новом значении в консоли отладки.
В новой версии - ни того ни другого.
ЕЩЕ ОДИН КОСЯК
Я понимаю ваше негодование, но решению проблемы помогает максимально полная информация, а не особо эмоциональные выражения.
А может просто уберете эту сырейшую новую версию из основного репозитария?
Как вас еще убедить - не издеваться над покупателями?
В приведённом вами примере неправильно выставлено поле value - должно быть значение типа bool, а у вас указан string. Это изменение логики описано здесь.
wb-rules 2.2.3 не лучше. после обновления не все скрипты работают корректно, например, не включаются реле, отсылка команды идет, реле не включается. откат на версию 1.7.1 исправляет этот баг.
Господа, когда поправите wb-rules
Добрый день! Мы не сможем “поправить” wb-rules, пока вы не поможете нам понять, что именно и как именно у вас не работает.
Пожалуйста приложите скрипты, покажите место, которое работает некорректно, по вашему мнению. Можно воспрольоваться функций log(), чтобы примерно найти место, где что-то не так.
Скрипты работают! не включаются устройства из скрипта, которые на шине данных или ввода/вывода.
Банально пример скрипт теплого пола:
defineVirtualDevice("heat-pol", {
title: "Heat pol",
cells: {
temp: { type : "range", value : 10, max : 30,},
}
});
defineRule("heater_floor", { //название правила, может быть произвольным
whenChanged: [ "wb-m1w2_43/External Sensor 1", "heat-pol/temp"], //при изменении состояния датчика 1-Wire
then: function (newValue, devName, cellName) { //выполняй следующие действия
if ( dev["wb-m1w2_4"]["External Sensor 1"] < dev["heat-pol"]["temp"] ) { //если температура датчика больше заданной
dev["wb-gpio"]["EXT2_R3A1"] = 1;
} else if ( dev["wb-m1w2_4"]["External Sensor 1"] > dev["heat-pol"]["temp"] ) {
dev["wb-gpio"]["EXT2_R3A1"] = 1;
}
}
});
Если вместо dev[“wb-gpio”][“EXT2_R3A1”] прописать вирутальный выключатель, виртуальный выключатель работать будет, а реле, подключеное к шине данных или как ввода/вывода не работает.