What it doesn't do

What it doesn’t do - the good news!:

[ul][li]Doesn’t constantly reload (like Vera often does, for no apparent reason).[/li]
[li]Doesn’t use lots of memory.[/li]
[li]Doesn’t use lots of cpu.[/li]
[li]Doesn’t do UPnP (and never will).[/li]
[li]Doesn’t require the use of the UI7 web interface.[/li][/ul]

Some minor difficulties:

[ul][li]Doesn’t support the or action tags in service files, but does support the device-level tag (for asynchronous socket I/O.)[/li]
[li]Doesn’t run encrypted, or licensed, plugins[/li]
[li]Doesn’t directly support local serial I/O hardware (there are work-arounds.)[/li]
[li]Some less-used HTML requests are not yet implemented, eg. lu_invoke.[/li][/ul]

For more details; read the last page of the documentation:

http://forum.micasaverde.com/index.php/topic,34463.0.html

@akbooer - I’m not sure what this means - particularly the “device-level” part.

Doesn’t support the or action tags in service files, but does support the device-level tag (for asynchronous socket I/O.)

Also do the Lua distributions being suggested and/or used include the bit function library?

Vera / Luup / MiOS uses a truly bizarre approach to asynchronous I/O, which shares incoming messages between the body of the plugin code and any jobs (actions) it happens to be running. I think it’s like this because they tried to shoehorn the mechanism into a UPnP framework - hence the xml tags. I used to think this might be an issue, but in fact I’ve not run into any plugins which actually do asynchronous I/O from jobs. The important thing is that it works for the main code of the plugin (the MySensors ethernet gateway is a good example.)

Doesn't run encrypted, or licensed, plugins
OK, a real downer, I know. There's nothing I can do about this - the plugin developer has, no doubt for the best of reasons, decided that this is not open source. A common reason to do this is licensing, and another is to protect authorization credentials, and implementation details. The only way around that I see is to work cooperatively with the plugin developers. The fact is, though, that openLuup can essentially make a clone of any Vera, so that simple licensing approaches (such as keying off the machine hardware id or access point) are not secure, so robust alternatives need to be used.
Doesn't directly support local serial I/O hardware (there are work-arounds.)
Depends what you want to do here. It's fairly straight-forward to interface to serial hardware with standard unix components making it look like TCP/internet protocol. In the same way that Vera is supported through the VeraBridge plugin, any developer can write a specific plugin for any particular bit of hardware. The good thing about openLuup is that there's nothing more to learn: all (most) of the tools provided for plugin development (Luup API and HTTP requests) are available here too.
Some less-used HTML requests are not yet implemented, eg. lu_invoke.
I can't believe this particular one is a problem. If there's something that's needed, then it can be implemented. But life is short and Luup is full of inconsistencies, redundancies, and anachronisms, so not quite everything has been implemented. Just ask. The aim is to make it as similar to Vera as possible in everything except unreliability (oh, and cpu usage and memory.) Just a few things prove difficult because of the nature of the open platforms on which openLuup runs (that includes, to my knowledge, Mac OS, Windows, Ubuntu, Debian, Open-WRT.) The prime example of this is the behaviour of the system-specific port 80 HTTP server. In Vera this uses a specific syntax to redirect requests to other ports, and you'd have to dig quite deep into system configuration at the Unix level to make that work on other systems.

Are there some issues here I’m missing?

Are there some issues here I'm missing?

My original post was just to illustrate that - hell no - virtually nothing is missing 8).

OK, that’s great!

Re. The bit library, my open-WRT has it.

Ran this:

local X = require "bit"
print (pretty(X))

Got this

{
  arshift = function: 0x13b41c8,
  band = function: 0x13b4168,
  bits = 52,
  bnot = function: 0x13b40d8,
  bor = function: 0x13b40b8,
  bswap = function: 0xbf7730,
  bxor = function: 0x13b4230,
  cast = function: 0xbf76b0,
  check = function: 0xbf7670,
  div = function: 0xbf7650,
  lshift = function: 0x13b4208,
  max = 4.5035996273705e+15,
  rshift = function: 0x13b4140,
  set = function: 0x13b4100,
  tobit = function: 0xbf76f0,
  unset = function: 0xbf7610}

Will try others tomorrow.