Just posting this as I’ll be away for a couple of weeks, so what did I fix since last post;
- Todo: UPnP security service has not been implemented (must have!)
- Todo: Some of the wrapper code (mutexes, waithandles and sockets) are not complete for all platforms yet, currently it only runs on Windows, but this should be limited as the wrappers themselves have all been created already
Todo: Solid logger, as its designed to be used in the background without an interface, it must provide solid logging, even if only for troubleshooting and debugging
- Todo: Serial library; currently network connections are supported through the LuaSocket library, but serial connections must be added to (probably through ser2net, but that lacks a windows version AFAIK)
Todo: The demo is a single Lua file (which is totally crap code), and should be replaced by a Lua side object oriented framework to access and modify UPnP devices/controlpoints
Today I finished the first working sample of the new UPnP gateway I’ve been working on, a major milestone! Stepped out of .NET and changed to platform independent code and libraries. Punished myself with hardcore C, multi-threading and multi-platform all at once, but it all seems to start working now.
So what is it?
Its a Lua scripting engine, glued to the pupnp library. Lua is a small, fast and very portable dynamic scripting language and pupnp is a portable UPnP library. This creates an engine that will run on any platform (Windows, Mac, Linux, or even embedded on a NAS or your wifi router), while at the same time allowing users/developers to write code in Lua. So it takes away the need to do all the complex stuff in hardcore C, threading, platforms, etc. The Lua scripts will simply run on all platforms, unmodified.
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. Continue reading
It’s been more than a year since I actually updated the gateway, but this is a major overhaul, still early stage, so probably going to be buggy.
The xPL schema set has been revised and is more thorough, the entire UPnP device description will now be announced and it will be done in a more structured way (check the readme for the schema details). Obviously there is no compatibility with the previous version. But that was a piece of disposable-test-code anyway. Continue reading
When starting with UPnP development, some test projects, I initially started of with the Microsoft stack, as its already included in most Windows versions. But the documentation on the microsoft UPnP stack is so sparse, all examples I could find, were in C and then still only controlpoints, no devices. Hence I started using the Developer tools for UPnP (formerly by Intel). They contain a fully functional C# UPnP stack, and a code generator that generates a C stack. Just compile the C# stack and the resulting dll can be used from any (including VB) .NET language. Besides that the toolset contains a number of very usefull UPnP utilities.
The tools where initially available as the Intel UPnP tools, and after having disappeared from the Intel website for some time they have been relaunched as open source. Currently the stack is being maintained by Ylian Saint-Hilaire (Intel), and he does a good job at it (several bugfixes and improvements I submitted landed in the code quickly). Its a pitty that there isn’t a public forum for the UPnP tools.
This post is mostly about my experiences getting things up-and-running using the C# stack, which has its peculiarities, so here is what I learned; Continue reading