Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix CO2 value interpretation #8644

Merged
merged 3 commits into from
Jan 19, 2025
Merged

Fix CO2 value interpretation #8644

merged 3 commits into from
Jan 19, 2025

Conversation

Eyenseo
Copy link
Contributor

@Eyenseo Eyenseo commented Jan 19, 2025

The zigbee standard specifies that the values of section 4.13 Concentration Measurement are to be represented between 0 and 1 (section 4.13.2.1 Attributes). Further it is explained in section 4.13.2.1.1 MeasuredValue Attribute that "MeasuredValue represents the concentration as a fraction of 1 (one)."

Because the current implementation multiplies the given MeasuredValue by 1000000 (million) the published value is not only wrong, but changes in the inverse direction. The larger the actual measured value becomes (the larger the denominator is), the smaller MeasuredValue becomes.

Device (PPM) MeasuredValue z2m (PPM)
800 0.00125 1250
1250 0.00080 800
  • I have tried this change as external converter with my own co2 zigbee device.
  • Dependent changes
    • modernExtend.ts seems to make similar assumptions too, but I do not know how / when scale and change are used - before or after the conversion took place.
    • some other place?
  • Figure out if some existing devices actually implement MeasuredValue in the current way. And provide device specific workarounds.
    • I would need help with that, as I own no other co2 sensor.

The zigbee standard specifies that the values of section 4.13
Concentration Measurement are to be represented between 0 and 1 (section
4.13.2.1 Attributes). Further it is explained in section 4.13.2.1.1
MeasuredValue Attribute that "MeasuredValue represents the concentration
as a fraction of 1 (one)."

Because the current implementation multiplies the given MeasuredValue by
1000000 (million) the published value is not only wrong, but changes in
the inverse direction. The larger the actual measured value becomes (the
larger the denominator is), the smaller MeasuredValue becomes.

| Device (PPM) | MeasuredValue | z2m (PPM) |
|--------------|---------------|-----------|
| 800          | 0.00125       | 1250      |
| 1250         | 0.00080       | 800       |
@Koenkk
Copy link
Owner

Koenkk commented Jan 19, 2025

modernExtend.ts seems to make similar assumptions too, but I do not know how / when scale and change are used - before or after the conversion took place.

What device do you have? Maybe it's best to also refactor that to modernExtend.

@Eyenseo
Copy link
Contributor Author

Eyenseo commented Jan 19, 2025

DIY project based on nrf52840/zephyr and scd41.

I would like to use modernExtend - I just don't know how to do that / where the calculations take place. But I have also not searched for documentation too much. My guess was that they somehow still make use of the function that I modified, but based on your answer that is not correct, which would mean that they convert via scale?
I wanted to get the PR out as it took me some head scratching why the values where weird and I was hoping to get some help from the community to figure out what to do with this change.

@Koenkk
Copy link
Owner

Koenkk commented Jan 19, 2025

Using modern extend should be easy, see

as an example.

The conversion is done here:

value = typeof scale === 'number' ? value / scale : scale(value, 'from');

@Eyenseo
Copy link
Contributor Author

Eyenseo commented Jan 19, 2025

I'm unsure about reporting: {min: '10_SECONDS', max: '1_HOUR', change: 0.00005}, // 50 ppm change. I guess change is used before scale is applied and is usually used in a way of abs(previous-new) > change?

I haven't reached the point just yet where I can use the reporting feature - but I guess it makes sense that the device will be able to undo the fraction to compare the two values.

This field is interpreted by the device and the device will have to undo
the fraction to figure out if there's something to report.
@Koenkk Koenkk merged commit 8a70e68 into Koenkk:master Jan 19, 2025
2 checks passed
@Koenkk
Copy link
Owner

Koenkk commented Jan 19, 2025

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants