Что означают провалы получения данных

Добрый день!

Что означают провалы освещенности на графике? Например с 3 до 8.

Подозреваю, что “достаточно темно” и значение освещенности не меняется (но при этом должно быть близким к нулю!, но это не так), поэтому не получаются? Так работает “быстрый модбас”?
На данный момент скорость на шине 9600 (и нет никаких тормозов)
Другие данные с датчика получаются без проблем (то же движение) в это же время.
Везде стоит “опрос в порядке очереди”.
Ради эксперимента поставил опрос раз в 200мс … но не хочется и шину забивать, но и значения урны актуальные (для автоматического управления яркостью)

Добрый день.
Не очень понятно что за датчик, что именно работает не так как ожидается.
Если вопрос про период за который нет данных - то высоковероятно в это время данных не было совсем (датчик не работал, не было связи.)

WB-MSW v.4, значение освещенности (по тому же движению вопросов нет …)
Также есть вопросы по температуре, она довольно странная и меняется от 19,5 до 20,5 … даже если помещение нагреть до +27 … Но там может место неудачное все же … для температуры.

Изменения “опрашивать каждый 200мс” не помогли … остаются непонятные провалы по освещенности.

Убрать дельту с графиков нельзя?

Очень странно.
Похоже: когда выключается свет … данные перестают поступать. Более того, они не становятся околонулевыми при выключении … часто. Данные теряются. И как ориентироваться на освещенность в эти периоды? Освещенность околонулевая, а по показаниям высокая …

200 мс не помогло, вернул на “в порядке очереди”
Может это не глюк датчика, а глюк интерфейса отображения данных?

Можно, просто щелкунуть на нее в легенде, что выше графика - отключиится.

Попробую воспроизвести.

Похоже проблема не с околонулевыми значениями, а с нулевыми.
То есть, если значение становится равным нулю (выключили свет и очень темно), то оно не пишется в линию или вообще датчик не работает …
Что-то странное. (И у кого черные датчики … у того совсем все плохо может быть …)

И пока непонятно как использовать в правилах.
Требуется автоматическая подстройка яркости.
Пока приходит в голову только одно - если данные долго не приходили (как фиксировать время последнего получения тогда? хотя …, а если была перезагрузка … непонятно до конца, “долго” - это сколько), то считать яркость равной нулю.

В целом не бывает совсем совсем темно … ну и все равно должно быть что-то околонулевое прыгать (как на датчике движения, например …)

Вот сейчас вот так, то есть оно отработало и спустилось вниз (уже можно использовать последнее значение …). но нули то тоже важны! И как-то теряются …

Хотя один ноль все-таки передался …
Тогда проблема не с нулями … или все же с нулями?

Получается так.
Гасится свет.
Датчик освещенности уходит в ноль или вообще в перегрузку (так как в соседних помещениях свет в целом есть и его капелька хоть как-то проникает … и видно, что околонулевые колебания при этом иногда существуют) и не передает данные.

Странно что движение не нулевое …

Добрался до воспроизведения. Какой сериный номер у датчика и какая в нем прошивка?

Версия прошивки 4.31.11

Серийный номер 144393

И кстати, а почему он с такой странной периодичностью опрашивается?

По непонятным причинам перестают данные по освещенности просто передаваться. Но другие данные от этого же датчика поступают …

Чаще всего когда данные околонулевые. Но вот … когда были не нулевые тоже встречается, но редко и пропадает на меньший период …
Как свет подстраивать под эти данные пока не очень понятно …

При этом датчик иногда может вдруг вспомнить, что пропускал данные по освещенности и передавать их много сразу и текущие …

Интересное “средство измерения” освещенности, конечно …
Устал, и перестал отдавать данные.
И непонятно куда копать …

Откуда такие скачки яркости? Фонариком никто не светил. Из окна свет не попадает (если только совсем сбоку и ближе к вечеру (когда в принципе не бывает яркого Солнца)
Лампа стоит диммером на 85 процентах и в целом это соответствует по датчику 180 … (кстати вопрос, а в чем он меряет, если посчитать на калькуляторе, то яркость должна быть около 1800 (то есть в 10 раз больше), но может неправильно считаю … но яркость достаточная и по формулам лампы ставились с запасом и на яркость 1800 …)

200 - да, если лампы и Солнце … ну 220 … 400 откуда?

Лампа может давать и больше.
Как пример:


Я воспроизвел:

Да, при низких значениях освещенности (предположительно) быстрый Modbus не передает изменения, пока разбираюсь.

Очень редкие очень странные скачки - это подозрительно.
Но это момент не критичен, и не срочный, проанализирую позже …
Пока впечатление, что в момент включения через диммер (с 50 до 85 процентов) очень странные скачки, иногда, не всегда и подозрительно …

Да вот тоже думал, что только при низких …
Но есть примеры, когда не только при низких (но очень редко и не так продолжительно)

И есть пример, когда данные прямо очень очень часто передаются …

Пока основное из моих предположений (но WB я знаю пока достаточно плохо) - работа быстрого модбаса. Или это связано с обновлениями контроллера последними и/или предпоследними. Или это связано с механизмом измерения: проблема с нулевыми и околонулевыми значениями.

Или проблема когда очень маленькая дельта (то есть: если сигнал в подряд измерениях поменялся незначительно, то просто данные не передаются… То есть:

0 - не передается
0.1 - не передается
0.2 (разница 0.1) - не передается
0.3 (разница 0.1) - не передается
0.2 (разница 0.1) - не передается
50 - передается
50.1 - не передается

В общем непонятны условия. но глюк явный …

Также думаю как это обрабатывать и по другим каналам и вообще всегда. То есть, уверенности в данных WB - они могут пропадать. Нужно учитывать возможную пропажу данных (как при глюках, так и при неисправностях и/или помехах или еще чем-то) в алгоритмах …

И вот это тоже странно.
Но другие данные, которые мало меняются или вообще не меняются - передаются.

Включил debug для wb-mqtt-serial - опрашивается с установленной.
Как раз тут проблем нету.
Для проверки вчера сделал

//11_20_test_04.js
var sensorDev = "wb-msw-v4_170/Illuminance";

defineRule("devValueToLog", {
    whenChanged: sensorDev,
    then: function (newValue, devName, cellName) {
        log.info("devValueToLog", devName, newValue)
    }
});

и вижу в логах записи. Проверьте тоже у себя, запустите скрипт. Что-то мне кажется что история не пишет, какое, кстати, значение стоит у вас для “Минимальный интервал записи, если значение не изменилось (с)”?

Включил. Понаблюдаю.
Но по точкам на графике видно, что обычно же опрашивается нормально, а только в периоды (не очень понятные пока) - пауза / не передает.

А как вы определили? Он же “ни с того ни с сего” перестает получать данные …

И все больше прихожу к мнению, что влияет дельта изменений. Если дельта меньше какого-то значения (от предыдущего, а не от последнего переданного!!! ← в этом и проблема), то данные не передаются.
И, скорее всего, это алгоритм быстрого модбаса (он же должен оценивать изменение, чтобы передать).

А так в темноте дельта обычно минимальна - то и проблема …

Плюс: ошибка нуля. Если значение с любого, вдруг стало нулевым (или ноль плюс та самая дельта), то тоже не передается.

Но это предположения, на основе предположений алгоритма внутри датчика с моими познаниями микроконтроллеров и программирования (то есть, у вас все может быть не так)

С завода. Я вообще мало что менял пока. Еще изучаю и разбираюсь …
Поставить что-нибудь определенное?