search

trvrnrth / esphome-bsec-bme680

ESPHome component for the Bosch BME680 sensor via BSEC providing temperature, humidity, pressure and indoor air quality measurements.
85 stars 17 forks source link

Using multiple I2C busses and i2c_id with bme680_bsec sensor #33

Closed ChristianWaechter closed 2 years ago

ChristianWaechter commented 3 years ago

Hello,

first of all thank you for your work! Your sensor-implementation works really nice on my side!

But I'm currently struggling to connect multiple BME680 sensors using I2C to one Wemos D1 Mini for testing (later a WT32-ETH01 should be used). I want one (software) I2C bus per BME680 sensor, 4 sensors would be perfect. So tried to write a config for ESPHome, but I'm always getting errors. Currently I'm not sure if the problem is, that the bme680_bsec component does not support multiple i2c_id propertys, or if I'm doing it wrong.

This code at least does not cause any error. But how can I add a second BME680 sensor on an other bus? As soon as I place the i2c_bus-property anywhere else od duplicate the sensor, I get errors....

esphome:
  name: airquality_bme680
  platform: ESP8266
  board: d1_mini

i2c:
  - id: bus_a
    sda: GPIO4
    scl: GPIO5
    scan: True
    frequency: 100kHz
  - id: bus_b # For testing multiple I2C buses
    sda: GPIO0
    scl: GPIO2
    scan: True
    frequency: 100kHz
  - id: bus_c # For testing multiple I2C buses
    sda: GPIO13
    scl: GPIO15
    scan: True
    frequency: 100kHz
  - id: bus_d # For testing multiple I2C buses
    sda: GPIO12
    scl: GPIO14
    scan: True
    frequency: 100kHz

bme680_bsec:
  id: bme680_a
  i2c_id: bus_b
  address: 0x77
  temperature_offset: 0
  iaq_mode: static
  sample_rate: lp
  state_save_interval: 6h

sensor:
  - platform: bme680_bsec
    temperature:
      # Temperature in °C
      name: "BME680 Temperature"
      filters:
        - median

wifi:
  ssid: "myWIFI"
  password: "123"
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Emergency WLAN"
    password: "abc"
captive_portal:
# Enable logging
logger:
# Enable Home Assistant API
api:
  password: "xxx"
ota:
  password: "xxx"

Best regrads, Chris

trvrnrth commented 3 years ago

I'm afraid I removed support for reading from multiple sensors in the latest release due to timing and state management complexities (it was untested in prior releases but worked in theory). With the latest release I focused on optimising performance with a single sensor with that being the expected primary usage scenario.

It should in principle be possible to support multiple sensors with some extra overhead but it isn't something I have any current intention of pursuing. I'd be happy enough to review PRs of course!

Out of interest what is your use case? Could you achieve the desired result running multiple d1 minis?

ChristianWaechter commented 3 years ago

Thank you for your explanation.

I'm aware that one might also use different I2C addresses for each sensors and connect them to one I2C bus. But on the BME680, you can only choose between two addresses, so you need to use two I2B busses for more than 2 sensors.

The "problem" in this case is a mix of different issues/requirements. First of all, I would like to have a centralized management of the sensors, so I do not need to connect to each sensor when changing a parameter. I'm rather new to Home Assistant, but as far as I see, ESPHome is perfect for this. For having it work with ESPHome, I of course need a supported device, which are mainly all ESP32 and ESP8266. But I'm also open to ESPHome alternatives, if there are any.

The D1 Mini is just my testing platform in this case, in the end something with a wired connection has to be used, e.g. the WT32-ETH01. All sensors should then connect to one of this WT32-ETH01. The reason is, that I do not have a wireless connection available on all of the three spots, I would like to install sensors. Of course I could install a wireless accesspoint or a switch on each of the three spots and use multiple ESP-devices, each with one sensor. But as two of these spots are outdoor an potentially wet and dirty, every device needs to be isolated (from water) properly, requires additional configuration and increases the possibility of fault, which I would like to avoid.

But before installing a switch or accesspoint with multiple ESP, I would use a singleboard computer as the NanoPi and use this with MQTT. Of course with the disadvantage, that it might not be configured via ESPHome

trvrnrth commented 3 years ago

I presume you're aware of the limits on i2c cable length? If your sensors are more than a couple of metres from the board you might run into problems so something to bear in mind.

Personally I'd be looking to run mutliple boards. Pushing a few OTA updates instead of just the one has never been a problem for me and ESPHome allows multiple nodes to inherit from the same base config with subsitutions which reduces the number of things to update. I'm of the view that one failed or misbehaving board/sensor is better than having them all become unavailable at once. Presumably you'll have to be making some provision for weather protection for the sensor itself already so perhaps making room for a board too would be possible.

It's a shame there isn't a readily available ESP based board with built in POE support (or at least I couldn't find one when I last went looking) as such a thing sounds like it might suit you nicely.

I'm sorry I can't bring you good news on the software support side of things but perhaps I've given some useful food for thought otherwise.

ChristianWaechter commented 3 years ago

Yes, I'm aware about the I2C cable length. The length will be a maximum of ~2 meters which sould be fine when using shielded CAT7 cables and a slow I2C clock setting.

Actually there are a few POE-powered ESP boards, like the Olimex ESP32-POE, wESP32 and LILYGO TTGO T-Internet-POE ESP32-WROOM.

The main problem with having multiple boards each with one sensor is not, that there might be a increased amount of configuration required. The problem is, that every board needs its own Ethernet connection. This means, a ethernet switch (maybe even with PoE) needs to be installed in a place, where I do not want to install one.

Maybe there will be a update for your files, that support multiple sensors/i2c busses. Until then I might use a other sensor, even though I like the BME680 ;)

EDIT: One other idea: Can multiple BME680 sensors be used with your files when using SPI instead of I2C?

bisbastuner commented 2 years ago

I want to use multiple BME680 devices on a bus (just two in my case).

I added two BME680s in configuration.yaml:

bme680_bsec:
  - id: "bme680_interno"
    name: "bme_interno"
    i2c_id: "i2cbus_bme"
    address: 0x76
    sample_rate: ulp

  - id: "bme680_esterno"
    name: "bme_esterno"
    i2c_id: "i2cbus_bme"
    address: 0x77
    sample_rate: ulp

when compiling, esphome returns

Desktop>esphome compile espino1_test2-bme680.yaml
←[32mINFO Reading configuration espino1_test2-bme680.yaml...←[0m
Failed config

bme680_bsec: [source espino1_test2-bme680.yaml:126]

  expected a dictionary.
  - id: bme680_interno
    name: bme_interno
    i2c_id: i2cbus_bme
    address: 118
    sample_rate: ulp
  - id: bme680_esterno
    name: bme_esterno
    i2c_id: i2cbus_bme
    address: 119
    sample_rate: ulp

I'm a programmer, and I would like to change the bme680_bsec component to accept more than one sensor (and hopefully get it to work, so I can issue a PR for that).

However, I'm really new to ESPHome, and I struggle to find the point where a dictionary is required here.

I looked at the i2c component, since I am able to declare more than one i2c bus, but I don't really see where the difference is, or where an error is spit out for not having a dictionary in the config.

Can you please @trvrnrth point me in the right direction?

trvrnrth commented 2 years ago

You'd need to enable MULTI_CONF on the component to accept an array of configurations. https://github.com/trvrnrth/esphome-bsec-bme680/commit/df37a7635f6acc3f7520f257d2645eda10b863a5 removed support for multiple sensors prior to inclusion in core which may be of some help in pointing you in the right direction if you want to try and get it up and running.

bisbastuner commented 2 years ago

It took a longer time than I'd expected (also because of lack of free time), but I think I got it working.

Tests performed (I own 2 sensors, connected to a single ESP32 with a single I2C bus; they use the 0x76 and 0x77 I2C addresses):

Code is available here: #https://github.com/bisbastuner/esphome/commit/9ec6f761ea2b75a4a8343d5779a6fbab75d05bd8

Can someone test it? @trvrnrth , do you think this is formally correct? Have you any comments about the code?

trvrnrth commented 2 years ago

@bisbastuner I don't have a test setup with multiple sensors to run against but the changes look fairly plausible. I do have a few question/thoughts though if you wanted to open a PR for me to comment on?

trvrnrth commented 2 years ago

@bisbastuner (To be clear I mean a PR to esphome not this repo)

bisbastuner commented 2 years ago

Sure, I forked from esphome so it should be OK.

However, I noted right now that I developed the changes starting from the file I had on my disk, but should have started from the esphome:dev repository. My repo is now behind of the changes that queue publish sensor states. Let me integrate these, test again, and I'll issue a PR. Thank you for your assistance @trvrnrth !

bisbastuner commented 2 years ago

@trvrnrth PR #3350 opened. I already reintroduced the changes I was behind, fixed some unnecessary changes I introduced, adhered to codebase standards, fixed problems found automatically by the check scripts.

Please correct me in anything I've been wrong, as this is my very first pull request!

trvrnrth commented 2 years ago

Thanks to @bisbastuner the work to support this is progressing well over on https://github.com/esphome/esphome/pull/3550 so I'm going to close out this issue in favour of tracking it exclusively within the esphome project.