I definitely can help with this given an achievable scope. But to send commands to a Crestron processor, you really need to know the code inside it, not just send packets based on some sort of protocol interpreter. This could crash their box or produce undesirable and unpredictable events triggering elsewhere in the code. These boxes are at heart a state driven machine.

Their CIP is just a way to map ID's associated with certain signal types within the code to provide an interface(generic for the most part). So by creating a ethernet symbol in their code that can listen for CIP commands, you can make it do what you need to in the code and not by triggering a state of a signal that could be dependent on many other factors. Being associated with their ethernet symbol, you drastically reduce complications to being predictable, therefore controllable.

Crestron just released a SDK kit for adobe flash action script. Many guy are doing iPhone interfaces by using this means of Crestron ethernet CIP connections. I have seen ajax used several times. It really isn't a big deal. Crestron processor can just about adapt to any interface, not just the ones they sell. You just got to get someone to build the code on their box first.

cheers

Action Script SDK ? Where you see this ? I am interested!

I've created a project page for you at Crestron Integration Project.

Clearly a worthwhile integration. Crestron is used in high-end residential as well as industrial and commercial. The ethernet symbols that Tres talks about is what we want to understand for mapping. We would expect a clean API from the server, not meddling with its process or internal state machine. Yes the ORC would support state, persistence of state, state replication, messaging, eventing, scheduling, state machines and workflow languages. HA programming is no mean feat but could ultimately be a visual driven one. Maybe consider integration to Sketchup?

In any case, Crestron support is something we want to have. Everyone does it and as was pointed out the panel is the king. A flash-driven panel is a great idea and where the iPhone may go critically wrong with their stubborn lack of support for the ever growingly popular flash format on their latest hardware. Have you ever looked at cocoa? buark!

It seems everyone is focusing on this CIP API which is a good thing it may mean it is stable. People are doing that with iPhone and Ajax and it isn't a big deal. It is a big deal. Good to hear about the excitement around the flash format. Have you seen flash-games lately? Some of them are excellent.

Good to have this on-board, JL or CB, I still can't find that magic toggle switch thingy that makes the thread sticky.

And how do you see, technically, the connection between OpenRemote and a Crestron processor ? I have many ideas, but I don't want to go a way others would find it wrong.

If you have many ideas, get it started.

One way would be to use a Crestron module that exposes TCP server on a given port. This module would have signal inputs and outputs. You could either drive an output signal high/low via an input message or get feedback via an output message from an input signal that is changing. I suppose that UDP could be an option as well.

Use ActiveCnx from crestron. http://www.crestron.com/downloads/pdf/productmisc/activecnx.pdf

Just joined this group. I have been giving this concept some thought for a while (several years) and am glad to have found OR - should have known others were already out there doing something similar.

Anyhow, having been a Crestron Dealer/Integrator/Designer/Programmer my thoughts are as follows:

- Best integration option IMO, would be to create a shim module that effectively duplicates functionality of Crestron's Test Manager application. This presumably speaks the CIP (Cresnet over IP) protocol but has the advantage of being able to access every signal within a crestron SimplWindows/SimplPlus program. It exposes read/write access to these signals and when tied together with a native program file (can display appropriate names/device IDs).

- The eControl family of applications/modules also already implements IP-enabled passing of signals bi-directionally, however the exposure of the API is not low level enough to get raw access to the individual programming signals and also assumes the use of their ActiveX or (older) Java UI controls to simulate touchpanel-like inputs/displays. The eControl Gateway does provide the functionality you'd be looking for, but it is not documented from the perspective of someone trying to create these lower-level native interfaces. Queries to Crestron as recently as a few months ago effectively went nowhere. I think Crestron is leery of exposing this degree of access into their protocols, etc - as they are used to providing a controlled/closed ecosystem from a programming perspective.

- I would bet that you're going to have to end up sniffing the CIP protocol. Good way to do so would be to sniff a session between Test Manager and a running system. I suspect that there is a fairly lightweight packet format for every event/signal which would contain a Device ID, Signal ID, Signal Type, and Value (possibly other things). I have thought about Wireshark-ing this session, but haven't done so yet...

A couple of other issues (misc) to keep in mind on the Crestron front:

- Need to anticipate the existence of a Crestron controller on a Crestron system. I don't see it as realistic to think that an OR-based application would replace that. Too many CresNet-only devices and hardware plant in a typical Crestron system to do without a Crestron controller entirely. - Need to create a stub host application that identifies all Crestron devices in the main controller, provides appropriate signals/names as hooks to OR, and provides certain types of autonomic logic functions so that keypads and other critical devices can function natively. - Move much other event logic into the OR-based server/applications so that complex events, sequences, and higher-level UI interfaces (IP-based devices, rich GUI's, etc) can be done outside of the Crestron domain... - From what I've been told native Cresnet protocol is effectively a serial, token-ring, network. So the processor is expecting to be polling devices and processing signals as they change.

I'd be interested in contributing to this sub-project further, and I think this specific area is one that provides one of those commercialization paths for the OR project. If you can create an environment that provides a smaller, lightweight, installer-configurable program stub in the main Crestron controller, and then allow for more logic to be done in a more macro style than what current Crestron programming paradigm provides, that would be worth a LOT of money in the HA marketplace... I too have a bunch of ideas about this domain, but am not a hard-core Java programmer. So perhaps I can contribute design and architectural ideas, specific knowledge of the Crestron programming and system engineering space, etc and those more Java-savvy can do the implementation.

Ted,

A lot of (interesting) information there. I've no expertise in Crestron at all, however some of the things you say do make sense.

The Crestron integration ball is very much in the air so if you're willing then go ahead, grab and run with it. I think the first step there is figuring out the CIP protocol part, as you say if it needs to be sniffed then that's a hacking project for someone, no Java skills needed.

The next logical step would be to get that information into our knowledge base, if we can get something akin to what we have for INSTEON wrt message structure we can at least mock some Crestron stuff and move from there towards real integration. And also, don't worry about your Java -- at this point just getting the protocol down would be helpful, as long as we can understand what happens on the wire we can get all the rest of it integrated -- fugly or not, as long as it works. I don't care if you just print stuff on the standard output as long as I can see what the protocol looks like.

WRT how we should integrate with Crestron controller what you describe is my current thinking as well, OR controller would pretend to be an application in a Crestron network, listen in on the network on events and try to build macro, scene management and UI tools on top of that and provide the option to integrate with other control networks and/or hardware as necessary.

OK, so I've made minor progress on the protocol front. I've dug out some information from a previously overlooked Appendix that eludes more specifically to protocol (UDP) and packet count/sizes used for CIP for various signal types - In Crestron-land there are 3 basic signals (Digital, Analog, and Serial) - each containing different data types.

That gives me a little more to go on. I'll be getting my hands on (either physially or virtually) a Crestron controller again to do the sniff in coming days I think - perhaps this weekend. Should be able to have some better details to go on then.

Cool, keep us posted! :-)

If I wanted to post/share some diagrams or other information/files with you guys, how should I do so. I haven't found a facility for either embedding images in a post or uploading/posting a file beyond a hyperlink to another site where I could host it.

Thoughts?

There's a way to upload images to the website but I don't really remember all the steps -- maybe we need to set you up with access rights.

I'll try to look into that tomorrow and let you know.

Happy to collaborate offline too so that we can post more fully developed documentation. I've got a thread going with Marc, but I don't have an email address for you. Skpye, Email, ichat or any other model would work. I want to contribute some possible architectural thoughts in diagrammatic form - I'm a picture person. Some of these discussions wold be more productive offline if you're agreeable...

Thanks for reporting what you have found out, Ted,

If you need Flash UI dev, I am sure we can find someone.

Hello Ted,

Thanks for the progress update.

I've created a Crestron page in the knowledge page. You can use it as you see fit.

Hi guys, just joined..

So I posted in the KB what some of you may or may not know.

There console commands that aren't publicly documented. If you type HIDHELP ALL on the console of a Crestron Processor you will see publicly known ones and some that are not.

One of the hidden commands is SENDCNETPKT this is useful for communicating on Cresnet.

Hope it is useful in figuring out both CIP (cresnet over ip protocol) and Cresnet Protocol.

Hello Daniel,

Thanks a lot. At this point any and all Crestron information into the knowledgebase will be useful. Feel free to add more if something comes up.

-- Juha