Производитель оборудования для систем контроля доступа Eng Прайс-лист
Оборудование Интеграция

Наименование: Режим Web-JSON

Приобрели контроллер z5rweb, т.к. нужен режим работы Web-json, от
контроллера приходят пакты с пустым POST, почему такое может быть?
При отправке сообщения на сервер выдается ошибка - сообщения
отправляются просто на http:// < IP-адрес контроллера > ?
На проверочном сервере действительно все нормально работает.
Поэтому вопрос: возможно ли использовать готовый сервер типа Apache или Nginx для обработки запросов и писать взаимодействие в виде cgi-приложения или использовать PHP или же нужно писать полностью свой сервер?
Из того, что я попробовал - ответы контроллер принимает нормально - видно отработки типа открытия двери, а запросы с него приходят явно неполные, т.е. переменная $_POST пустая, возможно это режет сервер (Apache) ввиду каких-то особенностей, хотя заголовки корректные. Возможно нужна дополнительная настройка?

Всё расписано в описании к протоколу: https://ironlogic.ru/il_new.nsf/file/ru_web-json.pdf/$FILE/web-json.pdf
Подключаться для проверки можно к серверу: https://json5.help8.ru/
Смотреть на :  https://json5.help8.ru/5/
https://json5.help8.ru/5/ - вход администратора
https://json5.help8.ru/ - вход контроллера
https://json5.help8.ru/unset.php - сброс сервера
https://json5.help8.ru/js.zip - архив этого сервера
Можно использовать любой HTTP сервер.
Только настройка HTTP сервера - это самостоятельный процесс.
В Web-JSON запросы от конвертера приходят не в параметрах, а в теле POST запроса, поэтому $_POST пустая. Надо читать входной поток.
В PHP например: $json = json_decode(file_get_contents('php://input')).

Приобрел устройство MATRIX-II Wi-Fi .
В настройках указал свою сеть Wi-Fi, режим работы web-json, и URL скрипта -обработчика.
IP-адрес устройство получило, стартовые запросы шлет:
{"type":"MATRIX II WIFI","sn":50308,"messages":[{"id":1481765933,"operation":"power_on","fw":"2.27","conn_fw":"1.26","active":0,"mode":0,"controller_ip":"0.0.0.0"}]}
Но IP-адрес 0-ой почему-то. Сюда по инструкции скрипт-обработчик должен ему ответить чем-то типа:
{"id":1481765933,"operation":"set_active","active":1,"online":1}

Ошибка в написании запроса.
Запрос устройству должен выглядеть так:
{"date":"2018-07-10 12:42:50","interval":10,"messages":[{"id":1481765934,"operation":"set_active","active":1,"online":1}]}

Такой вопрос. Удаляю карту из контроллера.
{"date":"2018-07-05 21:09:54","interval":10,"messages":[{"ID":10,"OPERATION":"del_cards","cards":[{"card":"00200049940A"}]}]}
Получаю ответ.
{"type":"Z5RWEB","sn":44389,"messages":[{ "id":10, "success":1},{"id":1704365084,"operation":"ping","active":1,"mode":0}]}
После чего эта же карта , пропускается контроллером и ее код стал :
{"type":"Z5RWEB","sn":44389,"messages":[{"id":1176911340,"operation":"events","events":[{"flag": 0,"event": 5,"time": "2018-07-05 21:14:22","card": "555555555555"}]}]}
В чем тут может быть проблема?
Причем на вход она не пропускается, а на выход "card": "555555555555".

Обновите прошивку модуля связи до версии 1.0.129 и модуля контроллера до версии 3.26. Прошивки можно скачать со страницы сайта: https://ironlogic.ru/il_new.nsf/htm/ru_Z5Rweb. В данных прошивках ошибка устранена.

Подключил контроллер в режиме Web-JSON. Не получилось разобраться с добавленим карт по временным зонам.
cards - массив карт для добавления
card - номер карты в шестнадцатеричном виде (см. ПРИЛОЖЕНИЕ 2)
flags - флаги для карты (8 - блокирующая карта, 32 - короткий код карты (три байта))
tz - временные зоны для карты
При этом "tz": 255 (если я правильно понимаю) это постоянный проход.
Можно получить пример программирования с временными зонами (например с 1,2 и 6)?

tz - это битовая маска разрешённых для карты зон.
Всего семь временных зон: от 0 до 6.
1(dec) = 00000001(bin) - нулевая зона
2(dec) = 00000010(bin) - первая зона
4(dec) = 00000100(bin) - вторая зона
8(dec) = 00001000(bin) - третья зона
16(dec) = 00010000(bin) - четвертая зона
32(dec) = 00100000(bin)) - пятая зона
64(dec) = 01000000(bin) - шестая зона
255(dec) = 11111111(bin) - полный доступ
Соответственно для 1,2,6 зон tz = 01000110(bin) = 70(dec)

Имеется контроллер Matrix-II Wi-Fi (1.26M/2.27) с внешним считывателем.
На первом этапе хочу написать своё серверное NodeJS-приложение, которое будет принимать все события от контроллера и записывать их в базу данных.
Если я верно понимаю, режим WEB-JSON контроллера имеет два подрежима - Web (решение о допуске на объект принимает контроллер) и Online (решение о допуске на объект принимает сервер).
Мне достаточно просто запустить приложение, которое будет слушать порт; перевести контроллер в режим WEB-JSON. Контроллер постучится в порт, не получив ответа, решит что сервер мёртв и перейдёт в режим OFFLINE. ОН ПРОДОЛЖИТ СЛАТЬ НА МЁРТВЫЙ, ПО ЕГО МНЕНИЮ, ПОРТ все события?!

События будут передаваться только после команды сервера "set_active". До этого контроллер будет посылать серверу сообщения "power_on". Ничего не посылать контроллеру не получится. Сервер обязан в
ответе на POST запрос контроллера присылать валидную команду. Если никаких команд для контроллера нет, то ответ должен иметь вид: {"date": "2017-07-25 10:20:30","interval": 10,"messages": []}
Если контроолер не получит валидного ответа, он перейдёт в автономный
режим, и опять начнёт слать "power_on".

Использую протокол WEB-json.
Не правильно срабатывает контроллер на открытие и пишет ошибку код 40.
Установлены следующие настройки:
{
"id": 2771,
"operation": "set_door_params",
"open": 1,
"open_control": 5,
"close_control": 5
},
- время импульса на открытие - 1
- время ожидания прохода - 5
- время ожидания закрытия двери - 5

Вывод сообщений вполне соответствует логике контроллера. У Вас задано :
{
"id": 2771,
"operation": "set_door_params",
"open": 1,
"open_control": 5,
"close_control": 5
},
Собственно в этом и ошибка, видимо в инструкции не сделан акцент на это.
Время должно задаваться в десятых долях секунды, т.е. 1 сек это код 10.
В случае JSON это должна делать программа. При текущих настройках датчик открытия должен сработать за 0.5 сек. Он, естественно, не срабатывает, и поэтому идёт код 40. Следующее срабатывание расценивается контроллером как "взлом".
Должно быть так:
{
"id": 2771,
"operation": "set_door_params",
"open": 10,
"open_control": 50,
"close_control": 50
},
Обратите внимание, что у турникетов бывает импульсное и потенциальное управление. В случае потенциального "время импульса открытия" и "время ожидания прохода" должны быть равны. В случае импульсного "время ожидания прохода" должно быть равно времени заданному в турникете.

Как на контроллере Z5R Web расшифровать флаги охраны, присылаемые вместе с кодом "Охранные события" (39), такие как 1025, 1291? В документации к контроллеру указано "см Охрана", но такого раздела нигде нет. Используется режим WEB-JSON.

Флаг 1025 (dec) = 0x0401(hex)
            
1й байт = 0x01 = 00000001(bin)
- > Бит0 – состояние охранного режима – 1 вкл/0 выкл
Бит1 – состояние тревоги
Бит2 – тревога по входу ALARM (шлейф охраны)
Бит3 – тревога по тамперу
Бит4 – тревога по датчику двери
Бит5 – состояние «сетевой тревоги»

2й байт = 0x04
0x00 – выключено по «сетевой тревоге»
0х01 – включено по «сетевой тревоге»
0х02 – выключено по входу ALARM
0x03 – включено по входу ALARM
- > 0х04 – выключено по тамперу
0х05 – включено по тамперу
0х06 – выключено по датчику двери
0х07 – включено по датчику двери

Флаг 1291 (dec) = 0x050B
            
1й байт = 0x0B = 00001011(bin)
- > Бит0 – состояние охранного режима – 1 вкл/0 выкл
- > Бит1 – состояние тревоги
Бит2 – тревога по входу ALARM (шлейф охраны)
- > Бит3 – тревога по тамперу
Бит4 – тревога по датчику двери
Бит5 – состояние «сетевой тревоги»

2й байт = 0x05
0x00 – выключено по «сетевой тревоге»
0х01 – включено по «сетевой тревоге»
0х02 – выключено по входу ALARM
0x03 – включено по входу ALARM
0х04 – выключено по тамперу
- > 0х05 – включено по тамперу
0х06 – выключено по датчику двери
0х07 – включено по датчику двери

Контроллер Z-5R web в режиме "WEB socket". Когда сервер отправляет ответ на сообщение events/лог событий от z5r-web, контроллер продолжает слать тот же пакет событий. Ответ генерируется корректно как указано в вашем API. Контроллер обновлен до последних прошивок 1.0.157 и 3.42.
[2021-11-26 08:56:10] local.INFO: RESPONCE:array (
'date' = > '2021-11-26 08:56:10',
'interval' = > 10,
'messages' = >
array (
0 = >
array (
'events_success' = > 19,
'id' = > 994244506,
'operation' = > 'events',
),
),
)

Неправильный ответ.
Протокол полностью повторяет WEB-JSON, кроме следующих пунктов:
- В сообщение "events" добавлен параметр "last_event". В ответном
сообщении надо присылать "events_success": < last_event >
{
"type": "Z5RWEB",
"sn": 48276,
"messages":
{
"id": 1714636915,
"operation": "events",
"events": [
{
"flag": 0,
"event": 5,
"time": "2019-12-19 12:07:33",
"card": "000000030201"
},
{
"flag": 0,
"event": 17,
"time": "2019-12-19 12:07:33",
"card": "000000030201"
}
],
"last_event": 3160
}
]
}
- добавлена операция чтения всех карт. "operation":read_cards".
Пример команды чтения карт:
{
"date": "2019-12-25 10:20:32",
"messages": [
{
"id": 12312,
"operation": "read_cards"
}
]
}
В ответ присылается одно или несколько сообщений вида:
{
"type": "Z5RWEB",
"sn": 50001,
"messages": [
{
"cards": [
{
"pos": 0,
"card": "000000DDD2DC",
"flags": 0,
"tz": 255
},
{
"pos": 1,
"card": "000000030201",
"flags": 0,
"tz": 255
}
]
}

Мы ранее делали интеграцию по Web-JSON на контроллере Z-5R (мод. Web), там на странице Режима работы был выбор аутентификации на сервере. Сейчас при работе с контроллером Z-5R (мод. Web BT) этих полей нет . Вопрос, убрана аутентификация в новых прошивках этого контроллера или спрятана?

Логин и пароль вводятся в адресной строке.
ext:12345@192.168.0.28
ext= > логин
12345 = > пароль доступа к API
192.168.0.28 = > IP адрес