Project WebMaster

Project WebMaster

Попробовать (Захостил сервер я у себя локально, и работает он не 24/7)

1. Описание продукта
2. Фичи
3. Направления развития
4. Недостатки

Пункт 1 – описание
ProjectWebMaster - это платформа для сбора, обработки, хранения данных с микроконтроллера, которая предоставляет настраиваемый интерфейс отображения данных, которая также позволяет управлять микроконтроллером. Проект состоит из сервера и клиента. Серверная часть написана на PHP. Клиент присоединяется к серверу по http.

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

Код (C++):

Webmaster.connect_open();
Webmaster.add_var(“Название переменной”, Значение переменной);
Webmaster.send();
// А получить ответ можно так:
String answer=Webmaster.receive_answer();

Такая архитектура взаимодействия помогает абстрагироваться от технических тонкостей реализации, сосредоточившись на решении непосредственных задач.

На сервере же вы можете выводить информацию в интерфейс, записывать ее в базу данных, строить графики(пункт 3), словом, вы можете все, что могут предложить современные технологии. И тут мы плавно подходим к пункту 3.

Пункт 3 – направления развития

На данный момент итоговый дистрибутив находится в состоянии «ProofofConcept», доказательство концепции, которая состоит в том, что можно удобно управлять микроконтроллером со «взрослого» сервера через Интернет.

Выделю наиболее интересные и перспективные направления развития:
1) Разработка графического интерфейса программирования сервера для пользователей
2) Разработка механизма, позволяющего грамотно отслеживать ход времени, и выполнять инструкции по временным условиям
3) Разработка функционала библиотеки, позволяющего программировать ардуино непосредственно из веб интерфейса
4) Разработка системы визуализации информации (графики, графы, таблицы, и прочее)
На данный момент среди оформленных идей это пока что все.

Пункт 4 – недостатки
Как ни крути, но для функционирования серверного функционала необходим компьютер с полноценной ОС. Будь то RaspberriPi, облачный сервер или локальный компьютер у вас дома.

Также, на данный момент, осуществление взаимодействия между сервером и клиентом осуществляется с помощью Ethernet Shield на базе чипа W5100.

P.S. Вообще, я планировал сделать анонс чуть попозже, но так сложилось, что дражайшие родственники привели в негодность мой Ethernetshield, в связи с чем у меня нет возможности заниматься разработкой дальше. Этой публикацией я хочу найти человека, который заинтересуется изложенными возможностями, и будет готов внести «железный вклад» в развитие проекта. Под железным вкладом я подразумеваю наличие платы arduino и Ethernetшилда, подключенных к локальной сети, а также доступ к железкам для меня (Teamviewer), чтобы я мог вживую отлаживать происходящее.

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

С удовольствием выслушаю мысли сообщества по поводу вышеизложенного, с уважением Vetrinus.

 

Интерфейс, с неработающими, в силу отсутствия железа, данными, находится здесь, можете посмотреть.
UPD.Опять же, не стоит воспринимать то, что можно там увидеть чем-то более, чем сделанным за пару минут интерфейсом

 

Вопрос: в чём плюсы по сравнению с https://ru.wikipedia.org/wiki/MQTT и паттерном "брокер-подписчики" ?

 

Если сравнивать реализацию по HTTP, то из плюсов только простота реализации.
В планах заменить протокол общения. Когда рассматривал варианты, видел mqtt и websocket.
Склоняюсь к websocket, поскольку можно обнаруживать факт разрыва соединения по событию, и назначить обработчик.
в MQTT же издатель вообще не знает о существовании подписчика, что делает проверку на "живость" соединения делом рук разработчика. И далеко не факт, что реализация будет оптимальной.

 

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

 

Вы случаем тёплое с круглым не путаете? MQTT - это протокол, а Wwbsocket - это транспорт. MQTT может работать как через вебсокеты, так и по TCP/IP, без изысков, что называется.

А зачем издателю знать про подписчиков - поясните? Есть брокер, который только тем и занят, что принимает сообщения от издателей, и перенаправляет их кудыть надо. Зачем модулю термометра знать, что кондиционер подписался на изменения его температуры?

 

Первый шаг в чём? В разработке? Так зачем оно, если есть Majordomo, например?

 

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

А затем, что не в идеальном мире живем, и если вдруг случилось так, что данные недоступны - эта ситуация должна быть под контролем. А в случае с MQTT брокер просто не получит данные из топика, не перешлет их подписчикам, и будет считать, что все в порядке. А устройство само не получит данные из топиков, на которые подписано, и тоже будет считать, что все в порядке. На мой взгляд это критически важно. Ну, послал я команду, а устройство эту команду не получило (по овер 9000 возможных причин). А время идет, я думаю, что команда исполнена, и даже не думаю, что что-то может пойти не так. Это неправильно.

 

И для разруливания этой ситуации волне себе есть методы, которые таки не обязывают издателя знать что-либо о подписчиках

Это я к чему всё? Возьмите MQTT и допишите туды ещё слой, который и будет наблюдать, как разруливаются данные. Кмк, в случае такой общей постановки задачи это будет самым правильным вариантом.

 

С этим не спорю, но: в вашем случае, как я понял, это будет "transport over protocol", т.е. лишний слой. Т.е. мы имеем один протокол (WebSocket) поверх которого пишем свой протокол, так? Вот я и задался вопросом - а зачем, собственно, если есть тот же MQTT, где многие головняки уже порешаны?

 

Не изложите свое видение контроля приема команд? Вообще, ваш подход, очевидно, тоже имеет право на жизнь, но он делает сервер клиентом. Мне же архитектура позволяет хоть на каждый slave контроллер создать собственный документ, его обрабатывающий. Тут уже разница архитектурных подходов. Мне лично близок такой подход. Хочу его пощупать, как он будет себя вести. Если вдруг будут критичные проблемы, то и на mqtt перейти можно.

 

Ну у вас же есть брокер, если мыслить в рамках подхода, используемого MQTT. И есть N подписчиков (кстати, Majordomo - это по сути подписчик на все топики). Сделайте подписчика, который будет подписан на все топики, и иметь настройки, которые нужны вам, например "Если с топика такого-то инфа не пришла в течение минуты - публикуем топик такой-то и встаём в аварию".

Подписчик может быть где угодно, в том числе

 

Чисто с технической точки зрения такой вариант реализации возможен, хоть я в данный момент и не совсем представляю, как именно такое можно сделать. Но переход на mqtt имеет один решительный маркетинговый недостаток. Он вводит один компонент, который нужно устанавливать и настраивать. Моя реализация позволяет просто залить библиотеку, и сразу начать делать то, что хочешь. Как ни крути, но простота - тоже критерий.

 

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

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

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

Задайте себе один простой вопрос: какую проблему пользователя эта разработка призвана решить?

 

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

 

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

Это я к тому, что простой сферический конь особо никому не интересен. Людям в 99% случаев надо решать свои проблемы, именно этим мы всю жизнь и занимаемся.

 

Чем больше думаю, тем больше прихожу к мнению, что описать весь спектр возможных применений - это сложно, черт подери) Как можно описать, что можно сделать на ардуино? А теперь представьте, что все, что вы делаете на ардуино, можно без особого труда вынести, и управлять через сеть?
Хотите ШИМ на выходе по условиям - Сможете!
Хотите включать/выключать реле по времени - Включите!
Хотите знать, сколько воды в бочке - Узнаете!
Хотите узнать, можно ли сделать то, что вам нужно? С большой долей вероятности - можно!
На самом деле мне очень хочется обратной связи от людей. Ведь много же чего можно сделать, были бы идеи!

 

Вы мыслите как исполнитель, а не как потребитель Как это знакомо - сам через это переболел в своё время, когда только-только начинал shareware-программы продавать. А теперь я попробую взглянуть глазами потребителя:

Что такое ШИМ? Зачем мне какие-то условия?

Не хочу, зачем? Мне просто нужно, чтобы в пятницу и субботу полив газона включился сам: в пятницу - в 10 утра на 1 час, в субботу - в 5 вечера на два часа. И чтобы не включался, когда идёт дождь.

Что мне даст это знание? Какая мне разница, сколько воды в бочке - полная или половина? Это абстрактное знание, которое ничего не решает.

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

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

Позиционируйте продукт. Определитесь с нишей. Обрисуйте проблемы, которые решает продукт. Начните развивать его. Обзаведитесь поклонниками и тестировщиками. Собирайте фидбэк. Не бойтесь отказаться от развития проекта, если что-то пойдёт не так.

И - избегайте общих решений, это смерть.

З.Ы. Всё имхо.

 

Я наконец-то добрался до исправного W5100. Снова возвращаюсь к разработке проекта вебмастер)

 

согласен. Например у меня проблема в том что очень хочется вести логи а докупать железо мне в тягость, вот если бы можно было взять 4 контакта с arduino, присобачить к витой паре, и без лишних телодвижений написать Webmaster.send() то было бы круто, экономия в финансах, решение проблемы. Но что то подсказывает что это нереально, а жаль.