Якщо ви під’єднали IP камери Dahua до NVR, а потім бачите, що в системі дві камери раптом мають однакову адресу — це майже завжди означає конфлікт на рівні мережевої взаємодії. У цьому матеріалі розберемо, як розпізнати причину та що робити, щоб відеонаблюдение знову запрацювало стабільно.


Уявіть ситуацію як в житті

У вас стоїть монтаж: частина камер підключена напряму до портів відеореєстратора, а ще кілька камер — через комутатор. Все працює, поки не станеться одне з двох:
- вимкнення живлення або перезапуск питание на комутаторі;
- перезавантаження система NVR/комутатора після перебоїв.

І тоді ви бачите дивне: камери “плутаються”, IP повертається назад, або NVR намагається призначити одну й ту саму адресу двом пристроям.


В чому була проблема на реальному кейсі Dahua

У прикладі з форуму було описано конфлікт, коли дві камери мали MAC адреси, відрізнявшись лише останнім символом. Через це NVR видавав однаковий IP адрес двом камерам:
10.1.1.77... (для обох).

Проблема проявлялась так:
- до перезавантаження все можна було “підправити” вручну: змінити настройка IP у веб панелі;
- але після перезапуску/втрати живлення комутатора конфлікт повертався, і IP “знову ставав тим самим”.

Це дуже важливо: навіть якщо ви разово зробили решение, конфлікт може повторюватись після мережевих подій.


Які моделі NVR та камери брали участь у конфлікті

З опису кейсу:

Тип Модель
NVR DHI-NVR4216-16P-4KS2/L
Камери IPC-HFW2831S-S-S2 (8 камер цього типу)

Які версії прошивок були

У тому ж кейсі зафіксовані такі версія:

Пристрій Версія прошивки
NVR 4.000.0000001.0
Камери 2.800.0000000.19.R

Чи допомагає оновлення прошивки

У описаному випадку оновлення прошивки NVR та камер не допомогло: конфлікт повторювався.

Тобто якщо ваші проблеми такі ж за симптомами, не варто розраховувати, що “просто оновлення” автоматично прибере повтор IP назавжди.


Чи допомагає скидання до заводських

Також в кейсі скидання налаштувань до дефолту (і через кнопку, і через ConfigTool) та подальша переналаштовка не вирішили проблему.

Висновок простий: інколи проблема не в “неправильних налаштуваннях користувача”, а в тому, як система видає/оновлює мережеві параметри.


Вплив статичних IP і DHCP

У кейсі пробували і статический IP, і DHCP на камерах. Але після перезавантаження комутатора конфлікт все одно з’являвся для камер із близькими MAC.

Це означає, що проблема проявлялась саме під час перезапусків/обміну параметрами, а не тільки через те, що десь “включений DHCP”.


Які заходи реально допомогли

Найефективніше рішення в цьому прикладі було “організаційне”, але дуже практичне:

  1. Рознести проблемні камери по різних сегментах підключення.
  2. Одну з “парної” камери підключити по кабелю до NVR напряму.
  3. Другу підключити через комутатор і для неї виставити статик.

Після такого “рознесення” конфлікт перестав повторюватись (принаймні в межах описаної конфігурації).

Чому це могло спрацювати

Коли одна пара камер знаходиться в одному мережевому середовищі, а їх MAC надто схожі, система може помилково прив’язати конфігурацію. Рознесення зменшує ймовірність того, що одна й та сама логіка призначення IP торкнеться одразу обох.


Вплив Bonjour і як це перевірити

В іншій відповіді в тій же гілці згадали спробу:
- відключити Bonjour сервіси на камерах і на реєстраторі.

Логіка тут проста для розуміння: інколи мережеві сервіси можуть “взаємодіяти” між пристроями не так, як очікується, і додаткові протоколи/оголошення можуть підмішуватися до роботи мережевих функцій. Тому цей крок варто спробувати, якщо в інтерфейсі камери/реєстратора є така опція.


DHCP на NVR чи функції комутатора

У кейсі припускали, що причина може бути:
- у старій версії DHCP сервера на NVR або
- у DHCP/поведінці коммутатора.

Це виглядає логічно: під час подій типу “пропало живлення” DHCP і механізми оновлення можуть працювати не ідеально, а дві камери з близькими параметрами можуть “отримати” однаковий результат.


Чому IP на камерах “відкочується” після втрати живлення комутатора

В описаній ситуації причина відрізнялася для різних ліній живлення.

  • Якщо NVR підключений через UPS, то навіть коли пропадає живлення в мережі, камери можуть не втрачати зв’язок повністю, і IP не змінюється.
  • Але камери, які живляться/перемикаються через комутатор без UPS, після завершення живлення повертаються назад: після відновлення живлення вони знову ініціалізуються, і NVR/мережеві сервіси можуть перезаписати адреси.

Інакше кажучи:
відсутність живлення на комутаторі запускає повторну “сесії ініціалізації”, і система може знову застосувати те, що вже колись налаштувалось або “підхоплюється” помилково.


Як вручну переналаштувати IP після втрати живлення

Якщо проблема повторюється після перебоїв і потрібно швидко відновити роботу, діяти треба по порядку:

Мінімальний чеклист

Крок Що зробити Навіщо
1 Після відновлення живлення дочекатися, поки камери піднімуться IP ще може перерахуватись “в процесі”
2 Зайти в веб інтерфейс камеры там бачите реальні адреси
3 Перевірити IP, маску, шлюз конфлікт інколи виглядає як “вже є адреса”
4 Для проблемних камер виставити статический IP вручну зменшує ризик повторного DHCP призначення
5 Переконатися, що ці адреси не повторюються перевірка відразу в NVR або в мережі

Практична порада

Працює підхід “дві сусідні адреси не поруч”. Наприклад, якщо одна камера має 10.1.1.88, то другій не давайте 10.1.1.89 лише через “зручність” — краще виділити їм різні зони адресного простору, щоб мінімізувати помилки прив’язки.


Альтернативи, окрім рознесення і ручного IP

Якщо ви не хочете або не можете розводити кабель по різних сегментах, є ще варіанти, які часто допомагають (або хоча б зменшують частоту проблем):

  1. Вимкнення Bonjour на камерах і на реєстраторі (як спроба для “мережевих оголошень”).
  2. Перевірка налаштувань DHCP:
  3. де саме DHCP має “бути авторитетним” (на NVR чи на окремому сервері/роутері);
  4. чи не відбувається конфлікт видачі адрес у різних компонентах.
  5. Зменшити кількість “факторів перемішування”:
  6. однаковий модельний ряд камер — добре, але конфлікт виникає при дуже близьких ідентифікаторах;
  7. якщо в системі є “пара” з близьким MAC — це сигнал, що її варто особливо контролювати.

Якщо ваша задача інша. RTSP з Dahua в VLC

Пошукова фраза була про порт IP камери Alhua, але за логікою матеріал буде корисним і для Dahua. RTSP часто потрібен, коли камера показує “є в мережі”, але в плеєрі треба швидко відкрити потік.

Підтримувані протоколи

Для Dahua зазначають підтримку:
- TCP
- UDP

А RTSP зазвичай йде на порт 554 (але його можна змінювати в налаштуваннях камери).


RTSP посилання Dahua Technology в форматі

Базовий шаблон:

rtsp://<username>:<password>@<ip>:<port>/cam/realmonitor?channel=<channelNo>&subtype=<typeNo>

Розшифровка частин

Частина Що означає
username:password логін і пароль камери
<ip> IP адреса камери
<port> за замовчуванням 554 (якщо змінено — ставте свій)
channel=<channelNo> номер каналу, нумерація з 1
subtype=<typeNo> тип потоку: 0 основний, 1 додатковий, 2 додатковий

Приклад для додаткового потоку subtype=1:

rtsp://admin:admin@10.7.6.67:554/cam/realmonitor?channel=1&subtype=1

Як відкрити RTSP в VLC

  1. Відкрийте VLC
  2. Перейдіть в MediaOpen Network Stream (Відкрити URL)
  3. Вставте RTSP адресу в поле
  4. Натисніть Play (Відтворити)

Що робити, якщо порт 554 змінено

Якщо в веб інтерфейсі камери ви поставили інший порт, то в RTSP посиланні має бути той самий порт. Інакше VLC не зможе підключитись до потоку.


Які ще протоколи даних підтримують IP відеокамери Dahua

У межах наданих матеріалів по RTSP ключові речі такі:
- RTSP-поток використовує мережеві можливості камери, яка підтримує TCP і UDP.


Куди звертатися при проблемах з RTSP

У разі, коли RTSP не відкривається або “не видно відео”, логічний шлях:
- перевірити, що порт (554 або ваш інший) вказаний правильно;
- звірити channel і subtype (основний чи додатковий потік);
- звірити логін/пароль.

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


Підсумок що зробити прямо зараз

  • Якщо у вас конфлікт IP для камера з Dahua: спробуйте рознести проблемні пристрої (як у кейсі) та виставити статический IP для хоча б однієї з пар.
  • Для стабільності після перебоїв живлення: врахуйте, що питание на коммутаторі може “зривати” відновлення і запускати повторну ініціалізацію.
  • Для RTSP в VLC: використайте правильний шаблон rtsp://.../cam/realmonitor?channel=...&subtype=..., і якщо порт змінено — змініть його в посиланні.

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