Forum: Haus & Smart Home Welche Technologie für Cloudanbindung?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jens (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum,

als Elektrotechniker und embedded SW-Entwickler stehe ich z.Zt. der 
Frage gegenüber, welche Technologie(n) geeignet ist für die Verbindung 
zwischen meiner "Smart-Home-Zentrale" und meinem "Cloud-Server". 
Constraint: Die Zentrale baut selbständig die Verbindung nach Außen auf.

Meine "Smart-Home-Zentrale" ist dabei ein Raspberry Pi mit GNU/Linux, 
steuert zu Hause ein paar Sachen und liest ein paar Sensoren aus. Das 
klappt so natürlich auch mit anderen Plattformen (Arduino, etc.).

Der "Cloud-Server" ist auf heroku.com gehostet und erlaubt es Clients 
via Webbrowser über HTTP eine WebSocket Verbindung aufzubauen. 
Cloud-Server und Client(s) tauschen dann Information im JSON-Format aus. 
So kann ich Steuerbefehle senden und Sensoren abfragen.

Aber was wäre nun besonders geeignet für die Verbindung dieser beiden 
zentralen Elemente?

[SmartHomeZentrale]----???----[CloudServer]----HTTP/WebSocket----[Client 
]

Mein Ansatz:
Damit das Konzept ohne Konfiguration von WLAN-Router, etc. funktioniert 
habe ich mich ebenfalls für HTTP/WebSocket entschiedenen, denn HTTP bzw. 
Port 80 von Innen nach Außen und ein keep-connection-alive für WebSocket 
scheint gut zu funktionieren ohne das irgendwelcher Filter/Firewalls da 
etwas blockieren.

Nachteil des Ansatzes:
Das Programm meiner Smart-Home-Zentrale muss nun HTTP-Client spielen und 
eine WebSocket-Verbindung aufbauen. Dafür habe ich momentan den 
WebSocket-Handshake eines Browsers via HTTP mitgeschnitten und manuell 
nachimplementiert.

Was wären denn nun Alternativen?
- existierende libs/module für WebSocket verwenden
- ganz andere libs/module die für diesen Zweck verwenden? (Pusher?, 
RESTful Protokolle?)

...an diesem Punkt fühle ich mich wie im Jungle der aus tausenden 
Web-Technologies besteht. E-Techniker fühlen hoffentlich mit mir :-)

Vielleicht bin ich ja auf dem richtigen Weg, weiss es aber nicht?

Danke für Tipps!
Jens

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was hast du auf server side und wie schnell brauchst du den response? 
Realtime, 1 sec 10 sec? ...
Welches limit wegen datenaufkommen besteht auf dem server?

von Jens (Gast)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Was hast du auf server side
Den Server habe ich mit Node.js gemacht.

> und wie schnell brauchst du den
> response?
> Realtime, 1 sec 10 sec? ...
Bzgl. Realtime: Es sollte so sein, dass manuelle Steuerung gefühlt ohne 
Zeitverlust geschieht. Das habe ich auch schon erreicht. Die Latenz 
entspricht ungefähr dem Ping vom Client zu Server plus Server zu 
Zentrale.

> Welches limit wegen datenaufkommen besteht auf dem server?
Da bin ich für alles offen, was für eine schicke Lösung notwendig wäre. 
Ich schätze aber mal, dass die paar Steuerinformationen im Vergleich zu 
heutigen Webseiten nicht relevant sind. Momentan bewege ich mich im 
dreistelligen Byte/s Bereich :-)

von TestX .. (xaos)


Bewertung
2 lesenswert
nicht lesenswert
wie wäre es mit einer einfachen tcp verbindung mit ssl (persistent) und 
dadrüber einfach json nachrichten ?

benutze ich seit jahren selbst im industriellen umfeld...

klar geht auch SOAP oder so...allerdings ist das in 99% der fälle 
wirklich overkill und macht das ganze nicht gerade wartungsfreundlich...

von Jens (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andi ... schrieb:
> wie wäre es mit einer einfachen tcp verbindung mit ssl
> (persistent) und
> dadrüber einfach json nachrichten ?
>
> benutze ich seit jahren selbst im industriellen umfeld...

Was für einProtokoll verwendest Du? Ein eigenes oder einen bekannten 
Standard wie z.B. Modbus over TCP?

Machst Du das über Port 80? Da ich mein System gern an verschiedenen 
Orten einsetze möchte, möchte ich möglichst nicht durch eine Firewall 
o.ä. behindert werden. D.h. es sollte überall dort funktionieren, wo 
auch ein lokaler Webbrowser einen HTTP-Server im Internet erreichen 
kann. Wenn nicht nur der ausgehende Port sondern auch die Inhalte HTTP 
sein müssen (gibt es überhaupt Firewalls, welche dies prüfen?) dann 
würde es wohl nicht mehr funktionieren. Und wenn man einen 
HTTP-Proxyserver benutzen muss, dann geht es sicherlich nicht mehr. Mit 
WebSocket via HTTP müsste es da noch klappen, sofern Firewall bzw. Proxy 
so nett sind und WebSocket kennen/erlauben.

Mich würde auch interessieren was die ganzen kommerziellen, 
Cloud-basierten Smart Home Systeme einsetzen. Wer da etwas zu sagen 
kann, ich wäre dankbar.

Ich bin mit meinem Ansatz zwar total zufrieden aber mich würden die 
möglichen Alternativen interessieren.

Grüße
Jens

von Linksammler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Evtl. mal einen Blick auf MQTT werfen.

ist recht leichtgewichtig (Kriegt man sogar in einen ESP8266 rein) und 
hat einige nette Features für den Anwendungsfall.

z.B. kann der letzte Zustand gespeichert werden. (d.H. Licht bleibt an, 
auch wenn Zwischendurch ein DSL-Reconnect passiert)

Oder Teilnehmer können vorab ein "Testament" hinterlegen, was passieren 
soll, wenn sie getrennt werden.

mit MQTT-Über-Websocket kriegt man auch sehr einfach schöne 
Visualisierungen und Bedienoberflächen hin, die komplett "Live" 
funktionieren.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Wenn Du es nicht zwingend von einem im Browser laufenden JavaScript aus 
ansprechen können musst sondern nur von einem eigenen kleinen standalone 
client dann brauchst Du (solltest Du) Dir den ganzen Websocket-Overhead 
ersparen und eine simple TCP-Verbindung aufbauen und ganz pragmatisch 
Dein eigenes Protokoll drüber fahren.

Die einzige Rechtfertigung für Websocket ist die Tatsache daß wenn Du 
einen Client in einem Webrowser in Javascript implementieren willst dann 
wird das ganze monströse (unter der Haube) Websocket-Gedöns schon von 
Haus aus schön verpackt vom Browser zur Verfügung gestellt und Du musst 
nur noch 3 simple Zeilen JS hinschreiben um es zu nutzen.

In allen anderen Fällen ist das Websocket Ungetüm hoffnungsloser 
Overkill hoch 12. Wenn Du aus welchem Grund auch immer gezwungen bist es 
zu nutzen dann kommst Du um funktionierende fertige libs nicht herum, es 
sei denn Du hast eine ausgeprägte masochistische Veranlagung.

: Bearbeitet durch User
von Linksammler (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> In allen anderen Fällen ist das Websocket Ungetüm hoffnungsloser
> Overkill hoch 12.

Achtung:
socket.io und Websockets sind nicht dasselbe.

Websockets selber sind sehr leichtgewichtig.

socket.io macht erst ein "Ungetüm" daraus, weil es u.A. versucht, 
fehlende Websocket-Implementationen in Browsern durch Polling zu 
ersetzen.

Wenn du sicher bist, dass nur aktuelle Browser verwendet werden, dann 
ist ein Websockets ganz ohne Library in einer Zeile geöffnet.
var socket = new WebSocket("ws://meinserver/");

socket.onmessage=function(e) {
  console.log("Server sagt: "+e.data);
};

socket.send("Client Sagt: Hallo Server!");


socket.close();

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
Linksammler schrieb:
> Wenn du sicher bist, dass nur aktuelle Browser verwendet werden, dann
> ist ein Websockets ganz ohne Library in einer Zeile geöffnet.

Ja, aber wenn er auf beiden Seiten gar keinen Browser verwendet dann ist 
Websocket hoffnungslos überdimensioniert, denn "mal eben" Websocket zu 
implementieren ohne Library wird ein mehrmonatiger Zeitvertreib (ohne 
Spaß) für lange eingeschneite Winterabende, nur unterbrochen von 
gelegentlichen lauten Fluchen auf die Google-Programmierer die sich das 
unter offensichtlichem Einfluß von Substanzen ausgedacht haben und 
gelegentlichen durch die Wohnung fliegenden Computerteilen. Wirf mal 
einen Blick auf das RFC: https://tools.ietf.org/html/rfc6455

von Linksammler (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Ja, aber wenn er auf beiden Seiten gar keinen Browser verwendet dann ist
> Websocket hoffnungslos überdimensioniert,

Wer kommt denn Bitte auf so eine Bescheuerte Idee, Websockets zu 
verwenden, wo garkein "Web" im Spiel ist?

Deswegen: MQTT. Da wo's einfach sein soll, ist es einfach.
also
 Aktor/Sensor <-> Zentrale.
oder
 Steuergerät <-> Zentrale.

mit minimalem Overhead ggü. Plain-TCP, aber großem Zusatznutzen.


Da wo "Web" im Spiel ist, geht ganz einfach ohne große Entwicklung 
Websocket, also z.B. für
 Zentrale <-> Webbrowser/Handy/Tablet.

So hat der Entwicker an jeder Stelle das passende Werkzeug.

von Je N. (ejsn)


Bewertung
0 lesenswert
nicht lesenswert
Hinweis: Ich bin der OP, habe mich jetzt hier angemeldet.

Bernd K. schrieb:
> Linksammler schrieb:
>> Wenn du sicher bist, dass nur aktuelle Browser verwendet werden, dann
>> ist ein Websockets ganz ohne Library in einer Zeile geöffnet.
>
> Ja, aber wenn er auf beiden Seiten gar keinen Browser verwendet dann ist
> Websocket hoffnungslos überdimensioniert, denn "mal eben" Websocket zu
> implementieren ohne Library wird ein mehrmonatiger Zeitvertreib (ohne

Naja, also ich hab einen Tag, die RFC6455 und einen tcpdump zwischen 
Chrome und meinem Server gebraucht. Wenn man die RFC6455 durcharbeitet 
merkt man, dass es nicht viel ist, was da getan werden muss.

Das Problem war viel mehr die Anwendungsschicht, welche RFC6455 nicht 
festlegt. Da ich auf meinem Server socket.io hatte musste ich dessen 
Sprache nachsprechen (daher auch der tcpdump). Das übernimmt ja 
normalerweise der socket.io-client (JavaScript-Schnippsel für den 
Browser) welchen ich ignoriere.

Nun, trotzdem gebe ich jedem Recht der hier schreibt, dass für diese 
Verbindung WebSockets nicht am sinnvollsten ist... Hin zu kommt, dass 
wenn auf dem Server in Zukunft eine neue Version von socket.io verwendet 
wird und sich der socket.io-client ändert die Chancen hochstehen, dass 
meine Lösung nicht mehr funktioniert. Also, wie schon erwähnt, höchst 
suboptimale Lösung.

von Je N. (ejsn)


Bewertung
0 lesenswert
nicht lesenswert
Linksammler schrieb:
> Evtl. mal einen Blick auf MQTT werfen.
>
> ist recht leichtgewichtig (Kriegt man sogar in einen ESP8266 rein) und
> hat einige nette Features für den Anwendungsfall.
>
> z.B. kann der letzte Zustand gespeichert werden. (d.H. Licht bleibt an,
> auch wenn Zwischendurch ein DSL-Reconnect passiert)
>
> Oder Teilnehmer können vorab ein "Testament" hinterlegen, was passieren
> soll, wenn sie getrennt werden.
>
> mit MQTT-Über-Websocket kriegt man auch sehr einfach schöne
> Visualisierungen und Bedienoberflächen hin, die komplett "Live"
> funktionieren.

Interessant, Danke für den Hinweis! Genau so Antwort habe ich gesucht 
:-) Ich sehe auch gerade, dass dieses "Wunderbar" IoT-Dinges Kit von 
Relayr auch MQTT verwendet.

von Je N. (ejsn)


Bewertung
0 lesenswert
nicht lesenswert
Linksammler schrieb:
> Bernd K. schrieb:
>> Ja, aber wenn er auf beiden Seiten gar keinen Browser verwendet dann ist
>> Websocket hoffnungslos überdimensioniert,
>
> Wer kommt denn Bitte auf so eine Bescheuerte Idee, Websockets zu
> verwenden, wo garkein "Web" im Spiel ist?

Das war dieser OP-Typ :-) Für mich hatte dies den Vorteil, dass ich 
einen beliebigen WebBrowser verwenden konnte, um in die Kommunikation 
zwischen Cloud und Home-Zentrale einzugreifen (mitlesen und manuell 
Kommandos senden). Und da alle Clients diese Technologie auch verwenden, 
war es auf Serverseite schon "da".

> Deswegen: MQTT. Da wo's einfach sein soll, ist es einfach.
> also
>  Aktor/Sensor <-> Zentrale.
> oder
>  Steuergerät <-> Zentrale.
>
> mit minimalem Overhead ggü. Plain-TCP, aber großem Zusatznutzen.
>
> Da wo "Web" im Spiel ist, geht ganz einfach ohne große Entwicklung
> Websocket, also z.B. für
>  Zentrale <-> Webbrowser/Handy/Tablet.
>
> So hat der Entwicker an jeder Stelle das passende Werkzeug.

Ich bin überzeugt, Danke :-)

Grüße
Jens

von Old P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Was hast du auf server side und wie schnell brauchst du den response?
> Realtime, 1 sec 10 sec? ...
> Welches limit wegen datenaufkommen besteht auf dem server?

Ist das noch Deutsch oder ist das schon Kunst?

Duck & weg
Old-Papa

von Christian B. (casandro) Flattr this


Bewertung
0 lesenswert
nicht lesenswert
Also nehmt es mir nicht übel, aber MQTT ließt sich schon so als ob das 
noch überkomplex wäre. Aber immerhin um Welten besser als OPC.

von KeinPlan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also ich habe keine Ahnung was du eigtl. willst, weil ich nur die Hälfte 
verstehe, aber wenn du doch eh einen Raspberry hast, warum installierst 
du dir keinen Apache2 Server Dienst mit MySqol datenbank und haust dann 
noch "owncloud" oben drauf.

Dann st deine Smart-Home Zentrale auch zugleich dein Cloud-Server. Und 
auf den kannst du dann per http (oder sogar https) zugreifen^^

von Je N. (ejsn)


Bewertung
0 lesenswert
nicht lesenswert
KeinPlan schrieb:
> Also ich habe keine Ahnung was du eigtl. willst, weil ich nur die Hälfte
> verstehe, aber wenn du doch eh einen Raspberry hast, warum installierst
> du dir keinen Apache2 Server Dienst mit MySqol datenbank und haust dann
> noch "owncloud" oben drauf.
>
> Dann st deine Smart-Home Zentrale auch zugleich dein Cloud-Server. Und
> auf den kannst du dann per http (oder sogar https) zugreifen^^

Dann würde ich ja als Anwender eine Verbindung direkt zur "Smart-Home 
Zentrale" aufbauen müssen. Nachteile:
- Ich muss deren öffentliche IP kennen, wenn ich unterwegs bin
- Die öffentliche IP ändert sich leider täglich
- Der Router muss erst konfiguriert werden, damit ich von Außen Zugriff 
habe
- Da ich von unterwegs auf verschiedene "Smart-Home Zentralen" zugreifen 
möchte multiplizieren sich die obigen Probleme und zudem kann ich nicht 
mehr ein UI für alle verwenden

Zu dem klingt Apache, MySQL und Owncloud eher nach einer Cloudlösung zum 
abspeichern/teilen von Daten und nicht zum steuern von SmartHomes in 
Echtzeit. Vielleicht unterschätze ich Owncloud ja?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.