Мониторинг МАП и MPPT МикроАРТ. Продукты пользователей

РЕКЛАМА НА ФОРУМХАУС

Я делаю не себе а клиенту, ведь "у всех работает". Клиенту лишь нужно оповещение о событиях по СМС. Оплатил комплект. Купил мегафоновский модем. Нанял меня настроить. А вы вообще кого-то можете нанять настроить ЭТО! МАП-овцев. Не смешите...

Продолжу процесс в субботу. Сообщу прошивки всех приборов. Скачаю все последние образы. Надеюсь заработает и я "впарю" ещё много (очень много) этих комплектов...

 

Сделать это не на пи, а на на 3.14цово-мощном компе за 50к для гиков и прочих странных людей кому это надо

Pi это не комп для сбора данных, скорее командир-координатор для конртоллеров типа адруино, мап-ов, кэс-ов и прочих. Рэсбиан не есть ос работающая в реальном времени. Not a real-time operating system...

 

@pashanoid,

Моя рекомендация:
1. Купите нормальную USB 3 флешку. Она обычно тормозит, а вы весьма торопливы
2. Нарежьте последнний образ и соблюдайте инструкцию
а) включите распи
б) дождитесь загрузки (секунд 40)
в) вставьте шнур МАП. udev его найдет и запомнит. Подключите к МАП
г.) вставьте шнур МППТ, подключите к МППТ.
д.) Запустите сервис МАП. Убедитесь, что работает
е) Запустите сервис контроллера. Убедитесь, что работает
ж), Установите модем. Настройте порт. Запустите сервис СМС. Настройте СМС
Все. И торопиться не нужно. Иногда бывают при запуске ошибки чтения с порта и демону приходится несколько раз стартовать.

 

Код открыт и унифицирован для всех. Устанавливать каждый может куда хочет
Чем нам мешает отсутствие рилтаймовости? Все, что нужно ПО делает в реальном времени и все отлично считается.
Вам ничего не мешает купить клиенту просто ПК и все установить на него, если вам чем-то не угодил RasPi

 

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

 

Предлагаю к рассмотрению мнение, мне видится так:
1. Оставить функционал софта на Пи как есть. Аргумент: есть куча пользователей кому в принципе не понадобится расширенная версия сбора статистики.
2. Добавить в ядро функционал для стандартного ответа на запрос по LAN, как вариант webservices. Аргумент: унификация получения любых данных по запросу в зависимости от параметров запроса. HTTP хорошо сжимается при работе по сети.
3. Добавить функционал для оформления Пи как мастер сборщик. Аргумент: эмуляция необязательного сбора данных (по примеру snmp), возможность управляемой конфигурации по хранению консолидированных данных (в том числе и HDD), конфигурация сбора данных с конкретных узлов (указание с каких узлов собирать настраивать на мастер сборщик, никак не на самих узлах – порочная практика привязки сервера статистики). Идея в том что мастер сборщик сам будет решать у кого, когда и с какой периодичностью запросить необходимые данные для хранения статистики. Появляется класс разреженных данных статистики с удаленных узлов.

В данном случае появляется возможность организовывать в сети множество мастер сборщиков с большим кол-вом групп узлов, которые в свою очередь могут являться узлами предоставления статистики для мастер машины на выделенной платформе НО с тем же софтом что и на Пи. Чувствуете выгоду от сокращения объемов кодирования и единообразие в наследовании модели.

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

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

 

@Cronex,

Спасибо, вашу мысль понял. Такие модели знаю. Надо будет подумать. Как идея безусловно интересна

 

@Cronex,

по 1-2 пункту тут я полностью так и собирался делать. Только на уровне приложений не HTTP, а свой протокол. Попроще. Хотя webservices тоже не отметаю.
Дальше я просто хотел ЦУ нагрузить сбором данных со всех зондов (РасПи)
До 100-200 узлов она обработает просто влет. А больше и не надо. Учитывая специфику инсталляций - модель вполне конечна.
Это не WAN и не LAN на 1000 узлов
Модель, что вы предлагаете достаточно стандартна для ОЧЕНЬ больших систем. По-моему тут она просто избыточна. В вашей модели появляется одна ипостась - маршрутизация запросов. Не хотелось бы туда сваливаться
Если уж когда-нибудь возникнет инсталляция на 1000МАПов, думаю тогда МикроАрт будут каждый день по телеку показывать и они войдут в список голубых фишек , можно просто будет сделать прокси-шлюзы на каждые 100 узлов

 

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

 

Архитектуру я понял. Не зря LAN упомянул.
Но вот видите - необходимость построения логической структуры у нас уже усложнит задачу.
Да и не вижу я смысла пока нагружать зонды сбором информации как функцией промежуточного слоя.
Если мы строим двухуровневое дерево, то у нас агенты-сборщики на нижнем уровне с унифицированным софтом и один ЦУ, который и так есть. И прямые логические каналы, соответствующие древовидной структуре ЛВС (физике). full-mesh LAN не прижились, увы.

 

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

 

А вот кстати я еще подумал и мысль остановилась вот на чем:
Вы правы действительно вполне достаточно выполнения двух первых пунктов - это обеспечивает минимально необходимый функционал для построения распределенной системы в принципе.
Консолидирующая система может быть любая, но получив унифицированную систему запросов это вообще не важно.
Фактически все узлы работают независимо, но выдают информацию по унифицированному запросу от системы консолидации.

Кстати отдельная система консолидации в принципе вещь со специфичным спросом, так что возникает вопрос о ее разработке только в типовом виде. Сложно будет разрабатывать систему без активного участия практического использования, можно получить мертвый невостребованный проект.
Это может только МА в полной мере заинтересовать.

 

Несколько отвлеченно и приземленно.

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

На мой взгляд - проблема не концептуальная. Могу ошибаться.

 

@Osolemio, @Cronex все это ужас как мудрено. Честно пытался вникнуть, но не хватает ума.
Есть ли у кого-то реально хотя бы десяток МАПов или МРРТ чтобы была потребность создавать универсальное решение для таких уникальных ситуаций?
Могу судить только по себе, но у меня полное ощущение, что я со своим 1 МАПом + 2 МРРТ от МА уже абсолютно белая ворона. В 99% случаев у народа максимум 1 МАП + 1 МРРТ от МА.
Действительно, невозможность в настоящее время контролировать два МРРТ по отдельности меня несколько уязвляет, но не более того. Мне кажется можно развивать программу в эту сторону, для чего хватит мощностей Малинки вполне. Нагрузка на ее процессор минимальна, а для расширения количества портов можно взять USB hub, можно и с внешним питанием.
У меня сейчас в USB Малинки воткнуты HDD 2'5 без внешнего питания, bluetooth передатчик для клавы, USB hub на 4 гнезда без внешнего питания в который воткнуты переходники от МАПа и МРРТ. Питание Малинки правда усиленное - адаптер 2000 мА, хотя сколько потребление на самом деле не знаю, не измерял.
Да, и еще. Если это возможно, хотелось бы чтобы статистика потребления и выработки энергии (история) сохранялась при обновлении версий программы.

 

Ну вот, обломили полет мысли