Plugins development

Note

If you think something is not clear or is missing in this documentation, please send an email to our developers mailing list : domogik-developers@lists.labs.libre-entreprise.org and explain us clearly what is not clear or what could be added.

First, create a repository and write some specifications

Plugin name

Choose a name that describes the plugin as good as possible. Notice that a plugin can not use more than 8 characters and they should be all lower case. This restriction is linked to xPL and is not a Domogik limitation.

Prepare the plugin

See workflow, step 1

Now, you will have to create a few files for your plugin on the master branch.

Json file

See workflow, step 3

The info.json file it surely the most important part of a plugin. It will describe the configuration of the plugins, the features, the xPL messages to send and to listen, … You should first read all this chapter, then make sure that you already defined the following part in your specifications :

  • configuration parameters
  • devices features, splitted in sensors and commands
  • xPL messages used by these features
  • the data to store in database

Starting to create the json file without being clear on these elements is useless!

Note

To help you to understand the way to create a json file, you can look on already existing plugins to see real examples.

Python part

See workflow, step 3

After creating a start script (used only by the developers), you will now create the python part of your plugin.

Dedicated administration page

See workflow, step 3

Some plugin may need some advanced configuration capabilities or some helpers feature that can be used from the administration interface. This is not mandatory.

Icon

See workflow, step 3

Your plugin should have an icon.

Udev rules

See workflow, step 3

If needed, you can add some sample udev rules files for your plugin.

Tests

See workflow, step 3

Preparing some automated tests is something really important for a plugin. It will help you to test automatically the plugin after each commit and will help you to easily validate some contributions (pull requests).

Your plugin is ready ? Make some users test it

See workflow, step 4

Now, your plugin may be functional, documented and the tests are automated. It is time to release a version! But before, you should make some people test your plugin!

Release a version of your plugin

See workflow, step 5

..todo ::
  • switch to develop
  • create a branch per version for readthedoc ????
  • update info.json version number
  • update docs/conf.py version number
  • do the dev/doc/tests
  • switch to master when version is ready (see previous chapter)

Some other points

  • Helpers
  • Data files