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

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

@DIYMan, подскажите, как мне вытащить в свою переменную значения датчиков (температура, влажность), положение окна?
Потому как я долго буду раскапывать OneState* os = m->State.GetStateByOrder (state,stateIdx); и WriteLogLine (hhmm,moduleName,stateType,sensorIdx,*os);
Спасибо

 

Куда вытащить, зачем вытащить? Что именно вы хотите сделать? И где - в прошивке, в конфигураторе, вебморде?

 

Сори, что не уточнил. Подключил вторую ESP, создал новый модуль, нужно для этой ESP выдрать значения с датчиков.

 

Куда вы подключили ESP? К той же меге? и что вы хотите в итоге получить? Не совсем понятно, что вам нужно конкретно.

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

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

Но в целом - я пока не понимаю, для чего именно вам всё это нужно. Вполне возможно, что можно обойтись уже реализованным функционалом в части команд, поддерживаемых контроллером: ESP работает, по сути, как мост TCP-UART, и через него можно отправлять любые команды, понятные контроллеру, и получать на них ответ, например - послав CTGET=0|STAT - получим слепок состояния контроллера.

Почитайте WIKI проекта, там есть чуть: https://github.com/Porokhnya/GreenhouseProject/wiki

 

Да, подключил к той же меге, смысл подключать esp куда-то еще
"и что вы хотите в итоге получить" - в итоге я хочу, чтобы esp8266 посылала нужный мне запрос на нужный ip (в частности сервер thingspeak). Дабы показания теплички было видно из интернета, а не только из локальной сети путем поднятия веб-сервера.
Судя по вашим словам, мне нужно как раз "State у модуля, зарегистрированного в системе. ". Спасибо, покопаюсь в ZeroStreamListener. Все датчики мне конечно не нужны, повыбираю нужные.

 

Не могу отредактировать предыдущий пост, поэтому пишу тут.
@DIYMan, спасибо за подсказку. нашел функцию void ZeroStreamListener: PrintSensorsValues которая выдирает данные датчиков.
На первом этапе, для упрощения задачи пропишу нужный мне датчик вручную.
Синтаксис вызова функции такой: PrintSensorsValues (tempCount,StateTemperature,mod,pStream);
В принципе я могу скопировать и изменить оригинальную PrintSensorsValues чтобы она возвращала значение не в outStream, а в нужную переменную, или вообще делала return.
Тогда возникает вопрос по поводу аргументов, пересылаемых функции:
- totalCount - количество датчиков одного типа. В принципе это число мне понятно.
- wantedState - что хотим получить (Температуру, влажность, прочее). Тут вроде тоже более-менее понятно.
- module - Тут вопрос: номер (допустим модуля температуры) постоянен (и после перепрошивки контроллера)?
-outStream - куда функция возвращает значение.

Подскажите, я в правильном направлении двигаюсь? Это вроде самое простое решение.
В идеале я хочу получить такое:
T_in = PrintSensorsValues (count = 1, state = temp, module =3)
Hum_in = PrintSensorsValues (count = 1, state = humidity, module =4)
Light_in = PrintSensorsValues (count = 1, state = light, module =5)
Далее я склеиваю нужную мне строчку с запросом и шлю в мой ESP8266 (который висит на Serial3). В итоге получаю такую штуку как на картинке

 

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

Смотрите принцип, как работает система - есть модули, у каждого модуля есть символьное имя, например, "HUMIDITY", у каждого модуля есть State, который содержит данные по датчикам и их показания. Любой модуль системы может запросить MainController->GetModuleByID - и получить указатель на модуль системы, если такой есть. После этого можно ковыряться в его State, получая показания с датчиков.

В принципе, я планировал в будущем ввести поддержку отсыла данных на ThingSpeak, но пока через GSM-модем. Если написать этот модуль так, чтобы он мог работать и с модулем Wi-Fi, и с модулем SMS (в них тоже допилить нужные функции), то необходимости в подключении второй ESP просто не будет - ибо незачем.

Я буду писать поддержку ThingSpeak, но - позже.

 

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

По этому поводу руководствуюсь такой информацией:

С прошлого года что-то изменилось в плане настройки esp?

 

Надо пробовать, вот что я скажу. Естественно, я сходу не помню, можно ли на ESP коннектиться на внешний IP, если она уже настроена как точка доступа и подконнекчена к роутеру - надо читать доку по ней. Но теоретически ничего не мешает юзать одну и ту же ESP, просто переинициализируя её на то или другое, при необходимости.

Вопрос многогранный, со второй ESP всё решается гораздо проще, конечно. Именно поэтому я хотел начать внедрение поддержки ThingSpeak именно с GSM-модема - там GPRS независимо, модем, по сути, бОльшую часть времени спит. Ну и на этом добре откатать архитектуру, именно поэтому советую вам не спешить

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

1. Каждый модуль, умеющий отправлять данные куда-то извне - должен предоставлять по запросу примерно такой интерфейс (требуется допиливание класса AbstractModule):

Тот, кто хочет отослать данные во внешний шлюз - может сделать следующее:

1. Собрать данные и поместить их в структуру известного всем формата;
2. Пробежаться по всем модулям систем, запросить каждый на поддержку отправки данных во внешний шлюз (if (module->IsExternalGateSupported()
3. Отправить данные через внешний шлюз:

Естественно, надо разрешить вопросы именования внешних шлюзов, чтобы уметь понимать - куда отправилось. По факту получим следующее: если не удалось отправить через ESP - попытка отправить через GSM-модем и т. п., т. е. - полное резервное дублирование. При этом внешние шлюзы подключаются просто имплементацией SendDataToExternalGate в нужном модуле, и если мы в дальнейшем захотим отправлять данные на thingSpeak через W5100 - то легко это допишем.

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

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

 

Короче, архитектуру продумывать надо, и сильно надо. Потому как сейчас подумалось: мы работаем всё равно через потоки (Stream*), и надо просто событийный интерфейс для моста во внешний мир, типа:

1. Попросить отправить данные;
2. По готовности к отправке попросить записать данные;
3. По записи данных попросить вернуть статус;

Что-то типа этого. Я подумаю, и буду потихоньку набрасывать интерфейс, чтобы можно было в дальнейшем легко расширить и на народный мониторинг, например. Конечно, с резервным дублированием отсылки через разные шлюзы.

 

Через 2 недели снова улетаю в командировку на полтора месяца, поэтому хочу до этого момента получить результат для теплички. Так что спешу из-за этого.

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

Код:

//Прочитать данные с датчика температуры
AbstractModule* mod = MainController->GetModuleByID(F("STATE"));
   OneState* os = mod->State.GetState(StateTemperature,1);
   sensorData = *os;
   sensorData += os->GetUnit();
   T=sensorData.c_str();

Пока только в коде, потестирую на железе вечером. Это позволит в короткие сроки понять, нужно ли это вообще.
Вам же предлагаю не спешить, и внедрять поддержку как и задумывали, начиная с модема. Одно дело у меня - своя локальная теплица, где я могу вообще выкинуть половину ненужного кода и всё будет работать. То ли изменять оригинальный код на github
Спасибо за помощь!

 

Та пока не за что Короче - я уже зарегился на ThingSpeak и сделал тестовый канал, буду потихоньку продумывать архитектуру, возможно - успеем за две недели Особенно, если для первой версии сделать настройки жёстко прошитыми в прошивку, без всякого секаса с конфигуратором

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

Потерпите чуть-чуть буквально.

 

Как-то не очень секьюрно получается, особенно еспешку высовывать наружу. Не проще, лучше, скрипт на роутере, и мегу с проблемой памяти не трогаем, и получаем веб-сервер и iptables, vpn и гпио питание дергать, а?
Роутер малина и прочее подобное все понадежнее еспешки
ЗЫ и прошивку можно залить, и камеру повесить

 

@Shelllonn, вообще не проще..., еще и излишне. ESP я за вечер сделаю, а все барахло с роутером (его еще найти нужно) поболее времени займет.
Да и не понял я фразы про " не очень секьюрно получается, особенно еспешку высовывать наружу". С чего вдруг она наружу высовывается? сидит себе в домашней сетке на 192.168.1.* и никого не трогает.

 

А домашняя сетка оптикой запитывается? циской?