Data Provider Catalog Plugin - Revision history

A-lurker at 02:27, 15 June 2013

2013-06-15T02:27:47Z

Henk at 15:19, 28 May 2011

2011-05-28T15:19:04Z

Javier at 03:30, 14 April 2010

2010-04-14T03:30:28Z

LibraSun at 15:19, 2 August 2009

2009-08-02T15:19:36Z

Show changes

Micasaverde at 03:29, 29 April 2009

2009-04-29T03:29:02Z

Nixterrimus at 06:41, 21 April 2009

2009-04-21T06:41:17Z

Nixterrimus at 04:47, 20 April 2009

2009-04-20T04:47:12Z

Micasaverde: /* Understanding the messages */

2009-03-12T15:37:54Z

‎Understanding the messages

Micasaverde at 00:36, 18 February 2009

2009-02-18T00:36:30Z

Micasaverde at 23:50, 17 February 2009

2009-02-17T23:50:58Z

← Older revision		Revision as of 02:27, 15 June 2013
Line 1:		Line 1:
−	~~[[Category:Development]]~~
	[[Category:Obsolete]]		[[Category:Obsolete]]
	----		----

@@ Line 1: / Line 1: @@
 [[Category:Development]]
 [[Category:Obsolete]]
 This has a general overview of the request architecture. For a list of requests see [[Data Provider Catalog Plugin Requests]].

← Older revision		Revision as of 03:30, 14 April 2010
Line 1:		Line 1:
		+	[[Category:Development]]
		+	[[Category:Obsolete]]
	This has a general overview of the request architecture. For a list of requests see [[Data Provider Catalog Plugin Requests]].		This has a general overview of the request architecture. For a list of requests see [[Data Provider Catalog Plugin Requests]].

@@ Line 3: / Line 3: @@
 == Introduction ==
-To understand the Data Provider Catalog plugin, it's helpful to have a general understanding of the DCE Router, DCE Devices, and general LinuxMCE development.  For a gentle introduction to these concepts, refer to the [http://wiki.linuxmce.org/index.php/Developers_Guide guide provided by LinuxMCE].
+Our goal is to allow developers to expand the functionality of Vera, adding custom UI's, and so on, without any knowledge of C/C++, or any of the under-the-hood LinuxMCE internals, like DCE, DCERouter, etc.  If you want to know more about the underlying LinuxMCE DCE architecture, and DCERouter, there is a good introduction here: [http://wiki.linuxmce.org/index.php/Developers_Guide guide provided by LinuxMCE].  The new [[LuaUPnP]] API allows you to communicate with all the devices in the system using standard UPNP calls, and you can write your own custom drivers in Lua, instead of using C/C++ and the DCE libraries.
-For many functions, the upcoming [[LuaUPnP]] API may be better choice.
+The Data Provider Catalog Plugin provides an easy way to get data, such as device listing, device status, and so on, using standard HTTP calls.  You can also use the same HTTP calls to send messages, initiate UPNP actions, and so on.
 == Information ==
-== Information from Linux MCE ==
-−
-The following information is based on Linux MCE's wiki on [http://wiki.linuxmce.org/index.php/Data_Provider_Catalog_Plugin Data Provider plugin].  For more information on the data provider visit the Linux MCE wiki.
 The Data_Provider_Catalog_Plugin runs as a plugin for the DCERouter.  It acts as an aggregator for data sources.  Other devices in the network can register with it by sending the command CMD_Register_Data_Provider and register to provide data, which is identified by a unique ID.  This is intended to replace the DataGrid concept previously in LinuxMCE.

@@ Line 1: / Line 1: @@
-This has a general overview of the request architecture.  For a list of requests see [[Data_Provider_Catalog_Plugin_Requests]]
+This has a general overview of the request architecture.  For a list of requests see [[Data_Provider_Catalog_Plugin_Requests]].
 == Information from Linux MCE ==
 The following information is based on Linux MCE's wiki on [http://wiki.linuxmce.org/index.php/Data_Provider_Catalog_Plugin Data Provider plugin].  For more information on the data provider visit the Linux MCE wiki.

← Older revision		Revision as of 04:47, 20 April 2009
Line 1:		Line 1:
	This has a general overview of the request architecture. For a list of requests see [[Data_Provider_Catalog_Plugin_Requests]]		This has a general overview of the request architecture. For a list of requests see [[Data_Provider_Catalog_Plugin_Requests]]
		+
		+
		+	== Information from Linux MCE ==
		+	The following information is based on Linux MCE's wiki on [http://wiki.linuxmce.org/index.php/Data_Provider_Catalog_Plugin Data Provider plugin]. For more information on the data provider visit the Linux MCE wiki.

	The Data_Provider_Catalog_Plugin runs as a plugin for the DCERouter. It acts as an aggregator for data sources. Other devices in the network can register with it by sending the command CMD_Register_Data_Provider and register to provide data, which is identified by a unique ID. This is intended to replace the DataGrid concept previously in LinuxMCE.		The Data_Provider_Catalog_Plugin runs as a plugin for the DCERouter. It acts as an aggregator for data sources. Other devices in the network can register with it by sending the command CMD_Register_Data_Provider and register to provide data, which is identified by a unique ID. This is intended to replace the DataGrid concept previously in LinuxMCE.

@@ Line 106: / Line 106: @@
 Note that you can also retrieve the raw json files directly using a cgi-bin: http://[ip address]/cgi-bin/cmh/get_json.sh?file=xx.json where xx is:<br>
-devices = the list of devices and all the device parameters<br>
+user_data = user specific data, like scenes, timers, events and devices<br>
-user_data = user specified data, like scenes, timers and events<br>
 template_data = static data defining the structure of commands, events, device templates, etc<br>
 timezone =  the known time zones<br>
-so calling http://[ip address]/cgi-bin/cmh/get_json.sh?file=devices.json will return the raw json data file containing the list of devices, and this will be similar to the data returned by the call http://[ip address]:3451/data_request?id=alldata&output_format=json, except the former is returning the raw data from the file system, and the latter is using Data Provider Catalog Plugin's port to return the data.
+so calling http://[ip address]/cgi-bin/cmh/get_json.sh?file=template_data.json will return the raw json data.  Note that you can request the user_data.json file, but the data may be out of date.  This data may change dynamically as the system is in use and, since the flash memory in the chip has a limited number of re-writes, rather than re-writing the user_data.json file everytime something changes, DCERouter will update an internal copy, and only periodically flush the changes to the RAM drive with user_data.json on it.  So for the most up to date user_data, use the request: http://[ip address]:3451/user_data?output_format=json or, if you want it in XML format: http://[ip address]:3451/user_data?output_format=xml.
 The data file template_data has the master definition for Device Templates, commands, events, and data configuration.

← Older revision		Revision as of 00:36, 18 February 2009
Line 54:		Line 54:

	So parameter 19 is 3 bytes long ("jpg"), and 20 is UU encoded with 18373 characters.		So parameter 19 is 3 bytes long ("jpg"), and 20 is UU encoded with 18373 characters.
		+
		+	If you are sending commands to a device that creates 'jobs', like for example, sending an on or off to the Z-Wave module, you should request a response, either response=r or response=o, and the OK will be followed by the job id. Then, if you want to get the status of the job, send a message type MESSAGETYPE_PENDING_TASKS (14) and the ID is the job # to the parent device that handles the job. For example, if you have a device 15, which is a light switch, and it's controlled by device 9, which is a zwave module:
		+
		+	send the off: http://192.168.80.1:3451/messagesend?from=1&to=15&response=r&type=1&id=193<br>
		+	I will get back something like: OK 2037, so 2037 is the job id, now:<br>
		+	send the request: http://192.168.80.1:3451/messagesend?from=1&to=9&response=o&type=14&id=2037<br>
		+	and I get back the status of 2037.<br>
		+

	Other plugins can register to provide certain types of data. For example, for each ip camera it manages Generic_IP_Camera_Manager registers the id "camera_control/device #". The parameters it recognizes are: get_video_frame, left, right, up, down, zoom_in, zoom_out		Other plugins can register to provide certain types of data. For example, for each ip camera it manages Generic_IP_Camera_Manager registers the id "camera_control/device #". The parameters it recognizes are: get_video_frame, left, right, up, down, zoom_in, zoom_out

@@ Line 11: / Line 11: @@
 So to get this data you can use the MessageSend utility as follows:
 /usr/bin/MessageSend dcerouter -o -targetType category 0 174 1 971 10 alldata
 The Data_Provider_Catalog_Plugin also includes a small http service which can be used to request data as well as to send messages which listens on port 3451.  Previously when outside applications, like a php page, wanted to send messages they would do a system call to spawn the /usr/bin/MessageSend utility.  This is inefficient because it makes a system call each time.