BME280 working with build 1231_merge_5205ac2480d5
Address 0x76 (dec 118)
for me:
P7 - SDA
P8 - SCL
Address 0x76 (dec 118)
for me:
Code: Text
Log in, to see the code
P7 - SDA
P8 - SCL
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
// startDriver BMPI2C 8 14 1 2 3 0
// startDriver BMPI2C [CLK] [DATA] [ChannelForTemp] [ChannelForPressure] [ChannelForHumidity] [Addr]
// Adr8bit 0 for 0x77, 1 for 0x76
BMPI2C_Cycle 60
// startDriver BMPI2C [CLK] [DATA] [ChannelForTemp] [ChannelForPressure] [ChannelForHumidity] [Addr]
//SDO to GND for Adr8bit 236 for 0x76 or set SD to VCC for Adr8bit 238 for 0x77
//set CSB pin to GND for SPI mode and to VCC for I2C mode
// startDriver BMP280 8 14 1 2 3 236
// startDriver BMP280 [CLK] [DATA] [ChannelForTemp] [ChannelForPressure] [ChannelForHumidity] [Adr8bit]
// Adr8bit 236 for 0x76, 238 for 0x77
startDriver BMPI2C 26 24 4 5 6 238
//BMP680_Adr 0x77
startDriver BMP280 8 7 1 2 3 236
//BMP280_Adr 0x76
divadiow wrote:that's cool. so that's your own build with the old driver added?
#define ENABLE_DRIVER_BMPI2C 1
#define ENABLE_I2C 1. #define ENABLE_DRIVER_BL0937 0;
#define ENABLE_DRIVER_BL0942 0,
#define ENABLE_DRIVER_CSE7766 0,
#define ENABLE_DRIVER_WEMO 0,
#define ENABLE_DRIVER_DHT 0
#define ENABLE_DRIVER_CHT83XX 0
#define ENABLE_DRIVER_DS1820 0
#elif PLATFORM_BL602
// I have enabled drivers on BL602
#define ENABLE_TASMOTADEVICEGROUPS 1
#define ENABLE_LITTLEFS 1
#define ENABLE_NTP 1
//#define ENABLE_NTP_DST 1
#define ENABLE_CALENDAR_EVENTS 1
#define ENABLE_DRIVER_LED 1
#define ENABLE_DRIVER_BL0937 1
#define ENABLE_DRIVER_BL0942 1
#define ENABLE_DRIVER_CSE7766 1
//#define ENABLE_DRIVER_WEMO 1
#define ENABLE_DRIVER_FREEZE 0
//#define ENABLE_DRIVER_DHT 1
// parse things like $CH1 or $hour etc
#define ENABLE_EXPAND_CONSTANT 1
#define ENABLE_TASMOTA_JSON 1
#define ENABLE_DRIVER_DDP 1
#define ENABLE_DRIVER_SSDP 1
//#define ENABLE_DRIVER_CHT83XX 1
//#define ENABLE_DRIVER_DS1820 1
#define OBK_OTA_EXTENSION ".bin.xz.ota"/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/build_out/shared/libshared.a(drv_main.o): in function `.LANCHOR0':
drv_main.c:(.data.g_drivers 0x24): undefined reference to `DRV_I2C_Init'
/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/toolchain/riscv/Linux/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: drv_main.c:(.data.g_drivers 0x28): undefined reference to `DRV_I2C_EverySecond'
/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/toolchain/riscv/Linux/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: drv_main.c:(.data.g_drivers 0x34): undefined reference to `DRV_I2C_Shutdown'
/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/toolchain/riscv/Linux/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/build_out/shared/libshared.a(new_pins.o): in function `Channel_OnChanged':
/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/bl602_sharedApp/shared/src/new_pins.c:1060: undefined reference to `I2C_OnChannelChanged'
make[1]: *** [/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/../../make_scripts_riscv/project.mk:448: /home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp/build_out/bl602_sharedApp.elf] Error 1
make[1]: Leaving directory '/home/runner/work/OpenBK7231T_App/OpenBK7231T_App/sdk/OpenBL602/customer_app/bl602_sharedApp'
make: *** [Makefile:177: OpenBL602] Error 2
Error: Process completed with exit code 2.TL;DR: With 1 sensor per WB2S and a simple command, OpenBK can read BME280 data over software I2C; one contributor confirmed, "all working fine" with
BMPI2C_Cycle 60, which also stops 1-second MQTT flooding. This FAQ helps OpenBK users connect BME280/BMP280/BME680-class sensors and publish stable readings to Home Assistant or OpenHAB. [#21510838]
Why it matters: This thread shows the practical path from a first BME280 question to working OpenBK drivers, Home Assistant publishing, BL602 builds, and configurable reporting intervals.
| Driver | Sensors discussed | Humidity support | Address handling | Reporting interval |
|---|---|---|---|---|
| BMP280 | BMP280, partial BME280 use | No native BME humidity at first | Later extended | Originally every 1 s |
| BMPI2C | BME280, BMP280, BME680-class testing | Yes, via humidity channel | Explicit address parameter | BMPI2C_Cycle 60 supported |
Key insight: Use the older BMP280 driver only for basic temperature and pressure tests. For real deployments, BMPI2C is the better OpenBK path because it adds humidity-channel support and a configurable measurement cycle.
0x60, while BMP280 reports 0x58; confusing those values causes the classic "wrong ID" error. [#20862072]0x76 or 0x77, selected by switch or ADDR wiring on the board. [#20861920]startDriver BMPI2C [CLK] [DATA] [TempCh] [PressureCh] [HumidityCh] [Addr], where 0 means 0x77 and 1 means 0x76 in the newer syntax. [#21123022]0x76 or 0x77. 3. Run startDriver BMP280 24 11 1 2 for temp and pressure, or use BMPI2C if you also want humidity. The thread confirms one BME280 worked immediately after pin selection and driver start on WB2S-class hardware. [#20862072]CLK and DATA are the software I2C pins, while ChannelForTemp and ChannelForPressure are numeric OpenBK channels, such as 1 and 2. Pick GPIOs that are free on your board, then map the channels to channel types like Temp_div100 or Pressure_div100. One working example from the thread is startDriver BMP280 8 14 1 2. [#20862067]0x60 instead of the BMP280 0x58. [#21011686]0x60 is the BME280 chip ID, 0x58 is the BMP280 chip ID, and 0x76 or 0x77 are selectable I2C addresses. They get mixed up because both numbers appear during setup, but they solve different problems. One user explicitly realized the difference after trying to treat 0x77 as a chip ID value. [#21072813]publishFloat myTemp $CH1*0.01 and publishFloat myPress $CH2*0.1. You can also trigger updates on change with addEventHandler OnChannelChange 1 publishFloat myTemp $CH1*0.01. One user said the target platform was Home Assistant over MQTT, and the developer confirmed both discovery-based and script-based publishing paths. [#20862313]0.01 and pressure by the correct divider for the channel type you use. The thread shows raw values like T 2391 and P 100185, which correspond to about 23.91 °C and 1001.85 hPa after scaling. In OpenBK, Temp_div100 is the expected choice for temperature, and pressure needed its own corrected handling during development. One fix changed the web display from g_pressure*0.1f to g_pressure*0.01f for hectopascals. [#20865733]2660 over MQTT instead of 26.60, even though the web page displayed scaled values correctly. The developer answered that a divider flag solves that mismatch because OpenBK still follows the TuyaMCU-style integer storage model. Turn that flag on if you want MQTT payloads to honor the selected divider. [#21013349][ChannelForHumidity] and [Addr], plus BMPI2C_Cycle 60. [#21123022]1 second, which multiple users called noisy or flooding for MQTT. The newer solution is BMPI2C_Cycle 60, which triggers the driver every 60 seconds instead. That change directly addresses the thread's repeated complaint about one-second updates on Home Assistant or OpenHAB. [#21123022]BMPI2C_Cycle 60 tells the BMPI2C driver to read and report every 60 seconds. For room temperature, pressure, and humidity, 60 seconds is a practical starting point because ambient conditions rarely need 1-second updates. One user wanted 5 minutes to reduce MQTT noise, while another confirmed 60 seconds worked fine in practice. Set the interval to match your dashboard and automation needs, not the fastest possible sensor rate. [#21510838]obk_config.h and compile a custom binary. The developer explicitly said the BMP280 driver may be disabled because the project is slowly running out of flash memory. For the older driver, add #define ENABLE_DRIVER_BMP280 1. For newer builds, enable the newer BMPI2C path instead if that is the driver you need. [#20945538]obk_config.h, then build without assuming generic I2C is required. The key trap is enabling ENABLE_I2C 1, which caused undefined references such as DRV_I2C_Init, DRV_I2C_EverySecond, and I2C_OnChannelChanged until it was fixed. The developer later clarified that ENABLE_I2C is not needed for this standalone BME/BMP driver on BL602. That makes the cleanest BL602 path: enable the sensor driver, skip generic I2C, and compile again. [#21370874].bin and .ota.bin files were rejected as "Invalid OTA file was selected." They then compressed the OTA file to xz, renamed it to OpenBL602_OTA.bin.xz.ota, and got the file into the expected size range near 400 kB instead of about 700 kB. Later, the same user confirmed OTA worked with their BL602 custom builds. [#21371661]