Отправлено: 28.10.11 22:43. Заголовок: Проблема с прошивками по и конфигуратора (продолжение)

Здрасьте у меня такая проблема: версия по 3.3.5.7 версия конфигуратора 3.1.2.20
ставлю на охрану дтмф командой *111, он ставиться, но смс не приходит, делаю тревогу, смс не приходит, делаю снятие дтмф *110 смс нет, хотя галочки все поставил о постаноке и снятии и по тревоге. Ставлю пустым звонком смс приходит, снимаю пустым звонком смс приходит. Позвонил вашим в тех поддержку сказали, чтоб скачал с сайта новую прошивку универсала 3.3.6.2 и новую версию конфигуратора 3.4.1.59, и залил в универсал, я всё сделал, как сказали, но проблема с смс так и осталась. Почитал инструкцию к универсалу и там в п. 6.3 написано---следите за тем, чтобы версия конфигуратора первыми двумя цифрами савпадала с версией по. а как так комплектуется универсал у вас если версия по и версия кофигуратора первыми двумя цифрами не совпадают и взять негде, на сайте тоже самое по 3.3.6.2, а конфигуратор-3.4.1.59 скорей всего проблемы у вас---пишите одно, делаете другое, а мы из-за вас теряем заказчиков, до этого на более старых версиях всё работает отлично, без нареканий. Вы пожалуйста разберитесь у себя побыстрей и напишите что мне делать и где взять по и конфигуратор одной версии!!!!

 Отправлено: 14.04.14 20:25. Заголовок: dem пишет: По повод..

dem пишет:

цитата:

По поводу часов видимо сбой при синхронизации времени с NTP сервером, отключите синхронизацию...

Почему тогда после команды сброса(*875) время восстанавливается? Раз, а то и два раза в неделю происходит сбой времени, причем сам этот сбой не устраняется(при последующих синхронизациях) прошивка 3.3.9.11 конфигуратор 3.9.11.223. В описаниях новых прошивок про время нет ни слова.

 Отправлено: 15.04.14 08:05. Заголовок: bajt пишет: Раз, а ..

bajt пишет:

цитата:

Раз, а то и два раза в неделю происходит сбой времени

Не выяснили причину сбоя времени, может кратковременные пропадания\восстановление питания, провалы сети GSM?

 Отправлено: 15.04.14 14:19. Заголовок: kader_ivan пишет: Н..

kader_ivan пишет:

цитата:

Не выяснили причину сбоя времени, может кратковременные пропадания\восстановление питания, провалы сети GSM?

Нет, эти факторы не влияют, но синхронизация с NTP сервером похоже все же виновата, правда, непонятно как и почему тогда после команды сброса(*875) время восстанавливается?... надо еще раз проверить, отключить синхронизацию, что-то в ней сбоит...

 Отправлено: 15.04.14 17:37. Заголовок: Я сегодня обнаружил ..

Я сегодня обнаружил сбой синхронизации. Причём дата/время сбилось до 1906-12-08 на обоих серверах мониторинга. В СМС и на кадре, присланном на почту время было правильное.
Удалённая перезагрузка исправила ситуацию.

 Отправлено: 15.04.14 20:23. Заголовок: Stalker пишет: дат..

Stalker пишет:

цитата:

дата/время сбилось до 1906-12-08... Удалённая перезагрузка исправила ситуацию.

Именно эту ситуацию я и описывал...
Проблема выявлена давно. Волнует вопрос, когда эта ситуация будет устранена, так как время сильно влияет на работу системы...

 Отправлено: 15.04.14 23:18. Заголовок: Я же написал - в сис..

Я же написал - в системе время работало нормально. Консоль передавала неправильное время только на сервер мониторинга. А в остальном - СМС, видео, работа выходов по расписанию - время выглядело как положено.

 Отправлено: 15.04.14 23:48. Заголовок: Stalker пишет: Прич..

Stalker пишет:

цитата:

Причём дата/время сбилось до 1906-12-08 на обоих серверах мониторинга.

Я вот щас залез ручками в базу, там 2 есть колонки - серверное время и консольное. Примерно такие значения (совершенно случайная выборка):
2013-03-06 18:58:41 -> 1906-12-08 02:01:52
2014-02-20 19:57:56 -> 1906-12-08 02:00:52
2012-12-22 15:57:30 -> 1906-12-08 02:00:49
2014-04-11 19:25:08 -> 1905-05-29 17:02:52

Т.е. сбрасывает чего-то на 1905-1906 года, но даты менее 1905-05-30 01:01:52 нет, это самое минимальное среди всех значений всех имеи за все время.

 Отправлено: 17.04.14 12:13. Заголовок: Проблемы у меня возн..

Проблемы у меня возникли - помогите разобраться.
Вот было тестовое событие, оно прошло 2014-04-15 12:53:13 (серверное время), 2014-04-15 12:53:00 (консольное время). Интервал тестового события в настройках - 6 минут.
Смотрите какое время у следующего тестового события:
2014-04-15 13:08:19 - серверное, 2014-04-15 12:59:00 - консольное.
Т.е. тут в моем понимании все правильно: 12:53 + 6 минут = 12:59, но из-за проблем со связью оно было передано в 13:08

Иной вариант:
16:17 было тестовое событие, следующее тестовое событие теоретически должно быть в 16:17 + 6 минут = 16:23
А происходит следующее: событие приходит в 16:29 по серверу и время консоли тоже указано 16:29.
Почему время консоли 16:29 ? (а не 16:23).

Т.е. вот 2 конкретных примера задержки тестового события , но время консоли формируется по разному. Почему так?

 Отправлено: 17.04.14 13:06. Заголовок: izograv пишет: 16:1..

izograv пишет:

цитата:

16:17 было тестовое событие, следующее тестовое событие теоретически должно быть в 16:17 + 6 минут = 16:23 А происходит следующее: событие приходит в 16:29 по серверу и время консоли тоже указано 16:29. Почему время консоли 16:29 ? (а не 16:23).

16.17+6= 16.23
16.23+6= 16.29

Видимо потерялся в 16.23, а почему сказать мог бы видя логи прибора. А так это гадания....

 Отправлено: 17.04.14 13:15. Заголовок: dem пишет: Видимо ..

dem пишет:

цитата:

Видимо потерялся в 16.23

Видимо да, мне это в голову не приходило :)

Если Вам не трудно, пож. напомните действия прибора в случае, если он не может передать тестовое или иное событие на сервер мониторинга: сколько раз он пытается событие протолкнуть и что делает, если все попытки неудачные - рестарта вроде не происходит, т.к. IP не меняется.

 Отправлено: 17.04.14 13:52. Заголовок: Три попытки и переза..

Три попытки и перезапуск GSM модуля... И снова 3 попытки...

 Отправлено: 17.04.14 14:27. Заголовок: dem пишет: Три попы..

dem пишет:

цитата:

Три попытки и перезапуск GSM модуля... И снова 3 попытки...

Судя по поведению прибора, это не касается тестовых сообщений, тест часто теряется, или перебивается сообщениями о сработке выходов, тревогами и передачей видео кадров...

 Отправлено: 17.04.14 14:34. Заголовок: bajt пишет: Судя по..

bajt пишет:

цитата:

Судя по поведению прибора, это не касается тестовых сообщений, тест часто теряется, или перебивается сообщениями о сработке выходов, тревогами и передачей видео кадров.

Кстати да, и однотипные события в очередь отправки не ставятся... Если в очереди (прибора) 2 тестовых - одно удаляется...

 Отправлено: 18.04.14 16:24. Заголовок: Я понял к вечеру при..

Я понял к вечеру причину "потерь" некоторых сообщений - хоть она и тривиальна, но до меня совсем не сразу дошло.
У меня стоит в адресах сервера 2 разных сервера мониторинга. При плохой связи сообщение не уходит на первый сервер, но уходит на второй. Соответственно потом на первом сервере это выглядит так, будто одно из сообщений "потерялось" - хотя на самом деле потери не было, поэтому и не было перезагрузок gsm-модуля и поэтому не менялся IP.

Т.е. логично ставить один сервер мониторинга - тогда сообщения не должны теряться, но могут быть проблемы при ситуациях недоступности сервера мониторинга.
Если 2 разных сервера - недоступность исчезает на 100%, но могут "пропадать" сообщения на основном сервере мониторинга при плохой связи.

Поэтому тут сам каждый для себя решает, что более правильно или ему более подходит.

ps: написал и задумался - а в чем тогда вообще смысл двух полей для сервера мониторинга? Именно с теоретической точки зрения разработчиков? Такой ответ в голову приходит: 2 поля - это 2 разных адреса серверов мониторинга, расположенных в разных ДЦ, базы которых синхронизированы по принципу Master-Master. Тогда обеспечивается и надежность и отсутствие "пропаж". Но это наверное справедливо для более крутых охранных систем с полноценным пультом, тревожной группой, большим числом клиентов. где "цена ошибки" высокая.

 Отправлено: 18.04.14 16:34. Заголовок: izograv пишет: ps: ..

izograv пишет:

цитата:

ps: написал и задумался - а в чем тогда вообще смысл двух полей для сервера мониторинга? Именно с теоретической точки зрения разработчиков? Такой ответ в голову приходит: 2 поля - это 2 разных адреса серверов мониторинга, расположенных в разных ДЦ, базы которых синхронизированы по принципу Master-Master. Тогда обеспечивается и надежность и отсутствие "пропаж".

На стороне ПЦН даже с одной базой событий два (физически) канала связи - два сервера...

 Отправлено: 28.04.14 21:29. Заголовок: dem пишет: Три попы..

dem пишет:

цитата:

Три попытки и перезапуск GSM модуля... И снова 3 попытки...

Что такое "перезапуск GSM модуля?" Подразумевается при этом смена IP (как при перезагрузке *875) или нет?

 Отправлено: 29.04.14 08:08. Заголовок: izograv пишет: Что ..

izograv пишет:

цитата:

Что такое "перезапуск GSM модуля?"

Грубо выключили питание - включили питание GSM-модуля SIM900R. А *875 это перезапуск процессора который в свою очередь перезапускает GSM-модуль. При любом из этих действий будет обрыв GPRS сессии и, как следствие смена IP.

 Отправлено: 29.04.14 08:46. Заголовок: dem пишет: При люб..

dem пишет:

цитата:

При любом из этих действий будет обрыв GPRS сессии и, как следствие смена IP.

Не происходит такого. Нет смены IP, нет обрыва сессии.

На 3mob начали шалить с NAT -ом, поэтому мне нужно иногда перегружать сессию для получения нового IP. Через DTMF лично мне это делать неудобно и дорого (каждый звонок - 50 коп). Возникла идея делать в таком случае временно недоступным сервер мониторинга - чтобы прибор сам перегрузился и сменил IP (это программно очень легко и удобно делать; я понимаю, что сама идея дикая, но просто выхода другого нету).
Вчера пробовал: разными средствами (через php или апачем) начал выдавать прибору разные "плохие" заголовки ответа на POST , например пробовал 403 и 504. После этого происходит следующее:
- заголовки реально передаются прибору, вот пример записей из логов:
46.202.206.35 - - [28/Apr/2014:23:49:47 +0300] "POST / HTTP/1.0" 403 - "-" "Universal 3.3.9.6"
46.203.25.28 - - [29/Apr/2014:00:27:13 +0300] "POST / HTTP/1.0" 504 - "-" "Universal 3.3.9.6"
- прибор действительно реагирует на такие заголовки, т.е. действительно в приборе работает алгоритм проверки кодов ответа сервера - вместо события test раз в 6 минут прибор начинает ломиться на каждый из двух адресов серверов мониторинга с интервалом ровно 2 минуты. Но: так происходит бесконечно (я целый час пробовал), смены IP не происходит

Вот и пытаюсь понять, почему так. Или что-то не так работает в жизни, как положено в теории, или у меня не совсем новая прошивка (конфигуратор 3.9.6.215), и в этой прошивке нет перезагрузки при недоступности сервера мониторинга.

 Отправлено: 29.04.14 09:31. Заголовок: прошивка 3.3.9.11 ко..

прошивка 3.3.9.11 конфигуратор 3.9.11.223
Заметил еще одну неприятную закономерность, если отключить синхронизацию времени через интернет, то периодически теряется связь с сервером, причем на несколько часов. Трижды проверял, на совпадение не похоже, если синхронизация включена, со связью никаких проблем (периодически время глючит), выключаеш - время не глючит (но проблемы со связью). Оператор 3моб.

 Отправлено: 29.04.14 10:43. Заголовок: izograv пишет: Вот ..

izograv пишет:

цитата:

Вот и пытаюсь понять, почему так. Или что-то не так работает в жизни, как положено в теории, или у меня не совсем новая прошивка (конфигуратор 3.9.6.215), и в этой прошивке нет перезагрузки при недоступности сервера мониторинга.

Данный алгоритм неоднократно менялся и сказать конкретно про указанную версию прошивки ничего не могу.

bajt пишет:

цитата:

Заметил еще одну неприятную закономерность

Проверим...