I’m working on building a plugin for a standalone IP based device that doesn’t have an API that you can call and make web requests, but there are configurable end point URLs where the unit can call Vera when certain events occur. I’m interfacing this device with the Vera, but have come up against a limitation. I’m using the _register_handler approach. It turns out that the originating device can’t send an http request to any port other than port 80 which is a problem since the _register_handler is exposed at port 49451.
I had thought that I could work around this with some kind of port forwarding on my internal network. I’m not sure what this would be called or how to set it up, but here’s what I’d like to do:
Set up a rule when requests originate from IP address #1 to IP Address #2 over port 80, change the destination port to port 49451.
Another option might be to hook up the device up to the Vera 3’s Ethernet port and use some rules in the Vera to do this. I seem to remember on the Vera 2 there was a fairly advanced router setup that could be accessed, but I’m not sure about the Vera 3.
I’m open to other options or suggestions as networking is not my strength.
Finally got some time to try this out and it worked! Thanks for the tip. Is this construct a feature of http, something that is implemented in Vera, or Linux?
Vera uses lighttpd for its HTTP access. Vera preconfigures lighty with a number of proxy settings, like the port_xxxxx ones, so you know it’ll be present in all Vera units.
You can see these listed in the lighttpd.conf file
That’s really good news. Come to think of it you should probably switch to port 3480, which seems to be the preferred option… @guessed can no doubt explain why!
TCP:49451 was the original port, and supposedly TCP:3480 replaced it. These are both directly handled by the [tt]LuaUPnP[/tt] process, so there is minimal overhead when connecting via these ports.
Presumably TCP:49451 is maintained for compatibility, since the earliest CP’s used it and may not have been changed over. No idea when that’ll be phased out, since it’s legacy nature hasn’t been referenced in some time.
The [tt]http://…/port_nnnnnn/[/tt] stuff goes through Lighty first, before being forwarded, so there is overhead to using these, although I’m guessing it’s negligible.
If I were using this, I’d use the [tt]/port_3480/[/tt] variant.
Oddly enough, the [tt]port_49451[/tt] variant proxy’s through to TCP:49451… and the doc on http://wiki.micasaverde.com references all 4x styles, so that’s no help 8)
The http://.../port_nnnnnn/ stuff goes through Lighty first
That’s REALLY interesting - I hadn’t thought this through, and have been rather random in my use of both. Wondering whether interleaving use of these might cause any problems. Anyway, it seems that [tt]/port_xxx[/tt] fixes the OP, so that’s good. I’ll try to be more consistent internally for my own coding. Thanks once again.
The http://…/port_nnnnnn/ stuff goes through Lighty first
That’s REALLY interesting - I hadn’t thought this through, and have been rather random in my use of both. Wondering whether interleaving use of these might cause any problems. Anyway, it seems that [tt]/port_xxx[/tt] fixes the OP, so that’s good. I’ll try to be more consistent internally for my own coding. Thanks once again.[/quote]
Things like NetworkMonitor actually poll all of the various access-path combinations. This is where it gets dodgy since that process can kill/restart, and in some cases REBOOT, Vera if it thinks connectivity has dropped. In UI5, I had to disable chunks of that logic, since it has retry-bugs that causes it to periodically reboot my Vera… very uncool
Best Home Automation shopping experience. Shop at Ezlo!
