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

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

Старался

Именно поэтому и выбрал это время

Очевидные вещи, да. CRC в моих пакетах уже есть, к слову - с этим всё норм. А протокол сознательно был сделан простым - кто ж знал, что ты насядешь по самые помидоры

Сегодня начну потихоньку, короче

 

Такой проект вы знаете конечно. https://wifi-iot.com/p/esp8266/ они там правда все по ip адресуются

 

замечательно стыкуется с проектом Дмитрия. Внешними скриптами

 

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

 

Поподробней можно ?

 

Нет, не знаю. Но в любом случае, повторюсь ещё раз: отсылка показаний датчиков с модуля Wi-Fi на контроллер - это одно: точка доступа известна, каждый модуль коннектится к ней и складывает показания. А вот отсылка состояния контроллера с контроллера на Wi-Fi-модуль - это совершенно другое: как контроллер будет знать, куда надо отсылать? Это чёрт-те сколько дописываний кода ещё. Пока считаю, что идеальным вариантом для модулей - является использование LoRa и RS-485, модуль для датчиков по Wi-Fi - был введён чисто для эксперимента, скажем так. И уже видно, что в некоторых местах такое динамическое добавление датчиков - оставляет пробелы, взять ту же вебморду, которая при добавлении правила никак не видит эти датчики.

Короче - нельзя впихнуть невпихуемое, а тем более - смешивать концепции. В рамках одной инсталляции должны использоваться одни типы модулей: если для вас приемлемы модули датчиков по Wi-Fi - то использовать только их, предварительно настроив правила через конфигуратор. При этом крайне не рекомендуется параллельно с модулями датчиков по Wi-Fi - использовать модули датчиков по другим протоколам, ибо это может банально привести к непониманию - что к чему (требуется вдумчивая правильная настройка, когда сначала регистрируются модули с датчиками не на Wi-Fi, а потом уже - подаётся питание на Wi-Fi модули с датчиками; иначе - будет разброд и шатание).

Исполнительные модули - можно использовать на LoRa и RS-485. В целом же - я бы всё же рекомендовал, во избежание путаницы - использовать все типы модулей по одному из двух протоколов: LoRa или RS-485. Именно под это изначально всё и затачивалось.

 

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

 

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

В общем, возьму на заметку, но когда до этого дойдут руки - не знаю.

 

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

А @Shelllonn имел в виду, скорее всего, как раз такой вариант: тот проект, на который вы давали ссылку, собирает показания датчиков, а сторонний скрипт - пихает эти показания в контроллер простейшими командами вида CTSET=STATE|TEMP|индекс|показания (это как пример добавления нового датчика температуры в систему).

 

А из командной строки вебморды можно создать правило зная его индекс. он же постоянный ?

 

@evgeny1241, сейчас на ум пришёл ещё один вариант: поправить прошивку так, чтобы ничего не поломалось, а именно: при прописывании настроек прошивки указывать, что некоторые жёстко прописанные датчики - являются виртуальными, и для них просто надо добавить состояние, не добавляя опрос датчика в систему. Это, на первый взгляд - будет решением проблемы: указываете 10 датчиков температуры, в настройках пинов для них указываете, что все они являются виртуальными, и всё - такие датчики появятся в состоянии системы сразу, следовательно - вебморда будет их видеть. При этом с Wi-Fi модулей можно будет по прежнему добавлять показания датчиков в систему, и даже 20 штук - просто всё, что выше кол-ва прописанных датчиков в прошивке - видно в в вебморде (в окне добавления правила) не будет.

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

 

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

 

@evgeny1241,
Mqtt get, но у меня эта каша управляется сторонним софтом.
DIYMan, все верно.

 

@evgeny1241, по внимательному просмотру кода вебморды видно, что к сожалению - не всё так просто: списки датчиков фигурируют много где, например, для ThingSpeak.

Попробую сделать пока в лоб - убрать в окне добавления правила выпадающий список, оставив ввод индекса. С вас - тестирование

 

Но лучше от WIFI отказаться, имеет привычку в самый не подходящий момент отваливаться.