Re: Re: xAP Configuration, Serial RS485 Bridge and PIC's

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Hi,

Lehane said..

>The intention was max messages at 10 per second with the initial ramp
>at 2.55 seconds from level 0-255 (no surprise there!).

Just for comparison on C-Bus the ramp rate is configurable although the
press time before a switch moves from ONOFF to ramp is not (IIRC)  - 2.55
secs sounds about right for the best experience - and it maps well to
binary !  Having an ability to set the ramp rate via a schema might be a
consideration ?  I will try and look what the 'default' ramp time is that
they use - it's probably been well researched at a UI level

BTW 10 messages per sec is enough to bring down xPLHAL currently :-( 
(until it's bug fixed) however it would need to be sustained and in your
app this isn't going to happen and I can't see more than perhaps a 5 second
burst (50 messages) so I think that's fine - having a xAP DMX application
would remove this limitation - I did start one here (story of my life that)
- using the Milford Instruments controller - which is again based on the
xAP BSC Skeleton framework - but it got pushed down the list - do you use
that controller by any chance , if so I'll resurrect it....


>> Could you enlist a middleware layer that just takes
>
>
a 'press'/'release'

>> message and handles the 'hold' by deduction (which is sort of how
C-Bus
>
>
>> works)
>>
>> Press > threshold time causes start ramp command and release
causes
>> end.  If threshold time not exceeded then release causes toggle.
>>
>
>
>I could but I'd prefer not to. One reason for going down the xAP
>route is the potential for autonomous operation (without a PC) in
>some scenarios, although not currently in this iteration.

>For now I'll probably just have the flags in the EEPROM and change
>them as I blow the device. If there is then space I'll look at a very
>specific config message and schema.

This also is the only approach if the device is a transmitter only - as
some xAP switches probably will be.   (or the 'press' 'release' and a
helper)

>Lehane said..."What I'd prefer not to have to do is define, in
advance, which port
>input is which switch type."


yep....sounds a good route although it still doesn't achieve the 'define in
advance' problem which was your original question...

I have long thought that a (nice low cost) embedded xAP BSC Mapper would be
the ideal. A standalone basic xAP engine implemented on say PIC or Rabbit -
with perhpas a config schema or web config page. This would handle
mappings, some logic (if then etc) and some scheduling.   Then you can
eliminate the PC altogether and could also support 'press' 'release' type
mapping in a controller so your switches remain standard as one config.  
Maybe using Phaedrus' hardware and a different chip to make it such a
device.


>Without some better xAP configuration mechanism source UID's are
>useless IMHO.
>
At this point we have no xAP official configuration schema , what
initially appears easy becomes a surprisingly complex area to accomodate
anything but the simplest of devices/parameters - plus it requires that
all configurable devices be transceivers -  we need something more
capable than the alternatives out there.    This is an interesting area
for someone to take up the task  ;-)    James did a lot of work on this
and it's almost there , but not quite....  FTTB however you can always
set up your own schema to configure your own devices including the UID
if necessary. It is expected most people will do this either via xAP
messages, a web config screen or in some cases only switches.  The UID
is powerfully & extensively used in BSC, indeed it's the cornerstone
that makes it possible. UID's also offer the ability to detect sources
based on 4 bytes of stored data. Very useful for small memory devices,
automation controllers and groups and scenes.

*******************
Actually having an agreed standard way to configure the key parameters
(UID , source address,  hbeat interval etc) - ie the header values is
probably very easy and we should at least have an interim schema
solution pending a full config schema. This probably can extend to sub
address names too.  What do people think ????
*******************

>You'd have to blow the UID(s) into the PIC which maybe
>OK for me but anyone picking up the code, maybe only a .hex file,
>would have to change it for their source device(s) of interest and it
>would make preprogrammed devices a nightmare.
>
Or have your own schema to set it in NVRAM - yes a formal xAP schema
would be the ideal way but a custom schema is workable pending such an
alternative.   We do have intents to extend the size of the UID allowing
for a far greater number of sub addresses and devices. This will also
include reserved ranges for manufacturers to pre-allocate unique UID's -
rather like  MAC addresses.

>It would be better for
>smaller devices that they always responded to a particular UID
>(effectively a globally defined xAP broadcast UID) and there was an
>optional configuration message to define further (maybe 4) UID's of
>interest.
>
>
>
Ahh I think you may have misunderstood the UID in this respect - no
device can 'respond' to a UID as it is not in any way targetable. A
message can't be sent to a UID.  You can only target the longform
address using target= .  The reason for this is again that wildcarding
wold fail (be bypassed)  if you were allowed to directly target a UID  .

eg a device is listening for all messages sent to  X10  by applying a
filter of 'target= *.X10.>:>   and it sees a message targeted at
FF123400  is that being sent to an X10 device ??   You can't tell.

However a device can recognise a sender (at either the device or node
level) based on just the 4 byte UID. Hence a device monitoring a group
of triggers eg a lamp that is operated by 4 different light switches
need only store 16 bytes of data - indeed possibly only 8 bytes if you
can afford to ignore the first byte (network) and last byte (subaddress)
in your particular implementation.


>I'm specifically trying to make it as generic as possible, so as far
>as I can it will follow the current xAP specs. If that isn't possible
>then maybe some extensions/revisions are required (for example the
>keyword tokenisation standardised, the crc in binary rather than
>ASCII, broadcast UID, etc).
>
>
If anyone else might be using your device then for interoperability
of course it would need to be to spec, what people do in their own
setups is sometimes quite different of course. For distributable
products the spec is key and indeed compliance would be required to use
the xAP branding.  I think if you can handle the CRC and process on the
fly that is going to be ideal.  I know you are a very accomplished PIC
programmer so I look forward to your experience and comments/feedback
here, I'm hoping we mainly got it right and  having some RS485 xAP I/O
will be most beneficial.

>Lehane
>
>
>
K

PS xAP TOM10 conduit now working again with latest BSC frameowrk  - will
send you it offlist shortly !