Regarding:

Inside the sendHeartbeat function, I would again call scheduleAfter to schedule the next heartbeat to be sent. I'm wondering how to ensure that I don't inadvertently schedule more than one timer at a time...

If the Pronto goes to sleep right after I schedule a 20 second timer, I suppose
the timer will still be called about 20 seconds after the Pronto wakes up??

Every time you call the outer function to schedule, you first check a heartbeatActive variable and see if it is true. If that is true, then simply return, otherwise, set the value to true and issue CF.activity().scheduleAfter().

In the function that will send the heartbeat, your callback, send the heartbeat request via async TCP/IP.

When the socket connects and you issue the write then set the heartbeatActive variable back to false. Ideally you'd want to be monitoring onData callbacks to know when you got a heartbeat response because at that time, you'd want to schedule another heartbeat 20 seconds out.

Your thought to use synchronous sockets will work for 1-way commands, but I've never used them as they simply take up too much time and block the pronto user interface (kinda like System.delay()).

So, hoping you see now why I said put a Proxy in place. You could let the proxy manage all this fairly easily with NodeJS. In fact, the Proxy's responsibilty is to keep a good connection to the unit and then the Prontos connect to the Proxy.

Not sure how much you know about Denon/Marantz TCP/IP protocol but the units only allow a single TCP/IP connection on port #23. Hence, I wrote a proxy and as such my Prontos connect to the proxy. I added some secret sauce in the proxy to support commands such as monitor on and monitor off that are absorbed and managed by the proxy. As a result, I can connect to the proxy with my PC, issue monitor on, and then the PC receives notification of the commands that are sent by any Pronto as well as the responses/events that are received.


Note that for my Proxy, I don't have a way to pull events that were received while the pronto was not connected, in fact, I don't recommend it.

Regarding:

EDIT: I don't have a TSU9600. I've thought about getting one in the past, but I like the one-handed operation of the TSU9400, and I didn't want to have to redo all the graphics that I've done for the TSU9400 (although a TSU9600's higher resolution would be nice when showing feedback from a madVR).

I don't think the TSU9400 supports all the IR frequencies that the TSU9600 does. That may be why you can learn the codes in PEP2 but the remote will not replay them.

Find a friend with a 9600 and try it out.

I think these codes may be XMP which may limit you to the TSU9600. Try to get clean codes from the manufacturer and post what you get back here.

Thanks,
Lyndel