If your ESPHome configuration for a Sensirion SCD4x CO2 sensor set ambient_pressure_compensation with a unit, for example 961mBar, the sensor never got that pressure and did not compensate for it. Pull request #19888 by zerafachris fixes the unit handling. bdraco merged it into the development branch on 19 October 2026 at 09:54 Polish time, which also closed issue #19751 from 27 September.
Two mistakes that cancelled out
The option was validated with ESPHome's general pressure type, which converts every value to bar. The C++ code sends the number to the sensor unchanged and treats it as hPa (the same as mbar), which is the unit the SCD4x datasheet uses. The documentation also says mbar.
The issue walks through what that meant in practice. A bare number worked by accident: validation read 1013 as 1013 bar, the sensor received 1013 and took it as hPa, so the two mistakes cancelled out. A unit broke that. 961mBar was converted to 0.961 bar and reached the sensor as 0 hPa, which left pressure compensation off without any warning.
What the fix changes
- A bare number is still hPa, so configurations written that way keep working.
bar,mbarandmBarare now converted properly, so961mBarand0.961barboth reach the sensor as 961 hPa.- Values outside 700-1200 hPa are rejected. That is the range the SCD4x accepts for compensation.
0is still allowed. It turns pressure compensation off and letsaltitude_compensationapply, as before.
sensor:
- platform: scd4x
co2:
name: CO2
ambient_pressure_compensation: 961mBar # now reaches the sensor as 961 hPa
The range check can stop a configuration that compiled before. A bare value below 700 or above 1200, other than 0, now fails validation. That would catch, for example, a pressure written in bar without a unit, which never did what was intended.
The change covers only the fixed value in the YAML. The separate ambient_pressure_compensation_source option, which takes the pressure from another sensor reporting hPa, was not touched. The pull request adds compile tests for a bare hPa value, a value in bar and 0 with altitude compensation, and the author marked it as tested on an ESP32 with ESP-IDF and on an ESP8266.
The fix is in the development branch. ESPHome 2026.10 is still in beta (2026.10.0b5 came out on 19 October), and bug fixes are sometimes carried into the beta. If this one is not, it will arrive with ESPHome 2026.11.
If you wrote the pressure with a unit, keep in mind that your readings so far were not pressure-compensated. A step in the CO2 graph right after the update may come from the compensation, not from the air in the room.