Remote serial port

I’m thinking how would it be possible to access remote RS-232 device over WiFi.

  1. Does Vera support virtual serial ports - over ethernet/wifi? RS232-USB adapter from one side, and virtual port for remote device on the other side - possible?

  2. What other device can I use to connect the client RS-232 device? I would naturally think of another router with RS232-USB adapter. But the question is what other firmware besides MCV-customized OpenWRT support RS232-USB and RS232-Ethernet?

???

you can use a gc100, although it’s kind of expensive to add one and an access point. Luup treats all serial ports as ethernet; there’s a separate daemon that opens an internet port and relays on the serial. This was done so that it would be easy to add remote serial ports that aren’t directly connected to the main Vera.

Is there easy way to do it having another Linux router on the other side?
It would look like:

Vera <<= … wifi bridge… =>> Router (dd-wrt or open-wrt) <<== USB2serial adapter <<== serial device

Actually it probably is. I could recompile the serial daemon for windows, and provide source code for Linux. It’s a trivial program. I’ll work on that tomorrow.

What’s required on the “remote” router to make this work?
I have spare Asus 520GU with one USB port…

I posted the serial proxy program here with Windows binaries: http://wiki.micasaverde.com/index.php/Windows_Serial_Proxy

I also attached the source code. The Makefile.lite is what we use to build it for our Vera build. Theoretically you could build it for the 520G and run it there, and use the 520G as a remote serial port.

SWEEET!

Ordered yet another router to break play…

Another very interesting option for connecting all kinds of things wireless is XBee, which in simplest config acts as… serial wireless link. Yet they have AD and DA converters too, so one can connect analog sensors right to them and receive a signal, process it in LUA, and do all kinds of fun stuff.
Take sonar sensor for example - unlike regular PIR it reports actual distance to the object, so one can use it to trigger events on much more specific conditions.

[quote=“micasaverde, post:6, topic:164547”]I posted the serial proxy program here with Windows binaries: http://wiki.micasaverde.com/index.php/Windows_Serial_Proxy

I also attached the source code. The Makefile.lite is what we use to build it for our Vera build. Theoretically you could build it for the 520G and run it there, and use the 520G as a remote serial port.[/quote]

Aaron, could you point me on the source code of the serial proxy?

source code is linked to here: http://wiki.micasaverde.com/index.php/Windows_Serial_Proxy

Just built OpenWrt package, installed on spare router - gives me a segmentation error.
have you guys seen such a thing? Any idea what to check?

root@OpenWrt:~# serproxy
Usage: serproxy ip_of_Luup some_unique_id com_port
root@OpenWrt:~# serproxy 192.168.1.131 asus COM1
Segmentation fault

there is no “COM” on Linux. That’s a windows thing. Run it like this:

serproxy 192.168.1.131 asus

Leaving the last parameter off, for Linux, means “scan for ports rather than using a fixed on”. Or, to use a fixed one:

serproxy 192.168.1.131 asus /dev/usb/tts/0
(or /dev/ttyUSB0, etc… depends on distro)

Guys, any progress on your side with serial port?

325xi, is this still not working for you after the current release I did? I got your trouble ticket re: the camera and fixed it (per another thread). If the serial port still isn’t working, I’d like to login and take a look at that too. Is this still a current problem? If so, do you want to open the back door again, and maybe email me a contact phone # and a time when I can call so we can get to the bottom of it?

I found the problem causing one user’s Luup engine to fail loading. It was caused by creating a new Luup plugin as a child object of the serial port. I fixed the engine so it won’t crash, but will instead log an error. This way you can fix the parent/child relationship. This fix is in .770.

The Luup plugin serial devices are actually top level devices. They don’t belong as children of the serial port. Instead, use the serial port configuration page to ‘bind’ the serial port to the device.

Oh, “COM”… of course, stupid me.
It didn’t help though, still getting “Segmentation fault”. I remember that compiler threw many warnings on serproxy, I didn’t really look into them, may be there’s some memory violation, or I missed some compiler parameter while modifying Makefile. I built OpenWRT SDK to build my packages on Ubuntu.

What I see after last FW upgrade, and putting my serial devices into /etc/cmh/serproxy.ports:

  • Device Serial_Portlist_2147450735 now contains two sub-devices for cp210x and pl2303
  • Somfy device I did according to walk-through is still “empty” and doesn’t show anything serial

Here’s the log saying that ports are recognized, but something definitely fails there

===---Running 3 with IP: 127.0.0.1 ID: 7410 COM: *none*
==Skipping unknown Serial Port: usbserinfo:1.0 driver:v1.4
Comparing custom port vendor:10c4 product:ea60 to 0: module:cp210x name:"CP210X" vendor:10c4 product:ea60 num_ports:1 port:1 path:usb-00:03.1-1.2
==Found Serial Port: 0 path:/dev/usb/tts/0 name: cp210x id: usb-00:03.1-1.2
Comparing custom port vendor:10c4 product:ea60 to 1: module:pl2303 name:"PL-2303" vendor:067b product:2303 num_ports:1 port:1 path:usb-00:03.1-1.1.3
Comparing custom port vendor:067b product:2303 to 1: module:pl2303 name:"PL-2303" vendor:067b product:2303 num_ports:1 port:1 path:usb-00:03.1-1.1.3
==Found Serial Port: 1 path:/dev/usb/tts/1 name: pl2303 id: usb-00:03.1-1.1.3
===Number of Serial Ports found: 2
Downloaded http://127.0.0.1:49451/data_request?id=lu_finddevice&devid=7410&devtype=micasaverde-com:serialportroot to /tmp/PlutoFileUtils.2hE0ja with /usr/bin/curl -k -s -S --fail --connect-timeout 5 --max-time 5 -o "/tmp/PlutoFileUtils.2hE0ja" "http://127.0.0.1:49451/data_request?id=lu_finddevice&devid=7410&devtype=micasaverde-com:serialportroot" Response 1792
Download failed
find_self failed
===---Running 3 with IP: 127.0.0.1 ID: 7410 COM: *none*
==Skipping unknown Serial Port: usbserinfo:1.0 driver:v1.4
Comparing custom port vendor:10c4 product:ea60 to 0: module:cp210x name:"CP210X" vendor:10c4 product:ea60 num_ports:1 port:1 path:usb-00:03.1-1.2
==Found Serial Port: 0 path:/dev/usb/tts/0 name: cp210x id: usb-00:03.1-1.2
Comparing custom port vendor:10c4 product:ea60 to 1: module:pl2303 name:"PL-2303" vendor:067b product:2303 num_ports:1 port:1 path:usb-00:03.1-1.1.3
Comparing custom port vendor:067b product:2303 to 1: module:pl2303 name:"PL-2303" vendor:067b product:2303 num_ports:1 port:1 path:usb-00:03.1-1.1.3
==Found Serial Port: 1 path:/dev/usb/tts/1 name: pl2303 id: usb-00:03.1-1.1.3
===Number of Serial Ports found: 2
Downloaded http://127.0.0.1:49451/data_request?id=lu_finddevice&devid=7410&devtype=micasaverde-com:serialportroot to /tmp/PlutoFileUtils.JWbC0O with /usr/bin/curl -k -s -S --fail --connect-timeout 5 --max-time 5 -o "/tmp/PlutoFileUtils.JWbC0O" "http://127.0.0.1:49451/data_request?id=lu_finddevice&devid=7410&devtype=micasaverde-com:serialportroot" Response 1792
Download failed
find_self failed

Access to Vera is still open, details in the support ticket 828

325xi, I just logged in and it seems serproxy is running ok now. I think you’re saying the segfault happens when running serproxy on another platform, not on Vera, right? What you might try doing is downloading the unmodified serproxy: http://www.lspace.nildram.co.uk/freeware.html

That takes the port settings from a configuration file. The modified serproxy deployed on Vera just changes the ‘readcfg’ to read the configuration from the Luup engine using http gets to get the ports, settings, etc., and to auto-scan for ports. But the actual function of serial port forwarding is unmodified. So you could use the unmodified serproxy and just add the ports manually to the Luup engine and to the serproxy configuration file.

As far as the error you’re seeing below… It’s not necessarily an error. Everytime you save changes, the Luup engine restarts, and the Luup services on port 49451 are unavailable for 4 seconds or so. Same thing when the list of ports changes and serproxy restarts the Luup engine.

===—Running… is when serproxy starts. So in your logs, I see serproxy is trying to run ‘find_self’, which just does a wget to retrieve the results of the lu_finddevice request. The download fails, presumably because the Luup engine isn’t running. So serproxy exits, and the start_serproxy script just restarts it again. So it’s normal for it to fail a few times when Vera first starts and the Luup engine isn’t up yet, and also after saving. But, after a few retries, the Luup engine should be back up and the lu_finddevice request should not fail, and so serproxy can go ahead and read the configuration using a few more wget’s.

You may see several more ‘download failed’ when serproxy uses the lu_variableget to request the port settings. This is normal. It just means you didn’t specify any settings yet on the ‘serial port configuration’ page, so those variables aren’t set. Serproxy will then use some hardcoded defaults (9600,N,8,1)

The key is that you should see:
===Setting up serproxy for…
Serproxy - (C)1999 Stefano Busti - Waiting for clients

at the end of the log. Those Setting up serproxy for… lines will show you what port settings our modified ‘readcfg’ passed on to the serproxy app.

Thanks for explanation.
The problem is that even though ports are now recognized by the system, the “Serial Port configuration” is still empty.

UPDATE: I eventually reset Vera to default factory settings, and viola! - I see the serial port settings!

In the Vera Luup Release notes it mentions for the last release you need to remove the serial device (save), then re-add it. This is because in the earlier serproxy it used the wrong devicetype, so it wasn’t recognized. So you needed the new serproxy to see them as new ports and report them with the right device type.

I tried, but in 770 it seems to be impossible to remove a device that has child devices.
Device menu stops working (shows empty screen) until reboot