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.
About a year ago I posted a tip/trick type article on CodeProject. Recently a comment proved a problem with my code, hence I updated it. Because I couldn’t add any downloads to the post, I’ll provide it here.
Here’s the article
Here’s the download (downloaded 1202 times)
Recently, while looking for a better Lua IDE I tried the Lua Development Tools by the Koneki project. The Koneki project focusses on machine-2-machine (M2M) development and hence does not yet support local run and debug configurations. With a support link to some helpful pages (which didn’t work straight away), I fiddled around a bit and got it working through the ‘external tools’ workaround, though still with some quirks. Also not sure it all works as it should, especially adding command line parameters is something I’ll be needing to fix still. Continue reading
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
Today I uploaded yet another update for the gateway and xPLGirder component. Mike C put it to the test and had a list findings, most are resolved now. Besides those bugfixes the component now also uses lua events (based on the component model) besides the regular Girder events. This should make it easier to develop lua code that works with the xPL component.
Here’s another update of the gateway and the xPLGirder component. It had a nasty (and hard to find) bug, which took me nearly a day to find and fix (fixing was actually 1 minute). There is also a functional update (to the xPLGirder plugin) that accompanies the bugfix; if for some reason the announcement of a UPnP device does not complete, this is now detected and any missing elements will be re-requested.
This post will try to explain how the UPnP devices can be controlled using Girder. By explaining some UPnP basics and at the same time create some example code to control a simple device. Continue reading
A few days ago I updated the gateway (I even gave it its own page now) and the xPLGirder component (the only client for the gateway so far). On the Girder forum there are now some users experimenting with it and it seems to be working pretty well. It already outperformed an IR controller 🙂
Great to see it finally comes to a use beyond just me!
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
After some discussion a proposal was made on the xPL forums to add fragmentation so the message size limit could be bypassed. The schema for this is ‘fragment.basic’ and support for it has been added to the xPL library for .NET in version 5.4.
There are some other minor updates too, check the changelog for those.
xPLLib for .NET is available for download on the xPLLib page