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

задача
есть (разрабатывается) несколько железок для передачи состояния датчиков через GSM канал.
кол-во устройств 5-10штук.
информация разная и немного. срабатывание да/нет и значения в раземере 1-2байт.

вопрос - как наиболее бюджетно собрать всю эту информацию, записать ее в БД и потом отобразить красиво пользователю.

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

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

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

Рецептов море как это сделать и похоже все уже ТАМ.
30 дней на IBM Bluemix дают бесплатно.
И всего то нужно поставить на дивайс MQTT.

Я забил на все модности с json и прочим - взял за 3 евро сайт на microsoft azure и сделал за две недели
http://vell.azurewebsites.net/
хоть какую красоту можно наводить.
Дешево и никаких ограничений.

Так фишка не в хостинге, а в сервисах.
Не дело инженеров наводить красоту, все равно не получится.

Только что смотрел что предлагает Microsoft Azure.
Протоколы на выбор: AMQP или HTTP/1
Чтобы реализовать AMQP дивайсу нужно 1 мег RAM-а. Если HTTP/1 то не поддерживается прямая посылка сообщений от сервера к дивайсам.
MQTT могут поддерживать только через какой-то Azure IoT Protocol Gateway.
Движка рисования графиков нет. Шаблонов приложений нет.
Вообщем нищета.

IBM Bluemix гораздо мощнее пока и MQTT поддерживает напрямую.

jedem das seine

не доверяю облаку
предпочитаю собственный контроль

ну раз нет рисования графиков - это отстой
хотя zedgraph никто не отменял
для меня общая схема не подошла - вот взял свою

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

А почему не нравится? Можно использовать, например, NMS типа Nagios, Zabbix, OpenNMS и тп с RRD базой данных.
Или вообще использовать InfluxDB+Grafana.

Grafana всего лишь выводит графики.
Но до того как выводить графики надо как-то наладить протокол подключения дивайсов, протокол администрирования и проч.

Решений по отображению графиков и у Bluemix больше чем достаточно:
Нажмите для просмотра прикрепленного файла

Да, grafana только выводит графики. Для сбора информации используется Influxdb, у нее протокол очень простой:
https://github.com/influxdb/influxdb

Там не протокол, а API поверх HTTP. А само API базируется на синтаксисе SQL.
Это гораздо сложнее чем MQTT.

А главное кто бесплатно хостит этот Influxdb?
И что, голая база данных как-то облегчает администрирование давайсов?

Bluemix бесплатно хостит ваши данные и дает интерфейс администрирования дивайсов. Из пакетов MQTT данные автоматом идут в базу данных (несколько разных движков на выбор ) без всяких нагрузок в виде HTTP и SQL.
Да еще c движком от http://nodered.org/ их там можно распарсить визуальными конструкциями.

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

а разработчики пишут: "протокол" ))
https://docs.influxdata.com/influxdb/v0.9/write_protocols/

С точки зрения записи в базу - все очень просто. С точки зрения чтения и анализа - сложнее, но для этого есть графические средства.
То что поверх HTTP это скорее преимущество, чем недостаток - не порежут в случае чего. А для 3g модемов со встроенным tcp/ip стеком вообще д.б. очень удобно.

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

Ну и не все клиенты настолько богатые люди, чтобы использовать бесплатные вещи

Ну да, сначала куча протоколов, а сверху API. Ибо это примитивная база данных. С базами данных невозможно работать без API.
Базы данных это не middleware, они не умеют выполнять бизнес процессы. Клиент базы данных значит должен это делать через API.

HTTP оно конечно круто и все такое, но кто у вас писал все-таки бизнес логику и главное сколько времени?
С тем же успехом можно продвигать MySQL c PHP. Эта парочка хотя бы любыми хостерами поддерживается.

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

А если клиенты не такие богатые, то IBM с удовольствием им организует платиновый план за пару сотен евро в месяц с распределением нагрузки и подключением более 10 тыс. устройств одновременно.

>Базы данных .. не умеют выполнять бизнес процессы.

Ага - новое "слово" в базо-строении и *-использовании.

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

Это неверно. В SNMP есть механизм Trap-ов, т.е. асинхронных оповещений о событиях.
Просто в SNMP громоздкое кодирование.
И когда я внедрял свои дивайсы с SNMP организации еще требовали чтобы он поддерживал стандартные схемы мапинга сетевой статистики требуемые для из SNMP менеджеров, что совсем уже было обременительно.
Плюс для SNMP надо получать свой уникальный номер от IANA.

это вопрос реализации агента. Можно агента(сервер) реализовать на сервере, а менеджер(клиента) - на железке. Тогда железка будет оповещать о своем состоянии pdu set, а забирать команды get. При этом ПО мониторинга должно опрашивать агента на сервере, а не на железе.

Для целей ТС, Mathworks продвигает свою платформу https://thingspeak.com/
Мне кажется это как раз подойдет.

ThingSpeak -А на нем ктонибудь уже работал. Матлаб какой стоимости нужен

Дык оно, вроде, и без Матлаба работает через API. Матлаб только для анализа нужен, и то, я не уверен.
Я, лично, жду от них поддержки MQTT, чтобы в каналы писать можно было.

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

(круглый)

Облако это когда работаем по API с доменом не зная ни IP, ни физического сервера.
В один момент с нами работает один сервер, а в другую секунду уже другой.

Вот ThingSpeak это не облако потому что хостить это чудо надо самому где-то.
А вот IBM Blue Mix или Microsoft Azure это облака.

т.е. свои протоколы, а не стандарт Ethernet?
Или всё-таки "облако" живёт до обычного резолвера, в обычный IP ?



и для поддержания динамики в IP выдумали новый термин? прям по анекдоту ))
значит если я реализую обычное переключение клиента между различными серваками - это и есть "спрэй"(С) (ну или нью облако)?

(круглый)
ЗЫ
2AlexandrY
Спасибо!

Термин облако характеризует инфраструктуру для размещения приложений как с моей точки зрения.
Протоколы к этому не имеют отношения.
У облака инфраструктура полностью скрыта, поэтому нельзя полагаться на адреса IP. Но это только как технический нюанс, не закон.

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

Но может облака кто-то по другому интерпретирует.

Вроде там как сам сайт и хостит, судя по API. А как опция для собственного хостинга предлагается проект на GitHub.

Как по мне "Облако" это комплекс средств и мер по обеспечению доступа к своей информации, или своим сервисам из любой точки мира в любое время и с помощью любых устройств.
Этот комплекс мер должен предусматривать не только удобный доступ в виде API, но и балансирование нагрузки, резервирование и бекап, если нужно.
Например, я считаю своей персональной "тучкой" мой NAS у себя дома, где хранятся мои фотки. Он включен 24/7, я могу загружать и смотреть фотки как со своего компа, так и с телефонов, зайти могу из любого места, где есть интернет, фотки периодически бекапятся автоматом на другой сервер. То есть я могу сказать, что у меня фотки хранятся в "облаке", хотя я также точно знаю, где они хранятся физически.

Главная характеристика облака это внутренняя распределенность.
Как же один NAS может быть облаком?
Хоть бы два NAS-а поставили и как-то бы их динамически реплицировали что ли. Вот тогда было бы облако.

Я ж и говорю - у меня - "тучка", это такой концентрированный вид облака.

в том веке это всё называлось другим модным сочетанием:

клиент-серверные приложения.

мелкомягкие извратили это правда, всякие там 25 уровней добавили
по поводу облаков (ИМХО) - очередной холивар от маркетинга.

(круглый)
ЗЫ
Кто то называет облаком иконочку на дэсктопе ))
ЗЫ ЗЫ
Вот сейчас прозвучало, что термин "облако" описывает некую структуру клиент-серверного решения...