Monitoring

User roles

The portal offers 4 user roles:

• Team admin – Main team administrator. Adds and removes users and sets their permissions; creates locations, sublocations, groups and all other portal elements. Naturally has the permission to manage all devices, sensors, alarms etc. A Team admin is an “absolute ruler” over the team and its data. Each Team must have at least one Team admin.
• Device admin – Usually the installation technician or the administrator of the equipment to be monitored. May view data, add and edit devices and sensors, set safe ranges, configure alarm messages, and add devices to locations or groups.
• Report admin – Usually an engineer, technology expert, or a financial administrator. May view measured data and create dashboards, graphs and reports. That is, works with data and overviews to present the measures values in line with the company needs.
• Visitor – May view the measured data but cannot change or add anything. This role is often given by small and medium system integrators to their clients who have no IT or other experts of their own, in order to allow them to view their environment but without the right to change any critical values that could cause harm. It is also suitable for receptionists or security guards who can then quickly check the affected location in case of an alarm.

Different roles (in particular Device admin and Report admin) can be combined as needed. On the contrary, in small-scale installations it may be sufficient to just have one or two Team admins and not worry about differentiating the roles.

	Team Admin	Device admin	Report Admin	Visitor
Add devices
Add teams
Delete teams
Edit devices and sensors
Display sensor readings
Create and edit reports
Download graphs (if available)
Create graphs
Create Dashboards
Create and edit groups
Create reports
Add users
Delete users
Create and edit locations
Batch operations
Create and delete Permission groups

Permission groups

Within a team, everyone can see and work with everything, if they have a role with sufficient permissions. On the contrary, permission groups can be used to grant access to specific elements only (devices, sensors, groups etc.) to individual users.

This allows to have a single team supervising multiple sites (e.g. server houses in Prague, Berlin and London) but at the same time restrict the values visible to individual employees to “their” site only. Team admins can still access everything.

In a similar way, permissions can be fine-tuned down to the level of sensors. For example, IT personnel can be only allowed to monitor the environment in their racks, even if thermometers that the kitchen staff is responsible for are connected to the same Poseidon device.  That way, the IT personnel cannot interfere with the settings of reports that the kitchen staff need for GAMP5 and HACCP.

Permission groups are a powerful tool, so their implementation needs to be carefully planned and executed. For that reason, only Team admins are allowed to create and manage Permission groups. Other users have lesser roles (or their combinations). It is possible to use Permission groups to limit the access by other Team admins; however, these Team admins can always use the permissions associated with their role to grant themselves access to everything.

With Permission groups, access can be granted independently in a fine-grained way to various elements:

• Devices
• Sensors
• Dashboards
• Graphs
• Reports
• Device groups
• Locations

The settings for individual elements are independent. This means that a user who is granted access to a location does NOT automatically receive access to devices and sensors in that location. Likewise, if a user is allowed to view a sensor, the user is NOT automatically granted access to the corresponding device.

Access to a device allows the user to view the device status, NOT the readings of its sensors. Likewise, permissions to work with a device group or a location only give access to data on that level. For example, for a location you can see that 6 sensors are OK and one is in alarm; however, if you don’t have the permission to work with that sensor, you will not know which one it is.

Elements that are not associated with any Permission groups are visible to all team members. This is to make sure that existing users, or users who do not need such a powerful tool, do not have to immediately deal with Permission groups. Therefore, nothing changes for existing customers. Similarly, customers who want to use Permission groups can start by creating a “default” group for all existing and new elements.

Gradually, Permission groups will be applied to XML exports, SNMP, and so on.

All HW group devices provide data in XML. However, for historical reasons, the XML formats used by different devices differ significantly, and unification is not feasible due to the need for backwards compatibility. However, with SensDesk.com, data can be retrieved from all connected devices in a unified format.

Due to the multi-user nature of the portal, it is necessary to ensure that each customer can only see their own data. For this reason, access to the values.xml file is somewhat more complex, compared to accessing individual devices. On the other hand, the content is structured in a better way.

There are two new ways of obtaining the values.xml file:

• At http://sensdesk.com/sensdesk/team/TEAM_ID/values.xml after logging in with your username and password
• At http://sensdesk.com/sensdesk/values.xml?values_xml_key=YOUR_VALUE.XML_KEY

In the first case, only the values to which you have permissions are retrieved. In the second case, the values of the whole team are retrieved.

The key for retrieving the XML file can be found at the team page:

Complete description of the XML format is available for download at: https://www.hw-group.com/cs/product-version/sensdesk-xml-format

What is alarm escalation?

Alarm escalation can refer to three different things. With our products, all user requirements can be met.

• Resending the alarm message
• Forwarding the alarm message to another user
• Sending a reminder if the situation gets worse

Resending the alarm message

Most mature devices, such as Poseidon2, Damocles2, Ares, HWg-WLD or WLD2, can resend alarm messages. This feature is called Periodic Alarm. Simply specify a time in minutes or seconds (depending on the device type). If the alarm lasts longer than the specified time, the alarm messages are sent again.

Devices intended for home use, such as HWg-STE, STE2 or SD devices, do not support this feature directly; however, the feature is available through the Sensdesk.com portal.  

The portal supports the feature for the SafeRange as well as for all Notice ranges – see below.

Forwarding the alarm message to another user

It is often needed to escalate alarms to another operator or to a supervisor. This function would be difficult to define within a device, hence it is implemented in its entirety within the SensDesk.com portal. That way, it is possible to configure the escalation in a user-friendly way, present an overview of all alarm messages, and provide central management. Escalation uses the Notice range feature and its Delay parameter. Simply set up a new Notice range with its limit values equal to an existing range and set the Delay to the required escalation delay. At the respective sensor or device, create a new action, set its target to the person handling the escalation and choose the range with the delay. It is possible to define multiple ranges and actions for several escalation levels, e.g. to send an alarm immediately to the technician on duty, one hour later to the back-up technician, and after two hours to the operations manager.

Note: When defining Notice Ranges, keep in mind that the PushPeriod can prolong the delay. For example, if the delay is 3600s (60 minutes = 1 hour), the escalation can take up to 4200s, that is, 75 minutes (1 hour and 15 minutes). If you need to escalate after 60 minutes at most, set a shorter delay, e.g. 55 minutes (3300s).

Escalation when the situation gets worse

This type of escalation only applies to sensors, i.e. analog values. It cannot be defined for binary inputs and outputs. It is similar to the escalation to another person as described above: instead of a delay, specify a different range of values. For example, when monitoring the temperature in a cabinet, one action can turn on back-up AC at 35°C, another action notifies the property maintenance at 45°C, another one shuts down the servers at 55°C and a yet another one notifies the fire brigade at 85°C.

Useful tips

Always set a hysteresis – Just as with in-device SafeRange settings, it is highly recommended for Notice Ranges, too.

Give descriptive names to Ranges and Actions – When creating a new Range or Action, a name needs to be specified. Choose names that are easy to understand. This will make it easier to edit Ranges and Actions and create new ones. When creating an action, it is necessary to select an existing range. At that moment, ranges named “Range1” and “Range2” don’t really help. On the other hand, ranges named “20-40C” or “20-40C 60min” are easy to distinguish.

All sensor's data from your user account on the SensDesk.com (SensDesk technology based portal) are available for some time in the XML format that can be periodically downloaded over http or https (XML Application Note is here). 
However, the XML format is not very suitable for IT environments that need quick and brief responses. To address this, a SNMP agent feature was added. This request-response protocol runs on top of UDP, It allows targeted queries for one specific value, without downloading lots of unneeded data.

Core information:
The SNMP implementation in the portal supports SNMPv1 and/or SNMPv3 over UDP.
All settings can be configured at the user’s login page, http://sensdesk.com/user/.
SNMP Server Address is portal address (ex.: Sensdesk.com), SNMP port is 1161.

Results of SNMP Walk request with Paessler SNMP tester

Showing all sensors data from the portal user account. The user / Team account is identified with using the Community.

Results of SNMP Walk request with iReasoning MIB Browser

Showing all sensors data from the portal user account. The user / Team account is identified with using the Community.

How to configurate SNMP on the SensDesk.com portal:

Every user can create two SNMP accounts. SNMP version and access permissions can be configured separately for each account. (At this moment, only read access is allowed.)
The community for SNMPv1 or the user name for SNMPv3 are randomly generated, and are unique within the whole portal. It is possible to regenerate them on saving.

The generated community or username is also shown in the user account properties.

The MIB table is currently under development and available for download in the user account.

The devices themselves support numerous protocols; one could therefore avoid a common concentrator and modify the communication protocols directly in the devices. However, this is not realistic due to their different characteristics, communication interfaces, age, and the need to maintain backward compatibility.

For instance, Narrowband devices (NB-devices family) do not offer any standardized outputs and only communicate using a proprietary protocol. Devices connected over GSM/LTE cannot be accessed for reading. And even Ethernet devices have very different properties. The solution is to use the portal. In addition to other functions, the portal provides current values from all devices in a unified way using XML or SNMP.

In case of SNMP, both SNMPv1 and SNMPv3 can be used. Support for SNMP traps (for alarms) is coming soon. Each user is assigned a community and a username for SNMPv3. This is to ensure that each user can only access values which they are authorized to access.

For SNMP, the principle is the same, except that the portal login username and password are used to determine user permissions.

For more information about using SensDesk.com for data concentration, see our application notes.