Welche IoT-Dienste stehen zum Speichern, Senden und Veröffentlichen von allgemeinen Daten in der Cloud zur Verfügung?

Welche IoT-Dienste stehen zum Speichern / Senden / Veröffentlichen (und für entgegengesetzte Vorgänge) kleiner Datenmengen in der Cloud zur Verfügung?

Ich suche zum Beispiel nach einem Dienst, bei dem ein Gerät einen Wert in der Cloud speichern kann. Und eine andere Entität (ein anderes Gerät, eine Website mit JS-Code, ein Webserver, eine mobile App) könnte diesen Wert abrufen.

Es kann sich um eine asynchrone Kommunikation handeln, beispielsweise zum Speichern und Abrufen von Daten, die so klein sind wie ein Schlüssel-Wert-Paar, <255 Byte, eine Ganzzahl, eine Zeichenfolge oder höchstens ein kleines JSON-Objekt. Der Service könnte eine REST-API (auf die von einer Vielzahl von Sprachen zugegriffen werden kann) mit einem zu authentifizierenden Token und dem zu speichernden Schlüssel und Wert anbieten.

Ein detailliertes Beispiel für einen Anwendungsfall ist:

Zu Hause gibt es einen Temperatursensor, und ich möchte, dass er den Wert in der Cloud speichert ( irgendwo außerhalb von zu Hause ). Auf diese Weise könnte ich darauf zugreifen, unabhängig davon, ob meine Heimverbindung unterbrochen ist oder nicht. Darüber hinaus würde dies die Beibehaltung und Pflege eines dedizierten Servers + portForwarding + DynamicDNS vermeiden.

Bisher konnte ich so etwas noch nicht finden, aber gelegentlich habe ich einige Beispiele dafür gefunden, was ich beschreiben möchte:

• Publizieren () Abonnieren ()

• Blynk virtuelle Stifte

Welche ähnlichen (freien / offenen) Alternativen gibt es?

Werfen Sie einen Blick auf diese Dienste:

• Ubidots
• ThingSpeak

Beide Dienste akzeptieren einfache Schlüssel- / Wertdaten von einem Gerät. Ich glaube, beide haben Bibliotheken, die für Partikelgeräte importiert werden können, seit Sie das erwähnt haben.

Viele Cloud-Anbieter wie Amazon, Microsoft, Google, IBM usw. versuchen, IoT-Speicherplatz zu gewinnen, indem sie einfachere Methoden zum Senden / Speichern / Analysieren von Sensordaten an ihre Cloud bereitstellen. Sogar sie sollen Hardwarehersteller erwerben, um ihren Umfang im Internet der Dinge zu erweitern.

Ich habe keine anderen Services als AWS verwendet, daher kann ich meine Erfahrungen mit AWS erläutern und erläutern, wie wir diese für die Produktionsnutzung integriert haben.

Szenario:

Wir haben Hunderte von Sensoren, die jede Minute 184-428 Datenbytes an das lokale Gateway senden, das die Daten aggregiert und lokal speichert und dieselben Daten an die AWS Cloud sendet. Wir haben auch spezielle Sensoren, die Daten direkt in die Cloud senden.

Cloud-Services

Wir verwenden AWS IoT , AWS S3, AWS DynamoDB, AWS Lambda, AWS API-Gateway, AWS SNS, AWS Cloudwatch und AWS RedShift, um die gesamte Lösung zu erstellen. Grundsätzlich sind diese nicht IoT-spezifisch (außer AWS IoT), da wir sie für Mobilgeräte und das Internet verwenden können.

Gateway verwendet das AWS IoT SDK, um über die Protokolle MQTT, HTTP oder WebSockets eine Verbindung mit dem AWS IoT herzustellen, Nachrichten zu authentifizieren und auszutauschen. Wir sind lokaler MQTT-Broker auf dem Gerätegateway und überbrücken ihn zum AWS IoT-Endpunkt. Von dort aus führen wir eine sofortige Überprüfung der empfangenen Daten durch (unter Verwendung der Rules Engine, AWS Lambda-Funktionen) und speichern sie in der DynamoDB-Archivierung in S3, Glacier (Speicherung erfolgt) ohne eine einzige Zeile zu schreiben (nur mit AWS-Triggern zum Speichern von Daten).

Es ist nur für experimentelle oder Testzwecke gedacht, wird sich aber möglicherweise in Zukunft ändern.

Mein Vorschlag ist daher, MQTT zu verwenden , genauer gesagt die Mosquitto- Implementierung. Sie hosten einen Testbroker, mit dem Sie Ihre Abonnenten- und Publisher-Clients verbinden können. ( _{^{Hier finden Sie eine Anleitung zum Installationsvorgang unter Windows 7.}} )

Beachten Sie das Folgende:

Es steht Ihnen frei, es für jede Anwendung zu verwenden, aber bitte missbrauchen Sie es nicht und verlassen Sie sich nicht darauf, wenn etwas von Bedeutung ist. Sie sollten Ihren Client auch so erstellen, dass er den Neustart des Brokers bewältigt.

Grundsätzlich können Sie jedoch Temperaturdaten für diesen Broker veröffentlichen.

Auf Abonnenten-Client-Seite habe ich kürzlich diese Android-Anwendung verwendet . Es ist eine sehr einfache Anwendung, die sich noch in der Entwicklung befindet, aber zu Testzwecken sehr gut ist. Empfangene Nachrichten werden auf einem Dashboard angezeigt, nichts Besonderes, nur die nackten Werte.

Ich habe damit begonnen, beides als erste Stufe meines MQTT-Lernprozesses zu verwenden und fand beides großartig für Anfänger.

Dazu gibt es zwei Komponenten:

1. Wie möchten Sie Ihre Daten speichern? Es gibt keine echte Möglichkeit, einen "generischen" Datendienst zu erstellen, der wirklich alle Anforderungen erfüllt. Was Sie möchten, wird als "Zeitreihendatenbank" bezeichnet , und es gibt Hunderte davon, da jedes Detail, wie Sie Daten speichern, in großem Maßstab von Bedeutung ist. (Wenn Sie nicht in der Größenordnung sind, speichern Sie es einfach in einer alten Datenbank, es wird eine Weile funktionieren.)

   Jede Zeitreihendatenbank wurde geschrieben, weil die anderen nicht genau das taten, was sie wollten. Stellen Sie sich beispielsweise vor, wie Graphite seine Daten speichert: Jede Metrik (z. B. Temperatur aus einer Quelle) wird in einer Datei mit fester Größe gespeichert. Unabhängig davon, wie oft Sie Metriken senden oder wie lange Sie sie senden, hat die Datei eine konstante Größe.

   Der Nachteil ist, dass ältere Daten eine geringere Auflösung haben und nach einem festgelegten Intervall (z. B. 1 Jahr) die Daten verworfen werden. Der Vorteil ist jedoch, dass es genauso schnell ist, einen Tag wie ein Jahr zu zeichnen, und die Größe der Messdaten mit der Zeit nicht zunimmt.

   In anderen Speichersystemen kann das Generieren eines Diagramms für ein Jahr das Abrufen von Millionen von Datenpunkten umfassen und eine enorme Menge an Datenspeicher erfordern.

   Der große Nachteil von Graphite ist, dass mit jeder Metrik eine neue Datei erstellt wird. Wenn Sie also dynamische Metriken haben (z. B. das Kommen und Gehen von Cloud-Boxen), ist dies möglicherweise keine gute Anpassung.

   Vergleichen Sie das mit Prometheus , wo Metriken meist nach Zeit gespeichert werden. Sie können viele dynamische Metriken haben, und es ist in Ordnung. Versuchen Sie jedoch nicht, diese Metriken langfristig zu speichern. Es wird ewig dauern, bis Sie sie erneut lesen.

   Keine Größe passt für alle.

   PS Graphana ist eine hervorragende Möglichkeit, Ihre Daten zu visualisieren. Es verfügt über Plug-Ins für die meisten Zeitreihendatenbanken.

2. Wer speichert Ihre Daten? Es gibt Tausende von Orten wie die , die Sie erwähnt haben. Es ist so einfach, eine Zeitreihen-DB in der Cloud aufzubauen, aber es ist WIRKLICH schwierig, damit Geld zu verdienen. Die meisten dieser Unternehmen werden nach einer Weile ihre Geschäftstätigkeit einstellen oder mit der Preisberechnung beginnen. (Selbst wenn die Preise stabil bleiben, sinken die Kosten ständig.) Oft stellen sie fest, dass sie nicht so viele neue Kunden anziehen können, wie sie möchten, und versuchen daher, die Preise zu erhöhen (unter dem Deckmantel) Änderung ihres Preismodells). Es stellt sich heraus, dass es eine Menge Geld kostet, alle Daten zu speichern ...

   Ich empfehle, sich selbst zu hosten oder einen seriösen Cloud-Anbieter wie AWS CloudWatch zu verwenden . (Teuer, wenn Sie viele Metriken haben, aber kostenlos für unter 50 Metriken!)

uBeac ist ein neues Freeware-Visualisierungswerkzeug, das wir entwickelt haben und es ist eine Beta-Version. Es ist keine Open Source, aber völlig kostenlos zu benutzen.

Sie können ein Gateway definieren und erhalten eine eindeutige URI. Sie können den URI in Ihrem Gateway oder Gerät so einstellen, dass HTTP / MQTT-Daten an gesendet werden.

Dies sind einige seiner Funktionen:

• Team, Gebäude, Grundrissdefinition
• Echtzeit-Datenvisualisierung
• Benutzerdefiniertes Dashboard-Design mit verschiedenen Widgets
• Definieren Sie Sensortypen, Einheiten und Präfixe
• ...

Es unterstützt auch das generische Json-Datenformat und verschiedene vordefinierte Gateways. Wenn Sie keine vordefinierten Payload-Formate verwenden möchten, können Sie Ihre benutzerdefinierte Payload-Verarbeitung entwickeln.

Ich bin überrascht, dass hier niemand Dweet erwähnte . Dies ist eine sehr einfache und unterhaltsame Möglichkeit, die Kommunikation zu verbessern. Sie sollten es auf jeden Fall ausprobieren, denn hey, es ist kostenlos!

flespi bietet kostenlose und kommerzielle Cloud-Dienste an:

• MQTT Broker - Service für PUB / SUB - Operationen und Sie können speichern die Daten sogar in den Nachrichten behalten ;
• Speicher-Engine für Schlüssel- / Wertevorgänge, speziell für Zeitreihendaten und generische Dateispeicherung (CDN). Arbeitet über die REST-API .

Haftungsausschluss: Ich arbeite für das Unternehmen, das die flespi-Plattform entwickelt. Ich habe zwar mein Bestes getan, um objektiv zu bleiben, aber bitte überprüfen Sie alle Informationen in dieser Antwort, um Verzerrungen auszuschließen, die sich auf Ihre Entscheidung auswirken könnten.