UnitCO2L fails to initialize when SCD41 feature set version is 0x1441

[glyzinie]

Describe the bug

UnitCO2L fails to initialize with M5UnitUnified when the connected SCD41-compatible UnitCO2L reports feature set version 0x1441.

The device responds on I2C address 0x62, and manual SCD4x commands such as STOP_PERIODIC_MEASUREMENT, GET_SERIAL_NUMBER, and GET_FEATURE_SET_VERSION work correctly.

However, Units.begin() returns false.

A workaround that subclasses UnitCO2L and skips is_valid_chip() allows initialization and measurement to work.

This suggests that the current UnitSCD41::is_valid_chip() check may be too strict and may only accept 0x1440.

To reproduce

1. Connect UnitCO2L to M5AtomS3 via Port.A / Grove.
2. Initialize M5Unified and M5UnitUnified.
3. Use m5::unit::UnitCO2L with Units.add(unit, Wire) and Units.begin().
4. Observe that Units.add() succeeds but Units.begin() fails.
5. Manually read the SCD4x feature set version with command 0x202F.
6. Observe that the sensor reports 0x1441.

Minimal diagnostic result:

Wire.begin done
I2C scan start
I2C found: 0x62
I2C scan end
SCD4x manual probe start
SCD4x cmd 0x3F86 err:0
SCD4x cmd 0x3682 err:0
SCD4x read 0x3682 got:9 expected:9
 word0: 57 DC crc:B1 calc:B1
 word1: 3D 07 crc:E4 calc:E4
 word2: 3B 2E crc:B0 calc:B0
SerialNumber ok:1 57DC-3D07-3B2E
SCD4x cmd 0x202F err:0
SCD4x read 0x202F got:3 expected:3
 word0: 14 41 crc:60 calc:60
Variant ok:1 value:0x1441
SCD4x manual probe end

M5UnitUnified initialization result:

Units.add:1
Units.begin:0
M5UnitUnified: 1 units
 [UnitSCD41]:ID{0X58c5ad0d}:0x3fcedee0:1 ADDR:62 CH:-1 parent:0 children:0/0

Expected behavior

UnitCO2L should initialize successfully when an SCD41-compatible sensor reports feature set version 0x1441.

The library should probably accept SCD41-compatible feature set versions such as 0x1440 and 0x1441, instead of requiring an exact 0x1440 match.

Screenshots

No response

Environment

• OS: macOS
• IDE & IDE Version: Arduino IDE
• Repository Version: M5Unit-ENV current master behavior observed
• Board: M5AtomS3
• Unit: UnitCO2L
• I2C address: 0x62
• I2C clock tested: 100 kHz

Additional context

The I2C bus and physical connection appear to be working correctly because:

• I2C scan detects 0x62
• GET_SERIAL_NUMBER succeeds with valid CRC
• GET_FEATURE_SET_VERSION succeeds with valid CRC
• Measurements work after bypassing the strict chip validation

Workaround:

class UnitCO2LLoose : public m5::unit::UnitCO2L {
public:
    using m5::unit::UnitCO2L::UnitCO2L;

protected:
    bool is_valid_chip() override
    {
        M5.Log.println("UnitCO2LLoose: skip is_valid_chip()");
        return true;
    }
};

With this workaround, initialization succeeds and measurements are available:

Unit component clock:100000
Units.add:1
UnitCO2LLoose: skip is_valid_chip()
Units.begin:1
M5UnitUnified: 1 units
 [UnitSCD41]:ID{0X58c5ad0d}:0x3fcedee0:1 ADDR:62 CH:-1 parent:0 children:0/0

>CO2:898
>Temperature:23.82
>Humidity:43.36

Possible fix:

Instead of checking for an exact {0x14, 0x40} match, accept SCD41-compatible feature set versions by checking the high byte.

bool UnitSCD41::is_valid_chip()
{
    uint8_t var[2]{};

    if (!read_register(GET_SENSOR_VARIANT, var, 2)) {
        M5_LIB_LOGE("Failed to read SCD41 feature set version");
        return false;
    }

    // Accept SCD41-compatible feature set versions such as 0x1440 and 0x1441.
    if (var[0] != 0x14) {
        M5_LIB_LOGE("Not SCD41 %02X:%02X", var[0], var[1]);
        return false;
    }

    return true;
}

Issue checklist

• I searched for previous reports in the issue tracker
• My report contains all necessary details