Есть несколько вопросов и пожеланий по реализации сценария термостата.
Вся система обновлена до последней версии testing. Настроен сценарий термостат, сам он работает отлично. Но, в истории данные по исполнительному механизму (каналу) отображаются непонятно как-то. С определенного момента все время данные “вкл“, хотя как на панели, так и физически вижу, что включается и отключается согласно времени и алгоритму ПИД (см. скрин). Никаких данных по настрйоке архивирования не менял. По остальным параметрам нет вопросов. Куда копать?
где посмотреть описание настроек (почему взяты такие начальные параметры) и математику реализации ПИД регулятора в этом сценарии?
в настройках сценария предлагаю поправить надписи. При первой настройке не сразу даже сообразил что и куда требуется прописать (см. скрин).
как будет работать и/или как подстроить ПИД регулятор, если в качестве исполнительных устройств выступает дискретный термостатичный исполнительный механизм (он открывается/закрывается полностью в течение 3 минут). В настройках ПИД вроде вкл/выкл укладывается в 1 минуту.
На скрине вижу что история отображается корректно до появления в истории данных по теплому полу лоджии. Попробуйте отследить только его и исполнительный механизм.
На данный момент только такое описание в инструкции, запишу ваше пожелание разработчикам более детально описать настройки.
Вот. вывел только исполнительный механизм (выход на реле). Первый выделенный красный квадрат - регулирование по гистерезису (у меня был написан простой алгоритм на wb-rules). Второй выделенный зеленый квадрат - настроенный сценарий регулирования по ПИД, при этом вначале работы в историю записываются все отработки вкл/выкл, а как с какого-то момента (красный овал) просто пишется “1“. Третий выделенный квадрат - изменение уставки по температуре и пока температура не упала, выход на реле = “0“, далее какие-то значения записались, а дальше снова “1”.
Сегодня еще одну странность заметил. Один из сценариев просто ночью выключился сам. Это точно не я в 3:19. Ранее тоже подмечал такую странность, но думал, что это из-за проблем с питанием, но на входе UPS скачков и пропажи не было. Как может сценарий отключится сам?
При этом сейчас еще настроен дополнительно другой сценарий и он не отключался в этот момент.
Попрошу вас зайти в конфигурационные файлы/настройки драйвера wb-mqtt-serial, поставить галочку “включить отладочные сообщения” снять и прислать архив с диагностической информацией контроллера. Создание архива описано в документации.
Галочку снять и пока наблюдать, повторяется ли ситуация, временной интервал достаточно велик как поймать данный баг пока не ясно, мы со своей стороны посмотрим.
Дополнительно опишите перечень устройств которые используются в данной сборке.
Добрый день.
Т.к. у вас testing попробуйте обновить пакеты и проверить осталась ли проблема с отображением истории.
Для этого подключитесь к контроллеру по SSH выполните поочередно команды: apt update apt upgrade reboot
Проверьте осталась ли проблема, дайте обратную связь.
Обновил, перезагрузил. Проблема с отображением исторических данных не ушла.
Ниже 2 скрина за период и что странно - в части отображения аналоговых сигналов температуры нет проблем, а вот дискретные сигналы как-то совсем не сочетаются. На графике один и тот же параметр исполнительного механизма, но один из сценария, второй канал выходной.
Справа их значения совпадают, а вот слева каждый живет своей жизнью.
И в целом при регулировании, данные снова по “1” почти на всем диапазоне (см. Справа). Может какой-то рассинхрон по времени записи идет. МОжет быть такое?
Итак, по вопросу истории подписался на два топика:
на топик выходного канала реле управления исполнительным механизмом;
на топик команды управления исполнительным механизмом настроенного сценария.
Значения меняются согласно логики сценария (см. скрины). А вот в истории этого нет! В историю заносятся значение с периодом 120 сек. При этом “1” (см. скрин). Я так понимаю настройка периода записи изменяющихся значений в настройках “Истории“ (скрин выше скидывал), должно влиять только на период записи накопившихся значений в БД, так? Или здесь логика иная?
Добрый день.
Извиняюсь за столь долгий ответ.
Будем пробовать воспроизводить, если баг то будем срочно чинить, дам ответ после проведения эксперимента. С вашей стороны если будет чем дополнить пишите пожалуйста.
“Сценарий” - просто обертка над скриптом, по сути.
Это, собственно, не та проблема из-за которой отключается. То есть для датчиков и вообще всех устройств наличие ошибок обмена - нормально. По шине постоянно идет опрос, мегабайты в час. На скриншоте видно что ошибка с d933253 возникает даже не каждый час.
А для отключения сценария - нужно чтобы ошибка длилась ощутимое время.
Вот в логах, на момент отключения контрола сценария - что было? Именно когда его, переключателя, статус сменился?
В диагностический архив это вряд ли попадет - уже прошло несколько дней.
Насколько часто воспроизводится?
Так, для диагностики истинной причины - лучше всего, по моему, подписаться на топики устройств указанных в сценарии.
Или просто из консоли в screen или правилом.
Если дадите топики - подскажу команду полностью.
Ну и про сценарий. Как писал выше - это программа. Она не может оценить насколько критично происходящее - когда возникает достаточно длительная ошибка просто прекращает выполнение.
Конечно, можно написать скрипт, снова включающий - но это, без оценки решение прямо сказать, не очень.
По проверке соединений и подключений задача понятна - перепроверю все. У меня 3 датчика сидят на одном входе (2 из 3-х бывают с ошибками чтения, один работает вообще без нареканий) и 1 датчик сидит отдельно на втором входе подключенный своим штатным кабелем (на нем также ошибки чтения проскакивают периодически).
Сценарий отключается (пропадает связь с датчиком) раз в 2-3 дня примерно.
Если ориентироваться на ошибки, которые выдает сценарий, то получается что в эти моменты более 10 сек отсутствует связь с датчиком. Откровенно говоря, у меня тут есть сомнения определенные, что связи с датчиком нет более 10 сек, хотя как неисправность полностью не исключаю данный факт.
Может быть так, что в коде скрипта таймер некорректно отрабатывает и не сбрасывается при восстановлении связи?
Где и в каком файле скрипта можно поправить данную задержку по связи и поставить например 60 сек или 5 мин?
топики:
/devices/wb-gpio/controls/EXT3_K1
/devices/wb-w1/controls/28-00000e7eb219
я так понимаю команда mosquitto_sub -v -t ‘/devices/wb-gpio/controls/EXT3_K1’ | ts такая должна быть, но она в моменте показывает фактические значения же
П.С. Чтобы не мешать темы, я могу отдельно создать тему по датчикам, а здесь оставить проблему с историческими данными.
Посмотрел, функция “createErrChangeRule” строки ~751-830 /usr/share/wb-rules-modules/thermostat.mod.js
Ошибок не вижу.
errorCheckTimeoutMs - можно задать при инициализации.
Ну и для диагностики можно включить отладку (debug) wb-rules, в функциии предусмотрел подробный вывод log.debug
Нет, вывод длится все время. Ну и целесообразно использовать mosquitto_sub -v -t ‘/devices/wb-gpio/controls/EXT3/#_K1’ | ts например чтобы видеть все подтопики.
