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

[ErmolenkoM]

Или меня что-то не в ту степь понесло?

1. Множественное наследование - ЗЛО. Без него всегда можно обойтись.
2. Структуру объектов МажорДоМо следует рассматривать как каталог с папками и файлами. Просто - удобная система организации контента.
3. Не нужно путать свойства объекта и тип объекта.

[lanket]

Можно все. Но и приверженец процедурного программирования не понимая ооп тоже будет говорить что ооп это зло. Ведь и в процедурном можно тоже реализовать этот проект.
Будет может громозкее, более запутанно и сложнее будет расширить. А еще лучше сразу на ассемблере написать. Потеряем кучу народу которые не смогут расширить функционал. Зато быстродействия....

По делу:

Так как я только приблизился к прописыванию сенсоров в систему посмотрев свежим взглядом на организацию взаимодействия мдм с сенсорами не приживается в уме один факт.

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

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

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

Для этого в объекте есть как минимум одно св-во для связи с модулем/шлюзом. Итого создали объект LivingroomTemp со св-вом для связи со шлюзом Temp. В шлюзе для создания связи из списка выбираем обект и св-во. Но так как объектов великое множество пользуемся удобным быстропоиском введа первые буквы Livingr св-в обычно немного поэтому просто выбирам из списка.
В св-ве linkedRoom прописываем вручную название объекта комнаты Livingroom.
Подитог: Temp ввели вручную 2 раза Livingroom 3 раза. Ткнули мышкой в выпадающем меню 2 раза.

Что было вчера:
Прикрутил блок реле на 16 каналов для управления света 1 го этажа и 6 каналов силовово рэле на mysensors .
И первый готовый модуль на лестницу состоящий из 6 датчиков: Фоторезистор, температура, влажность, открыта ли дверь, датчик движения, датчик дыма.

Итого
Underfloor я ввел вручную 22 реле * 3 раза на каждую 66 раз. Light/Reley/Power/Socket введено сумарно 22*2= 44 раза
Дотыкался мышкой точно в пункт 22*2=44 раза
Аналогично с блоком датчиков с лестницы только с другими названиями. 6*2=12 тыканий. 6*(3+2)=30 вводов названий вручную.

В результате
На лестнице еще будут активаторы, а в подвале еще и куча датчиков так как там техпомещение.
А помимо этого есть еще куча комнат да еще и улица.

Другими словами подключив всего на половину 2 помещения я ввел вручную 140 раз названия св-в/объектов. И ткнул мышкой в пункт выпадающего меню 56 раз. К слову яндекс понижает показатель юзабилити сайтам у которых выпадающее меню считая это крайненеудобным. В нашем случае увеличивает шанс ошибочного выбора приводящего к глюкам.

Если учесть человечиский фактор то лекго допустить мысль что при таком уже объеме можно допустить ошибку. Что выльется потом отловом глюков.
И это далеко не конец.

Учитывая что при таком популярном в этой экосистеме подходе все занимаются этой ручной работой создавая по сути матрицу удивляюсь что никого не волнует.
Да-да, по сути это матрица или сводная таблица с одной стороны это модуль-шлюз с другой это комнаты и с третей это типы сенсоров. Почти верно утверждение что все три цифры перемнаживаются и мы получаем кол-во объектов и для каждого надо по три раза написать вручную название комнаты по два раза название датчика и по два раза.

Если предположить что среднестатистический частный дом площадь 130 кв.м имеет помещения котельная, гостинная, кухня, 2 спальни. Улицу посчитаем как еще комната так как там тоже есть чем управлять и снимать показания.
Итого 6 мест установки сенсоров/активаторов.
Примерный набор из рязряда популярных , по моему мнению, хотелок:
Датчик освещенности
Датсик движения
Датчик открывания двери
Датчик открывания Окна
Датчик температуры и влажности.
Датчик дыма
Реле люстры
Реле бра

Понятно что не везде бра но и может окна не быть или не надо но гдето может быть и доп сенсоры и активаторы.

Итого получаем картину:
6 мест установки по 8 сенсоров в каждый получаем 48 объектов и каждый объект нам надо по 5 раз вручную прописать имя комнаты/тип датчика и по 2 раза попать в выпадающее меню.

В сумме среднестатистический дом прописать сенсоры надо:
240 раз вручную написать английские слова.
И 96 раз ткнуть не промазав мышкой в нужный пунк выпадающего меню.

Не смущает такое в ооп. Как то вразрез концепции ооп.

Как вариант если в я всетаки заблуждаюсь и по другому никак.

То хотябы можно сделать следующее облегчив внедрение системы новичкам и инсталяторам :

1 Создается класс, при желании с подклассами, где будут шаблоны объектов со свойствами всех типов сенсоров/активаторов для копирования.


2 Отдельный модуль в котором выбираем верхний уровень класса шаблонов и верхний уровень класса комнат а также верхний уровень класса где будут будующие объекты.
Нажимаем кнопку сгенерить.
Получаем страничку где перечисленны все пересечения типов сенсоров с комнатами. Например в виде таблицы. Где строки это комнаты а столбцы это сенсоры.
В пересечениях столбцов и строк галочки. Которые выбранны те сгенерятся копии.
Ну и конечно кнопки сбросить/отметить все. Ну и можно возле каждого столбца/строки кнопку снять/отметить столбец/строчку.

Имена новых объектов создаются путем слияния имени комнаты с именем шаблона сенсора. Это думаю и так понятно.

Вручную останеться только в модуле-шлюзе общения с железяками связать с полученными св-вами объектов. Это думаю врятли получиться автоматизировать. Хотя если доработать модули...

3 другой вариант думаю дополняющий чем заменяющий.
Пункт 1 остается. В модулях-шлюзах общения с железяками помимо кнопки связать со свойством объекта. Добавить кнопочку, "создать обработчик" например, по которой в появившемлся окне выбираем объект комнаты и обект-шаблонСенсора и класс где создать клона. Ну и кнопка создать собственно.

Надеюсь такое реализуете и таким образом облегчити жизь всем новичкам и интеграторам.

Я бы сам попробывал бы. Но у меня очень мало практики. Особенно в ооп.

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

[lanket]

Спасибо за такую развёрнутую рекомендацию. Суть проблемы вроде бы понял, подумаю над решением с учётом предложенных вариантов. Мне не приходилось сразу создавать такое большое количество объектов и связей с "нуля", так что имеющихся средств обычно хватало, чтобы не запутаться. Разве что была добавлена возможность создавать объект прямо из контрола ввода -- в поле выбора связанного объекта есть пункт Добавить в самом низу.

[ErmolenkoM]

Суть проблемы вроде бы понял, подумаю над решением с учётом предложенных вариантов. Мне не приходилось сразу создавать такое большое количество объектов и связей с "нуля", так что имеющихся средств обычно хватало, чтобы не запутаться.

Тиражированию объектов. Думаю что это нужно в ооочень редких случаях, и очень не многим.
Поэтому лучше, если бы это было _отдельным_ модулем в маркете, дабы не загромождать существующий функционал.

[lanket]

Суть проблемы вроде бы понял, подумаю над решением с учётом предложенных вариантов. Мне не приходилось сразу создавать такое большое количество объектов и связей с "нуля", так что имеющихся средств обычно хватало, чтобы не запутаться.

Тиражированию объектов. Думаю что это нужно в ооочень редких случаях, и очень не многим.
Поэтому лучше, если бы это было _отдельным_ модулем в маркете, дабы не загромождать существующий функционал.

Согласен про отдельно, чтобы тот кто не разобрался до конца не наплодил а потом в каше не потеря лся.

А редко это при развертывании системы с нуля и понимающим.

В первую очередь это очень пригодилось бы тем кто работает по разработки и установке уд клиентам.
Это сильно сэкономило бы им время.
И стало бы аргументом для выбора в сторону мдм.
Я гдето на форуме видел что такие есть.
Чем больше таких тем лучше будет развитие мдм. Тем больше функционала получу я и остальные пользователи мдм.

К слову. Я понял что всетаки сенсоры должны быть отдельно от комнат а не в с оставе. Так правильнее. Хот я бы потому что хлеб это еда а холодильник это быт. Техника.

Малоли кому интересно будет в коннекте все буду публиковать.
Пока там мало чего есть. Только "скелет" из классов и те сенсоры с реле которые описал ранее. Времени мало.

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

[ErmolenkoM]

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

Нет.
Инсталятор никогда ничего не делает с нуля. Только домашние заготовки. Поэтому у инсталятора уже есть разные примеры классов с объектами на все случаи жизни - экспорт и импорт клиенту. Все.

[lanket]

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

Нет.
Инсталятор никогда ничего не делает с нуля. Только домашние заготовки. Поэтому у инсталятора уже есть разные примеры классов с объектами на все случаи жизни - экспорт и импорт клиенту. Все.

Позвольте не согласиться.

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

Во вторых все равно импорт сократит только часть ручной работы так как в импорте сохраниться только название структура и только одна настройка LinketRoom а остальные св-ва, могу ошибаться, привязываются к id класса объекта и придется опять с выпадающими меню тыкаться прописывая большую часть названия для быстрого поиска.

В третьих когда появляются новые помещения например спальня10 или подвал3 то ее опять ручками. Теряется гибкость.

В четвертых что делать новым инстоляторам? С нуля набивать 300-500 вариантов пересечений типов датчиков с кол-вом комнат. А представьте обект например миниотель с 50 номерами. Так его ручками будешь месяц прописывать.
новый инсталятор получается да плюнет на эту затею.

В пятых, не уверен, завтра что то координально поменяется в мдм и ваши 300 шаблонов в топку. И заново вручную.

Ооп для таких задач и предназначен. Масштабируемость это его главное преимущество.

Так же у пхп в ооп есть полезная штука автоматическое развертывание проекта. в двух словах : Это когда есть скелет-шаблон программы а итоговый результат кода генериться из прописанных условий. То что я описывал это просто та малая часть возможностей пхп в ооп.

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

[sergejey]

Во вторых все равно импорт сократит только часть ручной работы так как в импорте сохраниться только название структура и только одна настройка LinketRoom а остальные св-ва, могу ошибаться, привязываются к id класса объекта и придется опять с выпадающими меню тыкаться прописывая большую часть названия для быстрого поиска.

Это прокомментирую -- при импорте/экспорте значения свойств не переносятся, только структура (включая наследование) и код методов. Ну и заодно -- там, где используется контрол выбора связанного объекта/свойства, там нет привязки к id, т.е. во всех таких местах сохраняется текстовое имя объекта и свойства.

[ErmolenkoM]

Позвольте не согласиться.

Ваше право. Сейчас смотрю на свою программу над которой работаю по работе: сотни форм, тысячи объектов, миллионы записей в базе Oracle.
Каждую крупичку информации оператор завел вручную. Не по тому что программист поленился сделать "матричный размножитель" или не знает ООП. Поверьте - знает.
Каждая крупичка информации (свойство, объект, ...) уникальна и неповторима. Она не может быть получена на основании имеющихся данных. А если и была получена от родителя информации, то может быть изменена и дальше живет своей жизнью. Эх, что-то я не о том. 3-я нормальная форма она и в акцессе 3-я НФ.

Вернемся к Алисе.
То, что вы предлагаете - очень хорошо и здорово. Но. Этим никто не сможет пользоваться. Ибо - не нужно. Покажите мне коннект с настолько единообразными объектами, что бы их получить перемножением классов. Нет? Так что это только теория.

Поймите, я не против сделать проект лучше. НО! Вы заказываете сложную разработку, на мой взгляд, бесполезного функционала. Время sergejey можно потратить с большей пользой (надеюсь sergejey не обидится за мой таймменеджемент ).

Ооп для таких задач и предназначен. Масштабируемость это его главное преимущество.

Неа. ООП и маштабируемость не связаны никак.

[lanket]

Сначало с положительных эмоций.

Вернемся к Алисе.
То, что вы предлагаете - очень хорошо и здорово. Но. Этим никто не сможет пользоваться. Ибо - не нужно. Покажите мне коннект с настолько единообразными объектами, что бы их получить перемножением классов. Нет? Так что это только теория.

Поймите, я не против сделать проект лучше. НО! Вы заказываете сложную разработку, на мой взгляд, бесполезного функционала. Время sergejey можно потратить с большей пользой (надеюсь sergejey не обидится за мой таймменеджемент ).

Согласен с Вами что в случае если Вы правы то тратить время Сергея на разработку бесполезного функционала некрасиво. Пусть это время лучше будет на благо общества а не чьито бредни, я имею себя ввиду в случе если Вы правы.

Поверьте все то что я написал и пытался донести не ради своих амбиций или целий, а тоже ради этого проекта который мне так пришол по душе.
Факт хотябы в том что если такой модуль появиться, я уже успею все вручную набить и собственно лично мне уже не нужно будет.

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

... сотни форм, тысячи объектов, миллионы записей в базе Oracle.
Каждую крупичку информации оператор завел вручную. Не по тому что программист поленился сделать "матричный размножитель" или не знает ООП. Поверьте - знает.
Каждая крупичка информации (свойство, объект, ...) уникальна и неповторима. Она не может быть получена на основании имеющихся данных. А если и была получена от родителя информации, то может быть изменена и дальше живет своей жизнью. Эх, что-то я не о том. 3-я нормальная форма она и в акцессе 3-я НФ.

Я уважаю Ваш опыт в программировании. Он намного больше чем мой, исходя из сказанного Вами. И я допускаю мысль что я в чем то заблуждаюсь.

Но хотел бы всетаки акцентировать Ваше внимание на МДМ не как целиковый продукт, а на конкретную часть его. А именно на добавление датчиков и активаторов.

Во первых каждый програмный продукт может быть похож чемто на другой и по своему или целиком уникален.
Во вторых есть разные, и в том числе в ООП PHP, разные стили и подходы к программированию.
В третьих Вы совершенно правы что как в Вашей программе так и в МДМ куча классов прописанных руками а не генераторами и путем клонирования. И каждый класс по своему уникален и живет своей жизнью.

Но речь идет о переделки всего програмного продукта а токль об меленькой, с моей точки зрения, опции. Почему маленькой: я посмотрел файл с классом добавления и выводом в админке классов и объектов. Там не так много кода, из чего сделал выводы что часть задачи уже написанно, надо только дополнить функционал, и одну лишь страничку где галочки кого с кем скрестить. Но это мой не такой опытный взгляд как Ваш, не настаиваю на 100% верности моего мнения. У меня и в правду мало опыта в программированиии, так любитель. Ну и есть свой програмный продукт, узконаправленный. Я там выступал как заказчик и руководитель проекта. А весь код писал "наемник". Но это по работе. А МДМ для души и для дома.

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

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

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

Объекты класса inhouseMovementSensors:
sensorMovement11 - Датчик движения в мастерской
sensorMovement10 - Датчик движения на кухне
sensorMovement9 - Датчик на веранде
Методы объекта:
statusChanged
sensorMovement8 - Rf датчик в гараже
Методы объекта:
statusChanged
sensorMovement7 - Датчик в зале (область гостиной)
sensorMovement6 - Датчик движения в топочной
sensorKey1 - Датчик открытия двери в гараж из топочной
sensorMovement5 - сенсор движения на веранде (не используется)
sensorMovementRemote2 - датчик на TPLINK
sensorMovement3 - датчик движения в спальне
sensorMovement4 - Датчик движения в ванной
sensorMovement2 - Датчик движения в зале
webCamMotion1
webCamMotion2
sensorMovement1 - Датчик движения в коридоре

Объекты класса NooRemotes:
NooKey63 - Датчик давления в контуре
NooKey62 - Датчик давления в контуре (пониженное давление)
NooKey61 - Датчик давления в контуре (повышенное давление)
nooButton5C - пульт-брелок ключи Сергея (кнопка C)
Методы объекта:
onLoadPreset
nooButton5B - пульт-брелок ключи Сергея (кнопка B)
Методы объекта:
onSwitch
nooButton5A - пульт-брелок ключи Сергея (кнопка A)
Методы объекта:
onSwitch
nooButton4C - пульт-брелок (кнопка C)
Методы объекта:
onLoadPreset
nooButton4B - пульт-брелок (кнопка B)
Методы объекта:
onSwitch
nooButton4A - пульт-брелок (кнопка A)
Методы объекта:
onSwitch
nooButton33 - кнопка 3.3
nooButton31 - кнопка 3.1
Методы объекта:
onSwitch
nooButton32 - кнопка 3.2
nooRemote1 - кнопка включения
Методы объекта:
onSwitch
onRollColor
onSwitchColor
nooButton23 - кнопка 2.3
nooButton21 - кнопка 2.1
Методы объекта:
onSwitch
nooButton22 - кнопка 2.2
Методы объекта:
onBrightBack
onSwitch

msh555 подтверждение моих слов о скрещевании названий:

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

Объекты класса NooLiteDimm:
NooLiteD_ZalBra - Светильник в зале (10)
NooLiteD_TualetVit - Вытяжка в туалете (8)
NooLiteD_TualetTP - Теплый пол в туалете (9)
NooLiteD_TualetTop - Люстра в туалете (7)
NooLiteD_KuhnyaVit - Вытяжка на кухне (6)
NooLiteD_KuhnyaBra - Светильник на кухне (5)
NooLiteD_KuhnyaTop - Люстра в кухне (4)
NooLiteD_ZalTop - Люстра в зале (3)
NooLiteD_SpalnyaBra - Светильник в спальне (2)
NooLiteD_SpalnyaTop - Люстра в спальне (1)

Объекты класса switchNooLite:
switchNooLite_Zal_Polka_3 - (29)
Методы объекта:
refresh
switchNooLite_Zal_Polka_2 - (28) Помечает последнюю проговоренную задачу как выполненную.
Методы объекта:
refresh
switchNooLite_Zal_Polka_1 - (27)
Методы объекта:
refresh
switchNooLite_HalLRGB - Выбор фиксированного цвета (26)
Методы объекта:
refresh
switchNooLite_Hall_Door_3 - Дверной выключатель в коридоре, сценарная 3 (25)
Методы объекта:
refresh
switchNooLite_Hall_Door_2 - Дверной выключатель в коридоре, сценарная 2 (24)
Методы объекта:
refresh
switchNooLite_Hall_Door_1 - Дверной выключатель в коридоре, сценарная 1 (23)
switchNooLite_Spalnya_Wall_3 - Прикроватный выключатель в спальне, сценарная кнопка
Методы объекта:
refresh
switchNooLite_Spalnya_Wall_2 - Прикроватный выключатель в спальне для бра
Методы объекта:
refresh
switchNooLite_Spalnya_Wall_1 - Прикроватный выключатель в спальне для люстры
Методы объекта:
refresh
switchNooLite_Spalnya_Door_3 - Дверной выключатель в спальне, сценарная кнопка
Методы объекта:
refresh
switchNooLite_Spalnya_Door_2 - Дверной выключатель в спальне для бра
Методы объекта:
refresh
switchNooLite_Spalnya_Door_1 - Дверной выключатель в спальне для люстры
Методы объекта:
refresh
switchNooLite_Zal_Comp_3 - Выключатель у компа в зале, сценарная 3
Методы объекта:
refresh
switchNooLite_Zal_Comp_2 - Выключатель у компа в зале, сценарная 2 (21)
switchNooLite_Zal_Comp_1 - Выключатель у компа в зале, сценарная 1 (20)
switchNooLite_Tualet_Wall_3 - Стенной выключатель в туалете, сценарная кнопка
Методы объекта:
refresh
switchNooLite_Tualet_Wall_2 - Стенной выключатель в туалете для вытяжки
Методы объекта:
refresh
switchNooLite_Tualet_Wall_1 - Стенной выключатель в туалете для люстры
Методы объекта:
refresh
switchNooLite_Tualet_Door_2 - Дверной выключатель в туалете для вытяжки (отвязан)
Методы объекта:
refresh
switchNooLite_Tualet_Door_3 - Дверной выключатель в туалете, сценарная кнопка (отвязан)
Методы объекта:
refresh
switchNooLite_Tualet_Door_1 - Дверной выключатель в туалете для люстры (отвязан)
Методы объекта:
refresh
switchNooLite_Zal_Door - Дверной выключатель в Зале
Методы объекта:
refresh
switchNooLite_Kuhnya_Wall_2 - Стенной выключатель на кухне для бра
Методы объекта:
refresh
switchNooLite_Kuhnya_Wall_3 - Стенной выключатель на кухне для вытяжки
Методы объекта:
refresh
switchNooLite_Kuhnya_Door_3 - Дверной выключатель на кухне сценарная кнопка
Методы объекта:
refresh
switchNooLite_Kuhnya_Wall_1 - Стенной выключатель на кухне для люстры
Методы объекта:
refresh
switchNooLite_Kuhnya_Door_2 - Дверной выключатель на кухне для бра
Методы объекта:
refresh
switchNooLite_Kuhnya_Door_1 - Дверной выключатель на кухне для люстры
Методы объекта:
refresh
snl30 - Люстра на кухне
Методы объекта:
refresh
snl31
snl32
snl33 - Люстра в туалете
Методы объекта:
refresh
snl34
snl35
snl36 - Люстра в зале
Методы объекта:
refresh
snl37
snl38
snl39
snl40
snl41
snl42 - Брелок A
snl43 - Брелок B
snl44 - Брелок C

BlackWarrior какойто пустой

Сергей
Углич, Россия

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

TempSensors
ts_office
ts_garage
ts_outdoor
ts_bedroom
ts_livingroom
ts_1wire
ts_kitchen
ts_hall

MovementSensors
ms_driveway
ms_porch - камера дверь
ms_kitchen
ms_hall

AlarmSensors
as_boilerroom_flood1 - z датчик протечки бойлерная
as_bathroom_flood1 - z датчик протечки ванная
as_storage_fire1 - пожарные датчики на складе
as_kitchen_flood1 - z датчик протечки кухня
as_officeroom_heat1 - z датчик тепла кабинет
as_officeroom_smoke1 - z датчик дыма кабинет
as_bedroom_heat1 - z датчик тепла спальня
as_bedroom_smoke1 - z датчик дыма спальня
as_livingroom_heat1 - z датчик тепла гостиная
as_livingroom_smoke1 - z датчик дыма гостиная
as_kitchen_heat1 - z датчик тепла на кухне
as_mansarda_fire1 - пожарные датчики мансарды
as_kitchen_smoke1 - z датчик дыма на кухне
as_underground_fire1 - пожарные датчики в подвале
as_terrac_fire1 - пожарные датчики терасы
as_attic_fire1 - пожарные датчики на крыше
as_hall_fire1 - пожарные датчики в холле
as_garage_fire1 - пожарные датчики в гараже

Shagrat у не го вообще както все закодированно

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

inhouseMovementSensors
5588245-24bit-P1 - Зал RC
5592085-24bit-P1 - Спальня RC
5594385-24bit-P1 - Кабинет RC
5588305-24bit-P1 - Коридор 1 этаж RC
Методы объекта:
statusChanged
5592405-24bit-P1 - Кухня RC
3257866-24bit-P1 - Детская RС
_16156170-24bit-P1 - _ RС
stairsdown - Датчик движения на лестнице (вниз)

MySensor с несколькими подклассами там по немногу поэтому объеденю
BathroomButtons - Контролер управления ванной
WaterCounter - Счётчик воды
GazCounter - Газовый счётчик
Pool - Басеин
PoolFilter
SprinkerZone1 - Полив Zone1
BathroomFan - Вентилятор в туалете
DoRCReciver
dwc - Датчик. В туалете
dbathroom - Датчик. В Ванной
wKitchenDoor - Датчик задней двери
wKitchenWind - Окно кухни

Ну и для наглядно сти у него класс tempSensors

tskitchen - Градусник Кухня
tsoffice - Градусник Кабинет
tsnursery - Градусник Детская
tshall - Градусник Зал
tscorridor1 - Градусник Коридор
tsattic - Градусник Чердак
tsrearyard - Градусник Задний Двор (Улица)
tsbedroom - Градусник Спальня

Думаю показательно в мою пользу. Большенство стараются ситематизировать КомнатаТипдатчика и ручками ручками одно и тоже действие.....

Что касаемо Вашего утверждения что нет в коннекте примера с большим кол-вом сенсоров, так может и нет из за этой проблемы их джобавлять. Но это не аргумент а догадка.
Допустим что кто то реализовал проект на МДМ миниотель на 50 номеров например. Во первых потратив месяц ручного кошмара как на конвееере однотипных операций, думаю тот кто такое провернет больше никогда не сядет за анологичны проект, только за типовой например отель в 30 номеров или 60.

Во вторых если этот инстолятор сообразительный он лучше потратит допустим неделю,если Вы правы чтио модуль сложный и грамозкий, на написание модуля и в будующем не придется вручную набивать одно и тоже. Это же кошмар целый.

Потом почему нет больших коннектов:
1 Сенсоры в большенстве своем недешовые и много их позволить далеко не каждый может. Я выбрал MySensors по причине дешевизны,если покупать в китае, и удобства. но удобство некоторые могут поспорить по этому лично это мое мнение и не думаю что стоит это обсуждать.
2 По причине дороговизны большой дом с кучей датчиков и активаторов приводит к тому что УД будут делать наемники а не сам хозяин ковыряясь и разбираясь в МДМ.
3 По выводу 2 следует что коммерческая компания не будет публиковать свои труды на весь интернет, тем более что заказчику будь он частник, хозяин отеля, склада или еще чего трудно будет обяснить что код его объекта общедоступен в интернете и это безопастно.

Думаю аргументов достаточно.

Просьба к всезнющему и справедливому сообществу как проголосовать надо ли это все всем. Потому что если ErmolenkoM прав и написание модуля займет много времени у Сергея да еще и впустую. То тогда умываю руки.

Идеально бы услышать мнение у инсталяторов. Они всетаки массово внедряют в массы МДМ делая его популярнее.


Ну и немного в сторону.
Лично я хочу и они закуплены и будут смонтированны, а соответственно увы но вручную добавленны, чтобы в каждой комнате был датчик качества воздуха, датчик дыма, датчик движения, Датчик освещенности, датчик окна и двери, температура и влажность. Релюхи на освещение. Не говоря уже об уникальных для некоторых комнат например на кухни датчик утечки газа, во влажных помещениях датчики утечки. Мест,комнаты подвал улица вобщем типовых, где все это будет у меня 8 не считая специфических. И только по минимуму без доп , например гдето 2 окна или еще бра есть RGB лента, получается 8 мест * 9 итого 72 обекта ручками + допы в некоторых помещениях, например понравилось у сергея удобная розетка, и сервисные думаю за сотню первалит И все это ручками ручками ручками ручками ручками ручками ручками ручками ............
А потом отлавливать тупые грамматические ошибки.

Ооп для таких задач и предназначен. Масштабируемость это его главное преимущество.

Неа. ООП и маштабируемость не связаны никак.

Вам как профи виднее. Просто когда изучал ООП читал одну статью програмирование на основе тестов, когда сначала пишутся тесты а потом уже код продукта под эти тесты, и автор описывал следующую эволюцию программирования называя автоматическое развертывание системы. Грубо: когда путем описывания в тестах что надо код сам генериться. Грубо если то Процедурное это одномерное измерение, ООП на основе классов и наследования это двумерное, а развертывание это уже более пространствнное. Так я понял и так мне запомнилось.Понят но что не простыми словами надиктовал компьютору что ты хочешь а он сам написал а что то навроде Sql запроса вроде строчка маленькая аа результат огромный, если скуль запрос сложный то и подумать надо поольше и в нем уже многое будет сделанно что не придется в пхп обрабатывать. Или аналогия с регулярными, малюсенькая строчка может сделать аналогичную громозкую работу написанную в процедурном языке. Но это в сторону от главной темы не буду настаивать на правильности своих рассуждений.