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

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

Пруф косяков китайцев:

Функция, которая вызывается после того, как данные отправлены, вызывается, видимо, из прерывания:

Код:

static void ICACHE_FLASH_ATTR
at_tcpclient_sent_cb(void *arg)
{
// вырезал не относящееся к делу
   uart0_sendStr("\r\nSEND OK\r\n");
}

Функция, которая отсылает пришедшие по воздуху данные в UART, то есть в порт Меги, в нашем случае:

Код:

void ICACHE_FLASH_ATTR
at_tcpclient_recv(void *arg, char *pdata, unsigned short len)
{
  if(at_ipMux)
  {
    os_sprintf(temp, "\r\n+IPD,%d,%d:",
               linkTemp->linkId, len);
  // печатаем строку, что данные пришли
    uart0_sendStr(temp);
// печатаем сам пакет данных
    uart0_tx_buffer(pdata, len);
  }
  at_backOk;
}

Где вы тут видите проверку на синхронность? В момент, когда данные в UART ещё выплёвываются, внезапно случается вызов функции at_tcpclient_sent_cb и прямо посреди нашего пакета данных начинает красоваться гордое "SEND OK"

Ну не дэбилы? Ну одной очередью на вывод решается ведь! Если данные пришли, но мы перед этим отослали чего-то там в эфир - не выплёвывай SEND OK, положи в корзину, выплюнешь, когда пакет с данными выплюнется в порт, и всё!

Не знаю, готов ли я переписывать всё это хозяйство, или проще с нуля написать...

 

Правка: спасибо, гляну.

 

Ага, ребята, по ходу, прошарили проблему:

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

 

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

Ещё раз спасибо.

 

Дмитрий, Вы писали, что ждете ESP-07.
У меня в 07 прошивка АТ 0.40 (если правильно понял, та же что и в Вашем ESP-01).
Вот здесь https://esp8266.ru/forum/threads/variant-proshivki-at-esp8266ru-na-novyx-sdk-dlja-modulej-s-512k-flas есть вариант АТ 0.60.
М. б. будет полезна такая информация?

 

От БП 24/1А работает прекрасно.

 

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

Кстати, прошивка ESP transparent bridge (даже форкнул её на гитхабе) написана очень просто, и на самом деле в чистом виде нам не подходит, т. к. плюёт всем клиентам то, что получено из порта UART, т. е. не делает различий - каких данных ждёт клиент. Но за основу взять можно, да.

 

В общем, принимаю волевое решение: будем писать свою прошивку для ESP, но - чуть позже, когда устаканим прошивку для Меги и я допишу вебморду в первом приближении. Прошивку будем делать наподобие AT, т. е. обмен командами между ESP и Мегой - в текстовом режиме, там много команд не надо поддерживать, в принципе.

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

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

Если есть среди читающих программисты - приглашаю к сотрудничеству в написании прошивки под ESP. Если нет - нет, значит нет, ничего страшного.

Тем временем, прошу всех, у кого есть ESP с официальной AT-прошивкой версии 0.40 - протестировать прошивку для меги в части стабильности работы с модулем ESP. Но, предупреждаю честно - ничего не гарантирую, т. к. работать с китайским соевым программным фаршем - то ещё удовольствие.

Так что пока вай-фай через ESP - чуть-чуть игрушка, и останется таковой на момент окончания написания функционала для Меги.

З. Ы. Собираю пожелания к модулю ведения логов. Что нужно сохранять, в каком формате, через какие промежутки времени? Пишите, надо эту тему начать, пока датчики влажности новые ещё не пришли.

 

Обновил на гитхабе, добавил функционал в вебморду - при загрузке страницы автоматически получается значение датчиков температуры и влажности, а также состояние досветки. Уже можно чуть-чуть поуправлять - вкл/выкл досветку.

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

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

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

 

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

 

Наткнулся на такой сайт. Конторка занимается автоматизацией. http://old.isagraf.ru/novosti/reshenie-npo-avtomatika-na-vistavke-zaschischenniy-grunt-rossii-2010
и такой конструктор https://glade.gnome.org/

 

Смотрите - я не могу оперировать параметрами типа "температура воздуха", "температура грунта" и т. п., т. к. система - модульная. Я могу оперировать данными, типа "Датчик номер 1 модуля с именем таким-то, тип показания - температура, показания - такие-то, время замера - такое-то". Могу пробежать все модули и опросить состояния всех модулей, получив значения с любых датчиков, которые поддерживает система, вне зависимости от того - какие модули включены в прошивку.

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

Вот, скажем: раз в 15 минут - это нормально? Естественно, время опроса можно будет настраивать из конфигуратора, и тут возникает ещё один вопрос - настраивать только общее время или указывать, какой модуль опрашивать через сколько времени (например, модуль контроля фрамуг (там датчики температуры) - опрашиваем раз в 10 минут, модуль влажности - раз в 20 минут и т. п.).

Если исходить из времени опроса в 15 минут и кол-ве модулей, пусть с десяток, в каждом в среднем пусть будет аж три датчика, то получим - 30 датчиков раз в 15 минут. Один датчик может содержать два значения (например, DHT - температура и влажность), поэтому умножаем 30 на 1,5 - получаем 45 значений навскидку, по-максимуму. То есть 45 строк в файле. В сутки - 4320 строк в логе, не так много. Если взять формат строки

DD. MM. YYYY HH: MM: SS MODULE_NAME SENSOR_IDX SENSOR_TYPE SENSOR_DATA

то пускай даже 70 байт на строку (как она есть сейчас), получим 300 Кб лога в сутки, или в год - 106 мегабайт, карточки хватит ооочень надолго

Пойдёт такой подход?

 

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

 

Еще бы писать отдельно ERRORы, а при заведении пользователей. (соответственно парольной) то можно и активность писать. Типа "31.12.2051 23:59:01 Петров-Водкин Досветка Включение"

Эххх, мячты, мячты...

 

только выборку такого размера будет пол суток делать, чтоб график нарисовать. Тут уже нужен забикс с псом
Думаете осилит?
к тому что строка вроде "DD. MM. YYYY HH: MM: SS MODULE_NAME SENSOR_IDX SENSOR_TYPE SENSOR_DATA" мало информативна, нужны графики, а это уже ресурсоемко.