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

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

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

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

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

Рис. Приклад різноманітних модулів з шиною I2C

Більшість мікроконтролерів (MCU) є мініатюрними пристроями і має дуже обмежений бюджет вільних портів вводу/виводу. Зазвичай на контролерах типу Arduino / ESP8266 / ESP32 / STM32 під шину I2C (навіть якщо їх передбачено дві) у реальності можливо зарезервувати лише один інтерфейс: два порти GPIO під сигнальні канали SDA та SCL.

Причин цьому щонайменше дві.

По-перше, GPIO порти – це коштовний ресурс на головному контролері. Вони задіяні під інші, не менш важливі зовнішні інтерфейси : UART, SPI, Deep Sleep Wakeup, входи під кнопки, виходи під актюатор(и),тощо.

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

Примітка. Також всі ми знаємо, що послідовну шину I2C може бути реалізовано не лише апаратно, з фіксованими портами вводу-виводу MCU, але і програмно, коли сигнальні лінії шини можуть бути призначені на будь-які порти GPIO MCU. Ба більше, програмна реалізація шини дозволяє об’явити декілька програмних шин I2C з різними Bus_ID.

Рис. Апаратна та програмна реалізації шини I2C головного контролера

Але маніфестація кількох програмних шин I2C одночасно в межах одного MCU скорочує кількість вільних виводів під інші задачі. Через це такими можливостями мало коли користуються. Виключенням можуть бути ситуації, коли така техніка дозволяє уникати проблем, які неможливо вирішити у інший спосіб. Наприклад, колізії адресації (два різних пристрої з однаковою 7-біт адресою) та подібні проблеми. Але навіть для таких проблем ефективніше застосувати апаратний мультиплексор шин I2C, ніж кілька програмних шин I2C.

Вирішення задачі

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

На ринку є безліч подібних пристроїв, та ми наведемо приклади на пристрої власного виробництва – I2CHUB_V1, має 6 портів I2C: 3 x JST HX2.54, 3 x Dupont і два виділені порти живлення.

Рис. Модуль поділювача інтерфейсів I2CHUB_V1 як приклад

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

Рис. Приклад підключення специфічних модулів сенсорів з двома роз’ємами I2C

“Вхідний” інтерфейс кожного такого модуля підключається до MCU або попереднього модуля сенсора на шині, а “вихідний” інтерфейс дозволяє каскадом підключити наступний модуль. Деякі виробники передбачають по два інтерфейси шини I2C саме з цією метою. Але, нажаль, більшість модулів не оснащено такими можливостями. Тому розглядаємо I2C HUB як більш поширений і універсальний підхід. Нижче наводимо основні схеми підключення модулів із застосуванням поділювача / хаба.

Примітка. Коли зростає кількість з’єднань, степеневим чином зростає:
– кількість точок відмови (PoF, Point of Failure);
– ризик людської помилки під час виконання з’єднань сигналів інтерфейсу.

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

• якомога частіше застосовувати роз’єми з ключем;
• застосовувати модулі з взаємно сумісними електричними інтерфейсами та фізичними роз’ємами.

Не дивлячись на те, що ми рекомендуємо застосовувати за можливості роз’єми з ключем, ми намагаємося рахуватися з реаліями ринку електронних компонентів та враховувати потреби споживачів. І тому ми наділили поділювач I2CHUB_V1 можливістю виступати у якості конвертора типу роз’ємів з JST на Dupont і навпаки – з Dupont на JST.

Вважаємо це дуже корисною функцією, адже завдяки можливості вільно розвертати інтерфейсні кабелі JST – Dupont відповідним боком користувач може підключити до хаба практично будь-який існуючий на ринку модуль з інтерфейсом I2C. Також користувач може вільно використовувати власні штирьові кабелі Dupont – Dupont.
Для опції “Замовлення з кабелями” в модулі I2CHUB_V1 роз’єми завжди встановлюються за однаковою схемою: половина роз’ємів – 2.54 мм JST (з ключем), інша половина – штирьові роз’єми Dupont. Це робиться саме для забезпечення згаданої вище гнучкості взаємного підключення різноманітних I2C-модулів.

Схеми модульного підключення до поділювача інтерфейсів

Зірка

Найпоширеніша схема, коли всі модулі інтерфейсами I2C підключаються у поділювач. Назвемо її “Зірка”.

Рис. Приклад підключення типу “Зірка”

Каскадування

Наступна топологія є каскадом двох і більше “Зірок”. Назвемо її “Каскадування”.

Рис. Приклад підключення типу “Каскадування”

Оскільки один з портів поділювача інтерфейсів завжди задіяно як “вхід”, то в деяких ситуаціях може виникнути нестача вільних портів поділювача. Саме в цьому випадку застосовується каскадування поділювачів у необхідній кількості таким чином, щоб забезпечити бажану кількість інтерфейсних портів на шині I2C.

Наприклад, I2CHUB_V1 виробництва IoT-devices має 6 портів I2C. Якщо в проекті, за задумом, необхідно підключати до MCU більше 5 підпорядкованих пристроїв, то можливо застосувати каскадування двох поділювачів і розподілити між їх інтерфейсами відповідні підпорядковані пристрої.

Довга лінія

Остання можлива схема впровадження, яку варто навести у даній публікації – це топологія з довгою лінією передачі даних і двома віддаленими, незалежними джерелами живлення. Назвемо її “Довга лінія”.

Рис. Приклад підключення типу “Довга лінія”

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

Сумісність поділювачів з іншими системами

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

Втім, оскільки класичний поділювач I2C (такий як I2CHUB_V1) є пристроєм пасивним та не перетворює напруги за рівнем, він автоматично є сумісним з будь-яким контролером, до якого ви вирішили його підключити: Arduino, STM32, ESP8266, ESP32, Raspberry Pi, etc.

Увага! Лише ви вирішуєте, з якими логічними рівнями мають працювати компоненти проекту: 1.8V, 3.3V чи 5V.

Докладні специфікації шини I2C

Для того, щоб ознайомитися докладно з усіма особливостями шини I2C, рекомендуємо читати офіційні настанови та вимоги специфікації за посиланням: https://www.nxp.com/docs/en/user-guide/UM10204.pdf
А також інші ресурси в мережі інтернет.

Ось і все, що ми запланували розповісти у даній публікації. Ми розглянули особливості і можливості підключення підпорядкованих модулів до інтерфейсу шини I2C головного контролера. Показали основні схеми застосування поділювача, такі як “Зірка”, “Каскадування”, “Довга лінія”, з можливістю віддаленого незалежного живлення окремих ланок шини, завдяки наявності у поділювача спеціальних портів “входів” / “виходів” живлення.

Дякуємо за увагу. Ставте запитання у наших соцмережах.
Бажаємо успіхів!