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

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

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

 

Уважаемый @DIYMan,

Да ладно.
Берем точность до минуты. Два байта, - часы и минуты.
В году 365 дней по два байта начала и два байта окончание.
Итого 365 на 4 пока 14460 байт.
Шьем в ПЗУ и просто оттуда читаем.
Контроллер не носится с теплицей по всему свету!
Можно прессануть, совместить байты, ну или подобную фигню.
А для народа при прошивке просим указать локацию, для правильной прошивки.
Как-то так.

 

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

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

 

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

 

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

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

Проблема дала о себе знать, когда появился модуль освещенности - показания с него тоже захотелось хранить в структуре состояний, а для этого - добавить туда ещё 4 байта. И эти 4 байта размножатся до 4*N, где N - кол-во программных модулей, прошитых в систему.

Вот эти помидоры для меня сейчас - главные, т. к. рушат всю красоту. Эстет, блин.

 

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

З. Ы. Опять не высплюсь, вернее, даже не лягу - вставать через полтора часа уже. Ну ничего, прорвёмся.

 

Нашел уже готовую таблицу (да простит меня автор данного творения) https://yadi.sk/d/yhu-6ZC9oG5Em
Все подробно расписано, самое главное это привязка к координатам. т. к. я Магнитогорске, кто то в Москве, а кто то может быть и с Сахалина.

 

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

 

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

 

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

 

Может быть, но RS-485 уже есть в наличии Строго говоря, любая подобная связка - всё равно кучу работы и тестирования, и я ещё как следует не настроился ни на CAN, ни на RS-485. Вот даже не уверен - надо ли это нам, ради пары метров лишних проводов? Мне бы интересно было понять - насколько велики погрешности на той же I2C, если провод сделать метров пять. Если мы войдём в допустимый диапазон - то и смысла городить огород с несколькими МК в сети - нет, мне кажется. Поскольку это усложняет разработку в несколько, как минимум, раз.

 

То есть в результате надо будет всё равно табличку с продолжительностью светового дня на год, как я понял?

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

Пока какие-то такие мысли, ещё полу-сумбур в голове - устаю на работе, не до программирования особо. Но досветку делать надо, конечно.

2All, между делом: а кто сможет проверить, как ведёт себя датчик освещённости, вынесенный на проводах длиной метра три-четыре? Хочу понять - вступать в болото под названием "локальная сеть из МК", или ну его нафик? Очень бы не хотелось первый вариант, если честно - больно большой объём ответственности для одного

 

нет, зачем оно нам ? какая нам разница сколько длится реальный световой день. У нас есть (изложенные кем-то выше) параметры по освещению: это длина светового дня и минимальный поток света, делаем эти параметры настраиваемыми пользователем. Сам пользователь задает световой день (например с 5 утра до 21 вечера, что составляет 16 часов) и задает минимальную освещенность. Если освещенность в это время ниже -> включается досветка, освещение поднялось (естественное от солнца) -> досветку выключаем, естественно датчик должен находится вне зоны действия ламп досветки. В итоге по мере того как световой день будет увеличиваться (с весны к лету) досветка будет включаться реже, когда световой день будет сокращаться (с лета к осени -> позже светлеет, раньше темнеет) досветка будет работать дольше, обеспечивая освещение как задал пользователь (в нашем варианте с 5 до 21).
По сути это работа по таймеру с проверкой хватает ли нам естественного освещения, если да то не включаем лампы, если нет то включаем до тех пор пока не посветлеет.

 

@2mike, по поводу CAN: вот такие драйвера подойдут?

http://ru.aliexpress.com/item/MCP2515-CAN-Bus-Module-Board-TJA1050-Receiver-SPI-For-51-MCU-ARM-Controller-NEW/32522595390.html?spm=2114.30010708.3.2.qz5hmd&ws_ab_test=searchweb201556_3,searchweb201644_2_505_506_503_504_301_502_10001_10002_10016_10017_10010_10005_10011_10006_10012_10003_10004_401_10009_10007_10008,searchweb201560_5,searchweb1451318400_-1,searchweb1451318411_6450&btsid=e555d277-ea4f-4a84-90f7-cddcc1de5bf2

 

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

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

В общем - как быть с переменной облачностью, если мы всё-таки решим отталкиваться от уровня освещённости?