I almost would say the only important factor is interoperability ;-)
Well also that it is suitable for the IoT devices that we believe is
going to make use of XMPP. In my perspective it would be good if
we consider even very small devices to be candidate for actually
running a complete (subset) of the XMPP stack.
I like the idea of setting up "standard profiles" for IoT like
you are doing in the linked document. Even if I am not sure I
like the distinction between fields and parameters it is a good
start.
I will continue to do some implementation based on 323 + 325 and
see what I like and dislike and provide more feedback as soon as
I have more to say ;-)
Best regards,
-- Joakim Eriksson, SICS
Peter Waher skrev 2014-01-15 18:17:
PS: Forgot to mention relating to the discussion regarding unit
conversion in devices:
One important factor in the design of the IoT XEPs is interoperability
between devices. If support for unit conversion were to be added to
XEP-0325, a mechanism for publishing supported units would also be
necessary. Syntax of units would also be a problem to define. (Is m^3
written m^3 , m^3, m3 or M3?) To avoid such problems in control
applications, control parameters are defined by the actuator, and
controllers are forced to use the ranges (or other validation rules) the
actuator defines.
To provide for an additional layer of interoperability between devices,
we’re writing a document listing interoperability interfaces (contracts)
for devices of different kinds. It is a working document at the moment:
http://htmlpreview.github.io/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/xep-0000-IoT-Interoperability.html
Best regards,
Peter Waher
*From:*Peter Waher
*Sent:* den 15 januari 2014 14:07
*To:* 'Joakim Eriksson'; XMPP Standards
*Subject:* RE: [Standards] XEP-323 vs XEP-325
Hello Joakim
I'll address your concerns one at a time:
So a resource limited device that can not translate between Fahrenheit
and Celcius will be able to provide and parse the control forms?
Yes, in the general case. Temperature and two units is of course a
trivial example, but the extension tries to solve the general case,
which is much more complicated. Furthermore assembling control forms is
easy, parsing them is often supported directly in the XMPP client
library already provided.
From my perspective (being a resource constrained device software
developer) I would prefer a more lightweight approach than the control
forms to discover the fields and their range, units, etc.
An additional approach might be possible. However, it would not remove
the need for control forms (see below).
A complete slimmer "discover fields" response could be:
...
<fields>
<int name='Temperature' min='-40' max='95' unit='C' /> <int
name='Humidity' min='0' max='100' unit='%' /> </fields> ...
Now, sensor data (XEP-0323) can publish a lot of records, not all
controllable. Normally, only a small fraction of published fields would
be controllable. Furthermore, many controllable parameters would not be
readable (and therefore not available as fields through XEP-0323). So
there’s no natural connection between fields in XEP-0323 and control
parameters in XEP-0325 in the general case.
Secondly, your example only include ranges. Intervals is just one
validation method. Control forms provide more. The pluggable validation
structure (i.e. using sub-elements) provides a more general way to
defining limits than attributes on an element would.
Thirdly, by supposedly including this information in the field
information, it would have to be sent every time the sensor is read, and
stored with the values as well. A control form can be read once to know
the capabilities of the device. When somebody wants to know the control
capabilities of a device, it simply reads the form. It can later issue
control commands without reading it beforehand.
Then if it is for humans - all the labels and other things could be
included?
Is the current forms mechanisms intended for machine-to-machine or
machine-to-human?
It is intended to be used by both machines and humans. Sufficient
meta-data has been added to create an interface that can both be
automated as well as be understood by humans with no device-specific
software added, and taking into account aspects important for both.
Best regards,
Peter Waher
Peter Waher skrev 2014-01-15 16:22:
Hello Joakim
The control form provides means to publish limits for control values. See
§3.3.1 for examples.
Best regards,
Peter Waher
-----Original Message-----
From: Joakim Eriksson [mailto:[email protected]]
Sent: den 15 januari 2014 08:51
To:[email protected] <mailto:[email protected]>
Subject: Re: [Standards] XEP-323 vs XEP-325
Tomasz Sterna skrev 2014-01-15 11:54:
Dnia 2014-01-14, wto o godzinie 11:30 +0100, Joakim Eriksson pisze:
<double name='DesiredRoomTemperature' value='22.0'/> ...
I can understand omitting unit and momentary [...]
I can't understand omitting the unit.
You need to know up front what unit does the control expect.
There's a room for misinterpretation and mistakes like ie.
frying/freezing your plants.
When you specify the unit, at least you give a chance to err-out on
unhandled unit if the control is unable to convert.
Yes, keeping the unit even for control make it possible for the controlled object so do
better error control and "sanity checking".
Is there a good way to inform the controller what are the limits of the values?
E.g. max and min values of the desired room temp?
(have not yet fully read all the XEP-323/325, etc).
Best regards,
-- Joakim Eriksson, SICS
-----
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2014.0.4259 / Virus Database: 3658/6960 - Release Date: 12/30/13
Internal Virus Database is out of date.
