Mr. D

Загалом, можливо, навіть зробити port forwarding (звісно, саме для цього треба мати реальний IPv4/IPv6 - до речі, навряд є оператори, хто працює з IPv6) у напрямку Web-інтерфейсу NVR, який вже надає функціонал Live View або Playback. Працюють або ні всі NVR так не знаю, але деякі не останні за кількістю пристроїв компанії мають такий варіант.

Цікаво, мабуть, MikroTik задіяв якісь стороні сервери для початкового створення зв'язку. Схоже, так і є - "...through the MikroTik relay server...". help.mikrotik.com/docs/display/ROS/Back+To+Home Цікава функція. Можливо, комусь навіть спростить налаштування.

Цікаво, як часто Ви обслуговуєте ці 50+ бездротових пристроїв з автономним живленням? Кожний пристрій пару раз на рік треба зарядити або змінити тому пристрою батарейки. Або рідше?

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

Думаю, є залежність від навантаження частотного діапазону в цілому. Або залежить від якості самих тих пристроїв IoT.

Загалом VPN є сенс використовувати для під'єднання до закритої (приватної) мережі. Тому з точки зору систем відеонагляду VPN - це щось, про що система відеонагляду не турбується та не знає, що таке існує. VPN - це суто про налаштування сучасної IP-мережі, яку системи відеонагляду використовують як транспорт для зв'язку окремих компонентів. Панове вище писали про наявність в якихось системах cloud-компонентів. Й тоді замість VPN використовуються захищені тунелі іншого типу.

Top 5 нових електромобілів, які зареєстровані останні місяці - це автомобілі з Китаю. Оце сьогодення. Та загалом мова про те, що ще багато ДВЗ, але тенденція така, що, можливо, через 10 років електромобілі будуть навіть економічно й практично зручними. Але цю тему можливо розширити та згадати проводи для сонячних елементів, які треба було б вивести на дах або на фасади.

Цікаво. Десь можливо про таке почитати детальніше? Такими засобами можливо транслювати й дані. Здається, все ще є навіть two-way оператори зв'язку такого типу. Але, дійсно, це щось вже занадто ексклюзивне. Та за наявності Starlink не має ніякого сенсу. Мій практичний досвід показує, що 10 -15 пристроїв на площі в 40 метрів з різними стінами й речами вже періодично від'єднуються від мережі. Тому на мою думку це дуже незручний варіант, якщо спиратися на таку конфігурацію як на постійну та стабільну. Можливо, Zigbee ще якось краще працює, але точно не Wi-Fi.

На мою думку, мій приклад про Hikvision навіть більш теоретичний, ніж обговорення CMR та SMR, тому що я нічого не можу зробити та майже нічого не можу подивитися в Hikvision. Тому є тільки непідтверджені здогадки як про тип файлової системи та й про інші програмні конструкції. Але й знання про те, що SMR записує доріжки так, що ті доріжки на 20 - 25% накладаються - це і є теоретична інформація, яка не дає ніякої відповіді на питання, чому SMR - це погано. Тому у разі CMR та SMR не так вже й складно провести відповідні тести на запис деяких послідовностей блоків, довжина яких, наприклад, по 1 GiB (якщо рахувати кількість даних), а потім видалити (навіть через файлову систему, а краще безпосередньо через блок, як Ви писали; програми для перевірки поверхні дисків саме приблизно так й працюють (звісно, умовно поверхні, бо LBA - це деякий віртуальний простір)). Деякі особливості SMR, звісно, існують й виглядають як зупинка SMR у вигляді відсутності підтверджень швидкого запису на деякий період. Тоді можливо в тому ж NVR перевірити SMR HDD, якщо всі дані по колу будуть перезаписані рази 3 - 4 та нічого не буде втрачено, то SMR HDD працює й встигає всі блоки оптимізувати та дефрагментувати. Колись таке ж відношення було й до SSD, але наразі будь-який сучасний комп'ютер працює з SSD. Та все одно користувач має можливість впливати на поведінку HDD - вказуючи деякі параметри файлової системи, налаштовуючи розмір файлів, які записує NVR, тому в цьому обговоренні достатньо багато практики. Наведу практичний приклад. Мій побутовий комп'ютер за деякий час прочитав 275 TiB та записав 176 TiB даних на свій block-device (це саме щось типу total RAW data, яке було пораховано засобами ОС). Ось такий практичний вимір. Співвідношення 61/39. Тому подальша практика - це визначення швидкості запису, яка потрібна NVR. Думаю, що це не дуже багато в побутовому NVR. Все ж SMR мають великі cache'и та достатньо швидкі процесори.

Саме так Всі такі додаткові пристрої бездротові, якщо їх буде багато, можуть бути проблеми зі зв'язком та й під них треба відповідно шукати місце розташування пристрою, який отримує сигнал. Вважаю, така система не дуже стабільна. Цікаво, чому не Одескабель? ) Єдиний варіант застосування наразі - це супутниковий сигнал, але, схоже, Starlink вже забирає цю категорію на себе Так, все вірно. Навіть, можливо, застосувати Mesh та зменшити потужність навіть для кращої якості зв'язку місцями. Про це забули. Дякую за нагадування. Загалом вірне зауваження. Десь проводи для LED-стрічок повинні вийти, а це можливо й низьковольтна система. Щось 230 V LED-стрічки дещо специфічно виглядають. Теж можливий варіант Так, й про це забули. Неминуче майбутнє. ) Загалом дякую за коментарі. Щось нове все ж додалося. )

З більшістю тез погоджуюсь, окрім вимикачів або інших пристроїв, які мають бездротовий зв'язок. Й причин кілька, а саме - такі пристрої все одно мають передати сигнал на якийсь інший пристрій, який, скоріше за все, отримує сигнал від кількох таких пристроїв й тоді з'являється питання розташування такого, скажімо, хабу (навіть у разі Wi-Fi все одно Access Point треба встановити десь поряд, або кілька, а тоді для цих AP потрібне живлення - все трохи ускладнюється); - бездротові пристрої отримують живлення від батарей; впевнений, що через пів року вже не буде цікаво замінювати ті батарейки в тих бездротових пристроях, тому, вважаю, проводові сенсори набагато зручніші Трохи вивчивши питання вирішив, що, скоріше за все, буде якийсь гібрид. Достатньо складно наразі уявити та вибрати всі майбутні пристрої. Є ще велика побутова техніка, яка в якійсь частині могла б бути інтегрована або керуватися якось узгоджено з чимось ще. З точки зору керування освітленням, достатньо цікаво виглядає KNX з децентралізованим підходом. Тому, скоріше за все, планується все якось зібрати, а далі з часом, якщо буде натхнення й бажання щось модифікувати, але без втрати надійності критичних компонентів. Загалом є бажання максимально відійти від бездротових рішень, окрім, звісно, звичайного Wi-Fi (для зв'язку мобільних пристроїв), який хоч в більшості випадків й працює, але буває що місцями є й питання.

Пристрої MikroTik мають багато варіантів - wiki.mikrotik.com/wiki/Category:VPN. Цікавий тролінг у Вас виходить. )

До речі, про які швидкості запису йде мова? 10 - 20 MiB/s? SMR HDD ще поспати встигне в такому режимі. )

VMware вигадали VMFS, яка достатньо ефективна і є невід'ємною частиною інфраструктури VMware. Якщо є ресурси, вважаю, є сенс оптимізувати файлову систему під потреби. Відновлення даних с кожним роком стає все складнішим й складнішим. Та вже деякий час не має ніякого сенсу на фоні ціни одного умовного TiB.

Що ж цікава тема. Тоді продовжимо. Block device - це як HDD, так й SSD, які під'єднані до комп'ютера в більшості випадків. Операційна система за допомогою або свого kernel або якихось додаткових програм працює з HDD та SSD використовуючи LBA, тобто просто вказуючи які блоки LBA треба прочитати, а які треба записати. Напишу ще раз, що ні HDD, ні SSD нічого не знає про файлову систему, яку використовує операційна система або інша програма, яка працює з HDD\SSD як з block device'ом. Мені здається, з цим вже всі погодились в цій темі. Які є прикладі file device'ів або file інтерфейсів. Це NFS різних видів, SMB різних видів, можливо, S3, також Apple щось своє має на цей рахунок. Й ось це називають file-інтерфейсами. Але до теми CMR HDD та SMR HDD це не має відношення, очевидно, що iSCSI - це block over IP. Далі про TRIM. Це команда, яку застосовує host для того, щоб повідомити програму керування HDD або SSD, а фактично block device, про те що деякий LBA range вже не потрібен операційній системі або, скажімо, host'у. Навіщо виробники додали таку функцію? Це пов'язано з тим, як саме працює пристрій зберігання типу NAND (саме цей вид storage device'ів частіше за все називають SSD, але ж це може бути й NOR). NAND технологічно має можливість записати одночасно тільки відносно великий block, а це значить у разі модифікації лише одного біта в блоці потрібно весь блок прочитати, модифікувати біт й далі записати. Дещо довго, блоків багато, не дуже ефективно. Дуже зручно коли транслятор пристрою збереження даних все ж додатково знає, які логічні LBAs вже непотрібні, тоді й оптимізувати\дефрагментувати дані буде дещо ефективніше, чим програма керування SSD й займається "в вільний від роботи час". Продовжуємо. А чи не схоже технологічне обмеження SSD на технологічне обмеження SMR HDD, які мають замість блоків великі стрічки? Так, це і є те ж саме фактично. Тому SMR HDD розуміють TRIM, який допомагає оптимізувати запис, який є технологічним обмеженням технології SMR (й зовсім не потрібно на цьому етапі розуміти, що track'и запису дещо перекриваються, точніше written track та read track мають різну ширину). Тому SMR HDD (програма керування таким HDD) фактично знає які блоки не потрібні, далі в cache збирається нова стрічка й записується відносно швидко. Й у разі NVR цього достатньо для нормальної роботи NVR. Але давайте для прикладу візьмемо NAS. NAS з одного боку працює з block-пристроями (мені, наприклад, зручно працювати з ZFS), а з іншого боку (з боку користувачів) працює як "файл" (SMB Opportunistic Locks обговорювати не будемо). Тому я роблю висновок, що немає принципової різниці для NVR HDD має CMR або SMR write technology. Для ще більшої страховки можливо використовувати на SMR HDD не 100% простору, а менше, щоб була можливість ефектично формувати стрічки. Але це лише моя здогатка, яка в чомусь походить від принципу роботи деяких SSD. NAS одночасно може вирішити видалити блоки в різних місцях диску, що у разі послідовного запису має меншу ймовірність (тобто видалення одного великого файлу (або кількох), які одночасно потрапили в кілька стрічок та навряд розкидані по всім SMR стрічкам). Тепер про Hikvision. Немає в мене підтвердження, яка файлова система розгорнута на HDD. Хоч я й можу під'єднатися до Hikvision через SSH, там мене зустрічає або якийсь BusyBox, або psh або ще щось. Й далі ходу немає. Тому як саме Hikvision працює не зрозуміло. Але в будь-якому випадку, навіть ОС Hikvision працює через LBA та, припускаю, підтримує ATA TRIM.

Є необхідність влаштувати кабелі в такій кількості, щоб надалі була можливість реалізувати такі функції 1) Керування освітленням; 2) Керування розетками (ввімкнена або вимкнена); 3) Під'єднання проводових датчиків сигналізації (датчики контакту, датчики об'єму); 4) Під'єднання проводових протипожежні датчики у тому числі визначення наявності побутового газу та CO; 5) Ethernet-мережа; 6) Керування або автоматизація внутрішніх ролетів Що і як буде керувати поки, що не зрозуміло. Варіантів відносно багато. Окрім деякої автоматизації керування освітленням хотілося б мати максимальну надійність та мати можливість завжди ввімкнути освітлення мануально (KNX?). Традиційно саме зараз все не потрібно, але пізніше поступово поки що є бажання додати. Кабелі, звісно, додавати з часом не зручно, тому саме зараз хотілося б всі кабелі й влаштувати. Поки що бачу ситуацію так. Розетки традиційно до кожної окремо 2,5 мм ВВГнг. Освітлення від кожної точки окремо 1,5 мм ВВГнг (трекові світильники або точкові світильники звісно можливо об'єднати в єдину групу, як й LED стрічку, яка, скоріше, за все буде 24 V, а таку напругу від щитка тягнути не зручно, тому окреме питання де саме встановлювати той блок живлення або LED-драйвер). На всі датчики мідний F/UTP-cat.6 8 x 0,57 мм. Додатково до вимикачів освітлення також FTP (можливо, KNX сподобається, тоді FTP кабель треба буде використати). Ethernet відповідно на тому ж F/UTP-cat.6 8 x 0,57 мм. Так, тем багато, є вже якась кількість обговорень, але можливо є якість сучасні тенденції (як, наприклад, перехід на оптичні кабелі). Як краще зробити?

"...VPN (скорочення від англ. virtual private network — віртуальна приватна мережа) — узагальнена назва технологій, які дозволяють створювати віртуальні захищені мережі поверх інших мереж із меншим рівнем довіри. VPN-тунель, який створюється між двома вузлами, дозволяє приєднаному пристрою чи користувачу бути повноцінним учасником віддаленої мережі і користуватись її сервісами — внутрішніми сайтами, базами, принтерами, політиками виходу в Інтернет..." uk.wikipedia.org/wiki/VPN Про що саме питання?

Мені здається, пан плутає Public VPN та Private VPN. Десь щось хтось купив. Й в тому продукті була інтеграція з якимось cloud-сервісами, до яких наразі можливо під'єднатися тільки через Public VPN. Про це є, дійсно, повідомлення на різних форумах. Але пан побачив слово "автомобіль", та вирішив, що в темі про електроавтомобілі можливо обговорити образу й систему EGR ДВЗ. ) Або просто такий собі тролінг. )

Я порівняв значення слова\терміну або його деякий відносний рівень. VPN можливо використовувати або можливо не використовувати. Окрім VPN є ще TLS, є мінімальна безпечна довжина ключів та інше. Наразі багато систем використовують cloud-сервіси. Але ж знову що й кому потрібно. Якщо Ви знаєте виробника камер відеоспостереження, які точно безпечні, будь ласка, напишіть.

Будь-яка сучасна система відеонагляду, скоріше за все, інтегрується в наявну IT-інфраструктуру (маленьку або більшу; навіть якщо це лише один Інтернет-маршрутизатор та одна Wi-Fi мережа). Існують деякі підходи та технології загалом у світі. Технологій багато, технології об'єднуються й виникає деякий продукт. Якийсь інтегратор може запропонувати проєкт з різними пристроями. Мабуть, Ви пишете про те, що більшість таких проєктів такі як вказано вище. Тоді це питання до інтеграторів, чому вони працюють таким чином. Той, хто має можливості, час або натхнення намагається розібратися й зібрати те, що йому цікаво або потрібно. Наразі можливо мати вдома систему яка буде з 200 метрів визначати людей та записувати номери автомобілів. Та й відслідкувати в якому напрямку надсилаються якісь дані теж є можливість, але потрібна деяка кваліфікація для цього. Й в цьому разі можливостей багато, але й різних нюансів багато. Щось не зручне, щось не сумісне, десь написано, що сумісне, а по факту не працює й так далі. Без досвіду - це дуже багато часу. А потім це все ще й треба підтримувати в робочому стані та визначати який саме пристрій не працює. Вибір обладнання дуже великий. Автоматизація будинку - неминуче майбутнє.

Зрозуміло. Щось схоже на керування китайськими IoT-пристроями Tuya та аналогами. Думаю, є готові простіші рішення, можливо, обмежені в можливостях. Але загалом, дійсно, несумісностей буває багато. Тільки в назву PoE різні виробники вкладають дещо різні значення. Як, наприклад, MikroTik, який називає свій Passive PoE теж PoE, який не підходить для камер відеоспостереження, тому що ті хотіли би працювати з приблизно IEEE 802.3 af/at.

VPN - це загальна назва категорії технологій. Це достатньо поширена мережева технологія або мережевий механізм. Мабуть, VPN можливо сприймати як "автомобіль", який може виробляти будь-яка країна. Тому загалом коментарі вище можливо сприймати як "для того, щоб дістатися в магазин, можливо використати автомобіль (VPN)".

Й ось відповідь "...TRIM/UNMAP is supported for external hard drives with SMR (Shingled Magnetic Recording) to improve Write performance over time. One of the shingled write benefits is that all physical sectors are written sequentially in a direction radially and are only rewritten after a wrap-around. Rewriting a previously written LBA (Logical Block Addressing) will cause the previous write to be marked invalid and the LBA will be written to the next sequential physical sector. The TRIM/UNMAP enables the OS to inform the drive which blocks are no longer considered to be in use and can be reclaimed internally by the HDD to ensure that later write operations perform at full speed..." support-en.wd.com/app/answers/detailweb/a_id/25185#subject3 Тому це проблема NVR, якщо той або його драйвер\операційна система не знає, що робити з TRIM. Мені здається, це і є рішенням у випадку (з вашого прикладу), коли кілька файлів, скажімо, з різних камер з однаковими або приблизно однаковими датами опинились в одній стрічці SMR HDD. Загалом дякую Вам за діалог на тему CMR та SMR HDD. Маю ось такий NVR Hikvision DS-7616NI-K2/16P та ніяк не можу зрозуміти, яка файлова система розгорнута на HDD. Припускаю, Hikvision щось придумав своє.

Програма керування HDD нічого не знає про файлову систему, але знає якими секторами (яка кількість загалом) оперує host. Драйвер файлової системи нічого не знає про фізичну структуру SMR HDD, скільки стрічок існує, на якій пластині знаходиться деякий довільний сектор. Все вірно? Тоді питання - програма керування HDD знає який сектор вільний або зайнятий? Драйвер файлової системи повідомляє про це HDD?

Поки я бачу якісь невідповідності, які й хотів би зрозуміти. Спочатку мова йшла про відсутність, як Ви називаєте, блокового доступу до HDD у NVR. Я надав Вам приклад, де чітко видно, що NVR працює з HDD як з block-пристроєм, як й більшість звичайних комп'ютерів.