Heartbeat

alecg

Hi all. AMX noob question here:

What is best practice for generating heartbeat scripts in NetLinx Studio?

Specifically, I'm controlling a Sharp TV via IP. My commands work fine, but after an hour or two, the connection seems to close, after which my commands fall on deaf ears. I'd like to powercheck the TV every 10 seconds or so and if it doens't respond, re-initialize the connection (IP_Client_Open).

Is there a correct way to do this? Or does my failure come from a more fundamental lack of programming knowledge (all I'm doing is the IP_Open command on start)?

Any help is very much appreciated!

John Nagy

Why pummel the unit with needless prodding when you have nothing to actually say?
How about you do an OPEN anytime you have a command to send? If you are still open from a recent prior command, the new open will error but that really doesn't matter... unless you have bursts of lots of commands and don't want to see the error clutter in telnet/diagnostics. In which case, look away, or reset a timer when you open, and skip the reopen if a new command is issued before a timeout you decide works for you and the connection.

vining

Since your com doesn't timeout per sei I would simply set a flag when commands go into my send queue. As soon as a command go into the q I open the the connection and when online I sent a connected flag. As long as there's commands in q I send strings at some timed interval or based on response, depends. When my send q is empty I close and in offline handler I reset the connected flag. My connected flag usually has several states not just boolean so when I go to open or close I can set the connected flag to pending so I don't send or try to open when we're in between opening and closing, vice verse.

alecg

I suppose I didn't understand the nature of the OPEN command properly.
It seems like John's solution is more appropriate for my use case in light of how simple my control requirements are, but I very much like the idea of using a status flag to qualify the need for the OPEN (or any other type of comms structure for that matter). I just seem to have a LOT to learn yet!

Thank you for the assistance, I will post my results shortly.

vining

With open you just need to realize it isn't always immediate and it isn't guaranteed. So when you open you want to verify it's open in the online event handler but since other stuff can happen between issuing the open and receiving the online verification is good to track the fact the the open is pending so you don't inadvertently issue other opens and throwing errors. Then once open only close once the send q is empty but if you already closed but didn't yet receive the offline notification you also want to know the connection is closing so you don't send until you are indeed offline and then re-issue an open.

Http you don't have a choice and have to open/close per command but connection that can maintain are often easier to maintain but that's just extra work for the processor. Either way though is really totally acceptable and I'll go either way depending on my mood that day.

Good luck.

alecg

Having played with this most of the day, I think I understand now.
I did not realize that the controller would manage that connection in its own right and report the verified connection status as an ONLINE and OFFLINE event without any further intervention from me. Following your advice I created a connection status flag with an off state, on state and waiting state. When an ONLINE or OFFLINE Event happens, the flag updates, when I initiate or kill a connection the flag updates, and when a command is requested it first evaluates the flag state before deciding how to proceed.

This is super cool and potentially way more reliable for not losing a command than some of the other systems I've been programming.

Now I'm onto incoming string parsing, but that's an entirely new thread.

Thanks very much for your help!

DHawthorne

I'm a little OCD about run-time errors and hate to deliberately do anything that will produce them. On a finicky IP connection like that, I will run a timeline that closes the client if it doesn't hear from the device in a set amount of time (generally 5 minutes). Then I will run a CLIENT_OPEN, but only if I have something to send. So if nothing is going on for an hour, it will just stay disconnected for an hour. It won't work well, however, if it's a device that takes a while to connect, because the first command after a disconnect will appear unresponsive. But *most* IP devices, you never notice.

fogled@mizzou

Sharp TV's in particular have a 3-minute IP connection timeout. On all the IP-based Sharp controls I use (got a couple dozen running this way right now), I have a standard timeline that polls the device once per minute. I've never had trouble with the device staying online in that situation, the 1-minute poll time satisfies the device communication timeout.

I do, however, still have a problem with Sharp IP connections dropping immediately on connect, if the TV isn't already on. This only seems to happen with the bigger sets, I've confirmed with 2 80" TV's but don't have the same problem with 60" sets. If the TV is on when the IP connection is made, no problem. It's only when the TV is off the connection picks up then drops immediately.

Always something strange, eh?

a_riot42

Everyone has a different way it seems. I don't bother with flags, and I don't care about a pending state, since its meaningless to me since there is nothing to be done until its actually open. I only care if the port is online, offline or in error. If its offline, and a command needs to be sent I open it and in the online event send the commands knowing its now open. If it goes offline, then I open it again if there are commands to be sent, otherwise I leave it closed. If it errors, I wait a predetermined time and then try to reopen if there is a command to be sent. If not, why open a port when you have no command to send? I have found this simplifies things.

If you look at the Kaleidescape module for instance, for some reason it keeps track of many states, offline, online, pending, waiting, closed, open, error etc, as if it was dealing with raw sockets. I don't see any reason to do this, and in fact leads to more errors trying to second guess what the underlying socket is doing. Some devices will close the port after receiving a command, like most typical IP devices like Sonos, etc, and some will not like Extron (I believe). Either way it doesn't matter since if the offline or error event hasn't run since the last online event, you know its open so send away. When the offline event runs you know you have to open the port, and then wait until the online event occurs to send commands. Its really that simple.
Paul

jabramson

I have several devices (mainly Extron equipment) that will send an update when the front buttons are pressed. I keep those devices online all the time and I like the AMX system to update accordingly.

I've have the AMX system essentially "ping" each device (varies by device and connection). It doesn't really matter the command as long as the piece of equipment returns some sort of string. Then on each string data_event I have a counter that resets. In the mainline of the code that counter increases ever X number of seconds. If XY number of seconds have passed without a response from the piece of equipment then the controller will attempt to reconnect. If that doesn't work, then an error message pops up on the touch panel screen alerting the user. Typically at this point the piece of equipment has locked up, the network has gone down, or a cable has been knocked loose.

I've found the offline/online to not be the most reliable, and if a piece of equipment does not come back online, the user should be notified to handle accordingly.

DHawthorne

jabramson wrote: »

I've found the offline/online to not be the most reliable, and if a piece of equipment does not come back online, the user should be notified to handle accordingly.

That's because there is no offline/online flag to track. It's not done on the hardware layer, best I can tell it's a simple "I'm getting responses," or "I'm not getting responses" from the socket, with a timeout.

JasonS

I believe that if the connection is Telnet, AMX uses AYT (Are You There) messages to determine if it is still connected. If you remember back in the day, (NXI's) there used to be a very long delay before a connection timed out.

AMXJeff

I must be old school, but when I actually spend the time to write code for a device, I believe in maintaining state and providing true feedback. If the nature of the transport protocol allows for maintain connection, I will keep the connection open and keep track of the state of the device,

If the transport protocol does not allow for maintain connection, like RESTful and SOAP, I will still maintain state of the device, and provide true feedback.

Although 100% of my device control is done with duet, so that may force me into this mind set.

JasonS

I generally stay connected to IP devices all the time also. My template IP code can be configured with a few send_commands to "tune" it to the device being controlled. I have very rarely run into issues with maintaining an IP connection to a device. I like real feedback too, it makes my job easier, if the panel always reflects the state of the equipment you don't have to worry about things getting out of sync or pushing state at startup.