|
Notes |
|
|
|
Общая логика мониторинга пока что такова.
В 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. Всё прочее по мелочи.
Пока бросаться переводить менюшки, тестить баги и т.п. не надо. Максимум что надо - трезвым взглядом со свежей головой посмотреть на это, и что-нибудь мудрое придумать, или нелогичность какую выискать, идею толкнуть. А то у меня уже в голове всё перемешалось с этим мониторингом. |
|
|
|
|
|
ИМХО передача своих координат и получение данных с сервера мониторинга это две почти независимые задачи и связывать их в одно целое смысла особого нет. |
|
|
|
|
А между ними и так связь только:
а) один пункт меню (подпункт у Monitoring) - визуально;
б) одна настройка логина, пароля,... - потому что она одна для обоих задач (фактически это настройка сервиса).
И всё. Потоки отдельные. Даже реализация отдельная. Включение-отключение независимое, настройки - тоже.
В частности, даже при отключенном GPS можно получать данные от сервисов.
А также можно сделать, чтобы на сервис только писалось. Или с него только забиралось. |
|
|
|
(0010871)
|
|
zed
|
|
14-03-2013 18:27
|
|
|
В инишках ничего не писал, никаких папок не создавал - при запуске AV |
|
|
|
|
>при запуске AV
Принято и исправлено |
|
|
|
|
Приаттачил 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
|
|
05-04-2013 08:29
|
|
1 Создал папку Monitoring и положил туда содержимое архива.
2 Дописал в ini
[Monitoring]
Available=1
Enabled=1
AllowSavePrivateData=1
PrimaryPath=Monitoring\
Запустил последнюю ночнушку и не вижу в меню пункта Monitoring :(
Может ещё что-то надо сделать? |
|
|
|
|
>Дописал в ini
Может там уже была такая секция?
У меня всё работает. |
|
|
|
(0011020)
|
|
Fetser
|
|
05-04-2013 11:23
|
|
>Может там уже была такая секция?
Совершенно верно - она создалась автоматически, а я не заметил и сделал ещё одну.
Всё появилось :) |
|
|
|
|
|
На всякий случай напоминаю, что единственная по большому счёту причина, почему тикет ещё не закрыт, это то, что точки создаются/изменяются в базе меток, а не в своей отдельной базе мониторинга, чего хотелось бы сделать по аналогии. |
|
|
|
(0013497)
|
|
Viktor
|
|
06-01-2014 14:55
|
|
Можно я один момент еще скажу, надеюсь стоящий, чтобы на него обратить внимание.
Ведь сейчас в САС координаты юзер имеет с GPS\Глонасс-приемника... А если всё дело для мониторинга объектов будет заточено под трекеры, то и объект на котором САС сам тоже может работать через трекер. Кроме того, есть и продвинутые трекеры, которые, например, могут цепляться за датчики авто, т.е. передавать сколь угодно много параметров в перспективе. Это я к тому, что будет ли смысл в чистом только приемнике; а также и сразу понимать спектр возможных передаваемых параметров. Кто вообще сказал, что объект мониторинга должен быть подвижным?! Это готовая и охранная система, и "умный дом", и что угодно еще... Вопрос лишь в том - что и какие параметры будет передвать. И у оператора все сигналы будут на общей карте - хоть каких объектов. Вообще, за такими вещами будущее. Это не только для контор было бы востребовано, но и для частных лиц. Такой путной системы и с хорошими картами в России мне не известно... Даже у ОВО более лажовые системы... Которые глючат так нормально... |
|
|
|
|
>если всё дело для мониторинга объектов будет заточено под трекеры
Ситуация в реальности совершенно обратная: трекеры затачиваются под сервис настройкой того, что и куда отправлять (формированием строки запроса).
Поэтому "если всё дело" - неверно по сути, никаких "если" уже не надо. Достаточно на трекере сформировать нужную строку запроса для GET.
>передавать сколь угодно много параметров в перспективе
Совершенно не проблема, и эти параметры прилетят в сас "как есть".
>также и сразу понимать спектр возможных передаваемых параметров
Глупость, и вот почему. Добавление нового произвольного параметра должно приводить к переписыванию системы? Очевидно, что не должно. Поэтому и глупость. Так что какие там будут дополнительные произвольные параметры - совершенно неважно.
>Кто вообще сказал, что объект мониторинга должен быть подвижным?!
Хм. А что Вы хотите в САСе от таких неподвижных объектов? Сменить иконку и описание? )))))))))))))
>у оператора все сигналы будут на общей карте
И оператор и его канал становятся слабым звеном )))))
Сигналы о событиях лучше слать не в сас, это чуть более чем очевидно. |
|
SASPlanet.elf (28,165) 14-03-2013 18:26
Monitoring_Scripts.rar (3,827) 22-03-2013 10:08