MiOS invented Luup, a software engine that wirelessly manages a variety of devices.
Luup (Lua-UPnP) is a new software engine which incorporates Lua, a popular scripting language, and UPnP, the industry standard way to control devices. Luup translates into standard UPnP all the various protocols, including: Z-Wave, Zigbee, Insteon, KNX/EIB and other home protocols, infrared remote control (ie TV's, Stereos, cable boxes, etc.), serial devices (ie alarm panels, high-end a/v gear, etc.), Ethernet devices (IP cameras, GC100, etc.), as well as your own custom devices and applications, are translated by Luup into industry standard UPnP, and can be controlled by any UPnP Control Point.

UPnP (Universal Plug and Play) is the defacto industry standard protocol for controlling all sorts of devices. Microsoft, Intel, Sony, Cisco, Panasonic, Samsung, General Electric and virtually every major consumer electronics (CE) company worldwide is a member of the UPnP Forum which creates free, open standards for controlling devices (see: upnp.org).There already exist many UPnP control points, which are basically remote controls for UPnP devices. They run on web pads, PDA's, set top boxes, cell phones, media center PC's, etc., and they can control UPnP devices. There are already industry standard UPnP protocols for home automation devices, too, such as UPnP light switches, thermostats, etc. These standards have been ratified by all the major CE companies, and they allow those devices to be controlled by any of the UPnP control points on the market.

Despite this, there are virtually no home automation devices available which conform to the UPnP standard, because all the current manufacturers instead use various proprietary standards, like Z-Wave, Zigbee, Insteon, X10, etc., mainly because UPnP only runs on TCP/IP networks (aka Ethernet, LAN, Internet), making it impractical for home automation. Well, it was impractical until MiOS' Luup engine came along.
Our Luup engine embeds Lua. Lua is an easy to use, fast, lightweight language commonly used for scripting and macros. It's quite popular in video games to allow gamers to write custom scripts to expand the game's functionality.
Our Luup engine handles all the complexities of the smarthome system. All the difficult things like the UPNP interface, socket handling, job queuing and prioritization, multi-threading, serial I/O, etc., are provided by the Luup engine. If you want to create a specific smarthome application, you simply define the actions your device implements using a web-based tool, and the web tool gives you fill-in-the-blanks to add Lua script to provide the functionality. The Luup engine provides hooks and API calls for your Lua scripts to handle all the complex parts so you can develop sophisticated smarthome applications very quickly.
Lua is very minimalistic in the sense of having very few special constructs, but they're carefully chosen for its wide generality, so it has a wide expressive power. The best documents are the official Lua reference at http://www.lua.org/manual/5.1/, and a good book is Programming in Lua (PIL):http://www.lua.org/docs.html#books
Any Lua code can use:

• The standard Lua libraries, described on the http://www.lua.org website;
• Some common Lua extension modules like LuaSocket, LuaExpat and LuaSec;
• The Luup API, described on http://wiki.micasaverde.com/index.php/Luup_Lua_extensions. and http://wiki.micasaverde.com/index.php/Luup_Declarations.

The API exposed by Luup to Lua code consist of:

• global variables: these hold most of the system status: geographic situation, list of devices, rooms, scenes and remotes.
• 'system' functions: to manage the log, the task display, timers, signal failure.
• 'device' functions: to inspect device capabilities, to get/set/watch state variables, to start actions.
• 'child device' functions: creating child devices can make it easier to manage devices with multiple functions.
• I/O functions: use these to write data on the configured port. For input, it's usually better to set an 'incoming' function to be called when there's data.

The device functions deal with device variables and actions. Both are identified by simple names (like "Status", "CurrentTemperature"); but prefixed by a 'service' identification, which is a longer and more intimidating string (like "urn:schemas-upnp-org:service:SwitchPower:1"). Because of this, a simple variable reading or action calling looks complex at first sight; but it can be abstracted away by using variables instead of string constants or with simple accessor functions.