Користувальницькькі налаштування

Налаштування сайту


Сайдбар

Розділи

Загальний опис
Історія змін
Рекомендації до оновлення
Плани на майбутнє
Відомі проблеми
Онлайн демо
Відео
Допомога проекту
Люди
Трохи про безпеку

FAQ



Редагувати сайдбар

visor

Облік відеоспостереження aka Visor

Призначення

  • Тарифікація наданих користувачам послуг відеоспостереження
  • Надання можливості бандлування цих послуг з існуючими обліковими записами інтернету
  • Забезпечення прозорості тарифікації послуг відеоспостереження для користувача
  • Інтеграція із зовнішніми NVR на тему розмежування прав користувачів

Суть

  • Кожна камера є сама по собі користувачем інтернету
  • У будь-який момент ви можете зробити з будь-якого користувача “камеру”
  • У будь-який момент ви можете прикріпити цю “камеру” до будь-якого існуючого користувача відеоспостереження
  • Кожна камера тарифікується власне “як інтернет” відносно її тарифного плану.
  • “Користувачі відеоспостереження” - це абсолютно окрема сутність, яка потрібна тільки для зв'язку камер “з чимось”
  • У “користувача відеоспостереження” може бути зв'язок у вигляді основного облікового запису у вигляді реального користувача інтернету або навіть камери (яка теж користувач)
  • У основного облікового запису, в профілі/кабінеті будуть відображатися всі пов'язані камери а також з цього облікового запису, будуть зніматися кошти в разі потреби
  • Для користувачів відеоспостереження автоматично генеруються логіни/паролі на DVR вигляду view[id]/циферки (так, так зручніше набирати на телефонах)
  • На даний момент реалізована інтеграція з NVR на базі WolfRecorder та Trassir Server.
  • Якщо у вас виникає питання “а як же мій Dahua/Hikvision/Tyto/Partisan? Чому так дорого?” - співчуваємо, це означає лише те, що у вас відбувається критична помилка: “у вас не достатньо грошей, щоб надати нормальні послуги відеоспостереження”.

Початкове налаштування

В alter.ini

; Вмикаємо Visor
VISOR_ENABLED=1
; Режим нарахування коштів Visor. 1 - за замовчуванням, камери в пріоритеті гроші забираються з головного акаунту нескінченно, щоб забезпечити
; безперервну роботу всіх пов'язаних камер. Заганяємо головний обліковий запис у глибокий мінус.
; 2 - сервіс інтернету головного облікового запису в пріоритеті. Нарахування коштів на користь камер буде відбуватися лише поки на рахунку користувача
; залишається коштів більше за нуль.
VISOR_CHARGE_MODE=1
; Показуємо у профілі основного користувача, що він має послуги відеоспостереження.
VISOR_IN_PROFILE=1
;Використовувати кешовані дані користувачів чи отримувати з БД їх щоразу? Про продуктивність.
VISOR_CACHED_USERDATA=1

В userstats.ini

VISOR_ENABLED=1
API_URL="http://127.0.0.1/billing/"
API_KEY="UBxxxxxxxxxxxxxxxxxxxxxxxx"

В crontab:

40 23 * * *  /bin/ubapi "visorcharge"

Так, зняття коштів на користь камер з основного облікового запису, передбачається до нарахування коштів за інтернет в останній день місяця.

Використання

Тиць

Додаємо DVRи на яких житимуть камери

Реєструємо користувача відеоспостереження, якому належать камери

І вписуємо або вибираємо “з камер” йому головний обліковий запис.

Можливість вибрати обліковий запис камери, як головний потрібна для тих випадків, якщо у користувача взагалі немає наданого вами інтернету (наприклад це якесь будівництво, гаражі або відеоспостереження за дитячим майданчиком або собачою будкою). Призначення однієї з камер на цьому об'єкті дозволить вносити кошти для функціонування всіх пов'язаних камер лише на основний обліковий запис.

Далі просто реєструємо камеру як звичайного користувача

Припустимо, вона у вас забиратиме інтернети отримуючи адресу по DHCP.

Далі робимо з цього користувача камеру в кілька кліків

І присвоюємо її відразу ж нашому користувачеві відеоспостереження

Все готово. Тепер камера тісно пов'язана з користувачем відеоспостереження і зможе, коли їй потрібно знімати кошти з основного облікового запису для продовження своєї роботи.

Основний користувач, у свою чергу, повинен лише поповнювати свій рахунок на потрібну суму. У його профілі тепер світиться індикація, пов'язаного з ним “користувача відеоспостереження”

В кабінеті користувача він може ознайомитися з підключеною у нього послугою відеоспостереження, кількістю камер і тому, як і куди, йому за це все платити:

Ось якось так виглядає зняття коштів камерами з основного акаунту в “русі коштів”:

Загалом це все, що відбувається щодо тарифікації. Завдання користувачів - оплачувати послуги зберігання вами їхніх даних на ваших NVR, ваше завдання тарифікувати кожну камеру.

У вас може виникнути питання “і це все?” Ні, звичайно ж, не все. Ми ж любимо красиві та автоматизовані рішення. Читаємо далі.

Інтеграція з Trassir Server

Призначена для зберігання відеоданих на таких пристроях під управлінням TRASSIR OS і включається однією опцією alter.ini:

;Чи включено інтеграцію з NVR на базі Trassir Server?
TRASSIRMGR_ENABLED=1
;Чи використовувати HLS для прев'ю каналів на TrassirNVR? (якщо вимкнено - використовуватиметься MJPEG)
TRASSIRHLS_ENABLED=0

І РАПТОВО панель контролів VISOR починає виглядати наступним чином

Реєструвати камери та пов'язаних з ними користувачів на NVR Trassir можна прямо з інтерфейсу редагування камери в декілька кліків за допомогою самоочевидного візарду

Слід також помітити, що станом на стабільний реліз Ubilling 1.0.5 iris автодетектування моделі камери не працює з невідомих причин причини зламаності API Trassir SDK. Тому для тимчасового спрощення вибору моделей камер, додана механіка “камер із зірочкою”. Зазирніть в content/documents/visormodels/ і вам відразу стане зрозуміло, за яким принципом моделі камер конкретного вендора розміщуються вгорі списку і позначаються як “ті, що часто використовуються” зірочкою.

Стоп, а для чого ми реєстрували камеру на NVR? А потім, щоб вона таки взяла і з'явилася на реєстраторі, породивши “канал”, яким ми можемо вже більш-менш керувати з інтерфейсу Ubilling.

Так, “жовтенькі” канали - не привласнені користувачеві, зелененькі - вже навішені на когось. Зв'язок канал-користувач теж відбувається між каналом на конкретному DVR та “користувачем відеоспостереження”. Робиться це з редагування користувача чи у інтерфейсі редагування каналу. При переході до інтерфейсу редагування каналу з профілю користувача

в інтерфейсі каналу відразу буде обрано користувача з профілю якого було здійснено перехід в інтерфейс редагування каналу, для мінімізації кількості кліків

Коротше, принцип навішування каналів користувачів відеоспостереження наслідує концепцію вибору з “нічийних” ONU модулю ПОНізатор.

Як наслідок всіх цих рухів тіла, користувач відразу ж у себе в кабінеті отримує додатковий функціонал за попереднім переглядом присвоєних йому каналів в різній якості, можливості завантаження потрібного ПЗ і список даних для доступу до NVR на яких знаходяться дані з його камер.

Так, на кожного користувача ви можете навішувати скільки завгодно камер та каналів. Так, ще раз нагадуємо - “камери це про тарифікацію”, а “канали це про перегляд і доступ”. Єдине обмеження на даний момент - камера або канал можуть бути присвоєні лише одному конкретному користувачеві в той самий момент часу. Заміна зв'язаного користувача каналу, робиться просто переклікуванням на потрібного в інтерфейсі редагування каналу.

Стопе. А що у кабінеті у розділі “завантаження” відеоспостереження? А ось що:

У що автоматично виливається ця особлива вулична магія на самому реєстраторі з погляду адміністратора:

Камери та відповідні канали вже автоматично зареєстровані

На реєстраторі вже доданий користувач з максимально обкусаними правами, що дозволяють лише дії перегляду

Йому вже навішано ACL для доступу тільки до “його” каналів.

А ось все, що бачить і може зробити з реєстратором користувач, при заході зі своїм логіном viewXX

Власне цю ж картину він спостерігатиме і у своєму прикладному ПЗ:

А так, ще ми можемо швиденько проконтролювати самопочуття наших NVR:

Інтеграція з WolfRecorder

Документація буде трішки згодом.

visor.txt · Востаннє змінено: 2023/06/14 11:11 повз nightfly