io module async ?

[ronluna]

There is a little issue I'm currently facing with openluup and plugins that relies on io module.

If openluup is watching a variable that belongs to a devices that relies on io module and there is an action attached that also relies on io module, when that watcher gets triggered, the action in question will get processed in openluup (it will show in the logs) but the parent device won't process it.

I have a feeling that this could be due to io packets crossing between each others somehow modifying the final message received by the parent device. it's feels like the io communication is happening in the same room for all plugins and sometimes they get crossed. Wondering if anyone has experienced something of that sort and if there is a way to prevent it?

[akbooer]

The I/O module design of Vera is famously bad, and indeed obscure in some of its functionality. It certainly gave me more than a few headaches (and long discussion on the forum) when trying to implement it. The 'intercept' functionality is particularly opaque.

I've only come across rather few plugins which actually use it, since most opt for using LuaSocket function directly – a much wiser choice. I've never had multiple plugins needing it at the same time. AFAIK there's no message modification, per se, but I could quite believe that simultaneous users run into a problem.

[a-lurker]

@akbooer said in io module async ?:

The I/O module design of Vera is famously bad, and indeed obscure in some of its functionality.

Totally agree with the above.

Currently I'm looking at a project that you may be able to provide some guidance on? It looks like so:

1. All TX and RX messages are lines of text with a cr/lf on the end - via an IP TCP connection
2. I want to send one line commands, that can result in an immediate single or multi-line response. The response has nothing to indicate how many lines are in or will be in the reply. There is no symbol that represents end of message. However each line in the response has a prefix, which can help with response data assembly and dissection.
3. Interspersed may be asynchronous event messages. When I say interspersed; not inside multi-line responses to commands but after a command response is completed but asynchronously thereafter. These events have a unique prefix, so they can be identified.

In general, don't want any I/O blocking on reads to occur but blocking while waiting for a command response would probably be OK.

As I understand I/O blocking on reads in Vera/openLuup results in everything coming to grinding halt up to the timeout period - assuming the read does timeout. I may have that wrong - not clear on this.

After a command & response pair, I assume you would use something like socket.select. Also should I be making use of "jobs"?

I've written a few plugins with comms but every time I do, I seem to need a different approach. In particular asynchronous incoming data seems a bit tricky. But I do want abandon the use of the Vera method!

Interested in any suggestions or comments.

[Buxton]

@a-lurker Hey, you may be able to make use of @toggledbits proxy plugin. It will keep your IP connection to the target device open and then push its data to your plugin after any new update. Check his github repositories for docs on how to setup.

[a-lurker]

Yes - I'll look at this again but I was hoping to avoid having to distribute another file. I can see why togglebits choose node.js for his work on MSR. It makes the comms between devices seem almost trivial.

[akbooer]

There’s a low-level openLuup call to register a handler for asynchronous TCP messages in just the same way as you can for HTTP requests. In fact, the asynchronous HTTP handler, which runs on both openLuup and Vera, also uses an asynchronous non-blocking wait. Under openLuup it uses the above call, but on Vera, it’s simulated using socket.select().

[ronluna]

Maybe adding sockproxyd natively into openluup and modifying io.lua to optionally use sockproxyd could be a real winner to finally solve the limitations/problems in the I/O module.