Які послуги IoT доступні для зберігання / відправки / публікації загальних даних у хмарі?

Які послуги IoT доступні для зберігання / відправки / публікації (та протилежних операцій) загальної невеликої кількості даних у хмарі?

Я шукаю, наприклад, послугу, де пристрій міг би зберігати значення у хмарі. І деякі інші об'єкти (інший пристрій, веб-сайт з кодом JS, веб-сервер, мобільний додаток) можуть отримати це значення.

Це може бути якийсь асинхронний зв'язок, наприклад, для зберігання та вилучення чогось такого маленького, як пара ключів і значень, <255 байт, ціле число, рядок, максимум невеликий об’єкт JSON. Сервіс може запропонувати API REST (так що до нього можна отримати доступ до великої кількості мов) з деяким маркером для автентифікації та ключем та значенням для зберігання.

Детальний приклад випадку використання:

Вдома є датчик температури, і я хочу, щоб він зберігав значення в хмарі ( десь поза домом ). Таким чином, я міг отримати доступ до нього, незалежно від того, моє домашнє з'єднання перерване чи ні. Morevoer, це дозволить уникнути збереження та підтримання виділеного сервера + порт для переадресації + DynamicDNS.

Поки що я не зміг знайти щось подібне, але час від часу я знаходив кілька прикладів того, що я маю на увазі описати:

• Particle.io публікувати () підписатися ()

• Віртуальні шпильки Blynk

Які ще подібні (вільні / відкриті) альтернативи існують?

Погляньте на ці послуги:

• Убідоти
• ThingSpeak

Обидві ці служби приймають прості дані про ключ / значення з пристрою. Я вважаю, що в обох є бібліотеки, готові імпортувати для пристроїв частинок, оскільки ви це згадали.

Багато хмарних провайдерів, як Amazon, Microsoft, Google, IBM тощо, намагаються залучати простір IoT, пропонуючи простіші способи надсилання / зберігання / аналізу даних датчиків до їх хмари. Навіть вони повинні придбати постачальників апаратних засобів, щоб збільшити їх сферу застосування в IoT.

Я не використовував жодних служб, крім AWS, тому можу пояснити свій досвід роботи з AWS та те, як ми інтегрували це для використання у виробництві.

Сценарій:

У нас є сотні датчиків, кожен з яких щохвилини посилає 184-428 байт даних на локальний шлюз, який агрегує дані і зберігає дані локально і надсилає ті самі дані до хмари AWS. У нас також є датчики зі спеціальним корпусом, які передають дані безпосередньо в хмару.

Хмарні послуги

Ми використовуємо AWS IoT , AWS S3, AWS DynamoDB, AWS Lambda, шлюз API AWS, AWS SNS, AWS Cloudwatch, AWS RedShift для створення цілого рішення. В основному, вони не характерні для IoT (крім AWS IoT), оскільки ми можемо використовувати їх для мобільних пристроїв, Інтернету.

Шлюз використовує AWS IoT SDK для підключення, аутентифікації та обміну повідомленнями з AWS IoT за допомогою протоколів MQTT, HTTP або WebSockets (ми використовуємо вузол JS SDK для підключення через MQTT). Ми є брокером MQTT локально на шлюзі пристрою і з'єднуємо його з кінцевою точкою AWS IoT звідти, ми проводимо миттєві перевірки отриманих даних (використовуючи механізм правил, функції AWS Lambda) і зберігаємо їх у архівації DynamoDB в S3, Glacier (Зберігання проводиться без написання єдиного рядка зроблено просто з використанням тригерів AWS для зберігання даних).

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

Тож моя пропозиція - використовувати MQTT , точніше його реалізацію Mosquitto . У них розміщений тестовий брокер, до якого ви можете підключити своїх абонентів та клієнтів-видавців. ( _{^{Ось посібник про процес налаштування в Windows 7.}} )

Зверніть увагу на наступне:

Ви можете використовувати його для будь-якої програми, але будь ласка, не зловживайте і не покладайтеся на неї за будь-що важливе. Ви також повинні побудувати свого клієнта, щоб впоратися з перезапуском брокера.

Але в основному ви можете опублікувати дані про температуру цього брокера.

Що стосується абонента-клієнта, я нещодавно використовував цю програму Android . Це дуже базове застосування, ще в розробці, але для тестових цілей воно дуже чудове. Отримані повідомлення відображаються на приладовій панелі, нічого не уявляють лише голі значення.

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

Для цього є два компоненти:

1. Як ви хочете, щоб ваші дані зберігалися? Немає реального способу зробити "загальну" послугу даних, яка дійсно відповідатиме усім потребам. Те, що ви хочете, називається "База даних часових рядів" , і їх сотні, тому що кожна деталь способу зберігання даних має значення в масштабі. (Якщо ви не в масштабі, просто збережіть його в будь-якій старій базі даних, вона буде працювати деякий час.)

   Кожна база даних часових рядів писалася тому, що інші не робили так, як хотіли. Наприклад, розглянемо, як Graphite зберігає свої дані: Кожна метрика (скажімо температура від одного джерела) зберігається у файлі фіксованого розміру. Незалежно від того, як часто ви надсилаєте показники або як довго ви надсилаєте їх, файл має постійний розмір.

   Мінусом є те, що старі дані знаходяться з меншою роздільною здатністю, і після встановленого інтервалу, який ви визначаєте (наприклад, 1 рік), дані викидаються. Але перевага полягає в тому, що графік на день так само швидко, як і рік, а показники з часом не збільшуються.

   В інших системах зберігання даних генерування графіку за рік може залучати мільйони точок даних і може зажадати великих обсягів зберігання даних.

   Великий мінус Graphite полягає в тому, що кожна метрика створює новий файл, тому якщо у вас є динамічні показники (скажімо, хмарні поля, що надходять та йдуть), це може бути не дуже зручним.

   Порівнюйте це з Прометеєм , де метрики зберігаються в основному за часом. Ви можете мати багато динамічних показників, і це добре. Але не намагайтеся зберігати ці показники довгостроково, для повернення та читання їх буде вічно.

   Жоден розмір не підійде всім.

   PS Graphana - прекрасний спосіб візуалізації ваших даних. Він має додатки для більшості баз даних часових рядів.

2. Хто збирається зберігати ваші дані? Є тисячі з місць , таких як ті , які ви згадали. Настільки легко закручувати БД часових рядів у хмарі, але заробити на цьому СТРІБЛИВО важко. Більшість цих компаній через деякий час припинять свою діяльність або розпочнуть підвищення цін. (Навіть утримувати ціни постійно - це зростання цін - оскільки вартість обчислень постійно падає.) Багато разів вони виявляють, що не можуть залучити стільки нових клієнтів, скільки хоч, тому намагаються підвищити ціни (під виглядом зміни їх моделі ціноутворення). Виявляється, для зберігання даних всіх людей коштує багато грошей ...

   Я рекомендую самостійно розмістити хостинг або використовувати авторитетного хмарного постачальника, наприклад AWS CloudWatch . (Дорога, якщо у вас багато показників, але безкоштовно для менше 50 метрик!)

uBeac - це новий безкоштовний інструмент візуалізації, який ми розробили, і це бета-версія. Він не є відкритим ресурсом, але повністю безкоштовний у використанні.

Ви можете визначити шлюз, і ви отримаєте унікальний URI. Ви можете встановити URI у вашому шлюзі чи пристрої для надсилання даних HTTP / MQTT.

Ось деякі його особливості:

• Команда, будівля, визначення плану поверху
• Візуалізація даних у режимі реального часу
• Спеціальний дизайн приладної панелі за допомогою різних віджетів
• Визначте типи, одиниці та префікси датчика Візуалізація карти
• ...

Він підтримує загальний формат даних Json та різні заздалегідь визначені шлюзи. Якщо ви не хочете використовувати заздалегідь задані формати корисного навантаження, вони відкриті для розробки вашої власної обробки корисних навантажень.

Я здивований, що тут ніхто не згадав про солодке . Це надзвичайно простий, надзвичайно цікавий спосіб налагодити спілкування. Ви обов'язково повинні спробувати це, адже ей, це безкоштовно!

flespi надає безкоштовні та комерційні хмарні послуги:

• Послуга MQTT Broker для операцій PUB / SUB, і ви навіть можете зберігати дані у збережених повідомленнях ;
• Двигун зберігання для операцій з ключем / значенням, особливо орієнтований на дані таймерів та загальне зберігання файлів (CDN). Працює через REST API .

Обов'язкове відмови від відповідальності: я працюю в компанії, яка розробляє платформу flespi. Хоча я робив все можливе, щоб залишатися об'єктивним, як завжди в Інтернеті, будь ласка, перевірте всю інформацію в цій відповіді, щоб виключити упередження, які можуть вплинути на ваше рішення.