I am a developer by trade. Started out in Unix, C++ and am now in the .NET world. SQL Server, etc. OOP blah blah blah.

Currently I am helping a relative make techical choices on his home. Very large house with a significant budget. A Crestron system was selected from what was presented. The installer and I got to talking and he was telling me that he would love to see me get into the Crestron (CAIP) and that he and a few others could "Give me all the work I could handle!". Sure.

It peaked my interest and I went to Crestrons site and read up. Interesting stuff. I've ran my own business before and I enjoyed it. Getting into a niche market is always a good thing so long as the market is stable and long-term and of course profitable.

Now to my questions:
- For an experienced developer, how long does it take to become 'competant' at customizing Crestron's product line?
- Is there enough work to go around, in general?
- What is the general income for small, medium, or large jobs?

Before I would get involved in something like this I would contact all dealers in a certain radius to see what their needs are to sort of 'test the waters' but I would love some of your opinions.

Care to share?

Another place to post would be

[Link: groups.yahoo.com]

Dave

Thanks Dave, I will do that.

If you are an experienced programmer and spend significant amount of time 6 month to a year to become proficient-meaning you can write at the same level you are able with the other languages you already know- at the language. However, writing code for control systems is conceptually very different from writing for other applications. This is partly the result of manufacturers making integration very difficult. Products whose serial drivers crash, whose feedback, despite the existance of a RS-232 protocol, is inconsistant ( as in the SONY CD player who would spit out outwanted strings occastionally when qurried for artist, track and disc data ). Products like cable boxes, DVRs and increasingly satlellite IRDs who only accept IR codes but have no discrete codes; and for which status sensing can be an experience all in itself.


Then there is the Crestron world of products which requires you to wrap you mind around a group of porducts in uniqure ways. If you are infamiliar with how a product works how will you know how to develop a UI for it? How will you determine the corect approach to code? Take a sercurity system. If you do not understand what is required are you going to provide every feature in the protocol or only those essential. How often and to what extant will you use graphics in your UI. I recently had a project where I spent countless hours drawing, scaling and coloring graphics only to find out that the resulting file size was to large to load the file into the touch panel. I had to redraw the panel without the graphics. Or something as common as distributed audio, which in the Crestron world would be a PAD8. Do you include features such as sleep timer ( shut system off after x amount of time ). priority [ only the first selector or a particular panel or individual ] has control of the source equipment, do you turn the room on to a particular volume or the last volume level?

Understanding the products you are controlling may take a very long time, much longer than 6 months depending on how familiar you are with A/V equipment and subsystems. If you do not understand video conference systems, HVAC, lighting, pool/spa writing code for it, especially the UI can be challanging.

If you need some help contact me off line.

Alan

This message was edited by Audible Solutionns on 10/10/04 12:58 ET.

You too, eh? Hit that wall last Friday....

Thanks for the depth of your response, I appreciate it. If possible I would start out part time in order to learn all I need to know to be successful as a full-timer. I doubt I am on the level of this group as far as my understanding of those products but I am far more knowledgeable then the average person walking the street, etc.

I don't know if it is feasible but doing it in the evenings and weekends would give me a good way to see if it something I would enjoy. I'm at the point in my career that if I take a different direction, it had better be for a pretty darn good reason, in enjoyment and income.

I may contact you offline as you offered.

Again, thanks.

To make things a bit more clear. Electronics manufacturers exist to sell audio/video gear. They stirve to make the firmware in their machines to work but thrid party control of their equipment is not important. They violate all sorts of sound practices where bidirctional protocols are involved because they are not forced to - as might be the case in the computer world - and because it costs money. Control potocols are not central to their business strategies and we in the autiomation industry sell too few products for them to pay much mind.

It is the absence of a standard and the failure of manufactureres to follow sound practices in their protocols that is the basis of the problem.

The ability to write code and knowing what code to write are two separate tasks. Many understand UI formation but lack the coding skills and those with the skills lack the talent for producing workable UI's. Crestron's Simpl language is very much different from any language you have probably ever come across. But based upon the commnets of those prodecual programmers who have mastered it they often come to like it. But even if you decided to learn and make yourself available to program every possible control system on the market you would still have to deal with understanding the equipment you are trying to code for.

Alan

Good words. Luckily I have written procedural code to manipulate controls before. One such application delt with controlling the flow of de-icing fluids during the winter at some airports. Others were in manufacturing environments where third party API's are weakly documented. While there is a good chance those adhered to a stronger "standard" then what you spoke of, at least I've had an opportunity to get my feet wet on those types of situations.

I would assume that once you get going, you build up a library on the particular behavior of every type of equipment that you deal with. I'll bet that is frustrating.