0001850: Поддержка серверов мониторинга объектов (отправка своих координат и получение списка объектов)

Notes
(0010864) vasketsov (manager) 13-03-2013 20:31	Общая логика мониторинга пока что такова. В ini-шке под это дело выделяется секция [Monitoring] Available=1 Enabled=0 PrimaryPath=Monitoring\ Поле Available - это вообще возможность использовать. Enabled - это то, что пользователь выбрал. PrimaryPath - в этой подпапке будут лежать настройки (по умолчанию подпапка Monitoring). Если Available (и хотя бы один сервис настроен) - в главном меню появится раздел Monitoring с некоторыми пунктами. Позволяется одновременно работать более чем с одним сервисом мониторинга. Теперь про папку для настроек мониторинга. Каждая ini-шка в папке пытается трактоваться как файл настроект, само имя файла может быть произвольное. Содержимое ini-шки должно быть типа такого: [PARAMS] GUID={A03F4E35-EEEA-4484-8EA3-FBFE92F54395} Caption=Локальный мониторинг OptionsUrl=http://127.0.0.1:88/ Enabled=1 RequestUrl=http://127.0.0.1:88/s.php?{0}:{1}:{3}:{4}:{5}:{6}:{7}:{2}:{8} Pause=10000 [ScriptControl] Enabled=1 Filename=local_apache.txt Language=PerlScript Function=sas_main InputParamNames=uid,pwd,ukey,dkey Здесь Caption (заголовок менюшки) и OptionsUrl (необязательный адрес web-страницы с настройками сервиса) можно указывать так, как в zmp указываются параметры со значениями на нескольких языках. По GUID-у сохраняются и читаются пользовательские настройки. RequestUrl используется для задания адреса для отправки координат и прочих параметров. Pause - пауза между отправками (в миллисекундах). Данные берутся с GPS, если приёмник включен. Если не включен - ничего не отправляется. Секция ScriptControl традиционно используется для обозначения того, что в ней настраивается скрипт (причём Filename указывает на файл, лежащий рядом, в этой же папке). Он будет использоваться для ПОЛУЧЕНИЯ данных с сервиса. Так как для получения данных надо пройти авторизацию (ну или как минимум представиться, кто пришёл и за какими данными), а вариантов её чуть больше чем много - решено было вынести это в скрипт (в отличие от отправки координат, которая пока что просто HTTP GET, а потом поглядим). Равно как в скрипте можно хоть на вебсокетах и голубиной почтой данные получать, и все настройки там указать. Скрипт для получения данных запускается в потоке, и должен организовать внутри себя очередь по запросу данных с сервиса, получению, обработке их и поштучной отдаче в основную программу. Если вдруг скрипт упадёт - он перезапустится в потоке, но лучше этого избегать. Скрипту для получения данных передаются пока что 4 параметра. Это логин, пароль, и 2 произвольных ключа (хэша). Что он будет с ними делать - личное половое горе скрипта и его автора. Если надо ещё параметры - добавим ещё. Параметры (private data) сохраняются в реестре (если разрешено галочкой). Расшифровка параметров RequestUrl (вообще говоря отправлялка просто заменяет параметры, не проверяя их наличия, например timestamp необязательный): {0} - это lat (широта, десятичные градусы) {1} - это lon (долгота, десятичные градусы) {2} - это timestamp (unixtime) {3} - это hdop {4} - это altitude (высота, метры) {5} - это speed (скорость, метры в секунду) {6} - это ukey (первый ключ - пользовательский) {7} - это dkey (второй ключ - устройства) {8} - это picname (имя иконки) Пока что не сделано следующее (порядок примерно соответствует приоритету работы над пунктом): 1. Запуск скрипта. Просто потому что пока нет скрипта и не на чем тренироваться. 2. Нормальный слив данных из скрипта в основную программу. Сейчас разве что можно из скрипта отправлять команды на внуренний httpd и двигать метки. Вообще говоря надо будет сделать отдельный шлюзик через внутренний протокол, и двигать не совсем метки, а родные метки не трогать. Ну а если скорость слива не устроит - будем через IDispatch пробовать. 3. Параметр {8} ни в каком виде. Он очевидно заработает только после того, как будет понятно, как пользователь будет менять свою иконку (и на что, ибо клиентом мониторинга может выступать не только сас). Пока что такого понимания нет. 4. Всё прочее по мелочи. Пока бросаться переводить менюшки, тестить баги и т.п. не надо. Максимум что надо - трезвым взглядом со свежей головой посмотреть на это, и что-нибудь мудрое придумать, или нелогичность какую выискать, идею толкнуть. А то у меня уже в голове всё перемешалось с этим мониторингом.

(0010865) vdemidov (manager) 13-03-2013 21:33	ИМХО передача своих координат и получение данных с сервера мониторинга это две почти независимые задачи и связывать их в одно целое смысла особого нет.

(0010866) vasketsov (manager) 13-03-2013 21:48	А между ними и так связь только: а) один пункт меню (подпункт у Monitoring) - визуально; б) одна настройка логина, пароля,... - потому что она одна для обоих задач (фактически это настройка сервиса). И всё. Потоки отдельные. Даже реализация отдельная. Включение-отключение независимое, настройки - тоже. В частности, даже при отключенном GPS можно получать данные от сервисов. А также можно сделать, чтобы на сервис только писалось. Или с него только забиралось.

(0010871) zed (manager) 14-03-2013 18:27	В инишках ничего не писал, никаких папок не создавал - при запуске AV

(0010874) vasketsov (manager) 14-03-2013 21:14	>при запуске AV Принято и исправлено

(0010926) vasketsov (manager) 22-03-2013 10:44	Приаттачил Monitoring_Scripts.rar для игр. Чтобы начать играться - надо: 1. Содержимое архива сложить в подпапку Monitoring. 2. Потом не забыть в сасовой ini-шке написать: [Monitoring] Available=1 Enabled=1 AllowSavePrivateData=1 PrimaryPath=Monitoring\ 3. Потом запустить сас (начиная с завтрашней ночнушки). 4. Убедиться, что в менюшке появился пункт Monitoring. 5. Убедиться, что первые две галочки (включено и сохранение приватных данных) обе включены. 6. Зайти в подменюшку на выбор. Можно в одну из двух (в архиве настройка для двух одинаковых сервисов, отличие только в том, что это разные сервера у разных хостеров). Тот который biz - работает вроде бы побыстрее, но иногда валится по http 500. А другой помедленнее, но не валится. В вашем случае может быть по-другому. Итак, будем считать что сервис выбран. Что с ним делать - идём по адресу странички (она будет и в подменюшке, а можно и из ini её взять и открыть в чём хочется) и читаем в описании сервиса. Если коротко - там надо зарегицца, создать группу(ы), устройство(а), привязать себя и устройство(а) к группе(ам), опционально затащить в группу соседа ))). Чтобы другой сервис не мозолил глаза - можно в его инишке сделать ему Enabled=0 (в двух местах!) или вообще удалить. 7. После регистрации на сервисе идём в сас в подменюшку и жмакаем пункт для редактирования приватных данных. Там указываем логин и пароль (они нужны для аутентификации при получении данных мониторинга), а также пару ключей (пользовательский и устройства) - они будут нужны при отправке данных на сервис. Если какая-то часть не делается (например свои данные не уходят, а только надзор за устройствами в группе) - можно соответствующую часть не указывать. Если не включено сохранение этих данных - их придётся вводить при старте саса (специального запроса не будет, просто функциональность отвалится). 8. Только когда на сервисе зарегались и явки с паролями в сасе указали - только теперь запускаем GPS и включаем отправку данных на сервис (send). Убеждаемся, что на главной странице или на сранице с данными мониторинга есть запись и меняется время (то есть данные приходят на сервис). 9. Включаем получение данных. Несколько секунд придётся подождать. Но в итоге должна появиться метка, которая с небольшим опозданием начнёт бегать за маркером GPS. 10. Вся эта котовасия требуется только при первом запуске. Если включено сохранение приватных данных, если игнорируются ошибки - можно просто закрыть сас при включённом мноиторинге, при пвторном запуске всё поднимется само. По крайней мере так должно быть. А теперь об ограничениях, и о том, что возможно придётся поправить руками. 1. Скрипты работают с инетом напрямую. Если надо через прокси - качаем доку по LWP, учим perl, и делаем какой угодно блекджек с любыми шлюхами, или вообще переписываем на другой VBScript. 2. Отправка данных мониторинга в сас из скрипта осуществляется через запрос HTTP к внутреннему HTTP-серверу. В скриптах прописан адрес 127.0.0.1:7999 (как адрес по умолчанию) - при необходимости указываем свой руками. Также при необходимости правим руками строку запроса: my $mkr = 'http://127.0.0.1:7999/sas/ExternalMonitoring/..... 3. Покуда на сервисе не хранится никаких архивов координат, а только последняя координата - время с сервера прилетает только серверное, не клиентское. Так что отличие во времени, обусловленное неточностью часов и другой зоной, пугать не должно. 4. Поскольку я пока что не смог побороть глюк LWP при отправке нового запроса изнутри функции обратного вызова при работе из ScriptControl - скрипты настроены на запуск в невидимой консоли. Путь до интерпретатора указывается в iniшке в поле Interpreter: Interpreter=C:\Perl\bin\perl.exe При необходимости его надо поправить на реальный. 5. Параметры командной строки (а при запуске скрипта во внешней консоли это в реальности те самые приватные данные) передаются в интерпретатор открытым текстом. Если это опасно и страшно, то после игр что-нибудь придумаем. 6. Сервисы работаю только через HTTP. Никаких SSL. Вообще в скриптах используется такой запуск, который должен правильно работать и из ScriptControl, и из консоли (при передаче параметров через командную строку), это сделано через runconsole специально. Если вдруг баг LWP внутри ScriptControl поборется - можно будет runconsole просто удалить.

(0011013) Fetser (reporter) 05-04-2013 08:29	1 Создал папку Monitoring и положил туда содержимое архива. 2 Дописал в ini [Monitoring] Available=1 Enabled=1 AllowSavePrivateData=1 PrimaryPath=Monitoring\ Запустил последнюю ночнушку и не вижу в меню пункта Monitoring :( Может ещё что-то надо сделать?

(0011018) vasketsov (manager) 05-04-2013 11:17	>Дописал в ini Может там уже была такая секция? У меня всё работает.

(0011020) Fetser (reporter) 05-04-2013 11:23	>Может там уже была такая секция? Совершенно верно - она создалась автоматически, а я не заметил и сделал ещё одну. Всё появилось :)

(0013495) vasketsov (manager) 05-01-2014 23:23	На всякий случай напоминаю, что единственная по большому счёту причина, почему тикет ещё не закрыт, это то, что точки создаются/изменяются в базе меток, а не в своей отдельной базе мониторинга, чего хотелось бы сделать по аналогии.

(0013497) Viktor (reporter) 06-01-2014 14:55	Можно я один момент еще скажу, надеюсь стоящий, чтобы на него обратить внимание. Ведь сейчас в САС координаты юзер имеет с GPS\Глонасс-приемника... А если всё дело для мониторинга объектов будет заточено под трекеры, то и объект на котором САС сам тоже может работать через трекер. Кроме того, есть и продвинутые трекеры, которые, например, могут цепляться за датчики авто, т.е. передавать сколь угодно много параметров в перспективе. Это я к тому, что будет ли смысл в чистом только приемнике; а также и сразу понимать спектр возможных передаваемых параметров. Кто вообще сказал, что объект мониторинга должен быть подвижным?! Это готовая и охранная система, и "умный дом", и что угодно еще... Вопрос лишь в том - что и какие параметры будет передвать. И у оператора все сигналы будут на общей карте - хоть каких объектов. Вообще, за такими вещами будущее. Это не только для контор было бы востребовано, но и для частных лиц. Такой путной системы и с хорошими картами в России мне не известно... Даже у ОВО более лажовые системы... Которые глючат так нормально...

(0013519) vasketsov (manager) 08-01-2014 11:01	>если всё дело для мониторинга объектов будет заточено под трекеры Ситуация в реальности совершенно обратная: трекеры затачиваются под сервис настройкой того, что и куда отправлять (формированием строки запроса). Поэтому "если всё дело" - неверно по сути, никаких "если" уже не надо. Достаточно на трекере сформировать нужную строку запроса для GET. >передавать сколь угодно много параметров в перспективе Совершенно не проблема, и эти параметры прилетят в сас "как есть". >также и сразу понимать спектр возможных передаваемых параметров Глупость, и вот почему. Добавление нового произвольного параметра должно приводить к переписыванию системы? Очевидно, что не должно. Поэтому и глупость. Так что какие там будут дополнительные произвольные параметры - совершенно неважно. >Кто вообще сказал, что объект мониторинга должен быть подвижным?! Хм. А что Вы хотите в САСе от таких неподвижных объектов? Сменить иконку и описание? ))))))))))))) >у оператора все сигналы будут на общей карте И оператор и его канал становятся слабым звеном ))))) Сигналы о событиях лучше слать не в сас, это чуть более чем очевидно.

Users who viewed this issue
User List	Anonymous (1730x), hrucker (67x), zarius (2x)
Total Views	1799
Last View	25-04-2024 09:50

Issue History
Date Modified	Username	Field	Change
09-03-2013 14:55	vasketsov	New Issue
09-03-2013 14:55	vasketsov	Assigned To	=> vasketsov
09-03-2013 14:55	vasketsov	Status	new => assigned
10-03-2013 08:58	vasketsov	Summary	Поддержка сервера мониторинга объектов (отправка своих координат) => Поддержка серверов мониторинга объектов (отправка своих координат и получение списка объектов)
13-03-2013 20:31	vasketsov	Note Added: 0010864
13-03-2013 21:33	vdemidov	Note Added: 0010865
13-03-2013 21:48	vasketsov	Note Added: 0010866
14-03-2013 18:26	zed	File Added: SASPlanet.elf
14-03-2013 18:27	zed	Note Added: 0010871
14-03-2013 21:14	vasketsov	Note Added: 0010874
22-03-2013 10:08	vasketsov	File Added: Monitoring_Scripts.rar
22-03-2013 10:44	vasketsov	Note Added: 0010926
05-04-2013 08:29	Fetser	Note Added: 0011013
05-04-2013 11:17	vasketsov	Note Added: 0011018
05-04-2013 11:23	Fetser	Note Added: 0011020
05-01-2014 23:23	vasketsov	Note Added: 0013495
05-01-2014 23:23	vasketsov	Relationship added	related to 0002295
06-01-2014 14:55	Viktor	Note Added: 0013497
08-01-2014 11:01	vasketsov	Note Added: 0013519

SASGIS