openLuup: Suggestions

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:

BUT, alas, I read in the documentation:

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.

So no Windows solution yet. Thoughts anyone?

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.

Hi AK,

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.

Cheers Rene

@Buxton, @reneboer, thanks for the feedback!

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!


Further discussion on the topic moved to here (old forum) openLuup: Asynchronous I/O

now here: openLuup: Asynchronous I/O

After about a year and a half of inaction, I’m considering this suggestion again…

Just wondering if anyone is using the http-digest module, and any further ideas as to preferences on the way it might be included in openLuup…

  1. as an external module, unchanged, simply part of the openLuup distribution
  2. integrated in the luup.inet.wget() function
  3. both the above

Thanks for any thoughts on this.

Now a moot point, since the latest (v19.8.1) development release provides basic and digest authorization in luup.inet.wget()

Hi AK,

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 take it that this is in async mode only?

aye. I am running in async mode. I did not test this otherwise.

As a sanity check it would be really helpful to check this for me… since you’re fooling about with the network?

I have seen this rarely, but with async it’s tricky to track down.

Ok Let me check this… I am alpha testing some firmware for ubnt so I am rebooting equipment quite a bit lately. Will get back to you shortly.

Yes… I just confirmed that it is only a problem in async mode.

ooh, that was quick.

Thanks, I’ll dig into it a bit.

Hi @akbooer,

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.

Cheers Rene

OK, this is not quite as trivial as it might seem. Just how often do you add new devices, and how much of a pain is a reload?

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.

Cheers Rene

OK, thanks.
I haven’t timed the new release, but I still think that openLuup reloads faster than Vera :grinning:

Duh :rofl:

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.