Vandag, danksy die vinnige ontwikkeling van mikro-elektronika, kommunikasiekanale, internettegnologieë en kunsmatige intelligensie, word die onderwerp van slim huise meer en meer relevant. Menslike behuising het aansienlike veranderinge ondergaan sedert die Steentydperk en in die era van Industriële Revolusie 4.0 en die Internet van Dinge, het dit gemaklik, funksioneel en veilig geword. Oplossings kom na die mark wat 'n woonstel of 'n plattelandse huis verander in komplekse inligtingstelsels wat van enige plek in die wêreld met 'n slimfoon beheer word. Boonop vereis mens-masjien-interaksie nie meer kennis van programmeertale nie - danksy spraakherkenning en sintese-algoritmes praat 'n persoon met 'n slim huis in hul moedertaal.

Sommige slimhuisstelsels wat tans op die mark is, is 'n logiese ontwikkeling van wolkvideo-toesigstelsels, waarvan die ontwikkelaars die behoefte aan 'n omvattende oplossing besef het, nie net vir monitering nie, maar ook vir die bestuur van afgeleë voorwerpe.

Ons bied 'n reeks van drie artikels aan u aandag, wat u sal vertel van al die hoofkomponente van 'n wolk-slimhuisstelsel, persoonlik ontwikkel deur die skrywer en in werking gestel. Die eerste artikel word gewy aan die terminale kliënttoerusting wat binne 'n slimhuis geïnstalleer is, die tweede aan die argitektuur van die wolkberging- en dataverwerkingstelsel, en laastens, die derde aan die kliënttoepassing vir die bestuur van die stelsel op mobiele en stilstaande toestelle.

Slim huis toerusting

Kom ons praat eers oor hoe om 'n slim huis uit 'n gewone woonstel, huis of kothuis te maak. Om dit te doen, is dit gewoonlik nodig om die volgende toerusting in die huis te plaas:

1. sensors wat verskeie omgewingsparameters meet;
2. aktueerders wat op eksterne voorwerpe inwerk;
3. 'n beheerder wat berekeninge uitvoer in ooreenstemming met sensormetings en ingebedde logika, en opdragte aan aktueerders uitreik.

Die volgende figuur toon 'n diagram van 'n slimhuis, waarop daar sensors is vir waterlekkasie (1) in die badkamer, temperatuur (2) en beligting (3) in die slaapkamer, 'n slimsok (4) in die kombuis en 'n videobewakingskamera (5) in die gang.

Tans word draadlose sensors wat die RF433-, Z-Wave-, ZigBee-, Bluetooth- en WiFi-protokolle gebruik, wyd gebruik. Hul belangrikste voordele is die gemak van installasie en gebruik, sowel as lae koste en betroubaarheid, want Vervaardigers streef daarna om hul toestelle na die massamark te bring en dit toeganklik te maak vir die gemiddelde gebruiker.

Sensors en aktueerders word as 'n reël via 'n draadlose koppelvlak aan 'n slimhuisbeheerder (6) gekoppel - 'n gespesialiseerde mikrorekenaar wat al hierdie toestelle in 'n enkele netwerk kombineer en dit beheer.

Sommige oplossings kan egter 'n sensor, 'n aktuator en 'n beheerder terselfdertyd kombineer. 'n Slimprop kan byvoorbeeld geprogrammeer word om volgens 'n skedule aan of af te skakel, en 'n wolkvideo-toesigkamera kan video opneem op grond van 'n bewegingsverklikkersein. In die eenvoudigste gevalle kan jy sonder 'n aparte beheerder klaarkom, maar om 'n buigsame stelsel met baie scenario's te skep, is dit nodig.

Om die slimhuisbeheerder aan die globale netwerk te koppel, kan 'n gewone internetroeteerder (7) gebruik word, wat lankal 'n algemene huishoudelike toestel in enige huis geword het. Hier is nog 'n argument ten gunste van 'n slimhuisbeheerder - as die verbinding met die internet verloor word, sal die slimhuis voortgaan om normaal te funksioneer danksy die logiese blok wat binne die beheerder gestoor is, en nie in die wolkdiens nie.

Slimhuisbeheerder

Die beheerder vir die wolk-slimhuisstelsel wat in hierdie artikel bespreek word, is ontwikkel op grond van 'n enkelbord-mikrorekenaar Raspberry Pi 3 model B+, wat in Maart 2018 vrygestel is en voldoende hulpbronne en werkverrigting het vir slimhuistake. Dit bevat 'n vierkern Cortex-A53-verwerker gebaseer op 64-bis ARMv8-A-argitektuur, geklok op 1.4 GHz, sowel as 1 GB RAM, Wi-Fi 802.11ac, Bluetooth 4.2 en 'n gigabit Ethernet-adapter wat via USB 2.0 werk. .

Die samestelling van die beheerder is baie eenvoudig - die mikrorekenaar (1) word in 'n plastiekkas (2) geïnstalleer, dan word 'n 8 GB geheuekaart in microSD-formaat met sagteware (3) en 'n USB Z-Wave netwerkbeheerder (4) geïnstalleer in die ooreenstemmende gleuwe. Die slimhuisbeheerder is aan die kragtoevoer gekoppel via 'n 5V, 2.1A-kragadapter (5) en 'n USB - mikro-USB-kabel (6). Elke beheerder het 'n unieke identifikasienommer, wat in die konfigurasielêer geskryf word wanneer dit die eerste keer bekendgestel word en wat nodig is om met wolkslimhuisdienste te kommunikeer.

Die slimhuisbeheerdersagteware is ontwikkel deur die skrywer van hierdie artikel gebaseer op die bedryfstelsel Linux Raspbian Stretch. Dit bestaan ​​uit die volgende hoofsubstelsels:

• bedienerproses vir interaksie met slimhuistoerusting en die wolk;
• grafiese gebruikerskoppelvlak vir die opstel van die konfigurasie en bedryfsparameters van die beheerder;
• databasis vir die stoor van kontroleerderkonfigurasie.

databasis slimhuisbeheerder word geïmplementeer op grond van 'n ingebedde DBBS SQLite en is 'n lêer op 'n SD-kaart met stelselsagteware. Dit dien as 'n berging vir die beheerderkonfigurasie - inligting oor die gekoppelde toerusting en sy huidige toestand, 'n blok logiese produksiereëls, sowel as inligting wat indeksering vereis (byvoorbeeld lêername van 'n plaaslike video-argief). Wanneer die beheerder herlaai word, word hierdie inligting gestoor, wat dit moontlik maak om die beheerder te herstel in die geval van 'n kragonderbreking.

Grafiese koppelvlak slimhuisbeheerder ontwikkel in PHP 7 met behulp van 'n mikroraamwerk Slim. Die webbediener is verantwoordelik om die toepassing te laat loop. ligtepd, wat dikwels in ingebedde toestelle gebruik word as gevolg van sy goeie werkverrigting en lae hulpbronvereistes.

(Klik op die prentjie om dit in hoër resolusie oop te maak)

Die hooffunksie van die grafiese koppelvlak is om slimhuistoerusting (IP-toesigkameras en sensors) aan die beheerder te koppel. Die webtoepassing lees die konfigurasie en huidige toestand van die beheerder en toestelle wat daaraan gekoppel is vanaf die SQLite-databasis. Om die kontroleerderkonfigurasie te verander, stuur dit beheeropdragte in JSON-formaat deur die RESTful API-koppelvlak van die bedienerproses.

Bediener proses

Bediener proses - 'n sleutelkomponent wat al die hoofwerk verrig om die inligtingsprosesse te outomatiseer wat die basis van 'n slimhuis vorm: ontvang en verwerking van sensoriese data, die uitreiking van beheeraksies afhangende van die ingebedde logika. Die doel van die bedienerproses is om met slimhuistoerusting te kommunikeer, produksielogiese reëls uit te voer, opdragte vanaf die grafiese koppelvlak en die wolk te ontvang en te verwerk. Die bedienerproses in die slimhuisbeheerder wat oorweeg word, word geïmplementeer as 'n multi-draadtoepassing wat in C++ ontwikkel is en as 'n aparte diens bekendgestel is systemd bedryfstelsel Linux Raspbian.

Die hoofblokke van die bedienerproses is:

1. Boodskapbestuurder;
2. IP kamera bediener;
3. Z-Wave toestel bediener;
4. Bediener van produksie logiese reëls;
5. Databasis van konfigurasie van die kontroleerder en blok van logiese reëls;
6. RUSTIGE API-bediener vir interaksie met die grafiese koppelvlak;
7. MQTT-kliënt vir interaksie met die wolk.

Bedienerprosesblokke word as aparte drade geïmplementeer, waartussen inligting oorgedra word in die vorm van boodskappe in JSON-formaat (of datastrukture wat hierdie formaat in prosesgeheue verteenwoordig).

Die hoofkomponent van die bedienerproses is boodskap bestuurder, wat JSON-boodskappe na alle bedienerprosesblokke stuur. Die tipes JSON-boodskapinligtingvelde en die waardes wat hulle kan aanvaar, word in die tabel gelys:

toesteltipe
protokol
boodskaptipe
toestel Staat
opdrag

kamera
onvif
sensordata
on
stroom (Aan/Af)

sensor
zwave
opdrag
af
opname (aan/af)

effektor
mqtt
businessLogicRule
stroom (Aan/Af)
evice (Voeg by / Verwyder)

besigheidsLogika
konfigurasie Data
opname (aan/af)

Bluetooth
toestel Staat
fout

wifi

rf

Byvoorbeeld, 'n boodskap van 'n kamera bewegingsdetektor lyk soos volg:

{
	"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"
}

Produksie logika

Om 'n boodskap van die versender te ontvang of te stuur, teken die bedienerprosesblok op boodskappe van 'n sekere soort in. Intekening is 'n produksie logiese reël van die tipe "As ... dan ...", aangebied in JSON-formaat, en 'n skakel na die boodskaphanteerder binne die bedienerprosesblok. Byvoorbeeld, om die IP-kamerabediener toe te laat om opdragte van die GUI en die wolk te ontvang, moet jy die volgende reël byvoeg:

{
	"if": {
	    "and": [{
		"equal": {
		    "deviceId": "1616453d-30cd-44b7-9bf0-************"
		}
	    },
	    {
		"equal": {
		    "messageType": "command"
		}
	    }
	    ]
	},
	"then": {
	    "result": "true"
	}
}

Indien die voorwaardes gespesifiseer in voorganger (linkerkant) die reëls is waar, dan is dit bevredig gevolglik (regterkant) reëls, en die hanteerder kry toegang tot die liggaam van die JSON-boodskap. Die antesedent ondersteun logiese operateurs wat JSON-sleutel-waarde-pare vergelyk:

1. gelyk aan "gelyk";
2. nie gelyk aan "nie_gelyk" nie;
3. minder "minder";
4. meer "groter";
5. minder as of gelyk aan "minder_of_gelyk";
6. groter as of gelyk aan "groter_of_gelyk".

Die vergelykingsresultate kan met mekaar in verband gebring word deur Boole-algebra-operateurs te gebruik:

1. En "en"
2. OF "of";
3. NIE "nie".

Deur dus operateurs en operandes in Poolse notasie te skryf, kan jy redelik komplekse toestande skep met 'n groot aantal parameters.

Presies dieselfde meganisme, gebaseer op JSON-boodskappe en produksiereëls in JSON-formaat, word in die produksielogika-bedienerblok gebruik om kennis voor te stel en logiese afleiding uit te voer met behulp van sensoriese data van slimhuissensors.

Deur 'n mobiele toepassing te gebruik, skep die gebruiker scenario's waarvolgens die slimhuis moet funksioneer. Byvoorbeeld: "As die sensor om die voordeur oop te maak geaktiveer word, skakel dan die lig in die gang aan". Die toepassing lees die identifiseerders van sensors (oopsensor) en aktueerders (slimsok of slimlamp) vanaf die databasis en genereer 'n logiese reël in JSON-formaat, wat na die slimhuisbeheerder gestuur word. Hierdie meganisme sal in meer besonderhede bespreek word in die derde artikel van ons reeks, waar ons sal praat oor die kliënttoepassing vir die bestuur van 'n slimhuis.

Die produksielogikameganisme wat hierbo bespreek is, word met behulp van die biblioteek geïmplementeer Vinnige JSON — SAX-ontleder vir JSON-formaat in C++. Opeenvolgende lees en ontleding van 'n verskeidenheid produksiereëls stel jou in staat om die datavergelykingsfunksie binne antesedente maklik te implementeer:

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);
        }
    }
}

Hier pFeit - 'n struktuur wat sleutel-waarde-pare van 'n JSON-boodskap bevat, m_Reëls - reeks produksiereëls. Die vergelyking van die inkomende boodskap en die produksiereël word in die funksie uitgevoer reader.Parse(ruleStream, ruleHandler)Waar reëlHandler is 'n objek wat die logika van Boole- en vergelykingsoperateurs bevat. sRuleId - 'n unieke reël-identifiseerder, waardeur dit moontlik is om reëls binne die slimhuisbeheerder-databasis te stoor en te redigeer. m_pActions — 'n skikking met die resultate van logiese afleiding: JSON-boodskappe wat gevolge van die reëlbasis bevat en verder na die boodskapbestuurder gestuur word sodat intekenaardrade dit kan verwerk.

RapidJSON-werkverrigting is vergelykbaar met die funksie strlen(), en die minimum stelselhulpbronvereistes laat die gebruik van hierdie biblioteek in ingebedde toestelle toe. Die gebruik van boodskappe en logiese reëls in JSON-formaat laat jou toe om 'n buigsame stelsel van inligting-uitruiling tussen alle komponente van die slimhuisbeheerder te implementeer.

Z-Wave sensors en aktueerders

Die grootste voordeel van 'n slim huis is dat dit onafhanklik verskeie parameters van die eksterne omgewing kan meet en nuttige funksies kan verrig, afhangende van die situasie. Om dit te doen, word sensors en aktueerders aan die slimhuisbeheerder gekoppel. In die huidige weergawe is dit draadlose toestelle wat die protokol gebruik Z-golf op 'n spesiaal toegewese frekwensie 869 MHz Vir Rusland. Om te werk, word hulle gekombineer in 'n maasnetwerk, wat seinherhalers bevat om die dekkingsarea te vergroot. Die toestelle het ook 'n spesiale energiebesparingsmodus - hulle spandeer die meeste van die tyd in slaapmodus en stuur inligting net wanneer hul toestand verander, wat die lewe van die ingeboude battery aansienlik kan verleng.

Jy kan nou 'n redelike groot aantal verskillende Z-Wave-toestelle op die mark vind. Kom ons kyk na 'n paar voorbeelde:

1. Die Zipato PAN16-slimsok kan die volgende parameters meet: elektrisiteitsverbruik (kWh), krag (W), spanning (V) en stroom (A) in die elektriese netwerk. Dit het ook ’n ingeboude skakelaar waarmee jy die gekoppelde elektriese toestel kan beheer;
2. Die Neo Coolcam-leksensor bespeur die teenwoordigheid van gemorste vloeistof deur die kontakte van die afstandsonde toe te maak;
3. Die Zipato PH-PSG01 rooksensor word geaktiveer wanneer rookdeeltjies die gasontlederkamer binnedring;
4. Die Neo Coolcam-bewegingsensor ontleed die infrarooi straling van die menslike liggaam. Daarbenewens is daar 'n ligsensor (Lx);
5. Multisensor Philio PST02-A meet temperatuur (°C), lig (%), deuropening, teenwoordigheid van 'n persoon in die kamer;
6. Z-Wave USB Stick ZME E UZB1 netwerkbeheerder, waaraan sensors gekoppel is.

Dit is baie belangrik dat die toestelle en die kontroleerder op dieselfde frekwensie werk, anders sal hulle mekaar eenvoudig nie sien op die oomblik van verbinding nie. Tot 232 toestelle kan aan een Z-Wave-netwerkbeheerder gekoppel word, wat genoeg is vir 'n woonstel of 'n plattelandse huis. Om die netwerkdekkingsarea binnenshuis uit te brei, kan 'n slimsok as 'n seinherhaler gebruik word.

In die slimhuisbeheerder-bedienerproses wat in die vorige paragraaf bespreek is, is die Z-Wave-bediener verantwoordelik vir interaksie met Z-Wave-toestelle. Dit gebruik 'n biblioteek om inligting van sensors te ontvang OpenZWave in C++, wat 'n koppelvlak bied vir interaksie met die Z-Wave-netwerk USB-beheerder en werk met 'n verskeidenheid sensors en aktueerders. Die waarde van die omgewingsparameter wat deur die sensor gemeet word, word deur die Z-Wave-bediener in die vorm van 'n JSON-boodskap aangeteken:

{
	"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"
}

Dit word dan aangestuur na die bedienerproses se boodskapbestuurder sodat intekenaardrade dit kan ontvang. Die hoofintekenaar is die produksielogikabediener, wat ooreenstem met die boodskapveldwaardes in die voorgange van die logikareëls. Die afleidingsresultate wat beheeropdragte bevat, word teruggestuur na die boodskapbestuurder en gaan van daar na die Z-Wave-bediener, wat dit dekodeer en na die Z-Wave-netwerk USB-beheerder stuur. Dan gaan hulle die aktuator binne, wat die toestand van omgewingsvoorwerpe verander, en die slim huis verrig dus nuttige werk.

(Klik op die prentjie om dit in hoër resolusie oop te maak)

Die koppeling van Z-Wave-toestelle word in die grafiese koppelvlak van die slimhuisbeheerder gedoen. Om dit te doen, gaan na die bladsy met 'n lys toestelle en klik op die "Voeg by" -knoppie. Die add-opdrag via die RESTful API-koppelvlak gaan die bedienerproses binne en word dan deur die boodskapbestuurder na die Z-Wave-bediener gestuur, wat die Z-Wave-netwerk USB-beheerder in 'n spesiale modus plaas om toestelle by te voeg. Vervolgens moet u op die Z-Wave-toestel 'n reeks vinnige druk (3 druk binne 1,5 sekondes) van die diensknoppie maak. Die USB-beheerder koppel die toestel aan die netwerk en stuur inligting daaroor na die Z-Wave-bediener. Dit skep op sy beurt 'n nuwe inskrywing in die SQLite-databasis met die parameters van die nuwe toestel. Na 'n gespesifiseerde tydinterval keer die grafiese koppelvlak terug na die Z-Wave-toestellysbladsy, lees inligting uit die databasis en vertoon die nuwe toestel in die lys. Elke toestel ontvang sy eie unieke identifiseerder, wat gebruik word in produksie-afleidingsreëls en wanneer daar in die wolk gewerk word. Die werking van hierdie algoritme word in die UML-diagram getoon:

(Klik op die prentjie om dit in hoër resolusie oop te maak)

Koppel IP-kameras

Die wolk-slimhuisstelsel wat in hierdie artikel bespreek word, is 'n opgradering van die wolkvideo-toesigstelsel, ook ontwikkel deur die skrywer, wat al etlike jare op die mark is en baie installasies in Rusland het.

Vir wolkvideo-toesigstelsels is een van die akute probleme die beperkte keuse van toerusting waarmee integrasie uitgevoer kan word. Die sagteware wat verantwoordelik is om aan die wolk te koppel, word binne die videokamera geïnstalleer, wat onmiddellik ernstige eise aan sy hardeware stel – die verwerker en die hoeveelheid vrye geheue. Dit verklaar hoofsaaklik die hoër prys van wolk CCTV-kameras in vergelyking met gewone IP-kameras. Daarbenewens word 'n lang stadium van onderhandelinge met CCTV-kameravervaardigingsmaatskappye vereis om toegang tot die kameralêerstelsel en al die nodige ontwikkelingshulpmiddels te kry.

Aan die ander kant het alle moderne IP-kameras standaardprotokolle vir interaksie met ander toerusting (veral video-opnemers). Die gebruik van 'n aparte beheerder wat via 'n standaardprotokol verbind en videostrome vanaf IP-kameras na die wolk uitsaai, bied dus aansienlike mededingende voordele vir wolkvideo-toesigstelsels. Verder, as die kliënt reeds 'n video-toesigstelsel geïnstalleer het wat op eenvoudige IP-kameras gebaseer is, word dit moontlik om dit uit te brei en dit in 'n volwaardige wolk-slimhuis te verander.

Die gewildste protokol vir IP-videobewakingstelsels, wat nou sonder uitsondering deur alle IP-kameravervaardigers ondersteun word, is ONVIF-profiel S, wie se spesifikasies bestaan ​​in 'n webdienste-beskrywingstaal wsdl. Gebruik nutsprogramme uit die gereedskapstel gSOAP Dit is moontlik om bronkode te genereer vir dienste wat met IP-kameras werk:

$ 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

Gevolglik kry ons 'n stel kop-“*.h”- en bron-“*.cpp”-lêers in C++, wat direk in 'n toepassing of 'n aparte biblioteek geplaas en saamgestel kan word met die GCC-samesteller. As gevolg van die baie funksies, is die kode groot en vereis addisionele optimalisering. Die Raspberry Pi 3 model B+ mikrorekenaar het voldoende werkverrigting om hierdie kode uit te voer, maar as daar 'n behoefte is om die kode na 'n ander platform oor te dra, is dit nodig om die korrekte verwerker-argitektuur en stelselhulpbronne te kies.

IP-kameras wat die ONVIF-standaard ondersteun, wanneer hulle op 'n plaaslike netwerk werk, is gekoppel aan 'n spesiale multicast-groep met die adres 239.255.255.250. Daar is 'n protokol WS-ontdekking, wat jou toelaat om die soektog na toestelle op die plaaslike netwerk te outomatiseer.

Die grafiese koppelvlak van die slimhuisbeheerder implementeer 'n soekfunksie vir IP-kameras in PHP, wat baie gerieflik is wanneer interaksie met webdienste via XML-boodskappe is. Wanneer kieslysitems gekies word Toestelle > IP-kameras > Skandeer Die algoritme om na IP-kameras te soek word geloods, wat die resultaat in die vorm van 'n tabel vertoon:

(Klik op die prentjie om dit in hoër resolusie oop te maak)

Wanneer jy 'n kamera by die beheerder voeg, kan jy die instellings spesifiseer waarvolgens dit met die wolk sal interaksie hê. Ook in hierdie stadium word dit outomaties 'n unieke toestelidentifiseerder toegeken, waardeur dit later maklik binne die wolk geïdentifiseer kan word.

Vervolgens word 'n boodskap in JSON-formaat gegenereer wat al die parameters van die bygevoegde kamera bevat en na die bedienerproses van die slimhuisbeheerder gestuur via die RESTful API-opdrag, waar die kameraparameters gedekodeer en in die interne SQLite-databasis gestoor word, en is ook gebruik om die volgende verwerkingsdrade te begin:

1. die vestiging van 'n RTSP-verbinding om video- en oudiostrome te ontvang;
2. transkodering van oudio vanaf G.711 mu-Law, G.711 A-Law, G.723, ens. formate. na AAC-formaat;
3. transkodering van videostrome in H.264-formaat en oudio in AAC-formaat na 'n FLV-houer en oordra dit na die wolk via die RTMP-protokol;
4. die vestiging van 'n verbinding met die eindpunt van die IP-kamera bewegingsdetektor via die ONVIF-protokol en dit periodiek te stem;
5. die generering van 'n duimnaelvoorskou beeld periodiek en stuur dit na die wolk via die MQTT-protokol;
6. plaaslike opname van video- en oudiostrome in die vorm van aparte lêers in MP4-formaat op 'n SD- of flitskaart van 'n slimhuisbeheerder.

Om 'n verbinding met kameras te bewerkstellig, te transkodeer, te verwerk en videostrome in die bedienerproses op te neem, word funksies van die biblioteek gebruik FFmpeg 4.1.0.

In die prestasietoetseksperiment is 3 kameras aan die beheerder gekoppel:

1. HiWatch DS-I114W (resolusie - 720p, kompressieformaat - H.264, bitsnelheid - 1 Mb/s, klank G.711 mu-Law);
2. Microdigital MDC-M6290FTD-1 (resolusie - 1080p, kompressieformaat - H.264, bitsnelheid - 1 Mb/s, geen klank);
3. Dahua DH-IPC-HDW4231EMP-AS-0360B (resolusie - 1080p, kompressieformaat - H.264, bitsnelheid - 1.5 Mb/s, AAC-oudio).

Al drie strome is gelyktydig na die wolk uitgevoer, oudio-transkodering is vanaf slegs een kamera uitgevoer, en plaaslike argiefopname is gedeaktiveer. SVE-lading was ongeveer 5%, RAM-gebruik was 32 MB (per proses), 56 MB (totaal insluitend bedryfstelsel).

Sowat 20 - 30 kameras kan dus aan die slimhuisbeheerder gekoppel word (afhangende van resolusie en bitsnelheid), wat genoeg is vir 'n videobewakingstelsel vir 'n drieverdiepingkothuis of 'n klein pakhuis. Vir take wat groter werkverrigting vereis, kan jy 'n nettop met 'n multi-kern Intel-verwerker en Linux Debian Sarge OS gebruik. Die beheerder ondergaan tans proefwerking, en data oor sy werkverrigting sal opgedateer word.

Interaksie met die wolk

’n Wolkgebaseerde slimhuis stoor gebruikersdata (video- en sensormetings) in die wolk. Die argitektuur van wolkberging sal in meer besonderhede in die volgende artikel in ons reeks bespreek word. Kom ons praat nou oor die koppelvlak vir die oordrag van inligtingsboodskappe vanaf die slimhuisbeheerder na die wolk.

Die toestande van gekoppelde toestelle en sensormetings word via die protokol oorgedra MQTT, wat dikwels in Internet of Things-projekte gebruik word vanweë die eenvoud en energiedoeltreffendheid daarvan. MQTT gebruik 'n kliënt-bediener-model, waar kliënte inteken op spesifieke onderwerpe binne die makelaar en hul boodskappe publiseer. Die makelaar stuur boodskappe aan alle intekenare volgens reëls wat bepaal word deur die QoS (Quality of Service) vlak:

• QoS 0 - maksimum een ​​keer (geen afleweringswaarborg nie);
• QoS 1 - ten minste een keer (met afleweringsbevestiging);
• QoS 2 - presies een keer (met bykomende afleweringsbevestiging).

In ons geval gebruik ons Eclipse Muskiet. Die onderwerpnaam is die unieke identifiseerder van die slimhuisbeheerder. Die MQTT-kliënt binne die bedienerproses teken in op hierdie onderwerp en vertaal JSON-boodskappe wat van die boodskapbestuurder af kom, daarin. Omgekeerd word boodskappe van die MQTT-makelaar deur dit aangestuur na die boodskapbestuurder, wat dit dan na sy intekenare binne die bedienerproses vermenigvuldig:

Om boodskappe oor die status van die slimhuisbeheerder te stuur, word die meganisme van gestoorde boodskappe gebruik behoue ​​boodskappe MQTT protokol. Dit laat jou toe om die tydsberekening van heraansluitings tydens kragonderbrekings korrek te monitor.

Die MQTT-kliënt is ontwikkel op grond van die biblioteekimplementering Verduistering Paho in C++ taal.

H.264 + AAC-mediastrome word via die RTMP-protokol na die wolk gestuur, waar 'n groep mediabedieners verantwoordelik is vir die verwerking en berging daarvan. Om die las in die groep optimaal te versprei en die mediabediener wat die minste gelaai is te kies, rig die slimhuisbeheerder 'n voorlopige versoek aan die wolklasbalanseerder en stuur eers daarna die mediastroom.

Gevolgtrekking

Die artikel het een spesifieke implementering van 'n slimhuisbeheerder ondersoek wat gebaseer is op die Raspberry Pi 3 B+ mikrorekenaar, wat inligting kan ontvang, verwerk en toerusting kan beheer via die Z-Wave-protokol, interaksie met IP-kameras via die ONVIF-protokol kan hê, en ook data kan uitruil en opdragte met die wolkdiens via MQTT- en RTMP-protokolle. 'n Produksielogika-enjin is ontwikkel gebaseer op 'n vergelyking van logiese reëls en feite wat in JSON-formaat aangebied word.

Die slimhuisbeheerder ondergaan tans proefwerking by verskeie terreine in Moskou en die Moskou-streek.

Die volgende weergawe van die beheerder beplan om ander soorte toestelle (RF, Bluetooth, WiFi, bedraad) te koppel. Vir die gerief van gebruikers sal die prosedure vir die koppeling van sensors en IP-kameras na die mobiele toepassing oorgedra word. Daar is ook idees vir die optimalisering van die bedienerproseskode en die oordrag van die sagteware na die bedryfstelsel oopskryf. Dit sal jou toelaat om op 'n aparte beheerder te bespaar en die funksionaliteit van 'n slimhuis na 'n gewone huishoudelike router oor te dra.

Bron: will.com