For nogle tid siden præsenterede vi for dig . Denne artikel var oprindeligt tænkt som en demonstration af dens firmware og styringssystem. Men for at forklare logikken bag termostatens funktion og hvad vi har implementeret, er det nødvendigt at skitsere hele konceptet som helhed.
Om automatisering
Generelt kan al automatisering opdeles i tre kategorier:
Kategori 1 — enkeltstående "smarte" enheder. Du køber pærer, kedler osv. fra forskellige producenter. Fordele: hver enhed udvider funktionerne og øger komforten. Ulemper: for hver ny producent kræves der sin app. Protokoller for enheder fra forskellige producenter er ofte ikke kompatible med hinanden.
Kategori 2 — installation af en enkelt board PC eller x86 kompatibel enhed. Dette fjerner begrænsningerne for beregningskraft, og på denne maskine installeres MajorDoMo eller en anden serverdistribution til styring af det smarte hjem. På denne måde forbindes enheder fra de fleste producenter i et samlet informationsrum. Dvs. der oprettes en egen Server for det smarte hjem. Fordele: kompatibilitet under et centralt system, hvilket giver udvidede muligheder for styring. Ulemper: ved serverfejl falder hele systemet tilbage til fase 1, dvs. det bliver fragmenteret eller bliver ubrugeligt.
Kategori 3 — den mest hardcore mulighed. I renoveringsfasen lægges alle kommunikationer, og alle systemer duplikeres. Fordele: alt bliver gjort til perfektion, og så bliver hjemmet virkelig smart. Ulemper: ekstremt høj pris sammenlignet med kategorierne 1 og 2, behovet for at planlægge alt på forhånd og tage højde for hver lille detalje.
De fleste brugere vælger mulighed et og overgang til mulighed to. Og senere når de mest vedholdende op til mulighed tre.
Men der findes en mulighed, som man kan kalde et distribueret system: hver enkelt enhed vil være både server og klient. I bund og grund er dette et forsøg på at kombinere mulighed 1 og mulighed 2. At tage alle deres fordele og udelukke ulemperne, finde den gyldne middelvej.
Nogle vil måske sige, at en sådan løsning allerede findes. Men sådanne løsninger er snævert fokuserede; for dem, der har programmeringskendskab. Vores mål er at sænke indgangen til sådanne distribuerede systemer både i form af slutbrugerenheder og ved at integrere eksisterende enheder i vores system. I tilfælde af termostaten fjerner brugeren blot sin gamle termostat, installerer en smart enhed, og tilslutter sine eksisterende sensorer til den. Uden nogen yderligere handlinger.
Lad os overveje integrationen i vores system ved hjælp af et eksempel.
Forestil dig, at vi har 8 Sonoff-moduler i vores netværk. Nogle brugere vil være tilfredse med at styre gennem Sonoff-cloud (kategori 1). Nogle vil begynde at bruge tredjepartsfirmware og gradvist skifte til kategori 2. De fleste tredjepartsfirmwares fungerer efter det samme princip: overførsel af data til en MQTT-server. OpenHub, Majordomo eller enhver anden server tjener et formål – at samle disparate enheder i et samlet informationsrum, der er placeret enten på internettet eller i et lokalt netværk. Derfor er tilstedeværelsen af en Server nødvendig. Her opstår hovedproblemet – når Serveren svigter, stopper hele systemet med at fungere autonomt. For at forhindre dette bliver systemerne mere komplekse, og der tilføjes manuelle kontrolmetoder, der duplicerer automatikken i tilfælde af Serverfejl.
Vi har dog valgt en anden vej, hvor hver enhed er selvforsynende. På denne måde spiller Serveren ikke en afgørende rolle, men udvider blot funktionaliteten.
Lad os vende tilbage til tankeeksperimentet. Lad os igen tage de samme 8 Sonoff-moduler og installere Lytko-firmware i dem. I alle Lytko-firmwares er funktionen implementeret . SSDP – en netværksprotokol, der er baseret på et sæt internetprotokoller, der bruges til at annoncere og opdage netværkstjenester. Svaret på forespørgslen kan være både standard og udvidet. Vi har lagt, at dette svar, ud over standardfunktioner, også indeholder en liste over enheder i netværket. På den måde finder enhederne selv hinanden, og hver af dem vil have en sådan liste. Eksempel på SSDP-liste:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Som det fremgår af eksemplet, inkluderer listen id'er for enheder, ip-adressen i netværket, enhedstypen (i vores tilfælde en thermostat baseret på Sonoff). Denne liste opdateres hvert andet minut (denne tidsramme er tilstrækkelig til at reagere på dynamiske ændringer i antallet af enheder i netværket). På den måde overvåger vi tilføjelsen, ændringen og frakoblingen af enheder uden nogen handling fra brugerens side. Listen sendes til browseren eller mobilappen, og scriptet opretter automatisk en side med det angivne antal blokke. Hver blok svarer til en enhed/sensor/kontroller. Visuelt ser listen således ud:
Men hvis andre radiosensorer er tilsluttet esp8266/esp32 via cc2530 (ZigBee) eller nrf24 (MySensors)?
Om projekterne
På markedet findes der forskellige distribuerede systemer. Vores system gør det muligt at integrere med de mest populære.
Nedenfor er projekter, der på en eller anden måde forsøger at ændre situationen med inkompatibilitet mellem forskellige producenter. Det er for eksempel: , eller . er bundet til MQTT-serveren, så det passer ikke til eksemplet.
En af måderne at implementere MySensors på er en gateway baseret på ESP8266. De øvrige eksempler er på ESP32. Og i dem kan vi implementere vores arbejdsprincips metode til detektering og oprettelse af en liste over enheder.
Lad os foretage endnu et tankeeksperiment. Vi har ZESP32, SLS Gateway eller MySensors. Hvordan kan vi samle dem i et samlet informationsrum? Til standardfunktionerne i disse gateways tilføjer vi SSDP-protokolbiblioteket. Når der anmodes om denne controller via SSDP, tilføjer den en liste over de enheder, der er tilsluttet den, til det standardmæssige svar. Baseret på disse oplysninger vil browseren oprette en side. Generelt vil det se sådan ud:
Web-interface
PWA-applikation
"ssdpList":
{
"id": 94967291, // unik enhedsidentifikation
"ip": "192.168.x.x", // ip-adresse i netværket
"type": "thermostat" // enhedstype
},
{
"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 tilsluttet et Wi-Fi-netværk, vil den have sin egen IP, og hvis den er tilsluttet en gateway, vil enhedens IP-adresse være gatewayens IP-adresse.
Vi anvender WebSocket til kommunikation med enhederne. Dette minimerer ressourceomkostningerne i forhold til GET-anmodninger og muliggør dynamisk modtagelse af information ved tilslutning eller ændring.
Dataene hentes direkte fra den enhed, som blokken tilhører, uden at gå gennem serveren. Dermed fortsætter systemet med at fungere, selv hvis en enhed svigter. Den webbaserede grænseflade viser kun ikke det enhed, der er forsvundet fra listen. Men meddelelser om tab vil, hvis nødvendigt, komme som en notifikation i brugerens applikation.
Det første forsøg på at implementere en sådan tilgang var en PWA-applikation. Dette muliggør opbevaring af databasen af blokke på brugerens enhed og kun anmode om nødvendige data. Men på grund af strukturens særegenheder er denne mulighed utilstrækkelig. Den eneste løsning er native apps til Android og IOS, som i øjeblikket er under aktiv udvikling. Som standard vil appen kun fungere i det interne netværk. Hvis nødvendigt kan alt skiftes til ekstern kontrol. Når brugeren forlader det lokale netværk, skifter appen automatisk til skyen.
Den eksterne kontrol er en fuld duplication af siden. Når siden aktiveres, kan brugeren logge ind på serveren og styre enhederne via sin personlige konto. Derved udvider serveren funktionaliteten, hvilket gør det muligt at styre enhederne uden for hjemmet og ikke være bundet til port forwarding eller dedikeret IP.
Dermed er den ovenfor beskrevne mulighed fri for serverens ulemper og har også en række fordele i form af fleksibilitet i tilslutning af nye enheder.
Om termostaten
Lad os se på et eksempel på vores termostat.
Beregnet til:
- Regulering af temperaturen for hver termostat (vises som en separat blok);
- Indstilling af tidsplan for termostatens drift (morgen, dag, aften, nat);
- Valg af Wi-Fi-netværk og tilslutning af enheden dertil;
- Opdatering af enheden "over luften";
- Indstilling af MQTT;
- Opsætning af netværket, som enheden er tilsluttet.
Udover at styre via webgrænsefladen er der også klassisk betjening — ved tryk på skærmen. Der er monteret en Nextion NX3224T024 2,4 tommer skærm. Valget faldt på den på grund af den enkle betjening af enheden. Derudover er der en egen monitor under udvikling baseret på STM32. Dens funktionalitet er ikke ringere end Nextion, men den vil være billigere, hvilket vil have en positiv indvirkning på den endelige pris for enheden.
Som enhver respektabel termostat-skærm kan vores Nextion:
- indstille den ønskede temperatur til brugeren (ved knapperne til højre);
- tænde og slukke for driftsmode i henhold til skemaet (N-knappen);
- vise relæets aktivitet (pil til venstre);
- have børnesikring (fysiske tryk er blokeret, så længe låsen ikke er deaktiveret);
- vise WiFi-signalkvalitet.
Derudover kan monitoret:
- vælge typen af den installerede sensor for brugeren;
- styre børnesikringsfunktionen;
- opdatere firmware.
Ved at klikke på WiFi-baren kan brugeren få oplysninger om det tilsluttede netværk. QR-koden bruges til at parre enheden i HomeKit-firmware.
Demo-arbejde med skærmen:
Vi har udviklet med tre tilsluttede termostater.
Du spørger: “Hvad er særligt ved din termostat?” Der er mange termostater på markedet med Wi-Fi-funktion, tidsplanstyring, touch-betjening. Entusiaster har skrevet moduler til interaktion med de fleste populære smarte hussystemer (Majordomo, HomeAssistant osv.).
Vores termostat er kompatibel med sådanne systemer og har alle de nævnte funktioner. Men det, der adskiller sig, er, at termostaten konstant opdateres takket være systemets fleksibilitet. Med hver opdatering vil funktionaliteten blive udvidet. Ud over den standard måde at styre systemet på (ifølge tidsplanen) vil vi tilføje en adaptiv måde. Appen gør det muligt at få brugerens geolocation. Takket være dette vil systemet dynamisk ændre driftsmoduser afhængigt af brugerens placering. Og vejrmodulet sikrer tilpasning til vejrforholdene.
Og skalerbarhed. Enhver, der ønsker det, kan nemt erstatte den installerede almindelige termostat med vores. Med minimale anstrengelser. Vi har valgt 5 af de mest populære sensorer på markedet og tilføjet deres understøttelse. Men selv i tilfælde af eksklusive sensorfunktioner kan brugeren tilslutte den til vores termostat. For dette skal termostaten kalibreres til at arbejde med den specifikke sensor. Vi leverer instruktioner.
Når du tilslutter termostaten eller en anden enhed, vises den automatisk overalt: både i webgrænsefladen og i PWA-applikationen. Tilføjelsen af enheden sker automatisk: det er nok kun at tilslutte den til Wi-Fi-netværket.
Vores system har ikke brug for en server, og i tilfælde af serverfejl forvandler det sig ikke til en græsk punk. Selv ved fejl på en af komponenterne begynder systemet ikke at arbejde efter en nødscenarie. Controllere, sensorer, enheder — hvert element er både server og klient, og derfor helt autonomt.
For de interesserede — vores sociale medier: , , , , .
E-mail: shop@lytko.com
P. S. Vi opfordrer ikke til at opgive serveren. Vi har også støtte til MQTT-servere og har vores eget cloud. Vores mål er at bringe stabiliteten og pålideligheden af systemet til et kvalitetsniveau. Så serveren ikke bliver det svage punkt, men supplerer funktionaliteten og gør systemet mere brugervenligt.
Kilde: habr.com
