RE: Progress on the xAP to C-Bus gateway

[Kevin Hawkins]

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