Автор Тема: Z5R WEB - web-json и отвратительная работа по нему[РЕШЕНО]  (Прочитано 21108 раз)

astashov

  • Пользователь
  • *****
  • Сообщений: 72
А ответ по протоколу не обязателен.
если на ping не отвечать, как контроллер поймет, что сервер активен?

Важно!
в зависимости от режима работы
если напинг нет ответа 1 или 5 раз
то контроллер считает, что связь потеряна
и повторяет  POWER_ON

Ну я опять же отталкиваюсь от протокола. Если обязательно, то ок. Надо пробовать.
В моем случае он каждый первый раз посылает power_on.

Причем смотрите, в самый первый пример, я на пинги отвечал "message": null
Т.е. так, как Вы это делаете на http://json.il78.com
И все равно...

Еще не понятен алгоритм, по которому контроллер самостоятельно перезагружается. Т.е. в веб интерфейсе регулярно небольшой аптайм. Я не исключаю что есть какая то логика, что если идет пачка ошибок, контроллер таким образом защищается и перезапускается. Но этот механизм нигде не описан и поэтому воспринимается как ошибка.

Я точно знаю как сделать так, что бы контроллер перезагрузился при открытии двери :) Надо послать чуть чуть неверный json в ответ на power_on :) И все. Как только подносится карточка, то контроллер в 100% случаем уходит в перезагрузку. А тут еще не понял зависимость.

murat351

  • Пользователь
  • *****
  • Сообщений: 70
"message": null
- это ошибка,
по протоколу
нужно отправлять массив
"messages":[""]

murat351

  • Пользователь
  • *****
  • Сообщений: 70
не понятен алгоритм, по которому контроллер самостоятельно перезагружается.

-  если  точно знаете или подозреваете  варианты,
это хорошо, информация полезная,
пишите - проверим и если  подтвердится исправим

astashov

  • Пользователь
  • *****
  • Сообщений: 72
"message": null
- это ошибка,
по протоколу
нужно отправлять массив
"messages":[""]

Я не спорю. Просто говорю что у Вас увидел, и сделал так же.
Тогда надо в протоколе пометку сделать, что для онлайн режима ответ на пинг обязательный.

И еще, было бы круто, если бы управлять контроллером не через ответы на пинги или другие сообщения, а подключаться к контроллеру и отдавать команды напрямую. В любое время.
Тогда пинг можно сделать не таким частым, и реакция контроллера не будет зависеть от периода пингования.

murat351

  • Пользователь
  • *****
  • Сообщений: 70
Файл с сетевым дампом общения контроллера и сервера

(13:33:26) /ILogic: Если убрать непонятный мне обмен
(13:33:36) /ILogic: с портом 4545 сервера
(13:35:14) /ILogic: то видно, что он действительно не отвечает на пинг.
то есть отсылается 200 ОК безо всякого json-a. если нечего отвечать, надо слать "messages":[]. ну и дату там,

astashov

  • Пользователь
  • *****
  • Сообщений: 72
не понятен алгоритм, по которому контроллер самостоятельно перезагружается.

-  если  точно знаете или подозреваете  варианты,
это хорошо, информация полезная,
пишите - проверим и если  подтвердится исправим

если отправить в ответ на power_on вот такую неправильную команду
Цитировать
{"date":"2018-06-06 16:12:44","interval":5,"messages":{"id":1911165193,"operation":"set_active","active":1,"online":1}}
То контроллер на нее не ответит, а через interval секунд заного отправит power_on.
Но если нажать кнопку, или поднести карточку, то контроллер перезапускается. По крайней мере аптайм начинается с нуля.
Причем если я с веб интерфейса контроллера нажимаю кнопку "вход" или "выход", то контроллер не перезапускается. Может и не важно, но решил донести до общественности.

murat351

  • Пользователь
  • *****
  • Сообщений: 70
https://ironlogic.ru/il_new.nsf/htm/ru_integration
Прошивка для интеграции сетевого контроллера Z-5R Web с автоматизированными системами
Решение нестандартных задач компаний путем изменения логики работы контроллера

murat351

  • Пользователь
  • *****
  • Сообщений: 70
Спасибо, за информацию, проверим

astashov

  • Пользователь
  • *****
  • Сообщений: 72
если нечего отвечать, надо слать "messages":[]. ну и дату там,

Отлично. Вроде помогло.  Теперь только пинги.

Буду наблюдать за самостоятельными перезапусками. Может какую ни будь закономерность замечу.

А по поводу ссылки на интеграцию :) Ну если бы стоял вопрос собрать все под ключ на причем на большом объеме, то скорее всего пошел бы на интеграцию. А у нас маленький офис программистов, и трата денег на такую доработку - выбросить их на ветер. Просто есть вариант клиент, сервер, и web-json. Можно было бы сделать "Клиент", "Сервер", "Сервер(web-json)". И тогда вообще все довольны.
Даже когда люди будут делать самостоятельные поделки для скуд, они тупо начнут Вас пиарить. И форум тоже более живым станет.
Я купил этот контроллер, только потому что у меня в прошлом офисе стоял контроллер младшей серии. Просто пошел по протоптанной дорожке. А так, возможно и никогда не услышал бы про Вас.

murat351

  • Пользователь
  • *****
  • Сообщений: 70
"реакция контроллера не будет зависеть от периода пингования."
- реакция контроллера не зависит от этого периода
- сообщение о событии приходит сразу

astashov

  • Пользователь
  • *****
  • Сообщений: 72
"реакция контроллера не будет зависеть от периода пингования."
- реакция контроллера не зависит от этого периода
- сообщение о событии приходит сразу
Все верно. Но вот только как мне тогда послать команду на открытие двери, если контроллер мне ничего не шлет?
Т.е. я поставил пинг например каждые 10 секунд.
Нажал в веб интерфейсе кнопку открытия двери(я например когда ключ забываю, то пользуюсь такой функцией, что бы не стучаться и не просить открыть мне дверь), или при приближении сотрудника к двери, направленная wifi антенна видит телефон сотрудника и сразу открывает дверь программным методом.
А тут при возникновении события надо еще 10 секунд подождать, когда контроллер пришлет пинг, и уже в ответе я скажу контроллеру что бы он открыл дверь.
Бред.

Именно по этому и приходится ставить пинг с интервалом в 1 или 2 секунды. А вот если бы контроллер принимал бы сообщения в выдуманном мною режиме "Сервер(web-json)", то пинги можно было бы сократить до 30 секунд, а может быть и до минуты. И тогда реакция контроллера на определенные события была бы моментальной.
Но..... Имеем то что имеем.

Одно интересно, такая реализация сделана исходя из маркетинговых требований?
Мол, если кому то, что то хорошее надо, купят софт на винду, а заодно и саму винду, и заодно сервер на самой винде поставят(ну или виртуалку).
Или так получилось только потому, что в процессе сбора требований, креативной группе не пришло в голову что этот функционал будут использовать, поэтому мы его раздувать до нормальной рабочей идеи не будем....

murat351

  • Пользователь
  • *****
  • Сообщений: 70
1) открытие двери командой через интернет,  предполагает наличие задержки
2)  пинг 1 секунда  для сервера это не проблема
3) вариантов реализации  "двустороннего вызова" много, например веб сокет или задержанный ответ,
но все они  имеют существенно более высокие требования к оборудованию

astashov

  • Пользователь
  • *****
  • Сообщений: 72
1) открытие двери командой через интернет,  предполагает наличие задержки
2)  пинг 1 секунда  для сервера это не проблема
3) вариантов реализации  "двустороннего вызова" много, например веб сокет или задержанный ответ,
но все они  имеют существенно более высокие требования к оборудованию
1) А кто сказал что через интернет? Локальная сеть. Да даже и если через интернет, то у нас по городу межоператорский пинг 10 мс :) можем позволить и через интернет :) Это к тому, что это не предполагает наличия задержки. Нажал - открылось. Идеал!
2) конечно не проблема. Только вот зачем?
3) веб сокет, обычный сокет. Задержанный ответ? Интересно. А можно поподробнее что именно вкладывается в этот термин? А вообще, хватило бы обычного хука в сторону контроллера с бейсик авторизацией. На крайний случай acl список сверху. Это точно не требует дополнительных мощностей. Т.к. режим сервера в контроллере уже есть, а он требует намного больше ресурсов. Кстати, может есть описание протокола общения с контроллером в режиме сервера?

astashov

  • Пользователь
  • *****
  • Сообщений: 72
2)  пинг 1 секунда  для сервера это не проблема
Еще немного по второму пункту: а зачем топить если нет смысла? Ведь автомобиль не стоит на холостых оборотах со стрелкой на тахометре в уровне 3000. Ведь это тоже не порблема. Оптимальное значение 760-880 оборотов на прогретом двигателе.

Так же и тут. Зачем гонять железку, постоянно заставляя ее слать и отвечать на пакеты, когда в этом нет необходимости. Ведь любые затраты вычислительной мощности приводят к нагреву(раз Вы пишите что ресурсов впритык, то возможно и к перегреву), излишнему энергопотреблению, и вполне возможно к преждевременному выходу из строя.
Но вариант есть! не гонять просто так контроллер! Он и так не понятно от чего регулярно перезагружается, сам по себе. А примотать к нему обычные http апи хуки, и все. Сервер сам скажет контроллеру когда хорошо,  а когда плохо. Мало того, сервер сам может говорить контроллеру пинг команду, тем самым можно еще сильнее разгрузить контроллер и выделить высвободившиеся ресурсы на благо обеспечения безопасности и стабильности работы системы.

Ну в общем как то так :)

murat351

  • Пользователь
  • *****
  • Сообщений: 70