Luup code / plugin to listen on tcp port

Is it possible to have luup listen to a port
For incoming data? The read it when it
Comes in?

Yes, absolutely. The Lua Socket library is just the thing.

Are you sure this is actually what you want? The Luup extensions in Vera allow a very easy HTTP server implementation which is handy.

Of course, if you have a specific device with TCP requirements then fine, go ahead. You just have to be careful with LuaSocket not to have the read block, or you may cause the Luup process to restart. Usual procedure is a (very) short timeout on the read in a loop with a modest delay (say 1 or 2 seconds) if you can stand the latency.

I’ve used this for UDP, which is even easier, since it doesn’t require a handshake. You should be able to find example code with TCP protocol though.

Have a link for the tcp built in to luup vera?

See Register Handler.

Hmmm that seems useful, but my device sends just raw json to the ip and port i specify on it.

Is this something i can do native to luup vera

Example: the wifi device as status changes sends json string to specified tcpip and port. My plugin would watch that for incoming data and then process.

Ended up using this to get me up and running

local socket = require("socket") local server = assert(socket.bind("vera ip", 10000 )) local SOCKip, SOCKport = server:getsockname() log('Roomba Socket Server Started: '.. SOCKip ..':' .. SOCKport ) while 1 do local client = server:accept() client:settimeout(10) local line, err = client:receive() if not err then client:send(line .. "\n") end client:close() end

If you run this in the LuaUPnP image … it will likely destabilize it.

What would you say would be the best way to handle this? Code something as a shell script and have it pass off to via wget and http handler?

Yeah, I would count that among the candidates.

If you can’t coerce the other device to produce different output, you’ll need some kind of adapter to convert the device’s JSON to a Vera HTTP call. That could take the form of:

  • A small Lua process that runs on the Vera but outside of LuaUPnP. It listens, then sends port-3480 GET requests to localhost that your plugin device acts on. No need to register a handler. See the UPnP Event Proxy plugin for prior art.
  • A small program in $your_favourite_language on some other always-on computer that does much the same thing, relaying to a GET request at port 3480 of your Vera.

You haven’t said if you expect any kind of data flow from Vera back to the device (not even confirmation of receipt of the message). That would be extra work, but not much more; it’s the risk of timeout on listening for incoming packets causing a Luup restart that you’re trying to avoid.

I have a similar issue. There is code running on Vera that expects the device I am monitoring to be connected via USB (the expectation being that I use a USB to serial adapter). The code seems to accept a port number (not sure if this is a tcp port or usb port?) I can’t find any documentation that is helpful.

However, the device is already connected to my network using serial to tcp bridge instead. With Vera having limited USB ports, and with my devices being spread out all over the house, I would like to continue with this setup. So how do I make Vera reroute the USB connection (local) to a remote port where the serial device server is listening (e.g.

There is nothing fancy about this – no authentication, no security, no application protocol layer. Just raw I/O. On Windows, there is a driver provided which maps a serial port (e.g., COM4) to the remote port. Anything similar I can do in MiOS, perhaps within an SSH? I suppose I could write a LUA application somehow, but that seems like additional overhead vs. something in the OS?

The function you need is If you search for that phrase you’ll find a wealth of prior discussions.

If you are expecting to monitor this device asynchronously you will probably have to bite the bullet and upgrade your code to a fully fledged plugin, with device and implementation files. A proper device has the ability to specify callback code in its section, without you needing to poll and risk the Luup engine restarting on you.