Revision as of 21:55, 16 June 2013

Plugin structure

A Luup plugin is composed of several types of files that can be broken into two groupings - some of the files are optional:

D_GenericPlugin1.xml

S_GenericPlugin1.xml

I_GenericPlugin1.xml

L_GenericPlugin1.xml

D_GenericPlugin1.json

J_GenericPlugin1.xml

Files to manage the creation and execution of code in Vera

• D_GenericPlugin1.xml: one device description file

The Description file is the prime anchor. All the other files are eventually reached by following the links in the chain or to be more precise; from XML <tag> to XML <tag>. The Description file contains the top level information about the plugin and then links to the Service file(s) as described below:

• S_GenericPlugin1.xml: zero or more service files

There are many Service files supplied with Vera, which contain the service descriptions for common requirements, such as on/off switches. This allows for consistency among devices. Refer to the list of service files provided with more detail here. And even more detail here. However in many cases the services you require may not exist. In which case you describe them in your own Service file(s) and then implement them in your Implementation file.

• I_GenericPlugin1.xml: one device implementation file

Refer to Luup Plugins By Hand and Luup Declarations The Implementation file contains the Actions/Lua code required to implement the services specified in the Service file(s). Additional Lua functions have been made available by the Luup engine to help you program your Vera device: Luup Lua extensions. Note carefully - this is an XML file, so make sure you escape the XML entities in your Lua code, that need to be escaped.

• L_GenericPlugin1.xml: zero or more Lua files:

Typically your Lua code is placed in the Implementation file. However for large programs this can make testing a little difficult and the program hard to read or unwieldy. Instead, you can place all your code in the Lua File and just make calls to it from the Implementation file. The use of this file is therefore optional. Those interested in communicating with other internet sites should look at Luasocket. Just Google --> Luasocket reference diego

Files to help manage User Interface (UIx) executed in the web browser

• D_GenericPlugin1.json: zero or one device interface file

Refer to Luup plugin: JSON and Luup plugin: tabs You only need this file if you want to control the device directly in the User Interface. If it is not present you can still control the device by invoking its services through scenes, Lua code, URL calls and the like. This file also contains links to the Icons to be used by the device

• J_GenericPlugin1.xml: zero or more JavaScript files

Called by device JSON file above. Only required when you need the User Interface to do more unusual stuff, rather say just displaying labels, buttons and sliders. The use of this file just depends on how complex the interface to your device is. It's often not needed.

Examples

• Google --> MIOS code repository
• Luup Somfy Walkthrough
• Luup plugins and Luup code
• Vera uses JSON as the native format, so any calls to Vera should request JSON in preference to XML. It's quicker.

Communicating with your plugin

UI Notes has a good summary on communicating with Vera and/or Vera plugins

• you can access your plugin via Vera scenes and also through the User Interface assuming a D_GenericPlugin1.json is part of your plugin
• you can also use Luup Requests. In particular, have a look the web page at VERAs_IP_address:3480/data_request?id=lu_invoke
• via the MIOS servers - have a look at UI Simple

Caution

• Odd behavior has been observed when plugin files that are prepended with a Byte Order Mark (BOM) have been uploaded to Vera. Usage of a text editor, such as NotePad++, can be used to ensure a text file is created that does not prepend the BOM. This is in contrast to Windows Notepad that does add in the BOM resulting in trouble for the unsuspecting programmer.
• As mentioned above - all XML files should be escaped properly. This is particularly relevant for any Implementation files containing Lua code, which often contains characters that need to be escaped.
• You can test your code in UI5-->Apps-->Develop Apps-->Test Luup code (Lua). While testing, always end you code with a "return true". Otherwise you will receive the message "Code failed" on execution, even when your actual code has executed correctly.
• Depending on the Plugin functionality, multiple reloads of the Luup Engine (Reload button) and refreshes of your browser (F5) may be required to fully install the Plugin. For example the WeMo Plugin requires this to be done five times as the user adds in input along the way.