I'm posting this thread as a discussion point and also to allow those who might be wanting Denon modules to be able to better make decisions as to which of the available ones might be right for them.

What a user MUST know
First off, if you want to talk to a Denon Receiver with a Pronto via TCP/IP, there is one limitation that you cannot overcome without having an intermediate controller between the receiver and the Pronto. The Denon can only support a single TCP/IP socket connection for 2-way control at any one point in time. So, if you have more than one Pronto and want them to communicate with the same Denon, RS-232 via RFX9600 is your ONLY solution without investing in a Crestron controller or rolling your own (PC program/controller that acts as message router). Otherwise, only one Pronto can communicate at any said point in time.

Background
In the past, I have developed 2 different versions of Denon scripts. My version 2 script was VERY robust and used lots of regular expressions for parsing (much like the stock Philips script) but was large, bulky, and quite honestly, would not perform when included with EscientPronto, which I also sell.

So, I have been working on DenonTCP version 3.0 for the past few months and am happy to say that it is coming along quite nicely. The few folks that have been using it indeed are very happy with it. I'm hoping to have it available shortly.

Available Denon Modules
To my knowledge, there are several modules available and I will list them as I recall them.

1. Free RS232-based Denon script from Philips (requires RFX9600) Cost? - free with level 1 ProntoScript certification from Philips

2. TCP/IP-based Denon script (TSU9400) by user Tenchi from www.prontoprojects.com Cost? - Free

3. TCP/IP-based Denon script from user Dominator (Dominic) available for purchase. Cost? - TBD

4. TCP/IP-based Denon script from user sWORDs (not sure if it is currently for sale). Availability and Cost? - ???

5. TCP/IP-based Denon script from myself that is currently in late alpha mode. Cost - TBD

Now, let's talk commonalities and differences of all these scripts.

Commonalities
First off, any of the above modules should allow you to send any command to the receiver. That is, there's likely a function you can call such as sendCommand(stringToSend) that will allow you to send a command.

Where the differences come in is in their support of 2-way feedback and general design philosophies. Let's start with 2-way feedback.

Differences in handling of feedback from Receiver
2-way feedback involves receiving an event/response from the Denon and then being able to communicate the data back to the real application (your configuration). For example, to capture the 'MODE' of the receiver, the script must be written to support processing of message 'PSMODE:XXXX' where 'XXX' is the real mode.

Depending on the choice of implementation by the module developer, one might covert 'PSMODE:CINEMA' into a graphical representation of enabling/disabling an image-based widget or simply setting the textual label in a well-defined widget. All of the above modules utilize the latter method and the script being developed by Dominator utilizes both methods. The module by Dominator and for sure the Philips module pop a Volume Bar up on the screen to allow a user to visualize a change in volume for example.

Determining if your module of choice supports feedback you need
So, if you are considering purchasing/integrating a module and 2-way feedback is important to you, you should inquire with the exact number of zones for which you need support along with the set of commands for which you are interested in receiving 2-way feedback. Also include the model of receiver you have. Often, you will need to review a protocol specification (RS-232 spec provided by Denon) to ascertain this information.

For example, you'd supply:

Two Zones (Main Zone and Z3)
PSMODE:
PSSB:
PSCINEMA.EQ
for a Denon 4306

Note that you may only be able to inquire about said functionality from developers who are currently actively maintaining their products.

Let's look at some of the challenges faced by script developers and decisions that are made based on said challenges.

Technical challenges faced by module developers

One thing that has rings true, and caused me to stop selling earlier versions of my module, is that earlier model Denon receivers, for example, the 5805, did not fully support all the "bells and whistles" that the later receivers that have 'CI' certification do.

As an owner of a 5805, I found it hard to write a "one-size-fits-all" module that would work with newer as well as older receivers. I did a fairly good job and finally worked out many of the kinks, but there could still be issues. As a developer, I attempt to develop robust, solid product that does not require many support calls or emails. With the difference in protocols across models, the amount of support required to "service what I sell" was tremendouss and simply did not provide an effective ROI.

The free Philips module, for example, does not do much, likely partly as a result of protocol differences. So, if you choose to use the Philips module, you will likely be writing code to manage 2-way feedback for your particular receiver.

However, there is good news. It would appear that Denon has done a great deal of work standardizing the protocol and supported functions across many of their 'CI' receivers. As a result, I started a complete rewrite of what will be known as DenonTCP V3.0.0.

Design philosophies

With regard to differences in design philosophies, a module may be developed for several different purposes and attempt to serve different audiences.

Let's briefly examine the approaches that have been taken.

Equipment-based Modules
In this mode, the module runs for a single activity for which all receiver functions can be controlled from a set of dedicated pages - Does not normally take into account other tasks/equipment in that it monitors ONLY a receiver. Tenchi's module as well as Dominator's appear to be using this approach.

Task-based Modules
In this mode, the script for the module will likely be used in many activities such as a Blu-Ray, DVD, or Music activity. Certain functionaly pages containing controls such as Surround Mode or Channel Levels are present in each activity. In fact, an integrator may choose to only allow certain Surround Modes based on the Input Source. ie. It may not make sense to allow a Dolby PLII Cinema surround mode in a 'Listen To Music' task-based activity.

Important Note
I am speaking from what I have seen/experienced. Just because a developer designs a module as an Equipment-based module, that does not mean that the script cannot be reused across activities and "shaped" by an integrator to become a Task-based module.

Modes employed by each available module and estimated work to integrate

1. The Philips 232 module

For the Philips script, they provided a single activity that allows you to control volume and view a Tuner screen. The source code is readily available and can be modified as needed. This module is basically Equipment-based and was developed to function as single activity that one could use to control a Denon.

However, due to the flexiblity of having a basic script that supports user modification, a Task-based Module can be developed. Be aware, that you will have a learning curve to figure out the use of scheduleAfter() and repeating page scripts employed for volume ramping. However, overall, this module is really flexible (except that 232 on RFX9600 can incur data loss/corruption if send is done at time notification is being sent by Denon).

A final note on this module is that user must write support for IPod or Internet Radio as it was not provided by Philips.

2. Tench's module from prontoprojects.com

This module was designed for the TSU9400 and was developed initially to be an Equipment-based module. It can be modified by a user to function as Task-based module. As it is free, you can expect that you may have work to learn/support the script.

Note that this module support Internet Radio. I don't belive IPod is currently supported but I could be wrong.

3. Dominator's module

This module appears to be Equipment-based. I don't believe the source code will be made publicly available and support user modification. However, I would suspect that based on the pages presented in the thread regarding the module, the module could be "broken apart" to become an Task-based module.

Dominator has publicly displayed screens for Internet Radio (very nice functionality) and has indicated that IPod support is present may not work properly due to bugs in Denon Protocol.

Dominic, comments please. :-)

4. User sWORDs module

I cannot comment on this module but I believe it was developed to be used in a Task-based mode.

5. DenonTCP V3.0.0 - Lyndel's module

This module was developed to be a Task-based module. Unlike the module by Dominator, DenonTCP V3.0.0 does NOT provide a complete set of nice UI pages. There are pages that have been developed such as Channel Levels, AM/FM Tuner, NetRadio, etc.

This module will require graphic design/page assembly but should NOT require user to know the underlying source code as user modification will likely NOT be allowed (for support reasons).

Just because modification by a user is NOT allowed does not mean that a potential user should disregard the module. I typically bend over backward to service and support what I provide. I also take great pride in writing both robust and bug-free (as bug-free as I can make them) module. If a user is not satisfied or has a problem that cannot be fixed, I will offer a complete refund.

Focus during design was on both performance and flexibility. Denon is notorious for providing ON/OFF commands but not providing ability to 'toggle' a setting. In my module, for almost all available settings, I have provided toggle functions. For example, receiver.muteToggle('Z1');

Another feature of DenonTCP V3.0.0 (and was also present in V2.0.0) is a page-activation function. In an activity page, a developer may code up a function and assign it to the 'onPageActivated' function of the receiver. Then, following assignment of this function, the user is required 'activate' the page. receiver.activatePage(this). Inside this function any command that is available may be issued. What user's normally do in this function is to execute the series of query commands that are used to 'seed' settings in the UI. Note that a receiver.updateUI() function can be used to quickly refresh all settings from the 'settings manager' which is a repository of all values retrieved since activity was started.

One final feature I would like to note is that if an input source change is requested; Ex. receiver.doInputSource('DVD') and the input source is currently the same as the one requested, the command will NOT be transmitted to the Denon, thus eliminating volume dropout while the Denon resynch's the audio DSPs.

Note that input source command can also be utilized in the 'page activation' script. This allows an integrator to develop a 'Listen to Stuff' activity in which there can be Internet Radio, AM/FM Tuner, and CD pages that can be cycled through using Page Up/Down and upon activation of the page, proper input (and surround mode if desired) could be selected.

DenonTCPV3.0.0 has a basic screen for Internet Radio and with relative ease (Does not include preset selection as was provided by Dominator's script). An IPod page ould be developed but has NOT been tested. The underlying code is present but UI not developed or tested at this time.

Again, this module is intended to be used to develop nice, robust, performant 2-way interfaces to your own liking using a robust and performant framework with which you may interact with the receiver.

Summary
Again, I am posting this thread such that someone interested in a Prontoscript-based module to communicate with a Denon is aware of known modules, features available from each module, and design philosophies in place during module development.

I WARMLY welcome comments/corrections to any misstatements in the above comment by the respective module authors. Feel free to submit errata to me via PM or simply post on this thread.

LRM - Edit #1 - edited title for clarity and to correct missspelling.