Idag, tack vare den snabba utvecklingen av mikroelektronik, kommunikationskanaler, internetteknik och artificiell intelligens, blir ämnet smarta hem mer och mer relevant. Människans bostäder har genomgått betydande förändringar sedan stenåldern och i eran av industriella revolutionen 4.0 och Internet of Things har det blivit bekvämt, funktionellt och säkert. Lösningar kommer till marknaden som gör en lägenhet eller ett hus på landet till komplexa informationssystem som styrs från var som helst i världen med en smartphone. Dessutom kräver interaktion mellan människa och maskin inte längre kunskap om programmeringsspråk - tack vare taligenkänning och syntesalgoritmer talar en person till ett smart hem på sitt modersmål.
Vissa smarta hemsystem som för närvarande finns på marknaden är en logisk utveckling av molnvideoövervakningssystem, vars utvecklare insåg behovet av en heltäckande lösning inte bara för övervakning utan också för hantering av fjärrobjekt.
Vi presenterar för din uppmärksamhet en serie med tre artiklar, som kommer att berätta om alla huvudkomponenterna i ett molnsystem för smarta hem, personligen utvecklat av författaren och satt i drift. Den första artikeln ägnas åt terminalklientutrustningen installerad i ett smart hem, den andra till arkitekturen för molnlagrings- och databehandlingssystemet, och slutligen den tredje till klientapplikationen för att hantera systemet på mobila och stationära enheter.
Smart hemutrustning
Låt oss först prata om hur man gör ett smart hem ur en vanlig lägenhet, dacha eller stuga. För att göra detta är det som regel nödvändigt att placera följande utrustning i hemmet:
- sensorer som mäter olika miljöparametrar;
- ställdon som verkar på externa föremål;
- en styrenhet som utför beräkningar i enlighet med sensormätningar och inbyggd logik och ger kommandon till ställdon.
Följande bild visar ett diagram över ett smart hem, på vilket det finns sensorer för vattenläckage (1) i badrummet, temperatur (2) och belysning (3) i sovrummet, ett smart uttag (4) i köket och en videoövervakningskamera (5) i korridoren.
För närvarande används trådlösa sensorer som använder protokollen RF433, Z-Wave, ZigBee, Bluetooth och WiFi i stor utsträckning. Deras främsta fördelar är enkel installation och användning, samt låg kostnad och tillförlitlighet, eftersom Tillverkare strävar efter att ta ut sina enheter till massmarknaden och göra dem tillgängliga för den genomsnittliga användaren.
Sensorer och ställdon är som regel anslutna via ett trådlöst gränssnitt till en smart hemkontroller (6) - en specialiserad mikrodator som kombinerar alla dessa enheter till ett enda nätverk och styr dem.
Vissa lösningar kan dock kombinera en sensor, ett ställdon och en styrenhet samtidigt. Till exempel kan en smart plugg programmeras att slå på eller av enligt ett schema, och en molnvideoövervakningskamera kan spela in video baserat på en rörelsedetektorsignal. I de enklaste fallen kan du klara dig utan en separat styrenhet, men för att skapa ett flexibelt system med många scenarier är det nödvändigt.
För att ansluta den smarta hemkontrollern till det globala nätverket kan en vanlig internetrouter (7) användas, som sedan länge har blivit en vanlig hushållsapparat i alla hem. Här finns ytterligare ett argument för en smart hemkontroller - om anslutningen till Internet bryts kommer det smarta hemmet fortsätta att fungera som vanligt tack vare logikblocket som är lagrat inuti kontrollenheten, och inte i molntjänsten.
Smart hemkontroller
Styrenheten för molnets smarta hemsystem som diskuteras i den här artikeln är utvecklad baserat på en mikrodator med ett kort , som släpptes i mars 2018 och har tillräckliga resurser och prestanda för smarta hemuppgifter. Den inkluderar en fyrkärnig Cortex-A53-processor baserad på 64-bitars ARMv8-A-arkitektur, klockad till 1.4 GHz, samt 1 GB RAM, Wi-Fi 802.11ac, Bluetooth 4.2 och en gigabit Ethernet-adapter som fungerar via USB 2.0 .
Att montera styrenheten är mycket enkel - mikrodatorn (1) installeras i ett plastfodral (2), sedan installeras ett 8 GB minneskort i microSD-format med programvara (3) och en USB Z-Wave nätverkskontroller (4) i motsvarande luckor. Den smarta hemkontrollen är ansluten till strömförsörjningen via en 5V, 2.1A strömadapter (5) och en USB - mikro-USB-kabel (6). Varje styrenhet har ett unikt identifikationsnummer, som skrivs i konfigurationsfilen när det startas första gången och är nödvändigt för att interagera med molntjänster för smarta hem.
Programvaran för smarta hemkontroller har utvecklats av författaren till den här artikeln baserat på operativsystemet Linux Raspbian Stretch. Den består av följande huvuddelsystem:
- serverprocess för interaktion med smart hemutrustning och molnet;
- grafiskt användargränssnitt för att ställa in styrenhetens konfigurations- och driftsparametrar;
- databas för lagring av styrenhetskonfiguration.
databas smart hemkontroller implementeras baserat på en inbyggd DBMS och är en fil på ett SD-kort med systemprogramvara. Det fungerar som ett minne för styrenhetens konfiguration - information om den anslutna utrustningen och dess nuvarande tillstånd, ett block med logiska produktionsregler, såväl som information som kräver indexering (till exempel filnamn på ett lokalt videoarkiv). När regulatorn startas om sparas denna information, vilket gör det möjligt att återställa regulatorn vid strömavbrott.
grafiskt gränssnitt smart hemkontroller utvecklad i PHP 7 med hjälp av en mikroram . Webbservern ansvarar för att köra applikationen. , används ofta i inbäddade enheter på grund av dess goda prestanda och låga resurskrav.
(klicka på bilden för att öppna den i högre upplösning)
Huvudfunktionen för det grafiska gränssnittet är att ansluta smart hemutrustning (IP-övervakningskameror och sensorer) till styrenheten. Webbapplikationen läser konfigurationen och det aktuella tillståndet för styrenheten och enheter som är anslutna till den från SQLite-databasen. För att ändra kontrollerkonfigurationen skickar den kontrollkommandon i JSON-format genom RESTful API-gränssnittet i serverprocessen.
Serverprocess
Serverprocess - en nyckelkomponent som utför allt huvudarbete med att automatisera informationsprocesser som ligger till grund för ett smart hem: ta emot och bearbeta sensoriska data, utfärda kontrollåtgärder beroende på den inbäddade logiken. Syftet med serverprocessen är att interagera med smart hemutrustning, exekvera logiska produktionsregler, ta emot och bearbeta kommandon från det grafiska gränssnittet och molnet. Serverprocessen i den övervägda smarta hemkontrollern är implementerad som en flertrådad applikation utvecklad i C++ och lanserad som en separat tjänst SYSTEMD operativ system Linux Raspbian.
Huvudblocken i serverprocessen är:
- Message Manager;
- IP-kameraserver;
- Z-Wave enhetsserver;
- Server för produktion logiska regler;
- Databas för konfiguration av styrenheten och block av logiska regler;
- RESTful API-server för interaktion med det grafiska gränssnittet;
- MQTT-klient för interaktion med molnet.
Serverprocessblock implementeras som separata trådar, mellan vilka information överförs i form av meddelanden i JSON-format (eller datastrukturer som representerar detta format i processminnet).
Huvudkomponenten i serverprocessen är meddelandehanterare, som dirigerar JSON-meddelanden till alla serverprocessblock. Typerna av JSON-meddelandeinformationsfält och de värden de kan acceptera listas i tabellen:
enhetstyp
protokoll
meddelandeTyp
enhetsstatus
kommando
rum
onvif
sensorData
on
streaming (på/av)
givare
zwave
kommando
sänkt
inspelning (på/av)
effektor
mqtt
businessLogicRule
streaming (på/av)
evice (lägg till/ta bort)
företagslogik
konfigurationsdata
inspelning (på/av)
bluetooth
enhetsstatus
fel
wiFi
rf
Till exempel, ett meddelande från en kamerarörelsedetektor ser ut så här:
{
"vendor": "*****",
"version": "3.0.0",
"timestampMs": "1566293475475",
"clientType": "gateway",
"deviceId": "1616453d-30cd-44b7-9bf0-************",
"deviceType": "camera",
"protocol": "onvif",
"messageType": "sensorData",
"sensorType": "camera",
"label": "motionDetector",
"sensorData": "on"
}
Produktionslogik
För att ta emot eller skicka ett meddelande från avsändaren, prenumererar serverprocessblocket på meddelanden av en viss typ. Prenumeration är en produktionslogisk regel av denna typ "Om då...", presenterad i JSON-format, och en länk till meddelandehanteraren inuti serverprocessblocket. Till exempel, för att tillåta IP-kameraservern att ta emot kommandon från GUI och molnet, måste du lägga till följande regel:
{
"if": {
"and": [{
"equal": {
"deviceId": "1616453d-30cd-44b7-9bf0-************"
}
},
{
"equal": {
"messageType": "command"
}
}
]
},
"then": {
"result": "true"
}
}
Om de villkor som anges i föregående (vänster sida) reglerna är sanna, då är det uppfyllt följd (höger sida) regler, och hanteraren får tillgång till brödtexten i JSON-meddelandet. Föregången stöder logiska operatorer som jämför JSON-nyckel-värdepar:
- är lika med "lika";
- inte lika med "not_equal";
- mindre "mindre";
- mer "större";
- mindre än eller lika med "mindre_eller_lika";
- större än eller lika med "större_eller_lika".
Jämförelseresultaten kan relateras till varandra med booleska algebraoperatorer:
- Och och"
- Eller eller";
- Inte inte".
Genom att skriva operatorer och operander i polsk notation kan du alltså skapa ganska komplexa förhållanden med ett stort antal parametrar.
Exakt samma mekanism, baserad på JSON-meddelanden och produktionsregler i JSON-format, används i produktionslogikserverblocket för att representera kunskap och utföra logisk slutledning med hjälp av sensorisk data från smarta hemsensorer.
Med hjälp av en mobilapplikation skapar användaren scenarier enligt vilka det smarta hemmet ska fungera. Till exempel: "Om sensorn för att öppna ytterdörren utlöses, tänd då ljuset i korridoren". Applikationen läser identifierarna för sensorer (öppningssensor) och ställdon (smart socket eller smart lampa) från databasen och genererar en logisk regel i JSON-format, som skickas till kontrollenheten för smarta hem. Denna mekanism kommer att diskuteras mer i detalj i den tredje artikeln i vår serie, där vi kommer att prata om klientapplikationen för att hantera ett smart hem.
Produktionslogikmekanismen som diskuterats ovan implementeras med hjälp av biblioteket — SAX-parser för JSON-format i C++. Sekventiell läsning och analys av en rad produktionsregler gör att du enkelt kan implementera datajämförelsefunktionen i antecedenten:
void CRuleEngine::Process(PProperties pFact)
{
m_pActions->clear();
rapidjson::Reader reader;
for(TStringMap::value_type& rRule : m_Rules)
{
std::string sRuleId = rRule.first;
std::string sRuleBody = rRule.second;
CRuleHandler ruleHandler(pFact);
rapidjson::StringStream ruleStream(sRuleBody.c_str());
rapidjson::ParseResult parseResult = reader.Parse(ruleStream, ruleHandler);
if(!parseResult)
{
m_Logger.LogMessage(
NLogger2::ePriorityLevelError,
std::string("JSON parse error"),
"CRuleEngine::Process()",
std::string("RuleId: ") + sRuleId);
}
PProperties pAction = ruleHandler.GetAction();
if(pAction)
{
pAction->Set("ruleId", sRuleId);
m_pActions->push_back(pAction);
}
}
}
Här pFakta — en struktur som innehåller nyckel-värdepar från ett JSON-meddelande, m_Regler — Strängar av produktionsregler. Jämförelsen av det inkommande meddelandet och produktionsregeln utförs i funktionen reader.Parse(ruleStream, ruleHandler)var regelHandler är ett objekt som innehåller logiken för booleska och jämförelseoperatorer. sRuleId — en unik regelidentifierare, tack vare vilken det är möjligt att lagra och redigera regler i databasen för smarta hemkontroller. m_pActions — en array med resultaten av logisk slutledning: JSON-meddelanden som innehåller konsekvenser från regelbasen och skickas vidare till meddelandehanteraren så att prenumeranttrådar kan bearbeta dem.
RapidJSON-prestanda är jämförbar med funktionen strlen(), och de lägsta systemresurskraven tillåter användning av detta bibliotek i inbäddade enheter. Användningen av meddelanden och logiska regler i JSON-format gör att du kan implementera ett flexibelt system för informationsutbyte mellan alla komponenter i kontrollenheten för smarta hem.
Z-Wave sensorer och ställdon
Den största fördelen med ett smart hem är att det självständigt kan mäta olika parametrar i den yttre miljön och utföra användbara funktioner beroende på situationen. För att göra detta är sensorer och ställdon anslutna till kontrollenheten för smarta hem. I den aktuella versionen är dessa trådlösa enheter som använder protokollet på en särskilt tilldelad frekvens 869 MHz För Ryssland. För att fungera kombineras de till ett mesh-nätverk, som innehåller signalrepeater för att öka täckningsområdet. Enheterna har också ett speciellt energisparläge - de tillbringar större delen av tiden i viloläge och skickar information endast när deras tillstånd ändras, vilket avsevärt kan förlänga livslängden på det inbyggda batteriet.
Du kan nu hitta ett ganska stort antal olika Z-Wave-enheter på marknaden. Låt oss ta en titt på några exempel:
- Zipato PAN16 smarta uttag kan mäta följande parametrar: elförbrukning (kWh), effekt (W), spänning (V) och ström (A) i elnätet. Den har även en inbyggd strömbrytare med vilken du kan styra den anslutna elektriska apparaten;
- Neo Coolcam-läckagesensorn upptäcker förekomst av utspilld vätska genom att stänga kontakterna på fjärrsonden;
- Zipato PH-PSG01 röksensorn utlöses när rökpartiklar kommer in i gasanalysatorkammaren;
- Neo Coolcam-rörelsesensorn analyserar den infraröda strålningen från människokroppen. Dessutom finns det en ljussensor (Lx);
- Multisensor Philio PST02-A mäter temperatur (°C), ljus (%), dörröppning, närvaro av en person i rummet;
- Z-Wave USB Stick ZME E UZB1 nätverkskontroller, till vilken sensorer är anslutna.
Det är mycket viktigt att enheterna och styrenheten arbetar med samma frekvens, annars kommer de helt enkelt inte att se varandra vid anslutningsögonblicket. Upp till 232 enheter kan anslutas till en Z-Wave-nätverkskontroller, vilket är tillräckligt för en lägenhet eller ett hus på landet. För att utöka nätverkets täckningsområde inomhus kan ett smart uttag användas som signalrepeater.
I den smarta hemkontrollerserverprocessen som diskuterades i föregående stycke är Z-Wave-servern ansvarig för att interagera med Z-Wave-enheter. Den använder ett bibliotek för att ta emot information från sensorer i C++, som ger ett gränssnitt för att interagera med Z-Wave nätverks USB-styrenhet och fungerar med en mängd olika sensorer och ställdon. Värdet på miljöparametern som mäts av sensorn registreras av Z-Wave-servern i form av ett JSON-meddelande:
{
"vendor": "*****",
"version": "3.0.0",
"timestampMs": "1566479791290",
"clientType": "gateway",
"deviceId": "20873eb0-dd5e-4213-a175-************",
"deviceType": "sensor",
"protocol": "zwave",
"messageType": "sensorData",
"homeId": "0xefa0cfa7",
"nodeId": "20",
"sensorType": "METER",
"label": "Voltage",
"sensorData": "229.3",
"units": "V"
}
Det vidarebefordras sedan till serverprocessens meddelandehanterare så att prenumeranttrådar kan ta emot det. Huvudabonnenten är produktionslogikservern, som matchar meddelandefältsvärdena i logikreglernas föregångare. Slutledningsresultaten som innehåller kontrollkommandon skickas tillbaka till meddelandehanteraren och går därifrån till Z-Wave-servern, som avkodar dem och skickar dem till Z-Wave-nätverkets USB-styrenhet. Sedan går de in i ställdonet, vilket ändrar miljöobjektens tillstånd, och det smarta hemmet utför därmed ett användbart arbete.
(klicka på bilden för att öppna den i högre upplösning)
Anslutning av Z-Wave-enheter görs i det grafiska gränssnittet på kontrollenheten för smarta hem. För att göra detta, gå till sidan med en lista över enheter och klicka på knappen "Lägg till". Add-kommandot via RESTful API-gränssnittet går in i serverprocessen och skickas sedan av meddelandehanteraren till Z-Wave-servern, som sätter Z-Wave-nätverkets USB-styrenhet i ett speciellt läge för att lägga till enheter. Därefter måste du på Z-Wave-enheten göra en serie snabba tryckningar (3 tryckningar inom 1,5 sekunder) på serviceknappen. USB-styrenheten ansluter enheten till nätverket och skickar information om den till Z-Wave-servern. Det skapar i sin tur en ny post i SQLite-databasen med parametrarna för den nya enheten. Efter ett angivet tidsintervall återgår det grafiska gränssnittet till Z-Wave enhets listsida, läser information från databasen och visar den nya enheten i listan. Varje enhet får sin egen unika identifierare, som används i produktionsinferensregler och när man arbetar i molnet. Funktionen av denna algoritm visas i UML-diagrammet:
(klicka på bilden för att öppna den i högre upplösning)
Ansluta IP-kameror
Molnets smarta hemsystem som diskuteras i den här artikeln är en uppgradering av molnvideoövervakningssystemet, också utvecklat av författaren, som har funnits på marknaden i flera år och har många installationer i Ryssland.
För molnvideoövervakningssystem är ett av de akuta problemen det begränsade urvalet av utrustning med vilken integration kan utföras. Mjukvaran som ansvarar för att ansluta till molnet är installerad inuti videokameran, vilket omedelbart ställer stora krav på dess hårdvara – processorn och mängden ledigt minne. Detta förklarar främst det högre priset på moln-CCTV-kameror jämfört med vanliga IP-kameror. Dessutom krävs ett långt skede av förhandlingar med företag som tillverkar CCTV-kameror för att få tillgång till kamerafilsystemet och alla nödvändiga utvecklingsverktyg.
Å andra sidan har alla moderna IP-kameror standardprotokoll för interaktion med annan utrustning (särskilt videobandspelare). Användningen av en separat styrenhet som ansluter via ett standardprotokoll och sänder videoströmmar från IP-kameror till molnet ger alltså betydande konkurrensfördelar för molnvideoövervakningssystem. Dessutom, om klienten redan har installerat ett videoövervakningssystem baserat på enkla IP-kameror, blir det möjligt att utöka det och förvandla det till ett fullfjädrat molnsmart hem.
Det mest populära protokollet för IP-videoövervakningssystem, som nu stöds av alla IP-kameratillverkare utan undantag, är , vars specifikationer finns i ett beskrivningsspråk för webbtjänster . Använda verktyg från verktygslådan Det är möjligt att generera källkod för tjänster som fungerar med IP-kameror:
$ wsdl2h -o onvif.h
https://www.onvif.org/ver10/device/wsdl/devicemgmt.wsdl
https://www.onvif.org/ver10/events/wsdl/event.wsdl
https://www.onvif.org/ver10/media/wsdl/media.wsdl
https://www.onvif.org/ver20/ptz/wsdl/ptz.wsdl
$ soapcpp2 -Cwvbj -c++11 -d cpp_files/onvif -i onvif.h
Som ett resultat får vi en uppsättning rubriker "*.h" och källfiler "*.cpp" i C++, som kan placeras direkt i en applikation eller ett separat bibliotek och kompileras med GCC-kompilatorn. På grund av de många funktionerna är koden stor och kräver ytterligare optimering. Raspberry Pi 3 modell B+ mikrodator har tillräcklig prestanda för att exekvera denna kod, men om det finns ett behov av att porta koden till en annan plattform är det nödvändigt att välja rätt processorarkitektur och systemresurser.
IP-kameror som stöder ONVIF-standarden, när de arbetar på ett lokalt nätverk, är anslutna till en speciell multicast-grupp med adressen 239.255.255.250. Det finns ett protokoll , som låter dig automatisera sökningen efter enheter i det lokala nätverket.
Det grafiska gränssnittet på den smarta hemkontrollern implementerar en sökfunktion för IP-kameror i PHP, vilket är mycket bekvämt när man interagerar med webbtjänster via XML-meddelanden. När du väljer menyalternativ Enheter > IP-kameror > Skanning Algoritmen för att söka efter IP-kameror startas och visar resultatet i form av en tabell:
(klicka på bilden för att öppna den i högre upplösning)
När du lägger till en kamera till kontrollern kan du ange inställningarna enligt vilka den ska interagera med molnet. Även i detta skede tilldelas den automatiskt en unik enhetsidentifierare, med vilken den senare lätt kan identifieras i molnet.
Därefter genereras ett meddelande i JSON-format som innehåller alla parametrar för den tillagda kameran och skickas till serverprocessen för kontrollenheten för smarta hem via kommandot RESTful API, där kameraparametrarna avkodas och sparas i den interna SQLite-databasen, och är används också för att starta följande bearbetningstrådar:
- upprättande av en RTSP-anslutning för att ta emot video- och ljudströmmar;
- kodning av ljud från formaten G.711 mu-Law, G.711 A-Law, G.723, etc. till AAC-format;
- omkoda videoströmmar i H.264-format och ljud i AAC-format till en FLV-behållare och överföra det till molnet via RTMP-protokollet;
- upprättande av en anslutning med IP-kamerans rörelsedetektor via ONVIF-protokollet och regelbundet polling av det;
- periodiskt generera en miniatyrbild för förhandsgranskning och skicka den till molnet via MQTT-protokollet;
- lokal inspelning av video- och ljudströmmar i form av separata filer i MP4-format på ett SD- eller Flash-kort på den smarta hemkontrollen.
För att upprätta en förbindelse med kameror, koda om, bearbeta och spela in videoströmmar i serverprocessen, används funktioner från biblioteket 4.1.0.
I prestandatestningsexperimentet kopplades 3 kameror till styrenheten:
- HiWatch DS-I114W (upplösning - 720p, komprimeringsformat - H.264, bithastighet - 1 Mb/s, ljud G.711 mu-Law);
- Microdigital MDC-M6290FTD-1 (upplösning - 1080p, komprimeringsformat - H.264, bithastighet - 1 Mb/s, inget ljud);
- Dahua DH-IPC-HDW4231EMP-AS-0360B (upplösning - 1080p, komprimeringsformat - H.264, bithastighet - 1.5 Mb/s, AAC-ljud).
Alla tre strömmarna matades ut samtidigt till molnet, ljudomkodning utfördes från endast en kamera och lokal arkivinspelning inaktiverades. CPU-belastningen var cirka 5 %, RAM-användningen var 32 MB (per process), 56 MB (totalt inklusive OS).
Således kan cirka 20 - 30 kameror kopplas till den smarta hemkontrollern (beroende på upplösning och bithastighet), vilket räcker till ett videoövervakningssystem för en stuga i tre våningar eller ett litet lager. För uppgifter som kräver högre prestanda kan du använda en nettop med en flerkärnig Intel-processor och Linux Debian Sarge OS. Regulatorn genomgår för närvarande provdrift och data om dess prestanda kommer att uppdateras.
Interaktion med molnet
Ett molnbaserat smart hem lagrar användardata (video- och sensormätningar) i molnet. Arkitekturen för molnlagring kommer att diskuteras mer i detalj i nästa artikel i vår serie. Låt oss nu prata om gränssnittet för att överföra informationsmeddelanden från den smarta hemkontrollen till molnet.
Tillstånden för anslutna enheter och sensormätningar överförs via protokollet , som ofta används i Internet of Things-projekt på grund av dess enkelhet och energieffektivitet. MQTT använder en klient-server-modell, där klienter prenumererar på specifika ämnen inom mäklaren och publicerar sina meddelanden. Mäklaren skickar meddelanden till alla abonnenter enligt regler som bestäms av QoS-nivån (Quality of Service):
- QoS 0 - maximalt en gång (ingen leveransgaranti);
- QoS 1 - minst en gång (med leveransbekräftelse);
- QoS 2 - exakt en gång (med ytterligare leveransbekräftelse).
I vårt fall använder vi . Ämnesnamnet är den unika identifieraren för kontrollenheten för smarta hem. MQTT-klienten inuti serverprocessen prenumererar på detta ämne och översätter JSON-meddelanden som kommer från meddelandehanteraren till det. Omvänt vidarebefordras meddelanden från MQTT-mäklaren av den till meddelandehanteraren, som sedan multiplexerar dem till sina prenumeranter i serverprocessen:
För att överföra meddelanden om statusen för kontrollenheten för smarta hem används mekanismen för sparade meddelanden MQTT-protokoll. Detta gör att du korrekt kan övervaka tidpunkten för återanslutningar under strömavbrott.
MQTT-klienten utvecklades baserat på biblioteksimplementeringen på C++ språk.
H.264 + AAC mediaströmmar skickas till molnet via RTMP-protokollet, där ett kluster av mediaservrar ansvarar för att bearbeta och lagra dem. För att optimalt fördela belastningen i klustret och välja den minst belastade medieservern, gör den smarta hemkontrollern en preliminär förfrågan till molnets belastningsbalanserare och skickar först efter det mediaströmmen.
Slutsats
Artikeln undersökte en specifik implementering av en smart hemkontroller baserad på mikrodatorn Raspberry Pi 3 B+, som kan ta emot, bearbeta information och styra utrustning via Z-Wave-protokollet, interagera med IP-kameror via ONVIF-protokollet och även utbyta data och kommandon med molntjänsten via MQTT- och RTMP-protokoll. En produktionslogikmotor har utvecklats baserat på en jämförelse av logiska regler och fakta presenterade i JSON-format.
Kontrollenheten för smarta hem genomgår för närvarande provdrift på flera platser i Moskva och Moskva-regionen.
Nästa version av kontrollern planerar att ansluta andra typer av enheter (RF, Bluetooth, WiFi, trådbunden). För användarnas bekvämlighet kommer proceduren för att ansluta sensorer och IP-kameror att överföras till mobilapplikationen. Det finns också idéer för att optimera serverns processkod och portera programvaran till operativsystemet . Detta gör att du kan spara på en separat kontroller och överföra funktionen hos ett smart hem till en vanlig hushållsrouter.
Källa: will.com