luup.call_action return values

Developer's Corner General Dev Discussions
#1

I’m calling luup.call_action to call an action in another device. On the target device, the action is handled by a tag. The caller is getting an immediate return with error code 0 and the job number is also 0. However, the job is still running and it completes successfully returning 4. There is also a message in the log that such and such action did not return a value, but it absolutely did return a value. I’m confused by this based on the docs as it seems as the caller should have gotten back an error code of 0 and a job id greater than 0.

You should be able to call luup.call_action across devices, right?

Bruce

#2

If that did not work … PLEG actions would be dead!

luup.call_actions does NOT return any data from the called action. It only returns information about scheduling the action.

#3

Hi Richard,

I understand that I won’t get any data back from the action I’m calling, but I do want the scheduling information. According to the docs, call_action returns:

returns: error (number), error_msg (string), job (number), arguments (table)

if the action is being run asynchronously as a job, then “job” should be a positive number. However, I’m getting back 0 for the error and 0 for the job, but the job is actually still running. If I got the job number back, then I would query that with luup.job.status so I could see the final result of the call.

So, my question is why am I not getting the job number back from call_action? Or am I misinterpreting the docs?

Bruce

#4

Sorry, I do not know … I only fire and forget.

#5
returns: error (number), error_msg (string), job (number), arguments (table)

Ok, seems I’ve made some headway using the debugger. It appears the first three args of the return (error, error_msg, and job) seem to do nothing. The key is in the arguments table. When calling an action that spawns a job, the table contains {[“JobID”] = XX}. When calling an action that just has a tag, the table comes back with {[“OK”] = “OK”}. I’ll do some more testing to see what is returned when the called action actually fails.

Bruce

#6

Hello,
Although this post is quite old, the problem still exists.

I’ve tried several ways with and , but the return value is not sent : “JobHandler_LuaUPnP::ConfirmReturnArguments missing”.

Here is a workaround to retrieve a computed value :

1/ In the UPnP service specifications file :

<?xml version="1.0" encoding="utf-8"?>
<scpd xmlns="urn:schemas-upnp-org:service-1-0">
	<specVersion>
		<major>1</major>
		<minor>0</minor>
	</specVersion>
	<serviceStateTable>
...
		<!-- Dummy return argument -->
		<stateVariable>
			<name>LastResult</name>
			<sendEventsAttribute>no</sendEventsAttribute>
			<dataType>string</dataType>
			<shortCode>lastresult</shortCode>
		</stateVariable>
...
	</serviceStateTable>
	<actionList>
...
		<action>
			<name>GetAlarmStatus</name>
			<argumentList>
				<argument>
					<name>retStatus</name>
					<direction>out</direction>
					<relatedStateVariable>LastResult</relatedStateVariable>
				</argument>
				<argument>
					<name>id</name>
					<direction>in</direction>
					<relatedStateVariable>A_ARG_TYPE_Id</relatedStateVariable>
				</argument>
				<argument>
					<name>name</name>
					<direction>in</direction>
					<relatedStateVariable>A_ARG_TYPE_Name</relatedStateVariable>
				</argument>
			</argumentList>
		</action>
...
	</actionList>
</scpd>

2/ In implementation file :

<?xml version="1.0"?>
<implementation>
...
	<actionList>
...
		<action>
			<serviceId>urn:upnp-org:serviceId:MyPlugin1</serviceId>
			<name>GetAlarmStatus</name>
			<run>
				luup.variable_set("urn:upnp-org:serviceId:MyPlugin1", "LastResult", "1", lul_device)
			</run>
		</action>
...
	</actionList>
</implementation>

It seems that the Vera sends automatically the value in the variable defined in “relatedStateVariable”.

3/ To get the result :

local json = require("dkjson")
lul_resultcode, lul_resultstring, lul_job, lul_returnarguments = luup.call_action("urn:upnp-org:serviceId:MyPlugin1", "GetAlarmStatus", { name = "Name1"}, 21)
luup.log(json.encode(lul_returnarguments))

The result is in lul_returnarguments.retStatus

Vincent

#7

@vosmont

Thanks, indeed, for this. The key point (which, I suppose should have been fairly obvious) is your observation that:

Vera sends automatically the value in the variable defined in "relatedStateVariable".

I tried this on an existing, unmodified, service: [tt]urn:upnp-org:serviceId:SwitchPower1[/tt], and the [tt]GetTarget[/tt] action. The relatedStateVariable is [tt]Target[/tt], into which I set the value 42. It works not only at the [tt]luup.call_action[/tt] level, but also for the HTTP request:

http://172.16.42.12:3480/data_request?id=action&DeviceNum=95&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=GetTarget&output_format=json

returning the value:

{ "u:GetTargetResponse": { "JobID": "27", "RetTargetValue": "42" } }

but, strangely, the log still shows:

02   05/05/15 17:00:39.785   JobHandler_LuaUPnP::ConfirmReturnArguments missing RetTargetValue <0x2ebf6680>

Anyway, job done, so far as I am concerned!

Thanks again (and Karma)