För en tid sedan presenterade vi för er . Denna artikel var ursprungligen avsedd som en demonstration av dess firmware och styrsystem. Men för att förklara logiken bakom termostatens arbete och vad vi har implementerat, Àr det nödvÀndigt att skissera hela konceptet som helhet.
Om automation
I stort kan all automation delas in i tre kategorier:
Kategori 1 â separata âsmartaâ enheter. Du köper lampor, vattenkokare etc. frĂ„n olika tillverkare. Fördelar: varje enhet utökar möjligheterna och ökar komforten. Nackdelar: för varje ny tillverkare behövs en egen app. Protokollen för enheter frĂ„n olika tillverkare Ă€r ofta inte kompatibla med varandra.
Kategori 2 â installation av en enkorts-PC eller x86-kompatibel. Detta tar bort begrĂ€nsningarna för berĂ€kningskraft, och pĂ„ denna maskin installeras MajorDoMo eller nĂ„gon annan serverdistribution för att hantera det smarta hemmet. DĂ€rigenom kopplas enheter frĂ„n de flesta tillverkare samman i ett enhetligt informationsutrymme. D.v.s. en egen server för det smarta hemmet skapas. Fördelar: kompatibilitet under en gemensam central, vilket ger utökade möjligheter för styrning. Nackdelar: vid serverfel Ă„tergĂ„r hela systemet till fas 1, d.v.s. blir splittrat eller obrukbart.
Kategori 3 â den mest hardcore varianten. Vid renovering lĂ€ggs alla kommunikationer och alla system dubbelas. Fördelar: allt Ă€r perfekt och dĂ„ blir huset verkligen smart. Nackdelar: extremt hög kostnad jĂ€mfört med kategorierna 1 och 2, behovet av att planera allt i förvĂ€g och ta hĂ€nsyn till varje detalj.
De flesta anvÀndare vÀljer alternativ ett, för att sedan gradvis övergÄ till alternativ tvÄ. Och sÄ smÄningom nÄr de mest ihÀrdiga alternativ tre.
Men det finns ett alternativ som kan kallas ett distribuerat system: varje enskild enhet kommer att vara bÄde server och klient. I grunden Àr det ett försök att kombinera alternativ 1 och alternativ 2. Att ta alla deras fördelar och utesluta nackdelarna, fÄnga den gyllene medelvÀgen.
Det finns kanske de som sÀger att en sÄdan lösning redan Àr utvecklad. Men sÄdana lösningar Àr snÀva och riktar sig mot personer med programmeringskunskaper. VÄrt mÄl Àr att sÀnka intrÀdesbarriÀren för sÄdana distribuerade system, bÄde nÀr det gÀller slutprodukter och integrering av befintliga enheter i vÄrt system. NÀr det gÀller termostaten, tar anvÀndaren helt enkelt bort sin gamla termostat, installerar den smarta och kopplar de sensorer han redan har till den. Utan nÄgra ytterligare ÄtgÀrder.
LÄt oss övervÀga integrationen i vÄrt system med ett exempel.
LĂ„t oss anta att vi har 8 Sonoff-moduler i nĂ€tverket. Vissa anvĂ€ndare kommer att nöja sig med att styra via Sonoff-molnet (kategori 1). Andra kommer att anvĂ€nda tredje parts firmware och smidigt gĂ„ över till kategori 2. De flesta tredje parts firmware fungerar enligt samma princip: överföring av data till en MQTT-server. OpenHub, Majordomo eller vilken annan tjĂ€nst som helst tjĂ€nar ett enda syfte â att förena spridda enheter i ett enhetligt informationsutrymme, antingen pĂ„ Internet eller i det lokala nĂ€tverket. DĂ€rför Ă€r nĂ€rvaron av en server obligatorisk. HĂ€r uppstĂ„r huvudproblemet â nĂ€r servern gĂ„r ner slutar hela systemet att fungera autonomt. För att förhindra detta kompliceras systemen, och manuella styrmetoder lĂ€ggs till som duplicerar automatik vid servermisslyckande.
Vi har dock valt en annan vÀg dÀr varje enhet Àr sjÀlvförsörjande. PÄ sÄ sÀtt spelar servern ingen avgörande roll, utan utökar bara funktionaliteten.
LĂ„t oss Ă„tervĂ€nda till vĂ„rt tankeexperiment. LĂ„t oss ta samma 8 Sonoff-moduler och installera Lytko-firmware i dem. I alla Lytko-firmwares finns funktionen . SSDP â ett nĂ€tverksprotokoll baserat pĂ„ en uppsĂ€ttning Internetprotokoll som anvĂ€nds för att annonserar och upptĂ€cka nĂ€tverkstjĂ€nster. Svaret pĂ„ en förfrĂ„gan kan vara bĂ„de standard och utökat. Vi har lagt till att skapa en lista över enheter i nĂ€tverket, förutom standardfunktionerna. PĂ„ sĂ„ sĂ€tt hittar enheterna varandra sjĂ€lva, och var och en av dem kommer att ha en sĂ„dan lista. Exempel pĂ„ en SSDP-lista:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}Som det framgÄr av exemplet inkluderar listan enheter, IP-adresser i nÀtverket, typ av modul (i vÄrt fall en termostat baserad pÄ Sonoff). Denna lista uppdateras varannan minut (den hÀr tidsperioden Àr tillrÀcklig för att reagera pÄ dynamiska förÀndringar i antal enheter i nÀtverket). PÄ sÄ sÀtt spÄrar vi tillÀgg, Àndringar och bortkoppling av enheter utan nÄgot krav pÄ anvÀndarens ÄtgÀrd. Denna lista skickas till webblÀsaren eller mobilappen, och skriptet genererar automatiskt en sida med angivet antal moduler. Varje modul motsvarar en enhet/sensor/styrenhet. Visuellt ser listan ut sÄ hÀr:
Men vad hÀnder om andra radiosensorer Àr anslutna till esp8266/esp32 via cc2530 (ZigBee) eller nrf24 (MySensors)?
Om projekt
Det finns olika distribuerade system pÄ marknaden. VÄrt system möjliggör integration med de mest populÀra.
Nedan följer projekt som pÄ olika sÀtt försöker förÀndra situationen med inkompatibilitet mellan olika tillverkare. Det Àr till exempel , eller . som Àr kopplad till MQTT-servern, sÄ den passar inte som exempel.
En av de möjliga implementationerna av MySensors Ă€r en gateway baserad pĂ„ ESP8266. Ăvriga exempel Ă€r baserade pĂ„ ESP32. I dem kan vi implementera vĂ„r arbetsprincip för att upptĂ€cka och skapa en enhetslista.
LÄt oss göra ytterligare ett tankexperiment. Vi har ZESP32 eller SLS Gateway, eller MySensors. Hur kan vi sammanföra dem i ett gemensamt informationsutrymme? Till de standardfunktionerna för dessa gateways lÀgger vi till SSDP-protokollet. NÀr vi kontaktar denna kontroller via SSDP, lÀgger den till en lista över enheter som Àr anslutna till den i sitt standard-svar. Baserat pÄ denna information kommer webblÀsaren att generera en sida. I allmÀnhet kommer det att se ut sÄ hÀr:
WebbgrÀnssnitt
PWA-applikation
"ssdpList":
{
"id": 94967291, // unik identifierare för enheten
"ip": "192.168.x.x", // IP-adress i nÀtverket
"type": "thermostat" // enhetstyp
},
{
"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"
}
Exemplet visar att enheter lÀggs till oberoende av varandra. Tre termostater med egna IP-adresser och fem olika sensorer med unika ID Àr anslutna. Om sensorn Àr ansluten till Wi-Fi-nÀtverket kommer den att ha sin egen IP, om den Àr ansluten till en gateway kommer enhetens IP-adress att vara gatewayens IP-adress.
För kommunikation med enheterna anvÀnder vi WebSocket. Detta minimerar resursförbrukningen jÀmfört med GET-förfrÄgningar och gör att vi kan fÄ information dynamiskt vid anslutning eller förÀndring.
Data hÀmtas direkt frÄn den enhet som blocket tillhör, utan att gÄ via servern. SÄledes fortsÀtter systemet att fungera vid fel pÄ nÄgon av enheterna. I webgrÀnssnittet kommer endast den borttagna enheten inte att visas i listan. Men signalen om bortfallet kommer, om nödvÀndigt, att skickas i form av en avisering i anvÀndarens app.
Det första försöket att implementera ett sÄdant tillvÀgagÄngssÀtt var en PWA-app. Detta möjliggör lagring av datablock pÄ anvÀndarens enhet och begÀr endast nödvÀndiga data. Men pÄ grund av strukturens egenskaper Àr denna variant ofullstÀndig. Lösningen Àr en native-app för Android och iOS, vilket för nÀrvarande Àr under aktiv utveckling. Som standard kommer appen att fungera endast i det interna nÀtverket. Om det behövs kan allt övergÄ till extern kontroll. NÀr anvÀndaren lÀmnar det lokala nÀtverket vÀxlar appen automatiskt till molnet.
Extern kontrollâ en fullstĂ€ndig duplikat av sidan. NĂ€r sidan aktiveras kan anvĂ€ndaren logga in pĂ„ servern och styra enheterna via sitt personliga konto. SĂ„ledes utökar servern funktionaliteten och möjliggör styrning av enheterna utanför hemmet utan att vara bunden till port forwarding eller dedikerad IP.
PÄ sÄ sÀtt saknar den ovan beskrivna varianten serveranslutningens nackdelar och har flera fördelar i form av flexibilitet i anslutning av nya enheter.
Om termostaten
LÄt oss övervÀga styrsystemet med vÄrt termostat som exempel.
Följande funktioner finns:
- Justering av temperaturen för varje termostat (visas som en separat block);
- InstÀllning av termostatens arbetsschema (morgon, dag, kvÀll, natt);
- Val av Wi-Fi-nÀtverk och anslutning av enheten till det;
- Uppdatering av enheten "over the air";
- InstÀllning av MQTT;
- InstÀllning av nÀtverket som enheten Àr ansluten till.
Förutom att styra via webgrÀnssnittet, finns Àven klassisk kontroll med knapptryckningar pÄ skÀrmen. Ombord finns en Nextion NX3224T024 2,4-tums skÀrm. Vi valde den pÄ grund av enkelheten att arbeta med enheten. Men en egen monitor baserad pÄ STM32 Àr under utveckling. Dess funktionalitet Àr lika bra som Nextions, men den kommer att kosta mindre, vilket positivt pÄverkar slutpriset för enheten.
Precis som alla respektabla termostat-skÀrmar kan vÄr Nextion:
- stÀlla in önskad temperatur för anvÀndaren (knapparna till höger);
- slÄ pÄ och av arbetsschemat (knappen N);
- visa relÀets funktion (pilen till vÀnster);
- ha barnskydd (fysiska knapptryck blockeras sÄ lÀnge lÄset Àr aktiverat);
- visa WiFi-signals styrka.
Dessutom kan man med skÀrmen:
- vÀlj typ av sensor som Àr installerad hos anvÀndaren;
- hantera barnskyddsfunktionen;
- uppdatera mjukvaran.
Genom att klicka pÄ WiFi-bar fÄr anvÀndaren information om det anslutna nÀtverket. QR-koden anvÀnds för att para ihop enheten med HomeKit-mjukvaran.
Demo av arbetet med skÀrmen:
Vi har utvecklat med tre anslutna termostater.
Du kanske undrar: âVad Ă€r det speciella med er termostat?â Det finns för nĂ€rvarande mĂ„nga termostater pĂ„ marknaden med Wi-Fi-funktion, schemalagd drift och pekstyrning. Och entusiaster har skrivit moduler för att interagera med de flesta populĂ€ra smarta hemsystemen (Majordomo, HomeAssistant etc.).
VÄr termostat Àr kompatibel med sÄdana system och har alla ovan nÀmnda funktioner. Men det som gör den unik Àr att termostaten stÀndigt förbÀttras, tack vare systemets flexibilitet. Med varje uppdatering kommer funktionaliteten att utökas. Utöver den standardiserade styrmetoden (enligt schema) kommer vi att lÀgga till en adaptiv metod. Appen tillÄter att fÄ anvÀndarens geolokalisering. Tack vare detta kommer systemet dynamiskt att Àndra driftslÀgen beroende pÄ anvÀndarens plats. Och vÀdermodulen gör att det kan anpassa sig till vÀderförhÄllandena.
Och skalbarhet. Alla som vill kan enkelt byta ut sin vanliga termostat mot vÄr. Med minimala anstrÀngningar. Vi har valt ut 5 av de mest populÀra sensorerna pÄ marknaden och lagt till stöd för dem. Men Àven om sensorn har unika egenskaper, kan anvÀndaren koppla den till vÄr termostat. För detta behövs en kalibrering av termostaten för att fungera med den specifika sensorn. Vi tillhandahÄller instruktionerna.
NÀr du kopplar en termostat eller en annan enhet, visas den automatiskt överallt: bÄde i webbgrÀnssnittet och i PWA-appen. TillÀgget av enheten sker automatiskt: det rÀcker med att koppla den till Wi-Fi-nÀtverket.
VĂ„rt system behöver ingen server, och i hĂ€ndelse av att den gĂ„r sönder förvandlas det inte till en pumpa. Ăven vid ett fel pĂ„ nĂ„gon av komponenterna börjar systemet inte att arbeta i nödlĂ€ge. Kontroller, sensorer, enheter â varje element Ă€r bĂ„de en server och en klient, vilket innebĂ€r att det Ă€r helt autonomt.
För dem som Ă€r intresserade â vĂ„ra sociala medier: , , , , .
E-post: shop@lytko.com
P.S. Vi uppmanar inte till att avstÄ frÄn servern. Vi har ocksÄ stöd för MQTT-server och har vÄr egen molntjÀnst. VÄrt mÄl Àr att höja systemets stabilitet och tillförlitlighet till en ny kvalitativ nivÄ. För att servern inte ska vara en svag punkt, utan komplettera funktionaliteten och göra systemet mer anvÀndbart.
KĂ€lla: habr.com
