o_nas 2pwr220

 


В мои руки попало устройство удаленного управления/мониторинга NetPing 2/PWR-220 v2 от компании Alentis Electronics, за что им большое спасибо - давно хотел попробовать данный вид приборов. Это один из многих приборов в линейке NetPing, с сугубо утилитарным основным назначением - управление двумя розетками и мониторинг температуры, т.е. - управление температурой в помещении (основной пример).

Сам по себе NetPing достаточно прост как по управлению, так и по функциям.

Начнем подробный разбор. Для чего предназначается и что может:
- удаленное управление питанием (по Etnernet);
- удаленный мониторинг до 8 датчиков температуры (датчики заказываются дополнительно);
- удаленный мониторинг за состоянием двух "сухих" контактов (сухие - это значит контакты с гальванической развязкой);
- возможность управления ИК приемопередатчиком (трансмиттер заказывается отдельно);
- Управление и мониторинг возможен через SNMP протокол или через HTTP (частично).


Сам по себе прибор выполнен на микроконтроллере Philips LPC2366FBD100 - однокристальный компьютер, внутри ARM7 микропроцессор плюс навешено куча периферии (Ethernet, USB, CAN, I2C, I2S, UART, DAC, ADC и др.). Т.е. практически настоящий комп: 75МГц, 512кб памяти, microSD интерфейс. Кстати, даже сильнее чем например компы в начале 90-х.
Это и хорошо.
Коробочка внутри:

две релюшки (6А, 220В) - управляют розетками, развязка для "сухих" контактов и прочая мелочь.

и с другой стороны:

здесь виден как раз микроконтроллер.

Как таковых выходов у NetPing всего два - и только в виде розеток. Естественно, управляемых.
Простых входов тоже два: это состояния контактов - замкнуты/разомкнуты.

Сам прибор должен быть включен в розетку питания 220В. Ну, и Ethernet для управления, разумеется, тоже.
По умолчанию выставлен адрес 192.168.0.100.

Первичные настройки и кое-какое управление/мониторинг доступны через HTTP. Для этого достаточно авторизоваться (HTTP метод) : visor / ping (по умолчанию).

Из панели управления можно ручками пощелкать релюшками или посмотреть данные температурных датчиков:

(в данном случае - 29 градусов. У меня сейча он лежит около выходного вентилятора компа).
Сами датчики подключаются следующим образом:

Вот здесь на фото - конкретно один датчик, если нужно больше - подключаем прямо параллельно к существующим. Единственное что у них ID должен быть разный. ID пишется цифрой на корпусе датчика. Их два типа: простые и влагозащищенные - TS и WT. Весь спектр датчиков можно посмотреть здесь.

К цифровым выходам IO1 и IO2 подключаются любые контакты (замкнутые или разомкнутые) - логика управления уже внутри обрабатывающей программы пользователя или в панели управления через HTTP.

Далее. Чтение данных термодатчиков может осуществляться через как через HTTP, так и через SNMP.

Вообще, в данном приборе (как и во всем семействе) все управление реализовано через протокол SNMP (UDP-порты 161 и 162).
Управление через HTTP есть, но оно больше похоже на демонстрационное. Хотя, данные с термодатчиков можно считывать простым GET запросом (как и данные с датчиков контактов).
Но, если данные температуры можно считать раз в минуту (и то, это - часто), то данные с контактов считывать раз в секунду достаточно напряжно, да и не продуктивно. Сам по себе протокол SNMP конечно, предусматривает сигналы от аппаратуры - это т.н. TRAP''ы.
Но мне кажется, спектр управления аппаратурой был бы куда богаче, если бы усилить его HTTP составляющую.
Например, хорошо бы задать возможность инициирования самим прибором посылки GET (или POST) на определенный адрес при изменении какого-то параметра. Таким образом, реализуется trap, как в SNMP. Защита в данном случае такая же, как и в обычном HTTP (даже HTTPS можно рассмотреть) - пароль, шифрование, сессия.
Этого пока нет. Т.е. температуру еще можно дергать и щелкать выключателями через HTTP, но брать данные с контактов - уже только в ограниченном ряде случаев (когда не нужен жесткий мониторинг).
С SNMP, конечно, тут все это решается на другом уровне. Но в целом, программинг на SNMP конечно требует подготовки.

С точки зрения программных языков для WEB работа с SNMP выглядит, как работа с его функциями.
Например, в PHP:
$g = snmpget("192.168.1.100","SWITCH",".1.3.6.1.4.1.25728.52.1.8800.1.1.3.3");
получение статуса 3-го датчика температуры (он вообще - есть?)
echo ''status:''.$g;

$g = snmpget("192.168.1.100","SWITCH",".1.3.6.1.4.1.25728.52.1.8800.1.1.2.3");
echo ''value:''.$g;
получение собственно, значения температуры от 3-го датчика. ( данном случае от 3-го - это у меня датчик с ID=3, а их может быть до 8).

а вот здесь - включение реле силового выхода (0 - выкл. 1 - вкл.)
$g = snmpset("192.168.1.100","SWITCH",".1.3.6.1.4.1.25728.52.1.5801.1.2.0",''i'',1);
var_dump($g);

Все работает. (для PHP не забудьте раскоментить строчку, отвечающую за SNMP расширение в php.ini);
Что означают параметры "SWITCH" и вот тот набор цифр? SWITCH - это community (имя сообщества), а "набор цифр" - это OID (object ID) устройства (компонента). Если community берется из описания устройства, то OID''ы берутся из MIB (Management Information Base) - административная база данных, содержащая, по-просту говоря все команды в цифровом виде. Разумеется, для управления по SNMP данным прибором "снаружи" обязательно необходимо иметь MIB файл, где прописаны команды получения каждого OID из прибора. OID можно получить из NetPing например, сторонней программой SysUpTime.

А проще было бы получить все OID у разработчика (например, вместе с прибором или прямо в приборе через HTTP запрос). Я высказывал такое пожелание разработчикам и они сочли это разумным.

Да, все это чудодейство с SNMP, OID, MID базой и прочими разборками с функциями хороши для тех, кто в теме. Для обычного web-разработчика это все таки достаточно сложно и отнимает время.
Проще было бы, действительно, указать, куда слать GET (POST) запросы для событий и по каким адресам управлять (мониторить) девайс с помощью GET (POST) запросов.
Здесь тоже разработчики обещали рассмотреть этот момент глубже (какие-то зачатки управления по HTTP все же есть).
Остается ИК-управление. В данном приборе оно пока не реализовано программно. Аппаратно есть, но программно еще не доделали. Хотя задумка правильная. И управление по ИК так же хотелось бы обслуживать через HTTP запросы. Сам приемопередатчик идет аксесуаром (заказывается у разработчика отдельно), маркируется IRC-TR. представляет собой небольшую коробочку с двумя ИК диодами и проводным универсальным интерфейсом.
Вообще, все датчики для семейства NetPing универсальны и могут применяться во всей линейке устройств. Интерфейс и разъемы - все унифицировано.

Применение.
Основное применение показано на рисунке (с сайта разработчика):

От себя хотелось бы добавить следующую упущенную возможность, которая сильно расширит спектр применения: возможность мониторинга силы тока через коммутируемые выходы - сделать такой анализатор не так уж сложно, но зато появится возможность отследить работоспособность прибора в принципе (он вообще - включился? работает?), оценить потребляемую мощность подключенного прибора (да еще и по времени суток например) - что в нынешних реалиях есть очень даже полезная информация.
Хотелось бы все же иметь коммутируемые контактные группы, отвязанные от питания. Т.е. я просто хочу включить "что-то", а не только силовые розетки. Что? Да хотя бы reset в зависшем компе (или каком другом девайсе) нажать, а не перезагружать его по питанию.
Ну и по-мелочи: вилку с проводом, жестко впаяную в коробочку я бы хотел заменить на обычную компьютерную розетку ("папа"). Мало ли - вдруг в UPS захочу девайс воткнуть. Я наверное врежу туда такой разъем - место там есть.

Выводы:
Устройство NetPing при вдумчивом использовании вполне может работать как датчик(и) температуры на улице с выдачей результата в web - ну это совсем утилитарное использование. Программинг в этом случае совсем простой - запрашиваем страничку раз 10 минут, выписываем температуру, пишем в файл, файл потом используется скриптом на страничке. Все. Конечно, тут если все это используется за NAT''ом домашнего роутера (в домашней сетке короче), то придется что-то мудрить с мапингом портов (еще раз о необходимости инициирования GET посылок), чтобы с наружи добраться до дейвайса. Иначе, девайс не является полностью автономным - ибо придется с отдельного компа в этой же сетке им управлять.
Как небольшой и простой климат-контроль: в гараже может включать тепловентилятор по порогам температуры. Интернета вообще не надо. Настроил граничные условия через web-интерфейс и оставил его вместе с датчиком температуры в гараже. Когда надо - пришел с нотером, переставил значения. Для дома: простейшая сигнализация на дому с выводом в интернет или далее - через SMS шлюз на сотик владельца.
При доделке ИК - автоматическое включение бытовых приборов через ИК: телевизоры, кондиционеры и т.п.
В принципе, устройство очень даже простое (что и хорошо) и правильно сделано. Подход системный просматривается. С программингом конечно пока не так все гладко, но эта проблема решаема.

А если нужно совсем что-то невообразимое по управлению, то очень много функций по вводу-выводу есть в особо навороченной версии UniPing RS-485/UniPing RS-232 с дополнительной платой CoolerBoard. Но это уже тема отдельной статьи.

 

Автор статьи - Cooler, опубликована 27 декабря 2009 года