'n Ruk gelede het ons jou voorgestel . Hierdie artikel was oorspronklik bedoel as 'n demonstrasie van sy firmware en beheerstelsel. Maar om die logika van die termostaat te verduidelik en wat ons geïmplementeer het, is dit nodig om die hele konsep as 'n geheel uiteen te sit.
Oor outomatisering
Konvensioneel kan alle outomatisering in drie kategorieë verdeel word:
Kategorie 1 - aparte "slim" toestelle. Jy koop gloeilampe, teepotte, ens. van verskillende vervaardigers. Voordele: Elke toestel brei vermoëns uit en verhoog gemak. Nadele: Elke nuwe vervaardiger benodig sy eie toepassing. Protokolle van toestelle van verskillende vervaardigers is dikwels nie met mekaar versoenbaar nie.
Kategorie 2 - installering van 'n enkelbord-rekenaar of x86-versoenbaar. Dit verwyder beperkings op rekenaarkrag, en MajorDoMo of enige ander bedienerverspreiding vir die bestuur van 'n slimhuis is op hierdie masjien geïnstalleer. Toestelle van die meeste vervaardigers word dus in 'n enkele inligtingspasie gekoppel. Dié. jou eie bediener vir 'n slim huis verskyn. Voordele: verenigbaarheid onder 'n enkele sentrum, wat verbeterde bestuursvermoëns bied. Nadele: as die bediener misluk, keer die hele stelsel terug na stadium 1, d.w.s. word gefragmenteerd of word nutteloos.
Kategorie 3 - die mees hardcore opsie. By die herstelstadium word alle kommunikasie gelê en alle stelsels gedupliseer. Voordele: alles word tot perfeksie gebring en dan word die huis werklik slim. Nadele: uiters duur in vergelyking met kategorieë 1 en 2, die behoefte om alles vooraf deur te dink en elke klein detail in ag te neem.
Die meeste gebruikers kies opsie een en gaan dan glad aan na opsie twee. En dan bereik die mees volhardendes opsie 3.
Maar daar is 'n opsie wat 'n verspreide stelsel genoem kan word: elke individuele toestel sal beide 'n bediener en 'n kliënt wees. In wese is dit 'n poging om opsie 1 en opsie 2 te neem en te kombineer. Neem al hul voordele en skakel die nadele uit, om die goue middeweg te vang.
Miskien sal iemand sê dat so 'n opsie reeds ontwikkel is. Maar sulke besluite is eng gefokus; vir mense wat vaardig is in programmering. Ons doelwit is om die versperring vir toegang tot sulke verspreide stelsels te verlaag, beide in die vorm van eindtoestelle en in die vorm van die integrasie van bestaande toestelle in ons stelsel. In die geval van 'n termostaat verwyder die gebruiker eenvoudig sy ou termostaat, installeer 'n slim een en koppel sy bestaande sensors daaraan. Sonder enige bykomende stappe.
Kom ons kyk na integrasie in ons stelsel deur 'n voorbeeld te gebruik.
Kom ons stel ons voor dat ons 8 Sonoff-modules op ons netwerk het. Vir sommige gebruikers sal beheer via die Sonoff-wolk (kategorie 1) voldoende wees. Sommige sal derdeparty-firmware begin gebruik en sal glad na kategorie 2 beweeg. Die grootste deel van derdeparty-firmware werk op dieselfde beginsel: die oordrag van data na 'n MQTT-bediener. OpenHub, Majordomo of enige ander dien een doel - om uiteenlopende toestelle te verenig in 'n enkele inligtingspasie wat óf op die internet óf op 'n plaaslike netwerk geleë is. Daarom is die teenwoordigheid van 'n bediener verpligtend. Dit is waar die hoofprobleem ontstaan - as die bediener misluk, hou die hele stelsel op om outonoom te werk. Om dit te voorkom, word stelsels meer kompleks, handbeheermetodes word bygevoeg wat outomatisering dupliseer in die geval van 'n bedienerfout.
Ons het 'n ander pad geneem, waar elke toestel selfonderhoudend is. Die Bediener speel dus nie 'n deurslaggewende rol nie, maar brei net die funksionaliteit uit.
Kom ons keer terug na die gedagte-eksperiment. Kom ons neem weer dieselfde 8 Sonoff-modules en installeer Lytko-firmware daarin. Alle Lytko-firmware het die funksie . SSDP is 'n netwerkprotokol gebaseer op die internetprotokolsuite vir advertensies en ontdekking van netwerkdienste. Die antwoord op 'n versoek kan óf standaard óf uitgebrei wees. Benewens standaardfunksies, het ons in hierdie antwoord die skepping van 'n lys toestelle op die netwerk ingesluit. So, die toestelle self vind mekaar, en elkeen van hulle sal so 'n lys hê. Voorbeeld SSDP-blad:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Soos u uit die voorbeeld kan sien, bevat die lys toestel-ID's, IP-adres op die netwerk, tipe eenheid (in ons geval 'n Sonoff-gebaseerde termostaat). Hierdie lys word een keer elke twee minute opgedateer (hierdie tydperk is voldoende om te reageer op dinamiese veranderinge in die aantal toestelle op die netwerk). Op hierdie manier volg ons toestelle wat bygevoeg, verander en gedeaktiveer is sonder enige gebruikeraksie. Hierdie lys word na die blaaier of mobiele toepassing gestuur, en die skrif genereer self 'n bladsy met 'n gegewe aantal blokke. Elke blok stem ooreen met een toestel/sensor/beheerder. Visueel lyk die lys soos volg:
Maar wat as ander radiosensors via cc8266 (ZigBee) of nrf32 (MySensors) aan die esp2530/esp24 gekoppel is?
Oor projekte
Daar is verskeie verspreide stelsels op die mark. Ons stelsel laat jou toe om met die gewildste te integreer.
Hieronder is projekte wat op een of ander manier probeer om die situasie te verander met die onverenigbaarheid van verskillende vervaardigers met mekaar. Dit is bv. , of . is gekoppel aan 'n MQTT-bediener, so dit is nie geskik vir die voorbeeld nie.
Een opsie vir die implementering van MySensors is 'n poort gebaseer op die ESP8266. Die res van die voorbeelde is op ESP32. En daarin kan u ons bedryfsbeginsel implementeer om 'n lys toestelle op te spoor en te skep.
Kom ons doen nog 'n gedagte-eksperiment. Ons het 'n ZESP32-poort of SLS-poort, of MySensors. Hoe kan hulle in 'n enkele inligtingspasie gekombineer word? Ons sal die SSDP-protokolbiblioteek by die standaardfunksies van hierdie poorte voeg. Wanneer toegang tot hierdie beheerder via SSDP verkry word, sal dit 'n lys toestelle wat daaraan gekoppel is, by die standaardantwoord voeg. Op grond van hierdie inligting sal die blaaier 'n bladsy genereer. Oor die algemeen sal dit so lyk:
Web koppelvlak
PWA aansoek
"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"
}
Die voorbeeld toon dat toestelle onafhanklik van mekaar bygevoeg word. 3 termostate met hul eie IP-adresse en 5 verskillende sensors met unieke ID's is gekoppel. As die sensor aan 'n Wi-Fi-netwerk gekoppel is, sal dit sy eie IP hê; as dit aan 'n poort gekoppel is, sal die toestel se IP-adres die poort se IP-adres wees.
Ons gebruik WebSocket om met toestelle te kommunikeer. Dit laat jou toe om hulpbronkoste te verminder in vergelyking met versoeke te kry en inligting dinamies te bekom wanneer jy koppel of verander.
Die data word direk geneem vanaf die toestel waaraan die blok behoort, wat die bediener omseil. Dus, as enige van die toestelle misluk, gaan die stelsel voort om te werk. Die webkoppelvlak wys net nie die ontbrekende toestel op die lys nie. Maar 'n sein oor die verlies, indien nodig, sal kom in die vorm van 'n kennisgewing in die gebruiker se toepassing.
Die eerste poging om hierdie benadering te implementeer was 'n PWA-toepassing. Dit laat jou toe om 'n blokbasis op die gebruiker se toestel te stoor en slegs die nodige data aan te vra. Maar as gevolg van die eienaardighede van die struktuur, is hierdie opsie onvolledig. En daar is net een uitweg - 'n inheemse toepassing vir Android en IOS, wat tans aktief ontwikkel word. By verstek sal die toepassing slegs op die interne netwerk werk. Indien nodig, kan u alles na eksterne beheer oordra. Dus, wanneer die gebruiker die plaaslike netwerk verlaat, skakel die toepassing outomaties oor na die wolk.
Eksterne beheer - volledige duplisering van die bladsy. Wanneer die bladsy geaktiveer is, kan die gebruiker by die bediener aanmeld en toestelle deur hul persoonlike rekening bestuur. Die bediener brei dus sy funksionaliteit uit, waardeur u toestelle kan bestuur terwyl u buite die huis is, en nie gekoppel is aan poortaanstuur of 'n toegewyde IP nie.
Die bogenoemde opsie het dus nie die nadele van die bedienerbenadering nie, en het ook 'n aantal voordele in die vorm van buigsaamheid om nuwe toestelle te koppel.
Oor die termostaat
Kom ons kyk na die beheerstelsel deur ons termostaat as voorbeeld te gebruik.
Voorsien:
- Temperatuurbeheer vir elke termostaat (vertoon as 'n aparte blok);
- Stel die termostaat werkingskedule in (oggend, middag, aand, nag);
- Kies 'n Wi-Fi-netwerk en koppel 'n toestel daaraan;
- Die opdatering van die toestel "oor die lug";
- Die opstel van MQTT;
- Stel die netwerk op waaraan die toestel gekoppel is.
Benewens beheer via die webkoppelvlak, het ons die klassieke een verskaf - deur op die skerm te klik. Daar is 'n Nextion NX3224T024 2.4-duim-monitor aan boord. Die keuse het op hom geval weens die gemak om met die toestel te werk. Maar ons ontwikkel ons eie monitor gebaseer op STM32. Die funksionaliteit daarvan is nie erger as dié van Nextion nie, maar dit sal minder kos, wat 'n positiewe impak op die finale prys van die toestel sal hê.
Soos enige selfrespekterende termostaatskerm, kan ons Nextion:
- stel die temperatuur wat deur die gebruiker vereis word in (gebruik die knoppies aan die regterkant);
- skakel die geskeduleerde werkingsmodus aan en af (knoppie H);
- vertoon afloswerking (pyltjie aan die linkerkant);
- het kinderbeskerming (fisiese klik word geblokkeer totdat die slot verwyder word);
- wys WiFi seinsterkte.
Daarbenewens kan u met behulp van die monitor:
- kies die tipe sensor wat deur die gebruiker geïnstalleer is;
- bestuur die kinderslotfunksie;
- dateer die firmware op.
Deur op die WiFi-balk te klik, sal die gebruiker inligting oor die gekoppelde netwerk uitvind. Die QR-kode word gebruik om die toestel in die HomeKit-firmware te koppel.
Demo van werk met die skerm:
Ons het ontwikkel met drie gekoppelde termostate.
Jy mag dalk vra: "Wat is spesiaal aan jou termostaat?" Nou op die mark is daar baie termostate met Wi-Fi-funksie, geskeduleerde werking en aanraakbeheer. En entoesiaste het modules geskryf om met die gewildste slimhuisstelsels te kommunikeer (Majordomo, HomeAssistant, ens.).
Ons termostaat is versoenbaar met sulke stelsels en het al die bogenoemde. Maar die kenmerkende kenmerk is dat die termostaat voortdurend verbeter word, danksy die buigsaamheid van die stelsel. Met elke opdatering sal die funksionaliteit uitbrei. By die standaardmetode van stelselbestuur (volgens 'n skedule), sal ons 'n aanpasbare een byvoeg. Die toepassing laat jou toe om die gebruiker se geoligging te verkry. Danksy dit sal die stelsel bedryfsmodusse dinamies verander na gelang van sy ligging. En die weermodule sal jou toelaat om by weersomstandighede aan te pas.
En uitbreidbaarheid. Enigeen kan hul bestaande konvensionele termostaat vervang met ons s'n. Met minimale moeite. Ons het 5 van die gewildste sensors op die mark gekies en ondersteuning daarvoor bygevoeg. Maar selfs al het die sensor eksklusiewe eienskappe, sal die gebruiker dit aan ons termostaat kan koppel. Om dit te doen, sal jy die termostaat moet kalibreer om met 'n spesifieke sensor te werk. Ons sal instruksies verskaf.
Wanneer 'n termostaat of enige ander toestel gekoppel word, verskyn dit gelyktydig oral: beide in die webkoppelvlak en in die PWA-toepassing. Die byvoeging van 'n toestel vind outomaties plaas: jy hoef dit net aan die Wi-Fi-netwerk te koppel.
Ons stelsel het nie 'n bediener nodig nie, en as dit misluk, verander dit nie in 'n pampoen nie. Selfs as een van die komponente misluk, begin die stelsel nie in 'n noodscenario werk nie. Beheerders, sensors, toestelle - elke element is beide 'n bediener en 'n kliënt, dus heeltemal outonoom.
Vir diegene wat belangstel, ons sosiale netwerke: , , , , .
Poskantoor: [e-pos beskerm]
PS Ons moedig jou nie aan om die bediener te laat vaar nie. Ons ondersteun ook 'n MQTT-bediener en het ons eie wolk. Ons doel is om die stabiliteit en betroubaarheid van die stelsel na 'n heel nuwe vlak te bring. Sodat die bediener nie 'n swak punt is nie, maar die funksionaliteit aanvul en die stelsel geriefliker maak.
Bron: will.com