Rano dokonałem aktualizacji ESPHome do najnowszej wersji, czyli 2024.2.0, po czym rutynowo zacząłem aktualizować kolejne urządzenia. I tak się złożyło, że już na pierwszym urządzeniu napotkałem błąd związany z czujnikiem BME280 (temperatura, ciśnienie i wilgotność powietrza). A że ten czujnik jest przeze mnie wykorzystywany dość często, to problemu nie można było zostawić bez rozwiązania.

Zmiana w konfiguracji (platformy) czujnika BME280 w ESPHome 2024.2.0

Oczywiście przed aktualizacją ESPHome do wersji 2024.2.0 zerknąłem na listę zmian. I oczywiście na tej liście zwróciłem uwagę na 2 wzmianki o czujniku BME280 w kontekście dodania obsługi komunikacji z tym czujnikiem po SPI (wreszcie, bo taka “prośba” pojawiła się w lipcu… 2021). A że korzystam z I2C, i nawet nie wiedziałem, że w ESPHome “w standardzie” po ISP się nie dało, to błędnie uznałem, że mnie to nie dotyczy:

New Components:

BME280 SPI esphome#5538 by @apbodrov (new-integration) (breaking-change)

I to pomimo tego, że informacja o tym, pojawiła się w “breaking change”:

Breaking Changes:

BME280 SPI esphome#5538 by @apbodrov (new-integration) (breaking-change)

Ale jak już wspomniałem – uznałem (błędnie), że to istotna zmiana dla tych, co korzystają z BME280 po SPI. A ja nie korzystam… ;-)

I tak przy próbie kompilacji nowej wersji oprogramowania pojawił się błąd:

Failed config
sensor.bme280: [source /config/esph01.yaml:107]
Platform not found: 'sensor.bme280'.

W tym momencie zrozumiałem, że ta zmiana nie dotyczy tylko tych, co chcą korzystać w ESPHome z czujnika BME280 po SPI, ale wszystkich. W tym mnie:

Breaking change notes: The original bme280 component has been renamed to bme280_i2c for consistency with other platforms. To update your configuration, simply replace bme280 with bme280_i2c.

Na szczęście – jak widać powyżej – naprawa błędu jest prosta, bo wystarczy zmienić identyfikator platformy z “bme280”:

sensor:
  - platform: bme280

na “bme280_i2c”:

sensor:
  - platform: bme280_i2c

I tyle wystarczy. Choć tu mała uwaga: po zmianie (korekcie) edytor nadal może podkreślać cały moduł z wiązany z BME280 na czerwono, ale wystarczy zapisać zmiany, wyjść z edycji kodu i jeszcze raz do niej wejść. A jeśli mimo zmiany dalej jest problem, to szukanie rozwiązania dobrze zacząć od opcji “Clean Build Files”, która znajduje się w menu kontekstowym każdego urządzenia skonfigurowanego w ESPHome.

No dobra, ale po co to ISP, jak I2C lepsze?

O zmianie od razu dałem znać znajomemu, i tu pojawiło się pytanie, po co to SPI, skoro I2C wydaje się sensowniejsze, bo nie tylko wystarczą 2 GPIO (SDA i SCL), to jeszcze na takim I2C można puścić wiele różnych urządzeń, cały czas wykorzystując tylko dwa GPIO.

Jest w tym sporo racji, ale SPI może się przydać, np. gdyby ktoś z jakiegoś powodu np. chciał do jednego urządzenia podpiąć więcej niż 2 czujniki BME280 (albo podobne), bo po I2C w przypadku tego czujnika mamy tylko 2 adresy: 0x76 i 0x77.

W przypadku SPI ogranicza nas właściwie tylko liczba wolnych GPIO, a tych potrzeba – jeśli dobrze kojarzę – 4 (nie licząc zasilania), by podłączyć BME280 po SPI, ale 3 z nich są współdzielone, więc każdy dodatkowy układ, to tylko jedno dodatkowe GPIO. Więc wraz z liczbą czujników, liczba wykorzystywanych kolejnych GPIO rośnie nieznacznie (1:1).

(!) Zgłoś błąd na stronie | Lub postaw nam kawę :-)
LUTy dla D-Cinelike (DJI Mini 3 Pro, DJI Avata, OSMO Pocket) od MiniFly
Wdrożenie Omnibusa w sklepie na WooCommerce
Jak (legalnie) latać dronem w Kategorii Otwartej
Patryk