Lytko kombinerer

For some time now, we have introduced you to a smart thermostat. The current article was initially intended as a demonstration of its firmware and control system. However, to explain the logic of the thermostat's operation and what we have implemented, it is necessary to outline the entire concept as a whole.

About automation

Conditionally, all automation can be divided into three categories:
Category 1 — individual “smart” devices. You purchase bulbs, kettles, etc., from different manufacturers. Pros: each device expands capabilities and increases comfort. Cons: each new manufacturer requires its own application. The protocols of devices from different manufacturers are often not compatible with each other.

Category 2 — installing a single-board PC or x86 compatible one. This removes limitations on computing power, and a MajorDoMo or any other server distribution for smart home management is installed on this machine. Thus, devices from most manufacturers connect within a unified information space. That is, a Smart Home Server is created. Pros: compatibility under a single center, which provides expanded control capabilities. Cons: in case of server failure, the entire system reverts to stage 1, i.e., it becomes fragmented or turns useless.

Category 3 — the most hardcore option. During the renovation stage, all communications are laid out and all systems are duplicated. Pros: everything is perfected, and then the home truly becomes smart. Cons: extremely high cost compared to categories 1 and 2, the necessity to plan everything ahead and take every little detail into account.

Most users choose option one and then gradually transition to option two. Eventually, the most persistent reach option three.

But there is an option that can be called a distributed system: each individual device will be both a server and a client. Essentially, this is an attempt to combine option 1 and option 2, to take all their advantages and eliminate the drawbacks, to find a golden mean.

Kanskje noen vil si at en slik løsning allerede er utviklet. Men slike løsninger er spesialiserte; for folk med programmeringskunnskap. Vårt mål er å senke inngangsbarrieren for slike distribuerte systemer, både når det gjelder sluttbrukerenheter og når det gjelder integrasjonen av eksisterende enheter i systemet vårt. Når det gjelder termostaten, fjerner brukeren ganske enkelt sin gamle termostat, installerer den smarte, og kobler de eksisterende sensorene til den. Uten ytterligere tiltak.

La oss se på integrasjon i systemet vårt med et eksempel.

La oss anta at vi har 8 Sonoff-moduler i nettverket. Noen brukere vil være fornøyd med styring via Sonoff-skyen (kategori 1). Andre vil bruke tredjeparts firmware og gradvis gå over til kategori 2. Hoveddelen av tredjepartsfirmware fungerer etter samme prinsipp: dataoverføring til en MQTT-server. OpenHub, Majordomo eller enhver annen tjener ett mål – å samle forskjellige enheter i et enhetlig informasjonsrom, enten på Internett eller i lokalt nettverk. Følgelig er tilstedeværelsen av en server obligatorisk. Her oppstår det største problemet – ved serverfeil slutter hele systemet å fungere autonomt. For å forhindre dette, kompliseres systemene, og manuelle kontrollmetoder som dupliserer automatikken legges til i tilfelle serverfeil.

Vi valgte imidlertid en annen tilnærming, der hver enhet er selvforsynt. Dermed spiller serveren ikke en avgjørende rolle, men utvider bare funksjonaliteten.

La oss gå tilbake til tankeksperimentet. La oss igjen ta de samme 8 Sonoff-modulene og installere Lytko-firmware i dem. Alle Lytko-firmwarene har implementert funksjonen SSDP. SSDP er en nettverksprotokoll basert på et sett med internettprotokoller, som brukes til å kunngjøre og oppdage nettverkstjenester. Svaret på forespørselen kan være både standard og utvidet. Vi har inkludert i dette svaret, i tillegg til standardfunksjoner, opprettelsen av en liste over enheter i nettverket. Dermed finner enhetene hverandre selv, og hver av dem vil ha en slik 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 av eksemplet, inkluderer listen id-ene til enhetene, ip-adressen i nettverket, blokktypen (i vårt tilfelle – en termostat basert på Sonoff). Denne listen oppdateres hver andre minutt (denne tidsrammen er tilstrekkelig for å reagere på dynamiske endringer i antallet enheter i nettverket). Dermed kan vi spore tillegg, endringer og frakoblinger av enheter uten noen handling fra brukerens side. Denne listen sendes til nettleseren eller mobilappen, og skriptet lager selv siden med det angitte antallet blokkene. Hver blokk tilsvarer én enhet/sensor/aktuator. Visuelt ser listen slik ut:

Men hva hvis 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 tillater integrasjon med de mest populære.

Nedenfor er prosjekter som, på en eller annen måte, prøver å endre situasjonen med inkompatibilitet mellom ulike produsenter. Dette inkluderer for eksempel SLS Gateway, MySensors eller ZESP32. ZigBee2MQTT er knyttet til MQTT-serveren, så det passer ikke som eksempel.

En av implementeringsalternativene for MySensors er en gateway basert på ESP8266. De andre eksemplene er basert på ESP32. I dem kan vi integrere vår arbeidsmetode for oppdagelse og opprettelse av enhetslisten.

Vi vil utføre et tankeeksperiment til. Vi har en gateway ZESP32 eller SLS Gateway, eller MySensors. Hvordan kan vi kombinere dem i et enkelt informasjonssystem? Til de standardfunksjonene til disse gatewayene legger vi til SSDP-protokollbiblioteket. Når vi henvender oss til denne kontrolleren via SSDP, vil den i sitt standardrespons legge til listen over enheter som er koblet til den. Basert på denne informasjonen vil nettleseren lage en side. I generell form vil dette se slik ut:

Nettgrensesnitt

PWA-applikasjon

"ssdpList": 
{
   "id": 94967291, // unik enhetsidentifikator
   "ip": "192.168.x.x", // ip-adresse i nettverket
   "type": "thermostat" // type enhet
},
{
   "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"
}

Fra eksempelet kan vi se at enhetene legges til uavhengig av hverandre. Tre termostater med egne IP-adresser og fem forskjellige sensorer med unike ID-er er koblet til. Hvis sensoren er tilkoblet et Wi-Fi-nettverk, vil den ha sin egen IP, og hvis den er tilkoblet en gateway, vil enhetens IP-adresse være IP-adressen til gatewayen.

Vi bruker WebSocket for kommunikasjon med enhetene. Dette gjør at vi kan minimere ressursbruken sammenlignet med GET-forespørslene og motta informasjon dynamisk ved tilkobling eller endring.

Dataene hentes direkte fra den enheten som blokken tilhører, uten å gå om serveren. Dermed fortsetter systemet å fungere selv om noen av enhetene feiler. På webgrensesnittet vil bare den tapte enheten ikke bli vist i listen. Men en varsling om tapet vil komme til brukeren i appen om nødvendig.

Den første forsøket på å implementere en slik tilnærming var en PWA-app. Dette gjør at man kan lagre blokkdata på brukerens enhet og bare be om nødvendige data. Men på grunn av strukturens særheter er denne varianten utilstrekkelig. Løsningen er native apper for Android og iOS, som nå er under aktiv utvikling. Som standard vil appen bare fungere i det interne nettverket. Om nødvendig kan alt overføres til ekstern kontroll. Dermed, når brukeren forlater det lokale nettverket, vil appen automatisk bytte til skyen.

Ekstern kontroll er en fullstendig duplisering av siden. Når siden aktiveres, kan brukeren logge inn på serveren og styre enhetene gjennom sin brukerkonto. På denne måten utvider serveren funksjonaliteten, slik at man kan kontrollere enhetene fra utsiden av huset, uten å være avhengig av portforwarding eller dedikert IP.

Dermed er den ovenfor beskrevne varianten fri for servertilnærmingens ulemper og har en rekke fordeler i form av fleksibilitet ved tilkobling av nye enheter.

Om termostaten

La oss se på kontrolleringssystemet ved hjelp av vårt termostat-eksempel.

Forutsatt:

1. Regulering av temperaturen for hver termostat (vist som en egen blokk);
2. Innstilling av timeplan for termostatens drift (morgen, dag, kveld, natt);
3. Valg av Wi-Fi-nettverk og tilkobling av enheten til det;
4. Oppdatering av enheten "over luft";
5. Innstilling av MQTT;
6. Innstilling av nettverket som enheten er koblet til.

I tillegg til styring via webgrensesnittet har vi også lagt til den klassiske metoden – berøringer på skjermen. Den har en Nextion NX3224T024 2,4 tommers skjerm om bord. Valget falt på den på grunn av enkelheten i å bruke enheten. Men vi utvikler også en egen skjerm basert på STM32. Funksjonaliteten vil ikke være noe mindre enn Nextion, men den vil koste mindre, noe som vil ha en positiv innvirkning på den endelige prisen på enheten.

Som enhver respektabel termostat-skjerm, kan vår Nextion:

• stille inn ønsket temperatur for brukeren (med knappene til høyre);
• skru av og på driftsmodusen etter timeplan (knapp H);
• vise aktiviteten til reléet (pil til venstre);
• ha barnesikring (fysiske trykk er blokkert inntil låsen er fjernet);
• vise nivået på WiFi-signalet.

I tillegg kan skjermen:

• velge typen sensor som er installert hos brukeren;
• kontrollere barnesikringsfunksjonen;
• oppdatere programvaren.

Ved å klikke på WiFi-baren får brukeren informasjon om det tilkoblede nettverket. QR-koden brukes for å pare enheten i HomeKit-firmware.

Demo av skjermen i bruk:

Vi har utviklet en demostrationsside med tre tilkoblede termostater.

Du spør: “Hva er spesielt med din termostat?” Det finnes mange termostater på markedet med Wi-Fi-funksjon, tidsplanfunksjon og berøringsstyring. Og entusiaster har skrevet moduler for interaksjon med de fleste populære smarthus-systemer (Majordomo, HomeAssistant, osv.).

Vår termostat er kompatibel med slike systemer og har alle de nevnte funksjonene. Men den unike egenskapen er at termostaten kontinuerlig forbedres, takket være systemets fleksibilitet. Med hver oppdatering vil funksjonaliteten bli utvidet. I tillegg til den standard måten å styre systemet på (etter timeplan), vil vi legge til en adaptiv metode. Appen gjør det mulig å hente brukerens geolokasjon. Takket være dette vil systemet dynamisk endre driftsmoduser avhengig av brukerens plassering. Og værmodulen vil tilpasse seg værforholdene.

Og utvidbarheit. Alle som ønskjer kan bytte ut den vanlege termostaten sin med vår. Med minimal innsats. Vi har valgt 5 av de mest populære sensorane som er tilgjengelege på markedet, og lagt til støtte for dei. Men sjølv om sensorane har eksklusive spesifikasjonar, kan brukaren koble dei til vår termostat. For dette vil det vere nødvendig å kalibrere termostaten for å arbeide med den spesifikke sensoren. Vi vil gi instruksjonar.

Når du koplar til termostaten eller ei anna enhet, viser den seg automatisk overalt: både i nettgrensesnittet og i PWA-appen. Legging av enheten skjer automatisk: det er berre å koble den til Wi-Fi-nettverket.

Systemet vårt treng ikkje ein server, og i tilfelle av eit feilbrytande scenario blir det ikkje til ein gresskar. Sjølv om ein av komponentane sviktar, går ikkje systemet over til ein nødmodus. Kontrollar, sensorar, enheter — kvar enkelt del er både server og klient, så det er heilt autonomt.

For dei interesserte — våre sosiale medier: Telegram, Instagram, Telegram Nyheter, VK, Facebook.

E-post: shop@lytko.com

P. S. Vi oppfordrar ikkje til å gi opp serveren. Vi har også støtte for MQTT-server og har vårt eige sky. Målet vårt er å heve stabiliteten og pålitelegheita til systemet til eit kvalitativt nytt nivå. Slik at serveren ikkje er det svake punktet, men supplerer funksjonaliteten og gjer systemet meir brukervennleg.

Kilde: habr.com