Как стать автором
Обновить

Комментарии 27

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

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

Кстати, читать текст в стиле: "… а вот тут вы сэкономите 70 000 рублей, ибо поставите нашу систему". Нет, не сэкономлю, ибо не куплю ее даже. Ну нет желания покупать, когда так рассказывают о продукте.
Мне кажется бесполезно их об этом спрашивать. Уже пытался в одной из предыдущих публикаций.
Посмотрел предыдущие статьи, тоже самое. Покупать подписку ради получения минусов — не самая лучшая трата денег. Да и к продукту это какой-то негатив вызывает, хотя я не говорю, что он плохой разумеется.
От получения минусов никто не застрахован, ибо люди, ставящие минусы не подчиняются правилам логики, а делают это лишь руководствуясь эмоциями. Среди читателей любой статьи найдется 1-2% недовольных, которые захотят воспользоваться властью ставить кому-то оценки, а уж тем более, если это коммерческая статья.
не 1-2 процента.
Сравните Ваш блог и, например, блог Лахта центра. (рейтинг постов, комментарии итд)
От качества контента все зависит
Да, вы в чем-то правы — я не раскрываю всех деталей, спецификаций и описаний. Раскрытие подобной технической информации не добавит продукту привлекательности. Но и сокрытие ее не скажется негативно. Для дела полезнее, когда продукт выполняет свои функции, а не когда известно в мельчайших подробностях, как он это делает.
взять ПЛК и написать только верхний софт
И стоить это будет гораздо меньше 70 тыс.р.
Да, это верно — гораздо дешевле. Мы так же сначала думали и с этого начинали. Жаль, что это не работает, как надо, без изменений в ПЛК, без своего нижнего софта и прочих доработок.
Так расскажите почему это не работает, как к этом пришли, что перед этим делали. Коммерческой тайной это не является точно… тогда чем? Некомпетентностью? Нежеланием писать хороший материал?
Вы вроде говорите о логике масс, о 1-2%, но своими действиями сами же оспариваете эту элементарную логику.
С удовольствием расскажу:
geektimes.ru/company/redpine/blog/288846
geektimes.ru/company/redpine/blog/290805
geektimes.ru/company/redpine/blog/291957

Возможно, там тоже не найдется большого числа технических деталей, но есть ответы на ваши вопросы — как к этому пришли и что перед этим делали. Коммерческой тайной это не является.
Не нашел ответа в приведенных вами на статьях на вышеуказанные вопросы.
Чтобы помочь с поиском, я могу сделать для вас выжимку из предложенных статей, которая позволит ответить на вопрос, «как мы пришли к нашему решению и что перед этим делали»:

При поиске решения для себя (собственный арендный парк более 250 ДГУ), мы пробовали различные системы мониторинга. Но находили системы, которые либо требовали больших затрат, либо обладали ограничениями, которые нас не устраивали. Мы хотели найти систему, которая бы обеспечила:

  • Гибкое ПО, чтобы мы могли сами добавлять любые новые функции и расширять возможности мониторинга. Ограничения, которые предлагались закрытой средой программирования от производителей систем мониторинга не давали нам нужной гибкости. Например, нам нужно было сделать так, чтобы данные преобразовывались в наш формат, который бы не занимал много места и мог маленькими пакетами передаваться по слабым сигналам связи, а для этого нам нужна была возможность самим писать софт.
  • Простота установки. Любой инженер электрик должен легко установить систему мониторинга на ДГУ без каких-то специальных обучений и сертификатов.
  • Стабильная связь. Поскольку ДГУ работают в труднодоступных районах, связь должна осуществляться надежно даже при плохом уровне связи. Никакие статические IP нам не подходили.
  • Универсальность. Система должна работать со всеми ДГУ любого производителя и с любой панелью управления. Цифровой интерфейс или аналоговый — все должно мониториться одинаково.


Мы более года искали подобный вариант, но найти не могли, поэтому решили создавать свой. Если грубо то вот по какой логике:

  • Данные с панели управления собираются ПЛК. Если панель аналоговая, то должны быть доп.модули и датчики. ПЛК должен иметь те интерфейсы и модули, которые нам нужны без каких-то доработок с нашей стороны.
  • На ПЛК должна стоять ОС Linux с открытым кодом для возможности написания собственного софта.
  • Связь должна осуществляться как по LAN, так и по обычному мобильному интернет-соединению (SIM карта без требований статического IP).
  • Данные в ПЛК при помощи нашего софта должны преобразовываться в наш собственный формат, который занимал бы минимум места и мог передаваться пакетно по очень слабым каналам связи (при плохом сигнале сотовой сети) на верхний уровень.
  • Также ПЛК должен уметь самостоятельно принимать различные решения в соответствии с уставками. Т.е. если связь с верхним уровнем пропала, а с ДГУ что-то пошло не так, то контроллер должен сам отреагировать на какие-то критические моменты, а потом дать отчет о событии и принятых мерах.
  • На верхнем уровне должно быть наше ПО и наши сервера. Там происходит расшифровка, анализ и хранение данных. Также на ПО верхнего уровня происходит администрирование системы и располагается пользовательский веб-интерфейс, доступ к которому пользователь может получить хоть с телефона, хоть с планшета, хоть с компьютера.
  • Пользовательский интерфейс должен работать быстро и иметь графическую оболочку с мнемосхемами оборудования, органами управлений и настройки, иметь возможность построения отчетов, графиков, трендов и пр. Также должна отображаться карта с метоположением ДГУ для удобства отслеживания и навигации по большому парку оборудования.


Пообщавшись с различными производителями ПЛК (отечественными и заграничными), мы остановились на Wiren Board, которые были готовы были произвести контроллеры именно по нашему ТЗ по приемлемой стоимости и в приемлемые сроки. Далее на С++ мы написали софт, отвечающий нашим пожеланиям, создан графический интерфейс, заработал сервер верхнего уровня.

Потом были многочисленные тестирования на нашем оборудовании, а потом и проекты с нашими клиентами (мониторинг RedPine успешно используют Сбербанк, Росморпорт, РТРС и прочие компании с распределенными объектами). В результате наработанного опыта, было создано универсальное коробочное решение RedPine ДГУ, которое можно достаточно просто установить на ДГУ своими силами, подключить и пользоваться. А главное — это готовый продукт у которого может быть однозначная цена.

Именно о том, что у нас появился коробочный продукт с калькулятором стоимости, я и написал статью. В комментариях к предыдущим статьям неоднократно просили сообщить цену и показать пример окупаемости, но это тогда было невозможно — т.к. это было проектное решение, а не определенный продукт с определенной ценой.
Какие изменения нужны в ПЛК? Кроме управляющей программы? А если в ДГУ есть, интерфейс (а он там, как правило, есть- иначе как связать ДГУ с внешним миром) с каким либо известным протоколом, скажем, MODBUS- то и ПЛК, как таковой не нужен: достаточно простой SCADA-системы. Для одной-двух установок решение и вообще бесплатным может оказаться. К тому же- многие существующие на рынке контроллеры ДГУ уже имеют софт для удаленного управления и настройки.
В ДГУ разных производителей разный интерфейс, и у них разные панели управления. В большинстве случаев мы сталкиваемся с разношерстным парком ДГУ у клиента. Вы тоже отчасти правы — если речь идет об одной ДГУ или о нескольких одинаковых ДГУ с одинаковыми панелями управления, то наше решение и не нужно — сам производитель ДГУ или панелей предлагает мониторинг, как опцию. Я об этом писал в прошлых публикациях, но, видимо, нужно постоянно на них ссылаться, чего я не сделал — у нас вся эпопея и началась с того, что мы приезжали к клиентам, а у них одна ДГУ — новенькая SDMO с возможностью мониторинга, а вторая — сарый CAT с аналоговой панелью, третья — еще что-то совсем другое. Вот для кого нам пришлось делать решение. Я вам как на духу говорю — мы перед этим перепробовали все варианты, иначе бы не выбрали этот путь. Повторюсь — RedPine ДГУ выгоден скорее для парков с совершенно разными машинами, разбросанными по разным уголкам страны с плохой связью. Это нефтянка, связь, заправки и т.п.
Спасибо за оценку, хоть и негативную. Не могу согласиться с вашим пожеланием — я так понимаю, что у вас есть желание видеть статьи формата Хабрахабр. Если да, то, я полагаю, будет продуктивнее там их и искать — именно там технарями размещается подробная информация о технической реализации для других технарей. Я, кстати, практически цитирую руководство данных площадок.

Почему делаем аппаратную часть, а не берем готовое я писал в предыдущем материале. Если кратко ответить на вопрос — нам нужно было кое-что сильно посложнее управления светом в сортирах. И мы долго искали, много чего перепробовали, но не нашли. В самой первой статье я рассказал, что это решение мы создали для себя в первую очередь, поскольку «взять ПЛК и написать верхний софт» не помогало, а так хотелось… Если вы сможете привести в пример хотя бы 2-3 ардуинщиков, которые реализовали такое же решение (одновременный мониторинг десятков видов оборудования разных производителей, разбросанных по всей стране, их удаленное управление по сотовой связи низкого качества… хотя бы это), я буду безмерно благодарен и даже готов вас премировать. Пусть не реализовали, но хотя бы знают, как это сделать правильно, проще и дешевле.

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

Вам не нравится, как рассказано о продукте, но вас же не продукт интересует, судя по комментариям, а всего лишь техническое решение.
нам нужно было кое-что сильно посложнее управления светом в сортирах. И мы долго искали, много чего перепробовали, но не нашли.
Насколько сложнее? Как бы нормальные ДГУ достаточно «разумны» чтобы не требовать постоянного присутствия человека рядом с собой. Залить топливо или отжать кнопку аварийной остановки по телефону все равно не получится.
привести в пример хотя бы 2-3 ардуинщиков, которые реализовали такое же решение (одновременный мониторинг десятков видов оборудования разных производителей, разбросанных по всей стране, их удаленное управление по сотовой связи низкого качества… хотя бы это
Зачем сразу ардуинщиков? Посмотрите, как это делают, ну, скажем в ЖКХ: теплопункты, КНС, станции подъема, котельные наконец. Разнородного оборудования там- перечислять только производителей задолбаешься. О стандартных интерфейсах и протоколах только мечтать приходиться. Однако- делают же:
teplo.owen.ru/projects/46393305
teplo.owen.ru/projects/84100715
Сложнее — это связать в единую сеть ДГУ разных производителей и разной нормальности и разумности (плюс связанные с ними другие инженерные системы). Как раз основная проблема в том, что из единого центра надо мониторить и советскую ДГУ на Камчатке, и новенький FG Wilson в Казани, и какую-нибудь AKSA в Краснодаре. Они друг с другом никак не дружат без очень длительных танцев с бубнами.

Про Овен я, конечно, знаю, но у них проектные решения, а не готовые коробочные. Т.е. если вы возьмете для своих ДГУ RedPine, то потребуется только установка и подключение, а если возьмете Овен, то придется писать ПО как низкого, так и высокого уровня, добавлять интерфейсы и делать прочие доработки индивидуально. Но в целом да — из Овна можно собрать себе систему мониторинга. Будет ли это дешевле, учитывая доработки? Это большой вопрос, ведь это будет индивидуальное решение и все будет зависеть от кучи нюансов. Будет ли это прощу и удобнее — однозначно не будет.
Овен я привел просто как пример. У них тоже есть свои плюсы и минусы.
Часть данных снимается с панели управления, часть посредством доп. модулей и датчиков. Работает с DEIF, ComAp, SmartGen, DSE, Bernini, Datacom и многими другими. Используется modbus

Т.е что делает ваш контроллер? Опрашивает ДГУ, преобразуя один протокол в в другой. Правильно? Это если ДГУ в меру умная (имеет интерфейс для мониторинга) уже будет вдвое дороже чем Овен. А если «панель управления» ДГУ представляет собой набор тумблеров и стрелочных приборов, а вся автоматика собрана на реле- то помимо вашего контроллера мне придется еще и кучу модулей прикупать? Итого- цена будет в районе 100 тыс на одну установку Вдобавок- Овен имеет сертификаты соответствия ТС и прочих. А ваше изделие?
Не совсем понимаю, почему меня постоянно спрашивают про наш контроллер, хотя мы не производим и не продаем контроллеры. Контроллер, который для нас производит Wiren Board является лишь частью системы мониторинга и стоит он не дороже контроллера от Овен. Wiren Board осуществляет для нас контрактную сборку контроллеров по нашему ТЗ и мы эти контроллеры уже используем для производства нашей системы мониторинга. Сам контроллер – лишь небольшая часть системы (около 20% по стоимости и функционалу).

Но я все же отвечу на Ваш вопрос, чтобы меня не обвиняли в отсутствии конкретики. Контроллер, является основой железа нижнего уровня и на для был написан специальный софт, который заточен именно под ДГУ (на языке С++). Вместе они являются программно-аппаратной составляющей нижнего уровня решения. В случае простого мониторинга, нижний уровень (контроллер + софт) снимает данные с различного оборудования, преобразует различные протоколы в собственный, сохраняет, пакетирует и отправляет данные с той частотой, с которой это угодно пользователю (пользователь настраивает это через личный кабинет в ПО верхнего уровня). При этом софт, который был написан нами для контроллера (на С++)собирает данные в зашифрованные пакеты и передает их на верхний уровень по LAN или при помощи встроенного 3G модема. Если у панели управления нет цифрового интерфейса, то придется использовать версию RedPine для аналоговых панелей, которая на 15-20% дороже за счет

На всякий случай еще раз повторю — контроллер является лишь частью программно-аппаратной части нижнего уровня (20% от функционала и цены). Мы рассматривали контроллеры Овен в качестве одного из вариантов железа нижнего уровня, но по соотношению цена/функционал выбрали wiren board. Овен не был дешевле и имел существенное ограничение в плане ПО нижнего уровня – собственная закрытая среда программирования с недостаточными для нас возможностями по обработке и передаче данных. Wiren Board несет на борту обычный Linux и дает любые возможности по разработке собственного софта.

Зачем гадать по ценам, если есть калькулятор, ссылку на который я давал, и где можно все за минуту посмотреть. Простое решение по удаленному мониторингу для ДГУ с панелью с цифровым интерфейсом будет стоить 65 тыс. руб. А если панель аналоговая, то 78 тыс. руб. (+20% в случае с обычным мониторингом). Извините за ссылку на внешний ресурс, но в рамках статьи на Geektimes невозможно разместить интерактивный калькулятор.

Еще раз повторюсь – цены, которые выдает наш калькулятор, не являются ценой контроллера, а являются ценой всего решения, т.е. контроллер + ПО нижнего уровня + монтажный комплект + ПО верхнего уровня + облачный web-интерфейс + хранение данных на наших серверах 1 год.

На наше изделие есть декларация о соответствии ТР ТС «О безопасности низковольтного оборудования» и ТР ТС «Электромагнитная совместимость технических средств». ПО RedPine также прошло проверку Минкомсвязи и внесено в единый реестр российских программ для ЭВМ и БД.
Общий совет, если публикуете текст, особенно если это материал рекламного характера!, проводите вычитку.
В данном примере система за 10 месяцев.

Это вот куда?
И теперь, менее чем через год, ежемесячные затраты составляют около 3 500 руб., а значит, система мониторинга RedPine стала экономить 16 500 руб. ежемесячно, если сравнивать со старым подходом.

В оригинале у вас поездки выходят 25000 в месяц, а 16500+3500=20000, куда 5000 сперли?
А потом удивляеться народ, а почему бизнес не идет…
Спасибо!
У меня вопрос про ценообразованию и уникальности решения: вы взяли wirenboard, переклеили лицевую наклейку со своим логотипом… Остаётся открытым вопрос какие изменения были сделаны относительно штатного софта WB и его функционала.
Что было переделано, чем лучше?
Зачем покупать Ваше решение за 70000р, а не WB за 15000?
Очень интересно почитать про проблемы с которыми столкнулись, применённые решения… Про локальный и облачный сервер и так далее…
Спасибо за вопрос!

Wirenboard — это контроллер, а не решение. В RedPine этот контроллер играет роль железа нижнего уровня и производится компанией WB по нашему ТЗ (внесли ряд изменений, например, заменены клеммы, добавлены новые и убраны лишние интерфейсы и т.п.). Кстати, они сами делают и лицевую и все торцевые наклейки. Далее для этого контроллера был написан софт нижнего уровня, основной задачей которого было преобразование разноформатных данных с целого зоопарка различного оборудования в единый формат и подготовка этих данных для гарантированной отправки по низкоскоростным каналам мобильной связи (и все то же самое в обратную сторону — для получения сигналов, перекодированию и передачи на оборудование). Но это еще не все — это лишь нижний уровень, т.е. половина решения. А еще софт и железо верхнего уровня.
Софт верхнего уровня отвечает за передачу, обработку и хранение данных, а также за работу графического интерфейса пользователя (чтобы мониторить, управлять, строить отчеты, графики и т.п.), который должен легко перевариваться любым железом пользователя, даже из 20 века. Ну и железо верхнего уровня — это в основном серверное оборудование и устройства обмена данных между нижним и верхним уровнями.

Это если очень кратко отвечать на вопрос, чем решение отличается от контроллера (в том числе и по цене). Если оценивать процентно, то контроллер — это 20-25% решения. Если вам интересно почитать подробнее, то об этом есть отдельная статья: geektimes.ru/company/redpine/blog/291957
Не убедили…

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

Судя по скриншотам, есть вариант с локальным сервером, есть с облаком.
Что из себя представляет локальный сервер, есть ли ограничения на количество подключённых устройств к нему, что с облаком…
Какова стоимость локального решения и решения в облаке? (это к вопросу про экономию)

Из очень существенных моментов — глубина хранения истории, дискретизация вычитки/получения сервером/сохранения в базу данных значений от ДГУ?

Есть ли возможность интеграции с вышестоящими системами/экспорта данных?

Очень интересно Ваше мнение о преимуществах Вашего продукта, над хорошо зарекомендовавшим себя решением от NetBiter? Правда, очень хотелось бы сравнения от вас… цена почти в 3 раза меньше, гибкость — несказанно выше, как и то, что решение — промышленное, что важно для такого промышленно объекта как ДГУ, а WB — это таки контроллер для домашней автоматизации…
Я, наверное, не очень понятно написал, попробую исправиться. RedPine ДГУ — это не вариация WB, а система, лишь малой частью которой является ПЛК (WB модифицированный под нас). Т.е. если RedPine ДГУ принять за условный автомобиль, то ПЛК — ее двигатель (без обвязки, подвески, кузова, колес, тормозной и топливной системы, органов управления и пр.). Поэтому сравнивать RedPine ДГУ и WB бессмысленно.

ПЛК Wiren Board действительно умеет прекрасно читать огромный зоопарк разных устройств — именно поэтому мы и выбрали этого производителя для наших ПЛК. А еще потому, что на контроллере стоит практически чистый linux и можно написать полностью свой софт, а также постоянно модифицировать и обучать ПЛК новым возможностям. Мы не вносили изменения в конструкцию WB, а в рамках контрактной сборки совместно с WB разработали собственную комплектацию, которая по железу практически такая же, но мы отказались от элементов, которые нам не нужны (типа Wi-Fi, GPS) и добавив нужные: дополнительный интерфейс RS-485 (теперь их 2), 3G модуль, заменили тип клемм для более простого монтажа. Но главное изменение – это не железо, а собственный софт, написанный на С++, который позволяет преобразовывать данные с зоопарка устройств именно в нужный нам формат данных (по структуре и объему), чтобы их можно было легко и безопасно хранить в памяти контроллера и гарантированно отправлять по сотовой связи низкого качества на верхний уровень, где и происходит основная работа системы мониторинга.

Про локальный сервер. Да, если пользователь не хочет хранить данные в облаке и на наших серверах (например, по причине секретности объекта), то он может использовать свой собственный сервер. В этом случае он получает специальную версию RedPine ДГУ с открытым функционалом и ее интеграцию в собственную систему пользователя по его желанию. Подключение осуществляется по протоколам Modbus TCP, RTU, SNMP. Стоит это дороже, чем облачная версия, т.к. подразумевает бессрочную передачу нашей интеллектуальной собственности, а также усложняет как саму процедуру подключения и настройки, так и поддержку решения, т.к. у каждого будет свой софт верхнего уровня со своими особенностями.
Под скриншотом, о котором вы говорите, есть ссылка, которая ведет на сам калькулятор и лучше там смотреть точные цены, т.к. они будут зависеть от нескольких параметров, которые нужно выбрать. Кроме того, там все элементы пояснены при помощи всплывающих подсказок, что может также дать ответы на ряд вопросов. Извините, что приходится Вас переадресовывать на другой сайт, то возможности GeekTimes не позволяют продемонстрировать работу прямо в статье.

Работа с данными. На нижнем уровне данные после обработки могут храниться в среднем 2-3 месяца, но это средние значения для резервной ДГУ, а реальная цифра будет зависеть от количества событий. Но чаще всего данные долго и не требуется хранить – с нужной частотой, например, раз в 5 секунд (настраивается пользователем), софт нижнего уровня пакетами отправляет данные на верхний уровень, и как только нижний уровень получает подтверждение об удачном получении данных, они удаляются с хранилища нижнего уровня. Данные на верхнем уровне хранятся по умолчанию 1 год, а потом уходят в архив. При желании пользователя, можно увеличить хранение оперативных данных с 1 года до 2, 3 и т.д. лет, но это потребует от него доп.затрат (либо доп.оплата хранения на наших серверах, либо выделение доп.памяти на собственном сервере, если выбран собственный локальный сервер).

Относительно NetBiter – давайте я попрошу коллег сделать сравнение для Вас. Пока не могу ответить сходу, т.к. нас отпугивала именно цена, низкая гибкость и тот факт, что в их решениях на нижнем уровне не происходит никаких вычислений, т.к. там у них стоит не ПЛК, а скорее УСПД, т.е. он просто собирает и передает данные без какой-либо обработки, что в нашем случае было неприемлемо (сравнительно большой объем передаваемых данных, для которого требовалась хорошая и устойчивая связь). Но опять повторюсь – это будет не сравнение железа NetBiter с WB, а сравнение решения NetBiter (железо + все антенны и кабели + подписка на их облачный сервис Manage and Analyse) и решения RedPine (железо + все антенны и кабели + наш облачный сервис RedPine). Попробую также сравнить функции облачных сервисов, чтобы осталось меньше вопросов.

Тут часто появляются комментарии о том, что нет конкретики, но от меня почему-то ждут конкретику по работе контроллеров, хотя мы не производим и не продаем контроллеры, а производим готовую коробочную систему мониторинга и управления, в состав которой хоть и входит контроллер, но он не является центром или основой системы, а служит лишь модулем, который по цене и функциям составляет лишь около 20% от всей системы. Этот контроллер можно заменить другим, если в этом будет необходимость, и поэтому я никогда не даю больше конкретики о нем — это уводит обсуждение нашего продукта, в сторону продуктов, которые мы не производим и не продаем, но нас почему-то с ними сравнивают. Согласитесь, как-то странно было бы убеждать кого-то в том, например, что системный блок с видеокартой radeon лучше или хуже, чем просто отдельная видеокарта nvidia. Отдельная карта всегда будет дешевле целого системного блока с подобной по производительности видеокартой, материнкой, процессором, БП, оперативкой, жестким диском и корпусом.

Хоть это и воспринимается, как попытки уйти от ответа, на самом деле я всего лишь стараюсь вернуть диалог к нашему продукту – к системе мониторинга, а не выяснять особенности ПЛК, которые мы и не производим вовсе. Я пытаюсь учесть критику, но не планирую полностью переключаться на другие темы и писать про то, к чему мы относимся лишь косвенно. Но это вызывает лишь негатив – в прошлые разы просили дать цены, т.к. это главное, и мы делаем калькулятор на сайте, где можно все посчитать, и поиграть с вариантами, даем ссылку в статье прямо под скриншотом, чтобы проще было найти, но по комментариям я вижу, что люди не захотели воспользоваться возможностью, а предпочли что-то додумать и начать критиковать эти домыслы. Я пишу это в ответ на ваш комментарий не потому, что имею в виду Вас, просто вы требуете конкретики, задавая действительно конкретные вопросы, что позволяет мне надеяться на адекватную реакцию.
И ещё вопросы о том, как снимаются данные и происходит управление ДГУ — по средством связи с контроллером, который установлен на ДГУ, или через самостоятельное снятие измерений посредством доп. модулей wirenboard?
Если через контроллер ДГУ, то какие производители контроллеров поддерживаются (DEIF, ComAp, etc), связь по какому каналу и протоколу поддерживается (modbus, CAN, проприетарные)?
Количество и состав снимаемых с ДГУ параметров — жёстко прописаны в системе или могут конфигурироваться пользователем?
Ориентация исключительно на одиночно стоящие ДГУ? А что если у меня их 2-3-… да ещё в параллель и с резервом сети?
Часть данных снимается с панели управления, часть посредством доп. модулей и датчиков. Работает с DEIF, ComAp, SmartGen, DSE, Bernini, Datacom и многими другими. Используется modbus. Количество и состав снимаемых с ДГУ может варьироваться — сначала можно поставить только контроль температуры и моточасов, а потом добавить еще, например, уровень топлива или заряд АКБ. Часть параметров могут конфигурироваться пользователем через личный кабинет. Ориентация скорее наоборот — на много разных ДГУ с разными панелями управления, находящихся в разным местах. Работа с синхронизированными ДГУ, резервирование сети — тоже все есть. На одиночные ДГУ мы скорее ориентируемся в случаях, когда это контейнерное исполнение с кучей систем, которые нужно постоянно контролировать издалека. Просто одиночная ДГУ, стоящая в городе — совсем не наш ориентир.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.