Спасибо, он вышел уже на связь. Но я имел ввиду, то как быть со скриптом до попадания правок в релиз?
Нашёл способ обойти проблему до выхода исправления - он проверен на стенде с вашей версией.
Причина в том, как создаются служебные каналы. В universal_heating.js вызовы createDeviceChannel для h{}tempSensorOneErrorRule, h{}tempSensorOneErrorTimer, h{}tempSensorTwoErrorRule и h{}tempSensorTwoErrorTimer (строки 137–143) передают последним аргументом lazyInit = true. Канал с этим флагом не создаётся в MQTT до тех пор, пока в него впервые не запишут значение, а записываются эти каналы только при аварии датчика температуры. В обычной работе они существуют только внутри движка правил, и при перезагрузке файла движок пытается снять канал, которого в брокере нет - на этом и происходит зависание.
Предлагаю в этих четырёх вызовах поменять последний аргумент с true на false.
Лучше делать это при остановленномдвижке wb-rules.
Внесите, пожалуйста, правку и напишите, ушло ли зависание при сохранении - если да, до выхода исправления можно будет работать без перезапусков.
Спасибо, попробую. Хотя, это несколько ломает логику обработки.
Другой вопрос: а как вообще возможно понять, что в конкретный релиз testing или stable вошли ранее заявленные доработки? Или обратная ситуация, как понять, на какой стадии находятся доработки: ожидание, разработка, реализация, один из релизов и т.п.?
Список изменений релиза, который сейчас в ветке testing (wb-2609): wb-2609 changelog - там по каждому пакету видно, с какой версии на какую он обновился и что именно изменилось.
Только, получается, что по каждому обращению, по которому ожидаются доработки, необходимо руками это все выбирать. Может быть, можно как-то реализовать связь обращений пользователей с сформированными багрепортами и их включением в релизы, чтобы пользователям наглядно было это видно?
Исходя из моих обращений за последний год, около десятка доработок уже были вроде как реализованы, что-то - в процессе. И на сегодня уже не очень-то и вспомнить, что инициировалось год назад и, главное, в каком оно в итоге статусе и где.
Когда по обращению вносится исправление, мы пишем об этом в ту же тему на портале, где было обращение: «изменения внесены, можно проверять». То есть уведомление приходит туда же, где вы описывали проблему, и ходить за ним никуда не требуется. По этой теме я так и сделаю, когда исправление дойдёт до вашей ветки.
Отдельного уведомления о том, что исправление перешло из ветки testing в stable, у нас нет — это происходит в рамках релизного цикла. Увидеть это можно в списке изменений релиза: https://wirenboard.com/statics/release-changelogs/<имя_релиза>/changelog.html, где имя релиза берётся из cat /etc/wb-release.
Но в данном случае багрепорт уже закрыт и пока оставляем тему открытой. Когда в стабильный релиз попадет исправленная протестированная версия - вам отпишусь.