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
