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

Дык жизнь не только лампочками определяется - еще кушать надо, в отпуск ездить, ...

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





например, каких? Сделать свою собственную недо-базу данных? nosql? key-value storage?




Гм. Qt - библиотека для С++ (плюс порты под другие языки) для разработки GUI (в основном).

RAD studio - ИДЕ + компилятор языка Delphi + библиотека стандартных компонентов + (в зависимости от варианта) компилятор C++ + (опять же в зависимости от варианта) возможность сборки для IOS / Android. Среда где-то неплохая, но сильно недешевая, а преимущества delphi по сравнению с той же явой или шарпом мне не очевидны.

Сравнивать одно с другим - это как холодильник с телевизором

Давайте к Малине поближе
А то уходим в сторону постоянно.

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

Хоть и опять не совсем о малине, но сей принцип это только частный подход к делу. 100% годится, когда разработчик де факто фрилансер - делает, что и как закажут а сделав, главное забыть о сделанном и сопровождениии навсегда и взяться за следущее "по ТЗ и в срок". В результате в голове, конечно, останется некий опыт, который возможно, сделает разработчика умнее, но может, и как в анекдоте, и "только опытнее" . Нежели-же разарботчик двигает СВОЙ продукт, то выбор инструментов и не только, становится сложнее и ответственнее.

А я бы сказал что SCADА типа AggreGate Building Automation и концепция умного дома это вообще одно и тоже.
Только "умный дом" почему то ломятся делать своим путем, при этом еще на фоне очевидной обреченности в виду участия в гонке монстров типа Google, Apple, IBM и т.д.

И чтобы не отходить от темы:
Очередные 10 абсурдных проектов на Raspberry

Любой из них можно сделать либо на STM32 либо на мини ПК и будет дешевле и функциональней и быстрее.

Вообще-то все ломятся, хоть "дома", хоть SCADA делать именно своими и никаким другими путями. Сотрудничество и унификация только по жесточайшей необходимости и никак иначе.
Под сотрудничеством понимается сотрудничество между равными, а не сотрудничестово между каким-нибудь скада-домо-монстром и производителем датчика . SCADA это страшное грязное БОЛОТО абсолютной несовметимости и грязной конкуренции.

Ну и эти все помянутые ТОЖЕ идут своими путями. Что теперь, всем отальным переквалифицироваться в инсталляторы виндовсов-линуксов-умныхдомов?

У каждого свой опыт и свои методы работы. Мы говорим о разных масштабах проектов. В моих проектах разработчики нанимаются на несколько лет проектирования и сопровождения, и эти люди могут быть откуда угодно, я могу даже их не видеть по несколько лет. Масштабы проекта таковы, что правило "Заказчик всегда прав" действует в полный рост, а выполнение требований ТЗ и календарного плана прямо влияют на жизнеспособность проекта с финансовой точки зрения. И почему Вы считаете, что проработав по 5-8 лет в моих проектах разработчики чего-то забывают и не могут чему-то научиться? Могу привести интересные примеры, опровергающие Ваши представления о проектировании, заодно и обо мне, как разработчике и руководителе проектов.

Вам не повезло с разработчиками, мне везет больше. С 2000 года сотрудничаю с одним из передовых ВУЗов страны МИФИ. Беру в проекты студентов старших курсов и аспирантов. Некоторые работают в штате по 3-5 лет, некоторые уезжают или переходят в крупные предприятия. Самое интересное, что мне удается приглашать в свои крупные проекты даже тех, кто уехал за рубеж, не говоря уже о тех, кто просто перешел в другую компанию. И никто при этом не пытается "двигать СВОЙ продукт", так как это утопия, когда речь идет о проекте масштаба угольного разреза в другой стране. О каких там СВОИХ продуктах может идти речь? Таким проектом будет невозможно управлять и доводить до конечного заданного результата, если каждый разработчик будет двигать свое.

Пару слов о SCADA, раз уж поддался уходу от темы топика. В моих проектах категорически нельзя применять SCADA в качестве основного ПО верхнего уровня, а внизу, ближе к железу можно. ПО верхнего уровня может быть только свое. А причин здесь несколько.
1) Дело в том, что продвинутый Заказчик не ограничивается приобретением по вашей смете только run-time версий SCADA, он потом покупает design-time, чтобы его программисты могли внести изменения при необходимости. Это самое страшное, когда часть системы состоит из твоего ПО и железа, а верхушку изменяет клиент.
2) Экономически выгоднее и безопаснее делать свое ПО, в которое никто не может сунуть нос, чтобы не порушить систему.


Я бы сказал иначе. SCADA и УД также не похожи, как если бы сравнивали RTOS и OS. В первой всё детерминировано по времени и предсказуемо, во второй все плывет и неопределенно. В УД при применении индустриально стандартных интерфейсов, типа RS-485, даже протоколы используются с непредсказуемым результатом. А все просто, пакеты шлются без квитирования, а зачем, без квитанций же экономичнее.

Пытаюсь вернуться к теме топика
Поэтому сочетание SCADA + Raspberry Pi для себя считаю невероятным, а УД + Raspberry Pi очень даже подходящим.

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

а что, квитирование в умном доме официально запрещено какими-то документами ?

Судя по отсутствию там цен, для дома эта штука мало подходит


И какие решения выдали эти монстры? Может быть когда нибудь и будет какая-то стандартная платформа, но пока ее нет

Если под массштабом понимать помянутый Вами "угольный разрез в другой стране", то об АБСОЛЮТНО соираизмеримых массштабах. Ну разве только у меня не один "угольный разрез" а в идеале и переход дальше на корпоративный уровень.

Эти несколько лет НЕ ЕСТЬ срок жизни продукта и не есть срок его сопровождения. Для такого великолепного заказчивка, как "угольный разрез" работа с ним должна продолжаться ВСЮ его жизнь. Основные деньги реально в сервисе, расширении, модернизации, после того, как заказчик ПОДСАЖЕН на ситсему. Так-что "несколько лет" это печальный результат сотрудничества.

А надо именно и управлять и двигать. Не понимаю, правда, кого Вы в контексте вышеотитированной фразы называете "разработчиком" - себя или пришедших к Вам на "пару лет" работников. Я понимаю под разработчиком СЕБЯ ( Вас ) двигающего СВОЮ систему.

1) Свое ПО это тоже может и даже должно быть SCADA, только СВОЕЙ.
2) Заказчик волен ставить сколько угодно других SCADA не SCADA подсистем, а я обязан, поскольку чистое белое поле встречается редко, интегрировать в себя (а потом желательно поглотить и заменить ) уже имеющиеся подсистемы. Условие только одно - ВСЕ остальные общаются строго через базу данных МОЕЙ системы. В крайнем случае совершенно автономных систем, например, монторинга горных ударов, им предоставляются только каналы передачи данных.

Абсолютно фантазийное представление о "детерминированости по времени" . Любые жестко детерминированные по времени действия системы возлагаются на локальные контроллеры или группы контроллеров связанных собственными и дублированными каналами передачи данных, а не на какой-то верхний мозг скады. Такова реальность, например, систем обеспечения безопасности производства. Для вырожденных, систем того-же "угольного разреза" действительно жеского реального времени практически не требуется, ну кроме разве что Proximity Alert System и Geofencing.

One_man_show - Я конечно понимаю, что у вас сложились определенные взаимоотношения с вашим заказчиком, и в принципе Вы правы во всем. Единственное, что SCADA, исходя из ее названия - supervisory control and data acquisition - это система диспетчерского контроля и сбора данных. В нее входят такие функции, как отображение и архивирование данных, посты управления - HMI - ведение различных баз данных и трендов, подключение к рабочей системе автоматизации с помощью различных протоколов, если надо - клиент - серверные решения с несколькими серверами для надежности.
По крайней мере у нас так. В итоге типовыми системами, которые мы используем в наших проектах - это Citect Scada в малых проектах, Codra Panorama - в сложных, и e-terrascada - где-то посередине.
Как видите, о самой системе управления тут даже речь не идет - это всего лишь надстройка над ней. Ессно клиенты получают не только run-time, но и сам дизайн, чтобы они могли интегрировать нашу систему в ихний уровень и изменять дизайн HMI. Ну и конечно, SCADA ни в коем случае не используется как инструмент построения систем управления и автоматизации.

В итоге, то что здесь осуждается - это совсем на SCADA, а система автоматизации зданий.
Ну и второе - Raspberry от SCADA очень далеко.

И второй комментарий:
К счастью и на рынке пост-ссср есть компании, которые разрабатывают свои изделия не исходя из ТЗ заказчика, а исходя из ситуации на рынке и возможных требований. При этом их клиентов не интересует, как изделие устроено, если оно выполняет свои функции, надежно, как часы (т.е. что называется - поставил и забыл), и стоит дешевле, чем альтернатива. Причем это касается не каких-нибудь консумерских штучек, а вполне промышленных вещей со сроками службы по 25 лет, индустриальными требованиями, и ответственностью в случае простоя. И для разработки и вывода этих изделий на рынок, как говорится - все средства хороши. И распбери и ардуино. Естественно - подходить к этому надо с умом и опытом. Многие стартапы в этой области накрываются очень быстро по простым причинам - придумали супер девайс на ардуино по супер цене - типа дешевле конкурентов. Предложили крупной фирме - нашему клиенту, которая в миг от нас переметнулась. Да вот не рассчитали с ЭМС и после грозы полетело аж 30% от ихней партии в ремонты. Клиент в шоке, и после пары таких вот пролетов, возвращается к нам, так как у нас не летит. А в стартапе инженеры разлетаются и он закрывается до лучших времен.
А мы себе потихоньку и распберри и ардуино пользуем, только в финальном продукте это все вырождается в промышленные решения. И время экономится не маленькое.

Что вы называете платформой?
Набор гаджетов на странице в броузере с разноцветными кнопочками? Всю эту лабуду на PHP и JavaScript?

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

GUI я и сам в RAD studio за 5 мин сделаю.
Или вот AggreGate предлагает целые мнемосхемы рисовать.

И как я уже писал есть такой фреймворк - https://allseenalliance.org/



Не стоит так утрировать.
Понятие SCADA с самого появления было больше чем просто мониторинг.
В пакеты SCADA всегда входили realtime контроллеры и на PC в том числе.

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

И если б почитали, то AggreGate ставится и на Rasberry и на BeagleBone и на проч. отладочные платы.

Речь про SCADA зашла потому, что SCADA делает все то что делает MajorDoMo и еще лучше.



Да не поверю. Покажите!

Rasberry не имеет никаких толковых интерфейсов. Даже CAN-а не имеет. Каким концом его в промышленности применить?
Даже c Arduino печальный опыт был.
Поскольку IDE этой свистульки не имеет минимальной внутрисхемной отладки, то малейшее недопонимание API библиотек вызывает простои по несколько дней в разработке.

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

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

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


Чем лабуда на яваскрипте отличается от лабуды на дельфи?


Это все здорово, вот только аггрегате, я подозреваю, совместим только сам с собой


Вот это уже что-то. Но как я понимаю, пока в зачаточном состоянии


Правда на порядки дороже

Не совсем понятно зачем? Если действительно уже многие годы занимаетесь промышленным оборудованием, то тогда уже всяких СОБСТВЕННЫХ аппаратных платформ должно уже было накопиться немало и уж если от чего-то плясать иробовать, то от них и на них, а не от каих-то "арудинообразных". Когда, как поминаемые Вами "добрым" словом "стартапы", тогда понятно, что железа нет совсем и на чем-то надо реально начинать. Да и то, железо можно-нужно брать, а на API зачем завазываться-то!