i think topic starter means "what AMX modules do you avoid?"
to be perfectly honest -> *.*
amx modules tend to hog up the system, are bloated, and can't be changed according to your "wishes".
We write all our modules ourselves and only use the AMX partner website to gather cable pinouts and pdf protocol documents
I have used several of the AMX modules but inevitably I end up scrapping them and writing my own because:
1. They often have bugs and as sure as you like, there's a bug in the one I'm using. Either a comms issue or feedback issue - regardless of which, it can make it almost useless because it's only 90% there or, not worth the time to write your way around it. Example: one of the Marantz integrated amps power feedback issue (a while ago admittedly).
2. They generally only offer basic comms. Example: projectors. You still have to write all of the logic around the module to make it deal with cool down etc...so all you are really getting is a code you can't edit that pumps out stacked device protocol commands. Yes, feedback also if it is all there and working. But since you need to add the logic wrapper to it anyway, I can't justify using this sort of module. If I get a bug, at least I can find it quickly if I have the code.
As an example of what we do in our vp modules, I simply demand SRC_RGB from the module's virtual dev and it doesn't care if the projector is off or on or cooling or warming, the user will get source RGB. Feedback alerts them to the current state of warming cooling etc.
To me, this is an ideal level for an AMX module to achieve.... It's not over engineering the module - someone (well...me) eventually has to write that bit because it won't work unless you do!!
It's a bit like having a car engine in your garage with no body. A very useful thing indeed, but not for driving!
Like most, I will try an AMX module, but often find myself losing hours trying to decipher why some part is not functioning and having to either create a work-around or starting from scratch with the protocol...
If AMX will not / decides to never release the source for their modules, then I do feel that there should be a very robust mechanism for reporting issues and for receiving a swift resolution. Lots of comments on here complain about finding a small flaw (such as baud changes) that render the locked module usless.
Tech support are a great resource and always happy to try and help - apart from when asking for a change to a locked module...
Have a system for posting issues, documentation errors, suggestions for specific modules - prob within the db for Inconcert devices. But have a designated team at AMX review / respond promptly - if modules are required as a core business component, then treat it so.
If AMX will not / decides to never release the source for their modules, then I do feel that there should be a very robust mechanism for reporting issues and for receiving a swift resolution. Lots of comments on here complain about finding a small flaw (such as baud changes) that render the locked module usless.
Tech support are a great resource and always happy to try and help - apart from when asking for a change to a locked module...
I had a problem with the Ademco FBP128 module a while back and I must say that tech support was very helpful. I was preparing to write my own module, but decided to call tech support because it was a simple problem. The module had been updated for the new protocol that was implemented, but it was still polling for information. This will cause problems with the panel reporting properly. I talked to tech support, explained the problem and also explained that I was on site and need to have the problem resolved as soon as possible. The person I was talking with sent a request to the module writer within a couple hours I had a modified version of the module with the changes I needed. I think it was a couple days later that I saw the module pushed to the website.
That has been the only time I've really needed to change the module to fix it. I have had to use the passthru and passback options to extend a module, but that meant I didn't have to deal with command buffering or timing issues.
Like most, I will try an AMX module, but often find myself losing hours trying to decipher why some part is not functioning and having to either create a work-around or starting from scratch with the protocol...
If AMX will not / decides to never release the source for their modules, then I do feel that there should be a very robust mechanism for reporting issues and for receiving a swift resolution. Lots of comments on here complain about finding a small flaw (such as baud changes) that render the locked module usless.
Tech support are a great resource and always happy to try and help - apart from when asking for a change to a locked module...
Have a system for posting issues, documentation errors, suggestions for specific modules - prob within the db for Inconcert devices. But have a designated team at AMX review / respond promptly - if modules are required as a core business component, then treat it so.
i know another company that releases their modules and let's you edit them.
As far as i know, they also don't care for warming/cooling feedback of a projector and stuff like that, don't really get why you wouldn't include that in a module, but that's just me i guess
I would agree that the Ademco Vista-128/250FBP needs to be looked at. I am not getting any commands to the virtual device when a string is received from the real device on zone status changes.
I usually go the route of using the Comm module and scraping the UI module. The Comm module usually puts the commands in a more easily used format, and why reinvent the wheel: just put a new tire on it and inflate!
Most Newer AMX Modules I don't like, because they are too big, too slow, or just too complex.
I should not need to have 15 include files and 3 modules just to talk to a DVD player(I may be overstating this, but you get the point), it is just a little much. Also many of the module do have some bugs in them or they do not have the functions that I am looking for.
More often then not I just use my own modules, because it is just easier to do it that way.
I would agree that the Ademco Vista-128/250FBP needs to be looked at. I am not getting any commands to the virtual device when a string is received from the real device on zone status changes.
I usually go the route of using the Comm module and scraping the UI module. The Comm module usually puts the commands in a more easily used format, and why reinvent the wheel: just put a new tire on it and inflate!
I completely agree has anyone else used this current module "Ademco_Vista_v1_0_7_dr1_0_0" successfully?
I completely agree has anyone else used this current module "Ademco_Vista_v1_0_7_dr1_0_0" successfully?
I was able to trick the module into getting feedback. It wouldn't recognize zone open/close so I created a timeline that ran only when on the security page of the panel that requested zone status every ten seconds. Ademco recommends not using request zone status commands continually, so it times out after 5 minutes when on the security page and exits that page. I spent two days tweaking this hack, which is a complete joke considering the module documentation says it will update the zone status when a change occures. In the future, I will be avoiding security systems as much as possible!
Responding purely to the subject line, I avoid anything without source. In one company's case, any module I have tried simply does not function properly. Guess which.
At least reading this thread, I know I'm not alone, at least in the reasoning of why I avoid closed modules.
The other reason that I doubt you will see a lot of open source modules is because the manufacturers of the various devices often times have a nondisclosure on their protocols. Obviously, the most common devices that require this are security related. I doubt you will get those manufacturers to abandon this practice just because I am guessing they don't want ever high tech burglar to have easy access to the protocols in place. (This would make it fairly easy to know how to at least monitor security panel status given access to the comm network) (I'm also a bit paranoid )
Security by obscurity is an illusion.
I would love to see open-source projects for AMX integration. We all may horde our source code (as we rightly should, IP is an asset), but this would help us all.
I just recently did a job that was a take-over from a company that went under. The house audio was a Russound, and the main theater was on a Denon receiver, neither of which were standard for us. But the equipment was there and paid for, it just needed code. So, to simplify, I threw in existing AMX Duet modules to control both. I had to rip them out within days and write my own. All the aforementioned reasons: bloat, unreliability, and bugs. Modules I cobbled together in a few hours because I had a budget and timeline to meet worked better than modules someone had clearly spent a very long time developing. So, add the Russound CAV and Denon receiver Duet modules to my list of "avoids."
In many cases it boils down to only putting in what you need. In the case of the Russound, I only had to turn audio zones on and off, switch sources, and change volume. I didn't need all the tuner and iPod control the module had included, and it slowed everything else down with its constant chatter. I'm sure tehre are setups where it would have been appropriate, it's just that I couldn't us it in this job. The Denon one, however, just didn't work. It kept locking up; that one is unusable for any project as near as I can see.
I have yet to use a Duet module in a system. I tried one for a Panasonic projector, but it was all of the things that Dave mentioned in the last post.
As I've become a better programmer, I've found it less necessary to use pre-written modules. I have been writing my own for just about everything I use with better and more consistent results.
I have a job we are using the NX-8E module on, and the unit will not communicate with AMX save for the initial status dump.
I've sent debug traces to AMX tech support and now after 4+ weeks of inaction, I still have nothing to show for many hours of work.
I have a test unit (NX-8E) in house now to do some debug myself, but haven't had the time to dig into the problem yet.
So, for now, I have bad things to say about the NX-8E module, and the level of follow-up and support that AMX is providing.
Brad
Hi Brad, I'm sure you may have already searched the forums but here's a thread that has some information on configuring the NX8e to work with the module: http://www.amxforums.com/showthread.php?t=2965&highlight=nx8e. The _comm module has been very reliable in my experience.
GE's tech support is also EXTREMELY helpful. They should be able to walk you through the configuration necessary to make it communicate properly. They know their products like the back of their hand, and they don't give you the standard, "oh that sounds like an AMX problem, you'll have to call them" line. Hope you get it working!
I don't actually think I have ever used an AMX module. I had the benefit of being the second AMX programmer at my old company. The first was a really good programmer who wrote his own stuff. For consistency, I used his pre-existing stuff.
That being said, I have looked AMX modules over in the past. Anything DSP related I have determined to be unusable. It was so much easier for me to write code for the stupid things I have done with audio pieces like Clear One. I actually wrote a pretty large include file for my AP800 to make it flexible since I change things on a monthly basis. I almost don't have to do anything with code at this point, no matter what I do. I can't expect AMX to build the framework for this sort of endeavor.
As far as releasing the COMM portion of the modules, I say do it. If someone takes it upon themselves to change something (probably anyone who comes to this site would change something) in a module, they take responsibility. AMX cannot possibly predict what everyone wants. At least let everyone decide if they want to empower themselves to expand on what was established by AMX. It could save some people a ton of time.
If someone takes it upon themselves to change something (probably anyone who comes to this site would change something) in a module, they take responsibility.
Not to be contrary, but I dispute this assertion. I know tons of people (programmers and not) who would make changes, it wouldn't work, and they'd call tech support and swear up and down that they hadn't changed a line, because they know the stuff they changed isn't relevant to the problem.
As long as it's locked, TS can at least try to help people and know what people are looking at.
IIRC, I was told that the whole locked module thing came around because people used to change the system_calls, and then call TS and spend hours trying to fix the mainline when the problem was in the system_call and the programmer wouldn't admit to changing it.
I think the real solution is to just write your own modules. I rarely spend very long writing a module, and once you've developed a standard you like it's absurdly easy. I can crank out a TV or projector module in 3 or 4 hours, and all of my modules are completely interchangeable. This is not actually the case with AMX modules, as much as they might like it to be. Modules are awesome, and I usually just pretend AMX doesn't offer any of their own, and just always write from scratch.
So, for now, I have bad things to say about the NX-8E module, and the level of follow-up and support that AMX is providing.
Brad
I am going to guess user error. I recently did a house with a dozen of these keypads and the AMX module worked flawlessly. The client was very impressed at the speed and functionality of the security system and the UI for it. I had to write my own UI code/graphics but it turned out very well.
Paul
anyone seen these or know what it means. We are having a problem with a NI talking to GE NX-8E. I am getting this when I use terminal and I have changed several parameters on the sec. panel to what .docs say on the tech forums / GE manuals / AMX downloads. Still no comms. Tx and Rx lighting up. I will talk with GE on monday but i am wondering if anyone here has seen this?
098600010000401204C0A781
and every 5 seconds sends the same thing.
The security people that first installed the security system had ordered an 232 interface on top of the Nx-8e, I would check to see what cards are installed and if you need them. When I spoke with GE Security they were very helpful.
While back, when I was integrating a NI -100 with the Nx-8e, nothing would work. I changed the paramenters many times and no go. I decided then to reboot the Nx-8e panel and like magic things started working great and the panel hasn't failed me once in 9 months. So try to rebbot the Nx-8e afeter chaning the parameters.
Comments
to be perfectly honest -> *.*
amx modules tend to hog up the system, are bloated, and can't be changed according to your "wishes".
We write all our modules ourselves and only use the AMX partner website to gather cable pinouts and pdf protocol documents
1. They often have bugs and as sure as you like, there's a bug in the one I'm using. Either a comms issue or feedback issue - regardless of which, it can make it almost useless because it's only 90% there or, not worth the time to write your way around it. Example: one of the Marantz integrated amps power feedback issue (a while ago admittedly).
2. They generally only offer basic comms. Example: projectors. You still have to write all of the logic around the module to make it deal with cool down etc...so all you are really getting is a code you can't edit that pumps out stacked device protocol commands. Yes, feedback also if it is all there and working. But since you need to add the logic wrapper to it anyway, I can't justify using this sort of module. If I get a bug, at least I can find it quickly if I have the code.
As an example of what we do in our vp modules, I simply demand SRC_RGB from the module's virtual dev and it doesn't care if the projector is off or on or cooling or warming, the user will get source RGB. Feedback alerts them to the current state of warming cooling etc.
To me, this is an ideal level for an AMX module to achieve.... It's not over engineering the module - someone (well...me) eventually has to write that bit because it won't work unless you do!!
It's a bit like having a car engine in your garage with no body. A very useful thing indeed, but not for driving!
:-)
All comments IMHO, of course.
If AMX will not / decides to never release the source for their modules, then I do feel that there should be a very robust mechanism for reporting issues and for receiving a swift resolution. Lots of comments on here complain about finding a small flaw (such as baud changes) that render the locked module usless.
Tech support are a great resource and always happy to try and help - apart from when asking for a change to a locked module...
Have a system for posting issues, documentation errors, suggestions for specific modules - prob within the db for Inconcert devices. But have a designated team at AMX review / respond promptly - if modules are required as a core business component, then treat it so.
I had a problem with the Ademco FBP128 module a while back and I must say that tech support was very helpful. I was preparing to write my own module, but decided to call tech support because it was a simple problem. The module had been updated for the new protocol that was implemented, but it was still polling for information. This will cause problems with the panel reporting properly. I talked to tech support, explained the problem and also explained that I was on site and need to have the problem resolved as soon as possible. The person I was talking with sent a request to the module writer within a couple hours I had a modified version of the module with the changes I needed. I think it was a couple days later that I saw the module pushed to the website.
That has been the only time I've really needed to change the module to fix it. I have had to use the passthru and passback options to extend a module, but that meant I didn't have to deal with command buffering or timing issues.
Jeff
i know another company that releases their modules and let's you edit them.
As far as i know, they also don't care for warming/cooling feedback of a projector and stuff like that, don't really get why you wouldn't include that in a module, but that's just me i guess
I usually go the route of using the Comm module and scraping the UI module. The Comm module usually puts the commands in a more easily used format, and why reinvent the wheel: just put a new tire on it and inflate!
I should not need to have 15 include files and 3 modules just to talk to a DVD player(I may be overstating this, but you get the point), it is just a little much. Also many of the module do have some bugs in them or they do not have the functions that I am looking for.
More often then not I just use my own modules, because it is just easier to do it that way.
I completely agree has anyone else used this current module "Ademco_Vista_v1_0_7_dr1_0_0" successfully?
I was able to trick the module into getting feedback. It wouldn't recognize zone open/close so I created a timeline that ran only when on the security page of the panel that requested zone status every ten seconds. Ademco recommends not using request zone status commands continually, so it times out after 5 minutes when on the security page and exits that page. I spent two days tweaking this hack, which is a complete joke considering the module documentation says it will update the zone status when a change occures. In the future, I will be avoiding security systems as much as possible!
At least reading this thread, I know I'm not alone, at least in the reasoning of why I avoid closed modules.
I would avoid this one at all cost.
Why? I am running the latest Netlinx version and it is and has been working flawlessly since installation. I am using my own UI code with AMX comm.
Security by obscurity is an illusion.
I would love to see open-source projects for AMX integration. We all may horde our source code (as we rightly should, IP is an asset), but this would help us all.
In many cases it boils down to only putting in what you need. In the case of the Russound, I only had to turn audio zones on and off, switch sources, and change volume. I didn't need all the tuner and iPod control the module had included, and it slowed everything else down with its constant chatter. I'm sure tehre are setups where it would have been appropriate, it's just that I couldn't us it in this job. The Denon one, however, just didn't work. It kept locking up; that one is unusable for any project as near as I can see.
As I've become a better programmer, I've found it less necessary to use pre-written modules. I have been writing my own for just about everything I use with better and more consistent results.
I've sent debug traces to AMX tech support and now after 4+ weeks of inaction, I still have nothing to show for many hours of work.
I have a test unit (NX-8E) in house now to do some debug myself, but haven't had the time to dig into the problem yet.
So, for now, I have bad things to say about the NX-8E module, and the level of follow-up and support that AMX is providing.
Brad
Dave,
Which Denon module did you use? I assume you didn't use all of them
GE's tech support is also EXTREMELY helpful. They should be able to walk you through the configuration necessary to make it communicate properly. They know their products like the back of their hand, and they don't give you the standard, "oh that sounds like an AMX problem, you'll have to call them" line. Hope you get it working!
--John
You're right, I was being lazy and didn't want to look up the exact one ... it was the AVR4306 module running in IP mode that I had issue with.
I have thought that a few times too, but NJ is too hot for me, I would wilt in TX.
Beside that, then you'd be the subject of ridicule on this forum.
You can't please everyone. It just pisses them off.
Sorry to make you look it up, but it's good to know which one to avoid. I know they just posted one for a new module. I wonder if that is any better.
That being said, I have looked AMX modules over in the past. Anything DSP related I have determined to be unusable. It was so much easier for me to write code for the stupid things I have done with audio pieces like Clear One. I actually wrote a pretty large include file for my AP800 to make it flexible since I change things on a monthly basis. I almost don't have to do anything with code at this point, no matter what I do. I can't expect AMX to build the framework for this sort of endeavor.
As far as releasing the COMM portion of the modules, I say do it. If someone takes it upon themselves to change something (probably anyone who comes to this site would change something) in a module, they take responsibility. AMX cannot possibly predict what everyone wants. At least let everyone decide if they want to empower themselves to expand on what was established by AMX. It could save some people a ton of time.
Not to be contrary, but I dispute this assertion. I know tons of people (programmers and not) who would make changes, it wouldn't work, and they'd call tech support and swear up and down that they hadn't changed a line, because they know the stuff they changed isn't relevant to the problem.
As long as it's locked, TS can at least try to help people and know what people are looking at.
IIRC, I was told that the whole locked module thing came around because people used to change the system_calls, and then call TS and spend hours trying to fix the mainline when the problem was in the system_call and the programmer wouldn't admit to changing it.
I think the real solution is to just write your own modules. I rarely spend very long writing a module, and once you've developed a standard you like it's absurdly easy. I can crank out a TV or projector module in 3 or 4 hours, and all of my modules are completely interchangeable. This is not actually the case with AMX modules, as much as they might like it to be. Modules are awesome, and I usually just pretend AMX doesn't offer any of their own, and just always write from scratch.
J
I am going to guess user error. I recently did a house with a dozen of these keypads and the AMX module worked flawlessly. The client was very impressed at the speed and functionality of the security system and the UI for it. I had to write my own UI code/graphics but it turned out very well.
Paul
anyone seen these or know what it means. We are having a problem with a NI talking to GE NX-8E. I am getting this when I use terminal and I have changed several parameters on the sec. panel to what .docs say on the tech forums / GE manuals / AMX downloads. Still no comms. Tx and Rx lighting up. I will talk with GE on monday but i am wondering if anyone here has seen this?
098600010000401204C0A781
and every 5 seconds sends the same thing.
The security people that first installed the security system had ordered an 232 interface on top of the Nx-8e, I would check to see what cards are installed and if you need them. When I spoke with GE Security they were very helpful.
Ricardo