Data Provider Catalog Plugin Requests - Revision history

Henk at 15:19, 28 May 2011

2011-05-28T15:19:26Z

Javier at 03:31, 14 April 2010

2010-04-14T03:31:01Z

LibraSun at 15:38, 2 August 2009

2009-08-02T15:38:10Z

Micasaverde: /* data_request */

2009-06-21T01:12:32Z

‎data_request

Micasaverde: /* data_request */

2009-05-01T00:20:13Z

‎data_request

Micasaverde: /* data_request */

2009-04-29T04:01:25Z

‎data_request

Micasaverde at 04:24, 18 February 2009

2009-02-18T04:24:01Z

Micasaverde: /* data_request */

2009-01-31T02:47:42Z

‎data_request

Micasaverde at 00:16, 29 January 2009

2009-01-29T00:16:21Z

Micasaverde at 04:49, 3 December 2008

2008-12-03T04:49:11Z

@@ Line 1: / Line 1: @@
 [[Category:Development]]
 [[Category:Obsolete]]
 Here are the possible requests you can make on port 3451 to the Data Provider Catalog Plugin.  For a general overview, see [[Data_Provider_Catalog_Plugin]]

← Older revision		Revision as of 03:31, 14 April 2010
Line 1:		Line 1:
		+	[[Category:Development]]
		+	[[Category:Obsolete]]
	Here are the possible requests you can make on port 3451 to the Data Provider Catalog Plugin. For a general overview, see [[Data_Provider_Catalog_Plugin]]		Here are the possible requests you can make on port 3451 to the Data Provider Catalog Plugin. For a general overview, see [[Data_Provider_Catalog_Plugin]]

@@ Line 1: / Line 1: @@
 Here are the possible requests you can make on port 3451 to the Data Provider Catalog Plugin.  For a general overview, see [[Data_Provider_Catalog_Plugin]]
-== Built-in requests ==
+== Built-in requests  ==
-'''user_data'''<br>
+'''user_data'''<br> Optional URL Parameters: output_format=json<br> Post Variables: parm=[json data to update] as multipart/form-data, not application/x-www-form-urlencoded<br>
 Optional URL Parameters: output_format=json<br>
 Post Variables: parm=[json data to update] as multipart/form-data, not application/x-www-form-urlencoded<br>
-This is the main request to retrieve the configuration and to make changes to it.  This returns the current configuration, which is stored in JSON format: http://192.168.81.1:3451/user_data?output_format=json<br>
+This is the main request to retrieve the configuration and to make changes to it. This returns the current configuration, which is stored in JSON format: http://192.168.81.1:3451/user_data?output_format=json<br> Go to http://www.jsonlint.com/ to format it nicely for easy reading.
 Go to http://www.jsonlint.com/ to format it nicely for easy reading.
-To update information, such as adding rooms, renaming devices, and so on, put the new JSON in the post variable 'parm'.  When you are including a JSON object your new objects are by default merged into the current ones unless you can attach the special tag json_action with "add" or "del" to explicitly add or remove something.  For example, assume that the data is currently like this:
+To update information, such as adding rooms, renaming devices, and so on, put the new JSON in the post variable 'parm'. When you are including a JSON object your new objects are by default merged into the current ones unless you can attach the special tag json_action with "add" or "del" to explicitly add or remove something. For example, assume that the data is currently like this:
    "Room": {
@@ Line 22: / Line 19: @@
+         }
-You want to remove the bedroom and add a new room called "Den" and change the Living Room to be called Kitchen.  You put the following in the parm post:
+You want to remove the bedroom and add a new room called "Den" and change the Living Room to be called Kitchen. You put the following in the parm post:
      "Room": {
          "PK_Room_2": {
@@ Line 38: / Line 36: @@
+         }
+     }
-Note that Sections, Rooms, Devices, and Scenes are all numbered: PK_Room_1, scene_2, etc.  When are adding new Sections, Rooms, Devices, and Scenes, use a number that is very high (> 1,000,000) to prevent conflicts.  Note that Room uses a really large ID.  You don't want to use the next available ID, like 3, because that might already have been created by another user, and, since the ID # is the key to merging, your new room would be preserved and there would be 2 room 3's if json_action=add, or your changes would be merged and overwrite room 3 otherwise.  When you use large id's > 1m, then on save, the system automatically re-numbers them and re-outputs the renumbered result.  This includes relationships as well.  So if you are submitting a new scene, device, room, etc., the device may be id 1m, and reference room 2, so it goes into room 2, and a new device id 1m + 1 may reference room 1m.  In this case both device id's would be renumbered, and the room 1m would be renumbered, and the reference in the device id 1m + 1 would be changed to reflect this.
-Thus when you submit new json data you should always output_format=json to the URL which causes the new json result to be output.  Then replace the existing json tree with the new one.  If there was a problem with your submission, you'll get back FAIL + a message instead of json.  If you leave off output_format you will just get back an "OK" or a failure message.
+Thus when you submit new json data you should always output_format=json to the URL which causes the new json result to be output. Then replace the existing json tree with the new one. If there was a problem with your submission, you'll get back FAIL + a message instead of json. If you leave off output_format you will just get back an "OK" or a failure message.
-'''messagesend'''<br>
+'''messagesend'''<br> URL Parameters:<br>from=the originating device ID<br> to=the destination device id<br> type=the type of message<br> id=the message id<br> response=[r|o|c] for Return String, Output Parameters, and Confirmation of delivery. (Default=don't wait for response)<br> target=[c|t] meaning the 'to' id is not a device ID but rather a Category or Template of device. (Default='to' is a device id)<br> [device data]=some other message parameter, where 'device data' is the parameter number<br> output_format=[json_callback_xxx|html] is how you want the response to come back, where xxx is a function that you want called in java script
 URL Parameters:
 from=the originating device ID<br>
 to=the destination device id<br>
 type=the type of message<br>
 id=the message id<br>
-response=[r|o|c] for Return String, Output Parameters, and Confirmation of delivery.  Default=don't wait for response<br>
-target=[c|t] meaning the 'to' id is not a device ID but rather a Category or Template of device.  Default=to is a device id<br>
 [device data]=some other message parameter where device data is the number<br>
 output_format=[json_callback_xxx|html] is how you want the response to come back, where xxx is a function that you want called in java script
-For example, to request a video frame from a camera with the device id #20 you send the message type 1 (command) id 84 (get video frame) and optionally the parameter 60 and 61 (width and height of desired image).  The command returns output parameters 19 and 20 where 19 contains the video image and 20 the format.  So we want to send message with response=o because we want the request to block until the message is process by device 20 and we want to get back the output parameters.  Here is the URL:
+For example, to request a video frame from a camera with the device id #20 you send the message type 1 (command), id 84 (get video frame) and optionally the parameter 60 and 61 (width and height of desired image). The command returns output parameters 19 and 20 where 19 contains the video image and 20 the format. So you would send a message with response=o, causing the request to block until the message is processed by device 20, and to get back the output parameters. Here is the URL:
-http://192.168.80.1:3451/messagesend?from=1&to=20&response=o&type=1&id=84&60=640&61=480
+http://192.168.80.1:3451/messagesend?from=1&amp;to=20&amp;response=o&amp;type=1&amp;id=84&amp;60=640&amp;61=480
-'''messagesend_cmdline'''<br>
+'''messagesend_cmdline'''<br> message=The message in the same format as the command line utility /usr/bin/MessageSend URL encoded<br> output_format=same as messagesend
 message=The message in the same format as the command line utility /usr/bin/MessageSend URL encoded<br>
-output_format=same like messagesend
-'''simple_html'''<br>
+'''simple_html'''<br> A simple text-only html control interface for use on WAP phones<br>
 A simple text-only html control interface for use on WAP phones<br>
-'''iphone'''<br>
+'''iphone'''<br> A basic web-based iphone interface
 A basic web-based iphone interface
 == data_request ==

← Older revision		Revision as of 01:12, 21 June 2009
Line 108:		Line 108:

	'''lu_action'''<br>		'''lu_action'''<br>
−	Executes a UPNP action. Pass on the URL either ~~device~~=[number of device] or udn=[UDN of device]~~. Optionally pass serviceid~~=[serviceid], or, if you don't specify it, the first service with the given action is assumed. Pass the name of the action as 'action'. Any extra arguments will be passed as arguments to the action. The response to the UPNP action is returned in the output_format, or, if there's an error, an error string is returned instead. So this turns on light #13: http://ipadress:~~3451~~/data_request?id=lu_action&output_format=xml&~~device~~=13&action=SetTarget&newTargetValue=1	+	Executes a UPNP action. Pass on the URL either DeviceNum=[number of device] or udn=[UDN of device] and serviceId=[serviceid], or, if you don't specify it, the first service with the given action is assumed. Pass the name of the action as 'action'. Any extra arguments will be passed as arguments to the action. The response to the UPNP action is returned in the output_format, or, if there's an error, an error string is returned instead. So this turns on light #13: http://ipadress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=10&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

← Older revision		Revision as of 00:20, 1 May 2009
Line 106:		Line 106:
	'''lu_lua'''<br>		'''lu_lua'''<br>
	Returns the Lua code for the device specified in the parameter. The only output format is text. Example: http://192.168.1.102:3451/data_request?id=lu_lua&parameters=15		Returns the Lua code for the device specified in the parameter. The only output format is text. Example: http://192.168.1.102:3451/data_request?id=lu_lua&parameters=15
		+
		+	'''lu_action'''<br>
		+	Executes a UPNP action. Pass on the URL either device=[number of device] or udn=[UDN of device]. Optionally pass serviceid=[serviceid], or, if you don't specify it, the first service with the given action is assumed. Pass the name of the action as 'action'. Any extra arguments will be passed as arguments to the action. The response to the UPNP action is returned in the output_format, or, if there's an error, an error string is returned instead. So this turns on light #13: http://ipadress:3451/data_request?id=lu_action&output_format=xml&device=13&action=SetTarget&newTargetValue=1

← Older revision		Revision as of 04:01, 29 April 2009
Line 97:		Line 97:
	'''camera_control/xxx'''<br>		'''camera_control/xxx'''<br>
	Control for camera xxx		Control for camera xxx
		+
		+	'''lu_device'''<br>
		+	Return the LuaUPNP device description document in XML format. The only output format is xml. This is the same description document that is retrieved by UPNP control points when they interrogate Vera. Vera provides one master device (called Vera) which has embedded devices for lights, sensors, a/v gear, and so on. Get the master document like this: http://ipaddress:3451/data_request?id=lu_device or if you want to see only the device description for a particular embedded device add &parameters=[devicenumber] to the URL.
		+
		+	'''lu_file'''<br>
		+	Return the contents of the file 'lu_file' from the UPNP root file directory. Example: http://ipaddress:3451/data_request?id=lu_file&parameters=HVAC_ZoneThermostat1.xml
		+
		+	'''lu_lua'''<br>
		+	Returns the Lua code for the device specified in the parameter. The only output format is text. Example: http://192.168.1.102:3451/data_request?id=lu_lua&parameters=15

@@ Line 88: / Line 88: @@
 '''zwave_status'''<br>
 The status of all ZWave devices.  See [[ZWave_Status]]
 '''live_energy_usage'''<br>

@@ Line 76: / Line 76: @@
 parameters=parameters to send on the data request<br>
 input_format=format of the parameters being sent<br>
-output_format= the desired output format of the data
+output_format= the desired output format of the data (xml, json, or nothing for plain text)
 Every device in the system can register to handle a particular 'id'.  The parameters are defined by the device.  The input_format is what format you will send the parameters in, in case the device can handle multiple formats, and output_format is how to get the data out.  Here are the current id's:

@@ Line 4: / Line 4: @@
 '''user_data'''<br>
-Optional URL Parameters: outputformat=json<br>
+Optional URL Parameters: output_format=json<br>
 Post Variables: parm=[json data to update]<br>
@@ Line 40: / Line 40: @@
+}
-Note that Sections, Rooms, Devices, and Scenes are all numbered: PK_Room_1, scene_2, etc.  When are adding new Sections, Rooms, Devices, and Scenes, use a number that is very high (> 1,000,000) to prevent conflicts.  See how Room
+Note that Sections, Rooms, Devices, and Scenes are all numbered: PK_Room_1, scene_2, etc.  When are adding new Sections, Rooms, Devices, and Scenes, use a number that is very high (> 1,000,000) to prevent conflicts.  Note that Room uses a really large ID.  You don't want to use the next available ID, like 3, because that might already have been created by another user, and, since the ID # is the key to merging, your new room would be preserved and there would be 2 room 3's if json_action=add, or your changes would be merged and overwrite room 3 otherwise.  When you use large id's > 1m, then on save, the system automatically re-numbers them and re-outputs the renumbered result.  This includes relationships as well.  So if you are submitting a new scene, device, room, etc., the device may be id 1m, and reference room 2, so it goes into room 2, and a new device id 1m + 1 may reference room 1m.  In this case both device id's would be renumbered, and the room 1m would be renumbered, and the reference in the device id 1m + 1 would be changed to reflect this.