DTO (обмен данными между клиентом и сервером (МК))

Sivolday commented 6 years ago

Предлагаю навести порядок в обмене данными:

Установка настроек МК тоже должна осуществлять через JSON // предложение от @mitskovets (полностью поддерживаю) ((сейчас не так, сейчас через разные GET))
На данном этапе МК должен обрабатывать два основных запроса**. Запрос состояния (все датчики, мощность…) и запрос на изменение настоек. Запрос состояния в свою очередь так же помимо всего транслирует настройки в ответ, тут мы сразу предусматриваем сценарий подключения нескольких устройств (ПК, смартфон, планшет аля большой дисплей, злая тёща))) )
Это важно сделать как можно скорее, чтобы заключить “соглашение” между разработчиками front/back-end и по возможности минимизировать влияние на работу друг друга (Даже на данном этапе между разработчиками явно выкристаллизовывается разделение труда). Завтра (26.05.2018) выкачу на обсуждение два JSON DTO

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

TheLuckyChip commented 6 years ago

У меня вопрос чайника. А почему get и json противопоставляются? Запрос идет к json файлу. Т.е. по запросу именно json и формируется. Затем он парсится.

Sivolday commented 6 years ago

GET это протокол (особенно если маячит переход на MQTT ), а JSON это просто формат. Не важно по какому протоколу передаваемый.

Сейчас передача данных на сервер (МК) осуществляется разными GET запросами. Возможно делать один GET запрос для передачи новых настроек, с помощью одного параметра. Этот параметр будет содержать в себе JSON–строку, со всеми настройками. Эту строку на МК лекго отпрасить (разобрать). Протокол всегда сменить будет легко.

calipzo commented 6 years ago

GET всё же не протокол, а метод протокола. Как и POST. Для передачи настроек неплохо было бы использовать вообще-то POST.

Sivolday commented 6 years ago

По поводу протокола справедливое замечание. Переходить на POST, смысла нет, он менее удобен в отладке. Особенно если учесть переход в перспективе на MQTT или Socket.

Sivolday commented 6 years ago

Просьба к сообществу просмотреть DTO. Если всё хорошо, можно приступать к реализации. https://github.com/TheLuckyChip/LuckyBox/blob/f3edb969bd23ee72540d432492703b76050e1f45/project_data/deviceCondition.json#L3 В таком виде должны передавать данные с МК на клиент. На МК передаётся только блок настроек. Это соглашение между сервером и клиентом. Если в последствии нужно добавить передачу каких дополнительных данных нужно сначала внести изменения в этот файл, что бы было наглядно и уже потом приступать к реализации.

mitskovets commented 6 years ago

// Параметры сети

"ssid": "SSID",
  "password": "password", — убрать

Считаю в параметрах сети не нужно передавать пароль

// Затирание

 "pauseTemp": [ // Температура паузы
    48,
    64,
    72,
    78
  ],
  "pauseTime": [ // Время паузы
    48,
    64,
    72,
    78
  ],

В затирании (расширение до пивоварения) сделать возможность создания динамических пауз со стороны web, добавить/убрать, и должен быть еще один параметр — текущая пауза (номер), т.е. должна быть возможность стартануть с нужного шага и так же дать возможность (в последствии) загрузить свой рецепт и варить по нему, а также сделать паузу процесса (при фильтрации/переливе сусла в другую емкость, мытья котла), и последующего старта (кипячения, например). Может вообще подойти именно к этому процессу более подробнее что-ли, (mesh in mesh out brew)), как я вижу:

brewing:{
status:"start", //"start","stop","pause" — может в булены переделать? 
pause:0,//номер текущей паузы
process:{
0:{temp:50,pause:20,name:"Белковая пауза"},
1:{temp:67,pause:50,name:"Осахаривание"},
2:{temp:72,pause:10,name:"Декстриновая пауза"},
3:{temp:78,pause:10,name:"Мэш аут"},
4:{temp:100,pause:90,name:"Кипячение"}
}
}

И еще, может нужно передавать какой в данный момент процесс запущен, или это отдельно?

А вообще это очень правильная концепция, продумать всю коммуникацию заранее ))

mitskovets commented 6 years ago

А, забыл, про пиво, добавить «аларм» — «пищалку и текст» при каждой следующей паузе: — «Хмель добавил?»

Sivolday commented 6 years ago

Насчёт пароля согласен, но тогда надо разделять описание на два json иначе будет путаница. Я до пивоварения ещё не дорос. Обращаюсь ко всему сообществу, не стесняйтесь коммитеть свои предложения.

mitskovets commented 6 years ago

А зачем разделять описание процесса на 2? В смысле, передавать только настройки и показания текущих датчиков/тена, а остальное передавать из каждого сервиса (json каждого процесса отдельно)?

Sivolday commented 6 years ago

Я предполагал два сервиса: получения полной информации о МК (датчики, настройки) и установка всех настроек сразу. Если пароль не передавать, то эта структура рушится. Впрочем, я не сильно настаиваю на 2 сервисах, я за скорейшее определение «протокола» обмена данными.

mitskovets commented 6 years ago

А зачем пароль передавать, я не понимаю, его же нужно ввести?

serjrv commented 6 years ago

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

TheLuckyChip commented 6 years ago

Очень классный, структурированный json! Менюшка для wifi это здорово.

mitskovets commented 6 years ago

Я вот про что, http://joxi.ru/Q2K0vn1S4DOvKA поскольку LuckyBox висит в WiFi в свободном доступе, то любой может к нему подключиться, разве не так?

Sivolday commented 6 years ago

Только если на роутере не пробросить порты во внешний мир. Если считать локальную сеть безопасной.

mitskovets commented 6 years ago

Стукнись в скайп, бросил запрос тебе, ничего, что на ты?

serjrv commented 6 years ago

https://cloud.mail.ru/public/DK5a/aePK4k4ob здесь пример обмена данными, правда тоже все без шифрования. web писал не я, просто товарища просил. Вход в настройки: http://ваш_ip/setup.htm просто посмотреть ответ контроллера: http://ваш_ip/set За более чем два года эксплуатации ломать ни кто не пытался, по сей день все работает. Эта какая то из промежуточных версий которую нашел с ходу, но идея понятна. Вся канитель связанная с web в Setup.ino

Sivolday commented 6 years ago

ничего, что на ты?

Норм

mefody1971 commented 6 years ago

mitskovets, К ESP-шке можно подоткнутся только когда она в начальном режиме настройки подключения к роутеру. Да и то зная дефолтное название сети и пароль. После подключения к роутеру потоки между ними и между роутером с компьютером пойдут по шифрованному протоколу WEP или WPA|WPA2. Взломать их можно, конечно... профессиональному хакеру с серьезной аппаратурой и подготовкой... лет за 5. Но не думаю, что найдется масса желающих ломать автоматику для дистилляции и пивоварения :)

mitskovets commented 6 years ago

Да и то зная дефолтное название сети и пароль.

Я как раз и провел такой эксперимент (подключился легко). Представьте, сколько людей будет компилировать LuckyBox, а сколько будут заливать готовый .bin, а еще больше будут уже пользоваться готовой собранной кем-то коробкой? И продвинутых людей реально не много и они могут даже не поменять этот дефолтный пароль LuckyBox/12345678. Соответственно, уже кто-то шутит на форуме, что скоро по всей стране будет куча WiFi точек «LuckyBox», злоумышленник легко подключается к LuckyBox и потом из json берет пароль к WiFi и просто им пользуется, а мы как разработчики, эту дыру ему дали.

TheLuckyChip commented 6 years ago

Коллеги, всем привет и с праздниками. Давайте вернемся к нашим баранам))) Все согласны с DTO предложенным Sivolday и методом Get как основой обмена? Давайте уже застабилизируем эти стандарты проекта и пойдем дальше.

mitskovets commented 6 years ago

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

TheLuckyChip commented 6 years ago

А куда его убрать? В отдельный json или как? И тогда мы вернемся к исходному набору json'ов.

TheLuckyChip commented 6 years ago

Это не хорошо и не плохо, просто надо понять, мы делаем один сложный, структурированный json или идем по пути "на свой процесс - свой json".

Sivolday commented 6 years ago

Не совсем так, просто данные датчиков требуются для всех процессов, а данные для затирания только для одного. Склонен согласиться с @mitskovets убрать затирание вроде не рушит концепцию.

Sivolday commented 6 years ago

Просьба посмотреть мою реализацию https://github.com/TheLuckyChip/LuckyBox/blob/b3fc6bff4016a1f526867563d7bd433b423f29ec/project_data/luckyBoxReceiver.js#L1

через подписку на событие

https://github.com/TheLuckyChip/LuckyBox/blob/b3fc6bff4016a1f526867563d7bd433b423f29ec/project_data/plot.js#L114

Есть один глобальный объект - luckyBoxReceiver к нему любой может подписать на событие получения DTO и получить данные. Если надо могу более подробно написать как это работает.

P/S: Без правки код не заработает, я захардкордил IP https://github.com/TheLuckyChip/LuckyBox/blob/b3fc6bff4016a1f526867563d7bd433b423f29ec/project_data/luckyBoxReceiver.js#L9

TheLuckyChip commented 6 years ago

Если большинство профессионалов считает, что затирание надо вынести, то я присоединяюсь. Мне бы успевать за вами)))

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

А хардкодинг IP останется в финальной версии? Это не совсем хорошо по идее.

Sivolday commented 6 years ago

Про механизм работы чуть позже попытаюсь написать. Что касается адреса в коде, сделано это специально для отладки. Интерфейс крутится НЕ на сервере ESP, а на машине с IDE, но запросы шьет к реальной ESP. В противном случае, я бы застрелился каждое изменение компилировать и заливать на ESP. Берите на вооружение.

Отвечая на вопрос про финальную версию, конечно нет, более того, не должно покинуть эту ветку.

mitskovets commented 6 years ago

А куда его убрать? В отдельный json или как? И тогда мы вернемся к исходному набору json'ов.

Это как раз будет более удобно, можно допиливать или добавлять любой сервис, не затрагивая основные свойства, будет запущен только один сервис единовременно, а параметры датчиков мы и так получаем, из основных свойств МК. Вопрос: а назначение датчиков (перераспределение) куб/тэн/колонна/вода... мы где будем делать? В основных настройках? Или отдельно сделаем — датчики?

TheLuckyChip commented 6 years ago

Отличный вопрос про переназначение датчиков. А еще, кстати, можно и калибровку сделать. Думаю, что в настройках имеет смысл подраздел сделать - датчики. Калибровка - это когда все датчики в кипяток засунули и нажали кнопку "калибровка". Берется дельта между 100С и текущим показанием и на все датчики всегда применяется. Я не очень знаю зачем это практически нужно. Но народ просил. Правда можно и на потом оставить калибровку.

serjrv commented 6 years ago

Все настройки отдельной вкладкой, и желательно с дополнительным паролем на доступ. У некоторых и ребенок на страничку из закладок браузера залезть сможет. Во многих промышленных web интерфейсах есть разграничение прав доступа к определенным закладкам. Сделать так же, думаю не сильно сложно. С назначением номеров датчикам температуры нужно решить в первую очередь. По запросу конкретной вкладки web интерфейса, контроллер выдаст запомненные в EEPROM значения датчиков, если еще не запоминали, то 1=1, 2=2 и т.д. В самой программе я все пере присвою, т.е. сами переменные в web "курочить" не надо. Только желательно кроме номера датчика еще и его цвет для графика предусмотреть, опционально, может быть и его название для себя любимого... Еще очень сильно не нравится смещение номеров датчиков при дистилляции и ректификации, это из того что сейчас присутствует, я к примеру 3-й и 4-й датчики местами поменять не могу, конструктив однако разный, на выходе по пару у меня 4 мм. трубка стоит.

mitskovets commented 6 years ago

Настройки можно вообще не передавать из контролера, их можно получить по запросу, открыл вкладку, получил, соответственно -1 луп в МК. Также и с датчиками, подписался на событие, указал процесс, указал датчики и запустил луп на контроллере. Про датчики: не понял, почему нельзя менять датчики местами? И еще датчики на «горячую» подключаются? Если например нужно добавить датчик на ходу? Или заменить, говорят, они часто выходят из строя, у меня нет опыта долгого использования. Мне кажется мы стали, потому что нет общего понимания архитектуры. И нужно переделать некоторые сервисы в МК, предлагаю созвониться в выходные и обсудить.

serjrv commented 6 years ago

Нумерация датчиков нужна, т.к. на TFT дисплей тоже данные выводятся. С выходом датчиков из строя не сталкивался. В данном релизе на горячую датчики менять нельзя, если надо, сделаем. По выходу продукта у меня стоит самодельный датчик с диаметром 4 мм., в кубе диаметр 6 мм., как я их могу местами поменять? Мой тел.: +79272561845 Сергей.

mitskovets commented 6 years ago

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

В данном релизе на горячую датчики менять нельзя, если надо, сделаем.

Я вообще имею ввиду, позволяет ли сам МК подключать датчики на горячую?

serjrv commented 6 years ago

Самому контроллеру ничего не будет при подключении датчиков на горячую. Просто надо тогда в WEB предусмотреть кнопочку, при нажатии которой MK получит команду пере инициализировать датчики. Другое дело что разъемы надо использовать такие, чтобы при подключении не происходило закорачивание питания, к примеру так произойдет если использовать джек для наушников.

mitskovets commented 6 years ago

Это очень здорово тогда, ) опять же это нужно сделать сначала в МК, прикрутить кнопку в веб не сложно )

serjrv commented 6 years ago

Ок. На этих выходных реализую, как раз еще и датчик BMP180 приедет, там тоже ошибку найти надо.

TheLuckyChip commented 6 years ago

BMP085 тоже с ошибкой давление измеряет. Думаю, где-то системная ошибка вкралась. Все датчики, судя по форуму работают, и все врут. Что-то с математикой расчета давления.

serjrv commented 6 years ago

BMP085 и BMP180 используют одну библиотеку, поэтому и врут одинаково. BMP280 и BME280 используют другую библиотеку, там все в норме, у меня оба этих датчика, все четко. BMP180 сегодня или завтра должен приехать, сделаем.

serjrv commented 6 years ago

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

Sivolday commented 6 years ago

Да верно, но только на клиент уходило это добро вот так: https://github.com/TheLuckyChip/LuckyBox/blob/cfb109ae37a9c8a7564a00c5a7d0d4feb7a5aa66/http_config.cpp#L82

А теперь предложение сделать это подобным образом: https://github.com/TheLuckyChip/LuckyBox/blob/97819576a45b47d2df4bd049cb93e15c492028b2/http_config.cpp#L124

Так же считаю переменную которую я ввёл лишней: https://github.com/TheLuckyChip/LuckyBox/blob/97819576a45b47d2df4bd049cb93e15c492028b2/setting.h#L69

Руками и ногами за инкапсуляцию: https://github.com/TheLuckyChip/LuckyBox/blob/97819576a45b47d2df4bd049cb93e15c492028b2/sensors.h#L14 В пером приближении сделал как сделал)

serjrv commented 6 years ago

Думаю сегодня уже добью сенсор на TFT и возьмусь за переменные для WEB. Они все равно в какой то степени у меня на дисплее дублироваться будут. Для начала нумерация DS-ок и по умолчанию нет старта какого либо процесса. На TFT экране при старте делаю четыре кнопки: Дистилляция, Ректификация, Затирание, Настройки. Все это я так понимаю и в WEB продублируется.

serjrv commented 6 years ago

Всем привет. Есть желающие к конструктивной беседе по поводу обмена данными Контроллер <=> WEB ? Есть предложение провести конференцию в скайпе сегодня чесиков в 20:00 по Москве? Стучимся к Счастливчику ближе к восьми вечера, группу он создавал. Надо WEB к консенсусу привести, основное по железу я дописал.

TheLuckyChip / LuckyBox

DTO (обмен данными между клиентом и сервером (МК)) #8