You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

<< Work in progress. Contents are under review >>


Most of the up-to-data examples with the new JSONRPC can be found here : https://github.com/WebPlatformForEmbedded/ThunderNanoServices/tree/master/examples

This directory contains two Example plugins, called : JSONRPCPlugin and OutOfProcessPlugin.

This directory also contains an example on how to communicate from outside of the Thunder framework, to the ThunderFramework (bidirectional). The JSONRPC Client is a stand-alone application that connect to the JSONRPCPlugin.

For using the plugins, the documentation (API documentation ) is pretty well documented. This is due to the fact that the documentation is automatically generated from the interface specification. The API specifications for each plugin can be found here:
https://github.com/WebPlatformForEmbedded/ThunderNanoServices/blob/master/README.md

Plugins can be developed in a large variety, in process, out-of-process, out-of host, and each plugin can exploit a large scale over communication protocols, JSONRPC/COMRPC, MessagePackRPC.

Steps involved in implementing new Thunder Plug-In

Interface Specification in wpeframework 

  1. <PluginName>.json

       Add <PluginName>.json in wpeframework module so as to define the interfaces.

          https://github.com/WebPlatformForEmbedded/Thunder/tree/master/Source/interfaces/json

          eg: DeviceInfo.json

          After adding the json file and compilation of wpeframework, it will autogenerate header file JsonData_PluginName.h 

          eg: JsonData_DeviceInfo.h

          This header will be used from wpeframework-plugins module. 

Plugin Development in wpeframework-plugins

In wpeframework-plugins workspace :

(cloned from https://github.com/WebPlatformForEmbedded/ThunderNanoServices/)

Create PluginName folder 


Inside PluginName directory:

1. Create “CmakeLists.txt” to compile the Plug-in code and to generate the shared library (“.so”)

This will handle all the dependencies as well


2. Module.h: This header file includes the support for JSON request, response, logging etc.,

3. Module.cpp: This file is used to declare the module name for the Plug-in


4. <PluginName>Plugin.json:

This file contains the plugin's information like schema, information and interface json file (defined earlier)

            Ex:-

{
  "$schema": "plugin.schema.json",
  "info": {
    "title": "Plugin Name Plugin",
    "callsign": "PluginName",
    "locator": "libWPEFrameworkPluginName.so",
    "status": "production",
    "description": "The PluginName plugin allows retrieving of various plugin-related information.",
    "version": "1.0"
  },
  "interface": {
    "$ref": "{interfacedir}/PluginName.json#"
  }
}


5.  <PluginName>.config: This file is used to set configurations of the Plug-in 

Ex:- set (autostart true)

Used to make the Plug-in to start automatically along with wpeframework daemon

We can set some other parameters based on our need


6. <PluginName>.h

Declare the plugin class in this which should contains all the structures, variables and methods which are needed for plugin implementation. The interface header auto-generated earlier will be used here,

            Ex:-   Declare the class in the following name space with constructor and destructor: 

namespace WPEFramework {
	namespace Plugin {
	
		class PluginName : public PluginHost::IPlugin, public PluginHost::IWeb, public PluginHost::JSONRPC {
		public:
				PluginName()
					: _skipURL(0)
					, _service(nullptr)
					, _subSystem(nullptr)
				{
					RegisterAll();
				}

				virtual ~PluginName()
				{
					UnregisterAll();
				}
		} 

            Declare the methods in the above class, required to implement the functionality of the plugin 


These methods are used to place collection of plugin JSON interface methods to register & unregister with JSON RPCs APIs      

void RegisterAll();
void UnregisterAll(); 

These methods are used to initialize and deinitialize the handlers for the plug-in service

virtual const string Initialize(PluginHost::IShell* service);
virtual void Deinitialize(PluginHost::IShell* service); 

These are are the JSON interface (get/set) methods to communicate with plugin

uint32_t get_method(JsonData::Plugin::ClassName& response) const;
uint32_t set_method(JsonData::Plugin::ClassName& response) const; 

This method is used to process the REST APIs request such as GET/POST/SET and return the response

virtual Core::ProxyType<Web::Response> Process(const Web::Request& request) override;


 7. <PluginName>.cpp: This class does contains all the definitions for the methods declared in the Plugin.h and those definitions should be defined inside the below namespace. 

         The plugin should register using service registration MACRO as declared below: 

namespace WPEFramework {
	namespace Plugin {  
		SERVICE_REGISTRATION(Plugin, 1, 0);
		//All the methods declared in Plugin.h should be defined here
	}
}


 8.  <PluginName>JsonRpc.cpp: This class is used to register the methods with JSON RPC interface as below

            Ex:- 

namespace WPEFramework { 

namespace Plugin {

	using namespace JsonData::PluginName; 	
	
    void Plugin::RegisterAll()
    {
		//Can register any number of methods in this way
		Property<className>(_T("parameter1"), &PluginName::get_method, nullptr, this);
		Property<className>(_T("parameter2"), &PluginName::set_method, nullptr, this);
    }

	void Plugin::UnregisterAll()
    {
    	Unregister(_T("parameter1"));
        Unregister(_T("parameter2"));
	}
}
} 

The registered (get / set ) methods are defined in the same file

uint32_t Plugin::get_method(ClassName& response) const
{
	//body of the method
}

uint32_t Plugin::set_method(ClassName& response) const
{
	//body of the method
}       


9.  <PluginName>HAL.cpp: Used to communicate to driver layer in order to get some information or to set some properties.


Please refer to any existing plugins in https://github.com/WebPlatformForEmbedded/ThunderNanoServices/ 

or in workspace of RDK4.0 Beta build:

(rdkv_4.0_beta/build-raspberrypi-rdk-hybrid-thunder/tmp/work/cortexa7t2hf-neon-vfpv4-rdk-linux-gnueabi/wpeframework-plugins/3.0+gitrAUTOINC+886f9025b3-r1/git/)

for further clarifications

Compilation and Install

Enable the plugin in the main CMakeLists.txt of wpeframework-plugins


bitbake wpeframework-plugins

will generate <PluginName>.json and libWPEFrameworkPlugin.so

Copy the plugin library (libWPEFrameworkPlugin.so) to “/usr/lib/wpeframework/plugins” 

Copy the Plugin.json file to “/etc/WPEFramework/plugins” so that the controller plugin identify it and list it in the WebUI (controller UI ) 


Restart the service

systemctl restart wpeframework


Using the command “$ journalctl – u wpeframework | grep <plug-in name>” we can identify, if the newly added plug-in got activated or not

If the plug-in got activated, it will be listed in the WebUI and using Controller plug-in we can control (activate / deactivate) the newly added plugin

Validation

REST APIs based curl command:

Request:

curl --request GET http://127.0.0.1:9998/Service/<pluginName>/<function>

eg: $ curl --request GET http://127.0.0.1:9998/Service/Picture/Brightness

Response:

{"brightness":100}

JSON RPC APIs based curl command:

Request:

$ curl --data-binary '{"jsonrpc": "2.0", "id": 3, "method": "Picture.1.brightness"}' http://127.0.0.1:9998/jsonrpc

Response:

{"jsonrpc":"2.0","id":3,"result":{"brightness":100},"success"}



  • No labels