Стандарты имен переменных, например, лучший способ отправки motion_detect=true

Нет, никакого "отраслевого стандарта" не существует. Вы вольны выбирать то, что вам нравится.

Если вы хотите быть полностью универсальным, вы можете сделать что-то вроде:

p1name=Temperature&p1units=celcius&p1value=23.4&p2name=Humidity&p2units=%25&p2value=43.8

(%25 - это % при кодировании URL-адреса)

Или вы могли бы использовать:

p1=Temperature/Celcius/23.4&p2=Humidity/%25/43.8

Это всего лишь два примера. Нет конца тому, как вы могли бы это сделать.

Я не думаю, что это так. Это также отчасти зависит от того, как вы собираетесь хранить данные.

Я бы выбрал motion=true вместо pir=true, поскольку он описывает, что вы обнаруживаете, а не какой тип датчика вы использовали. Что делать, если вы решите заменить датчик PIR на датчик на основе радара. Теперь имя переменной не имеет смысла.

Во-вторых, что произойдет, если вы добавите второй датчик движения в другое место? Я бы добавил к запросу что-то уникальное. Что-то вроде идентификатора узла. Таким образом, вы сможете провести различие между ними. Что-то вроде ?nodeid=1&motion=1. Вы также можете добавить дополнительную информацию, такую как напряжение батареи для этого узла; ?nodeid=1&motion= 1&voltage = 3.1.

Я не думаю, что проводить различие между C и F имеет большой смысл. Но если это произойдет, вы бы сохранили это где-нибудь на сервере, так как на самом деле оно никогда не должно меняться. Что-то вроде; значение температуры, поступающее из nodeid 6, является температурой в "гостиной" и указывается в "C" и должно быть показано на графике с осью Y от "10 C" до "30 C".

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

OPC DA

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

Можно было бы один раз настроить точки данных на стороне сервера, то есть настроить тип и устройство, которые вы собираетесь получать по этому "каналу" или "порту", или как вы это называете.

К сожалению, OPC DA и OPC HDA используют XML, а построение XML не является тривиальным. Это не очень подходит для устройств Интернета вещей.

Извлеченные уроки: настройте устройство на стороне сервера и разрешите клиенту отправлять только данные. Не используйте XML для передачи данных.

OPC UA

Затем существует Унифицированная архитектура OPC. Они также усвоили свой урок и удалили XML и добавили безопасность. Теперь они используют двоичный протокол. Спецификация составляет более 1000 страниц, поэтому понять ее будет сложно и на самом деле настолько сложно, что даже реализации OPC UA разных компаний плохо работают вместе.

OPC UA определяет 25 типов данных и способы определения других типов данных.

Адресное пространство в OPC UA является иерархическим - и, вероятно, устройство может существовать в нескольких иерархиях, например, физической топологии, такой как этажи и комнаты, или логической топологии, которая вписывается в структуру машины.

Извлеченные уроки: упростите протокол и подумайте о безопасности, т. Е. Если вы хотите использовать кодировку URL (GET), то используйте, по крайней мере, HTTP S. AFAIK, устройства ESP32 поддерживают шифрование, так что это больше не проблема для крошечных устройств. Люди будут использовать очень странные типы данных, например 18-битные целые числа. Кроме того, не только предоставьте единый список устройств, но и позвольте им расставлять вещи по мере необходимости.

MQTT и кивнул

Теперь это были довольно тяжелые протоколы и модели, управляемые компаниями. Конечно, существуют также протоколы, лучше подходящие для Интернета вещей, такие как MQTT. MQTT широко известен и использует также хорошо известное программное обеспечение Node Red для его обработки. Вы можете определить рабочие процессы, как данные должны обрабатываться, преобразовываться, храниться и должны ли срабатывать сигналы тревоги выше или ниже пороговых значений.

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

Извлеченные уроки: Люди хотят большего, чем просто хранение данных и графика.

Единицы измерения

OpenHAB пытается составить список объектов. Я радиолюбитель. Я измеряю электромагнитные поля. Я все еще пропал без вести

• КСВ (коэффициент стоячей волны)
• dBu (дБ мкВт)
• dBc (дБ относительно самого сильного сигнала)
• dBV, dBmV (дБ для вольт вместо Ватт)

Личный опыт

Я работал в компании, которая производила программное обеспечение для промышленности. Существуют устройства, которые посылают значение измерения каждые 100 мс. Допустим, это простое значение температуры всего в 1 байт, то есть все равно 315 000 000 записей в год.

Как вы отображаете такие данные? На экране Full HD вам все равно потребуется объединить 150 000 значений измерений в одном столбце пикселей.

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

Заключение

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

ИМХО, извините, это вряд ли нужно. Люди не хотят отправлять свои данные на случайный HTTP-сервер. Некоторые хотят настроить его только дома, чтобы никакие данные никогда не попадали в Интернет. Некоторые люди хотят делать больше, чем просто отображать графики (особенно сигналы тревоги). MQTT и Node Red работают локально, на Raspberry, на сервере и даже в облаке, как вы хотите.

Вам нужно не только pir=true, pir= 1, motion_detect=true, вам также нужно

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

Это требует немалых усилий. Красный узел имеет > 4000 коммитов.