Re: Progress on the xAP to C-Bus gateway

[Paul Robinson]

All sounds very good - well done Kevin.

On the problem of reporting a level during a ramp, could you keep track of
what current ramps are in place and when they started? If so, you could
work
out an estimate of what the current level should be (for example by
assuming
a linear ramp curve). So what about providing both the currently-reported
level (as given by C-Bus) and your estimated instantaneous level (on
demand)?

The only problem I see with this is the additional storage required to
implement it. I don't know what limitations the hardware places on you. For
home use, it is unlikely that there will be many simultaneous ramps since
the number of units installed will be small, so you could impose a limit
based on available memory if that helps.

Paul

----- Original Message -----
From: "Kevin Hawkins" <<a
href="/group/xap_automation/post?postID=66L4m3vJT__VLiDNC7xOJb7f86A_mnnKPL54d0SFxRJg4FYbxt8UTnYT0PcQb9NVFsEP6AwgQjZV3oY9yg">lists@u...</a>>
To: <<a
href="/group/xap_automation/post?postID=C6qvYB-gNmrINy53BItf8h327xufiE5kSXFpx0KY5wKr-g5imG7poPB0pz4ePY-zhv77yJ4iXy-7hh0GHVNFvDX_7D1qn8vwNQ">xap_automation@xxxxxxx</a>>
Sent: Tuesday, July 15, 2003 1:14 AM
Subject: RE: [xap_automation] Progress on the xAP to C-Bus gateway


> A sort of two weekly update - unfortunately I had a rather heavy
weekend
> this last one and the hangover is only just starting to ease, anyway..
>
> Fully settled on the Rabbit now and just to decide on which cores to
> support and how to approach the actual hardware bit - it is actually
very
> easy to use an off the shelf dev board and add in the C-Bus SIM - and
if
the
> quantities are very low this is probably how I will approach it. I
would
> like to have done a full pcb layout and build but for just a few units
it
> may not be worth it. Anyway more on that later.
> I have just about got it all working now - just playing around with
> schemas and status messages at the moment to try and settle on what I
feel
> are the likely usages of the product. I haven't yet done any of the
web
> configuration screens, or ftp, that's next on my list. The controller
seesm
> ver solid at the moment - it runs continually and seems to do what I
expect.
> As I am new to C I am quite chuffed at this - I worried a lot about
string

> and pointer errors but thankfully they seem absent (currently).
> I did have a few issues this week with udp packet lengths but I am
> now over these and can handle full length packets correctly.
Unfortunately
> it is just not quite enough to be able to report the 256 simultaneous
groups
> states in one packet so they are split over a couple should there be
more
> than 200 groups in use. Usually you are only interested in the groups
that
> change state anyway - and each group change produces a xAP status
change
> message fully identified by UID and source sub addressing. The UID
feature
> of xAP has been very useful in the C-Bus implementation.
> I bashed my head against a problem for ages until I found that I had
> a C-Bus SIM with slightly older firmware that was behaving differently
to
> the others - nice to solve the issue but a wasted day along the way.
> One thing I have found is that Clipsal have slightly restricted the
> SIM features to prevent fully implementing group level reporting for
non
> Clipsal manufactured products - it's not a big issue (I don't think)
but
it
> could have been neater. Group levels for external loads now have to be
> maintained within the gateway hardware and not on C-Bus.
> If any of you have any particular feature requests for the gateway,
> or ideas please chirp up as now is the time to get them supported.
Just as
a
> recap the following features are currently supported.
>
> All C-Bus group changes generate a xAP message which reports source
> unit, group and level + ramp time. Each xAP message originates from a
group
> as a specific uid.
>
> A xAP 'command' message can be sent that alters any group using the
> same parameters as above. Targeting and broader schema body/name/value
pair
> commands can also be issued allowing you to include C-Bus bodies
within
> other xAP schemas. Wildcarding is supported too.
>
> A periodic group status message is sent that gives the
> ON/OFF/PRESENT/ERROR state of each group (also available on demand).
>
> A periodic message is sent that provides the group levels of all
> present groups. (again available on demand).
>
> As the device is both a receiver and sender heartbeats are sent.
>
> Housekeeping and local state information is maintained for the full
> local C-Bus network - this has proven doubly necessary as C-Bus itself
will
> not maintain and report state for non Clipsal manufactured devices.
>
> Housekeeping and synchronisation is automatic (periodic - although
> it can be forced too). Any differences go through a conflict
resolution
> procedure.
>
> Bridges are not currently supported although are ignored gracefully
> (I think).
>
> Any group can be interrogated for state and supports basic
> (ONOFFLevel as a %) and advanced state information - ERRORABSENT. An
> ERROR state is when a conflicting statement of current group level is
> present in two devices eg ON in one and OFF in another. C-Bus
automatically
> resolves these as does my gateway - however this takes a very brief
period
> of time and in the interim a group enters an ERROR state - I have
never
seen
> this happen.
>
> Pre defined ramp times btw are restricted to the C-Bus
> implementations of
> nearinstantaneous,4,8,12,20,30,40,60,90,120,180,300,420,600,900,1120
secs -
> if you ask for an arbitrary ramp time the next lower available preset
is
> used.
>
> One thing I am still pondering is level status reporting during a
> ramp. Currently if you start a ramp say over 60 seconds the level
reported
> at 30 secs is not half way up the ramp - I am not sure how critical
this
> issue is, I can probably work around it. C-Bus naturally reports only
the
> target level and the ramptime at the instant it is started - it does
not
> report when a ramp is completed or mid way. As ramps can be cancelled
or
> superseded this is awkward.
>
> Wishlist features.....:
> --------------------------
>
> Timeswitch functionality within the gateway (as this is a sadly
> lacking feature within base C-Bus installs). Perhaps a dozen time
values
> that can be set to action C-Bus events. Or would most people be doing
this
> from a central control application.
>
> Macro sequencing ( same comment as above)
>
> xAP RS232 to Ethernet bridging
>
> Basic emulation of a C-Gate server Telnet interface, ( event or
> loadchange) - to allow support for say, HomeGate.
>
> Handling of C-Bus group names within the xAP messages - these are
> not readable anywhere from C-Bus, so would be manual entry.
>
> Support for C-Bus temperature and light sensors.
>
> C-Touch touchscreen support - basic support is there already, this
> may be restricted by the current touchscreen capabilities.
>
> Support for applications beyond the '38' lighting app. particularly
> the security application.
>
> Keypad/LCD screen support (currently in but will probably remove)
>
> C-Bus bridge support*
>
> C-Bus infra red support*
>
> C-Bus Network (Ethernet) Interface* support
>
> * I don't own these interfaces so this looks unlikely -
> however the bridge support information is within the docs I have.
>
>
>
> Anyway - back to the flashing LED's ... and I promise I'll get some
> pics of the development board up soon.
>
> Kevin