Part of creating any Vera plug-in includes creating the appropriate UPnP XML. There various tools for helping you work with UPnP devices, such as “Device Spy” which is part of the the Developer Tools for UPnP available at
[url=http://opentools.homeip.net/dev-tools-for-upnp]Blog - Mikula Beutl
Another similar tool is Cling Workbench available here:
[url=http://4thline.org/projects/cling/]http://4thline.org/projects/cling/[/url]
Unfortunately, My Vera3 did not show up in the Device Spy device list although other devices, such as network routers did show up. Furthermore, Device Spy did not do a good job of telling my what was wrong. As it turned out, there were a number of minor syntax errors in the XML for various Vera Apps which I had downloaded. Very was fine with these errors but Device Spy was not.
I modified the Open Source developer tools suite to improve XML error handling. If you open the Device Spy error long and enable Errors and Warnings, you will now see log messages that pinpuint the exact problem. This feature is now available in v0.0.64.
Using Device Spy, you can explore all of the devices and plug-ins which are handled by Vera. You can control devices, and you can also subscribe to events which occur when the state of your devices changes.
The following are some of the types of XML errors which I found which caused problems:
Actions without related state variables
[font=courier]
A_ARG_TYPE_foo
string
SetFoo
DoFoo
in
A_ARG_TYPE_foo[/font] [font=courier]
[/font]
Both UPnP 1.0 and 1.1 specification make the relatedStateVariable element mandatory even if the parameter for the action is not intended to be a visible state variable. In such cases, the state variable must be created (with the appropriate type) but with a A_ARG_TYPE_ prefix in the name. For an example of the correct way to do this, look at Page 22 of [url=http://upnp.org/specs/phone/UPnP-phone-AddressBook-v1-Service.pdf]http://upnp.org/specs/phone/UPnP-phone-AddressBook-v1-Service.pdf[/url].
Be careful with your service type.
Use somrting like
[font=courier]urn:schemas-example-com:service:example:1[/font]
and NOT
[font=courier]urn:schemas-example-com:serviceId:example:1[/font]
or
[font=courier]urn:schemas-example-com:service:example1[/font]
even though your service ID is
[font=courier]urn:example-com:serviceId:example1[/font]
Be careful with capitalization
ExampleVariable
string
Note that the UPnP standard since 1.0 specifies using the “sendEvnets”= attribute rather than the commonly used
[font=courier]no[/font]
element. I updated the UPnP tools to support both since this convention is so widely used. (However, I also update Device Spy to detect events even if sendEvents is set to “no” using either convention)
Hopefully, these tips will help plug-in developers write better code.