Pass multiple devices in DEFINE_MODULE
mstocum
Posts: 120
Is there an easy way to pass multiple devices to a single Duet module in the DEFINE_MODULE() statement? I fully understand how to modify the MODULE_NAME line in the generated AXS file in Cafe Duet. What I'm looking for is if there are additional properties I can set in DUET_PROPERTIES to support additional devices (or some other method which would achieve the same result), and how they'd be exposed on the Duet side.
0
Comments
First the answer is yes! But you have to be writing the duet module, are you? If not, the question that comes to mind is, why? What are you trying to do?
I'm just getting started with Duet, and I was looking to replicate a NetLinx classroom module I currently use. We have multiple classrooms running off a single controller, so I just have a classroom module per room, which gets the vdvs for all of the various devices (projectors, DVD player, touch panel, etc.) and to provide an RMS interface for remote management and reporting. I also mimic certain SNAPI behaviors for the classroom, channel 255 can be used to start up or shutdown the classroom, level 1 exposes is the main program audio level for them room.
So now, I'm looking for the best way to recreate that behavior in Duet. Doing this all in Duet compared to NetLinx may not be the best idea, but I thought it would be a good project to learn with.
But... to answer your question... in order to pass in multiple devices in to a duet module, you got to create additional properties in the NetLinx wrapper module.
Add DEV to the module header
Increase size of the array and provide a placeholder for the new device
CHAR DUET_PROPERTIES[10][47] = { 'Physical-Device', 'Duet-Device', 'Projector', 'Duet-Module=Classroom_dr1_0_0', 'Bundle-Version=1.0.0', 'Device-Category=ip', 'Device-Make=Classroom', 'Device-Model=Classroom', 'Device-SDKClass=com.amx.duet.devicesdk.Utility', 'Device-Revision=1.0.0' }Assign the DPS the properties array.
DUET_PROPERTIES[3] = "'Projector',FORMAT('%d:',dvProjector.NUMBER),FORMAT('%d:',dvProjector.PORT),FORMAT('%d',dvProjector.SYSTEM)";The device list will show up in the "props" of the contructor to your module.
You can also for go all of this, and send commands into your duet module, after the module is loaded, setting the device addresses.
I think that might be my approach. I do realize this is an extremely ambitious project where I am right now, and I have some other smaller projects I'm working on first. With that said, are there any good getting started with Duet documents out there? The tutorial that comes with Cafe Duet is rather, shall we say, simplistic. It's going to be a while before I can get out to Texas for training.
Personally I would probably avoid this. I do a lot of stuff in Duet but have kept all UI on the Netlinx side for several reasons. First, it's just too easy to do in Netlinx given all the built-in plumbing. It wouldn't be an issue to build this on the Java side, but the lack of documentation on how to work with all the event handling classes would make it laborious and frustrating. Second, I've started implementing everything on the Java side to be as portable as possible, so I want as few AMX-specific classes as possible. For example, my serial drivers now reference a SerialPort interface vs. talking directly to a Netlinx port. I use a serial-port factory class to provide a platform-specific serial port class to the driver class. This allows me to easily move to another platform, which I've done for both Modbus and Aprilaire.
As far as adding devices to DEFINE_MODULE, I've stayed away from this as well. Using custom commands to add functionality at run-time gives you a more flexible approach, IMO. I've got an Aprilaire driver that can poll devices on 1..n serial ports. Instead of passing these in through properties I created an "add-port" command that my driver responds to. To me this better fits an object-oriented approach vs. parsing through properties at startup.
Nothing that I have seen, I got Cafe Duet the day it shipped originally and had a very difficult time getting information/help. There were parts of the sub-system that were broken that I had to find work-arounds for and it was very frustrating. When I have issues now I send an email to tech support asking them to please route my question to the appropriate person.
I'm not sure how strong the community is, but something like a wiki or GitHub account where examples, work-arounds, etc. could be shared. This forum is nice, but not really the best format, mainly due to the weak search and categorization.
I would also recommend getting a good primer on OSGi. I have OSGi in Action from Manning Press.
I'm reading OSGi in Practice now.
I have implemented UIs in Duet, and I like it! I have found the UI to be noticeably faster! It is also easy to do Mainline loop style feedback in a separate thread using an inner class that implements Runnable. One of the UIs I wrote uses a 10 item list using 10 buttons, scrolling thru the list is so fast you don't even see the individual button text updating. It is also very easy to scroll thru an ArrayList using the sublist method to return a List interface. Everything is in there you just have to do some digging and make some educated guesses.
I see this opinion a lot in reference to Duet but I disagree for two reasons. First, anything else I write in Java is not going to be written in JDK 1.4, of course code written for JDK 1.4 can be used in newer JDK's, but this brings me to my next reason. If you code using OO concepts, i.e MVC (Model View Controller) it will be easy to reuse the classes that pertain to what you want to do on another platform without having any AMX specific classes required. Besides, a lot of the AMX classes are helper classes that you may want to avoid anyway. There are many classes that try to emulate how things are done in NetLinx, i.e. File IO, that actually limit the power and flexibility available in Java.
I also highly recommend "Head First Design Patterns" to anyone who has not read it yet.
That's a great book, the format is awesome. It basically led me to pulling AMX specific stuff out of the "model/controller" classes into classes that implement an interface. My thermostat class, for example, receives an "adapter" class that it uses to interact with the view side. In the AMX version this is a class that implements all the various NetLinx event handlers.
This enables you to still build a module for interaction with a single device, making this simple and self contained. Even more importantly you can grab a module for device X that has already been build by someone else. From here you connect your modules together using the OSGi services registry. This way you can still have a 'core system' and/or UI module built in Duet if you like, but dynamically wire it to your device control modules as required.
One of the super nice things here is that RMS will be plug and play for you to. Just point it at your device modules using the RMS SDK and you are done.
For some Duet examples keep an eye on the AMX Australia GitHub page. We'll be putting up some projects there over the next couple of months.
Also, nice idea on the wiki sonny. I've put up a shiny new one just for this. If anyone you like to contribute any nuggets of awesome I've left this publicly editable. Feel free to add in links to your own projects, any approaches to specific problems that you've had success with other other general Duet guff.
Cool!!! As I get time I'll upload some stuff I've done.