Диковатый глюк в wb-rules

Программное обеспечение Rule Engine
1

Вдогонку к этой теме. Странное (но это не точно) поведение mosquitto bridge - #8 от пользователя cu6apum

Представим себе на одном контроллере (мастере) тумблер, который при помощи whenChanged включает или выключает поле RUN (тип switch) в виртуальном устройстве. Это устройство через бридж отображается на виртуальное устройство на другом ВБ (слейве). По изменению значения этого контрола слейв щелкает своим реле.

Тык вот. Когда тумблер на мастере переключается, то в обеих копиях виртуального устройства ползунок-switch включается и выключается как надо. Правило на слейве отрабатывает (пишет в лог строку). А реле - НЕТ, ибо в его адрес не летит никакой телеграммы!!!

Если ЖЕ я щелкаю не тумблером на мастере, а в вебальнике мышой (неважно, на мастере или слейве), то в очереди штатно появляется телеграмма /devices/mwac_1/K1/on 1 и реле срабатывает как нужно.

Я ли тут набредил? Если да, то как?!!?!?!?!

2

Дополнение.
Если я дергаю физическим тумблером, на слейв прилетает /devices/vdev/controls/run 1
Если дергаю ползунок на вебальнике, то:
/devices/vdev/controls/run/on 1
/devices/vdev/controls/run 1

Вероятно, разница в этом. Почему - я опросил все звёзды и луну, но ответа не получил. Как пришпандрючить /on к топику через рули?

И почему правило на слейве - СРАБАТЫВАЕТ, но не включает реле?! Как такое технически возможно?!

3

Идентичная проблема, оказывается, тут уже обсуждалась.

Как решили?
Я выкрутился лобовой атакой, заменив dev[]=true на publish(“/devices/vdev/controls/run/on”, “1”)

Вообще такие волчьи ямы документировать бы надо…

4

Завел вопросы на гите, вы уж извиняйте.

5

Это фича, а не баг. wb-rules является владельцем виртуального устройства, а /on-топик предназначен для передачи сотояния сервису-владельцу устройства.
Иначе всё будет ещё сложнее.

Соответствующую документацию напишем.

6

Можно хотя бы первичное понимание, как безопасно обходить эту фичу? И логику того, что правило срабатывает, а безусловно прописанная в нем команда - не срабатывает.

7

Похоже, нельзя. Жаль.

8

Здравствуйте!

А можете минимальный пример правила для теста прислать? Ведь, как я понимаю, это и без бриджа можно протестировать? Публикуем вручную топик, имитируя полученный с другого контроллера, и смотрим как выполняется правило.

9

Ви таки не поверите.

Мастер (стоп, но старт такой же):

defineRule("remote_pump_stop", {
  asSoonAs: function () {
    return !dev["tcp-10-118-21-42-20108_wb-mwac_74"]["S2"] 
  },
  then: function () {
    log.info("stopping pump");
//    dev["well6_pump1"]["run"] = false;
    publish("/devices/well6_pump1/controls/run/on", "0", 2, true)
  }
});

Слейв:

defineRule("pump_run", {
  whenChanged: "PUMP1/run",
  then: function (newValue) {
    log.info("starting pump", newValue);
    dev["ttyrs485-1_wb-mwac_49/K2"] = newValue;
  }
});

Вот log.info в предпоследней строчке срабатывает, а К2 - хрен. Я минут с полчаса проходил онлайн разные психиатрические тесты, прежде чем вдуплил сделать publish вместо assign…

10

Вообще, конечно, надо бросать попытки заставить это всё работать…
Два контроллера, одна и та же версия софта. На одном dev[virtdev/control] показывает значения из топика mqtt /devices/virtdev/controls/control, на другом, в том же скрипте, получаю ноль.
При этом на вебальнике всё отображается корректно.
Достало слегка.

Жаль. Если б работало, было бы удобно.

11

Не занимались?

12

Я подумал, что вот это

решило проблему. Но, видимо, проблема не решена? Тогда постараюсь проверить.

13
14

Нет, ни одну не решило. Я прикостылил ее с двух сторон: publish() на одной и trackMqtt на другой. При этом понятия, почему оно так странно глюкает, у меня не появилось, документации об опасных «фичах» также не дождался.
Учитывая, что число контроллеров у меня подползает к сотне, я вскорости премило забуду, какой именно из костылей является позвоночником и буду иметь риск одним движением всё повалить. Это не работа.

Уже предлагал в личной беседе заплатить вам денег, чтоб сесть и сделать уже нормально. Ответа предсказуемо не последовало. Жаль.

15

Да пишется новая, “хорошая” версия wb-rules.
Насчет бага:
На мастере и на слейве надо глянуть в топик, то есть mosquitto_sub …/PUMP1/#
Подозреваю - что-то с типом, ну и строку с логом дополнить

log.info("starting pump", newValue, typeof(newValue));

А то может там не булево а строка.

16

Я бы хотел понимать, когда. Вся автоматизация второй год держится на десятках костылей в разных местах и все равно падает.
Пока я в статусе энтузиаста, нет смысла бесить вас каждую неделю. Если же делаем договор, появляется таймлайн и обязательства по его исполнению.

17

Я не понимаю, как поверх бриджа передается тип. Вероятно, ваш демон - тоже не понимает, см. пост выше про разное поведение идентичных скриптов на идентичной версии софта.

18

В топике устройства есть type параметр. Вот им-то, значением и определяется тип. Но я сам при настройке межсистемного" взаимодействия - забиваю половину кода проверками. Не надеюсь. Так что typeof возвращает?

19

О!!! Еще любопытственнее! Ничего.
Не в смысле undef, а в лог вывода теперь нету. Если typeof() убрать, в лог ВЫВОДИТ, но релейкой не щелкает. Шайтан.
При этом на вебальнике слейва переключатель в виртустройстве переключается как ни в чем не бывало.

20

Так-так. А если отдельной строкой?
То есть

log.info("starting pump", newValue, typeof(newValue));
log.info("starting pump typeof", typeof(newValue));
log.info("starting pump control_0");

и после строки, которая включает реле

log.info("starting pump control_1");

ну и что выводит на слейве

journalctl -u wb-rules -f