Datový model chytré domácnosti

Chytré domy bývaly striktně v budoucnosti; nyní jsou realitou. Většina z nás o nich slyšela, ale nejsou tak rozšířené, jak budou v blízké budoucnosti. Správa vašeho domova „inteligentním“ způsobem určitě vyprodukuje spoustu dat. Dnes budeme analyzovat datový model, který bychom mohli použít k ukládání dat chytré domácnosti.

Datový model

Když pomyslíte na chytrou domácnost, pravděpodobně vás napadne zamykání a odemykání vašeho domova na dálku, aktivace alarmů, světel nebo kamer z vašeho telefonu, teploměry, které automaticky řídí vaše vytápění a chlazení atd. Chytré domy ale umí mnohem víc. Můžete připojit řadu chytrých zařízení a ovladačů a dosáhnout tak mnoha komplexních funkcí. Můžete posílat pokyny zařízením nebo číst jejich stav, ať jste kdekoli.

Pojďme se podívat na datový model, který by nám umožnil implementovat takové funkce. Kromě tohoto datového modelu bychom mohli vytvořit webovou aplikaci a mobilní aplikaci, která by registrovaným uživatelům umožnila spravovat jejich účty, posílat pokyny a sledovat stavy.

Model se skládá ze tří tematických oblastí:

• Estates & devices
• Users & profiles
• Commands & data

Popíšu každou z těchto oblastí v pořadí, v jakém jsou uvedeny. Před čímkoli jiným však popíšu user_account tabulka.

Tabulka uživatelských účtů

Začínáme s user_account tabulka, protože se používá ve všech třech tematických oblastech. Uchovává seznam všech registrovaných uživatelů naší aplikace.

user_account tabulka obsahuje všechny standardní atributy, které byste očekávali, včetně:

• first_name a last_name – Jméno a příjmení uživatele.
• user_name – JEDINEČNÉ uživatelské jméno zvolené uživatelem.
• password – Hodnota hash hesla uživatele.
• email – E-mailová adresa poskytnutá uživatelem během procesu registrace.
• confirmation_code – Kód vygenerovaný během procesu registrace.
• confirmation_time – Časové razítko, kdy uživatel potvrdil svůj účet a dokončil proces registrace.
• ts – Časové razítko, kdy byl tento záznam vložen do databáze.

Část 1:Majetky a zařízení

Celá motivace za vytvořením této databáze je sledovat, co se děje s našimi nemovitostmi (tj. domy nebo nemovitosti). Mohou to být soukromé pozemky, jako jsou byty nebo domy, nebo to mohou být obchodní nemovitosti, jako jsou kanceláře, sklady atd. Pokud chceme náš systém skutečně dotáhnout na hranici možností, mohli bychom jej použít i pro vozidla.

Centrální tabulka v této oblasti je real_estate stůl. Zde budeme ukládat všechny různé nemovitosti nebo nemovitosti spojené s naší aplikací pro chytrou domácnost. Pro každou nemovitost uložíme:

• real_estate_name – Uživatelem zvolený název, který odkazuje na konkrétní vlastnost.
• user_account_id – ID uživatele, ke kterému se tato nemovitost vztahuje. Společně s atributem real_estate_name tvoří UNIQUE (alternativní) klíč této tabulky.
• real_estate_type – Označuje typ nemovitosti, o kterou nemovitost jde.
• address – Skutečná adresa tohoto majetku. Toto je nulovatelné, protože tento systém můžeme použít pro jiné typy majetku (tj. vozidla).
• details – Všechny další podrobnosti v textovém formátu.

Již jsme zmínili typy nemovitostí. Kompletní seznam možných typů je uložen v real_estate_type slovník. Obsahuje pouze jednu UNIQUE hodnotu, type_name . Zde bychom mohli očekávat hodnoty jako „byt“, „dům“ nebo „garáž“.

Jednu nemovitost lze rozdělit do více oblastí. Mohou to být místnosti bytu nebo domu; možná chceme seskupit několik místností nebo chceme vše, co souvisí se dvorem či zahradou, do jedné skupiny atd. Nebo možná máme průmyslový areál nebo areál s několika kancelářemi; pokud je naše nemovitost opravdu velká, může být velmi užitečné mít konkrétní oblasti. Abychom toho dosáhli, použijeme area stůl. Obsahuje UNIKÁTNÍ pár real_estate_id a area_name zvolené uživatelem.

Poslední dvě tabulky v této oblasti se týkají zařízení.

V device_type tabulky, uložíme kompletní seznam všech různých typů zařízení. Pro každý typ použijeme UNIKÁTNÍ type_name a vložte další description V případě potřeby. Typy zařízení mohou být různé senzory (teplota, plyn), dveřní nebo okenní zámky, světla, klimatizační a topné systémy atd.

Nyní jsme připraveni na zábavnou část. Použijeme device tabulka pro uložení seznamu všech zařízení obsažených v různých chytrých domácnostech. Tato zařízení přidává uživatel buď ručně, nebo automaticky, pokud má zařízení tuto možnost. Pro každé zařízení budeme muset uložit:

• real_estate_id – ID nemovitosti, kde je toto zařízení nainstalováno.
• area_id – Odkazuje na area kde je toto zařízení nainstalováno. Toto je volitelná hodnota, protože nemovitost mohla být rozdělena do oblastí, ale také nemusí být rozdělena.
• device_type_id – ID device_type toto zařízení patří.
• device_parameters – Tento atribut použijeme k uložení všech možných parametrů zařízení (např. intervalů pro ukládání dat) ve strukturovaném textovém formátu. Tyto parametry může nastavit uživatel nebo součást běžné funkce zařízení (např. různé míry).
• current_status – Aktuální stav parametrů zařízení.
• time_activated a time_deactivated – Označte interval, kdy bylo toto zařízení aktivní. Pokud time_deactivated není nastaveno, pak je zařízení aktivní a is_active atribut je také nastaven na hodnotu True.

Část 2:Uživatelé a profily

Již jsme zmínili user_account stůl. V naší aplikaci by uživatelé měli mít možnost vytvářet různé profily a sdílet je s ostatními uživateli, pokud chtějí.

Profily jsou v podstatě podmnožiny zařízení nainstalovaných v každé nemovitosti vlastněné uživatelem. Každý uživatel může mít jeden nebo více profilů. Cílem je umožnit uživateli seskupovat svá zařízení pro chytrou domácnost vhodným způsobem. Zatímco uživatel mohl mít jeden profil se všemi svými zařízeními, mohl mít také jeden profil zobrazující pouze přední kamery pro všechny jejich vlastnosti. Nebo možná jeden profil jen pro teploměry instalované ve všech místnostech jejich bytu.

Všechny profily vytvořené uživateli jsou uloženy v profile stůl. Pro každý záznam budeme mít:

• profile_name – Jméno profilu zvolené uživatelem.
• user_account_id – Odkazuje na uživatele, který vytvořil tento profil. Tento atribut a profile_name atribut tvoří UNIKÁTNÍ klíč tabulky.
• allow_others – Příznak označující, zda je tento profil sdílen s ostatními uživateli.
• is_public – Příznak označující, zda je tento profil veřejně viditelný. I když můžeme očekávat, že to bude většinu času nastaveno na False, mohou nastat případy, kdy chceme sdílet profil se všemi.
• is_active – Příznak označující, zda je tento profil aktivní či nikoli.
• ts – Časové razítko, kdy byl tento záznam vložen.

Pro každý profil definujeme seznam všech zařízení, která jsou v něm obsažena. Tento seznam je uložen v profile_device_list a obsahuje seznam UNIKÁTNÍCH profile_id – device_id páry. Tento pár cizích klíčů tvoří primární klíč naší tabulky.

Poslední tabulka v tomto předmětu umožňuje uživatelům sdílet své profily s ostatními registrovanými uživateli. To by mohlo být velmi užitečné, např. pokud vše spravuje jedna osoba a ostatní registrovaní uživatelé (např. členové rodiny) chtějí prohlížet profily vytvořené vlastníkem. V shared_with tabulky, uložíme seznam všech UNIKÁTNÍCH párů profile_id – user_account_id . Tento pár cizích klíčů je opět primárním klíčem tabulky. Upozorňujeme, že sdílení bude fungovat pouze v případě, že profile.allow_others atribut je nastaven na hodnotu True.

Část 3:Příkazy a data

K ukládání komunikace mezi uživateli a zařízeními použijeme tabulky z této poslední tematické oblasti. Půjde o obousměrnou komunikaci. Zařízení budou během své činnosti generovat data a naše databáze je bude ukládat, stejně jako všechny zprávy generované systémem (nebo zařízeními). Uživatelé budou chtít vidět tyto zprávy a data odesílaná jejich zařízeními. Na základě těchto dat by uživatelé mohli vytvářet programy pro svůj chytrý dům. Tyto programy jsou ručně nebo automaticky generované příkazy nebo dokonce série příkazů, které udělají přesně to, co každý uživatel chce.

Začneme datovými zařízeními, která nám poskytují. V device_data tabulky, uložíme popis dat generovaných zařízením a umístění dat. Data jsou opět automaticky generována zařízeními. Může to být řada měření, stavy (textová data) nebo audiovizuální data. Pro každý záznam v této tabulce uložíme:

• device_id – ID zařízení, které vygenerovalo tato data.
• data_description – Popis uložených dat, např. co se ukládá, kdy byla data uložena v našem systému a v jakém formátu.
• data_location – Úplná cesta k umístění, kde jsou tato data uložena.
• ts – Časové razítko, kdy byl tento záznam vložen.

Data zařízení budou uložena bez ohledu na to, zda zařízení funguje správně nebo zda jsou data mimo očekávaný rozsah. Toto je v podstatě protokol všeho, co zařízení zaznamenalo. Můžeme očekávat, že budeme mít strategii pro mazání starých datových souborů zařízení, ale to je mimo rozsah tohoto článku.

Na rozdíl od dat zařízení můžeme očekávat, že zprávy budou generovány pouze tehdy, když se stane něco neočekávaného – např. pokud je měření zařízení mimo normální rozsah, pokud senzor detekoval pohyb atd. V takových případech zařízení generuje zprávy. Všechny takové zprávy jsou uloženy v auto_message stůl. V každém záznamu budeme mít:

• device_id – ID zařízení, které vygenerovalo tuto zprávu.
• message_text – Text generovaný zařízením. Může se jednat o předdefinovaný text, hodnotu, která je mimo očekávaný rozsah, nebo o kombinaci těchto dvou.
• ts – Časové razítko, kdy byl tento záznam uložen.
• read – Příznak označující, zda byla zpráva přečtena uživatelem.

Zbývající tři tabulky slouží k ukládání uživatelských příkazů. Příkazy umožňují uživatelům převzít kontrolu nad svými ovladatelnými zařízeními a navázat obousměrnou komunikaci s jejich chytrým domem.

Nejprve definujeme seznam všech možných typů příkazů. Mohou to být hodnoty jako „zapnout/vypnout“, „zvýšit/snížit teplotu“ atd. Mohli bychom mít i podmíněné příkazy, tzn. příkazy, které jsou splněny pouze tehdy, je-li splněna určitá podmínka. Seznam všech různých typů příkazů je uložen v command_type slovník. Pro každý typ uložíme UNIKÁTNÍ type_name . Uložíme také seznam všech parametrů, které by měly být pro daný typ příkazu definovány. To bude ve formátu strukturovaného textu s vloženými výchozími hodnotami. Uživatel nastaví tyto hodnoty při vkládání svých nových příkazů.

Uživatel může také definovat všechny recurring_commands vpředu. Možná chceme teplou vodu každý den v 7:00 nebo aktivovat systém vytápění/chlazení každý den v 16:00. Sada pravidel a všechny potřebné atributy pro provádění opakujících se příkazů jsou uloženy v této tabulce. Budeme mít:

• user_account_id – ID uživatele, který vložil tento opakující se příkaz.
• device_id – ID zařízení relevantního pro tento opakující se příkaz.
• command_type_id – Odkaz na command_type slovník.
• parameters – Všechny parametry, které by měly být definovány pro daný typ příkazu, spolu s jejich požadovanými hodnotami.
• interval_definition – Interval mezi dvěma opakováními tohoto příkazu. Stejně jako u parametrů příkazu se bude jednat o strukturované textové pole.
• active_from a active_to – Interval, během kterého se má tento příkaz opakovat. active_to atribut může být NULL, pokud chceme, aby se tento příkaz opakoval navždy (nebo dokud nedefinujeme active_to datum).
• ts – Časové razítko, kdy byl tento záznam vložen.

Poslední tabulka v našem modelu obsahuje seznam jednotlivých příkazů. Tyto příkazy mohou být vkládány ručně uživatelem nebo generovány automaticky (tj. jako součást opakujících se příkazů). Pro každý příkaz uložíme:

• recurring_command_id – ID opakovaného příkazu spouštějícího tento příkaz, pokud existuje.
• user_account_id – ID uživatele, který vložil tento příkaz.
• device_id – ID příslušného zařízení.
• command_type_id – Odkazuje na command_type slovník.
• parameters – Všechny parametry relevantní pro tento příkaz.
• executed – Příznak označující, zda byl tento příkaz proveden.
• ts – Časové razítko, kdy byl tento záznam vložen.

Co si myslíte o datovém modelu chytré domácnosti?

V tomto článku jsme se pokusili pokrýt nejdůležitější aspekty správy chytré domácnosti. Jedním z nich je určitě obousměrná komunikace mezi uživatelem a systémem. Většina „skutečných“ akcí je uložena jako textové parametry a tyto hodnoty by měly být analyzovány při provádění konkrétních akcí. To bylo provedeno proto, abychom měli dostatečnou flexibilitu pro práci s mnoha různými typy zařízení.

Máte nějaké návrhy na přidání do našeho modelu chytré domácnosti? Co byste změnili nebo odstranili? Řekněte nám to prosím v komentářích níže.