On and off, for a very long while now, I’ve been considering the best way to address asynchronous I/O.
In keeping with the platform-independent nature of openLuup, I’ve wanted to stick with pure Lua code and minimize links with particular OS libraries (especially, I still want this all to work on Windows.)
For HTTP(S) requests, it seems that a very good option would have been this library:
lua-http is pure Lua code with dependencies on the following external libraries:
cqueues - Posix API library for Lua
luaossl - Lua bindings for TLS/SSL
lua-zlib - Optional Lua bindings for zlib
lua-http can run on any operating system supported by cqueues and openssl, which at the time of writing is GNU/Linux, FreeBSD, NetBSD, OpenBSD, OSX and Solaris.
One of the biggest users of this would be the VeraBridge plugin, which actually spends quite a while polling Veras, so it would improve response times to Vera events considerably.
I’d say leave it up to Windows users to make the dependencies work. You’re talking about an environment where Windows curl barely functions!! Getting anything to work out of the box cross platform is almost impossible without some sort virtualization. And that’s coming from someone who uses Windows for most computer related work.
I’m with Buxton here. I use Oracle VM to run a PI emulator. Runs faster than any PI and is perfect for testing as well. If you trash it, you just restore the image. Back up running in seconds.
Not sure who or why would like to run on just Windows for an application like this.
Actually, it’s now a moot point, since I have just discovered a valid and robust way to access the low-level HTTP routines in the LuaSocket library. This means that I can now easily (well, fairly easily) split the HTTP request and responses into asynchronous activities and use the intervening latency for normal plugin processing.
I’ll be testing this first on the VeraBridge plugin which will allow me to use the proper lazy polling afforded by the lu_status request Timeout and MinimumDelay parameters, and, as a side-effect, get much better response times to Vera status changes.
This may a take a while to implement, but now I do know that it’s possible… have been wanting to do this for years!
I have been fooling with my network equipment and have at times had my switch or router disconnected between openluup and the vera. I noticed that when this happens, verabridge stops polling the vera until I reload luup on openluup. May I suggest to have either a button to restart the polling loop of the verabridge or alternatively for it to ignore the polling errors and just keep polling ad aeternam?
I have a similar request (and got the same result as Rafale changing the Vera IP adresses). If you add/remove devices from your Vera(s) the changes are not picked up until after a luup reload. That same option to restart the connection, could that pull a new full config? That would be great Just an action for this would do too as those are so simple to initiate from ALTUI, just like the GetVeraFiles one for example.
Well, normally it is not an issue indeed. However i moved from an Edge to a Plus in small batches so that meant quite some reloads. Not a top priority though. I was just thinking it could lift on top of the change from Rafale. No biggie if it cannot.
I’ve been digging into this and it seems that the issue may be to do with imperfect timeout handling in the LuaSocket library. This has been an issue elsewhere in the past.
It may mean that automatic detection of this condition is not possible, so I am investigating your suggestion of a manual action to reset the I/O.