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
