Графики IH Pro



  • @Erik:

    отправил.

    На момент отправки уже успел включиться насос.

    Корректно отображались насос и клапан санузла.

    Клапаны кухни и комнаты - не корректно.

    Кухня - с "предсказанием", "комната" - без.

    Спасибо, получили. Будем разбираться



  • @intrapro:

    @Erik:

    отправил.

    На момент отправки уже успел включиться насос.

    Корректно отображались насос и клапан санузла.

    Клапаны кухни и комнаты - не корректно.

    Кухня - с "предсказанием", "комната" - без.

    Спасибо, получили. Будем разбираться

    Кухня это ACTORA22?



  • Кухня - ACTORA22

    Комната - ACTORA10

    Санузел - ACTORA34

    Насос - ACTORA72



  • @Erik:

    Кухня - ACTORA22

    Комната - ACTORA10

    Санузел - ACTORA34

    Насос - ACTORA72

    Спасибо. Причину нашли, исправление будет в ближайшей версии.



  • И снова сбой графиков.

    Совпал с пропаданием связи на 2 минуты - с 16.10 до 16.12, и перезагрузкой контроллера (без этого модбас не работал)

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

    Графики на самом контроллере показывают фактическую ситуацию. Котел не включался.

    При этом, отображение состояния теплого пола вернется к действительности после включения/выключения актуаторов, а вот отображение состояния электрокотла будет ждать вашего патча, видимо. Т.к. я его включать не планирую.

    Может есть способ вернуть его в нашу реальность?



  • И кроме этого, есть у меня такой скрипт, который шлет на е-майл оповещения о включении/выключении электрокотла

    Так он мне дважды, в 16.11 и в 16.25 прислал е-майл, что электрокотел вЫключен.

    Почему он на графиках то включен?

    Откуда такая разная информация в одной системе при типовых ситуациях - пропадании связи и перезагрузке контроллера?



  • @Erik:

    И кроме этого, есть у меня такой скрипт, который шлет на е-майл оповещения о включении/выключении электрокотла

    Так он мне дважды, в 16.11 и в 16.25 прислал е-майл, что электрокотел вЫключен.

    Почему он на графиках то включен?

    Откуда такая разная информация в одной системе при типовых ситуациях - пропадании связи и перезагрузке контроллера?

    В timeline неверно отрабатывается ошибка устройства, именно в этом проблема.

    У Вас на актуаторах есть флаг ошибки при потере связи? А таймлайн ошибку обрабатывает неверно.

    Исправим это в ближайшем релизе.



  • @intrapro:

    @homa:

    Не для всех счетчиков создался параметр uptoMonth, сегодня заводил новые и обратил внимание. Если дописать руками - то начинает работать. По тем, где uptomonth изначально был - проверил по графикам показания - они действительно далеко не на 1е число.

    Проверим. Время до момента uptoMonth у нас еще есть 🙂

    Добрый день!

    Момент снова настал и uptomonth снова не обновился))



  • @homa:

    Добрый день!

    Момент снова настал и uptomonth снова не обновился))

    Пофиксили, но версию выпустить не успели 😞



  • Добрый день. Сделал новый график с двумя кривыми. Главное отличие от остальных - датчики опрашиваются 2 раза в секунду, в БД пишутся по изменению. Период отображения - сутки. Главная проблема в том, что при переходе на этот график страница iH виснет, процессор на клиентском нетбуке 100%, ОЗУ на на максимум тоже. Можно как-то оптимизировать отрисовку графиков?



  • @Alex_Jet:

    Добрый день. Сделал новый график с двумя кривыми. Главное отличие от остальных - датчики опрашиваются 2 раза в секунду, в БД пишутся по изменению. Период отображения - сутки. Главная проблема в том, что при переходе на этот график страница iH виснет, процессор на клиентском нетбуке 100%, ОЗУ на на максимум тоже. Можно как-то оптимизировать отрисовку графиков?

    А какой смысл записывать в базу 2 раза в секунду? Что за датчики?

    Если боитесь потерять всплески, можно сделать по другому.

    Специально для таких целей есть механизм записи в базу данных: min/max

    Этот механизм позволяет записывать в базу 2 значения (минимальное и максимальное) за период. Для датчиков температуры или влажности достаточно установить период в 60 сек.

    Таким образом можно существенно уменьшить размер базы данных и соответственно увеличить скорость отображения на графиках.

    И при этом не потерять выбросы показаний датчика.

    Примерный расчет показывает:

    Если 2 раза в секунду: 26060*24= 172800 точек за сутки.

    Если min/max в минуту: 26024= 2880 точек за сутки.

    Оптимизация 😉



  • @intrahouse:

    А какой смысл записывать в базу 2 раза в секунду? Что за датчики?

    Если боитесь потерять всплески, можно сделать по другому.

    Специально для таких целей есть механизм записи в базу данных: min/max

    Этот механизм позволяет записывать в базу 2 значения (минимальное и максимальное) за период. Для датчиков температуры или влажности достаточно установить период в 60 сек.

    Таким образом можно существенно уменьшить размер базы данных и соответственно увеличить скорость отображения на графиках.

    И при этом не потерять выбросы показаний датчика.

    Примерный расчет показывает:

    Если 2 раза в секунду: 26060*24= 172800 точек за сутки.

    Если min/max в минуту: 26024= 2880 точек за сутки.

    Оптимизация 😉

    Да я все понимаю. Но задача - некоторое время измерять напряжение на клеммах MegaD… чтобы не пропустить момент пришлось установить период 0,5 секунд...



  • @Alex_Jet:

    Да я все понимаю. Но задача - некоторое время измерять напряжение на клеммах MegaD… чтобы не пропустить момент пришлось установить период 0,5 секунд...

    Понятно. Попробуйте min/max. Как раз в этом случае может помочь.
    @Alex_Jet:

    Можно как-то оптимизировать отрисовку графиков?

    Что понимать под оптимизацией? Мы этим занимались достаточно долго. Кроме как уменьшение количества отображаемых точек, ничего другого нет. Ведь графики отображает не специальная программа, а браузер. Возможно в будущем попробуем на WebGL или аналогичном движке.



  • @intrahouse:

    Что понимать под оптимизацией? Мы этим занимались достаточно долго. Кроме как уменьшение количества отображаемых точек, ничего другого нет. Ведь графики отображает не специальная программа, а браузер. Возможно в будущем попробуем на WebGL или аналогичном движке.

    Я понимаю так - при большом масштабе отбрасывание части подобных значений. При меньшем масштабе - отрбрасывание меньшей части подобных значений. Ну и при самом малом масштабе показ всех значений.



  • @intrahouse:

    @Alex_Jet:

    Да я все понимаю. Но задача - некоторое время измерять напряжение на клеммах MegaD… чтобы не пропустить момент пришлось установить период 0,5 секунд...

    Понятно. Попробуйте min/max. Как раз в этом случае может помочь.
    @Alex_Jet:

    Можно как-то оптимизировать отрисовку графиков?

    Что понимать под оптимизацией? Мы этим занимались достаточно долго. Кроме как уменьшение количества отображаемых точек, ничего другого нет. Ведь графики отображает не специальная программа, а браузер. Возможно в будущем попробуем на WebGL или аналогичном движке.

    А нельзя переложить расчет точек графика на сервер?



  • Для графиков ставились такие задачи:

    1. Динамическое отображение в режиме реального времени. То есть получение новой точки не перезагружает график, а только сдвигает его по оси X.

    2. Возможность плавной прокрутки графика вдоль оси X. Опять же без перезагрузки данных, плавно.

    3. Плавное масштабирование.

    4. Уменьшение объема хранимой информации в БД. То есть место на диске.

    @Alex_Jet:

    Я понимаю так - при большом масштабе отбрасывание части подобных значений. При меньшем масштабе - отрбрасывание меньшей части подобных значений. Ну и при самом малом масштабе показ всех значений.

    То есть при изменении масштаба запрашивать сервер на перерасчет и обновлять график с новыми данными.

    Таким образом убиваем первые три пункта задачи.
    @homa:

    А нельзя переложить расчет точек графика на сервер?

    На клиенте никакого расчета нет. Там только отображение того что получено с сервера.



  • @intrahouse:

    Для графиков ставились такие задачи:

    1. Динамическое отображение в режиме реального времени. То есть получение новой точки не перезагружает график, а только сдвигает его по оси X.

    2. Возможность плавной прокрутки графика вдоль оси X. Опять же без перезагрузки данных, плавно.

    3. Плавное масштабирование.

    4. Уменьшение объема хранимой информации в БД. То есть место на диске.

    @Alex_Jet:

    Я понимаю так - при большом масштабе отбрасывание части подобных значений. При меньшем масштабе - отрбрасывание меньшей части подобных значений. Ну и при самом малом масштабе показ всех значений.

    То есть при изменении масштаба запрашивать сервер на перерасчет и обновлять график с новыми данными.

    Таким образом убиваем первые три пункта задачи.
    @homa:

    А нельзя переложить расчет точек графика на сервер?

    На клиенте никакого расчета нет. Там только отображение того что получено с сервера.

    Понятно, тем не менее достаточно долго формируется график на клиенте, особенно на слабых планшетах, но не критично) с графиками все равно удобнее работать с ПК



  • Интересное совпадение по теме.

    Телеграмм на днях объявил конкурс на разработку библиотеки для графиков с призовым фондом $125000



  • У меня дома из "рабочих" остался только нетбук Acer с Win7, планшет тоже не новый - на них все тяжело ворочается, а график с множеством точек просто загоняет процессор и ОЗУ в красную зону, браузер предалагает закрыть страницу. Поэтому анализирую данные только на работе 😄 на мощном ноутбуке… Дома, как вариант, просмотреть графики на смартфоне...он явно мощнее домашних железок.



  • Ну а по поводу min/max.

    Это не решает задачи обнаружения всплесков?


Авторизуйтесь, чтобы ответить