Канал - это группа датчиков разных типов, показания с которых объединены в один график. Вы легко можете создать столько каналов, сколько нужно именно вам. Более того - если пожелаете, вы можете сделать канал публичным, т.е. доступным к просмотру всеми пользователями на странице Публичные каналы. К каналу можно прикрепить показания любых датчиков, полученных от любого из ваших контроллеров - при этом эти показания будут выводиться в общем графике, что, согласитесь, довольно удобно
Данные датчиков появляются в сервисе в тот момент, когда контроллер запрашивает систему на предмет наличия задач к выполнению (конечно, если вы сами разрешили такое действие в настройках контроллера). Сервис при получении данных от контроллера разбирает их, и сохраняет в базу данных, для дальнейшего показа вам на странице личного кабинета Каналы.
Здесь всё несколько сложнее, хотя и не так сложно, как кажется. Дело в том, что контроллер - это микроконтроллер, а не взрослый компьютер, поэтому - чем меньше данных будет по объёму - тем лучше. Именно поэтому я ушёл от развесистых форматов и никому не нужных усложнений, и сделал очень просто, как мне кажется.
Сервис поддерживает несколько типов датчиков:
(буковки нарисованы только для удобства понимания). Теперь, когда мы знаем типы поддерживаемых датчиков, нам надо как-то передать их показания с контроллера на сервис. Я решил, что самым простым вариантом будет передача всех показаний скопом - датчиков редко когда бывает сотню, да и, строго говоря, сервис не рассчитывает на такой объём датчиков на одном контроллере
Поскольку протокол HTTP - текстовый, то и показания надо передавать в текстовом формате, тут со стандартами не поспоришь, знаете ли. Поэтому контроллер делает просто: берёт показания всех типов датчиков, складывает их в кучу и передаёт в закодированном в строковой HEX-формат виде. Звучит пугающе, но на самом деле всё просто: допустим, у нас есть число 255 - в этом случае контроллер передаст строку FF, т.е. строковое представление числа в шестнадцатеричной системе счисления.
К чему такие заморочки, спросите вы? В них, на самом деле, есть смысл: допустим, показания вашего датчика температуры - 25,35 градуса. Как их передать в максимально коротком текстовом виде? Если передавать строкой 25,35 - то это 5 байт, как видите. А вот если передавать закодированно, то легко можно обойтись тремя символами, в случае приведённой температуры контроллер передаст строку 195, где первые два символа - это целая часть показаний (25 градусов в десятеричной = 19 в шестнадцатеричной системе счисления), третий символ - дробная часть показаний (0,35 градуса), отражённая на диапазон 0-15. Плюс ко всему - не надо для каждого датчика иметь свою переменную в HTTP-запросе (как хочет тот же ThingSpeak) - а это, знаете ли, тоже по нескольку байт на один датчик! Оперативки у нас не вагон, поэтому было решено уйти от избыточности именно таким образом.
Итак, мы выяснили, каким образом кодируются символы. Осталось разобраться с порядком следования показаний...
Показания датчиков выдаются контроллером в переменной s, и представляют собой непрерывную последовательность дуплетов (каждый дуплет = 2 символа = 1 байт) или триплетов. Очерёдность следования показаний такова:
Контроллер передаёт показания всех датчиков, прописанных в нём, с сохранением порядка следования датчиков в контроллере. Если с какого-то датчика нет показаний, то для датчика передаётся символ -, и система понимает, что для этого датчика нет показаний.
Впрочем, вам не надо об этом беспокоиться - наша прошивка всё сделает за вас! Данная статья предназначена для имплементаторов своих прошивок, которые могут захотеть интегрировать их с сервисом.
Ну и, напоследок, приведу абстрактный пример слепка состояния контроллера, где датчиков каждого типа - по пять штук, и, заодно - посмотрим, какое количество байт потребуется для передачи такого пакета. Все данные в пакете - просто для примера, и представляют собой цепочку значений F. В жизни, конечно, всё будет не так Не забывайте, что данные, передаваемые контроллером, слеплены в одну строку, в примере они разделены для наглядности:
Итак, как видно из примера - у нас 25 датчиков, и на их показания понадобилось 125 байт, т.е., в среднем - по 4,6 байт на один датчик (не учитывая байты их количества). Согласитесь - не так плохо, хотя и кажется избыточным на первый взгляд. Но при таком раскладе мы полностью избавлены от манипулирования дополнительной информацией, вроде указания при передаче индекса датчика, его типа, названия и прочей ненужной мишуры, которую вы вполне себе можете настроить в нашем сервисе, обозвав датчик так, как вам удобней.
Плюс в том, что в реальности датчиков освещённости используется не так много, датчиков pH может вовсе не быть, т.е. размер пакета будет меньше. Поэтому, надеюсь, мы с вами вместимся в оперативную память микроконтроллера
И ещё один пример, когда с каких-то датчиков нет показаний (посмотрим, как в этом случае изменится размер пакета; считаем, что в каждой группе из пяти датчиков два - не работают):
Что мы получили? 79 байт вместо 125 - неплохая экономия
Надеюсь, приведённая выше информация будет полезной.