Excellent. Regarding distinction between fields and control parameters:
Fields provide sensor-data along three axes: Field Name, Node ID and Time. A single parameter can result in many thousands of fields across time. A control parameter is more direct. Control parameters exist along two axes: Parameter Name and Node ID. Apart from the fact that not all fields are from parameters and not all control parameters are suitable fields, there are in some cases fields that correspond to a set of control parameters, and vice versa, control parameters that might correspond to a set of fields. Example: Control parameters might be used for calibration or configuration as well as control. Consider an 16-bit analog output. It might have a set of control parameters available to configure the output (Scale, offset, unit, decimals for instance), and a raw 16-bit output parameter (0-65535). But when reading the device only one or two fields are reported (scaled value and raw A/D value). Furthermore, fields control QoS and other meta data attributes not applicable in control applications, and vice versa: control parameters have additional attributes that are not applicable in sensor data readout. There's some overlap as you've noticed. The idea is to let the name attribute be the key signaling overlap, and the interoperability interfaces to fix meanings. Best regards, Peter -----Original Message----- From: Joakim Eriksson [mailto:[email protected]] Sent: den 15 januari 2014 15:39 To: Peter Waher; XMPP Standards Cc: [email protected] Subject: Re: PS: [Standards] XEP-323 vs XEP-325 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. > ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6960 - Release Date: 12/30/13 Internal Virus Database is out of date.
