The [tt][/tt] block declares each of the named Scene “Actions” that can be performed against your Plugin. This is typically the list you see when you create a scene defn, and want to “do” something with the device.
There are a number of blocks in the [tt][/tt] XML block, and each looks like:
"group_1":{
...,
"cmd_4":
{
"label": "Up",
"serviceId": "urn:upnp-org:serviceId:WindowCovering1",
"action": "Up"
},
...
btw, I’m not sure where the [tt]OPEN[/tt], [tt]CLOSE[/tt] and [tt]Set Level[/tt] ones came from in the “original” code in the ZIP. I’m not expecting that a Blind is either a Switch, or a Dimmer. The source file I had from before only lists [tt]Up[/tt], [tt]Down[/tt] and [tt]Stop[/tt] as actions.
Anyhow, each is a snippet of JSON that [effectively] gets loaded by the Browser component. Not sure why they don’t use XML everywhere, and just “transcribe” to JSON after upload, but that’s another story.
Each of these “entries” maps a Scene “action” (like “Up”, “Down” or “Stop” in the case of the original [tt]D_WindowCovering1.xml[/tt]) to a specific Lua/Luup serviceId/Action.
As your Parent Device has indicated that it handles child events ([tt][/tt] value of 1), then these Action handlers are expected in the Parent’s implementation ([tt]I_SomfyBlinds.xml[/tt]) file and you’ll see something like:
[code]
urn:upnp-org:serviceId:WindowCovering1
Up
local lul_command = lul_prefix … luup.devices[lul_device].id … ‘U\r’
local lul_reverse = luup.variable_get(“urn:micasaverde-com:serviceId:HaDevice1”,“ReverseOnOff”,lul_device)
if( lul_reverse==“1” ) then
lul_command = lul_prefix … luup.devices[lul_device].id … ‘D\r’
end
luup.log("ANK-Somfy-Up: " … tostring(lul_command),1)
if luup.io.write(lul_command)==false then
luup.log("cannot send: " .. tostring(lul_command),1)
luup.set_failure(true)
return false
end
</run>
...[/code]
You’ll see that the Service Id and Name match exactly between these two. This is required, since it’s part of how one “invokes” the other at runtime.
Note that Vera’s UI’s are often hardwired to either the [tt]ServiceType[/tt], or the [tt]ServiceId[/tt], so you cannot typically add/remove “Buttons” at will. Typically you’ll be stuck with the ones provided for a given [tt]ServiceType[/tt]/[tt]ServiceId[/tt], although there’s some talk about making that more flexible in the future.
For my Alarm code, I had them write a temporary UI until the Flex/Flash one comes along.
In the short term though, each Plugin can expose as many [tt][/tt] sections as it wants. If these happen to be parameterLess, then you can register a Scene using them, and you’ll have a Button that performs that “action”, similar to Turning on a light, except it performs the “named” action in your Plugin instead (which might open a blind, send an SMS etc)
I should draw a picture, but I hope you get what I mean.