Enige tijd geleden hebben wij jullie voorgesteld . Dit artikel was oorspronkelijk bedoeld als demonstratie van de firmware en het besturingssysteem. Maar om de logica van de thermostaat en wat we hebben geïmplementeerd uit te leggen, is het noodzakelijk om het hele concept als geheel te schetsen.
Over automatisering
Conventioneel kan alle automatisering in drie categorieën worden verdeeld:
Categorie 1 — afzonderlijke “slimme” apparaten. U koopt lampen, theepotten etc. van verschillende fabrikanten. Voordelen: Elk apparaat breidt de mogelijkheden uit en verhoogt het comfort. Nadelen: elke nieuwe fabrikant heeft zijn eigen toepassing nodig. Protocollen van apparaten van verschillende fabrikanten zijn vaak niet compatibel met elkaar.
Categorie 2 — installatie van een single-board pc of x86-compatibel. Hiermee worden de beperkingen op de rekenkracht opgeheven en wordt MajorDoMo of een andere serverdistributie voor het beheren van een smart home op deze machine geïnstalleerd. Apparaten van de meeste fabrikanten zijn dus verbonden in één informatieruimte. Die. uw eigen Server voor een smart home verschijnt. Voordelen: compatibiliteit onder één enkel centrum, dat verbeterde beheermogelijkheden biedt. Nadelen: als de server uitvalt, keert het hele systeem terug naar fase 1, d.w.z. gefragmenteerd raakt of nutteloos wordt.
Categorie 3 - de meest hardcore optie. In de reparatiefase wordt alle communicatie gelegd en worden alle systemen gedupliceerd. Pluspunten: alles wordt tot in de perfectie gebracht en dan wordt het huis echt slim. Nadelen: extreem duur in vergelijking met categorie 1 en 2, de noodzaak om alles vooraf te overdenken en rekening te houden met elk klein detail.
De meeste gebruikers kiezen voor optie één en gaan vervolgens vlot over naar optie twee. En dan komen de meest hardnekkige bij optie 3.
Maar er is een optie die een gedistribueerd systeem kan worden genoemd: elk afzonderlijk apparaat zal zowel een server als een client zijn. In wezen is dit een poging om optie 1 en optie 2 te combineren. Neem al hun voordelen en elimineer de nadelen, om de gulden middenweg te vinden.
Misschien zal iemand zeggen dat een dergelijke optie al is ontwikkeld. Maar dergelijke beslissingen zijn beperkt gericht; voor mensen die handig zijn met programmeren. Ons doel is om de drempel voor toegang tot dergelijke gedistribueerde systemen te verlagen, zowel in de vorm van eindapparaten als in de vorm van het integreren van bestaande apparaten in ons systeem. In het geval van een thermostaat verwijdert de gebruiker simpelweg zijn oude thermostaat, installeert hij een slimme thermostaat en sluit hij zijn bestaande sensoren daarop aan. Zonder extra stappen.
Laten we de integratie in ons systeem bekijken aan de hand van een voorbeeld.
Laten we ons voorstellen dat we 8 Sonoff-modules op ons netwerk hebben. Voor sommige gebruikers zal bediening via de Sonoff-cloud (categorie 1) voldoende zijn. Sommigen zullen firmware van derden gaan gebruiken en zullen soepel overgaan naar categorie 2. Het grootste deel van de firmware van derden werkt volgens hetzelfde principe: gegevens overbrengen naar een MQTT-server. OpenHub, Majordomo of iets anders dienen één doel: het verenigen van uiteenlopende apparaten in één enkele informatieruimte die zich op internet of op een lokaal netwerk bevindt. Daarom is de aanwezigheid van een server verplicht. Dit is waar het grootste probleem zich voordoet: als de server uitvalt, stopt het hele systeem autonoom te werken. Om dit te voorkomen worden systemen complexer en worden handmatige controlemethoden toegevoegd die de automatisering dupliceren in het geval van een serverstoring.
We zijn een ander pad ingeslagen, waarbij elk apparaat zelfvoorzienend is. De server speelt dus geen doorslaggevende rol, maar breidt alleen de functionaliteit uit.
Laten we terugkeren naar het gedachte-experiment. Laten we dezelfde 8 Sonoff-modules opnieuw nemen en Lytko-firmware daarin installeren. Alle Lytko-firmwares hebben de functie . SSDP is een netwerkprotocol gebaseerd op de internetprotocolsuite voor het adverteren en ontdekken van netwerkdiensten. Het antwoord op een verzoek kan standaard of uitgebreid zijn. Naast de standaardfuncties hebben we in dit antwoord het maken van een lijst met apparaten op het netwerk opgenomen. Zo vinden de apparaten elkaar zelf, en elk van hen zal zo'n lijst hebben. Voorbeeld SSDP-blad:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Zoals u in het voorbeeld kunt zien, bevat de lijst apparaat-ID's, IP-adres op het netwerk en unittype (in ons geval een op Sonoff gebaseerde thermostaat). Deze lijst wordt elke twee minuten bijgewerkt (deze periode is voldoende om te reageren op dynamische veranderingen in het aantal apparaten op het netwerk). Op deze manier volgen we toegevoegde, gewijzigde en uitgeschakelde apparaten zonder enige actie van de gebruiker. Deze lijst wordt naar de browser of mobiele applicatie gestuurd en het script genereert zelf een pagina met een bepaald aantal blokken. Elk blok komt overeen met één apparaat/sensor/controller. Visueel ziet de lijst er als volgt uit:
Maar wat als er andere radiosensoren via cc8266 (ZigBee) of nrf32 (MySensors) op de esp2530/esp24 worden aangesloten?
Over projecten
На рынке присутствуют различные распределенные системы. Наша система позволяет интегрироваться с самыми популярными.
Hieronder staan projecten die op de een of andere manier proberen de situatie te veranderen met de incompatibiliteit van verschillende fabrikanten met elkaar. Dit is bijvoorbeeld , of . is gekoppeld aan een MQTT-server en is dus niet geschikt voor het voorbeeld.
Een optie voor het implementeren van MySensors is een gateway op basis van de ESP8266. De rest van de voorbeelden staan op ESP32. En daarin kunt u ons werkingsprincipe van het detecteren en creëren van een lijst met apparaten implementeren.
Laten we nog een gedachte-experiment doen. We hebben een ZESP32-gateway of SLS Gateway, of MySensors. Hoe kunnen ze worden gecombineerd in één informatieruimte? We zullen de SSDP-protocolbibliotheek toevoegen aan de standaardfuncties van deze gateways. Wanneer u via SSDP toegang krijgt tot deze controller, wordt een lijst met apparaten die erop zijn aangesloten toegevoegd aan het standaardantwoord. Op basis van deze informatie genereert de browser een pagina. Over het algemeen zal het er als volgt uitzien:
Web-interface
PWA-applicatie
"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"
}
Het voorbeeld laat zien dat apparaten onafhankelijk van elkaar worden toegevoegd. Er zijn 3 thermostaten met eigen IP-adressen en 5 verschillende sensoren met unieke ID's verbonden. Als de sensor is verbonden met een Wi-Fi-netwerk, heeft deze een eigen IP; als hij is verbonden met een gateway, is het IP-adres van het apparaat het IP-adres van de gateway.
We gebruiken WebSocket om met apparaten te communiceren. Hierdoor kunt u de resourcekosten minimaliseren in vergelijking met het ontvangen van aanvragen en het dynamisch verkrijgen van informatie bij het verbinden of wijzigen.
De gegevens worden rechtstreeks overgenomen van het apparaat waartoe het blok behoort, waarbij de server wordt omzeild. Dus als een van de apparaten uitvalt, blijft het systeem werken. De webinterface geeft het ontbrekende apparaat uit de lijst gewoon niet weer. Maar een signaal over het verlies komt, indien nodig, in de vorm van een melding in de applicatie van de gebruiker.
De eerste poging om deze aanpak te implementeren was een PWA-applicatie. Hierdoor kunt u een blokbasis op het apparaat van de gebruiker opslaan en alleen de noodzakelijke gegevens opvragen. Maar vanwege de eigenaardigheden van de structuur is deze optie onvolledig. En er is maar één uitweg: een native applicatie voor Android en IOS, die momenteel actief wordt ontwikkeld. Standaard werkt de applicatie alleen op het interne netwerk. Indien nodig kunt u alles overdragen aan externe besturing. Wanneer de gebruiker het lokale netwerk verlaat, schakelt de applicatie dus automatisch over naar de cloud.
Externe controle - volledige duplicatie van de pagina. Wanneer de pagina is geactiveerd, kan de gebruiker inloggen op de server en apparaten beheren via zijn persoonlijke account. Zo breidt de server zijn functionaliteit uit, waardoor u apparaten buitenshuis kunt beheren en niet gebonden bent aan port forwarding of een speciaal IP-adres.
Bovenstaande optie heeft dus niet de nadelen van de serveraanpak, maar heeft ook een aantal voordelen in de vorm van flexibiliteit bij het aansluiten van nieuwe apparaten.
Over de thermostaat
Laten we eens kijken naar het besturingssysteem met onze thermostaat als voorbeeld.
Mits:
- Temperatuurregeling voor elke thermostaat (weergegeven als apart blok);
- Instellen van het werkingsschema van de thermostaat (ochtend, middag, avond, nacht);
- Een Wi-Fi-netwerk selecteren en er een apparaat op aansluiten;
- Het apparaat ‘over the air’ updaten;
- MQTT opzetten;
- Configureer het netwerk waarmee het apparaat is verbonden.
Naast de bediening via de webinterface hebben we de klassieke versie geleverd: door op het display te klikken. Er is een Nextion NX3224T024 2.4 inch monitor aan boord. De keuze viel op hem vanwege het gemak van het werken met het apparaat. Maar we ontwikkelen onze eigen monitor op basis van STM32. De functionaliteit is niet slechter dan die van Nextion, maar kost minder, wat een positieve invloed zal hebben op de uiteindelijke prijs van het apparaat.
Zoals elk zichzelf respecterend thermostaatscherm kan onze Nextion:
- stel de door de gebruiker gewenste temperatuur in (met behulp van de knoppen aan de rechterkant);
- schakel de geplande bedieningsmodus in en uit (knop H);
- weergave relaiswerking (pijl links);
- beschikt over kinderbeveiliging (fysieke klikken worden geblokkeerd totdat het slot wordt verwijderd);
- geeft de WiFi-signaalsterkte weer.
Bovendien kunt u met de monitor:
- selecteer het type sensor dat door de gebruiker is geïnstalleerd;
- de kinderslotfunctie beheren;
- update de firmware.
Door op de WiFi-balk te klikken, krijgt de gebruiker informatie over het verbonden netwerk. De QR-code wordt gebruikt om het apparaat te koppelen in de HomeKit-firmware.
Demo van het werken met het display:
Wij hebben ontwikkeld met drie aangesloten thermostaten.
Je vraagt je misschien af: 'Wat is er speciaal aan je thermostaat?' Nu zijn er veel thermostaten op de markt met Wi-Fi-functie, geplande bediening en aanraakbediening. En enthousiastelingen hebben modules geschreven om te communiceren met de meest populaire smart home-systemen (Majordomo, HomeAssistant, enz.).
Onze thermostaat is compatibel met dergelijke systemen en beschikt over al het bovenstaande. Maar het onderscheidende kenmerk is dat de thermostaat voortdurend wordt verbeterd, dankzij de flexibiliteit van het systeem. Met elke update wordt de functionaliteit uitgebreid. Aan de standaardmethode van systeembeheer (volgens een schema) voegen we een adaptieve manier toe. Met de applicatie kunt u de geolocatie van de gebruiker verkrijgen. Dankzij dit zal het systeem de bedrijfsmodi dynamisch veranderen, afhankelijk van de locatie. En met de weermodule kunt u zich aanpassen aan de weersomstandigheden.
En uitbreidbaarheid. Iedereen kan zijn bestaande conventionele thermostaat vervangen door de onze. Met minimale inspanning. We hebben 5 van de populairste sensoren op de markt geselecteerd en er ondersteuning voor toegevoegd. Maar zelfs als de sensor exclusieve eigenschappen heeft, kan de gebruiker hem op onze thermostaat aansluiten. Om dit te doen, moet u de thermostaat kalibreren om met een specifieke sensor te werken. Wij zullen instructies geven.
Bij het aansluiten van een thermostaat of ander apparaat verschijnt deze overal tegelijkertijd: zowel in de webinterface als in de PWA-applicatie. Het toevoegen van een apparaat gebeurt automatisch: je hoeft het alleen maar te verbinden met het Wi-Fi-netwerk.
Ons systeem heeft geen server nodig, en als het faalt, verandert het niet in een pompoen. Zelfs als een van de componenten uitvalt, treedt het systeem in een noodscenario niet in werking. Controllers, sensoren, apparaten - elk element is zowel een server als een client en dus volledig autonoom.
Voor degenen die geïnteresseerd zijn, onze sociale netwerken: , , , , .
E-mail: [e-mail beveiligd]
PS Wij moedigen u niet aan om de Server te verlaten. We ondersteunen ook een MQTT-server en hebben onze eigen cloud. Ons doel is om de stabiliteit en betrouwbaarheid van het systeem naar een geheel nieuw niveau te brengen. Zodat de Server geen zwak punt is, maar de functionaliteit aanvult en het systeem handiger maakt.
Bron: www.habr.com