Моделът на данни за интелигентен дом

Умните домове са били строго в бъдещето; сега те са реалност. Повечето от нас са чували за тях, но те не са толкова разпространени, колкото ще бъдат в близко бъдеще. Управлението на вашия дом по „интелигентен“ начин определено ще произведе много данни. Днес ще анализираме модел на данни, който бихме могли да използваме за съхраняване на данни за интелигентен дом.

Моделът на данните

Когато мислите за интелигентен дом, вероятно се сещате за дистанционно заключване и отключване на дома си, за активиране на аларми, светлини или камери от телефона си, за термометри, които автоматично управляват вашето отопление и охлаждане и т.н. Но интелигентните домове могат да направят много повече. Можете да свържете множество интелигентни устройства и контролери, за да постигнете много сложни функции. Можете да изпращате инструкции до устройствата или да четете техните състояния, където и да се намирате.

Нека да разгледаме модел на данни, който би ни позволил да внедрим подобни функционалности. Върху този модел на данни бихме могли да изградим уеб приложение и мобилно приложение, което ще позволи на регистрираните потребители да администрират своите акаунти, да изпращат инструкции и да проследяват статусите.

Моделът се състои от три предметни области:

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

Ще опиша всяка от тези предметни области в реда, в който са изброени. Преди всичко друго обаче ще опиша user_account таблица.

Таблицата User_Account

Започваме с user_account таблица, защото се използва и в трите предметни области. Той съхранява списък с всички регистрирани потребители на нашето приложение.

user_account таблицата съдържа всички стандартни атрибути, които бихте очаквали, включително:

• first_name и last_name – Името и фамилията на потребителя.
• user_name – УНИКАЛНО потребителско име, избрано от потребителя.
• password – Хеш стойност на паролата на потребителя.
• email – Имейл адресът, предоставен от потребителя по време на процеса на регистрация.
• confirmation_code – Кодът, генериран по време на процеса на регистрация.
• confirmation_time – Времевата марка, когато потребителят е потвърдил акаунта си и е завършил процеса на регистрация.
• ts – Времевата марка, когато този запис е бил вмъкнат в базата данни.

Раздел 1:Имоти и устройства

Цялата мотивация зад създаването на тази база данни е да наблюдаваме какво се случва с нашите имоти (т.е. домове или имоти). Това може да са частни имоти, като апартаменти или къщи, или бизнес имоти, като офиси, складове и т.н. Ако наистина искаме да докараме системата си до краен предел, бихме могли да я използваме и за превозни средства.

Централната таблица в тази предметна област е real_estate маса. Тук ще съхраняваме всички различни имоти или имоти, свързани с нашето приложение за интелигентен дом. За всяко имущество ще съхраняваме:

• real_estate_name – Име, избрано от потребителя, което се отнася до конкретно свойство.
• user_account_id – ИД на потребителя, с който е свързано това имущество. Заедно с атрибута real_estate_name, това образува УНИКАЛНИЯ (алтернативен) ключ на тази таблица.
• real_estate_type – Означава вида на недвижимия имот, представляващ този имот.
• address – Реалният адрес на този имот. Това е нула, тъй като може да използваме тази система за други типове имоти (напр. превозни средства).
• details – Всички допълнителни подробности в текстов формат.

Вече споменахме видовете недвижими имоти. Пълен списък с възможни типове се съхранява в real_estate_type речник. Той съдържа само една УНИКАЛНА стойност, type_name . Тук можем да очакваме стойности като „апартамент“, „къща“ или „гараж“.

Едно парче недвижим имот може да бъде разделено на няколко области. Това може да са стаи на апартамент или къща; може би искаме да групираме няколко стаи заедно или искаме всичко свързано с двора или градината в една група и т.н. Или може би имаме индустриален комплекс или комплекс с няколко офиса; ако нашият имот е наистина голям, наличието на специфични площи може да бъде много полезно. За да постигнем това, ще използваме area маса. Той съдържа УНИКАЛНАТА двойка real_estate_id и area_name избран от потребителя.

Последните две таблици в тази тема са свързани с устройства.

В device_type таблица, ще съхраняваме пълен списък на всички различни типове устройства. За всеки тип ще използваме УНИКАЛНО type_name и вмъкнете допълнително description ако е необходимо. Типовете устройства могат да бъдат различни сензори (температура, газ), ключалки за врати или прозорци, светлини, климатични и отоплителни системи и др.

Сега сме готови за забавната част. Ще използваме device таблица за съхраняване на списък с всички устройства, включени в различни интелигентни домове. Тези устройства се добавят от потребителя ръчно или автоматично, ако устройството има тази опция. За всяко устройство ще трябва да съхраняваме:

• real_estate_id – Идентификационният номер на недвижимия имот, където е инсталирано това устройство.
• area_id – Препраща area където е инсталирано това устройство. Това е незадължителна стойност, тъй като имуществото може да бъде разделена на области, но също така не може да бъде разделена.
• device_type_id – Идентификационният номер на device_type това устройство принадлежи на.
• device_parameters – Ще използваме този атрибут, за да съхраняваме всички възможни параметри на устройството (напр. интервали за съхранение на данни) в структуриран текстов формат. Тези параметри могат да бъдат зададени от потребителя или част от нормалната функция на устройството (напр. различни мерки).
• current_status – Текущото състояние на параметрите на устройството.
• time_activated и time_deactivated – Определете интервала, когато това устройство е било активно. Ако time_deactivated не е зададено, тогава устройството е активно и is_active атрибутът също е настроен на True.

Раздел 2:Потребители и профили

Вече споменахме user_account маса. В нашето приложение потребителите трябва да могат да създават различни профили и да ги споделят с други потребители, ако искат.

Профилите са основно подмножества от устройства, инсталирани във всяка част от недвижим имот, собственост на потребителя. Всеки потребител може да има един или повече профили. Идеята е да се даде възможност на потребителя да групира своите интелигентни домашни устройства по подходящ начин. Докато потребителят може да има един профил с всичките си устройства, той също може да има един профил, показващ само камерите на предната врата за всичките им имоти. Или може би един профил само за термометрите, монтирани във всички стаи на апартамента им.

Всички създадени от потребителите профили се съхраняват в profile маса. За всеки запис ще имаме:

• profile_name – Име на профила, избрано от потребителя.
• user_account_id – Препраща към потребителя, създал този профил. Този атрибут и profile_name атрибут формира УНИКАЛНИЯ ключ на таблицата.
• allow_others – Флаг, обозначаващ дали този профил е споделен с други потребители.
• is_public – Флаг, обозначаващ дали този профил е видим публично. Въпреки че можем да очакваме, че това ще бъде зададено на False през повечето време, може да има случаи, когато искаме да споделим профил с всички.
• is_active – Флаг, обозначаващ дали този профил е активен или не.
• ts – Отпечатък за дата, когато този запис е бил вмъкнат.

За всеки профил ще дефинираме списък с всички устройства, включени в него. Този списък се съхранява в profile_device_list таблица и съдържа списък с УНИКАЛЕН profile_id – device_id двойки. Тази двойка външни ключове формира първичния ключ на нашата таблица.

Последната таблица в тази тема позволява на потребителите да споделят своите профили с други регистрирани потребители. Това може да бъде много полезно, напр. ако едно лице управлява всичко и други регистрирани потребители (например членове на семейството) искат да видят профили, създадени от собственика. В shared_with таблица, ще съхраняваме списък с всички УНИКАЛНИ двойки profile_id – user_account_id . Още веднъж, тази двойка външни ключове е първичният ключ на таблицата. Моля, имайте предвид, че споделянето ще работи само ако profile.allow_others атрибутът е настроен на True.

Раздел 3:Команди и данни

Ще използваме таблици от тази последна тематична област, за да съхраняваме комуникациите между потребители и устройства. Това ще бъде двупосочна комуникация. Устройствата ще генерират данните по време на своите операции и нашата база данни ще ги съхранява, както и всички съобщения, генерирани от системата (или устройствата). Потребителите ще искат да видят тези съобщения и данните, изпратени от техните устройства. Въз основа на тези данни потребителите могат да създават програми за своя умен дом. Тези програми са ръчно или автоматично генерирани команди или дори поредица от команди, които ще направят точно това, което всеки потребител иска.

Ще започнем с данните, които ни дават устройствата. В device_data таблица, ще съхраняваме описание на генерираните от устройството данни и местоположението(ята) на данните. Отново данните се генерират автоматично от устройствата. Това може да бъде поредица от измервания, състояния (текстови данни) или аудио-визуални данни. За всеки запис в тази таблица ще съхраняваме:

• device_id – Идентификационният номер на устройството, генерирало тези данни.
• data_description – Описанието на съхранените данни, напр. какво се съхранява, кога данните са били съхранени в нашата система и в какъв формат.
• data_location – Пълният път до мястото, където се съхраняват тези данни.
• ts – клеймото за време, когато този запис е бил вмъкнат.

Данните за устройството ще се съхраняват независимо дали устройството функционира правилно или ако данните са извън очаквания диапазон. Това е основно дневник на всичко, което е записано от устройствата. Можем да очакваме да имаме стратегия за изтриване на стари файлове с данни на устройството, но това е извън обхвата на тази статия.

За разлика от данните за устройството, можем да очакваме, че съобщенията ще се генерират само когато се случи нещо неочаквано – напр. ако измерването на устройството е извън нормалния диапазон, ако сензорът е открил движение и т.н. В такива случаи устройството генерира съобщенията. Всички такива съобщения се съхраняват в auto_message маса. Във всеки запис ще имаме:

• device_id – Идентификационният номер на устройството, генерирало това съобщение.
• message_text – Текстът, генериран от устройството. Това може да бъде предварително дефиниран текст, стойност, която е извън очаквания диапазон или комбинация от тези две.
• ts – Отпечатък за време, кога е съхранен този запис.
• read – Флаг, обозначаващ дали съобщението е било прочетено от потребителя.

Останалите три таблици се използват за съхранение на команди на потребителите. Командите позволяват на потребителите да поемат контрола над своите контролируеми устройства и да установят двупосочна комуникация със своя интелигентен дом.

Първо, ще дефинираме списък с всички възможни типове команди. Това може да са стойности като “включване/изключване”, “увеличаване/намаляване на температурата” и т.н. Можем да имаме и условни команди, т.е. команди, които се изпълняват само ако определено условие е вярно. Списък с всички различни типове команди се съхранява в command_type речник. За всеки тип ще съхраняваме УНИКАЛНО type_name . Ние също така ще съхраняваме списък с всички параметри, които трябва да бъдат дефинирани за този тип команда. Това ще бъде в структуриран текстов формат с вмъкнати стойности по подразбиране. Потребителят ще зададе тези стойности, когато вмъква новите си команди.

Потребителят може също да дефинира всички recurring_commands отпред. Може би искаме топла вода всеки ден в 7 сутринта или да активираме системата за отопление/охлаждане всеки ден в 16 часа. Наборът от правила и всички необходими атрибути за извършване на повтарящи се команди се съхраняват в тази таблица. Ще имаме:

• user_account_id – ИД на потребителя, който е вмъкнал тази повтаряща се команда.
• device_id – Идентификационният номер на устройството, свързано с тази повтаряща се команда.
• command_type_id – Препратка към command_type речник.
• parameters – Всички параметри, които трябва да бъдат дефинирани за този тип команда, заедно с техните желани стойности.
• interval_definition – Интервалът между две повторения на тази команда. Както при командните параметри, това ще бъде структурирано текстово поле.
• active_from и active_to – Интервалът, през който тази команда трябва да се повтори. active_to атрибутът може да бъде NULL, ако искаме тази команда да се повтаря завинаги (или докато не дефинираме active_to дата).
• ts – клеймото за време, когато този запис е бил вмъкнат.

Последната таблица в нашия модел съдържа списък с единични команди. Тези команди могат да бъдат въведени ръчно от потребителя или генерирани автоматично (т.е. като част от повтарящи се команди). За всяка команда ще съхраняваме:

• recurring_command_id – Идентификационният номер на повтарящата се команда, задействаща тази команда, ако има такава.
• user_account_id – ИД на потребителя, който е вмъкнал тази команда.
• device_id – Идентификационният номер на съответното устройство.
• command_type_id – Препраща command_type речник.
• parameters – Всички параметри, свързани с тази команда.
• executed – Флаг, обозначаващ дали тази команда е била изпълнена.
• ts – клеймото за време, когато този запис е бил вмъкнат.

Какво мислите за модела на данни за интелигентен дом?

В тази статия се опитахме да покрием най-важните аспекти на управлението на интелигентен дом. Едно от тях определено е двупосочната комуникация между потребителя и системата. Повечето „реални“ действия се съхраняват като текстови параметри и тези стойности трябва да бъдат анализирани при извършване на конкретни действия. Това беше направено, за да можем да имаме достатъчно гъвкавост, за да работим с много различни типове устройства.

Имате ли някакви предложения да добавите към нашия модел умен дом? Какво бихте променили или премахнали? Моля, кажете ни в коментарите по-долу.