I would like to develop a plugin which receives it’s incomming data from a UDP source. Does anybody know how (and if) this can be done?
Thanks
Your best bet would be the luasocket library; it’s standard on Vera. It would be fairly low-level: you’d get the datagram in a string of bytes and you’d have to use substring operations to pull whatever data you wanted out of it.
Start with an existing plugin like the Google Weather plugin, and replace the periodic function with your UDP listener. The function should loop forever, perhaps using a blocking UDP listen to avoid busy-waiting. No idea if Vera is going to like a function that runs forever.
I did a quick search for example Lua code for a UDP server. I didn’t find one, so I’m afraid that you’re going to have to experiment a lot, or port a C example to Lua.
@futzle is correct, there’s really no native way to do this barring coding it like the above, periodically polling the UDP connect for incoming data, and hoping that there’s enough buffering going on in-between your polls.
I’d recommend against any sort of blocking IO in timer(s) etc. I recently had a plugin that was timing out (10seconds) on a TCP socket, running inside a Timer code (every minute). This Blocking IO activity was preventing the (Save) operation from running, and causing all sorts of havoc (under UI4). There are now ENH’s to make these “system” events not be interrupted by “user” events, but for now that’s the reality.
Short version, poll as infrequently as possible, hope that something will buffer for you, and don’t block.
Thanks for all information. Seems like UDP isn’t a sollid solution with the Vera. I will switch back to TCP.
Do you think there is anyway we could convince MiCasaVerde to add UDP support to the plugin architecture?
That way a new UDP packet would trigger an function call?
It would depend upon the strength of what could be included as a result of adding it. If it’s a few toy devices, probably not. If it’s a major set of devices, AV etc, then I suspect it could be lobbied for.
A nice Lua/UDP tutorial: [tt]http://www.luxinia.de/index.php/Tutorials/Tutorial08[/tt]
@guessed, unfortunately I don’t think I can make a strong claim based on my needs. I’m just messing with xPL / xAL and those require UDP servers OR another program running on a different machine working as a bridge (basically a UI simple program that also handles xPL messages).
I have it working as the external bridge program. I also have most of this working as a Vera plugin but obviously I have to just check for UDP messages periodically which more or less defeats the purpose of making it a plugin.
I have a feeling that the amount of potential xPL / xAL users is low (heck, I’m not even sure if I’m actually going to use it long term, I’m just experimenting) that it probably wouldn’t be worth it for those protocols.
I’m not sure how exactly Vera works, but I’m assuming it is a pretty basic Event Driven model. I wouldn’t think UDP support would be too hard to add, but again the payoff might not be great either.
Right and that’s the eternal problem.
Adding this functionality, and stabilizing it, takes time away from something else… So the use-case has to be strong enough, and wide enough, to knock out some other feature, a stabilization effort, or something that would attract 1000’s more to the platform (to fund all these efforts)
I don’t think it’s there yet in terms of potential feature impact, albeit technically interesting.
You could also experiment with a localized Lua engine ‘launched’ from a plugin as a process, similar to what was being done in this older thread:
http://forum.micasaverde.com/index.php?topic=7644.msg49428#msg49428
Of course they hadn’t yet gotten to launching it, but the overall model for TCP or UDP servers would be the same, using the coroutine stuff…
If you built the pro to that way, you could use it as the platform to show the value of what you wanted it for…with an eventual path to put it back together again.
@guessed and @AP15e, thank you very much for those links!
I was thinking about doing something very similar but on a remote machine that basically just listened for UDP messages and had a TCP server running to forward them to the Vera. I didn’t think about running that UDP->TCP server bridge on Vera itself! I may look at doing that in the future.
In the interim, do you know if there is a performance benefit to running a “UI Simple” based process on a remote machine versus running a UDP->TCP bridge on a remote machine and having Vera do similar processing in a plugin using luup.watch_variable?
I would use variable_watch, locally, over a complete UI Simple implementation on another box. Vera’s internals are very much setup to follow variable values, and pipeline actions off the back of them…