This one is hitting home in a big way for me. I was up all night Monday night fighting a prodigy system that we pushed too far. We are full line Crestron dealers, but thought we could make this work without too much trouble. We have two programmers on staff, one was on vacation all week, and the other was tied up in other projects, so I took on the system builder fun. The rack had to be on a truck by noon the next day to go out of state.

Long story short, everytime I would rebuild to try and fix some problem, something else would break or lose connection. As I sat there in the wee hours of the morning rebuilding and counting the time untill I could call Crestron tech, I was reading this, and wishing to god I could program in Simpl. I would have gladly scrapped the whole thing and started over.

When I talked to Crestron, they wern't sure why it wasn't working either, and after about two hours on the phone, things just started working. Neither I nor tech support was really sure what the problem was, and at that point didn't care.

I think what 39's point is, and has been repeated from other programmers I have talked to, is this: When something is broken in simple, you fix it and move on to the next thing. When something is broken in system builder, you fix it, recompile, and hope that the problem actually gets fixed, and doesn't break something that was already working. In the end you are limited with what you can provide the client with systembuilder, where as sky's the limit with simple. So go for the win regardless of which processor you are using.

About the only positive I can come up with from my situation is as I was waiting for this thing to compile, I was watching every training video on Crestrons web site, and reading every thing I could come across. I have a really good handle on every other portion of the software other then simpl now!!

Hmmm...I think the point of my comments were a little lost. I was not trying to evaluate the overall value/benefit of SystemBuilder as compared to Simpl, but expressing the desire to have help in dealing with this beast as-is.

Again, no one denies the fact that learning Simpl would be the most advantageous. However,...as a Prodigy dealer who has access to it only through distribution, Simpl training is not even opened up to us!! Crestron has not allowed it...yet. So, in reality, the learning process of having to pick up Simpl programming on our own or simply through yahoo forum groups and other threads - without the benefit of Crestron training - is not a time-saving practice. For those Prodigy-only dealers who are direct with Crestron, I would agree that the best course of action would probably be to investigate if Simpl training is opened to them. But from my understanding, they're in the same boat as us distribution guys.

This only leaves the other "Simpl" option of hiring a programmer for every Prodigy job that's sold. To do this for every project that the Prodigy line has been targeted to [modest system, modest budget] - again, is not practical. Very easy to say, but for any business owner, project manager, salesperson, etc. who has ever had to run the numbers and examine profit margins on small projects, it just does not always work. You will price yourself out of so many small jobs. All of us who have experience selling Crestron projects know exactly how large of a percentage Crestron programming factors into the cost of a project. Large project? The cost is easy to explain. Small project? Not always easy. C'mon, it's the very reason why many of the CI firms carry secondary automation systems - so as not to be priced out on the SMALL job.

When you are offering a modest Prodigy system - staying in the "sandbox" as some here like to phrase it - and you're several thousand dollars more on a proposal over an exact system programmed with URC or RTI [again this is for a modest system that Prodigy is marketed for], are we truly offering any extra value to the client by having it programmed in Simpl? Will the client notice the difference on a small, typical one-room theatre system, even on a simple D/A system? Will his Samsung bluray player play any faster because the IR code was sent via Simpl programming instead of URC? Will his Panasonic 3D set offer better 3D capabilities because it's got Simpl as its backbone and not RTI programming? No. The client will not see the difference nor know the difference.

Is there some value for the dealer? Perhaps. Do I hate the fact that my code may be broken by a SystemBuilder update made 2,3,4 years from now? Absolutely. Do I intend on still being a Prodigy-only/SystemBuilder dealer 2,3,4 years from now? Absolutely not. God willing that my current biz continues to climb, I'll have that full-time Simpl programmer on-staff by then. I will have extra means to deal with these issues - if it arises. And I'm sure that a lot of other Prodigy dealers feel the same way. It's a stepping stone. However, I have to deal with the stone as it exists right now.

Trust me, I'm not trying to p**s off the CAIP guys out there. I've hired many in the past for our mid to high-end projects. AND I WOULD HAVE IT NO OTHER WAY. However, again...I'm trying to address the market for which Prodigy has been directly marketed to. I'm trying to address the issue that Crestron has purposefully opened it up to dealers on the distribution level who they would like to see replace their RTI & URC projects with Prodigy projects. I'm talking about projects that live within the "sandbox" of RTI and URC programming. If you look at that simple RTI project proposal and now replace it with Prodigy + Simpl programming, chances are you've priced yourself out of the running. Will you still be able to win a few? Of course. But who wouldn't prefer to stack the odds in his favor the majority of the time?

So, I must deal with SystemBuilder for now. I'm not overly fond of it. To be honest, I don't really think much about it. [Definitely not bragging to anyone that I'm using it.] But for many of us guys who need to keep profit margins up on smaller projects and have a plan for taking on more with Crestron, we're forced to use it. It sure would be nice to have a place to go to where dealers/programmers could help each other through the transistion period.

Please define "too far".  May I ask what you were doing? Not to be nosy, but how far is too far? Were there a lot of devices? What out of the ordinary were you trying to accomplish that wouldn't work? What "broke" after you fixed something else?





"We are full line Crestron dealers, but thought we could make this work without too much trouble."



I have zero previous experience with Crestron. Posts like this make me worried that I am either going to have a lot of problems with Prodigy, or that I won't know enough to leave the sandbox and probably be fine. It's hard to tell. I appreciate any info you feel free to share. TIA    
G

G, much can be done with the system. 3 completed systems so far. But dont get too hung up on the whole "sandbox" thing. Because you may start to believe that "in the sandbox" automatically equates with a simple job and "out of the sandbox" automatically equates with a complex job. Not that black & white once you start fooling around with the program. There are many simple, everyday programming tasks and project arrangements that will take you out of Prodigy Composer and into Systembuilder. Tis the nature of the beast.

I've learned much - primarily through trial and error, and I'm seeing my programming headaches being reduced. You just have to prepare yourself mentally that it will take some time to wrap your head around the unique ways SystemBuilder would like to see things done. Composer is a super-easy program to navigate through. ToolBox [a Crestron multi-faceted utility program] can look daunting at first but is really straightforward once you know where to look for certain features or troubleshooting tools. Fortunately, I've had several years to use it, which really helps me in setting up my Prodigy components. It's some of these very issues that a community thread could help new dealers overcome quickly.

Is Prodigy or SystemBuilder rocket-science? Nope. Could it be better? Yup. I'd wholeheartedly recommend getting a demo unit to play with inhouse before going full-speed ahead with it.

Thanks for the input NorCal. I didn't realize that Systembuilder was a stepchild when I was researching my decision to take the class. I have 0 years experience with Systembuilder, or with Crestron for that matter, though I hope that is changing. So when I took the class it was easy to see that Composer would go by the wayside fairly quickly, but Systembuilder looked like programs I'd used before, just more powerful. I know there is a lot to get used to. Stamps point would be that since I am starting fresh, don't go down the Systembuilder road, but I kinda have to since I am small and if I want to do Crestron it is going to have to be Prodigy.

All but one guy in my class of 7 or 8 were doing or had done full Crestron. I assume that they were there because it is an entry level product for their markets. Even you say that you have done Systembuilder for several years and that your programming headaches have been "reduced". From what to what? 3 posts back Gerry talks about things being "broken" or losing connection. I 'm sure that I can learn Systembuilder, but "trial and error", things being broken after fixing other things, staying up all night troubleshooting, as a one man band that worries me because my time is precious. Are these things a normal part of programming in Systembuilder or as Gerry said is it because "we pushed too far"?  And what does "pushed too far" mean? What is everyone trying to make this program do?

Again, I really appreciate that people that have some experience with Prodigy have been willing to share. I put my PO in with my application etc but haven't received my demo equipment yet. When I do, I will set it up and play before I put it in anyones house. I want to know that I can make it work reliably.

So here is how I see Prodigy working for me. "Hi Mr and Mrs Customer. So you would like to upgrade your system (or install new). Check this out. You can control your whole system from this very sharp looking colorscreen remote. You can also see your Ipod on this remote and control it. When you sit down to watch TV you can lower the temp of the house from this remote, and dim the lights for that movie theater feel, and you don't need all those other remotes. And this system can grow with you, add more lights, add music in other parts of the house and control it from this remote, a keypad, or one of these color touchscreens."  Or they have a dedicated theater. I'm simplifying. But that is the gist of it. And since Crestron makes all the parts, I only have to talk to one tech support if there is a problem. Is my logic horribly flawed here?

What would I be doing that would make things "break" in this senario? Why would Simpl be better for this senario?

And I'm guessing that some full line guy just read this and spit his drink all over the table "OMG, this guy is bastardizing Crestron". Don't flame me guys, I really am looking for answers and solutions. Prodigy seems to be a good one. And I'm guessing that this is what it was designed and built for. As a one man shop, it looks like a great solution, especially for retro-fits.

So since I am growing INTO Systembuilder and not dumbing DOWN to it from Simpl, am I going to run into the same problems? I think I'm less likely to try to make Systembuilder do something it isn't made for than someone who is familiar with all the power of full Crestron.

Again, I appreciate the input. TIA!
G

Hi G:

Just to clarify. I don't have years of experience programming Systembuilder. I'm in similiar shoes to yours. However, I've been exposed to it off/on for a few years while working for another large Crestron firm. I'm learning it now, as I'm now working for myself.

I can't really comment on the "breaking code" issue that was brought up by several of the guys in this thread. But it wouldn't surprise me that this phenomenon happens. BTW, as standard practice for any programming job, I save a copy of each client's firmware, program, and database files as part of each project's archive. This will not eliminate the possibility of a future "enhancement" from Crestron breaking the code of a previous job that you're updating, but I'm sure it would make getting back to "square one" much easier.

You can accomplish the things you mention in your example scenario with Prodigy. Perhaps much of it within Composer. Just dont be surprised if you're taken out into SystemBuilder from time to time - even for the simple system you mention.

For example, take your scenario. One room with A/V and lighting control. Most likely, you could get it all done in Composer. All lights can dim up to the same level or dim down to the same level. Easy in Composer. But now, let's say the client wants a lighting scene for "Reading" where he wants his sconces on the front wall entirely off, but rear lamps and overheads at 65%. You're in Systembuilder's world now - not Composer. Is this "pushing the limits"? No, it's a very reasonable and realistic request of any lighting control system.

Or as another example, you decide to add a touchpanel in a centralized location. But dont assume that by the end of your programming in Composer that you'll be able to see all the different lighting loads in the house, particularly if the touchpanel's location - although ideal for the client - doesn't have a lighting load part of your system. Can it be easily fixed? In Systembuilder, yes. Is this an "advanced" project? Hardly.

It's just some of the nuances of the program[s] that need to be worked through. And this was the "trial and error" that I was referring to.

Overall, I'm quite happy with the system. This weekend, I've been setting up the lighting control throughout my house. Piece of cake. Only issue I had wasn't even related to programming, but trying to figure out how my contractor wired my multiple 3-way lighting locations. [I think every 3-way location was different!]

I look forward to chatting with you more once you get your system set up. I don't claim to know much about it, but I'm more than willing to share the little I've learned so far with you.

I think a system builder section would be great. Not just for prodigy, but for system builder in general.

GLS,
As for overdoing it, We had the pmc2+, 2 ptx3's, ipod dock, am/fm/xm tuner, 3 pamp's, 4 ptl4's, 5 p-cbd-ad wired keypads, apple tv, 2 sat boxes, bluray, two tv's.

May I ask.. What issues did you encounter?

Houston, we have a problem! THAT is overdoing it? Take out 1 or 2 pamp's and 1 or 2 ptl4's and that's just about anyones project. Not even a tstat in there. I thought you were going to tell me that you were pushing 100 devices or something. That's master bed and family room, with some distributed audio. No lighting either? Obvously you were up all night, but can you give a Cliff Notes version of the issues you had?
TIA.
G

Sorry, it was asked multiple times that I explain some of the things in my earlier post. I wasn't avoiding or ignoring it, I've been working through our next prodigy system problem, and i wanted to spend some time on the phone with crestron TBS to make sure I wasn't making a mountain out of a molehill. I would also just like to throw it out there, Crestron has some of the best tech support I have ever dealt with. When they get on the phone, they are on it untill your problem is solved. If they can't solve it, they will find someone who can.

Let me start with the latest one, because it will demonstrate the "sandbox" idea fairly clearly. I'll leave out the part #'s because they don't matter. There's two parts so I'll break them up.
System:
plasma
receiver
bluray
comcast box
Can't get much easier then this right? Except it's the customers receiver, which won't switch hdmi, so the tv is doing the video switching, receiver is doing audio. So I build it in composer, and end up with three problems.
1. TV power on and off works, but source codes are wrong, so I figure I'll just add another display device in system builder, and just change the source codes out. MY BAD! This is a no no, system builder cannot deal with having the second device, even though I manually went in and reassigned the codes. Builds some really weird pages, so I start over. Go into DEAL and add the correct source codes and save in user database, so all the codes are in one device. This is my screwup, and tech helped me through it.

2.Bluray commands are repeating 4 times with one button push. This was a crestron code set I used out of their database. Turns out all the codes are set to min 4 repeats. So I have to open up DEAL again, change each code, resave it under a different name in my user database, then go back in and change over to my new codes. PITA!

3. When the system built, it included two blank pages for the comcast box. Just blue backgrounds, plus the main page I need, and a keypad page. So when you choose comcast, it comes up on a blue screen. My inital thought was to just delete the blank pages, but again this is apparently a bad idea in systembuilder, so I just copied one of each of the pages I did need onto the blank pages. Not the end of the world, still a pain though.

So if that was it, I could chalk some of this up to learning curve, and stuff I know not to do again. But here comes the real problem for us. Customer also has a two channel setup in this same room. Mark Levinson cd player that does the volume out to an amp and two B&W spkrs. He wants to be able to also control this setup from the remote. The answer is no. The guy at Crestron told me that that was too far out of systembuilders box(his words). The only way to make that happen was to do it in Simpl.

I also had to edit the touchscreen graphics in VTE pro for all the devices because the buttons it generates were either worthless or insufficent. i.e a track forward and back for the bluray. I added the colors and the pop up menu.
I could do this entire program on urc or rti in about 20 minutes on a bad day. Not so much with prodigy.

We run into funky control requests quite often. If you don't then this may not be that big of a deal for you.

I will go into the other system tomorrow if you would like, just let me know. On a side note, I did spend the majority of today with our programmer starting to learn how to do this in Simple.

For the additional 2 channel setup, I did this for my own house.

SB doesn't like if you remove pages, but you can add pages (in VTpro) without breaking anything.

To add a separate stereo set to my system, I added a new room to SB, put all 2 channel equipment in there. Add an dummy PTX3 to the new room to generate pages for it so you can later copy-paste them to the real interface.

Open the real interface, add a page for the 2 channel amp (e.g. by copy paste an existing one) in the same room and add some buttons for input / volume etc.

Add a button to the systems home page (call it 'listen to stereo' or so, I removed the climate icon to make room for it) and make it flip to the new amp page. If you wish you can let it switch the power on to the 2 channel set or you can provide separate power buttons on the touch screen for them (some people they want to keep power always on, claim better sound).

If the customer is never going to use the climate section, you could consider to edit the project's defaults to use the 'climate' hard button to flip to the 2 channel pages and change the 'climate' text to 'CD' or so.

When finished, don't forget to remove the dummy PTX3 from the project, otherwise the project will not upload properly.

It's a bit much work I have to agree...

That's just nuts. Thanks for the input RobSmit. This thread will stay alive if everone shares their SB/Prodigy experiences.

Good idea!

Nothing better than a program with 20,000 warnings and notices.

LOL!!! that sh*t was funny and true.