The core of the platform are the rules and the rule configurator. The rule configurator allows a customer to edit the pre-defined rules that are available or to add and edit new rules.

The editor consists of six main components:

1. Data graph

2. Datasets

3. Condition

4. Message

5. Settings

6. Command

7. Rule Simulator

This documentation guides you through all the core features and contains relevant information for the integration with your systems.

Click the card below to start exploring our documentation.

The core of the platform are the rules. A rule is a combination of datasets, conditions, settings and notification which should be sent to the household.

When navigating to the Rules Menu the first screen that is presented is the Rules Overview. It displays all rules that are currently activated for your customer.

MOOST has a pre-defined set of rules that can be activated for a customer. Each customer has the possibility to add custom new rules to the platform by clicking "Add Rule".

You have the option of analyzing the performance of each individual rule by clicking on the round analysis icon or checking and editing each rule in the rule configurator by clicking on the pencil icon next to the rule.

New Users

To be able to login to the Recommender Platform you need a login. The User Management is currently done by MOOST. If you need a new user to be added to an existing customer please fill out the ticket here and the MOOST Support will get back to you asap.

Existing Users

When you already have an account for the Recommender Platform fill in the form on the right of the screen using the email address which was provided to MOOST during the onboarding process and the corresponding password.

The Notification Overview is a powerful tool to keep track of recent notifications and analyze data over a certain period. The page's features, such as search functionality, column selection, time frame adjustment, and pagination, make it easy for users to customize the view according to their needs.

The dashboard provides users with additional insight into their notification strategy, allowing them to quickly identify which rules are generating the most notifications, how users are engaging with notifications, and how effective the notification delivery process is.

Dashboard

The Dashboard provides users with additional insight into their notification strategy.

• The "Rules" chart shows how many notifications of a specific rule were sent in percent, allowing users to quickly identify which rules are generating the most notifications.

• The "Interactions" chart shows the interaction rate of the sent notifications in percent, providing insight into how users are engaging with notifications.

• The "Delivery Status" chart shows the rate in percent if notifications were actually delivered or dropped, providing insight into how effective the notification delivery process is.

• The "Delivered Notifications" heatmp gives you insights which rules are sending most recommendations to endusers on a daily basis. It helps to identify if there is an imbalance in one of the rules configured on your tenant.

Data Table

The table on the bottom of the page displays detail information about the latest notifications sent. The table includes columns such as the notification name, date and time, recipient, and other relevant information. Each row in the table represents a single notification, and users can adjust how many notifications are shown at once by adjusting the page limit.

Toolbar

Located on top of the page is the toolbar which allows you to adjust which information is shown in the charts and the data table.

Filter

The filter functionality on the top of the page allows users to filter for specific notifications by building, rule, delivery status, interactions and time range.

The part on top of the rule configurator is called the data graph. It visualizes the data which is defined by the datasets of the rule for a certain building.

Action Bar

The bar at the top of the data graph is called the action bar. It features settings, like

• the active toggle of a rule

• the building and time range selector, which define which data is visualized within the datagraph

• the drop down menu, which contains Delete, Export and Import functionality.

Filter for Building Selector

The filter is able to reduce the displayed buildings of the building selector. By default the "Dataset scoped buildings" option is turned on, so that the building only displays buildings which match to the dataset of the rule.

Building Selector

On top of the data graph is the building selector. The building selector allows you to visualize the datasets of a rule for a specific building.

Date Range Selector

Next to the building selector is the date range selector. The date range selector defines for which date range the datasets will be visualized. It also defines for which date range a simulation run will be executed when clicking on "RUN SIMULATION" in the action bar.

Graph

On top of the graph are the notifications as a envelop icon, which were generated by the rule. Below the notifications, the datasets that have been defined in the rule are displayed as a time series.

Datapoints

Each line is a the representation of a set of datapoints which we have in the system for the selected building. By hovering over a data point of the line the value of the respective datapoint is displayed.

Datasets

Datasets are the basis of each rule. You may attach one or multiple event types, and optionally a set of event sources to a dataset.

The created datasets are rendered in the graph as a single line per event and source type. The displayed datasets can be found in the legend on top of the graph. By clicking on the name of a dataset in the legend the line for the dataset can be hidden or displayed.

They y-axis is dynamically changed according to the types which are defined on the datasets.

Y-Axis

The y-axis differ in the scale that they provide, and it is able to display data types, even when having a mixed dataset of different unit types. For example if a dataset is temperature based, and another one is power based, the y-axis renders both a scale for temperature in °C, and for power in W.

Notifications

At the top of the graph you may see notifications that were generated by the rule. They are represented by small envelops. The color of the envelops represent the status of the notification:

Visualization

Hover over the notification icon to see the notification message which was generated. This is the same content that users saw on their device, if the notification was delivered.

Actions

• Delete a dataset by clicking on the "x"-cross icon on the right side of a dataset.

Dataset Configuration Form

A dataset defines a set of data points which can be included in the rule's condition and the notification message.

A dataset consists of the following properties:

Name

The name of the dataset. It is recommended to use a self-explaining name. This name can be used as variable in rule condition and rule message.

Description

This field may be used to describe the dataset in more detail. This field is optional

Type

This field defines whether we are interested only in a single value, or a whole time series:

• Single Value: only the last matching event is relevant

• Time Series: all matching events of specified timeframe are relevant

Event Types

This field defines which event type(s) shall be matched.

Source Types

This field defines which source(s) shall be matched. This field is optional

Timeframe

This field is only visible if type Time Series is selected, and it defines the size of the timeframe for the time series.

A condition defines a boolean expression. If this condition is fulfilled (true), then a notification is created which eventually then is going to be delivered to the customer.

The condition can be expressed as a mathematical expression producing a boolean value, which consists of:

• dataset references E.g. $MyConsumption refers to the dataset with name MyConsumption

• values E.g. number 1000

• operators E.g. plus operator +, or comparison operator =

• functions E.g. average function AVG(...), which calculates the average of specified time series

When a rule's condition matches, then a message is created and possibly sent to the customer. A message consists of a title, a message text, and actions (primary & secondary). It needs to be defined for languages German, English and optionally French.

Message Title

This field contains the content for the message title.

Message Text

This field contains the content for the message text, and may contain dynamic data, so that e.g. the effective grid power consumption of the last week may be embedded into the message, with a suitable formatting.

• dataset references E.g. $MyConsumption refers to the dataset with name MyConsumption

• values E.g. text "Excpected consumption is..." (text can be wrapped in single or double quotes)

• operators E.g. plus operator + (for text concatination, or number addition), or format operator | to format numbers, etc

• functions E.g. average function MAX(...), which finds the maximum value of specified time series

Primary and Secondary Action Text

This field contains the text which should be displayed for the primary and secondary action.

Primary and Secondary Action

This field defines the action category of the primary and secondary action.

A rule can be used for Streaks. Therefore you can turn on the "Streak" feature, and define a streak condition.

The streak condition can be expressed as a mathematical expression producing a boolean value. It works exactly the same as the "Condition" field.

A notification is sent if both the "Condition" and the "Streak Condition" expression is fulfilled. If the "Streak Condition is fulfilled, the streak counter is incremented, otherwise the streak counter is reseted.

Besides datasets, condition and message, the rule has a couple of additional settings which are required.

Name

The name of the rule. The name is for internal use only (i.e. is not customer-facing), has to be unique, and should give a good understanding what the rule is about.

Description

This field may be used to describe the rule in more detail. This is for internal use only (i.e. is not customer-facing).

Match Threshold

This field defines, how often a condition has to be met, before the message is delivered.

If this value is set to "0" (default), then it will always be delivered.

Time between Notifications

When a message has been delivered, we might want to make sure that the same rule does not trigger another message for the same building for some time. This can be defined in this field.

When writing a new rule, you may turn on the rule only for early adopter buildings. This is great to gain in-sight and to collect feedback from early adopters, before turning on this rule for all buildings.

The Rule Simulator is a logical component which allows us to simulate changes or new rules based on existing data of existing buildings.

The simulator runs the current rule configuration against the datasets and the time rang which is selected. The notifications which would have been generated and sent to the message queue and eventually to the user are shown as green letters on top.

When hovering over the green notification icons, the text is shown, which would have been transmitted to the customer and eventually to the end user. Even placeholders are replaced with the actual text so that logic components within the message can be tested, before a new rule or changes to an existing rule go live.

In this example we see already all core elements of the language.

In the following chapters you see many more examples, and all details about what kind of functions and operations exist, and how you can compose the data.

Example of a condition term:

$GridPowerConsumption > 500 AND ($CarChargingMode = 0 OR $CarChargingMode = 4) AND $IsLowTariffHours = 0

Example of a message term:

"Sie beziehen aktuell " + ($GridPowerConsumption / 1000) + "kW vom Netz."

Following syntax base components exist:

Literals

Variables

Example

$GridPowerConsumption

Example of a variable referring to the dataset with name "PowerConsumption"

Values

Example

1.5

Example of a number value

"it is cold"

Example of a text value

30min

Example of a timespan value

now

Example of a time value

Functions

Example

AVG($PowerConsumption)

Example for calculating the average

Operations

Example

1.2 * 42

Example for multiplying two numbers

Brackets

Brackets may be needed to control the resolution order of the terms in the expression. This is very familiar to us of course in mathematical terms:

Example

((4 + 0.5) / (4 - 0.5)) * 2

The Rule Language is a powerful feature which we use in the Recommender Platform to process event streams, test condition rules, and produce relevant and precise recommendation messages.

Expressions in Rule Language look similar to expressions in Excel or other comparable tools or script/program languages.

To give a first impression, have a look at the following examples, which give an idea how the language can be used:

Examples

Example of a boolean expression which compares multiple values and uses AND/OR operators:

$GridPowerConsumption > 500 AND ($CarChargingMode = 0 OR $CarChargingMode = 4) 
AND $IsLowTariffHours = 0

Example of a text expression, which concatenates static text and dynamic data:

"Heat: " + $HeatCelsius::Value + " °C / " + ($HeatCelsius::Value - 273.15) + " K"

Details

In the next step you need to enter the email address which was used during the onboarding for which the password should be reset.

If the entered email is registered on the Recommender Platform you will receive an email with a link to reset your password, after clicking on the "Continue" Button.

When a rule's condition matches, then the notification will not only contain a message but the evaluated expression.

Example

When having a look at some previous examples, it might not be directly obvious, but we are actually not always working just with single values, such as a number. We also had a look at examples which are actually working with a multi-value set, such as when calculating an average.

Scalar

A single value is stored in a Scalar data structure.

Examples

99.5

Example with $PowerConsumption with dataset of name PowerConsumption of type Single Value:

AVG($PowerConsumption)

Vector

A set of values is stored in a Vector data structure.

Examples:

Example with $PowerConsumption with dataset of name PowerConsumption of type Time Series:

SUBSET($PowerConsumption, now-24h)

GroupedScalar

A list of single values, grouped by device or time.

Examples

AVG(GROUP_BY_DEVICE($PowerConsumption)) with Dataset of name PowerConsumption with type Time Series

GroupedVector

A list of list of value sets, grouped by device or time.

Examples

GROUP_BY_DEVICE($PowerConsumption) with Dataset of name PowerConsumption with type Time Series

Every function is of form FCT-NAME(argument1, ...), expects one or more arguments, and returns a value.

Overview

Following functions are provided:

AVG

COUNT

DISTINCT

EVAL

FILTER

GROUP_BY_DEVICE

GROUP_BY_TIME

MAX

MIN

POSITION

REVERSE

SORT

SUBSET

SUM

Boolean

Examples

true

AVG($PowerConsumption) > 1000

Number

A decimal number

Examples

42.0

$Event::Value * 1.5

Time

A time which consists of date and day time.

Besides of event times, we can also use one of following supported literals:

Examples

$Event::Timestamp

now - 24h

Timespan

A timespan.

A timespan literal is a combination of a number and a time unit. Following time units are supported:

Examples

7d

24h

30min

Text

A text element

Everything that begins and ends with a single or double quotation mark is considered a text element. This also includes elements that cannot be assigned to one of the other data types. For example, if $Event was used but no such variable was defined, it would also be considered a text element.

Remark: we recommend to use one of the quoted forms, which makes it crystal clear for the readers that this is a text.

Examples

'foo'

"bar"

foo

Event

An event, which consists of:

Examples:

$Event::DeviceName

Building

Examples:

Building::DeviceTypes

StreakCounter

See Streakfor more details about the Streak feature.

Examples

StreakCounter

Description

Calculates the average on a set of numbers or event values

AVG(Vector<Number/Event>)

AVG(vector: Vector<Number/Event>): Scalar<Number>

Calculate the average as Scalar<any> from the given parameter.

Parameters

Returns

Returns the average as Scalar<Number>

AVG(GroupedScalar<any, Number/Event>)

AVG(group: GroupedScalar<any, Number/Event>): Scalar<Number>

Calculate the average as Scalar<any> from the given parameter.

Parameters

Returns

Returns the average as Scalar<Number>

AVG(GroupedVector<any, Number/Event>)

AVG(group: GroupedVector<any, Number/Event>): GroupedScalar<Number>

Calculate the average as GroupedScalar<any> from the given parameter.

Parameters

Returns

Returns the average as Scalar<Number>

Examples

Retrieve the average of the GridPowerConsumption time series.

AVG($GridPowerConsumption)

Description

Removes duplicate entries. So if applying on ascending ordered data, you would get a descending ordered data set.

DISTINCT(Scalar<any>)

DISTINCT(scalar: Scalar<any>): Scalar<any>

Returns the same scalar (because a scalar cannot have any duplicates).

Parameters

DISTINCT(Vector<any>)

DISTINCT(vector: Vector<any>): Vector<any>

Returns the same elements, but without any duplicates.

Parameters

DISTINCT(GroupedScalar<any, any>)

DISTINCT(group: GroupedScalar<any,any>): GroupedScalar<any,any>

Returns the same GroupedScalar (because a scalar cannot have any duplicates).

Parameters

DISTINCT(GroupedVector<any, any>)

DISTINCT(group: GroupedVector<any,any>): GroupedVector<any,any>

Returns the same GroupedVector, but removes all duplicates in the values of each group.

Parameters

Examples

Removes duplicated entries in the building's device types Vector.

DISTINCT(Building::DeviceTypes)

Description

Filter data on a vector, grouped scalar or grouped vector, by comparing with a threshold. Only data which fulfills that boolean condition is kept.

Filter(Vector<any>, Scalar<Text>, Scalar<any>)

FILTER(vector: Vector<any>, 
       comparisonSymbol: Scalar<Text>, 
       threshold: Scalar<any>): Vector<any>

Filter data in the given vector by comparing with the threshold.

Parameters

Returns

Vector of same type as from the first function parameter, with filtered data.

Examples

Filter events, so that only values > 1000 are kept in the vector.

FILTER($GridPowerConsumption, '>', 1000)

Filter(GroupedScalar<any, any>, Scalar<Text>, Scalar<any>)

FILTER(groupedScalar: GroupedScalar<any, any>, 
       comparisonSymbol: Scalar<Text>, 
       threshold: Scalar<any>): GroupedScalar<any, any>

Filter data in the given grouped scalar by comparing with the threshold. Empty groups are removed from the grouped scalar.

Parameters

Returns

Grouped scalar of same type as from the first function parameter, with filtered data.

Examples

Filter events in the grouped scalar, so that only values > 1000 are kept in the vector.

FILTER(MIN(GROUP_BY_DEVICE($PowerConsumption)), '!=', 0)

Filter(GroupedVector<any, any>, Scalar<Text>, Scalar<any>)

FILTER(groupedVector: GroupedVector<any, any>, 
       comparisonSymbol: Scalar<Text>, 
       threshold: Scalar<any>): GroupedVector<any, any>

Filter data in the given grouped vector by comparing with the threshold. Empty groups are removed from the grouped vector.

Parameters

Returns

Grouped vector of same type as from the first function parameter, with filtered data.

Examples

Filter events, so that only values > 1000 are kept in the grouped vector.

FILTER(GROUP_BY_DEVICE($PowerConsumption), '<=', 200)

Description

Evaluates the buildingSelector for the given datasetName and returns a GroupedVector, where:

• The key is the customerBuildingId.

• The value is a Vector containing all event values from the dataset, grouped by customerBuildingId.

EVAL(Text, AttributeOperator)

POSITION(datasetName: Text, buildingSelector: AttributeOperator): GroupedVector<Text, Vector<Number>>

Parameters

Returns

Returns a GroupedVector where:

• The key is the customerBuildingId.

• The values are vectors containing event values, grouped by household as specified in datasetName.

Description

Converts vector to a grouped vector, by gouping by timespans, so that we have a list of events per timespan. The timespan either is fixed on the latest event, or can be fixed on another time if specified.

GROUP_BY_TIME(Vector<Event>, Scalar<Timespan>)

GROUP_BY_TIME(vector: Vector<Event>, timespan: Scalar<Timespan>): GroupedVector<Time,Event>

Groups the events in the given vector in spans defined by timespan, starting from the latest event.

Parameters

Returns

A GroupedVector of type <Time, Event>.

GROUP_BY_TIME(Vector<Event>, Scalar<Timespan>, Scalar<Time>)

GROUP_BY_TIME(vector: Vector<Event>, timespan: Scalar<Timespan>, time: Scalar<Time>): GroupedVector<Time,Event>

Group the vector in the given timespans starting at the given time.

Parameters

Returns

A GroupedVector of type <Time, Event>.

Examples

Group events in 1h spans starting from latest event

GROUP_BY_TIME($GridPowerConsumption, 1h)

Group events in 1d spans on full day spans (i.e. 00:00-23:59)

GROUP_BY_TIME($Produced, 1d, lastZeroHour)

Description

Converts vector to a grouped vector by grouping by devices. I.e. each device has its own list of events.

GROUP_BY_DEVICE(Vector<Event>)

GROUP_BY_DEVICE(vector: Vector<Event>): GroupedVector<Device,Event>

Groups the events in the given vector by deviceId.

Parameters

Returns

A GroupedVector of type <Device,Event>.

Examples

Group the events in the GridPowerConsumption vector by device id.

GROUP_BY_DEVICE($GridPowerConsumption)

Description

Counts the number of entries on a vector, grouped scalar, or grouped vector.

COUNT(Vector<any>)

Count the entries of the given Vector<any>.

Parameters

Returns

Returns how many elements are within the given vector as Scalar<Number>

COUNT(GroupedScalar<any, any>)

Count the entries of the given GroupedScalar<any, any>.

Parameters

Returns

Returns how many elements are within the given group as Scalar<Number>

COUNT(GroupedVector<any, any>)

Count the entries of the given GroupedVector<any, any>.

Parameters

Returns

Returns how many elements are within the given group as Scalar<Number>

Examples

Count the elements within the GridPowerConsumption time series.

Description

Extracts the maximum on a set of numbers or event values.

MAX(Vector<Number/Event>)

MAX(vector: Vector<Number/Event>): Scalar<Number>

Extract the highest value as Scalar<any> from the given parameter.

Parameters

Returns

Returns the highest value as Scalar<Number>

MAX(GroupedScalar<any, Number/Event>)

MAX(group: GroupedScalar<any, Number/Event>): Scalar<Number>

Extract the highest value as Scalar<any> from the given parameter.

Parameters

Returns

Returns the highest value as Scalar<Number>

MAX(GroupedVector<any, Number/Event>)

MAX(group: GroupedVector<any, Number/Event>): Scalar<Number>

Extract the highest value as Scalar<any> from the given parameter.

Parameters

Returns

Returns the highest value as Scalar<Number>

Examples

Retrieve the maxiumum of the GridPowerConsumption time series.

MAX($GridPowerConsumption)

Description

Returns the Position of an element within a vector as Scalar<Number>. The position of the element within the vector is the index of the element within the vector plus 1.

POSITION(Vector<Number>)

POSITION(vector: Vector<Number>, targetElement: Scalar<Number>): Scalar<Number>

Returns the position of the given targetElement within the given Vector.

Parameters

Returns

Returns the position of the searched element within the vector as Scalar<Number>.

Description

Sorts the entries of the given parameter in ascending order.

SORT(Scalar<any>)

SORT(scalar: Scalar<any>): Scalar<any>

Sort the entries of the given Scalar<any> in ascending order.

Parameters

Returns

Returns the given scalar sorted in ascending order as type Scalar<any>.

SORT(Vector<any>)

SORT(vector: Vector<any>): Vector<any>

Sort the entries of the given Vector<any> in ascending order.

Parameters

Returns

Returns the given vector sorted in ascending order as type Vector<any>.

SORT(GroupedScalar<any, any> [, Scalar<Text>])

SORT(group: GroupedScalar<any, any> [, by: Scalar<Text>]): GroupedScalar<any, any>

Sort the entries of the given GroupedScalar<any, any> in ascending order by values.

Parameters

Returns

Returns the given group sorted by the specified property in ascending order as type GroupedScalar<any, any>.

SORT(GroupedVector<any, any> [, Scalar<Text>])

SORT(group: GroupedVector<any, any> [, by: Scalar<Text>]): GroupedVector<any, any>

Sort the entries of the given GroupedVector<any, any> in ascending order by values.

Parameters

Returns

Returns the given group sorted by the specified property in ascending order as type GroupedScalar<any, any>.

Examples

Sort GridPowerConsumption in ascending order.

SORT($GridPowerConsumption)

Sort GroupedByDevicePowerConsumption in ascending order by event

SORT($GroupedByDevicePowerConsumption, byGroupKey)

Description

Extracts a subset of elements from a given Vector.

SUBSET(Vector<Any>, Scalar<Number>)

Extract the first or last x entries.

Parameters

Returns

Returns a Vector of type any.

SUBSET(Vector<any>, Scalar<Number>, Scalar<Number>)

Parameters

SUBSET(Vector<Event>, Scalar<Time>)

Extract entries from time start until the latest event (left argument is excluding, right is including)

Parameters

Returns

A Vector of type Event.

SUBSET(Vector<Event>, Scalar<Time>, Scalar<Time>)

Extract entries from time start until time end (left argument is excluding, right is including the time border)

Parameters

Returns

A Vector of type Event.

Examples

Extract the last entry from the vector GridPowerConsumption.

Extract all events from zero hour (midnight) until now.

Extract all events 2 days ago until 1 day ago.

Description

Extracts the minimum on a set of numbers or event values

MIN(Vector<Number/Event>)

MIN(vector: Vector<Number/Event>): Scalar<Number>

Extract the lowest value as Scalar<any> from the given parameter.

Parameters

Returns

Returns the lowest value as Scalar<Number>

MIN(GroupedScalar<any, Number/Event>)

MIN(group: GroupedScalar<any, Number/Event>): Scalar<Number>

Extract the lowest value as Scalar<any> from the given parameter.

Parameters

Returns

Returns the lowest value as Scalar<Number>

MIN(GroupedVector<any, Number/Event>)

MIN(group: GroupedVector<any, Number/Event>): Scalar<Number>

Extract the lowest value as Scalar<any> from the given parameter.

Parameters

Returns

Returns the lowest value as Scalar<Number>

Examples

Retrieve the minimum of the GridPowerConsumption time series.

MIN($GridPowerConsumption)

Description

Reverses the entries. So if applying on ascending ordered data, you would get a descending ordered data set.

REVERSE(Scalar<any>)

REVERSE(scalar: Scalar<any>): Scalar<any>

Reverse the order of the given Scalar<any>

Parameters

Returns

Returns the given scalar in reversed order with type Scalar<any>

REVERSE(Vector<any>)

REVERSE(vector: Vector<any>): Vector<any>

Reverse the order of the elements in the given Vector<any>

Parameters

Returns

Returns the given vector in reversed order with type Vector<any>

REVERSE(GroupedScalar<any, any>)

REVERSE(group: GroupedScalar<any,any>): GroupedScalar<any,any>

Reverse the order of the elements in the given GroupedScalar<any, any>

Parameters

Returns

Returns the given group in reversed order with type GroupedScalar<any, any>.

REVERSE(GroupedVector<any, any>)

REVERSE(group: GroupedVector<any,any>): GroupedVector<any,any>

Reverse the order of the elements in the given GroupedVector<any, any>

Parameters

Returns

Returns the given group in reversed order with type GroupedVector<any, any>.

Examples

Reverse the elements in the GridPowerConsumption Vector.

REVERSE($GridPowerConsumption)

Description

Adding or concat two values with each other.

Number|Event + Number|Event

Two arguments of type Scalar<Numbers> added to each other result in a Scalar<Number> which is the sum of both arguments.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Time + Timespan

Adding a Scalar<Time> with a Scalar<Timespan> results in a Scalar<Time> which is a point in time after the Scalar<Time>.

Timespan + Timespan

Adding a Scalar<Timespan> to a Scalar<Time> results in a Scalar<Time> which is far more in the future as stated by the Scalar<Timespan>

Text + any

Examples

Calculating 1 + 2 equals 3

Adding 8 hours to the last full hour results in 13:00 o'clock, when the lastZeroHour was 5:00 o'clock.

Adding 30min to 1h results in 1h30m

Concat Text with the result of a function

Description

Calculates the sum on a set of numbers or event values

SUM(Vector<Number/Event>)

SUM(vector: Vector<Number/Event>): Scalar<Number>

Calculate the sum as Scalar<any> from the given parameter.

Parameters

Returns

Returns the sum as Scalar<Number>

SUM(GroupedScalar<any, Number/Event>)

SUM(group: GroupedScalar<any, Number/Event>): Scalar<Number>

Calculate the sum as Scalar<any> from the given parameter.

Parameters

Returns

Returns the sum as Scalar<Number>

SUM(GroupedVector<any, Number/Event>)

SUM(group: GroupedVector<any, Number/Event>): GroupedScalar<Number>

Calculate the sum as Scalar<any> from the given parameter.

Parameters

Returns

Returns the sum as Scalar<Number>

Examples

Retrieve the sum of the GridPowerConsumption time series.

SUM($GridPowerConsumption)

Every operation is of form: OP argument1 , or argument1 OP argument2 and returns a value.

Overview

Following operations are provided:

Plus

Minus

Multiply

Divide

Negate

Less Than

Less or Equal

Equal

Not Equal

Greater or Equal

Greater

AND

OR

NOT

Format

Attribute Accessor

Description

Subtracting two values from each other.

Number/Event - Number/Event

Two arguments of type Scalar<Numbers> subtracted from each other result in a Scalar<Number> which is the result of the division.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Time - Time

Subtracting a Scalar<Time> from another Scalar<Time> results in a Scalar<Time> which is a point in time before the first operator.

Time -Timespan

Subtracting a Scalar<Timespan> from a Scalar<Time> results in a Scalar<Time> which is a point in time before the Scalar<Time>.

Timespan - Timespan

Subtracting a Scalar<Timespan> from a Scalar<Timespan> results in a Scalar<Time> which is further in the past as stated by the Scalar<Timespan>

Examples

Calculating 1 - 2 equals -1

Subtracting 8 hours to the last full hour results in 00:00 o'clock, when the lastZeroHour was 8:00 o'clock.

Subtracting 30min from 1h results in 30m.

Description

Multiply two values with each other.

Number|Event * Number|Event

Scalar<Number|Event> * Scalar<Number|Event> : Scalar<Number>
Scalar<Number|Event> * GroupedScalar<Number|Event> : GroupedScalar<Number>
GroupedScalar<Number|Event> * Scalar<Number|Event> : GroupedScalar<Number>
GroupedScalar<Number|Event> * GroupedScalar<Number|Event> : GroupedScalar<Number>

Two arguments of type Scalar<Number> multiplied with each other result in a Scalar<Number> which is the result of the multiplication.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Calculating 1.5 multiplied by the SUM of the PowerConsumption

1.5 * SUM($PowerConsumption)

Description

Checks whether first argument is less or equal than the second argument.

any <= any

Scalar<any> <= Scalar<any> : Scalar<Boolean>
Scalar<any> <= GroupedScalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> <= Scalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> <= GroupedScalar<any> : GroupedScalar<Boolean>

Comparing if a Scalar<any> is less or equal than another Scalar<any>. Returns a Scalar<Boolean> either true if the first operator is less or equal than the second otherwise false.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Check if the PowerConsumption is less or equals than the PowerProduction

$PowerConsumption <= $PowerProduction

Description

Divide two values by each other.

Number|Event / Number|Event

Scalar<Number|Event> / Scalar<Number|Event> : Scalar<Number>
Scalar<Number|Event> / GroupedScalar<Number|Event> : GroupedScalar<Number>
GroupedScalar<Number|Event> / Scalar<Number|Event> : GroupedScalar<Number>
GroupedScalar<Number|Event> / GroupedScalar<Number|Event> : GroupedScalar<Number>

Two arguments of type Scalar<Number> divded by each other result in a Scalar<Number> which is the result of the division.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Calculating 3 divided by 2 results in 1.5

3 / 2

Description

Checks whether first argument is less than the second argument.

any < any

Scalar<any> < Scalar<any> : Scalar<Boolean>
Scalar<any> < GroupedScalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> < Scalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> < GroupedScalar<any> : GroupedScalar<Boolean>

Comparing if a Scalar<any> is less than another Scalar<any>. Returns a Scalar<Boolean> either true oif the first operator is less than the second otherwise false.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Check if the PowerConsumption is less than the PowerProduction

$PowerConsumption < $PowerProduction

Description

Negate a Scalar<Event>

-Number|Event

-Scalar<Number|Event> : Scalar<Number>
-Vector<Number|Event> : Vector<Number>
-GroupedScalar<Number|Event> : GroupedScalar<Number>
-GroupedVector<Number|Event> : GroupedVector<Number>

An argument of type Scalar<Event> prefixed by a - negates the value of the Event.

If it is a Vector, GroupedScalar or GroupedVector, then the operation is performed on each value, and results in another Vector, GroupedScalar or GroupedVector.

Examples

Calculating 3 divided by 2 results in 1.5

-3

Description

Checks whether first argument is equal to the second argument.

any = any

Scalar<any> = Scalar<any> : Scalar<Boolean>
Scalar<any> = GroupedScalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> = Scalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> = GroupedScalar<any> : GroupedScalar<Boolean>

Comparing if a Scalar<any> is equal to another Scalar<any>. Returns a Scalar<Boolean> either true if the first operator equals to the second otherwise false.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Check if the PowerConsumption is equals to the PowerProduction

$ChargeMode1 = $ChargeMode2

Description

Checks whether first argument is greater than the second argument.

any > any

Scalar<any> > Scalar<any> : Scalar<Boolean>
Scalar<any> > GroupedScalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> > Scalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> > GroupedScalar<any> : GroupedScalar<Boolean>

Comparing if a Scalar<any> is greater than another Scalar<any>. Returns a Scalar<Boolean> either true if the first operator is greater as the second otherwise false.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Check if the PowerConsumption is greater than the PowerProduction

$PowerConsumption > $PowerProduction

Description

Checks whether first argument and the second argument are true.

Boolean AND Boolean

Scalar<Boolean> AND Scalar<Boolean> : Scalar<Boolean>
Scalar<Boolean> AND GroupedScalar<Boolean> : GroupedScalar<Boolean>
GroupedScalar<Boolean> AND Scalar<Boolean> : GroupedScalar<Boolean>
GroupedScalar<Boolean> AND GroupedScalar<Boolean> : GroupedScalar<Boolean>

Comparing if a Scalar<Boolean> and Scalar<Boolean> are both true. Returns a Scalar<Boolean> with true when both terms result in true otherwise false.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Check if the PowerConsumption is greater 0 AND the PowerProduction is > 0. Only returns true if both are valid.

$PowerConsumption > 0 AND $PowerProduction > 0

Description

Checks whether first argument or the second argument is true.

Boolean OR Boolean

Scalar<Boolean> OR Scalar<Boolean> : Scalar<Boolean>
Scalar<Boolean> OR GroupedScalar<Boolean> : GroupedScalar<Boolean>
GroupedScalar<Boolean> OR Scalar<Boolean> : GroupedScalar<Boolean>
GroupedScalar<Boolean> OR GroupedScalar<Boolean> : GroupedScalar<Boolean>

Comparing if one of Scalar<Boolean> OR Scalar<Boolean> is true. Returns a Scalar<Boolean> with true when one of the terms result in true. Returns false when both terms are false.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Check if the PowerConsumption is greater 0 OR the PowerProduction is > 0. Only returns false if both are false.

$Consumption > 0 OR $Production > 0

Description

Checks whether first argument is not equal to the second argument.

any != any

Scalar<any> != Scalar<any> : Scalar<Boolean>
Scalar<any> != GroupedScalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> != Scalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> != GroupedScalar<any> : GroupedScalar<Boolean>

Comparing if a Scalar<any> is not equal to another Scalar<any>. Returns a Scalar<Boolean> either true if the first operator equals to the second otherwise false.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Check if the PowerConsumption is equals to the PowerProduction

$ChargeMode1 != $ChargeMode2

Description

Checks whether argument is not true.

NOT Boolean

NOT Scalar<Boolean> : Scalar<Boolean>
NOT Vector<Boolean> : Vector<Boolean>
NOT GroupedScalar<Boolean> : GroupedScalar<Boolean>
NOT GroupedVector<Boolean> : GroupedVector<Boolean>

Negate the Scalar<Boolean> after the NOT keyword. This means a Scalar<Boolean> with value true will return false and vise versa.

If it is a Vector, GroupedScalar or GroupedVector, then the operation is performed on each value, and results in another Vector, GroupedScalar or GroupedVector.

Examples

Check if the PowerConsumption is NOT greater than the PowerProduction.

NOT ($PowerConsumption > $PowerProduction)

Description

Formats numbers, time and timestamp.

Format on Vector will result in a comma-separated list of formatted values. E.g.: Device Link Car, Fronius Symo

Format on GroupedScalar will result in a comma-separated list of group identifier, double-quote and formatted value; the group identifier is rendered as device name, if grouped by device, else the time span index is taken. E.g.: 'Device Link Car': 1035, 'Fronius Symo': 8012

Format on GroupedVector will result in a slash-separated list of group identifier, double-quote and comma-separated formatted values; the group identifier is rendered as device name, if grouped by device, else the time span index is taken. E.g.: 'Device Link Car': 1035, 2012, 3097 / 'Fronius Symo': 8012

Signatures

Number/Event | Text

Time | Text

Timespan | Text

Timespan | '(ADAPTIVE|SECONDS|MINUTES|HOURS|DAYS):(WORD|SYMBOL)'

Format pattern semantic

Examples

Format the Result of the AVG($Consumption) function (which is a Scalar<Number) in format '#,##0'.

Format the Timestamp of the $Event (which is Scalar<Event>) as hours and minutes.

Fromat the resulting Timestamp as Hours suffixed with the word Hours.

Description

Checks whether first argument is greater or equal than the second argument.

any >= any

Scalar<any> >= Scalar<any> : Scalar<Boolean>
Scalar<any> >= GroupedScalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> >= Scalar<any> : GroupedScalar<Boolean>
GroupedScalar<any> >= GroupedScalar<any> : GroupedScalar<Boolean>

Comparing if a Scalar<any> is greater or equal than another Scalar<any>. Returns a Scalar<Boolean> either true if the first operator is greater or equals to the second otherwise false.

If one argument is a Scalar, and the other one a GroupedScalar, then the operation is performed by taking the Scalar value and the value of each group value, which results another GroupedScalar (it has same group size, as the one from the input argument).

If both arguments are GroupedScalar, then the operation is performed by taking values with same group key, which results in another Grouped Scalar (the group size is equal or smaller than the ones of the input arguments).

Examples

Check if the PowerConsumption is greater or equal than the PowerProduction

$PowerConsumption >= $PowerProduction

The Events Overview page is a powerful tool for users who need to keep track of recent events, monitor changes in real-time, and analyze data over a certain period. The page's features, such as search functionality, column selection, time frame adjustment, and pagination, make it easy for users to customize the view according to their needs.

The page provides a comprehensive view of the latest events received and allows users to quickly and efficiently navigate through the information.

The table on the Events Overview page displays information about the latest events received. The table includes columns such as the event name, date and time, location, and other relevant information. Each row in the table represents a single event, and users can view multiple events at once by adjusting the pagination.

Filter

The filter functionality on the Events Overview page allows users to search for specific events by filtering by building, event type, event source, device name and date range.

Pagination

The table has pagination enabled, which means that users can navigate through the table by clicking the page numbers or using the previous and next buttons. Users can also select how many elements per page they want to display. This feature can be accessed by clicking the "Page Size" button located above the table. A drop-down menu will appear, and users can select the number of elements they want to be displayed per page.

SUBSETS

Subsets are often used to select a certain time period from a timeseries.

For example, we want to send a message if the minimum of the newest two entries of a time series of 5 days in Grid Power Consumption is greater than the minimum of the remaining time series.

MIN(SUBSET($GridPowerConsumption5d, -2))

Alternatively, we can also take the newest entries in a certain time period. Here we want to get the minimum of all registered Grid Power Consumption events from the last 30 minutes until now.

MIN(SUBSET($GridPowerConsumption5d, now-31min, now)) 

Let us continue with the first version. We now want to compare this minimum value with the minimum of the rest of the time series.

The beginning of this snippet is therefore the first value of the vector at position 0 up to and including the third most recent event. As before, we can get the minimum by applying a MIN function to the resulting subset.

MIN(SUBSET($GridPowerConsumption5d, 0, -3))

MIN(SUBSET($GridPowerConsumption5d, -2)) > MIN(SUBSET($GridPowerConsumption5d, 0, -3))

The user profile can be access by clicking on the avatar in the right corner of the header and then clicking on your username. On the user profile you can start the following processes:

• Change Username

• Change Password

This page provides an overview of all buildings within the system, allowing you to view and manage their details. Below is a detailed guide to help you navigate and utilize the features available on this page.

Filters and Search

At the top of the page, you will find several filters and a search bar to help you find specific buildings quickly.

• ID: Search or filter buildings by their unique Building ID.

• Location: Filter buildings based on their location.

• Status: Filter buildings by their status (e.g., Active, Inactive).

• Event Types: Filter buildings by the types of events associated with them.

• Event Sources: Filter buildings based on the sources of their events.

Building List

Below the filter and search bar, you will see a list of buildings with the following columns:

• Building ID: The unique identifier for each building.

• Location: The location of the building, including city and country code.

• Status: The current status of the building (e.g., Active).

Actions

For each building listed, there are action buttons available to perform various tasks:

• View (Circle Icon): Click to view detailed information about the building.

• Edit (Pencil Icon): Click to edit the building’s information.

• Early Adopter (Hat Icon): Indicates if the building is in the list of early adopters.

• Star (Star Icon): Click to mark the building as a favorite for quick access.

Pagination

• Items per Page: Select the number of items to display per page (e.g., 10, 25, 50).

• Page Navigation: Use the arrows to navigate between pages if there are more buildings than can be displayed on one page.

Description

Access sub-data of the argument.

Accessor on Scalar<Event>

Scalar<Event>::Value             : Scalar<Number>
Scalar<Event>::DeviceId          : Scalar<Text>
Scalar<Event>::DeviceName        : Scalar<Text>
Scalar<Event>::Timestamp         : Scalar<Time>
Scalar<Event>::ForecastTimestamp : Scalar<Time>

Returns

Returns the event value, device id, device name, timestamp or forecast timestamp.

Remark: if there is no forecast timestamp, "0" is returned

Examples

Get the value of the event stored in the PowerConsumption Variable.

$PowerConsumption::Value
$PowerConsumption::Timestamp

Accessor on Vector<any>

Vector<any>::First : Scalar<any>
Vector<any>::Last  : Scalar<any>

Returns

Returns the first or last element of the Vector as Scalar<any>

Examples

Get the first Event from the $PowerGeneration vector.

$PowerConsumption::First

Accessor on Vector<Event>

Vector<Event>::Value             : Vector<Number>
Vector<Event>::DeviceId          : Vector<Text>
Vector<Event>::DeviceName        : Vector<Text>
Vector<Event>::Timestamp         : Vector<Time>
Vector<Event>::ForecastTimestamp : Vector<Time>

Returns

Returns the set of event values, device ids, device names, timestamps or forecast timestamps.

Remark: if there is no forecast timestamp, "0" is returned

Examples

Get the values of all events in the vector $PowerConsumption as new Vector<Number>

$PowerConsumption::Value

Accessor on GroupedScalar<any, Event>

GroupedScalar<any, Event>::Value             : Vector<Number>
GroupedScalar<any, Event>::DeviceId          : Vector<Text>
GroupedScalar<any, Event>::DeviceName        : Vector<Text>
GroupedScalar<any, Event>::Timestamp         : Vector<Time>
GroupedScalar<any, Event>::ForecastTimestamp : Vector<Time>

Returns

Returns the set of event values, device ids, device names, timestamps or forecast timestamps, grouped by device or time spans.

Examples

Get the values of all events in the group $PowerConsumption as new Vector<Number>

GROUP_BY_DEVICE($PowerConsumption)::Value

Accessor on GroupedScalar<Device, any>

GroupedScalar<Device, any>::GroupKeyDeviceId   : Vector<Text>
GroupedScalar<Device, any>::GroupKeyDeviceName : Vector<Text>

Returns

Returns the device id or name of the device which is part of the GroupedScalar key.

Examples

Get all device names from all the devices in the $PowerConsumption group.

GROUP_BY_DEVICE($PowerConsumption)::GroupKeyDeviceName

Accessor on GroupedScalar<any, any>

GroupedScalar<any, any>::GroupKeyValue : Vector<any>

Returns

Returns the value of the group as new Vector<any>.

Examples

Get all Values from the $PowerConsumption group.

GROUP_BY_DEVICE($PowerConsumption)::GroupValue

Accessor on GroupedVector<any, any>

GroupedVector<any, any>::First : GroupedScalar<any, any>
GroupedVector<any, any>::Last  : GroupedScalar<any, any>

Returns

Returns a GroupedScalar, which holds the first or last value of each group.

Examples

Get all Values from the $PowerConsumption group.

GROUP_BY_DEVICE($PowerConsumption)::First

Accessor on GroupedVector<any, Event>

GroupedVector<any, Event>::Value             : GroupedVector<Number>
GroupedVector<any, Event>::DeviceId          : GroupedVector<Text>
GroupedVector<any, Event>::DeviceName        : GroupedVector<Text>
GroupedVector<any, Event>::Timestamp         : GroupedVector<Time>
GroupedVector<any, Event>::ForecastTimestamp : GroupedVector<Time>

Returns

Returns the values, device ids, device names, timestamps or forecast timestamps of all events in the group and return as new GroupedVector<Number>.

Examples

Get the values of all events in the group $PowerConsumption as new Vector<Number>

GROUP_BY_DEVICE($PowerConsumption)::Value

Accessor on GroupedVector<Device, any>

GroupedVector<Device, any>::GroupKeyDeviceId   : Vector<Text>
GroupedVector<Device, any>::GroupKeyDeviceName : Vector<Text>

Returns

Returns the device ids or device names of all devices which are the groups key, and return as new Vector<Text>.

Examples

Get all device names from all the devices in the $PowerConsumption group.

GROUP_BY_DEVICE($PowerConsumption)::GroupKeyDeviceName

Accessor on Building

Building::Id
Building::RegistrationTimestamp
Building::ActivationTimestamp
Building::DeviceTypes
Building::EconomicalMotivationScore
Building::EcologicalMotivationScore
Building::SelfSufficiencyMotivationScore
Building::MultiPersonScore
Building::CommercialBuildingScore
Building::IsSelfSufficiencyMotivated
Building::IsEcologicalMotivated
Building::IsSelfSufficiencyMotivated
Building::IsMultiPerson
Building::IsSinglePerson
Building::IsResidential
Building::IsCommercial
Building::IsInSameCountry
Building::IsInSameConsumptionCategory
Building::All

Returns

Selects the event related building, and returns the specified building data, such as the building id, the registration date when the building was registered, the activation date when the building was activated on MOOST side, or the types of all devices.

See Building

Examples

Get all device types from the event related device.

Building::DeviceTypes

The Billing Portal is a self-service portal where you can manage your subscription billing, update payment information, view past invoices, and perform other billing-related tasks.

By selecting the navigation point "Billing" in the navigation, you will be redirected to the Billing Portal.

By clicking on the link "Edit information" you can update the billing address for your company.

The Household Profile page provides detailed information about a specific building or household within the recommender platform. This page is structured to present key metrics and data points related to the building's characteristics, user motivations, and interaction history. Below is a detailed description of each section on this page.

Building Information

Status

Indicates the current state of the building profile. Either the building is "Active" or a timestamp is shown for when the building was set Inactive.

Early Adopter

The Badge Early Adopter tells us tha this building is part of the early adopter group which can be activated for rules to be tested before they are set accessible for all buildings.

Location Details

• PLZ: The postal code associated with the building (e.g., 8000).

• City: The city where the building is located (e.g., Zürich).

• Country: The country code, such as CH for Switzerland.

Motivations

This section includes a radar chart that visualizes the building occupants' motivations across three axes:

• Ecological: Represents interest in sustainability and environmental impact.

• Economical: Reflects the importance placed on cost-saving measures.

• Self-Sufficiency: Indicates the desire for independence in resources, such as energy.

The position of the plot on the chart indicates the building's relative emphasis on these three factors.

Behind the motivation scores are complex algorithms that determinate the motivation of a household through multiple factors like their Power Consumption, their Device Settings, their Interaction with the Recommendations etc. For a deep-dive into the algorithms behind the platform feel free to reach-out to hello@moost.io

Household Type

• Household Gauge: A semi-circular gauge that displays the likelihood of the building being a single-person or multi-person household.

  • Value: The gauge shows a numerical value (e.g., 0.692) that leans towards a multi-person household.

Interactions

• Per Rule: A pie chart that breaks down user interactions based on different rule sets or categories. Each segment represents a specific rule or interaction type, labeled with its identifier and percentage.

• Delivery Status: This section contains a pie chart that details the status of interactions or deliveries:

  • Delivered: The percentage of interactions successfully delivered (e.g., 43.75%).

  • Dropped (Time Between...): Represents interactions dropped due to timing issues (e.g., 53.12%).

  • Dropped (Match Counter Not Reached): Indicates interactions that were dropped for not meeting specified criteria (e.g., 3.13%).

• Interaction Types: Another pie chart that categorizes user engagement:

  • Viewed: The proportion of interactions where content was viewed (e.g., 87.5%).

  • Open App: The percentage of interactions where users opened an application (e.g., 12.5%).

Usage

The Building Profile page is intended to provide a quick and comprehensive overview of the building's profile, including motivations, household type, and interaction patterns. This information is crucial for tailoring recommendations, understanding user behavior, and optimizing engagement strategies.

Add Payment Method

By Clicking on the "Add Payment Method" or "Change Payment Method" link you can add a new payment method to your account. Currently supported payment methods are:

• VISA

• Mastercard

• AMEX

• UnionPay

The Weather Forecast service provides accurate and up-to-date weather information for a given location. It offers various meteorological data points, such as temperature, humidity, wind speed, precipitation, and more.

With the Weather Forecast service we can leverage weather conditions to enhance the quality of recommendations.

Types

The Weather Forecast generates events with the following types. This information is available for all customers of the recommender platform which provide a ZIP for their buildings.

At the bottom of the billing portal you see the last invoices which have been processed. After clicking on the link icon next to an invoice, you will be redirected to the invoice screen on which you can download a copy of the invoice or a receipt for the charge.

If you want to terminate your subscription you can do this be clicking on the "terminate" button in the MOOST Billing Platform.

The Recommender Platform offers multiple context services that provide valuable information for making recommendations. The available context services include Weather Forecast, Solar Production Forecast and Power Consumption Forecast.

You find information about each context service and how to utilize them within the recommendation platform on the next pages.

The Solar Production Forecast service predicts the amount of solar energy that can be generated from a solar power system at a specific location. It takes into account factors like solar radiation, cloud cover, and other environmental conditions to provide accurate solar production forecasts.

By incorporating the Solar Production Forecast service into the recommendation platform, we can optimize recommendations based on expected solar energy availability.

Types

The Solar Production Forecast generates events with the following types. This information is available for all customers of the recommender platform which provide a ZIP for their buildings.

The Power Consumption Forecast is a context service that applies machine learning algorithms to historical power consumption data to forecast the power consumption for a building. The Power Consumption Forecast can be used within rules as a normal event type.

Types

The Energy Consumption Forecast generates events with the following types.

NOTE: The Power Consumption Forecast is only available in the Premium Subscription

The Power Generation Forecast is a context service that applies machine learning algorithms to historical power generation data to forecast the power generation for a building. The Power Generation Forecast can be used within rules as a normal event type.

Types

The Power Generation Forecast generates events with the following types.

NOTE: The Power Generation Forecast is only available in the Premium Subscription

This guide helps you as a customer with the necessary steps on how to integrate your cloud offering with the MOOST Recommender Platform. The integration consists of four sections. Each section covers a part of the information flow that is needed to integrate your cloud platform with the MOOST Recommender Platform.

Integration Steps

The cloud-to-cloud integration consists of following steps:

1. Platform On-boarding

2. Configure Notification Settings

3. MOOST API Integration

As a first step ask MOOST to on-board you onto the MOOST Recommender Platform.

What we need from you

• Organisation name - optionally you may provide an organisation logo URL.

• Email addresses of members of your organizations which need access to the admin frontend. Of course, we can add more members to the group at a later stage.

• Email address and mobile number of a member which is responsible for the API integration. We will send parts of the API secrets via these two channels. We use two channels due to security reasons.

• Email address of billing administrator.

• Set of desired Notification Languages. By default we activate languages English, German and French.

What we do for you

• We create a customer on the MOOST Recommender Platform. This key element is needed for many processes, such as e.g. registering buildings, and then feed events.

• We set up logins to the MOOST admin frontend for members of your organization. The frontend enables you to get in-sights about the MOOST Recommender Platform, so that you are able to see the available rules and buildings, processed events or delivered notifications.

• We set up API secrets and send them to the person on your side which will be responsible for the API integration. The API secrets will enable you to access our API's, so that you may e.g. read delivered notifications.

• We set up the rules by selecting the relevant ones from our use-case library.

• We set up the pricing for the monthly billing.

• We set up the Training Jobs that are needed to periodically train our Machine Learning Models with our Events to get more precise results over time.

Each rule of the Recommender Platform may eventually emit notifications.

On the MOOST Help Center you can choose the type of issue you are facing and create a ticket which will be handled by the MOOST Support regarding the SLA's for the Recommender Platform.

Introduction

The MOOST Recommender Platform delivers Notifications to Customer’s specified REST Endpoint. The Endpoint that should be used can be configured as a per Customer, per End-user or a combination of both.

REST Endpoint

To send notifications to the REST Endpoint, the Endpoint has to be exposed on a public domain that can be accessed via Internet. Any REST Endpoint that is accessible via Internet should be protected via authentication. The MOOST Recommender Platform is able to authenticate against a Customer’s REST Endpoint via various authentication methods.

Authentication

The Recommender Platform is able to authenticate against a Customer REST Endpoint via various authentication methods as listed below.

Username / Password

The Recommender Platform can be configured to authenticate against a customer’s REST endpoint with username and password (i.e. “Basic” authentication).

API-Token

The Recommender Platform can be configured to use an API-Token to authenticate against a customer REST Endpoint.

Bearer-Token

The Recommender Platform can be configured to use a Bearer Token to authenticate against a Customer REST Endpoint.

API Throttling

If the Customer’s REST Endpoint is protected against DDOS attacks with some kind of request throttling the Customer should inform MOOST during the integration phase about the limitations that are in place. MOOST will configure the Recommender Platform accordingly.

If the limits are exceeded, the MOOST Recommender Platform will not able to send all notifications back to the Customer’s REST Endpoint. Cusermers are encouraged to ensure that the chosen limitation is in line with the expected notifications per time unit.

Notification Schema

An example of a notification object which will be sent to the Customer’s REST Endpoint is shown below. The notification object will be posted to the specified Customer’s REST Endpoint as a JSON message in the body.

Format

Old Format (Deprecated)

Actions

A notification includes two actions that should be presented to the End-user. The actions consists out of a text field which contains the text that should be presented to the End-user in the different languages, and a action qualifier field, which describes the type of action (and which should be returned to the MOOST API when the action is selected by the end-user).

The Recommender Platform has the following action qualifiers:

• DISMISS

• OPENAPP

• STOPDELIVERY

• OPENWEB

DISMISS

The DISMISS actionQualifier states that the push notification should be dismissed when this action is selected be the end-user.

OPENAPP

The OPENAPP action states that when this action is selected by the the end-user, then the app should be opened. The optional parameter attribute may contain a language specific value, such as e.g. an URL or a use case name.

STOPDELIVERY

The STOPDELIVERY action states that when this action is selected the push-notification should be dismissed and the actionQualifier should be returned to the MOOST API implicating that no more notifications of this type should be sent to the End-user.

OPENWEB

The OPENWEB action states that when this action is selected by the the end-user, then a browser should be opened. The optional parameter attribute may contain a language specific value, typically an URL.

Command

Optionally, you may specify a command when defining a notification in a rule. The command field may contain an instruction for a machine-to-machine interface so that some changes could be triggered.

As this is customer specific, this field is initially empty, but can be defined by the customer to his preferred format.

In case your organization is implementing the MOOST API integration on your own, you are in charge to synchronize necessary building and device data, and then feed events into MOOST Recommender Platform.

API Usage

MOOST API is OAuth2 based. Therefore first you have to obtain an access token with your client id and client secret. Then you are able to call the MOOST API's, by using the provided access token.

The access token can be re-used for multiple calls, but eventually expires after some hours.

API Documentation

Set up Data Feeds

In the next steps we will guide you through the needed steps to be able to setup buildings, send events and send interactions with notifications to the MOOST recommender platform

iOS does differentiate between the action which happens when pressing the notification and the quick actions which are presented to the user when long pressing a notification.

Firebase Cloud Messaging

Handling FCM notifications

func userNotificationCenter(_ center: UNUserNotificationCenter,
       didReceive response: UNNotificationResponse,
       withCompletionHandler completionHandler: 
         @escaping () -> Void) {
       
   // Get the additional information from the original notification.
   let userInfo = response.notification.request.content.actions
   let url = userInfo["parameter"]["en"] as! String
        
   // Perform the task associated with the action.
   switch response.actionIdentifier {
    case "OPENAPP":
        sharedAppManager.openApp()
        break
    case "STOPDELIVERY":
        sharedAppManager.sendStopDelivery()
        break
    case "OPENWEB":
        sharedAppManager.openWeb(url)
        break
    default:
        sharedAppManager.openApp(url)
        break
   }
    
   // Always call the completion handler when done.    
   completionHandler()
}

To perform operations with the MOOST API, it is essential to obtain a new access token from the Auth API. This token is required for authenticating and authorizing your requests. The steps to lease a new access token are as follows:

1. Request a New Token: Send a request to the https://api.moost.io/auth/token/v1 endpoint with the provide client id and client secret to obtain a new access token. This endpoint will issue a token that is valid for 86400 seconds (24 hours).

2. Use the Token: Include the access token in the Authorization header of your API requests to authenticate them. This token grants access to the API's functionalities as documented.

3. Token Expiration: Be aware that the access token will expire after 86400 seconds. It is crucial to monitor the token's validity and request a new one before it expires to maintain uninterrupted access to the API.

4. Refresh the Token: Once the token expires, repeat the process by sending a request to the /auth/token/v1 endpoint to lease a new access token. Ensure this is done promptly to continue using the API services without any interruptions.

By following these steps, you can efficiently manage the access tokens required for seamless interaction with the API.

Auth Token API

Example

API Call with CURL

# use your own id and secret:
CLIENT_ID="6c............................Uo"
CLIENT_SECRET="Df............................................................Ye"

curl -X GET "https://api.moost.io/auth/token/v1?clientId=$CLIENT_ID&clientSecret=$CLIENT_SECRET"

Sample response

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik5EVkNSa0l6T1RBek16RkRRakV3TURBeU1EYzBSRE01TTBJNE5qRTVSamxGUWpKQ1FqQTNNZyJ9.eyJjdXN0b21lcklkIjoiNjU2NzMwYmUyYmM5NzE5ZTZlNWVkNTFkIiwiaXNzIjoiaHR0cHM6Ly9hdXRoLm1vb3N0LmlvLyIsInN1YiI6ImtJaG5FdmJHVXBPU2VGeDYwdFZETkg1QzhFYWJoMzZpQGNsaWVudHMiLCJhdWQiOiJodHRwczovL21vb3N0LWFwaSIsImlhdCI6MTcyMDEwMDE5MywiZXhwIjoxNzIwMTg2NTkzLCJzY29wZSI6InJlYWQ6YnVpbGRpbmdzIHdyaXRlOmJ1aWxkaW5ncyByZWFkOmV2ZW50cyB3cml0ZTpldmVudHMgcmVhZDpwdXNobm90aWZpY2F0aW9ucyB3cml0ZTpwdXNobm90aWZpY2F0aW9ucyIsImd0eSI6ImNsaWVudC1jcmVkZW50aWFscyIsImF6cCI6ImtJaG5FdmJHVXBPU2VGeDYwdFZETkg1QzhFYWJoMzZpIiwicGVybWlzc2lvbnMiOlsicmVhZDpidWlsZGluZ3MiLCJ3cml0ZTpidWlsZGluZ3MiLCJyZWFkOmV2ZW50cyIsIndyaXRlOmV2ZW50cyIsInJlYWQ6cHVzaG5vdGlmaWNhdGlvbnMiLCJ3cml0ZTpwdXNobm90aWZpY2F0aW9ucyJdfQ.Yp9mZq9n-enmhRB1sm0mUppIECWlHE94qu6pgtyBLPvhl6UMDL-UWNN26eZjhugm003icEQjgXBdVtzljXmXnr2y29xfgflztvdHWmHMO_6Pdx-f_XjcGJjBtF1WgHLiCemr-GXY5wLLXQgFqnTNU6IyUk9fcV7rYPJWP_CwLMawSeB_FcfGATtkXmijHMsX2nZVKAq-_R9uLMgieOBeu9VPhFx6lGGaaUbtXJ3t-P3lvNZJBuz4c1YAiVtcc6s66wbYx2-7Uzd2rOwAPlo-Y2pjk8qmE0CgRlWRf8lg9bk58qIYWHF_Zlef1CUP7A0y7KIN9ymtAp1x0184iiD2dQ",
  "expires_in": 86400,
  "scope": "read:buildings write:buildings read:events write:events read:pushnotifications write:pushnotifications",
  "token_type": "Bearer"
}

You may store the access token in another variable, if you plan to call some MOOST API from the shell:

# use your received access token
ACCESS_TOKEN="eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik5EVkNSa0l6T1RBek16RkRRakV3TURBeU1EYzBSRE01TTBJNE5qRTVSamxGUWpKQ1FqQTNNZyJ9.eyJjdXN0b21lcklkIjoiNjU2NzMwYmUyYmM5NzE5ZTZlNWVkNTFkIiwiaXNzIjoiaHR0cHM6Ly9hdXRoLm1vb3N0LmlvLyIsInN1YiI6ImtJaG5FdmJHVXBPU2VGeDYwdFZETkg1QzhFYWJoMzZpQGNsaWVudHMiLCJhdWQiOiJodHRwczovL21vb3N0LWFwaSIsImlhdCI6MTcyMDEwMDE5MywiZXhwIjoxNzIwMTg2NTkzLCJzY29wZSI6InJlYWQ6YnVpbGRpbmdzIHdyaXRlOmJ1aWxkaW5ncyByZWFkOmV2ZW50cyB3cml0ZTpldmVudHMgcmVhZDpwdXNobm90aWZpY2F0aW9ucyB3cml0ZTpwdXNobm90aWZpY2F0aW9ucyIsImd0eSI6ImNsaWVudC1jcmVkZW50aWFscyIsImF6cCI6ImtJaG5FdmJHVXBPU2VGeDYwdFZETkg1QzhFYWJoMzZpIiwicGVybWlzc2lvbnMiOlsicmVhZDpidWlsZGluZ3MiLCJ3cml0ZTpidWlsZGluZ3MiLCJyZWFkOmV2ZW50cyIsIndyaXRlOmV2ZW50cyIsInJlYWQ6cHVzaG5vdGlmaWNhdGlvbnMiLCJ3cml0ZTpwdXNobm90aWZpY2F0aW9ucyJdfQ.Yp9mZq9n-enmhRB1sm0mUppIECWlHE94qu6pgtyBLPvhl6UMDL-UWNN26eZjhugm003icEQjgXBdVtzljXmXnr2y29xfgflztvdHWmHMO_6Pdx-f_XjcGJjBtF1WgHLiCemr-GXY5wLLXQgFqnTNU6IyUk9fcV7rYPJWP_CwLMawSeB_FcfGATtkXmijHMsX2nZVKAq-_R9uLMgieOBeu9VPhFx6lGGaaUbtXJ3t-P3lvNZJBuz4c1YAiVtcc6s66wbYx2-7Uzd2rOwAPlo-Y2pjk8qmE0CgRlWRf8lg9bk58qIYWHF_Zlef1CUP7A0y7KIN9ymtAp1x0184iiD2dQ"

Forward Event Data of Devices

Make sure that event data, which shall be taken into consideration by MOOST Recommender Platform, are forwarded to MOOST via MOOST API.

See Event Types to get an overview which Events should be forwarded for which Devices in which periodicity.

Event Data Structure

Following example depicts an event structure of a energy consumption event.

{
  "id": "6703cfa2fa7bfc35eb1f74d0",
  "customerId": "656730be2bc9719e6e5ed51d",
  "customerBuildingId": "99900000C048ADA6",
  "deviceId": "c8f09e83046c",
  "deviceName": "Sinemaa main meter",
  "source": "GATEWAY",
  "type": "ENERGY_CONSUMPTION",
  "value": 858.71,
  "timestamp": 1727992800000
}

Data Structure Attributes

Add an Event

For sending new Events to the MOOST Recommender Platform the below Endpoint can be used.

Example with CURL

# make sure ACCESS_TOKEN is set and valid (see "Request Access Token")
curl -X POST "https://api.moost.io/events/v1" \
     -H  "Authorization: Bearer $ACCESS_TOKEN" \
     -H  "Content-Type: application/json" \
     -d "{\"timestamp\":1657029000,\"customerId\":\"656730be2bc9719e6e5ed51d\",\"customerBuildingId\":\"999000009C54AAAA\",\"deviceId\":\"17306deb97e0f94609f13e22\",\"deviceName\":\"Device Link Car\",\"value\":99.9,\"type\":\"STATE_OF_CHARGE_RATE\",\"source\":\"CAR\"}"

Below you can find a list of Device Types that are known to the MOOST Recommender Platform and which Event Types you can send for each Device Type. If you cannot send all the information for a device, this does not significantly impact the number of possible use cases.