IronLogic СКУД
Сетевые контроллеры => Z5R WEB => Тема начата: astashov от 06 Июня 2018, 13:25
-
Ребята здравствуйте.
За три последнии дня совсем замучился с этим режимом работы.
Как только подключаешь его к скрипту, он скидывает пачку событий, сколько накопил, и начинает подряд, в каждую итерацию слать сначала power_on, а уже потом ping
И так повторяется без конца.
И не совсем понятно как именно работает check_access. Иногда сразу хорошо спрашивает и сервер ему отвечает granded, но чаще всего на скрипт даже запрос о разрешения доступа не приходит.
Если контроллер долго не передает информацию, например после ночи, то контроллер может в принципе перестать ее подавать.
т.е. из основных вопросов:
1) почему перезагружается
2) почему не всегда спрашивает check_access
3) почему регулярно шлет power_on и следом ping, если формально перезагрузки не было. И аптайт об этом рассказал
Вот пример power_on запроса и ответа сервера к нему
Запрос от контроллера к серверу
16:12:44.880888 IP 192.168.100.2.39021 > 192.168.100.1.4545: Flags [P.], seq 1351113626:1351113986, ack 559712264, win 1825, options [nop,nop,TS val 952060 ecr 397353636], length 360
POST /z5rweb/z5rweb.php HTTP/1.1
Host: 192.168.100.1:4545
Accept: */*
User-Agent: Z5R WEB
Conection: close
Content-type: application/json
Content-Length: 193
{"type":"Z5RWEB","sn":44640,"messages":[{"id":1911165193,"operation":"power_on","fw":"3.24","conn_fw":"1.0.128","active":0,"mode":0,"controller_ip":"192.168.100.2","reader_protocol":"dallas"}]}
Ответ сервера на запрос от контроллера
16:12:44.881364 ethertype IPv4, IP 192.168.100.1.4545 > 192.168.100.2.39021: Flags [P.], seq 559712264:559712646, ack 1351113986, win 235, options [nop,nop,TS val 397353636 ecr 952060], length 382
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 06 Jun 2018 10:12:44 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 121
Connection: keep-alive
X-Powered-By: PHP/5.6.33-0+deb8u1
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
{"date":"2018-06-06 16:12:44","interval":5,"messages":[{"id":1911165193,"operation":"set_active","active":1,"online":1}]}
Пожалуйста подскажите.
-
Так же интересно почему он по два раза присылает запросы. Два раза подряд один и тот же запрос.
И следом вариант с ping запросом-ответом
16:12:44.982335 IP 192.168.100.2.39022 > 192.168.100.1.4545: Flags [P.], seq 3760511315:3760511611, ack 450982953, win 1825, options [nop,nop,TS val 952070 ecr 397353661], length 296
POST /z5rweb/z5rweb.php HTTP/1.1
Host: 192.168.100.1:4545
Accept: */*
User-Agent: Z5R WEB
Conection: close
Content-type: application/json
Content-Length: 129
{"type":"Z5RWEB","sn":44640,"messages":[{ "id":1911165193, "success":1},{"id":269441500,"operation":"ping","active":1,"mode":0}]}
Ответ сервера на этот запрос:
16:12:44.982797 IP 192.168.100.1.4545 > 192.168.100.2.39022: Flags [P.], seq 450982953:450983272, ack 3760511611, win 235, options [nop,nop,TS val 397353662 ecr 952070], length 319
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 06 Jun 2018 10:12:44 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 59
Connection: keep-alive
X-Powered-By: PHP/5.6.33-0+deb8u1
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
{"date":"2018-06-06 16:12:44","interval":5,"messages":null}
-
контроллер отправляет информацию о событиях или запрос управления до тех пор пока не получит ответ (подтверждение ) от сервера
если он не получает подтверждения то начинает отправлять POWER_ON, так как считает, что связь потеряна.
подробнее об обмене данными в презентации
http://json.il78.com/json.pdf
-
для PHP сервера. Не понятное поведение может быть связано с отправкой информации об ошибках, что контроллер не в состоянии переварить. Что бы отключить отправку таких сообщений
добавьте такой текст php_flag display_errors off в файл .htaccess
-
{"date":"2018-06-06 16:12:44","interval":5,"messages":null}
- ответ сервера с ошибкой, обратите внимание "messages":[""]
-
{"date":"2018-06-06 16:12:44","interval":5,"messages":null}
- ответ сервера с ошибкой, обратите внимание "messages":[""]
Этот пример я взял из диагностики через
Подключаться для проверки можно к серверу: http://json.il78.com
Смотреть на : http://json.il78.com/2/
Не понятное поведение может быть связано с отправкой информации об ошибках, что контроллер не в состоянии переварить.
Ну конечно же нет. Я же привел пакетики. Что получает сервер от контроллера и что отдает. Там нет никаких ошибок. Я могу написать что больше 10 лет админю более сотни серверов, и поэтому такие вещи знаю не по наслышке, но не буду.... :)
контроллер отправляет информацию о событиях или запрос управления до тех пор пока не получит ответ (подтверждение ) от сервера
если он не получает подтверждения то начинает отправлять POWER_ON, так как считает, что связь потеряна.
подробнее об обмене данными в презентации
http://json.il78.com/json.pdf
Окей, что бы не быть голословным, вот полный путь "счастливого" power_on
18:52:34.915349 IP 192.168.100.2.41099 > 192.168.100.1.4545: Flags [P.], seq 4147671979:4147672338, ack 3736399321, win 1825, options [nop,nop,TS val 1911064 ecr 399751145], length 359
POST /z5rweb/z5rweb.php HTTP/1.1
Host: 192.168.100.1:4545
Accept: */*
User-Agent: Z5R WEB
Conection: close
Content-type: application/json
Content-Length: 192
{"type":"Z5RWEB","sn":44640,"messages":[{"id":568637651,"operation":"power_on","fw":"3.24","conn_fw":"1.0.128","active":0,"mode":0,"controller_ip":"192.168.100.2","reader_protocol":"dallas"}]}
18:52:34.915863 IP 192.168.100.1.4545 > 192.168.100.2.41099: Flags [P.], seq 3736399321:3736399702, ack 4147672338, win 235, options [nop,nop,TS val 399751145 ecr 1911064], length 381
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 06 Jun 2018 12:52:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 120
Connection: keep-alive
X-Powered-By: PHP/5.6.33-0+deb8u1
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
{"date":"2018-06-06 18:52:34","interval":5,"messages":[{"id":568637651,"operation":"set_active","active":1,"online":1}]}
18:52:35.012185 ethertype IPv4, IP 192.168.100.2.41100 > 192.168.100.1.4545: Flags [P.], seq 128828847:128829142, ack 3166035494, win 1825, options [nop,nop,TS val 1911073 ecr 399751169], length 295
POST /z5rweb/z5rweb.php HTTP/1.1
Host: 192.168.100.1:4545
Accept: */*
User-Agent: Z5R WEB
Conection: close
Content-type: application/json
Content-Length: 128
{"type":"Z5RWEB","sn":44640,"messages":[{ "id":568637651, "success":1},{"id":681928291,"operation":"ping","active":1,"mode":0}]}
Прошу обратить внимание, что в этом "счастливом" пути указывается один и тот же id. Т.е. 568637651. И сервер радостно сообщает что { "id":568637651, "success":1}
Вроде все замечательно, но нет, на следующей итерации(спустя interval секунд) опять все заного.
Если же на пинг не отвечать, так как по протоколу не обязательно, и возвращать серверу пустую строку(что то ведь вернуть все равно надо), то это ровным счетом ни на что не влияет. И скуд через interval секунд все равно говорит что он power_on
-
Уважаемые товарищи разработчики или специалисты технической поддержки и сопровождения клиентов, я понимаю что никто никому ничего не обязан персонально, и если нет обращения в саппорт официального, то можно и не смотреть, но переводить в плоскость общения с саппортом через почту не сильно хочется. Т.к. проблема может быть не только у меня, а и у других пользователей.
Напишите пожалуйста хоть что ни будь.
Ведь и возвращать устройство обратно тоже нет никакого желания(в данный момент она не выполняет заявленных возможностей, так как одна из возможностей работа в режиме web-json). А для работы в автономном режиме у нас другая, младшая модель. Которая с автономным режимом справляется на ура. Но мы купили эту, и она работает как попало.
Пожалуйста проявите активность, ответьте.
п.с.: я взял скуд только из за того, что есть интерфейс внешнего управления контроллером через консольный линукс через web-json. И я подумал что с удовольствием в качестве хобби напишу интерфейс управления. А тут не получается делать. Контроллер не адекватно себя ведет. И посмотрел что есть поддержка.
Готов участвовать в тестировании и отсылать данные.
Только не молчите.
п.п.с: к пользователям данного скуд: если у Вас тоже неадекватно ведет себя устройство, напишите пожалуйста. Или наоборот. Все хорошо. Желательно с указанием версии прошивок. Спасибо.
-
Все зависит от задачи.
Если нужно решить проблему присылайте полноценный лог обмена данными
, например, за 15 секунд.
Во всех ваших примерах нет законченного обмена.
какая версия прошивки контроллера и модуля связи?
я проверю на http://json.il78.com
впрочем, это можете сделать и сами.
-
для оперативной связи есть Онлайн-консультант: sp.il78.com
-
Все зависит от задачи.
Если нужно решить проблему присылайте полноценный лог обмена данными
, например, за 15 секунд.
Окей. Сейчас соберу сетевой дамп за минуту с включенным интервалом в 5 секунд.
Во всех ваших примерах нет законченного обмена.
Простите, а можно для себя, что бы в будущем были более полные сообщения: а что значит нет законченного обмена?
Нужно показать повторяемость? Или что? Потому что в примере одна итерация закончена полностью, и описал через interval секунд ситуация повторяется.
В моем понимание что обмен закончен.
какая версия прошивки контроллера и модуля связи?
Эта информация есть в первом запросе от контроллера в моем сообщении.
Версия прошивки ,"fw":"3.24","conn_fw":"1.0.128"
я проверю на http://json.il78.com
впрочем, это можете сделать и сами.
Дело в том, что иногда контроллер перестает говорить power_on и только передает ping, а чаще всего он постоянно говорит power_on
В любом случае, текущий пример, который я указан ранее верный? Контроллеру должен был понравиться такой обмен информацией? Раз он в конце сказал "success":1
Я не прикапываюсь к Вашему ответу, просто хочу понять, это я немного не дописываю информацию которая необходима для решения вопроса, или Вы прочитали по диагонали и не увидели то что я написал все полностью, что посчитал достаточным для ответа специалистов.
-
одна итерация закончена полностью, и описал через interval секунд ситуация повторяется.
В моем понимание что обмен закончен.
после этой операции должен быть ping и ответ на него
-
Версия прошивки ,"fw":"3.24","conn_fw":"1.0.128"
- ок принял
-
одна итерация закончена полностью, и описал через interval секунд ситуация повторяется.
В моем понимание что обмен закончен.
после этой операции должен быть ping и ответ на него
эээ. Ну я написал что
{"type":"Z5RWEB","sn":44640,"messages":[{ "id":568637651, "success":1},{"id":681928291,"operation":"ping","active":1,"mode":0}]}
А ответ по протоколу не обязателен.
-
А ответ по протоколу не обязателен.
если на ping не отвечать, как контроллер поймет, что сервер активен?
Важно!
в зависимости от режима работы
если напинг нет ответа 1 или 5 раз
то контроллер считает, что связь потеряна
и повторяет POWER_ON
-
Файл с сетевым дампом общения контроллера и сервера
-
А ответ по протоколу не обязателен.
если на ping не отвечать, как контроллер поймет, что сервер активен?
Важно!
в зависимости от режима работы
если напинг нет ответа 1 или 5 раз
то контроллер считает, что связь потеряна
и повторяет POWER_ON
Ну я опять же отталкиваюсь от протокола. Если обязательно, то ок. Надо пробовать.
В моем случае он каждый первый раз посылает power_on.
Причем смотрите, в самый первый пример, я на пинги отвечал "message": null
Т.е. так, как Вы это делаете на http://json.il78.com
И все равно...
Еще не понятен алгоритм, по которому контроллер самостоятельно перезагружается. Т.е. в веб интерфейсе регулярно небольшой аптайм. Я не исключаю что есть какая то логика, что если идет пачка ошибок, контроллер таким образом защищается и перезапускается. Но этот механизм нигде не описан и поэтому воспринимается как ошибка.
Я точно знаю как сделать так, что бы контроллер перезагрузился при открытии двери :) Надо послать чуть чуть неверный json в ответ на power_on :) И все. Как только подносится карточка, то контроллер в 100% случаем уходит в перезагрузку. А тут еще не понял зависимость.
-
"message": null
- это ошибка,
по протоколу
нужно отправлять массив
"messages":[""]
-
не понятен алгоритм, по которому контроллер самостоятельно перезагружается.
- если точно знаете или подозреваете варианты,
это хорошо, информация полезная,
пишите - проверим и если подтвердится исправим
-
"message": null
- это ошибка,
по протоколу
нужно отправлять массив
"messages":[""]
Я не спорю. Просто говорю что у Вас увидел, и сделал так же.
Тогда надо в протоколе пометку сделать, что для онлайн режима ответ на пинг обязательный.
И еще, было бы круто, если бы управлять контроллером не через ответы на пинги или другие сообщения, а подключаться к контроллеру и отдавать команды напрямую. В любое время.
Тогда пинг можно сделать не таким частым, и реакция контроллера не будет зависеть от периода пингования.
-
Файл с сетевым дампом общения контроллера и сервера
(13:33:26) /ILogic: Если убрать непонятный мне обмен
(13:33:36) /ILogic: с портом 4545 сервера
(13:35:14) /ILogic: то видно, что он действительно не отвечает на пинг.
то есть отсылается 200 ОК безо всякого json-a. если нечего отвечать, надо слать "messages":[]. ну и дату там,
-
не понятен алгоритм, по которому контроллер самостоятельно перезагружается.
- если точно знаете или подозреваете варианты,
это хорошо, информация полезная,
пишите - проверим и если подтвердится исправим
если отправить в ответ на power_on вот такую неправильную команду
{"date":"2018-06-06 16:12:44","interval":5,"messages":{"id":1911165193,"operation":"set_active","active":1,"online":1}}
То контроллер на нее не ответит, а через interval секунд заного отправит power_on.
Но если нажать кнопку, или поднести карточку, то контроллер перезапускается. По крайней мере аптайм начинается с нуля.
Причем если я с веб интерфейса контроллера нажимаю кнопку "вход" или "выход", то контроллер не перезапускается. Может и не важно, но решил донести до общественности.
-
https://ironlogic.ru/il_new.nsf/htm/ru_integration
Прошивка для интеграции сетевого контроллера Z-5R Web с автоматизированными системами
Решение нестандартных задач компаний путем изменения логики работы контроллера
-
Спасибо, за информацию, проверим
-
если нечего отвечать, надо слать "messages":[]. ну и дату там,
Отлично. Вроде помогло. Теперь только пинги.
Буду наблюдать за самостоятельными перезапусками. Может какую ни будь закономерность замечу.
А по поводу ссылки на интеграцию :) Ну если бы стоял вопрос собрать все под ключ на причем на большом объеме, то скорее всего пошел бы на интеграцию. А у нас маленький офис программистов, и трата денег на такую доработку - выбросить их на ветер. Просто есть вариант клиент, сервер, и web-json. Можно было бы сделать "Клиент", "Сервер", "Сервер(web-json)". И тогда вообще все довольны.
Даже когда люди будут делать самостоятельные поделки для скуд, они тупо начнут Вас пиарить. И форум тоже более живым станет.
Я купил этот контроллер, только потому что у меня в прошлом офисе стоял контроллер младшей серии. Просто пошел по протоптанной дорожке. А так, возможно и никогда не услышал бы про Вас.
-
"реакция контроллера не будет зависеть от периода пингования."
- реакция контроллера не зависит от этого периода
- сообщение о событии приходит сразу
-
"реакция контроллера не будет зависеть от периода пингования."
- реакция контроллера не зависит от этого периода
- сообщение о событии приходит сразу
Все верно. Но вот только как мне тогда послать команду на открытие двери, если контроллер мне ничего не шлет?
Т.е. я поставил пинг например каждые 10 секунд.
Нажал в веб интерфейсе кнопку открытия двери(я например когда ключ забываю, то пользуюсь такой функцией, что бы не стучаться и не просить открыть мне дверь), или при приближении сотрудника к двери, направленная wifi антенна видит телефон сотрудника и сразу открывает дверь программным методом.
А тут при возникновении события надо еще 10 секунд подождать, когда контроллер пришлет пинг, и уже в ответе я скажу контроллеру что бы он открыл дверь.
Бред.
Именно по этому и приходится ставить пинг с интервалом в 1 или 2 секунды. А вот если бы контроллер принимал бы сообщения в выдуманном мною режиме "Сервер(web-json)", то пинги можно было бы сократить до 30 секунд, а может быть и до минуты. И тогда реакция контроллера на определенные события была бы моментальной.
Но..... Имеем то что имеем.
Одно интересно, такая реализация сделана исходя из маркетинговых требований?
Мол, если кому то, что то хорошее надо, купят софт на винду, а заодно и саму винду, и заодно сервер на самой винде поставят(ну или виртуалку).
Или так получилось только потому, что в процессе сбора требований, креативной группе не пришло в голову что этот функционал будут использовать, поэтому мы его раздувать до нормальной рабочей идеи не будем....
-
1) открытие двери командой через интернет, предполагает наличие задержки
2) пинг 1 секунда для сервера это не проблема
3) вариантов реализации "двустороннего вызова" много, например веб сокет или задержанный ответ,
но все они имеют существенно более высокие требования к оборудованию
-
1) открытие двери командой через интернет, предполагает наличие задержки
2) пинг 1 секунда для сервера это не проблема
3) вариантов реализации "двустороннего вызова" много, например веб сокет или задержанный ответ,
но все они имеют существенно более высокие требования к оборудованию
1) А кто сказал что через интернет? Локальная сеть. Да даже и если через интернет, то у нас по городу межоператорский пинг 10 мс :) можем позволить и через интернет :) Это к тому, что это не предполагает наличия задержки. Нажал - открылось. Идеал!
2) конечно не проблема. Только вот зачем?
3) веб сокет, обычный сокет. Задержанный ответ? Интересно. А можно поподробнее что именно вкладывается в этот термин? А вообще, хватило бы обычного хука в сторону контроллера с бейсик авторизацией. На крайний случай acl список сверху. Это точно не требует дополнительных мощностей. Т.к. режим сервера в контроллере уже есть, а он требует намного больше ресурсов. Кстати, может есть описание протокола общения с контроллером в режиме сервера?
-
2) пинг 1 секунда для сервера это не проблема
Еще немного по второму пункту: а зачем топить если нет смысла? Ведь автомобиль не стоит на холостых оборотах со стрелкой на тахометре в уровне 3000. Ведь это тоже не порблема. Оптимальное значение 760-880 оборотов на прогретом двигателе.
Так же и тут. Зачем гонять железку, постоянно заставляя ее слать и отвечать на пакеты, когда в этом нет необходимости. Ведь любые затраты вычислительной мощности приводят к нагреву(раз Вы пишите что ресурсов впритык, то возможно и к перегреву), излишнему энергопотреблению, и вполне возможно к преждевременному выходу из строя.
Но вариант есть! не гонять просто так контроллер! Он и так не понятно от чего регулярно перезагружается, сам по себе. А примотать к нему обычные http апи хуки, и все. Сервер сам скажет контроллеру когда хорошо, а когда плохо. Мало того, сервер сам может говорить контроллеру пинг команду, тем самым можно еще сильнее разгрузить контроллер и выделить высвободившиеся ресурсы на благо обеспечения безопасности и стабильности работы системы.
Ну в общем как то так :)
-
https://learn.javascript.ru/xhr-longpoll
-
https://learn.javascript.ru/xhr-longpoll
А, ну понятно. Окей, это вариант реализации. Согласен. НО!
Во первых для ленивых опишу словами то что описано по ссылке простыми словами:
1) контроллер пингует сервер раз в 15 секунд
2) сервер получив запрос от контроллера держит его N секунд, в ожидании команд от оператора(например открытия двери с веб интерфейса).
3) дождавшись любой команды, отвечает на пинг(или любой другой запрос) с командой.
3) если за N секунд никаких команд не появилось, то отвечаем пустым понг ответом и go to 2
Что имеем в реале:
Абсолютно не важно какой интервал пингования установлен в контроллере или передан через параметр Interval. Контроллер в любом случае посылает команду power_on, если нет ответа на пинг в течении 4-х секунд. Есть предположение что проверяется отсутствия пинга более 4.99... секунд.
Т.е. по факту отложить можно максимум на 4 секунды :)
Но и это еще не все. Следующий пинг контроллер посылает только тогда, когда получит ответ на предыдущий пинг :) Т.е. ни о какой асинхронности даже и речи нет :)
И в итоге, данный подход для реализации на этом контроллере полностью бесполезен. Ладно бы новый пинг от понга не зависел бы, еще можно было бы выставить время интервала в 5 секунд, отвечать не позднее чем в 4 секунды и можно было бы говорить что почти что реалтайм(конечно с оговорками что если произошло событие, то новое событие может произойти только в течении interval секунд)
2018-06-20 13:35:53 - Z5RWEB446405b2a03d94816e - ...ping
2018-06-20 13:35:57 - Z5RWEB446405b2a03d94816e - ...pong
2018-06-20 13:36:12 - Z5RWEB446405b2a03ec1a205 - ...ping
2018-06-20 13:36:16 - Z5RWEB446405b2a03ec1a205 - ...pong
Интервал пингования 15 секунд, сон между пинг и понг 4 секунды. По таймингу видно как ведет себя контроллер.
-
я перечислял варианты на которых это могло бы быть реализовано - какие варианты бывают (типовые)
"вариантов реализации "двустороннего вызова" много, например веб сокет или задержанный ответ,"
- они не реализованы в этим контроллере.
-
а, если те варианты на которых могло бы быть реализовано, тогда да. Это приемлемый вариант.
-
"Следующий пинг контроллер посылает только тогда, когда получит ответ на предыдущий пинг  Т.е. ни о какой асинхронности даже и речи нет "
- я не понял проблемы
1) на пинг отвечаем не позднее 4 сек
2) интервал между пингами ставим 1 сек
наверное, хорошо бы иметь возможность регулировать допустимое время задержки до 15-30 сек
но в остальном я проблем не вижу
-
"Следующий пинг контроллер посылает только тогда, когда получит ответ на предыдущий пинг  Т.е. ни о какой асинхронности даже и речи нет "
- я не понял проблемы
1) на пинг отвечаем не позднее 4 сек
2) интервал между пингами ставим 1 сек
наверное, хорошо бы иметь возможность регулировать допустимое время задержки до 15-30 сек
но в остальном я проблем не вижу
В таком варианте я согласен. будет оптимально. Даже думаю что можно использовать как конечное решение.
-
1) на пинг отвечаем не позднее 4 сек
2) интервал между пингами ставим 1 сек
но в остальном я проблем не вижу
На самом деле проблемы есть! Так как режим работы синхронный, то запрос check_access приходит только тогда, когда я отсылаю понг ответ
И что происходит.... Прикладываю карту. приемник моргает желтым и потом сразу красным. И только когда подносишь карту в момент когда пришел понг ответ, сервер получает запрос от контроллера и может авторизовать тебя.
И что то мне подсказывает, именно с этим связано поведение с картой 555555555555.
В общем этот вариант работы не подходит. Остается только выжигать все напалмом - т.е. ставить пинг интервал 1 секунды. Иначе никак.
-
да согласен, не получается
-
Кстати из за того, что выставляется пинг задержка в 1 секунду, то время аутентификации может быть в пределах 0-1.х секунды. Т.е. иногда подносишь карту, и сервер моментально авторизует тебя, а иногда подносишь карту, и задержка в секунду точно присутствует(визуально дискомфортно, когда приготовился тянуть дверь, а она зараза закрыта :) ). Раньше я не понимал почему. В автономном режиме все моментально, не успеваешь поднести как дверь открылась, а тут задержка. Грешил на запрос-ответ, сетевые издержки и т.д.. Ну не секунда ведь..... Теперь понятно почему.
Если честно, то не комфортно конечно.
Вот бы убрать зависимость... Было бы хорошо.
п.с.: неплохо было бы описать эту особенность в протоколе. А то вдруг еще кто ни будь захочет так же как я заморочиться. Что бы меньше сюрпризов было....
-
Люди! прошло столько времени а проблемы не решены! это минусы нашего Российского "подхода"!
Контроллер шлет постоянно power_on в режиме online:1 . В режиме online:0 контроллер отвечает на пинг корректно но время от времени присылает все-же power_on
Даже разработчики мне прислали свой скрипт которым они тестируют свои железки, там все так же.
Использовать режим онлайн возможно только при long_pool запросах. На сервере нужно ставить цикл и смотреть когда появятся новые события, если события появились, то отдаем json контроллеру, если не появились то отдаем пустое сообщение.
Такой подход избавит вас от задержек.
В режиме онлайн нужно постоянно отправлять active 1 active 1
Видимо это недоработка их программистов .
Хочу так же пожаловаться на очень скудную документацию по протоколу. Нет четкого описания параметров, входных/выходных данных, так же не указаны обязательные парметры на те или иные действия.
-
"Контроллер шлет постоянно power_on в режиме online:1 . В режиме online:0 контроллер отвечает на пинг корректно но время от времени присылает все-же power_on"
- тут ошибка на сервере. Как правило ошибаются при отправке на пинг.
правильный ответ {"date":"2019-08-21 12:55:20","interval":8,"messages":[]}
обратите внимание !!! "messages":[] - таким должен быть пустой ответ.
эта ошибка приводит к "В режиме online:0 контроллер отвечает на пинг корректно но время от времени присылает все-же power_on"
"Контроллер шлет постоянно power_on в режиме online:1"
- это просто ошибка на сервере, видимо, логическая
Правильное оформление запросов и ответов можно посмотреть на тестовом сервере
http://json5.il78.com/5/
это веб интерфейс администратора
сервер написан на PHP