dSS Addons - deprecated. Talk to us before you start development

The purpose of dSS addons is to extend the functionality of the digitalSTROM Server. Developers can upload their addons to the digitalSTROM app repository. Before end users can download them to their digitalSTROM Server, a thorough sanity check will be performed before the packaged addon is released.

General Considerations

dSS-addons can be divided in three different classes, which can be charactized by their usage:

  1. Background-only addons: This class of addons extends the functionality of a dS-System by adding some new features or automation to the system, but it don't provide any significant UI at all.
  2. UI-only addons: This class of addons have a extensive UI but no oder just minor backend functionality. The addon "mobile-remote-control" is good example for that kind of app.
  3. Full-Featured addons: This addon will provide both a fully fledged UI and some complex backend logic.

There are also three additional characteristics, which can apply on a high-level view on a a addon:

  1. system-addon: These addons will by installed by default on a dSS-platform. Apps as the scene-responder or the timed-event should be allways part of the dSS, because they provide essential extensions for a dS-System. This apps are maintained by the dSS-Plattform provider and may provide also a base for other apps.
  2. UIs based on the dss-addon-framework: On the dSS-Plattform the dss-addon-framework is provided as a UI Framework, mainly to provide a shared consistent UI-Library for the system addons. Other addons can also utilize that framework for their own UI, but that is not a mandatory regulation.
  3. dependent addons: Generelly most apps will define a structure or a way of communication between its UI and backend. This might be direct communication via events or indirect communication via reading and writing a property. Theoretical a second addon can also utilize that way of communication to control the first addon remote. But that might be very harmful, because there are no explicit dependency rules or system in the background to ensure such kind of addon-relations. So it is not adviseable to make such addons with maybe only one exception: interfacing a system-addon via a configuration-event. But that should be also be done with caution.

Structure of a addon project

An addon usually consists of the three folders
  1. ui: contains the end-user facing frond end.
  2. scripts: contains the backend scripts running directly within the dSS process on the dSS hardware.
  3. config: contains event subscriptions for the backend script(s).

Conventions

  • When defining own events, prepend the event name with the name of the script, i.e. myapp.myeventname to avoid collisions with other addons
  • Mailbox configuration for scripts that wish to send e-mails can be read from the following place in the property tree:
    /config/credentials/mail/mailserver
    /config/credentials/mail/login
    /config/credentials/mail/password
    /config/credentials/mail/sender
    /config/credentials/mail/receiver
    

    Sending a email should be done using event, which targets a subscription with the sendmail eventhandler