Plugin Creation Tutorial - Revision history

A-lurker at 23:24, 18 July 2013

2013-07-18T23:24:44Z

A-lurker at 21:55, 16 June 2013

2013-06-16T21:55:16Z

A-lurker at 08:53, 14 June 2013

2013-06-14T08:53:41Z

A-lurker at 03:54, 14 June 2013

2013-06-14T03:54:48Z

A-lurker at 03:48, 14 June 2013

2013-06-14T03:48:29Z

A-lurker at 02:20, 14 June 2013

2013-06-14T02:20:52Z

A-lurker at 01:43, 14 June 2013

2013-06-14T01:43:01Z

A-lurker at 07:41, 13 June 2013

2013-06-13T07:41:35Z

A-lurker at 07:11, 13 June 2013

2013-06-13T07:11:14Z

A-lurker at 06:52, 13 June 2013

2013-06-13T06:52:51Z

@@ Line 43: / Line 43: @@
 =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.
+*As mentioned above - all XML files should be escaped properly. This is particularly relevant for any Implementation files containing Lua code, which often contains these 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.

@@ Line 35: / Line 35: @@
 *[[Luup_Somfy_Walkthrough|Luup Somfy Walkthrough]]
 *[[Luup_plugins_and_Luup_code|Luup plugins and Luup code]]
 =Communicating with your plugin=
 *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|Luup Requests]]. In particular, have a look the web page at VERAs_IP_address:3480/data_request?id=lu_invoke

@@ Line 2: / Line 2: @@
 =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
@@ Line 20: / Line 21: @@
 :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 [[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.]] And even [[Luup_UPnP_Variables_and_Actions|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_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.
 *'''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 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
@@ Line 31: / Line 32: @@
 :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
+*Google --> MIOS code repository
 *[[Luup_Somfy_Walkthrough|Luup Somfy Walkthrough]]
 *[[Luup_plugins_and_Luup_code|Luup plugins and Luup code]]
 =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 device requires this to be done five times as the user adds in input along the way.
+*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.

← Older revision		Revision as of 03:54, 14 June 2013
Line 38:		Line 38:
	*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.		*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.		*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 device requires this to be done five times as the user adds in input along the way.

@@ Line 1: / Line 1: @@
 [[Category:Development]] [[Category:Plugins]]
 =Plugin structure=
-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 - some of the files are optional:
 D_GenericPlugin1.xml
@@ Line 37: / Line 37: @@
 *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.

← Older revision		Revision as of 01:43, 14 June 2013
Line 34:		Line 34:
	*[[Luup_Somfy_Walkthrough\|Luup Somfy Walkthrough]]		*[[Luup_Somfy_Walkthrough\|Luup Somfy Walkthrough]]
	*[[Luup_plugins_and_Luup_code\|Luup plugins and Luup code]]		*[[Luup_plugins_and_Luup_code\|Luup plugins and Luup code]]
		+	=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.