Как лучше? Сенсоры по категориям или в каждую комнату?

[lanket]

Нарисовал и сверстал все сцены, базовое меню и прописал базовые алгоритмы (расписание, сценарии, климат контроль).
Наконец закончил с железными экспериментами, определился с выбором на чем будут датчики и активаторы.
Сделал рабочие прототипы, и несколько модулей (сенсоры и активаторы) уже вмонтированы.

А теперь о главном к чему этот пост.

Путь по настройке объектов, свойств и классов я оказалось выбрал не совсем обычный.
Перед уже глобальной настройкой к рабочей системе, чтобы потом не перенастраивать все заново я решил посмотреть в коннекте у Сергея как классы и объекты со свойствами организованны у ГУРУ.
И заметил что Релюхи все в классе Reley
Датчики движения и кнопки ... в классе keySensors
.....
И засомневался об эффективности/правильности пути.

Смысл в следующем:
Класс Rooms содержит обекты Комнат (это понятно и вроде как у всех)
Но свойства отличаются от того что я увидел в коннекте
У каждой комнаты есть набор св-в привязанных к датчикам и активаторам:

СпойлерПоказать

Livingroom.LatestActivity 1409838134
Livingroom.LatestActivityTime 16:42
Livingroom.SomebodyHere 1
Livingroom.Temperature 25.3
Livingroom.Humidity
влажность 42
Livingroom.Title Гостиная
Livingroom.AvgTemp
Участие в вычислении средней температуры. 1 в доме. 2 на улице. 3 температура около водопровода. 1
Livingroom.AliveTempSensor 25.3
Livingroom.OpenDoor 1
Livingroom.OpenWindow 1
Livingroom.Sunlight 33
Livingroom.LightSwitchTable 1
Livingroom.LightSwitch 1
Livingroom.LightSwitchBra 1
Livingroom.Smoke 10
Livingroom.Gas 0
Livingroom.Power 1
Livingroom.LightR 255
Livingroom.LightG 255
Livingroom.LightB 255
Livingroom.Сhandelier
Люстра 1
(linked to: mysensor)
Livingroom.LightTable
Livingroom.Bra
(linked to: mysensor)
Livingroom.OpenWindow2 1
Livingroom.OpenDoor2 1
Livingroom.OpenDoor3 1
Livingroom.SomebodyHere2

Понятно что не везде есть полный набор датчиков или активаторов.
А также если в какой-нибудь комнате есть уникальный сенсор/активатор то у этой комнаты есть персональное св-во.


Почему я пошел по этому пути?
Собственно мне показалось неудобно и громозко создавать кучу классов и объектов, по кучи раз прописывая их названия и привязки к комнатам что в свою очередь может привести к ошибкам и неудобством к обращениям. И сразу же идет стандартизация :

Livingroom.OpenDoor Дверь в гостинной
BedRoom.OpenDoor Дверь в Ванной


Может я не вижу подводного камня?
Или что то не догоняю по причине "юности" своей в МДМ?
Может у Сергея это издержки многоуровнего апдейта и это наследство древних версий системы и ему затратно переделывать все свои наработки в такое русло?
Кто-нибудь реализовывал себе по такому же принцепу?

!!!!! Ткните носом если я ошибаюсь !!!!!

[sergejey]

О чём-то подобном я тоже думал, но оставил "огород" с объектами под каждый датчик в основном для того, чтобы следить за их "здоровьем". Т.е. если я буду напрямую вносить значение в свойство комнаты, то я могу просто не заметить, что оно перестало обновляться либо мне нужно дополнительное свойство, чтобы знать последнее время обновления каждого из свойств. Поэтому я решил, что лучше пусть будут объекты датчиков со свойствами LinkedRoom. Честно говоря, та структура, которая идёт с установочным пакетом, не оптимальна, о чём уже писали в других ветках, так что не нужно к ней относиться, как к эталонной и в какой-то степени это действительно результат наслоений. По-хорошему, надо большую часть классов удалять и заново продумывать, как лучше организовать данные.

[Михаил_Калуга]

[quote="sergejey"][/quote]
Сергей, а почему Вы не реализовали возможность при добавлении свойств Классу в качестве свойств добавить другой класс?

[olehs]

Я все же пошел по пути - каждая сущность должна быть в своем классе и не зависеть от других, а взаимодействовать с ними посредством связей.
Это вполне соответсвует парадигме ООП и шаблогам программирования.

На примере температуры:
У меня есть класс Sensors. Вот его структура

sensors.png (24.59 КБ) 9200 просмотров

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

У комнаты есть свойство Температура. Но, в комнате может быть несколько сенсоров температуры.
В таком случае можно пройтись во всем сенсорам с классом TemperatureSensor, привязанным к данной комнате, посчитать среднюю температуру, и записать ее в свойство Temperature комнаты.

Кроме того, если датчики беспроводные, и я решу один из них перенести, то в системе это так же просто делается сменой одного свойства (местоположение).

То же самое с исполнительными устройствами. У меня есть класс ClimateDevices в котором живут Кондиционер, обогреватель, увлажнитель и т.д.
Алгоритм климат-контроля не привязан к конкретным объектам - он оперирует типами устройств, находящимися в помещении, в котором регулирует климат.
И если в какой-то комнате становится холодно, и я переношу туда обогреватель, нужно также сменить местоположение обогревателя в МЖД.
После этого климат-контроль точно также управляет им, но уже отталкиваясь от установленных параметров, но уже для новой комнаты.

[sergejey]

Сергей, а почему Вы не реализовали возможность при добавлении свойств Классу в качестве свойств добавить другой класс?

Если коротко, то типизацию свойств я не вводил, чтобы не усложнять систему. Была цель внести элемент базовой объектно-ориентированности, но без стремления воссоздать все возможности.

[lanket]

Ну как я понял все методы хороши.
Главное чтобы самому было удобно этим пользоваться.
Спасибо всем за комментарии.

Осмелюсь свои мысли озвучить.
Каждый экземпляр запущенного класса кушает память. Если учесть во внимание что на форуме расспространнено мнение что УД нужен не только для удобства но и для экономии. Как то обсуждали пригодность малинки для мдм, а так как первая малинка мало справлялась с этими задачами то кто то толкал идеи реализации на обычном компе. И эту идею многие приняли в штвки. Но и во второй малинке ресурсы ограничены. Если наплодить кучу классов то и памяти может уже не хватить. И каждый сенсор получается в кучи классов задествован что мне кажется может отразится и на производительности.

Каждому видней.

Я тогда попробую в своем направлении реализовать.
Если пойму что это не приемлеммо или всплывут камни то поделюсь опытом.

Просьба отозваться тех, если такие есть, кто пошел по схожему пути.

Отправлено с моего HM NOTE 1LTEW через Tapatalk

[Михаил_Калуга]

Ну как я понял все методы хороши.

Так как основу МЖД составляет база данный, то правильно комнаты к комнатам, а датчики к датчикам. В этом случае и поиск будет быстрее и нагрузка минимальной. Чем больше объектов тем ощутимее разница.
Как это проверить?
Пример.
Есть 10 автомобилей разных. 3 типа резины разной. 3 типа дисков.
Заполняем таблицу по Вашему варианту:
Столбцы в таблице
№ п/п; марка авто; резина;тип диска
1; Лада; Кама; штамповка
2; Хонда; Мишлен; литье
3;

Заполняем по моему варианту:

таблица 2 резина
№ п/п; марка резины
1; Мишлен
2; Кама

таблица 3 диски
№ п/п; марка диска
1 ; литье
2 ; штамповка

таблица 1 авто
№ п/п; марка авто; резина;тип диска
1 ; Лада ; 2 ; 2
2 ; Хонда ; 1 ; 1
в столбец марка авто пишите - марку авто
в столбец резина пишите № п/п из таблицы 2 резина
в столбец тип диска пишите № п/п из таблицы 3 диски

В моем варианте объем получится меньше. И чем больше записей тем разница будет заметнее.

[ipz]

Михаил, все правильно, но в MJM это не работает, т.к. здесь все сущности хранятся не в отдельных таблицах, а в одной и той же структуре
Если грубо: Объекты -> Свойства -> Значения

Если точнее:
Объекты -> Базовые свойства объекта класса -> Значения
Объекты -> Инивидуальные свойства экземпляра объекта -> Значения

Вроде так.

[Михаил_Калуга]

Вроде так.

Визуально устроено так http://majordomo.smartliving.ru/forum/v ... 6&start=20.
Те 4 таблицы а не одна.

[lanket]

О чём-то подобном я тоже думал, но оставил "огород" с объектами под каждый датчик в основном для того, чтобы следить за их "здоровьем". Т.е. если я буду напрямую вносить значение в свойство комнаты, то я могу просто не заметить, что оно перестало обновляться либо мне нужно дополнительное свойство, чтобы знать последнее время обновления каждого из свойств. Поэтому я решил, что лучше пусть будут объекты датчиков со свойствами LinkedRoom. Честно говоря, та структура, которая идёт с установочным пакетом, не оптимальна, о чём уже писали в других ветках, так что не нужно к ней относиться, как к эталонной и в какой-то степени это действительно результат наслоений. По-хорошему, надо большую часть классов удалять и заново продумывать, как лучше организовать данные.

Сергей, а почему Вы не реализовали возможность при добавлении свойств Классу в качестве свойств добавить другой класс?

Я думмаю Михаил_Калуга не смог донести свою мысль.
Предлогаемая/популярная схема взоимодействия МДМ с сенсорами/активаторами, далее по тексту сенсоры, режет взляд ненамылиному глазу.

Как olehs и sergejey делают
Есть Класс, или несколько классов разбитых на подкатегории, сенсоров. Где описаны все устаноленные на объекте сенсоры.
Объкты этих классов связанны ссылкой на индетификатор комнаты где он установлен и имеет как минимум одно свойство связанное в модуле-програмного моста для общения с железякой.

Режет взгляд когда пытаешься с нуля заполнить систему тот факт что приходиться одно и тоже шаблонно забивать при условии что все построенно на ООП.
Т.Е. каждый датчик имеет полную копию себеподобной записи с измененным св-вом комнаты и "id железяки"

Что пытался донести Михаил_Калуга:

Если поступить по другому. Есть разновидности сенсоров далее по тексту тип сенсора. И каждый вид сенсора имеет одни и те же характеристики, а также одни и те же методы по обработки.

Если в Классе Rooms Каждое помещение делать не объектами а классами расширяющие класс Rooms
В каждом помещении сенсоры добавлять не обеъктом или свойством а расширяешь класс помещения "клоном" класса тип сенсора

Как сделал olehs с сенсорами Sensors->StateSensors->MotionSensor http://majordomo.smartliving.ru/forum/v ... 812#p30932

Сделать Так
Rooms->LivingRoom->PirSensor

Таким образом не надо каждый сенсор одинакого типа копировать методы и св-ва такого же датчика. Создавать копии одного и того же кода да еще и во множественном числе противоречет ООП.