{"id":55356,"date":"2020-01-18T00:00:00","date_gmt":"2020-01-17T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/lytko-obedinyaet"},"modified":"2020-02-18T14:03:28","modified_gmt":"2020-02-18T11:03:28","slug":"lytko-obedinyaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/lytko-obedinyaet","title":{"rendered":"Lytko vereint","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vor einiger Zeit haben wir Ihnen ein intelligentes Thermostat<\/a><\/noindex>. Der aktuelle Artikel sollte urspr\u00fcnglich als Demonstration seiner Firmware und des Steuerungssystems dienen. Um jedoch die Funktionsweise des Thermostats und das, was wir umgesetzt haben, zu erkl\u00e4ren, ist es notwendig, das gesamte Konzept insgesamt zu umrei\u00dfen.<\/p>\n

\"Lytko
\n<\/a><\/noindex><\/p>\n

Zur Automatisierung<\/h3>\n

\nGrunds\u00e4tzlich l\u00e4sst sich die gesamte Automatisierung in drei Kategorien unterteilen:
\nKategorie 1<\/u> \u2014 einzelne \u201esmarte\u201c Ger\u00e4te. Sie erwerben von verschiedenen Herstellern Gl\u00fchbirnen, Wasserkocher usw. Vorteile: Jedes Ger\u00e4t erweitert die M\u00f6glichkeiten und erh\u00f6ht den Komfort. Nachteile: F\u00fcr jeden neuen Hersteller wird eine eigene App ben\u00f6tigt. Die Protokolle von Ger\u00e4ten unterschiedlicher Hersteller sind oft nicht miteinander kompatibel.<\/p>\n

Kategorie 2<\/u> \u2014 Installation eines Einplatinencomputers oder x86-kompatiblen Systems. Dies hebt die Einschr\u00e4nkungen der Rechenleistung auf, und auf dieser Maschine wird MajorDoMo oder eine andere Server-Distribution zur Steuerung des Smart Homes installiert. So werden die Ger\u00e4te der meisten Hersteller in einem einheitlichen Informationsraum verbunden. Das hei\u00dft, es entsteht ein eigener Server f\u00fcr das Smart Home. Vorteile: Kompatibilit\u00e4t unter einem zentralen System, das erweiterte M\u00f6glichkeiten f\u00fcr die Steuerung bietet. Nachteile: Bei einem Ausfall des Servers f\u00e4llt das gesamte System wieder in die Stufe 1 zur\u00fcck, d.h. es wird auseinandergerissen oder wird nutzlos.<\/p>\n

Kategorie 3<\/u> \u2014 die extremste Variante. In der Planungsphase werden alle Kommunikationsleitungen verlegt und alle Systeme redundant ausgelegt. Vorteile: Alles wird bis ins kleinste Detail perfektioniert und somit wird das Haus tats\u00e4chlich intelligent. Nachteile: extrem hohe Kosten im Vergleich zu den Kategorien 1 und 2, und die Notwendigkeit, alles im Voraus zu planen und jedes Detail zu ber\u00fccksichtigen.<\/p>\n

Die meisten Nutzer w\u00e4hlen die Variante eins und wechseln dann schrittweise zu Variante zwei. Und schlie\u00dflich erreichen die best\u00e4ndigsten die Variante 3. <\/p>\n

Es gibt jedoch eine Variante, die man als verteiltes System bezeichnen kann: Jedes einzelne Ger\u00e4t fungiert sowohl als Server als auch als Client. Im Grunde genommen ist dies der Versuch, die Variante 1 und Variante 2 zu vereinen. Alle Vorteile zu vereinen und die Nachteile auszuschlie\u00dfen, um die goldene Mitte zu finden. <\/p>\n

Vielleicht wird jemand sagen, dass eine \u00e4hnliche L\u00f6sung bereits entwickelt wurde. Aber solche L\u00f6sungen sind spezialisierte Ans\u00e4tze; sie richten sich an Menschen mit Programmierkenntnissen. Unser Ziel ist es, die Einstiegsh\u00fcrde f\u00fcr solche verteilten Systeme sowohl auf der Ebene der Endger\u00e4te als auch bei der Integration bestehender Ger\u00e4te in unser System zu senken. Im Fall des Thermostats entfernt der Nutzer einfach seinen alten Thermostat, installiert einen smarten und verbindet seine vorhandenen Sensoren mit diesem. Ohne zus\u00e4tzliche Ma\u00dfnahmen.<\/p>\n

Betrachten wir die Integration in unser System am Beispiel. <\/p>\n

Nehmen wir an, dass wir in unserem Netzwerk 8 Sonoff-Module haben. Einige Benutzer ben\u00f6tigen lediglich die Steuerung \u00fcber die Sonoff-Cloud (Kategorie 1). Andere werden eine Drittanbieter-Firmware verwenden und nahtlos in Kategorie 2 wechseln. Der Gro\u00dfteil der Drittanbieter-Firmwares funktioniert nach dem gleichen Prinzip: Daten\u00fcbertragung an einen MQTT-Server. OpenHub, Majordomo oder jeder andere haben ein gemeinsames Ziel \u2013 disparate Ger\u00e4te in einen einheitlichen Informationsraum zu integrieren, der entweder im Internet oder im lokalen Netzwerk liegt. Daher ist das Vorhandensein eines Servers unerl\u00e4sslich. Daraus ergibt sich das Hauptproblem \u2013 im Falle eines Ausfalls des Servers funktioniert das gesamte System nicht autonom. Um dies zu verhindern, werden die Systeme komplexer, es werden manuelle Steuerungsm\u00f6glichkeiten hinzugef\u00fcgt, die die Automatisierung im Falle eines Serverausfalls duplizieren. <\/p>\n

Wir sind jedoch einen anderen Weg gegangen, bei dem jedes Ger\u00e4t autark ist. Dadurch spielt der Server keine entscheidende Rolle, sondern erweitert nur die Funktionalit\u00e4t.<\/p>\n

Lass uns zu diesem gedanklichen Experiment zur\u00fcckkehren. Nehmen wir wieder die gleichen 8 Sonoff-Module und installieren die Firmware Lytko darauf. In allen Lytko-Firmwares wurde die Funktion implementiert SSDP<\/a><\/noindex>. SSDP ist ein Netzwerkprotokoll, das auf einer Sammlung von Internetprotokollen basiert und dazu dient, Netzwerkdienste zu deklarieren und zu entdecken. Die Antwort auf eine Anfrage kann sowohl standardm\u00e4\u00dfig als auch erweitert sein. Wir haben in diese Antwort neben den Standardfunktionen die Erstellung einer Ger\u00e4tesliste im Netzwerk integriert. So finden sich die Ger\u00e4te gegenseitig und jedes von ihnen hat eine solche Liste. Beispiel f\u00fcr eine SSDP-Liste:<\/p>\n

\"ssdpList\": \n\t{\n\t\t\"id\": 94967291,  \n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"thermostat\"\n\t}, \n\t{\n\t\t\"id\": 94967282,\n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"thermostat\"\n\t}<\/code><\/pre>\n
\nWie im Beispiel zu sehen ist, umfasst die Liste die IDs der Ger\u00e4te, die IP-Adresse im Netzwerk, den Blocktyp (in unserem Fall ein Thermostat, das auf Sonoff basiert). Diese Liste wird alle zwei Minuten aktualisiert (diese Zeitspanne ist ausreichend, um auf dynamische \u00c4nderungen der Anzahl der Ger\u00e4te im Netzwerk zu reagieren). Somit verfolgen wir das Hinzuf\u00fcgen, \u00c4ndern und Trennen von Ger\u00e4ten, ohne dass der Benutzer eingreifen muss. Diese Liste wird an den Browser oder die mobile Anwendung gesendet, und das Skript erstellt automatisch eine Seite mit der angegebenen Anzahl an Bl\u00f6cken. Jeder Block entspricht einem Ger\u00e4t\/Sensor\/Controller. Visuell sieht die Liste so aus:<\/p>\n
\"Lytko
\n
\nAber was ist, wenn andere Funk-Sensoren \u00fcber cc2530 (ZigBee) oder nrf24 (MySensors) mit esp8266\/esp32 verbunden sind? <\/p>\n
\u00dcber Projekte<\/h3>\n
\nAuf dem Markt gibt es verschiedene verteilte Systeme. Unser System erm\u00f6glicht die Integration mit den beliebtesten. <\/p>\n
Nachfolgend sind Projekte aufgef\u00fchrt, die versuchen, die Kompatibilit\u00e4tsprobleme zwischen verschiedenen Herstellern zu ver\u00e4ndern. Dazu geh\u00f6rt beispielsweise SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> oder ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> ist an einen MQTT-Server gebunden, daher ist es f\u00fcr dieses Beispiel nicht geeignet. <\/p>\n
Eine der Implementierungsvarianten von MySensors ist ein auf ESP8266 basierendes Gateway. Die anderen Beispiele basieren auf ESP32. In ihnen k\u00f6nnen wir unser Arbeitsprinzip zur Erkennung und Erstellung einer Ger\u00e4teliste einf\u00fcgen. <\/p>\n
Lassen Sie uns ein weiteres Gedankenexperiment durchf\u00fchren. Wir haben ein Gateway ZESP32 oder SLS Gateway oder MySensors. Wie k\u00f6nnen wir sie in einem einheitlichen Informationsraum zusammenf\u00fchren? Zu den Standardfunktionen dieser Gateways f\u00fcgen wir die SSDP-Protokollbibliothek hinzu. Wenn auf dieses Gateway \u00fcber SSDP zugegriffen wird, f\u00fcgt es der Standardantwort eine Liste der daran angeschlossenen Ger\u00e4te hinzu. Basierend auf diesen Informationen erstellt der Browser die Seite. In allgemeiner Form wird dies so aussehen:<\/p>\n
\"Lytko
\nWeboberfl\u00e4che<\/i><\/p>\n
\"Lytko
\nPWA-Anwendung<\/i><\/p>\n
\"ssdpList\": \n{\n   \"id\": 94967291, \/\/ eindeutige Ger\u00e4te-ID\n   \"ip\": \"192.168.x.x\", \/\/ IP-Adresse im Netzwerk\n   \"type\": \"thermostat\" \/\/ Ger\u00e4tetyp\n},\n{\n   \"id\": 94967292,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"thermostat\"\n},\n{\n   \"id\": 94967293,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"thermostat\"\n},\n{  \n   \"id\": 13587532, \n   \"type\": \"switch\"  \n},\n{  \n   \"id\": 98412557, \n   \"type\": \"smoke\"\n},\n{  \n   \"id\": 57995113, \n   \"type\": \"contact_sensor\"\n},\n{  \n   \"id\": 74123668,\n   \"type\": \"temperature_humidity_pressure_sensor\"\n},\n{\n    \"id\": 74621883, \n    \"type\": \"temperature_humidity_sensor\"\n}\n<\/code><\/pre>\n
\nAus dem Beispiel geht hervor, dass die Ger\u00e4te unabh\u00e4ngig voneinander hinzugef\u00fcgt werden. Es sind 3 Thermostate mit eigenen IP-Adressen und 5 verschiedene Sensoren mit einzigartigen IDs angeschlossen. Wenn der Sensor mit dem WLAN verbunden ist, hat er seine eigene IP, wenn er mit dem Gateway verbunden ist, ist die IP-Adresse des Ger\u00e4ts die des Gateways.<\/p>\n
Zur Kommunikation mit den Ger\u00e4ten nutzen wir WebSocket. Dies minimalisiert den Ressourcenaufwand im Vergleich zu GET-Anfragen und erm\u00f6glicht es, Informationen dynamisch bei Verbindung oder \u00c4nderung zu erhalten. <\/p>\n
Die Daten werden direkt von dem Ger\u00e4t bezogen, dem der Block geh\u00f6rt, ohne den Server zu durchlaufen. So l\u00e4uft das System auch bei Ausfall eines der Ger\u00e4te weiter. Im Web-Interface wird lediglich das fehlende Ger\u00e4t nicht angezeigt. Bei Bedarf wird jedoch ein Signal \u00fcber den Verlust in Form einer Benachrichtigung an die Benutzeranwendung gesendet. <\/p>\n
Der erste Versuch zur Umsetzung eines solchen Ansatzes war die PWA-Anwendung. Dadurch kann die Datenbasis der Bl\u00f6cke auf dem Ger\u00e4t des Benutzers gespeichert werden, und es werden nur die notwendigen Daten angefragt. Aufgrund der Strukturmerkmale ist diese Variante jedoch unvollst\u00e4ndig. Der einzige Ausweg ist eine native Anwendung f\u00fcr Android und iOS, die sich derzeit in aktiver Entwicklung befindet. Standardm\u00e4\u00dfig wird die Anwendung nur im internen Netzwerk funktionieren. Bei Bedarf kann alles auf externe Verwaltung umgestellt werden. So wechselt die Anwendung automatisch in die Cloud, wenn der Benutzer das lokale Netzwerk verl\u00e4sst. <\/p>\n
Die externe Verwaltung ist eine vollst\u00e4ndige Duplikation der Seite. Bei Aktivierung der Seite kann sich der Benutzer auf dem Server einloggen und die Ger\u00e4te \u00fcber sein pers\u00f6nliches Dashboard steuern. So erweitert der Server die Funktionalit\u00e4t und erm\u00f6glicht die Steuerung der Ger\u00e4te von au\u00dferhalb des Hauses, ohne an Portweiterleitungen oder eine feste IP gebunden zu sein.<\/p>\n
Damit ist die oben beschriebene Variante frei von Nachteilen des serverseitigen Ansatzes und bietet mehrere Vorteile in Form von Flexibilit\u00e4t bei der Anbindung neuer Ger\u00e4te.<\/p>\n
\u00dcber den Thermostat<\/h3>\n
\nSchauen wir uns das Management-System am Beispiel unseres Thermostats an.<\/p>\n
Vorgesehen sind:<\/p>\n
    \n
  1. Regelung der Temperatur jedes Thermostats (als einzelner Block angezeigt);<\/li>\n
  2. Einstellung eines Arbeitsplans f\u00fcr den Thermostat (Morgen, Tag, Abend, Nacht);<\/li>\n
  3. Auswahl des WLAN-Netzwerks und Verbindung des Ger\u00e4ts damit;<\/li>\n
  4. Firmware-Updates \"over the air\";<\/li>\n
  5. MQTT-Konfiguration;<\/li>\n
  6. Einstellung des Netzwerks, mit dem das Ger\u00e4t verbunden ist.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nNeben der Steuerung \u00fcber die Web-Oberfl\u00e4che haben wir auch eine klassische Steuerung durch Ber\u00fchrung des Displays vorgesehen. An Bord befindet sich ein 2,4-Zoll-Nextion-Monitor NX3224T024. Die Wahl fiel auf ihn aufgrund der einfachen Handhabung mit dem Ger\u00e4t. Es befindet sich jedoch ein eigener Monitor auf Basis von STM32 in der Entwicklung. Sein Funktionsumfang ist nicht schlechter als der von Nextion, wird jedoch kosteng\u00fcnstiger sein, was sich positiv auf den Endpreis des Ger\u00e4ts auswirkt.<\/p>\n
    \"Lytko
    \n
    \nWie jeder respektable Thermostat-Bildschirm kann unser Nextion:<\/p>\n