Мажордомо-Клиент-Сервер

[panda5]

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

И главный вопрос в том, есть ли в системе (или хотя бы в задумках), разнесение всего функционала на клиентов и сервер. Пока что децентрализацию системы я делаю с помощью отдельного mqtt сервера, и отдельного mySQL сервера, датчикам не важно кто этот сервер будет слушать, сколько подписчиков, и кто в ответ отправит управляющие коды, но вот базы для каждого мажордома получаются отдельные, а это ненужная избыточность, да и сами сервера друг про друга ничего не знают - тоже не хорошо. А хотелось бы хотя бы примитивной синхронизации, и управления приоритетами по одной базе. Тогда одними таблицами смогут пользоваться все дружно, и отказоустойчивость системы будет интереснее.

(ну и разработчикам в конце концов будет удобнее: сервер - это одна топология, клиент - совсем другая, разные функции)

PS.
И раз уж поднял тему по поводу разделения функционала, не скажет ли кто нибудь, планируется ли планшетное приложение для мажора, а то на планшете смотреть веб страничку...ну бяда для дизайна, и функционала. Для себя делаем как никак.

[lanket]

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

И главный вопрос в том, есть ли в системе (или хотя бы в задумках), разнесение всего функционала на клиентов и сервер. Пока что децентрализацию системы я делаю с помощью отдельного mqtt сервера, и отдельного mySQL сервера, датчикам не важно кто этот сервер будет слушать, сколько подписчиков, и кто в ответ отправит управляющие коды, но вот базы для каждого мажордома получаются отдельные, а это ненужная избыточность, да и сами сервера друг про друга ничего не знают - тоже не хорошо. А хотелось бы хотя бы примитивной синхронизации, и управления приоритетами по одной базе. Тогда одними таблицами смогут пользоваться все дружно, и отказоустойчивость системы будет интереснее.

(ну и разработчикам в конце концов будет удобнее: сервер - это одна топология, клиент - совсем другая, разные функции)

Обычно здесь немного по другому реализуется подобная задача. В качестве клиентов, в вашем ключе, используются умные актуаторы/Сенсоры. К примеру megaD, MySensors, Z wave, esp8266, Mi home... Которые могут жить своей автономной жизнью.
А уже МД рулит этим балетом.

PS.
И раз уж поднял тему по поводу разделения функционала, не скажет ли кто нибудь, планируется ли планшетное приложение для мажора, а то на планшете смотреть веб страничку...ну бяда для дизайна, и функционала. Для себя делаем как никак.

MajorDroid на андрюшу, рисуете сцены под ваши нужды и прописываете как стартовую.
Либо дашбоард в качестве стартовой. Он немного сыроват, но пришёл по вкусу большинству, а это означает что доведут до ума скоро.


Отправлено с моего Redmi Note 3 через Tapatalk

[panda5]

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

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

Примеры:

Централизация внешних запросов через один из клиентов,
Обновление настроек на всех клиентах и синхронизация баз данных, если не удастся разделить права и пользоваться всем клиентам одной базой

[lanket]

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

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

Примеры:

Централизация внешних запросов через один из клиентов,
Обновление настроек на всех клиентах и синхронизация баз данных, если не удастся разделить права и пользоваться всем клиентам одной базой

Согласен на 50%

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

Вышеперечисленные умные девайсы, могут работать без МД.
Забыл указать на AMS. Она как раз и интерфейс имеет и с МД работает на ура.

Не хочется вас пугать, но здесь распространнено мнение у бывалыз что МД нестабилен и поэтому ему доверять все нельзя.

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

По похожей схеме работает zwave. Просто сначала начал на нем строить уд. Потом перешёл на МД с MySensors. Схема работы у меня как я описываю.

То о чем вы говорите, из того что есть на данный момент из готового подойдёт AMS. По сути самодостаточная система плотно интегрированая в МД. Думаю Вам имеет смысл посмотреть в эту сторону.

Разбивать МД на подсистемы такого врят ли тут поддержат. Хотя запросы похожие тут были. И у бывалых есть МД работающие к примеру на работе и дома.


Отредактированно. В 20:32

Отправлено с моего Redmi Note 3 через Tapatalk

[serghei]

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

Я реализую такую же идеологию. Всем в доме рулят АМС. МД ставят только в известность. Фишка АМС даже по сравнению с MySensor - все сенсоры выступают в роли СЕРВЕРОВ , а не клиентов. Цена вопроса - переизбыток кода сенсоров. Не оспоримый плюс - если в системе начнет все рушиться ( после не удачных обновлений или просто выхода из строя МД ) - сенсоры сами принимают решения и рулят домом дальше. Сейчас два АМС видят один сенсор. И если один из них упадет, ничего страшного не произойдет. Мало того - сенсоры могут разговаривать сами между собой. Но этот функционал еще не разработан.
То есть минимальная единица - это некий сенсор, который отвечает за конкретную задачу. Например для вытяжки на кухне - если повысилась влажность - включи вытяжку. При этом АМС передает состояние на МД . Можно и обратный процесс запустить - нажал на кнопочку вытяжки в МД - она включилась.
Ну и глобальное предназначение МД - голосовое управление.Плюс всякие косметические плюшки....

[panda5]

вопрос немного о другом, избыточность и резервирование никто не отменял, у самого сенсоры одновременно сыпят данные и в mqtt и в блинк, и еще и дамп с таймингом делают на случай временных просадок со связью, и плате с сенсором по барабану кто на той стороне принимает его сообщения, мажор или опен или скрипт на ноде, но вопрос как раз о том, чтобы эта другая сторона (более высокоуровневая, если можно так сказать, вела себя логично и согласованно) те же z-wave хоть и на низком уровне но делают маршрутизацию, а не все ломятся к серверу, такой принцип хотелось бы и в мажордоме, и это не вопрос разработчиков модулей или доп функций, это ядро системы: когда один является сервером, и пишет в базу, а другие оттуда только читают, и логика тут на пол страницы кода... мы больше слов об этом уже написали.

[serghei]

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

[lanket]

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

Отправлено с моего Redmi Note 3 через Tapatalk

[lanket]

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

Отправлено с моего Redmi Note 3 через Tapatalk

[panda5]

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

Отправлено с моего Redmi Note 3 через Tapatalk

К сожалению, это опять же задача не для модуля отдельного, а задача самой системы, и реализация как раз не такая сложная: тут народ по веб - переменным столько всего написал, чтоб парсить чужие странички и оттуда забирать данные, а тут нужно всего лишь взять несколько переменных мажордомо (под текущую задачу), и вставить в код под конкретную плату (выводы которой конфигурируют эту переменную с конкретными выводами платы/микросхемы) а дальше если хотите, то для винды или для линукса командная строчка компиляции и прошивки платы давно уже существует. Итого: ролик урока - делают одни, без Сергея, а ему нужно только добавить оболочку (для начала небольшую, и постепенно наращивать ее уже на основании пожеланий уважаемого сообщества. А там и дойдет до автообновления всех комплектующих, и плат которые подключены по такому принципу (как это сейчас незаметно происходит в современных операционках).