Re: PIC testing WAS OSD ALERT

[armagh_elect]

Hi Ian

> This is specifically to allow for smarter, easier parsing of the
messages
> using a small MPU

It certainly does ;-))


> yep, it's perfectly okay to not support any filters other than the
full
> match or full broadcast

Ok Good...Im going to change the the Target...aec-tvosd.default
aec is a registered vendor id..can i use steves sample ...tvosd..??
and i assume a non configured device would have default....?


> I'm afraid that the Configuration really is "core" enough
that it
needs be
> supported. That being said, it's not that "expensive" in
terms of
CODE and
> EEPROM space.


Aw.....was almost there ....Although the spec states reconfig of
Instance is not mandatory ??? It does make sense though to have it
configurable.....Did you get to that stage with your curtain
controllers ?? If so any snippets of code ???...
I assume only need to store the Instance and heatbeat value in
eedata of the pic ?? correct??

I think i will have a go at getting the heartbeat going first then
try the config stuff...Will Tonys Monitor Program pick up my OSD
heartbeat message and display it ?? Would be handy if it did for
testing....

Nice Work on the Multiple Instances /Zoning Schemas...;-))
Thanks
Frank







--- In <a
href="/group/ukha_xpl/post?postID=RAu_GPH63wDgMV0Bwl6z05DTtyBkTG_k-y47SwaCyQdUY4ytRT8x6hdQQ4ulNw6wWkuCBGHJyJSfpDPZCBD0Ovjj">ukha_xpl@xxxxxxx</a>,
"Ian Lowe" <ian@w...> wrote:
> > > Row ,Column or delay can be optional BUT if any included
they
must be
> > > in the proper order as im using a table and its ok to jump
fwd
but
> > > to keep jumping back and forth searching would be a pain to
keep
> > > track ...is this ok?? (im using asm) ;-((
> >
> > The xPL protocol doesn't specifically cater for the order in
which the
> > namepair come so it's best not to rely on it.
>
> oops! yes, the order of namepairs *IS* fixed in the xPL Protocol:
> all mandatory tags have to be present, in the correct order.
> optional tags may be present or not, but if they are present, they
*must* be
> in the right order.
> developer's custom tags must be *after* any of the schema
specified tags.
>
> > Having said that though I
> > see no reason why a device can't specific that it expects the
namepairs in
> > a specific order as I see this as a operational point of the
device rather
> > than the protocol.
>
> This is specifically to allow for smarter, easier parsing of the
messages
> using a small MPU
>
> >
> > > hop =*....??
> > > Source =.....ignore the rest
> > > Target =aec-sunroom.tv or target =*
> >
> > hop= ignore for incoming the hub deals with hop counts -
outgoing message
> > =1
> > Source = ..ignore for incoming messages aec-sunroom.tv for
outgoing
> > Target = fine with above but you will need to state that the
device only
> > support direct addressing or a full wildcard and not partial
wildcards
> i.e.
> > aec-sunroom.*. Again I see this an acceptable device
restriction.
>
> yep, it's perfectly okay to not support any filters other than the
full
> match or full broadcast.
>
> > On a more general note I believe that devices will general fall
into two
> > categories either fully xPL compliant supporting all options or
with
> > operate with the core values of the protocol but with a few bits
on the
> > edges not being supported. As long as the restriction are
clearly stated
> > in the documentation I see no problems.
>
> We can say that xPL devices don't have to support filters and
groups, but
> I'm afraid that the Configuration really is "core" enough
that it
needs be
> supported. That being said, it's not that "expensive" in
terms of
CODE and
> EEPROM space.
>
> Ian.