{"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\/novosti-interneta\/lytko-obedinyaet","title":{"rendered":"Lytko vereint","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vor einiger Zeit haben wir Ihnen vorgestellt ein intelligentes Thermostat<\/a><\/noindex>. Der aktuelle Artikel war urspr\u00fcnglich als Demo seiner Firmware und Steuerungssystem gedacht. Um jedoch die Logik des Thermostats und das, was wir implementiert haben, zu erkl\u00e4ren, ist es notwendig, das gesamte Konzept zu umrei\u00dfen.<\/p>\n

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

Zur Automatisierung<\/h3>\n

\nZun\u00e4chst kann man die 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 ist eine eigene App notwendig. Die Protokolle der Ger\u00e4te verschiedener Hersteller sind oft nicht miteinander kompatibel.<\/p>\n

Kategorie 2<\/u> \u2014 Installation eines Einplatinencomputers oder eines x86-kompatiblen Systems. Dadurch werden die Einschr\u00e4nkungen der Rechenleistung aufgehoben, und auf dieses Ger\u00e4t kann MajorDoMo oder eine andere Server-Distribution zur Verwaltung des Smart Homes installiert werden. So werden die Ger\u00e4te der meisten Hersteller in einem gemeinsamen Informationsraum verbunden. Das hei\u00dft, es entsteht ein eigener Server f\u00fcr das Smart Home. Vorteile: Kompatibilit\u00e4t unter einem zentralen Punkt, was erweiterte Managementm\u00f6glichkeiten bietet. Nachteile: Bei einem Ausfall des Servers wird das gesamte System auf den Ausgangszustand 1 zur\u00fcckgesetzt, also wird es fragmentiert oder nutzlos.<\/p>\n

Kategorie 3<\/u> \u2014 die extremste Variante. In der Renovierungsphase werden alle Kommunikationen eingeplant und alle Systeme redundant ausgelegt. Vorteile: alles ist bis ins kleinste Detail perfektioniert, und das Haus wird wirklich smart. Nachteile: extrem hohe Kosten im Vergleich zu den Kategorien 1 und 2, Notwendigkeit, alles im Voraus zu planen und jedes Detail zu ber\u00fccksichtigen.<\/p>\n

Die meisten Benutzer w\u00e4hlen zun\u00e4chst Variante eins und wechseln dann allm\u00e4hlich zu Variante zwei. In der Folge erreichen die hartn\u00e4ckigsten schlie\u00dflich Variante drei. <\/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 es ein Versuch, Variante 1 und Variante 2 zu kombinieren. Alle Vorteile beider Ans\u00e4tze zu vereinen und die Nachteile zu eliminieren \u2013 die goldene Mitte zu finden. <\/p>\n

Vielleicht k\u00f6nnte jemand sagen, dass eine solche L\u00f6sung bereits entwickelt wurde. Doch solche Ans\u00e4tze sind sehr spezialisiert und richten sich an Personen mit Programmierkenntnissen. Unser Ziel ist es, die Einstiegsh\u00fcrden f\u00fcr solche verteilten Systeme zu senken, sowohl in der Form von Endger\u00e4ten als auch durch die Integration bestehender Ger\u00e4te in unser System. Im Fall eines Thermostats entfernt der Benutzer einfach seinen alten Thermostat, installiert einen intelligenten und verbindet die vorhandenen Sensoren damit. Ohne zus\u00e4tzliche Ma\u00dfnahmen.<\/p>\n

Lassen Sie uns die Integration in unser System anhand eines Beispiels betrachten. <\/p>\n

Stellen wir uns vor, wir haben 8 Sonoff-Module in unserem Netzwerk. Einige Nutzer werden mit der Steuerung \u00fcber die Sonoff-Cloud (Kategorie 1) zufrieden sein. Andere werden eine alternative Firmware verwenden und nahtlos in Kategorie 2 wechseln. Die meisten alternativen Firmwares arbeiten nach dem gleichen Prinzip: Daten\u00fcbertragung an einen MQTT-Server. OpenHub, Majordomo oder jede andere L\u00f6sung haben dasselbe Ziel \u2013 die Verkn\u00fcpfung von verstreuten Ger\u00e4ten in einen einheitlichen Informationsraum, der entweder im Internet oder im lokalen Netzwerk lokalisiert ist. Daher ist das Vorhandensein eines Servers unerl\u00e4sslich. Daraus ergibt sich das Hauptproblem \u2013 f\u00e4llt der Server aus, funktioniert das gesamte System nicht mehr autonom. Um dem entgegenzuwirken, werden die Systeme komplizierter, und es werden manuelle Steuerungsmethoden hinzugef\u00fcgt, die die Automatisierung im Falle eines Serverausfalls duplizieren. <\/p>\n

Wir haben uns f\u00fcr einen anderen Ansatz entschieden, bei dem jedes Ger\u00e4t autark ist. So spielt der Server keine entscheidende Rolle, sondern erweitert lediglich die Funktionalit\u00e4t.<\/p>\n

Lassen Sie uns zu unserem Gedankenexperiment zur\u00fcckkehren. Nehmen wir wieder die gleichen 8 Sonoff-Module und installieren die Lytko-Firmware. In allen Lytko-Firmwares ist eine Funktion integriert. SSDP<\/a><\/noindex>. SSDP \u2014 ein Netzwerkprotokoll, das auf einer Sammlung von Internetprotokollen basiert und zum Bekanntmachen und Entdecken von Netzwerkdiensten dient. Die Antwort auf eine Anfrage kann sowohl standardisiert als auch erweitert sein. Wir haben in dieser Antwort zus\u00e4tzlich zur Standardfunktion die Erstellung einer Liste von Ger\u00e4ten im Netzwerk integriert. So finden die Ger\u00e4te einander, 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, enth\u00e4lt die Liste die IDs der Ger\u00e4te, die IP-Adresse im Netzwerk und den Blocktyp (in unserem Fall ein Thermostat auf Basis von Sonoff). Diese Liste wird alle zwei Minuten aktualisiert, was ausreicht, um dynamischen \u00c4nderungen der Anzahl der Ger\u00e4te im Netzwerk gerecht zu werden. So \u00fcberwachen wir das Hinzuf\u00fcgen, \u00c4ndern und Abschalten von Ger\u00e4ten, ohne dass der Benutzer etwas unternehmen muss. Diese Liste wird an den Browser oder die mobile App gesendet, und das Skript erstellt automatisch die Seite mit der angegebenen Anzahl von 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 Funksensoren \u00fcber cc2530 (ZigBee) oder nrf24 (MySensors) an esp8266\/esp32 angeschlossen sind? <\/p>\n
\u00dcber Projekte<\/h3>\n
\nAuf dem Markt gibt es verschiedene verteilte Systeme. Unser System erm\u00f6glicht die Integration mit den bekanntesten. <\/p>\n
Im Folgenden sind Projekte aufgef\u00fchrt, die versuchen, die Situation der Inkompatibilit\u00e4t zwischen verschiedenen Herstellern zu ver\u00e4ndern. Dazu geh\u00f6ren beispielsweise SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> oder ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> basierend auf einem MQTT-Server, daher nicht f\u00fcr das Beispiel geeignet. <\/p>\n
Eine der Implementierungsoptionen f\u00fcr MySensors ist ein Gateway, das auf dem ESP8266 basiert. Die weiteren Beispiele verwenden den ESP32, und in diesen kann unser Prinzip zur Erkennung und Erstellung von Ger\u00e4telisten integriert werden. <\/p>\n
Lassen Sie uns ein weiteres gedankliches Experiment durchf\u00fchren. Wir haben das ZESP32-Gateway 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 Bibliothek des SSDP-Protokolls hinzu. Wenn man diesen Controller \u00fcber SSDP abruft, wird die Standardantwort um eine Liste der daran angeschlossenen Ger\u00e4te erg\u00e4nzt. Basierend auf diesen Informationen erstellt der Browser eine Seite. Insgesamt wird es so aussehen:<\/p>\n
\"Lytko
\nWeb-Interface<\/i><\/p>\n
\"Lytko
\nPWA-Anwendung<\/i><\/p>\n
"ssdpList": \n{\n   "id": 94967291, \/\/ \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u044b\u0439 \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430\n   "ip": "192.168.x.x", \/\/ ip \u0430\u0434\u0440\u0435\u0441 \u0432 \u0441\u0435\u0442\u0438\n   "type": "thermostat" \/\/ \u0442\u0438\u043f \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430\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
\nWie das Beispiel zeigt, werden die Ger\u00e4te unabh\u00e4ngig voneinander hinzugef\u00fcgt. Es sind 3 Thermostate mit eigenen IP-Adressen und 5 verschiedene Sensoren mit einzigartigen IDs angeschlossen. Ist der Sensor mit dem Wi-Fi-Netzwerk verbunden, hat er eine eigene IP-Adresse. Bei einer Verbindung zum Gateway ist die IP-Adresse des Ger\u00e4ts die IP-Adresse des Gateways.<\/p>\n
Zur Kommunikation mit den Ger\u00e4ten verwenden wir WebSocket. Dies minimiert den Ressourcenaufwand im Vergleich zu GET-Anfragen und erm\u00f6glicht das dynamische Abrufen von Informationen bei Verbindungen oder \u00c4nderungen. <\/p>\n
Die Daten werden direkt von dem Ger\u00e4t abgerufen, dem das Modul geh\u00f6rt, und umgehen den Server. So bleibt das System auch bei Ausfall eines Ger\u00e4tes funktionsf\u00e4hig. Im Web-Interface wird lediglich das fehlende Ger\u00e4t nicht angezeigt. Bei Bedarf wird jedoch eine Benachrichtigung im Benutzer-Interface \u00fcber den Verlust des Ger\u00e4ts gesendet. <\/p>\n
Der erste Versuch, einen solchen Ansatz umzusetzen, war eine PWA-Anwendung. Diese erm\u00f6glicht es, eine Datenbank von Bl\u00f6cken auf dem Ger\u00e4t des Benutzers zu speichern und nur die erforderlichen Daten abzurufen. Aufgrund der Strukturmerkmale ist dieses Modell jedoch unvollst\u00e4ndig. Die einzige L\u00f6sung ist eine native App f\u00fcr Android und iOS, die derzeit in aktiver Entwicklung ist. Standardm\u00e4\u00dfig wird die App nur im internen Netzwerk funktionieren. Bei Bedarf kann alles auf externe Steuerung umgestellt werden. So wird die App automatisch auf die Cloud umschalten, sobald der Benutzer das lokale Netzwerk verl\u00e4sst. <\/p>\n
Die externe Steuerung ist eine vollst\u00e4ndige Duplizierung der Seite. Wenn die Seite aktiviert wird, kann sich der Benutzer auf dem Server einloggen und die Ger\u00e4te \u00fcber das Benutzerkonto steuern. Auf diese Weise erweitert der Server die Funktionalit\u00e4t und erm\u00f6glicht es, Ger\u00e4te auch au\u00dferhalb des Hauses zu steuern, ohne an Portweiterleitungen oder eine dedizierte IP gebunden zu sein.<\/p>\n
Auf diese Weise ist die oben beschriebene Variante frei von Nachteilen des serverbasierten Ansatzes und bietet zudem zahlreiche Vorteile in Form von Flexibilit\u00e4t bei der Anbindung neuer Ger\u00e4te.<\/p>\n
\u00dcber den Thermostat<\/h3>\n
\nBetrachten wir das Managementsystem am Beispiel unseres Thermostats.<\/p>\n
Folgendes ist vorgesehen:<\/p>\n
    \n
  1. Regulierung der Temperatur jedes Thermostats (wird als einzelner Block angezeigt);<\/li>\n
  2. Einstellung des Zeitplans f\u00fcr den Betrieb des Thermostats (Morgen, Tag, Abend, Nacht);<\/li>\n
  3. Auswahl des Wi-Fi-Netzwerks und Verbindung des Ger\u00e4ts damit;<\/li>\n
  4. Ger\u00e4te-Updates \u201eover-the-air\u201c;<\/li>\n
  5. Einstellung von MQTT;<\/li>\n
  6. Konfiguration des Netzwerks, mit dem das Ger\u00e4t verbunden ist.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nNeben der Verwaltung \u00fcber die Web-Oberfl\u00e4che haben wir eine klassische Steuerung durch Ber\u00fchrung des Bildschirms vorgesehen. An Bord befindet sich ein Nextion NX3224T024 2,4 Zoll Monitor. Die Wahl fiel auf ihn aufgrund der Benutzerfreundlichkeit. Ein eigener Monitor auf Basis von STM32 ist jedoch in Entwicklung. Seine Funktionalit\u00e4t wird nicht schlechter sein als die des Nextion, er wird jedoch g\u00fcnstiger sein, was sich positiv auf den Endpreis des Ger\u00e4ts auswirkt.<\/p>\n
    \"Lytko
    \n
    \nWie jeder respektable Thermostatbildschirm kann unser Nextion:<\/p>\n