Hello Joakim
Thanks for the response. I'll try to respond to your question below: Then of course when having a desired room temperature in C that is a double the code that checks that the values are correct will need to check that this room temperature is between +5.0 and +30.0 or so. Is there also ways to express these "limits" too? Or is there a need for the controlling entity to know what it is doing by knowing that this is in fact a room temperature and not a oven temperature. The control parameter exists in the context of what is defined in the control form. The set operation assumes knowledge of ranges, data types, units, etc., from what has been published in the control form. See §3.3.1 Getting a control form in XEP-0325, as an example. It is assumed that unit conversion is too complex for small devices to perform, but relatively simple for system applications. I is not possible to control a parameter using a different unit than the unit defined by the device itself, and that's why unit information is not provided in the control command. It is assumed to be in the unit and within the allowed range. The meta-data concerning the parameter is available in the control form. Best regards, Peter Waher -----Original Message----- From: Joakim Eriksson [mailto:[email protected]] Sent: den 14 januari 2014 18:06 To: XMPP Standards Subject: Re: [Standards] XEP-323 vs XEP-325 Hi Peter, Yes, there might be reasons to be more specific when doing control, but for making implementations as easy as possible it would be very good if the types where the same and as few as possible. I would go for something like: int double (or float) boolean datetime string both for querying (323) and for control (325). Then of course when having a desired room temperature in C that is a double the code that checks that the values are correct will need to check that this room temperature is between +5.0 and +30.0 or so. Is there also ways to express these "limits" too? Or is there a need for the controlling entity to know what it is doing by knowing that this is in fact a room temperature and not a oven temperature. Best regards -- Joakim Eriksson, SICS Peter Waher skrev 2014-01-14 15:38: > Hello Joakim > > Thank you for your mail. I'll try to respond to your question: > > Hi, > > I am working on testing out the new XEP's for Internet of Things and > Sensor networks by mapping a Heat pump connected over serial into > these XEP's in a embedded PC. I have already made some registers > readable over > > XEP-323 so that seems good, but why is there such a difference between > reading out values and setting values? > > Assuming that there is a desired room temperature would be read it > would be something like: > > ... > > <numeric name='DesiredRoomTemperature' momentary='true' value='21.0' > > unit='°C'/> > > ... > > and to set would be (XEP-325): > > ... > > <double name='DesiredRoomTemperature' value='22.0'/> ... > > I can understand omitting unit and momentary but why not keeping the > same tag-names (e.g. <numeric> or <double> in both)? > > The reason here is because the control extension (XEP-0325) is more > detailed when it comes to format and validation. For instance, it > contains 3 numeric types: int, long and double. Handling integers is > easier in control applications, but not suitable for all control > parameters, as is the case in your example. The integer types are > meant to be used for say simple analog outputs and the like. The > sensor data extension (XEP-0323) is less interested in formats and > validation, and uses only one element to convey all numeric field > values. It also transmits meta data about the value not applicable in the > control case. > > I've been unable to update the site with the most recent versions of > the extensions you mention. I've attached them instead. There are some > minor changes documented in the revision histories of each one. > > Best regards, > > Peter Waher >
