Форум » GSM Universal » Проблема с прошивками по и конфигуратора (продолжение) » Ответить
Проблема с прошивками по и конфигуратора (продолжение)
art-314: Здрасьте у меня такая проблема: версия по 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 скорей всего проблемы у вас---пишите одно, делаете другое, а мы из-за вас теряем заказчиков, до этого на более старых версиях всё работает отлично, без нареканий. Вы пожалуйста разберитесь у себя побыстрей и напишите что мне делать и где взять по и конфигуратор одной версии!!!!
bajt: dem пишет: По поводу часов видимо сбой при синхронизации времени с NTP сервером, отключите синхронизацию... Почему тогда после команды сброса(*875) время восстанавливается? Раз, а то и два раза в неделю происходит сбой времени, причем сам этот сбой не устраняется(при последующих синхронизациях) прошивка 3.3.9.11 конфигуратор 3.9.11.223. В описаниях новых прошивок про время нет ни слова.
kader_ivan: bajt пишет: Раз, а то и два раза в неделю происходит сбой времени Не выяснили причину сбоя времени, может кратковременные пропадания\восстановление питания, провалы сети GSM?
bajt: kader_ivan пишет: Не выяснили причину сбоя времени, может кратковременные пропадания\восстановление питания, провалы сети GSM? Нет, эти факторы не влияют, но синхронизация с NTP сервером похоже все же виновата, правда, непонятно как и почему тогда после команды сброса(*875) время восстанавливается?... надо еще раз проверить, отключить синхронизацию, что-то в ней сбоит...
Stalker: Я сегодня обнаружил сбой синхронизации. Причём дата/время сбилось до 1906-12-08 на обоих серверах мониторинга. В СМС и на кадре, присланном на почту время было правильное. Удалённая перезагрузка исправила ситуацию.
bajt: Stalker пишет: дата/время сбилось до 1906-12-08... Удалённая перезагрузка исправила ситуацию. Именно эту ситуацию я и описывал... Проблема выявлена давно. Волнует вопрос, когда эта ситуация будет устранена, так как время сильно влияет на работу системы...
Stalker: Я же написал - в системе время работало нормально. Консоль передавала неправильное время только на сервер мониторинга. А в остальном - СМС, видео, работа выходов по расписанию - время выглядело как положено.
izograv: 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 нет, это самое минимальное среди всех значений всех имеи за все время.
izograv: Проблемы у меня возникли - помогите разобраться. Вот было тестовое событие, оно прошло 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 конкретных примера задержки тестового события , но время консоли формируется по разному. Почему так?
dem: 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, а почему сказать мог бы видя логи прибора. А так это гадания....
izograv: dem пишет: Видимо потерялся в 16.23 Видимо да, мне это в голову не приходило :) Если Вам не трудно, пож. напомните действия прибора в случае, если он не может передать тестовое или иное событие на сервер мониторинга: сколько раз он пытается событие протолкнуть и что делает, если все попытки неудачные - рестарта вроде не происходит, т.к. IP не меняется.
dem: Три попытки и перезапуск GSM модуля... И снова 3 попытки...
bajt: dem пишет: Три попытки и перезапуск GSM модуля... И снова 3 попытки... Судя по поведению прибора, это не касается тестовых сообщений, тест часто теряется, или перебивается сообщениями о сработке выходов, тревогами и передачей видео кадров...
dem: bajt пишет: Судя по поведению прибора, это не касается тестовых сообщений, тест часто теряется, или перебивается сообщениями о сработке выходов, тревогами и передачей видео кадров. Кстати да, и однотипные события в очередь отправки не ставятся... Если в очереди (прибора) 2 тестовых - одно удаляется...
izograv: Я понял к вечеру причину "потерь" некоторых сообщений - хоть она и тривиальна, но до меня совсем не сразу дошло. У меня стоит в адресах сервера 2 разных сервера мониторинга. При плохой связи сообщение не уходит на первый сервер, но уходит на второй. Соответственно потом на первом сервере это выглядит так, будто одно из сообщений "потерялось" - хотя на самом деле потери не было, поэтому и не было перезагрузок gsm-модуля и поэтому не менялся IP. Т.е. логично ставить один сервер мониторинга - тогда сообщения не должны теряться, но могут быть проблемы при ситуациях недоступности сервера мониторинга. Если 2 разных сервера - недоступность исчезает на 100%, но могут "пропадать" сообщения на основном сервере мониторинга при плохой связи. Поэтому тут сам каждый для себя решает, что более правильно или ему более подходит. ps: написал и задумался - а в чем тогда вообще смысл двух полей для сервера мониторинга? Именно с теоретической точки зрения разработчиков? Такой ответ в голову приходит: 2 поля - это 2 разных адреса серверов мониторинга, расположенных в разных ДЦ, базы которых синхронизированы по принципу Master-Master. Тогда обеспечивается и надежность и отсутствие "пропаж". Но это наверное справедливо для более крутых охранных систем с полноценным пультом, тревожной группой, большим числом клиентов. где "цена ошибки" высокая.
dem: izograv пишет: ps: написал и задумался - а в чем тогда вообще смысл двух полей для сервера мониторинга? Именно с теоретической точки зрения разработчиков? Такой ответ в голову приходит: 2 поля - это 2 разных адреса серверов мониторинга, расположенных в разных ДЦ, базы которых синхронизированы по принципу Master-Master. Тогда обеспечивается и надежность и отсутствие "пропаж". На стороне ПЦН даже с одной базой событий два (физически) канала связи - два сервера...
izograv: dem пишет: Три попытки и перезапуск GSM модуля... И снова 3 попытки... Что такое "перезапуск GSM модуля?" Подразумевается при этом смена IP (как при перезагрузке *875) или нет?
dem: izograv пишет: Что такое "перезапуск GSM модуля?" Грубо выключили питание - включили питание GSM-модуля SIM900R. А *875 это перезапуск процессора который в свою очередь перезапускает GSM-модуль. При любом из этих действий будет обрыв GPRS сессии и, как следствие смена IP.
izograv: 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), и в этой прошивке нет перезагрузки при недоступности сервера мониторинга.
bajt: прошивка 3.3.9.11 конфигуратор 3.9.11.223 Заметил еще одну неприятную закономерность, если отключить синхронизацию времени через интернет, то периодически теряется связь с сервером, причем на несколько часов. Трижды проверял, на совпадение не похоже, если синхронизация включена, со связью никаких проблем (периодически время глючит), выключаеш - время не глючит (но проблемы со связью). Оператор 3моб.
dem: izograv пишет: Вот и пытаюсь понять, почему так. Или что-то не так работает в жизни, как положено в теории, или у меня не совсем новая прошивка (конфигуратор 3.9.6.215), и в этой прошивке нет перезагрузки при недоступности сервера мониторинга. Данный алгоритм неоднократно менялся и сказать конкретно про указанную версию прошивки ничего не могу. bajt пишет: Заметил еще одну неприятную закономерность Проверим...
полная версия страницы