I dag, takket være den raske utviklingen av mikroelektronikk, kommunikasjonskanaler, Internett-teknologier og kunstig intelligens, blir temaet smarte hjem mer og mer aktuelt. Menneskelig bolig har gjennomgått betydelige endringer siden steinalderen og i epoken med industriell revolusjon 4.0 og tingenes internett har den blitt komfortabel, funksjonell og trygg. Det kommer løsninger på markedet som gjør en leilighet eller et landsted til komplekse informasjonssystemer som styres fra hvor som helst i verden ved hjelp av en smarttelefon. Dessuten krever menneske-maskin-interaksjon ikke lenger kunnskap om programmeringsspråk - takket være talegjenkjennings- og syntesealgoritmer snakker en person til et smart hjem på morsmålet sitt.
Noen smarthussystemer som for tiden er på markedet er en logisk utvikling av skyvideoovervåkingssystemer, hvor utviklerne innså behovet for en omfattende løsning, ikke bare for overvåking, men også for administrasjon av eksterne objekter.
Vi presenterer for din oppmerksomhet en serie på tre artikler, som vil fortelle deg om alle hovedkomponentene i et sky-smarthjemsystem, personlig utviklet av forfatteren og satt i drift. Den første artikkelen er viet terminalklientutstyret installert i et smarthus, den andre til arkitekturen til skylagrings- og databehandlingssystemet, og til slutt, den tredje til klientapplikasjonen for å administrere systemet på mobile og stasjonære enheter.
Smart hjem utstyr
Først, la oss snakke om hvordan du lager et smart hjem ut av en vanlig leilighet, hytte eller hytte. For å gjøre dette er det som regel nødvendig å plassere følgende utstyr i hjemmet:
- sensorer som måler ulike miljøparametere;
- aktuatorer som virker på eksterne objekter;
- en kontroller som utfører beregninger i henhold til sensormålinger og innebygd logikk, og gir kommandoer til aktuatorer.
Følgende figur viser et diagram av et smarthus, hvor det er sensorer for vannlekkasje (1) på badet, temperatur (2) og belysning (3) på soverommet, en smart stikkontakt (4) på kjøkkenet og en videoovervåkingskamera (5) i gangen.
For tiden er trådløse sensorer som bruker RF433, Z-Wave, ZigBee, Bluetooth og WiFi-protokollene mye brukt. Deres viktigste fordeler er enkel installasjon og bruk, samt lave kostnader og pålitelighet, fordi... Produsenter streber etter å bringe enhetene sine til massemarkedet og gjøre dem tilgjengelige for den gjennomsnittlige brukeren.
Sensorer og aktuatorer er som regel koblet via et trådløst grensesnitt til en smarthjemkontroller (6) - en spesialisert mikrodatamaskin som kombinerer alle disse enhetene til et enkelt nettverk og kontrollerer dem.
Noen løsninger kan imidlertid kombinere en sensor, en aktuator og en kontroller samtidig. For eksempel kan en smart plugg programmeres til å slå på eller av i henhold til en tidsplan, og et skyvideoovervåkingskamera kan ta opp video basert på et bevegelsesdetektorsignal. I de enkleste tilfellene kan du klare deg uten en egen kontroller, men for å lage et fleksibelt system med mange scenarier er det nødvendig.
For å koble smarthuskontrolleren til det globale nettverket kan en vanlig Internett-ruter (7) brukes, som for lengst har blitt et vanlig husholdningsapparat i ethvert hjem. Her er det et annet argument for en smarthuskontroller – hvis forbindelsen til Internett blir borte, vil smarthjemmet fortsette å fungere som normalt takket være logikkblokken som er lagret inne i kontrolleren, og ikke i skytjenesten.
Smart hjemmekontroller
Kontrolleren for nettsky-smarthjemsystemet som er omtalt i denne artikkelen, er utviklet basert på en enkeltkorts mikrodatamaskin , som ble utgitt i mars 2018 og har tilstrekkelige ressurser og ytelse for smarthusoppgaver. Den inkluderer en firekjerners Cortex-A53-prosessor basert på 64-biters ARMv8-A-arkitektur, klokket til 1.4 GHz, samt 1 GB RAM, Wi-Fi 802.11ac, Bluetooth 4.2 og en gigabit Ethernet-adapter som opererer via USB 2.0 .
Montering av kontrolleren er veldig enkel - mikrodatamaskinen (1) er installert i en plastboks (2), deretter installeres et 8 GB minnekort i microSD-format med programvare (3) og en USB Z-Wave nettverkskontroller (4) i de tilsvarende sporene. Smarthjemkontrolleren kobles til strømforsyningen via en 5V, 2.1A strømadapter (5) og en USB - mikro-USB-kabel (6). Hver kontroller har et unikt identifikasjonsnummer, som er skrevet i konfigurasjonsfilen når den startes første gang, og er nødvendig for å samhandle med smarte hjemmetjenester i skyen.
Programvaren for smarthjemkontroller ble utviklet av forfatteren av denne artikkelen basert på operativsystemet Linux Raspbian Stretch. Den består av følgende hoveddelsystemer:
- serverprosess for interaksjon med smarthusutstyr og skyen;
- grafisk brukergrensesnitt for å stille inn konfigurasjonen og driftsparametrene til kontrolleren;
- database for lagring av kontrollerkonfigurasjon.
Database smarthjemkontroller er implementert basert på en innebygd DBMS og er en fil på et SD-kort med systemprogramvare. Den fungerer som lagring for kontrollerkonfigurasjonen - informasjon om det tilkoblede utstyret og dets nåværende tilstand, en blokk med logiske produksjonsregler, samt informasjon som krever indeksering (for eksempel filnavn på et lokalt videoarkiv). Når kontrolleren startes på nytt, lagres denne informasjonen, noe som gjør det mulig å gjenopprette kontrolleren i tilfelle strømbrudd.
Grafisk grensesnitt smarthjemkontroller utviklet i PHP 7 ved hjelp av et mikrorammeverk . Nettserveren er ansvarlig for å kjøre applikasjonen. , ofte brukt i innebygde enheter på grunn av dens gode ytelse og lave ressurskrav.
(klikk på bildet for å åpne det i høyere oppløsning)
Hovedfunksjonen til det grafiske grensesnittet er å koble smarthusutstyr (IP-overvåkingskameraer og sensorer) til kontrolleren. Nettapplikasjonen leser konfigurasjonen og gjeldende tilstanden til kontrolleren og enheter som er koblet til den fra SQLite-databasen. For å endre kontrollerkonfigurasjonen, sender den kontrollkommandoer i JSON-format gjennom RESTful API-grensesnittet til serverprosessen.
Serverprosess
Serverprosess - en nøkkelkomponent som utfører alt hovedarbeidet med å automatisere informasjonsprosesser som danner grunnlaget for et smart hjem: motta og behandle sensoriske data, utstede kontrollhandlinger avhengig av den innebygde logikken. Formålet med serverprosessen er å samhandle med smarthusutstyr, utføre logiske produksjonsregler, motta og behandle kommandoer fra det grafiske grensesnittet og skyen. Serverprosessen i smarthuskontrolleren som vurderes er implementert som en flertrådsapplikasjon utviklet i C++ og lansert som en egen tjeneste systemd operativsystem Linux Raspbian.
Hovedblokkene i serverprosessen er:
- Meldingsbehandling;
- IP-kamera server;
- Z-Wave enhet server;
- Server for produksjon logiske regler;
- Database for konfigurasjon av kontrolleren og blokk med logiske regler;
- RESTful API-server for interaksjon med det grafiske grensesnittet;
- MQTT-klient for samhandling med skyen.
Serverprosessblokker implementeres som separate tråder, informasjon mellom disse overføres i form av meldinger i JSON-format (eller datastrukturer som representerer dette formatet i prosessminnet).
Hovedkomponenten i serverprosessen er meldingsbehandler, som ruter JSON-meldinger til alle serverprosessblokker. Typene JSON-meldingsinformasjonsfelt og verdiene de kan godta er oppført i tabellen:
Enhetstype
protokollen
meldingstype
enhetstilstand
kommando
rom
onvif
sensordata
on
streaming (på/av)
sensor
zwave
kommando
off
opptak (på/av)
effektor
kvm
businessLogicRule
streaming (på/av)
utstyr (Legg til/fjern)
forretningslogikk
konfigurasjonsdata
opptak (på/av)
blåtann
enhetstilstand
feil
wifi
rf
For eksempel ser en melding fra en kamerabevegelsesdetektor slik ut:
{
"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"
}
Produksjonslogikk
For å motta eller sende en melding fra ekspeditøren, abonnerer serverprosessblokken på meldinger av en bestemt type. Abonnement er en produksjonslogisk regel av typen "Hvis da...", presentert i JSON-format, og en lenke til meldingsbehandleren inne i serverprosessblokken. For å la IP-kameraserveren motta kommandoer fra GUI og skyen, må du for eksempel legge til følgende regel:
{
"if": {
"and": [{
"equal": {
"deviceId": "1616453d-30cd-44b7-9bf0-************"
}
},
{
"equal": {
"messageType": "command"
}
}
]
},
"then": {
"result": "true"
}
}
Hvis forholdene spesifisert i forutgående (venstre side) reglene er sanne, så er den fornøyd konsekvent (høyre side) regler, og behandleren får tilgang til brødteksten i JSON-meldingen. Forløpet støtter logiske operatorer som sammenligner JSON-nøkkelverdi-par:
- er lik "lik";
- ikke lik "ikke_lik";
- mindre "mindre";
- mer "større";
- mindre enn eller lik "mindre_eller_lik";
- større enn eller lik "større_eller_lik".
Sammenligningsresultatene kan relateres til hverandre ved å bruke boolske algebraoperatorer:
- og "og"
- ELLER "eller";
- Ikke ikke".
Ved å skrive operatorer og operander i polsk notasjon kan du dermed lage ganske komplekse forhold med et stort antall parametere.
Nøyaktig den samme mekanismen, basert på JSON-meldinger og produksjonsregler i JSON-format, brukes i produksjonslogikkserverblokken for å representere kunnskap og utføre logisk slutning ved hjelp av sensoriske data fra smarthussensorer.
Ved hjelp av en mobilapplikasjon lager brukeren scenarier som smarthjemmet skal fungere etter. For eksempel: "Hvis sensoren for å åpne inngangsdøren utløses, slå på lyset i gangen". Applikasjonen leser identifikatorene til sensorer (åpningssensor) og aktuatorer (smart socket eller smart lampe) fra databasen og genererer en logisk regel i JSON-format, som sendes til smarthjemkontrolleren. Denne mekanismen vil bli diskutert mer detaljert i den tredje artikkelen i serien vår, hvor vi vil snakke om klientapplikasjonen for å administrere et smart hjem.
Produksjonslogikkmekanismen diskutert ovenfor implementeres ved bruk av biblioteket — SAX-parser for JSON-format i C++. Sekvensiell lesing og parsing av en rekke produksjonsregler lar deg enkelt implementere datasammenligningsfunksjonen i antecedenter:
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 som inneholder nøkkelverdi-par fra en JSON-melding, m_Regler — streng rekke produksjonsregler. Sammenligningen av innkommende melding og produksjonsregelen utføres i funksjonen reader.Parse(ruleStream, ruleHandler)Der regelHandler er et objekt som inneholder logikken til boolske og sammenligningsoperatorer. sRuleId — en unik regelidentifikator, takket være hvilken det er mulig å lagre og redigere regler i smarthjemkontrolldatabasen. m_pActions — en matrise med resultatene av logisk slutning: JSON-meldinger som inneholder konsekvenser fra regelbasen og sendt videre til meldingsbehandlingen slik at abonnenttråder kan behandle dem.
RapidJSON-ytelsen er sammenlignbar med funksjonen strlen(), og minimumskravene til systemressurs tillater bruk av dette biblioteket i innebygde enheter. Bruken av meldinger og logiske regler i JSON-format lar deg implementere et fleksibelt system for informasjonsutveksling mellom alle komponentene i smarthjemkontrolleren.
Z-Wave sensorer og aktuatorer
Hovedfordelen med et smart hjem er at det uavhengig kan måle ulike parametere i det ytre miljøet og utføre nyttige funksjoner avhengig av situasjonen. For å gjøre dette er sensorer og aktuatorer koblet til smarthjemkontrolleren. I gjeldende versjon er dette trådløse enheter som bruker protokollen på en spesielt tildelt frekvens 869 MHz For Russland. For å operere er de kombinert til et mesh-nettverk, som inneholder signalrepeatere for å øke dekningsområdet. Enhetene har også en spesiell energisparingsmodus - de tilbringer mesteparten av tiden i hvilemodus og sender informasjon kun når tilstanden deres endres, noe som kan forlenge levetiden til det innebygde batteriet betydelig.
Du kan nå finne et ganske stort antall forskjellige Z-Wave-enheter på markedet. La oss ta en titt på noen eksempler:
- Zipato PAN16 smartkontakt kan måle følgende parametere: strømforbruk (kWh), effekt (W), spenning (V) og strøm (A) i det elektriske nettverket. Den har også en innebygd bryter som du kan styre det tilkoblede elektriske apparatet med;
- Neo Coolcam-lekkasjesensoren oppdager tilstedeværelsen av væskesøl ved å lukke kontaktene til den eksterne sonden;
- Zipato PH-PSG01 røyksensoren utløses når røykpartikler kommer inn i gassanalysatorkammeret;
- Neo Coolcam-bevegelsessensoren analyserer den infrarøde strålingen fra menneskekroppen. I tillegg er det en lyssensor (Lx);
- Multisensor Philio PST02-A måler temperatur (°C), lys (%), døråpning, tilstedeværelse av en person i rommet;
- Z-Wave USB Stick ZME E UZB1 nettverkskontroller, som sensorer er koblet til.
Det er veldig viktig at enhetene og kontrolleren fungerer på samme frekvens, ellers vil de rett og slett ikke se hverandre i tilkoblingsøyeblikket. Opptil 232 enheter kan kobles til en Z-Wave-nettverkskontroller, som er ganske nok for en leilighet eller et landsted. For å utvide nettverksdekningsområdet innendørs kan en smart stikkontakt brukes som signalforsterker.
I serverprosessen for smarthjemkontroller diskutert i forrige avsnitt, er Z-Wave-serveren ansvarlig for å samhandle med Z-Wave-enheter. Den bruker et bibliotek for å motta informasjon fra sensorer i C++, som gir et grensesnitt for interaksjon med Z-Wave nettverks USB-kontroller og fungerer med en rekke sensorer og aktuatorer. Verdien av miljøparameteren målt av sensoren registreres av Z-Wave-serveren i form av en JSON-melding:
{
"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"
}
Den videresendes deretter til serverprosessens meldingsbehandler slik at abonnenttråder kan motta den. Hovedabonnenten er produksjonslogikkserveren, som samsvarer med meldingsfeltverdiene i forløpene til logikkreglene. Inferensresultatene som inneholder kontrollkommandoer sendes tilbake til meldingsbehandleren og går derfra til Z-Wave-serveren, som dekoder dem og sender dem til Z-Wave nettverks USB-kontrolleren. Deretter går de inn i aktuatoren, som endrer tilstanden til miljøobjekter, og smarthjemmet utfører dermed nyttig arbeid.
(klikk på bildet for å åpne det i høyere oppløsning)
Tilkobling av Z-Wave-enheter gjøres i det grafiske grensesnittet til smarthjemkontrolleren. For å gjøre dette, gå til siden med en liste over enheter og klikk på "Legg til" -knappen. Add-kommandoen via RESTful API-grensesnittet går inn i serverprosessen og sendes deretter av meldingsbehandleren til Z-Wave-serveren, som setter Z-Wave nettverks USB-kontrolleren i en spesiell modus for å legge til enheter. Deretter må du på Z-Wave-enheten gjøre en rekke hurtige trykk (3 trykk innen 1,5 sekunder) på serviceknappen. USB-kontrolleren kobler enheten til nettverket og sender informasjon om den til Z-Wave-serveren. Det skaper igjen en ny oppføring i SQLite-databasen med parametrene til den nye enheten. Etter et spesifisert tidsintervall går det grafiske grensesnittet tilbake til Z-Wave-enhetslistesiden, leser informasjon fra databasen og viser den nye enheten i listen. Hver enhet mottar sin egen unike identifikator, som brukes i produksjonsslutningsregler og når du jobber i skyen. Virkemåten til denne algoritmen er vist i UML-diagrammet:
(klikk på bildet for å åpne det i høyere oppløsning)
Koble til IP-kameraer
Sky-smarthussystemet som diskuteres i denne artikkelen er en oppgradering av skyvideoovervåkingssystemet, også utviklet av forfatteren, som har vært på markedet i flere år og har mange installasjoner i Russland.
For skyvideoovervåkingssystemer er et av de akutte problemene det begrensede utvalget av utstyr som integrasjon kan utføres med. Programvaren som er ansvarlig for å koble til skyen er installert inne i videokameraet, som umiddelbart stiller alvorlige krav til maskinvaren - prosessoren og mengden ledig minne. Dette forklarer hovedsakelig den høyere prisen på sky-CCTV-kameraer sammenlignet med vanlige IP-kameraer. I tillegg kreves det en langvarig fase av forhandlinger med CCTV-kameraprodusenter for å få tilgang til kamerafilsystemet og alle nødvendige utviklingsverktøy.
På den annen side har alle moderne IP-kameraer standardprotokoller for interaksjon med annet utstyr (spesielt videoopptakere). Dermed gir bruk av en egen kontroller som kobles til via en standardprotokoll og kringkaster videostrømmer fra IP-kameraer til skyen betydelige konkurransefortrinn for skyvideoovervåkingssystemer. Dessuten, hvis klienten allerede har installert et videoovervåkingssystem basert på enkle IP-kameraer, blir det mulig å utvide det og gjøre det om til et fullverdig skysmarthjem.
Den mest populære protokollen for IP-videoovervåkingssystemer, nå støttet av alle IP-kameraprodusenter uten unntak, er , hvis spesifikasjoner finnes i et beskrivelsesspråk for nettjenester . Bruke verktøy fra verktøysettet Det er mulig å generere kildekode for tjenester som fungerer 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 sett med overskrift "*.h" og kilde-"*.cpp"-filer i C++, som kan plasseres direkte i en applikasjon eller et separat bibliotek og kompileres ved hjelp av GCC-kompilatoren. På grunn av de mange funksjonene er koden stor og krever ytterligere optimalisering. Raspberry Pi 3 modell B+ mikrodatamaskin har tilstrekkelig ytelse til å utføre denne koden, men hvis det er behov for å portere koden til en annen plattform, er det nødvendig å velge riktig prosessorarkitektur og systemressurser.
IP-kameraer som støtter ONVIF-standarden, når de opererer på et lokalt nettverk, er koblet til en spesiell multicast-gruppe med adressen 239.255.255.250. Det er en protokoll , som lar deg automatisere søket etter enheter på det lokale nettverket.
Det grafiske grensesnittet til smarthuskontrolleren implementerer en søkefunksjon for IP-kameraer i PHP, noe som er veldig praktisk når du samhandler med webtjenester via XML-meldinger. Når du velger menyelementer Enheter > IP-kameraer > Skanning Algoritmen for å søke etter IP-kameraer lanseres, og viser resultatet i form av en tabell:
(klikk på bildet for å åpne det i høyere oppløsning)
Når du legger til et kamera til kontrolleren, kan du spesifisere innstillingene som det skal samhandle med skyen i henhold til. Også på dette stadiet tildeles den automatisk en unik enhetsidentifikator, som den senere enkelt kan identifiseres med i skyen.
Deretter genereres en melding i JSON-format som inneholder alle parameterne til kameraet som er lagt til og sendes til serverprosessen til smarthjemkontrolleren via RESTful API-kommandoen, hvor kameraparametrene dekodes og lagres i den interne SQLite-databasen, og er brukes også til å starte følgende behandlingstråder:
- etablere en RTSP-tilkobling for å motta video- og lydstrømmer;
- omkoding av lyd fra formatene G.711 mu-Law, G.711 A-Law, G.723, etc.. til AAC-format;
- transkoding av videostrømmer i H.264-format og lyd i AAC-format til en FLV-beholder og overføre den til skyen via RTMP-protokollen;
- etablere en forbindelse med endepunktet til IP-kameraets bevegelsesdetektor via ONVIF-protokollen og periodisk polle den;
- periodisk generere et forhåndsvisningsbilde med miniatyrbilder og sende det til skyen via MQTT-protokollen;
- lokalt opptak av video- og lydstrømmer i form av separate filer i MP4-format på et SD- eller Flash-kort på smarthjemkontrolleren.
For å etablere forbindelse med kameraer, omkode, behandle og ta opp videostrømmer i serverprosessen, brukes funksjoner fra biblioteket 4.1.0.
I ytelsestesteeksperimentet ble 3 kameraer koblet til kontrolleren:
- HiWatch DS-I114W (oppløsning - 720p, komprimeringsformat - H.264, bitrate - 1 Mb/s, lyd G.711 mu-Law);
- Microdigital MDC-M6290FTD-1 (oppløsning - 1080p, komprimeringsformat - H.264, bitrate - 1 Mb/s, ingen lyd);
- Dahua DH-IPC-HDW4231EMP-AS-0360B (oppløsning - 1080p, komprimeringsformat - H.264, bitrate - 1.5 Mb/s, AAC-lyd).
Alle tre strømmene ble sendt ut samtidig til skyen, lydtranskoding ble utført fra bare ett kamera, og lokalt arkivopptak ble deaktivert. CPU-belastningen var omtrent 5 %, RAM-bruken var 32 MB (per prosess), 56 MB (totalt inkludert OS).
Dermed kan cirka 20 - 30 kameraer kobles til smarthuskontrolleren (avhengig av oppløsning og bitrate), noe som er nok til et videoovervåkingssystem for en tre-etasjers hytte eller et lite lager. For oppgaver som krever større ytelse, kan du bruke en nettop med en multi-core Intel-prosessor og Linux Debian Sarge OS. Kontrolløren er for tiden under prøvedrift, og data om ytelsen vil bli oppdatert.
Interaksjon med skyen
Et skybasert smarthus lagrer brukerdata (video- og sensormålinger) i skyen. Arkitekturen til skylagring vil bli diskutert mer detaljert i neste artikkel i serien vår. La oss nå snakke om grensesnittet for overføring av informasjonsmeldinger fra smarthjemkontrolleren til skyen.
Tilstandene til tilkoblede enheter og sensormålinger overføres via protokollen , som ofte brukes i Internet of Things-prosjekter på grunn av sin enkelhet og energieffektivitet. MQTT bruker en klient-server-modell, der klienter abonnerer på spesifikke emner i megleren og publiserer meldingene sine. Megleren sender meldinger til alle abonnenter i henhold til regler bestemt av QoS-nivået (Quality of Service):
- QoS 0 - maksimalt én gang (ingen leveringsgaranti);
- QoS 1 - minst én gang (med leveringsbekreftelse);
- QoS 2 - nøyaktig én gang (med ytterligere leveringsbekreftelse).
I vårt tilfelle bruker vi . Emnenavnet er den unike identifikatoren til smarthjemkontrolleren. MQTT-klienten inne i serverprosessen abonnerer på dette emnet og oversetter JSON-meldinger som kommer fra meldingsbehandleren til det. Motsatt blir meldinger fra MQTT-megleren videresendt av den til meldingsbehandleren, som deretter multiplekser dem til sine abonnenter inne i serverprosessen:
For å overføre meldinger om statusen til smarthjemkontrolleren, brukes mekanismen for lagrede meldinger MQTT-protokoll. Dette lar deg overvåke tidspunktet for gjentilkoblinger under strømbrudd.
MQTT-klienten ble utviklet basert på bibliotekimplementeringen på C++ språk.
H.264 + AAC-mediestrømmer sendes til skyen via RTMP-protokollen, hvor en klynge av medieservere er ansvarlig for å behandle og lagre dem. For å fordele belastningen i klyngen optimalt og velge den minst belastede medieserveren, sender smarthjemkontrolleren en foreløpig forespørsel til skylastbalanseren og sender mediestrømmen først etter det.
Konklusjon
Artikkelen undersøkte én spesifikk implementering av en smarthuskontroller basert på Raspberry Pi 3 B+ mikrodatamaskinen, som kan motta, behandle informasjon og kontrollere utstyr via Z-Wave-protokollen, samhandle med IP-kameraer via ONVIF-protokollen, og også utveksle data og kommandoer med skytjenesten via MQTT- og RTMP-protokoller. En produksjonslogikkmotor er utviklet basert på en sammenligning av logiske regler og fakta presentert i JSON-format.
Smarthjemkontrolleren er for tiden under prøvedrift på flere steder i Moskva og Moskva-regionen.
Den neste versjonen av kontrolleren planlegger å koble til andre typer enheter (RF, Bluetooth, WiFi, kablet). For brukerens bekvemmelighet vil prosedyren for tilkobling av sensorer og IP-kameraer bli overført til mobilapplikasjonen. Det er også ideer for å optimalisere serverprosesskoden og portere programvaren til operativsystemet . Dette lar deg spare på en separat kontroller og overføre funksjonaliteten til et smart hjem til en vanlig husholdningsruter.
Kilde: www.habr.com