This dashboard is essential for monitoring and ensuring the devices configured with OSS are performing as expected. It enables you to filter information based on date time, areas, schedules. Moreover, it allows you to track changes over time, providing flexibility in monitoring and analyzing device (configs) startup trends.

There are four pages in the dashboard:

• The Current Day page provides current day information on devices configured with OSS.

• The Historical page provides historical information on OSS and devices configured.

• The Configs Changes page provides information on expired OSS configs.

• Expired refers to configured devices which were made incompatible because of a change.

• The Troubleshooting page provides information on device overrides made by OSS.

• The dashboard shows data only for devices configured with OSS, which were running for the specified day or time period.

• Difference between Comfort Index and Recovery Temperature:

• CI: Difference of temperature set-point with temperature at occupancy start (time when people come in).

• RT: Difference of temperature set-point with temperature at device occupancy start (time when device is started by OSS).

Current Day

This page is updated every hour.

This page provides an overview of the devices configure with OSS, for the current day. It includes details on when the devices started working, and critical metrics such as the comfort index, the number of devices that were optimized, the number of devices that did not reach setpoint, average time to setpoint, etc.
What you see first when opening the dashboard are cards displaying important metrics and a table displaying AHU start times (this only shows if the building has parent-child devices, such as AHU-VAV, configured with OSS. If that is not the case, a weather widget is shown). From the cards you can get an initial idea on how the building and devices are doing, by checking the number of devices which were able to reach setpoint, as well as the comfort index.

The first graph you see is a heatmap, which shows how much on average the devices within a schedule deviate from their setpoint during the day. You can notice whether the devices within a schedule are keeping the zone temperature within setpoint throughout the selected day.

The next two graphs are related to devices working and setpoint satisfaction. The one on the left (“Optimized Devices & Time to Setpoint”) shows you the number of devices that were optimized by OSS per Schedule and the average time it takes them to reach setpoint. The right one (“Devices Satisfied Hourly”) shows you how many of the optimized devices reached setpoint at each hour of the day.

The following scatterplot offers you insight on device level (represented by points) and schedule level (represented by colors). Here, you can notice patterns of devices within a schedule, while also being able to detect outliers. Devices which appear on the top left corner should draw attention because they take a long time to reach setpoint when the recovery temperature is low. Whereas the points in the low right corner are devices that can be considered the best at recovering their temperature for a short time.

The drop-down table displays metrics based on the hierarchy: Area, Schedule, Device. You can see specific device information, as well as summary averages for Area and Schedule.

The last table in this view shows you specific device details based on a device filter.

Historical

This page is updated every hour.

The Historical page provides an overview of the devices configure with OSS, for a selected time period. The objective of this page is to show you what OSS is doing on the long run, and get insight on device performance when it comes to setpoint satisfaction.

When first opening the page you can see three filters on top: Date Time, Area Name, and Schedule Name. You can select any time period to see the respective graphs and metrics, same for the other two filters. Next, there are four cards with information on the number of devices configured with OSS for the building, information on how close to setpoint the zones are when people come in, the average time it takes to reach setpoint, and the total hours saved by running the devices with OSS. Moreover, there is a table showing details on startup time for each day of the selected period.

The hours saved metric requires additional coordination with KODE support. Our product team is working to enable self serve enablement of this feature in Q1 2025. If you have an active OSS deployment which needs this information please reach out to [email protected].

Apart from the total hours saved, you can also see the hours saved by OSS per day. This helps notice patterns in device runtime savings. On the plot below “Daily Hours Saved”, the number of devices optimized by OSS per day is shown, along with the average time to setpoint.

The left graph (“Number of Devices That Did Not Reach Setpoint”) here shows the total number of devices that did not reach setpoint per day, while the right graph (“Satisfaction Time”) shows the average time in which the devices satisfied setpoint before occupancy starts (also known as running minutes lost) and after occupancy starts (also known as comfort minutes lost). At the same time we show a line of the average recovery temperature (the difference between zone temperature at device OSS start and the setpoints).

The next graph, “Time to Setpoint”, gives you an overview on Schedule average time to setpoint per day. Helping detect patterns related to both Schedule and day.

Same as in the Current Day page, you can see a scatter plot showing the average device time to recovery, over the long run.

The drop-down table below is grouped based on schedule and device, displaying aggregated information on the relevant metrics for the selected period.

The last table on this view shows 10 of the devices which took the longest to reach setpoint on average, along with their average recovery temperature, giving you an idea on which devices may need to paid attention.

Config Changes 

This page is updated every day.

This page provides information on changes that happen within a configured device that may have led to it being incompatible with OSS. You can see which devices were made incompatible with OSS and what changes were made to these devices which may have led to incompatibility.

In this page we show all changes detected in a device by our service. So a device might have more than one change in a day, and therefore will show up on the table more than once.

The goal is to check which devices were made incompatible by the changes, and do what it takes to make them compatible again with OSS if needed.

Troubleshooting 

This page is updated every hour.

In this page, overrides made by OSS in the configured devices are showed. By filtering with Override Status, you can see issues that may have happened when overriding the devices.
The purpose of this page is to inform the user why a device could not be turned on by OSS.