Re: [Sensors] Temperature sensor use cases

What about also some pretty straight-up use cases in which a webapp will monitor temperature for various recording/post-processing/alerting purposes?

An app monitors temperature as well as sleep movements (using ambient sound), to help those with difficulty getting a good night's sleep understand how room temperature might be affecting them.

Similarly, a room temperature sensor is used to help a worker stay alert and/or hydrated, by providing an alarm when the temperature rises above a level that can begin to affect focus and hydration.

A blogger/writer may just want to record the temperature with postings, just because we are information-addicted, or it might really have something to do with the quality of the output.

A temperature sensor installed in an oven hood is monitored by a webapp that can let the homeowner know when they forgot to turn a stove burner off (tell me "that never happens"!). The app can set a timer when the temperature indicates something is being cooked, and wait for the typical time when the stove should have cooled, before providing an alert.

Many more.

Bryan

On Jul 26, 2011, at 4:23 PM, Tran, Dzung D wrote:

> Agree, that some of these use cases might not be best. However temperature sensor is still useful in an application (webapp). For example:
> 
> - I can have a webapp that take a snapshot of me sitting on the beach and tag the picture with the location, temperature, ..etc.
> 
> Thanks
> Dzung Tran
> 
> -----Original Message-----
> From: Josh Soref [mailto:jsoref@rim.com] 
> Sent: Tuesday, July 26, 2011 3:52 PM
> To: Tran, Dzung D; public-device-apis@w3.org
> Subject: RE: [Sensors] Temperature sensor use cases
> 
>> Temperature Sensor
>> 
>> Use-Cases
>> 
>> Application can throttle activity based on device temperature.
>> 
>> A web application can take device temperature into account in order to
>> throttle activity and avoid degraded performance or crashes due to heat
>> from intense hardware use. For example, some devices include RFID
>> radios with >1 watt power amplifiers and can generate a lot of heat.
> 
> Overheating is something the device needs to handle on its own. This isn't a good reason to expose temperature to web apps, potentially some might choose to actively *try* to cause the system to overheat.
> 
> General information about wanting to use less power can be reflected by the battery indicator claiming to be running down faster (which will probably be true anyway).
> 
>> Throttling performance may avoid degradation or crashes on these
>> devices. In addition the application may present the user with a
>> notification about device temperature and suggest an action
> 
> The system will need to do this anyway and shouldn't be relying on a web application (which will probably fail under interesting cases anyway). In fact, deployed devices already do this (the last products I shipped certainly did, I know, I rewrote the translations for them).
> 
>> or send a notification to an IT web service that indicates the
>> device is "running hot".
> 
> While a widget might want to exist for this purpose, I really don't think this justifies a Web facing API. It's a use case for SNMP and if the device wants to support SNMP, it can and should.
> 
> This should really be SNMP/nagios (or an equivalent).
> 
>> A weather monitoring application uses temperature data from automobile
>> temperature sensors.
> 
> This is more reasonable, and probably supports a path via Discovery (with pairing to applications) of Sensors.
> 
>> A web application that runs on a dashboard console could send the
>> temperature outside the car, with additional location information to a
>> weather related web service.
> 
> This is the same use case as the previous one.
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Thursday, 4 August 2011 06:03:07 UTC