Добрый день. Использую WB-M1W2, через модуль уведомлений отслеживаю выход из разрешенного диапазона температур и отправляю соответствующие смс. Возник вопрос как быть, если датчик отключится? Возможно ли отслеживать состояние/доступность/контакт с датчиком? Какое значение получит модуль уведомлений при запросе данных с недоступного датчика?
Добрый день.
Да, возможно, подробно описано тут: Сообщение при отключении или неисправности в Telegram
Смое последнее полученное. поэтому надо проверять актуальность данных.
Попытался сделать так, как понял, видимо что-то неправильно понял с этими функциями) Подскажите как правильно оформлять запрос в error? Наткнулся на Github на то, что можно напрямую обращаться в топик (например wb-m1w2_157/External_Sensor 2#error) но это тоже не захотело работать
trackMqtt срабатывает только, если были какие-то изменения, то есть просто вывел эту функцию в отдельное правило и если “обрывается” линия, то сразу же срабатывает условие. Надеюсь я правильно всё понял, но главное, что работает)
1 лайк
Всё-таки всё не так просто оказалось. Моя задача: постоянно контролировать состояние датчиков, если происходит обрыв, то вывести это для начала хотя бы в лог. Чтобы избежать реакции на краткосрочные сбои хочу сделать задержку: Обнаружен обрыв-ждём 5 секунд-обнаружен обрыв-тревога. Использую trackMqtt, вижу “r”, запускаю таймер, использую trackMqtt, вижу “r” выставляю тревогу. Но вот в обратном направлении так не работает, если нужно отслеживать когда нет “r” функция trackMqtt не хочет выполняться второй раз.
Я так понял, мой вопрос похож на вот эту тему, но и там в итоге не разобрались как быть с meta/error в случае если нет ошибок
Функция срабатывает толко при изменении состояния.
У вас неверный, архитектурно, подход. Совершенно не нужно создавать несколько правил tarckmqtt. Достаточно одного, так как сейчас при каждом срабатывании верхнего создается новое правило (хук) и их количество увеличивается. То есть в итоге, при длительной работе когда правил (возможно) будет десятки тысяч - скорей всего сервис упадет с ошибкой.
Так точно не надо.
Там используют стороннее По в котором механизм работы немного другой.
Сейчас сделано так, мониторю состояние ошибки и сообщаю об отключении/подключении устройства. Так плохо?
(меня в этом варианте смущает случай, если провод втыкать/вытыкать с большой частотой, хотелось бы добавить задержку и повторный запрос)
Не понял про умножение правил, в каком случае это происходит?
Так - нет критичных ошибок.
Не, “повторный запрос” - точно не надо/
Посмотрите как описывается, например тут: Debounce (антидребезг) - #2 от пользователя BrainRoot
Всякий раз когда выполняется trackMqtt(" - создается новое правило (объект)
то есть это не единичный запрос топика, это создание обработчика.
наткнулся на то, что можно считывать как значение, добавив #error. Вроде, работает. Есть ли какие-то подводные камни у этого? И правильно ли я понимаю, что чтобы так считывать нужно при включении запустить хоть раз trackMqtt до …/error?
Итоговый вариант с обнулением таймера при переключении состояния для каждого датчика
UPD: глупая ошибка) сначала удалил ID потом по нему пытался сделать clear.
Остались тогда только вопросы: 1) нет ли каких-то подвохов в с моим итоговым кодом?
2) Чтобы доступ к Dev/Control#error получать обязательно прописывать при перезагрузке trackMqtt(“/…/errror”) или можно это как-то в по-умолчанию открыть?
Да, именно для единичего чтения в произвольном месте - так.
Нет, не обязательно. Вот после паузы, в обработчике SetTimeout - проверять так можно. Красиво и работает.
Нет, не нужно.
Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.