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

Переглянути лістинг контрибуторів можна за посиланням тут. Або в Інтернет Архіві через Wayback Machine.

Посилання за темою:

ESPHome Devices

GitHub

Просте впровадження моніторингу радіації

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

Він надає повний набір даних, необхідних для повноцінного контролю, включаючи:

• Потужність (μSv/h)
• Еквівалентна поглинута доза (μSv/h)
• Сукупна доза (μSv)
• Кількість імпульсів за хвилину (CPM) за період часу виміру
• Миттєве значення кількості імпульсів (pulse count)
• Статус системи (попередження про небезпеку, нормальний рівень або помилки сенсора)

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

Ключова перевага: Крос-контролерна сумісність

Головна цінність розробки компоненту полягає в забезпеченні універсальності. Компонент ggreg20_v3 є крос-контролерним і підтримує будь-який мікроконтролер, сумісний з ESPHome (включно з ESP32, ESP8266, Raspberry Pi Pico W та іншими).

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

“Ми створили компонент ggreg20_v3 з думкою про спільноту ESPHome. Наша мета — зробити моніторинг навколишнього середовища максимально доступним і надійним, надаючи єдине, гнучке рішення, яке працює відразу на всіх підтримуваних контролерах,” — прокоментували новину у IoT-devices LLC.

Як почати використовувати

Компонент ggreg20_v3 доступний як зовнішній компонент Git.

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

• GitHub Репозиторій: [https://github.com/iotdevicesdev/esphome_external_components]
• Документація: Перегляньте README.md для повної інструкції з встановлення та налаштування.

IoT-devices LLC запрошує спільноту до тестування, надання зворотного зв’язку та внесків у розвиток компонента.

В даній новинній публікації йдеться про першу складову проекту, а саме про ESP32 BLE Server. Ми розробили YAML-приклад для прошивки ESPHome. Оскільки у нас вже є кілька прикладів для ESPHome, ми подумали, що і цього разу варто обрати цю чудову, популярну і відносно просту технологію.

Створений таким чином BLE Server, буде спроможний працювати автономно, а також з сервером Home Assistant (HA). Ті користувачі, у яких є HA, зможуть обирати, як саме використати розроблений нами приклад.Ті ж, у кого немає HA, зможуть користуватися лічильником Гейгера GGreg20_V3 через ESP32 BLE повністю автономно і незалежно від будь-яких інших додаткових технологій.

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

Опис цієї частини проекту і сам YAML-файл конфігурації для створення прошивки ви можете знайти на нашому GitHub за посиланням:

https://github.com/iotdevicesdev/GGreg20_V3-BLE_Server-ESP32-ESPHome

У другій частині ми плануємо викласти приклад готового клієнтського додатку для ОС Android і розповісти як ми його розробляли і які функції заклали. Наразі процес дещо стримує процедура публікації додатку на Google Play.

Також у нас в планах викласти вихідний MIT AI2 “код” додатку у вільний доступ.

Київ. Україна. 2025 рік

ORCID: 0009-0002-6482-9419

Методологія тестування

Для проведення вимірювань ми розробили спеціальний тестовий стенд на базі платформи Home Assistant. Центральним елементом системи був контролер Raspberry Pi Pico W з прошивкою ESPHome, який керував роботою модуля GGreg20_V3. Для точного вимірювання споживаної енергії ми використовували сенсор INA219, підключений до контролера NodeMCU / ESP8266 також з прошивкою ESPHome. У якості джерела живлення GGreg20_V3 ми застосували лабораторний блок живлення, який і задавав точний рівень напруги під час тестування. 

Оскільки модуль GGreg20_V3 підтримує широкий діапазон напруг живлення, щонайменше від 3.0 і аж до 5.5В, для того, щоб показати наскільки відрізняється результат тесту, ми взяли три найпоширеніших рівня напруги живлення: 3.3В, 3.7В, 5.0В. Такі напруги дають уявлення про те, яке буде споживання модуля під час живлення від:

• іншого контролера чи джерела з напругою 3.3В;
• літієвої акумуляторної батареї з напругою 3.7В;
• іншого контролера чи джерела з напругою 5В.

Важливо зазначити, що сенсор INA219 вимірював лише енергоспоживання модуля GGreg20_V3, тоді як контролери живилися окремо. Це дозволило отримати максимально точні дані.

Також відмітимо, що рівень напруги живлення з плином часу у межах 60 хвилинного тесту не змінювався. Тому не слід сподіватися, що ми виконали повну емуляцію, наприклад літієвої батареї, що розряджається під навантаженням і відповідно втрачає напругу з 4.2В до 2.5В на протязі тесту. І хоча, це був би дійсно корисний і цікавий дослід, ми вирішили настільки сильно не заморочуватися з цим.

Тестовий стенд

Програмне забезпечення на боці вимірювального сенсора спожитої електричної енергії на базі ESP8266 + INA219 з прошивкою ESPHome:

sensor:
  - platform: ina219
    address: 0x40
    shunt_resistance: 0.1 ohm

    current:
      name: "INA219 Current"
      accuracy_decimals: 5
      id: current_value

    power:
      name: "INA219 Power"
      accuracy_decimals: 5
      id: power_value

    bus_voltage:
      name: "INA219 Bus Voltage"
      accuracy_decimals: 5

    shunt_voltage:
      name: "INA219 Shunt Voltage"
      accuracy_decimals: 5

    max_voltage: 32.0V
    max_current: 3.2A
    update_interval: 1min

  - platform: integration
    name: "Total Energy Consumed"
    id: total_energy
    sensor: power_value
    time_unit: min
    accuracy_decimals: 5
    unit_of_measurement: "Wh"
    filters:
      - multiply: 0.0166666666666667

  - platform: integration
    name: "Total Current Consumed"
    id: total_current
    sensor: current_value
    time_unit: min
    accuracy_decimals: 5
    unit_of_measurement: "Ah"
    filters:
      - multiply: 0.0166666666666667

Цей фрагмент YAML-конфігу забезпечує всі необхідні дані для запланованого нами тестування модуля сенсора радіації GGreg20_V3 з точки зору споживання енергії під час роботи у нормальних умовах фонового випромінювання.

Процес вимірювання

Вимірювання споживання енергії проводилися щохвилини, з накопиченням даних за попередні періоди. Тестування тривало протягом години, що дозволило отримати значення реального споживання модуля GGreg20_V3 за 60 хвилин для кожної з трьох напруг живлення.

Платформа Home Assistant використовувалася для збору та фіксації даних з сенсорів. Вона також надала інструменти для створення наочних графіків споживання електроенергії.

Результати та висновки

Завдяки проведеному тестуванню ми отримали детальні дані про споживання електроенергії модулем GGreg20_V3 при різних напругах живлення. Отримані результати дозволяють користувачам оптимізувати енергоспоживання своїх DIY-проектів з використанням цього модуля.

Живлення напругою 3.3В

Живлення напругою 3.7В

Живлення напругою 5.0В

Узагальнені результати

Тестування споживання енергії модулем GGreg20_V3 проводилося протягом 60 хвилин при різних напругах за нормальних умов. Цикл оновлення вимірів INA219: 1 хвилина

Дата проведення: 27.08. – 31.08.2023

Під час тестування відхилень у вимірах рівня радіації не спостерігалося

Тестування проводилося з налаштуваннями модуля GGreg20_V3 за замовчуванням. Базер включений. Діод захисту Шотткі – встановлений. Синій індикатор живлення світиться постійно. Напруга живлення залишалася незмінною на протязі всього циклу тестування.

Додаток. Теоретичний графік розряду батарей

Ми також вирішили показати наочно теоретичний графік розряду при трьох різних напругах під час живлення модуля GGreg20_V3 від акумуляторних батарей різної хімії та ємності.

За основу для розрахунків ми взяли характеристики батарей, що є в інтернет:

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

Про GGreg20_V3

Модуль лічильника Гейгера GGreg20_V3 виробництва ТОВ “ІОТ-ДЕВАЙСЕС” (aka IoT-devices, LLC) є флагманським продуктом компанії, що знайшов своїх користувачів у більш ніж 30 країнах світу. 

По всьому світові радіоаматори застосовують GGreg20_V3 – створюють власні DIY проекти, навчаються та ставлять експерименти, пов’язані з вимірюванням радіації. 

Розробляючи цей продукт і удосконалюючи його з 2020 року, ми намагалися зробити модуль компактним, готовим до використання, сумісним з якомога більшою кількістю DIY платформ і систем, невибагливим щодо живлення, простим з точки зору програмування та гармонізованим за робочими характеристиками з різноманітними трубками Гейгера. 

А ще ми розробили низку прикладів та виклали їх на GitHub для різноманітних апаратних та програмних платформ як от Arduino UNO, ESP32, ESP8266, Raspberry Pi Pico W, NodeMCU, ESPHome, Tasmota, MicroPython, Home Assistant.

І ми, у IoT-devices сподіваємося, що наші Клієнти отримують чудовий користувацький досвід та справжнє задоволення, впроваджуючи цей модуль у свої проекти.

А також ми дякуємо кожному, що підтримали та обрали цей розроблений і виготовлений в Україні продукт. Ми це дуже цінуємо!

Ключові слова

Лічильник Гейгера 

GGreg20_V3

Тестування споживання електроенергії

DIY-проекти

Home Assistant

Raspberry Pi Pico W

ESPHome

INA219

NodeMCU

ESP8266

I2C

WiFi

YAML

Якщо ви стикнулися з такою ж ситуацією після оновлення ваших пристроїв ESP32 з прошивкою ESPHome, радимо ознайомитися з нашим репозиторієм, який вже містить опис та обхідне рішення виявленої проблеми. Ось шлях: https://github.com/iotdevicesdev/GGreg20_V3-ESP32-HomeAssistant-ESPHome

Також запрошуємо почитати обговорення на GitHub:
https://github.com/iotdevicesdev/GGreg20_V3-ESP32-HomeAssistant-ESPHome/issues/5

З повагою,
IoT-devices Team

Та найголовніша його перевага у тому, що він працює через I2C шину. 

Чому ці термометри є недооціненими

Хтось може зауважити, що LM75 це не найкращий сенсор за своїми технологічними особливостями і виконанням у вигляді мікросхеми. І дійсно, є багато інших типів сенсорів температури, такі як 1-Wire Dallas  DS18b20. Ці сенсори мають одно-провідне підключення та багато інших конструктивних переваг, таких як вологозахищені металізовані корпуси у вигляді капсули, тощо. На шину 1-Wire можливо підключити багато термометрів на одному дроті, 1Wire підтримує контроль помилок та ідентифікацію пристроїв, тощо, тощо.

Але у шини 1-Wire є один і найголовніший недолік – для цієї шини не випускають інших пристроїв, крім термометрів. Точніше не так, їх випускають, але це настільки не популярний сегмент, що їх неможливо купити.

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

• Сенсор BME680 / BME280 I2C / SPI;
• Сенсор DS18b20 1-Wire;
• Дисплей SPI / I2C;
• Сенсор блискавки AS3935 SPI / I2C;
• Сенсор освітленості MAX44009 I2C;
• Сенсор температури та вологості HDC1080 I2C;
• Сенсор CCS811 I2C;
• Сенсор SCD4X I2C;

І навіть в ситуації з потужним ESP32 (не кажучи про ESP8266 та подібні контролери, як-от Arduino чи RPI Pico W), ми будемо вимушені вирішувати задачу оптимізації кількості інтерфейсів та протоколів. Адже обробка кількох різних протоколів рано чи пізно вплине на нашу розробку і буде вимагати спрощення не лише на боці апаратного забезпечення (бюджет вільних портів вводу-виводу), а і програмної реалізації драйверів для різних протоколів та інтерфейсів, які мають крутитися паралельно в головному циклі контролера.

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

Тому, на нашу думку варто одразу обирати рішення, які буде можливо легко розширювати та експлуатувати в майбутньому. 1-Wire- та SPI- пристрої мало придатні до таких вимог і через це ми радимо їх не розглядати крім випадків, коли це дійсно необхідно (як у випадку з SPI: дисплеями високої роздільної здатності, чи вимірюванням величин з швидкостями наближеними до реального часу).

Варто спробувати будувати оптимальне програмно-апаратне рішення – робимо крок у бік шини I2C. Тобто, оскільки у нас на головному контролері буде дисплей SSD1306 з I2C, кейпад I2CUI4_V1 з I2C – навіщо нам ставити сенсори температури з якимось іншим інтерфейсом? – Так і вирішили, буде лише один інтерфейс: шина I2C. Всі з’єднання будуть через поділювач / хаб I2CHUB_V1, який підтримує підключення до контролера 5 пристроїв одночасно.

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

Вбудовані у ESPHome драйвери

Втім, коли ми робимо пошук на сайті ESPHome, то виявляється, що сенсор LM75, який ми зібралися використати у проекті в якості термометрів, не підтримується – вбудованого драйвера немає.

Починаємо проводити власне невелике розслідування щодо наявних драйверів у ESPHome для сенсорів температури подібних до LM75 (0.89 USD на Mouser). І виявляємо, що є два інші термометри, для яких вже написано вбудований драйвер у ESPHome:

• MCP9808 (1.39 USD на Mouser)
• TMP1075 (0.74 USD на Mouser)

Обидва сенсори нас би влаштували технічно. Вони є в наявності на Mouser та інших подібних майданчиках. Але ми не змогли знайти готові модулі з цими мікросхемами за ціною, яка була б наближено до ціни на модулі з LM75. 

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

Цікаво, що сенсор TMP1075 є сумісним зі специфікацією LM75 (про це чітко вказано у даташит), яка дефакто є галузевим стандартом. Відтак, ми зробили висновок, що можемо спробувати підключити наш LM75-термометр з драйверами для TM1075, які є вбудованими у ESPHome.

Але, на жаль, у нас не вийшло зробити таке підключення, навіть зважаючи на те, що адресація на шині, внутрішні регістри є тотожними у згаданих сенсорів. Єдине що їх відрізняє, так це те, що у TMP1075 також є спеціальний регістр ідентифікації, якого не має сенсор LM75. Але навіть спроби внести зміни у перевірку типу сенсора на рівні CPP-коду цього драйвера не дали нам змоги його застосувати з чипом LM75.

Примітка. Чесно кажучи, нам досі не зрозуміло, чому розробники та контрибутори ESPHome, досі не зробили вбудованого драйвера для LM75. Нам би не довелося писати цю публікацію і проводити купу часу за дивними експериментами.

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

Підключення драйвера ззовні

Як ви мабуть знаєте, в ESPHome є щонайменше два механізми підключення власних драйверів пристроїв ззовні: Custom Component та External Component. 

Custom component наразі вважається застарілим варіантом інтеграції і не рекомендується документацією ESPHome до використання. 

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

Відмінність External Component полягає у тому, що користувач ESPHome не прописує вручну інтерфейси для потоків даних з сенсора через манівці, а застосовує цілком регламентовані механізми, які до речі застосовуються також всіма іншими компонентами ESPHome:

Отже, щоб підключити External Component, спочатку потрібно правильно описати його обвязку. Ми не будемо тут занурюватися у деталі програмування та конфігурацій, адже ми знайшли на GitHub вже готовий компонент для LM75.

Щоб додати сенсори LM75, у YAML-конфіг пристрою в ESPHome, потрібно додати лише кілька рядків:

• підключити зовнішній компонент (External Component):

• додати сутності сенсорів LM75

Для зручності ми форкнули репозиторій esphome-lm75, який надано https://github.com/btomala на GitHub у свій акаунт https://github.com/iotdevicesdev/esphome-lm75

Приклад, як виглядає підключення драйверів LM75 для контролера ESP12.OLED_V1 виробництва IoT-devices, LLC у ESPHome:

# YAML Config Example
esphome:
  name: esp12oled-lm75
  friendly_name: esp12oled-lm75
  comment: "Configuration example of two LM75 for ESP12.OLED_V1 with ESPHome firmware"
  project:
    name: "iot-devices.esp12oled-lm75"
    version: "1.0.0"


external_components:
  - source: github://iotdevicesdev/esphome-lm75
    components: [ lm75 ]


esp8266:
  board: nodemcuv2


logger:


api:
  encryption:
    key: "8tDDLc3S5dnSjADItGR5+7KxoUBhUIqeOiJZIXy"


ota:
  password: "c15e9a44e1408352d945b8cd35b79"


wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password


  ap:
    ssid: "Test-Node Fallback Hotspot"
    password: "rtF1XxDZ9"


captive_portal:


i2c:
  sda: 4
  scl: 5
  id: i2c_bus


sensor:
  - platform: lm75
    id: temperature
    name: "LM75 temperature"
    update_interval: 30s
    address: 0x48


  - platform: lm75
    id: temperature2
    name: "LM75 temperature2"
    update_interval: 30s
    address: 0x49
# END YAML Config Example

Примітка. Цей код також є на нашому GitHub: github.com/iotdevicesdev/ESP12.OLED_V1-LM75-ESPHome 

Склад проекту

1 x Модуль ESP12.OLED_V1 з прошивкою ESPHome 2023.12.5;

1 x Модуль I2CHUB_V1;

1 x Модуль LM75 (no brand);

1 x Модуль CJMCU-75.

Результати проекту

Головне, що ми хотіли вам розповісти у цьому тексті:

1. Ми підключили LM75 через механізм External Component настільки легко і просто, що самі не повірили у успіх після складних експериментів з драйвером для TMP1075.
2. Конфігурації підтягуються напряму з GitHub, або можуть лінкуватися з локального сховища на вашому ESPHome / HomeAssistant диску. Підключений таким чином External Component автоматично включається у прошивку під час її компіляції.
3. Ми перевірили, що з цим компонентом не виникає проблем з адресацією кількох сенсорів LM75 одночасно.
4. Все настільки ж просто, як підключити у ESPHome сенсор для якого є вбудований драйвер на кшталт BME280. Простота застосування готового компоненту через метод External Component не йде ні в яке порівняння з застосуванням застарілого методу Custom Component, який ми колись робили для інших своїх задач із сенсором ультрафіолету VEML6070.  

Як можна бачити на наступних скріншотах, наш проект успішно виконано:

• LM75 підключено до контролера ESP12.OLED_V1 з прошивкою ESPHome;
• Два сенсори LM75 одночасно працюють з головним контролером. Там де працює два сенсори, може працювати і вісім (за потреби, LM75 має три піни конфігурації I2C адреси, що дозволяє одночасно працювати з вісьмома сенсорами на кожній шині I2C);
• Дані з сенсорів потрапляють у Home Assistant та виводяться на Dashboard;
• Далі значення сенсорів можуть або автономно виводитися на дисплей контролера ESP12.OLED_V1 засобами прошивки ESPHome, та/або можуть застосовуватися у сценаріях автоматизації Home Assistant.

Значення сенсорів LM75 на Dashboard сервера Home Assistant:

Графіки з Logbook сервера Home Assistant:

Значення сенсорів LM75 у меню Developer Tools сервера Home Assistant:

Скріншоти консолі ESPHome:

• Пристрої знайдено під час сканування шини I2C (дисплей і два термометри)

• Драйвери для сенсорів LM75 ініціалізовано

• Дані з сенсорів отримує ESPHome та передає у Home Assistant

Це наразі все, що ми запланували розповісти за цією темою.

Дякуємо за увагу!

Бажаємо успіхів!

Цей механізм отримав назву Pin Reuse validation: https://esphome.io/changelog/2023.12.0.html#pin-reuse-validation

Ці оновлення у версії ESPHome 2023.12.0 також торкнулися прикладів розроблених нашою компанією для продукту GGreg20_V3 Geiger counter ionizing radiation detector module. 

Відповідно до звернення (https://github.com/iotdevicesdev/GGreg20_V3-ESP32-HomeAssistant-ESPHome/issues/2) користувача стосовно репозиторію для GGreg20_V3-ESP32-HomeAssistant-ESPHome ми внесли необхідні оновлення в конфігураційний YAML-файл. 

Тепер цей приклад буде нормально працювати з урахуванням нововведень у валідацію конфігурацій ESHome та ви зможете перейти на нові версії ESPHome без проблем.

Ми також плануємо оновити інші репозиторії з цією проблемою.

Ви також самостійно можете внести зміни у свої YAML-файли конфігурації у ESPHome. 

Станом на зараз нам відомо два шляхи виправлення конфігу так, щоб він проходив нові правила валідації конфігурації:

Шлях №1. Якщо вам потрібно повторно використати pin, натомість використовуйте https://esphome.io/components/copy.html

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

Для сутностей сенсорів (sensor entities):

https://esphome.io/components/copy.html#copy-sensor

для сутностей дискретних сенсорів (binary sensor entities):

https://esphome.io/components/copy.html#copy-binary-sensor

Приклад коду який ви маєте отримати наведено ось тут:

https://github.com/iotdevicesdev/GGreg20_V3-ESP32-HomeAssistant-ESPHome/issues/2#issuecomment-1867814996

Шлях №2. Ви також можете задіяти виключну можливість, описану у документі ESPHome Pin Schemma:

https://esphome.io/guides/configuration-types#config-pin-schema

config key: “allow_other_uses”

Ви можете використати цей ключ налаштування щоб обійти контроль повторного застосування пінів у виключних ситуаціях. 

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

Помилкові ключі:

Правильні ключі:

У вас має вийти ось такий код із застосуванням ключа “alow_other_uses”:

# YAML code example:
- platform: pulse_counter
    pin: 
      number: GPIO2
      allow_other_uses: true
    state_class: "measurement"
    unit_of_measurement: 'CPM'
    name: 'Ionizing Radiation Power CPM'
    count_mode: 
      rising_edge: DISABLE
      falling_edge: INCREMENT # GGreg20_V3 uses Active-Low logic
  # It seems that only one instance of pulse counter internal filters can be set
  # So here no any debounce filters for CPM value 
    use_pcnt: False
    internal_filter: 180us
    update_interval: 60s
    accuracy_decimals: 0
    id: my_cpm_meter
 
  - platform: pulse_counter
    pin:
      number: GPIO2
      allow_other_uses: true
      inverted: True
      mode: 
        input: True 
        pullup: False
        pulldown: False
    unit_of_measurement: 'uSv/Hour'
    name: 'Ionizing Radiation Power'
    count_mode: 
      rising_edge: DISABLE
      falling_edge: INCREMENT
    update_interval: 60s
    accuracy_decimals: 3
    id: my_dose_meter
    filters:
  #    - sliding_window_moving_average: # 5-minutes moving average (MA5) here
  #        window_size: 5
  #        send_every: 1      
      - multiply: 0.0057 # or 0.00332 for J305 by IoT-devices tube conversion factor of pulses into uSv/Hour
# END of YAML code example

Ви можете обирати, який із способів підходить до вашого DIY проекту.

На цьому все. Бажаємо успіхів!

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

• враховано і підтримується два типи трубок: J305 та SBM20. Користувач може перемикатися між двома типами трубок за допомогою зручного селектора для розрахунку значень безпосередньо під час роботи, через фронтенд, наприклад, через віджет інформаційної панелі “Home Assistant”.
• було враховано та запропоновано режим компенсації внутрішнього шуму трубки Гейгера. Цей режим також можна перемикати безпосередньо під час роботи через фронтенд.
• розрахунок компенсації внутрішнього шуму також враховує ситуацію, коли кількість імпульсів недостатня для компенсації. У цьому випадку компенсація не виконується. Зверніть увагу, що наш приклад містить коефіцієнти, надані виробниками трубок Гейгера: для J305 – 0,2 імпульсу на секунду; для SBM20 – 1 імпульс на секунду.
• конфігурація створює окремий текстовий датчик, який автоматично показує поточний стан відповідно до рівня радіації: нормальний / попередження / небезпека.
• текстовий датчик стану також підтримує ситуацію, коли від модуля GGreg20_V3 не надходять імпульси. У такому випадку цей датчик матиме значення “помилка сенсора”..

https://github.com/iotdevicesdev/RPi-Pico-W_GGreg20_V3-ESPHome

Нам стало цікаво, що станеться, якщо ми візьмемо наш DIY модуль лічильника Гейгера GGreg20_V3 і разом з контролером ESP32 помістимо його в морозильну камеру з цільовою температурою -23 градуси за Цельсієм. 

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

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

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

• плата модуля лічильника Гейгера, 
• плата контролера ESP32, 
• з’єднання між ними, 
• та трубка Гейгера-Мюллера СБМ20.

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

Хоча трубка Гейгера-Мюллера має відповідний температурний діапазон (від -60°C до +70°C) зазначений виробником, вона також може змінювати свою поведінку під впливом низьких температур. Наприклад, втрата здатності генерувати імпульси через уповільнення молекулярних/електронних процесів внаслідок зменшення енергії частинок у газах, що заповнюють трубку, або, навпаки, лавиноподібна іонізація всередині колби через термодинамічні характеристики цих газів (Ne+Br2+Ar).

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

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

І…. І ми задоволені цим тестом, але не будемо забігати наперед і розповімо, як все відбувалося покроково.

Отже, в цьому експерименті ми мали на меті дослідити роботу DIY модуля лічильника Гейгера при низьких температурах. Ми помістили модуль лічильника Гейгера і контролер ESP32 в морозильну камеру з температурою -23 градуси Цельсія і тримали його там протягом 5 годин. Ми записували вимірювання з датчика і спостерігали за графіками вимірювань, щоб оцінити будь-які збої або відхилення у вимірах датчика випромінювання.

Ми також змогли виміряти температуру датчика під час тесту, оскільки мали під рукою температурний сенсор (1-wire DS18b20 12-bit). Однак ми також кілька разів під час тесту контролювали зовнішню температуру корпусу модуля за допомогою безконтактного інфрачервоного термометра.

Результати

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

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

Обговорення

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

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

Зокрема, ми не робили статистичної перевірки отриманих даних, а лише провели кілька тривалих (до шести годин) експериментів і практично перевірили, чи будуть нормально працювати датчик і мікроконтролер.

Висновки

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

Тепер ви також знаєте, що відбувається, якщо лічильник Гейгера GGreg20_V3 помістити в низькотемпературне середовище.

Сподіваємося, що ця стаття була для вас такою ж цікавою і корисною, як і проведений нами експеримент.

Просимо звернути увагу, що у грудні 2022 та у січні 2023 року вийшло кілька виправлень прошивки ESPHome, які можуть впливати на підрахунок імпульсів від лічильника Гейгера на порту мікроконтролера ESP32.

1) Release 2022.12.3 – December 20 https://www.esphome.io/changelog/2022.12.0.html#release-2022-12-3-december-20

– Fix ESP32 GPIO when using PULLUP or PULLDOWN in INPUT mode #4213:

https://github.com/esphome/esphome/pull/4213/files

2) Release 2022.12.4 – January 20 

https://www.esphome.io/changelog/2022.12.0.html#release-2022-12-4-january-20

– Fix gpio pin mode for ISR pins #4216:

https://github.com/esphome/esphome/pull/4216/files

Через помилкову роботу / налаштування (без вказаних вище виправлень) обробника переривань, користувачі GGreg20_V3 та подібних лічильників Гейгера з імпульсним виходом могли спостерігати помилкові значення рівня радіації. 

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

Зверніть також увагу, що команда IoT-devices, LLC не проводила технічних випробувань з виправленнями та без них і не може точно вказати на характер впливу цих помилок у попередніх версіях прошивки і відповідних виправлень на роботу контролера ESP32 з перериваннями.

Якщо після встановлення оновлень з виправленнями ви помітили зміни у роботі вашого модуля лічильника Гейгера GGreg20_V3, будь-ласка, поділіться з нами та DIY/IoT – спільнотою своїм досвідом.

Найкращі побажання,

Team IoT-devices, LLC