The PSLab app should expand support for external sensors and provide a consistent framework for adding, configuring, reading, displaying, and documenting sensors.
This issue unifies and updates the older sensor-related issues:
The original issues were written for the earlier Android app. The PSLab app is now Flutter-based, so sensor support should be implemented in a way that fits the current app architecture and works across supported platforms where hardware access is available.
The implementation should not only add raw readings. Where applicable, sensors should have dedicated user interfaces, meters, controls, guides, and hardware compatibility information.
Current behavior
The app does not yet provide complete and consistent support for PSLab kit sensors and commonly used external sensors.
Older issues mention support for sensors such as:
- Moisture sensor FR-04
- LDR GL5528
- Microphone KY-037
- Magnetic KY-003
- Temperature LM35
- DHT11 temperature/humidity sensor
Some sensors may already have partial or existing support. For example, the microphone already has a sound meter, and MQ135 is already supported. These should not be duplicated, but existing support should be reviewed and documented where needed.
Expected behavior
The app should provide a clear and extensible sensor support system.
Users should be able to:
- Select a supported sensor.
- See whether the sensor works with PSLab V5, PSLab V6, phone hardware, or other supported hardware.
- Connect the sensor using a clear wiring guide.
- Read live sensor values.
- View values in useful units.
- Use a suitable sensor-specific interface where applicable.
- See charts, meters, indicators, or dashboards where useful.
- Calibrate sensors where needed.
- Understand limitations of each sensor.
- Add support for new sensors more easily in the future.
Sensors to support or review
Sensors to implement or improve
Sensors with existing support to review
MQ135 should not be part of the first implementation list for new sensor support because it is already supported. The task for MQ135 is only to verify that the current implementation, guide, and sensor overview are accurate.
Scope
1. Audit current sensor support
2. Create a unified sensor data model
Add a structured sensor definition system.
Each supported sensor should define:
- Sensor name
- Sensor type
- Supported hardware
- Required pins
- Communication protocol, for example analog, digital, I2C, SPI, UART, or phone sensor
- Measurement units
- Value range where known
- Calibration requirements
- Sampling requirements
- Guide or wiring diagram reference
- Sensor-specific UI type where applicable
Suggested structure:
enum SensorProtocol {
analog,
digital,
i2c,
spi,
uart,
phone,
}
enum SensorUiType {
rawValue,
analogMeter,
digitalState,
thermometer,
soundMeter,
humidityTemperatureDashboard,
chart,
}
class SensorDefinition {
final String id;
final String name;
final SensorProtocol protocol;
final SensorUiType uiType;
final List<String> supportedHardware;
final List<String> supportedUnits;
final String guideAsset;
}The final implementation should use the project’s existing architecture and naming conventions.
3. Implement DHT11 support
DHT11 should be implemented as part of the updated sensor framework.
The older issue referenced the Adafruit DHT sensor library for inspiration. The Flutter app implementation should use a PSLab-compatible approach and should not blindly copy Arduino-specific assumptions.
4. Implement or update PSLab kit sensors
For each kit sensor, create or update the app instrument or sensor view.
Each sensor should include:
Sensor-specific notes:
- Moisture sensor FR-04 should show soil moisture or analog level.
- LDR GL5528 should show light intensity or relative light level.
- Magnetic KY-003 should show digital magnetic detection state.
- LM35 should show temperature.
- DHT11 should show temperature and humidity.
- KY-037 microphone should reuse or improve the existing sound meter instead of duplicating it.
- MQ135 should only be reviewed for documentation and support overview accuracy because it is already supported.
Sensor-specific UI and meters
Where applicable, sensors should not only use a generic raw value display. The app should provide dedicated user interfaces, meters, or controls that match the type of sensor and make readings understandable for users.
Some sensors already have dedicated interfaces. In these cases, the task is to review, update, and improve the existing implementation instead of creating a duplicate screen.
Moisture sensor FR-04
LDR GL5528
Microphone KY-037
The microphone appears to already have a sound meter or related sound interface. This should not be duplicated.
Magnetic KY-003
Temperature LM35
DHT11
Already supported sensors
MQ135 is already supported and should not be part of the first implementation list for new sensor support.
Shared UI components
Sensor guides and wiring
Each supported sensor should have a guide.
The guide should include:
- What the sensor measures
- Required PSLab hardware
- Supported PSLab versions
- Whether phone hardware can be used instead
- Pin connections
- Breadboard connection diagram where suitable
- Expected reading range
- Calibration information
- Known limitations
- Troubleshooting steps
The guide should work on Android, iOS, desktop, and web where applicable.
User interface
The sensor area should provide a consistent UI for supported sensors.
Cross-platform behavior
The implementation should clearly state where sensor support works.
If a sensor requires PSLab hardware communication that is not available on a platform, the app should show a clear message instead of failing silently.
Testing
Add tests or documented manual testing steps for:
- Sensor list display
- Hardware compatibility filtering
- Sensor connection handling
- Successful readings
- Failed readings
- Unit display
- Sensor-specific meter rendering
- DHT11 temperature reading
- DHT11 humidity reading
- Analog sensor readings
- Digital sensor readings
- Guide display
- Responsive layout on different screen sizes
Implementation details
- Review the existing sensor implementation in the Flutter app.
- Review the older Android implementation if useful.
- Define a common sensor interface or service.
- Add sensor metadata for supported sensors.
- Implement missing sensor readers incrementally.
- Reuse existing interfaces where they already exist, for example the microphone sound meter.
- Avoid duplicate implementations for already supported sensors, for example MQ135.
- Use follow-up issues for individual sensors if the implementation becomes too large.
- Ensure each sensor can be independently tested.
- Ensure unsupported platforms or hardware combinations show clear messages.
- Keep the system extensible for future sensors.
Suggested first implementation scope
The first implementation should focus on:
- Sensor support audit
- Sensor metadata model
- Sensor list UI
- DHT11 temperature and humidity support
- One or two analog kit sensors, for example LM35 and LDR GL5528
- Sensor-specific UI components for implemented sensors
- Guides and wiring diagrams for implemented sensors
- Review of existing KY-037 sound meter support
- Review of existing MQ135 documentation and support overview
Additional sensors can be added in follow-up PRs using the same framework.
Out of scope for first implementation
- Full support for every possible external sensor
- Duplicate implementation of MQ135
- Duplicate implementation of the microphone sound meter if already available
- Complex automatic sensor detection
- Advanced calibration workflows for all sensors
- Scientific-grade calibration for gas sensor readings
- Cloud upload or long-term data logging unless already available elsewhere
Rationale
Sensor support is a core part of PSLab. A unified sensor framework will make it easier to support current kit sensors, add DHT11 and related sensors, and extend the app to more hardware in the future.
Instead of implementing sensors as unrelated one-off features, the app should provide a consistent architecture, UI, guide system, compatibility model, and sensor-specific interfaces.
Dedicated meters and controls make sensor readings easier to understand for students, workshop participants, and general users. Raw values should still be available for debugging, but the main user interface should show meaningful readings and visual feedback where possible.
Acceptance criteria
- Current sensor support is audited and documented.
- The app has a unified sensor definition or metadata structure.
- The app can list supported sensors.
- Sensor availability can be tied to supported hardware.
- DHT11 support is implemented or clearly scoped in the first PR.
- DHT11 temperature and humidity readings are displayed correctly.
- At least the priority PSLab kit sensors are listed with status.
- Implemented sensors have guides.
- Guides include wiring and supported hardware information.
- Where applicable, sensors have dedicated UI components or meters.
- KY-037 uses or improves the existing sound meter instead of duplicating it.
- MQ135 is not duplicated and is only reviewed for documentation and support overview accuracy.
- Unsupported sensors or platforms show clear messages.
- The implementation is extensible for more sensors.
- Relevant tests or documented manual testing steps are included.
The PSLab app should expand support for external sensors and provide a consistent framework for adding, configuring, reading, displaying, and documenting sensors.
This issue unifies and updates the older sensor-related issues:
The original issues were written for the earlier Android app. The PSLab app is now Flutter-based, so sensor support should be implemented in a way that fits the current app architecture and works across supported platforms where hardware access is available.
The implementation should not only add raw readings. Where applicable, sensors should have dedicated user interfaces, meters, controls, guides, and hardware compatibility information.
Current behavior
The app does not yet provide complete and consistent support for PSLab kit sensors and commonly used external sensors.
Older issues mention support for sensors such as:
Some sensors may already have partial or existing support. For example, the microphone already has a sound meter, and MQ135 is already supported. These should not be duplicated, but existing support should be reviewed and documented where needed.
Expected behavior
The app should provide a clear and extensible sensor support system.
Users should be able to:
Sensors to support or review
Sensors to implement or improve
Sensors with existing support to review
MQ135 should not be part of the first implementation list for new sensor support because it is already supported. The task for MQ135 is only to verify that the current implementation, guide, and sensor overview are accurate.
Scope
1. Audit current sensor support
2. Create a unified sensor data model
Add a structured sensor definition system.
Each supported sensor should define:
Suggested structure:
The final implementation should use the project’s existing architecture and naming conventions.
3. Implement DHT11 support
DHT11 should be implemented as part of the updated sensor framework.
The older issue referenced the Adafruit DHT sensor library for inspiration. The Flutter app implementation should use a PSLab-compatible approach and should not blindly copy Arduino-specific assumptions.
4. Implement or update PSLab kit sensors
For each kit sensor, create or update the app instrument or sensor view.
Each sensor should include:
Sensor-specific notes:
Sensor-specific UI and meters
Where applicable, sensors should not only use a generic raw value display. The app should provide dedicated user interfaces, meters, or controls that match the type of sensor and make readings understandable for users.
Some sensors already have dedicated interfaces. In these cases, the task is to review, update, and improve the existing implementation instead of creating a duplicate screen.
Moisture sensor FR-04
LDR GL5528
Microphone KY-037
The microphone appears to already have a sound meter or related sound interface. This should not be duplicated.
Magnetic KY-003
Temperature LM35
DHT11
Already supported sensors
MQ135 is already supported and should not be part of the first implementation list for new sensor support.
Shared UI components
Sensor guides and wiring
Each supported sensor should have a guide.
The guide should include:
The guide should work on Android, iOS, desktop, and web where applicable.
User interface
The sensor area should provide a consistent UI for supported sensors.
Cross-platform behavior
The implementation should clearly state where sensor support works.
If a sensor requires PSLab hardware communication that is not available on a platform, the app should show a clear message instead of failing silently.
Testing
Add tests or documented manual testing steps for:
Implementation details
Suggested first implementation scope
The first implementation should focus on:
Additional sensors can be added in follow-up PRs using the same framework.
Out of scope for first implementation
Rationale
Sensor support is a core part of PSLab. A unified sensor framework will make it easier to support current kit sensors, add DHT11 and related sensors, and extend the app to more hardware in the future.
Instead of implementing sensors as unrelated one-off features, the app should provide a consistent architecture, UI, guide system, compatibility model, and sensor-specific interfaces.
Dedicated meters and controls make sensor readings easier to understand for students, workshop participants, and general users. Raw values should still be available for debugging, but the main user interface should show meaningful readings and visual feedback where possible.
Acceptance criteria