För en tid sedan presenterade vi dig . Den här artikeln var ursprungligen tänkt som en demonstration av dess firmware och kontrollsystem. Men för att förklara termostatens logik och vad vi implementerade är det nödvändigt att beskriva hela konceptet som helhet.
Om automatisering
Konventionellt kan all automation delas in i tre kategorier:
Kategori 1 — separata "smarta" enheter. Du köper glödlampor, tekannor mm från olika tillverkare. Fördelar: Varje enhet utökar kapaciteten och ökar komforten. Nackdelar: Varje ny tillverkare kräver sin egen applikation. Protokoll för enheter från olika tillverkare är ofta inte kompatibla med varandra.
Kategori 2 — installation av en PC med ett kort eller x86-kompatibel. Detta tar bort restriktioner för datorkraft, och MajorDoMo eller någon annan serverdistribution för att hantera ett smart hem är installerad på den här maskinen. Således är enheter från de flesta tillverkare anslutna i ett enda informationsutrymme. De där. din egen server för ett smart hem visas. Fördelar: kompatibilitet under ett enda center, vilket ger förbättrade hanteringsmöjligheter. Nackdelar: om servern misslyckas återgår hela systemet till steg 1, d.v.s. blir fragmenterad eller blir värdelös.
Kategori 3 - det mest hårda alternativet. I reparationsstadiet läggs all kommunikation och alla system dupliceras. Fördelar: allt blir perfekt och sedan blir huset riktigt smart. Nackdelar: extremt dyrt jämfört med kategori 1 och 2, behovet av att tänka igenom allt i förväg och ta hänsyn till varje liten detalj.
De flesta användare väljer alternativ ett och går sedan smidigt vidare till alternativ två. Och sedan når de mest ihärdiga alternativ 3.
Men det finns ett alternativ som kan kallas ett distribuerat system: varje enskild enhet kommer att vara både en server och en klient. I huvudsak är detta ett försök att ta och kombinera alternativ 1 och alternativ 2. Ta alla deras fördelar och eliminera nackdelarna, för att fånga den gyllene medelvägen.
Kanske kommer någon att säga att ett sådant alternativ redan har utvecklats. Men sådana beslut är snävt fokuserade; för personer som är insatta i programmering. Vårt mål är att sänka inträdesbarriären i sådana distribuerade system, både i form av slutenheter och i form av att integrera befintliga enheter i vårt system. När det gäller en termostat tar användaren helt enkelt bort sin gamla termostat, installerar en smart och ansluter sina befintliga sensorer till den. Utan några ytterligare steg.
Låt oss titta på integrationen i vårt system med hjälp av ett exempel.
Låt oss föreställa oss att vi har 8 Sonoff-moduler i vårt nätverk. För vissa användare kommer kontroll via Sonoff-molnet (kategori 1) att räcka. Vissa kommer att börja använda firmware från tredje part och kommer smidigt att flytta in i kategori 2. Huvuddelen av tredje parts firmware fungerar på samma princip: överföring av data till en MQTT-server. OpenHub, Majordomo eller något annat tjänar ett syfte - att förena olika enheter till ett enda informationsutrymme som finns antingen på Internet eller på ett lokalt nätverk. Därför är närvaron av en server obligatorisk. Det är här som huvudproblemet uppstår - om servern misslyckas slutar hela systemet att fungera autonomt. För att förhindra detta blir systemen mer komplexa, manuella kontrollmetoder läggs till som duplicerar automatisering vid serverfel.
Vi tog en annan väg, där varje enhet är självförsörjande. Servern spelar alltså ingen avgörande roll utan utökar bara funktionaliteten.
Låt oss återgå till tankeexperimentet. Låt oss ta samma 8 Sonoff-moduler igen och installera Lytko firmware i dem. Alla Lytko firmware har funktionen . SSDP är ett nätverksprotokoll baserat på Internetprotokollsviten för reklam och upptäckt av nätverkstjänster. Svaret på en förfrågan kan vara antingen standard eller utökat. Förutom standardfunktioner inkluderade vi i detta svar skapandet av en lista över enheter i nätverket. Således hittar enheterna själva varandra, och var och en av dem kommer att ha en sådan lista. Exempel 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 i exemplet innehåller listan enhets-ID, IP-adress på nätverket, enhetstyp (i vårt fall en Sonoff-baserad termostat). Denna lista uppdateras en gång varannan minut (denna period är tillräcklig för att svara på dynamiska förändringar i antalet enheter i nätverket). På så sätt spårar vi enheter som lagts till, ändrats och inaktiverats utan någon användaråtgärd. Denna lista skickas till webbläsaren eller mobilapplikationen och själva skriptet genererar en sida med ett givet antal block. Varje block motsvarar en enhet/sensor/kontroller. 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 låter dig integrera med de mest populära.
Nedan finns projekt som på ett eller annat sätt försöker förändra situationen med inkompatibilitet mellan olika tillverkare med varandra. Detta är t.ex. , eller . är kopplad till en MQTT-server, så den är inte lämplig för exemplet.
Ett alternativ för att implementera MySensors är en gateway baserad på ESP8266. Resten av exemplen finns på ESP32. Och i dem kan du implementera vår driftsprincip för att upptäcka och skapa en lista över enheter.
Låt oss göra ett annat tankeexperiment. Vi har en ZESP32 gateway eller SLS Gateway, eller MySensors. Hur kan de kombineras i ett enda informationsutrymme? Vi kommer att lägga till SSDP-protokollbiblioteket till standardfunktionerna för dessa gateways. När du får åtkomst till denna styrenhet via SSDP kommer den att lägga till en lista över enheter som är anslutna till den till standardsvaret. Baserat på denna information kommer webbläsaren att skapa en sida. I allmänhet kommer det att se ut så här:
webbgränssnitt
PWA-applikation
"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"
}
Exemplet visar att enheter läggs till oberoende av varandra. 3 termostater med egna IP-adresser och 5 olika sensorer med unika ID är anslutna. Om sensorn är ansluten till ett Wi-Fi-nätverk kommer den att ha sin egen IP; om den är ansluten till en gateway kommer enhetens IP-adress att vara gatewayens IP-adress.
Vi använder WebSocket för att kommunicera med enheter. Detta gör att du kan minimera resurskostnaderna jämfört med att få förfrågningar och få information dynamiskt när du ansluter eller ändrar.
Data tas direkt från den enhet som blocket tillhör och går förbi servern. Således, om någon av enheterna misslyckas, fortsätter systemet att fungera. Webbgränssnittet visar helt enkelt inte den saknade enheten från listan. Men en signal om förlusten, om nödvändigt, kommer i form av ett meddelande i användarens applikation.
Det första försöket att implementera detta tillvägagångssätt var en PWA-applikation. Detta gör att du kan lagra en blockbas på användarens enhet och endast begära nödvändiga data. Men på grund av strukturens särdrag är detta alternativ ofullständigt. Och det finns bara en väg ut - en inbyggd applikation för Android och IOS, som för närvarande är under aktiv utveckling. Som standard kommer programmet bara att fungera på det interna nätverket. Vid behov kan du överföra allt till extern styrning. Så när användaren lämnar det lokala nätverket växlar applikationen automatiskt till molnet.
Extern kontroll - fullständig dubblering av sidan. När sidan är aktiverad kan användaren logga in på servern och hantera enheter via sitt personliga konto. Servern utökar alltså sin funktionalitet, så att du kan hantera enheter utanför hemmet och inte vara bunden till portvidarebefordran eller en dedikerad IP.
Ovanstående alternativ har alltså inte nackdelarna med servermetoden, och har även ett antal fördelar i form av flexibilitet vid anslutning av nya enheter.
Om termostaten
Låt oss titta på styrsystemet med vår termostat som exempel.
Försedd:
- Temperaturkontroll för varje termostat (visas som ett separat block);
- Ställa in termostatens driftschema (morgon, eftermiddag, kväll, natt);
- Välja ett Wi-Fi-nätverk och ansluta en enhet till det;
- Uppdatering av enheten "over the air";
- Ställa in MQTT;
- Konfigurera nätverket som enheten är ansluten till.
Förutom styrning via webbgränssnittet tillhandahöll vi det klassiska – genom att klicka på displayen. Det finns en Nextion NX3224T024 2.4-tumsskärm ombord. Valet föll på honom på grund av hur lätt det var att arbeta med enheten. Men vi utvecklar vår egen bildskärm baserad på STM32. Dess funktionalitet är inte sämre än Nextions, men det kommer att kosta mindre, vilket kommer att ha en positiv inverkan på det slutliga priset på enheten.
Som vilken termostatskärm som helst med självrespekt kan vår Nextion:
- ställ in den temperatur som användaren kräver (med knapparna till höger);
- slå på och av det schemalagda driftläget (knapp H);
- display relädrift (pil till vänster);
- har barnskydd (fysiska klick blockeras tills låset tas bort);
- visar WiFi-signalstyrkan.
Dessutom kan du med hjälp av monitorn:
- välj den typ av sensor som installeras av användaren;
- hantera barnlåsfunktionen;
- uppdatera firmware.
Genom att klicka på WiFi-fältet får användaren information om det anslutna nätverket. QR-koden används för att para ihop enheten i HomeKit firmware.
Demo av att arbeta med skärmen:
Vi har utvecklats med tre anslutna termostater.
Du kanske frågar "Vad är speciellt med din termostat?" Nu på marknaden finns det många termostater med Wi-Fi-funktion, schemalagd drift och pekkontroll. 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 allt ovanstående. Men det utmärkande är att termostaten ständigt förbättras, tack vare systemets flexibilitet. Med varje uppdatering utökas funktionaliteten. Till standardmetoden för systemhantering (enligt ett schema) kommer vi att lägga till en adaptiv. Applikationen låter dig få användarens geolokalisering. Tack vare detta kommer systemet dynamiskt att ändra driftlägen beroende på dess placering. Och vädermodulen låter dig anpassa dig till väderförhållandena.
Och utbyggbarhet. Vem som helst kan byta ut sin befintliga konventionella termostat mot vår. Med minimal ansträngning. 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 exklusiva egenskaper kommer användaren att kunna koppla den till vår termostat. För att göra detta måste du kalibrera termostaten för att fungera med en specifik sensor. Vi kommer att ge instruktioner.
När du ansluter en termostat eller någon annan enhet visas den samtidigt överallt: både i webbgränssnittet och i PWA-applikationen. Att lägga till en enhet sker automatiskt: du behöver bara ansluta den till Wi-Fi-nätverket.
Vårt system behöver ingen server, och om det misslyckas förvandlas det inte till en pumpa. Även om en av komponenterna misslyckas, börjar systemet inte fungera i ett nödscenario. Styrenheter, sensorer, enheter - varje element är både en server och en klient, därför helt autonomt.
För de intresserade, våra sociala nätverk: , , , , .
mail: [e-postskyddad]
PS Vi uppmuntrar dig inte att överge servern. Vi stöder även en MQTT-server och har ett eget moln. Vårt mål är att ta systemets stabilitet och tillförlitlighet till en helt ny nivå. Så att servern inte är en svag punkt, utan kompletterar funktionaliteten och gör systemet mer bekvämt.
Källa: will.com