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.
:
Bearbeitet durch User
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.
1 | var socket = new WebSocket("ws://meinserver/"); |
2 | |
3 | socket.onmessage=function(e) { |
4 | console.log("Server sagt: "+e.data); |
5 | }; |
6 | |
7 | socket.send("Client Sagt: Hallo Server!"); |
8 | |
9 | |
10 | socket.close(); |
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 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.
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?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.