прочитайте статью в бз, фильтрация значений
Я знаю про эту статью, но это сложно для большинства и противоречит концепции ПУ
а если у меня датчик показывает правильно - но температура поднимается до 40 . Для меня это ужее за порогом.. И я иду смотреть что там с температурой не так ....
а если у меня датчик показывает правильно - но температура поднимается до 40 . Для меня это ужее за порогом.. И я иду смотреть что там с температурой не так ..
для этого есть порог уведомления
НО зачем отсеивать такое данное - если оно правильно ? Для м еня порог это комфортное условие проживания...
Выход значения датчика за порог тоже нормально . Если бы отсеивать все температуры выше или ниже 50 градусов. Что для основных датчиков это есть порогом измерения тогда да...
ито эо не показатель. А если у меня муфельная печь есть в доме...???
какой концепции противоречит?!
это помимо отбрасывания ложных, позволяет экономить ресурсы железа при максимальной точности
если вдумчиво перечитать и применять
тарас на печь другой фильтр
а на морозилку третий , а на гидромаса 4 и т.д. ? да ну его всю жизнь только фильтра писать. А не проще ли в контроллере проверять значение и не передавать ложные срабатывания ?
на контроллере не у всех можно, но лучше там да
а про количество, пишешь функцию и с нужными параметрами на то где что нужно
ну так Я о чем же и глаголю что это частный случай, и НЕ надо его сюда пихать. Надо нормальный датчик ставить.. Я вон из г. слепил и второй год никаких проблемм... Еще и вытяжку само включает...
и даже более того, из за такого напихано все кто может поуходили с пу
и ими некому заниматься, а кто ими пользуется просят напихать еще больше (((
на приеме данных через MQTT метод не работает, ему параметры не передаются...
это проблема конкретного модуля и он такой не один
не нужно это усугублять на все остальные
Поэтому фильтровать и надо в логике ПУ, а не зависеть от кривых модулей.
выше было мнение что фильтровать нужно на контроллере )))
но если он кривой, то ... не нужно это усугублять в пу, хотя пофиг, ушел
Логрус прав - кривое с кривым лепить гомно получится.. извените за грубость...
А мне кстати не пофиг -поскольку я пользую ПУ... Вот поэтому и говорю что кривое....
Варианта 2.
1) фильтровать в контроллере (чувствую уже было выше в переписке)
2) писать в доп. свойство, и фильтровать перед записью в основное свойство
ПУ тут по идее не при чем. В них должны передаваться уже корректные значения. Если у вас по какой либо причине прилетают некорректные - вопрос уже реально к контроллеру либо к датчику. В отлаженых системах такого по идее не должно наблюлаться.
Проблемные значения приходят и от "заводских" устройств - даже от xiaomi бывает и контроллеров котлов. Тот же apple homekit имеет такие предельные значения, например, датчик температуры.
я не против мне одинаково что ломать - но если бы понять еще как считать температуру -50 нормальной или вышедшей за порог? ну или +50....
Человек хочет, чтобы эти значения в настройки выносились. Типа не учитывать значения больше/меньше указанного.
я не против мне одинаково что ломать - но если бы понять еще как считать температуру -50 нормальной или вышедшей за порог? ну или +50....
Ну если это температура в комнате, то предельные значения, например, от +1 до +50, остальные просто отбрасываются. А то "прилетевшее" случайно неверное значение "-100" напрочь искажает график, пока это значение не устареет. Соответственно для для каждого датчика свои пределы.
А пороги для уведомлений - это просто сообщить о выходе за нормальные значения, например, в комнате стало холоднее нормы и пора закрыть окно.
Человек хочет, чтобы эти значения в настройки выносились. Типа не учитывать значения больше/меньше указанного.
Да конечно, это должно настраиваться для каждого датчика.
ну так сделай реквест к альфе на какие датчики хош границы вот и все .
Он бы не не заводил, наверное, тикет, если бы сам в состоянии был дописать существующий код.
Блин я в датчиках счас нифига не понимаю, там какие то глобальные изменения проошли... Так что даже хз чего там и как...
Ну тикет к простым устройствам. Думаю Сергей когда нить доберется.
в бз через метод это расписано
если в свойство, аналогично через промежуточное (тут же только получает с мкютт)
смысл это пихать всем? все- равно найдется кто- то с другими требованиями, а текущее желание спокойно реализуется уже сейчас своими силами
Как выше сказали - 1) это противоречит концепции ПУ, 2) Это есть в других аналогичных системах на базовом уровне. Так что почему бы и нет.
Сейчас для решения данной задачи можно использовать настройку валидации для свойств класса, так что я думаю задачу можно закрывать.
Please login to leave comments. Join us!