Module complexity - what to include, what to leave out?
HARMAN_Chris
Posts: 598
The LEAP thread, and others of the years brings up an important and timely conversation. When writing a driver, what do you include and when does it become "bloated?"
ITG = the Integrated Technologies Group -- aka the team who make developer resources like AMX created device drivers. In general, we have two rules when creating device drivers:
1) Code for full functionality of the device protocol because every integration project is different and programmers always surprise us in the features they want to use.
2) If it is a configuration item, likely one-time use during commissioning, we generally do not include it.
If ITG is lucky enough to receive hardware to test against, we generally only have access to it one time and need to test all of the functionality while in possession of the actual device. ITG is a relatively small team and it is difficult to revisit a module for feature enhancements that come in after a module is released because there are other requests in the dev que, and the hardware may have been shipped back.
In your own module writing efforts, where is your line in terms of features to include? Do you have a defined list of "must-have" commands by device type? Is your rule to code to the job requirements and nothing more?
Our goal is to deliver device drivers that meet your needs, and easy to use and implement, and ultimately solve a problem for you. We understand that there will always be a gap between what is found in InConcert and the devices you are encountering in your projects. In some cases, you will need to write your own driver or block of code to interface with a new device. When that happens, what are you including? Many variables go into this decision, and I would like to hear from the community on the topic. Most projects do not take into account any time needed for driver creation, let alone a fully developed driver that encompasses all of the capabilities of a device. The risk to the business (independent or company) is a reality that we may never encounter this one-off type device again and any time spent beyond the project requirements is lost revenue.
What are you including in drivers you create?
What would you change in terms of what AMX includes in drivers they release?
Comments
Maybe less the driver itself, but the files around... If you download an module archive, you get the module itself, the documentation and a massive amount of includes and uncompiled module files. I know that these files are the testing environment for the module, with lots of help files and standardisations of the ITG group.
Was I miss since the first days, is an "essential and minimum" implementation and configuration guide. Beginners get confused by all these files when trying to basically implement a driver. The sample program now in the archives e.g. uses functions to send PROPERTY commands, you may copy them, but never understand the background and format of the commands as they are listed in the module documentation. Also it is way too much overhead for a beginner to implement e.g. a simple switcher like the Precis series if he gets a dozen includes and modules with dependencies, instead a simple very basic control example.
What I would wish for from a supporter and trainer view is a very basic sample program, with clear readable commands, channels, etc, that can be compared to the module manual. Just define a panel, the physical port and the duet device, just 1 line to implement the driver module itself, do a data_event..online where the PROPERTY commands are set like in the module command documentation, just 3 or 4 clear code pushes that show a very basic control (e.g. with the Precis, absolute basic CI1O1 etc.), and one or two feedback commands parsing.
I don't have a fixed set of commands I include in a driver. It depends on the device and the protocol used. Some devices use a protocol structure that make it very easy to add a command, while with others every commands needs it's own set of rules. I usually only include what I need, and if it's easy enough, also the things that might be useful somewhere in the future. Because I write the drivers myself I can always come back to them and expand. If I have to do that I most likely have access to the physical device, because why else do I need to expand them? Although it usually is a LOT more convenient to do driver development in the office, or at home, instead of working with the device while already installed, it if has to be done, it can be done.
On the subject of "Our goal is to deliver device drivers that meet your needs", I must say that I avoid AMX supplied drivers if I can. Due to experiences over many years with drivers that don't work as expected I tend to stay away, unless I really have to. If I go into a job thinking I have the correct driver, and it ends up that something doesn't work properly I will end up with time and budget problems. Because I cannot do anything to repair even a small defect in an AMX supplied driver, I'll have to start from scratch.
I work with 2 other control systems, one does not supply drivers at all, the other supplies the drivers as source code. With the first it is easy enough: budget the time to make the drivers you don't already have. With the latter I tend to use the supplied driver, for if something is wrong I'm often able to correct that. Sometimes easy, sometimes not, but at least I can.
With AMX drivers you get a blob of code you can't fix, while management and clients assume YOU wrote the code, so 'why isn't it working?'
I totally understand the problems of making a gazillion drivers without having the devices at hand and being strained for time. Not to mention future device or API changes. I would not want to do that... But I think the only solution for that is to make it possible for programmers to 'fix' the drivers, aka have a readable and editable source code.
Maybe we can already do something like that with the 'Cafe Duet plugin' that was made available some time ago, but to me that looked like half a gigabyte of duct-taped together software and I quickly gave up on that. But that could just be me.
So in the end I would use AMX drivers if I had the source code for them AND a way to realistically edit them.
A historical example: G4 panel Intercom and SIP Phone use. Long time now but the same issue at the base.
We implemented the AMX modules for SIP/Intercom years back. They worked with small installs but one of our best dealers used our system for a huge home with over 25 panels... and the system crashed endlessly. Things worked with the module defeated, but panels would go offline while waiting for other panels to finish initializing, lather, rinse, repeat. AMX insisted that we use the module or they would provide us no support on the function. As their support only prolonged the agony and offered no solutions, our dealer had to withdraw from the job at a huge loss that we had to compensate him for. And he dropped us and AMX as a result. So we dumped the module and wrote our own, and in the process discovered that the issue with the AMX module was scalability failure in it's too-clever-for-prime-time automatic discovery and configuration. With enough panels, the identification process took too long, and the first panels wouldn't wait for it to complete and be ready to use... so they would trigger a repeat setup which could never finish. If we had insight to the module functions, and ability to use the parts we wanted, this could have been gotten around. Finally, we built our own structure that simply relied on intercom panels being set to reserved IP addresses and everything worked. Extremely costly for us, and damaged dealers and AMX reputation...
All that said, the "sealed-black-box" module policy at AMX is often a curse. If the philosophy were based "how it works" instead of "use this", we'd have liked it better. I understand the issues of confidentiality - some equipment manufacturers regard their API as trade secrets and demand that modules be closed. And I understand the support load of working with inexperienced programmers who struggle with concepts and just want a solution.
The constraints ultimately defeat the purpose.