For en tid siden introduserte vi deg . Denne artikkelen var opprinnelig ment som en demonstrasjon av fastvaren og kontrollsystemet. Men for å forklare logikken til termostaten og hva vi implementerte, er det nødvendig å skissere hele konseptet som en helhet.
Om automatisering
Konvensjonelt kan all automatisering deles inn i tre kategorier:
Kategori 1 — separate "smarte" enheter. Du kjøper lyspærer, tekanner osv. fra forskjellige produsenter. Fordeler: Hver enhet utvider mulighetene og øker komforten. Ulemper: Hver ny produsent krever sin egen applikasjon. Protokoller til enheter fra forskjellige produsenter er ofte ikke kompatible med hverandre.
Kategori 2 — installasjon av en enkeltkorts PC eller x86-kompatibel. Dette fjerner restriksjoner på datakraft, og MajorDoMo eller annen serverdistribusjon for å administrere et smarthjem er installert på denne maskinen. Dermed er enheter fra de fleste produsenter koblet sammen i et enkelt informasjonsrom. De. din egen server for et smart hjem vises. Fordeler: kompatibilitet under ett enkelt senter, som gir forbedrede administrasjonsmuligheter. Ulemper: hvis serveren svikter, går hele systemet tilbake til trinn 1, dvs. blir fragmentert eller ubrukelig.
Kategori 3 - det mest hardcore alternativet. På reparasjonsstadiet legges all kommunikasjon og alle systemer dupliseres. Fordeler: alt er brakt til perfeksjon og da blir huset virkelig smart. Ulemper: ekstremt dyrt sammenlignet med kategori 1 og 2, behovet for å tenke gjennom alt på forhånd og ta hensyn til hver minste detalj.
De fleste brukere velger alternativ én og går deretter jevnt videre til alternativ to. Og så når de mest vedvarende alternativ 3.
Men det er et alternativ som kan kalles et distribuert system: hver enkelt enhet vil være både en server og en klient. I hovedsak er dette et forsøk på å ta og kombinere alternativ 1 og alternativ 2. Ta alle fordelene deres og eliminer ulempene, for å fange den gyldne middelvei.
Kanskje noen vil si at et slikt alternativ allerede er utviklet. Men slike beslutninger er snevert fokuserte; for folk som er kunnskapsrike i programmering. Vårt mål er å senke barrieren for inntreden i slike distribuerte systemer, både i form av sluttenheter og i form av å integrere eksisterende enheter i systemet vårt. Når det gjelder en termostat, fjerner brukeren ganske enkelt sin gamle termostat, installerer en smart en og kobler sine eksisterende sensorer til den. Uten noen ekstra trinn.
La oss se på integrering i systemet vårt ved å bruke et eksempel.
La oss forestille oss at vi har 8 Sonoff-moduler på nettverket vårt. For noen brukere vil kontroll via Sonoff-skyen (kategori 1) være tilstrekkelig. Noen vil begynne å bruke tredjeparts firmware og vil jevnt flytte inn i kategori 2. Mesteparten av tredjeparts firmware fungerer på samme prinsipp: overføring av data til en MQTT-server. OpenHub, Majordomo eller en hvilken som helst annen tjener ett formål - å forene forskjellige enheter til et enkelt informasjonsrom plassert enten på Internett eller på et lokalt nettverk. Derfor er tilstedeværelsen av en server obligatorisk. Det er her hovedproblemet oppstår - hvis serveren svikter, slutter hele systemet å fungere autonomt. For å forhindre dette blir systemene mer komplekse, manuelle kontrollmetoder legges til som dupliserer automatisering i tilfelle serverfeil.
Vi tok en annen vei, der hver enhet er selvforsynt. Dermed spiller ikke Serveren en avgjørende rolle, men utvider kun funksjonaliteten.
La oss gå tilbake til tankeeksperimentet. La oss ta de samme 8 Sonoff-modulene igjen og installere Lytko-firmware i dem. Alle Lytko-firmwares har funksjonen . SSDP er en nettverksprotokoll basert på Internett-protokollpakken for annonsering og oppdagelse av nettverkstjenester. Svaret på en forespørsel kan enten være standard eller utvidet. I tillegg til standardfunksjoner, inkluderte vi i dette svaret opprettelsen av en liste over enheter på nettverket. Dermed finner enhetene selv hverandre, og hver av dem vil ha en slik 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 du kan se fra eksempelet, inkluderer listen enhets-IDer, IP-adresse på nettverket, enhetstype (i vårt tilfelle en Sonoff-basert termostat). Denne listen oppdateres hvert annet minutt (denne perioden er tilstrekkelig til å svare på dynamiske endringer i antall enheter på nettverket). På denne måten sporer vi enheter lagt til, endret og deaktivert uten noen brukerhandling. Denne listen sendes til nettleseren eller mobilapplikasjonen, og selve skriptet genererer en side med et gitt antall blokker. Hver blokk tilsvarer én enhet/sensor/kontroller. Visuelt ser listen slik ut:
Men hva om andre radiosensorer er koblet til esp8266/esp32 via cc2530 (ZigBee) eller nrf24 (MySensors)?
Om prosjekter
Det finnes ulike distribuerte systemer på markedet. Vårt system lar deg integrere med de mest populære.
Nedenfor er prosjekter som på en eller annen måte prøver å endre situasjonen med inkompatibiliteten til forskjellige produsenter med hverandre. Dette er f.eks. , eller . er knyttet til en MQTT-server, så den er ikke egnet for eksempelet.
Et alternativ for å implementere MySensors er en gateway basert på ESP8266. Resten av eksemplene er på ESP32. Og i dem kan du implementere vårt driftsprinsipp for å oppdage og lage en liste over enheter.
La oss gjøre et nytt tankeeksperiment. Vi har en ZESP32 gateway eller SLS Gateway, eller MySensors. Hvordan kan de kombineres i ett enkelt informasjonsrom? Vi vil legge til SSDP-protokollbiblioteket til standardfunksjonene til disse gatewayene. Når du får tilgang til denne kontrolleren via SSDP, vil den legge til en liste over enheter som er koblet til den til standardsvaret. Basert på denne informasjonen vil nettleseren generere en side. Generelt vil det se slik ut:
Webgrensesnitt
PWA-applikasjon
"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 enheter legges til uavhengig av hverandre. 3 termostater med egne IP-adresser og 5 forskjellige sensorer med unike IDer er tilkoblet. Hvis sensoren er koblet til et Wi-Fi-nettverk, vil den ha sin egen IP; hvis den er koblet til en gateway, vil enhetens IP-adresse være gatewayens IP-adresse.
Vi bruker WebSocket til å kommunisere med enheter. Dette lar deg minimere ressurskostnadene sammenlignet med å få forespørsler og innhente informasjon dynamisk når du kobler til eller endrer.
Dataene hentes direkte fra enheten som blokken tilhører, og omgår serveren. Derfor, hvis noen av enhetene svikter, fortsetter systemet å fungere. Nettgrensesnittet viser bare ikke den manglende enheten fra listen. Men et signal om tapet, om nødvendig, vil komme i form av et varsel i brukerens applikasjon.
Det første forsøket på å implementere denne tilnærmingen var en PWA-applikasjon. Dette lar deg lagre en blokkbase på brukerens enhet og be om bare de nødvendige dataene. Men på grunn av strukturens særegenheter er dette alternativet ufullstendig. Og det er bare én vei ut - en innebygd applikasjon for Android og IOS, som for tiden er under aktiv utvikling. Som standard vil applikasjonen bare fungere på det interne nettverket. Om nødvendig kan du overføre alt til ekstern kontroll. Så når brukeren forlater det lokale nettverket, bytter applikasjonen automatisk til skyen.
Ekstern kontroll - fullstendig duplisering av siden. Når siden er aktivert, kan brukeren logge på serveren og administrere enheter gjennom sin personlige konto. Dermed utvider serveren sin funksjonalitet, slik at du kan administrere enheter mens du er utenfor hjemmet, og ikke være knyttet til portvideresending eller en dedikert IP.
Dermed har ikke alternativet ovenfor servertilnærmingens ulemper, og har også en rekke fordeler i form av fleksibilitet ved tilkobling av nye enheter.
Om termostaten
La oss se på kontrollsystemet med termostaten vår som et eksempel.
Sørget for:
- Temperaturkontroll for hver termostat (vises som en separat blokk);
- Stille inn termostatens driftsplan (morgen, ettermiddag, kveld, natt);
- Velge et Wi-Fi-nettverk og koble en enhet til det;
- Oppdatering av enheten "over luften";
- Sette opp MQTT;
- Konfigurer nettverket som enheten er koblet til.
I tillegg til kontroll via nettgrensesnittet, ga vi det klassiske – ved å klikke på displayet. Det er en Nextion NX3224T024 2.4-tommers skjerm om bord. Valget falt på ham på grunn av det enkle å jobbe med enheten. Men vi utvikler vår egen skjerm basert på STM32. Funksjonaliteten er ikke dårligere enn Nextion, men den vil koste mindre, noe som vil ha en positiv innvirkning på den endelige prisen på enheten.
Som enhver termostatskjerm med respekt for seg selv, kan vår Nextion:
- still inn temperaturen som kreves av brukeren (ved hjelp av knappene til høyre);
- slå på og av den planlagte driftsmodusen (knapp H);
- display relédrift (pil til venstre);
- har barnevern (fysiske klikk er blokkert til låsen er fjernet);
- viser WiFi-signalstyrken.
I tillegg kan du ved å bruke skjermen:
- velg typen sensor installert av brukeren;
- administrere barnesikringsfunksjonen;
- oppdatere fastvaren.
Ved å klikke på WiFi-linjen vil brukeren finne informasjon om det tilkoblede nettverket. QR-koden brukes til å pare enheten i HomeKit-fastvaren.
Demo av arbeid med skjermen:
Vi har utviklet oss med tre tilkoblede termostater.
Du kan spørre: "Hva er spesielt med termostaten din?" Nå på markedet er det mange termostater med Wi-Fi-funksjon, planlagt drift og berøringskontroll. Og entusiaster har skrevet moduler for å samhandle med de mest populære smarthussystemene (Majordomo, HomeAssistant, etc.).
Termostaten vår er kompatibel med slike systemer og har alt det ovennevnte. Men det særegne er at termostaten blir stadig forbedret, takket være systemets fleksibilitet. Med hver oppdatering vil funksjonaliteten utvides. Til standardmetoden for systemadministrasjon (i henhold til en tidsplan), vil vi legge til en adaptiv. Applikasjonen lar deg få brukerens geolokalisering. Takket være dette vil systemet dynamisk endre driftsmodus avhengig av plasseringen. Og værmodulen lar deg tilpasse deg værforholdene.
Og utvidelsesmuligheter. Hvem som helst kan erstatte sin eksisterende konvensjonelle termostat med vår. Med minimal innsats. Vi har valgt ut 5 av de mest populære sensorene på markedet og lagt til støtte for dem. Men selv om sensoren har eksklusive egenskaper, vil brukeren kunne koble den til vår termostat. For å gjøre dette, må du kalibrere termostaten for å fungere med en bestemt sensor. Vi vil gi instruksjoner.
Når du kobler til en termostat eller en annen enhet, vises den samtidig overalt: både i webgrensesnittet og i PWA-applikasjonen. Å legge til en enhet skjer automatisk: du trenger bare å koble den til Wi-Fi-nettverket.
Systemet vårt trenger ikke en server, og hvis det feiler, blir det ikke til et gresskar. Selv om en av komponentene svikter, begynner ikke systemet å fungere i et nødscenario. Kontrollere, sensorer, enheter - hvert element er både en server og en klient, derfor helt autonom.
For de som er interessert, våre sosiale nettverk: , , , , .
Post: [e-postbeskyttet]
PS Vi oppfordrer deg ikke til å forlate serveren. Vi støtter også en MQTT-server og har vår egen sky. Vårt mål er å bringe stabiliteten og påliteligheten til systemet til et helt nytt nivå. Slik at Serveren ikke er et svakt punkt, men utfyller funksjonaliteten og gjør systemet mer praktisk.
Kilde: www.habr.com