The sensor API has felt the brunt of design change over time in the mobile applications. There are a few adjustments to be made/discussed to reflect product expectations.
from_utc vs from: both query parameters mean the current Unix timestamp (without offset) in milliseconds
24hours vs day: both parameters indicate fetching sensor historical data for the past day
Sensor units do not have a uniform style or capitalization (c,AQI,%,lux,dB). They are formatted for display in English, but not reuse for client localization or enumeration.
Client-side unit conversions
Clients need to check and convert between Centigrade and Fahrenheit before displaying the data to users.
Payload size for graph endpoints
There might be a data format more efficient than JSON for representing large amounts of data points for graphs and could at least reduce the payload size by removing object key duplication.
Lack of data structure for expressing the ideal range of a sensor value
There is currently an ideal_conditions message string to indicate the what values of the sensor unit would indicate an IDEAL state, but no way outside of string parsing to access that data directly. This is more of a concern for the API once it is open to third parties.
pims
commented
9 years ago
The sensor API has felt the brunt of design change over time in the mobile applications. There are a few adjustments to be made/discussed to reflect product expectations.
Specification for Sensors v1
Initial Concerns
Parameter inconsistency
from_utcvsfrom: both query parameters mean the current Unix timestamp (without offset) in milliseconds24hoursvsday: both parameters indicate fetching sensor historical data for the past dayc,AQI,%,lux,dB). They are formatted for display in English, but not reuse for client localization or enumeration.Client-side unit conversions
Clients need to check and convert between Centigrade and Fahrenheit before displaying the data to users.
Payload size for graph endpoints
There might be a data format more efficient than JSON for representing large amounts of data points for graphs and could at least reduce the payload size by removing object key duplication.
Lack of data structure for expressing the ideal range of a sensor value
There is currently an
ideal_conditionsmessage string to indicate the what values of the sensor unit would indicate anIDEALstate, but no way outside of string parsing to access that data directly. This is more of a concern for the API once it is open to third parties.