Vor einiger Zeit haben wir Sie vorgestellt . Dieser Artikel war ursprünglich als Demonstration seiner Firmware und seines Steuerungssystems gedacht. Doch um die Logik des Thermostats und unsere Umsetzung zu erklären, ist es notwendig, das gesamte Konzept als Ganzes zu skizzieren.
Über Automatisierung
Herkömmlicherweise lässt sich die gesamte Automatisierung in drei Kategorien einteilen:
Kategorie 1 — separate „intelligente“ Geräte. Sie kaufen Glühbirnen, Teekannen etc. von verschiedenen Herstellern. Vorteile: Jedes Gerät erweitert die Möglichkeiten und erhöht den Komfort. Nachteile: Jeder neue Hersteller benötigt eine eigene Anwendung. Protokolle von Geräten unterschiedlicher Hersteller sind oft nicht miteinander kompatibel.
Kategorie 2 — Installation eines Single-Board-PCs oder x86-kompatibel. Dadurch werden Einschränkungen der Rechenleistung aufgehoben und MajorDoMo oder eine andere Server-Distribution zur Verwaltung eines Smart Homes wird auf diesem Rechner installiert. Somit sind Geräte der meisten Hersteller in einem einzigen Informationsraum verbunden. Diese. Ihr eigener Server für ein Smart Home erscheint. Vorteile: Kompatibilität unter einem einzigen Zentrum, was erweiterte Verwaltungsfunktionen bietet. Nachteile: Fällt der Server aus, kehrt das gesamte System in die Stufe 1 zurück, d. h. wird fragmentiert oder unbrauchbar.
Kategorie 3 - die härteste Option. In der Reparaturphase werden die gesamte Kommunikation verlegt und alle Systeme dupliziert. Vorteile: Alles wird perfektioniert und dann wird das Haus richtig smart. Nachteile: extrem teuer im Vergleich zu Kategorie 1 und 2, die Notwendigkeit, alles im Voraus zu durchdenken und jedes noch so kleine Detail zu berücksichtigen.
Die meisten Benutzer entscheiden sich für Option eins und gehen dann problemlos zu Option zwei über. Und dann erreichen die Hartnäckigsten Option 3.
Es gibt jedoch eine Option, die man als verteiltes System bezeichnen kann: Jedes einzelne Gerät ist sowohl Server als auch Client. Im Wesentlichen handelt es sich hierbei um einen Versuch, Option 1 und Option 2 zu kombinieren. Nehmen Sie alle Vorteile und eliminieren Sie die Nachteile, um die goldene Mitte zu finden.
Vielleicht wird jemand sagen, dass eine solche Option bereits entwickelt wurde. Aber solche Entscheidungen sind eng fokussiert; für Leute, die sich mit Programmierung auskennen. Unser Ziel ist es, die Eintrittsbarriere in solche verteilten Systeme zu senken, sowohl in Form von Endgeräten als auch in Form der Integration bestehender Geräte in unser System. Im Falle eines Thermostats entfernt der Benutzer einfach seinen alten Thermostat, installiert einen intelligenten und verbindet seine vorhandenen Sensoren damit. Ohne zusätzliche Schritte.
Schauen wir uns die Integration in unser System anhand eines Beispiels an.
Stellen wir uns vor, wir haben 8 Sonoff-Module in unserem Netzwerk. Für einige Benutzer wird die Steuerung über die Sonoff-Cloud (Kategorie 1) ausreichend sein. Einige werden anfangen, Firmware von Drittanbietern zu verwenden und nahtlos in Kategorie 2 übergehen. Der Großteil der Firmware von Drittanbietern funktioniert nach dem gleichen Prinzip: der Übertragung von Daten an einen MQTT-Server. OpenHub, Majordomo oder andere dienen einem Zweck: unterschiedliche Geräte in einem einzigen Informationsraum zu vereinen, der sich entweder im Internet oder in einem lokalen Netzwerk befindet. Daher ist die Anwesenheit eines Servers zwingend erforderlich. Hier entsteht das Hauptproblem: Fällt der Server aus, funktioniert das gesamte System nicht mehr autonom. Um dies zu verhindern, werden Systeme komplexer, manuelle Steuerungsmethoden werden hinzugefügt, die die Automatisierung im Falle eines Serverausfalls duplizieren.
Wir sind einen anderen Weg gegangen, bei dem jedes Gerät autark ist. Somit spielt der Server keine entscheidende Rolle, sondern erweitert lediglich die Funktionalität.
Kehren wir zum Gedankenexperiment zurück. Nehmen wir noch einmal die gleichen 8 Sonoff-Module und installieren darin die Lytko-Firmware. Alle Lytko-Firmwares verfügen über die Funktion . SSDP ist ein Netzwerkprotokoll, das auf der Internet Protocol Suite für die Werbung und Erkennung von Netzwerkdiensten basiert. Die Antwort auf eine Anfrage kann entweder Standard oder erweitert sein. Zusätzlich zu den Standardfunktionen haben wir in diese Antwort die Erstellung einer Liste von Geräten im Netzwerk aufgenommen. Somit finden sich die Geräte selbst und jedes von ihnen verfügt über eine solche Liste. Beispiel für ein SSDP-Blatt:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Wie Sie dem Beispiel entnehmen können, umfasst die Liste Geräte-IDs, IP-Adresse im Netzwerk und Gerätetyp (in unserem Fall ein Sonoff-basierter Thermostat). Diese Liste wird alle zwei Minuten aktualisiert (dieser Zeitraum reicht aus, um auf dynamische Änderungen in der Anzahl der Geräte im Netzwerk zu reagieren). Auf diese Weise verfolgen wir ohne Benutzereingriff hinzugefügte, geänderte und deaktivierte Geräte. Diese Liste wird an den Browser oder die mobile Anwendung gesendet und das Skript selbst generiert eine Seite mit einer bestimmten Anzahl von Blöcken. Jeder Block entspricht einem Gerät/Sensor/Controller. Optisch sieht die Liste so aus:
Was aber, wenn andere Funksensoren über cc8266 (ZigBee) oder nrf32 (MySensors) mit dem esp2530/esp24 verbunden sind?
Über Projekte
Es gibt verschiedene verteilte Systeme auf dem Markt. Unser System ermöglicht Ihnen die Integration mit den beliebtesten.
Nachfolgend finden Sie Projekte, die auf die eine oder andere Weise versuchen, die Situation mit der Inkompatibilität verschiedener Hersteller untereinander zu ändern. Das ist zum Beispiel , oder . ist an einen MQTT-Server gebunden und daher für das Beispiel nicht geeignet.
Eine Möglichkeit zur Implementierung von MySensors ist ein Gateway auf Basis des ESP8266. Die restlichen Beispiele basieren auf ESP32. Und in ihnen können Sie unser Funktionsprinzip der Geräteerkennung und Erstellung einer Geräteliste umsetzen.
Machen wir noch ein Gedankenexperiment. Wir haben ein ZESP32-Gateway oder SLS-Gateway oder MySensors. Wie können sie in einem einzigen Informationsraum kombiniert werden? Wir werden die SSDP-Protokollbibliothek zu den Standardfunktionen dieser Gateways hinzufügen. Wenn Sie über SSDP auf diesen Controller zugreifen, wird der Standardantwort eine Liste der mit ihm verbundenen Geräte hinzugefügt. Basierend auf diesen Informationen generiert der Browser eine Seite. Im Allgemeinen wird es so aussehen:
Webschnittstelle
PWA-Anwendung
"ssdpList":
{
"id": 94967291, // уникальный идентификатор устройства
"ip": "192.168.x.x", // ip адрес в сети
"type": "thermostat" // тип устройства
},
{
"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"
}
Das Beispiel zeigt, dass Geräte unabhängig voneinander hinzugefügt werden. Es sind 3 Thermostate mit eigenen IP-Adressen und 5 verschiedene Sensoren mit eindeutigen IDs verbunden. Wenn der Sensor mit einem Wi-Fi-Netzwerk verbunden ist, verfügt er über eine eigene IP. Wenn er mit einem Gateway verbunden ist, ist die IP-Adresse des Geräts die IP-Adresse des Gateways.
Wir verwenden WebSocket, um mit Geräten zu kommunizieren. Dadurch können Sie die Ressourcenkosten im Vergleich zum Abrufen von Anfragen minimieren und beim Verbinden oder Ändern dynamisch Informationen abrufen.
Die Daten werden unter Umgehung des Servers direkt von dem Gerät übernommen, zu dem der Block gehört. Sollte also eines der Geräte ausfallen, läuft das System weiter. Das Webinterface zeigt das fehlende Gerät einfach nicht in der Liste an. Bei Bedarf erfolgt jedoch ein Signal über den Verlust in Form einer Benachrichtigung in der Anwendung des Benutzers.
Der erste Versuch, diesen Ansatz umzusetzen, war eine PWA-Anwendung. Dadurch können Sie eine Blockbasis auf dem Gerät des Benutzers speichern und nur die erforderlichen Daten anfordern. Aufgrund der Besonderheiten der Struktur ist diese Option jedoch unvollständig. Und es gibt nur einen Ausweg – eine native Anwendung für Android und IOS, die sich derzeit in der aktiven Entwicklung befindet. Standardmäßig funktioniert die Anwendung nur im internen Netzwerk. Bei Bedarf können Sie alles an eine externe Steuerung übergeben. Wenn der Benutzer also das lokale Netzwerk verlässt, wechselt die Anwendung automatisch in die Cloud.
Externe Kontrolle – vollständige Vervielfältigung der Seite. Wenn die Seite aktiviert ist, kann sich der Benutzer über sein persönliches Konto beim Server anmelden und Geräte verwalten. Dadurch erweitert der Server seine Funktionalität und ermöglicht Ihnen die Verwaltung von Geräten auch von unterwegs, ohne an Portweiterleitung oder eine dedizierte IP gebunden zu sein.
Somit weist die obige Option nicht die Nachteile des Server-Ansatzes auf, sondern bietet darüber hinaus eine Reihe von Vorteilen in Form der Flexibilität beim Anschluss neuer Geräte.
Über den Thermostat
Schauen wir uns die Steuerung am Beispiel unseres Thermostats an.
Bereitgestellt:
- Temperaturregelung für jeden Thermostat (als separater Block angezeigt);
- Einstellen des Betriebsplans des Thermostats (morgens, nachmittags, abends, nachts);
- Auswählen eines Wi-Fi-Netzwerks und Verbinden eines Geräts damit;
- Aktualisieren des Geräts „over the air“;
- MQTT einrichten;
- Konfigurieren Sie das Netzwerk, mit dem das Gerät verbunden ist.
Neben der Steuerung über das Webinterface bieten wir auch die klassische Steuerung – per Klick auf das Display. An Bord ist ein Nextion NX3224T024 2.4-Zoll-Monitor. Die Wahl fiel auf ihn aufgrund der einfachen Handhabung des Geräts. Aber wir entwickeln unseren eigenen Monitor auf Basis von STM32. Seine Funktionalität ist nicht schlechter als die von Nextion, aber es wird weniger kosten, was sich positiv auf den Endpreis des Geräts auswirken wird.
Wie jeder Thermostatbildschirm mit Selbstachtung kann unser Nextion:
- Stellen Sie die vom Benutzer gewünschte Temperatur ein (mit den Tasten rechts);
- den geplanten Betriebsmodus ein- und ausschalten (Taste H);
- Relaisbetrieb anzeigen (Pfeil links);
- verfügt über einen Kinderschutz (physische Klicks werden blockiert, bis die Sperre aufgehoben wird);
- Zeigt die WLAN-Signalstärke an.
Darüber hinaus können Sie mit dem Monitor:
- Wählen Sie den vom Benutzer installierten Sensortyp aus.
- die Kindersicherungsfunktion verwalten;
- Aktualisieren Sie die Firmware.
Durch einen Klick auf die WLAN-Leiste erfährt der Nutzer Informationen über das verbundene Netzwerk. Der QR-Code wird zum Koppeln des Geräts in der HomeKit-Firmware verwendet.
Demo zur Arbeit mit dem Display:
Wir haben entwickelt mit drei angeschlossenen Thermostaten.
Sie fragen sich vielleicht: „Was ist das Besondere an Ihrem Thermostat?“ Mittlerweile gibt es auf dem Markt viele Thermostate mit WLAN-Funktion, zeitgesteuertem Betrieb und Touch-Steuerung. Und Enthusiasten haben Module geschrieben, um mit den gängigsten Smart-Home-Systemen (Majordomo, HomeAssistant usw.) zu interagieren.
Unser Thermostat ist mit solchen Systemen kompatibel und verfügt über alle oben genannten Eigenschaften. Die Besonderheit besteht jedoch darin, dass der Thermostat dank der Flexibilität des Systems ständig verbessert wird. Mit jedem Update wird die Funktionalität erweitert. Zur Standardmethode der Systemverwaltung (nach einem Zeitplan) werden wir eine adaptive hinzufügen. Mit der Anwendung können Sie die Geolokalisierung des Benutzers ermitteln. Dadurch ändert das System je nach Standort dynamisch den Betriebsmodus. Und mit dem Wettermodul können Sie sich an die Wetterbedingungen anpassen.
Und Erweiterbarkeit. Jeder kann seinen vorhandenen herkömmlichen Thermostat durch unseren ersetzen. Mit minimalem Aufwand. Wir haben 5 der beliebtesten Sensoren auf dem Markt ausgewählt und Unterstützung für sie hinzugefügt. Aber auch wenn der Sensor über exklusive Eigenschaften verfügt, kann der Benutzer ihn an unseren Thermostat anschließen. Dazu müssen Sie den Thermostat so kalibrieren, dass er mit einem bestimmten Sensor funktioniert. Wir geben Anweisungen.
Beim Anschließen eines Thermostats oder eines anderen Geräts erscheint es überall gleichzeitig: sowohl im Webinterface als auch in der PWA-Anwendung. Das Hinzufügen eines Geräts erfolgt automatisch: Sie müssen es lediglich mit dem Wi-Fi-Netzwerk verbinden.
Unser System benötigt keinen Server, und wenn dieser ausfällt, verwandelt er sich nicht in einen Kürbis. Selbst wenn eine der Komponenten ausfällt, nimmt das System im Notfall nicht den Betrieb auf. Controller, Sensoren, Geräte – jedes Element ist sowohl ein Server als auch ein Client und daher völlig autonom.
Für Interessierte unsere sozialen Netzwerke: , , , , .
E-mail: [E-Mail geschützt]
PS Wir empfehlen Ihnen nicht, den Server zu verlassen. Wir unterstützen auch einen MQTT-Server und verfügen über eine eigene Cloud. Unser Ziel ist es, die Stabilität und Zuverlässigkeit des Systems auf ein völlig neues Niveau zu bringen. Damit stellt der Server keine Schwachstelle dar, sondern ergänzt die Funktionalität und macht das System komfortabler.
Source: habr.com