Re: [RFC] Health Thermometer Profile API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, Jun 20, 2011 at 7:45 AM, Elvis Pfutzenreuter <epx@xxxxxxxxxxx> wrote:
>> +             MeasureReceived(dict measure)
>> +
>> +                     This signal is emmited when a measure has been scanned
>> +                     by the thermometer. The Time entry in the dict will be
>> +                     only present if the device supports storing of data.
>> +                     The Type entry is optional and it will be provided if
>> +                     the measure type is non-static. For static measures the
>> +                     property Type will be provided. The Value entry
>> +                     corresponds to IEEE-11073 32-bit FLOAT.
>> +
>> +                     Dict is defined as below:
>> +                     {
>> +                             "Value" : uint32,
>> +                             "Unit" : ("Celsius" or "Fahrenheit")
>> +                             "Time" : {
>> +                                             "Year" : uint16,
>> +                                             "Month" : uint8,
>> +                                             "Day" : uint8,
>> +                                             "Hours" : uint8,
>> +                                             "Minutes" : uint8,
>> +                                             "Seconds" : uint8
>
> We don't really need to mimic the timestamp structure used in spec. We could
> go for a simple int with time() format (we should look into other
> BlueZ APIs to see which format they use for date or time).
>
> A value for no-timestamp case should be defined, too.

For reference, this is from doc/clock-api.txt in connman (which has
architecture similar to BlueZ:

[...]
Properties      uint64 Time [readonly or readwrite]

                        Current system time in seconds since epoch.
[...]



>
>> +                                     }
>> +                             "Type" : uint8,
>> +                             "Measurement" : ("Final", "Intermediate")
>> +                     }
>
> I would favor an agent for this case instead of signals, because it makes it
> implicit whether there is someone interested in getting temperature notifications.
> I mean, if some app a) enables notification properties and b) leaves, notification
> will keep being done, burning both devices' batteries. That's LE, after all :)
>
> Turning off upon exit is not an option because some other app may be interested,
> too. The agent is a natural 'reference counter', too.

In general, if you want/need to support multiple users of the D-Bus
API, something like an agent is necessary IMHO. Otherwise, it would be
necessary to return some "busy" error to avoid other users disabling
intermediate measurements while another user is interested on them.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux