режим отопления "ночной тариф" с погодозависимостью по прогнозу погоды

[fim]

Для всех зон - одни и те же.

Нюанс в другом - у меня ПИД не обычный

как раз у тебя я почти все понял

 

У меня используется несколько необычный алгоритм. Дело в том, что "трехточечный привод" фактически работает как интегратор (если входное воздействие это время подачи на него напряжения), поэтому ПИ-алгоритм управления у меня заменен на ПД (пропорционально-дифференциальный), при этом пропорциональная часть эквивалентна интегральной, а дифференциальная - пропорциональной в обычном варианте, интегрирование производится приводом Сейчас интегральный коэффициент 1.0, пропорциональный 2.0.

sov1178, я несколько раз читал... так и не въехал в эту игру слов

 

навел порядок с малинками в щите

после переподключения питания на 10А блок начали отваливаться датчики температуры...

проверил питание 5.6В, поправил на 5.1В - помогло, до этого переписал скрипт считывания (теперь в т.ч. с проверкой crc)

наконец-то научился калибровать датчик со2Ж-)

ооочень много потратил времени на датчики, но имхо оно того стоило, т.к. датчики - основа домашней автоматизации

т.к. теперь я понимаю поведение датчика со2, решил привести в порядок то что у меня считывает со2:) (разные кусочки на "веревочках")

нарисовал плату, без корпуса должно выглядеть примерно так (esp8266, dht22, mh-z-19, ds18b20, пины с gpio для шила реле, кнопки progr, reset (будут невысокие, доступны после разборки корпуса), калибровка со2, размер платы: 7,2 х 4,6 см)

 

 

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

кстати, тема калибровки со2 и роллет - следствие, так сказать, встречи с Dmode:)

 

зы режим "комфорт" получился довольно комфортный, даже возможно слишком, т.к. я постоянно проваливался в лень

[InSAn]

ds18b20

 

Я бы рекомендовал бы уйти от цифровых датчиков. Слишком уж они помехам подвержены. ИМХО.

 

У себя реализовал еще и программный (как я его назвал - двухуровневый) отлов помех.

 

Постоянно подсчитывается среднее арифметическое последних 20-ти измерений (раз в секунду).

Каждое следующее измерение - удаляем из массива первое значение, в конец массива добавляем новое. На выходе - среднее всего массива.

Т.о. если помеха попадет - то она исказит данные совсем не значительно.

Поступающие данные постоянно сверяем с выходной величиной (та, что средняя). Если на входе данные отличаются более, чем на 20% - считаем их недостоверными.

 

 

 

Провел эксперимент - генерировал на входе помехи. Ни одна не прошла

Вернее, те, что проходили - на итоговый результат никак не влияли.

[sov1178]

sov1178, я несколько раз читал... так и не въехал в эту игру слов

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

 

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

 

Теперь понятнее?

 

Вот если интересно все параметры регулятора:

 

Немного допилил свой скрипт который делает резервное копирование - теперь копируется база+скрипты+запаковывается в TAR архив+сжимается в bz2+загружается на FTP сервер. В итоге все (с базой за один год) занимает всего 6МБ.

[sov1178]

У себя реализовал еще и программный (как я его назвал - двухуровневый) отлов помех.

Могу предложить усовершенствование - примените медианный фильтр, случайные помехи он отсеет полностью, и скорее всего можно будет использовать меньшее кол-во замеров.

 

Еще один момент, если измерять DS18B20 температуру воздуха, то работа с частотой более одного замера в 5сек вызывает уплывание результата вверх - датчик саморазогревается. Т.е. нужно либо его приделать к чему-либо с хорошим теплообменом со средой, либо понизить частоту опроса.

 

У меня после перехода на мастер на D2482-800 ошибок нет совсем, посмотрю еще, что будет когда добавлю датчиков.

[InSAn]

Могу предложить усовершенствование - примените медианный фильтр, случайные помехи он отсеет полностью, и скорее всего можно будет использовать меньшее кол-во замеров.

 

Спасибо, почитал о нем.

Меньшее кол-во замеров точно к медианному фильтру не относится (как и скорость из-за необходимости сортировки массива), но точность его - выше.

[sov1178]

Меньшее кол-во замеров точно к медианному фильтру не относится

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

 

как и скорость из-за необходимости сортировки массива

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

[InSAn]

Запустил у себя. Немного не понравились "прыгающие" значения, добавил первую часть "своего" усреднения.

На выходе - красота

 

Добавлено через 1 минуту

PS: Разницы между 11 элементами и 21 - не заметил никакой. Наверное, остановлюсь на 7 :-D

[fim]

Я бы рекомендовал бы уйти от цифровых датчиков. Слишком уж они помехам подвержены.

32 датчика последовательно (топология "шина", т.е. в линию) опрашиваются

проверяется контрольная сумма, если она не сходится, повторный опрос, так до 5 раз

SELECT avg(SECOND(datetime)), min(SECOND(datetime)), max(SECOND(datetime)) FROM `room_tempt` WHERE datetime > '2017-12-04'

29.4345

28

34 сек

т.е. проверка crc в боьшенстве случаев проходит с первого раза

 

 

Последовательность действий при измерении температуры должна быть следующей: (с)

 

Посылаем импульс сброса и принимаем ответ термометра.

Посылаем команду Skip ROM [CCh].

Посылаем команду Convert T [44h].

Формируем задержку минимум 750мс.

Посылаем импульс сброса и принимаем ответ термометра.

Посылаем команду Skip ROM [CCh].

Посылаем команду Read Scratchpad [bEh].

Читаем данные из промежуточного ОЗУ (8 байт) и CRC.

Проверяем CRC, и если данные считаны верно, вычисляем температуру.

 

 

блин, не пойму о каких ошибках вы говорите

 

DS18B20 - подчиненное устройство, отвечающее мастеру (в моем случае малины) по шине 1wire

контрольная сумма - говорит о целосности/правильности пакета, т.е. достоверности доставленной информации с DS18B20 на мастер или что ошибки при передаче по шине не было

 

как-то мы с sov1178 уже общались на тему ошибок ds18b20...

c тех пор ничего не поменялось в моих наблюдениях во всяком случае

т.е. если мастер устойчиво видит датчик, то ошибки... блин, после проверки crc не видел, а до проверки ну может 1 на 10 000 хз

 

я писал о том, что при напряжении 5,6В мастер не устойчиво видел некоторые датчики, сделал напряжение 5,1В - все проблема исчезла

эт к тому что для малинки плохо "небольшие":) отклонения напряжения и нет возможности считывать/контролировать текущее напряжение, например, как температуру проца

[sov1178]

проверяется контрольная сумма, если она не сходится, повторный опрос, так до 5 раз

У меня так же. Причем записывается в лог любая проблема. Отдельно пишется если все пять раз были с ошибками.

 

Последовательность действий при измерении температуры должна быть следующей:

Это все делает модуль ядра (после моего "допиливания", которое уже вошло официальную Armbian), по крайней мере в моей конфигурации. Мне остается только инициировать замер температуры и потом прочитать данные.

 

блин, не пойму о каких ошибках вы говорите

Ну я не вдавался в подробности откуда ошибки, возможно CRC не проверяется, вот и ошибки будут.

 

как-то мы с sov1178 уже общались на тему ошибок ds18b20...

Да, было дело, я, когда ошибки посыпались с добавлением датчиков, перешел на нормальный мастер и нормальную топологию, и наступила гармония Ну и теоретически правильность CRC не гарантирует 100% отсутствие ошибок, хотя лично такого не наблюдал (скорее всего ввиду малого кол-ва ошибок).

 

я писал о том, что при напряжении 5,6В мастер не устойчиво видел некоторые датчики, сделал напряжение 5,1В - все проблема исчезла

А у Вас датчики от 5В питаются? У меня 3.3В питание датчиков. Я кстати не уверен, что порты у малинки 5V tolerant (точнее почти уверен, что более 3.3В на них не стоит подавать).

[fim]

У меня так же. Причем записывается в лог любая проблема. Отдельно пишется если все пять раз были с ошибками.

я так же буду писать в лог файл датчик и количество проверок, если проверок больше одной

 

Да, было дело, я, когда ошибки посыпались с добавлением датчиков, перешел на нормальный мастер и нормальную топологию, и наступила гармония

вот, если система настроена так, что датчики постоянно определяются мастером, то ошибки в передаче маловероятны

 

А у Вас датчики от 5В питаются? У меня 3.3В питание датчиков. Я кстати не уверен, что порты у малинки 5V tolerant (точнее почти уверен, что более 3.3В на них не стоит подавать).

3.3В питание датчиков

но дело имхо в работе мастера малинки, которая в свою очередь чувствительна к напряжению

 

зы датчики ds18b20 у мну самые ответственные/точные, вот например датчик со2...

 

 

т.е. выдает показания с "хорошими" скачками, каждое показание имеет свой "статус" (1, 4, 8, 16, 32, 64), может этот "статус" и есть какое-то среднее последних (1, 4, 8, 16, 32, 64 показаний) хз

датчики влажности ведут себя лучше со2, но хуже ds18, но если по влажности контролируется только верхнее значение и точка росы и там все относительно просто, то с со2... буду пробовать отбрасывать значения как вы предлагаете с InSAn

[InSAn]

"Музыкальная пауза": кто догадается - что это за график?

А я пока до вечера отлучусь

 

[fim]

"Музыкальная пауза": кто догадается - что это за график?

А я пока до вечера отлучусь

 

 

 

сигнал с марса

я всегда знал, что там есть жизнь

 

десять зон работы клапанов - голубые горизонтальные (две зоны не нуждаются в подпитке)

красная - теплоноситель

вертикальные - зоны, когда все (регулируемые объекты) могут отдыхать (например, поменялась уставка), пока хозяин не наблюдает или просто график порвало от такого набора цифр

 

а чем графики строятся? highcharts?

[sov1178]

или просто график порвало от такого набора цифр

Да ну, чего бы его рвало - данных совсем не много. Может быть это периоды "допиливания" системы автоматизации, когда она не работала по какой-либо причине.

[InSAn]

Андрей, браво! С первого раза - практически в точку!

Вертикальные зоны - работа циркуляционного насоса. Зачем ему зря работать, когда клапана закрыты?

 

А "рваный" график - все просто объясняется... Когда запускается циркуляционный насос, то в первое мгновенье нет смысла снимать температуру подачи (красная линия), т.к. "настоящая" температура в трубе будет только через минуту-две. А до этого она будет комнатной.

[InSAn]

Вот даже съем данных через две минуты после запуска циркуляционника не показывает реальную темп-ру в трубе...

[InSAn]

а чем графики строятся? highcharts?

 

Ага, в нем самом.

А у тебя?

[InSAn]

Кстати, не в курсе - как побороть неравномерность интервалов на х-оси?

 

 

от 2:00 до 3:30 - полтора часа.

Но расстояние значительно больше, чем от 3:30 до 5:00...

[sov1178]

Кстати, не в курсе - как побороть неравномерность интервалов на х-оси?

Данные задаются наверное парами (значение X, значение Y)? Значения по оси Х должны идти равномерно (в смысле в исходных данных), тогда все будет ок.

 

У себя использую другой режим где ось Х задается через pointStart и pointInterval так:

{ pointStart: $pointStart, pointInterval: $pointInterval, ....., data: { ... } }

data при этом содержит только значения по оси Y.

[InSAn]

Значения по оси Х должны идти равномерно (в смысле в исходных данных), тогда все будет ок.

Увы, я ж не могу сказать ПИД-регулятору "погоди, не включайся, твоя равномерность не наступила"

 

Добавлено через 1 минуту

Данные задаются наверное парами (значение X, значение Y)?

Да, именно так: произошло событие - записали время и значение.

[sov1178]

Увы, я ж не могу сказать ПИД-регулятору "погоди, не включайся, твоя равномерность не наступила"

Всегда можно произвести пост обработку и "заполнить" недостающие значения, чтобы по оси Х шли равномерно распределенные отсчеты либо установить значение по Y в null, тогда эта точка не будет отображена - это уже надо исходя из отображаемой величины решать. Конечно в особо неблагоприятном случае будет много "лишних" точек, но тут уже ничего не сделать.

 

По второму варианту кстати обработка прилично быстрее получается, я как-то замерял, занимался оптимизацией, чтобы на мобилке нормально отображалось, т.к. пишу много данных и графиков много (сейчас 17штук, еще 8 добавится в ближайшее время).

[InSAn]

Всегда можно произвести пост обработку и "заполнить" недостающие значения, чтобы по оси Х шли равномерно распределенные отсчеты

Не хочу усложнять систему. Вернее, даже не так. Не хочу делать пост-обработку, т.к. вероятность возникновения критической ошибки возрастает стремительными шагами

К тому же, в реал-тайм добавлять пост-обработку - не по феншую.

 

либо установить значение по Y в null, тогда эта точка не будет отображена - это уже надо исходя из отображаемой величины решать. Конечно в особо неблагоприятном случае будет много "лишних" точек, но тут уже ничего не сделать.

Или лишних, или недостающих.

 

Пусть так и остается, раз нельзя обойтись "без крови"

[fim]

Ага, в нем самом.

А у тебя?

тоже (движок Highstock)

в основе асинхронное получение seriesOptions

Кстати, не в курсе - как побороть неравномерность интервалов на х-оси?

 

 

 

 

от 2:00 до 3:30 - полтора часа.

Но расстояние значительно больше, чем от 3:30 до 5:00...

Try it

ordinal: Boolean

 

 

ordinal: Boolean

In an ordinal axis, the points are equally spaced in the chart regardless of the actual time or x distance between them. This means that missing data for nights or weekends will not take up space in the chart.

 

Defaults to true.

Try it

• True by default
  
• False
  

 

 

короче

xAxis: {       
   ordinal: false
}

 

ps всетаки перерисовал схемку датчика(ов)

вынес антеyну esp, добавил радиатор для LM1117

удобная штука эта 3dbrdviewer.cytec.bg/

 

 

Змінено 8 грудня 2017 користувачем fim

[InSAn]

тоже (движок Highstock)

 

в основе асинхронное получение seriesOptions

Я сам писал дополнение - мне стандартное не понравилось.

 

Try it

ordinal: Boolean

 

Блин, и как я не заметил эту опцию? Раз десять смотрел... Вот что значит свежий взгляд. Спасибо!

[sov1178]

Я сам писал дополнение - мне стандартное не понравилось.

Я тоже изменял стандартный вариант lazy loading т.к. он не совместим с автообновлением графиков.

 

удобная штука эта 3dbrdviewer.cytec.bg/

В KiCAD такая штука встроена в пакет

[sov1178]

можно еще в крон засунуть

ionice -c 3 fstrim -v /

 

У меня fstrim с карточкой не работает: