For noget tid siden præsenterede vi dig . Denne artikel var oprindeligt tænkt som en demonstration af dets firmware og kontrolsystem. Men for at forklare termostatens logik og hvad vi implementerede, er det nødvendigt at skitsere hele konceptet som en helhed.
Om automatisering
Konventionelt kan al automatisering opdeles i tre kategorier:
Kategori 1 — separate "smarte" enheder. Du køber elpærer, tekander osv. fra forskellige producenter. Fordele: Hver enhed udvider mulighederne og øger komforten. Ulemper: Hver ny producent kræver sin egen applikation. Protokoller for enheder fra forskellige producenter er ofte ikke kompatible med hinanden.
Kategori 2 — installation af en enkeltkort-pc eller x86-kompatibel. Dette fjerner begrænsninger på computerkraft, og MajorDoMo eller enhver anden serverdistribution til styring af et smart hjem er installeret på denne maskine. Enheder fra de fleste producenter er således forbundet i et enkelt informationsrum. De der. din egen server til et smart hjem vises. Fordele: kompatibilitet under et enkelt center, som giver forbedrede administrationsmuligheder. Ulemper: hvis serveren fejler, vender hele systemet tilbage til trin 1, dvs. bliver fragmenteret eller ubrugelig.
Kategori 3 - den mest hardcore mulighed. På reparationsstadiet er al kommunikation lagt og alle systemer duplikeret. Fordele: alt er bragt til perfektion, og så bliver huset virkelig smart. Ulemper: ekstremt dyrt i forhold til kategori 1 og 2, behovet for at tænke alt igennem på forhånd og tage højde for hver lille detalje.
De fleste brugere vælger mulighed et og går derefter glat videre til mulighed to. Og så når de mest vedholdende mulighed 3.
Men der er en mulighed, der kan kaldes et distribueret system: hver enkelt enhed vil være både en server og en klient. I bund og grund er dette et forsøg på at tage og kombinere mulighed 1 og mulighed 2. Tag alle deres fordele og eliminer ulemperne for at fange den gyldne middelvej.
Måske vil nogen sige, at en sådan mulighed allerede er blevet udviklet. Men sådanne beslutninger er snævert fokuserede; for folk, der er kyndige i programmering. Vores mål er at sænke barrieren for adgang til sådanne distribuerede systemer, både i form af slutenheder og i form af at integrere eksisterende enheder i vores system. I tilfælde af en termostat, fjerner brugeren blot sin gamle termostat, installerer en smart en og forbinder sine eksisterende sensorer til den. Uden yderligere trin.
Lad os se på integration i vores system ved hjælp af et eksempel.
Lad os forestille os, at vi har 8 Sonoff-moduler på vores netværk. For nogle brugere vil kontrol via Sonoff-skyen (kategori 1) være tilstrækkelig. Nogle vil begynde at bruge tredjeparts firmware og vil uden problemer flytte ind i kategori 2. Størstedelen af tredjeparts firmware fungerer efter samme princip: overførsel af data til en MQTT-server. OpenHub, Majordomo eller en hvilken som helst anden tjener ét formål - at forene forskellige enheder i et enkelt informationsrum placeret enten på internettet eller på et lokalt netværk. Derfor er tilstedeværelsen af en server obligatorisk. Det er her hovedproblemet opstår - hvis serveren svigter, holder hele systemet op med at fungere autonomt. For at forhindre dette bliver systemer mere komplekse, manuelle kontrolmetoder tilføjes, som duplikerer automatisering i tilfælde af en serverfejl.
Vi tog en anden vej, hvor hver enhed er selvforsynende. Serveren spiller således ikke en afgørende rolle, men udvider kun funktionaliteten.
Lad os vende tilbage til tankeeksperimentet. Lad os tage de samme 8 Sonoff-moduler igen og installere Lytko-firmware i dem. Alle Lytko firmwares har funktionen . SSDP er en netværksprotokol baseret på internetprotokolpakken til annoncering og opdagelse af netværkstjenester. Svaret på en anmodning kan enten være standard eller udvidet. Ud over standardfunktioner inkluderede vi i dette svar oprettelsen af en liste over enheder på netværket. Således finder enhederne selv hinanden, og hver af dem vil have en sådan liste. Eksempel på SSDP-ark:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Som det kan ses af eksemplet, inkluderer listen enheds-id'er, IP-adresse på netværket og enhedstype (i vores tilfælde en Sonoff-baseret termostat). Denne liste opdateres hvert andet minut (denne periode er tilstrækkelig til at reagere på dynamiske ændringer i antallet af enheder på netværket). På denne måde sporer vi tilføjede, ændrede og deaktiverede enheder uden nogen brugerhandling. Denne liste sendes til browseren eller mobilapplikationen, og selve scriptet genererer en side med et givet antal blokke. Hver blok svarer til én enhed/sensor/controller. Visuelt ser listen sådan ud:
Men hvad hvis andre radiosensorer er forbundet til esp8266/esp32 via cc2530 (ZigBee) eller nrf24 (MySensors)?
Om projekter
Der findes forskellige distribuerede systemer på markedet. Vores system giver dig mulighed for at integrere med de mest populære.
Nedenfor er projekter, der på en eller anden måde forsøger at ændre situationen med forskellige producenters uforenelighed med hinanden. Dette er f.eks. , eller . er bundet til en MQTT-server, så den er ikke egnet til eksemplet.
En mulighed for at implementere MySensors er en gateway baseret på ESP8266. Resten af eksemplerne er på ESP32. Og i dem kan du implementere vores driftsprincip for at opdage og oprette en liste over enheder.
Lad os lave endnu et tankeeksperiment. Vi har en ZESP32 gateway eller SLS Gateway eller MySensors. Hvordan kan de kombineres i et enkelt informationsrum? Vi tilføjer SSDP-protokolbiblioteket til standardfunktionerne i disse gateways. Når du får adgang til denne controller via SSDP, tilføjer den en liste over enheder, der er forbundet til den, til standardsvaret. Baseret på disse oplysninger vil browseren generere en side. Generelt vil det se sådan ud:
Webgrænseflade
PWA applikation
"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"
}
Eksemplet viser, at enheder tilføjes uafhængigt af hinanden. Der er tilsluttet 3 termostater med deres egne IP-adresser og 5 forskellige sensorer med unikke ID'er. Hvis sensoren er forbundet til et Wi-Fi-netværk, vil den have sin egen IP; hvis den er forbundet til en gateway, vil enhedens IP-adresse være gatewayens IP-adresse.
Vi bruger WebSocket til at kommunikere med enheder. Dette giver dig mulighed for at minimere ressourceomkostninger sammenlignet med at få forespørgsler og opnå information dynamisk, når du forbinder eller ændrer.
Dataene tages direkte fra den enhed, som blokken tilhører, uden om serveren. Hvis nogen af enhederne svigter, fortsætter systemet med at fungere. Webgrænsefladen viser bare ikke den manglende enhed fra listen. Men et signal om tabet vil om nødvendigt komme i form af en meddelelse i brugerens applikation.
Det første forsøg på at implementere denne tilgang var en PWA-applikation. Dette giver dig mulighed for at gemme en blokbase på brugerens enhed og kun anmode om de nødvendige data. Men på grund af strukturens ejendommeligheder er denne mulighed ufuldstændig. Og der er kun én vej ud – en indbygget applikation til Android og IOS, som i øjeblikket er under aktiv udvikling. Som standard vil applikationen kun fungere på det interne netværk. Om nødvendigt kan du overføre alt til ekstern kontrol. Så når brugeren forlader det lokale netværk, skifter applikationen automatisk til skyen.
Ekstern kontrol - fuldstændig duplikering af siden. Når siden er aktiveret, kan brugeren logge ind på serveren og administrere enheder via deres personlige konto. Således udvider serveren sin funktionalitet, så du kan administrere enheder, mens du er uden for hjemmet, og ikke være bundet til portvideresendelse eller en dedikeret IP.
Ovenstående mulighed har således ikke servertilgangens ulemper, og har også en række fordele i form af fleksibilitet i forbindelse med tilslutning af nye enheder.
Om termostaten
Lad os se på kontrolsystemet med vores termostat som eksempel.
Stillet til rådighed:
- Temperaturkontrol for hver termostat (vises som en separat blok);
- Indstilling af termostatens driftstidsplan (morgen, eftermiddag, aften, nat);
- Valg af et Wi-Fi-netværk og tilslutning af en enhed til det;
- Opdatering af enheden "over the air";
- Opsætning af MQTT;
- Konfigurer det netværk, som enheden er tilsluttet.
Udover styring via webgrænsefladen leverede vi den klassiske - ved at klikke på displayet. Der er en Nextion NX3224T024 2.4-tommer skærm ombord. Valget faldt på ham på grund af det lette at arbejde med enheden. Men vi er ved at udvikle vores egen skærm baseret på STM32. Dens funktionalitet er ikke værre end Nextions, men den vil koste mindre, hvilket vil have en positiv indvirkning på den endelige pris på enheden.
Som enhver termostatskærm med respekt for sig selv kan vores Nextion:
- indstil den temperatur, der kræves af brugeren (ved hjælp af knapperne til højre);
- tænd og sluk for den planlagte driftstilstand (knap H);
- display relædrift (pil til venstre);
- har børnebeskyttelse (fysiske klik er blokeret, indtil låsen fjernes);
- viser WiFi-signalstyrken.
Derudover kan du ved at bruge skærmen:
- vælg den type sensor, der er installeret af brugeren;
- administrere børnesikringsfunktionen;
- opdatere firmwaren.
Ved at klikke på WiFi-bjælken finder brugeren information om det tilsluttede netværk. QR-koden bruges til at parre enheden i HomeKit-firmwaren.
Demo af arbejdet med skærmen:
Vi har udviklet os med tre tilsluttede termostater.
Du kan spørge: "Hvad er specielt ved din termostat?" Nu på markedet er der mange termostater med Wi-Fi-funktion, planlagt drift og berøringsstyring. Og entusiaster har skrevet moduler til at interagere med de mest populære smart home-systemer (Majordomo, HomeAssistant osv.).
Vores termostat er kompatibel med sådanne systemer og har alle ovenstående. Men det karakteristiske er, at termostaten konstant bliver forbedret, takket være systemets fleksibilitet. Med hver opdatering udvides funktionaliteten. Til standardmetoden til systemstyring (i henhold til en tidsplan) tilføjer vi en adaptiv. Applikationen giver dig mulighed for at få brugerens geolocation. Takket være dette vil systemet dynamisk ændre driftstilstande afhængigt af dets placering. Og vejrmodulet giver dig mulighed for at tilpasse dig vejrforholdene.
Og udvidelsesmuligheder. Alle kan erstatte deres eksisterende konventionelle termostat med vores. Med minimal indsats. Vi har udvalgt 5 af de mest populære sensorer på markedet og tilføjet support til dem. Men selvom sensoren har eksklusive egenskaber, vil brugeren være i stand til at tilslutte den til vores termostat. For at gøre dette skal du kalibrere termostaten til at arbejde med en bestemt sensor. Vi vil give instruktioner.
Når du tilslutter en termostat eller en hvilken som helst anden enhed, vises den samtidigt overalt: både i webgrænsefladen og i PWA-applikationen. Tilføjelse af en enhed sker automatisk: du skal bare forbinde den til Wi-Fi-netværket.
Vores system behøver ikke en server, og hvis det fejler, bliver det ikke til et græskar. Selvom en af komponenterne svigter, begynder systemet ikke at fungere i en nødsituation. Controllere, sensorer, enheder - hvert element er både en server og en klient, derfor fuldstændig autonomt.
For de interesserede, vores sociale netværk: , , , , .
E-mail: [e-mail beskyttet]
PS Vi opfordrer dig ikke til at forlade serveren. Vi understøtter også en MQTT-server og har vores egen sky. Vores mål er at bringe systemets stabilitet og pålidelighed til et helt nyt niveau. Så serveren ikke er et svagt punkt, men komplementerer funktionaliteten og gør systemet mere bekvemt.
Kilde: www.habr.com