IP Controllable Devices
remeolb
Posts: 79
Does anybody know of any TV's that are IP controllable?
Does anybody know of any BluRay players that are IP controllable?
Does anybody know of any BluRay players that are IP controllable?
0
Comments
Jeff
If Samsung would give us a peek under the hood so we can control them via AMX, that would be sweet.
I?ve got a few Digi One converters in my house for a Beta Brite and caller ID boxes.
I set them up with static IPs and use UDP instead of TCP. Then in my AMX program I just open a UDP port one time and then treat it exactly like an RS-232 port. Using UDP I don?t have to worry about reopening ports and making sure a connection is established before I send. I just send.
If the end device is there then it works, if it?s not there then doesn?t work. As soon as the end device comes back everything works again with no extra work involved. Same as if you plugged in or unplugged an RS-232 cable.
Just wanted to throw that out for an option even though built-in IP support would be the way to go.
Do you use UDP for all IP connections? It sounds much more straightforward than trying to maintain a TCP connection.
This is interesting to know, especially if there is a way of discretely staying in the Internet@TV mode. Does the remote app support input selection?
If so, as we sell Samsung TVs, I might write a module for this...
I would definitely love for you to do that!
Any info would be greatly appreciated. I have the protocol for the 5000, but it's a single disc changer (or at least I don't see any commands for disc selection).
The DIGI series is very reliable on TCP if you check the box for RECONNECT AUTOMATICALLY. No connection maintenance has to be done in the NetLinx, but you get the benefit of diagnostics that can tell you that the unit is connected.... or not.
Yes, I’ve seen the reconnect option so I assume you are using the Digi as a TPC Client since the TPC server doesn’t (can’t) offer auto reconnect. Correct? Aside from assigning the port number you also have to assign the IP of the Netlinx master that the Digi is supposed to connect to.
<disclaimer>I’m testing against a Digi One SP with firmware Version 82000774_U 11/09/2007. If I’ve already gone off track then the rest of my ramble won’t hold water.</disclaimer>
I also assume somewhere during Netlinx startup there must be an IP_SERVER_OPEN() and when that happens the Digi will connect automatically to the Netlinx server port. Easy enough.
This is where you lose me. You absolutely have to do connection maintenance assuming a reboot of Netlix is not an acceptable workaround when things don't go as planned. Here’s why:
The Netlinx system boots and opens a server port and the Digi connects automatically. If we (Netlinx) were monitoring connections we would see that the Netlinx server port has generated an ONLINE event. So far so good.
Since most systems don’t live in the perfect world let’s test for possible *what if* scenarios. Let’s see what happens if the Digi loses power (or a network connection) so let’s remove power from the Digi.
On the Netlinx side of things everything will appear as if nothing bad has happened for the first 75 seconds to 5 minutes depending on what firmware the NI Master is running. Send a string out to the Digi and Netlix says ok sounds good as it sends the string into thin air.
Now after the Netlinx network timeout period Netlinx generates this runtime message and kills our portal to Digi:
Exiting TCP Read thread - closing this socket for local port <port number>
And then this message:
CIpEvent::OffLine 0:<port number>:<system number>
But since we (Netlinx) are not doing connection maintenance we have no idea this has happened so when we send a string out to the Digi we will generate the following runtime error:
SendString to socket-local port (<port number>) invalid.
Now let’s restore power back to the Digi. After the Digi boots it will try to connect to the Netlinx master but since the Netlinx master isn’t listening anymore (we didn’t reopen the server port) nothing happens and nothing will happen until a reboot of Netlinx.
Unless I’m missing something or have made some incorrect assumptions (if I am please let me know), Netlinx needs to monitor and maintain connections if using TCP. The Digi auto reconnect really means nothing. Well not nothing but nothing as far as making TCP more stable or easier to use; it doesn’t bypass the need for Netlinx connection maintenance.
Rambling continues...
I chose I different route and when possible I like to use the Digi as a UDP Server instead of a TCP Client. Here’s a comparison.
Digi TCP Client - Configuration:
Select a port and enter the IP of the Netlinx master.
Digi UPD Server - Configuration:
Select a port.
Digi TCP Client – Netlinx Startup:
IP_SERVER_OPEN() using TCP.
Digi UPD Server – Netlinx Startup:
IP_CLIENT_OPEN () using UDP. You need to know the IP of the Digi.
Digi TCP Client – Netlinx Runtime:
Connection maintenance required.
Online Event: Flag Digi as Online.
Offline Event: Flag Digi as Offline and do another IP_SERVER_OPEN() after x amount of time.
Before sending a string out we probably should check to make sure the Digi online flag is set unless we don’t care about the SendString to socket runtime errors.
Digi UPD Server – Netlinx Runtime.
No connection maintenance required.
Nothing to do other than send and receive strings as if an RS-232 port is sitting there.
If you unplug the network cable to the Digi as soon as you plug it back in we’re ready to send and receive instantly.
Almost the last of the rambling...
I have an RS-232 controlled BetaBrite in my home that I use to display time, temp, caller ID, etc.
I moved the BetaBrite and the only cable I had readily available was a network connection so I bought a Digi One SP and set it up as a UDP Server.
All I needed to do in my program is add one line of code at startup, the IP_CLIENT_OPEN () using UDP and that’s it. No connection maintenance, nothing had to be changed in my comm module.
Assuming you are monitoring connections in code and it’s not during a Netlinx port timeout period, that’s correct. But that really doesn’t tell us what we really want to know.
I really don’t care about the Digi. I know when that thing is powered with a good network connection and is configured properly it’s going to work. I treat it like a cable which is essentially what it is. I mean I do care and it’s a good thing to know if the Digi is there or not but it’s not what I’m after.
What I really want to know is if the end RS-232 device is connected and working...or not. And whether we’re using the Digi as a TCP Client or a UDP server doesn’t get us that answer.
I’m not saying everyone should use the Digi as a UDP server and I don’t think it’s wrong to use the Digi as a TCP client. I’m sure there are cases where UPD may not allowed and TCP is a must for whatever reason. But if you are using TCP you need to maintain it.
I just like the simplicity and flexibility that UPD offers and I use it when I can.
End of ramble...
It turns out the UPD setup example I described above was for a one-way RS-232 device. I’m not looking for feedback and I’m doing an IP_CLIENT_OPEN using UDP.
The other Digi I have is for my Caller ID box and the best I can tell I’m using it only to receive strings, I don’t send strings to it. In this case I’m doing an IP_SEVER_OPEN using UDP and I configured the Digi to forward all data to the IP of the Netlinx master to the port I’m opened with the IP_SERVER_OPEN.
I know I’ve used a Digi in the past for 2way comms but I can’t find the code at the momement. I don’t remember if I needed to do an IP_SERVER_OPEN to listen on and an IP_CLIENT_OPEN to send on or if the IP_UDP_2WAY option worked.
Bottom line my ramble is just getting worse so I’ll stop here.
I should have just responded the first time by saying if using TCP you need to manage connections and left it at that.
I really need to stop these 24 hour+ shifts.
Oh well...
Why? I find that without my conscious brain getting in the way, I am able to churn out some really good code
Jeff
Indeed, you also seem to just go on and on. I get distracted less when I've been working long hours as well. Though I shouldn't do anything else than programming at that point :P.