The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024

Latest message you have seen: Re: Re: Possible bug in xPLHVision


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Config protocol -- when do config values reset?




Howdy,

So one way of reading this is -- it really doesn't matter whether I use
plan
#1 or #2 because in the end, they'll be the same thing.  Right now, I'm
doing #2, but it's a bit more overhead and for efficiancy sake, I'd prefer
to use #1.

I'll do some additional testing -- and am very interested in anyone elses
thoughts on this topic as well.

Thanks!

Gerry

Tom Van den Panhuyzen wrote:
> Hi Gerry,
>
> The way I understand it, the config items are mandatory in the CMND
> "config.response", STAT "config.list" and STAT
"config.current".
> They are the "interface" (developer-speak) of the device. 
Their
> number is unlikely to change unless a new release of the app is
> deployed.  And yes... in that case you may have old config items being
> sent to the new device that are redundant.  In such a case it is
> probably better that the developer uses another device id.
>
> In your example, the messages would be:
>
> config.response
> {
>    newconf=devicename
>    interval=5
>    filter=xpl-cmnd.*.*.*.some-schema-element
>    group=
>    color=red
>    color=blue
>    color=green
>    meal=
> }
>
> and
>
> config.response
> {
>    newconf=devicename
>    interval=5
>    filter=xpl-cmnd.*.*.*.some-schema-element
>    group=
>    color=
>    meal=taco
> }
>
>
> Maybe a veteran of this list can confirm ?
>
> Hth,
> Tom
>
>
> On Fri, 03 Dec 2004 17:15:50 -0500, Gerry Duprey <gerry@xxxxxxx>
wrote:
>
>>Howdy,
>>
>>I'm just about done implementing xPL in java and will be releasing
this
>>soon.
>>  I'm finishing the configuration handling and had a questions
about what a
>>device should do when receiving a config.response message. 
Specifically,
>>when
>>should the device clear it's own configuration values.
>>
>>For example, by previous conversations here, it appears that if the
device
>>has
>>groups or filters, they should be reset as part of the processing
of the
>>config.response message.  In short, if a device has existing
filters and a
>>config.response is received, those filters should be dumped -- even
if if
>>there is no filter= in the message body.  Same for groups.
>>
>>When dealing with device specific values, especially multiple
values (like
>>filter and group where than can be >1 value associated with a
single name),
>>there is a question as to when the device should clear those values
when
>>processing the config.response.  The two ways I can imagine are:
>>
>>1) just like filters and groups, as soon as the config.response is
received,
>>all configurable/reconfigurable values should be cleared regardless
of the
>>content of the message.
>>
>>2) When the first instance/reference to a config values name is
encountered
>>while processing the message body. Only at that point would all
values
>>matching that config name be cleared.
>>
>>It would seem to me that #1 should be the case as that matches the
group=
>>and
>>filter= tag, but I'm not seeing it specifically spelled out in the
xPL docs.
>>
>>The benefit to #1 is it's the only way to "erase" an
obsolete configuration
>>value.  If #2 were the case, you'd have to know of the obsolete
config value
>>to include it, at least once, to cause the old, obsolete config
values to be
>>dumped.
>>
>>By way of example, please consider this config.response
>>
>>...
>>config.response
>>{
>>   color=red
>>   color=blue
>>   color=green
>>}
>>
>>If this is the first response, after I'm done I have a
configuration item
>>called "color" with three values in it.  If later I
receive this
>>
>>...
>>config.response
>>{
>>   meal=taco
>>}
>>
>>on the same device, should I have cleared all the values for the
"color"
>>element previously configured? (the #1 scenario) or left hem in
tact since
>>there is no color= tab (the #2 scenario)?
>>
>>Thanks!
>>
>>Gerry
>>
>>--
>>Gerry Duprey
>>Ann Arbor, MI 48103
>>http://www.cdp1802.org
>>
>>
>>xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
>>http://www.xpl.myby.co.uk
>>To Post a Message: ukha_xpl@xxxxxxx
>>To Subscribe:  ukha_xpl-subscribe@xxxxxxx
>>To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
>>
>>
>>
>>Yahoo! Groups Sponsor
>>
>>ADVERTISEMENT
>>
>>
>>________________________________
>>Yahoo! Groups Links
>>
>>To visit your group on the web, go to:
>>http://groups.yahoo.com/group/ukha_xpl/
>>
>>To unsubscribe from this group, send an email to:
>>ukha_xpl-unsubscribe@xxxxxxx
>>
>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
>
>
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> Yahoo! Groups Links
>
>
>
>
>
>

--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org



xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.