Питання швидкодії WordPress-сайтів завжди залишається актуальним – особливо для тих, хто розміщує свій проєкт на малопотужних, але енергоефективних пристроях, як-от Raspberry Pi 4.

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

У цій статті я вирішив порівняти ці два вебсервери за декількома параметрами такими як First Contentful Paint, Largest Contentful Paint, Total Blocking Time та Speed Index. Ці параметри переважно зустрічаються в основних бенчмарках.

Вступ

Як тільки я розгортав цей блог, я за замовчанням встановив Apache як основний вебсервер. Звісно WordPress із коробки доволі сирий, тому з кожним разом я довстановлював додаткові плагіни які з часом сповільнювали роботу сайту. Це мене навело на думку спробувати перейти на Nginx сервер. Адже сам принцип роботи Apache та Nginx настільки різний, що прямо порівняти їх особливості не коректно. Проте існує багато бенчмарків які показують швидкодію сайту і таким чином можна провести базове порівняння, про що і буде мова в цьому блозі.

Методика тестування

Щоб протестувати швидкодію сайту я вирішив скористатися вже перевіриними бенчмарками:

• PageSpeed Insights від Google
• ApacheBench від Apache

Перед міграцією я запустив тести тричі, в різні часи (вранці, вдень та ввечері) а результати обєднав щоб показати середнє значення. Звісно так само я протестував сайт під керуванням Nginx сервера. Я знав, що додатково можна оптимізувати роботу Nginx тому третій запуск тестів був вже в оптимізованій середі.

Давайте дивитися на результати!

PageSpeed Insights тест

Google PageSpeed Insights – це онлайн-інструмент від Google, який оцінює продуктивність вебсторінок з точки зору реальних користувачів.
Він аналізує сторінку як на мобільних пристроях, так і на десктопах, вимірюючи ключові показники досвіду завантаження, відомі як Core Web Vitals:

• Largest Contentful Paint (LCP) – час, за який відображається основний вміст сторінки;
• Total Blocking Time (TBT) – скільки часу сторінка лишається «нечутливою» до взаємодії після завантаження;
• Cumulative Layout Shift (CLS) – стабільність елементів під час завантаження;
• а також додаткові метрики, як First Contentful Paint (FCP) і Speed Index.

На основі цих вимірювань PageSpeed Insights виставляє оцінку швидкодії сторінки та надає рекомендації з оптимізації. Це дозволяє не лише перевірити швидкість відповіді сервера, а й оцінити загальний користувацький досвід у реальних умовах.

Швидкодія може різнитися в залежності від типу пристрою – мобільна версія чи версія для ПК. Як я розумію, при тестуванні виконуються всі тести, але відображається спочатку результат для мобільних пристроїв, а вже потім при бажанні можна подивитися результат для ПК. На основі вимірів я визначив середнє значення та побудував графіки.

Для мобільних пристроїв

Перехід з Apache на Nginx сам по собі дав незначне покращення, приблизно 15%. Однак після активації FastCGI-кешу ситуація змінилася кардинально.

• сайт почав віддавати сторінку майже втричі швидше,
• головний контент (LCP) з’являється менш ніж за 4 секунди,
• а загальний час блокування скриптів знизився на 40 %.

Це пояснюється тим, що мобільний клієнт має слабший процесор і повільніше з’єднання, тому будь-яке серверне кешування (Nginx FastCGI + Cloudflare edge) дає помітний ефект. Браузеру вже не потрібно чекати виконання PHP-коду на Raspberry Pi, він отримує готовий HTML. Кешування в Nginx – найефективніше покращення для WordPress на Raspberry Pi 4. Сайт переходить з “повільної” категорії до стабільної “середньої/швидкої”, і користувач бачить контент утричі раніше, ніж на Apache.

Для ПК

На потужному настільному пристрої різниця між серверами менша, бо браузер і мережа обробляють дані швидше, ніж Raspberry Pi встигає їх підготувати.
Тут видно, що:

• FCP та LCP майже не відрізняються – сайт і так завантажується швидко;
• TBT після кешу падає до 15 мс – це ідеально, сторінка рендериться без затримок;

Speed Index у кешованій версії (1,3 с) трохи гірший, ніж у початковій (1,1 с). Чому так сталося? Speed Index вимірює швидкість візуального заповнення сторінки, а не лише серверну відповідь. У кешованій версії браузер отримує сторінку швидко, але Cloudflare/Nginx можуть віддавати контент із трохи іншими заголовками (cache-control, content-encoding: zstd), через що порядок завантаження дрібних ресурсів (CSS, JS, шрифтів) трохи змінюється. Для потужного ПК це різниця у десяті частки секунди – і тому Speed Index може виглядати “гірше” чисто статистично, навіть якщо користувач візуально різниці не помітить.

ApacheBench

ApacheBench (ab) – це консольний інструмент для вимірювання продуктивності вебсерверів. Він моделює навантаження, надсилаючи велику кількість одночасних запитів до сайту й вимірює, наскільки швидко сервер обробляє відповіді. У тесті я використовував команду:

ab -n 200 -c 50 https://ostrich.kyiv.ua/en/

• -n 200 — загальна кількість запитів (200 сторінок поспіль)
• -c 50 — кількість одночасних клієнтів (імітація 50 відвідувачів одночасно)

Таким чином, тест дозволяє побачити, як швидко Raspberry Pi 4 справляється з навантаженням під час роботи з Apache, Nginx та Nginx із FastCGI-кешем.

Без кешу різниця між Apache і Nginx мінімальна — обидва обробляють близько ~108–109 запитів/сек. Nginx трохи ефективніший у встановленні з’єднань (коротший час Connect), але витрачає більше часу на обробку PHP-відповіді, тому сумарна швидкість практично рівна.

Увімкнення FastCGI-кешу змінило ситуацію кардинально:

• кількість оброблених запитів зросла з 109 до 141 на секунду;
• середній час відповіді зменшився на понад 100 мс;
• навантаження на PHP-FPM і CPU різко знизилось.

Кожна сторінка WordPress віддається напряму з кешу Nginx, без генерації на рівні PHP, що робить обслуговування одночасних користувачів значно швидшим і стабільнішим.

Отже, комбінація Nginx + FastCGI-Cache перетворює Raspberry Pi 4 на легкий, але повноцінний вебсервер продакшн-класу, який упевнено витримує навантаження навіть для WordPress-сайту з динамічним контентом.

Висновки

Перехід із Apache на Nginx на Raspberry Pi 4 показав, що навіть на невеликому домашньому сервері можна досягти помітного приросту швидкодії. Сам по собі Nginx виявився трохи ефективнішим у роботі з великою кількістю одночасних запитів, проте справжній потенціал відкрився після активації FastCGI-кешу.

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

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

Загалом, поєднання Nginx + FastCGI Cache + Cloudflare CDN перетворює Raspberry Pi 4 на повноцінний вебсервер продакшн-рівня: швидкий, стабільний і оптимізований під сучасні вимоги.

Raspberry Pi часто використовується у проектах, які працюють цілодобово. У такому режимі питання охолодження стає критичним. Один із найпоширеніших варіантів – PoE HAT з вбудованим вентилятором. На перший погляд може здатися, що достатньо під’єднати HAT і все запрацює автоматично. Але на практиці іноді виникають нюанси, як це сталося і в мене.

Я купив Waveshare PoE M.2 HAT+. Підключив його згідно інструкції, проте звернув увагу на те, що вентилятор працював постійно на максимальних обертах. Звісно така поведінка неочікувана і я почав шукати причину щоб усунути її.

Параметрами ядра

Вентилятор PoE HAT не працює “напряму” від напруги. Він керується параметрами ядра та спеціальним драйвером, який реагує на температуру процесора і змінює оберти. Ці параметри налаштовуються в файлі конфігурації распбері пай /boot/firmware/config.txt

В цей файл необхідно додати наступний блок налаштувань :

# Fan settings
dtparam=cooling_fan=on
dtparam=fan_temp0=55000,fan_temp0_hyst=2000,fan_temp0_speed=80
dtparam=fan_temp1=60000,fan_temp1_hyst=2000,fan_temp1_speed=140
dtparam=fan_temp2=65000,fan_temp2_hyst=2000,fan_temp2_speed=200
dtparam=fan_temp3=70000,fan_temp3_hyst=2000,fan_temp3_speed=255

Опишу цей блок детальніше на прикладі першого рядка:

• dtparam=cooling_fan=on – вмикає драйвер апаратного вентилятора на Raspberry Pi 5.
• fan_temp0=55000 – поріг у мілі-градусах °C (55 000 = 55 °C). При досягненні цієї температури вентилятор увімкнеться.
• fan_temp0_hyst=2000 – гістерезис (2 °C). Це означає, що вентилятор вимкнеться лише тоді, коли температура опуститься нижче 53 °C.
• fan_temp0_speed=80 – швидкість обертів при цьому порозі. Значення в діапазоні 0–255 (де 255 = максимальні оберти). 80 ≈ низька швидкість, фактично «тихе охолодження».

Після застосування цих змін, я перезавантажив Raspberry Pi, проте зміни не відбулися, вентилятор продовжував працювати на максимальних обертах. Я був змушений шукати інші причини вирішення проблеми – постійні максимальні оберти вентилятора.

Діагностика несправності

Оскільки внесені параметри не вплинули на поведінку роботи вентилятора, то я вирішив подивитися всі можливі параметри які могли б теоретично відповідати за температуру та оберти вентилятора. Для цього я послідовно запустив три команди.

cat /sys/class/hwmon/*/fan1_input
13863

Показує кількість імпульсів за секунду вентилятора. fan1_input – стандартний сенсор у Linux hardware monitoring (hwmon). Зазвичай тут значення коливаються залежно від PWM-сигналу (тобто від того, яку швидкість встановлено через fan_tempX_speed або target_pwm).

/vcgencmd measure_temp
temp=27.9'C

Утиліта vcgencmd читає температуру CPU (через firmware GPU). Означає, що ядро ARM зараз має температуру 27,9 °C. Це «офіційний» спосіб подивитися температуру Raspberry Pi, і саме ці дані використовує система охолодження.

cat /sys/class/hwmon/hwmon0/temp1_input
27050

Той самий сенсор CPU, але доступний через інтерфейс Linux hwmon. temp1_input подає температуру в міліградусах Цельсія. 27050 = 27 050 м°C = 27,05 °C. Це більш «сирий» спосіб доступу до температури, який використовують утиліти типу sensors або monitoring-системи (Zabbix, Prometheus, lm-sensors).

Оскільки кожен параметр видав мені дані, то це значить, що сенсори активні та працюють. Я почав шукати проблему в апаратній частині. Спершу я вимкнув і від’єднав живлення Raspberry Pi, від’єднав шлейф PCI Express та від’єднав повністю плату PoE HAT. Я побачив, що в конекторі для вентилятора распбері пай одна ніжка погнута, і це стало великою проблемою, адже сам роз’єм дуже маленький, і навіть масштаб розмірів голки здається доволі великим. Щоб ви розуміли масштаб мініатюри, я це фото зробив на макро об’єктив.

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

Наразі виконавши команду перевірки кількість імпульсів вентилятора cat /sys/class/hwmon/*/fan1_input я отримав значення 3447 що втричі менше за попереднє значення. Таким чином я поборов проблему, і тепер мій вентилятор керується коректно в залежності від температури процесора.

Головний висновок такий: для стабільної та тихої роботи PoE HAT на Raspberry Pi необхідно не лише правильно налаштувати параметри в config.txt, а й переконатися в цілісності конектора та пінів. Мій приклад наочно показує що цим нехтувати не треба, а якщо вже і сталася проблема, то її вирішити не просто, адже елементи конектора настільки маленькі, що їх фізично вирівняти буде або неможливо, або дуже важко і для цього голка або пінцет будуть доволі великими інструментами.

Raspberry Pi 5 у поєднанні з PoE/M.2 HAT відкриває можливість використовувати швидкі NVMe SSD-диски. Це значно підвищує швидкодію системи, робить її надійнішою у порівнянні з традиційними microSD-картами і дозволяє зберігати значно більші обсяги даних. У цій статті я покажу, як повністю перенести систему з SD на NVMe, зберігши всі розділи й налаштування.

Підготовка системи

Перш за все варто переконатися, що система оновлена та завантажувач EEPROM підтримує роботу з NVMe. Для цього в терміналі достатньо виконати оновлення пакетів, оновити прошивку завантажувача і перезавантажити Raspberry Pi. Після цього можна перевірити командою lsblk, чи бачить система новий SSD. Якщо вивід покаже пристрій nvme0n1, то все готово до наступного кроку.

apt update
apt upgrade -V

В списку я побачив, що rpi-eeprom має нову версію, тому оновлення системи буде не марним.

Після піся оновлення бажано перезавантажити Raspberry Pi, а вже після перезавантаження треба перевірити, чи NVMe SSD визначається системою:

lsblk

У списку має з’явився пристрій nvme0n1

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0     179:0    0 117.1G  0 disk 
├─mmcblk0p1 179:1    0   512M  0 part /boot/firmware
└─mmcblk0p2 179:2    0 116.6G  0 part /
nvme0n1     259:0    0 238.5G  0 disk

Термінал можна закривати та переходити в графічний інтерфейс копіювання даних

Клонування SD картки

Клонування робиться дуже просто – в Raspberry Pi OS є вбудована утиліта SD Card Copier. Вона знаходиться в меню «Accessories» і дозволяє одним кліком перенести систему з картки на інший носій.

Коли програма запущена, потрібно вказати джерелом SD-картку, а ціллю – SSD. Я рекомендую поставити галочку яка створить новий UUID для розділів, щоб уникнути конфліктів. Після натискання «Start» почнеться процес копіювання, який залежно від швидкості картки та диска може тривати кілька хвилин. В моєму випадку це виглядає так:

• У полі Copy From Device треба вибрати із списку SD-картку (mmcblk0)

• У полі Copy To Device треба вибрати із списку NVMe SSD (nvme0n1).
• Поставити галочку Use new partition UUIDs – щоб уникнути конфліктів ідентифікаторів.
• Почати процес копіювання натиснувши на кнопку Start.

Користувач отримає попередження про те, що всі дані будуть видалені з NVMe диска.

Треба погодитися і тоді вже почнеться процес копіювання.

Процес може зайняти кілька хвилин (залежно від швидкості SD та SSD).

Тепер, коли картка пам’яті клонована, можна переходити до налаштувань пріоритету загрузки.

Налаштування порядку завантаження

Коли система скопійована, потрібно налаштувати завантаження так, щоб Raspberry Pi стартував із NVMe. Це робиться через raspi-config. У меню «Advanced Options» є пункт «Boot Order», де достатньо вибрати завантаження спочатку з NVMe, потім з USB і лише потім із SD. Це налаштування записується не на картку чи SSD, а у вбудований EEPROM самої плати, тому після цього Pi завжди спершу перевірятиме NVMe. Дивіться скріншоти.

sudo raspi-config

Відкриється вікно “Raspberry Pi Software Configuration Tool (raspi-config)” в якому вибрати наступні розділи меню:

Advanced Options

Boot Order

NVMe/USB (Boot from NVMe before trying USB and then SD Card)

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

Після цього можна вийти з меню налаштувань, натиснувши на кнопку “Finish“. Для застосування змін система попросить перезавантажитися зараз. Можна перезавантаження перенести на інший час, але краще це зробити одразу.

Перевірка роботи системи

Оскільки перезавантаження відбулося майже миттєво, то сумнівів в тому, що використовується саме NVMe немає, проте краще перевірити. Вимикаємо Raspberry Pi, виймаємо SD-картку, залишаємо лише SSD та знову вмикаємо пристрій. Якщо все зроблено правильно, система завантажиться вже з нового носія. У цьому можна переконатися командою lsblk або mount, де кореневий розділ / має відображатися на nvme0n1p2.

mount | grep ' / '
/dev/nvme0n1p2 on / type ext4 (rw,noatime)

Тут кореневий розділ (/) на nvme0n1p2 що свідчить про те, що завантаження відбувається саме з NVMe. Тепер можна виймати картку пам’яті та працювати вже з новеньким NVMe диском.

Після завершення всіх кроків Raspberry Pi працюватиме швидше та стабільніше, адже SSD краще справляється з інтенсивними операціями читання й запису, ніж звичайні microSD. Крім того, з’явиться запас вільного місця, що дозволяє зберігати більше даних та запускати важчі додатки.

Висновки

Перехід із SD-картки на NVMe SSD для Raspberry Pi — це простий, але дуже відчутний апгрейд. Система починає працювати значно швидше: програми відкриваються без затримок, журнали та бази даних не створюють «вузьких місць», а саме завантаження Pi скорочується у кілька разів. Окрім продуктивності, важливим є й фактор надійності — SSD набагато стійкіші до зношування, тоді як SD-картки можуть виходити з ладу після тривалого використання.

Використання вбудованої утиліти SD Card Copier робить процес міграції максимально простим навіть для новачків: усі розділи переносяться автоматично, UUID оновлюються, а розмір кореневого розділу адаптується під обсяг нового носія. Налаштування порядку завантаження через EEPROM гарантує, що Raspberry Pi завжди обиратиме NVMe як основний диск.

У підсумку, заміна microSD на NVMe SSD — це крок, який не потребує складних налаштувань, але кардинально змінює досвід роботи з Raspberry Pi. Якщо у вас є PoE/M.2 HAT і сумісний NVMe-диск, радимо зробити цей апгрейд одразу після початкового налаштування системи.

Я придбав для свого Raspberry Pi 5 адаптер PoE M.2 HAT+ від Waveshare, який дозволяє не лише живити плату через Ethernet, а й підключати NVMe-накопичувач формату M.2. Це відкриває нові можливості для використання Raspberry Pi у якості міні-сервера, NAS або системи зберігання даних з високою продуктивністю.

Щоб повною мірою використати цей потенціал, я обрав компактний та енергоефективний SSD Samsung MZ9L4256HCJQ-00BD1 об’ємом 256 ГБ. У цьому огляді я поділюся досвідом підключення, налаштування та тестування цього накопичувача у зв’язці з Raspberry Pi 5. Зокрема, ми розглянемо дизайн, основні характеристики, роботу інтерфейсу PCIe 3.0 x1, і перевіримо реальні швидкісні показники з інтерфейсом PCIe 3.0 x4.

Компактність та дизайн

Модель Samsung MZ9L4256HCJQ-00BD1 виконана у форм-факторі M.2 2230, що означає довжину всього 30 мм (на відміну від поширенішого 2280, який має 80 мм). Такий формат часто використовується в ультракомпактних пристроях – планшетах, міні-ПК, а тепер і в Raspberry Pi 5 завдяки доступним адаптерам. Через обмежену площу, накопичувачі у форматі 2230 мають певні конструктивні обмеження:

• Виробляються лише кількома компаніями (Samsung, Kioxia, Western Digital, Sabrent, та ще кілька).
• Найпоширеніші об’єми — 256 ГБ і 512 ГБ, які вважаються оптимальними за співвідношенням ціна/ємність.
• Моделі на 1 ТБ або більше існують, але їхня ціна значно вища, ніж у аналогів формату 2280, через високу щільність компонування і менший попит.

Попри компактність, SSD NVMe MZ9L4256HCJQ-00BD1 зберігає всі переваги повноцінного накопичувача: високу швидкість, низьке енергоспоживання та стабільну роботу. Форм-фактор 2230 ідеально підходить для використання з Raspberry Pi 5 у проектах, де важливі компактність і надійність.

Щоб краще уявити його габарити – я порівняв накопичувач з монетою номіналом 1 євро. Це наочно демонструє щільність компонентів досягнуту в цьому форм-факторі.

Основні характеристики

Цей SSD призначений для виробників комп’ютерів і ноутбуків, тобто це OEM-продукт і нажаль я не зміг знайти публічної сторінки на споживчих сайтах Samsung, тому його специфікацію я отримав від продавця:

• Серія – PM9B1
• Об’єм пам’яті – 256 GB
• Тип флеш-пам’яті – TLC
• Форм-фактор – M.2
• Типорозмір М2 – M.2 2230
• Інтерфейс підключення – PCI Express 4.0 x4
• Швидкість читання – 3300 Mb/s
• Швидкість запису – 1250 Mb/s

Підключення до Raspberry Pi 5

Підключення SSD до Raspberry Pi 5 через Waveshare POE M.2 HAT+ виявилося не простим. Я зіткнувся з проблемою – відсутністю гвинтика фіксації накопичувача в комплекті до SSD та в комплекті до самого PoE HAT. Через це я витратив час в його пошуки, але в результаті знайшов потрібний і зафіксував SSD.

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

SSD Необхідно вставити під кутом до упору та зафіксувати гвинтом, ось так буде виглядати підключене рішення.

Після підключення, переходимо до наступного етапу – налаштування та тестування швидкості.

Ідентифікація пристрою

При включенні Raspberry Pi накопичувач був коректно ідентифікований утилітою Disk як PM9B1 NVMe Samsung 256GB (46304039)

За замовчанням Raspberry Pi використовує інтерфейс PCIe 2.0. Щоб це визначити, треба виконати наступну команду, де пристрої будуть відфільтровані за ключовим словом PCIe. Серед отриманого результату важливий наступний рядок, який точно вказує на базове значення PCI Express 2.0. Не дивлячись на обмеження швидкість в 5 Гігабіт на секунду, вона все одно вища за будь яку сучасну MicroSD картку пам’яті.

dmesg | grep PCIe
[0.505851] pci 0001:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0001:00:00.0 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link)

Налаштування PCIe 3.0

Параметри апаратної частини прописані в файлі конфігурації, який щоразу читається при завантаженні операційної системи. Саме цей файл ми і будемо редагувати:

sudo nano /boot/firmware/config.txt

В конфігурації шукаємо параметр dtparam який відповідає за версію PCIe інтерфейса pciex1_gen і змінюємо його значення на pciex1_gen=3, якщо такого параметра нема то просто додаємо його:

dtparam=pciex1_gen=3

Зберігаємо цей файл, і перезавантажуємо распбері пай, щоб зміни були застосовані, і перевіряємо результат ще раз:

dmesg | grep PCIe
[0.401861] pci 0001:01:00.0: 7.876 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x1 link at 0001:00:00.0 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link)

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

Тестування швидкості

Ще раз повторюсь, що SSD Samsung підтримує інтерфейс PCIe Gen 4.0 x4, що забезпечує дуже високі швидкості. Однак Raspberry Pi 5 обмежує його можливості до PCIe 3.0 x1, як описано в попередньому розділі. Щоб зрозуміти, наскільки це впливає на швидкість, я провів порівняльний тест: спершу перевірив SSD на своєму ПК з PCIe 3.0 x4, а потім – на Raspberry Pi 5, вже із інтерфейсом PCIe 3.0 x1.

Тестування проводилося за допомогою утиліти KDiskMark. Ця програма є альтернативною версією CrystalDiskMark тільки для Linux операційних систем. Встановити KDiskMark можна виконавши наступні команди:

echo 'deb http://download.opensuse.org/repositories/home:/kimi:/kdiskmark/Raspbian_12/ /' | sudo tee /etc/apt/sources.list.d/home:kimi:kdiskmark.list
curl -fsSL https://download.opensuse.org/repositories/home:kimi:kdiskmark/Raspbian_12/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_kimi_kdiskmark.gpg > /dev/null
sudo apt update
sudo apt install kdiskmark

Після встановлення програми можна її запустити командою

kdiskmark

В інтерфейсі треба буде вибрати диск, який розпізнався, в моєму випадку це /media/ostrich/NVME і також треба в налаштуваннях програми вибрати меню Settings та вибрати NVMe SSD для оптимізації тесту саме для NVMe дисків. Інші параметри я залишив за замовчанням. Для старту тесту клацаємо на кнопку “All” і чекаємо завершення результатів!

Я вирішив провести аналогічний тест тільки на своєму ПК. SSD я підключив до материнської плати Asus Prime A520M-K яка також підтримує PCIe 3.0 але з індексом x4, що означає 4 лінії замість однієї.

Нажаль в мене немає можливості повністю перевірити весь потенціал цього накопичувача, але різниця дуже помітна.

Висновки

Samsung MZ9L4256HCJQ-00BD1 — це надійний та швидкий SSD, який чудово підходить для розширення можливостей Raspberry Pi 5. Його головною перевагою є стабільна робота, хороша енергоефективність та швидкість читання/запису, яка максимально використовує потенціал інтерфейсу PCIe 3.0 x1 на Raspberry Pi. З таким накопичувачем ви зможете створити файловий сервер, систему зберігання даних або навіть запускати бази даних із мінімальними затримками. Якщо вам не потрібні максимальні швидкості понад 1 ГБ/с, ця комбінація — ідеальне рішення за свої гроші.

Raspberry Pi 5 став справжнім проривом у світі одноплатних комп’ютерів. Оновлене залізо, потужніший процесор, підтримка PCIe через FPC-кабель – усе це відкриває нові горизонти для ентузіастів. Проте однієї ключової деталі все ще бракує, а саме офіційної POE HAT від Raspberry Pi Foundation для п’ятого покоління.

Хоча офіційний реліз, за чутками, вже «на підході», багато користувачів не хочуть чекати. Вони прагнуть компактності, зручності та живлення Raspberry Pi без зайвих кабелів і окремої розетки на 220 В. Саме тут у гру вступає Waveshare POE M.2 HAT+ це неофіційне, але надзвичайно практичне рішення для PoE-живлення та одночасного розширення за допомогою накопичувачів M.2.

Waveshare POE M.2 HAT+ це рішення для тих, хто не хоче чекати офіційного релізу POE для Raspberry Pi 5

Живлення Raspberry Pi 5

Raspberry Pi 5 продається як окрема плата без блоку живлення в комплекті. Для користувачів пропонується оригінальний блок живлення 27W USB-C PowerSupply EU. На першому етапі я купив саме цей блок живлення, адже інші виробники пропонували майже такі самі і по ціні і по потужності пристрої, тому не було сенсу в пошуках чогось іншого.

27W USB-C PowerSupply EU device – box

27W USB-C PowerSupply EU – logo

27W USB-C PowerSupply EU – specification

Цей блок живлення підтримує наступні режими:

• 5.1V, 5A;
• 9V, 3A;
• 12V, 2.25A;
• 15V, 1.8A

Якщо розглянути варіант підключення Raspberry Pi 5 через Waveshare POE M.2 HAT+ використовуючи як джерело мій свіч UniFi USW-Lite-8-PoE який підтримує стандарт 802.3at що подає напругу на вході 48 вольт, то характеристики живлення будуть такими.

• Напруга на вході = ~48V DC
• Потужність = до 25.5 Вт
• Струм приблизно = 0.5 – 0.6 А

Комплектація

Я зробив замовлення в інтернет магазині України, тому но коробочці був вже наклеєний стікер продавця. Проте через цей стікер прогладався оригінальний напис Waveshare. Також був зазначений код моделі: SKU: 28411. Оскільки бренд Waveshare китайський, то логічно і вироблена ця плата була також в Китаї.

Всі елементи запаковані в індивідуальні пакетики, а саме:

• PoE M.2 HAT+
• Металевий радіатор
• Кабель 16 контактів, довжина 40 мм
• Термострічка (3 штуки)
• Набір гвинтів і стійок

Пропоную розглянути кожен компонент окремо, для цього я зробив фото

Waveshare POE M.2 HAT back

Waveshare POE M.2 HAT face

Waveshare POE M.2 HAT Metal heatsink

Waveshare POE M.2 HAT 16P-Cable-40mm

Waveshare POE M.2 HAT Thermal tape

Waveshare POE M.2 HAT Screws pack

Підключення POE M.2 HAT+

Процес підключення має свою послідовність, і складається з декількох простих кроків:

Наклеювання термострічки

В комплекті три квадратні термострічки, вони в захисній плівці яку треба зняти перед наклеюванням. Найбільший квадратик приклеїти на процесор, а два інші на чіп Wi-Fi / Bluetooth та на чіп пам’яті.

• Процесор
• Wi-Fi / Bluetooth
• Память

Фіксація радіатора

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

Закріплення POE M.2 HAT+

Ця плата кріпиться до Raspberry Pi за допомогою 4 стійок, які знизу та зверху закручуються гвинтиками.

Цікавий факт: в комплекті 5 стійок та 10 гвинтиків, можливо зайві враховуються як запасні.

Підєднуємо шлейф живлення кулера

Закручуємо 4 стійки знизу гвинтами.

Підєднуємо плату через контакти GPO. Треба бути обережним із проводом до кулера, щоб він був розміщений компактно та не заважав компонентам.

Закручуємо стійки зверху

Таким чином наша плата встановлена та підключена, залишилося лише останнє – підключити PCI шлейф.

Підключення шлейфу PCI

Шлейф має дві сторони, тому важливо не переплутати напрямок та позицію підключення

16P-Cable-40mm socket

16P-Cable-40mm socket rpi

16P-Cable-40mm plugged

Тестування

В ролі джерела живлення в мене буде свіч Ubiquiti UniFi Switch Lite 8 PoE (USW-Lite-8-PoE). Цей свіч має 4 PoE+ порти на загальну потужність не більше 60 ватт, та не більше 30 ватт на 1 порт. Я підключив Raspberry Pi 5 до першого порту. Буквально через секунду почалося завантаження, та почав крутитися кулер, що свідчить про коректне підключення як кулера так і PCI шлейфу.

Два світлодіоди мережевого порту світяться, що свідчать про живлення PoE+ та передачу даних.

Звісно мені було цікаво дізнатися яке реальне споживання Raspberry Pi 5? Для цього я подивився ці значення в контролері Ubiquiti – UniFi Network, в розділі Ports та вибравши вкладку Stats.

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

• Не підключено SSD через PCI
• Не підключено USB флешку
• Raspberry Pi майже в стані простою

При збільшенні навантаження або підключенні додаткових пристроїв споживання неодмінно збільшиться.

Висновки

Waveshare POE M.2 HAT+ це не просто заміна офіційної PoE HAT, а функціонально багатший варіант, що поєднує в собі одразу три можливості:

1. PoE живлення без окремого блока.
2. M.2 накопичувач для серверних проектів.
3. Активне охолодження — необхідне при роботі з великим навантаженням.

До появи офіційного рішення від Raspberry Pi Foundation — це найкращий вибір для ентузіастів, які хочуть максимально ефективно використовувати можливості нового Pi 5.

У світі Linux традиційно прийнято орієнтуватися на текстові інтерфейси: консоль, htop, top, systemctl – ці інструменти добре знайомі досвідченим користувачам. Проте сучасні реалії диктують інші вимоги: багато користувачів переходять з Windows на Linux, де звичним і зрозумілим є графічний інтерфейс. Особливо це стосується візуалізації системних процесів.

Тут на допомогу приходить Mission Center – надзвичайно зручний та візуально привабливий менеджер задач, який дуже нагадує Task Manager із Windows 11. Це справжній подарунок для користувачів Raspberry Pi, які хочуть мати не лише функціональний, а й естетично приємний інструмент для моніторингу системи.

Що таке Mission Center?

Mission Center – це сучасна альтернатива традиційним менеджерам задач, яка поєднує стильний дизайн, високу продуктивність і багату функціональність:

• відображення використання CPU, RAM, диску, мережі;
• список процесів у зручному вікні з можливістю завершення;
• зручна діагностика продуктивності в реальному часі;
• візуальний стиль максимально наближений до Windows Task Manager;
• підтримка Wayland та X11.

Навіщо встановлювати Mission Center на Raspberry Pi?

Raspberry Pi використовується не лише як сервер або IoT-пристрій, а й як повноцінний настільний комп’ютер. Якщо ви запускаєте на ньому графічне середовище (наприклад, Raspberry Pi OS з інтерфейсом), зручний диспетчер задач – must-have. Mission Center робить моніторинг процесів не лише інформативним, а й приємним для ока.

Як встановити Mission Center на Raspberry Pi

Є декілька особливостей встановлення, а саме распбері пай повинна бути десктопною, з графічний інтерфейсом, і оскільки Mission Center розповсюджується через

• AppImage (ARM64),
• Flatpak
• Snap

Найпростішим вибором буде встановити Mission Center саме через Flatpak. Адже на Raspberry Pi остання версія Snap 2.57.6, а для встановлення потрібна мінімум версія Snap 2.61. Інакше користувач отримає помилку.

Крок 1: Оновлюємо систему

sudo apt-get update && sudo apt upgrade

Крок 2: Встановлюємо Flatpak

sudo apt-get install flatpak

Крок 3: Встановлюємо Mission Center

sudo flatpak install flathub io.missioncenter.MissionCenter

Looking for matches…

Required runtime for io.missioncenter.MissionCenter/aarch64/stable (runtime/org.gnome.Platform/aarch64/48) found in remote flathub

Do you want to install it? [Y/n]: y

1. [✓] org.freedesktop.Platform.GL.default
2. [✓] org.freedesktop.Platform.openh264
3. [✓] org.gnome.Platform.Locale
4. [✓] org.gnome.Platform
5. [✓] io.missioncenter.MissionCenter

Installation complete.

Крок 4: Запуск Mission Center

Після встановлення ярлик в меню не було виведено, тому утиліту я запустив через флатпак:

flatpak run io.missioncenter.MissionCenter

Порівняння з Диспетчером завдань Windows

В Mission Center визначено три розділи:

• Продуктивність
• Застосунки
• Сервіси

В диспетчері завдань Windows ще додано розділи: Журнали, Програми що запускаються, Користувачі, та Відомості.

Розглянемо розділи які можна порівняти

Продуктивність

Візуально майже така сама метрика:

• Процесор (можна переключати з загального вигляду на логічні процесори)
• Память
• Диски
• Мережа (Wi-Fi та дротова)

В цьому випадку я зробив порівняльний скріншот із своїм десктопом на якому встановлена Windows 11.

Застосунки

В Mission Center це називається Apps в віндовс перелік запущених програм називається Процеси, де при сортуванні по імені відображаються саме активні програми, які своєрідно можно назвати застосунками.

Як видно з наведених скріншотів, є можливість сортування за значенням навантаження на процесор, чи по споживанню оперативної пам’яті.

Сервіси

На відміну від Mission Center в Диспетчері завдань Сервіси назвали Службами, проте логіка одна й та сама – служби чи сервіси можна зупинити або запустити, подивитися їх стан та статус.

Особливості застосунку

Встановлення Mission Center на Raspberry Pi виявилося можливим, але супроводжувалося низкою технічних обмежень. Пакет недоступний у стандартних APT-репозиторіях, а встановлення через Snap виявилось неможливим через застарілу версію snapd, яка не підтримує нові базові Snap-пакети, зокрема core20.

У результаті, єдиним варіантом швидкого встановлення стала версія через Flatpak. Вона справді запускається й виглядає сучасно, однак має свої нюанси: через обмеження sandbox’а Flatpak частина функціоналу недоступна або працює некоректно. Зокрема, виводяться численні повідомлення про помилки з доступом до системних файлів та відмову підключення до внутрішніх сокетів, а графічний інтерфейс місцями перевищує розмір екрану.

Висновок

Застосунок виявився дійсно вражаючим за дизайном і наближеністю до Диспетчеру завдань Windows 11 проте на жаль не оптимізований чи не адаптований під слабенькі процесори на ARM.

Одним із найзручніших способів дистанційного керування Raspberry Pi традиційно було використання VNC-сервера, який дозволяє отримати доступ до графічного інтерфейсу «малини» через локальну мережу або ззовні. Проте з виходом нової офіційної операційної системи – Raspberry Pi OS на базі Debian Bookworm, яка була офіційно випущена 10 жовтня 2023 року, стандартний метод підключення через RealVNC Server більше не підтримується.

На щастя, Raspberry Pi Foundation представила новий зручний сервіс – Raspberry Pi Connect, який дозволяє дистанційно керувати пристроєм прямо з браузера, без складних налаштувань мережі чи порт-форвардингу. Бета-тестування Raspberry Pi Connect розпочалося у грудні 2023 року, а офіційний стабільний реліз вийшов у квітні 2024 року.

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

Вимоги

На відміну від попередніх рішень на кшталт RealVNC, які вимагали окремої інсталяції та налаштування, Raspberry Pi Connect вже інтегрований у Raspberry Pi OS (Bookworm), починаючи з оновлень, що вийшли після офіційного релізу в жовтні 2023 року.

• Raspberry Pi OS (Bookworm) – оновлена до останніх пакетів.
• Графічне середовище (Desktop edition) – Raspberry Pi Connect працює тільки з графічною оболонкою.
• Обліковий запис Raspberry Pi – сервіс вимагає авторизацію через connect.raspberrypi.com, що дозволяє захищено зв’язати ваш пристрій із хмарним інтерфейсом.
• Інтернет-з’єднання – Raspberry Pi повинен мати стабільний доступ до Інтернету.

Оновлення Raspberry Pi OS

Підключившись до Raspberry Pi по SSH необхідно оновити операційну систему

sudo apt update
sudo apt full-upgrade

Після оновлення системи можна перевірити і версію самого сервісу

rpi-connect --version
rpi-connect 2.5.2 (revision 0691027f16f3ddbf6417b0030e1ebf50b2e74790) [arm64]

Після виконання цих команд, використовується остання версія Raspberry Pi OS та Raspberry Pi Connect.

Графічне середовище (Desktop edition)

Під графічним середовищем мається на увази використання певного набору функцій ОС при встановленні, це може бути так званна серверна версія Raspberry Pi OS Lite або десктопна Raspberry Pi OS Full Проте якщо ви не знаєте яка саме версія встановлена, це можна перевірити виконавши наступну команду

dpkg -l | grep raspberrypi-ui-mods
ii raspberrypi-ui-mods 1.20250506 arm64 Config to customise the LXDE UI for the Raspberry Pi

Наявність запису raspberrypi-ui-mods – свідчить про наявність графічного середовища.

Обліковий запис Raspberry Pi

Для створення облікового запису необхідно перейти за посиланням https://connect.raspberrypi.com/sign-in та клацнути на посилання create one for free

Для реєстрації необхідно заповнити форму:

• Email
• Password and Re-enter password
• Name (Nick) What should we call you?
• Agree to the Terms and Conditions

Додатково я активував 2FA для покращення захисту мого акаунта.

Інтернет-з’єднання

Оскільки це оналйн сервіс, то Інтернет-з’єднання є обов’язковою умовою.

Зв’язок Raspberry Pi з обліковим записом Raspberry Pi Connect

Оскільки вимоги всі виконані, необхідно виконати додаткові налаштування, а саме запустити сервіс командою

rpi-connect on
✓ Raspberry Pi Connect started

Таке повідомлення свідчить що сервіс запустився і працює коректно. Тепер потрібно пов’язати пристрій з обліковим записом Connect. виконавши наступну команду

rpi-connect signin
Complete sign in by visiting https://connect.raspberrypi.com/verify/XXXX-XXXX

Результатом цієї команди буде посилання із 8-значним кодом. Необхідно це посилання відкрити в браузері для подальшої реєстрації пристрою.

В цьому вікні необхідно ввести назву для свого пристрою. Ця назва буде відображатися в обліковому записі і буде ідентифікатором саме цього пристрою. Якщо у вас декілька пристроїв, то краще їм давати унікальні назви.

Клацаємо на Create device and sign in, щоб додати пристрій. У вікні побачимо повідомлення про успішне завершення зв’язку

Device sign in successful
Your device Ostrich RPI now has access to your account. If this was a mistake, you can delete the device and its access tokens.
You can now close this window, or view all devices.

В цей час в терміналі з’явиться додатковий рядок

rpi-connect signin
Complete sign in by visiting https://connect.raspberrypi.com/verify/XXXX-XXXX

✓ Signed in

Це свідчить про успішний зв’язок Raspberry Pi з обліковим записом Raspberry Pi Connect.

Підключення

В браузері переходимо за посиланням view all devices, і потрапляємо на головний екран де є перелік пов’язаних пристроїв та їх статус

Для підключення графічним методом, необхідно із випадаючого списку Connect via вибрати Screen sharing. В новому вікні на короткий проміжок часу, до повного з’єднання користувач побачить напис на чорному екрані Waiting for response from Ostrich RPI

Згодом, користувач побачить звичний робочий стіл Raspberry Pi OS і зможе керувати вже мишкою.

Висновок

Поява Raspberry Pi Connect значно спростила дистанційне керування пристроєм без потреби в складному налаштуванні VNC або порт-форвардингу. Завдяки інтеграції з Raspberry Pi OS (починаючи з версії на базі Debian Bookworm), цей сервіс відкриває нові можливості для користувачів, які хочуть мати швидкий доступ до свого Raspberry Pi з будь-якої точки світу.

Якщо у вас встановлена версія з графічним інтерфейсом, активація Raspberry Pi Connect займає лише кілька хвилин і не потребує додаткового програмного забезпечення. Це чудове рішення для розробників, ентузіастів та освітніх проектів, де потрібен стабільний та безпечний віддалений доступ.

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

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

Інфраструктура

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

• Будь який пристрій який підключений до електромережі та локальної мережі через дротове з’єднання або через wi-fi.
• Роутер, свіч та wi-fi точка доступу які підключені як до мережі так і до додаткового джерела живлення
• Raspberry Pi яка також підключена до альтернативного джерела живлення

В моєму випадку, в ролі домашнього пристрою виступив wi-fi термостат для теплої підлоги. В ролі мережевих пристроїв виступили пристрої від Ubiquiti, а в ролі обробки даних виступила моя Raspberry Pi.

Принцип підключення та взаємодії я зобразив графічно

Тобто написаний на пайтоні скрипт постійно 24/7 надсилає пінг запити. Якщо електроенергія знакла, то звісно термостат не зможе відповісти, проте мережеве обладнання та Raspberry Pi продовжать працювати від альтернативного джерела енергії, і про відсутність електроенергії користувач дізнається через пуш сповіщення Телеграма. Коли електроенергія відновиться, термостат з’явиться в локальній мережі, і при успішній відповіді на пінг користувач буде проінформований про те, що електроенергія з’явилася, також буде прорахований час відсутності електроенергії.

Для реалізації цього алгоритму необхідно:

• Створення Telegram-бота
• Написання Python скрипта
• Автоматизація запуску через сервіс

Ці пункти я опишу детально.

Створення Telegram-бота

В телеграмі є спеціальний бот, який створений спеціально для створення інших ботів. Цей бот має назву BotFather. Для створення свого власного боту необхідно виконати наступні дії:

• У Telegram треба знайти бота під назвою BotFather
• Для початку роботи треба написати /start
• Для створення свого бота, треба ввести команду /newbot
• Ввести ім’я та назву свого бота

Після створення бота, через головне меню можна налаштувати приватність та отримати АПІ токен. Також необхідно отримати Chat_ID для приватного використання бота, адже йому потрібно знати кому відправляти повідомлення. Для цього існує ще один бот @userinfobot, треба йому щось написати, наприклад /start і він у відповідь напише Chat_ID, який в майбутньому буде використаний.

Найголовніше, що ми отримали:

• API token
• Chat_ID

Переходимо до створення скрипту на пайтоні.

Написання Python скрипта

Для роботи скрипта необхідно встановити додаткові пакети та бібліотеки, створити та активувати віртуальне середовище.

Встановлення додаткових пакетів

sudo apt install python3-venv

Створення віртуального середовища в потрібній директорії, в моєму випадку /home/rpi/TG_BOT

cd /home/rpi/TG_BOT
python3 -m venv myenv

Активація віртуального середовища

source myenv/bin/activate

Коли віртуальне середовище активоване, треба встановити бібліотеки для роботи з API телеграма

pip install python-telegram-bot requests

Скрипт буде мати наступні функції:

• format_time – для визначення часу
• send_message – для відправки повідомлення
• ping_address – для пінгування термостата
• monitor_ip – для визначення статусу та формування повідомлення

Код надано в спойлері

import os
import time
import asyncio
from telegram import Bot

CHAT_ID = "<Your Chat ID>"
BOT_TOKEN = "<Your API tioken>"

bot = Bot(token=BOT_TOKEN)

def format_time(seconds):
    """Форматує секунди в години, хвилини і секунди."""
    hours, remainder = divmod(seconds, 3600)
    minutes, seconds = divmod(remainder, 60)
    return f"{hours} годин {minutes} хвилин {seconds} секунд"

async def send_message(message):
    await bot.send_message(chat_id=CHAT_ID, text=message)

def ping_address(ip, count=3):
    """
    Пінгує IP-адресу `count` разів.
    Повертає True, якщо хоча б один пінг успішний.
    """
    response = os.system(f"ping -c {count} -W 2 {ip} | ts")
    return response == 0

async def monitor_ip(ip):
    power_off_time = None
    power_on = True

    while True:
        if ping_address(ip):
            if not power_on:
                power_on = True
                time_power_on = time.time()
                outage_duration = int(time_power_on - power_off_time)
                formatted_duration = format_time(outage_duration)
                outage_message = f"Світло з'явилося. Відключення тривало {formatted_duration}."
                await send_message(outage_message)
        else:
            if power_on:
                power_on = False
                power_off_time = time.time()
                await send_message("Світло зникло.")

        await asyncio.sleep(30)  # Використовуйте asyncio.sleep для асинхронного затримки

if __name__ == "__main__":
    ip_address = "<Thermostat local IP>"  # Замініть на свою IP-адресу
    asyncio.run(monitor_ip(ip_address))

Зазвичай лог виконання команди записується в системній журнал, і там кожен запис має мітку дати та часу, проте я вирішив виділити логування в окремий файл засобами сервісу. Якщо логування відбувається не в системний журнал, то за замовчуванням час події не фіксується. Для того, щоб час пінгу фіксувався, я команду ping обробляю додатково командою ts, таким чином вивід запису:

ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=16.1 ms

перетворюється на:

ping -c 3 8.8.8.8 | ts
May 12 19:18:23 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
May 12 19:18:23 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=15.7 ms

Для цього необхідно додатково встановити утиліту moreutils

Автоматизація запуску через сервіс

Для того, щоб скрипт виконувався навіть після перезавантаження Raspberry Pi, я створив сервіс, який буде запускатися автоматично. Зазвичай всі системні сервіси знаходяться в директорії /etc/systemd/system/, тому сервіс для скрипта я розміщу також там. Як я раніше зазначав, що логування буде відбуватися в окремий файл для зручності, за адресою /var/log/sun.log, то ця адреса буде прописана саме в параметрах сервісу.

Я вигадав таку назву для свого сервісу – FolletSun.service. Параметри сервісу будуть наступними:

[Unit]
Description=Script which check electricity and pass status to Telegram Bot.

[Service]
ExecStart=/home/rpi/TG_BOT/bin/python3 /home/rpi/TG_BOT/Sun.py
StandardOutput=file:/var/log/sun.log
StandardError=file:/var/log/sun.log
WorkingDirectory=/home/rpi/TG_BOT
Restart=always
User=rpi
Group=rpi

[Install]
WantedBy=multi-user.target

Для того, щоб ініціювати сервіс без перезавантаження системи необхідно виконати наступні команди:

sudo systemctl daemon-reexec
sudo systemctl daemon-reload

Також, щоб активувати сервіс, запустити його та перевірити його статус слід виконати наступні команди:

sudo systemctl enable FolletSun.service
sudo systemctl start FolletSun.service
sudo systemctl status FolletSun.service

Результат виконання команди статусу сервісу буде такий:

● FolletSun.service - Script which check electricity and pass status to Telegram Bot.
     Loaded: loaded (/etc/systemd/system/FolletSun.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-05-11 22:31:20 EEST; 21h ago
   Main PID: 1458494 (python3)
      Tasks: 1 (limit: 8735)
        CPU: 3min 40.583s
     CGroup: /system.slice/FolletSun.service
             └─1458494 /home/rpi/TG_BOT/bin/python3 /home/rpi/TG_BOT/Sun.py

Це свідчить про те, що в скрипті не виявлено жодних помилок та конфліктів.

Перевірка роботи боту

Для того щоб перевірити роботу бота, треба в додатку Telegram, знайти створеного бота та підписатися на нього. З цієї миті Бот повинен сповіщати про зміну статусу енергоживлення. Ось скріншот з мого смартфона:

Пінг відбувається кожні 30 секунд, і ви мабуть звернули увагу на повідомлення, де електроенергія зникла лише на 30 секунд – це хибне спрацювання через те, що термостат не відповів на пінг запит, або Raspberry Pi не отримала відповідь від термостата. Можливо це результат нестабільного підключення. Для того, щоб уникнути цього або мінімізувати, краще використовувати не менше 3х пінг запитів.

Висновки

У відповідь на актуальні загрози, пов’язані з енергетичною безпекою в умовах війни, було розроблено ефективну та недорогу систему моніторингу електропостачання. Вона базується на популярних технологіях з відкритим кодом — мікрокомп’ютері Raspberry Pi, Python-скрипті та Telegram-боті.

Система забезпечує безперервне відстеження наявності електроенергії у домі, фіксує час її зникнення та повернення, а також автоматично надсилає сповіщення користувачеві. Такий підхід дозволяє швидко реагувати на ситуацію, планувати використання резервних джерел живлення і приймати обґрунтовані рішення щодо купівлі генератора або зарядної станції.

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

Raspberry Pi вже давно вийшов за межі простої плати для ентузіастів: сьогодні це повноцінний міні-комп’ютер, здатний виконувати складні завдання, включаючи апаратну віртуалізацію. У цій статті покроково розглядається процес встановлення Raspberry Pi OS Lite, налаштування доступу по SSH, оновлення системи, встановлення підтримки KVM, інсталяція веб-інтерфейсу Cockpit, а також створення і запуск гостьової операційної системи за допомогою KVM. Цей підхід дозволяє перетворити Raspberry Pi на зручну платформу для тестування та навчання у сфері віртуалізації.

Встановлення Raspberry Pi OS Lite

Використовуючи утиліту Raspberry Pi Imager на картку мікро сд встановлюємо операційну систему Raspberry Pi OS Lite (64) На етапі встановлення треба змінити конфігурацію, щоб потім можна було працювати із Raspberry Pi дистанційно підключившись по SSH.

• Hostname
• Username and password
• Enable SSH

host settings

enable ssh

Завантажуємо систему з цієї картки пам’яті та перевіряємо IP адресу.

Оновлення системи

Підключаємося до Raspberry Pi по SSH

ssh [email protected]

Оновлюємо ОС до останньої версії та перезавантажуємо Raspberry Pi

sudo apt update && sudo apt full-upgrade -y
sudo reboot

Встановлення KVM libvirt

Починаючи з ядра Linux 5.10+ (а зараз Raspberry Pi OS використовує 6.x), підтримка апаратної віртуалізації KVM для ARM64 включена безпосередньо в ядро. У Raspberry Pi OS (64-bit, desktop або lite) KVM активується автоматично, щойно пристрій підтримує апаратну віртуалізацію.

Це стало можливим завдяки тому, що Raspberry Pi Foundation інтегрувала підтримку KVM безпосередньо в upstream ядро для своїх ARM64-платформ. Вони орієнтуються на те, щоб користувач міг одразу експериментувати з віртуалізацією – без додаткової конфігурації.

Проте краще це перевірити запустивши наступні команди:

якщо файл /dev/kvm є – підтримка активна

ls /dev/kvm
/dev/kvm

покаже лог запуску KVM при старті системи.

dmesg | grep -i kvm
[    1.078559] kvm [1]: nv: 554 coarse grained trap handlers
[    1.084177] kvm [1]: IPA Size Limit: 40 bits
[    1.088486] kvm [1]: GICV region size/alignment is unsafe, using trapping (reduced performance)
[    1.097272] kvm [1]: vgic interrupt IRQ9
[    1.101231] kvm [1]: VHE mode initialized successfully
[    3.526966] systemd[1]: Hostname set to <kvm>

Оскільки kvm працює за замовченням, необхідно довстановити libvirt

sudo apt install libvirt-daemon-system libvirt-clients bridge-utils virtinst

Перевірка роботи сервісу:

systemctl status libvirtd
● libvirtd.service - Virtualization daemon
     Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-05-08 10:42:46 BST; 25s ago
TriggeredBy: ● libvirtd-admin.socket
             ● libvirtd-ro.socket
             ● libvirtd.socket
       Docs: man:libvirtd(8)
             https://libvirt.org
   Main PID: 4708 (libvirtd)
      Tasks: 19 (limit: 32768)
        CPU: 138ms
     CGroup: /system.slice/libvirtd.service
             └─4708 /usr/sbin/libvirtd --timeout 120

May 08 10:42:46 kvm systemd[1]: Starting libvirtd.service - Virtualization daemon...
May 08 10:42:46 kvm systemd[1]: Started libvirtd.service - Virtualization daemon.

Зміна прав користувача

Необхідно додати користувача kvm до груп libvirt. Оскільки ми на першому етапі створили користувача kvm, то нема потреби його додавати в групу kvm, проте якщо ви на початковому етапі створили іншого користувача, то його необхідно додати в групу kvm.

sudo usermod -aG libvirt kvm

Після додавання користувача до групи libvirt, щоб не перезавантажувати систему, можна активувати нові права командою:

newgrp libvirt

Встановлення Cockpit

Cockpit – це веб-інтерфейс для керування Linux-серверами, і один із його плагінів — Cockpit Machines — є надбудовою саме для KVM

sudo apt install cockpit cockpit-machines

Перевірка роботи служби:

sudo systemctl status cockpit.socket
● cockpit.socket - Cockpit Web Service Socket
     Loaded: loaded (/lib/systemd/system/cockpit.socket; enabled; preset: enabled)
     Active: active (listening) since Thu 2025-05-08 10:59:18 BST; 46s ago
   Triggers: ● cockpit.service
       Docs: man:cockpit-ws(8)
     Listen: [::]:9090 (Stream)
      Tasks: 0 (limit: 9561)
        CPU: 12ms
     CGroup: /system.slice/cockpit.socket

May 08 10:59:18 kvm systemd[1]: Starting cockpit.socket - Cockpit Web Service Socket...
May 08 10:59:18 kvm systemd[1]: Listening on cockpit.socket - Cockpit Web Service Socket.

Служба активна, проте в режимі прослуховування, треба її активувати виконавши команду:

sudo systemctl enable --now cockpit.socket

отримаємо результат, де cockpit сокет буде вже активним.

sudo systemctl status cockpit.socket
● cockpit.socket - Cockpit Web Service Socket
     Loaded: loaded (/lib/systemd/system/cockpit.socket; enabled; preset: enabled)
     Active: active (running) since Thu 2025-05-08 10:59:18 BST; 3min 24s ago
   Triggers: ● cockpit.service
       Docs: man:cockpit-ws(8)
     Listen: [::]:9090 (Stream)
      Tasks: 0 (limit: 9561)
        CPU: 12ms
     CGroup: /system.slice/cockpit.socket

May 08 10:59:18 kvm systemd[1]: Starting cockpit.socket - Cockpit Web Service Socket...
May 08 10:59:18 kvm systemd[1]: Listening on cockpit.socket - Cockpit Web Service Socket.

Тепер можна переходити за посиланням на порт 9090 в браузері: https://192.168.99.180:9090/

Тест гостьової ОС

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

Для універсальності я перемкнув інтерфейс на англійську мову, мені так більше подобається працювати. Отже, щоб створити ОС необхідно перейти в меню Virtual machines та клацнути на кнопку Create VM відкриється вікно Create new virtual machine де треба вибрати бажані параметри ОС

Попередньо я завантажив ISO образ убунту сервера ubuntu-24.04.2-live-server-arm64.iso і розмістив його в корені системи в лдиректорії iso. Цей образ я буду запускати локально.

• Name: Ubuntu_server
• Connection: System
• Installation type: Local install medis (ISO image or distro install tree)
• Installation source: /iso/ubuntu-24.04.2-live-server-arm64.iso
• Operating system: Generic Linux 2022
• Storage: Create new volume
• Storage limit: 20 Gib
• Memory: 4 Gib

Щоб розпочати створення клацни create and run, але через мить ти отримаєш помилку:

Це помилка означає, що віртуальна машина не може бути створена, бо мережа default неактивна. Libvirt за замовчанням створює віртуальну мережу з ім’ям default, але вона може бути неактивною або неавтоматичною при запуску. Щоб виправити це необхідно активувати мережу і додати її до автозапуску, для цього на хості треба лише виконати дві команди:

sudo virsh net-start default
Network default started

sudo virsh net-autostart default
Network default marked as autostarted

перевіримо статус мережі default:

sudo virsh net-list --all
 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

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

Для визначення та зміни налаштувань віртуальної ОС, або для доступу до керування ОС як мінімум для логічного завнершення встановлення необхідно вибрати в списку необхідну ОС і тоді користувач попаде на дашборд цієї ОС із детальними її характеристиками

Щоб збільшити екран консолі, клацаємо на кнопку Expand, і приступаємо до встановлення Ubuntu Server for ARM. В моєму випадку вікно було частково обрізано тому я встановив ОС інтуїтивно, вибиравши параметри кнопками ліворуч праворуч, таб, пробіл та ентер.

Перший запуск встановленої ОС не відбувся успішно, виник конфлікт зациклення. В консолі вибравши Serial Console, я побачив багато повідомлень: Recursive exeption occurred while dumping the CPU state.

Після вимкнення віртуальної машини та через певний час запуску, з другої спроби запуск все-ж таки відбувся, проте не без помилок. Оскільки ця ОС хмарна, то їй потрубен доступ до інтернету. На даний момент інтернет не налаштовано, тому запуск відбувся посля очікування повідомлення:

Connected to domain 'linux2022-2025-5-10'
[ ***  ] Job systemd-networkd-wait-online.se…tart running (1min 22s / no limit)

Але вссе-ж таки ОС запустилася!

Тепер треба перейти до розділу налаштування локальної мережі та інтернету через брідж.

Налаштування мережі

За замовчанням використовується вбудований інтерфейс virtio із наступною мережею 192.168.122.1/24, для гостьової ОС був виділен IP 192.168.122.39 проте сам хост знаходиться в іншій підмережі, через що треба виконати певні налаштування.

Створення мосту відбувається в розділі Networking -> Interfaces, вибираємо Add Bridge і прописуємо назву bridge0, жодної галочки не ставимо, бо це може призвести до втрати звязку із хостом. Таким чином в списку інтерфейсіів зявився новий інтерфейс bridge0 із автоматичним отриманням IP адреси DHCP. Зараз нема жодного інтерфейсу, який би був повязаним з цим бріджем, тому продовжуємо налаштування вже на хості через термінал.

Треба переконатися, що фізичний інтерфейс хоста включено в в брідж

sudo brctl show
bridge name     bridge id               STP enabled     interfaces
bridge0         8000.000000000000       no
virbr0          8000.5254006ad9b7       yes

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

sudo brctl addif bridge0 eth0
sudo ip link set bridge0 up

Повторно запускаємо команду перевірки стану бріджу і бачимо, що колонка інтерфейс вже набула звязку із фізичним інтерфейсом:

sudo brctl show
bridge name     bridge id               STP enabled     interfaces
bridge0         8000.d83adde83f07       no              eth0
virbr0          8000.5254006ad9b7       yes

Після цього брідж буде виконувати свою функцію. Тепер переходимо знову в веб інтерфейс Cockpit в розділ Networking і очікуємо від бріджа IP адресу.

IP адреса правильної підмережі з’явилася в колонці IP address, проте через певні особливості віртуальна машина так і не отримала

Висновок

Використання KVM-віртуалізації та Cockpit на Raspberry Pi — це чудова можливість для навчання, тестування та експериментів у світі ARM64-віртуалізації. Ця комбінація дозволяє користувачам глибше розібратися в принципах гіпервізора, управлінні ресурсами та налаштуванні мережевих інтерфейсів.

Однак, практичне застосування залишається досить сумнівним через кілька серйозних обмежень:

1. Сумісність ARM64-операційних систем
   • Багато популярних ОС мають .img замість .iso, що ускладнює їх запуск у KVM.
   • Не всі дистрибутиви коректно підтримують UEFI, що призводить до складнощів із завантаженням.
   • Відсутність офіційних оптимізованих ARM64-дистрибутивів у форматі .iso.
2. Нестабільна робота KVM на ARM64
   • Часті проблеми із сумісністю CPU (KVM is not supported for this guest CPU type).
   • Виникнення критичних помилок, таких як “Recursive Exception occurred while dumping the CPU state”, що робить роботу віртуальних машин непередбачуваною.
   • Обмежена підтримка host passthrough для ARM64.
3. Складнощі з мережевими налаштуваннями
   • Нестабільність у конфігурації моста (bridge0) через NetworkManager.
   • Проблеми з DHCP та ручним додаванням інтерфейсів у міст (NO-CARRIER).
   • Cockpit не завжди правильно розпізнає мережеві параметри у ARM64-віртуальних машинах.

В цілому, KVM на Raspberry Pi — це більше експериментальна платформа, ніж стабільний варіант для продуктивного використання. Вона чудово підходить для досліджень у сфері віртуалізації на малопотужних ARM-пристроях, проте через технічні обмеження та нестабільність її важко рекомендувати для реальних розгортань.

У світі IoT та домашніх серверів Raspberry Pi є незамінним помічником. Проте для забезпечення його стабільної роботи важливо постійно контролювати ключові параметри, зокрема температуру процесора. У цій статті я покажу, як за допомогою Zabbix налаштувати моніторинг температури CPU Raspberry Pi – від прав доступу до створення графіка на дашборді. Цей гайд допоможе вам не лише дізнатися поточну температуру, але й вчасно отримувати сповіщення у випадку перегріву.

В мене Zabbix встановлений на Raspberry Pi, тому для неї він виступає в ролі як сервера так і клієнта, що трошки полегшує налаштування.

Налаштування прав доступа для Zabbix агента

Щоб уникнути помилок при зборі температури необхідно додатково виконати наступні дії, вони залежать від певних помилок, з якими я стикався під час налаштування.

Try creating a device file with: sudo mknod /dev/vcio c 100 0

Оскільки девайс /dev/vcio існує, йому просто недостатньо прав для коректної роботи. Необхідно змінити дозвіл, щоб Zabbix міг використовувати /dev/vcio

sudo chgrp video /dev/vcio
sudo chmod 660 /dev/vcio

Також треба додати користувача zabbix до групи video, щоб мати доступ

sudo usermod -aG video zabbix

Щоб зміни вступили в силу, треба перезавантажити агента

sudo systemctl restart zabbix-agent

Тепер можна перейти до користувацьких налаштувань

Налаштування відстеження температури

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

sudo nano /etc/zabbix/zabbix_agentd.conf

В кінці файлу додайте рядок:

UserParameter=system.cpu.temp,vcgencmd measure_temp | sed -n "s/temp=\([0-9]*\.[0-9]*\)[^0-9]*$/\1/p"

Детальний опис цієї команди:

• UserParameter – це назва функції для користувацького ключа
• system.cpu.temp – це ключ, який ми будемо використовувати
• vcgencmd measure_temp – Це стандартна команда Raspberry Pi, яка повертає температуру CPU у форматі: temp=45.0’C
• s/temp=\([0-9]*\.[0-9]*\)[^0-9]*$/\1/p – це регулярний вираз який прибирає зайві символи і залишає числове значення.

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

sudo systemctl restart zabbix-agent

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

Додавання елемента (item) у Zabbix

У веб-інтерфейсі Zabbix відкрий: Data collection → Hosts → Zabbix server → Items → Create item

Заповнюються такі поля:

• Name: CPU Temperature
• Type: Zabbix agent
• Key: system.cpu.temp
• Type of information: Numeric (float)
• Units: °C

Щоб впевнитися, що все правильно заповнено необхідно протестувати роботу цього айтемса, клацаємо на кнопку Test. У вікні Test item клацаємо Get value and test і отримуємо результат.

Зберігаємо цей Айтем клацнувши на Add або Update

Налаштування тригера для сповіщення

Для того, щоб я отримував сповіщення про підвищення температури, наприклад до бажаного значення в 70 градусів, потрібно створитти тригер. Він буде порівнювати поточну температуру із критичною, і якщо така подія відбудеться то на дашборді з’явиться нотифікація.

Перейди до: Data collection → Hosts → Zabbix server → Triggers → Create trigger

У вікні треба заповнити поля:

• Name: CPU Temperature is too high
• Event name: CPU Temperature is too high
• Severity: Warning
• Expression: last(/Zabbix server/system.cpu.temp)>=70

або клацнути на кнопку Add і через конструктор виразу вибрати необхідні параметри як зображено на скріншоті.

Це означає, що якщо температура перевищить 70°C, тригер спрацює.

Натисни Add, щоб зберегти цей тригер.

Віджет графа на дашборді

Було б візуально привабливо спостерігати за графіком температури пристрою в залежності від умов використання.

Для цього треба перейти на дашборд, натиснути “edit dashboard” і визначити місце нового графіку. Відкриється вікно з налаштуваннями, треба вибрати:

• Type: Graph
• Name: RPI Temp C
• Host patterns: Zabbix Server
• Item patterns: CPU Temperature

Додати цей віджет клацнувши на кнопку Add.

Таким чином дашборд заббікса буде відстежувати температуру распбері пай та візуально ілюструвати графік на дашборді.

Далі можна змінити розмір та розмістити цей віджет як буде зручно. Після цього в правому верхньому куті підтвердити збереження дашборду клацнувши на кнопку Save changes.

Висновки

Як бачимо, налаштування Zabbix для моніторингу температури CPU на Raspberry Pi не є складним, але вимагає уваги до деталей, особливо при роботі з правами доступу. Завдяки кастомному параметру, тригеру та візуалізації на дашборді, ви отримаєте потужний інструмент для контролю стану вашого пристрою. Це особливо корисно для довготривалих проєктів, серверних завдань або просто для ентузіастів, що бажають знати більше про роботу свого Raspberry Pi.