Data Provider Catalog Plugin

From MiOS
Revision as of 19:00, 9 October 2008 by Micasaverde (Talk | contribs)

Jump to: navigation, search

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.

So, for example, the media plugin can register to provide a set of data with the ID "SongsByArtist", and a security module can provide a set of data with the ID "ListOfSecurityBreaches". These devices register with Data_Provider_Catalog_Plugin, which then becomes a single point for requesting data.

Request data from Data_Provider_Catalog_Plugin by sending it the message CMD_Request_Data_Provider (ID 971), which includes parameters where you can indicate what format you want the data in (ie XML, plain text, etc.), what input parameters are provided to the data source (ie "SongsByArtist" may require an input parameter of "Artist ID").

The Data_Provider_Catalog_Plugin is in the category 174 (DEVICECATEGORY_Data_Provider_Catalog_Plugins_CONST). One device that registers to provide general purpose data sources is Shared_JSON_Data_Provider_Plug, and one of the data ID's it registers is "alldata", which returns all the common user data in the system (ie list of devices, scenes, etc.). It provides it in 'json' format.

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.

To request data, request "data_request" from the http server and include the parameters:

id=id of the data request

parameters=parameters to send on the data request

input_format=format of the parameters being sent

output_format= the desired output format of the data

for example the following URL returns the same list of 'alldata' described earlier:

http://192.168.80.1:3451/data_request?id=alldata&output_format=json

You can also use this to send messages by requesting "messagesend" and adding the parameters:

from=the originating device ID

to=the destination device id

type=the type of message

id=the message id

response=[r|o|c] for Return String, Output Parameters, and Confirmation of delivery. Default=don't wait for response

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

[device data]=some other message parameter where device data is the number

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:

http://192.168.80.1:3451/messagesend?from=1&to=20&response=o&type=1&id=84&60=640&61=480

The response will be "OK" if the message succeeds, or "FAIL" if it didn't, followed by the values of the output parameters. Because output parameter #20 is defined as 'binary', the result is uuencoded and the U after the 20 indicates this. The above returns:

OK

[19=3]

jpg

[20U=18373]

[uu encoded video frame]

So parameter 19 is 3 bytes long ("jpg"), and 20 is UU encoded with 18373 characters.

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

So the following makes the camera with device id #20 move right:

http://192.168.80.1:3451/data_request?id=camera_control/20&parameters=right

and the following returns a single video frame from the camera

http://192.168.80.1:3451/data_request?id=camera_control/20&parameters=get_video_frame

If you turn on the findvera.com remote access, you can also securely access your box's port 3451 remotely with to control it, fetch devices, etc. with this syntax:

https://[ra server]/[username]/[password]/3451/

Different installations use different remote access servers. The ra server for a given installation is defined in your system file: /etc/cmh/RA_Server. If you have an application that prompts the user for his username/password, such as a cell phone app, call this to get the ra server for a given username: https://findvera.com/get_server.php?username=[username]

So with a username of testvera9 and password of myvera123, the following: https://ra1.findvera.com/testvera9/myvera123/3451/data_request?id=simple_device_list&output_format=txt is the list of devices

Personal tools