The last few days I spent some time fixing the .NET UPnP stack to be more resilient. The stack itself it pretty ok, but the problem is that you do not have control over all the other UPnP devices out there. If these are faulty and don’t play by the rules, you can either ignore them (what the UPnP stack did until now) or try and handle only those parts that are ok.
Supporting for the UPnP gateway showed that several devices would simply not show up. Some fiddling with other UPnP tools and the debug facilities showed that the devices had faulty description xml’s (bad UPnP implementations by their vendors). The cases were the Grace Digital tuner and the Vera home automation box (the Grace Digital has a firmware update, beta, available that fixes the issue)
I had to take a pretty steep dive into the code to fix all the undelying elements. What happened was that the code for parsing device and service xml’s only had exception handling on the highest level. This means that you get either all or nothing.
The update now includes more error checking so that individual elements that do not adhere to the UPnP standards are now left out. So any faulty device or service will still get parsed, for all the proper elements it has. To know whether there are any issues with the description xml’s, the debug window can be used.
Showing the debug window can be done from the menu, or via the ‘/DEBUG’ commandline option.
As an example using the faulty service description of the Grace Digital tuner, that device has/had a RenderingControl1.xml service description with an action argument that referenced a non-existing statevariable. If you load this xml into the Service Author tool, it would simply display an error and do nothing;
With the fixed version of the stack, it now logs the errors, but commences with parsing the proper parts of the device;
In the screenshot you can see in the top pane of the debug window that the errors pertain to the actions GetLoudness and SetLoudness. In the bottom pane it is mentioned that there is an invalid reference to the Loudness statevariable. In the main Service Author window, all proper defined actions are now shown (note that Get/SetLoudness are absent here).
The practical use for the Service Author application is very limited, but I have no access to the device itself, so this was the only way to show the effects. Any way, the same UPnP stack can be used with the Device Spy, which basically means that from now on even the bad behaving devices will show up in the Device Spy, which is great for troubleshooting UPnP devices, and of course, the stack can be used to build controlpoints that are also capable of controlling those bad behaving devices.