Тема: Отправка SIP-SDA3 HTTP-запросов при срабатывании Датчиков
Здравствуйте.
Спасибо, что продолжаете улучшать Ваши (уже как 2 года и наши) изделия.
Особенно хорошо, что появилось HTTP-управление, в частности для SIP-SDA3.
Вы проделали большую работу.
Однако в HTTP-управлении не хватает считывания параметров и ОСОБЕННО отправки устройством HTTP-запросов на Сервер событий (указанный в настройках HTTP-сервер) при срабатывании Датчиков !
Сообщите пожалуйста, планируете ли Вы сделать это ?
Вот прямо в ближайших планах такого нет. Хотя это безусловно вполне реализуемо. Здравые мысли на расширение функционала конечно же приветствуются. Подобный функционал есть у универсальных контроллеров SIP-BSC3, контроллеры буквально могут управлять друг другом и взаимодействовать с внешними системами. https://komendant.pro/product/page/s23/ Оно и понятно, это контроллеры автоматизации. Но вот применительно к SIP-CDA3 не совсем ясно с практической точки зрения - а зачем? Всеж это контроллер абонентский. Кроме того, есть вызов по датчику. Если надо отследить какое-то событие по датчику всегда можно отправить вызов на определенного абонента, даже просто с моментальным отбоем, схватить лог и скриптом осуществить сигнализацию внешним системам. Как-то так.
В общем, конкретизированных по назначению запросов на такой функционал пока не поступало. Различные фичи для редких ситуаций конечно же не в счет.
Во-первых, Вы проделали 99 % работы:
- расположили на плате электрические цепи Датчиков
- сделали Web-интерфейс
- сделали HTTP- управление
Осталось совсем немного:
- Отсылать HTTP-запрос определённой структуры, в которой только один указываемый пользователем параметр (IP-адрес)
Во-вторых, потребности всегда найдутся:
Например у нас есть потребность держать под контролем дверцы щитков, в которых стоят SIP-SDA3.
В-третьих, предложенный вами вариант отправки сигнала требует дополнительных участников и по сложности реализации на 2 порядка выше, чем Вам добавить отправку HTTP-запроса.
... у нас есть потребность держать под контролем дверцы щитков, в которых стоят SIP-SDA3 ...
Вот это и есть конкретизация. Потребность явно не массовая, с другой стороны, вполне логичная. Только ради этого заводить базу запросов, ее обработки и т.п., да и еще при учете не массовости потребности и в принципе наличия решения и без отправки запросов - жирновато получается в плане расхода ресурсов процессора. Другое дело если сам функционал отправки запросов будет решать еще какие-либо задачи, что добавит рациональности к внедрению. Вот на эту тему подумаем. Если у вас возникнут идеи - будем признательны.
... Только ради этого заводить базу запросов, ее обработки и т.п., ...
Не понятно о чём речь.
SIP-SDA3 при срабатывании датчика только лишь отправляет HTTP-запрос типа:
http://{IP-адрес пользовательского Сервера Событий}/sda?sensor1=1
И всё !
А обработку этих запросов ведёт уже этот самый пользовательский Сервер Событий.
Ну а если сделаете ещё и отмену срабатывания датчика:
http://{IP-адрес пользовательского Сервера Событий}/sda?sensor1=0
то будет совсем хорошо.
Поправьте, если не так.
Для реализации подобного функционала, по уму, надо делать мини базу для произвольных(!) запросов определенной длинны (еще и выбрать какой), присваивать им ID и протаскивать по ряду функций срабатывание отправки запроса с нужным ID. + WEB интерфейс (страница управления базой и управление таковой по API). В контроллере нет ОС (и в этом вся прелесть решения), это все скушает место в процессоре. Место пока есть, его не так много, приходится подходить с долей экономии, на тот случай если потребуется что-то радикально важное, а место уже будет занято менее важным. Переход же на более старший процессор это вообще отдельная песня, дорого во всех отношениях. В общем, с вашей потребностью понятно, зафиксировали, подумаем. Повторюсь, будут мысли на тему исходящей сигнализации, кроме озвученного, сообщайте, возможно что-то ускорит процесс.
... надо делать мини базу для произвольных(!) запросов определенной длинны (еще и выбрать какой), присваивать им ID и протаскивать по ряду функций срабатывание отправки запроса с нужным ID. + WEB интерфейс (страница управления базой и управление таковой по API)...
Извините, но по-прежнему не понятно о какой базе вы говорите. И зачем её делать на SIP-SDA3 ?
Объясните пожалуйста
Также важно отметить, что Ваш WEB-итерфейс визуализирует состояние Датчиков.
Это значит, что остаётся только разместить на WEB-странице крошечныйскрипт, отправляющий HTTP-запрос на сторонний Сервер событий.
Получается вся реализация заключается только в мелкой правке html-страницы.
Разве не так ?
Нет, не так, и даже не близко. Это так не работает. Но это и не важно, в данном случае речь была лишь о самой задаче, а не о технологиях ее реализации.
Нет, не так, и даже не близко. Это так не работает.
Извините, но вынужден с Вами не согласиться, т.к. с заданной пользователем частотой постоянно происходит обновление WEB-страницы, состояние Датчиков на ней актуализируются, а значит ничего не мешает программно со страницы отправить HTTP-запрос.
Тем более, что я описал схему реализации, а вы нет.
... в данном случае речь была лишь о самой задаче, а не о технологиях ее реализации.
Как раз в данном случае это важно, так как реализация крайне проста, а значит задача может быть выполнена без особых усилий.
В результате вы расширяете функционал Ваших устройств с минимальными затратами (и не надо ждать крупного заказчика, как вы пишите на форуме).
P.S.
Странно, что об этом пишет пользователь, а не производитель...
В рамках данных дискуссий нет задачи погружения в процессы разработки.
PS: Чтоб на web странице сработал скрипт, для начала надо ее открыть, держать открытой и ждать события (отдельный ПК для этого купите? или cron запустите в условиях отсутствия ОС? ). Описываемый вами способ решения, это даже не костыль, это вообще не реально. Тригер на событие должен быть именно в программе процессора, а не страницы web интерфейса. Нельзя на фронтенд вешать системные функции.
Как раз функцию контроля интерфейса на предмет срабатывания Датчика дверцы у нас и вынужден выполнять отдельный ПК ...
Но не буду спорить - Вам виднее.
В любом случае спасибо, что постоянно расширяете функционал !
HTTP-запросы уже активно используем.
Хорошего Вам вечера
