Add barometer as an entity that iPhone/some iPads expose

[teancom]

Summary

I was reading this article https://www.howtogeek.com/your-phone-has-a-powerful-weather-instrument-hidden-inside/ - and it seemed neat! And adding support was actually pretty simple. Mostly just the one file plus tests and a little scattering of changes to the Xcode project file.

Screenshots

Link to pull request in Documentation repository

Documentation: home-assistant/companion.home-assistant#1309

Any other notes

Nothing bigger, just thought it would be neat.

[Copilot]

Pull request overview

This PR adds support for barometric pressure sensing to the Home Assistant iOS app by introducing a new BarometerSensor that leverages the device's built-in barometer via CoreMotion's CMAltimeter API. The sensor converts pressure readings from kilopascals to hectopascals (hPa) and reports them through the existing webhook sensor infrastructure.

Changes:

• Introduces a new BarometerSensor class that provides pressure readings from the device's barometer
• Adds a Barometer environment wrapper in AppEnvironment that abstracts the CoreMotion CMAltimeter API
• Extends WebhookSensorId enum with a new pressure case
• Includes comprehensive test coverage for authorization, availability, data validation, and pressure conversion logic
• Updates Xcode project configuration to include the new sensor files in appropriate build phases

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
Sources/Shared/API/Webhook/Sensors/BarometerSensor.swift	New sensor implementation that retrieves pressure data and converts it from kPa to hPa with 2 decimal place rounding
Sources/Shared/Environment/Environment.swift	Added Barometer struct wrapping CMAltimeter and registered BarometerSensor in the sensor container
Sources/Shared/API/Webhook/WebhookSensorId.swift	Added new pressure case to the sensor ID enum
Tests/Shared/Sensors/BarometerSensor.test.swift	Comprehensive test suite covering error conditions, data conversion, and proper cleanup
Tests/App/Webhook/WebhookSensorIdTests.swift	Updated test case count to 22 and added pressure sensor ID verification
HomeAssistant.xcodeproj/project.pbxproj	Added file references and build phase entries for both implementation and test files

[codecov]

Codecov Report

❌ Patch coverage is 89.36170% with 5 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@56b5c6a). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
Sources/Shared/Environment/Environment.swift	54.54%	5 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4491   +/-   ##
=======================================
  Coverage        ?   42.71%           
=======================================
  Files           ?      275           
  Lines           ?    16277           
  Branches        ?        0           
=======================================
  Hits            ?     6953           
  Misses          ?     9324           
  Partials        ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bgoncal]

How's the permission request flow? I see it has "unauthorized" as one of the possible state

[bgoncal]

Isn't this something that should update often?

[teancom]

I was following the pedometer sensor as a bit of a template, but I can absolutely switch over to SensorProviderUpdateSignaler like BatterySensor does and have it send more continuous updates if you would prefer that approach. Frankly, I'm just not sure what the impact is to battery life so I went with a conservative approach. If that's not an issue, great.

[bgoncal]

What are the use cases you have in mind for this sensor?

Then we can define how often we want to update it.

I would expect that who activates this sensor would expect it updating more than just once every long period of time

[teancom]

Yeah, I was probably being overly cautious. I was thinking about triggers on "big" drops in a short time as an alert source, which would require more frequent updates. I used to live in Nebraska and that was a sign to head for shelter.

I'll update the PR tonight to switch over.

[teancom]

How's the permission request flow? I see it has "unauthorized" as one of the possible state

I took the same approach as PedometerSensor and ActivitySensor, which are also bundled into the Motion & Fitness permission but otherwise are silently skipped in the list of available sensors. I figured this was enough of a niche thing that it shouldn't be something that pops up and requests the user grant permission how we do for Bluetooth, Notifications, or Camera (etc).