Vor einiger Zeit haben wir Ihnen vorgestellt . Der aktuelle Artikel war ursprünglich als Demo seiner Firmware und Steuerungssystem gedacht. Um jedoch die Logik des Thermostats und das, was wir implementiert haben, zu erklären, ist es notwendig, das gesamte Konzept zu umreißen.
Zur Automatisierung
Zunächst kann man die 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 ist eine eigene App notwendig. Die Protokolle der Geräte verschiedener Hersteller sind oft nicht miteinander kompatibel.
Kategorie 2 — Installation eines Einplatinencomputers oder eines x86-kompatiblen Systems. Dadurch werden die Einschränkungen der Rechenleistung aufgehoben, und auf dieses Gerät kann MajorDoMo oder eine andere Server-Distribution zur Verwaltung des Smart Homes installiert werden. So werden die Geräte der meisten Hersteller in einem gemeinsamen Informationsraum verbunden. Das heißt, es entsteht ein eigener Server für das Smart Home. Vorteile: Kompatibilität unter einem zentralen Punkt, was erweiterte Managementmöglichkeiten bietet. Nachteile: Bei einem Ausfall des Servers wird das gesamte System auf den Ausgangszustand 1 zurückgesetzt, also wird es fragmentiert oder nutzlos.
Kategorie 3 — 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ücksichtigen.
Die meisten Benutzer wählen zunächst Variante eins und wechseln dann allmählich zu Variante zwei. In der Folge erreichen die hartnäckigsten schließlich Variante drei.
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 es ein Versuch, Variante 1 und Variante 2 zu kombinieren. Alle Vorteile beider Ansätze zu vereinen und die Nachteile zu eliminieren – die goldene Mitte zu finden.
Vielleicht könnte jemand sagen, dass eine solche Lösung bereits entwickelt wurde. Doch solche Ansätze sind sehr spezialisiert und richten sich an Personen mit Programmierkenntnissen. Unser Ziel ist es, die Einstiegshürden für solche verteilten Systeme zu senken, sowohl in der Form von Endgeräten als auch durch die Integration bestehender Geräte 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ätzliche Maßnahmen.
Lassen Sie uns die Integration in unser System anhand eines Beispiels betrachten.
Stellen wir uns vor, wir haben 8 Sonoff-Module in unserem Netzwerk. Einige Nutzer werden mit der Steuerung über 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übertragung an einen MQTT-Server. OpenHub, Majordomo oder jede andere Lösung haben dasselbe Ziel – die Verknüpfung von verstreuten Geräten in einen einheitlichen Informationsraum, der entweder im Internet oder im lokalen Netzwerk lokalisiert ist. Daher ist das Vorhandensein eines Servers unerlässlich. Daraus ergibt sich das Hauptproblem – fällt der Server aus, funktioniert das gesamte System nicht mehr autonom. Um dem entgegenzuwirken, werden die Systeme komplizierter, und es werden manuelle Steuerungsmethoden hinzugefügt, die die Automatisierung im Falle eines Serverausfalls duplizieren.
Wir haben uns für einen anderen Ansatz entschieden, bei dem jedes Gerät autark ist. So spielt der Server keine entscheidende Rolle, sondern erweitert lediglich die Funktionalität.
Lassen Sie uns zu unserem Gedankenexperiment zurückkehren. Nehmen wir wieder die gleichen 8 Sonoff-Module und installieren die Lytko-Firmware. In allen Lytko-Firmwares ist eine Funktion integriert. . SSDP — 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ätzlich zur Standardfunktion die Erstellung einer Liste von Geräten im Netzwerk integriert. So finden die Geräte einander, 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, enthält die Liste die IDs der Geräte, 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 Änderungen der Anzahl der Geräte im Netzwerk gerecht zu werden. So überwachen wir das Hinzufügen, Ändern und Abschalten von Geräten, 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öcken. Jeder Block entspricht einem Gerät/Sensor/Controller. Visuell sieht die Liste so aus:
Aber was ist, wenn andere Funksensoren über cc2530 (ZigBee) oder nrf24 (MySensors) an esp8266/esp32 angeschlossen sind?
Über Projekte
Auf dem Markt gibt es verschiedene verteilte Systeme. Unser System ermöglicht die Integration mit den bekanntesten.
Im Folgenden sind Projekte aufgeführt, die versuchen, die Situation der Inkompatibilität zwischen verschiedenen Herstellern zu verändern. Dazu gehören beispielsweise , oder . basierend auf einem MQTT-Server, daher nicht für das Beispiel geeignet.
Eine der Implementierungsoptionen für 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ätelisten integriert werden.
Lassen Sie uns ein weiteres gedankliches Experiment durchführen. Wir haben das ZESP32-Gateway 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 Bibliothek des SSDP-Protokolls hinzu. Wenn man diesen Controller über SSDP abruft, wird die Standardantwort um eine Liste der daran angeschlossenen Geräte ergänzt. Basierend auf diesen Informationen erstellt der Browser eine Seite. Insgesamt wird es so aussehen:
Web-Interface
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"
}
Wie das Beispiel zeigt, werden die Geräte unabhängig voneinander hinzugefügt. 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äts die IP-Adresse des Gateways.
Zur Kommunikation mit den Geräten verwenden wir WebSocket. Dies minimiert den Ressourcenaufwand im Vergleich zu GET-Anfragen und ermöglicht das dynamische Abrufen von Informationen bei Verbindungen oder Änderungen.
Die Daten werden direkt von dem Gerät abgerufen, dem das Modul gehört, und umgehen den Server. So bleibt das System auch bei Ausfall eines Gerätes funktionsfähig. Im Web-Interface wird lediglich das fehlende Gerät nicht angezeigt. Bei Bedarf wird jedoch eine Benachrichtigung im Benutzer-Interface über den Verlust des Geräts gesendet.
Der erste Versuch, einen solchen Ansatz umzusetzen, war eine PWA-Anwendung. Diese ermöglicht es, eine Datenbank von Blöcken auf dem Gerät des Benutzers zu speichern und nur die erforderlichen Daten abzurufen. Aufgrund der Strukturmerkmale ist dieses Modell jedoch unvollständig. Die einzige Lösung ist eine native App für Android und iOS, die derzeit in aktiver Entwicklung ist. Standardmäßig 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ässt.
Die externe Steuerung ist eine vollständige Duplizierung der Seite. Wenn die Seite aktiviert wird, kann sich der Benutzer auf dem Server einloggen und die Geräte über das Benutzerkonto steuern. Auf diese Weise erweitert der Server die Funktionalität und ermöglicht es, Geräte auch außerhalb des Hauses zu steuern, ohne an Portweiterleitungen oder eine dedizierte IP gebunden zu sein.
Auf diese Weise ist die oben beschriebene Variante frei von Nachteilen des serverbasierten Ansatzes und bietet zudem zahlreiche Vorteile in Form von Flexibilität bei der Anbindung neuer Geräte.
Über den Thermostat
Betrachten wir das Managementsystem am Beispiel unseres Thermostats.
Folgendes ist vorgesehen:
- Regulierung der Temperatur jedes Thermostats (wird als einzelner Block angezeigt);
- Einstellung des Zeitplans für den Betrieb des Thermostats (Morgen, Tag, Abend, Nacht);
- Auswahl des Wi-Fi-Netzwerks und Verbindung des Geräts damit;
- Geräte-Updates „over-the-air“;
- Einstellung von MQTT;
- Konfiguration des Netzwerks, mit dem das Gerät verbunden ist.
Neben der Verwaltung über die Web-Oberfläche haben wir eine klassische Steuerung durch Berührung 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ät wird nicht schlechter sein als die des Nextion, er wird jedoch günstiger sein, was sich positiv auf den Endpreis des Geräts auswirkt.
Wie jeder respektable Thermostatbildschirm kann unser Nextion:
- die vom Benutzer gewünschte Temperatur einstellen (mit den Tasten rechts);
- den Betriebsmodus nach Zeitplan ein- und ausschalten (Taste H);
- den Betrieb des Relais anzeigen (Pfeil links);
- verfügt über einen Kindersicherungsschutz (physische Betätigungen werden blockiert, solange das Schloss nicht aufgehoben ist);
- zeigt den WLAN-Signalpegel an.
Zusätzlich ermöglicht der Monitor:
- den Typ des bei Benutzer installierten Sensors auszuwählen;
- die Kindersicherungsfunktion zu steuern;
- die Firmware zu aktualisieren.
Durch einen Klick auf die WiFi-Leiste erhält der Benutzer Informationen über das verbundene Netzwerk. Der QR-Code wird verwendet, um das Gerät mit der HomeKit-Firmware zu koppeln.
Demo der Arbeit mit dem Display:
Wir haben entwickelt mit drei angeschlossenen Thermostaten.
Sie fragen sich: „Was ist das Besondere an Ihrem Thermostat?“ Derzeit gibt es auf dem Markt viele Thermostate mit Wi-Fi-Funktion, Zeitsteuerung und Touch-Bedienung. Zudem haben Enthusiasten Module entwickelt, um mit den meisten gängigen Smart Home-Systemen (Majordomo, HomeAssistant usw.) zu interagieren.
Unser Thermostat ist mit einer Vielzahl von Systemen kompatibel und bietet alle oben genannten Funktionen. Ein herausragendes Merkmal ist die kontinuierliche Weiterentwicklung des Thermostats, ermöglicht durch die Flexibilität des Systems. Mit jedem Update wird der Funktionsumfang erweitert. Neben der standardmäßigen Steuerungsmethode (nach Zeitplan) werden wir eine adaptive Steuerung hinzufügen. Die App ermöglicht die Geolokalisierung des Nutzers. Dadurch kann das System dynamisch den Betriebsmodus je nach Standort des Nutzers anpassen. Ein Wettermodul sorgt dafür, dass sich die Einstellungen an die aktuellen Wetterbedingungen anpassen.
Und die Erweiterbarkeit. Jeder kann seinen herkömmlichen Thermostat unkompliziert durch unseren ersetzen. Mit minimalem Aufwand. Wir haben fünf der beliebtesten Sensoren ausgewählt, die auf dem Markt erhältlich sind, und deren Unterstützung hinzugefügt. Selbst wenn ein Sensor exklusive Eigenschaften aufweist, kann der Nutzer ihn mit unserem Thermostat verbinden. Dazu muss der Thermostat lediglich für den spezifischen Sensor kalibriert werden. Die entsprechenden Anleitungen stellen wir bereit.
Wenn Sie ein Thermostat oder ein anderes Gerät anschließen, wird es gleichzeitig überall angezeigt: sowohl in der Weboberfläche als auch in der PWA-App. Das Hinzufügen eines Geräts erfolgt automatisch: Es reicht aus, es mit dem WLAN-Netzwerk zu verbinden.
Unser System benötigt keinen Server und verwandelt sich im Falle eines Ausfalls nicht in einen Kürbis. Selbst wenn eines der Komponenten ausfällt, wechselt das System nicht in einen Notbetrieb. 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 Medien: , , , , .
E-Mail: shop@lytko.com
P. S. Wir fordern nicht dazu auf, auf den Server zu verzichten. Wir unterstützen auch einen MQTT-Server und bieten eine eigene Cloud an. Unser Ziel ist es, die Stabilität und Zuverlässigkeit des Systems auf ein qualitativ neues Niveau zu heben, damit der Server nicht das schwächste Glied ist, sondern die Funktionalität ergänzt und das System benutzerfreundlicher macht.
Quelle: habr.com
