🛠 Capteurs Grove sur le bus I2C 1 et inventaire du bus

Objectives

Use the BeaglePlay Grove connectors on the I2C side: the Grove connector is connected to I2C bus 1. We enable the bus, list the occupied addresses with i2cdetect, then read a Grove sensor (for example BME680 at 0x77 or BME280 at 0x76) using raw register reads, without relying on a manufacturer library.

Hardware

• A BeaglePlay board
• One or more Grove I2C sensors (BME680, SHT3x, OLED 0x3C...)
• 4-wire Grove male/female cable

Complete code

# Vérifier que le bus 1 (Grove) est actif
i2cdetect -l
sudo i2cdetect -y -r 1        # grille des adresses 0x08-0x77

# Lecture brute d'un registre (exemple : ID BME680 attendue 0x61)
sudo i2cget -f -y 1 0x77 0xD0

# Script d'inventaire automatique
for a in $(seq 8 119); do
  if sudo i2cget -f -y 1 $a 0x00 >/dev/null 2>&1; then
    printf "présent : 0x%02x\n" $a
  fi
done

# lecture SMBus simple (pip install smbus2)
import smbus2
bus = smbus2.SMBus(1)
print(hex(bus.read_byte_data(0x77, 0xD0)))

Expected verification

i2cdetect -l lists at least bus 1 (Grove) and bus 5 (Qwiic). With a sensor connected, i2cdetect -y -r 1 displays its address (e.g., 77); the inventory script retrieves it. i2cget on the identification register returns the value expected by the datasheet (0x61 for BME680, 0x60 for BME280).

Common errors

• Confusing the Grove bus (1) and the Qwiic bus (5): a sensor invisible on one is often on the other.
• Forgetting -f on i2cget when the kernel already has a driver attached to the address.
• Two identical Grove modules in parallel: same fixed address, the second never appears; choose an addressable variant.
• Interpreting a UU in the grid as a failure: it simply means a kernel driver already occupies the device.
• Wiring a Grove module in SPI/UART on the I2C connector: the bus will see nothing, check the cable pinout.