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

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

Секундочку, шилд - это то что участвует в ардуиновом "бутерброде". Отдельная коробочка - это не шилд! Что все же делаем?

Вот нарисовал шилд (именно шилд) для реле. Дополнительное питание ему не нужно - он замыкает-размыкает внешние источники. Да, дорожки между реле и разъемами будут много шире сигнальных.
Реле поставил абстрактные, под точную модель реле - будем подгонять.
Прицепил управление на первые попавшиеся ножки ардуины. Выбирайте правильные.

 

Ок, я неправильно выразился. Шилд - точно не нужен, нужна отдельная коробочка, подключаемая к контроллеру по трём проводам.

 

Думаю, это сейчас неактуально, т. к. по идее, было бы классно - если бы на этой отдельной плате были бы колодки для подключения сигнала с пинов, плюс - контактные площадки, чтобы можно было подпаяться.

Но, повторюсь, шилд - не надо. Это не выживет в реальных условиях эксплуатации. Плюс - нафига нам наводки от индуктивности? Лучше вынести это физически в отдельную, развязанную по питанию и управлению коробушку, и всё. Я так думаю (с).

 

Тогда давайте в эту коробочку и attiny засунем. Она обеспечит надежный протокол (ну, скажем - OneWire) а то и RF возможности.

 

Эээх, знал бы, как нарисовать, чтобы было понятно всем (а не только мне) - я бы нарисовал

 

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

 

Или всё-таки подумать стоит? Всё-таки RF для управления - тоже гуд.

 

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

В случае с беспроводными датчиками мне уже более-менее всё понятно - там данные гоняются в одну сторону. В случае же с исполнительными устройствами - надо думать. Я не против пихнуть в каждую коробочку по дешёвому МК, мне надо понять - каким образом мы всё это подружим. Ведь сейчас получается следующее: грубо говоря, поддержка сдвиговых регистров есть, осталось только прикрутить несколько строчек кода - и сможем управлять реле не по 8, а по 3-м пинам. Но это - опять провод. То есть если в случае с реле управления форточками надо ещё и беспроводное управление - значит, надо кроить архитектуру прошивки.

Давайте думать в этом направлении. Идеально было бы: выплюнули в какой-нибудь шлюз команду с указанием, кому оно надо, и забыли. Остальные проблемы - решать по ходу.

В общем, вам пока виднее. Поэтому давайте отталкиваться от следующего:

1. Проводное управление на плате с реле - есть, через сдвиговые регистры, по входящим трём проводам.

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

 

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

Ушёл сильно думать.

 

Я думаю это всё делается без особых хлопот.
1. ставим attiny
2. на одни пины ему приходит всё что идет от хоста на регистры сдвига.
3. на другие от RF модуля (nrf24 & etc)
4. соответственно входная последовательность выдается транзитом на выходные пины attiny к регистру или декодируется и опять таки выдается в регистры.
5. всё что пришло от хоста
а) пишется во флеш attiny
б) выдается на исполнение далее в регистры
в) выдается на передачу в RF модуль (для подтверждения хосту)
Как то так. вполне прозрачно и хост наверное даже не будет заморачиваться чем да как оно до конечного устройства доставлено.

 

Нет нет. Я пока тупо сделаю RF датчик влажности земли. Я думать пока не готов.

Подумайте еще о том, что команда "запустить двигатель закрывания форточки" по RF может пройти, а команда "Остановить двигатель" - нет. Можно поломать форточку)

 

Поддерживаю.
Тинька стоит 50 рублей, а гибкости, во всем теле, добъемся невероятной.

 

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

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

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

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

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

 

И да, в указанном мной формате пакета вижу один недостаток: там надо не адрес датчика в 1 байт, а его уникальный номер, в 4 байта. Чтобы никогда и ни при каких условиях добавленный в систему беспроводной датчик не конфликтовал с другими - вернее, чтобы на момент разбора приходящих от датчика данных мега точно знала, что такой датчик в системе точно уникален.

 

Неееее, устраивание выносных измерений это как почта - куда/кому. т. е. надо как то тогда всю адресацию в проекте делать однообразно.
Так что наверное правильнее говорить о адресате от которого приходят показания.
0 - уровень хоста, датчики подключенные напрямки к меге.
1/2/3/4.../7 - № выноса с которого идут показания
а какие показания и с какого именно датчика тоже надо продумывать, т. е. делать однообразно, учитывая категорический отказ от процедуры инициализации и прописывания датчиков в текущем проекте.