NOTICE
My involvement with xPL has come to an end. Automation has moved on considerably over the past few years, and it is now possible to buy a stand-alone controller off the shelf for a reasonable price, without having to spend hours writing your own code.
This website is being maintained as a record of my xPL development work up until 2011.
I have released the full source code of all my xPL projects into the public domain. You can download the archive from here.
Mal
A tool to help identify the causes of xPL problems under Windows is now available.
The Windows C++ SDK for xPL has been updated to compile under Visual Studio .NET 2005.
The xPLExec application has been updated to address a couple of issues. The program path is longer specified in the exec.basic messages since it is obtained from the Permitted Programs list instead. The xPLExecConfig program has been fixed to allow the proper selection of .exe, .bat, .com and .cmd files.
An application allowing executable files to be run in response to xPL messages is now available for download.
A number of changes have been made to the xPL specification, with the eventual aim of improving the end-user experience. As a result, all xPL applications are being recompiled to support the new features. Users are strongly urged to visit the downloads page and upgrade their software to the latest version.
The most significant change is in the approach taken with the xPLHub. Applications are no longer allowed to include a built-in hub, either as part of the code or as part of the install package. Instead, a stand-alone hub must be selected and installed separately. The purpose of this change is to make it obvious which application is handling the hub functions, simplifying the task of troubleshooting an xPL installation.
Other changes relate to device discovery. Under the old system, applications would receive no messages from the xPL network until the hub had picked up the heartbeat message that each xPL application sends at regular intervals (chosen by the user to be between 5 and 9 minutes). However, if the hub was to start after an xPL application, it would miss its first heartbeat and it would then take anything up to 9 minutes for the next heartbeat to be sent and for the application to join the network. The new system gets around this problem in two ways. 1) Heartbeats are sent at 3 second intervals for the first two minutes of operation, or until the hub responds. 2) It is now possible to "poll" for heartbeats by sending a hbeat.request xPL message. All upgraded applications will respond immediately with their normal heartbeat message.
There are other changes in the pipeline, and an xPL diagnostic tool is also in the works. Check out the xPL Forums for the latest developments.
I've moved! No longer buried in the depths of www.lansell.org, I now have this new site dedicated exclusively to my xPL and home automation work. Over the next few weeks and months I hope to expand it to include more information, as well as provide new xPL solutions to your home automation problems.
A freeware Windows software development kit for xPL is now available for download.
The SDK replaces the old xPLCppLib. The new code is intended to be more logically structured, simpler to work with and better documented, while at the same time providing more power and flexibility to anyone developing xPL applications in C++.
The service has been rewritten to use the upcoming xPL SDK. It now includes the ability to act as an xPL hub.
This release also fixes a bug that caused duplicate messages to not be filtered correctly.
I finally got as sick of all the orange as the rest of you, so I'm giving the site a bit of a polish. It's not complete yet, so please bear with me as I find the time to create new artwork. The new subject areas are not finished yet - they will be uploaded in the near future.
