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

Компонент 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 запрошує спільноту до тестування, надання зворотного зв’язку та внесків у розвиток компонента.

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

Для проведення вимірювань ми розробили спеціальний тестовий стенд на базі платформи 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

Та найголовніша його перевага у тому, що він працює через 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

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

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

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

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

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

Як можна бачити, підключення емулятора дуже просте: кабель живлення micro USB та сигнальні дроти імпульсного виходу, а також за бажанням можна підключити debug-консоль через UART.

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

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

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

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

Відомі обмеження

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

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

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

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

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

Сайт IoT-devices.com.ua: GCcemu20_V1

tindie.com: GCcemu20_V1

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

Початок статті:

Емулятор лічильника Гейгера GGreg20_V3 засобами ESP8266: Частина 1. Вступ та загальний огляд

Емулятор лічильника Гейгера GGreg20_V3 засобами ESP8266: Частина 2 Створення емулятора

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

Команда IoT-devices LLC

Для побудови емулятора лічильника Гейгера нам знадобляться наступні деталі та матеріали:

• ESP8266 #1 як основний (MCU_A, модуль NodeMCU);
• ESP8266 #2 як емулятор GGreg20_V3 (MCU_B, модуль ESP12.OLED);
• Дроти для перемичок;
• USB кабель для програмування та живлення.

Далі нам потрібно буде запрограмувати основний контролер MCU_A та код скрипту емуляції програмного забезпечення GGreg20_V3 для MCU_B.

Примітка 3. Ми будемо наводити приклади у цій публікації на модулях власного виробництва ESP12.OLED. Втім, якщо у вас немає модуля ESP12.OLED, ви також можете застосувати плату розробника на базі ESP8266, наприклад NodeMCU, і самостійно розробити програмне забезпечення керуючись прикладами, що наведено у тексті. Якщо ж ви бажаєте одразу користуватися готовим пристроєм, будь-ласка, дочитайте цю статтю до кінця, адже далі ми даємо посилання на наш готовий до використання модуль емулятора, який можливо придбати.

Примітка 4. У цій, як і у інших наших публікаціях ми будемо наводити приклади простою та потужною скриптовою мовою програмування Lua, що доступна у популярній програмній прошивці NodeMCU.

Бюджет необхідних нам входів/виходів

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

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

Схема підключення

Щоб взаємодія головного контролера з емулятором модуля GGreg20_V3 виглядала реалістично, пропонуємо скористатися вбудованими властивостями певних портів вводу/виводу плати ESP12.OLED і обрати на контролері емулятора MCU_B наступні GPIO:

• для емуляції імпульсного виходу GGreg20_V3 рекомендуємо використовувати GPIO4 / D2 (GPIO D-index в Lua);
• для перемикання режимів роботи емулятора ми можемо використати вбудовану на платі ESP12.OLED кнопку Flash – GPIO0 / D3;
• вбудований RGB-світлодіод на модулі ESP12.OLED займає GPIO14 / D5; GPIO12 / D6; GPIO13 / D7.

На модулі головного контролера MCU_A, пропонуємо обрати наступний порт для лічильника вхідних імпульсів:

• GPIO14 / D5.

Примітка 5. У якості довідкового матеріалу за нумерацією портів рекомендуємо наступні матеріали:

Стандарт планування та застосування пінів, розроблений alterstrategy.lab: ttps://alterstrategy.com/recommended-pin-use-standard/

Документація на прошивку NodeMCU: https://nodemcu.readthedocs.io/en/latest/modules/gpio/

Документація на модуль ESP12.OLED на сайті: https://iot-devices.com.ua/en/product/esp12oled-universal-esp8266-mcuboard-oled-en/

та на Tindie: https://www.tindie.com/products/iotdev/esp12oled-universal-esp8266096oled-mcu-board/

Оновимо таблицю з урахуванням конкретних портів вводу/виводу, які ми обрали:



Режими роботи емулятора

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

Натискаючи кнопку Flash (D3), користувач може поперемінно перемикати режими, щоб вибрати необхідний.

Для зручності користування емулятором RGB-світлодіод модуля ESP12.OLED блимає різними кольорами, які легко розрізняються людським оком. За кожним режимом роботи емулятора закріплено свій колір. Тож коли емулятор видає на імпульсний вихід сигнал про вдаване “спрацювання”, світлодіод також буде блимати кольором поточного режиму роботи.

Діапазони рівня радіації

Пропонуємо реалізувати емуляцію наступних діапазонів радіаційного випромінювання оточуючого середовища, яке буде імітувати MCU_B:

Режим 0. Немає імпульсів (імітація помилки сенсора);

Режим 1. Природне фонове випромінювання: 0.1 – 0.2 мкЗв/год;

Режим 2. Припустимий рівень: 0.2 – 0.3 мкЗв/год;

Режим 3. Підвищений рівень: 0.3 – 0.6 мкЗв/год;

Режим 4. Небезпечний рівень: 0.6 мкЗв/год – 1.5 мкЗв/год.

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

Реальний модуль GGreg20_V3 оснащено трубкою Гейгера радянського виробництва СБМ-20. Ця трубка має наступний коефіцієнт перерахунку імпульсів на хвилину у мікрозіверти на годину:

мкЗв на годину = CPM * 0.0057

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

CPM = мкЗв на годину / 0.0057

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

Режим 0. 0 CPM;

Режим 1. від 18 CPM до 35 CPM;

Режим 2. від 36 CPM до 52 CPM;

Режим 3. від 53 CPM до 105 CPM;

Режим 4. від 106 CPM до 264 CPM.

Співвіднесення кольору спалахів RGB-світлодіода певному режиму роботи є наступним:

Тепер нам лишається написати відповідний програмний Lua-код для ролі MCU_A та для ролі MCU_B.

Приклад. Код лічильника Гейгера для головного контролера (роль MCU_A)

Ми візьмемо цей код з GitHub за наступною адресою:

https://github.com/iotdevicesdev/ggreg20-v3-nodemcu-lua-example

Код з GitHub повністю готовий до застосування. Щоб запускати код з GitHub, треба його скачати з інтернет і завантажити у контролер, наприклад у модуль NodeMCU, як у нашому випадку. Також необхідно написати ще один Lua-скрипт і його теж завантажити у контролер:

-- filename: mcu_a.lua
-- MCU_A Lua code example
-- Copyright 2022 IoT-devices LLC, Kyiv, Ukraine
dofile('ggreg20_v3_nodemcu_firmware_lua_example.lua')
init(5, 1, 60000)

function snsrUpd()
ma5_rad_lvl, cpm, minutes = read()
print(ma5_rad_lvl, cpm, minutes)
end

snsrUpd_tmr = tmr.create()
snsrUpd_tmr:register(60000, tmr.ALARM_AUTO, function() snsrUpd() end)
snsrUpd_tmr:start()

Приклад. Код для емулятора модуля GGreg20_V3 (роль MCU_B)

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

local gpio = gpio
local mode = gpio.mode
local trig = gpio.trig
local write = gpio.write
local read = gpio.read
local INT = gpio.INT
local OUTPUT = gpio.OUTPUT
local FLOAT = gpio.FLOAT
local HIGH = gpio.HIGH
local LOW = gpio.LOW
local PULLUP = gpio.PULLUP
local print = print

local tmr = tmr
local create = tmr.create
local now = tmr.now
local delay = tmr.delay
local alarm = tmr.alarm
local ALARM_SINGLE = tmr.ALARM_SINGLE
local ALARM_SEMI = tmr.ALARM_SEMI
local ALARM_AUTO = tmr.ALARM_AUTO
local register = tmr.register
local start = tmr.start
local stop = tmr.stop

local node = node
local heap = node.heap
local random = node.random

Також нам необхідно налаштувати GPIO, які у нас будуть відповідати за свої функції (див. вище):

mode(3,INT,FLOAT)
mode(4,OUTPUT, PULLUP)
write(4, HIGH)

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

local function pulseOut()
	write(4, LOW)
	delay(10)
	write(4, HIGH)
end

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

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

Для цього нам знадобиться скористатися генератором випадкових чисел, який відповідно до документації на прошивку NodeMCU здатен генерувати справжні випадкові числа. У прошивці для цього ми маємо готовий метод node.random().

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

create():alarm(timer timeout, timer type, callback function)

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

Тож функція, яка у циклі створює випадкові таймаути запуску pulseOut(), має наступний вигляд:

local t_start = 0
local count = 0
local function randGen(pulses)
	for i = 1, pulses do -- pulses
			create():alarm(random(60000), ALARM_SINGLE, 
				function()
						print(heap(), count, i, (now() - t_start)/1000000)
						pulseOut()
				end
			)
	end
end

Працюючи у парі, розроблені нами функції randGen(pulses) та pulseOut() створюють необхідну нам кількість абсолютно випадкових імпульсів на виході ESP8266 тривалістю 10 мікросекунд кожен в межах однієї хвилини.

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

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

radMode = 1
rand_tmr = create()
rand_tmr:register(1000, ALARM_AUTO, 
	function()
		if radMode == 0 and running == 0 then 
			print(heap(), 'Mode0:Snsr Err emu')
			return 0
		end
		local num = 0
		if radMode == 1 then 
			num = random(math.ceil(18),math.ceil(35))
		elseif radMode == 2 then
			num = random(math.ceil(36),math.ceil(52))
		elseif radMode == 3 then
			num = random(math.ceil(53),math.ceil(105))
		elseif radMode == 4 then
			num = random(math.ceil(106),math.ceil(264))
		end
		if num ~= 0 then print('count:',count + 1,'mode:',radMode, 'num:',num); randGen(num) end
	end
)

rand_tmr:start()

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

Останнє, що нам необхідно передбачити у емуляторі, це перемикання режиму потужності радіації за допомогою вбудованої кнопки Flash / GPIO0 / D3:

trig(3, 'down', 
	function(lvl, ts, cnt)
		if radMode < 4 then radMode = radMode + 1 else radMode = 0 end
		print ('New radMode:', radMode)
	end
)

Повний програмний код емулятора

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

Примітка 6. Наведений у даному розділі код є лише прикладом. Ви можете самостійно завантажити і налагодити роботу даного прикладу у власному емуляторі лічильника Гейгера, або придбати готовий до використання апаратний модуль з прошивкою та повнофункціональним програмним забезпеченням у нашому магазині чи на Tindie за наступними посиланнями:

Сайт: GCcemu20_V1

Tindie: GCcemu20_V1

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

-- filename: mcu_b.lua
-- MCU_B Lua code example
-- Copyright 2022 IoT-devices LLC, Kyiv, Ukraine
local t_start = 0
local count = 0
radMode = 0

local gpio = gpio
local mode = gpio.mode
local trig = gpio.trig
local write = gpio.write
local read = gpio.read
local INT = gpio.INT
local OUTPUT = gpio.OUTPUT
local FLOAT = gpio.FLOAT
local HIGH = gpio.HIGH
local LOW = gpio.LOW
local PULLUP = gpio.PULLUP
local print = print

local tmr = tmr
local create = tmr.create
local now = tmr.now
local delay = tmr.delay
local alarm = tmr.alarm
local ALARM_SINGLE = tmr.ALARM_SINGLE
local ALARM_SEMI = tmr.ALARM_SEMI
local ALARM_AUTO = tmr.ALARM_AUTO
local register = tmr.register
local start = tmr.start
local stop = tmr.stop

local node = node
local heap = node.heap
local random = node.random

mode(3,INT,FLOAT)
mode(4,OUTPUT, PULLUP)
write(4, HIGH)

local function pulseOut()
	write(4, LOW)
	delay(10)
	write(4, HIGH)
end

local function randGen(pulses)
	for i = 1, pulses do -- pulses
			create():alarm(random(60000), ALARM_SINGLE, 
				function()
						print(heap(), count, i, (now() - t_start)/1000000)
						pulseOut()
				end
			)
	end
end

rand_tmr = create()
rand_tmr:register(1000, ALARM_AUTO, 
	function()
		if radMode == 0 and running == 0 then 
			print(heap(), 'Mode0:Snsr Err emu')
			return 0
		end
		local num = 0
		if radMode == 1 then 
			num = random(math.ceil(18),math.ceil(35))
		elseif radMode == 2 then
			num = random(math.ceil(36),math.ceil(52))
		elseif radMode == 3 then
			num = random(math.ceil(53),math.ceil(105))
		elseif radMode == 4 then
			num = random(math.ceil(106),math.ceil(264))
		end
		if num ~= 0 then print('count:',count + 1,'mode:',radMode, 'num:',num); randGen(num) end
	end
)

rand_tmr:start()

trig(3, 'down', 
	function(lvl, ts, cnt)
		if radMode < 4 then radMode = radMode + 1 else radMode = 0 end
		print ('New radMode:', radMode)
	end
)

Початок статті: Емулятор модуля лічильника Гейгера GGreg20_V3 засобами ESP8266: Частина 1. Вступ та загальний огляд

Завершення статті за кілька днів у наступній публікації:
Емулятор модуля лічильника Гейгера GGreg20_V3 засобами ESP8266: Частина 3. Тестування та висновок

Оновлено: Під час написання цієї статті, ми подумали і вирішили зробити окремий комерційний продукт – емулятор лічильника Гейгера GCemu20_V1.

Частина 1: Вступ та загальний огляд

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

https://web.archive.org/web/20170321162556/http://esp8266-re.foogod.com/wiki/Random_Number_Generator

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

Прошивка NodeMCU – це компільована мікропрограма з відкритим вихідним кодом, яка може записуватися на апаратні модулі з контролером ESP8266 компанії Espressif. Одним з величезної кількості продуктів на базі контролера ESP8266, є апаратний модуль NodeMCU.

Тож програмну прошивку NodeMCU можливо записати на апаратний модуль NodeMCU. У тексті цієї статті ми намагаємося, де це можливо, вказувати, що саме мається на увазі поруч з назвою NodeMCU: модуль чи прошивка.

Для чого потрібен емулятор лічильника Гейгера

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

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

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

1. Немає високої напруги

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

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

2. Спрощений навчальний процес

Емулятор лічильника Гейгера добре лягає у набір для навчальних закладів. Викладач може поступово поглиблювати практичні заняття з студентами.

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

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

3. Нижча вартість

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

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

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

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

4. Справжнє джерело радіації не потрібне

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

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

З емулятором жодної з цих проблем не буде. Прилад вміє імітувати 5 різних режимів потужності іонізуючого випромінювання. Емулятор лічильника Гейгера створює вихідні імпульси аналогічні імпульсам справжнього модуля GGreg20_V3 у діапазоні від 0 до 1.5 мкЗв/год (якщо брати за аналогічний еталон трубку СБМ-20). На виході генеруються хаотичні (із застосуванням генератора справжніх випадкових чисел ESP8266) імпульси однакової амплітуди з тривалістю повного періоду імпульсу 10 мікросекунд кожен.

5. Ресурс емулятора не виснажується

Трубка СБМ-20, яку встановлено у GGreg20_V3, має відносно великий, але все ж таки обмежений ресурс частинок, які вона може детектувати за своє життя.

Заявлений у документації ресурс трубки СБМ-20 складає не менше 2*10¹⁰ імпульсів.

Примітка 1. За фонового випромінювання 0.15 мкЗв/год з коефіцієнтом 0.0057 трубка СБМ-20 детектувати близько 27 імпульсів на хвилину.

Таким чином, за нормальних умов ресурсу трубки вистачить на 2*10¹⁰ / (27 * 60 * 24) = 20 000 000 000 / (26 * 60 * 24) = 514403 днів. І здавалося б, що це цілком достатній потенційний строк експлуатації однієї трубки.

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

Наведемо приклад:

На своєму сайті компанія Images Scientific Instruments наводить перелік дозволених до ввозу граничних рівнів радіоактивного випромінювання для тестових джерел:

https://www.imagesco.com/geiger/radioactive-sources-int.html

Візьмемо два джерела з наведеного за посиланням переліку:

1. Co-60 1.00 uCi, 37000 Bq;
2. Cs-137 0.25 uCi, 9250 Bq;

Якщо припустити, що під впливом такого тестового джерела половина частинок від радіоактивних розпадів потрапляють у трубку Гейгера СБМ-20, то ресурс такої трубки складе:

1. 20 000 000 000 / (37000 / 2 * 60 * 60 * 24) = 12 днів (для Co-60);
2. 20 000 000 000 / (9250 / 2 * 60 * 60 * 24) = 50 днів (для Cs-137).

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

З емулятором такої проблеми немає. Застосовувати спочатку емулятор замість трубки економічно доцільно.

6. Дані налагодження в UART

Емулятор модуля GGreg20_V3 у процесі своєї роботи виводить у порт UART-консолі оперативні дані своєї роботи (імпульси, час, кількість, цикли і т.п.), які за необхідності може реєструвати і обробляти студент, розробник чи радіоаматор щоб навчатися, або порівнювати з вимірами своєї системи, яка тестується чи розробляється.

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

Примітка 2. Для підключення до UART-консолі, модуль ESP12.OLED, на якому базується емулятор GGreg20_V3, має на друкованій платі окремо виведені лінії інтерфейсу UART (отвори з кроком 2.54 мм під пайку). Для підключення емулятора до комп’ютера користувачеві додатково потрібно мати власний перетворювач USB-UART. Далі у тексті буде наведено схему підключення.

Продовження статті у наступних публікаціях:
Емулятор модуля лічильника Гейгера GGreg20_V3 засобами ESP8266 Частина 2 Створення емулятора
Емулятор модуля лічильника Гейгера GGreg20_V3 засобами ESP8266 Частина 3: Тестування та висновок

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

Емулятор лічильника Гейгера з імпульсним виходом GCemu20_V1 – це не тільки чудовий інструмент для радіоаматорів та ентузіастів “зроби сам”, але й ідеальний пристрій для тих, хто займається розробкою, налаштуванням, тестуванням і вивченням детекторів радіації.

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

“Ми раді представити наш останній продукт, емулятор лічильника Гейгера GCemu20_V1, на ринку B2C”, – сказав представник компанії. “Цей пристрій розроблений спеціально для радіоаматорів та ентузіастів “зроби сам”, яким потрібно імітувати рівні радіації в своїх проектах, і ми впевнені, що він задовольнить їхні унікальні потреби”.

Емулятор лічильника Гейгера з імпульсним виходом GCemu20_V1 вже доступний для придбання:

Для отримання додаткової інформації, будь ласка, відвідайте сайт IoT-devices, LLC.

Про компанію IoT-devices, LLC

IoT-devices, LLC – провідний постачальник інноваційних рішень у сфері Інтернету речей. Компанія базується в Києві, Україна, і пропонує широкий спектр продуктів, покликаних допомогти своїм клієнтам покращити знання про Інтернет речей та досвід у сфері “зроби сам” і досягти поставлених цілей.

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

• подвійного призначення: стокова і кастомна прошивка можлива;
• без жорсткого прив’язування до IoT-devices LLC, як виробника;
• проста конфігурація і швидкий старт користування;
• підключення опціональних сенсорів на кшталт Plug & Play;
• ретрансляція даних вузлами на кшталт meshed networks;
• connectionless and serverless архітектура;
• сумісність компонентів з ESPHome;
• та відтак, підтримка у Home Assistant.

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

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

Другу частину опису дивіться за посиланням: Підключення сенсора радіації GGreg20_V3 до сервера Home Assistant через інтеграцію ESP Home – частина 2

Примітка. Дана публікація підходить для всіх версій детектора іонізуючої радіації виробництва IoT-devices: GGreg20_V1, GGreg20_V2, GGreg20_V3. 
Оскільки вся лінійка даних детекторів орієнтована на трубку СБМ-20, усі версії пристроїв мають однаковий алгоритм та коефіцієнти розрахунку рівня потужності та дози іонізуючого випромінювання.
На точність вимірювання впливають лише індивідуальні властивості встановленої в кожен конкретний детектор GGreg20_V3 трубки СБМ-20. У технічних характеристиках виробника трубок вказано граничний діапазон точності вимірювань у 20%. На практиці це означає, що два однакові пристрої GGreg20, але з різними трубками СБМ-20, можуть давати результати (не білше ніж) із зазначеним відхиленням за кількістю імпульсів.

Кроки з підключення GGreg20 до Home Assistant – продовження.

Крок 8. Перевірити журнал нового контролера ESP8266 з підключеним Ggreg20
Крок 9. Перевірити, чи утворилися нові сутності на боці сервера
Крок 10. Додати на Дашборд віджети сенсора радіації Ggreg20
Крок 11. Додати скрипт автоматизації Push-нотифікації у додаток Home Assistant про перетин порогів

Сутності та показники пристрою на сервері

Крок 8. Перевірити журнал нового контролера ESP8266 з підключеним GGreg20

Наводимо приклад консолі діючого пристрою з GGreg20 та yaml-налаштуваннями аналогічними тим, що ми розробили вище.

Рис. Вивід у консоль журналу (Logs) пристрою через інтерфейс ESP Home

Крок 9. Перевірити, чи утворилися нові сутності на боці сервера

Щоб перевірити, чи утворилися відповідні сутності GGreg20 в плагіні ESP Home і чи бачить їх сервер Home Assistant, є два шляхи:

• перейти в меню Інструменти для розробників на бічній панелі інтерфейсу Home Assistant та пошукати відповідні дані так, як показано на Рис.

Рис. Пошук потрібних сутностей через меню Інструменти для розробників

• або перейти у меню Конфігурація -> Інтеграція та пошукати як показано на на наступних рисунках

Рис. Пошук потрібних сутностей через меню Конфігурація -> Інтеграція

Рис. Пошук потрібних сутностей через меню Конфігурація -> Інтеграція : Пристрої / Сутності

Візуалізація та Автоматизація

Крок 10. Додати на Дашборд віджети сенсора радіації GGreg20

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

Рис. Дашборд демонструє віджети з даними про рівень радіації з двох сенсорів GGreg20_V1 і GGreg20_V3 що розташовано за різними вісями координат.

Крок 11. Додати скрипт автоматизації Push-нотифікації у додаток Home Assistant про перетин порогів

Після того, як ми пересвідчилися, що новий пристрій працює і надсилає надійні дані, можливо перейти до головної задачі – Автоматизацій. Цей потужний інструмент доступний адміністраторові через меню Конфігурація -> Автоматизації.

Оскільки сутності, зі значенням потужності та дози іонізуючої радіації, створені нами засобами ESP Home, доступні наскрізно для всіх компонентів та функцій Home Assistant, адміністратор може створювати будь-які події, функції, сценарії з їх застосуванням.

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

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

Висновки

У першій та другій частинах ми розглянули кроки

Сервер
Крок 1. Встановити (або запустити) сервер Home Assistant

Плагін ESP Home для Home Assistant
Крок 2. Підключити розширення ESP Home для сервера Home Assistant через меню Supervisor -> Add-on Store

YAML-конфіг нового пристрою ESP з GGreg
Крок 3. Скачати готовий приклад пакетного yaml-файлу конфігурації пристрою GGreg20_V3 для ESP8266 з нашого сайту
Крок 4. Створити (на базі прикладу) у ESP Home відповідний yaml-файл конфігурації

Апаратне підключення GGreg20_V3 і контролера
Крок 5. Обрати пін GPIO на контролері, який буде реєструвати імпульси від Ggreg20
Крок 6. Підключити до контролера ESP8266 детектор радіації GGreg20_V3 через роз’єм Out до обраного GPIO контролера

Прошивка пристрою ESP з GGreg
Крок 7. Побудувати і записати прошивку для контролера

Далі ми виконали наступні кроки з підключення GGreg20 до Home Assistant:

Крок 8. Перевірити журнал нового контролера ESP8266 з підключеним Ggreg20
Крок 9. Перевірити, чи утворилися нові сутності на боці сервера
Крок 10. Додати на Дашборд віджети сенсора радіації Ggreg20
Крок 11. Додати скрипт автоматизації Push-нотифікації у додаток Home Assistant про перетин порогів

Ми докладно розглянули найпростіший шлях підключення детектора GGreg20 з контролером ESP8266 до сервера Home Assistant з плагіном ESP Home.

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

• Детектор GGreg20_V3 – одразу ж реєструє імпульси і передає їх на ESP8266;
• Плагін ESP Home – надає інтерфейс з побудови прошивок і програмування ESP8266;
• Готовий yaml-файл звільняє нас від самостійного написання директив для сенсора GGreg20;
• Сервер Home Assistant надає нам можливість зручно підключати, адмініструвати та отримувати інформацію з будь-яких наших пристроїв.

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