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

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

Прочитайте пару предыдущих страниц и все помете.

 

Мы экономим не ресурс, мы делаем проще работу как с датчиками, так и с модулями. Объяснять долго, но если вкратце, то, на примере стандартной работы с 1-Wire:

1. Есть два датчика на одном проводе, у каждого из них свой уникальный идентификатор. Ок, мега вычитала эти идентификаторы и поняла, что на линии два датчика. Вопрос - какому датчику какой индекс назначать? Другими словами - какой датчик будет называться "Т снаружи", а какой "Т внутри"?

2. Ок, мега тупо сохранила привязки адресов датчиков к индексам (уже память занимаем на ненужные привязки, заметьте), и пошла себе работать. Первый датчик скончался, печаль. Повесили на его место новый - а у нового адрес другой, и нет привязки ни к какому внутреннему индексу - куда с него сохранять информацию прикажете? А если на линии появилось 5 новых датчиков - чего делать?

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

И чтобы не пришлось геморроиться с заменой датчика, с перепривязкой его адреса к индексу в системе, сделано крайне просто - одна линия - один датчик DS18B20. Точно так же, как одна линия - один датчик DHT22, например (там это никого не смущает, почему-то ). И получается при таком раскладе всё предельно просто - есть датчик на линии - с него берутся показания, и пофиг на его адрес. Сломался датчик - поставили другой, и пофиг на его адрес. Линия в этом случае как раз и служит железной привязкой датчика ко внутреннему индексу в системе, не занимая ни один байт памяти. Нам пинов жалко?

Много проводов? Не согласен - их и так будет ворох, несколько витых пар беды не наделают.

Теперь по поводу универсальных модулей на шине 1-Wire - там пока ситуация точно такая же - общение с ними идёт, игнорируя адреса. То есть вы можете повесить хоть 10 модулей на одну линию, но будет - кто первым встал, того и тапки. Почему пока так сделано - я объяснял: я не вижу большого смысла экономить пины при следующем посыле: исполнительный модуль, как правило - со своим питанием, это раз. В витой паре - 8 проводов, аж на 8 исполнительных модулей, куда больше, у нас не ракета .

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

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

 

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

 

Здравствуйте, коллеги!
Работа проведена колоссальная! И ещё предстоит сделать не мало...
Когда весь проект заработает, то, на мой взгляд, необходимо озаботиться ещё некоторыми функционалами: обязательно ввести резервируемое питание + организовать систему безопасности с выдачей аварийной сигнализации (SMS, e-mail). Пожар ли, нет в ёмкостях воды для полива, пропадание питалова, несанкционированный доступ незваных "гостей" (бывает, что твой урожай "помогут" собрать без твоего ведома и участия), а кто обогревает газом, то и утечку газа тоже необходимо отследить...
Не пинайте сино ногами, и не сино кидайте камни - это взято из жизни, ибо на всё хорошее рано ли, поздно ли, будет кусок негатива, а это оч омрачает жизнь!

 

Много у нас датчиков DS18B20 планируется? В прошивке по умолчанию - всего два, для T внутри и T снаружи, беда небольшая.

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

Три провода - ок, Но два из них - общие для всех датчиков, Т. е. одна витая пара - на 6 датчиков всё равно. Мало?

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

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

Ок, я готов пересмотреть подход при одном условии: вы мне чётко распишете, как, не тратя память и не заморачиваясь с адресами на шине 1-Wire - чётко обеспечить лёгкую, прозрачную для пользователя замену датчика без перенастройки прошивки, без перерегистрации датчика в системе, без необходимости перепривязки каких-бы то ни было индексов. Возможно, я не вижу решения из-за своей зашоренности, кто знает. Как всё устроено изнутри - я вам объяснял: сейчас пин, на котором сидит датчик (мы про DS18B20 говорим, если что) - является той самой привязкой _любого_ DS18B20, висящего на этом пине, к индексу датчика в системе. Адреса при этом - не нужны от слова "вообще".

Буду признателен, если укажете путь решения.

 

Я понял, парадигма относилась к проводам.

 

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

По его адресу на шине? Ок, не вопрос. А ну как он сломался? У другого датчика - будет свой адрес, а правила у нас писаны под абстракцию "Т внутри", а не под конкретный датчик с конкретным адресом. Т. е. если датчик вышел из строя - мы должны будем редактировать правила? А с графиками чего будет, если привязывать показания к адресу датчика на шине 1-Wire?

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

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

 

Обновил на гитхабе - конфигуратор перешёл в версию 3.0, прошивка меги стала работать с исполнительными модулями, появилась прошивка самого исполнительного модуля на 8 слотов. Прошивка исполнительного модуля получилась компактной - пару килобайт, да меньше сотни байт в оперативке, так что на всякие Pro mini - со свистом, можно ещё кучу дописать туда, по желанию.

Исполнительный модуль теперь можно регистрировать на линии регистрации 1-Wire, и обновлять его настройки, при необходимости. Выглядит это добро в конфигураторе так:



Тестировал выводом в Serial - видно, что состояния пинов обновляются, так что всё обошлось малой кровью - не пришлось цеплять 8 светодиодов

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

Можно считать, что работа с 1-Wire в первом приближении сделана. Теперь всё это добро в вебморду вытащить - поиск и регистрацию универсальных модулей - и вообще будет шоколадно

Кто хочет потестировать, что это такое: берём Uno (или Nano, или Pro mini), заливаем в него прошивку отсюда: https://github.com/Porokhnya/GreenhouseProject/tree/master/UniversalExecutionModule (предварительно настроив её на нужные пины; впрочем, там уже настройка есть, так что можно ничего и не менять), потом подключаем Uno (пин 2) к линии регистрации меги (пин 28 по умолчанию, подтянут к питанию резистором на 4К7). Открываем конфигуратор, открываем окошко "Регистрация универсальных модулей", жмакаем кнопку "Поиск" и регистрируем привязки. После регистрации - перетыкаем Uno на пин 30 меги (единственная линия 1-Wire по умолчанию, для универсальных модулей), пин также подтянут к питанию резистором на 4К7, на этом - всё.

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

В общем, всё гораздо проще, чем я тут расписал

 

Прочитал про NXP 82b715 - зачётная вещь, удлинитель шины I2C до 50 м https://www.nxp.com/products/interface-and-connectivity/interface-and-system-management/isup2-supc-bus-portfolio/isup2-supc-bus-repeaters-hubs-extenders/i2c-bus-extender:P82B715PN

Цепляется элементарно. Так что теперь в загашнике есть железки для опытов новые Правда, махонькие они, зарразы.

 

- ну, наверное совсем не тратить память не получится... Но..., как Вам такой подход:
1) при прошивке универсала ему приписывается номер в системе 01, 02, и т. д. (00 - соответственно Мега)
2) при включении универсала он создает свои статусы (в соответствии с прошитыми и подключенными датчиками-релюшками), стучится в Мегу, сдает ей статус и впадает в состояние ожидания
3) Мега жует статус,
а) если датчик не зарегистрирован - регистрирует, обсасывает статус в соответствии со своим внутренним вИдением окружающего мира, если надо - корректирует, СОХРАНЯЕТ в себе и отсылает изменения или ОК универсалу
б) если зарегистрирован - сличает статус с сохраненным, если надо - корректирует, СОХРАНЯЕТ в себе и отсылает изменения или ОК универсалу
4) универсал принимает
а) ОК и впадает в спячку
б) принимает изменения, исполняет их и впадает в спячку
5) Мега с заданной периодичностью, или для изменения статусов, или в целях проверки работоспособности дергает НУЖНЫЙ ЕЙ универсал и с п. 2 по п. 4
ЗЫ. например, не вижу смысла в постоянном дергании универсала с клапаном полива, включенным на 2 часа или обработки светового датчика ночью (разве что с целью ловли воров, которые подсвечивают себе фонариком )

 

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

 

-похоже, по размеру она и в Тиньку влезет, вот только в Тиньке "логика" слегка другая... Или нет?

 

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

 

Да вроде особо ничего не добавилось космического.

 

Вы как-то всё в одну кучу смешали - модули с датчиками, исполнительные модули, модуль с дисплеем. Дёргать периодически - надо, иначе как узнаем, что модуль с датчиками отвалился? Вы не забыли, что модули могут работать на любой линии 1-Wire, нет? И в зависимости от того, какой модуль подцеплен - мега делает то или иное. Но для того, чтобы понять, что модуль есть на линии - надо его периодически дёргать.

Регистрация в системе - строго отдельно, на выделенной линии. Если подцепить незарегистрированный модуль на рабочую линию - ничего не будет работать.

"стучится в Мегу" - вы понимаете, что 1-Wire - это мастер-слейв? Что только мега может сама опросить, а не модуль, когда ему вздумается, постучаться?

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