---
doc/thermometer.txt | 125 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 125 insertions(+), 0 deletions(-)
create mode 100644 doc/thermometer.txt
diff --git a/doc/thermometer.txt b/doc/thermometer.txt
new file mode 100644
index 0000000..9afd2b2
--- /dev/null
+++ b/doc/thermometer.txt
@@ -0,0 +1,125 @@
+BlueZ D-Bus Thermomether API description
+****************************************
+
+ Santiago Carot-Nemesio <[email protected]>
+
+Health Thermomether Profile hierarchy
+=====================================
+
+Service org.bluez
+Interface org.bluez.Thermometer
+Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
+
+
+Methods void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ read-write properties can be changed. On success
+ this will emit a PropertyChanged signal.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+
+ dict GetProperties()
+
+ Returns all properties for the interface. See the
+ Properties section for the available properties.
+
+ RegisterThermometerWatcher(object agent)
+
+ Registers a watcher to monitor scanned measures.The agent
+ will be notified about final.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+
+ UnregisterThermometerWatcher(object agent)
+
+ Unregisters a watcher.
+
+ Final and intermediate temperatures won't be notified to
+ this agent any more.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.NotFound
+
+ EnableIntermediateMeasures(object agent)
+
+ Enables intermediate measure notifications for this agent
+ if the thermometer supports it.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.NotSupported
+
+ DisableIntermediateMeasures(object agent)
+
+ Disables intermediate measure notifications for this
+ agent. It will disable notifications in the thermometer
+ when the last agent removes the watcher for intermediate
+ measures.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.NotFound
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties boolean Intermediate [readonly]
+
+ True if the thermometer supports intermediate measure
+ notifications.
+
+ uint16 Interval (optional) [readwrite]
+
+ The Measurement Interval defines the time (in seconds)
+ between measurements. This interval is not related to
+ the intermediates measures and must be defined into
+ a valid range. Setting it to zero meaning that no
+ periodic measurements will be taken.
+
+ uint16 Minimum (optional) [readonly]
+
+ Defines the maximum value allowed for the interval
+ between periodic measurements.
+
+ uint16 Maximum (optional) [readonly]
+
+ Defines the minimuum value allowed for the interval
+ between periodic measurements.
+
+
+Health Thermometer Watcher hierarchy
+====================================
+Service unique name
+Interface org.bluez.ThermometerWatcher
+Object path freely definable
+
+Methods void MeasureReceived(dict measure)
+
+ This callback gets called when a measure has been
+ scanned in the thermometer. The Time entry in the dict
+ will be only present if the device supports storing of
+ data. The time value is expressed in seconds since epoch.
+ The value represented is (mantissa) x (10**exponent)
+ See foot note for special values when treating with
+ health devices.
+
+ Dict is defined as below:
+ {
+ "Exponent" : int8,
+ "Mantissa" : int32,
+ "Unit" : ("Celsius" or "Fahrenheit"),
+ "Time" : uint64,
+ "Type" : ("Armpit", "Body", "Ear", "Finger",
+ "Intestines", "Mouth", "Rectum", "Toe",
+ "Tympanum"),
+ "Measurement" : ("Final" or "Intermediate"),
+ }
+
+ For special cases, the exponent shall always be zero and
+ the mantissa should be one of following values:
+
+ NRes = -(2**23)
+ NaN = +(2**23-1)
+ INFINITY = (2**23-2)
+ -INFINITY = -(2**23-2)
--
1.7.5.2
Hi Anderson,
(cut)
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? This callback gets called when a measure has been
>> + ? ? ? ? ? ? ? ? ? ? ? scanned in the thermometer. The Time entry in the dict
>> + ? ? ? ? ? ? ? ? ? ? ? will be only present if the device supports storing of
>> + ? ? ? ? ? ? ? ? ? ? ? data. The time value is expressed in seconds since epoch.
>> + ? ? ? ? ? ? ? ? ? ? ? The value represented is (mantissa) x (10**exponent)
>> + ? ? ? ? ? ? ? ? ? ? ? See foot note for special values when treating with
>> + ? ? ? ? ? ? ? ? ? ? ? health devices.
>
> IIRC, the "Type" value is also optional.
>
Sorry, I didn't see this comment before.
You are right, there are two ways to notify the type of the
measurements. In a non-static fashion the Temperature Characteristic
will be used instead of adding this information with the measure at
notification time. On the other hands, the Temperature Characteristic
won't be used If the thermometer can take measurements from different
places. In this case the type information will be added when the
natification occurs. Only one of both methods can be used but not both
at the same time.
The first version of the API included the type as property when static
values were used. At last, we decided get ride of this property to
always include it in the callback. It is just an idea take from Luiz
Augusto's comments to simplify the API. You can see the old API
discussion in previous emails if you feel like it.
Best regards.
Hi Anderson,
2011/6/28 Anderson Lizardo <[email protected]>:
> Hi Santiago,
>
> On Tue, Jun 28, 2011 at 8:25 AM, Santiago Carot-Nemesio
> <[email protected]> wrote:
>> ---
>> ?doc/thermometer.txt | ?125 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> ?1 files changed, 125 insertions(+), 0 deletions(-)
>> ?create mode 100644 doc/thermometer.txt
>>
>> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
>> new file mode 100644
>> index 0000000..9afd2b2
>> --- /dev/null
>> +++ b/doc/thermometer.txt
>> @@ -0,0 +1,125 @@
>> +BlueZ D-Bus Thermomether API description
>
> Typo: Thermomether -> Thermometer
>
>> +****************************************
>> +
>> + ? ? ? Santiago Carot-Nemesio <[email protected]>
>> +
>> +Health Thermomether Profile hierarchy
>> +=====================================
>
> Typo: Thermomether -> Thermometer
>
>> +
>> +Service ? ? ? ? ? ? ? ?org.bluez
>> +Interface ? ? ?org.bluez.Thermometer
>> +Object path ? ?[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
>> +
>> +
>> +Methods ? ? ? ? ? ? ? ?void SetProperty(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Changes the value of the specified property. Only
>> + ? ? ? ? ? ? ? ? ? ? ? read-write properties can be changed. On success
>> + ? ? ? ? ? ? ? ? ? ? ? this will emit a PropertyChanged signal.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> + ? ? ? ? ? ? ? dict GetProperties()
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Returns all properties for the interface. See the
>> + ? ? ? ? ? ? ? ? ? ? ? Properties section for the available properties.
>> +
>> + ? ? ? ? ? ? ? RegisterThermometerWatcher(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Registers a watcher to monitor scanned measures.The agent
>
> Typo: measures -> measurements
>
>> + ? ? ? ? ? ? ? ? ? ? ? will be notified about final.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> + ? ? ? ? ? ? ? UnregisterThermometerWatcher(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Unregisters a watcher.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Final and intermediate temperatures won't be notified to
>> + ? ? ? ? ? ? ? ? ? ? ? this agent any more.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
>> +
>> + ? ? ? ? ? ? ? EnableIntermediateMeasures(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Enables intermediate measure notifications for this agent
>
> Typo: measure -> measurement
>
>> + ? ? ? ? ? ? ? ? ? ? ? if the thermometer supports it.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotSupported
>> +
>> + ? ? ? ? ? ? ? DisableIntermediateMeasures(object agent)
>
> What about a second argument to RegisterThermometerWatcher() that
> enables/disables intermediate measurements ?
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Disables intermediate measure notifications for this
>
> Typo: measure -> measurement
>
>> + ? ? ? ? ? ? ? ? ? ? ? agent. It will disable notifications in the thermometer
>> + ? ? ? ? ? ? ? ? ? ? ? when the last agent removes the watcher for intermediate
>> + ? ? ? ? ? ? ? ? ? ? ? measures.
>
> Typo: measures -> measurements
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
>> +
>> +Signals ? ? ? ? ? ? ? ?PropertyChanged(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? This signal indicates a changed value of the given
>> + ? ? ? ? ? ? ? ? ? ? ? property.
>> +
>> +Properties ? ? boolean Intermediate [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? True if the thermometer supports intermediate measure
>
> Typo: measure -> measurement
>
>> + ? ? ? ? ? ? ? ? ? ? ? notifications.
>> +
>> + ? ? ? ? ? ? ? uint16 Interval (optional) [readwrite]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? The Measurement Interval defines the time (in seconds)
>> + ? ? ? ? ? ? ? ? ? ? ? between measurements. This interval is not related to
>> + ? ? ? ? ? ? ? ? ? ? ? the intermediates measures and must be defined into
>
> Typo: intermediates -> intermediate
> Typo: measures -> measurements
>
>> + ? ? ? ? ? ? ? ? ? ? ? a valid range. Setting it to zero meaning that no
>
> Typo: meaning -> means
>
>> + ? ? ? ? ? ? ? ? ? ? ? periodic measurements will be taken.
>> +
>> + ? ? ? ? ? ? ? uint16 Minimum (optional) [readonly]
>
> This is inverted with Maximum.
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Defines the maximum value allowed for the interval
>> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
>> +
>> + ? ? ? ? ? ? ? uint16 Maximum (optional) [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Defines the minimuum value allowed for the interval
>
> Typo: minimuum -> minimum
>
>> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
>> +
>> +
>> +Health Thermometer Watcher hierarchy
>> +====================================
>> +Service ? ? ? ? ? ? ? ?unique name
>> +Interface ? ? ?org.bluez.ThermometerWatcher
>> +Object path ? ?freely definable
>> +
>> +Methods ? ? ? ? ? ? ? ?void MeasureReceived(dict measure)
>
> typo (measure vs. measurement)
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? This callback gets called when a measure has been
>> + ? ? ? ? ? ? ? ? ? ? ? scanned in the thermometer. The Time entry in the dict
>> + ? ? ? ? ? ? ? ? ? ? ? will be only present if the device supports storing of
>> + ? ? ? ? ? ? ? ? ? ? ? data. The time value is expressed in seconds since epoch.
>> + ? ? ? ? ? ? ? ? ? ? ? The value represented is (mantissa) x (10**exponent)
>> + ? ? ? ? ? ? ? ? ? ? ? See foot note for special values when treating with
>> + ? ? ? ? ? ? ? ? ? ? ? health devices.
>
> IIRC, the "Type" value is also optional.
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Dict is defined as below:
>> + ? ? ? ? ? ? ? ? ? ? ? {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Exponent" : int8,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Mantissa" : int32,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Unit" : ("Celsius" or "Fahrenheit"),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Time" : uint64,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Type" : ("Armpit", "Body", "Ear", "Finger",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Intestines", "Mouth", "Rectum", "Toe",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Tympanum"),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Measurement" : ("Final" or "Intermediate"),
>> + ? ? ? ? ? ? ? ? ? ? ? }
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? For special cases, the exponent shall always be zero and
>> + ? ? ? ? ? ? ? ? ? ? ? the mantissa should be one of following values:
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? NRes = -(2**23)
>> + ? ? ? ? ? ? ? ? ? ? ? NaN = +(2**23-1)
>> + ? ? ? ? ? ? ? ? ? ? ? INFINITY = (2**23-2)
>> + ? ? ? ? ? ? ? ? ? ? ? -INFINITY = -(2**23-2)
>> --
>> 1.7.5.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
>
>
> Regards,
Thanks for your notes.
I'll submit a patch fixing this issues during the day if nobody has
more comments about this API.
Best regards.
Hi mike,
2011/6/28 mike tsai <[email protected]>:
> On Tue, Jun 28, 2011 at 5:25 AM, Santiago Carot-Nemesio
> <[email protected]> wrote:
>> ---
>> ?doc/thermometer.txt | ?125 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> ?1 files changed, 125 insertions(+), 0 deletions(-)
>> ?create mode 100644 doc/thermometer.txt
>>
>> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
>> new file mode 100644
>> index 0000000..9afd2b2
>> --- /dev/null
>> +++ b/doc/thermometer.txt
>> @@ -0,0 +1,125 @@
>> +BlueZ D-Bus Thermomether API description
>> +****************************************
>> +
>> + ? ? ? Santiago Carot-Nemesio <[email protected]>
>> +
>> +Health Thermomether Profile hierarchy
>> +=====================================
>> +
>> +Service ? ? ? ? ? ? ? ?org.bluez
>> +Interface ? ? ?org.bluez.Thermometer
>> +Object path ? ?[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
>> +
>> +
>> +Methods ? ? ? ? ? ? ? ?void SetProperty(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Changes the value of the specified property. Only
>> + ? ? ? ? ? ? ? ? ? ? ? read-write properties can be changed. On success
>> + ? ? ? ? ? ? ? ? ? ? ? this will emit a PropertyChanged signal.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> + ? ? ? ? ? ? ? dict GetProperties()
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Returns all properties for the interface. See the
>> + ? ? ? ? ? ? ? ? ? ? ? Properties section for the available properties.
>> +
>> + ? ? ? ? ? ? ? RegisterThermometerWatcher(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Registers a watcher to monitor scanned measures.The agent
>> + ? ? ? ? ? ? ? ? ? ? ? will be notified about final.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> + ? ? ? ? ? ? ? UnregisterThermometerWatcher(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Unregisters a watcher.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Final and intermediate temperatures won't be notified to
>> + ? ? ? ? ? ? ? ? ? ? ? this agent any more.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
>> +
>> + ? ? ? ? ? ? ? EnableIntermediateMeasures(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Enables intermediate measure notifications for this agent
>> + ? ? ? ? ? ? ? ? ? ? ? if the thermometer supports it.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotSupported
>> +
>> + ? ? ? ? ? ? ? DisableIntermediateMeasures(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Disables intermediate measure notifications for this
>> + ? ? ? ? ? ? ? ? ? ? ? agent. It will disable notifications in the thermometer
>> + ? ? ? ? ? ? ? ? ? ? ? when the last agent removes the watcher for intermediate
>> + ? ? ? ? ? ? ? ? ? ? ? measures.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
>> +
>> +Signals ? ? ? ? ? ? ? ?PropertyChanged(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? This signal indicates a changed value of the given
>> + ? ? ? ? ? ? ? ? ? ? ? property.
>> +
>> +Properties ? ? boolean Intermediate [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? True if the thermometer supports intermediate measure
>> + ? ? ? ? ? ? ? ? ? ? ? notifications.
>> +
>> + ? ? ? ? ? ? ? uint16 Interval (optional) [readwrite]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? The Measurement Interval defines the time (in seconds)
>> + ? ? ? ? ? ? ? ? ? ? ? between measurements. This interval is not related to
>> + ? ? ? ? ? ? ? ? ? ? ? the intermediates measures and must be defined into
>> + ? ? ? ? ? ? ? ? ? ? ? a valid range. Setting it to zero meaning that no
>> + ? ? ? ? ? ? ? ? ? ? ? periodic measurements will be taken.
>> +
>> + ? ? ? ? ? ? ? uint16 Minimum (optional) [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Defines the maximum value allowed for the interval
>> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
>> +
>> + ? ? ? ? ? ? ? uint16 Maximum (optional) [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Defines the minimuum value allowed for the interval
>> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
>> +
>> +
>> +Health Thermometer Watcher hierarchy
>> +====================================
>> +Service ? ? ? ? ? ? ? ?unique name
>> +Interface ? ? ?org.bluez.ThermometerWatcher
>> +Object path ? ?freely definable
>> +
>> +Methods ? ? ? ? ? ? ? ?void MeasureReceived(dict measure)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? This callback gets called when a measure has been
>> + ? ? ? ? ? ? ? ? ? ? ? scanned in the thermometer. The Time entry in the dict
>> + ? ? ? ? ? ? ? ? ? ? ? will be only present if the device supports storing of
>> + ? ? ? ? ? ? ? ? ? ? ? data. The time value is expressed in seconds since epoch.
>> + ? ? ? ? ? ? ? ? ? ? ? The value represented is (mantissa) x (10**exponent)
>> + ? ? ? ? ? ? ? ? ? ? ? See foot note for special values when treating with
>> + ? ? ? ? ? ? ? ? ? ? ? health devices.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Dict is defined as below:
>> + ? ? ? ? ? ? ? ? ? ? ? {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Exponent" : int8,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Mantissa" : int32,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Unit" : ("Celsius" or "Fahrenheit"),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Time" : uint64,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Type" : ("Armpit", "Body", "Ear", "Finger",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Intestines", "Mouth", "Rectum", "Toe",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Tympanum"),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Measurement" : ("Final" or "Intermediate"),
>> + ? ? ? ? ? ? ? ? ? ? ? }
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? For special cases, the exponent shall always be zero and
>> + ? ? ? ? ? ? ? ? ? ? ? the mantissa should be one of following values:
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? NRes = -(2**23)
>> + ? ? ? ? ? ? ? ? ? ? ? NaN = +(2**23-1)
>> + ? ? ? ? ? ? ? ? ? ? ? INFINITY = (2**23-2)
>> + ? ? ? ? ? ? ? ? ? ? ? -INFINITY = -(2**23-2)
>> --
>> 1.7.5.2
>>
>> --
>
> Is this proposal going to use reference count for property setting of
> notification/indication? and if one of the applications enables
> immediate alert notification, then all other applications will receive
> the notification even if they have not registered it?
Yes, the idea is just the same as suggested by Anderson. We will use a
reference counter to enable/disable indications and notification.
Applications won't manage characteristics and properties directly, the
plugin will do it based on the number of watchers subscribed.
With respect to second question, no, only agents which enable
intermediate notifications will be notified. Rest of agents only will
be notified about final measures.
Regards.
On Tue, Jun 28, 2011 at 5:25 AM, Santiago Carot-Nemesio
<[email protected]> wrote:
> ---
> ?doc/thermometer.txt | ?125 +++++++++++++++++++++++++++++++++++++++++++++++++++
> ?1 files changed, 125 insertions(+), 0 deletions(-)
> ?create mode 100644 doc/thermometer.txt
>
> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
> new file mode 100644
> index 0000000..9afd2b2
> --- /dev/null
> +++ b/doc/thermometer.txt
> @@ -0,0 +1,125 @@
> +BlueZ D-Bus Thermomether API description
> +****************************************
> +
> + ? ? ? Santiago Carot-Nemesio <[email protected]>
> +
> +Health Thermomether Profile hierarchy
> +=====================================
> +
> +Service ? ? ? ? ? ? ? ?org.bluez
> +Interface ? ? ?org.bluez.Thermometer
> +Object path ? ?[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
> +
> +
> +Methods ? ? ? ? ? ? ? ?void SetProperty(string name, variant value)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Changes the value of the specified property. Only
> + ? ? ? ? ? ? ? ? ? ? ? read-write properties can be changed. On success
> + ? ? ? ? ? ? ? ? ? ? ? this will emit a PropertyChanged signal.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> +
> + ? ? ? ? ? ? ? dict GetProperties()
> +
> + ? ? ? ? ? ? ? ? ? ? ? Returns all properties for the interface. See the
> + ? ? ? ? ? ? ? ? ? ? ? Properties section for the available properties.
> +
> + ? ? ? ? ? ? ? RegisterThermometerWatcher(object agent)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Registers a watcher to monitor scanned measures.The agent
> + ? ? ? ? ? ? ? ? ? ? ? will be notified about final.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> +
> + ? ? ? ? ? ? ? UnregisterThermometerWatcher(object agent)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Unregisters a watcher.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Final and intermediate temperatures won't be notified to
> + ? ? ? ? ? ? ? ? ? ? ? this agent any more.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
> +
> + ? ? ? ? ? ? ? EnableIntermediateMeasures(object agent)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Enables intermediate measure notifications for this agent
> + ? ? ? ? ? ? ? ? ? ? ? if the thermometer supports it.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotSupported
> +
> + ? ? ? ? ? ? ? DisableIntermediateMeasures(object agent)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Disables intermediate measure notifications for this
> + ? ? ? ? ? ? ? ? ? ? ? agent. It will disable notifications in the thermometer
> + ? ? ? ? ? ? ? ? ? ? ? when the last agent removes the watcher for intermediate
> + ? ? ? ? ? ? ? ? ? ? ? measures.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
> +
> +Signals ? ? ? ? ? ? ? ?PropertyChanged(string name, variant value)
> +
> + ? ? ? ? ? ? ? ? ? ? ? This signal indicates a changed value of the given
> + ? ? ? ? ? ? ? ? ? ? ? property.
> +
> +Properties ? ? boolean Intermediate [readonly]
> +
> + ? ? ? ? ? ? ? ? ? ? ? True if the thermometer supports intermediate measure
> + ? ? ? ? ? ? ? ? ? ? ? notifications.
> +
> + ? ? ? ? ? ? ? uint16 Interval (optional) [readwrite]
> +
> + ? ? ? ? ? ? ? ? ? ? ? The Measurement Interval defines the time (in seconds)
> + ? ? ? ? ? ? ? ? ? ? ? between measurements. This interval is not related to
> + ? ? ? ? ? ? ? ? ? ? ? the intermediates measures and must be defined into
> + ? ? ? ? ? ? ? ? ? ? ? a valid range. Setting it to zero meaning that no
> + ? ? ? ? ? ? ? ? ? ? ? periodic measurements will be taken.
> +
> + ? ? ? ? ? ? ? uint16 Minimum (optional) [readonly]
> +
> + ? ? ? ? ? ? ? ? ? ? ? Defines the maximum value allowed for the interval
> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
> +
> + ? ? ? ? ? ? ? uint16 Maximum (optional) [readonly]
> +
> + ? ? ? ? ? ? ? ? ? ? ? Defines the minimuum value allowed for the interval
> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
> +
> +
> +Health Thermometer Watcher hierarchy
> +====================================
> +Service ? ? ? ? ? ? ? ?unique name
> +Interface ? ? ?org.bluez.ThermometerWatcher
> +Object path ? ?freely definable
> +
> +Methods ? ? ? ? ? ? ? ?void MeasureReceived(dict measure)
> +
> + ? ? ? ? ? ? ? ? ? ? ? This callback gets called when a measure has been
> + ? ? ? ? ? ? ? ? ? ? ? scanned in the thermometer. The Time entry in the dict
> + ? ? ? ? ? ? ? ? ? ? ? will be only present if the device supports storing of
> + ? ? ? ? ? ? ? ? ? ? ? data. The time value is expressed in seconds since epoch.
> + ? ? ? ? ? ? ? ? ? ? ? The value represented is (mantissa) x (10**exponent)
> + ? ? ? ? ? ? ? ? ? ? ? See foot note for special values when treating with
> + ? ? ? ? ? ? ? ? ? ? ? health devices.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Dict is defined as below:
> + ? ? ? ? ? ? ? ? ? ? ? {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Exponent" : int8,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Mantissa" : int32,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Unit" : ("Celsius" or "Fahrenheit"),
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Time" : uint64,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Type" : ("Armpit", "Body", "Ear", "Finger",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Intestines", "Mouth", "Rectum", "Toe",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Tympanum"),
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Measurement" : ("Final" or "Intermediate"),
> + ? ? ? ? ? ? ? ? ? ? ? }
> +
> + ? ? ? ? ? ? ? ? ? ? ? For special cases, the exponent shall always be zero and
> + ? ? ? ? ? ? ? ? ? ? ? the mantissa should be one of following values:
> +
> + ? ? ? ? ? ? ? ? ? ? ? NRes = -(2**23)
> + ? ? ? ? ? ? ? ? ? ? ? NaN = +(2**23-1)
> + ? ? ? ? ? ? ? ? ? ? ? INFINITY = (2**23-2)
> + ? ? ? ? ? ? ? ? ? ? ? -INFINITY = -(2**23-2)
> --
> 1.7.5.2
>
> --
Is this proposal going to use reference count for property setting of
notification/indication? and if one of the applications enables
immediate alert notification, then all other applications will receive
the notification even if they have not registered it?
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Hello,
2011/6/28 Anderson Lizardo <[email protected]>:
> Hi Santiago,
>
> On Tue, Jun 28, 2011 at 8:25 AM, Santiago Carot-Nemesio
> <[email protected]> wrote:
>> ---
>> ?doc/thermometer.txt | ?125 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> ?1 files changed, 125 insertions(+), 0 deletions(-)
>> ?create mode 100644 doc/thermometer.txt
>>
>> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
>> new file mode 100644
>> index 0000000..9afd2b2
>> --- /dev/null
>> +++ b/doc/thermometer.txt
>> @@ -0,0 +1,125 @@
>> +BlueZ D-Bus Thermomether API description
>
> Typo: Thermomether -> Thermometer
>
>> +****************************************
>> +
>> + ? ? ? Santiago Carot-Nemesio <[email protected]>
>> +
>> +Health Thermomether Profile hierarchy
>> +=====================================
>
> Typo: Thermomether -> Thermometer
>
>> +
>> +Service ? ? ? ? ? ? ? ?org.bluez
>> +Interface ? ? ?org.bluez.Thermometer
>> +Object path ? ?[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
>> +
>> +
>> +Methods ? ? ? ? ? ? ? ?void SetProperty(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Changes the value of the specified property. Only
>> + ? ? ? ? ? ? ? ? ? ? ? read-write properties can be changed. On success
>> + ? ? ? ? ? ? ? ? ? ? ? this will emit a PropertyChanged signal.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> + ? ? ? ? ? ? ? dict GetProperties()
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Returns all properties for the interface. See the
>> + ? ? ? ? ? ? ? ? ? ? ? Properties section for the available properties.
>> +
>> + ? ? ? ? ? ? ? RegisterThermometerWatcher(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Registers a watcher to monitor scanned measures.The agent
>
> Typo: measures -> measurements
>
>> + ? ? ? ? ? ? ? ? ? ? ? will be notified about final.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> + ? ? ? ? ? ? ? UnregisterThermometerWatcher(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Unregisters a watcher.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Final and intermediate temperatures won't be notified to
>> + ? ? ? ? ? ? ? ? ? ? ? this agent any more.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
>> +
>> + ? ? ? ? ? ? ? EnableIntermediateMeasures(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Enables intermediate measure notifications for this agent
>
> Typo: measure -> measurement
>
>> + ? ? ? ? ? ? ? ? ? ? ? if the thermometer supports it.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotSupported
>> +
>> + ? ? ? ? ? ? ? DisableIntermediateMeasures(object agent)
>
> What about a second argument to RegisterThermometerWatcher() that
> enables/disables intermediate measurements ?
The idea is that applications can enable/disable intermediate
measurement notifications without have to unregister from the
thermometer service. If we use only a method for that purpose we are
forcing to applications to register and unregister themself from the
service even if they only want to disable this feature but remain
receiving final measures.
In any case comments about it are welcome.
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Disables intermediate measure notifications for this
>
> Typo: measure -> measurement
>
>> + ? ? ? ? ? ? ? ? ? ? ? agent. It will disable notifications in the thermometer
>> + ? ? ? ? ? ? ? ? ? ? ? when the last agent removes the watcher for intermediate
>> + ? ? ? ? ? ? ? ? ? ? ? measures.
>
> Typo: measures -> measurements
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
>> +
>> +Signals ? ? ? ? ? ? ? ?PropertyChanged(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? This signal indicates a changed value of the given
>> + ? ? ? ? ? ? ? ? ? ? ? property.
>> +
>> +Properties ? ? boolean Intermediate [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? True if the thermometer supports intermediate measure
>
> Typo: measure -> measurement
>
>> + ? ? ? ? ? ? ? ? ? ? ? notifications.
>> +
>> + ? ? ? ? ? ? ? uint16 Interval (optional) [readwrite]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? The Measurement Interval defines the time (in seconds)
>> + ? ? ? ? ? ? ? ? ? ? ? between measurements. This interval is not related to
>> + ? ? ? ? ? ? ? ? ? ? ? the intermediates measures and must be defined into
>
> Typo: intermediates -> intermediate
> Typo: measures -> measurements
>
>> + ? ? ? ? ? ? ? ? ? ? ? a valid range. Setting it to zero meaning that no
>
> Typo: meaning -> means
>
>> + ? ? ? ? ? ? ? ? ? ? ? periodic measurements will be taken.
>> +
>> + ? ? ? ? ? ? ? uint16 Minimum (optional) [readonly]
>
> This is inverted with Maximum.
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Defines the maximum value allowed for the interval
>> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
>> +
>> + ? ? ? ? ? ? ? uint16 Maximum (optional) [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Defines the minimuum value allowed for the interval
>
> Typo: minimuum -> minimum
>
>> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
>> +
>> +
>> +Health Thermometer Watcher hierarchy
>> +====================================
>> +Service ? ? ? ? ? ? ? ?unique name
>> +Interface ? ? ?org.bluez.ThermometerWatcher
>> +Object path ? ?freely definable
>> +
>> +Methods ? ? ? ? ? ? ? ?void MeasureReceived(dict measure)
>
> typo (measure vs. measurement)
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? This callback gets called when a measure has been
>> + ? ? ? ? ? ? ? ? ? ? ? scanned in the thermometer. The Time entry in the dict
>> + ? ? ? ? ? ? ? ? ? ? ? will be only present if the device supports storing of
>> + ? ? ? ? ? ? ? ? ? ? ? data. The time value is expressed in seconds since epoch.
>> + ? ? ? ? ? ? ? ? ? ? ? The value represented is (mantissa) x (10**exponent)
>> + ? ? ? ? ? ? ? ? ? ? ? See foot note for special values when treating with
>> + ? ? ? ? ? ? ? ? ? ? ? health devices.
>
> IIRC, the "Type" value is also optional.
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Dict is defined as below:
>> + ? ? ? ? ? ? ? ? ? ? ? {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Exponent" : int8,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Mantissa" : int32,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Unit" : ("Celsius" or "Fahrenheit"),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Time" : uint64,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Type" : ("Armpit", "Body", "Ear", "Finger",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Intestines", "Mouth", "Rectum", "Toe",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Tympanum"),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Measurement" : ("Final" or "Intermediate"),
>> + ? ? ? ? ? ? ? ? ? ? ? }
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? For special cases, the exponent shall always be zero and
>> + ? ? ? ? ? ? ? ? ? ? ? the mantissa should be one of following values:
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? NRes = -(2**23)
>> + ? ? ? ? ? ? ? ? ? ? ? NaN = +(2**23-1)
>> + ? ? ? ? ? ? ? ? ? ? ? INFINITY = (2**23-2)
>> + ? ? ? ? ? ? ? ? ? ? ? -INFINITY = -(2**23-2)
>> --
>> 1.7.5.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
>
>
> Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
>
Hi Santiago,
On Tue, Jun 28, 2011 at 8:25 AM, Santiago Carot-Nemesio
<[email protected]> wrote:
> ---
> ?doc/thermometer.txt | ?125 +++++++++++++++++++++++++++++++++++++++++++++++++++
> ?1 files changed, 125 insertions(+), 0 deletions(-)
> ?create mode 100644 doc/thermometer.txt
>
> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
> new file mode 100644
> index 0000000..9afd2b2
> --- /dev/null
> +++ b/doc/thermometer.txt
> @@ -0,0 +1,125 @@
> +BlueZ D-Bus Thermomether API description
Typo: Thermomether -> Thermometer
> +****************************************
> +
> + ? ? ? Santiago Carot-Nemesio <[email protected]>
> +
> +Health Thermomether Profile hierarchy
> +=====================================
Typo: Thermomether -> Thermometer
> +
> +Service ? ? ? ? ? ? ? ?org.bluez
> +Interface ? ? ?org.bluez.Thermometer
> +Object path ? ?[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
> +
> +
> +Methods ? ? ? ? ? ? ? ?void SetProperty(string name, variant value)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Changes the value of the specified property. Only
> + ? ? ? ? ? ? ? ? ? ? ? read-write properties can be changed. On success
> + ? ? ? ? ? ? ? ? ? ? ? this will emit a PropertyChanged signal.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> +
> + ? ? ? ? ? ? ? dict GetProperties()
> +
> + ? ? ? ? ? ? ? ? ? ? ? Returns all properties for the interface. See the
> + ? ? ? ? ? ? ? ? ? ? ? Properties section for the available properties.
> +
> + ? ? ? ? ? ? ? RegisterThermometerWatcher(object agent)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Registers a watcher to monitor scanned measures.The agent
Typo: measures -> measurements
> + ? ? ? ? ? ? ? ? ? ? ? will be notified about final.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> +
> + ? ? ? ? ? ? ? UnregisterThermometerWatcher(object agent)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Unregisters a watcher.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Final and intermediate temperatures won't be notified to
> + ? ? ? ? ? ? ? ? ? ? ? this agent any more.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
> +
> + ? ? ? ? ? ? ? EnableIntermediateMeasures(object agent)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Enables intermediate measure notifications for this agent
Typo: measure -> measurement
> + ? ? ? ? ? ? ? ? ? ? ? if the thermometer supports it.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotSupported
> +
> + ? ? ? ? ? ? ? DisableIntermediateMeasures(object agent)
What about a second argument to RegisterThermometerWatcher() that
enables/disables intermediate measurements ?
> +
> + ? ? ? ? ? ? ? ? ? ? ? Disables intermediate measure notifications for this
Typo: measure -> measurement
> + ? ? ? ? ? ? ? ? ? ? ? agent. It will disable notifications in the thermometer
> + ? ? ? ? ? ? ? ? ? ? ? when the last agent removes the watcher for intermediate
> + ? ? ? ? ? ? ? ? ? ? ? measures.
Typo: measures -> measurements
> +
> + ? ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
> +
> +Signals ? ? ? ? ? ? ? ?PropertyChanged(string name, variant value)
> +
> + ? ? ? ? ? ? ? ? ? ? ? This signal indicates a changed value of the given
> + ? ? ? ? ? ? ? ? ? ? ? property.
> +
> +Properties ? ? boolean Intermediate [readonly]
> +
> + ? ? ? ? ? ? ? ? ? ? ? True if the thermometer supports intermediate measure
Typo: measure -> measurement
> + ? ? ? ? ? ? ? ? ? ? ? notifications.
> +
> + ? ? ? ? ? ? ? uint16 Interval (optional) [readwrite]
> +
> + ? ? ? ? ? ? ? ? ? ? ? The Measurement Interval defines the time (in seconds)
> + ? ? ? ? ? ? ? ? ? ? ? between measurements. This interval is not related to
> + ? ? ? ? ? ? ? ? ? ? ? the intermediates measures and must be defined into
Typo: intermediates -> intermediate
Typo: measures -> measurements
> + ? ? ? ? ? ? ? ? ? ? ? a valid range. Setting it to zero meaning that no
Typo: meaning -> means
> + ? ? ? ? ? ? ? ? ? ? ? periodic measurements will be taken.
> +
> + ? ? ? ? ? ? ? uint16 Minimum (optional) [readonly]
This is inverted with Maximum.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Defines the maximum value allowed for the interval
> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
> +
> + ? ? ? ? ? ? ? uint16 Maximum (optional) [readonly]
> +
> + ? ? ? ? ? ? ? ? ? ? ? Defines the minimuum value allowed for the interval
Typo: minimuum -> minimum
> + ? ? ? ? ? ? ? ? ? ? ? between periodic measurements.
> +
> +
> +Health Thermometer Watcher hierarchy
> +====================================
> +Service ? ? ? ? ? ? ? ?unique name
> +Interface ? ? ?org.bluez.ThermometerWatcher
> +Object path ? ?freely definable
> +
> +Methods ? ? ? ? ? ? ? ?void MeasureReceived(dict measure)
typo (measure vs. measurement)
> +
> + ? ? ? ? ? ? ? ? ? ? ? This callback gets called when a measure has been
> + ? ? ? ? ? ? ? ? ? ? ? scanned in the thermometer. The Time entry in the dict
> + ? ? ? ? ? ? ? ? ? ? ? will be only present if the device supports storing of
> + ? ? ? ? ? ? ? ? ? ? ? data. The time value is expressed in seconds since epoch.
> + ? ? ? ? ? ? ? ? ? ? ? The value represented is (mantissa) x (10**exponent)
> + ? ? ? ? ? ? ? ? ? ? ? See foot note for special values when treating with
> + ? ? ? ? ? ? ? ? ? ? ? health devices.
IIRC, the "Type" value is also optional.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Dict is defined as below:
> + ? ? ? ? ? ? ? ? ? ? ? {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Exponent" : int8,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Mantissa" : int32,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Unit" : ("Celsius" or "Fahrenheit"),
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Time" : uint64,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Type" : ("Armpit", "Body", "Ear", "Finger",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Intestines", "Mouth", "Rectum", "Toe",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Tympanum"),
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Measurement" : ("Final" or "Intermediate"),
> + ? ? ? ? ? ? ? ? ? ? ? }
> +
> + ? ? ? ? ? ? ? ? ? ? ? For special cases, the exponent shall always be zero and
> + ? ? ? ? ? ? ? ? ? ? ? the mantissa should be one of following values:
> +
> + ? ? ? ? ? ? ? ? ? ? ? NRes = -(2**23)
> + ? ? ? ? ? ? ? ? ? ? ? NaN = +(2**23-1)
> + ? ? ? ? ? ? ? ? ? ? ? INFINITY = (2**23-2)
> + ? ? ? ? ? ? ? ? ? ? ? -INFINITY = -(2**23-2)
> --
> 1.7.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
>> (cut)
>>
>> Thing is, you need to show each client app process a different 'view' of
>> those D-Bus properties. It is feasible, but it is a new trick, not
>> employed in other APIs.
>
> I think that it may work for Final and Intermediate but not for the
> Interval property that is common for all agents. Besides, this
> characteristic can be readed/writed through the D-Bus attribute API
> too as Anderson said.
Agreed. Interval is unsolvable; there is only one per device.
Hi,
2011/6/25 Elvis Pfutzenreuter <[email protected]>:
> On Jun 24, 2011, at 11:27 AM, mike tsai wrote:
>
>> On Fri, Jun 24, 2011 at 6:20 AM, Elvis Pfutzenreuter <[email protected]> wrote:
>>>>> (cut)
>>>>
>>>> Coming back to this issue. I was just wondering that we may not need
>>>> worried about this issue because the same case may occurs at GATT
>>>> level. I mean, an application using GATT could disturb the behaviour
>>>> of other one when it enables/disables characteristics.
>>>
>>> Ok, but then the risk is clear. My feeling is that people are already
>>> "toning down" this API because of this. (One of the reasons my patch
>>> to add descriptor manipulation capability was rejected is that it was
>>> not meant to be a complete API and effort should go to profile-specific
>>> APIs. Without this, you can't toggle notifications and indications
>>> using generic GATT API anyway.)
>>>
>>>>
>>>> Because of any application can enable/disable characteristics we don't
>>>> need to worry about to manage this in the Thermometer API. Remember
>>>> that in other threads in the mailing list people were speaking about
>>>> making a D-Bus API for GATT. Those applications using GATT could
>>>> enable notification for measures and disable it. On account of this,
>>>> it will be inevitable collisions in the use cases.
>>>>
>>>> For this reason I think that the Thermometer API should be the most
>>>> permissive possible. If any application disable intermediate or final
>>>> measures, the PropertyChanged signal will be triggered, well, there is
>>>> no problem, if there are agents interested in such measures they only
>>>> will have to enable the proterty in the API once again as usual.
>>>
>>> I can see two apps monitoring PropertyChanged to enforce opposite
>>> states of notification. It would create a lot of heat.
>>>
>>>> To summarize, I think we should add the properties to enable and
>>>> disable intermediate and final measures and to leave to applications
>>>> to take deccisions about how they are going to behave when this stuff
>>>> happen.
>>>
>>> I remember Marcel saying once that applications always do the wrong
>>> thing when given the chance :) In this respect, our opinions are
>>> pretty much opposite; IMHO one application must not have a way to
>>> create a problem to others. Notification interval is impossible to
>>> insulate, for there is just one per device, but we can do better for
>>> toggling of notifications.
>>>
>>> It would be nice to have more opinions on this.
>> could we apply an 'OR' logic to this inside the profile? Each
>> application will have its own property setting.
>> So if App-A enables both, then it will receive both immediate/.final
>> temperatures indication/notification.
>> if App-B enables only final, then it receives final temperature indication only.
>> There are still the issue of how profile can "wake up" application(s)
>> when notification/indication come.
>
> It is a tempting alternative, would render a very clean API.
>
> Thing is, you need to show each client app process a different 'view' of
> those D-Bus properties. It is feasible, but it is a new trick, not
> employed in other APIs.
I think that it may work for Final and Intermediate but not for the
Interval property that is common for all agents. Besides, this
characteristic can be readed/writed through the D-Bus attribute API
too as Anderson said.
IMO we should adopt a refcount like behavior for
notifications/indications. On the other hands, we can assume that
there will be agents registered during the time they are interested
for final measures so we can activate this notification whenever there
are agents registered for the health thermometer service.
Opinions?
Best regards.
On Jun 24, 2011, at 11:27 AM, mike tsai wrote:
> On Fri, Jun 24, 2011 at 6:20 AM, Elvis Pfutzenreuter <[email protected]> wrote:
>>>> (cut)
>>>
>>> Coming back to this issue. I was just wondering that we may not need
>>> worried about this issue because the same case may occurs at GATT
>>> level. I mean, an application using GATT could disturb the behaviour
>>> of other one when it enables/disables characteristics.
>>
>> Ok, but then the risk is clear. My feeling is that people are already
>> "toning down" this API because of this. (One of the reasons my patch
>> to add descriptor manipulation capability was rejected is that it was
>> not meant to be a complete API and effort should go to profile-specific
>> APIs. Without this, you can't toggle notifications and indications
>> using generic GATT API anyway.)
>>
>>>
>>> Because of any application can enable/disable characteristics we don't
>>> need to worry about to manage this in the Thermometer API. Remember
>>> that in other threads in the mailing list people were speaking about
>>> making a D-Bus API for GATT. Those applications using GATT could
>>> enable notification for measures and disable it. On account of this,
>>> it will be inevitable collisions in the use cases.
>>>
>>> For this reason I think that the Thermometer API should be the most
>>> permissive possible. If any application disable intermediate or final
>>> measures, the PropertyChanged signal will be triggered, well, there is
>>> no problem, if there are agents interested in such measures they only
>>> will have to enable the proterty in the API once again as usual.
>>
>> I can see two apps monitoring PropertyChanged to enforce opposite
>> states of notification. It would create a lot of heat.
>>
>>> To summarize, I think we should add the properties to enable and
>>> disable intermediate and final measures and to leave to applications
>>> to take deccisions about how they are going to behave when this stuff
>>> happen.
>>
>> I remember Marcel saying once that applications always do the wrong
>> thing when given the chance :) In this respect, our opinions are
>> pretty much opposite; IMHO one application must not have a way to
>> create a problem to others. Notification interval is impossible to
>> insulate, for there is just one per device, but we can do better for
>> toggling of notifications.
>>
>> It would be nice to have more opinions on this.
> could we apply an 'OR' logic to this inside the profile? Each
> application will have its own property setting.
> So if App-A enables both, then it will receive both immediate/.final
> temperatures indication/notification.
> if App-B enables only final, then it receives final temperature indication only.
> There are still the issue of how profile can "wake up" application(s)
> when notification/indication come.
It is a tempting alternative, would render a very clean API.
Thing is, you need to show each client app process a different 'view' of
those D-Bus properties. It is feasible, but it is a new trick, not
employed in other APIs.
Hi Santiago,
On Fri, Jun 24, 2011 at 6:06 AM, Santiago Carot <[email protected]> wrote:
> Coming back to this issue. I was just wondering that we may not need
> worried about this issue because the same case may occurs at GATT
> level. I mean, an application using GATT could disturb the behaviour
> of other one when it enables/disables characteristics.
Actually, the current D-Bus "generic" GATT API does not enable/disable
notifications (it assumes it has been enabled by some other mean, e.g.
using gatttool). I had a patch to enable it when the first D-Bus
client was interested on a characteristic (disabling was not possible
yet), but it has not been submitted upstream (we are currently
focusing on the core API for profiles AKA "attio driver").
So, as of now, some application using the generic D-Bus API will not
affect the profile specific behavior, as it can only read/write
characteristic values, and watch for already enabled
notifications/indications.
> Because of any application can enable/disable characteristics we don't
> need to worry about to manage this in the Thermometer API. Remember
> that in other threads in the mailing list people were speaking about
> making a D-Bus API for GATT. Those applications using GATT could
> enable notification for measures and disable it. On account of this,
> it will be inevitable collisions in the use cases.
I think we should adopt a refcount like behavior for
notifications/indications, and bluez core should manage this. IOW,
applications registered over d-bus grab a counter, on the first ref()
the notification/indication is enabled on peer device, on last unref()
it is disabled.
My two cents,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
On Fri, Jun 24, 2011 at 6:20 AM, Elvis Pfutzenreuter <[email protected]> wrote:
>>> (cut)
>>
>> Coming back to this issue. I was just wondering that we may not need
>> worried about this issue because the same case may occurs at GATT
>> level. I mean, an application using GATT could disturb the behaviour
>> of other one when it enables/disables characteristics.
>
> Ok, but then the risk is clear. My feeling is that people are already
> "toning down" this API because of this. (One of the reasons my patch
> to add descriptor manipulation capability was rejected is that it was
> not meant to be a complete API and effort should go to profile-specific
> APIs. Without this, you can't toggle notifications and indications
> using generic GATT API anyway.)
>
>>
>> Because of any application can enable/disable characteristics we don't
>> need to worry about to manage this in the Thermometer API. Remember
>> that in other threads in the mailing list people were speaking about
>> making a D-Bus API for GATT. Those applications using GATT could
>> enable notification for measures and disable it. On account of this,
>> it will be inevitable collisions in the use cases.
>>
>> For this reason I think that the Thermometer API should be the most
>> permissive possible. If any application disable intermediate or final
>> measures, the PropertyChanged signal will be triggered, well, there is
>> no problem, if there are agents interested in such measures they only
>> will have to enable the proterty in the API once again as usual.
>
> I can see two apps monitoring PropertyChanged to enforce opposite
> states of notification. It would create a lot of heat.
>
>> To summarize, I think we should add the properties to enable and
>> disable intermediate and final measures and to leave to applications
>> to take deccisions about how they are going to behave when this stuff
>> happen.
>
> I remember Marcel saying once that applications always do the wrong
> thing when given the chance :) In this respect, our opinions are
> pretty much opposite; IMHO one application must not have a way to
> create a problem to others. Notification interval is impossible to
> insulate, for there is just one per device, but we can do better for
> toggling of notifications.
>
> It would be nice to have more opinions on this.
could we apply an 'OR' logic to this inside the profile? Each
application will have its own property setting.
So if App-A enables both, then it will receive both immediate/.final
temperatures indication/notification.
if App-B enables only final, then it receives final temperature indication only.
There are still the issue of how profile can "wake up" application(s)
when notification/indication come.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
>> (cut)
>
> Coming back to this issue. I was just wondering that we may not need
> worried about this issue because the same case may occurs at GATT
> level. I mean, an application using GATT could disturb the behaviour
> of other one when it enables/disables characteristics.
Ok, but then the risk is clear. My feeling is that people are already
"toning down" this API because of this. (One of the reasons my patch
to add descriptor manipulation capability was rejected is that it was
not meant to be a complete API and effort should go to profile-specific
APIs. Without this, you can't toggle notifications and indications
using generic GATT API anyway.)
>
> Because of any application can enable/disable characteristics we don't
> need to worry about to manage this in the Thermometer API. Remember
> that in other threads in the mailing list people were speaking about
> making a D-Bus API for GATT. Those applications using GATT could
> enable notification for measures and disable it. On account of this,
> it will be inevitable collisions in the use cases.
>
> For this reason I think that the Thermometer API should be the most
> permissive possible. If any application disable intermediate or final
> measures, the PropertyChanged signal will be triggered, well, there is
> no problem, if there are agents interested in such measures they only
> will have to enable the proterty in the API once again as usual.
I can see two apps monitoring PropertyChanged to enforce opposite
states of notification. It would create a lot of heat.
> To summarize, I think we should add the properties to enable and
> disable intermediate and final measures and to leave to applications
> to take deccisions about how they are going to behave when this stuff
> happen.
I remember Marcel saying once that applications always do the wrong
thing when given the chance :) In this respect, our opinions are
pretty much opposite; IMHO one application must not have a way to
create a problem to others. Notification interval is impossible to
insulate, for there is just one per device, but we can do better for
toggling of notifications.
It would be nice to have more opinions on this.
Hi,
(cut)
>> I mean the case when a process (it is not neccesary it has to be an
>> agent) is enabling intermediate and/or final notifications through
>> setProperty method in D-Bus API. Please, note that any process can do
>> this in current API because no extra control is done for this
>> operation.
>>
>> May be I'm misundertanding what you want to said with per-agent basis
>> but as far as I see the only way to manage enabling/disabling
>> properties in this way is by adding a new parameter in setProperty
>> method with the agent path and checkicng if it is already registered
>> before enabling or disabling intermediate and final notifications. IMO
>> If we do this we would break the BlueZ APIs where no extra parameters
>> are required in such methods. I'm not sure if this would be a problem
>> but I don't feel comfortable with this solution.
>>
>> On the other hands, if we discard adding the agent parameter in that
>> method (which I think that it fits better in BlueZ API), we can ignore
>> the case when there aren't any agents registered for the thermometer
>> service and a process enables some of this properties. In this case it
>> wouldn't be necessary to activate these properties since no one will
>> receive notifications for the measures.
>
> True, I did not remember that those were properties. They would have
> to go, otherwise it is too easy for an app to "break" another, by
> disabling notifications.
Coming back to this issue. I was just wondering that we may not need
worried about this issue because the same case may occurs at GATT
level. I mean, an application using GATT could disturb the behaviour
of other one when it enables/disables characteristics.
Because of any application can enable/disable characteristics we don't
need to worry about to manage this in the Thermometer API. Remember
that in other threads in the mailing list people were speaking about
making a D-Bus API for GATT. Those applications using GATT could
enable notification for measures and disable it. On account of this,
it will be inevitable collisions in the use cases.
For this reason I think that the Thermometer API should be the most
permissive possible. If any application disable intermediate or final
measures, the PropertyChanged signal will be triggered, well, there is
no problem, if there are agents interested in such measures they only
will have to enable the proterty in the API once again as usual.
To summarize, I think we should add the properties to enable and
disable intermediate and final measures and to leave to applications
to take deccisions about how they are going to behave when this stuff
happen.
Waiting for you comments before sending a new RFC.
Regards.
Hi,
2011/6/23 Elvis Pfutzenreuter <[email protected]>:
> On 22 Jun 2011, at 18:44 , mike tsai wrote:
>
>> Hi,
>>
>> On Wed, Jun 22, 2011 at 6:50 AM, Elvis Pfutzenreuter <[email protected]> wrote:
>>>>>> (cut)
>>>>>
>>>>> True, I did not remember that those were properties. They would have
>>>>> to go, otherwise it is too easy for an app to "break" another, by
>>>>> disabling notifications.
>>>>>
>>>>> A pair of Enable/DisableIntermediate methods taking an agent as
>>>>> parameter would be more adequate.
>>>>>
>>>>> IMHO there would not be a need of such
>>>>> methods for final measure, because the final measurement (which is
>>>>> the only one guaranteed to be precise) is the final objective, there
>>>>> is no point in registering an agent and not wanting a final measurement.
>>>>>
>>>>
>>>> They werent in this RFC. I only see a problem now, for example if an
>>>> agent wants to get only a single *final* measure without setting an
>>>> interval and after a while the same agents decides that it wants to
>>>> get a new single measure without setting an interval for periodic
>>>> measurements. I don't see how it could do this with current API (where
>>>> get final measure methods are not present).
>>>
>>> For that, having temperature as one of the properties would be great
>>> (allowing apps unable/unwilling to set up an agent to read it).
>>>
>>> Or setting a convention that, if you register an agent, a GATT read is
>>> fired and you get a measurement right after. (It seems that you said
>>> something in that direction below.) Disvantage is that registering
>>> and unregistering agents just to get 1 measurement would cycle
>>> GATT indications needlessly.
>>>
>>>> We could think that an agent is only registered during the time it is
>>>> interested in being notified about final measures, after that, it
>>>> should unregister itself from the service. In that scenario we can set
>>>> notify property for final measures each time an agent is registered
>>>> (if not periodic interval is already set).
>>>
>>> In terms of minimizing energy consumption and API methods, the 'best'
>>> would be:
>>>
>>> a) intermediate and final temperatures being properties (intermediate
>>> ? property is there only if thermometer supports it).
>>>
>>> b) There are GATT reads on them when some app reads the property;
>>>
>> [MT] Final temperature can only be indicated and intermediate
>> temperature can only be notified. Client can't read them from server,
>> according to the Thermometer profile spec.
>
> Glup, that is true :\
>
> In other profiles people are taking care of making notifiable
> characteristics readable as well, but it slipped for thermometer.
>
> In this case, the only reason one could argue using properties for
> temperatures would be to reuse the PropertyChanged for notifications
> and indications. BlueZ could store the last temperature locally,
> should some app wants it immediately. (The special IEEE FLOAT values
> take care of the case where a measurement hasn't been taken yet.)
I would prefer not to use properties for the measures for several
reasons. First of them is because of we should have to store the last
temperature locally, Sometimes the device does not include time stamp
in the measure because is not mandatory. if the device does not
support storing of data we should to include a timestamp because after
a while an application may want to read the last measure. That is not
severe but we are adding extra information to the data that it isn't
provided by the thermometer, IMO it seems a little ugly. The same case
for intermediate temperature.
On the other hands, a new PropertyChange signal would be triggered on
the bus each time a measure arrives, I think that it may be too heavy
specially in the case of intermediate measures where the rate of
updates is higher.
For above reasons I think that we should use a callback in the agent
side whenever it is possible.
>
>>
>>> c) those properties generate PropertyChanged signals only when
>>> notifications are enabled for one or another, or there was a GATT read;
>>>
>>> d) applications signal interest in notifications by registering
>>> an agent (or by some other way). Registering an agent automatically
>>> means interest in final temp notifications, an additional method
>>> enables/disables interest in intermediate temp notifications.
>>>
>> [MT] Once indication or notification is enabled, client has to be
>> ready to receive notification or indication as soon as the physical
>> link is established with the temperature sensor.
>
> Ok, but we can disable it when no agent is active, right?
Hi Elvis,
On Thu, Jun 23, 2011 at 7:08 AM, Elvis Pfutzenreuter <[email protected]> wrote:
> On 22 Jun 2011, at 18:44 , mike tsai wrote:
>
>> Hi,
>>
>> On Wed, Jun 22, 2011 at 6:50 AM, Elvis Pfutzenreuter <[email protected]> wrote:
>>>>>> (cut)
>>>>>
>>>>> True, I did not remember that those were properties. They would have
>>>>> to go, otherwise it is too easy for an app to "break" another, by
>>>>> disabling notifications.
>>>>>
>>>>> A pair of Enable/DisableIntermediate methods taking an agent as
>>>>> parameter would be more adequate.
>>>>>
>>>>> IMHO there would not be a need of such
>>>>> methods for final measure, because the final measurement (which is
>>>>> the only one guaranteed to be precise) is the final objective, there
>>>>> is no point in registering an agent and not wanting a final measurement.
>>>>>
>>>>
>>>> They werent in this RFC. I only see a problem now, for example if an
>>>> agent wants to get only a single *final* measure without setting an
>>>> interval and after a while the same agents decides that it wants to
>>>> get a new single measure without setting an interval for periodic
>>>> measurements. I don't see how it could do this with current API (where
>>>> get final measure methods are not present).
>>>
>>> For that, having temperature as one of the properties would be great
>>> (allowing apps unable/unwilling to set up an agent to read it).
>>>
>>> Or setting a convention that, if you register an agent, a GATT read is
>>> fired and you get a measurement right after. (It seems that you said
>>> something in that direction below.) Disvantage is that registering
>>> and unregistering agents just to get 1 measurement would cycle
>>> GATT indications needlessly.
>>>
>>>> We could think that an agent is only registered during the time it is
>>>> interested in being notified about final measures, after that, it
>>>> should unregister itself from the service. In that scenario we can set
>>>> notify property for final measures each time an agent is registered
>>>> (if not periodic interval is already set).
>>>
>>> In terms of minimizing energy consumption and API methods, the 'best'
>>> would be:
>>>
>>> a) intermediate and final temperatures being properties (intermediate
>>> ? property is there only if thermometer supports it).
>>>
>>> b) There are GATT reads on them when some app reads the property;
>>>
>> [MT] Final temperature can only be indicated and intermediate
>> temperature can only be notified. Client can't read them from server,
>> according to the Thermometer profile spec.
>
> Glup, that is true :\
>
> In other profiles people are taking care of making notifiable
> characteristics readable as well, but it slipped for thermometer.
>
> In this case, the only reason one could argue using properties for
> temperatures would be to reuse the PropertyChanged for notifications
> and indications. BlueZ could store the last temperature locally,
> should some app wants it immediately. (The special IEEE FLOAT values
> take care of the case where a measurement hasn't been taken yet.)
>
>>
>>> c) those properties generate PropertyChanged signals only when
>>> notifications are enabled for one or another, or there was a GATT read;
>>>
>>> d) applications signal interest in notifications by registering
>>> an agent (or by some other way). Registering an agent automatically
>>> means interest in final temp notifications, an additional method
>>> enables/disables interest in intermediate temp notifications.
>>>
>> [MT] Once indication or notification is enabled, client has to be
>> ready to receive notification or indication as soon as the physical
>> link is established with the temperature sensor.
>
> Ok, but we can disable it when no agent is active, right?
Actually, from "Health" thermometer profile point of view, the desire
processing should be like this.
Application registers with profile (or agent?)
Application decides to connect to thermometer, bond and enable
indication/notification(Profile shall return OK immediately if device
was bonded before)
Profile should add thermometer device into white list
Application disconnects thermometer
Application ends (user exits the application)
User press a button in Health thermometer sensor to measure the temperature
Thermometer starts directed connectable advertising, then indirected
connectable advertising
Profile does white list selective connection and connects to thermometer
thermometer sends intermediate temperature (if enabled) notification
Profile invokes application(s) and passes the intermediate temperature
Application processes the intermediate temperature (display as number
or draw a graphic)
Profile sends final measurement to application
User sees the data and ends the application
So, since the current architecture has thermometer profile as part of
bluetoothd, then it shall remember the registered application(s) and
invoke it(or them) automatically.
On 22 Jun 2011, at 18:44 , mike tsai wrote:
> Hi,
>
> On Wed, Jun 22, 2011 at 6:50 AM, Elvis Pfutzenreuter <[email protected]> wrote:
>>>>> (cut)
>>>>
>>>> True, I did not remember that those were properties. They would have
>>>> to go, otherwise it is too easy for an app to "break" another, by
>>>> disabling notifications.
>>>>
>>>> A pair of Enable/DisableIntermediate methods taking an agent as
>>>> parameter would be more adequate.
>>>>
>>>> IMHO there would not be a need of such
>>>> methods for final measure, because the final measurement (which is
>>>> the only one guaranteed to be precise) is the final objective, there
>>>> is no point in registering an agent and not wanting a final measurement.
>>>>
>>>
>>> They werent in this RFC. I only see a problem now, for example if an
>>> agent wants to get only a single *final* measure without setting an
>>> interval and after a while the same agents decides that it wants to
>>> get a new single measure without setting an interval for periodic
>>> measurements. I don't see how it could do this with current API (where
>>> get final measure methods are not present).
>>
>> For that, having temperature as one of the properties would be great
>> (allowing apps unable/unwilling to set up an agent to read it).
>>
>> Or setting a convention that, if you register an agent, a GATT read is
>> fired and you get a measurement right after. (It seems that you said
>> something in that direction below.) Disvantage is that registering
>> and unregistering agents just to get 1 measurement would cycle
>> GATT indications needlessly.
>>
>>> We could think that an agent is only registered during the time it is
>>> interested in being notified about final measures, after that, it
>>> should unregister itself from the service. In that scenario we can set
>>> notify property for final measures each time an agent is registered
>>> (if not periodic interval is already set).
>>
>> In terms of minimizing energy consumption and API methods, the 'best'
>> would be:
>>
>> a) intermediate and final temperatures being properties (intermediate
>> property is there only if thermometer supports it).
>>
>> b) There are GATT reads on them when some app reads the property;
>>
> [MT] Final temperature can only be indicated and intermediate
> temperature can only be notified. Client can't read them from server,
> according to the Thermometer profile spec.
Glup, that is true :\
In other profiles people are taking care of making notifiable
characteristics readable as well, but it slipped for thermometer.
In this case, the only reason one could argue using properties for
temperatures would be to reuse the PropertyChanged for notifications
and indications. BlueZ could store the last temperature locally,
should some app wants it immediately. (The special IEEE FLOAT values
take care of the case where a measurement hasn't been taken yet.)
>
>> c) those properties generate PropertyChanged signals only when
>> notifications are enabled for one or another, or there was a GATT read;
>>
>> d) applications signal interest in notifications by registering
>> an agent (or by some other way). Registering an agent automatically
>> means interest in final temp notifications, an additional method
>> enables/disables interest in intermediate temp notifications.
>>
> [MT] Once indication or notification is enabled, client has to be
> ready to receive notification or indication as soon as the physical
> link is established with the temperature sensor.
Ok, but we can disable it when no agent is active, right?
Hi all,
2011/6/22 mike tsai <[email protected]>:
> Hi,
>
> On Wed, Jun 22, 2011 at 6:50 AM, Elvis Pfutzenreuter <[email protected]> wrote:
>>>>> (cut)
>>>>
>>>> True, I did not remember that those were properties. They would have
>>>> to go, otherwise it is too easy for an app to "break" another, by
>>>> disabling notifications.
>>>>
>>>> A pair of Enable/DisableIntermediate methods taking an agent as
>>>> parameter would be more adequate.
>>>>
>>>> IMHO there would not be a need of such
>>>> methods for final measure, because the final measurement (which is
>>>> the only one guaranteed to be precise) is the final objective, there
>>>> is no point in registering an agent and not wanting a final measurement.
>>>>
>>>
>>> They werent in this RFC. I only see a problem now, for example if an
>>> agent wants to get only a single *final* measure without setting an
>>> interval and after a while the same agents decides that it wants to
>>> get a new single measure without setting an interval for periodic
>>> measurements. I don't see how it could do this with current API (where
>>> get final measure methods are not present).
>>
>> For that, having temperature as one of the properties would be great
>> (allowing apps unable/unwilling to set up an agent to read it).
>>
>> Or setting a convention that, if you register an agent, a GATT read is
>> fired and you get a measurement right after. (It seems that you said
>> something in that direction below.) Disvantage is that registering
>> and unregistering agents just to get 1 measurement would cycle
>> GATT indications needlessly.
>>
>>> We could think that an agent is only registered during the time it is
>>> interested in being notified about final measures, after that, it
>>> should unregister itself from the service. In that scenario we can set
>>> notify property for final measures each time an agent is registered
>>> (if not periodic interval is already set).
>>
>> In terms of minimizing energy consumption and API methods, the 'best'
>> would be:
>>
>> a) intermediate and final temperatures being properties (intermediate
>> ? property is there only if thermometer supports it).
>>
>> b) There are GATT reads on them when some app reads the property;
>>
> [MT] Final temperature can only be indicated and intermediate
> temperature can only be notified. Client can't read them from server,
> according to the Thermometer profile spec.
With reference to final measurement, I think that the best solution
may be a mix between previous RFC and this one. We could have a
feature "Final" that applications can enable through SetProperty
method. If some process change its value the proper signal is emmited
as usual. When the final measure arrived, the callack and
propertychange signal is emmited too indicating that its value has
changed from true to False and no more final measures will be scanned.
In this way, everybody could get final measures without have to set
periodic intervals.
Of course, we can ignore this action if some process set this property
and no watchers are registered. In this way we can save GATT traffic
and power consumption because in this case there are'nt agents
interested in getting measures.
>> c) those properties generate PropertyChanged signals only when
>> notifications are enabled for one or another, or there was a GATT read;
>>
>> d) applications signal interest in notifications by registering
>> an agent (or by some other way). Registering an agent automatically
>> means interest in final temp notifications, an additional method
>> enables/disables interest in intermediate temp notifications.
It seems a mix between both RFCs. What do you think if I prepare a new
API to send it to the mailing list during the day?
Regards
Hi,
On Wed, Jun 22, 2011 at 6:50 AM, Elvis Pfutzenreuter <[email protected]> wrote:
>>>> (cut)
>>>
>>> True, I did not remember that those were properties. They would have
>>> to go, otherwise it is too easy for an app to "break" another, by
>>> disabling notifications.
>>>
>>> A pair of Enable/DisableIntermediate methods taking an agent as
>>> parameter would be more adequate.
>>>
>>> IMHO there would not be a need of such
>>> methods for final measure, because the final measurement (which is
>>> the only one guaranteed to be precise) is the final objective, there
>>> is no point in registering an agent and not wanting a final measurement.
>>>
>>
>> They werent in this RFC. I only see a problem now, for example if an
>> agent wants to get only a single *final* measure without setting an
>> interval and after a while the same agents decides that it wants to
>> get a new single measure without setting an interval for periodic
>> measurements. I don't see how it could do this with current API (where
>> get final measure methods are not present).
>
> For that, having temperature as one of the properties would be great
> (allowing apps unable/unwilling to set up an agent to read it).
>
> Or setting a convention that, if you register an agent, a GATT read is
> fired and you get a measurement right after. (It seems that you said
> something in that direction below.) Disvantage is that registering
> and unregistering agents just to get 1 measurement would cycle
> GATT indications needlessly.
>
>> We could think that an agent is only registered during the time it is
>> interested in being notified about final measures, after that, it
>> should unregister itself from the service. In that scenario we can set
>> notify property for final measures each time an agent is registered
>> (if not periodic interval is already set).
>
> In terms of minimizing energy consumption and API methods, the 'best'
> would be:
>
> a) intermediate and final temperatures being properties (intermediate
> ? property is there only if thermometer supports it).
>
> b) There are GATT reads on them when some app reads the property;
>
[MT] Final temperature can only be indicated and intermediate
temperature can only be notified. Client can't read them from server,
according to the Thermometer profile spec.
> c) those properties generate PropertyChanged signals only when
> notifications are enabled for one or another, or there was a GATT read;
>
> d) applications signal interest in notifications by registering
> an agent (or by some other way). Registering an agent automatically
> means interest in final temp notifications, an additional method
> enables/disables interest in intermediate temp notifications.
>
[MT] Once indication or notification is enabled, client has to be
ready to receive notification or indication as soon as the physical
link is established with the temperature sensor.
> Main problem would be having a "toothless" agent. Looks funny.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
>>> (cut)
>>
>> True, I did not remember that those were properties. They would have
>> to go, otherwise it is too easy for an app to "break" another, by
>> disabling notifications.
>>
>> A pair of Enable/DisableIntermediate methods taking an agent as
>> parameter would be more adequate.
>>
>> IMHO there would not be a need of such
>> methods for final measure, because the final measurement (which is
>> the only one guaranteed to be precise) is the final objective, there
>> is no point in registering an agent and not wanting a final measurement.
>>
>
> They werent in this RFC. I only see a problem now, for example if an
> agent wants to get only a single *final* measure without setting an
> interval and after a while the same agents decides that it wants to
> get a new single measure without setting an interval for periodic
> measurements. I don't see how it could do this with current API (where
> get final measure methods are not present).
For that, having temperature as one of the properties would be great
(allowing apps unable/unwilling to set up an agent to read it).
Or setting a convention that, if you register an agent, a GATT read is
fired and you get a measurement right after. (It seems that you said
something in that direction below.) Disvantage is that registering
and unregistering agents just to get 1 measurement would cycle
GATT indications needlessly.
> We could think that an agent is only registered during the time it is
> interested in being notified about final measures, after that, it
> should unregister itself from the service. In that scenario we can set
> notify property for final measures each time an agent is registered
> (if not periodic interval is already set).
In terms of minimizing energy consumption and API methods, the 'best'
would be:
a) intermediate and final temperatures being properties (intermediate
property is there only if thermometer supports it).
b) There are GATT reads on them when some app reads the property;
c) those properties generate PropertyChanged signals only when
notifications are enabled for one or another, or there was a GATT read;
d) applications signal interest in notifications by registering
an agent (or by some other way). Registering an agent automatically
means interest in final temp notifications, an additional method
enables/disables interest in intermediate temp notifications.
Main problem would be having a "toothless" agent. Looks funny.
Hi,
2011/6/22 Elvis Pfutzenreuter <[email protected]>:
> On Jun 22, 2011, at 7:20 AM, Santiago Carot wrote:
>
>> Hi,
>>
>> 2011/6/21 Elvis Pfutzenreuter <[email protected]>:
>>> On Jun 21, 2011, at 12:56 PM, Santiago Carot wrote:
>>>
>>> (cut)
>>>
>>>>>
>>>>> Another option would be to guarantee that MeasureReceived() is called
>>>>> right after agent registering, in order to give the client an
>>>>> initial value to show (having in mind that notification interval might
>>>>> be very long).
>>>>
>>>> I would prefer to use the Final and Intermediate properties too. The
>>>> problem that we should address occurs when an application wich hasn't
>>>> got a watcher registered sets Intermediate or Final measurement
>>>> property and the last watcher is removed. I think that the best option
>>>> may be turn off measurments for power safe due that no watcher will
>>>> get the measures.
>>>
>>> I'm not sure I follow. Enabling intermediate and/or final notifications
>>> is done per-agent basis; if any of active agents needs intermediate
>>> measurements, device is configured to send them. Disabling it on one
>>> agent should not hurt another.
>>>
>>
>> I mean the case when a process (it is not neccesary it has to be an
>> agent) is enabling intermediate and/or final notifications through
>> setProperty method in D-Bus API. Please, note that any process can do
>> this in current API because no extra control is done for this
>> operation.
>>
>> May be I'm misundertanding what you want to said with per-agent basis
>> but as far as I see the only way to manage enabling/disabling
>> properties in this way is by adding a new parameter in setProperty
>> method with the agent path and checkicng if it is already registered
>> before enabling or disabling intermediate and final notifications. IMO
>> If we do this we would break the BlueZ APIs where no extra parameters
>> are required in such methods. I'm not sure if this would be a problem
>> but I don't feel comfortable with this solution.
>>
>> On the other hands, if we discard adding the agent parameter in that
>> method (which I think that it fits better in BlueZ API), we can ignore
>> the case when there aren't any agents registered for the thermometer
>> service and a process enables some of this properties. In this case it
>> wouldn't be necessary to activate these properties since no one will
>> receive notifications for the measures.
>
> True, I did not remember that those were properties. They would have
> to go, otherwise it is too easy for an app to "break" another, by
> disabling notifications.
>
> A pair of Enable/DisableIntermediate methods taking an agent as
> parameter would be more adequate.
>
> IMHO there would not be a need of such
> methods for final measure, because the final measurement (which is
> the only one guaranteed to be precise) is the final objective, there
> is no point in registering an agent and not wanting a final measurement.
>
They werent in this RFC. I only see a problem now, for example if an
agent wants to get only a single *final* measure without setting an
interval and after a while the same agents decides that it wants to
get a new single measure without setting an interval for periodic
measurements. I don't see how it could do this with current API (where
get final measure methods are not present).
We could think that an agent is only registered during the time it is
interested in being notified about final measures, after that, it
should unregister itself from the service. In that scenario we can set
notify property for final measures each time an agent is registered
(if not periodic interval is already set).
Any suggestion?
Regards.
On Jun 22, 2011, at 7:20 AM, Santiago Carot wrote:
> Hi,
>
> 2011/6/21 Elvis Pfutzenreuter <[email protected]>:
>> On Jun 21, 2011, at 12:56 PM, Santiago Carot wrote:
>>
>> (cut)
>>
>>>>
>>>> Another option would be to guarantee that MeasureReceived() is called
>>>> right after agent registering, in order to give the client an
>>>> initial value to show (having in mind that notification interval might
>>>> be very long).
>>>
>>> I would prefer to use the Final and Intermediate properties too. The
>>> problem that we should address occurs when an application wich hasn't
>>> got a watcher registered sets Intermediate or Final measurement
>>> property and the last watcher is removed. I think that the best option
>>> may be turn off measurments for power safe due that no watcher will
>>> get the measures.
>>
>> I'm not sure I follow. Enabling intermediate and/or final notifications
>> is done per-agent basis; if any of active agents needs intermediate
>> measurements, device is configured to send them. Disabling it on one
>> agent should not hurt another.
>>
>
> I mean the case when a process (it is not neccesary it has to be an
> agent) is enabling intermediate and/or final notifications through
> setProperty method in D-Bus API. Please, note that any process can do
> this in current API because no extra control is done for this
> operation.
>
> May be I'm misundertanding what you want to said with per-agent basis
> but as far as I see the only way to manage enabling/disabling
> properties in this way is by adding a new parameter in setProperty
> method with the agent path and checkicng if it is already registered
> before enabling or disabling intermediate and final notifications. IMO
> If we do this we would break the BlueZ APIs where no extra parameters
> are required in such methods. I'm not sure if this would be a problem
> but I don't feel comfortable with this solution.
>
> On the other hands, if we discard adding the agent parameter in that
> method (which I think that it fits better in BlueZ API), we can ignore
> the case when there aren't any agents registered for the thermometer
> service and a process enables some of this properties. In this case it
> wouldn't be necessary to activate these properties since no one will
> receive notifications for the measures.
True, I did not remember that those were properties. They would have
to go, otherwise it is too easy for an app to "break" another, by
disabling notifications.
A pair of Enable/DisableIntermediate methods taking an agent as
parameter would be more adequate.
IMHO there would not be a need of such
methods for final measure, because the final measurement (which is
the only one guaranteed to be precise) is the final objective, there
is no point in registering an agent and not wanting a final measurement.
So, inside the driver, final measurement indications are enabled if there
is at least one agent; and intermediate notifications are enabled if at
least one agent has requested it.
>
>>>
>>> We can change the API to do that. What do you think?
>>>
>>>
>>>>
>>>>> +
>>>>> +
>>>>> +Health Thermometer Watcher hierarchy
>>>>> +====================================
>>>>> +Service unique name
>>>>> +Interface org.bluez.ThermometerWatcher
>>>>> +Object path freely definable
>>>>> +
>>>>> +Methods void MeasureReceived(dict measure)
>>>>> +
>>>>> + This callback gets called when a measure has been
>>>>> + scanned in the thermometer. The Value entry corresponds
>>>>> + to IEEE-11073 32-bit FLOAT.The Time entry in the dict
>>>>> + will be only present if the device supports storing of
>>>>> + data. The time value is expressed in seconds since epoch.
>>>>
>>>> Using such a special type (FLOAT) looks funny. Not sure whether it is the best option
>>>> for this API.
>>>>
>>>> At the very least, a description of FLOAT type should be added to the API, since
>>>> IEEE 11073 specs are not public/free, and API users would have to resort to unofficial
>>>> source to learn it.
>>>>
>>>> I understand why you used this type (keeps the thermometer transcodable through this
>>>> API and there are the special values), so BTW the lack of device information service
>>>> access through this API should at least be mentioned, so we ammend that later (either
>>>> here or adding another API).
>>>
>>> ...or we can split the value in their exponent and mantissa
>>> components. Any suggestion?
>>
>> I'd go for that, but we need to take a look on special values to see if it makes sense.
>> It would be really ugly to say something like "if mantissa=5 and exponent=-3 then
>> temperature is actually zero" :)
>
> We could provide special values in the API so that end users can know
> when they are treating with those special cases. As far as I remember
> the only special cases are NaN, NRes, +INIFINITY, - INFINITY and RFU.
> Do you see anything else?
I think that these are all. Can't see a way to represent those special
values in a clean fashion. For the next RFC just include the mantissa/exponent
pairs related to them, and see if someone else complains.
Hi Elvis,
(cut)
>
> I understand why you used this type (keeps the thermometer transcodable through this
> API and there are the special values), so BTW the lack of device information service
> access through this API should at least be mentioned, so we ammend that later (either
> here or adding another API).
I don't forget the DIS issue but so far I think it's better address a
part of the problem, when we fix the thermomether API we must treat
this one. Let's split the problem in subproblems ;)
Regards.
Hi,
2011/6/21 Elvis Pfutzenreuter <[email protected]>:
> On Jun 21, 2011, at 12:56 PM, Santiago Carot wrote:
>
> (cut)
>
>>>
>>> Another option would be to guarantee that MeasureReceived() is called
>>> right after agent registering, in order to give the client an
>>> initial value to show (having in mind that notification interval might
>>> be very long).
>>
>> I would prefer to use the Final and Intermediate properties too. The
>> problem that we should address occurs when an application wich hasn't
>> got a watcher registered sets Intermediate or Final measurement
>> property and the last watcher is removed. I think that the best option
>> may be turn off measurments for power safe due that no watcher will
>> get the measures.
>
> I'm not sure I follow. Enabling intermediate and/or final notifications
> is done per-agent basis; if any of active agents needs intermediate
> measurements, device is configured to send them. Disabling it on one
> agent should not hurt another.
>
I mean the case when a process (it is not neccesary it has to be an
agent) is enabling intermediate and/or final notifications through
setProperty method in D-Bus API. Please, note that any process can do
this in current API because no extra control is done for this
operation.
May be I'm misundertanding what you want to said with per-agent basis
but as far as I see the only way to manage enabling/disabling
properties in this way is by adding a new parameter in setProperty
method with the agent path and checkicng if it is already registered
before enabling or disabling intermediate and final notifications. IMO
If we do this we would break the BlueZ APIs where no extra parameters
are required in such methods. I'm not sure if this would be a problem
but I don't feel comfortable with this solution.
On the other hands, if we discard adding the agent parameter in that
method (which I think that it fits better in BlueZ API), we can ignore
the case when there aren't any agents registered for the thermometer
service and a process enables some of this properties. In this case it
wouldn't be necessary to activate these properties since no one will
receive notifications for the measures.
>>
>> We can change the API to do that. What do you think?
>>
>>
>>>
>>>> +
>>>> +
>>>> +Health Thermometer Watcher hierarchy
>>>> +====================================
>>>> +Service ? ? ? ? ? ? ?unique name
>>>> +Interface ? ?org.bluez.ThermometerWatcher
>>>> +Object path ?freely definable
>>>> +
>>>> +Methods ? ? ? ? ? ? ?void MeasureReceived(dict measure)
>>>> +
>>>> + ? ? ? ? ? ? ? ? ? ? This callback gets called when a measure has been
>>>> + ? ? ? ? ? ? ? ? ? ? scanned in the thermometer. The Value entry corresponds
>>>> + ? ? ? ? ? ? ? ? ? ? to IEEE-11073 32-bit FLOAT.The Time entry in the dict
>>>> + ? ? ? ? ? ? ? ? ? ? will be only present if the device supports storing of
>>>> + ? ? ? ? ? ? ? ? ? ? data. The time value is expressed in seconds since epoch.
>>>
>>> Using such a special type (FLOAT) looks funny. Not sure whether it is the best option
>>> for this API.
>>>
>>> At the very least, a description of FLOAT type should be added to the API, since
>>> IEEE 11073 specs are not public/free, and API users would have to resort to unofficial
>>> source to learn it.
>>>
>>> I understand why you used this type (keeps the thermometer transcodable through this
>>> API and there are the special values), so BTW the lack of device information service
>>> access through this API should at least be mentioned, so we ammend that later (either
>>> here or adding another API).
>>
>> ...or we can split the value in their exponent and mantissa
>> components. Any suggestion?
>
> I'd go for that, but we need to take a look on special values to see if it makes sense.
> It would be really ugly to say something like "if mantissa=5 and exponent=-3 then
> temperature is actually zero" :)
We could provide special values in the API so that end users can know
when they are treating with those special cases. As far as I remember
the only special cases are NaN, NRes, +INIFINITY, - INFINITY and RFU.
Do you see anything else?
Waiting for comments
Regards.
On Jun 21, 2011, at 12:56 PM, Santiago Carot wrote:
(cut)
>>
>> Another option would be to guarantee that MeasureReceived() is called
>> right after agent registering, in order to give the client an
>> initial value to show (having in mind that notification interval might
>> be very long).
>
> I would prefer to use the Final and Intermediate properties too. The
> problem that we should address occurs when an application wich hasn't
> got a watcher registered sets Intermediate or Final measurement
> property and the last watcher is removed. I think that the best option
> may be turn off measurments for power safe due that no watcher will
> get the measures.
I'm not sure I follow. Enabling intermediate and/or final notifications
is done per-agent basis; if any of active agents needs intermediate
measurements, device is configured to send them. Disabling it on one
agent should not hurt another.
>
> We can change the API to do that. What do you think?
>
>
>>
>>> +
>>> +
>>> +Health Thermometer Watcher hierarchy
>>> +====================================
>>> +Service unique name
>>> +Interface org.bluez.ThermometerWatcher
>>> +Object path freely definable
>>> +
>>> +Methods void MeasureReceived(dict measure)
>>> +
>>> + This callback gets called when a measure has been
>>> + scanned in the thermometer. The Value entry corresponds
>>> + to IEEE-11073 32-bit FLOAT.The Time entry in the dict
>>> + will be only present if the device supports storing of
>>> + data. The time value is expressed in seconds since epoch.
>>
>> Using such a special type (FLOAT) looks funny. Not sure whether it is the best option
>> for this API.
>>
>> At the very least, a description of FLOAT type should be added to the API, since
>> IEEE 11073 specs are not public/free, and API users would have to resort to unofficial
>> source to learn it.
>>
>> I understand why you used this type (keeps the thermometer transcodable through this
>> API and there are the special values), so BTW the lack of device information service
>> access through this API should at least be mentioned, so we ammend that later (either
>> here or adding another API).
>
> ...or we can split the value in their exponent and mantissa
> components. Any suggestion?
I'd go for that, but we need to take a look on special values to see if it makes sense.
It would be really ugly to say something like "if mantissa=5 and exponent=-3 then
temperature is actually zero" :)
Hello Elvis,
2011/6/21 Elvis Pfutzenreuter <[email protected]>:
>
> On Jun 21, 2011, at 10:03 AM, Santiago Carot-Nemesio wrote:
>
>> ---
>> doc/thermometer.txt | ?111 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 111 insertions(+), 0 deletions(-)
>> create mode 100644 doc/thermometer.txt
>>
>> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
>> new file mode 100644
>> index 0000000..4635fdf
>> --- /dev/null
>> +++ b/doc/thermometer.txt
>> @@ -0,0 +1,111 @@
>> +BlueZ D-Bus Thermomether API description
>> +****************************************
>> +
>> + ? ? Santiago Carot-Nemesio <[email protected]>
>> +
>> +Health Thermomether Profile hierarchy
>> +=====================================
>> +
>> +Service ? ? ? ? ? ? ?org.bluez
>> +Interface ? ?org.bluez.Thermometer
>> +Object path ?[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
>> +
>> +
>> +Methods ? ? ? ? ? ? ?void SetProperty(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? Changes the value of the specified property. Only
>> + ? ? ? ? ? ? ? ? ? ? read-write properties can be changed. On success
>> + ? ? ? ? ? ? ? ? ? ? this will emit a PropertyChanged signal.
>> +
>> + ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> + ? ? ? ? ? ? dict GetProperties()
>> +
>> + ? ? ? ? ? ? ? ? ? ? Returns all properties for the interface. See the
>> + ? ? ? ? ? ? ? ? ? ? Properties section for the available properties.
>> +
>> + ? ? ? ? ? ? RegisterThermometerWatcher(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? Register a watcher to monitor scanned measures.
>> +
>> + ? ? ? ? ? ? ? ? ? ? The agent registered for the health thermometer
>> + ? ? ? ? ? ? ? ? ? ? service will be notified about measures scanned.
>> +
>> + ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> +
>> + ? ? ? ? ? ? UnregisterThermometerWatcher(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? Unregister a watcher.
>> +
>> + ? ? ? ? ? ? ? ? ? ? Final and intermediate temperatures won't be notified to
>> + ? ? ? ? ? ? ? ? ? ? the agent any more.
>> +
>> + ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
>> +
>> + ? ? ? ? ? ? EnableIntermediateMeasures(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? Enable notifications about intermediate measures. Agent
>> + ? ? ? ? ? ? ? ? ? ? should have registered a watcher for health thermometer
>> + ? ? ? ? ? ? ? ? ? ? service before to enable this feature.
>> +
>> + ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotAllowed
>> +
>> + ? ? ? ? ? ? DisableIntermediateMeasures(object agent)
>> +
>> + ? ? ? ? ? ? ? ? ? ? Disable intermediate temperatures. It will disable
>> + ? ? ? ? ? ? ? ? ? ? intermediate measure notifications in the device when
>> + ? ? ? ? ? ? ? ? ? ? the last agent disables this feature.
>> +
>> + ? ? ? ? ? ? ? ? ? ? Possible Errors: org.bluez.Error.InvalidArguments
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? org.bluez.Error.NotFound
>
> Not sure whether there is a need to have these. Out of simplicity we could just
> accept that intermediate temperatures will be notified, if the thermometer
> provides this feature.
>
> In the other hand, a good reason to keep this would be saving energy when
> intermediate measures are not needed. LE profiles to into great lengths to
> save a couple bytes of traffic (literally).
That's the reason which I put them in the API but I was just wondering
if we could use the Final and Intermediate properties for that as you
suggest below.
>
>> +
>> +Signals ? ? ? ? ? ? ?PropertyChanged(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? This signal indicates a changed value of the given
>> + ? ? ? ? ? ? ? ? ? ? property.
>> +
>> +Properties ? uint16 Interval (optional) [readwrite]
>> +
>> + ? ? ? ? ? ? ? ? ? ? The Measurement Interval defines the time (in seconds)
>> + ? ? ? ? ? ? ? ? ? ? between measurements. This interval is not related to
>> + ? ? ? ? ? ? ? ? ? ? the intermediates measures and must be defined into
>> + ? ? ? ? ? ? ? ? ? ? a valid range. Setting it to zero meaning that no
>> + ? ? ? ? ? ? ? ? ? ? periodic measurements will be taken.
>> +
>> + ? ? ? ? ? ? uint16 Minimum (optional) [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? Defines the maximum value allowed for the interval
>> + ? ? ? ? ? ? ? ? ? ? between periodic measurements.
>> +
>> + ? ? ? ? ? ? uint16 Maximum (optional) [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? Defines the minimuum value allowed for the interval
>> + ? ? ? ? ? ? ? ? ? ? between periodic measurements.
>
> I would still like to have temperature (final and intermediate) among properties
> so an app could read them out without having to register an agent, either to
> take a single measurement or to update display upon loading. (That's why
> the respective GATT characteristics support read along with notification.)
> Reading the property provokes actual characteristic reading.
>
> Disvantage: generating PropertyChanged signals along with agent calls, which
> puts the usefulness of the agent into question.
>
> Another option would be to guarantee that MeasureReceived() is called
> right after agent registering, in order to give the client an
> initial value to show (having in mind that notification interval might
> be very long).
I would prefer to use the Final and Intermediate properties too. The
problem that we should address occurs when an application wich hasn't
got a watcher registered sets Intermediate or Final measurement
property and the last watcher is removed. I think that the best option
may be turn off measurments for power safe due that no watcher will
get the measures.
We can change the API to do that. What do you think?
>
>> +
>> +
>> +Health Thermometer Watcher hierarchy
>> +====================================
>> +Service ? ? ? ? ? ? ?unique name
>> +Interface ? ?org.bluez.ThermometerWatcher
>> +Object path ?freely definable
>> +
>> +Methods ? ? ? ? ? ? ?void MeasureReceived(dict measure)
>> +
>> + ? ? ? ? ? ? ? ? ? ? This callback gets called when a measure has been
>> + ? ? ? ? ? ? ? ? ? ? scanned in the thermometer. The Value entry corresponds
>> + ? ? ? ? ? ? ? ? ? ? to IEEE-11073 32-bit FLOAT.The Time entry in the dict
>> + ? ? ? ? ? ? ? ? ? ? will be only present if the device supports storing of
>> + ? ? ? ? ? ? ? ? ? ? data. The time value is expressed in seconds since epoch.
>
> Using such a special type (FLOAT) looks funny. Not sure whether it is the best option
> for this API.
>
> At the very least, a description of FLOAT type should be added to the API, since
> IEEE 11073 specs are not public/free, and API users would have to resort to unofficial
> source to learn it.
>
> I understand why you used this type (keeps the thermometer transcodable through this
> API and there are the special values), so BTW the lack of device information service
> access through this API should at least be mentioned, so we ammend that later (either
> here or adding another API).
...or we can split the value in their exponent and mantissa
components. Any suggestion?
>
>> +
>> + ? ? ? ? ? ? ? ? ? ? Dict is defined as below:
>> + ? ? ? ? ? ? ? ? ? ? {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Value" : uint32,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Unit" : ("Celsius" or "Fahrenheit"),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Time" : uint64,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Type" : ("Armpit", "Body", "Ear", "Finger",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Intestines", "Mouth", "Rectum", "Toe",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Tympanum"),
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Measurement" : ("Final" or "Intermediate"),
>> + ? ? ? ? ? ? ? ? ? ? }
>> --
>> 1.7.5.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
>
On Jun 21, 2011, at 10:03 AM, Santiago Carot-Nemesio wrote:
> ---
> doc/thermometer.txt | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 111 insertions(+), 0 deletions(-)
> create mode 100644 doc/thermometer.txt
>
> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
> new file mode 100644
> index 0000000..4635fdf
> --- /dev/null
> +++ b/doc/thermometer.txt
> @@ -0,0 +1,111 @@
> +BlueZ D-Bus Thermomether API description
> +****************************************
> +
> + Santiago Carot-Nemesio <[email protected]>
> +
> +Health Thermomether Profile hierarchy
> +=====================================
> +
> +Service org.bluez
> +Interface org.bluez.Thermometer
> +Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
> +
> +
> +Methods void SetProperty(string name, variant value)
> +
> + Changes the value of the specified property. Only
> + read-write properties can be changed. On success
> + this will emit a PropertyChanged signal.
> +
> + Possible Errors: org.bluez.Error.InvalidArguments
> +
> + dict GetProperties()
> +
> + Returns all properties for the interface. See the
> + Properties section for the available properties.
> +
> + RegisterThermometerWatcher(object agent)
> +
> + Register a watcher to monitor scanned measures.
> +
> + The agent registered for the health thermometer
> + service will be notified about measures scanned.
> +
> + Possible Errors: org.bluez.Error.InvalidArguments
> +
> + UnregisterThermometerWatcher(object agent)
> +
> + Unregister a watcher.
> +
> + Final and intermediate temperatures won't be notified to
> + the agent any more.
> +
> + Possible Errors: org.bluez.Error.InvalidArguments
> + org.bluez.Error.NotFound
> +
> + EnableIntermediateMeasures(object agent)
> +
> + Enable notifications about intermediate measures. Agent
> + should have registered a watcher for health thermometer
> + service before to enable this feature.
> +
> + Possible Errors: org.bluez.Error.InvalidArguments
> + org.bluez.Error.NotAllowed
> +
> + DisableIntermediateMeasures(object agent)
> +
> + Disable intermediate temperatures. It will disable
> + intermediate measure notifications in the device when
> + the last agent disables this feature.
> +
> + Possible Errors: org.bluez.Error.InvalidArguments
> + org.bluez.Error.NotFound
Not sure whether there is a need to have these. Out of simplicity we could just
accept that intermediate temperatures will be notified, if the thermometer
provides this feature.
In the other hand, a good reason to keep this would be saving energy when
intermediate measures are not needed. LE profiles to into great lengths to
save a couple bytes of traffic (literally).
> +
> +Signals PropertyChanged(string name, variant value)
> +
> + This signal indicates a changed value of the given
> + property.
> +
> +Properties uint16 Interval (optional) [readwrite]
> +
> + The Measurement Interval defines the time (in seconds)
> + between measurements. This interval is not related to
> + the intermediates measures and must be defined into
> + a valid range. Setting it to zero meaning that no
> + periodic measurements will be taken.
> +
> + uint16 Minimum (optional) [readonly]
> +
> + Defines the maximum value allowed for the interval
> + between periodic measurements.
> +
> + uint16 Maximum (optional) [readonly]
> +
> + Defines the minimuum value allowed for the interval
> + between periodic measurements.
I would still like to have temperature (final and intermediate) among properties
so an app could read them out without having to register an agent, either to
take a single measurement or to update display upon loading. (That's why
the respective GATT characteristics support read along with notification.)
Reading the property provokes actual characteristic reading.
Disvantage: generating PropertyChanged signals along with agent calls, which
puts the usefulness of the agent into question.
Another option would be to guarantee that MeasureReceived() is called
right after agent registering, in order to give the client an
initial value to show (having in mind that notification interval might
be very long).
> +
> +
> +Health Thermometer Watcher hierarchy
> +====================================
> +Service unique name
> +Interface org.bluez.ThermometerWatcher
> +Object path freely definable
> +
> +Methods void MeasureReceived(dict measure)
> +
> + This callback gets called when a measure has been
> + scanned in the thermometer. The Value entry corresponds
> + to IEEE-11073 32-bit FLOAT.The Time entry in the dict
> + will be only present if the device supports storing of
> + data. The time value is expressed in seconds since epoch.
Using such a special type (FLOAT) looks funny. Not sure whether it is the best option
for this API.
At the very least, a description of FLOAT type should be added to the API, since
IEEE 11073 specs are not public/free, and API users would have to resort to unofficial
source to learn it.
I understand why you used this type (keeps the thermometer transcodable through this
API and there are the special values), so BTW the lack of device information service
access through this API should at least be mentioned, so we ammend that later (either
here or adding another API).
> +
> + Dict is defined as below:
> + {
> + "Value" : uint32,
> + "Unit" : ("Celsius" or "Fahrenheit"),
> + "Time" : uint64,
> + "Type" : ("Armpit", "Body", "Ear", "Finger",
> + "Intestines", "Mouth", "Rectum", "Toe",
> + "Tympanum"),
> + "Measurement" : ("Final" or "Intermediate"),
> + }
> --
> 1.7.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi all,
2011/6/20 Anderson Lizardo <[email protected]>:
> Hi,
>
> On Mon, Jun 20, 2011 at 7:45 AM, Elvis Pfutzenreuter <[email protected]> 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.
Ok, I think the agent style API will fit better with multi-user use
cases. I'm going to work in these changes and I'll submit a new patch
when it's ready.
Regards.
Hi,
On Mon, Jun 20, 2011 at 7:45 AM, Elvis Pfutzenreuter <[email protected]> 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
Hi Santiago,
On Jun 20, 2011, at 6:07 AM, Santiago Carot-Nemesio wrote:
> ---
> doc/thermometer.txt | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 101 insertions(+), 0 deletions(-)
> create mode 100644 doc/thermometer.txt
>
> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
> new file mode 100644
> index 0000000..9d74403
> --- /dev/null
> +++ b/doc/thermometer.txt
> @@ -0,0 +1,101 @@
> +BlueZ D-Bus Thermomether API description
> +****************************************
> +
> + Santiago Carot-Nemesio <[email protected]>
> +
> +Health Thermomether Profile hierarchy
> +=====================================
> +
> +Service org.bluez
> +Interface org.bluez.Thermometer
> +Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
> +
> +
> +Methods void SetProperty(string name, variant value)
> +
> + Changes the value of the specified property. Only
> + read-write properties can be changed. On success
> + this will emit a PropertyChanged signal.
> +
> + dict GetProperties()
> +
> + Returns all properties for the interface. See the
> + Properties section for the available properties.
> +
> +Signals PropertyChanged(string name, variant value)
> +
> + This signal indicates a changed value of the given
> + property.
> +
> + 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.
> + }
> + "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.
Another option would be to create some kind of handle, like HealthApplication,
that allows BlueZ to detect when the client app is gone. That would avoid creating
another agent API and PropertyChanged signal would be emitted when there is at
least one interested party.
> +
> +Properties boolean Enable [readwrite]
> +
> + Switch notification of a measure on or off.
> +
> + boolean Intermediate (optional) [readwrite]
> +
> + Switch notification of intermediates measures on or off.
Those would go if agent was used.
> +
> + uint16 Interval (optional) [readwrite]
> +
> + The Measurement Interval defines the time (in seconds)
> + between measurements. This interval is not related to
> + the intermediates measures and must be defined into
> + a valid range. Setting it to zero meaning that no
> + periodic measurements will be taken.
> +
> + dict Range (optional) [readonly]
> +
> + Defines the valid range for the interval between
> + periodic measurements.
> +
> + Dict is defined as below:
> + {
> + "Minimum" : uint16,
> + "Maximum" : uint16,
> + }
I'd go for two properties: MinimumInterval and MaximumInterval, or some like that.
> +
> + uint8 Type (optional) [readonly]
> +
> + Describes the type of the temperature measurement in
> + relation to the thermometer location. If this property
> + is present, the measure type won't be provided with the
> + measure received signal. The value corresponds to the
> + descriptions used in ISO/IEEE 11073-10408-2008.
> + Possible values:
> + 0 -> Reserved for future use
> + 1 -> Armpit
> + 2 -> Body (general)
> + 3 -> Ear (usually lobe)
> + 4 -> Finger
> + 5 -> Gastro-intestinal Tract
> + 6 -> Mouth
> + 7 -> Rectum
> + 8 -> Toe
> + 9 -> Tympanum (ear drum)
> + 10-255 -> Reserved for future use
Regardless of signal/agent discussion, there should be Temperature and Intermediate
Temperature properties. If intermediate temp property does not show, this implicitly
means that thermometer does not support it.
All notifiable characteristics of thermometer are also readable; this allows an app
to update its screen and state immediately. (Imagine a thermometer that takes samples
once every 240 seconds.)
> --
> 1.7.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
We have the issue of Device Information Servce. In order to be transcodable to IEEE
11073, the API must include Device Information Service data.
We have two options:
a) Adding DIS this very API, making it feature-complete and 1:1 with health
thermometer profile, but that would have to be replicated for every LE health device
API, because every one will have DIS, too.
b) Adding a separate DIS API. This is 'cleaner' and avoids duplication (at
documentation level at least; internally, it could just forward calls to a
single DIS plug-in). But then e.g. the Thermometer API is not 1:1 with profile,
you need that API plus DIS API to cover the whole profile.
Hi Luiz
2011/6/20 Luiz Augusto von Dentz <[email protected]>:
> Hi,
>
> On Mon, Jun 20, 2011 at 12:07 PM, Santiago Carot-Nemesio
> <[email protected]> wrote:
>> ---
>> ?doc/thermometer.txt | ?101 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> ?1 files changed, 101 insertions(+), 0 deletions(-)
>> ?create mode 100644 doc/thermometer.txt
>>
>> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
>> new file mode 100644
>> index 0000000..9d74403
>> --- /dev/null
>> +++ b/doc/thermometer.txt
>> @@ -0,0 +1,101 @@
>> +BlueZ D-Bus Thermomether API description
>> +****************************************
>> +
>> + ? ? ? Santiago Carot-Nemesio <[email protected]>
>> +
>> +Health Thermomether Profile hierarchy
>> +=====================================
>> +
>> +Service ? ? ? ? ? ? ? ?org.bluez
>> +Interface ? ? ?org.bluez.Thermometer
>> +Object path ? ?[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
>> +
>> +
>> +Methods ? ? ? ?void SetProperty(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Changes the value of the specified property. Only
>> + ? ? ? ? ? ? ? ? ? ? ? read-write properties can be changed. On success
>> + ? ? ? ? ? ? ? ? ? ? ? this will emit a PropertyChanged signal.
>> +
>> + ? ? ? ? ? ? ? dict GetProperties()
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Returns all properties for the interface. See the
>> + ? ? ? ? ? ? ? ? ? ? ? Properties section for the available properties.
>> +
>> +Signals ? ? ? ? ? ? ? ?PropertyChanged(string name, variant value)
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? This signal indicates a changed value of the given
>> + ? ? ? ? ? ? ? ? ? ? ? property.
>> +
>> + ? ? ? ? ? ? ? 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
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
>
> I would try not got past the Dict, so the Time we could just use a timestamp.
I did it thinking in ISO/IEEE11073-20601 integration. Personal health
devices transcoding whitepaper talk about it. Transcoder components
should get this information when it is present to compose the
appropriate APDUs to use this kind of devices in a 20601 ecosystem. I
though that providing the time fields through a dict makes easy for
both kind of application (20601 compatible applications and non-20601
compatible ones) get the time and make the appropriate internal
representation. I do not oppose your proposal if we can get all these
information from the time stamp too.
so no problem to me.
>
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Type" : uint8,
>
> Hmm, what values can Type assume? Also be aware that D-Bus don't have
> enum type so it is a bit inconvenient in some bindings, so perhaps we
> should try to avoid them and always convert to human readable string.
I don't recommend it because type is defined by the upper layer
protocol so I wouldn't do that thinking in the maintainability. The
Type values may change (adding or removing new ones) in the IEEE
specification so we should constantly update this stuff whenever the
upper protocol changes to fullfil with that specification which IMO is
out of Bluetooth scope. I suggest to keep indepence between both
worlds.
>
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Measurement" : ("Final", "Intermediate")
>> + ? ? ? ? ? ? ? ? ? ? ? }
>> +
>> +Properties ? ? boolean Enable [readwrite]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Switch notification of a measure on or off.
>> +
>> + ? ? ? ? ? ? ? boolean Intermediate (optional) [readwrite]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Switch notification of intermediates measures on or off.
>> +
>> + ? ? ? ? ? ? ? uint16 Interval (optional) [readwrite]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? The Measurement Interval defines the time (in seconds)
>> + ? ? ? ? ? ? ? ? ? ? ? between measurements. This interval is not related to
>> + ? ? ? ? ? ? ? ? ? ? ? the intermediates measures and must be defined into
>> + ? ? ? ? ? ? ? ? ? ? ? a valid range. Setting it to zero meaning that no
>> + ? ? ? ? ? ? ? ? ? ? ? periodic measurements will be taken.
>> +
>> + ? ? ? ? ? ? ? dict Range (optional) [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Defines the valid range for the interval between
>> + ? ? ? ? ? ? ? ? ? ? ? periodic measurements.
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Dict is defined as below:
>> + ? ? ? ? ? ? ? ? ? ? ? {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Minimum" : uint16,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Maximum" : uint16,
>> + ? ? ? ? ? ? ? ? ? ? ? }
>
> I guess we can just use them directly as properties.
I considered it too but at the end I choose the dict way thinking that
Range is a property by itself with minimum and maximum values. But we
can split in two properties if all you think that it fits better in
the API.
>
>> +
>> + ? ? ? ? ? ? ? uint8 Type (optional) [readonly]
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? Describes the type of the temperature measurement in
>> + ? ? ? ? ? ? ? ? ? ? ? relation to the thermometer location. If this property
>> + ? ? ? ? ? ? ? ? ? ? ? is present, the measure type won't be provided with the
>> + ? ? ? ? ? ? ? ? ? ? ? measure received signal. The value corresponds to the
>> + ? ? ? ? ? ? ? ? ? ? ? descriptions used in ISO/IEEE 11073-10408-2008.
>> + ? ? ? ? ? ? ? ? ? ? ? Possible values:
>> + ? ? ? ? ? ? ? ? ? ? ? 0 -> Reserved for future use
>> + ? ? ? ? ? ? ? ? ? ? ? 1 -> Armpit
>> + ? ? ? ? ? ? ? ? ? ? ? 2 -> Body (general)
>> + ? ? ? ? ? ? ? ? ? ? ? 3 -> Ear (usually lobe)
>> + ? ? ? ? ? ? ? ? ? ? ? 4 -> Finger
>> + ? ? ? ? ? ? ? ? ? ? ? 5 -> Gastro-intestinal Tract
>> + ? ? ? ? ? ? ? ? ? ? ? 6 -> Mouth
>> + ? ? ? ? ? ? ? ? ? ? ? 7 -> Rectum
>> + ? ? ? ? ? ? ? ? ? ? ? 8 -> Toe
>> + ? ? ? ? ? ? ? ? ? ? ? 9 -> Tympanum (ear drum)
>> + ? ? ? ? ? ? ? ? ? ? ? 10-255 -> Reserved for future use
>
> Not sure why you need MeasureReceived and PropertyChanged here, I
> would use one or another but not both to avoid possible
> inconsistencies.
The idea is that there may be two kinds of thermometers. Static ones
wich are designed for a kind of measurement and non-static ones wich
can be used in different locations. From application side, wherever a
device provides this property is due that it only will provide static
measures so it doesn't need to provide it in all measures scanned (to
keep bandwich), if this property is not present is because of it can
scan for measures in several places and it will provide this
information to you when the measure arrives.
We can remove this roperty from the API if it is confused and always
provide this information in the MeasureReceived signal. It looks fine
to me too.
Thanks for your comments, they are very appreciated.
Let's wait for more suggestions. I'll send other patch including the
changes if nobody says anything about the API in next days.
Regards.
Hi,
On Mon, Jun 20, 2011 at 12:07 PM, Santiago Carot-Nemesio
<[email protected]> wrote:
> ---
> ?doc/thermometer.txt | ?101 +++++++++++++++++++++++++++++++++++++++++++++++++++
> ?1 files changed, 101 insertions(+), 0 deletions(-)
> ?create mode 100644 doc/thermometer.txt
>
> diff --git a/doc/thermometer.txt b/doc/thermometer.txt
> new file mode 100644
> index 0000000..9d74403
> --- /dev/null
> +++ b/doc/thermometer.txt
> @@ -0,0 +1,101 @@
> +BlueZ D-Bus Thermomether API description
> +****************************************
> +
> + ? ? ? Santiago Carot-Nemesio <[email protected]>
> +
> +Health Thermomether Profile hierarchy
> +=====================================
> +
> +Service ? ? ? ? ? ? ? ?org.bluez
> +Interface ? ? ?org.bluez.Thermometer
> +Object path ? ?[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
> +
> +
> +Methods ? ? ? ?void SetProperty(string name, variant value)
> +
> + ? ? ? ? ? ? ? ? ? ? ? Changes the value of the specified property. Only
> + ? ? ? ? ? ? ? ? ? ? ? read-write properties can be changed. On success
> + ? ? ? ? ? ? ? ? ? ? ? this will emit a PropertyChanged signal.
> +
> + ? ? ? ? ? ? ? dict GetProperties()
> +
> + ? ? ? ? ? ? ? ? ? ? ? Returns all properties for the interface. See the
> + ? ? ? ? ? ? ? ? ? ? ? Properties section for the available properties.
> +
> +Signals ? ? ? ? ? ? ? ?PropertyChanged(string name, variant value)
> +
> + ? ? ? ? ? ? ? ? ? ? ? This signal indicates a changed value of the given
> + ? ? ? ? ? ? ? ? ? ? ? property.
> +
> + ? ? ? ? ? ? ? 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
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
I would try not got past the Dict, so the Time we could just use a timestamp.
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Type" : uint8,
Hmm, what values can Type assume? Also be aware that D-Bus don't have
enum type so it is a bit inconvenient in some bindings, so perhaps we
should try to avoid them and always convert to human readable string.
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Measurement" : ("Final", "Intermediate")
> + ? ? ? ? ? ? ? ? ? ? ? }
> +
> +Properties ? ? boolean Enable [readwrite]
> +
> + ? ? ? ? ? ? ? ? ? ? ? Switch notification of a measure on or off.
> +
> + ? ? ? ? ? ? ? boolean Intermediate (optional) [readwrite]
> +
> + ? ? ? ? ? ? ? ? ? ? ? Switch notification of intermediates measures on or off.
> +
> + ? ? ? ? ? ? ? uint16 Interval (optional) [readwrite]
> +
> + ? ? ? ? ? ? ? ? ? ? ? The Measurement Interval defines the time (in seconds)
> + ? ? ? ? ? ? ? ? ? ? ? between measurements. This interval is not related to
> + ? ? ? ? ? ? ? ? ? ? ? the intermediates measures and must be defined into
> + ? ? ? ? ? ? ? ? ? ? ? a valid range. Setting it to zero meaning that no
> + ? ? ? ? ? ? ? ? ? ? ? periodic measurements will be taken.
> +
> + ? ? ? ? ? ? ? dict Range (optional) [readonly]
> +
> + ? ? ? ? ? ? ? ? ? ? ? Defines the valid range for the interval between
> + ? ? ? ? ? ? ? ? ? ? ? periodic measurements.
> +
> + ? ? ? ? ? ? ? ? ? ? ? Dict is defined as below:
> + ? ? ? ? ? ? ? ? ? ? ? {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Minimum" : uint16,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "Maximum" : uint16,
> + ? ? ? ? ? ? ? ? ? ? ? }
I guess we can just use them directly as properties.
> +
> + ? ? ? ? ? ? ? uint8 Type (optional) [readonly]
> +
> + ? ? ? ? ? ? ? ? ? ? ? Describes the type of the temperature measurement in
> + ? ? ? ? ? ? ? ? ? ? ? relation to the thermometer location. If this property
> + ? ? ? ? ? ? ? ? ? ? ? is present, the measure type won't be provided with the
> + ? ? ? ? ? ? ? ? ? ? ? measure received signal. The value corresponds to the
> + ? ? ? ? ? ? ? ? ? ? ? descriptions used in ISO/IEEE 11073-10408-2008.
> + ? ? ? ? ? ? ? ? ? ? ? Possible values:
> + ? ? ? ? ? ? ? ? ? ? ? 0 -> Reserved for future use
> + ? ? ? ? ? ? ? ? ? ? ? 1 -> Armpit
> + ? ? ? ? ? ? ? ? ? ? ? 2 -> Body (general)
> + ? ? ? ? ? ? ? ? ? ? ? 3 -> Ear (usually lobe)
> + ? ? ? ? ? ? ? ? ? ? ? 4 -> Finger
> + ? ? ? ? ? ? ? ? ? ? ? 5 -> Gastro-intestinal Tract
> + ? ? ? ? ? ? ? ? ? ? ? 6 -> Mouth
> + ? ? ? ? ? ? ? ? ? ? ? 7 -> Rectum
> + ? ? ? ? ? ? ? ? ? ? ? 8 -> Toe
> + ? ? ? ? ? ? ? ? ? ? ? 9 -> Tympanum (ear drum)
> + ? ? ? ? ? ? ? ? ? ? ? 10-255 -> Reserved for future use
Not sure why you need MeasureReceived and PropertyChanged here, I
would use one or another but not both to avoid possible
inconsistencies.
--
Luiz Augusto von Dentz