add description how to setup devices in a plugin
@ -5,8 +5,8 @@ description = Gear up your Home!
|
||||
|
||||
dita.metadata.default.author = Simon Stürz
|
||||
dita.metadata.default.permissions = all
|
||||
dita.metadata.default.publisher = guh
|
||||
dita.metadata.default.copyryear = 2015
|
||||
dita.metadata.default.publisher = guh GmbH
|
||||
dita.metadata.default.copyryear = 2016
|
||||
dita.metadata.default.copyrholder = Simon Stürz
|
||||
dita.metadata.default.audience = programmer
|
||||
|
||||
|
||||
182
doc/create-setupmethods.qdoc
Normal file
@ -0,0 +1,182 @@
|
||||
/*!
|
||||
\page create-setupmethods.html
|
||||
\title CreateMethods and SetupMethods
|
||||
\brief This page describes how the setup and creation of a device is working in a plugin.
|
||||
|
||||
This page describes how the setup and creation of a device is working in a plugin. Since the device manager handles all the plugins and devices there are certain steps during the device setup which have to be considered.
|
||||
|
||||
The \l{DeviceClass::CreateMethods}{CreateMethod} describes how the device will be created (by the user, by discovery or automatically).
|
||||
The \l{DeviceClass::SetupMethod}{SetupMethod} describes how the device will be set up. A \l{Device} can have multiple \l{DeviceClass::CreateMethods}{CreateMethods}, but only one \l{DeviceClass::SetupMethod}{SetupMethod}.
|
||||
|
||||
\list
|
||||
\li - \l{DeviceClass::CreateMethods}{CreateMethods}
|
||||
\list
|
||||
\li \e user \unicode{0x2192} \l{DeviceClass::CreateMethodUser}
|
||||
\li \e discovery \unicode{0x2192} \l{DeviceClass::CreateMethodDiscovery}
|
||||
\li \e auto \unicode{0x2192} \l{DeviceClass::CreateMethodAuto}
|
||||
\endlist
|
||||
\li \l{DeviceClass::SetupMethod}{SetupMethods}
|
||||
\list
|
||||
\li \e justAdd \unicode{0x2192} \l{DeviceClass::SetupMethodJustAdd}
|
||||
\li \e displayPin \unicode{0x2192} \l{DeviceClass::SetupMethodDisplayPin}
|
||||
\li \e enterPin \unicode{0x2192} \l{DeviceClass::SetupMethodEnterPin}
|
||||
\li \e pushButton \unicode{0x2192} \l{DeviceClass::SetupMethodPushButton}
|
||||
\endlist
|
||||
\endlist
|
||||
|
||||
|
||||
\section1 CreateMethod \b "user" - SetupMethod \b "justAdd - synchronous"
|
||||
|
||||
This is the simplest setup what a device can have.
|
||||
|
||||
\list
|
||||
\li CreateMethod \b "user": the user has to fill out the \l{Param}{Params} of the device by hand
|
||||
\li SetupMethod \b "justAdd": there is nothing special to do during the setup with the device.
|
||||
\endlist
|
||||
|
||||
Once the is adding the device the \l{DeviceManager} is calling following methods in the device plugin:
|
||||
|
||||
\image setup-sync-resized.png
|
||||
|
||||
\list
|
||||
\li \b Setup
|
||||
\list
|
||||
\li \b 1. | The main setup of the device in the plugin.
|
||||
\li \b 2. | If something goes wrong during the setup return \l{DeviceManager::DeviceSetupStatusFailure}, otherwise \l{DeviceManager::DeviceSetupStatusSuccess}.
|
||||
\li \b 3. | If the device setup succeded and the device is in the system, the \l{DeviceManager} will call the \l{DevicePlugin::postSetupDevice()}{postSetupDevice()} method.
|
||||
\endlist
|
||||
\endlist
|
||||
|
||||
\section1 CreateMethod \b "user" - SetupMethod \b "justAdd" - asynchronous
|
||||
|
||||
\image setup-async-resized.png
|
||||
|
||||
\list
|
||||
\li \b Setup
|
||||
\list
|
||||
\li \b 1. | The main setup of the device in the plugin.
|
||||
\li \b 2. | If the status can not be determined immediately, we have to tell the \l{DeviceManager} that the status will be communicated later.
|
||||
\li \b 3. | Once the setup status is determined, the plugin can emit the signal \l{DevicePlugin::deviceSetupFinished} to inform the \l{DeviceManager} about the result.
|
||||
\li \b 4. | If the device setup succeded and the device is in the system, the \l{DeviceManager} will call the \l{DevicePlugin::postSetupDevice()}{postSetupDevice()} method.
|
||||
\endlist
|
||||
\endlist
|
||||
|
||||
\section1 CreateMethod \b "auto" - SetupMethod \b "justAdd"
|
||||
|
||||
\image setup-auto-resized.png
|
||||
|
||||
\list
|
||||
\li \b Monitor
|
||||
\list
|
||||
\li \b 1. | The method \l{DevicePlugin::startMonitoringAutoDevices()}{startMonitoringAutoDevices()} will be called once the \l{DeviceManager} has loaded all \l{DevicePlugin}{Plugins} and the discovery for auto devices can be started.
|
||||
\li \b 2. | Once the plugin has discovered one or more devices, the plugin can emit the signal \l{DevicePlugin::autoDevicesAppeared()} to inform the \l{DeviceManager} that new devices where found (without user interaction).
|
||||
\endlist
|
||||
\li \b Setup
|
||||
\list
|
||||
\li \b 3. | The plugin will be set up with the params of the auto discovered \l{DeviceDescriptor}.
|
||||
\li \b 4. | If something goes wrong during the setup return \l{DeviceManager::DeviceSetupStatusFailure}, otherwise \l{DeviceManager::DeviceSetupStatusSuccess}.
|
||||
\li \b 5. | If the device setup succeded and the device is in the system, the \l{DeviceManager} will call the \l{DevicePlugin::postSetupDevice()}{postSetupDevice()} method.
|
||||
\endlist
|
||||
\endlist
|
||||
|
||||
|
||||
\section1 CreateMethod \b "discovery" - SetupMethod \b "justAdd"
|
||||
|
||||
\image setup-discovery-resized.png
|
||||
|
||||
\list
|
||||
\li \b Discovery
|
||||
\list
|
||||
\li \b 1. | The user started to discover devices. The method \l{DevicePlugin::discoverDevices()}{discoverDevices()} will be called in the plugin.
|
||||
\li \b 2. | Return \l{DeviceManager::DeviceError}{DeviceErrorAsync} and start the discovery in the source code.
|
||||
\li \b 3. | Once the discovery is finished, the plugin can emit the signal \l{DevicePlugin::devicesDiscovered} to inform the \l{DeviceManager} about the result.
|
||||
\endlist
|
||||
\li \b Setup
|
||||
\list
|
||||
\li \b 4. | The plugin will be set up with the params of the discovered \l{DeviceDescriptor}.
|
||||
\li \b 5. | If something goes wrong during the setup return \l{DeviceManager::DeviceSetupStatusFailure}, otherwise \l{DeviceManager::DeviceSetupStatusSuccess}.
|
||||
\li \b 6. | If the device setup succeded and the device is in the system, the \l{DeviceManager} will call the \l{DevicePlugin::postSetupDevice()}{postSetupDevice()} method.
|
||||
\endlist
|
||||
\endlist
|
||||
|
||||
\section1 CreateMethod \b "discovery" - SetupMethod \b "pushButton"
|
||||
|
||||
\image setup-discovery-pairing-resized.png
|
||||
|
||||
\list
|
||||
\li \b Discovery
|
||||
\list
|
||||
\li \b 1. | The user started to discover devices. The method \l{DevicePlugin::discoverDevices()}{discoverDevices()} will be called in the plugin.
|
||||
\li \b 2. | Return \l{DeviceManager::DeviceError}{DeviceErrorAsync} and start the discovery in the source code.
|
||||
\li \b 3. | Once the discovery is finished, the plugin can emit the signal \l{DevicePlugin::devicesDiscovered} to inform the \l{DeviceManager} about the result.
|
||||
\endlist
|
||||
\li \b Pairing
|
||||
\list
|
||||
\li \b 4. | The user has already seen the pairing info with the push button instructions and should also already have pushed the button. The method \l{DevicePlugin::confirmPairing()} will be called. Here can be verified if the push button has been pressed and if the pairing succeeded.
|
||||
\li \b 5. | Returns the \l{DeviceManager::DeviceSetupStatus} to inform about the result (sync or async).
|
||||
\li \b 6. | Once the pairing has been verified (check if the button has been pushed) the plugin can emit the signal \l{DevicePlugin::pairingFinished()} to inform the \l{DeviceManager} about the result.
|
||||
\endlist
|
||||
\li \b Setup
|
||||
\list
|
||||
\li \b 7. | The plugin will be set up with the params of the paired \l{Device}.
|
||||
\li \b 8. | If something goes wrong during the setup return \l{DeviceManager::DeviceSetupStatusFailure}, otherwise \l{DeviceManager::DeviceSetupStatusSuccess}.
|
||||
\li \b 9. | If the device setup succeded and the device is in the system, the \l{DeviceManager} will call the \l{DevicePlugin::postSetupDevice()}{postSetupDevice()} method.
|
||||
\endlist
|
||||
\endlist
|
||||
|
||||
\section1 CreateMethod \b "discovery" - SetupMethod \b "enterPin"
|
||||
|
||||
\image setup-discovery-pairing-resized.png
|
||||
|
||||
\list
|
||||
\li \b Discovery
|
||||
\list
|
||||
\li \b 1. | The user started to discover devices. The method \l{DevicePlugin::discoverDevices()}{discoverDevices()} will be called in the plugin.
|
||||
\li \b 2. | Return \l{DeviceManager::DeviceError}{DeviceErrorAsync} and start the discovery in the source code.
|
||||
\li \b 3. | Once the discovery is finished, the plugin can emit the signal \l{DevicePlugin::devicesDiscovered} to inform the \l{DeviceManager} about the result.
|
||||
\endlist
|
||||
\li \b Pairing
|
||||
\list
|
||||
\li \b 4. | The user has already seen the pairing info with the instructions which pin should be entered. The method \l{DevicePlugin::confirmPairing()} will be called. Here can be verified if the entered pin is valid and if the pairing succeeded.
|
||||
\li \b 5. | Returns the \l{DeviceManager::DeviceSetupStatus} to inform about the result (sync or async).
|
||||
\li \b 6. | Once the pairing has been verified (check if the button has been pushed) the plugin can emit the signal \l{DevicePlugin::pairingFinished()} to inform the \l{DeviceManager} about the result.
|
||||
\endlist
|
||||
\li \b Setup
|
||||
\list
|
||||
\li \b 7. | The plugin will be set up with the params of the paired \l{Device}.
|
||||
\li \b 8. | If something goes wrong during the setup return \l{DeviceManager::DeviceSetupStatusFailure}, otherwise \l{DeviceManager::DeviceSetupStatusSuccess}.
|
||||
\li \b 9. | If the device setup succeded and the device is in the system, the \l{DeviceManager} will call the \l{DevicePlugin::postSetupDevice()}{postSetupDevice()} method.
|
||||
\endlist
|
||||
\endlist
|
||||
|
||||
|
||||
\section1 CreateMethod \b "discovery" - SetupMethod \b "displayPin"
|
||||
|
||||
\image setup-discovery-display-pin-resized.png
|
||||
|
||||
\list
|
||||
\li \b Discovery
|
||||
\list
|
||||
\li \b 1. | The user started to discover devices. The method \l{DevicePlugin::discoverDevices()}{discoverDevices()} will be called in the plugin.
|
||||
\li \b 2. | Return \l{DeviceManager::DeviceError}{DeviceErrorAsync} and start the discovery in the source code.
|
||||
\li \b 3. | Once the discovery is finished, the plugin can emit the signal \l{DevicePlugin::devicesDiscovered} to inform the \l{DeviceManager} about the result.
|
||||
\endlist
|
||||
\li \b{Display pin}
|
||||
\list
|
||||
\li \b 4. | Once the user selected one of the discovered devices the device manager will call the method \l{DevicePlugin::displayPin()} in the plugin. Here can be sent the command to display the pin on the device. The pin which will be displayed on the device will be passed as secret in the \l{DevicePlugin::confirmPairing()} method.
|
||||
\li \b 5. | Returns the \l{DeviceManager::DeviceError} to inform about the result (sync or async).
|
||||
\endlist
|
||||
\li \b Pairing
|
||||
\list
|
||||
\li \b 4. | The user should see now the pin on the display and the pairing info. The method \l{DevicePlugin::confirmPairing()} will be called once he entered the pin. Here can be verified if the pin is authorized by the device and if the pairing succeeded.
|
||||
\li \b 5. | Returns the \l{DeviceManager::DeviceSetupStatus} to inform about the result (sync or async).
|
||||
\li \b 6. | Once the pairing has been verified (check if the button has been pushed) the plugin can emit the signal \l{DevicePlugin::pairingFinished()} to inform the \l{DeviceManager} about the result.
|
||||
\endlist
|
||||
\li \b Setup
|
||||
\list
|
||||
\li \b 7. | The plugin will be set up with the params (i.e. containing a \tt pin param) of the paired \l{Device}.
|
||||
\li \b 8. | If something goes wrong during the setup return \l{DeviceManager::DeviceSetupStatusFailure}, otherwise \l{DeviceManager::DeviceSetupStatusSuccess}.
|
||||
\li \b 9. | If the device setup succeded and the device is in the system, the \l{DeviceManager} will call the \l{DevicePlugin::postSetupDevice()}{postSetupDevice()} method.
|
||||
\endlist
|
||||
\endlist
|
||||
*/
|
||||
@ -3,6 +3,8 @@
|
||||
\title Getting Started
|
||||
\brief Understanding the basic concept of guh plugins
|
||||
|
||||
\b{\unicode{0x2192} \underline{\l{https://www.youtube.com/watch?v=B8oqItKCcgU}{Video for this tutorial}}}
|
||||
|
||||
Plugins in guh are used to exand the functionalitys and capabilitys of the guh server. A plugin is basically a shared library, which will be loaded dynamically from the guh server during the start up process. Each plugin has a \e name, a \e uuid and a list of supported \e vendors which will be visible in the system once the plugin is loaded. Each of thouse \l{Vendor}{Vendors} contains a list of supported \l{DeviceClass}{DeviceClasses}. A \l{DeviceClass} describes how the supported \l{Device} looks like, how it will be created (\l{DeviceClass::CreateMethod}{CreateMethod}), how the setup (\l{DeviceClass::SetupMethod}{SetupMethod}) looks like and what you can do with the \l{Device}.
|
||||
|
||||
\section1 Devices
|
||||
@ -20,11 +22,9 @@
|
||||
\section1 Hardware resources
|
||||
The \e libguh provides a list of \l{Hardware Resources}{HardwareResources}, which can be used in every plugin. When sou start writing a plugin, you need to know which resource you will need. Each resource provides it's own interface for a \l{DevicePlugin}. In the plugin you don't have to take care about the resource.
|
||||
|
||||
|
||||
\section1 Getting started with a plugin
|
||||
In order to show how a plugin ist structured here is an example of the most minimalistic device plugin possible for the guh system.
|
||||
|
||||
|
||||
For an easier start we provide a set of plugin templates which can be used for your own plugin and to have a basic for the tutorials described in this documentation. You can get the templates with following command:
|
||||
|
||||
\code
|
||||
@ -76,7 +76,6 @@
|
||||
The \b SOURCES and \b HEADERS variables define the \tt .cpp and \tt .h files of your plugin like in any other Qt project.
|
||||
|
||||
|
||||
|
||||
\section3 plugins.pri
|
||||
The \tt plugins.pri file contains all relevant definitions and configuration to build a plugin. Each plugin must contain this file and \underline{should not} be changed. In this file the precompiler \b guh-generateplugininfo will be called.
|
||||
\code
|
||||
@ -85,8 +84,8 @@
|
||||
|
||||
QT += network
|
||||
|
||||
QMAKE_CXXFLAGS += -Werror
|
||||
CONFIG += c++11
|
||||
QMAKE_CXXFLAGS += -Werror -std=c++11
|
||||
QMAKE_LFLAGS += -std=c++11
|
||||
|
||||
INCLUDEPATH += /usr/include/guh
|
||||
LIBS += -lguh
|
||||
@ -105,12 +104,12 @@
|
||||
\endcode
|
||||
|
||||
|
||||
If you need an extra Qt module i.e. \tt serialport please add it in the \tt <pluginName>.pro file an not in the \tt plugin.pri:
|
||||
If you need an extra Qt module i.e. \tt serialport please add it in the \tt <pluginName>.pro file an \underline{not} in the \tt plugin.pri:
|
||||
\note Please make sure you have installed the corresponding development libs i.e. \b{\tt{sudo apt-get install libqt5serialport5-dev}}
|
||||
\code
|
||||
QT += serialport
|
||||
\endcode
|
||||
|
||||
|
||||
\section3 devicepluginminimal.json
|
||||
The properties of a plugin will be definend with in the \tt JSON file containing all needed information for guh to load it. The name convention fot the json file is:
|
||||
|
||||
@ -118,7 +117,7 @@
|
||||
|
||||
This file must have a clear, definend structure and looking like this:
|
||||
|
||||
\note For more details about the structure, values and Objects please take a look at the \l{The Plugin JSON File} documentation.
|
||||
\note For more details about the structure, values and objects please take a look at the \l{The Plugin JSON File} documentation.
|
||||
|
||||
\code
|
||||
{
|
||||
@ -136,6 +135,9 @@
|
||||
"idName": "minimal",
|
||||
"name": "Minimal device",
|
||||
"createMethods": ["user"],
|
||||
"basicTags": [
|
||||
"Device"
|
||||
],
|
||||
"paramTypes": [
|
||||
{
|
||||
"name": "name",
|
||||
@ -212,6 +214,6 @@
|
||||
}
|
||||
\endcode
|
||||
|
||||
You can start with \l{Tutorial 1 - The "Minimal" plugin}.
|
||||
Now you can start with \l{Tutorial 1 - The "Minimal" plugin}.
|
||||
|
||||
*/
|
||||
|
||||
@ -24,7 +24,7 @@ HTML.postpostheader = \
|
||||
HTML.footer = \
|
||||
"<div class=\"footer\">\n" \
|
||||
" <p>\n" \
|
||||
" <acronym title=\"Copyright\">©</acronym> 2013-2015 guh. All rights reserved. <a href=\"license.html\">License</a>" \
|
||||
" <acronym title=\"Copyright\">©</acronym> 2013-2016 guh GmbH. All rights reserved. <a href=\"license.html\">License</a>" \
|
||||
" </p>\n" \
|
||||
"</div>\n" \
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 146 KiB |
BIN
doc/images/setup-async-resized.png
Normal file
|
After Width: | Height: | Size: 63 KiB |
BIN
doc/images/setup-async.odg
Normal file
BIN
doc/images/setup-async.png
Normal file
|
After Width: | Height: | Size: 146 KiB |
BIN
doc/images/setup-auto-resized.png
Normal file
|
After Width: | Height: | Size: 68 KiB |
BIN
doc/images/setup-auto.odg
Normal file
BIN
doc/images/setup-auto.png
Normal file
|
After Width: | Height: | Size: 160 KiB |
BIN
doc/images/setup-discovery-display-pin-resized.png
Normal file
|
After Width: | Height: | Size: 134 KiB |
BIN
doc/images/setup-discovery-display-pin.odg
Normal file
BIN
doc/images/setup-discovery-display-pin.png
Normal file
|
After Width: | Height: | Size: 319 KiB |
BIN
doc/images/setup-discovery-pairing-resized.png
Normal file
|
After Width: | Height: | Size: 118 KiB |
BIN
doc/images/setup-discovery-pairing.odg
Normal file
BIN
doc/images/setup-discovery-pairing.png
Normal file
|
After Width: | Height: | Size: 277 KiB |
BIN
doc/images/setup-discovery-resized.png
Normal file
|
After Width: | Height: | Size: 76 KiB |
BIN
doc/images/setup-discovery-sync.png
Normal file
|
After Width: | Height: | Size: 178 KiB |
BIN
doc/images/setup-discovery.odg
Normal file
BIN
doc/images/setup-sync-resized.png
Normal file
|
After Width: | Height: | Size: 41 KiB |
BIN
doc/images/setup-sync.odg
Normal file
BIN
doc/images/setup-sync.png
Normal file
|
After Width: | Height: | Size: 96 KiB |
@ -3,7 +3,7 @@
|
||||
\title License
|
||||
\brief The license agreement of guh
|
||||
|
||||
Copyright 2015 Simon Stürz <simon.stuerz@guh.guru>.
|
||||
Copyright 2013-2016 Simon Stürz <simon.stuerz@guh.guru>.
|
||||
|
||||
\section1 GNU GENERAL PUBLIC LICENSE
|
||||
|
||||
|
||||
@ -1,12 +1,3 @@
|
||||
/ *!
|
||||
\legalese
|
||||
|
||||
Copyright 2015 Simon Stürz <simon.stuerz@guh.guru>.
|
||||
|
||||
Guh is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2 of the License. Guh is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with guh. If not, see \l{http://www.gnu.org/licenses/}.
|
||||
\endlegalese
|
||||
* /
|
||||
|
||||
/*!
|
||||
\page plugin-json.html
|
||||
\title The plugin JSON File
|
||||
@ -31,7 +22,6 @@
|
||||
The \tt plugininfo.h has to be included in the main plugin \tt cpp file (\tt{deviceplugin<\b pluginName>.cpp}). The \tt extern-plugininfo.h can be included in other classes/files of the plugin to get the extern definitions of the ID's and the logging category.
|
||||
|
||||
|
||||
|
||||
\section1 Basic structure
|
||||
|
||||
The name convention fot the plugin json file is:
|
||||
@ -59,51 +49,51 @@
|
||||
}
|
||||
\endcode
|
||||
|
||||
\warning For each new Object which has an \e "uuid" value, you need to generate a new UUID. The easyest way to do this is using the command \tt uuidgen:
|
||||
\warning For each new object which has an \e "uuid" value, you need to generate a new UUID. The easyest way to do this is using the command \tt uuidgen:
|
||||
|
||||
\code
|
||||
$ sudo apt-get install uuid-runtime
|
||||
$ sudo apt-get install uuid-runtime
|
||||
\endcode
|
||||
|
||||
\code
|
||||
$ uuidgen
|
||||
cd938452-213d-432f-ae7a-3ef3c474fe99
|
||||
$ uuidgen
|
||||
cd938452-213d-432f-ae7a-3ef3c474fe99
|
||||
\endcode
|
||||
|
||||
|
||||
|
||||
|
||||
\section1 Writing the plugin JSON file
|
||||
|
||||
\section2 The Plugin definition
|
||||
The parameters of the first Object (\e name, \e idName, \e id and \e vendors) describe the properties of the plugin it self.
|
||||
The parameters of the first object (\e name, \e idName, \e id and \e vendors) describe the properties of the plugin it self.
|
||||
|
||||
\code
|
||||
{
|
||||
"name": "Name of the plugin",
|
||||
"idName": "PluginName",
|
||||
"id": "uuid",
|
||||
"vendors": [
|
||||
{
|
||||
{
|
||||
"name": "Name of the plugin",
|
||||
"idName": "PluginName",
|
||||
"id": "uuid",
|
||||
"paramTypes": [
|
||||
...
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"vendors": [
|
||||
{
|
||||
...
|
||||
}
|
||||
]
|
||||
}
|
||||
\endcode
|
||||
|
||||
\note All parameters \underline{must} be definend!
|
||||
|
||||
\list
|
||||
\li - \underline{\e name:} The visible name of the plugin \unicode{0x2192} \l{DevicePlugin::pluginName()}
|
||||
\li - \underline{\e idName:} This parameter will be used to define the PluginId variable named <idName>PluginId in the plugininfo.h, so it can be used in the code. This parameter also defines the logging categorie for this plugin. The loging category will always definend as \tt dc<idName> and can be used as follows (\tt {"idName":"Example"}):
|
||||
|
||||
\code
|
||||
qCdebug(dcExample) << "Hello world!";
|
||||
qCWarning(dcExample) << "Warning the world!";
|
||||
qCWarning(dcExample) << "Warning the world!";
|
||||
\endcode
|
||||
|
||||
Please start allways with a capital letter i.e. \tt {"idName": "Example"}. The logging category allowes you to categorise the debug output. It can be configured with the \tt -d argument of guhd (see \tt {$ man guhd}).
|
||||
\li - \underline{\e id:} The actual uuid (\l{PluginId}) of the plugin \unicode{0x2192} \l{DevicePlugin::pluginId()}
|
||||
\li - \underline{\e id:} The actual uuid (\l{PluginId}) of the plugin \unicode{0x2192} \l{DevicePlugin::pluginId()}
|
||||
\li - \underline{\e paramTypes:} Optionl: A list of \l{ParamType}{ParamTypes} which define the paramters of this plugin \unicode{0x2192} \l{DevicePlugin::configuration()} (see section "\l{The ParamType definition}").
|
||||
\li - \underline{\e vendors:} The list of \l{Vendor}{Vendors} objects (see section "\l{The Vendor definition}");
|
||||
\endlist
|
||||
|
||||
@ -151,10 +141,10 @@
|
||||
"idName": "deviceClassName",
|
||||
"deviceClassId": "uuid",
|
||||
"basicTags": [
|
||||
"BasicTag"
|
||||
"BasicTag"
|
||||
],
|
||||
"createMethods": [
|
||||
"CreateMethod"
|
||||
"CreateMethod"
|
||||
],
|
||||
"setupMethod": "SetupMethod",
|
||||
"pairingInfo": "Information how to pair the device.",
|
||||
@ -296,7 +286,8 @@ A \l{StateType} has following parameters:
|
||||
\li - \underline{\e idName:} This parameter will be used to define the StateTypeId variable named <idName>StateTypeId in the plugininfo.h, so it can be used in the code.
|
||||
\li - \underline{\e id:} The actual uuid (\l{StateTypeId}) of the \l{StateType} \unicode{0x2192} \l{StateType::id()}.
|
||||
\li - \underline{\e type:} The data type of this state \unicode{0x2192} \l{StateType::type()}.
|
||||
\li - \underline{\e unit:} With this parameter you can specify the unit of the state value i.e. \unicode{0x00B0}C \unicode{0x2192} DegreeCelsius.
|
||||
\li - \underline{\e unit:} With this parameter you can specify the unit of the state value i.e. \unicode{0x00B0}C \unicode{0x2192} DegreeCelsius (\l{Types::Unit}).
|
||||
\li - \underline{\e possibleValues:} Gives you the possibility to define a list of possible values which this state can have. This allowes a user to create a rule based on a state and define only values which are possible. This is typically used for strings i.e. ["Loading", "Installing", "Removing"].
|
||||
\li - \underline{\e defaultValue:} The state will be initialized with this value.
|
||||
\li - \underline{\e writable:} If you define the "\e writable : true" value an \l{ActionType} will be created to set the \l{State} value. The created \l{ActionType} has the same uuid (\l{ActionTypeId}) like the \l{StateType} uuid and will be named "set <stateName>". The \l{ParamType} of the created \l{ActionType} will have the same values in the \e allowedValues list as the \l{StateType} in the \e possibleValues list. Also the \e minValue / \e maxValue will be taken over from the \l{StateType}.
|
||||
|
||||
@ -314,7 +305,7 @@ This mechanism was created to ensure that the \l{EventType} and \l{ActionType} w
|
||||
"id": "9bc84381-785f-46bf-94c8-6e35116f50d3",
|
||||
"idName": "volume",
|
||||
"name": "volume",
|
||||
"unit": "UnitPercentage",
|
||||
"unit": "Percentage",
|
||||
"type": "int",
|
||||
"minValue": 0,
|
||||
"maxValue": 100,
|
||||
@ -333,7 +324,7 @@ This mechanism was created to ensure that the \l{EventType} and \l{ActionType} w
|
||||
"type": "int",
|
||||
"maxValue": 100,
|
||||
"minValue": 0,
|
||||
"unit": "UnitPercentage"
|
||||
"unit": "Percentage"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@ -3,6 +3,8 @@
|
||||
\title Set up the build environment
|
||||
\brief This tutorial shows you how to set up the build environment for developing guh.
|
||||
|
||||
\b{\unicode{0x2192} \underline{\l{https://www.youtube.com/watch?v=7a_k0C1Ib1A}{Video for this tutorial}}}
|
||||
|
||||
Assuming you are working on an Ubuntu system here are the steps how to set up the build environment. Basically you can choose your prefered SDK but all tutorials are based on the Qt Creator and we recommand to use that one. You can also use the Ubuntu SDK, which is basically a modified Qt Creator.
|
||||
|
||||
\note Please take care that you are using the Qt version from the system for building. The guh server will allways be built with the official Qt version for the appropriate system version. The plugin \underline{must} have the same version like the guh server.
|
||||
|
||||
@ -4,7 +4,12 @@
|
||||
\brief This tutorial shows you how to open, edit, build and load the first plugin.
|
||||
\ingroup tutorials
|
||||
|
||||
This first tutorial shows you how to open, edit, build and load the first plugin.
|
||||
\section1 Topics
|
||||
This first tutorial shows you how to:
|
||||
\list
|
||||
\li \unicode{0x25B6} Open and edit the project
|
||||
\li \unicode{0x25B6} Build and load the first plugin.
|
||||
\endlist
|
||||
|
||||
\section1 Open the project
|
||||
Assuming you already have downloaded the \l{https://github.com/guh/plugin-templates}{plugin-templates} you can open the \tt {plugin-templates \unicode{0x2192} minimal \unicode{0x2192} minimal.pro} file with the Qt Creator.
|
||||
|
||||
@ -7,9 +7,15 @@
|
||||
|
||||
In the second tutorial we make our own first plugin with the name \b {"Buttons"}. We will use this name for the naming concentions of the filenames.
|
||||
|
||||
This plugin will show you how to implement \l{Action}{Actions}.
|
||||
\section1 Topics
|
||||
This tutorial will show you how to:
|
||||
\list
|
||||
\li \unicode{0x25B6} Start with a new \l{DevicePlugin}{Plugin}
|
||||
\li \unicode{0x25B6} Implement an \l{Action}
|
||||
\li \unicode{0x25B6} Implement an \l{Event}
|
||||
\endlist
|
||||
|
||||
In order to get started with our new \b {"Button"} plugin we use the \b {"Minimal"} plugin as template and start from there. Make a copy of the minimal folder and name the new folder \b buttons-diy. In this case \b{buttons-diy} because the folder \b buttons already exits from the \tt plugin-template repository.
|
||||
In order to getting started with the new \b {"Button"} plugin we use the \b {"Minimal"} plugin as template and start from there. Make a copy of the minimal folder and name the new folder \b buttons-diy. In this case \b{buttons-diy} because the folder \b buttons already exits from the \tt plugin-template repository.
|
||||
|
||||
\section1 Create the basic structure
|
||||
\code
|
||||
|
||||
@ -7,9 +7,15 @@
|
||||
|
||||
In the third tutorial we use the project from \l{Tutorial 2 - The "Buttons" plugin}{Tutorial 2} and add a new button type to the existing plugin.
|
||||
|
||||
This device will show you how to implement \l{State}{States} and how \l{Param}{Params} will be used in \l{Action}{Actions} and \l{Event}{Events}.
|
||||
\section1 Topics
|
||||
This tutorial will show you how to:
|
||||
\list
|
||||
\li \unicode{0x25B6} Implement a \l{State}
|
||||
\li \unicode{0x25B6} Use \l{Param}{Params} in an \l{Event}
|
||||
\li \unicode{0x25B6} Use \l{Param}{Params} in an \l{Action}
|
||||
\endlist
|
||||
|
||||
Our new "Power Button" will be able to execute an \l Action and set the \l State of the \l Device \tt true or \tt false .
|
||||
Our new "Power Button" will be able to execute an \l Action and set the \l State of the \l Device \tt true or \tt false .
|
||||
|
||||
\section1 Add a new DeviceClass
|
||||
|
||||
|
||||
@ -3,7 +3,13 @@
|
||||
\title Tutorial 4 - The alternative "Power Button"
|
||||
\brief This device demonstrates how a writable state works.
|
||||
\ingroup tutorials
|
||||
|
||||
|
||||
\section1 Topics
|
||||
This tutorial will show you how to:
|
||||
\list
|
||||
\li \unicode{0x25B6} Implement a writable \l{State} (which can be manipulated by an \l{Action})
|
||||
\endlist
|
||||
|
||||
In the fourth tutorial you will see how a \e writable \l State works. We use the \l DeviceClass \b {"Power Button"} from the previouse \l{Tutorial 3 - The "Power Button" device}{Tutorial 3} for that and create a new one called \b {"Alternative Power Button"}. It does exactly the same like the \b {"Power Button"} except it will be created in a different way for a good reason.
|
||||
|
||||
\section1 Add a new DeviceClass
|
||||
@ -42,7 +48,7 @@
|
||||
|
||||
As you can see, there is only one \tt bool \l State which has the property \e {"writable"}. This property indicates, that this \l State is writable and we need an \l Action for doing that. You can find more details about this property in \l {The StateType definition} documentation.
|
||||
|
||||
We learnend in the previouse tutorial that a \l State will allways generate an \l Event when he changes his \e {value}. This \l Event has the same UUID as the \l State which generated the \l Event. The same thing happens with the \l Action if you make a \l State writable. The devicemanager defines a new \l ActionType which has the same UUID as the \l State which will be changed with the \l Action.
|
||||
We learnend in the previouse tutorial that a \l State will allways generate an \l Event when he changes his \e {value}. This \l Event has the same UUID as the \l State which generated the \l Event. The same thing happens with the \l Action if you make a \l State writable. The device manager defines a new \l ActionType which has the same UUID as the \l State which will be changed with the \l Action.
|
||||
|
||||
\tt {\l{StateTypeId} == \l{EventTypeId} == \l{ActionTypeId}}
|
||||
|
||||
|
||||
@ -4,6 +4,12 @@
|
||||
\brief The plugin shows you how to use the NetworkManager and how asynchronous actions work
|
||||
\ingroup tutorials
|
||||
|
||||
\section1 Topics
|
||||
This tutorial will show you how to:
|
||||
\list
|
||||
\li \unicode{0x25B6} Use hardware resource \l{NetworkManager}
|
||||
\endlist
|
||||
|
||||
|
||||
In the tutorial we make a plugin with the name \b {"Network Info"}. This plugin will use the \l{NetworkManager} hardware resource to fetch the location and WAN ip of your internet connection from \l{http://ip-api.com/json}. It will have an \l Action called \e "update" which will refresh the \l{State}{States} of the \l{Device}.
|
||||
|
||||
|
||||
@ -4,7 +4,20 @@
|
||||
\brief The plugin shows you how to use the CoAP lib
|
||||
\ingroup tutorials
|
||||
|
||||
\section1 Topics
|
||||
This tutorial will show you how to:
|
||||
\list
|
||||
\li \unicode{0x25B6} Allow only one \l{Device}
|
||||
\li \unicode{0x25B6} Implement the \l{DevicePlugin::deviceRemoved()}{deviceRemoved()} method
|
||||
\li \unicode{0x25B6} Use plugin configurations
|
||||
\li \unicode{0x25B6} Use the \l{Coap}{CoAP} library
|
||||
\endlist
|
||||
|
||||
This tutorial shows you how to write a \l{Coap}{CoAP} plugin and how the plugin configuration work. The plugin it self has no practical purpose but shows some concepts of CoAP and plugin development.
|
||||
|
||||
\section1 Plugin structure
|
||||
|
||||
networkinfo.pro
|
||||
|
||||
*/
|
||||
|
||||
|
||||
@ -6,13 +6,41 @@
|
||||
\li \l{Set up the build environment}
|
||||
\li \l{Getting started}
|
||||
\li \l{The plugin JSON File}
|
||||
\li \l{CreateMethods and SetupMethods}
|
||||
\li \l{Tutorials}
|
||||
\list
|
||||
\li \l{Tutorial 1 - The "Minimal" plugin}
|
||||
\list
|
||||
\li Open and edit the project
|
||||
\li Build and load the first plugin.
|
||||
\endlist
|
||||
\li \l{Tutorial 2 - The "Buttons" plugin}
|
||||
\list
|
||||
\li Start with a new \l{DevicePlugin}{Plugin}
|
||||
\li Implement an \l{Action}
|
||||
\li Implement an \l{Event}
|
||||
\endlist
|
||||
\li \l{Tutorial 3 - The "Power Button" device}
|
||||
\list
|
||||
\li Implement a \l{State}
|
||||
\li Use \l{Param}{Params} in an \l{Event}
|
||||
\li Use \l{Param}{Params} in an \l{Action}
|
||||
\endlist
|
||||
\li \l{Tutorial 4 - The alternative "Power Button"}
|
||||
\list
|
||||
\li Implement a writable \l{State} (which can be manipulated by an \l{Action})
|
||||
\endlist
|
||||
\li \l{Tutorial 5 - The "Network Info" plugin}
|
||||
\list
|
||||
\li Use hardware resource \l{NetworkManager}
|
||||
\endlist
|
||||
\li \l{Tutorial 6 - The "CoAP Client" plugin}
|
||||
\list
|
||||
\li Allow only one \l{Device}
|
||||
\li Implement the \l{DevicePlugin::deviceRemoved()}{deviceRemoved()} method
|
||||
\li Use \l{DevicePlugin}{Plugin} configurations
|
||||
\li Use the \l{Coap}{CoAP} library
|
||||
\endlist
|
||||
\endlist
|
||||
\endlist
|
||||
*/
|
||||
|
||||