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
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?
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 :-)
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...
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
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.
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.
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.
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
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.
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.
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.
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
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
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^^
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?
