On Mon, 03 Oct 2011 10:56:36 -1000 Joel Roth <jo...@pobox.com> wrote:
> On Mon, Oct 03, 2011 at 02:32:15PM -0500, Kent West wrote: > > Yes, off-topic, but you folks are the brightest group with which I'm > > affiliated .... > > > > We're thinking of building a Debian-based web-server that offers up > > a "remote control" interface for a smart classroom in a university. > > We want a web interface so it'll be universal (particularly working > > with mobile devices such as smartphones, iPads, etc.). This web > > interface would allow the the teacher to control the various > > multimedia devices in the room (projector, volume on the sound > > system, doc-cam, DVD player, etc) just by bringing up the web site > > on his Android phone, etc, and clicking hyperlink-type buttons. In > > this way he can power up the projector, tell the projector to show > > the signal from the laptop port in the podium or to switch to the > > image from the document camera, crank up the sound system volume, > > dim the room lights, etc. > > > > In order to do this, we have to convert the web clicks into infrared > > signals going to the various IR-enabled devices, essentially > > replacing the remote controls that came with the devices. > > > > Global Cache (http://www.globalcache.com/products/itach/models2/) > > has devices that, as I understand it, will send out the various IR > > signals to the various devices, based on ASCII commands sent to it > > via a wireless connection. > > > > My problem is how to convert a click on a web page into the proper > > code to be sent over the wireless network to the Global Cache > > device. I don't have the Global Cache yet to play with, but I'm > > trying to get a feel for how to do things before we start spending > > money. The API documentation from their web site indicates it's a > > matter of just sending the correct ASCII sequence out the web > > server's TCP socket on Port 4998. > > > > Here's a snippet from their documentation that might help set some > > background: > > > > >Commands are initiated by short ASCII string representing the > > >command type. Typically, physical address and data information > > >will follow. The structures of iTach commands are described in the > > >following sections. Text enclosed in brackets (<text>) must be > > >substituted by its ASCII definition. Multiple ASCII choices are > > >divided by separator ( | ) characters. > > > > > >Note: Commands are case sensitive. > > > > > >Example: The network settings are queried with the get_NET command: > > > > > >get_NET,<connectoraddress>↵ > > > > > >where; > > ><connectoraddress> is 0:1 (network module address) > > > > > >The command ASCII string sent to the iTach is: > > > > > >get_NET,0:1↵ > > > > > >Note: get_NET command is documented fully in section 5.1 below. > > > > Can anyone provide me a snippet of HTML (and/or related, such as > > php, etc) code for sending an ASCII string (such as the above > > "net_NET,0:1 <CR>") to TCP socket Port 4998? > > > > Better yet, can anyone also provide me a means of testing if I'm > > sending to that port without yet having the hardware in-hand? Like, > > if I manage to send data to port 4998, how do I know I sent it and > > what it looks like on the other side? Change the device to which you are connecting to localhost and 'netcat -l -p PORT' is the appropriate incantation I believe. > > And is this called "raw socket programming", or what? If I knew what > > terms to google for, I might not need to bother y'all any more. > > > > Thanks! > > I think what you need is a web framework that lets you > process HTTP requests generated by a user clicking on links > submitting forms, activating buttons, etc. > > Any modern scripting language will have suitable web > frameworks and socket communication > libraries to accomplish what you want. If I were doing it, I would use python to detect which button was pressed on the last page and send a command out a socket, then regenerate the page again. Python's socket libraries are very, very easy - see http://docs.python.org/howto/sockets.html for a quick rundown. Server side would make this nicer (IMHO), but it might be *easier* to do it client side (the only real difficulty being the client must be able/know how to connect directly to the controller). The only real difficulty would be making it easily extensible. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003162906.346b2...@rbmj-laptop.mason.homeunix.org
