Should we have sensor readings traits in embedded-hal or another "sensor" crate?

[therealprof]

Since concrete driver implementations are on the way it would be great if there was a common set of Traits that could be implemented to retrieve values from sensors, potentially including unit conversion.

Some Traits that immediately come to my mind would be:

• Temperature
• Electricity
• Location
• Kinetics
• Orientation
• Vision
• Concentrations
• ...

My question would be: Is this something we would want to add to embedded-hal or should this better live in a to-be-created new crate?

[hannobraun]

This is a good idea, but I believe it's better to create a new crate. embedded-hal should be a basic building block for all things embedded Rust, and I think broadening its scope and adding more experimental stuff runs counter to that goal.

Starting a new crate will keep embedded-hal focused and give the new stuff the freedom to experiment without restriction. We can always decide to merge them later, if we think that makes sense.

[EugeneGonzalez]

I'm in favor of adding these traits to embedded-hal, even if that restricts the experimenting. There is two reason why: 1) Exposure/Reach - If people are going to use embedded-hal for their sensor crate, they're much more likely to use sensor traits if they're included in embedded-hal. 2) Adds output uniformity to embedded-hal. The awesome thing about embedded-hal is that it unifies the inputs for sensor crates. Adding sensor traits to embedded-hal now unifies the input and output of sensor crates. Making dropping in different IMUs or temperature sensors much easier. Most of the logical code would be the same only needing to edit configuration of the sensor or input.