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

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

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

 

Вот это пойдёт, для макетирования: http://ru.aliexpress.com/item/10-x-M74HC595B1R-74HC595-8-Bit-Shift-Register-74HC595N-DIP-16/32345911359.html?spm=2114.30010708.3.1.ddOIWq&ws_ab_test=searchweb201556_7,searchweb201602_3_301_10034_10033_507_10032_508_10020_10017_10005_10006_10021_10022_401_10007_10018_10019,searchweb201603_2&btsid=a29d692b-ada9-4e89-895d-7237241dda2b

?

 

Вместо такого:
pinMode (LAMP_RELAYS,OUTPUT);
digitalWrite (LAMP_RELAYS,RELAY_OFF);

Должно быть
SetPin (LAMP_RELAYS,RELAY_OFF, REFRESH);

А в нем либо старый код, либо запись в массив для сдвигового регистра:
SHIFT[PIN_NO]=NEW_VALUE
if (REFRESH) { SHIFT_UPDATE()}

Последнее - чтобы можно было в цикле выставить много значений и отправить в сдвиговый регистр за один раз, командой SHIFT_UPDATE();

 

Всё, ушёл корёжить архитектуру прошивки, чтобы на будущее для сдвиговых регистров было проще подключить поддержку.

 

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

 

Конечно подойдет.
Кстати, не пожалейте пин на Latch.
Не нужен нам дребезг на реле при записи цепочки в регистр.

 

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

 

Эммм. А те реле, которые стоят на шилдах - не потянут что ли? Открыть картинку любого шилда с али и посмотреть, какие там реле стоят. Надо, чтобы на 10А было - это точно, что знаю

 

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

При этом старая версия работает как и прежде - всё разруливается директивами условной компиляции.

Код для актуальной записи в сдвиговый регистр не писал, кому вдруг срочно надо - в файле TempSensors. cpp есть функция WriteToShiftRegister - там есть указание, в каком месте вставить кусок кода для актуальной записи.

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

1. Закрытая коробочка, куда подводится отдельное питание;
2. Все входы от меги - оптоизолированы;
3. От меги - 3 входа, для работы через сдвиговый регистр;
4. 16 реле на борту, для руления 8 форточками;
5. Возможность соединять шилды в каскад через сдвиговые регистры (т.е. пробрасывать байт данных дальше). Как это реализовать железно - х. з., но в прошивке у меня нет ограничений на кол-во форточек, следовательно, если их будет 16 - то в шилд один за другим уйдут 4 байта, в каждом из которых - данные для одного сдвигового регистра;
6. Идеально - проброс питания от одного шилда к другому, чтобы, запитав только первый шилд мощным БП и подключив второй (при необходимости) - имели на втором питание.

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

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

Всё правильно изложил?

 

Вот что на али нашел http://ru.aliexpress.com/item/Free-Shipping-NEW-Relay-SRA-05VDC-CL-DIP5-feet-Black-20A-5V-RELAYS-SRA-05VDC/32440562926.html?aff_platform=aaf&aff_trace_key=88fa0febac8f4306b29555d6d62c532b-1460116150867-09189-fUzv3NvZ3&sk=fUzv3NvZ3%3A&cpt=1460116150867&af=cc

 

Только не знаю точно, контакты нормально открыты или закрыты.

 

Обычно такие стоят, они ещё и подешевле:

http://ru.aliexpress.com/item/10PCS-RELAY-5V-SRD-5VDC-SL-C-T73-5V-SONGLE-Power-Relay-NEW-GOOD-QUALITY/32444108945.html?spm=2114.30010708.3.29.qiNPe3&ws_ab_test=searchweb201556_7,searchweb201602_3_301_10034_10033_507_10032_508_10020_10017_10005_10006_10021_10022_401_10007_10018_10019,searchweb201603_2&btsid=754b6af4-69b8-4827-9e63-065927a13c54

 

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

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

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

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

 

Вот идея, для вброса: http://imarh.ru/content/%D0%B1%D0%B5%D1%81%D0%BF%D1%80%D0%BE%D0%B2%D0%BE%D0%B4%D0%BD%D1%8B%D0%B5-%D0%B4%D0%B0%D1%82%D1%87%D0%B8%D0%BA%D0%B8-%D1%82%D0%B5%D0%BC%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D1%83%D1%80%D1%8B-%D0%B4%D0%BB%D1%8F-narodmonru-arduino-pro-mini-nrf24l01

 

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

1. Настраиваемый интервал между опросами (задаётся в прошивке к датчику);
2. Вид пакета, отсылаемого по радио - меняется в зависимости от типа датчика;
3. Каждый датчик имеет свой уникальный адрес.

Теперь давайте пройдёмся по структуре пакета:

1 байт - адрес датчика;
1 байт - тип передаваемых показаний;
1 байт - длина передаваемых показаний;
n байт - показания;
1 байт - контрольная сумма (CRC8, думаю, будет достаточно).

Типы передаваемых показаний:

1 - температура с DS18B20;
2 - температура с влажностью с любых датчиков влажности (например, Si7021);
3 - влажность почвы;
4 - освещённость.
далее - резерв на будущее.

Длины пакетов для разных типов датчиков:

1 - 2 байта;
2 - 4 байта;
3 - 2 байта;
4 - 4 байта.

Итого, при самой жирной конфигурации, пакет у нас будет занимать 1+1+1+4+1 - 8 байт. Что совсем немного, согласитесь.

Остаётся вопрос выбора МК, который будет на стороне беспроводных датчиков. Понятное дело, что чем меньше он жрёт, тем лучше. Однако, для целей универсальности и повторяемости желательно применить такой МК, в который влезет прошивка и для работы по 1-Wire, и для опроса DHT-22, и для опроса Si7021, и для опроса BH1750. Естественно, не всё вместе, а в зависимости от типа датчика.

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

В итоге, на стороне меги, будет висеть радиомодуль и слушать эфир: поймал байты, проанализировал, что за пакет, проверил контрольную сумму, и:

1. Если пришла температура с DS18B20 - пихнул её в новый датчик для модуля STATE;
2. Если пришла влажность - пихнул её в новый датчик для модуля HUMIDITY.
3. и т. п.

При таком раскладе можно и комбинировать - провод/беспровод. С написанием прошивки под выбранный МК могу и помочь, правда - удалённо пока.

Други, давайте пропедалируем эту крайне интереснейшую тему