Rules
To manage rules, you need to have the permission Manage rules.
Rules are needed to get informed about certain situations the sensor detects. The contains
- the type of the sensor-event
- (optional) filter conditions
- the recipient of a message and the type of service
- the content of the message
- a rate limit
Rules can be added to a sensor or to a group.
Type of sensor-events
The sensor-event has to be defined within each rule. This is a mandatory field.
|
Setting |
Meaning |
|---|---|
|
Someone has fallen. |
Someone has fallen and the sensor has confirmed that fall. |
|
Someone might have fallen. |
Someone may have fallen and the sensor has started the fall analysis. |
|
Someone has fallen (high sensitivity). |
Someone has fallen and the sensor has confirmed the fall through the sensitive mode (requires sensor firmware v0.38 or later and enabled sensitive mode). |
|
The sensor is in a fall loop. |
The sensor reports a lot of fall events in a short time period but the state is not stable. This could indicate a fall. |
|
All persons have left the detection range. |
There is no presence in the monitored area. |
|
A person has entered the empty detection area. |
The sensor sees a person in the monitored area. |
|
Sensor is inactive. |
The sensor is offline because of power failure, wifi or internet interruption. He is not able to send any event. |
|
Sensor was inactive and is now active again. |
The sensor is online again and able to send events. |
|
A region was entered. |
A sub-region was entered and is occupied (e.g. the bed). |
|
A region has been left. |
A sub-region was left and is empty (e.g. the bed). |
|
The bed was left |
The region defined as bed has been left (requires sensor firmware from v0.40 and activated bed exit function). |
Type of group-events
The group-event has to be defined within each rule. This is a mandatory field.
To use rules on a group base you have to create a group first and add at least one sensor to this group. After that, click on the group and add a rule.
|
Setting |
Meaning |
|---|---|
|
All persons have left the sensor group. |
A sensors within this group have no presence in the monitored area. |
Filter conditions
Depending on the type of sensor-event you can use different filter conditions. These conditions are optional and not mandatory.
|
Setting |
Meaning |
|---|---|
|
The fall occurred between {x} and {y} o’clock. |
The fall event has to be reported between {x} and {y} o’clock to trigger this rule and send a message. |
|
The person who has fallen does not get up again for at least x seconds. |
To reduce the fall messages in case of some one is cleaning the room you can define a minimum of time the fall has to take place. |
|
The area was entered / exited between {x} and {y} o'clock |
The area must be entered or exited between {x} and {y} for a message to be sent. |
|
The area was previously occupied / unoccupied for {x seconds} |
In order for a message to be sent, the specified area must have been occupied or empty for the defined time unit. This can prevent a flood of messages when occupancy is constantly changing. |
|
The region was entered / exited between {x} and {y} o'clock |
The event must take place between {x} and {y} o'clock, only then will the rule be triggered and a message sent. |
Message recipient and service
Hence the cloud is able to inform the user about the selected type of sensor- or group-event a recipient and service has to be defined. This is a mandatory field.
|
Label |
Meaning |
|---|---|
|
User |
You can only select user who are assigned to the same customer like the sensor. |
|
Service |
Depending on the contact information of the user you can select several services to receive a message. If you are not able to select a specific service then the contact information are not complete. |
A list of available publisher can be found on the corresponding page.
message content
You can define the content of the message and which information should be send in case a rule gets hit by a sensor-event. You can customize the content to your needs.
|
Label |
Meaning |
|---|---|
|
Title |
Welcome message |
|
Message |
Main content of the message with important information regarding the sensor-event |
You can also use some pre-defined variables within the title and main content of the message.
Rate limiting
To avoid a flood of message you can use the Rate Limiting to enforce a break before sending further messages.
|
Label |
Meaning |
|---|---|
|
After sending a message, no message is sent for at least {x time units}. |
This option causes a break of the defined time unit after sending a message. |
|
After sending a message, the event must not occur again for at least {x time units} before a message can be sent again. |
Independent how often a sensor-event appears the event has to be stay out for the defined time unit until a further message will be send. |
Options
With this options you can enable or disable special functions. To view this options you have to edit an existing rule or create a new one.
In the top area Setup are 3 different buttons.
Feedback
This option gives the recipient of a message the possibility to validate the integrity of the message. With this feedback you can optimize the rule and / or sensor configuration to avoid false reports.
This option is only available for several service because of technical reasons.
Supported services
- GRPC
- Telegram
In the event list of the sensor this feedback is represented.
Confirmation
This option gives the recipient of a message the possibility to confirm that they process the notification.
Mit dieser Option gibst du dem Empfängern von Benachrichtigungen die Möglichkeit zu bestätigen, dass sie die Benachrichtigung bearbeiten. A confirmation informs all other recipients that the notification is being processed. This is to avoid multiple recipients taking care of a notification at the same time.
The confirmation only applies to the current rule. If several rules are created for the same situation (e.g. several rules for a fall detected) the confirmation only applies to the current rule. Several different confirmations are thus possible.
For technical reasons, this function is not supported by all services.
Supported services
- GRPC
- Telegram
Automatic update
This option informs the recipient of a notification when the event has ended. No separate message is sent for this, but the sent message is updated.
For technical reasons, this function is not supported by all services.
Supported services
- GRPC
- Telegram
Variable
Message titles and texts can be filled with dynamic content using variables. Variables always begin and end with two curly brackets. Access to the variable value itself begins with a period.
{{.Account.FirstName}}
If it is not clear whether a variable exists, this can be checked with if. An IF block must always end with an end block.
Hello {{if .Account.FirstName}} {{.Account.FirstName}} {{end}}
An alternative can also be specified directly with else.
Hello {{if .Account.FirstName}} {{.Account.FirstName}} {{else}} Unbekannter {{end}}
Caution: Be careful when using variables! If a variable does not exist or leads to an error, the message cannot be sent.
Overview of the values
An overview of all possible values can be found in this documentation.
|
Variable |
Meaning |
|---|---|
|
{{.EventMoment}} |
Time at which the event occurred. Date and time is specified if it did not occur on the same day as the message. Otherwise only the time is output. |
|
{{.EventDateTime}} |
Date and time the event occurred. Example: Feb. 2, 2020 15:04. |
|
{{.EventTime}} |
Time in seconds when the event occurred. Example: 15:04. |
|
{{.EventDate}} |
Date on which the event occurred. Example: Feb. 2, 2020. |
|
{{.IsUpdatable}} |
Indicates whether automatic update (AA) is enabled. |
|
{{.Publisher}} |
Indicates which service is used to send the message. |
|
{{.Account.FirstName}} |
First name of the user receiving the message. |
|
{{.Account.LastName}} |
Last name of the user receiving the message. |
|
{{.Account.DisplayName}} |
Cloud-generated name of the user receiving the message. This is always available. |
|
{{.Account.CustomerName}} |
Name of the customer to which the user belongs. |
|
{{.Account.IsBot}} |
Indicates whether the user is a bot or not. |
|
{{.Sensor.Name}} |
Name of the sensor that triggered the rule. |
|
{{.Sensor.Id}} |
SensorId of the sensor that triggered the event. |
|
{{.Customer.Name}} |
Name of the customer to which the sensors belong. |
|
{{.Customer.Location}} |
Location of the customer to which the sensors belong. |
|
{{.Customer.Email}} |
E-mail of the customer to which the sensors belong. |
|
{{.Customer.SensorCount}} |
Number of sensors managed by the customer. |
|
{{.Rule.Id}} |
ID of the rule that was met. |
|
{{.Rule.Name}} |
Name of the rule that was met. |