Service Add-ons

[tim-hellhake]

There are many things which use the concept of a thing although they aren't really things.
There is already an issue proposing notification addons (#1758).
Although I fully agree I think it's a general problem.
There are other examples where the thing concept doesn't really fit.

For example:

• date-time-adapter
• pulse-adapter
• speed-test-adapter
• twilio-adapter
• voice-addon
• wake-on-lan-adapter
• weather-adapter

There is already some abstraction in the weather-adapter which hides multiple weather providers behind the weather device. If someone wants to add a new weather provider he would have to modify the existing weather-adapter because the abstraction is located there.

I really like the concept of capabilities in the WoT spec which allows the things to describe themselves instead of hardcoding certain devices types.
So how about introducing the general concept of a Service?
The @type property could define which type of service it is.

For example, a NotificationService requires a NotifyAction.
The NotifyAction requires a message and a receiver.
In case of slack the receiver could be a person or a channel.
The gateway would be aware of all notification services and could group them in the rules view as Notify action.

A WeatherService would require a set of weather-related properties.

There could be also multiple PresenceService implementations for different ways to detect the presence of a user.

New types of services could be added by simply adding a new type to the WoT spec.

[raidnet-ms]

I totally agree

[flatsiedatsie]

I'd say this is part of a larger question about functionality and the long term vision behind the Mozilla Gateway.

How I see it, you need:

• Basic technical support for things
• Services
• Automations
• User rights system
• Interface extension

Currently the Mozilla Gateway seems focused on getting feature parity with most solutions, which is understandable.

However, it would be a good idea to explore how the Gateway would 'one up' the devices currently on the market, and grow beyond the 'a router for things' paradigm. Perhaps organize some workshops internally to explore how these things form the basis for next-level features on top of all that. For example:

• Apps. These are extensions that combine things into new useful features.

• • For example, an app could combine a motion detector pointed at a bed with a connection to a stereo and a dimmable light, and turn these into a virtual wake-up light that slowly wakes up the user when they are in the optimal part of their sleep cycle.
• • A power-disaggregation app would use machine learning to learn and monitor how much power devices in the home use. It can then suggest more power-efficient devices.
• • A smart virtual thermostat app could learn how heat dissipates in the home by learning which rooms are heated more frequently and how quickly they cool down again. it could create optimal heating, and also suggest ways of improving energy use.

Also:

• Next level user system which more closely models a family unit, and less closely models the hierarchical structures seen in current ICT solutions. I believe we need a system in which users can
• • make democratic decisions, instead of leaving it to an admin.
• • gain virtual 'human rights'. These are different from current user rights. Some can not be revoked, others can only be revoked by a majority of the people in the home. For example, once a child reached the age of 12 they may be given the 'veto' right over all things in their bedroom, which not even the admin can overrule. However, the bedroom door lock could get a majority-override: if a majority of the family members wanted it, they door would be unlocked.

In my opinion there's always an understandable desire to focus on technical excellence and broad device support. That's what everybody is doing. "We will win if we support more devices than the competition, and fix this mess where there are so many different standards".

However, I think that's not what is keeping people from making their homes smarter. What is missing is the next step beyond that, in which a user-centered analysis of what normal people really need leads to loads of fun (and privacy-protecting) integrations on top of that standardised base. And to do a good analysis of this you need to talk to ethnographers, sociologists and psychologists that know a lot about social dynamics around the home.

For me all this is summarized as "don't be a router, be a platform".

[raidnet-ms]

I also agree that a router software may have several limits. This should mostly be a platform.

About extensions what do you think about Joomla way to define different kind of extension?

[benfrancis]

I kind of agree. In addition to the add-ons for notification services like email/twitter/slack/twilio which could become notifier add-ons, there are quite a few adapter add-ons being submitted which don't actually represent physical devices.

Controlling a software Spotifier player is perhaps a good example. Date/time, weather and the idea of representing OpenStreetMap locations as web things are also strange examples. Arguably a location like a restaurant building is a "thing", but does it really have properties, actions and events which represent a physical state? Same with weather, I think you could argue it either way. Weather at least represents state in the real world, but where do we draw the line? Can any web service be a web thing? That seems wrong.

The Twitter add-on is currently for sending tweets, which makes sense as a notifier. But imagine you wanted to use Twitter as an input, say to display text on an LCD display or change the colour of lights based on the number of tweets using a particular hashtag. Twitter isn't a "thing", but it is a service which might be used as an input. Another example might be using calendar events as an input, e.g. to show the status of a meeting room.

I think we might want to collect more examples before deciding what exactly to do here. I don't necessarily think we want the gateway to become a general app platform, but I can forsee use cases which don't neatly fit into an adapter, notifier or extension add-on.

[flatsiedatsie]

App might indeed be a big word, meant more metaphorical here than actual. That would require a store, an expansive API, etc. But I think that if add-ons could generate a little interface, then you're moving in a good direction, one where the community could bring more to the table. Currently, more and more add-on developers are trying to do this, and ending up shoe-horning things into the things model. I myself am running into this.

[mrstegeman]

Our current plan for "Service add-ons" is to allow a background process which:

• Doesn't serve as an adapter or notifier
• Accesses the gateway via the Web Thing API and does things

[flatsiedatsie]

How is a service add-on different from an adapter?

In my experience I often want add-ons to do multiple things. Be an adapter and a notifier and a UI expansion at the same time.

Voco, for example:

• Creates a Voco thing (adapter)
• Requires access to all things, needs to be able to change their values, and needs to know when their names change (API)
• Provides rules the ability to output text-to-speech (notifier)
• Could have a UI extension part in the future, for example to see a visual overview of all the alarms, timers and perhaps even recurring rules they have set (UI extension).