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.
Thanks! That's what I did, and heartbeats work great! I got TCP working with the MadVR Envy. It also receives replies and any notifications from the Envy.
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()).
Yeah, I decided not to use synchronous sockets. I got the asynchronous method working just fine, so no need for synchronous sockets. I also recall having trouble with synchronous sockets years ago with an old Dune player.
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.
Probably if I had more components that use TCP, I would use a 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.
I have a Marantz processor and a JVC projector. They both support TCP, but so far, I'm still using RS232, which works great. If and when there's some feature specific to TCP (and I have more time), then I'll work on TCP. And then a proxy like you mentioned would start sounding good to have.
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.
Well, as the saying goes, if a tree falls in the woods and noone is there to hear it...
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.
It turns out I needed to hold the Envy remote almost touching the Pronto remote to teach the codes (less than 1" away). I was holding it about 4" to 6" away, and the codes weren't being learned. Later, I replaced the batteries that shipped with the Envy and I can hold the Envy remote 4" away and teaching would work okay. Anyway, now that the IR codes have been learned by the Pronto, the Pronto can send the IR codes just fine (either directly from > 10' away or more or using the RFX9600 to send the IR).
