Vor einiger Zeit haben wir Ihnen . Der aktuelle Artikel sollte ursprünglich als Demonstration seiner Firmware und des Steuerungssystems dienen. Um jedoch die Funktionsweise des Thermostats und das, was wir umgesetzt haben, zu erklären, ist es notwendig, das gesamte Konzept insgesamt zu umreißen.
Zur Automatisierung
Grundsätzlich lässt sich die gesamte Automatisierung in drei Kategorien unterteilen:
Kategorie 1 — einzelne „smarte“ Geräte. Sie erwerben von verschiedenen Herstellern Glühbirnen, Wasserkocher usw. Vorteile: Jedes Gerät erweitert die Möglichkeiten und erhöht den Komfort. Nachteile: Für jeden neuen Hersteller wird eine eigene App benötigt. Die Protokolle von Geräten unterschiedlicher Hersteller sind oft nicht miteinander kompatibel.
Kategorie 2 — Installation eines Einplatinencomputers oder x86-kompatiblen Systems. Dies hebt die Einschränkungen der Rechenleistung auf, und auf dieser Maschine wird MajorDoMo oder eine andere Server-Distribution zur Steuerung des Smart Homes installiert. So werden die Geräte der meisten Hersteller in einem einheitlichen Informationsraum verbunden. Das heißt, es entsteht ein eigener Server für das Smart Home. Vorteile: Kompatibilität unter einem zentralen System, das erweiterte Möglichkeiten für die Steuerung bietet. Nachteile: Bei einem Ausfall des Servers fällt das gesamte System wieder in die Stufe 1 zurück, d.h. es wird auseinandergerissen oder wird nutzlos.
Kategorie 3 — 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ächlich 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ücksichtigen.
Die meisten Nutzer wählen die Variante eins und wechseln dann schrittweise zu Variante zwei. Und schließlich erreichen die beständigsten die Variante 3.
Es gibt jedoch eine Variante, die man als verteiltes System bezeichnen kann: Jedes einzelne Gerät 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ßen, um die goldene Mitte zu finden.
Vielleicht wird jemand sagen, dass eine ähnliche Lösung bereits entwickelt wurde. Aber solche Lösungen sind spezialisierte Ansätze; sie richten sich an Menschen mit Programmierkenntnissen. Unser Ziel ist es, die Einstiegshürde für solche verteilten Systeme sowohl auf der Ebene der Endgeräte als auch bei der Integration bestehender Geräte 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ätzliche Maßnahmen.
Betrachten wir die Integration in unser System am Beispiel.
Nehmen wir an, dass wir in unserem Netzwerk 8 Sonoff-Module haben. Einige Benutzer benötigen lediglich die Steuerung über die Sonoff-Cloud (Kategorie 1). Andere werden eine Drittanbieter-Firmware verwenden und nahtlos in Kategorie 2 wechseln. Der Großteil der Drittanbieter-Firmwares funktioniert nach dem gleichen Prinzip: Datenübertragung an einen MQTT-Server. OpenHub, Majordomo oder jeder andere haben ein gemeinsames Ziel – disparate Geräte in einen einheitlichen Informationsraum zu integrieren, der entweder im Internet oder im lokalen Netzwerk liegt. Daher ist das Vorhandensein eines Servers unerlässlich. Daraus ergibt sich das Hauptproblem – im Falle eines Ausfalls des Servers funktioniert das gesamte System nicht autonom. Um dies zu verhindern, werden die Systeme komplexer, es werden manuelle Steuerungsmöglichkeiten hinzugefügt, die die Automatisierung im Falle eines Serverausfalls duplizieren.
Wir sind jedoch einen anderen Weg gegangen, bei dem jedes Gerät autark ist. Dadurch spielt der Server keine entscheidende Rolle, sondern erweitert nur die Funktionalität.
Lass uns zu diesem gedanklichen Experiment zurückkehren. Nehmen wir wieder die gleichen 8 Sonoff-Module und installieren die Firmware Lytko darauf. In allen Lytko-Firmwares wurde die Funktion implementiert . 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äßig als auch erweitert sein. Wir haben in diese Antwort neben den Standardfunktionen die Erstellung einer Gerätesliste im Netzwerk integriert. So finden sich die Geräte gegenseitig und jedes von ihnen hat eine solche Liste. Beispiel für eine SSDP-Liste:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Wie im Beispiel zu sehen ist, umfasst die Liste die IDs der Geräte, 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 Änderungen der Anzahl der Geräte im Netzwerk zu reagieren). Somit verfolgen wir das Hinzufügen, Ändern und Trennen von Geräten, 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öcken. Jeder Block entspricht einem Gerät/Sensor/Controller. Visuell sieht die Liste so aus:
Aber was ist, wenn andere Funk-Sensoren über cc2530 (ZigBee) oder nrf24 (MySensors) mit esp8266/esp32 verbunden sind?
Über Projekte
Auf dem Markt gibt es verschiedene verteilte Systeme. Unser System ermöglicht die Integration mit den beliebtesten.
Nachfolgend sind Projekte aufgeführt, die versuchen, die Kompatibilitätsprobleme zwischen verschiedenen Herstellern zu verändern. Dazu gehört beispielsweise , oder . ist an einen MQTT-Server gebunden, daher ist es für dieses Beispiel nicht geeignet.
Eine der Implementierungsvarianten von MySensors ist ein auf ESP8266 basierendes Gateway. Die anderen Beispiele basieren auf ESP32. In ihnen können wir unser Arbeitsprinzip zur Erkennung und Erstellung einer Geräteliste einfügen.
Lassen Sie uns ein weiteres Gedankenexperiment durchführen. Wir haben ein Gateway ZESP32 oder SLS Gateway oder MySensors. Wie können wir sie in einem einheitlichen Informationsraum zusammenführen? Zu den Standardfunktionen dieser Gateways fügen wir die SSDP-Protokollbibliothek hinzu. Wenn auf dieses Gateway über SSDP zugegriffen wird, fügt es der Standardantwort eine Liste der daran angeschlossenen Geräte hinzu. Basierend auf diesen Informationen erstellt der Browser die Seite. In allgemeiner Form wird dies so aussehen:
Weboberfläche
PWA-Anwendung
"ssdpList":
{
"id": 94967291, // eindeutige Geräte-ID
"ip": "192.168.x.x", // IP-Adresse im Netzwerk
"type": "thermostat" // Gerätetyp
},
{
"id": 94967292,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967293,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 13587532,
"type": "switch"
},
{
"id": 98412557,
"type": "smoke"
},
{
"id": 57995113,
"type": "contact_sensor"
},
{
"id": 74123668,
"type": "temperature_humidity_pressure_sensor"
},
{
"id": 74621883,
"type": "temperature_humidity_sensor"
}
Aus dem Beispiel geht hervor, dass die Geräte unabhängig voneinander hinzugefügt 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äts die des Gateways.
Zur Kommunikation mit den Geräten nutzen wir WebSocket. Dies minimalisiert den Ressourcenaufwand im Vergleich zu GET-Anfragen und ermöglicht es, Informationen dynamisch bei Verbindung oder Änderung zu erhalten.
Die Daten werden direkt von dem Gerät bezogen, dem der Block gehört, ohne den Server zu durchlaufen. So läuft das System auch bei Ausfall eines der Geräte weiter. Im Web-Interface wird lediglich das fehlende Gerät nicht angezeigt. Bei Bedarf wird jedoch ein Signal über den Verlust in Form einer Benachrichtigung an die Benutzeranwendung gesendet.
Der erste Versuch zur Umsetzung eines solchen Ansatzes war die PWA-Anwendung. Dadurch kann die Datenbasis der Blöcke auf dem Gerät des Benutzers gespeichert werden, und es werden nur die notwendigen Daten angefragt. Aufgrund der Strukturmerkmale ist diese Variante jedoch unvollständig. Der einzige Ausweg ist eine native Anwendung für Android und iOS, die sich derzeit in aktiver Entwicklung befindet. Standardmäßig 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ässt.
Die externe Verwaltung ist eine vollständige Duplikation der Seite. Bei Aktivierung der Seite kann sich der Benutzer auf dem Server einloggen und die Geräte über sein persönliches Dashboard steuern. So erweitert der Server die Funktionalität und ermöglicht die Steuerung der Geräte von außerhalb des Hauses, ohne an Portweiterleitungen oder eine feste IP gebunden zu sein.
Damit ist die oben beschriebene Variante frei von Nachteilen des serverseitigen Ansatzes und bietet mehrere Vorteile in Form von Flexibilität bei der Anbindung neuer Geräte.
Über den Thermostat
Schauen wir uns das Management-System am Beispiel unseres Thermostats an.
Vorgesehen sind:
- Regelung der Temperatur jedes Thermostats (als einzelner Block angezeigt);
- Einstellung eines Arbeitsplans für den Thermostat (Morgen, Tag, Abend, Nacht);
- Auswahl des WLAN-Netzwerks und Verbindung des Geräts damit;
- Firmware-Updates "over the air";
- MQTT-Konfiguration;
- Einstellung des Netzwerks, mit dem das Gerät verbunden ist.
Neben der Steuerung über die Web-Oberfläche haben wir auch eine klassische Steuerung durch Berührung 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ät. 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ünstiger sein, was sich positiv auf den Endpreis des Geräts auswirkt.
Wie jeder respektable Thermostat-Bildschirm kann unser Nextion:
- die benötigte Temperatur für den Benutzer einstellen (mit den Tasten auf der rechten Seite);
- den Betriebsmodus nach Zeitplan ein- und ausschalten (Taste N);
- den Betrieb des Relais anzeigen (Pfeil links);
- bietet Kindersicherung (physische Tasten werden gesperrt, solange das Schloss nicht aufgehoben ist);
- zeigt den WiFi-Signalpegel an.
Darüber hinaus kann der Monitor:
- den Typ des beim Benutzer installierten Sensors auswählen;
- die Kindersicherung steuern;
- das Firmware-Update durchführen.
Durch einen Klick auf die WiFi-Leiste erfährt der Benutzer Informationen über das verbundene Netzwerk. Der QR-Code wird zur Kopplung des Geräts mit der HomeKit-Firmware verwendet.
Demonstration der Arbeit mit dem Display:
Wir haben mit drei verbundenen Thermostaten entwickelt.
Sie fragen sich: „Was ist das Besondere an Ihrem Thermostat?“ Derzeit gibt es auf dem Markt viele Thermostate mit Wi-Fi-Funktion, Zeitplansteuerung und Touch-Steuerung. Und Enthusiasten haben Module für die Interaktion mit den meisten gängigen Smart-Home-Systemen (Majordomo, HomeAssistant usw.) entwickelt.
Unser Thermostat ist mit solchen Systemen kompatibel und bietet alles oben Genannte. Aber das Unterscheidungsmerkmal ist, dass der Thermostat ständig weiterentwickelt wird, dank der Flexibilität des Systems. Mit jedem Update wird der Funktionsumfang erweitert. Neben der standardmäßigen Steuerungsmethode (nach Zeitplan) werden wir eine adaptive hinzufügen. Die App ermöglicht es, die Geolokalisierung des Benutzers zu erfassen. Dadurch wird das System die Betriebsmodi dynamisch je nach Standort ändern. Und das Wettermodul wird es ermöglichen, sich an die Wetterbedingungen anzupassen.
Und die Erweiterbarkeit. Jeder Interessierte kann seinen installierten herkömmlichen Thermostat gegen unseren austauschen. Mit minimalem Aufwand. Wir haben die 5 beliebtesten Sensoren ausgewählt, die auf dem Markt angeboten werden, und ihre Unterstützung hinzugefügt. Selbst im Falle exklusiver Eigenschaften des Sensors kann der Benutzer ihn mit unserem Thermostat verbinden. Dazu muss der Thermostat für die Arbeit mit dem spezifischen Sensor kalibriert werden. Die Anleitungen stellen wir zur Verfügung.
Wenn Sie den Thermostat oder ein anderes Gerät anschließen, erscheint es gleichzeitig überall: sowohl im Web-Interface als auch in der PWA-Anwendung. Das Hinzufügen des Geräts erfolgt automatisch: es genügt, es mit dem WLAN-Netzwerk zu verbinden.
Unser System benötigt keinen Server und verwandelt sich im Falle eines Ausfalls nicht in eine Kürbis. Selbst bei einem Ausfall eines der Komponenten beginnt das System nicht mit einem Notfallszenario zu arbeiten. Controller, Sensoren, Geräte – jedes Element fungiert sowohl als Server als auch als Client und ist somit vollständig autonom.
Für Interessierte – unsere sozialen Netzwerke: , , , , .
E-Mail: shop@lytko.com
P. S. Wir fordern nicht zum Verzicht auf den Server auf. Auch wir unterstützen einen MQTT-Server und haben unsere eigene Cloud. Unser Ziel ist es, die Stabilität und Zuverlässigkeit des Systems auf ein qualitativ neues Niveau zu heben. Damit der Server nicht der Schwachpunkt ist, sondern die Funktionalität ergänzt und das System benutzerfreundlicher macht.
Quelle: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish