What modules do you avoid?
![[Deleted User]](https://w6.vanillicon.com/v2/63a8129e82e83b6a69ca82041981c031.svg)
[Deleted User]
Posts: 0
There has been much discussion on the quality of our modules. Please use this thread to list the modules that need improvement.
0
Comments
When trying an AMX Epson module (Powerlite 811 v1.0) I came across an issue where the module would go through it's cool-down cycle. However, the internal cooldown counter rolled around to 65535 after reaching 0. This prevented me from powering up the projector for over 18 hours. Not good, particularly when it was in a "high corporate power" meeting room.
I like tighter control than what the AMX module affords. I.e. If I tell the projector to turn on or off while it is cooling/warming, my module keeps hammering away (every 10 seconds) until the cooling/warming cycle is complete, then sets the appropriate power state. On some projectors, cooldown times can vary depending on room temperature. Since room temperature is beyond my control, I can not rely on a counter.
FWIW - I use RMS, so my modules also track online state of the projector. Occasionally a projector will miss a command or two (especially druing warmup or cooldown). My module takes this into account and presents the online state as a vdv channel. This prevents false triggers for RMS alerts.
Roger McLean
Swinburne University
Another module that was lacking when I checked it was the Ademco Vista###BP module. There was a firmware change in the product line that briefly broke most of the functionality of the module, but I worked with tech support to fix that problem. (It was polling and the new firmware didn't like it). The last I checked, the module still didn't support the reporting of the zone status properly. There are also a lot of events that are not handled by the module that were added in the new firmware.
Those are the only two that come to mind at the moment.
Jeff
With only one or two exceptions, I stay away from the UI portions of all of the modules except as a reference.
Okay, now that - that's out of my system.
Hi Brian, hope all is well!
The client always seems to wants something the module doesn't offer, or they won't work in a large TP system. You know my feeling on modules, open up the source code and I'll use LOTS of them. It would save me so much time building my own - like so many of us do.
The number one reason I started using Request/Kaleidescape is because they have an open source module which makes it easier to start from when building my own module. I think other companies have to realize there is no Holy Grail inside their modules, just code. They make life easier for us, we in turn recommend and sell their product.
Gary,
I agree to a point. I am not sure that completely open source on the modules would be the best thing. I know you and (probably) most of the people on this forum either have the ability to make the changes they need, or at least understand they don't have the ability and avoid making changes. (They might even learn some things about writing code). I am worried about Joe programmer that was thrown into this game by an ambitious owner and he starts making "just a couple changes that couldn't possibly do harm". Then all of a sudden the module is just slightly screwed up and he calls into tech support because the module isn't working right. They ask if he has made any changes and he assures them he hasn't because his changes absolutely could not have messed anything up.
The end results will likely be higher product costs due to increased tech support calls, longer hold times and problem resolution with tech support, and the first trouble shooting step for every module problem will be to download the latest module from the AMX site and run it by itself. (But, I'm a bit of a pessimist
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
I would like to see AMX possibly release module source to highly qualified programmers as long as the nondisclosure thing isn't a problem. The question is how to qualify people. Maybe leave it to the reps, maybe make a separate test, maybe have a lottery
Jeff
First, Joe is a good programmer, let's leave him out of this!
I understand what you are saying, but I can't agree (nothing personal
I believe this is why we have the 50 page warning when we buy microwaves (like don't place bird, cat , dog, child, etc in microwave). If you change a module then you are responsible - end of story. I'm tired of protecting ourselves from the stupid people.
I can't think of... or would I EVER use a company's product that did not make their protocol available to a programmer. I've received protocol from every security device I've ever programmed. I also have no problem signing a disclosure form before a company releases their source code. I'm not sure why they do this, as it is only code and most of the time not very good code at that.
I know someone might say GSLogic sells modules with locked source code, and this is true, but these modules are either applications (games) or customized device control modules. If I was selling a device the first thing I would offer -- "open source code."
Next, I would like to say "the secret word".... now where is my prize?
Lastly, Gary, if your in my area, give me a call and we can discuss this further over lunch .... I don't have my microphone with me, so I can use my voice recognition. Also,I am having some weird problems with a bit of code... and it needs to be installed tomorrow morning. And I wanted to list one more reason, but I'm so consumed with fixing this code so I can go home, I forgot what it was....
Jeff
Interesting, as I just used the duet AP module for the first time a couple of weeks ago for an Optima and a Precis. I found it to work really well, better than I initially expected. It was a bit of a trick to figure out how they set things up, but once that is understood I was impressed with the speed and accuracy of the volume control and switching. The Precis has a 10 band eq as well as tone controls which aren't implemented yet but of course pass-thru is always an option. It would be nice to be able to walk around the house with a panel and tailor the eq for each room. Shouldn't take much to add it to the module.
I will usually try and use a premade module before writing a new one (I'm lazy). Most modules I have found to be pretty good with no real disasters yet. That said, they all have their quirks that are a reflection of the person who wrote them.
Paul
My number one complaint is AMX UI modules are not optimized to work well on large systems. They are fine with one or two panels, but get into a situation where you have a dozen or so, and the lack of optimization brings the system to a crawl.
Among the evil tendencies:
1) They update feedback more than is necessary. If the page is not displayed, or the data hasn't changed, it doesn't need a feedback update.
2) They tend not to sync feedback when a panel is rebooted, or if the data changed when the page wasn't displayed. The first time you go to it, or if you switch away and back again, it may be showing old data.
3) They are hard on resources. If you have a dozen panels and need to include a dozen UI instances, it eats up memory fast. For some devices, I understand this is necessary (like media mangers where different meta data needs to be stored for each panel), but others could be handled just as easily with an array of panels and one instance.
All I know is that there are modules out there (AMX or non-AMX) that break my program and I have no way of figuring out why save watching the diagnostics window and cyphering from strange error messages what might be going wrong.
AMX Modules that I do like and seem to work pretty flawlessly.
iPort written by Jon.
Lutron Homeworks. (I'm even able to run all our systems at 115K baud with some slight modifications)
Ademco Destiny 6100.
AMX AS16
Modules that I don't like.
MAX
i!-Weather
Matrix Audio - (I wrote my own.)
Autopatch - (this is one I honestly don't know why you'd write a module for it. It's a very simple audio matrix switcher. I just do it in code as an include)
And that segues into another part of this disussion.
I tend to not use modules that much because in most cases I spend less time just doing it myself. For me the process of working with a new piece of gear is as follows.
1) set up a test situation. hook up the device and see how it works.
2) hook up a controller and see how it communicates.
3) see how it responds to normal use situations.
4) implementation of the code and the user interface design.
5) migrate all this into working project/code.
Obviously, how long each step takes is dependent upon how complicated/simple the gear is and whatnot. For simple devices I'll just usually write the code right into the working project or create the include on the fly. If it's something more complicated, I'll get mor formal in my approach.
In a lot a cases if I try to use a module it adds another 'virtual' piece of gear in the chain. And subsequently one or two more steps in the process. 1 of getting the module plugged in and working, another of ferreting out physical communication problems without being able to see what the software is actually doing. If something's not working and you have a relatively new module, you spend as much time trying to figure out if the problem is something to do with the gear, connection, or the module.
My general rule with modules and whether or not to use them is: If I'm spending more than 20 minutes of my time trying to figure out what in the hell is going wrong with a module, I'll put it away and do it myself. I'm not going to spend half my day solving someone elses problem particularly when I'm flying blind. I have enough trouble solving my own.
And this leads to another more 'gestalt' comment. I personally think the whole 'AMX writing modules' approach has done damage to AMX as a solution in general.
It promotes a lot of laziness on the part of in-the-field programmers. I don't know how many times I've seen on this forum a new user poke in and and ask if anyone here has writte code for a such-and-so box, and if they wouldn't mind sending it to them. I'd be, quite frankly,embarrased to do this.
I have no problem sharing code and do so quite often here. However, the practice of this is to share ideas and new ways of getting from point A to B. It is not supposed to be a <insert Big-Box store name> where you can go to isle 34 and grab what you need to controll a home theater. C'mon, do we really associate Big Box store with quality?
And while having more centralized control of code writing is more streamlined and more conformist in nature, there is still the harsh reality that AMX is very busy trying to run their business and cannot possibly be on top of the game when it comes to the bleeding edge of technology that is inherently not part of what they do to pay the bills. I can sympathise with this completely. Their world should not come to a screeching halt just because <insert brand name here> has put out a firmware upgrade that breaks all the code in thier module. It's too big and chaotic a market to even try to take that on with any measure of success.
We out here have to deal with it as part of our daily work. I would much rather AMX spend its time working with us, making us a better and more limber programmer community that can rapidly respond to the changes. Not because we're better or worse, but because its our jobs. We do it because we have to. That's a pretty inspired work force if you ask me.
I'd much rather they make me a better fisher-person than to keep handing me different colored fish that kinda-sorta work.
I'd much rather see AMX put more resources into better product development and implementation. Not to get sidetracked, but that is an area that is pretty weak right now. I'm not saying more stuff. I'm saying reliable bullet-proof stuff that fits what's going on out there. There is a lot of processes and products that AMX runs and sells that are already getting their rear-ends kicked but they have so much investing in them that they dare not improve or get rid of them.
I'm not meaing to sound harsh. I'm not questioning anyones skills or talents. I think it's more to do with the dynamics of running a company this way. It's too controlling and bulky and is unable to move with any agility.
I'll quit now since I'm wandering off into the weeds with my train of thought. I'll end with the previous mixed-metaphor.
AMX is stuck between a rock and a hard place on this one. They have to write modules. I can see how you would think they don't from a programmers perspective, but from a business perspective, they have to write modules, if for no other reason then they can say that they write modules.
For a small business owner trying to decide between signing up as a dealer for AMX or the big C this could be all the difference. The boys in blue have modules and if AMX tells this small business owner, "sorry we don't write modules we recommend hiring a *real* programmer," who do you think this small business will want to sign up with. I'm not saying that's the only reason, but they can't not have modules.
So if they must have modules and they have to support these modules, they also can't let anyone make changes to them or has already been stated, tech support will get bogged down.
If you don't like the modules, then you don't have to use them. Personally, I like them. I've had problems with them, but some of that can probably be traced back to improper implementation, or my misunderstanding of the documentation. I also used to not like the Autopatch module, until I realized that I had implemented it wrong.
With that said I have had problems with modules, that were the fault of the modules, at least I think they were.
For instance, the Somfy RTS module was talking at 1200 and the device wanted to talk at 9600. It would be nice if you could change the baud the module is talking at with a properties command followed by a reinit.
I've also had a problem with the AudioControl M2 Surround Processor module. When I was using this module the program was slow and virtually unusable, I isolated the problem to this module and when I removed it the program worked fine. I ended up writing my own module for this device.
I've also found some of the documentation to be confusing or misleading, but can't remember a specific example.
Overall, for a new programmer, the modules have helped me a lot, because I don't have a large library of modules and code I've already written, so the modules have saved me time more then they've cost me time.
I just had the pleasure of going through a training class for a different C company (Not THE big C
I would say that 85% of the people attending the class had never programmed anything other than maybe a pronto remote before getting to the class. Some of the people there were working for very large and respected A/V companies. I would guess that most of the integration programmers out there started as A/V installers/sales people and learned some programming along the way. I was reminded that not everyone has a logical mindset when I saw a few people fail the certification practical (It was OPEN BOOK and the problems were word in a way that they were almost the answers). I would not call most of the people I saw failing "stupid". In fact, they were very well spoken and had a good handle on what they wanted the system to do, but their brains just could not mesh with logic of programming for whatever reason.
Obviously, a company cannot target those individuals, nor can they target the top 5% of users, they have to target the majority. In AMX's case, I think they are getting better at targeting the majority without limiting the top 5% of programmers. I hope the result of AMX making it easier for the average dealer to spec and install their products reliably will mean that there is an increase in product awareness in the market as a reliable solution. This will hopefully translate into more product sales which can make it easier for prices to stay competitive.
Well, I think I'm starting to ramble, so I'll wrap it up.
Jeff
You have hardware I can screw with. I can wire cables wrong, fry the ports, invert polarity, do tons of things and not tell your tech guys about it. Part of the tech support is figuring out what stupid thing the customer did and they wont tell you about. How is this any different? If the module isn't working and it should be, tell 'em to download it fresh, that it might be corrupted or something.
I write most of the modules I use. I've written modules for all the projectors in my building, so when a projector goes down, I just swap in a different model, change the module declaration, and away we go. The only module I'm currently using that I didn't write is the Tandberg Duet module for a single 6000MXP I have.
Which brings me to another issue, that doesn't quite fit here. Is it just me, or are a lot of these projector modules not actually plug and play? I tried doing the projector swap I previously described with AMX projector modules, and had the inputs and power all sending different numbers for different things. Thats when I changed up and started writing my own. Was I using AMX's modules incorrectly, or are things not actually as universal as they could be?
J
Problem with doing things this way is what do you do if you have more than one switcher? Now your include needs a lot of variable name modifications to take care of that. If you had used a module then one more line of code takes care of it.
I am surprised so many people are intent on writing their own modules when there are so many out there already written. I love it when I have a prewritten module to use as then I can spend more time on the user experience rather than dealing with the low level stuff.
As for the open source model, there is no reason that it can't exist alongside what AMX does, in fact I think it would be better if they weren't involved. Got a module that you want to share? Post it here and we will critique it and hopefully make it better.
http://sourceforge.net/projects/netlinx-modules/
Paul
I'm sure there are other reasons, intellectual property is the first one that comes to mind, standardization another. But the fact is that they do not now, and apparently have no intention to ever, make their modules open source. It's also apparent that this is a business decision on their part so I would not expect it to change unless something changes externally to make them reconsider.
I do think you have a valid point and I think if AMX was to do this along with a code Wiki that they supported it could be something really good. But I also think that they've made a decision that they're sticking to.
My current include can deal with up to 10 switchers. I can easily midify it if needed as wellto deal with more The limitations It's not really a big resource hog compared to modules.
I don't think I am following. With an include, all variable names have the same scope. So if you are using a variable named currentOutput and you have 3 of the same switchers, you now have to modify things so that you have currentOutput1 , currentOutput2, currentOutput3. With a module you just declare another module and that variable is local to the module so no scope issues crop up.
What file transfers are you referring to that would be quicker?
Paul
I don't see why you would need multiple instances of the same variable. Only one switcher gets switched at a time. Also, arrays are your friend, if you do need multiple instances.
File transfers? Sending the compiled files to the master. Watching a program with a Duet module load is a painful experience, even at 100T.
I'm not trying to say that using multiple instances of modules is not an efficient way for a programmer to manage this sort of thing. Especially for those cases when you really don't feel like getting into a protocol, for whatever reason. But, it's much more than adding one line of code. You use up one line of code just declaring the virtual device. You still have to figure out, and program, which instance of a module gets triggered under particular circumstances. You've probably got touch panel stuff to do. Maybe modify button number arrays that apply to the UI module. It's not a daunting task, but it has to be done. Same if you are using an include file. It doesn't seem at all obvious to me that using multiple instances of modules is significantly more efficient (if at all) than using a well designed include file.
If you are keeping track of volume, mute and switching status then you would need an array with a different name for each switch wouldn't you?
I know what you mean, but it isn't a big deal to me. It isn't the file transfer that takes so long but the initialization and startup of the Duet code. This will likely speed up as the technology improves.
I have never timed myself but I have had to redo a few includes due to variable name overlap and it wasn't fun nor was the result particularly pretty. Modules are set and forget. I wrote a DirecTV module that requires one line of code for the module definition, one array for the channel numbers, and that is all the configuration required (not counting device definitions/arrays as they are required regardless of the method to control them). One DVR or 20, controlled by one R4 or 20 Modero's? Doesn't matter, no extra code or modification is required. Can you do that with an include as well?
Paul
I think the point we are missing is not if AMX should have modules but if they should be locked. AMX must have modules for their dealers, but modules have become an illusion. Most modules are designed for a single panel system or they just don't work properly for a custom system design, which is what I thought AMX is all about.
Here's an example:
Take a look at the Request module which is a good starting point for a module. If you use this module as is - in a large system (say over 8 panels) you'll have a processor that is crawling. The module is set up so you have to add a module for every panel, the size becomes unnecessarily huge. My theory has always been that if a panel is not viewing a section (music, theater, security, etc) you should NOT send ANY data. The present modules AMX offers are either sending data all the time and/or you'll have to duplicate the module for every panel.
Locked modules were designed for devices like Tandberg, Polycom, etc - one device in a single system with one touchpanel. Yes you got it, the corporate world!
You can't learn or improve, unless you can SEE what they are doing.
Like President Reagan once said "Mr. Gorbachev, unlock the modules"
All,
Great discussion and very thought provoking comments. You got to love the passion.
Mine gives better status and doesn't hog the system.
Modules than have given me grief are:
Matrix Audio module first when they changed the baud rate of the device and didn't publish that fact and then when I found this out but then they didn't update the module to accomadate the baud change for months and of course wouldn't give me the source of the comm module. So I got to spend a week writing and adapting my own.
Fujitsu PD42xx?? something which just didn't work. I'm sure I complained about back when I had to write my own which I believe I subsequently posted on the forum.
Runco VCS2X projector module which I recently complained about just didn't work either. It wouldn't even complile with out modifications. Constants are listed in DEFINE_DEVICE, other constants that were called in the code weren't defined anywhere, a real mess.
I do like the fact that this is being addressed by you guys cuz at times it seemed you guys didn't care or should I say your resources were stretched so thin that no one was available to care. This thread is a good omen!
Further to this I understand why AMX has decided to use Duet Modules, however personally in most cases I would prefer not to use duet based communication. I had a situation recently while using the Harmon Kardon Receiver module from AMX that has driven me to change from using Harmon Kardon Equipment. I have a copy of the extended rs232 codes, but couldn?t get the communication protocol correct, myself and 2 other programmers f**ked with it for about a week before we gave up and used the Duet Module which functioned straight away. It was really frustrating to know that we were sending the correct codes ( verified with telnet etc ) but something in the COMM module was different than what was listed in the protocol so we couldn?t work out how to set it up ourselves. I find that it a lot of circumstances the modules provided are too all encompassing or either the reverse is true and there is one feature that is really hard to implement because of the way that the module works.
Personally I wish that there was a Duet Version of the Module ( for general download ) and then a special password protected side of the website where accredited programmers can get non-duet versions of the same module. The reason for this is that a lot of us now are being asked to update existing installation, I find myself quite often using say an NI-700 slaved to an old Access Cardframe and running duet module via an Access cardframe can lead to heaps of problems.
There are no easy solutions to this, AMX is basically damned if they do or damned if they don't. I have to admit thought that I use modules as a last resort, I always prefer to write the code myself, maybe I am just naive, but I think that it's the better way.
Radio Ra - it brought systems to a halt and I received no reply for support- pulled it out and the problem went away
Polk XM - worked great for one tuner but adding a second causes the feedback to disappear for no apparent reason.
Autopatch Precis - could not locate any documentation that explained all of the parameters and the basics would not work
Pentair Intellitouch - never worked
Apex Destiny 6100 - does not matter any more- they have discontinued
I know on some modules you have to set the device properties with a SEND_COMMAND and then send a 'reinit' to update those changes. Would it also be possible to do this with the baud rate? That way when a manufacture changes a baud rate we can change that aspect of the module.