Extension Add-ons

[benfrancis]

As a developer I want to write an add-on which extends the user interface of the Things Gateway.

This might include:

• Collections of web components to represent third party device schemas
• Adding top level menu entries to add a whole new section to the UI

Questions:

• How would these add-ons be packaged?
• What can we learn from Web Extensions here?
• How can we do this safely?

[flatsiedatsie]

Great!

Add-ons packaging
Existing open source home automation projects have wildly different approaches to this, ranging from zip file upload, to Github url input and some forms of terminal scripts which install the often required OS libraries (GPIO access, bluetooth GATT, etc).

Security
Security is indeed the issue here. From my limited discussions on this it seems that the most secure way would be to host a github project for add-ons where people may add them to. This would be option A, the highly walled garden approach.
A slightly less walled garden (option B) would allow users to send in code which, after an optional inspection, becomes accepted into the 'add-on store'. They can still manage their code elsewhere in between these deposits. If something malicious is found, then it can be removed from the store.

A third model would create a plugin-system that limits how much damage a plugin can do. Domoticz has the Python Plugin system, which has functionality to create things in the interface and also to get data out of Domoticz. This can be a completely separate system from the add-on system. The add-ons would offer 'deeper' functionality and would be more thoroughly vetted, while these 'plugins' would be a higher level aspect, and would more often work with things that are already available in the system. Perhaps 'plugins' could have dependencies on 'add-ons'. As an aside, the plugin level could also work as a way to add theming. Or you could split of an even higher third level of 'themes' that may only include client side javascript and CSS.

A fourth "Wild West" option (D) would be the "at your own risk" model, where users can add any code simply by pasting in a link from a github page.

A mix could be that a group of special 'guinea pig' users is appointed. They try new add-ons and can spot issues before they are accepted to the main stream. It might be a simple checkbox in the interface to become a guinea pig. If there haven't been issues after X amount of guinea pig hours (users * length of time installed per user), or of a certain mound of users say that they found no issues, then the code could be deamed 'safe' for broader consumption.

In all cases you would probably need a standardised schema for how the add-ons can inform which OS libraries are required. (and how plugins could inform which add-ons they rely on, if you want to go that route).

How much control you want to go for depends on the goals of the Gateway project.

[benfrancis]

I should mention that we do already have an add-ons system for "adapter add-ons" which use npm packages, an IPC API, a GitHub repository to list them and checksums to verify their integrity.

This issue is about adding a new type of add-ons which modify the gateway's UI.

[flatsiedatsie]

Good point :-D

[flatsiedatsie]

I had some fun doodling. Some of them are pretty far out.

Add-ons settings pages could help users manage settings, and even help users get an idea of which devices they govern. Here's an example of a MySensors add-on. Users can use this to easily upload code to Arduino's that they attach to the Raspberry Pi.

Add-ons could offer things like wizards to help on-board new devices.

Here's another example for a 433Mhz cloning add-on:

With a similar wizard:

Not all add-ons are about adding things to the system. Some could focus more on creating software functionality, and could perhaps be called apps instead. Perhaps technically they are the same thing.

Here's the settings page of an "app" that adds photo frame functionality:

But I could imaging all kinds of apps that try to wrangle the available functionality into larger types of over-arching functionality.

[createcandle]

Here's a practical example of an interface I'd like to incorporate into the Mozilla Gateway somehow:
https://github.com/createcandle/Candle-manager

[flatsiedatsie]

Here's another mockup.

The idea would be:

• Apps can have a display page. Once started, 'apps' can take up the entire screen. The side menu would always be on top of any 'app'. This would allow for, for example, a photo display app.
• Apps can bring along a settings page. This could be made to preferentially conform to the Gateway's CSS, but still allow for custom JS. Settings pages allow for the launch of settings wizards that aid users in the generation of new devices / recording of new signals, etc.
• Apps can bring along 'widgets'. These are tiny templates (schemas?) for data display. They have 'slots' where users can add existing data sources. This could allow them to overlay simple graphs, create a list of toggle buttons, create a widget optimised for weather forecasts, home energy usage, car charging status, etc. These widgets could become a marketplace all of themselves.

In my experience it's really useful if people can mix and match existing data into new display constellations. They often want to bring disparate sensors from different devices together in one view/widget.

Here's a quick bad mockup of what a dashboard could look like. In reality these widgets could be made to be more in one style if some useful ready made widgets are bundled with the Mozilla Gateway.

[flatsiedatsie]

Maybe another useful example of an 'app' is a virtual thermostat. It's something that very useful. It uses your existing temperature sensors and actuators to toggle heaters on and of. It uses a PID algorithm, allowing for very stable temperatures in your home. It can handle multiple rooms, and for each room will automatically learn how well isolated it is.

[flatsiedatsie]

I was thinking: what if the add-on settings page is expanded a little bit as follows:

• The json schema is still transformed into a basic HTML form, as it is now.
• That form is now a html page that is inside an iframe.
• An add-on can add javascript to that html page, so that the basic form can be transformed into more advanced interfaces (wizards, fancy selectors, etc). The iFrame would limit the reach of that javascript.
• The javascript could interact with the add-on in a very basic way to pull/poll updated data from it. For example, in the case of the presence detection add-on, a list of found devices on the wireless network could be updated by the add-on. The javascript could pull in the updated list and display it inside a textarea. This textarea has another bit of javascript code to turn it into a fancy selector tool. The user can then select which device on the wireless network they want to add as a thing, and send this knowledge back to the add-on, which then only presents those devices as things.
• The add-on settings page could, perhaps through a checkbox, gain a shortcut inside the main menu. That way it could become more like an 'app'.

[flatsiedatsie]

Perhaps as an interesting example I'm currently working on an add-on that needs a complex interface. The add-on now creates a thing with an "alt" link. If you click on it it opens a new page in a new tab. This page is served by the Flask webserver (on a different port) that the add-on launches and manages.

Using a wizard, it will allow users to upload code to Arduino's that they attach via USB.

[mrstegeman]

I'm going to close this issue now that we can build extensions. Any additional extension points that we want can be filed in their own issues.