Arduino Mega. Контроллер теплицы. Хроники

РЕКЛАМА НА ФОРУМХАУС

Написал тестовый скетч для UNO - получилось 2 литра за 5 секунд, что уже примерно похоже на заявленные максимально 30 л/минуту. Есть фактор калибровки.

У кого есть подобные датчики протока (да и вообще любой из подобного семейства) - просьба протестировать: http://ru.aliexpress.com/item/G1-2-Water-Flow-Sensor-Fluid-Flowmeter-Switch-Counter-1-30L-min-Meter-E2shopping/32617842149.html?spm=2114.30010708.3.29.gZPGaE&ws_ab_test=searchweb201556_7,searchweb201602_3_10036_10035_301_10034_507_10032_10020_10017_10005_10006_10021_10022_401_10007_10018_10019,searchweb201603_9&btsid=b9e076ab-839e-4056-ab30-4f774c25c21c

Скетч прикрепил.

 

Ещё из новостей: такой датчик будет только один (максимум 2), т. к. работает на прерываниях, а пины 2 и 3 у нас уже заняты - придётся схему немножко менять, кой-чего перетыкивать в другие пины.

Планирую ввести два типа виртуальных датчиков для этого:

1. Виртуальный датчик мгновенного расхода воды (показывает, сколько мл вылито с момента последнего замера);
2. Виртуальный датчик общего расхода воды (показывает кол-во литров, протекших через датчик с момента старта его работы; значение сохраняется в EEPROM).

Думаю, потянет такой подход. Кому нужно больше двух - звиняйте, упёрлись в аппаратные ограничения: на пинах 18 и 19 - аппаратный UART, на пинах 20 и 21 - I2C, остаются два пина - номер 2 и номер 3.

Что скажет начальник транспортного цеха?

 

Ещё такой нюанс: делать ли отдельный модуль для учёта воды, или просто в модуль полива ввести новые виртуальные датчики? Первый вариант - позволяет учитывать расход воды вне зависимости от того - есть ли модуль полива в прошивке. Второй - вроде как у нас есть модуль полива, и было бы логично юзать его по полной.

Что скажете? Надо выбрать какой-то из двух вариантов. В случае первого варианта - это ещё одна вкладка в конфигураторе будет.

 

Да, освободил два пина - 2 и 3, схему немножко перерисовал, как определимся с программной частью - выложу все обновы, пока всё по прежнему.

 

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

 

Что делать, шеф, что делать? Всё пропало, шеф! Вот и я - в непонятках пока: с одной стороны - плодить сущности, с другой - ущерб в универсальности...

 

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

 

Ай, ладно - пропади оно всё пропадом: сделаю отдельным модулем

 

Добавил поддержку датчиков учёта расхода воды, всего максимум 2, как я и говорил - на пинах 2 и 3.

Обновил конфигуратор и схему, будьте внимательны: для LCD 128x64 поменялся пин подсветки с 3-го на 5-й, для Neoway M590 - пин проверки его присутствия - со 2-го на 10-й. В остальном вроде изменений больше нет.

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

Датчики расхода воды подключаются не просто, а очень просто: первый - на пин номер 2, второй, если нужен - на пин номер 3, остальные два провода каждого датчика - питание и земля, всё. В прошивке пока используется только один, т. к. имею только один в наличии.

Как водится - в Globals. h всё настраивается - и кол-во датчиков, и присутствие этого модуля в прошивке, и интервал опроса, и калибровочный коэффициент, и настройка - через сколько литров сохранять накопленные показания в EEPROM (чтобы часто не дёргать память, паанимаишь).

Выводятся показания двух типов: мгновенный расход (с момента последнего замера), и накопленный расход - с момента пуска датчика в эксплуатацию.

В общем, пробуйте. Система всё больше и больше становится похожа на нормальную Ттт, чтоб не сглазить.

З. Ы. Хотя да - за кол-во оперативки переживаю постоянно Видимо, лично в моём случае в итоговой конфигурации каких-то модулей не будет, скорее всего - GSM как минимум: что-то по зрелому размышлению подумалось, что не особо он мне нужен. Хотя, конечно, время покажет - надо тестировать жёстко. Но, как вы сами понимаете - 2 кила свободной оперативки под всё-всё-всё - маловато остаётся: одна СМС, если приходит забитая под завязку - просит в оперативке под двести байт, плюс на раскодировку столько же - жесть, короче. Хотя - там по оптимизации ещё конь не валялся, и на крайняк - можно перевести всё на знакомые нам лыжи - работать через SD-карту

З. З. Ы. По датчикам газа - даже не знаю, припиливать их или нет: ну прогрел я его пару часов (не сутки, конечно, но всё же) - показывает он своё сопротивление, скажем, в 800 условных единиц. Оставил на часок, чтоб остыл, включил, прогрел опять полчасика - показывает сопротивление в 900 с гаком условных единиц. То есть пока я не добился устойчивого ноля (условной точки отсчёта) от датчиков. В этой ситуации вижу только один вариант: тупое срабатывание по пороговому уровню - если что-то выше чего-то - значит где-то кому-то поплохело, всё. Как с их помощью детектить CO2? Да никак, вот и весь сказ. Для этого нужен узкозаточенный, а на него у меня деньгов нету - стоит больше двух тыщ, зараза.

 

Хотел спросить, вот допустим есть на роутерах контакты uart, можно ли подключить непосредственно нашу arduino к нему, ведь мы можем получить сразу и лан порты, wi-fi, и веб морду на роутере, или я не прав?

 

Да, можно и через UART, тогда, правда, конфигуратор некуда будет к меге подоткнуть - всё через вебморду придётся делать, если что.

Смысл использовать мосты типа Wi-Fi и Ethernet прямо на меге - это вытащить контроллер подальше от роутера - UART вы сильно далеко не утащите, максимум - пару метров, кмк. Если это некритично - никто не запрещает подключить мегу по UART прямо к роутеру

Но выбор - быть должон

 

DIYMan, а какие-то манипуляции с роутером ещё придётся делать, кроме как прошить dd-wrt или openwrt,? Он сам там все находит или надо будет их подружить?

 

Естественно, придётся дружить: как минимум - написать скрипт, который дёргает или UART, или LAN, посылая туда раз в пару секунд команду CTGET=0|STAT\r\n - и складывая ответ хучь куда.

Собственно, минималка, которая нужна, помимо самой прошивки роутера - этот самый скрипт. Который шлёт команду, принимает ответ, разбирает его и складывает в БД sqlite3 - всё. Остальное - это уже вебморда.

Так что если обладаете необходимыми познаниями для написания такого скрипта - то можете накидать его костяк, поставить в cron и проверить, как оно. А с разбором ответа от меги я уже подскажу, что там и как устроено

На всякий - псевдокод (считаем, что у нас установлен пакет pySerial):

Код:

import serial
ser = serial.Serial()
ser.baudrate = 57600
ser.port = 'COM1'
ser.open()
ser.write(b'CTGET=0|STAT\r\n')
ser.flush()
answer = ser.readline()
// тут анализируем ответ
ser.close()

Вот как-то так.

 

Обычно это UART который используется для восстановления роутера после окирпичивания неудачной прошивкой. у всех ARM процев есть пины boot, комбинация уровней на которых при старте схемы позволяет грузить прошивку в камень, в том числе и через UART.
как правило это нормальный порт, но полноценный доступ может быть только из openwrt. правда я там не встречал такого но вполне может быть что просто не полностью ознакомился.

 

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