AFAIK, this is not an issue. As for scenes, a blank return from either run or job code should do the expected thing: exit successfully.
That’s what I found in my testing whilst reverse engineering the Luup engine for openLuup.[/quote]
By testing this weekend I found out why so many probably return blank. You can put as much code in the I…xml file returning values as you like, but those are not returned with luup.call_action. It are the values from the variables you defined in the S…xml file. I first ran tests on openLuup and repeated them on Vera all with that result. So that odd design ‘logic’ is why most call_actions return nothing if you ask me.
The return codes from run or job functions control the status/flow of the action. However, as you say, the named associated state variables are used to return their values to the original action caller.
Note that these values reflect their state after a run action, but before a job action, which makes them tricky to use correctly.
Also note that an action can have both run and job parts, in which case the return status of the run part is used, as in scene Lua code, to determine whether the following job should be run at all.
Totally separate indeed, but if you look at the logic in some existing plugins (only source to really try and understand how things work due to lack of proper documentation) some do think that that return (on run) is the call_action return value.
I should realize I best ask you as you had to learn all ugly internals building openLuup ;D
Thanks for to continued learning. Truly appreciate all your knowledge sharing. I have some more plugins to check and possible update.
On a side note, I haven’t seen a lot of use of actions to return values in live code. It seems most people just go after the related state variables directly, as the use case seems most often as a “getter” for a related to state value, rather than a computed result. I can’t think of an example where I’ve ever had to use an action that returns a result other than something that can be derived from a state variable directly, in fact. But, I can see the utility of having that capability. Any idea where one might see such a thing in actual use?
It’s immediately useful for actions which use the <job> tag, since it returns the actual job number. This allows a plugin to follow the (asynchronous) status of the action, to know when it finishes, and, if necessary, to abort it.
Having said that, aside from the job termination notification, I know of no plugins which have tried to be that sophisticated with actions, probably because the documentation has been so poor.
For actions which are invoked via HTTP requests, the possibility of returning useful parameters as part of the response has obvious benefits in terms of I/O and response time.
OK, but that comes back in the first three result values of call_action(), and that’s not really what I’m talking about. I’m referring to the contents of the fourth argument, and using that direcly from Lua.
Having said that, aside from the job termination notification, I know of no plugins which have tried to be that sophisticated with actions, probably because the documentation has been so poor.
Amen to that. Couple with a rather loose interpretation of UPnP, well, you know…
For actions which are invoked via HTTP requests, the possibility of returning useful parameters as part of the response has obvious benefits in terms of I/O and response time
Agreed. Being able to return that data in any form is also huge for me.
In my new release of the Harmony plugin I thought it was a good idea to add some mapping functions one could call to map between names and ID’s as I added the possibility to use either to start actions or send commands. I did not have a variable for that (what is the point, right) and could not figure out why the (run) action had no return value. So now it ends in a generic temp variable, and the S…xml definitions make it a nice return name.
As you say there are very few examples, mine now is one :o
In my new release of the Harmony plugin I thought it was a good idea to add some mapping functions one could call to map between names and ID’s as I added the possibility to use either to start actions or send commands. I did not have a variable for that (what is the point, right) and could not figure out why the (run) action had no return value. So now it ends in a generic temp variable, and the S…xml definitions make it a nice return name.
As you say there are very few examples, mine now is one :o
Cheers Rene[/quote]
That’s exactly the kind of thing I’d expect. I’ve done that as well in a plugin, to return the current plugin version, which is just a constant not stored in state. But I doubt that’s ever been used by anybody.