Comments 23
На старой работе была задача — снимать показания с счетчиков электроэнергии в машзале (~50 штук!). Посчитали, сколько это обойдётся если брать MOXA и родной софт от счетчиков и немного обалдели…
Но тут ктото вспомнил, что есть у нас сисадмин необычный (я) и поставили задачу сэкономить…
В итоге я отреверсил протокол обмена (Весьма простой) и запилил кучку аппаратных Zabbix-agent'ов на базе Arduino + enc28j60 + MAX232 (~500р всего, включая корпус)
В общем — начальство видит красивые графики в Zabbix и Graphana, а я получил некислую премию :P
Нечто похожее уже описывалось на хабре раза два. Правда там про электросчетчики «Меркурий 230» (И подобные) писали.
Собственно, так получилось, что когда я искал инфу по своим счетчикам статьи ещё небыло, а когда разобрался и начал писать прошивку под Arduino — вышла и статья… Эх, на неделю бы раньше — не пришлось бы мучится с реверсом протокола… :(
Себестоимость: 8 модулей, примерно по 500р за каждый (Примерно, т.к. тотже корпус сделал из одолженных у электриков пластиковых распред-коробок).
Zabbix сервер уже был.
Точно не скажу, сколько сэкономили, но получилось раз в 20 дешевле, чем если бы делали по рекомендациям производителей этих самых счетчиков (MOXA + их специализированный софт, который тоже немалых денег стоит)
Может немного поздно, но зачем городить огород?
Если в одной локации есть куча устройств с rs485 интерфейсом, то собирается шина, каждому из них присваивается свой номер, ставится один конвертор rs485/eth и поочередно опрашиваются все устройства. Это типичная схема работы и никаких дополнительных усилий не требуется.
Вопрос в скорости опроса устройств. Сбор всех данных с того-же меркурия 230 может занимать до 10-20 секунд на каждый девайс. А если девайсов пару десятков, а тебе нужна статистика практически в реальном времени (Для быстрого реагирования на проблемы) ?
В моём случае каждый девайс опрашивал 4-5 счётчиков. Этого было достаточно (Получалось снятие данных примерно раз в минуту с каждого счётчика)
Если честно, не могу представить себе задачу в которой необходимо опрашивать в большом количестве счетчики электроэнергии (в одной локации) и при этом очень часто.
Поясню почему - ввод электроэнергии у вас один или два. Контролировать входные параметры (всякие там косинусы) можно прямо на входе. Учет электроэнергии по стойкам (арендаторам, как я понимаю) вряд-ли требуется проводить в режиме реального времени. Ну даже если представить что вы хотите мониторить изменение потребляжа каждой стойки, чтобы отслеживать что некоторые железки ушли в даун... есть более правильные способы,
Я уже и не припомню, зачем это нужно было. Вроде как таким образом хотели отслеживать возможные замыкания и прочие перегрузки в сети (И реагировать на них максимально быстро).
Плюс оборудования было действительно много, ещё и разнесено всё по нескольким отдельным участкам. Плюс дизель-генераторы и даже газовая электростанция и/или котельная "где-то скраю".
И мониторилось не только электричество, но и газ, температуры и некоторые другие штуки. (Было много "ардуин" с DHT22, которые мониторили температуры в технических и жилых помещениях)
Чип оказался с большим количеством аппаратных багов, основная часть которых проявлялась при работе с tcp/ip стеком (а ведь это фишка камня!), библиотека забита пометками //workaround. Прототип я сделал, но в продакшн решил не пускать из-за кривого кремния.
Основная идея использования w7500p была в удешевлении решения на stm32f4, но все уперлось в баги кремния.
Мы используем MOXA в своих работах. И давно уже хотелось снять с пользователя задачи по их настройке в случае нештатных ситуаций. Да и своим инженерам будет меньше мороки при первичной настройке изделия.
При этом дополнительно на скорость очень сильно влияет параметр Serial Command Mode, включенный по-умолчанию.
Лучше использовать Wiznet, если есть возможность.
p.s. Ещё вспомнил прикол про старые PCI платы CP-132. У них по-умолчанию в драйвере стоит настройка размера буферов «High». Но при этом плата теряла каждый шестнадцатый байт при передаче (или приёме, уже не помню, это было в середине 2000-х).
модель MOXA Nport device, в данном случае NPort 5232
Уважаемый Автор! Займусь немного некропостингом...
1. Хотелось бы сначала дать высокую оценку проделанному труду. Посидеть посниффать пакеты может любой, а вот составить мануал и две слегка отличающиеся публикации для сообщества - дорогого стоит. В этом вопросе Вы просто уникальны.
2. Теперь к ложке дегтя. Вы уверенно говорите, что берем dsci, тащим данные оттуда и все работает. Однако в реальности "справочника", на который Вы ссылаетесь, в природе нет. В библиотеке не прописаны, например, модели с индексом "А", как та, на которую Вы ссылаетесь в блоге (в части по эндианам). Скажу без обиняков, мне сразу вспомнилась шутка про преподающего профессора, который говорит "откуда очевидно", когда не знает, как произвести и обосновать какой-то этап вычисления, но не хочет показать это перед студентами.
Если я не прав, разъясните, пожалуйста, что я смотрю не туда и в какую сторону смотреть. Если Вы действительно не смогли разобраться с этой частью, напишите откровенно, так как по факту отсылка на dll не несет толком смысловой нагрузки и только сбивает с толку. А я, со своей стороны, готов поделиться какой-либо информацией, хотя на данный момент мне предоставить откровенно нечего.
MOXA Nport — взгляд изнутри