Why to prefer a Duet Module?
Sensiva
Posts: 211
Hello All...
During my relatively short period in AMX programming , I always see two types of modules
Netlinx and Duet... I knew (don't remember from where) that Duet modules are specificly written to work with VA.
With Radia dimmers , I tried to add its module to the device database, but it didn't.
Then Mr. Doug Hall said
Then I used this module with Netlinx, and the only benefit I had is that I can configure the dimmer using a Configuration webpage.
anything else can be done. Add for this , The module doesn't have all the features of the dimmer so I have to use the PASSTHRU command.
Now my question is : What else can I duet module offer me?, What are they anyway? and Should I prefer it rather than the other Netlinx modules? What can be done with duet and not with anotther?
All I know about Duet is it's written in Java using Cafe Duet and written to work with VA.
Thank you
Sensiva
During my relatively short period in AMX programming , I always see two types of modules
Netlinx and Duet... I knew (don't remember from where) that Duet modules are specificly written to work with VA.
With Radia dimmers , I tried to add its module to the device database, but it didn't.
Then Mr. Doug Hall said
Doug Hall wrote:Sorry for your frustration but our timing was a little off with Radia Eclipse support. Our intention was to align release of Eclipse with VA 1.3 but it did not quite work out. The new release scheduled now for release on Aug 31 includes a new device type "Lighting System" which will allow you to include many Radias but will only show as one "Controller" in the UI view. This will allow you to have one page for lighting control where in the past you would have had one page for each Radia. This release also introduces UI Specific Event Programming that will allow you to have the same button doing different things on different panels. One more thing that you will find useful for lighting is support of user defined variables.
We appreciate your patience and apologize for any inconvenience this has caused you.
Then I used this module with Netlinx, and the only benefit I had is that I can configure the dimmer using a Configuration webpage.
anything else can be done. Add for this , The module doesn't have all the features of the dimmer so I have to use the PASSTHRU command.
Now my question is : What else can I duet module offer me?, What are they anyway? and Should I prefer it rather than the other Netlinx modules? What can be done with duet and not with anotther?
All I know about Duet is it's written in Java using Cafe Duet and written to work with VA.
Thank you
Sensiva
0
Comments
Duet modules can be written as generic modules for use with NetLinx. VA is not a requirement. So think of it as a generic module, just as NetLinx offers. It is just programmed in Java.
If you implement the SNAPI classes it will be usable from VA. It will also be available via standard NetLinx, albeit more work.
You can implement your entire control system programming in Java, right now if you like.
Java offers features not available in NetLinx or %res$ron. It's up to the programmer to take advantage of the options.
Well I knew that VA is not a requirement, just after knowing that the current version of Radia Duet module isn't compatible with VA.... So i started to ask.
Most of the functions are done using channels and levels instead of send_commands and string feedback in netlinx modules.
Also you have a "device initialized" and "device online" channel to see if the device is there.
Also you only have to know the "classes" your duet module has.
If the device has a volume control, it is ALWAYS on the same channels.
This benefit is also used by AMX itself to test most of the duet modules. If you look at the most recent duet modules, they have made a UI-Module for each class and a AXI file for the buttons. They simply include these files and the testprogram is ready :-)
So you have "ITGModule" UI file to do the Version and module version stuff. Same for Volume or matrix switching.
So the main part can be done without reading the manual of the module.
The first time modules are realy exchangeable :-)
The disadvantage is the high load of files to transfer after a compile :-(
Interface design - I have to re-do it anyway, they don't match the rest of my panels. Most of the Duet modules use that horrible "Platinum" design.
I absolutely cannot stand the paradigm of using channels to communicate with a module. I would much rather use a SEND_COMMAND. If the command syntax is consistent from device to device, I don't have to change my code at all if the device changes with SEND_COMMANDS. When it uses channels, you got to go through the whole thing to make sure they are the same. Channels were supposed to be standardized, but the implementation has not been perfect. Because I am not using an AMX panel design, and because I do things rather differently, I also cannot guarantee my button channels are going to work with theirs. SEND_COMMAND bypasses all that fuss.
AMX UI modules are notorious for not working right in any system that has multiple panels or multiple devices. They make no effort to give variables unique names (every one I have seen uses TP_BUTTONS and TP_FEEDBACK ... what if you have 4 modules all requiring the same nomenclature? You have to go through them all and rename them ... mind you, this is in the INCLUDE file, not the module itself, so instancing doesn't apply). It's like they tested them alone on a master. What about working will with the rest of the system? They are getting better, and not all of their UI modules are bad, but I've been stung so many times, I tend to shy away from them.
A good part of my issues, I admit, is because I don't follow the AMX paradigm for system control 100%. Standardization only woks if everyone does everything the same way. Because I do some things slightly differently, the standardization often doesn't work for me. This is []icustom[/i] control after all though. If I wanted cookie-cutter jobs, I'd be using C.
I don't necessarily have any problems integrating the duet modules into my existing code tho. (Part of it is a good sales staff that doesn't change brands and devices like the weather in Michigan, so I don't have to support 15 different DVD players and what not
Jeff
So what's special about Duet modules? Maybe Duet modules are in some magical manner more reliable than the old non-Duet modules. Maybe they get more attention or more love.
PinGo AmiGo!!
That's what I am talking about, till this moment I didn't get any replies that really say What in Duet better than Non-duet?
Indeeeeeeeed.
From what perspective?
Module end user or developer?
Of course from Developer, I don't think end user would care what modules I am using.
There are a number of possible topics.
1. Dynamic loading of code at runtime.
2. Why dynamically load drivers at runtime?
3. SNAPI programming in Netlinx
4. SNAPI programming in Duet
5. Why have a standard API such as SNAPI?
6. You can program solely in Netlinx or Java, and know zero about the other programming language.
You cannot dynamically load Netlinx code at run time. This is why Duet exists. In Java one can dynamically load classes at runtime. OSGI - Open Services Gateway Initiative is the framework AMX uses to dynamically lookup/download/load drivers (bundles).
Perhaps you can be more clear as to what you're looking for.
When AMX posts a Duet module, their goal is a VA compatible driver. This is accomplished by their Duet code implementing the SNAPI.
So... as I don't get most of the possible topics , let's keep ourselves in discussing "What features can duet modules offer me - (as a Netlinx programmer not a Modules developer) - and Non-duet can't?
And thanks for your NEAT answer.
My impression of why Duet exists (conveyed by my AMX instructor, I think) is that it allows manufacturers to provide modules for their own products, rather than needing a NetLinx programmer on staff or AMX themselves to create the module. Whether this actually happens in practice or not, I don't know...
Jeremy
Good question.
All Duet modules are OSGI bundles.
Duet firmware loads two bundles at start.
http.jar
morpheus.jar
If your code defines a bundle that implements a SNAPI interface, then the snapirouter.jar bundle loads, followed by program specified bundles.
This is based on the OSGI framwork. OSGI is implemented in Java, nothing else. C# does not support dynamic class loading.
The point behind dynamic device discovery is to be able to uniquely identify a device, and load the appropriate driver. If the device implements the AMX unique id, then it is possible to develop a Duet driver that leverages the bundle search/resolution loading scheme. AMX implemented their own version of the OSGI search/load framework.
So any Duet module uses all this. You can write a Duet module that does not implement SNAPI in any way. This is the case of my posted examples to date.
VA leverages the SNAPI. This means Netlinx SNAPI compliant or Duet modules. You can also reference a DDP device in VA. A DDP device is implemented with Duet.
By being a Duet device does not imply it implements the DDP.
Why am I attracted to Duet?
It provides a platform to do things that cannot be done on other control platforms. It also did not earn a "free" public encryption crack the week after it was released. AMX can look at your encrypted Duet code, which is an interesting arrangement.
Is the learning curve steeper to pick up Netlinx and it's particulars, or Java J2ME CDC, or Standard Netlinx API (SNAPI) and it's particulars? The argument one could make is Java developers are a dime a dozen. In reality Duet does not implement a complete nor standard JVM implementation. The concepts of which are quite foreign to run of the mill Java developers.
Use SNAPI if you want to leverage a common API and make your code available to use in VA. Coding against a common API is always a good idea. It allows code reuse on multiple levels, and allows better test coverage of your code.
I have found SNAPI is best documented in Cafe Duet.
If you plan to implement SNAPI, be sure to do your homework before you get to the jobsite.