Plugin Creation Tutorial

From MiOS
(Difference between revisions)
Jump to: navigation, search
Line 3: Line 3:
 
A Luup plugin is composed of several types of files that can be broken into two groupings:
 
A Luup plugin is composed of several types of files that can be broken into two groupings:
  
D_GenericPlugin.xml
+
D_GenericPlugin1.xml
  
S_GenericPlugin.xml
+
S_GenericPlugin1.xml
  
I_GenericPlugin.xml
+
I_GenericPlugin1.xml
  
L_GenericPlugin.xml
+
L_GenericPlugin1.xml
  
  
D_GenericPlugin.json
+
D_GenericPlugin1.json
  
J_GenericPlugin.xml
+
J_GenericPlugin1.xml
  
 
==Files to manage the creation and execution of code in Vera==
 
==Files to manage the creation and execution of code in Vera==
*One device description file: D_GenericPlugin.xml
+
*'''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:
 
: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:
*Zero or more service files: S_GenericPlugin.xml
+
*'''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 [[Luup_UPNP_Files#Device_Files|list of service files provided]] with more [[Luup_Devices|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.
 
: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 [[Luup_UPNP_Files#Device_Files|list of service files provided]] with more [[Luup_Devices|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.
*One device implementation file: I_GenericPlugin.xml
+
*'''I_GenericPlugin1.xml''': one device implementation file
 
:Refer to [[Luup_Plugins_ByHand|Luup Plugins By Hand]] and [[Luup_Declarations|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|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.
 
:Refer to [[Luup_Plugins_ByHand|Luup Plugins By Hand]] and [[Luup_Declarations|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|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.
*Zero or more Lua files: L_GenericPlugin.xml
+
*'''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 you code in the Lua File and just make calls to it from the Implementation file. The use of this file is therefore optional.
 
: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 you code in the Lua File and just make calls to it from the Implementation file. The use of this file is therefore optional.
 
==Files to help manage User Interface (UIx) executed in the web browser==
 
==Files to help manage User Interface (UIx) executed in the web browser==
*Zero or one device interface file: D_GenericPlugin.json
+
*'''D_GenericPlugin1.json''': zero or one device interface file  
 
:Refer to [[Luup_plugins:_Static_JSON_file|Luup plugin: JSON]] and [[Luup_plugin_tabs|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 [[Luup_plugin_icons|Icons]] to be used by the device
 
:Refer to [[Luup_plugins:_Static_JSON_file|Luup plugin: JSON]] and [[Luup_plugin_tabs|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 [[Luup_plugin_icons|Icons]] to be used by the device
*Zero or more JavaScript files:&nbsp;J_GenericPlugin.xml
+
*'''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.
 
: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=
 
=Examples=
Line 35: Line 35:
 
*[[Luup_plugins_and_Luup_code|Luup plugins and Luup code]]
 
*[[Luup_plugins_and_Luup_code|Luup plugins and Luup code]]
 
=Caution=
 
=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.
+
*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.

Revision as of 02:20, 14 June 2013

Contents

Plugin structure

A Luup plugin is composed of several types of files that can be broken into two groupings:

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. 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 you code in the Lua File and just make calls to it from the Implementation file. The use of this file is therefore optional.

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

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.
Personal tools