Вебхук-сигнализация для входа в дверь

Вебхук-сигнализация для входа в дверь, UniFi Access

EssexCaresIT Guest	#1 16.04.2026 09:59:00 Привет, есть ли какой-нибудь способ заполнить это поле, которое отправляет вебхук? "user_name": "",

UI-Team

Guest

01.05.2026 01:49:00

Привет, @EssexCaresIT, не мог бы ты, пожалуйста, воспроизвести проблему и предоставить полный скриншот конфигурации вебхука? Также, пожалуйста, поделись файлом поддержки UniFi Console, чтобы мы могли разобраться подробнее.

EssexCaresIT

Guest

13.05.2026 12:48:00

Итак, вебхук, отправляемый от сигнализации доступа из UDM, волшебным образом начал отправлять всю нужную мне информацию. Я могу использовать power automate, чтобы получать вебхук, а затем в конечном итоге выводить его в power apps. Сейчас я в процессе создания красивого внешнего интерфейса для приложения, чтобы отображать его на табло по нашим объектам. Это ещё очень ранняя стадия, но, по крайней мере, теперь я получаю нужные данные.

UI-Team

Guest

07.05.2026 07:09:00

Привет @EssexCaresIT, судя по скриншоту, который ты скидывал раньше, ты сейчас используешь Alarm Manager / Create Alarm «Custom Webhook». Он отправляет ровно тот payload, который ты и видишь: alarm_id + events[] + user + user_name. Тот самый "actor": { "id", "name", "type" }, который ты ищешь, приходит из webhook-эндпоинта UniFi Access Developer API. Его нужно регистрировать отдельно через /api/v1/developer/webhooks/endpoints — из Access Alarm Manager он не создаётся. Alarm Manager используется для отправки уведомлений или webhook'ов на основе Trigger / Scope / Action. В официальной документации процесс настройки Alarm Manager тоже описан как Create Alarm → Configure Actions → Send a webhook to a custom URL. Однако формат access.door.unlock, который использует Access OpenAPI Developer webhook, — это отдельная схема webhook'а. Например: В Power Automate: создай cloud flow. Используй триггер: When an HTTP request is received. Затем для начального тестирования установи аутентификацию триггера в Anyone. Power Automate поддерживает разные режимы аутентификации для этого триггера. Если ты выберешь tenant/user OAuth аутентификацию, вызывающая сторона должна отправить валидный Microsoft bearer token с нужными claims. UniFi Access не будет автоматически генерировать Microsoft OAuth токены для Power Automate, так что для прямого тестирования UniFi → Power Automate используй режим триггера Anyone или поставь middleware-сервис перед Power Automate. Сохрани flow. Скопируй сгенерированный HTTP POST URL. Добавь простое действие Response, возвращающее HTTP 200, например:
{
"code": "SUCCESS",
"data": null,
"msg": "success"
}

Документация по UniFi Access webhook'ам ожидает, что твой приёмник примет POST, и рекомендует быструю/асинхронную обработку, потому что у обработки webhook'ов есть таймаут.

EssexCaresIT Guest	#5 05.05.2026 13:35:00 @UI-Team Я всё ещё на том же месте с этим, так как это ваш продукт, можете подсказать, как это сделать, без «посмотрите в документе»

EssexCaresIT Guest	#6 01.05.2026 15:06:00 Спасибо за информацию, очень признателен

travis6509

Guest

01.05.2026 13:53:00

Не знаю насчёт Power Automate или Azure, я ими не пользуюсь, но, похоже, должно работать. Когда ты добавляешь вебхук, ты делаешь API-вызов, прямо как все остальные API-вызовы в мануале, со следующим payload. endpoint — это "Delivery URL" в Alarm Manager. Полагаю, при использовании Azure или Power Automate они его тебе предоставят. В примере curl он указывает на предполагаемый локальный веб-сервер или слушатель вебхуков. Начиная со страницы 185 есть реальные примеры кода того, как построить слушатель вебхуков, написанные на Go, Rust и Python. name — просто имя, которое ты ему даёшь. Какое хочешь. events — собственно события, на которые хочешь подписаться. Это должен быть список, но может быть и список из одного элемента. Тебе, судя по всему, нужна только разблокировка двери, так что это значение будет "['access.door.unlock']". headers — у Azure или PA может быть специфичный заголовок, который они требуют для верификации. Прямо как Unifi API требует заголовок authorization bearer. В остальном он опционален. Ответ, который ты получишь, будет содержать следующее: id — самоочевидно. name — имя, которое ты дал. secret — важная часть. Это "shared key", предоставленный тебе unifi, чтобы проверить, что вебхук валиден и пришёл из правильного места. Главная цель примеров слушателя вебхуков — показать, как верифицировать вебхук с помощью секрета (большая часть кода посвящена именно этому). Правда в том, что верифицировать вообще не обязательно, если не хочешь. Настройка вебхуков в Alarm Manager не имеет секрета и верификации, всегда просто предполагается, что они пришли из хорошего источника. Но всё равно хорошая практика — их верифицировать.

EssexCaresIT

Guest

01.05.2026 12:56:00

@travis6509 Я начал работать с API всего около 3 недель назад, так что прости моё невежество. 11.4 Этот API позволяет добавить endpoint вебхука — куда, откуда, могу ли я использовать power automate, azure runbooks, как я вызываю этот API? Request URL: Что здесь вписать? /api/v1/developer/webhooks/endpoints В примере запроса используется cURL, которым я никогда не пользовался, но endpoint, который там показан, — это приватный IP-адрес. Мне просто нужен реальный пример конфигурации, чтобы уложить это в голове.

travis6509 Guest	#9 01.05.2026 11:50:00 Тебе нужно настроить вебхук через API, а не через alarm manager. У вебхуков alarm manager гораздо меньше данных. Используй раздел 11.4, чтобы добавить свой вебхук-эндпоинт и данные.

EssexCaresIT Guest	#10 01.05.2026 11:07:00 @UI-Team

EssexCaresIT Guest	#11 01.05.2026 09:02:00 Вебхук, который я использую, — это стандартный вебхук, созданный через создание тревоги на вкладке тревог доступа. Это тревога разблокировки с отмеченным «дверь разблокирована» > все пользователи и все методы. Это для каждой локации, и вебхук настроен на URL моего эндпоинта, то есть Power Automate, я также использовал Azure Runbooks, всё стандартное. Он отправляет только «user», то есть unique_id, а не данные «name», которые показывает ваша документация по Access API. Вот тело ответа, которое я получаю от этого вебхука, я обрезал часть информации: "body": { "alarm_id": "019d1a44", "events": [ { "id": "access.unlocks.location_unlocked", "scope": { "locations": "7330f25f" }, "device": "", "location": "7330f25f", "user": "fb9679f0", "user_name": "", "admin": "", "time": "", "emergency_mode": "", "device_name": "", "location_name": "", "direction": "unlocked", "unlock_method_text": "Remote Unlock" } ], "data": { "custom_content": "" } }. Этот JSON на выходе совсем не похож на примеры в вашем PDF с api_reference, значит, я делаю что-то неправильно. Мне документ api_reference кажется сложным для восприятия, как я и говорю, я новичок в этом. Всё, что мне нужно, — это вот это: "actor": { "id": "d62e92fd-91aa-44c2-9b36-6d674a4b74d0", "name": "Hon***", "type": "user" }, чтобы я мог извлечь данные пользователя и использовать их в других приложениях. Я не могу найти ни одного примера, где кто-то реально использует эти Access API. Много разговоров о том, что люди их используют, но нет ничего конкретного в духе «вот как это настроить». Я без проблем получаю все стандартные GET-запросы к API удалённо: устройства, сайты и т.д. И если я использую Postman или Power Automate Desktop в той же локальной сети, я могу получить список пользователей, /proxy/users/api/v2/users/search?, но это только локально и, опять же, вывод не такой, как показывает ваш справочный документ. Я бы очень хотел продвинуть этот проект вперёд, пока его не прикрыли и мы не перешли к другому стороннему поставщику по железу и софту. Как только файл поддержки сгенерируется, я прикреплю его в другом посте.

Читают тему (гостей: 1)