A suggestion for the python plugin framework
Posted: Wednesday 24 January 2018 22:58
While creating the RF Switched plugin I noticed a few things that I'd thought I'd share.
- Currently the python plugins operate very much under the assumption that you are adding some kind of hardware or connecting to a cloud service. But a lot of plugins may want to add very different kinds of functionality. For example:
- - Add new interface items (a new remote control?)
- - add a privacy feature
- - a plugin that manages the easy installation of other plugins.
- - A plugin that exports all blockly's
In my case I wanted to create a way for users to add switches. But there are currently no facilities to design even a basic interface for this, like a "start cloning" button, or a way to show some feedback to the user. For example:
- - I wanted to tell my users that they had 10 seconds to press the ON button on their remote, which the plugin would then record. Ideally with a countdown. If recording was succesfull, I would then like to tell them that step 2 is recording the 'off' button. But there was no way to do any of this. After I decided to 'hack' it by using a master switch to toggle this, I then found that there was no real way of saying "press the button now".
In practice I would suggest:
- Set the 255 devices limit to something much higher. As users create and delete new RF Switches they may hit this limit.
- It took a while before I figured out that you had to stick to the parameters that were set by the framework. If possible, allow users to create their own parameters and parameter names? If that's not possible, then I'd suggest to at least create a parameter (or two) that can hold a random string. One example of this problem is the way that the Smart Virtual Thermostat asks users to fill in comma-separated data. This is a smart hack, but it's not very user friendly.
- On a related note: currently the plugin stores the RF codes in a python shelve. But it would be nice if generated data like this could be stored inside the Domoticz database. That way, when people backup Domoticz, they can also backup the plugin data. (user variables are not an option, as they are tied to users and can be a maximum of 200 bytes long).
- Allow plugins to create popups and notifications in the interface (A more universal way would be to create an API call for this).
- Allow plugins to have other types of interface, like buttons, checkboxes and a text output area. This would have allowed the plugin to show a countdown and other details about where in the cloning process the plugin was.
- Please don't set fixed width of input elements in the plugin. Set a class instead, and then set the width in a css file (style.css). This has a number of advantages:
- - Themes can override the design of items that have classes.
- - If, for example, a parameter had extra css classes like "itemSelector" I could build functionality in javascript to allow people to select existing items form a dropdown list, instead of having to find the IDX of the item and fill that in manually. The Domoticz Api would make this easy. So my final suggestion is:
- Allow plugins to insert CSS and JS into Domoticz.
Unrelated thoughts:
- Perhaps show an overlay with a license the first time users enable a plugin? This could be a way of reminding people they are responsible for managing the dangers of installing plugins from the internet.
- This is probably a big one, but it would be great if python plugins could be in their own processes and could run permanently. For example, I'd love to create a companion plugin / expansion of the plugin that would allow Domoticz to respond to incoming RF signals, instead of just sending them out. But to do this I would have to create some kind of python deamon/listener. It would also allow my plugin to internalise all the code. Currently it uses a call to the shell to start the RF sniffing python script, so as not to interupt the other python plugins. But it would be great if that didn't matter.
Ok, a big list. I hope it this feedback is useful. This plugin stuff is mighty cool!
- Currently the python plugins operate very much under the assumption that you are adding some kind of hardware or connecting to a cloud service. But a lot of plugins may want to add very different kinds of functionality. For example:
- - Add new interface items (a new remote control?)
- - add a privacy feature
- - a plugin that manages the easy installation of other plugins.
- - A plugin that exports all blockly's
In my case I wanted to create a way for users to add switches. But there are currently no facilities to design even a basic interface for this, like a "start cloning" button, or a way to show some feedback to the user. For example:
- - I wanted to tell my users that they had 10 seconds to press the ON button on their remote, which the plugin would then record. Ideally with a countdown. If recording was succesfull, I would then like to tell them that step 2 is recording the 'off' button. But there was no way to do any of this. After I decided to 'hack' it by using a master switch to toggle this, I then found that there was no real way of saying "press the button now".
In practice I would suggest:
- Set the 255 devices limit to something much higher. As users create and delete new RF Switches they may hit this limit.
- It took a while before I figured out that you had to stick to the parameters that were set by the framework. If possible, allow users to create their own parameters and parameter names? If that's not possible, then I'd suggest to at least create a parameter (or two) that can hold a random string. One example of this problem is the way that the Smart Virtual Thermostat asks users to fill in comma-separated data. This is a smart hack, but it's not very user friendly.
- On a related note: currently the plugin stores the RF codes in a python shelve. But it would be nice if generated data like this could be stored inside the Domoticz database. That way, when people backup Domoticz, they can also backup the plugin data. (user variables are not an option, as they are tied to users and can be a maximum of 200 bytes long).
- Allow plugins to create popups and notifications in the interface (A more universal way would be to create an API call for this).
- Allow plugins to have other types of interface, like buttons, checkboxes and a text output area. This would have allowed the plugin to show a countdown and other details about where in the cloning process the plugin was.
- Please don't set fixed width of input elements in the plugin. Set a class instead, and then set the width in a css file (style.css). This has a number of advantages:
- - Themes can override the design of items that have classes.
- - If, for example, a parameter had extra css classes like "itemSelector" I could build functionality in javascript to allow people to select existing items form a dropdown list, instead of having to find the IDX of the item and fill that in manually. The Domoticz Api would make this easy. So my final suggestion is:
- Allow plugins to insert CSS and JS into Domoticz.
Unrelated thoughts:
- Perhaps show an overlay with a license the first time users enable a plugin? This could be a way of reminding people they are responsible for managing the dangers of installing plugins from the internet.
- This is probably a big one, but it would be great if python plugins could be in their own processes and could run permanently. For example, I'd love to create a companion plugin / expansion of the plugin that would allow Domoticz to respond to incoming RF signals, instead of just sending them out. But to do this I would have to create some kind of python deamon/listener. It would also allow my plugin to internalise all the code. Currently it uses a call to the shell to start the RF sniffing python script, so as not to interupt the other python plugins. But it would be great if that didn't matter.
Ok, a big list. I hope it this feedback is useful. This plugin stuff is mighty cool!
