[li]openLuup Extensions plugin[/li]
[li]create_device action call[/li]
[li]refactor luup.chdev module[/li]
[li]fix server query/file logic (thanks @vosmont)[/li]
Some important points to note:
[ul][li]The VeraBridge is NOT compatible with the old version, you will have to rebuild from a startup.lua file rather than an existing user_data.json (sorry)[/li]
[li]There is a new plugin openLuup:Extensions.[/li][/ul]
There was an intrinsic problem with the way that the bridge used to treat device numbers: any new device, be it local or cloned from a remote machine, would receive the next available deviceID, as in a standard Vera. This meant that any change to local devices or ones on remote machines (ie. creation/deletion) could result in an extensive renumbering of all devices in openLuup… clearly not acceptable.
The approach now is for local device numbers to work as in Vera - a new device gets the next available ID. However, cloned devices from remote machines get device IDs allocated from higher-numbered blocks. The first VeraBridge uses device numbers starting at 10,000, the second one at 20,000, and so on. There is also some consistency in the remote device numbering in that the original Vera deviceIDs are simply shifted by the bridge offset. Thus device 42 on your first bridged Vera will always be device 10042 on openLuup.
Local and remote devices are thus completely isolated in terms of device numbering interactions. This will make scene triggers and actions much more stable.
This is a new plugin - move the files to /etc/cmh-ludl/ and install with:
luup.create_device ('', '', nil, "D_openLuupExtensions.xml")
… or use the +Create button on the AltUI interface (which works now! - thanks @amg0)
The philosophy here is that openLuup itself should remain as true as possible* to standard Vera functionality. That way we can ensure that most plugins written for Vera run also under openLuup. HOWEVER… now having gained the freedom to make improvements, the Extensions plugin is going to add extra facilities over time.
At the moment, it does very little:
[ul][li]front panel display shows system uptime and memory usage[/li]
[li]similar data can be read from device variables (and used as device variable watch triggers or pushed to ThingSpeak)[/li]
[li]a few actions have been implemented, more will come. At the moment you can set StartupCode and ShutdownCode[/li][/ul]
A feature to come soon (hopefully) is the ability to upgrade openLuup itself from the GitHub repository in much the same way as the AltUI update works now.
- with the notable exceptions of: not crashing, not running out of memory, and not using much CPU.