Safeguarding Sensor Readings with Rust's Type System

In modern software development, ensuring data integrity and preventing runtime errors is paramount. Rust's powerful type system is a key tool for achieving this. This challenge will focus on leveraging Rust's strong typing to create a robust system for handling sensor readings, preventing invalid or unexpected data from corrupting your application.

Problem Description

You are tasked with building a system to process sensor readings. These readings come in various types, such as temperature, humidity, and pressure. However, not all readings are valid; some might represent errors or uninitialized states. Your goal is to design Rust data structures and logic that enforce type safety and prevent invalid readings from being used in calculations or other operations.

Key Requirements:

1. Represent Sensor Readings: Create an enum to represent different types of sensor readings (e.g., Temperature, Humidity, Pressure).
2. Handle Valid and Invalid States: For each sensor reading type, you must differentiate between a valid measurement and an invalid or uninitialized state.
3. Enforce Type Safety: Ensure that operations are only performed on valid sensor readings of the correct type.
4. Provide Safe Access: Implement methods to safely extract the underlying value from a sensor reading, returning an Option to indicate success or failure.
5. Simulate Sensor Data: Create a function that generates a collection of sensor readings, which may include both valid and invalid states.
6. Process Valid Readings: Write a function that iterates through a collection of sensor readings and performs a specific operation (e.g., averaging) only on valid readings of a particular type.

Expected Behavior:

• The system should compile without errors, demonstrating type safety.
• Attempting to access the value of an invalid reading should yield None.
• Operations on collections of sensor readings should correctly ignore invalid data and only process valid data of the expected type.

Edge Cases:

• An empty collection of sensor readings.
• A collection containing only invalid readings.
• A collection with mixed valid and invalid readings of different types.

Examples

Example 1:

Input: A `Vec<SensorReading>` containing:
- `SensorReading::Temperature(Valid(25.5))`
- `SensorReading::Humidity(Invalid)`
- `SensorReading::Pressure(Valid(1013.25))`
- `SensorReading::Temperature(Valid(26.1))`

Processing for temperature:
- Attempt to get valid temperature readings.
- Calculate the average of valid temperature readings.

Output:
Valid temperatures: [25.5, 26.1]
Average temperature: 25.8

Explanation: The Humidity(Invalid) and any other non-temperature readings are ignored. The average is calculated only from the two valid temperature readings.

Example 2:

Input: A `Vec<SensorReading>` containing:
- `SensorReading::Temperature(Uninitialized)`
- `SensorReading::Pressure(Valid(998.0))`

Processing for pressure:
- Attempt to get valid pressure readings.
- Calculate the average of valid pressure readings.

Output:
Valid pressures: [998.0]
Average pressure: 998.0

Explanation: Uninitialized is treated as an invalid state. The average is calculated from the single valid pressure reading.

Example 3: Edge Case - Empty Input

Input: An empty `Vec<SensorReading>`

Processing for humidity:
- Attempt to get valid humidity readings.
- Calculate the average of valid humidity readings.

Output:
Valid humidities: []
Average humidity: NaN (or some representation of no average)

Explanation: With no readings, there are no valid humidities, and thus no average can be computed.

Constraints

• The sensor readings will be represented by f32 for temperature and pressure, and f32 for humidity (representing percentage).
• The system should handle at least three distinct sensor types: Temperature, Humidity, and Pressure.
• Performance is not a primary concern for this challenge, but inefficient solutions that lead to excessive memory usage or extremely slow execution might be suboptimal.

Notes

• Consider using Rust's enum and struct to model your data.
• The Option enum is your friend for handling cases where a value might or might not be present.
• Think about how to represent the "invalid" or "uninitialized" states for each sensor type. You might need nested enums or different variants within your main sensor reading enum.
• When calculating averages, consider how to handle the case of zero valid readings.