November 30th, 2018

Зачем использовать мое решение, а не Arduino?

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

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

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

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

Однако, здесь есть ряд проблем, которые на первых шагах не заметны:
1) Нам нужно найти решение, которое будет хранить нашу статистику и позволять как-то с ней работать, а если захочется реализовать удаленный доступ к управлению?
2) Если Ардуин несколько, как они будут взаимодействовать? Особенно на расстояниях в несколько метров. Используем дополнительные платы расширения а с ними что, разрабатываем протокол? Все еще простая задача? Не забываем, что нужно учесть кучу проблем взаимодействия, что если данные не дошли к примеру?
3) А если все на одной Ардуино? Хорошо, а у вас получится обвязать несколько портов управления с одновременным опросом датчиков и других элементов системы? А организовать интерфейс во внешний мир и корректную выгрузку данных скажем в БД и тому подобное? Кстати этот-же вопрос актуален и для первого пункта.
Вот тут уже большие сомнения в простоте решения таких задач.
4) Ну хорошо, возьмем миникомпьютер, что-то типа RaspberryPi. Дружим его с Ардуино и все замечательно, решаем кучу проблем, пишем на чем угодно, пусть даже на Go или PHP, или вообще BASH скрипты используем. Достаточно простая задача для программиста. Стоп, нам нужны программисты... причем постоянно, в каждом изменении решения нам нужен будет программист, ну и схемотехник вероятно. В общем берем двоих в штат....

Разрешите откланяться...

Основные функции сервера

Мое решение позволяет работать с контроллером напрямую (через клиента).
Кроме этого есть сервер предоставляющий облачное решение.

Здесь описан функционал именно сервера, много другого функционала будет описано при рассмотрении остальных узлов системы.

1) Сбор статистики с возможностью выгрузки с агрегацией за час, день, неделю и детальной за любой период
2) Передача команд контроллеру, далее конечным устройствам, с гарантией доставки данных и таймаутом. Реализован механизм обратной связи клиента - вы всегда будете знать выполнена ваша команда или нет.
3) Лог истории действий над исполнительным устройством, а также API для его выгрузки.
4) Хранение проекта с поддержкой версионности (частичная реализация), здесь же механизмы оффлайн редактирования проекта с защитой от одновременного редактирования несколькими пользователями и полноценного информирования.
5) Обеспечение связи всех узлов, узлы могут быть в локальной сети(за натом). Никаких статических внешних IP и настроек NAT не требуется. Также гарантируется передача информации между узлами без задержек за исключением действительных проблем с сетью.
6) Кроме механизмов передачи команд контроллеру и показаний клиенту реализован механизм заявок как мгновенных (синхронных) так и без ожидания ответа (асинхронных), в том числе и односторонних.
7) Возможность изменения 'на лету' некоторых данных проекта, не существенных для контроллера, например название исполнительного устройства.
8) Механизмы взаимодействия клиента с сервером не зависят от состояния контроллера. К примеру, настройки проекта активируются даже если контроллер в данный момент недоступен.
9) Возможность привязки к проекту локаций другого проекта.
10) Поддержка неограниченного количества пользоваетелей  с одновременным использованием устройств и функционала.
11) Разграничение доступов как на уровне локаций так и на уровне конечных устройств.
12) Профили пользователей, полный функционал - смена паролей, подтверждение email, ФИО, контактные данные и т.п.
13) Поддержка сценариев как независимого функционала от проекта, пользователь может иметь доступ к сценариям не имея доступа к редактированию проекта, в том числе когда проект кем-то редактируется.
14) Поддержка сторонних сервисов, таких как Алиса, Telegram и SMS(частичная реализация)
15) На базе п.6, возможность организации моста между клиентом и контроллером(далее интерфейсом конечного устройства - к примеру моста TCP/IP c хоста клиента в интерфейс RS232 конечного устройства)
16) Широкие возможности информирования, в клиент, email, Telegram, SMS(частичная реализация)
17) Наблюдение за доступностью узлов - возможность информирования при потери связи с контроллером и т.п.
18) Много языковая поддержка(частичная реализация).
19) Вся служебная информация хранится в виде словарей, которая обновляется налету и не требует обновления контроллера или клиента. Т.е. обновлять эти узлы необходимо только в случае значительных изменений функционала узла, такие изменения, как ввод новых устройств в систему обновления не требуют.

При этом обращаю внимание, что проект постоянно дорабатывается, т.е. функционал постоянно растет по мере необходимости.