Lytko vereint

Vor einiger Zeit haben wir Ihnen einen intelligenten Thermostat vorgestellt . Dieser Artikel wurde ursprünglich als Demonstration seiner Firmware und seines Steuerungssystems konzipiert. Um jedoch die Logik des Thermostats und die von uns implementierten Funktionen zu erläutern, muss das gesamte Konzept erläutert werden.

Über die Automatisierung

Herkömmlicherweise kann die gesamte Automatisierung in drei Kategorien unterteilt werden:
Kategorie 1 - separate „intelligente“ Geräte. Sie erhalten Glühbirnen, Teekannen usw. von verschiedenen Herstellern. Pluspunkte: 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 Einplatinen-PCs oder eines x86-kompatiblen PCs. Dadurch werden die Einschränkungen der Rechenleistung aufgehoben, und MajorDoMo oder eine andere Serververteilung für die Verwaltung eines Smart Homes ist auf diesem Computer installiert. Somit sind die Geräte der meisten Hersteller in einem einzigen Informationsraum verbunden. Das heißt erscheint Ihr Server für Smart Home. Vorteile: Kompatibilität unter einem einzigen Center, das erweiterte Verwaltungsfunktionen bietet. Nachteile: Im Falle eines Serverausfalls kehrt das gesamte System zu Stufe 1 zurück, d. H. wird fragmentiert oder unbrauchbar.

Kategorie 3 ist die Hardcore-Version. In der Reparaturphase werden alle Kommunikationen verlegt und alle Systeme dupliziert. Vorteile: Alles wird zum Ideal gebracht und dann wird das Haus wirklich schlau. Nachteile: Extreme Kosten im Vergleich zu den Kategorien 1 und 2, die Notwendigkeit, alles im Voraus zu überdenken und jede Kleinigkeit zu berücksichtigen.

Die meisten Benutzer wählen Option eins und wechseln dann nahtlos zu Option zwei. Und in Zukunft die beständigste Reichweitenoption 3.

Es gibt jedoch eine Option, die als verteiltes System bezeichnet werden kann: Jedes einzelne Gerät ist sowohl ein Server als auch ein Client. In der Tat ist dies ein Versuch, Option 1 und Option 2 zu ergreifen und zu kombinieren. Nehmen Sie alle ihre Pluspunkte und beseitigen Sie die Minuspunkte, um den Mittelweg zu erreichen.

Vielleicht wird jemand sagen, dass eine solche Option bereits entwickelt wurde. Solche Entscheidungen sind jedoch eng gefasst. für Programmierer. Unser Ziel ist es, die Schwelle für den Eintritt in solche verteilten Systeme sowohl in Form von Endgeräten als auch in Form der Integration bestehender Geräte in unser System zu senken. Im Falle des Thermostats entfernt der Benutzer einfach seinen alten Thermostat, installiert einen intelligenten Thermostat und schließt seine Sensoren daran an. Ohne zusätzliche Aktion.

Betrachten wir die Integration in unser System anhand eines Beispiels.

Stellen Sie sich vor, wir haben 8 Sonoff-Module in unserem Netzwerk. Einige Benutzer haben möglicherweise ausreichend Kontrolle über die Sonoff-Cloud (Kategorie 1). Einige verwenden Firmware von Drittanbietern und wechseln problemlos zu Kategorie 2. Der Großteil der Firmware von Drittanbietern funktioniert nach demselben Prinzip: Datenübertragung zum MQTT-Server. OpenHub, Majordomo oder andere Geräte dienen demselben Zweck: Sie können unterschiedliche Geräte in einem einzigen Informationsbereich zusammenfassen, der sich entweder im Internet oder in einem lokalen Netzwerk befindet. Daher ist die Anwesenheit des Servers obligatorisch. Ab hier tritt das Hauptproblem auf: Wenn der Server ausfällt, funktioniert das gesamte System nicht mehr autonom. Um dies zu verhindern, werden die Systeme komplizierter, und es werden manuelle Steuerungsmethoden 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 nur die Funktionalität.

Zurück zum Gedankenexperiment. Nehmen Sie wieder dieselben 8 Sonoff-Module und installieren Sie die Lytko-Firmware darin. In allen Lytko-Firmware ist die SSDP- Funktion implementiert. SSDP ist ein Netzwerkprotokoll, das auf einer Reihe von Internetprotokollen basiert, mit denen Netzwerkdienste angekündigt und erkannt werden. Die Antwort auf die Anforderung kann entweder Standard oder Advanced sein. Zusätzlich zu den Standardfunktionen haben wir in diese Antwort die Erstellung einer Liste von Geräten im Netzwerk aufgenommen. So finden sich die Geräte selbst und jeder von ihnen wird eine solche Liste haben. Beispiel SSDP-Sheet:

"ssdpList": { "id": 94967291, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967282, "ip": "192.168.xx", "type": "thermostat" } 

Wie Sie dem Beispiel entnehmen können, enthält die Liste die Geräte-ID, die Netzwerk-IP-Adresse und den Blocktyp (in unserem Fall einen Sonoff-basierten Thermostat). Diese Liste wird alle zwei Minuten aktualisiert (dieses Intervall reicht aus, um auf eine dynamische Änderung der Anzahl der Geräte im Netzwerk zu reagieren). So können wir das Hinzufügen, Ändern und Trennen von Geräten nachverfolgen, ohne dass der Benutzer etwas unternehmen muss. Diese Liste wird an einen Browser oder eine mobile Anwendung gesendet, und das Skript selbst bildet eine Seite mit einer bestimmten Anzahl von Blöcken. Jeder Block entspricht einem Gerät / Sensor / Controller. Visuell sieht die Liste folgendermaßen aus:



Aber ob andere Funksensoren über cc2530 (ZigBee) oder nrf24 (MySensors) mit esp8266 / esp32 verbunden sind?

Über Projekte

Es gibt verschiedene verteilte Systeme auf dem Markt. Unser System ermöglicht Ihnen die Integration mit den beliebtesten.

Im Folgenden sind die Projekte aufgeführt, die versuchen, die Situation mit der Inkompatibilität verschiedener Hersteller untereinander zu ändern. Dies sind beispielsweise SLS Gateway , MySensors oder ZESP32 . ZigBee2MQTT ist an einen MQTT-Server gebunden und daher beispielsweise nicht geeignet.

Eine Implementierungsoption für MySensors ist ein ESP8266-basiertes Gateway. Andere Beispiele beziehen sich auf ESP32. Und in ihnen können Sie unser Prinzip der Erkennung und Erstellung einer Geräteliste umsetzen.

Machen wir noch ein Gedankenexperiment. Wir haben ein Gateway ZESP32 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 eine Liste der angeschlossenen Geräte zur Standardantwort hinzugefügt. Anhand dieser Informationen bildet der Browser eine Seite. Im Allgemeinen wird es so aussehen:


Weboberfläche


PWA-Anwendung

 "ssdpList": { "id": 94967291, //    "ip": "192.168.xx", // ip    "type": "thermostat" //   }, { "id": 94967292, "ip": "192.168.xx", "type": "thermostat" }, { "id": 94967293, "ip": "192.168.xx", "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 die Geräte unabhängig voneinander hinzugefügt werden. Es sind 3 Thermostate mit eigener IP-Adresse und 5 verschiedene Sensoren mit eindeutiger ID angeschlossen. Wenn der Sensor mit einem Wi-Fi-Netzwerk verbunden ist, hat er eine eigene IP. Wenn er mit dem Gateway verbunden ist, ist die IP-Adresse des Geräts die IP-Adresse des Gateways.

Zur Kommunikation mit Geräten verwenden wir WebSocket. Auf diese Weise können Sie die Kosten für Ressourcen im Vergleich zu Abrufanforderungen minimieren und Informationen dynamisch empfangen, wenn Sie eine Verbindung herstellen oder ändern.

Die Daten werden unter Umgehung des Servers direkt von dem Gerät abgerufen, zu dem das Gerät gehört. Wenn also eines der Geräte ausfällt, arbeitet das System weiter. Das Webinterface zeigt nicht nur das Gerät an, das in der Liste fehlt. Das Signal für den Verlust wird jedoch, falls erforderlich, in Form einer Benachrichtigung in der Benutzeranwendung angezeigt.

Der erste Versuch, diesen Ansatz zu implementieren, war eine PWA-Anwendung. Auf diese Weise können Sie die Blockbasis auf dem Gerät des Benutzers speichern und nur die erforderlichen Daten anfordern. Aufgrund der Besonderheiten der Struktur ist eine solche Option jedoch unterlegen. Und es gibt nur einen Ausweg - eine native Anwendung für Android und IOS, die derzeit aktiv entwickelt wird. Standardmäßig funktioniert die Anwendung nur im internen Netzwerk. Bei Bedarf können Sie alles an eine externe Steuerung übertragen. Wenn der Benutzer das lokale Netzwerk verlässt, wechselt die Anwendung automatisch in die Cloud.

Externe Verwaltung - vollständige Vervielfältigung der Seite. Wenn die Seite aktiviert ist, kann sich der Benutzer beim Server anmelden und Geräte über ein persönliches Konto verwalten. Auf diese Weise erweitert der Server die Funktionalität, sodass Sie Geräte außerhalb des Hauses verwalten können und nicht an die Portweiterleitung oder eine dedizierte IP gebunden sind.

Somit ist die obige Option frei von den Nachteilen des Server-Ansatzes und hat auch mehrere Vorteile in Form der Flexibilität beim Anschließen neuer Geräte.

Über den Thermostat

Betrachten Sie ein Steuersystem am Beispiel unseres Thermostats.

Zur Verfügung gestellt von:

1. Temperaturregelung für jeden Thermostat (als separate Einheit angezeigt);
2. Einstellen des Zeitplans des Thermostats (morgens, tags, abends, nachts);
3. Auswählen eines Wi-Fi-Netzwerks und Anschließen eines Geräts daran;
4. Aktualisieren des Geräts "über Funk";
5. MQTT konfigurieren;
6. Konfigurieren Sie das Netzwerk, mit dem das Gerät verbunden ist.

Neben der Verwaltung über das Webinterface sorgten sie für das klassische - durch Tippen auf das Display. An Bord befindet sich der 2,4-Zoll-Monitor Nextion NX3224T024. Die Wahl fiel auf ihn aufgrund der Einfachheit der Arbeit mit dem Gerät. In der Entwicklung befindet sich jedoch ein eigener 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 auswirkt.



Wie jeder Thermostatbildschirm mit Selbstachtung kann unser Nextion:

• Stellen Sie die für den Benutzer erforderliche Temperatur ein (mit den Tasten auf der rechten Seite).
• Ein- und Ausschalten des geplanten Betriebsmodus (Taste H);
• Relaisbetrieb anzeigen (Pfeil links);
• hat Schutz vor Kindern (physische Klicks sind blockiert, bis die Sperre entfernt wird);
• Zeigt die WiFi-Signalstärke an.

Mit dem Monitor können Sie außerdem:

• Wählen Sie den vom Benutzer installierten Sensortyp.
• die Kinderschutzfunktion verwalten;
• Firmware aktualisieren.

Durch Klicken auf die WLAN-Leiste erhält der Benutzer Informationen zum verbundenen Netzwerk. Der QR-Code wird zum Koppeln des Geräts in der HomeKit-Firmware verwendet.



Demo der Arbeit mit dem Display:



Wir haben eine Demoseite mit drei angeschlossenen Thermostaten entwickelt.

Sie fragen: „Was ist die Besonderheit Ihres Thermostats?“ Jetzt gibt es auf dem Markt viele Thermostate mit WLAN-Funktion, zeitgesteuerter Arbeit und Berührungssteuerung. Und Enthusiasten haben Module für die Interaktion mit den gängigsten Smart-Home-Systemen (Majordomo, HomeAssistant usw.) geschrieben.

Unser Thermostat ist mit solchen Systemen kompatibel und hat alle oben genannten Eigenschaften. Das Besondere ist jedoch, dass der Thermostat dank der Flexibilität des Systems ständig verbessert wird. Mit jedem Update wird die Funktionalität erweitert. Zur Standardmethode für die Verwaltung des Systems (gemäß Zeitplan) wird eine adaptive hinzugefügt. Mit der Anwendung können Sie die Geolocation des Benutzers abrufen. Aus diesem Grund ändert das System die Betriebsmodi je nach Standort dynamisch. Und mit dem Wettermodul können Sie sich an die Wetterbedingungen anpassen.

Und Erweiterbarkeit. Jeder kann den bei ihm üblichen Thermostat durch unseren ersetzen. Mit minimalem Aufwand. Wir haben die 5 beliebtesten Sensoren auf dem Markt ausgewählt und deren Unterstützung hinzugefügt. Aber auch bei exklusiven Sensoreigenschaften kann der Benutzer es an unseren Thermostat anschließen. Dazu müssen Sie den Thermostat kalibrieren, um mit einem bestimmten Sensor zu arbeiten. Wir werden Anweisungen geben.

Wenn ein Thermostat oder ein anderes Gerät angeschlossen wird, erscheint es gleichzeitig überall: sowohl im Webinterface als auch in der PWA-Anwendung. Das Hinzufügen eines Geräts erfolgt automatisch: Verbinden Sie es einfach mit einem Wi-Fi-Netzwerk.

Unser System benötigt keinen Server und verwandelt sich im Fehlerfall nicht in einen Kürbis. Selbst wenn eine der Komponenten ausfällt, startet das System nicht gemäß dem Notfallszenario. Steuerungen, Sensoren, Geräte - jedes Element ist sowohl ein Server als auch ein Client, daher ist es völlig autonom.

Für Interessierte sind unsere sozialen Netzwerke: Telegramm , Instagram , Telegrammnachrichten , VK , Facebook .

E-Mail: shop@lytko.com

PS wir drängen nicht, den Server aufzugeben. Wir haben auch Unterstützung für den 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 ist der Server keine Schwachstelle, sondern ergänzt die Funktionalität und macht das System komfortabler.