AMX control of Cre$tron lighting
bwestlake
Posts: 82
I am nearly done with a job where we pulled out 10 tons of Craptron and replaced it with 5 tons of AMX. You can now actually control everything. The house has a large Vantage lighting control system, which works great. For some unknown, but idiotic, reason the previous integrator put Cre$tron lighting control in the pool house. Is there any reasonable way to control these panels with AMX? Probably a dumb question but I'm sure it won't be my last.
0
Comments
Ahh good, I thought I was the only one who believes that Craptron truly is rubbish. Good to know I'm not alone.
I've never actually used Craptron lighting but a quick poke around SpasticWindows (probably not PC, how about FunctionallyAndStabilityChallengedWindows) seems to indicate they're all Cresnet.
If that's the case you've got two options I can think of:
1) Retain one ******** control system to act as a gateway. Open a socket connection to the ******** from the AMX master and implement some form of API to provide control of the lighting.
2) Reverse engineer Craptrons XSIG protocol so that your AMX can look to the Craptron as a native Ethernet device. I seem to remember it's a pretty simple protocol.
A third option if you're not comfortable with the Craptron programming side of the suggestion in point 1 would be to retain a Craptron control system as a Cresnet gateway but to implement a PC app using the Craptron ActiveCNX .NET SDK which provides a gateway through which the AMX can talk to the Craptron.
Any way you look at it's a bit ugly.
Is it central lighting? Keypads? There is Infinet stuff and wired stuff. What do you mean by "panels?" Lighting panels? So it is central? You'll likely have a PAC2 or PAC2M in the same enclosure, and yes, this would be Cresnet. Write a simple module and have the AMX talk to that - that'd be your easiest bet. Connect all your loads to your module symbol...should be easy.
You can use Cres's native protocol if you want - it is documented. It might be easier to write a Cres module to listen to AMX commands rather than try to directly control digitals or analogs via AMX.
And, if all you have to do is control one or two cresnet devices, you don't need to know a whole lot about Cre$tron programming to do it. You don't need much logic stuff or anything, pretty much just program something to parse some strings and you're on your way. Rudimentary string parsing is pretty easy. If you don't have anybody familiar with the Cre$tron stuff, it might be a little tough, though. Probably have to hire a independent Cre$tron programmer for whatever the minimum time is.
All entitled to our own opinions. I'll be losing as much sleep about your comments as the powers that be at ******** will be losing over mine.
I'm always happy to back my comments up with empirical data. Feel free to PM me if you would like a rundown on why I hold the views that I do.
Agree on the filter, I'd be perfectly happy to use the real company name most of the time if I was able.
Nor do comments like that FWIW.
There is a C******* processor connected to the system and functioning. I wouldn't be intimidated by using AMX to control the other but I can't find anyone to get me a copy of the C******* software. A dealer for whom I have favors for told me that the Crestapo would take legal action if they got caught.
The worst project I have seen was a Cres system, but I see far more messed up AMX ones than ******** ones around where I am. Both environments have their flaws. Sadly, some of the worst with AMX have to do with training and users who are tasked to write code for systems who never take it farther than what they learned in training - basically, doing it wrong to begin with and never fixing it. Some of the stuff I've seen puts the copy&paste nature of Cres (aside: give us metamodules or something!) in a good light.
Bad programming is bad programming. I think C-tron sees more of it because of their distribution model, but you're right, it happens in the AMX world too. I knew an AMX programmer who, as a matter of course, made CALLs (pre-FUNCTION days) that were one line in size ... I mean really, what's the point? He was just enamored with CALLs and had no real idea how to use them properly. That and one-letter global variables ... what a mess trying to figure it out after the fact.
Awesome! I've had to dig through some fairly large old AMX programs...touch panels defined as "TP" are a treat.
That's funny. Could have been worse -- could have used 'T."
I shouldn't be so smug -- just the other day I was looking at some code that I wrote several years ago that was throwing continuous whiney error messages about trying to access elements of an array beyond the size of the array. Variable defined as nVariable[20] and trying to access nVariable[21]. I tried to figure out what that section of code actually did and I couldn't do it in the brief period of time that I had available, but I did figure out that it was important. Fixing it so that it no longer tried to access nonexistent subscripts wasn't hard, but I never did figure out what in the hell I was up to when I wrote it.