Overview

This documentation is intended to remove ambiguity in MyMaxwell portal development. It should be a common reference for making development decisions affecting user interface, performance, reports generation, infrastructure cost, roles’ privileges.

Intended users

• HTMS CEO - Tom Grizetti
• HTMS development lead - Marco Potenza
• Developers
• Designers
• Sprinterra management
• DevOps team
• Outside consultants
• And most importantly - QA engineer

Documentation workflow

Each call, email chain or personal discussion resulting into decision making should be reflected in the documentation at least in the form of meeting minutes, ideally as a decision page. This will make it easier to refence taken decisions removing “He said that on the call from XX October last year”.

Source location

All sources are stored in a git repository located at https://bitbucket.org/sprinterra/htms-docs. All new editors should get a bitbucket account in order to make changes. Ask Sprinterra devops.

View access

Currently view access is respricted on IP address basis. Ask Sprinterra devops to add new IP.

How to use it

The documentation is written in Markdown and compiled into a static website using mdBook. This README provides instructions for developers, users, and DevOps on how to:

• Run the documentation locally for preview and editing
• Build the documentation for deployment

Prerequisites

• Rust (recommended) or
• Install mdBook directly via other package managers (see mdBook installation)

Running mdBook Locally

To preview the documentation locally while you work on it:

1. Clone the repository

   git clone <repository-url>
   cd <repository-folder>
   

2. Run the mdBook server

This command starts a local web server with live reload.

mdbook serve

3. Open your browser

Visit http://localhost:3000/ to see the documentation.

4. Edit the markdown files

Changes will automatically refresh in the browser.

Building for Deployment

To generate the static files for deployment (e.g., to a web server, S3 bucket, or any static site hosting):

1. Build the book

   mdbook build
   

2. Output directory

The static website files will be generated inside the book/ directory by default.

3. Deploy

Copy the contents of the book/ directory to your deployment target.

Why mdbook

mdbook documentation engine was chosen because it is:

• lightweight and super fast to navigate
• static and portable
• every change is easily trackable via git
• textual math formulas and diagram thanks to Mathjax and Mermaid

timeline
    title Test timeline diagram
    2002 : LinkedIn
    2004 : Facebook
         : Google
    2005 : YouTube
    2006 : Twitter

User Roles

Overview

The MyMaxwell system defines a fixed set of user roles. Each role has a predefined set of permissions that cannot be modified at runtime. Any change to role permissions requires changes to both backend and frontend code.

The following user roles exist in the system:

• Superuser
  Creates and manages HTMS Admin accounts.

• HTMS Admin
  HTMS employee responsible for managing resellers and HTMS Viewer accounts.

• HTMS Viewer
  HTMS employee with read-only, global visibility across the system.

• Reseller
  External partner responsible for managing clients and their sites.

• Client Admin
  End-client representative responsible for managing users within their organization.

• Client User
  End-client user with view and reporting access to assigned sites.

Reseller

The Reseller is a key role in the HTMS business model and serves as the primary operational and communication interface between HTMS and the end client.

Responsibilities of the Reseller include:

• Acting as the main point of contact for the client
• Collecting and validating technical inputs such as:
  • Chiller parameters
  • Fluid parameters
  • Number of required M&V kits
• Deploying M&V equipment on site
• Creating and configuring corresponding sites in the MyMaxwell platform
• Ordering MMU kits, M&V kits, and fluid mixtures from HTMS via the MyMaxwell portal
• Tracking order status and deliveries through the Orders page

Reseller users are grouped by reseller company. All users within a reseller company share the same set of permissions.

Client Admin

The Client Admin represents the end client organization.

Responsibilities include:

• Viewing all sites associated with their organization
• Managing client users within their organization
• Requesting a change of assigned reseller

Client User

The Client User represents an end client employee with limited access.

Responsibilities include:

• Viewing assigned sites
• Accessing efficiency dashboards
• Generating IPMVP reports for assigned sites

System Entities

This chapter defines the core conceptual entities used in the MyMaxwell system.
Entities are ordered from the largest organizational scope to the smallest physical unit.

Reseller Company

A Reseller Company represents an external legal entity acting as a distributor of Maxwell fluid and monitoring equipment to end clients.

Reseller Companies are responsible for:

• Client-facing communication and coordination
• On-site and remote support
• Deployment and configuration of monitoring equipment
• Ordering equipment and consumables from HTMS

Key characteristics:

• A Reseller Company consists of one or more reseller users
• All users within a reseller company share the same permissions
• A Reseller Company may manage multiple Client Companies and their Sites

Relationship to clients:

• Each Client Company is associated with exactly one Reseller Company
• A Client Company may request a reseller change
• Reseller change is a supported business concept but is not currently exposed as a standard UI feature

Client Company

A Client Company represents a legal entity responsible for one or more buildings where Maxwell fluid is deployed.

Client Companies are end customers of the HTMS solution.

Key characteristics:

• A Client Company consists of one or more client users
• Client users may have access to one or more Sites belonging to the client
• A Client Company is always associated with exactly one Reseller Company
• A Client Company owns one or more Sites

Constraints:

• A Site cannot exist without a Client Company
• A Site cannot be transferred between Client Companies through normal system behavior

Site (Installation)

A Site (also referred to as an Installation) represents a single administrative unit in the system, typically corresponding to one physical building.

A Site:

• Always belongs to exactly one Client Company
• Represents the primary unit for monitoring, reporting, and analysis
• Cannot be transferred between Client Companies through normal system behavior

Operational notes:

• A Site may be created before physical deployment
• Correction of an incorrectly assigned Site (e.g. created under the wrong client) is considered a support-level action, not a standard UI operation

A Site may contain:

• Zero or more monitored equipment items

Monitored Equipment

Monitored Equipment represents a logical or physical part of an HVAC system that is being monitored within a Site.

Monitored Equipment:

• Provides context for sensor data
• Is used for visualization, analysis, and reporting
• Does not produce data directly

Key characteristics:

• Monitored Equipment belongs to exactly one Site
• Monitored Equipment is created manually, typically before physical installation
• One monitored equipment item may have multiple associated sensor units
• Monitored Equipment may exist without any sensor units assigned

Operational notes:

• Monitored Equipment without assigned sensor units is valid but non-functional, as no data will be produced

Sensor Unit

A Sensor Unit represents a physical sensor unit deployed at a Site.

A Sensor Unit:

• Measures one or more physical parameters
• Produces time-series data points stored in the system
• Is physically deployed and undeployed as part of site operations

Key characteristics:

• A Sensor Unit belongs to exactly one Site
• A Sensor Unit is associated with exactly one monitored equipment item
• A Sensor Unit produces data at a fixed interval (currently one data point per minute)

Operational constraints:

• Sensor Units are not reassigned between Sites
• A Sensor Unit may be deleted from one Site and recreated under another Site to reflect physical relocation
• Such relocation is considered an edge case and a support-level action

Entity Relationships (Summary)

• A Reseller Company manages one or more Client Companies
• A Client Company is associated with exactly one Reseller Company
• A Client Company owns one or more Sites
• A Site represents a single physical building (installation)
• A Site contains monitored equipment
• Monitored Equipment groups one or more sensor units
• Sensor Units produce time-series data points

graph TD
    RESELLER[Reseller Company]
    CLIENT[Client Company]
    SITE[Site / Installation]
    EQUIP[Monitored Equipment]
    SENSOR[Sensor Unit]

    RESELLER --> CLIENT
    CLIENT --> SITE
    SITE --> EQUIP
    EQUIP --> SENSOR

IPMVP report

This chapter explains IPMVP report building mechanics and reasoning.

1. Purpose

The main purpose of the IPMVP report in MyMaxwell is to prove that Maxwell additive has a positive effect on building’s HVAC system. This is achieved by showing that COP has increased.

2. Main Report Development Methodology

2.1 COP Curve Comparision

Methodology is best described going backwards from final desired figures to raw input data. Final report page consists of сomparison of the COP curve as a function of temperature and average COP increase, for example:

Averaged COP increase 13.1%

To compare COP curves from the baseline and reporting periods, it may be necessary to extrapolate the measured COP values over a wider temperature range. This is done under the assumption that COP varies linearly with outside air temperature (OAT). Linear extrapolation enables the comparison of COP curves that were originally obtained over different, non-overlapping temperature ranges.

The linear relationship can be expressed as:

\[ COP(OAT) = m \cdot OAT + q \] where:

• \(OAT\) is the outside air temperature in °C,
• \(m\) is the slope of the linear relationship,
• \(q\) is the intercept.

Note that comparision table uses data point from the model, not actual averaged COP data at specific OAT point.

2.2 COP Curve building

To build the COP curve, a statistical approach is required. First, the average COP values are calculated within discrete temperature bins, typically using 1°C intervals. These averaged data points \( (OAT_i,COP_i) \)are then used to construct a linear model that describes the relationship between COP and outside air temperature (OAT).

The linear regression model has the form: \[ \mathrm{COP}(OAT) = m \cdot OAT + q \]

\(m \) calculated as:

\[ m = \frac{ n \sum_{i=1}^n OAT_i COP_i - \sum_{i=1}^n OAT_i \sum_{i=1}^n COP_i }{ n \sum_{i=1}^n OAT_i^2 - \left(\sum_{i=1}^n OAT_i\right)^2 } \]

\( q \) calculated as:

\[ q = \frac{ \sum_{i=1}^n COP_i - m \sum_{i=1}^n OAT_i }{n} \] where \( n \) is the number of temperature bins.

The goodness of fit (linearity) of the model is assessed using the coefficient of determination \( R^2 \), defined as: \[ R^{2} = 1 - \frac{\sum_{i=1}^{n}(COP_{i} - \hat{COP_{i}})^2}{ \sum_{i=1}^{n} (COP_{i} - \bar{COP})^{2}} \] where:

• \( \hat{COP_{i}} = m \cdot OAT_i + q \) is the predicted value from the model,
• \( \bar{COP} \) is the mean of the observed COP values.

In the context of HVAC chiller COP curves, an \( R^2 \) value above 0.95 is considered acceptable, indicating a strong linear relationship between COP and outside air temperature. However, due to inherent variability in operational and environmental conditions, slightly lower values (e.g., around 0.9) may still be valid for practical analysis.

2.3 COP calculation

Coefficient of Performance (COP) represents the instantaneous efficiency of a chiller over a given time period.

\[ COP = \frac{|H|}{W} \]

where:

• \( H \) is the useful heat transferred by the chiller during the period,
• \( W > 0 \) is the net work input to the chiller.

In practical calculations, a correction factor of 0.8 is applied to account for system inefficiencies or measurement uncertainties. Needs explanation from Marco

To compute the chiller’s performance, the following measurements are required (averaged over 1 minute):

• \( Q\ (m^3/h)\) — fluid flow rate,
• \( t_{in}\ (°C) \) — fluid temperature at chiller inlet,
• \( t_{out}\ (°C) \) — fluid temperature at chiller outlet,
• \( P\ (\text{kW}) \) — power consumption,
• \( C_p\ (kJ/kg·K) \) — fluid specific heat capacity (constant, depends on fluid mixture),
• \( \rho\ (kg/m^3) \) — fluid density (constant, depends on fluid mixture).

The COP is calculated as:

\[ COP = \frac{ \frac{Q}{3600} \cdot \rho \cdot C_p \cdot (t_{in} - t_{out}) }{ P } \cdot 0.8 \]

COP should be computed for each time point after proper data sanitation.

2.4 Data sanitation

Since measurement data is taken continously regardless of currecnt chiller operation mode, it is required to do data sanitation to exclude irrelevant data points when chille ris not in steady operation mode. This includes any of the following conditions:

• Flow rate \( Q < 60\ m^3/h \)
• Flow rate \( Q > 75\ m^3/h \)
• Electrical power \( P < 20\ \text{kW} \)
• Electrical power \( P > 155\ \text{kW} \)

Marco: I assume these sanitation limits are chiller specific? maybe they should be specified in percentage of nominal power/flow rate?

3 Comparative analysis

IPMVP report should have comparative analysis of operation during baseline and reporting periods. This includes partload distribution and flow rate distribution analisis.

3.1 Partload distribution

Partload shows the chiller load percentage, calculated as:

\[ L = \frac{P_i}{P_{nominal}}\]

Where

• \( P_i\ (\text{kW})\) - power consumption measured,
• \( P_{nominal}\ (\text{kW})\) - nominal power consumption, from chiller datasheet.

Partload distribution is effectively a histogram showing how much time chiller spent in diffent operating conditions, for example:

Average Partload 35%

For comparative analisis it is important to plot both baseline and reporting period histograms on the same shart.

3.2 Flow rate distribution

Flow rate distribution is a histogram showing how much time chiller pump spent in different operating conditions. For example:

This histogram as well should be draw for both baseline and reporting periods on the same chart for comparision.

3.3 Data sanitation

Comparative analysis also exclude data points that are far from normal steady chiller operation. This includes any of the following:

• \( Q < 40\ m^3/h\)
• \(P_i < 50\ \text{kW}> \)

Technical Specification

This section defines expected system scale parameters to support architecture planning and to avoid over-engineering scalability. The values below are not strict limits but agreed planning assumptions based on current usage and expected growth.

All architectural decisions should be validated against these assumptions. If assumptions change materially, this section must be updated.

Current State (Baseline)

• Active installations: 24
• Average users per installation: 5
• Total users: ~120
• Data generation rate:
  Each installation produces 1 data point per minute

Growth Assumptions

• Installations are expected to double every year
• User count scales linearly with installations
• Data ingestion scales linearly with installations
• System is expected to support at least 3 years of growth without major architectural redesign

Target Scale Projections

Installations

Users

Assumption: 5 users per installation

Concurrent (Live) Users

Assumption:

• ~10–15% of users active concurrently during peak hours

Data Ingestion

Per Installation

• 1 data point per minute
• 60 data points per hour
• 1,440 data points per day
• 525,600 data points per year

System-wide Data Points

Data Retention Assumptions

Unless stated otherwise:

• All raw data points are stored
• No automatic down-sampling or aggregation is assumed
• Historical data must remain accessible for reporting and audits

Architectural Implications (Non-binding)

Based on the above assumptions:

• The system does not require hyperscale architecture
• Single-region deployment is sufficient
• Database design must support:
  • ~100 million rows over 3 years
  • Append-heavy write patterns
  • Time-series queries by installation and time range
• Read traffic is expected to be significantly lower than write traffic
• Peak load is driven by:
  • Report generation
  • Dashboard views during business hours

Out of Scope

This document does not define:

• Hard system limits
• Performance SLAs
• Disaster recovery requirements
• High-availability guarantees

These topics should be addressed separately if needed.

Revision Notes

This section reflects current expectations as of writing.
Any change in growth rate, data frequency, or retention strategy requires revisiting these assumptions.

Decisions

D-1 Use modified ISO format in CSV export

Regional date format will be interpreted incorrectly in another locale by Excel. To avoid ambiguity and to keep CSV generation simple following dattime format should be used: yyyy-mm-dd hh:mm:ss

D-2 IPMVP report requires compatibility with Excel only

Generated IPMVP report is not required to be compatible with Google Sheets or LibreOffice Calc. This enables usage of spill formulas, significantly reducing the file size.

D-3 Change Reseller functionality is postponed until the first request

This will require some FE and BE work and low priority, so it will be re-considered when we get first client asking for reseller change.

D-4 Mobile application does not necessaritly need to be native app. It may be a Progressive Web App

The only requirement is that it should be usable from mobile phone. No tiny text, usable controls. See 2025-01-15 weekly call

D-5 Impersonation should not be read-only.

See 2025-01-15 weekly call

Open Questions

Q-1 What is sensor unit name?

Do we really expect technicians to name sensor units? These are “grey” boxes for them. Maybe we should rename this to Location, letting them describe where sensor unit is located.

Q-2 Multi chiller systems seems to have incorrect report building. How they should be accounted?

Chillers 2, 3 .. N are not included in total electrical consumption of the system.

Q-3 What is the purpose of having individual sensor units as a separate list in the top menu?

What is the user flow that uses it?

Q-4 What is the reason to develop mobile application?

What problem does it solve that web portal cannot? Can it be postponed until we have a customer request for it?

Q-5 Do we have a general manual for the reseller?

Maxwell fluid is not easy to handle. M&V kit is not easy to setup. If we expect reseller to be autonomous, we need to give them a “Handbook” or “Operation manual”.

Glossary

List of domain-specific terms used in this documentation.

• COP - The coefficient of performance or COP (sometimes CP or CoP) of a heat pump, refrigerator or air conditioning system is a ratio of useful heating or cooling provided to work (energy) required. Higher COPs equate to higher efficiency, lower energy (power) consumption and thus lower operating costs. The COP is used in thermodynamics.

• HVAC - Heating, ventilation, and air conditioning.

• IPMVP report - A formal Measurement & Verification (M&V) report prepared according to the International Performance Measurement and Verification Protocol (IPMVP). Its purpose is to quantify and document energy savings achieved by HVAC projects such as retrofits, upgrades, or optimization measures.

• M&V kit - Measurement and Verification kit used to monitor chiller’s COP during baseline and reporting periods.

Weekly Meetings

This folder contains the minutes of all weekly meetings.

Meeting Minutes — 2026-02-19

Date: 2026-02-19
Time: 13:30 CET Location: Online Meeting

Attendees:

• Viktor Semenov
• Marco Potenza
• Tom Grizetti
• Edward Yusko
• Yurii Chabanov
• Mykola Surygin
• Pavlo Kalinkin
• Norayr Mkrtchyan

Agenda

1. Orders functionality updates
2. Baseline-only report generation status
3. Error notification overload and prioritization
4. Mobile app publication status
5. App walkthrough planning

Notes & Discussion

1. Orders Functionality Updates

Recent Changes:

• Added “Updated Date” field to orders.
• Order list view is now available to:
  • Maxwell (HTMS) admins
  • Resellers
• Previously, only order creation was visible; now full list and details are accessible.

Access & Visibility:

• Resellers see only their own orders.
• Maxwell admins see all reseller orders.

Delivery Packages:

• Orders now support delivery package management.
• From Maxwell side:
  • Add delivery packages
  • Modify packages
  • Delete packages
• Delivery form uses same columns as order table (liters, units, etc.).
• Feature is functional but still under development.
• Notifications in progress:
  • Reseller notified when order is fulfilled.
  • Maxwell admins notified when order is created.
  • All Maxwell admins will receive notifications (no differentiation yet).

2. Baseline-Only Report Generation

• Technically completed.
• Pending final clarification on data handling:
  • For baseline-only reports, use full data range without overlap sanitization.
  • Apply general thresholds from configuration to handle outliers.
• Release planned:
  • Mid next week (worst case: end of next week).

Recent Issue:

• Temporary MyMaxwell outage earlier today.
• Issue investigated and resolved.

3. Error Notifications & Prioritization

Problem Identified:

• Excessive error emails (hundreds).
• All errors marked “critical.”
• Important issues (e.g., panel offline for days) are lost among minor sensor fluctuations.
• Email overload is reducing usefulness of the alert system.

Examples of Issues:

• Sensors going offline/online frequently (minor).
• Complete loss of panel transmission for multiple days (major).
• Major data transmission gaps not being clearly prioritized.

Agreed Improvements:

1. Severity-Based Prioritization

   • Separate minor threshold violations from critical failures.
   • Complete panel communication loss to be highest priority.

2. Time-Based Filtering

   • Short sensor interruptions (minutes) → No alerts.
   • Consider alert only if:
     • Panel offline ≥ 24 hours.
   • 24-hour threshold considered reasonable and actionable.

3. User Segmentation

   • Differentiate between:
     • Maxwell super admins (technical alerts).
     • Resellers/clients (limited relevance).
   • Most internal alerts should be HTMS-facing only.

4. Retest Existing Logic

   • System was designed to send:
     • One notification per site per day.
   • Currently appears to be sending multiple.
   • Development team to re-test and verify grouping logic.

5. Separate Critical Category

   • Complete data transmission failure must:
     • Bypass daily grouping.
     • Be clearly labeled and elevated.
     • Potentially immediate notification.

Next Step:

• Add notification prioritization to upcoming sprint planning (Monday).
• Align with ongoing order notification development.

4. Mobile App Publication

Status:

• App description and privacy policy now provided.
• Next step: publish to App Store (Apple) and Google Play.

Decision Needed:

• Whether to:
  • Use HTMS developer account, or
  • Create a dedicated company developer account.

Notes:

• Apple Developer account costs approx. $100/year.
• Team will confirm whether previous account exists.
• Instructions to be sent to Tom if new account required.

5. App Review & Walkthrough Session

• Dedicated session requested to review app functionality in detail.
• Goal: Full walkthrough of current features (30–60 minutes).
• Screen sharing required during session.

Scheduled:

• Monday
• 12:30 (Tom’s time)
• 1-hour session
• Invite to include Victor, Marco, Edward, and possibly Nick.

Decisions Made

• Baseline-only report will use full data range with standard thresholds.
• Panel offline ≥ 24 hours qualifies as high-priority alert.
• Notification logic to be re-tested and redesigned with severity separation.
• Order and delivery notifications to continue development.
• Schedule dedicated app review session.

Action Items

Meeting Minutes — 2026-02-12

Date: 2026-02-12
Time: 13:30 CET Location: Online Meeting

Attendees:

• Viktor Semenov
• Marco Potenza
• Tom Grizetti
• Edward Yusko
• Yurii Chabanov
• Mykola Surygin
• Pavlo Kalinkin
• Norayr Mkrtchyan
• Volodymyr Shevtsov

Agenda

1. General document folder status
2. Mobile app privacy policy and store publication
3. Baseline reporting update
4. Order creation functionality demo
5. Field naming and ordering form adjustments

Notes & Discussion

1. General document folder

• General/global document folder is not currently under development.
• Existing document sharing already allows sharing with all current users.
• Limitation: access does not automatically extend to newly registered users.
• Temporary solution: distributors continue using Google Drive.

2. Mobile app: privacy policy and store listing

• Privacy policy and app descriptions are still required to publish apps to the App Store and Google Play.
• Edward to provide:
  • Basic app description
  • Privacy policy text
• Since access is restricted to known users (login-based), complexity is reduced.
• Legal consultation may still be advisable for privacy policy preparation.

3. Client feedback and baseline reporting

• Client in Thailand (Genome Auto) previously reported baseline dashboard issue.
• Issue was caused by a minor bug and has now been fixed.
• COP and tonnage values are now visible during baseline period.
• Remaining pending item: report generation during baseline-only period (still in progress).
• This is being developed alongside reseller and ordering functionality.

4. Order creation functionality demo

• Order creation is available under the “Orders” tab.
• Users can:
  • Create a new order
  • Specify quantity of units
  • Select related site
  • Enter billing and shipping addresses
  • Reuse previously stored addresses
  • Review all entered data before submission
• Orders are stored, but order list view is not yet implemented.
• Order listing functionality expected by next call.

5. Ordering form improvements

Several adjustments were requested to improve clarity for distributors:

MMV Panels

• Split into:
  • MMV Primary Panels
  • MMV Secondary Panels
• Multiple primary panels may be required depending on building configuration.

MMU Naming

• Rename “MMU panels” to:
  • “Maxwell Monitoring Units”

Ion Correction Liquid

• Discussion on whether to use system volume or liquid volume.
• Decision:
  • Use actual ion correction liquid volume (in liters).
  • This aligns with delivery tracking and package fulfillment.
• System volume calculations remain internal.

Decisions Made

• Keep general document sharing as-is for now; no immediate development.
• Edward to provide privacy policy and app description for store submission.
• Split MMV panels into primary and secondary fields.
• Rename MMU panels to Maxwell Monitoring Units.
• Ion correction liquid to be specified in liters for ordering and fulfillment clarity.

Action Items

Meeting Minutes — 2026-02-05

Date: 2026-02-05
Time: 13:30 CET Location: Online Meeting

Attendees:

• Viktor Semenov
• Marco Potenza
• Tom Grizetti
• Yurii Chabanov
• Mykola Surygin
• Pavlo Kalinkin
• Norayr Mkrtchyan
• Volodymyr Shevtsov

Agenda

1. Reseller-HTMS ordering functionality status
2. Recent fixes and deployment updates
3. Mobile application store release
4. Client feedback on baseline data and dashboard
5. Next release planning

Notes & Discussion

1. Reseller–HTMS ordering functionality

• Ordering functionality between resellers and HTMS is approximately 75% complete.
• Backend work is largely done; frontend development is currently in progress.
• Distributor-facing release is expected in approximately four weeks.
• A detailed list of distributor functionality will be shared separately.

2. Fixes and deployment updates

• Warnings for calculated values have been removed and are already deployed to production.
• Report generation for baseline-only data is in progress and nearing completion.
• Final infrastructure adjustments are being implemented to support baseline-only reports.

3. Mobile application store release

• Mobile applications (iOS and Android) are ready functionally but not yet submitted to app stores.
• App Store and Google Play listing text is required before submission.
• Edward is responsible for providing a short, accurate application description.
• Description should clearly state functionality and avoid marketing language to satisfy Apple and Google review requirements.

4. Client feedback: baseline data and dashboard

• Feedback received from a client in Thailand regarding dashboard visibility during the baseline period.
• Issue: COP and efficiency values are empty on the dashboard during baseline, making the performance tab unusable.
• Request: During baseline period, dashboard should show available calculated data (e.g., COP, efficiency), even if reporting-period comparison is not yet possible.
• Baseline-only report generation is already underway; dashboard behavior will be added to development planning (or maybe it works already, and it was just data mapping issue).

Technical investigation

• Live review identified missing COP calculation due to missing density data alignment.
• Root cause: Sensor configuration mismatch caused by installing two chillers instead of three as originally planned.
• Data fields were shifted, leading to incorrect parameter mapping.
• Resolution: Marco will adjust the data mapping (including creating a placeholder third chiller) to realign data streams.
• Density and CP values are constants; fixing the mapping will restore COP and dashboard calculations.

5. User adoption and UX feedback

• Currently, only one client is actively reviewing the system.
• No broader UX feedback available yet regarding navigation or usability.
• Additional feedback expected once more installations are completed.

Decisions Made

• Proceed with fixing dashboard data visibility during baseline periods.
• Maintain plan to release baseline-only reports first, followed by dashboard enhancements.
• Distributor functionality to be released in approximately four weeks.

Action Items

Meeting Minutes — 2026-01-29

Date: 2026-01-29 Time: 13:30–14:00 CET
Location: Google Meet

Attendees:

• Viktor Semenov
• Marco Potenza
• Tom Grizetti
• Edward Yusko
• Yurii Chabanov
• Mykola Surygin
• Pavlo Kalinkin
• Norayr Mkrtchyan
• Volodymyr Shevtsov

Agenda

1. Infrastructure updates
2. Reseller orders implementation status
3. User adoption and feedback
4. Reporting and baseline functionality
5. Mobile application status

Notes & Discussion

1. Infrastructure updates

• Production environment has been redeployed to a Linux Virtual Machine.
• Infrastructure costs reduced; SSL certificates are now automatically issued via Let’s Encrypt.
• DNS changes for mymaxwell.net were completed as part of this work.

2. Reseller orders implementation

• Development of the reseller–HTMS ordering system is in progress.
• Current work focuses on database and API layers; frontend work will follow.
• Goal is to make resellers autonomous in ordering MMU kits and fluids directly from HTMS.
• Inventory and production management are planned but intentionally postponed until basic ordering functionality is complete.

3. User adoption and feedback

• Real users are now accessing the system (Xavier and a client in Taiwan).
• Access was granted recently with limited functionality (MMU-related features disabled for now).
• No feedback has been received yet; users are expected to start testing soon.

4. Reporting and baseline functionality

• COP calculations are confirmed to be working correctly.
• Current limitation: reports cannot be downloaded if no reporting-period data exists, even when baseline data is available.
• This forces manual extraction and processing of raw data to validate baselines.
• Development requested and agreed to allow report generation even when only baseline data is present.
• Target delivery for this enhancement is by the end of next week.

5. Mobile application status

• Mobile app (iOS and Android) exists and supports client-side performance viewing.
• App currently lacks reseller and ordering functionality.
• App is still distributed via TestFlight / direct Android install and not yet published to app stores.
• With real users now onboarded, app store release is required.
• Edward to provide short descriptive copy for App Store / Google Play listing; screenshots will be handled by the dev team.

6. Documents and marketing materials

• Work is ongoing on a new shared folder (tentatively “Tech Marketing”) for presentations and marketing materials.
• Once ready, access and upload flow will be tested jointly.

Decisions Made

• Proceed with publishing the mobile app to official app stores once descriptive copy is provided.
• Implement report generation for baseline-only periods as a priority.
• Continue prioritizing reseller ordering functionality before internal inventory management.

Action Items

Meeting Minutes — 2026-01-22

Date: 2026-01-22
Time: 13:30–14:00 CET
Location: Google Meet

Attendees:

• Viktor Semenov
• Marco Potenza
• Yurii Chabanov
• Mykola Surygin
• Pavlo Kalinkin
• Norayr Mkrtchyan

Agenda

1. User feedback on MyMaxwell platform
2. Reseller integration demo and discussion
3. Error handling and notifications improvements
4. Reporting enhancements

Notes & Discussion

1. User feedback on MyMaxwell platform

• No external users have been granted access yet except Xavier. No user feedback received so far.
• It was agreed to request feedback from users to compare with internal vision.

2. Reseller integration demo and discussion

• Pavlo demonstrated current development status of reseller integration in DevZone environment.
• Resellers are autonomous units managing their own clients, sites, sensors, users, and documents.
• Invitations to resellers are sent by email; resellers set up their company profile and create clients and sites.
• Reseller users have a company-wide access level where all users see all clients and sites under their reseller company.
• Resellers have similar access rights to MyMaxwell admins but limited to their own created clients and sites.
• Sensor units can be created, mapped, and edited by resellers; chiller modification rights are being limited to maintain data consistency.
• Resellers can impersonate client admins/users to view dashboards and trigger reports.
• UI improvements planned to clarify reseller-client relationships and allow client movement between resellers.
• Order system development for resellers has started using an Excel order form example.

3. Error handling and notifications improvements

• Issues reported with frequent error notifications for offline sensor units and out-of-range values.
• Out-of-range warnings for calculated values (e.g., temperature differential) are not configurable and cause excessive notifications.
• Agreed to remove warnings for calculated data to reduce noise.

4. Reporting enhancements

• Request to enable report generation even when no reporting data exists, e.g., to show baseline behavior.

Decisions Made

• Remove out-of-range warnings for calculated parameters like temperature differential.
• Implement report generation logic to allow reports even if no data is present for the reporting period.
• Reseller access rights clarified as equivalent to MyMaxwell admin but scoped to their own clients and sites.
• Allow editing chiller number in parameter mapping

Action Items

None

Meeting Minutes — 2026-01-15

Date: 2026-01-15
Time: 13:30–14:00 CET
Location: Google Meet

Attendees:

• Viktor Semenov
• Tom Grizetti
• Marco Potenza
• Edward Yusko
• Yurii Chabanov
• Mykola Surygin

Agenda

1. Document functionality still lacks global documents
2. Impersonation need to be NOT read only
3. Mobile application priority

Notes & Discussion

1. Document functionality still lacks global documents

HTMS wants to have global shared documents called Technical documents available for every authenticated MyMaxwell user. HTMS admins can edit them.

2. Impersonation need to be NOT read only

For the sake of support and flexibility we allow impersonation to be fully functional. This will allow to help resellers manage their installations, do orders, etc. And this is relatively easy to implement.

3. Mobile application priority

Viktor: Currently we have a native Android and iOS application that support read only view of MyMaxwell. And while it’s almost ready, deployment process is way more complicated than it is for web application. This may require supporting 2 concurrent API versions, forcing customers to update their app, waiting for Apple and Google application review, conform to their UI and UX standards (yes, they check this as well, especially apple). Even tiny visual change will require to pass through the whole flow. And at the very end MyMaxwell portal is a work application and we don’t expect users to chek their efficiency during commute.

Tom: We need this mobile functionality to enable technicians to do field work and customers to check their building status on the go. Also Inverstors like it.

Victor: Then we can do mobile web app. This means adjusting web interface for mobile device when open from the phone or tablet. This does not require installation, updates are simple and users never have stale version installed. Also it is easier to deploy and intergate with existing web functions.

Tom: Dev team should figure out how to make this technically. I’m ok with either option if it looks and behave like a phone optimized application: controls and text size should be adequate.

Decisions Made

• Native web application is not a requirement per se. Mobile view is a requirement.
• Impersonation should allow all actions of impersonated user, not read-only.

Action Items

Meeting Minutes — 2026-01-08

Date: 2026-01-08
Time: 13:30–14:00 CET
Location: Google Meet

Attendees:

• Viktor Semenov
• Marco Potenza
• Edward Yusko
• Yurii Chabanov
• Mykola Surygin
• Volodymyr Shevtsov
• Pavlo Kalinkin

Agenda

1. Development progress on Reseller functionality
2. Timestamp format in raw CSV export
3. Client presentation status of the MyMaxwell portal
4. Remaining work to eliminate last bugs before release
5. Documentation portal for requirements alignment
6. Azure Application Service Plan migration to Linux to reduce infrastructure costs

Notes & Discussion

1. Development progress on Reseller functionality

There is still a significant amount of work to be done. Progress is highly dependent on timely management input.

2. Timestamp format in raw CSV export

The yyyy-mm-dd hh:mm:ss format now works universally across all locales in Microsoft Excel. This change has not yet been deployed to production.

3. Client presentation of the MyMaxwell portal

Edward: A newsletter will be sent on January 14th to 75 distributors, stating that some already have access to the MyMaxwell portal. There are many requests coming through sales representatives for access.
As a result, the team should be ready to support 2–3 HTMS-friendly distributors after January 14th and address their feedback and complaints. These distributors should be selected together with Tom and Ben.

4. Remaining work to eliminate last bugs

Viktor: There is nothing preventing a release in principle. Final fixes to client documents are still pending and are expected to be released next week; these can then be used.
Efficiency calculations still have minor issues, but these are purely mathematical nuances and not considered critical. The raw CSV export date format issue has been fixed.

5. Documentation portal for requirements alignment

Edward was invited to review the portal documentation available at
https://docs.mymaxwell.net

6. Azure Application Service Plan migration to Linux

Azure Windows-based service plans are approximately four times more expensive than Linux-based plans. The application runs well in a Linux environment; this has been tested in development and is planned for release to production next week.

Decisions Made

• No formal decisions were made; the call served as a progress sync.

Action Items

Meeting Minutes - 2025-12-11

Date: 2025-12-11
Time: 13:30 CET – 14:00 CET
Location: Google Meet
Attendees:

• Viktor Semenov
• Tom Grizetti
• Edward Yusko
• Yurii Chabanov (absent, on vacation)
• Mykola Surygin
• Marco Potenza

Agenda

1. Calculations review
2. Assessment response & developer availability
3. Efficiency results clarification
4. Naming conventions in MyMaxwell
5. Timestamp consistency
6. Schedule update
7. IPMVP report generation documentation

Notes & Discussion

1. Calculations review

• Marco rechecked the calculations and found minor but important issues that must be addressed.

2. Assessment response & developer availability

• Sprinterra requires developer availability to respond properly to the assessment.
• Yuriy is currently on vacation and will return on December 22.

3. Efficiency results clarification

• Negative efficiency values are expected, as the system consumed less energy.

4. Naming conventions

• Naming conventions should be revised to avoid confusion, for example “efficiency” should always be positive, “consumption” can be negative.

5. Timestamp consistency

• The timestamp format in reports is inconsistent (mix of 24h and AM/PM), sometimes string, sometimes Datetime.
• Format must be unified across all reports.

6. Schedule update

• No call next week (Dec 18) due to lack of developer availability.

7. IPMVP report generation documentation

• Viktor has started working on IPMVP report generation documentation.

Decisions Made

• Timestamp formatting needs to be unified across all reports.
• Naming conventions should be aligned to avoid confusion.
• Next meeting will take place after December 22.

Action Items

Meeting Minutes - 2025-12-04

Date: 2025-12-04
Time: 13:30 CET - 14:00 CET Location: Google Meet Attendees:

• Viktor Semenov
• Tom Grizetti
• Edward Yusko
• Yurii Chabanov
• Mykola Surygin

Agenda

1. Calculations confirmation
2. Libararies update
3. Sprinterra waits for task prioritization
4. Client level documentation
5. Initial assessment briefing

Notes & Discussion

1. Calculations confirmation

• Sprinterra waits on calculations confirmation
• Marco will respond with his judgement ASAP.

2. Libararies update

• Some libraries used in the project are outdated and better be updates for security reasons.

3. No work to be done. Sprinterra waits for task prioritization

• This is why Viktor is onboarded.
• Viktor is Sprinterra’s day-to-day contact.

4. Client level documentation

• Currently docs are on the site level.
• We want to have more generic, client-level document storage where documents are not tied to a specific site.
• Documents should be available only to logged users.
• Files are isolated per client, not global.
• This is not urgent, but required.
• This task is independent of calculations, Marco’s absense is not a blocker.

5. Initial assessment briefing

• Data ingress and portal backend are sharing resources. They need to be split in two to avoid tampering sensors data ingress by user actions or DDOS attack.
• Using time-series database to store sensors data should improve extracting data for dashboard and reporting. Also build-in archiving and averaging is possible for historical data. Azure SQL server may already provide this functionality, need to be researched by DevOps.
• Report generation need to be streamed and not built in-memory. This will significantly reduce load on the infrastrcuture and will allow hosting this service as a function, not a full-time VM. This is less convenient from the developer point of view, but should be tolerated for the sake of report generation simplicity. This approach allows to
• Simplified report in PDF format should be added with only the final data, thus making it easy to open.
• Old sensor data should be archived for cost-effective storage. Again, maybe azure already offers something for this. Otherwise we need to make a plan for this. This is not ugent, but required once dataset grows.
• Frontend need to be served via CDN and cached at the edge, closer to the users. Use brotli compression for static assets, with gzip as fallback. Use http/2 and http/3 with http/1.1 as fallback. This will improve page load time for client.
• Viktor have not found deployment monitoring tool but it is present in functional. Sprinterra also has Disaster Recovery Protocol and Viktor want to take a look at it.

Decisions Made

• Mykola will clarify infra questions with devops
• Viktor will formalize requirements on client-wide document storage
• Client-wide documentation storage should go into implementation

Action Items