Crestron Interfacing Problem

[mickoneav]

I have recently installed a Cbus system in my own house it is a combination wired and wireless system no problem so far. The whole system is being controlled by Crestron touch screens via a 5500PC no problem so far.This is where the strange stuff starts to happen the wired half of my system works in the way intended lights turn on/off and ramp up/down but the wireless half has the problem. Lights turn on/off but there seems to be some thing strange with the ramp up/down. Upon pressing a ramp up/down button on my Crestron touch screen the lights do nothing until I release than the light will snap to a set level this is unlike the wired half of my system where the light immediately start to fade the fade rate is set to %100 to %0 over 5 seconds a nd viscera The other observation I have made is depending on the release time of the button depends on what level the light is set to ie if I hold for more than 5 sec the lights go to %100 or %0 if I hold for 2 sec the light are set too %40 give or take. Strange indeed The Crestron smp code is some thing I have used over 30 or 40 times on various jobs and has been refined and works well I believe there is an incompatibility in the 5800WCGA gateway.

More information

There is no group address the same on ether hardware or lighting loads on each side of the gateway

I have checked the CBus codes going out on the network via Cbus test tool and there is no problem

If any one can shed some light on this Quirky problem thanks in advance

Mick Baker

[ashleigh]

As far as is known there is nothing wrong with the gateway, I suggest you set up an experiment using a plain cbus bridge and 2 wired networks and you will almost certainly see the same thing.

This points to some peculiarity in the Crestron screen and the way it issues the ramp commands.

The release and snap-to is a good sign, it means the Crestron screen is issuing the final level set.

[rhamer]

This may also be your problem.

http://www.cbusforums.com/forums/showthread.php?t=2195

[TheDocta]

Dont know if this wil help but I have discovered the exact same problem issuing ramp commands to dali ballasts. The outcome was that if the ballasts had a ramp rate that didnt match the c-bus output ramp rate it would react in the same way you have described, the ballast was sending a recall-max/recall-min command. I could be way off track .... let us know how you go.

[TheBear]

Drive the ramp command thru an OSC (0.1s, 0.1s). That works fine for all my Crestron installation... A constant press on your TP will produce 5 ramp commands in one second. You will be able to see the light lavel changing...

Hope it helps,

Dovi

[mickoneav]

Thanks for the help it was the extra routing bit in the gateway the original problem was masked by the fact that gate way was update with group address on both sides when I sent a message from the wired side to the wireless the gate way took care off the routing bit but information coming back from the wireless side was appended with the extra bite and my Crestron code ignored it

[ashleigh]

This means the gateway is doing exactly what it is meant to do, AND the Crestron interface is non-compliant :(.

I believe a new Creston interface to cbus is in development, though having nothing to do with Crestron I have no idea of the status or when it will be available.

I suggest you users of Crestron hassle your Crestron sales channel!!!

[mickoneav]

That’s a bit harsh it is not the fact that the Crestron code is non compliant it is the fact that it was written not to include bridge routing information.

In fact this is due to CBus not printing any information in the public protocol release about bridge bites and more to the point the Crestron code was written over 4 years ago when Cbus held on to the protocol like it was the crown jewels.

It has been only observation and the tenacity of people who use this forum that secret squirrel information get's out to the public.

[rhamer]

Why is there a perception that we as the end user have a right to the inner workings of a product?

It is absolutely Clipsals decision if, when and how much information they release regarding interfacing to their products.

Now whilst I'm all for as much information as possible, I recognise the fact that it is their IP and as such, their decision what to release.

If somebody decides to reverse engineer a protocol 4 years ago then all bets are off, in fact I would be very wary of using something that I know has effectively been obtained without the owners permission (they have a much bigger legal budget than me).

I would suggest that we be thankful that the information is available at all, although I do agree that what is available should be complete and correct (in the case of the routing bytes).

I am also interested in how you came to get a copy of the C-Bus/Crestron protocol that you could modify?

From my own experience, Clipsal have been very strict about the distribution of code that can be read by the end user. Did you have to prove you had applied and been granted access to the Public Release Protocol before the author of the interface made it available to you?

[ashleigh]

The public release protocol is very clearly made available with: no support, no warranty, use at own risk, errors & omissions excepted.

The public release protocol is a subset for general consumption. This is limited to the methods used for lighting control, on a single network only. Equipment vendors SHOULD NOT be using the public release as the basis for designing equipment. They should instead be joining the (very reasonably priced) C-Bus Enabled Program which provides FULL protocol information, as well as access to engineering for support, and a validation service is also available at no cost.

The public release protocol is primarily aimed at the home owner who wants to control a small number of devices, or an installer trying to get an odd piece of equipment to output ASCII strings to achieve some degree of integration.

The public release protocol invariably attracts 2 major criticisms:

1. The information is limited, and this is not right because it should be complete!

2. The document is too long, too large, and too complex, and should be further cut down and simplified!

In the light of these two opposed views that are fed back, the right decision seems to be to leave it as-is.

[Unseeable]

I have a network that im working on with one other. We have a Clipsal C-bus lighting system (includes relays dimmers etc.) We also have a crestron sound system as that is what the owner whated at the time now i have the crestron touch panel remote able to control the c-bus does anyone here know where i can get the software to let the Colour touch control the crestron sound system.

[ashleigh]

You need a crestron interface to cbus. Search this forum, there is quite a bit of info here.