I dag, takket være den hurtige udvikling af mikroelektronik, kommunikationskanaler, internetteknologier og kunstig intelligens, bliver emnet smarte hjem mere og mere relevant. Det menneskelige hjem har gennemgået betydelige ændringer siden stenalderen, og i æraen med den industrielle revolution 4.0 og Internet of Things er det blevet komfortabelt, funktionelt og sikkert. Der kommer løsninger på markedet, som gør en lejlighed eller et landsted til komplekse informationssystemer, der styres fra hvor som helst i verden ved hjælp af en smartphone. Desuden kræves der ikke længere kendskab til programmeringssprog for menneske-maskine-interaktion - takket være talegenkendelse og syntesealgoritmer taler en person med et smart hjem på sit modersmål.
Nogle smarte hjemmesystemer på markedet i øjeblikket er en logisk udvikling af cloud-videoovervågningssystemer, hvis udviklere har indset behovet for en omfattende løsning, ikke kun til overvågning, men også til styring af fjerntliggende objekter.
Din opmærksomhed inviteres til en serie på tre artikler, som vil fortælle om alle hovedkomponenterne i cloud-smart home-systemet, personligt udviklet af forfatteren og sat i drift. Den første artikel er afsat til terminalklientudstyret, der er installeret inde i det smarte hjem, den anden er helliget arkitekturen af skylagrings- og databehandlingssystemet, og endelig er den tredje artikel afsat til klientapplikationen til styring af systemet på mobile og stationære enheder.
Smart hjem udstyr
Lad os først tale om, hvordan man laver et smart hjem ud af en almindelig lejlighed, sommerhus eller sommerhus. For at gøre dette er det som regel påkrævet at placere følgende udstyr i boligen:
- sensorer, der måler forskellige parametre i det eksterne miljø;
- aktuatorer, der virker på eksterne genstande;
- en controller, der udfører beregninger i overensstemmelse med målinger af sensorer og den underliggende logik, og giver kommandoer til aktuatorerne.
Følgende figur viser et diagram over et smart hjem, som indeholder vandlækagesensorer (1) i badeværelset, temperatur- (2) og lys- (3) sensorer i soveværelset, en smart stikkontakt (4) i køkkenet og en videoovervågning kamera (5) i gangen.
I øjeblikket er trådløse sensorer, der fungerer på RF433, Z-Wave, ZigBee, Bluetooth og WiFi-protokollerne, meget udbredt. Deres vigtigste fordele er nem installation og brug samt lave omkostninger og pålidelighed. producenter stræber efter at bringe deres enheder til massemarkedet og gøre dem tilgængelige for den gennemsnitlige bruger.
Sensorer og aktuatorer er som regel forbundet via et trådløst interface til smart home-controlleren (6) - en specialiseret mikrocomputer, der kombinerer alle disse enheder i et enkelt netværk og styrer dem.
Nogle løsninger kan dog kombinere en sensor, en aktuator og en controller på samme tid. For eksempel kan et smart stik programmeres til at tænde eller slukke i henhold til en tidsplan, og et cloud-videoovervågningskamera kan optage video på et bevægelsesdetektorsignal. I de enkleste tilfælde kan du undvære en separat controller, men for at skabe et fleksibelt system med mange scenarier er det nødvendigt.
For at forbinde smart home-controlleren til det globale netværk kan der bruges en almindelig internetrouter (7), som for længst er blevet et velkendt husholdningsapparat i ethvert hjem. Der er et andet argument til fordel for smart home controlleren - hvis forbindelsen til internettet mistes, så vil smart home fortsætte med at fungere normalt takket være den logiske blok, der er gemt inde i controlleren, og ikke i cloud-tjenesten.
smart home controller
Controlleren til cloud-smart-home-systemet, der diskuteres i denne artikel, er udviklet på basis af en enkeltkorts mikrocomputer , som blev udgivet i marts 2018 og har nok ressourcer og ydeevne til smarte hjemmeopgaver. Den inkluderer en quad-core Cortex-A53-processor på en 64-bit ARMv8-A-arkitektur, klokket til 1.4 GHz, samt 1 GB RAM, Wi-Fi 802.11ac, Bluetooth 4.2 og en gigabit Ethernet-adapter, der fungerer via USB 2.0 bus.
Samlingen af controlleren er meget enkel - mikrocomputeren (1) er installeret i en plastikkasse (2), derefter installeres et 8 GB microSD-hukommelseskort med software (3) og en USB Z-Wave netværkscontroller (4). de passende slots. Smart Home-controlleren er tilsluttet lysnettet via en 5V, 2.1A strømadapter (5) og et USB-mikro-USB-kabel (6). Hver controller har et unikt identifikationsnummer, som skrives i konfigurationsfilen ved første start og er påkrævet for at interagere med cloud smart home-tjenester.
Smart Home Controller-softwaren er udviklet af forfatteren af denne artikel baseret på operativsystemet Linux Raspbian Stretch. Den består af følgende hovedundersystemer:
- en serverproces til interaktion med smart home-udstyr og skyen;
- grafisk brugergrænseflade til indstilling af controllerens konfiguration og driftsparametre;
- database til lagring af controller-konfiguration.
database smart home controller er implementeret på basis af et indlejret DBMS og er en fil på SD-kortet med systemsoftware. Det fungerer som en controller-konfigurationslagring - information om det tilsluttede udstyr og dets aktuelle tilstand, en blok af logiske produktionsregler samt information, der kræver indeksering (f.eks. lokale videoarkiv-filnavne). Når controlleren genstartes, gemmes denne information, hvilket gør det muligt at gendanne controllerens funktionalitet i tilfælde af strømsvigt.
Grafisk interface smart home controller er udviklet i PHP 7 ved hjælp af en mikroramme . Webserveren er ansvarlig for at køre applikationen. , som ofte bruges i indlejrede enheder på grund af dens gode ydeevne og lave ressourcekrav.
(klik på billedet for at åbne i større opløsning)
GUI'ens hovedfunktion er at forbinde smart home-udstyr (IP-kameraer og sensorer) til controlleren. Webapplikationen læser konfigurationen og den aktuelle tilstand for controlleren og enheder, der er tilsluttet den, fra SQLite-databasen. For at ændre controllerkonfigurationen sender den kontrolkommandoer i JSON-format gennem serverprocessens RESTful API.
Server proces
Server proces - en nøglekomponent, der udfører alt hovedarbejdet med at automatisere informationsprocesser, der danner grundlaget for et smart hjem: modtagelse og behandling af sensoriske data, udstedelse af kontrolhandlinger afhængigt af den underliggende logik. Formålet med serverprocessen er at interagere med smart home-udstyr, eksekvere produktionslogikregler, modtage og behandle kommandoer fra den grafiske grænseflade og skyen. Serverprocessen i den betragtede smart home controller er implementeret som en multi-threaded applikation udviklet i C++ og lanceret som en separat tjeneste systemd operativ system Linux Raspbian.
De vigtigste blokke i serverprocessen er:
- Message Manager;
- IP kamera server;
- Z-Wave enhed server;
- Server af produktion logiske regler;
- Database over konfiguration af controlleren og blok af logiske regler;
- RESTful API-server til interaktion med den grafiske grænseflade;
- MQTT-klient til interaktion med skyen.
Serverprocesblokke implementeres som separate strømme, hvorimod information overføres i form af meddelelser i JSON-format (eller datastrukturer, der repræsenterer dette format i proceshukommelsen).
Hovedkomponenten i serverprocessen er besked manager, som dirigerer JSON-meddelelser til alle blokke i serverprocessen. Typerne af informationsfelter i en JSON-meddelelse og de værdier, de kan tage, er angivet i tabellen:
enhedstype
protokol
beskedtype
enhedstilstand
kommando
værelse
ONVIF
sensordata
on
streaming (til/fra)
sensor
zwave
kommando
off
optagelse (Til/Fra)
effektor
mqtt
businessLogicRule
streaming (til/fra)
enhed (Tilføj/fjern)
forretningslogik
konfigurationsdata
optagelse (Til/Fra)
Bluetooth
enhedstilstand
fejl
wifi
rf
For eksempel ser en besked fra en kamerabevægelsesdetektor sådan ud:
{
"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
For at modtage eller sende en besked fra afsenderen abonnerer serverprocesblokken på beskeder af en bestemt type. Et abonnement er en produktionslogisk regel af typen "Hvis så...", repræsenteret i JSON-format, og et link til meddelelsesbehandleren inde i serverprocesblokken. For at IP-kameraserveren for eksempel kan modtage kommandoer fra GUI og skyen, skal du tilføje følgende regel:
{
"if": {
"and": [{
"equal": {
"deviceId": "1616453d-30cd-44b7-9bf0-************"
}
},
{
"equal": {
"messageType": "command"
}
}
]
},
"then": {
"result": "true"
}
}
Hvis betingelserne angivet i forudgående (venstre side) regler er altså sande konsekvens (højre side) regler, og behandleren får adgang til brødteksten i JSON-meddelelsen. Forgængeren understøtter logiske operatorer, der sammenligner JSON-nøgle-værdi-par:
- er lig med "lige";
- ikke lig med "ikke_lige";
- mindre end "mindre";
- mere "større";
- mindre end eller lig med "mindre_eller_lig";
- større end eller lig med "større_eller_lige".
Resultaterne af sammenligningen kan sammenkobles ved hjælp af boolske algebraoperatorer:
- Og "og";
- ELLER "eller";
- IKKE "ikke".
Ved at skrive operatorer og operander i polsk notation kan man således danne ret komplekse forhold med et stort antal parametre.
Den nøjagtig samme mekanisme, baseret på JSON-meddelelser og produktionsregler i JSON-format, bruges i produktionslogikserverblokken til at repræsentere viden og udføre inferens ved hjælp af sensordata fra smart home-sensorer.
Brugeren skaber ved hjælp af en mobilapplikation scenarier, som et smart hjem skal fungere efter. For eksempel: "Hvis sensoren til at åbne hoveddøren udløses, så tænd lyset i gangen". Applikationen læser identifikatorerne for sensorer (åbningssensor) og aktuatorer (smart socket eller smart lampe) fra databasen og genererer en logisk regel i JSON-format, som sendes til smart home-controlleren. Denne mekanisme vil blive diskuteret mere detaljeret i den tredje artikel i vores cyklus, hvor vi vil tale om klientapplikationen til styring af et smart hjem.
Mekanismen for produktionslogik diskuteret ovenfor implementeres ved hjælp af biblioteket — SAX-parser af JSON-format i C++ sprog. Sekventiel læsning og parsing af en række produktionsregler gør det nemt at implementere en datamatchningsfunktion inden for forhistorier:
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);
}
}
}
Her pFakta - en struktur, der indeholder nøgleværdi-par fra en JSON-meddelelse, m_Regler — række af produktionsregler. Matchningen af den indgående besked og produktionsreglen sker i funktionen reader.Parse(ruleStream, ruleHandler)Hvor regelHandler er et objekt, der indeholder logikken for booleske operatorer og sammenligningsoperatorer. sRuleId - en unik regelidentifikator, takket være hvilken det er muligt at gemme og redigere regler inde i smart home controller-databasen. m_pActions - et array med resultaterne af inferens: JSON-meddelelser, der indeholder konsekvenser fra regelbasen og sendt videre til meddelelsesadministratoren, så abonnent-tråde kan behandle dem.
Ydeevnen af RapidJSON er sammenlignelig med funktionen strlen(), og de minimale systemressourcekrav tillader, at dette bibliotek kan bruges i indlejrede enheder. Brugen af beskeder og logiske regler i JSON-format giver dig mulighed for at implementere et fleksibelt system til informationsudveksling mellem alle komponenter i smart home-controlleren.
Sensorer og aktuatorer Z-Wave
Den største fordel ved et smart hjem er, at det selvstændigt kan måle forskellige parametre i det ydre miljø og udføre nyttige funktioner afhængigt af situationen. For at gøre dette er sensorer og aktuatorer forbundet til smart home-controlleren. I den aktuelle version er disse trådløse enheder, der fungerer under protokollen på en dedikeret frekvens 869 MHz For Rusland. Til deres arbejde er de kombineret til et mesh-netværk, hvori der er signalforstærkere for at øge dækningsområdet. Enhederne har også en speciel strømbesparende tilstand - de bruger det meste af deres tid i dvaletilstand og sender kun information, når deres tilstand ændres, hvilket kan forlænge levetiden på det indbyggede batteri betydeligt.
Der er en del forskellige Z-Wave-enheder på markedet i dag. Som et eksempel kan du overveje et par stykker:
- Zipato PAN16 smart-stikket kan måle følgende parametre: elforbrug (kWh), effekt (W), spænding (V) og strøm (A) i lysnettet. Den har desuden en indbygget kontakt, som du kan styre det tilsluttede elektriske apparat med;
- Neo Coolcam-lækagesensoren registrerer tilstedeværelsen af spildt væske ved at lukke kontakterne på fjernsonden;
- Zipato PH-PSG01 røgdetektoren udløses, når røgpartikler kommer ind i gasanalysatorkammeret;
- Neo Coolcam bevægelsessensoren analyserer den infrarøde stråling fra den menneskelige krop. Derudover er der en lyssensor (Lx);
- Multisensor Philio PST02-A måler temperatur (°C), belysning (%), døråbning, menneskelig tilstedeværelse i rummet;
- Netværkscontroller Z-Wave USB Stick ZME E UZB1, hvortil sensorerne er tilsluttet.
Det er meget vigtigt, at enhederne og controlleren arbejder med samme frekvens, ellers vil de på en enkel måde ikke se hinanden på tidspunktet for tilslutningen. Op til 232 enheder kan tilsluttes en Z-Wave netværkscontroller, hvilket er ganske nok til en lejlighed eller et landsted. For at udvide netværksdækningen indendørs, kan en smart socket bruges som signalforstærker.
I smart home controller-serverprocessen, der blev diskuteret i det foregående afsnit, er Z-Wave-serveren ansvarlig for at interagere med Z-Wave-enheder. For at få information fra sensorer bruger den biblioteket i C++, som giver et interface til at interagere med en Z-Wave netværk USB-controller og fungerer med en række forskellige sensorer og aktuatorer. Værdien af miljøparameteren målt af sensoren skrives af Z-Wave-serveren som en JSON-meddelelse:
{
"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 sendes derefter til serverprocessens beskedhåndtering, så abonnenttråde kan modtage det. Den primære abonnent er produktionslogikserveren, som matcher meddelelsesfeltværdierne i forhistorien til logikreglerne. Inferensresultaterne, der indeholder kontrolkommandoer, sendes tilbage til beskedhåndteringen og derfra til Z-Wave-serveren, som afkoder dem og sender dem til Z-Wave-netværkets USB-controller. Så kommer de ind i den udøvende enhed, som ændrer tilstanden af objekter i det eksterne miljø, og det smarte hjem udfører således nyttigt arbejde.
(klik på billedet for at åbne i større opløsning)
Tilslutning af Z-Wave-enheder foretages i den grafiske grænseflade på smart home-controlleren. For at gøre dette skal du gå til siden med listen over enheder og klikke på knappen "Tilføj". Tilføj kommandoen via RESTful API-grænsefladen kommer ind i serverprocessen og sendes derefter af beskedadministratoren til Z-Wave-serveren, som sætter Z-Wave USB-netværkscontrolleren i en speciel tilstand til tilføjelse af enheder. Dernæst skal du på Z-Wave-enheden lave en række hurtige tryk (3 tryk inden for 1,5 sekunder) på serviceknappen. USB-controlleren forbinder enheden til netværket og sender information om den til Z-Wave-serveren. Det skaber til gengæld en ny post i SQLite-databasen med parametrene for den nye enhed. Den grafiske grænseflade vender efter det angivne tidsinterval tilbage til Z-Wave-enhedslistesiden, læser information fra databasen og viser en ny enhed på listen. Samtidig modtager hver enhed sin egen unikke identifikator, som bruges i reglerne for produktionsinferens og når man arbejder i skyen. Funktionen af denne algoritme er vist i UML-diagrammet:
(klik på billedet for at åbne i større opløsning)
Tilslutning af IP-kameraer
Cloud-smarthome-systemet, der diskuteres i denne artikel, er en opgradering af cloud-videoovervågningssystemet, også udviklet af forfatteren, som har været på markedet i flere år og har mange installationer i Rusland.
For cloud-videoovervågningssystemer er et af de akutte problemer det begrænsede udvalg af udstyr, som man kan integrere med. Softwaren, der er ansvarlig for at oprette forbindelse til skyen, er installeret inde i videokameraet, hvilket øjeblikkeligt stiller alvorlige krav til dets hardwarefyld - processoren og mængden af ledig hukommelse. Dette forklarer hovedsageligt den højere pris på skyovervågningskameraer sammenlignet med almindelige IP-kameraer. Derudover kræves der en langvarig forhandlingsfase med CCTV-kamerafirmaer for at få adgang til kameraets filsystem og alle de nødvendige udviklingsværktøjer.
På den anden side har alle moderne IP-kameraer standardprotokoller til interaktion med andet udstyr (især videooptagere). Brugen af en separat controller, der forbinder via en standardprotokol og udsender videostreams fra IP-kameraer til skyen, giver således betydelige konkurrencefordele for cloud-videoovervågningssystemer. Desuden, hvis klienten allerede har installeret et videoovervågningssystem baseret på simple IP-kameraer, bliver det muligt at udvide det og gøre det til et fuldgyldigt cloud-smarthjem.
Den mest populære protokol til IP-videoovervågningssystemer, nu understøttet af alle IP-kameraproducenter uden undtagelse, er , hvis specifikationer findes i Web Services Description Language . Brug af hjælpeprogrammerne fra værktøjskassen det er muligt at generere kildekoden for tjenester, der arbejder med IP-kameraer:
$ 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 et resultat får vi et sæt header "*.h" og kilde "*.cpp" filer i C++ sproget, som kan placeres direkte i en applikation eller et separat bibliotek og kompileres ved hjælp af GCC compileren. På grund af de mange funktioner er koden stor og kræver yderligere optimering. Raspberry Pi 3 model B+ mikrocomputeren har nok ydeevne til at udføre denne kode, men i tilfælde af at det bliver nødvendigt at portere koden til en anden platform, er det nødvendigt at vælge den rigtige processorarkitektur og systemressourcer.
IP-kameraer, der understøtter ONVIF-standarden, er, når de opererer i et lokalt netværk, forbundet til en speciel multicast-gruppe med adressen 239.255.255.250. Der er en protokol , som giver dig mulighed for at automatisere søgningen efter enheder på det lokale netværk.
I den grafiske grænseflade på smart home-controlleren er funktionen til at søge efter IP-kameraer i PHP-sproget implementeret, hvilket er meget praktisk, når man interagerer med webtjenester via XML-meddelelser. Ved valg af menupunkter Enheder > IP-kameraer > Scan algoritmen til at søge efter IP-kameraer startes og viser resultatet i form af en tabel:
(klik på billedet for at åbne i større opløsning)
Når du tilføjer et kamera til controlleren, kan du angive de indstillinger, som det vil interagere med skyen efter. Også på dette trin tildeles den automatisk en unik enhedsidentifikator, hvormed den let kan identificeres i skyen i fremtiden.
Dernæst genereres en besked i JSON-format, der indeholder alle parametrene for det tilføjede kamera og sendes til serverprocessen for smart home-controlleren via RESTful API-kommandoen, hvor kameraparametrene afkodes og gemmes i den interne SQLite-database og er bruges også til at starte følgende behandlingstråde:
- etablering af en RTSP-forbindelse til at modtage video- og lydstreams;
- lydtranskodning fra G.711 mu-Law, G.711 A-Law, G.723 osv. til AAC-format;
- omkodning af videostreams i H.264-format og lyd i AAC-format til en FLV-beholder og overførsel til skyen via RTMP-protokollen;
- Etablering af en forbindelse med endepunktet af IP-kameraets bevægelsesdetektor ved hjælp af ONVIF-protokollen og periodisk polling af den;
- periodisk at generere et miniaturebillede (preview) og sende det til skyen ved hjælp af MQTT-protokollen;
- lokal optagelse af video- og lydstreams som separate filer i MP4-format på SD- eller Flash-kortet på smart home-controlleren.
For at etablere forbindelse med kameraer, omkode, behandle og optage videostreams i serverprocessen, bruges funktioner fra biblioteket 4.1.0.
I præstationstesteksperimentet blev 3 kameraer forbundet til controlleren:
- HiWatch DS-I114W (opløsning - 720p, komprimeringsformat - H.264, bithastighed - 1 Mb/s, lyd G.711 mu-Law);
- Microdigital MDC-M6290FTD-1 (opløsning - 1080p, komprimeringsformat - H.264, bithastighed - 1 Mb/s, ingen lyd);
- Dahua DH-IPC-HDW4231EMP-AS-0360B (opløsning - 1080p, komprimeringsformat - H.264, bithastighed - 1.5 Mb/s, AAC-lyd).
Alle tre streams blev samtidigt udsendt til skyen, lyd blev omkodet fra kun ét kamera, og lokal arkivoptagelse blev deaktiveret. CPU-belastningen var omkring 5%, RAM-forbruget var 32 MB (pr. proces), 56 MB (i alt med OS).
Der kan således tilsluttes omkring 20 - 30 kameraer til smart home-controlleren (afhængig af opløsning og bitrate), hvilket er nok til et videoovervågningssystem af et tre-etagers sommerhus eller et lille lager. I opgaver, hvor høj ydeevne er påkrævet, kan du bruge en nettop med en multi-core Intel-processor og Linux Debian Sarge. Den registeransvarlige er i øjeblikket under prøvedrift, og data om udførelsen af dens arbejde vil blive specificeret.
Interaktion med skyen
Cloud smart home gemmer brugerdata (video- og sensormålinger) i skyen. Arkitekturen af cloud storage vil blive diskuteret mere detaljeret i den næste artikel i vores serie. Lad os nu tale om grænsefladen til at overføre informationsmeddelelser fra smart home-controlleren til skyen.
Tilstandene for tilsluttede enheder og sensormålinger transmitteres via protokollen , som ofte bruges i Internet of Things-projekter på grund af dets enkelhed og energieffektivitet. MQTT bruger en klient-server-model, hvor klienter abonnerer på bestemte emner i mægleren og udgiver deres beskeder. Mægleren sender beskeder til alle abonnenter i henhold til reglerne bestemt af QoS-niveauet (Quality of Service):
- QoS 0 - maksimalt én gang (ingen garanti for levering);
- QoS 1 - mindst én gang (med leveringsbekræftelse);
- QoS 2 - præcis én gang (med yderligere bekræftelse af levering).
I vores tilfælde er MQTT-mægleren . Emnenavnet er det unikke ID for smart home-controlleren. MQTT-klienten inde i serverprocessen abonnerer på dette emne og oversætter til det JSON-meddelelser, der kommer fra meddelelsesafsenderen. Og omvendt videresendes beskeder fra MQTT-mægleren til beskedadministratoren, som derefter multiplekser dem til sine abonnenter inde i serverprocessen:
For at sende beskeder om status for smart home-controlleren bruges mekanismen for lagrede beskeder. MQTT protokol. Dette giver dig mulighed for korrekt at spore gentilslutningsmomenterne i tilfælde af strømsvigt.
MQTT-klienten blev udviklet baseret på implementeringen af biblioteket i C++.
H.264 + AAC-mediestrømme sendes til skyen via RTMP-protokollen, hvor en klynge af medieservere er ansvarlige for deres behandling og lagring. For optimal belastningsfordeling i klyngen og valg af den mindst belastede medieserver, sender smart home controlleren en foreløbig anmodning til cloud load balancer og sender først derefter mediestrømmen.
Konklusion
Artiklen behandlede en specifik implementering af en smart home controller baseret på Raspberry Pi 3 B+ mikrocomputeren, som kan modtage, behandle information og styre udstyr ved hjælp af Z-Wave-protokollen, interagere med IP-kameraer ved hjælp af ONVIF-protokollen og også udveksle data og kommandoer med skytjenesten via MQTT- og RTMP-protokoller. En produktionslogikmotor er blevet udviklet baseret på en sammenligning af logiske regler og fakta præsenteret i JSON-format.
Nu er smart home-controlleren under prøvedrift på flere faciliteter i Moskva og Moskva-regionen.
I den næste version af controlleren er det planlagt at forbinde enheder af andre typer (RF, Bluetooth, WiFi, kablet). For brugernes bekvemmelighed vil proceduren for tilslutning af sensorer og IP-kameraer blive overført til mobilapplikationen. Der er også ideer til optimering af serverproceskoden og portering af software til operativsystemet . Dette vil spare på en separat controller og overføre funktionaliteten af et smart hjem til en almindelig husstandsrouter.
Kilde: www.habr.com