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

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

У меня еще старый советский с1-101.

 

Что бы с батарейками не парится ставим такие часы и радуемся.

 

а может сделать так, чтобы универсальные датчики сидели в режиме ожидания и экономии питашки, а контроллер сам слал им запрос (допустим, по времени из правил) и получал ответ?

 

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

 

Вопрос, дабы пока не рыться в исходниках esp-link: если подключить ESP на RX0 и TX0 меги - прошивается? Если да - то значит где-то в исходниках жёстко юзается первый Serial.

 

Без ответа не есть хорошо, можно выставить время ожидания ответа.

 

Чтобы с батарейками не париться - достаточно в DS3231 поставить аккумулятор, а не батарейку, тем более, что китайские модули из коробки как раз на аккум заточены

 

Да в принципе можно всё на данном этапе, т. к. с работа ещё работа не начиналась

 

Без ответа всегда плохо Естественно, этот вопрос ещё вентилировать и вентилировать, скорее всего, будет взвод какого-нибудь флага ожидания ответа, и его проверка спустя некоторое время. Чтобы в delay не висеть - у меня почти нигде в моём коде delay нет, за реедким некритичным исключением

 

Среднее время работы от батареи CR2032 при типичном применении в качестве беспроводного датчика - 5 лет
Средний ток потребления при приёме сообщения - 43,1 мкA
ЗЫ. какое потребление у той же attiny85 - не нашел

 

А типичная частота общения устройств друг с другом? Одно дело - сидеть в ожидании и раз в сутки чего-то там делать по запросу, другое - регулярно пинать эфир.

Понятное дело, что у nRF просто обязана быть нога с прерыванием, чтобы будить МК по приходу пакета. Тут вопрос в другом стоит: кто должен слать данные первым: беспроводные модули свои показания, или - контроллер в цикле слать в эфир пакеты с приглашением отдать данные?

 

300мкА

 

Да, поглядел бегло описание nRF24L01+ - есть там нога IRQ, то, что надо. Соответственно, проблем со спящим режимом у универсальных модулей - никаких.

Останется только подумать, как грамотно опрашивать модули из контроллера (сейчас модулям при регистрации всаживается только ID контроллера, а ID модуля нигде не сохраняется в контроллере) - и тогда можно будет пихать модули с контроллера.

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

Но тут встаёт вопрос с коллизиями в сети. Думаю, что как раз можно использовать поле скратчпада, в котором храниться уникальный ID универсального модуля, не под уникальный ID, а под настройку таймслота, когда такой модуль имеет право вещать в эфир.

И тут просыпается математика

 

У nRF это всё разруливается. подробно описано у картинок с Data pipe .

 

В общем, просмотрел бегло код, что увидел:

1. При регистрации/настройке датчика по 1-Wire ему можно назначать интервал, через который он будет слать показания, с этим всё норм;

2. Когда мы с @Snark обсуждали ситуацию с универсальными модулями, то было решено, что модуль сам - просыпается когда нужно, и плюёт в эфир пакет;

3. Менять поведение пункта 2 - не вижу смысла.

То есть универсальные модули, которые только с датчиками - будут сами слать инфу в эфир, а контроллер уже по приходу пакета будет понимать, ему этот пакет - или нет. И, соответственно, обновлять своё внутреннее состояние.

Про исполнительные универсальные модули я уже писал выше - там будет несколько по другому: и структура пакета, и, видимо, регистрация такого модуля в системе. И при работе с ними контроллер сам будет выступать инициатором общения.

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