NEWS
Sql.0 не сохраняются данные
-
Похоже нашел причину: в настройках истории выставляю Минимальный интервал(ms) в 1000 - и все начинает работать - валит каждую секунду. Достаточно увеличить это интервал до 10 секунд (значение 10000) - и значения начинают проваливаться - пишутся нерегулярно и непредсказуемо.
Проверь пожалуйста - выставь 60000 - 1 минуту.
-
Похоже нашел причину: в настройках истории выставляю Минимальный интервал(ms) в 1000 - и все начинает работать - валит каждую секунду. Достаточно увеличить это интервал до 10 секунд (значение 10000) - и значения начинают проваливаться - пишутся нерегулярно и непредсказуемо.
Проверь пожалуйста - выставь 60000 - 1 минуту. `
Если стоит "0" то данные пишутся сразу после получения.Если стоит "10000" или "60000" то данные пишутся по истечению таймера исходя из данных в тот момент в переменной. Какие то траблы там есть, выставив "60000" данные какое то время пишутся исправно иногда проскакивают интервалы в 30сек(приходят данные в переменную).
-
А у меня, вместе с 30-секундными данными, появляются еще провалы - 30-40 МИНУТ!
График при этом выглядит просто потрясающе!
Ну и управление отоплением при такой дискретизации, конечно не построишь. `
Если не ошиваюсь у тебя данные приходят каждые 10сек, нельзя ли изменить интервал опроса modbas? В OWFS на каждый датчик можно установить свой интервал опроса. Если нет пиши все данные в базу только сократи время хранения до минимума тебе нужного. -
Интервал опроса стоит 1 сек. Изменить можно. Уже пробовал. Но у меня освещение на этом же контроллере (BC9000) - в случае увеличения интервала опроса не работает vis: нажал на элемент, фактически он отработал (свет погас, к примеру), а в форме он до следующего опроса горит.
Индивидуально у каждого объекта период опроса изменить не могу.
А то, что это явный баг, у автора нет возможности его исправить? Он еще тут бывает?
-
Уважаемый Haus!
Может я в принципе не прав и есть другое решение? Опишу свои пожелания, а вы может что и подскажете.
Про свою структуру я писал: внешний owfs-сервер для мониторинга температуры и modbus-контроллер в качестве исполнительного модуля. Мне нужно:
1. Сбор разнородных даныын из разных источников в одно место. Это работает!
2. Реализация сложных алгоритмов, в т.ч. прогнозных - на основании анализа данных за предыдущие периоды, для управления отоплением. Это работает частично - с анализом предыдущих данных пока вопрос. Хотя что-то и есть для анализа.
3. Визуализация температурных данных: несколько источников на одном графике, разный временной масштаб. Этого пока нет.
-
Уважаемый Haus!
Может я в принципе не прав и есть другое решение? Опишу свои пожелания, а вы может что и подскажете.
Про свою структуру я писал: внешний owfs-сервер для мониторинга температуры и modbus-контроллер в качестве исполнительного модуля. Мне нужно:
1. Сбор разнородных даныын из разных источников в одно место. Это работает!
2. Реализация сложных алгоритмов, в т.ч. прогнозных - на основании анализа данных за предыдущие периоды, для управления отоплением. Это работает частично - с анализом предыдущих данных пока вопрос. Хотя что-то и есть для анализа.
3. Визуализация температурных данных: несколько источников на одном графике, разный временной масштаб. Этого пока нет. `
Как временное решение данные в базу каждую минутуschedule("* * * * *", function(){ setState("javascript.0.test2"/*test2*/, (getState("modbus.0.holdingRegisters.16393_ТЕМP").val / 10)); }); -
Спасибо!
Я проверил - работает как часы ).
Отличный вариант!
Попутно подобрал параметры для классического варианта:
Минимальный интервал 1000
Только изменения - отметить
Запись неизменённых значений каждые 0
Минимальная разница с последним записанным значением = 0,5
В результате имеем записи при изменении температуры минимум на 0,5 градуса. Что меня устраивает. Вот результат:
34.5 false 2017-11-01 10:47:48.086 35 false 2017-11-01 08:42:13.806 35.5 false 2017-11-01 07:10:20.039 36 false 2017-11-01 05:42:36.986 36.5 false 2017-11-01 03:59:58.551 37 false 2017-11-01 01:51:16.586 37.5 false 2017-11-01 01:34:22.830 37 false 2017-11-01 01:04:23.098 36.5 false 2017-11-01 00:28:10.194 36 false 2017-10-31 23:53:24.717 36.5 false 2017-10-31 23:44:09.962 36 false 2017-10-31 23:37:51.404 36.5 false 2017-10-31 23:35:45.342 37 false 2017-10-31 23:33:25.658 37.5 false 2017-10-31 23:31:11.227 38 false 2017-10-31 23:30:16.509 38.6 false 2017-10-31 23:29:45.502 39.1 false 2017-10-31 23:29:11.433 39.6 false 2017-10-31 23:28:42.472Понаблюдаю еще за работой и выберу наиболее стабильный из этих вариантов.
А шедулер много системных ресурсов потребляет?
-
Попутно подобрал параметры для классического варианта:
Минимальный интервал 1000 `
Я еще летом в теме по influxdb писал про ту же проблему. Можете посмотреть. И тоже путем подбора пришел к тому, что стабильная работа идет только при секундной или меньше записи. Причем со старой версией драйвера такой проблемы нет. Поэтому и не обновляю, оставаясь на 1.3.4. Пробовал и sql с postgresql - все то же самое. Разработчики большого интереса к проблеме не проявили. Странно, что проблема не массовая, возможно люди не заморачиваются объемом хранения и оставляют секунду по умолчанию. Модбас тут совершенно ни при чем, поскольку у меня данные для базы берутся не только оттуда с теми же проблемами. Хотя и к драйверу модбаса тоже у меня немало претензий и тоже никакого интереса у разработчиков.
-
Adav, с версией драйвера sql 1.3.4. у вас работает без этих проблем, я правильно понял?
C драйвером modbus я помучился при настройке, но в работе он показал себя неплохо. Вопросов к modbus нет. `
Я использую influxdb, со старой версией работает не только на секунде. Гляньте ветку по influxdb - я там подробно описал. A sql я пробовал чисто ради интереса последнюю - с ней та же беда, старую не проверял. Подозреваю, что тут будет все то же самое. Очень похоже, что сделали какое-то новшество во всех этих драйверах одновременно. С modbus у меня есть пара проблем - есть девайс, где дискретные входы идут не подряд, с пропусками - там ошибки всегда (как я понял, драйвер по-любому считывает сразу 8), несколько устройств на одной шине не работают (точнее работают, но постоянно конфликтуют с ошибками в логах). Ни при прямом подключении на USB-485, ни через 485-Ethernet конвертер. А вообще у меня modbus устройств немало, но вот такое неудобство… Сначала хотел перенести опрос напрямую с iobroker, но после такой фигни оставил почти все как было (за исключением нескольких устройств) - опрос modbus через WB5 и уже с него на iobroker через mqtt. Это касается 485. Есть устройство с TCP modbs - тут все нормально. Но оно типовое (универсальные входы-выходы) и негде ему конфликтовать на одной 485 шине.
-
Если есть проблемы, то я очень советую создать issue на github (причём на английском)
modbus - да я его писал. Но железа у меня нет и я пользуюсь симуляторами.
sql - Apollon не понимает по русски и именно он поддерживает sql/influx/history
Я не в состоянии прочитать и ответить на 50 сообщений в день в форуме. А ещё есть telegram, whatsapp, email, facebook, github, trello.
И потом у меня работа и двое детей с женой в придачу, а ведь надо фиксить баги и добавлять новые фичи, поддерживать сайт и 2 облака, а то все пользователи разбегутся :)
-
Если есть проблемы, то я очень советую создать issue на github (причём на английском)
modbus - да я его писал. Но железа у меня нет и я пользуюсь симуляторами.
sql - Apollon не понимает по русски и именно он поддерживает sql/influx/history
Я не в состоянии прочитать и ответить на 50 сообщений в день в форуме. А ещё есть telegram, whatsapp, email, facebook, github, trello.
И потом у меня работа и двое детей с женой в придачу, а ведь надо фиксить баги и добавлять новые фичи, поддерживать сайт и 2 облака, а то все пользователи разбегутся :) `
Не воспринимайте это как претензию. Скорее как отдельные выявленные недостатки. Но даже с ними система работает очень неплохо. Шустро и стабильно. Нет никакого желания искать что-то другое. Про issue я понял. Как руки дойдут - воспользуюсь. Прямо сейчас не получится - надо вспоминать подробности. К тому же уже и так приладился…
Вообщем-то на старой версии influx прекрасно работает, и действительно эта проблема возникла после обновлений от Apollon.
С modbus эмулятором наверное можно попробовать повторить ошибку с дискретными регистрами. Попробуйте дискретные входы (или выходы) задать на эмуляторе не подряд. Скажем, адреса регистров 0,1,3,4,5,6,7,8,10 и попробовать такое считать. Понимаю, такой "бардак" с адресацией не типичен, но вот мне досталось именно такое устройство. Такое происходит только с дискретными, с input или c holding такой проблемы нет. С несколькими устройствами на шине 485, как я понимаю, с эмулятором не получится повторить. В меру моего разумения, проблема в том, что нет очереди при использовании разных драйверов на опрос разных устройств на одной 485 шине с разными ID. Вот и возникает конфликт при опросе.
-
Похоже нашел причину: в настройках истории выставляю Минимальный интервал(ms) в 1000 - и все начинает работать - валит каждую секунду. Достаточно увеличить это интервал до 10 секунд (значение 10000) - и значения начинают проваливаться - пишутся нерегулярно и непредсказуемо.https://gclub.royal-ruby888.com
-
Ровно то же самое с драйвером influxdb. Выше писал. Поэтому и использую до сих пор совсем старую версию, где такой проблемы не было. Вероятно и sql будет нормально работать на старой версии. Issue оставлял на гитхабе, результат нулевой. И провалы начинаются уже с 2 секунд и чем больше значение - тем более вероятно, что значение не сохранится.
Support us
822
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge