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

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