# Myrspoven myCoreAI is Myrspoven's optimization layer for commercial and residential buildings. It connects to an existing Building Management System (BMS) and trains a physics-informed digital twin of how the building responds to weather, how it is used, and the control actions applied to it. From that, it automatically adjusts a selected set of control signals to cut energy waste while keeping indoor conditions inside agreed comfort bounds. The building's existing HVAC logic stays in place — myCoreAI makes no permanent changes to it. Instead, it works on top of that logic, continuously tuning the relevant signals so the building runs at a more efficient operating point. *** ### Audience * **Portfolio and asset managers** use myCoreAI to reduce energy costs and improve operating margins across their building portfolio. myCoreAI connects to existing building systems and optimizes HVAC setpoints continuously — delivering measurable savings without capital expenditure or changes to existing infrastructure. It also supports energy management obligations under ISO 50001 and EPBD reporting. * **Property and facility managers** are the day-to-day operators. They set comfort bounds, review performance, and respond to alerts — myCoreAI handles the continuous optimization in the background, so facility teams aren't manually tuning setpoints across the building. * **System integrators and energy data providers** connect buildings to the platform by mapping existing BMS signals: the sensors myCoreAI reads and the setpoints it controls.\ Integration is signal-based and vendor-agnostic — stacks such as Schneider, Siemens, Honeywell, and Fidelix are fully supported. * **Developers** work with Myrspoven via the Myrspoven AI-API to read signals, push setpoints, or build tooling on top of the platform. You can operate against the API directly or wire your own scripts and pipelines to it. ### How it works Every hour, myCoreAI runs the same loop: 1. **Read** the latest signals from the BMS. This covers live sensor data — indoor temperatures, energy meters, equipment status — alongside the building's own configuration, such as current setpoints and system structure. 2. **Predict** how the building will respond over the next 72 hours, using the digital twin together with the weather forecast and learned patterns of how the building behaves. 3. **Optimize** the setpoint policy to minimize energy use while staying inside comfort bounds. 4. **Write** the resulting setpoints back to the BMS — pushed every 15 minutes. The digital twin is retrained as new data arrives, so myCoreAI adapts as the building, weather, and usage patterns shift.
myCoreAI control loop: the building's BMS sends sensor readings via the Myrspoven edge to the cloud, which runs the optimizer hourly over a 72-hour horizon using weather and price inputs, then writes setpoints back every 15 minutes.

The myCoreAI control loop — sensors in, optimized setpoints out.

#### Worked example Consider an office building heated by district heating on a capacity-based tariff — one where the cost depends partly on the building's peak power draw, not just total energy used. It connects its BMS via a standard signal mapping: zone temperatures, supply and return on two heating circuits, the primary heat meter, and the outdoor sensor. myCoreAI trains a digital twin on the building's recent operating history, then takes over the heating-circuit supply setpoints. In the weeks that follow, it flattens the morning ramp by pre-heating earlier at lower supply temperatures, holds zone temperatures inside the configured comfort bounds, and clips the daily peak below the tariff threshold. Result: lower delivered energy and a reduced capacity charge, with no change to BMS logic. ### Key concepts * **BMS / BAS (Building Management System / Building Automation System)** — the existing controller stack in the building (Schneider, Siemens, Honeywell, Fidelix, and others) that myCoreAI reads from and writes setpoints to. * **Signal** — a single named data stream from the building. It is the level at which everything is represented: the sensor data read in the loop above (a temperature sensor, an energy meter), a setpoint, and equipment status are each one signal. See the [Developer reference](/developer-reference/overview). * **Setpoint** — a writable value sent back to the BMS (for example, a heating-circuit supply temperature). The BMS's own control loops act on the setpoint. * **Digital twin** — the physics-informed model of a specific building, trained from its sensor history. myCoreAI uses it to predict how setpoint changes will affect indoor conditions and energy use. * **Optimization horizon** — how far ahead myCoreAI looks when choosing setpoints. Currently 72 hours. * **Baseline (energy)** — the reference energy profile a building is compared against in reporting, used to estimate savings. This is distinct from the building's *control* baseline — how its own systems would run without myCoreAI — and the two must not be conflated. * **Comfort bounds** — the indoor-condition bounds (typically temperature) myCoreAI must stay within. Configured per building, sometimes learned from historical data. * **Energy cap** — optional feature that limits the building's peak power draw. Relevant for capacity-based ("effekt") tariffs, where charges scale with peak power rather than total energy. * **myLoadshift** — shifts consumption across the day in response to spot-market electricity prices (e.g. ENTSO-E day-ahead). ## Where to next | Audience | Start here | | ---------------------------------------- | ---------------------------------------------------------- | | **Customers** using myPortal | [myPortal](/customer-interfaces/myportal) | | **BMS integration partners** | [BMS integration](/integrations/overview/bms-integrations) | | **Developers** building against the APIs | [Developer reference](/developer-reference/overview) | | All **integration options** | [Integrations](/integrations/overview/bms-integrations) | | **Security and compliance** | [trust.myrspoven.com](https://trust.myrspoven.com/) | # Glossary This page defines the meaning of every product name, feature name, and recurring technical term used across Myrspoven docs. Where two terms existed before this glossary, the entry here is the one all agents and writers should use going forward. *** ### Adaptive comfort bounds See [comfort bounds](#comfort-bounds). ### Adaptive min/max A per-signal constraint applied by myCoreAI that clips the upper or lower bound of a supply-temperature setpoint relative to its baseline supply curve. Used to prevent the optimizer from operating in ranges that are uneconomical (e.g. very high summer supply temperatures) or unsafe during startup. ### AHU (air handling unit) A mechanical unit that conditions and distributes ventilated air inside a building. myCoreAI controls AHU supply-air temperatures and, where applicable, fan pressure setpoints. ### AI Freedom A myCoreAI configuration parameter that allows the optimizer to move setpoints beyond the configured comfort bounds, drawing instead on learned reference limits derived from the [indoor climate baseline](#indoor-climate-baseline). Any value greater than zero activates the feature; the customer-visible control is effectively a binary on/off toggle. ### AI Penalty The objective-function weighting system inside myCoreAI that balances comfort, equipment behavior, heating sources, cooling sources, and energy price across each optimization run. Higher penalties on comfort violations force the optimizer to stay within [comfort bounds](#comfort-bounds). ### AI uptime See [uptime](#uptime). ### Baseline The historical supply-curve or energy-consumption reference against which myCoreAI savings are measured. For heating and cooling, the baseline captures what the building consumed before myCoreAI was activated. For setpoints, the baseline supply curve describes the pre-AI control relationship between outdoor temperature and supply temperature. ### BMS (Building Management System) The on-site automation system that reads sensors and actuates equipment in a building. myCoreAI connects to the BMS via an [edge](#myrspoven-edge) component to read sensor values and write [setpoints](#setpoint). ### CO₂ Carbon dioxide concentration, measured in ppm, used as an indoor air-quality observable. ### Comfort bounds The configured upper and lower limits within which myCoreAI may move indoor-climate or setpoint values. Comfort bounds protect occupant comfort and are never violated by the optimizer. See also [AI Freedom](#ai-freedom), which allows the optimizer to draw on learned bounds rather than fixed ones. ### Digital twin The customer-facing term for the physics-informed model of a building that myCoreAI uses to predict how supply-temperature changes propagate to indoor temperatures. Internally called the Xindy model; "digital twin" is the preferred customer-facing label. ### District cooling A centralized cooling distribution system in which chilled water is supplied from a remote plant and metered at the building. myCoreAI controls cooling-circuit setpoints and AHU cooling to reduce district-cooling consumption. ### District heating A centralized heat distribution system in which hot water is supplied from a remote plant and metered at the building. myCoreAI controls heating-circuit supply-temperature setpoints to reduce district-heating consumption. ### Draught control A myCoreAI feature that raises the lower bound on heating-circuit supply temperatures during cold-weather office hours (outdoor temperature below 5 °C, 07:00–17:00), offsetting cold downdraughts (Swedish: kallras) near windows and facades. ### Edge See [Myrspoven edge](#myrspoven-edge). ### ENTSO-E spot price The day-ahead electricity price published by the European Network of Transmission System Operators for Electricity. Used by [myLoadshift](#myloadshift) to shift heating and cooling load away from high-price periods. ### Golden Report Myrspoven's recurring PDF performance report delivered to customers. Covers energy savings per source (district heating, district cooling, electricity), indoor-climate compliance, AI uptime, and AI insights. ### Groupings A myCoreAI mechanism that controls indoor climate by sensor group rather than by individual sensor: it holds the group average temperature inside a band defined by the averaged per-sensor bounds, acting only when the group as a whole drifts outside it. This stabilizes control by preventing a single outlier sensor from dominating. See also [comfort bounds](#comfort-bounds). ### Guardrails Hard absolute limits on setpoint values that myCoreAI never crosses, regardless of penalty configuration or AI Freedom settings. Guardrails include crash-protection limits and rate-of-change constraints. Distinct from [comfort bounds](#comfort-bounds), which are softer configured limits the optimizer typically respects. ### HDD (Heating Degree Days) A climate-normalization metric equal to the sum of degrees by which daily mean outdoor temperature falls below a base temperature. Used in [climate-compensated reporting](/evaluation-and-reporting/climate-compensated) to remove weather effects from energy savings calculations. ### Indoor climate baseline The per-building historical record of indoor temperatures and other comfort observables from which myCoreAI derives learned reference limits. When [AI Freedom](#ai-freedom) is active, the optimizer may use these learned limits rather than the fixed configured [comfort bounds](#comfort-bounds). ### Mixed circuit control A myCoreAI control mode for HVAC circuits that serve both heating and cooling (i.e. circuits where the supply temperature can be above or below the ambient depending on season). ### MyCap A myCoreAI feature that enforces an energy-consumption or power-demand cap for a building, limiting the optimizer's actions to prevent the building from exceeding a contracted threshold. Referred to in customer-facing prose as "energy cap". ### myCoreAI Myrspoven's AI optimization engine. myCoreAI runs in the cloud, receives sensor readings from a building via the [Myrspoven edge](#myrspoven-edge), predicts indoor-climate responses using a [digital twin](#digital-twin), and writes [setpoints](#setpoint) back to the [BMS](#bms-building-management-system). ### myLoadshift A myCoreAI feature that shifts heating and cooling load in time by pre-heating or pre-cooling a building during low-price or low-tariff periods, and reducing load during expensive periods. Draws on [ENTSO-E spot prices](#entso-e-spot-price) or a dynamic district-heating tariff signal. ### myPortal The customer-facing web application where building owners and facility managers monitor myCoreAI performance, review setpoint trends, check indoor-climate compliance, and upload energy data. ### Myrspoven edge The on-premise software component installed at a building that polls the [BMS](#bms-building-management-system), forwards sensor readings to Myrspoven's cloud, and applies setpoint writes received from [myCoreAI](#mycoreai). ### Optimization horizon The look-ahead window over which myCoreAI solves its optimization problem. Typically 72 hours. ### Optimizer The component of myCoreAI that solves the energy-comfort trade-off at each run. ### RMSE (Root Mean Square Error) A model-accuracy metric myCoreAI uses to assess how well the [digital twin](#digital-twin) predicts indoor temperatures. If RMSE exceeds a threshold (nominally 1.7 for Schneider EBO sites), myCoreAI may fall back to safe mode and suspend setpoint writes. ### Safe mode The fallback operating state myCoreAI enters when it cannot reliably predict building behavior (e.g. because RMSE exceeds the threshold, sensor data is stale, or BMS writes are failing). In safe mode, myCoreAI suspends setpoint writes; the BMS reverts to its native control strategy. ### Setpoint A target value that myCoreAI writes to the BMS — for example, a heating-circuit supply temperature or AHU supply-air temperature. ### Signal A named data stream from or to the BMS, identified by a signal key. Signals can be readable (sensor readings) or writable (setpoints). The set of signals for a building is captured in a signal list produced during technical survey. ### Supply curve The pre-AI control relationship between outdoor temperature and heating-circuit supply temperature for a building. myCoreAI's [baseline](#baseline) is derived from the supply curve; [adaptive min/max](#adaptive-minmax) clips the optimizer's range relative to it. ### Tariff signal A dynamic pricing signal — either an ENTSO-E spot-electricity price or a time-varying district-heating tariff — that [myLoadshift](#myloadshift) uses to shift building load in time. ### Uptime The fraction of eligible optimization-run slots during a reporting period in which myCoreAI was actively writing setpoints (i.e. not in [safe mode](#safe-mode) and not manually paused). ### Xindy model The internal name for Myrspoven's physics-informed building model. Customer-facing documentation uses the term [digital twin](#digital-twin) instead. # FAQ Common questions from customers, partners, and system integrators. If you don't see your question here, talk to your Myrspoven representative or open a support case. ### Getting started
What is myCoreAI? myCoreAI is software that continuously reads data from your building — the control system (BMS), indoor sensors, and the external factors that affect the building, such as outdoor temperature and weather. It uses that data to make small, continuous adjustments to the systems that drive temperature and comfort (supply temperatures, pressures, flows, and so on), steering them toward more efficient operation. The goal isn't to replace your existing systems but to run them better: minimizing energy use by exploiting the building's thermal inertia, smoothing demand to avoid cost peaks, and pre-heating or pre-cooling ahead of need. The control happens automatically, within a framework agreed with you, and gets better the longer it runs. You decide which signals myCoreAI is allowed to write to.
Does myCoreAI replace our BMS? No. Think of myCoreAI as an application running alongside your building's control system — one focused on energy optimization. All the existing logic and frameworks in your BMS stay exactly as they are. myCoreAI works on top of them, and if it's ever disconnected, control simply returns to your BMS running on its own logic, as before.
Which BMS systems are supported? Support isn't about brand or region — it's about whether the BMS can meet a few technical requirements. myCoreAI needs to be able to read the relevant signals from the system, write setpoints back to the signals you want it to control, and reach the system over a supported communication protocol (directly or via Myrspoven edge). A BMS qualifies when those things are possible; where they aren't yet, Myrspoven edge can often bridge the gap. The full integration requirements are covered under *Data and integrations*.
How long does onboarding take? Onboarding runs in three stages: 1. **Read integration** — we connect and start reading data. This is the simple step; it mainly requires that we're granted access. 2. **Write integration** — we configure which signals myCoreAI will control and set up write-access to them. This is more involved: it requires agreeing which signals to steer and having the right access to change setpoint values on them. 3. **Safety logic** — fallback behavior, baselines, and the guardrails that keep the building safe if anything goes wrong. How long each stage takes depends mostly on data access and how quickly write-access can be granted, but a building typically goes from kickoff to writing setpoints in weeks, not months.
How quickly will I see savings? It helps to separate two things. **Performance** — how myCoreAI's control compares against the baseline (how the building would have run without it) — can be shown within a few weeks. As long as we've received the right signal values from you, we can report the day-by-day difference between AI optimization and baseline on an ongoing basis. **Measurable energy savings** — savings expressed in delivered energy — depend on having energy data, and the right energy data. Where that's in place, the evaluation runs continuously rather than waiting for a full season.
### Accounts and access
I can't log in, or my verification code isn't working. myPortal uses single sign-on via Keycloak. Your one-time code comes from an **authenticator app** set up on your account — not from an email, and there is currently no email-code or magic-link option. Two things to check: * **Have you signed in since the Keycloak migration?** You need to sign in once afterwards so Myrspoven can apply the correct access rights to your account. * If your authenticator isn't set up yet, you've lost access to it, or sign-in still fails, contact your Myrspoven representative to restore access.
How do we add, remove, or change users? User accounts and permissions are managed by Myrspoven — and, where enabled, by partner superusers for their own company. Request changes through your Myrspoven contact, giving the person's name, email, and which buildings or portfolio they need. A single account can be granted access across multiple companies or portfolios where the contract allows.
Why do times in myPortal look shifted by a few hours? By default myPortal displays times in UTC, so locally set schedules can appear offset. Set your preferred display timezone in myPortal and times — including comfort schedules — will show in your local time.
### Data and integrations
What data does myCoreAI need? To assess and onboard a building, we need to understand both what's in it and how we can reach it. About the building's systems: * which systems exist, and whether they can be controlled * whether those systems already carry other control logic * whether they're standalone or sit within the BMS About sensors: * whether the building has physical sensors (duct sensors alone aren't sufficient), how well distributed they are, and what they measure * whether those sensors are available in the control system at a usable data resolution About access: * the communication protocol the building uses * how we can reach it remotely (for example, via VPN) This is the information that actually determines whether and how myCoreAI can run — more than a generic "minimum data" list.
What data resolution is required? It depends on the type of data, so it's clearest to take them one at a time: * **Sensor data** — ideally around 15-minute resolution or finer. * **Signal data** — read directly, in real time. * **Energy (meter) data** — See [Energy Data](/integrations/overview/energy-data#granularity-levels). As a rule, give us the highest resolution you can: finer data unlocks better optimization and more precise reporting.
What if our energy meters aren't on the BMS? Energy data can reach myCoreAI three ways: imported (uploaded manually), fetched directly, or pulled via a third-party provider (Mestro and Metry in Sweden). Connecting meters to the BMS is the simplest path where it's possible. Whichever route you use, the resolution of the energy data matters — higher resolution gives more precise, climate-compensated savings reporting.
### AI behavior
What happens if myCoreAI makes a bad decision? myCoreAI never optimizes toward an extreme. It optimizes toward the lowest energy use that still keeps the building inside the comfort bounds you've agreed — so it won't drive the building to the coldest (or warmest) state to save energy. Comfort is a hard constraint, not something it trades away. The safeguards that protect your tenants are set during startup: comfort bounds per building, bounds on each controlled signal, and fallback behavior if anything goes wrong. If a building does drift outside its comfort bounds, myCoreAI can be paused for that building while the cause — usually a comfort bound, a sensor, or a configuration detail — is investigated.
Can we override myCoreAI? Yes, myCoreAI doesn't take over your building. You can influence control at any time: through myPortal for the systems myCoreAI controls, and in your own BMS for everything else, exactly as before. You can step in even while myCoreAI is actively optimizing. You're never locked out of your own building.
What if we disagree with a setpoint myCoreAI has written? On a signal myCoreAI controls, a one-off change in the BMS won't hold because myCoreAI re-applies its own setpoint on its next control cycle. To make a lasting change you have two routes: pause myCoreAI's control of that system, or adjust its configuration so it optimizes toward what you want. Let your Myrspoven representative know what's wrong. Persistent disagreements usually trace back to a comfort bound, an occupancy assumption, or a sensor. The fix is to retune the configuration rather than fight individual setpoints.
What does myCoreAI actually control? Typically: heating circuit supply temperatures, air handling unit supply temperature and fan pressure, cooling setpoints where applicable, and zone-level terminal units where the building has them. The exact list depends on what your BMS exposes and what's been configured during startup.
Does myCoreAI detect broken sensors or schedule maintenance? A faulty sensor — one that has drifted, is stuck, or is reporting nonsense — is not something myCoreAI repairs. What myCoreAI does is optimize a working system. Because its decisions are only as good as the data it reads, keeping sensors healthy is what lets the optimization stay accurate meaning unreliable input is a signal for maintenance, handled the same way as any other building fault.
### Reporting and savings
How are savings calculated? Savings are measured against a baseline — a model of how the building would have used energy without myCoreAI — adjusted for weather and other variables. Two timescales matter. Performance (myCoreAI versus baseline, day by day) can be shown within weeks, as soon as we have the right signal values. Energy savings expressed in delivered energy depend on having good energy data; where it's in place, that evaluation runs continuously rather than waiting for a full heating or cooling season. Reporting precision improves with the resolution of your energy data.
Where do I see savings and current operation? In myPortal. You'll find dashboards for energy use, indoor climate, savings, and historical trends, plus a live view of current setpoints and what myCoreAI is doing right now. Performance against baseline is visible on an ongoing basis — you don't have to wait for a full season to see how the building is tracking.
Can we get raw data out for our own reporting? Yes. Your data is yours, and it's always available to you. You can pull it for your own reporting and, where your systems support it, connect myCoreAI to your energy or follow-up systems through our integration APIs. See [Integrations](/integrations/overview) for what's possible; the exact exports available depend on your setup.
### Privacy and security
How is our data handled? Your data is always yours. We process it only to operate and improve the service for your buildings, and it's encrypted both in transit and at rest.
Where is our data stored? Your data is stored in EU-region data centers.
How is our data kept confidential? All information for a given building or portfolio is treated as confidential. We don't share data between buildings or between portfolios. Myrspoven is ISO 27001 certified, and access is logged and scoped to the buildings a staff member supports.
Where can I read more about Myrspoven's security posture? See [trust.myrspoven.com](https://trust.myrspoven.com/) for the current security overview.
### Billing and contracts
How is myCoreAI priced? Pricing depends on building size, scope, and which optional features are enabled. Talk to your Myrspoven representative for a quote.
Which features are included in our contract? It depends on your plan. The core optimization loop — myCoreAI HVAC optimization, indoor climate monitoring, energy reporting, and continuous model retraining — is always on. Beyond that, capabilities differ between Subscription and Enterprise: | Feature / Service | Subscription | Enterprise | | ---------------------------------------- | ------------ | ---------- | | HVAC AI optimization (myCoreAI) | ✓ | ✓ | | AI Dashboard & portfolio insights | Limited | ✓ | | Load shifting & spot-price optimization | – | ✓ | | Predictive maintenance | – | ✓ | | Power limiting & tariffs | – | ✓ | | Unlimited scale-up (fixed license) | – | ✓ | | Open APIs & SDK – any vendor | – | ✓ | | Portfolio benchmarking & CAPEX guidance | – | ✓ | | Standardized data model | – | ✓ | | Innovationsvalvet – roadmap influence | – | ✓ | | Innovationsvalvet – network days (2+/yr) | – | ✓ | | Innovationsvalvet – MVP & R\&D projects | – | ✓ | | Innovationsvalvet – shared codebase | – | ✓ | Check with your Myrspoven representative if you're not sure what's enabled for your buildings.
# Overview When something looks wrong — a sensor reads cold, energy data stops flowing, or myCoreAI seems inactive — start here. This chapter collects the questions we encounter most often, the symptom-driven fixes that resolve the majority of cases, and the right way to escalate when they don't. ## Where to start * [**FAQ**](/faq) — short answers to the questions customers and partners ask most often: how quickly savings appear, what happens if myCoreAI goes offline, who can write setpoints, what data is needed. * [**Common issues**](/troubleshooting/common-issues) — symptom-based troubleshooting for the things that go wrong in day-to-day operation. Each entry covers what you see, the likely cause, what to try, and when to escalate. ## Before you raise a case {% stepper %} {% step %} ## Check the sensor and signal level first Open the sensor map in myPortal and look for sensors flagged outside their recommended range. A single misplaced sensor (direct sun, draft, broken hardware) can impact the whole building's behavior. Go ahead and adjust the sensor's Min/Max-range to match physical reality, extend the range if you wish to enhance savings potential, or disable it if it isn't representative. {% endstep %} {% step %} ## Confirm data is still flowing If a sensor, system signal or meter has gone silent, myCoreAI can't act on it. Energy data in particular has its own integration path — see [Energy data](/integrations/overview/energy-data) if values look stale. {% endstep %} {% step %} ## Confirm myCoreAI is active for the building myCoreAI can be deactivated for a specific building (intentionally, while a case is open) and the optimizer can deactivate automatically if sensor deviation crosses the building's RMSE threshold. Both are recoverable, but the recovery steps differ — common issues walks through both. {% endstep %} {% step %} ## Check the BMS connection If your BMS integration drops, myCoreAI can't read current values or write setpoints. The building keeps running on its own BMS logic in the meantime. {% endstep %} {% endstepper %} If you've worked through these and the problem persists, raise a support case. ## How to raise a support case Contact your Myrspoven representative through the channel agreed at onboarding or send an email to . In your ticket, please include: * The building (or buildings) affected. * A short description of what you're seeing. * The time window when the issue started — date and approximate time. * Screenshots or links to the affected myPortal view, if relevant. If indoor comfort is significantly affected, please say so when you raise the case so we can prioritize accordingly. ### What happens next 1. We acknowledge the case and confirm we're investigating. 2. We diagnose the cause — usually a mix of checking the BMS connection, recent setpoint writes, and sensor data quality. 3. We agree on a fix or workaround with you. If the fix needs work on your side (for example, a BMS change), we explain what's required. 4. We close the case once you've confirmed it's resolved. ## A note on scope The pages in this chapter are platform-wide — they apply regardless of which BMS you run. BMS-specific diagnostic procedures (for example, reading process status inside Schneider EBO) live with the integration documentation for that platform. # Common issues This page covers the symptoms you're most likely to run into on a myCoreAI-optimized building, and what to check before raising a support case. Work top to bottom — most issues are caught in the first one or two checks. If a symptom matches but the suggested checks don't resolve it, raise a support case with the details listed at the end of this page. ## Data isn't flowing from the BMS Symptoms: sensor readings in myPortal are flat, missing, or stuck on an old value. The blueprint view shows sensors in a disabled or stale state. Check: * **Connection status.** Confirm the BMS-side integration is online. A dropped connection between the BMS and myCoreAI is the single most common cause of missing data. Restoring the connection usually clears the symptom within a few minutes. myCoreAI reads every minute (at most every five minutes); reliable optimization needs at least one data point every five minutes. * **The signal at source.** Open the value in the BMS and confirm it's updating there. If the BMS itself shows a stale value, the issue is upstream of myCoreAI — check the sensor, the controller, or the BMS logging configuration. ## Setpoint writes aren't reaching the BMS Symptoms: myCoreAI shows an active setpoint in myPortal, but the BMS is acting on the original (non-AI) value. The building behaves as if optimization is off even though it's enabled. Check: * **myCoreAI is actually running** for this building in myPortal. A paused or disabled building won't write. * **The write path is enabled** end to end. Most BMS integrations have a separate read path and write path; it's possible to have reads working while writes are disabled. * **The most recent write succeeded.** Each integration exposes a write status indicator. A short lag — up to about 15 minutes — between myCoreAI computing a value and the BMS receiving it is normal and resolves itself. A persistent failure is not. * **Signal mapping.** If writes are reaching the BMS but landing on the wrong point, the binding between myCoreAI's output signal and the BMS point is wrong. Compare each value myCoreAI is writing against the value visible in the BMS image — they must match. ## Signal mismatch between myCoreAI and the BMS Symptoms: a value visible in myPortal doesn't agree with the same value in the BMS. Or a signal you expect to see in myPortal isn't there at all. Most signal mismatches come from one of three things: 1. **Wrong mapping.** The signal key points to the wrong BMS point. The fix is on the integration side — correct the key. 2. **Unit or scaling mismatch.** The value is technically flowing but interpreted differently on each side (Celsius vs. Kelvin, Pa vs. kPa, percent vs. fraction). 3. **A logging point being read instead of the live point.** Some BMS integrations expose both; myCoreAI needs the live signal for control and the logging point for historical analysis. Mixing them up causes lag or stuck values. A signal that's missing entirely is usually a mapping that was never created, or a tag that's been disabled on the BMS side. ## Indoor climate isn't hitting target Symptoms: rooms are persistently too warm or too cold. Sensors in the blueprint view show outside the recommended range — too hot (red/orange) or too cold (blue/light blue). Check: * **Bottleneck sensors first.** The blueprint view's bottleneck list shows which sensors are pulling the building out of range. For each: * **Adjust Min/Max** to match the actual physical conditions in that space. * **Disable the sensor** if it's poorly placed — direct sunlight, draft, near a heat source — and not representative of the room. * **Whole building vs. single outlier.** If the whole building is too cold, raise the Max on all relevant sensors so myCoreAI adjusts uniformly. If only one sensor is the outlier, lower its Min so it stops dominating myCoreAI's behavior. * **Environmental causes** before tuning. Drafts, poor insulation, or sun load on a sensor will all produce readings that look like a control problem but aren't. If individual sensor tuning isn't enough, you can tighten the building's Adaptive Min/Max bounds, which limits how far myCoreAI is allowed to move from the original setpoint. Treat this as a temporary measure — myCoreAI performs best when it's free to move without artificial restrictions. Widen the bounds again once the underlying issue is fixed. ## Optimizer has fallen back to safe mode Symptoms: myCoreAI was running normally, then stopped writing optimized values. The building reverts to its original setpoints. myCoreAI monitors how far each sensor is deviating from expected behavior (the building's RMSE factor). When deviation crosses a threshold — **1.7** by default, adjustable per building — the optimizer deactivates automatically and the building enters safe mode. This is a safety mechanism, not a bug. It prevents myCoreAI from acting on bad data. To recover: 1. Identify the problematic sensors from the bottleneck list. 2. Resolve the deviation at the source — recalibrate, reposition, replace the sensor, or correct an over-tight setpoint range. 3. Clear safe mode for the building. The optimizer will not resume until the underlying sensor issues are fixed. Clearing safe mode alone is not enough. ## A building isn't training or optimizing Symptoms: a building's training doesn't complete (the training status stays red, or the queue doesn't move), or the optimizer stops with an error about faulty, frozen, or missing data. myCoreAI needs recent, changing sensor data to train its digital twin and run the optimizer. The usual causes are: * **A frozen or stale signal.** A sensor — or a circuit in pump-stop — reports the same value, or no value, for an extended period. Data validation flags this as faulty and removes it. * **Too much faulty or missing data.** When many signals are faulty or absent across the training window, too little usable data remains, and validation can drop most or all of it. * **A recently added signal with little history**, which can cause rows to be dropped until it has built up enough data. Check at the [sensor and signal level](/troubleshooting/overview) first, confirm data is still flowing, and clear or disable any frozen or faulty sensors. If the building was recently retrained but still won't optimize — or validation reports it dropped most of the data — raise a support case. ## Taking a single circuit out of AI control If you need one circuit to revert to its original (non-AI) setpoint without stopping optimization on the whole building, you can deactivate that single circuit from its control panel in myPortal. The rest of the building continues to be optimized. This is the right answer when one loop is misbehaving and you want to investigate without disrupting everything else. ## When to raise a support case If you've worked through the checks above and the symptom persists, raise a support case. Include: * The building or buildings affected. * The symptom — what you're seeing and what you expected. * The approximate time the issue started. * Which check above you reached, and what you found. * Screenshots or links to the affected myPortal view, if relevant. For urgent issues — for example, indoor comfort is significantly affected — say so explicitly. If you want myCoreAI paused for a building while the case is open, ask. Pausing stops setpoint writes but leaves data collection and monitoring intact. # myPortal myPortal is the customer-facing web application for monitoring building performance under myCoreAI. It surfaces energy use, indoor climate, optimization activity, and reported savings across a single building or an entire portfolio. ## Audiences | Role | Primary use | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Building owners and asset managers | Portfolio-level view of energy, savings, and indoor conditions | | Technical operations | Per-building drill-down into HVAC systems and the setpoints myCoreAI writes to the Building Management System (BMS) | | Sustainability and reporting staff | Energy and savings exports for internal or external reporting, including alignment with ISO 50001 reporting cycles | Access is per user. Permissions are managed by Myrspoven. ## Views * **Portfolio dashboard** — recent energy use, indoor climate status, and flagged issues across accessible buildings. * **Building view** — drill-down into a single building, its systems (heating, ventilation, cooling), and individual signals. * **Graphs and history** — time-series for energy consumption, indoor temperature, and tracked signals. Date range and resolution are adjustable. * **Reports** — measured energy use versus baseline, with estimated savings over a selected window. Reporting fidelity depends on energy-data resolution — see [Energy data](/integrations/overview/energy-data). * **Alerts and flags** — surfaced in-app when myCoreAI or the data pipeline detects a missing signal, stuck sensor, or similar fault. ## Capabilities * **Monitor** — current and historical energy use, indoor climate, and the setpoints myCoreAI is sending to the BMS. * **Compare** — measured consumption against agreed baselines over arbitrary windows. * **Upload data** — manual energy-data upload where automated transfer is not available. See [Energy data — Manual upload](/integrations/overview/energy-data/manual-upload). * **Configure (limited)** — selected settings such as comfort bounds and occupancy schedules, where the contract permits. Deeper configuration changes are made by Myrspoven. {% file src="/files/BUzps7kGQEBt8sgGD6ny" %} ## Access Browser-based; no installation. Customers receive an invitation email with a sign-in link at onboarding. Additional users are requested through Myrspoven. {% file src="/files/AZO2cb8yRIwxmasXbb1w" %} ## Browser support Recent versions of Chrome, Edge, Firefox, and Safari. Mobile browsers cover most read-only views; configuration tasks require desktop. # BackOffice BackOffice is Myrspoven's internal configuration and monitoring tool. Operations staff use it to register signals, set the bounds within which myCoreAI operates, and manage the processes that drive data collection and control. Customers work in [myPortal](/customer-interfaces/myportal); integration partners have self-service access to BackOffice for onboarding and configuration tasks. ## Scope * **Building onboarding.** Registers signals from the Building Management System (BMS) integration, sets optimizer bounds and comfort bounds, and configures the writable setpoints myCoreAI will steer. * **Feature configuration.** Enables and tunes myCoreAI add-ons per building — energy cap, myLoadshift, and comfort-driven adaptive min/max limits. * **Process management.** Creates and toggles the recurring processes behind data collection and control: BMS reads, weather reads, optimizer runs, and setpoint writes. * **Curves and transformations.** Supply curves define the operating envelope available to myCoreAI; transformation tables link related signals — for example, a supply-air temperature reading with its corresponding setpoint. * **Support diagnosis.** Used by Myrspoven staff to inspect a building's configuration and recent optimizer runs when a case is raised. ## Customer-visible effects Most BackOffice activity is invisible from the outside. A subset of changes surfaces in myPortal: * Updated comfort bounds or optimizer bounds appear in the relevant myPortal views once applied. * Newly added signals or meters show up in reporting and component views. * Feature toggles — enabling myLoadshift, for instance — reveal the corresponding myPortal section. Configuration changes are requested through the Myrspoven representative; customers do not action them directly. ## Integration partners Partner-specific onboarding steps — discovery file, transformation table, supply curves, read-process activation — are covered in the onboarding material shared by the Myrspoven contact. They sit outside the public documentation because the workflow depends on the BMS vendor and integration method. ## Access Access is restricted to Myrspoven staff and integration partners with self-service accounts. # Overview myCoreAI runs a continuous optimization loop on every building: it trains a model from the building's own data, predicts how setpoint changes affect indoor climate and energy use, and writes setpoints to the Building Management System (BMS) that reduce consumption while staying within agreed comfort bounds. The pages in this chapter document the individual features that shape that loop. Which ones are active depends on contract scope and on what the BMS exposes for reading and writing. **Asset and facility management:** myCoreAI lowers heating and electricity consumption without capital expenditure, while keeping comfort within contractual limits — improving operating costs and supporting energy management obligations under ISO 50001 and EPBD. **Technical operations:** myCoreAI provides a transparent optimization layer over the existing BMS. Setpoint writes, comfort bounds, and the energy/comfort trade-off are all configurable per building and per zone. **Integrators:** myCoreAI consumes BMS datapoints over the standard integrations (BACnet, Modbus, vendor APIs) and writes back through the same channels. No parallel control system is introduced. ## Core behavior The optimization loop — model training, comfort-vs-energy trade-off, setpoint writing — is always on for any building under myCoreAI control. The features below tune or extend it. 1. **Model.** myCoreAI trains a building-specific model from historical sensor and setpoint data. 2. **Predict.** It forecasts indoor climate and energy response to candidate setpoint moves over the optimization horizon. 3. **Decide.** It selects the operating point that minimizes energy or cost under the active comfort bounds. 4. **Write.** It pushes the resulting setpoints to the BMS at the configured cadence. ## Features * [**Adaptive min/max**](/ai-features/adaptive-min-max) — Heating Circuit setpoints freedom around the baseline. * [**AI Freedom**](/ai-features/ai-freedom) — Setting that lets the myCoreAI get full freedom to ensure energy savings. * [**Comfort schedule**](/ai-features/comfort-schedule) — Relaxes comfort bounds and ventilation during scheduled or learned unoccupied hours. * [**AI Penalty**](/ai-features/ai-penalty) — The trade-off function that balances energy use against comfort deviations. * [**Draught control**](/ai-features/draught-control) — Prevents Heating Circuit conditions that cause perceived draught in occupied zones. * [**Groupings**](/ai-features/groupings) — Logical grouping of sensors for control and reporting. * [**Indoor climate baseline**](/ai-features/indoor-climate-baseline) — Reference comfort bounds that myCoreAI will determine from the historical data. * [**Loadshift**](/ai-features/loadshift) — myLoadshift shifts energy use across the day in response to spot electricity prices, while keeping comfort. * [**Mixed circuit control**](/ai-features/mixed-circuit-control) — Control logic for buildings where heating and cooling share circuits or sources. # Indoor climate baseline The indoor climate baseline lets myCoreAI factor a building's historical indoor climate into how aggressively it optimizes, rather than relying only on configured temperature limits. It is one of the mechanisms gated by AI Freedom. The intent: give myCoreAI more room to save energy where the building has historically tolerated wider comfort bounds, without ever operating outside conditions it has actually run in. ## How the baseline is calculated myCoreAI builds the baseline from **reference data** — historical indoor-temperature data from periods when myCoreAI was not in control. From that data it computes **reference limits**: a per-sensor minimum and maximum that approximate the building's historical comfort bounds. * Applies only to **indoor temperature sensors**. CO₂, supply temperatures, and energy meters are not affected. * Outliers are filtered before the limits are computed; a single cold or warm hour does not skew the result. * Requires sufficient seasonal coverage. If the reference period lacks enough winter and summer data, the baseline cannot be produced and myCoreAI falls back to the configured limits. ## How the setting behaves The baseline is controlled together with AI Freedom and is effectively binary: | AI Freedom | Baseline | | ---------- | ---------------------------------------------------- | | 0 | Off — only configured limits are used. | | > 0 | On — any value above zero applies the full baseline. | When active, myCoreAI compares two candidate sets of limits per sensor: 1. The **configured limits** set in the platform. 2. The **reference limits** derived from history. For the lower bound, myCoreAI picks whichever set has the **lower average** during office hours — the one that gives more room to push temperatures down. For the upper bound, it picks whichever has the **higher average**. If the reference set is not the outermost one, myCoreAI shifts the reference limits so their average matches the configured average; the shape of the reference curve is preserved, but the level aligns with what was configured. The baseline only ever **widens** the comfort bounds. It never tightens limits beyond what was configured. ## Office hours myCoreAI separates office hours from the rest of the week, because tolerated comfort bounds often differ between workday and nights/weekends. Office hours are fixed for all buildings at **07:00–18:00, Monday to Friday**. Each reference limit therefore has one value for office hours and another for non-office hours. In a building with a consistent climate, the two values are nearly identical. In a building with strong day/night or weekday/weekend patterns, they diverge more. ## Safety floor for historically warm buildings If a building has historically operated warm but is configured with relatively cold lower limits, applying the reference minimum verbatim could push the building colder than it has ever run. A safety rule prevents this: > If the average reference minimum is above 20.7 °C but the configured minimum is below 20.7 °C, myCoreAI adjusts the chosen limits so their average lands at 20.7 °C. ## Worked example An office building has been configured with a lower indoor temperature limit of 20.0 °C, but two heating seasons of reference data show the building has never actually operated below 21.4 °C during office hours. With AI Freedom set above zero, myCoreAI selects the reference minimum as the outermost lower bound, then applies the 20.7 °C safety floor: the chosen lower limit is shifted so its office-hours average is 20.7 °C instead of 20.0 °C. The upper bound is left at the configured value, since the reference maximum sits inside it. Result: myCoreAI gains a realistic lower bound to work against during night setback and morning ramp-up, without ever driving the building below temperatures it has historically held. ## What this means in practice * Configured limits remain in control. The baseline only widens the comfort bounds. * Buildings with rich historical data get more flexibility, because more evidence exists for what the building has tolerated. * Buildings with thin or unrepresentative history fall back to configured limits and behave conservatively. * Recently onboarded buildings see little or no baseline effect until enough off-period data accumulates across seasons. # Adaptive min/max Adaptive min/max is a tuning lever in myCoreAI to restrict how far supply-temperature setpoints on heating circuits may deviate from the baseline supply curve. Two values define the band: one above the baseline, one below, each expressed as a fraction of the signal's configured full range. The signal's original min and max are always respected — adaptive min/max can only narrow the operating range, never widen it. ## How it works The baseline is the expected supply temperature for current conditions, derived from the building's supply curve. myCoreAI applies adaptive min/max as a band around it: $$ \text{upper bound} = \text{baseline} + \text{adaptive\_max} \times (\text{max} - \text{min}) $$ $$ \text{lower bound} = \text{baseline} - \text{adaptive\_min} \times (\text{max} - \text{min}) $$ Where `min` and `max` are the signal's configured boundaries. * `adaptive_max = 0` — myCoreAI cannot push the setpoint above the baseline. * `adaptive_max = 100` — myCoreAI may reach the configured maximum. * `adaptive_min` behaves symmetrically on the lower side. A small margin is always preserved between the lower and upper bound to avoid numerical issues during optimization. ### Example | Setting | Effect | | ------------------- | --------------------------------------------------------- | | `adaptive_max = 20` | Setpoint may rise up to 20% of full range above baseline. | | `adaptive_min = 15` | Setpoint may fall up to 15% of full range below baseline. | A district-heated office with a supply signal configured from 25 °C to 65 °C and `adaptive_max = 20`, `adaptive_min = 15` gives myCoreAI eight degrees of headroom above the baseline and six degrees below. ## Choosing values If there is no specific reason, keep both values at `100`. This gives other energy-saving features room to work. A restrictive Adaptive Min can, for example, block [Comfort schedule](/ai-features/comfort-schedule) and [Loadshift](/ai-features/loadshift). ## Negative values Negative values flip a boundary to the opposite side of the baseline. A negative `adaptive_min` places the lower boundary *above* the baseline, forcing myCoreAI to heat more than the baseline curve suggests. This is occasionally useful for short-term comfort recovery or diagnostic tests, but it works directly against energy savings. Negative values must be reset once no longer needed — a negative `adaptive_min` left in place drives extra energy use indefinitely. ## Where it applies Adaptive min/max applies to heating-circuit supply-temperature signals. It does not apply to air handling unit (AHU) supply temperatures, indoor temperature limits, or ventilation pressure. # AI Freedom AI Freedom is an umbrella setting in myCoreAI that lets the optimizer pursue energy savings more aggressively by relaxing how strictly configured comfort bounds and schedules are enforced. Enabling it activates two underlying behaviors together: learned reference comfort bounds, and a guaranteed setback during unoccupied hours. ## What it does * **Indoor climate baseline.** myCoreAI replaces static min/max comfort bounds with learned reference bounds derived from the building's actual performance. Office hours retain bounds close to the configured limits; non-office hours widen them further. See [Indoor climate baseline](/ai-features/indoor-climate-baseline). * [**Comfort schedule**](/ai-features/comfort-schedule). AI Freedom enables Automatic Comfort Schedule (ACS) with a guaranteed setback. During unoccupied periods, myCoreAI widens comfort bounds by at least 0.5 °C. ## How it works | Value | Effect | | ----- | ------------------------------------------------------------- | | Off | myCoreAI stays within configured static bounds and schedules. | | On | Both underlying behaviors activate together. | In customer-facing terms, treat AI Freedom as on/off: any value above zero activates it fully, with no partial levels. Each underlying feature can also be enabled independently of AI Freedom. The umbrella turns both on at once. ## Scope AI Freedom relies on enough history for the learned reference bounds to be meaningful. Reasonable to enable when: * The building has been monitored for several months and behavior is stable. * Occupancy patterns are predictable enough for a learned schedule to be trustworthy. * Energy savings are prioritized over the tightest possible comfort bounds. Reasonable to leave off (or turn off) when: * The building is new to myCoreAI or has just been renovated. * Comfort complaints are still being root-caused. * The building is in a commissioning or validation period that requires predictable, configuration-driven behavior. ## Worked example An office building with stable occupancy enables AI Freedom after six months of monitoring. myCoreAI replaces the configured 21–23 °C comfort bounds with learned reference bounds: 21.2–22.8 °C during weekday office hours, and 19.5–24.5 °C overnight and weekends. During unoccupied periods, the guaranteed 0.5 °C setback ensures the optimizer can coast on stored thermal mass rather than holding daytime setpoints. Heating energy drops without daytime comfort complaints. ## Interaction with other settings AI Freedom changes which comfort bounds myCoreAI uses and guarantees a minimum unoccupied-hours setback. It does **not** override: * Hard guardrails and crash protections. * Maximum rate-of-change limits on heating circuits. * Other building-specific limits unrelated to comfort min/max. When a comfort complaint arrives with AI Freedom on, the first diagnostic step is to compare the learned reference bounds against the configured comfort bounds and check whether the learned bounds are wider than intended. # Comfort schedule How myCoreAI relaxes comfort requirements during unoccupied hours. Comfort schedule lets myCoreAI relax comfort requirements when a building is unoccupied. Holding office-hours comfort around the clock wastes energy on empty floors. Nights, weekends, and early mornings can run with wider temperature bounds and reduced ventilation without anyone noticing. It comes in two variants: a **manual** schedule configured per building, and **Automatic Comfort Schedule (ACS)** that learns occupancy from the building's own CO₂ sensors. They can also be combined. ACS applies its setbacks on top of whatever bounds the manual schedule has in force. ## Manual comfort schedule The manual variant is a weekly schedule of comfort bounds, configured per building in BackOffice. Operations defines time slots and the min/max bounds that apply in each. myCoreAI receives those bounds as time-varying limits and optimizes within them. The manual schedule is explicit and predictable. Bounds change exactly when the schedule says they do, every week. That is also its limit. It does not adapt to how the building is actually used. ## Automatic Comfort Schedule (ACS) ACS removes the guesswork. Instead of a configured schedule, myCoreAI infers occupancy from CO₂ sensor data. When people arrive, CO₂ rises. When they leave, it falls. From that pattern, myCoreAI builds a weekly occupancy schedule per air handling unit (AHU) at 15-minute resolution and applies setbacks during the hours it has learned are unoccupied. ### How occupancy is learned * myCoreAI analyzes roughly the last 90 days of CO₂ readings for the zones served by each AHU. * For each weekday pattern, it finds the morning CO₂ rise, typically 05:00–11:00, and the evening fall, typically 14:00–22:00. * It marks the time between those events as occupied and builds a weekly pattern per AHU. * Schedules are recomputed continuously, so usage changes work their way into the learned schedule within weeks. Different AHUs can get different schedules. A building where one AHU serves a 24/7 gym and another serves offices will not be treated as uniformly occupied. ### What changes during unoccupied hours Three setbacks are configured per building. Each is independent. | Setting | Applies to | Effect during unoccupied hours | | ------------------------- | --------------------------- | ------------------------------------------------------------------------- | | Indoor temperature offset | Indoor temperature bounds | Bounds widen by ±X °C. The building may drift further from target. | | Supply-air offset | AHU supply-air temperature | Setpoint may drop by up to X °C. | | Ventilation offset | AHU pressure/flow setpoints | Setpoint may drop by up to X%, never below 30% of the configured maximum. | A setting of `0` disables that setback. If all three are `0`, ACS still computes schedules but applies no changes. ### Fail-safes ACS only relaxes bounds when it is confident the building is empty. When in doubt, it assumes occupied. * If CO₂ data is missing, too short, or too flat to show a clear pattern, the schedule defaults to fully occupied. * A weekday pattern must show at least 4 occupied hours to be trusted. Otherwise that AHU falls back to fully occupied. * Ventilation never drops below 30% of the configured maximum, so baseline air exchange is always maintained. * Individual signals can be excluded from ACS. This is useful for zones that must hold conditions around the clock, such as server rooms or labs. {% hint style="info" %} The learned schedule follows day-of-week patterns only. Public holidays run on the schedule of their weekday, so a holiday Monday is treated as a normal Monday. {% endhint %} ## Interaction with other features * [**AI Freedom**](/ai-features/ai-freedom) enables ACS with a guaranteed setback. Comfort bounds widen by at least 0.5 °C during unoccupied hours, even if no indoor temperature offset is configured. * [**Adaptive min/max**](/ai-features/adaptive-min-max) can restrict how far heating-circuit supply temperatures may fall. Keep both values at `100` unless there is a specific reason not to. # AI penalty myCoreAI balances several competing goals on every optimization cycle — occupant comfort, equipment efficiency, and operating cost. Each undesirable outcome carries a penalty, and myCoreAI selects the candidate plan with the lowest total penalty over the optimization horizon. This page describes how those priorities are ordered. ## How the penalty system works On every cycle, myCoreAI evaluates many candidate setpoint plans across a 72-hour horizon, predicts the outcome of each against the building model, sums the penalties, and selects the lowest-cost plan. Only the first hour is dispatched to the Building Management System (BMS); the remaining horizon ensures the current decision leads to a coherent trajectory. Penalties are not equal in weight, and several are conditional on season, time of day, or occupancy. ## Priority 1 — Comfort Comfort penalties dominate. myCoreAI weights them far above any energy or cost term, so it accepts higher energy use rather than allow comfort to drift outside the comfort bounds. Comfort penalties cover: * **Indoor temperature** outside the comfort bounds * **CO₂ levels** above the configured limit * **Humidity** above the configured limit, where measured For buildings with sensor groupings configured, myCoreAI evaluates comfort per group (typically one group per heating or cooling circuit) rather than per individual sensor. ## Priority 2 — Air handling unit behavior For each air handling unit (AHU), myCoreAI chooses between heating, cooling, or ventilation-only based on outdoor temperature and season. | Season | AHU role | Penalty | | ---------- | ------------------------ | ------------------------------------------------------------------------------------- | | Winter | Heating via AHU | High — discouraged unless comfort requires it or **Heat with ventilation** is enabled | | Summer | Free cooling via AHU | Low — encouraged before mechanical cooling | | Year-round | Fan / pressure operation | Small constant — discourages unnecessary ventilation | ## Priority 3 — Heating source myCoreAI assigns a low penalty to the primary heating circuits (typically district heating via radiators) and a high penalty to AHU-based heating. This ranking produces the winter logic above. A smoothness term discourages rapid hour-to-hour changes in heating setpoints. The **Max change heating circuit** setting in AI settings caps how fast setpoints can move. ## Priority 4 — Cooling source Cooling sources carry light penalties, ordered by cost and environmental impact: free cooling via ventilation, then district cooling, then mechanical cooling. ## Energy price modulation When [myLoadshift](/ai-features/loadshift) is active, myCoreAI multiplies energy-related penalties by the time-varying spot price and shifts consumption toward cheaper hours. Comfort penalties are not price-modulated. ## Energy cap When energy cap is configured, an additional penalty activates as the predicted daily average approaches the cap. myCoreAI weights it heavily — the cap behaves as a near-hard constraint. ## Putting it together myCoreAI scores each candidate plan on: 1. Comfort penalties — high, usually zero when comfort is maintained 2. Equipment-use penalties — moderate, season- and temperature-dependent 3. Smoothness penalties — small, keep operation stable 4. Cost-related penalties — small, favor cheaper energy when other constraints are satisfied 5. Cap penalties — active only near the energy cap The lowest-total-cost plan is dispatched. ## Worked example A district-heated office on a mild February afternoon: outdoor temperature is 6 °C, indoor sensors sit mid-band, and the spot price drops sharply between 13:00 and 15:00. With myLoadshift active, myCoreAI lifts the radiator supply slightly during the cheap window to pre-charge the building mass, then lets it coast through the early evening price peak. Comfort penalties stay at zero throughout — the move is driven entirely by the cost term, bounded by the smoothness cap on the heating circuit. ## Interpreting unexpected behavior When setpoints look counterintuitive — radiator supply unchanged on a mild day, AHU running warmer than expected — a higher-priority penalty is typically active: a comfort sensor near its limit, the smoothness term preventing a fast drop, or the building approaching its energy cap. To bias myCoreAI toward more aggressive energy savings, adjust AI settings: widen the adaptive min/max, enable AI Freedom, or increase off-hours offsets. # Draught control Draught control is a myCoreAI feature that prevents perimeter discomfort from cold air falling along windows and façades — *kallras* in Swedish — during cold-weather office hours. myCoreAI raises the lower bound on heating-circuit supply temperatures so radiator water stays warm enough to offset the downdraught, even when room temperature is already on target. ## Trigger conditions myCoreAI activates draught control when both conditions hold: * **Time of day:** 07:00–17:00 (building local time) * **Outdoor temperature:** below 5 °C Outside these conditions, the bounds produced by other pipeline steps are left unchanged. ## Effect myCoreAI raises the lower bound of every heating-circuit supply-temperature setpoint by **15% of that signal's configured min–max range**. | Configured range | Lower-bound uplift | | ------------------ | ------------------ | | 15–70 °C (typical) | \~8 °C | The upper bound is untouched. myCoreAI can still push the setpoint higher when heat demand warrants it — only the floor moves up. ## Position in the bounds pipeline Draught control is one step in the sequence of bound adjustments myCoreAI applies before each optimization run. It only tightens the lower bound upward; it never widens it. If an earlier step has already pushed the lower bound above the draught-corrected level, draught control has no further effect at that timestep. ## Scope Draught control acts on heating-circuit supply temperatures only. myCoreAI does not modify the following signals through this feature: * Air-handling-unit supply-air setpoints * Zone-asset schedules * Indoor temperature targets configured per climate group # Groupings myCoreAI controls indoor climate by sensor group, not by individual sensor. Each building is partitioned into groups tied to the HVAC system that influences them, and myCoreAI holds the group average temperature inside a target band. Control is smoother and less reactive than tracking each sensor in isolation. ## How groupings work Each group exposes three quantities to myCoreAI: * A **group average** — the mean of all indoor temperature sensors in the group. * An **average minimum** and **average maximum** — the means of the per-sensor lower and upper bounds across the group. * A scope tied to a specific HVAC asset, so a group corresponds to a heating circuit, air handling unit (AHU), or zone asset rather than an arbitrary set of rooms. myCoreAI compares the group average against the average min and max, and acts only when the group as a whole drifts outside the band. Individual sensors can sit outside their own limits without triggering a control change, as long as the group mean stays inside. ## Why this improves stability * **Collective control.** Limits apply to the group mean, not to each sensor. myCoreAI reacts to building-wide trends rather than a single noisy reading. * **Resilience to outliers.** A single sensor has little weight in the average. A meaningful share of the group has to move before the mean shifts. * **Seasonal balance.** Because limits apply to the average: * In a **20–23 °C** winter range, up to roughly half the sensors can read below 20 °C while the group mean still sits in the band. * In a **21–24 °C** summer range, up to roughly half can read above 24 °C before cooling is increased. The result is fewer short-cycle reactions to local disturbances and a steadier control signal overall. ## Where the limits come from Per-sensor minimums and maximums feeding the group averages come from one of two sources: * **Comfort bounds**, when comfort bounds are set explicitly for the building. * **Reference data**, when [AI Freedom](/ai-features/ai-freedom) is enabled. Bounds are derived from historical sensor behavior. ## How groups are defined Groups are not a free-form tagging system. myCoreAI assigns each indoor sensor to the heating or cooling system that most influences it, based on the building's signal mapping: * Buildings with **zone assets** (per-zone heating or cooling units): each zone asset forms its own group. Remaining sensors are grouped under the heating circuits. * Buildings heated mainly through ventilation: sensors are grouped by **air handling unit**. * Otherwise: sensors are grouped by **heating circuit** for heating and by **cooling circuit** for cooling. A building can have both heating groups and cooling groups, and the two sets can overlap. Groups outside myCoreAI's control scope — for example, circuits that are not written to — are excluded from the comfort penalty. ## Worked example An office served by two heating circuits, one feeding the open-plan floors and one feeding a set of corner offices. The corner offices include a south-facing room that runs warm on sunny afternoons. Without groupings, the warm reading pulls myCoreAI toward reducing supply temperature, which under-heats the rest of the circuit. With groupings, the south-facing sensor is one input to the corner-office group mean; myCoreAI keeps the group average inside 20–23 °C and the open-plan circuit stays unaffected. The warm room is handled as a local disturbance rather than a circuit-wide signal. # Mixed circuit control A mixed circuit feeds both another downstream heating or cooling circuit *and* at least one air handling unit (AHU). Because the same circuit serves two loads with different temperature requirements, myCoreAI applies a dedicated control strategy so neither side is starved. ## Qualification myCoreAI treats a circuit as mixed when all three conditions hold: 1. A **reference formula** is defined for the circuit — a reference held in the circuit's metadata that couples it to the other systems it feeds. 2. A **supply curve** exists for that reference — the baseline temperature curve against outdoor conditions. 3. **Component connections** link the reference to at least one downstream heating or cooling circuit *and* at least one downstream AHU. Otherwise the circuit is controlled as a regular (non-mixed) circuit. ## Supply temperature myCoreAI combines its optimization target with the baseline value from the supply curve so the most demanding downstream consumer is always covered: | Circuit type | Supply temperature | | ------------ | --------------------------------------------------------- | | Heating | **Maximum** of optimizer target and supply curve baseline | | Cooling | **Minimum** of optimizer target and supply curve baseline | This prevents the AHU side from being undersupplied when the radiator side could be lowered further, and vice versa. ## Fallback If the supply curve is missing or returns a non-numeric value at the current outdoor temperature, myCoreAI logs a warning and uses the optimizer value directly, without the baseline floor or ceiling. ## Identification Mixed circuits are tagged in the Components view of myPortal. # myLoadshift myLoadshift factors energy prices into myCoreAI's control decisions, shifting consumption toward cheap hours and away from expensive ones. Comfort bounds are untouched — only the timing of energy use moves. ## What it does myCoreAI balances comfort, energy use, and — when myLoadshift is enabled — energy cost. Each hour's energy penalty is multiplied by that hour's price, so cheap hours look cheaper to use and peak hours look costlier to avoid. Comfort targets remain fixed. ## How it works * **Normalization** — the price curve is scaled so its mean over the optimization horizon equals 1. Only the *shape* of the curve influences when energy moves, not its absolute level. * **Peak amplification** — prices in the top of the day's range are amplified, so peak hours are actively avoided rather than mildly deprioritized. * **Edge cases** — negative prices clamp to zero. Missing prices fill from the hour-of-day average across the available window. Past prices never influence future policy. ### Worked example A district-heated office on a utility that publishes a dynamic tariff sees a sharp morning peak between 06:00 and 08:00. With myLoadshift enabled, myCoreAI pre-heats heating circuits during the cheaper overnight hours so the building reaches the morning comfort bounds on stored thermal mass. Supply temperatures drop during the priced peak, then resume normal control once the tariff falls. Indoor climate stays inside the configured comfort bounds throughout — only the energy timing shifts. ## Scope myLoadshift acts on heating supply temperatures for heating circuits and air handling unit (AHU) heating coils. It runs against two price sources: | Controls | Energy source | Price source | | ------------------------------------------------------------ | ---------------- | -------------------------------------- | | Heating supply temperatures (circuits and AHU heating coils) | Electricity | ENTSO-E spot market | | Heating supply temperatures (circuits and AHU heating coils) | District heating | Dynamic district heating tariff signal | myLoadshift is enabled per energy type and only influences the parts of the building supplied by that source. ## Requirements * **Component setup** — each heating component linked to its energy source so myCoreAI applies the correct price curve. * **Price data** — a live or forecasted price feed for the targeted energy type. Electricity uses the ENTSO-E spot market; district heating depends on whether the utility publishes a dynamic tariff. ## Comfort always wins myLoadshift operates strictly within the building's comfort bounds and operating limits. If a shift would compromise indoor climate, myCoreAI does not execute it. # Dew point function The dew point function protects chilled-water (CHW) systems against condensation. When the risk of condensation rises, myCoreAI lifts the CHW supply-temperature setpoint above its optimized value so the supplied water never falls close enough to the dew point to cause condensation on pipes and equipment. myCoreAI normally controls toward a **base setpoint** — the standard setpoint that applies when the dew point function does not need to intervene. The behavior below applies when no separate base setpoint is available and the dew point function governs the CHW setpoint directly. ## Dew point signal myCoreAI reads the actual dew point signal from the BMS. * Only **one** dew point signal can be used per chilled-water system. * If multiple dew point signals are available, the one to use is selected during the controls and technical review meeting. ## How the setpoint is chosen myCoreAI compares the current dew point against the optimized CHW setpoint and applies a fixed safety margin: | Step | Behavior | | ------------- | --------------------------------------------------------------------------------------------------------------------- | | Base range | The CHW system's normal MIN/MAX range is treated as the base setpoint range. | | Safety margin | A fixed **+2 °C** is added to the current dew point. | | Precedence | If the dew-point setpoint is higher than the optimized range, it takes precedence and the MIN/MAX limits are ignored. | The safety margin is currently the same for all buildings and cannot be adjusted. ## Example * Current dew point: **15 °C** * Safety margin: **+2 °C** * Calculated dew-point setpoint: **17 °C** If the optimized CHW setpoint is 14 °C, the system instead controls toward **17 °C** to avoid condensation. ## Summary The dew point function acts as an override on the normal CHW setpoint. When the risk of condensation is low, myCoreAI follows the optimized base setpoint. When the dew point rises, the setpoint is raised to **dew point + 2 °C** to ensure condensation-free operation. # Overview myCoreAI runs on operational data from buildings and external data providers. Integrations bring those values into Myrspoven and, where the connected system supports control, return new setpoint values to the building. This chapter covers the available integration options and the requirements on the building side. **Technical operations:** confirm which signals myCoreAI needs to read and, where relevant, which setpoints it may write.\ **Integrators:** scope the API, protocol, edge component, network access, and commissioning handover.\ **Asset managers:** understand which data sources are used and how energy, sensor, IoT, and weather data are ingested. ## Integration models Myrspoven integrations use two main models. ### Myrspoven integrates to external APIs In this model, Myrspoven is responsible for writing and maintaining the integration code. myCoreAI connects to the external system, reads the configured values, and writes new setpoint values back when the connected system supports control. Supported BMS and SCADA integrations include dedicated platform connectors and protocol-based integrations: * **Web Port** * **Siemens Building X** * **Ouman** * **Fidelix Analytics** * **ProptechOS** These integrations support both reading BMS data and writing new setpoint values. The named platforms are not the full limit of what can be connected. Web Port is a gateway layer with driver support for many field protocols and device types, which lets Myrspoven integrate with a wider range of local BMS and automation setups than the vendor list alone suggests. See [Web Port driver support](https://kiona.com/products/web-port/driver-support) and [Web Port](/integrations/overview/bms-integrations/web-port). Myrspoven also supports smaller read-only integrations for sensor, IoT, energy, weather, and environmental data: * **Yggio** * **EcoGuard** * **PropEye** * **Mestro** * **Metry** * **Radonova** * **OpenMeteo** * **AirThings** Most integrations in this model are HTTP/REST-based. Myrspoven also supports MQTT-based integrations where that is the right fit for the external system. ### External providers integrate to Myrspoven In this model, the external provider is responsible for sending values to Myrspoven. The provider uses the Myrspoven AI-API to send values from a BMS or other data provider, and to pick up new setpoint values when they are available. This model is used when the external party owns the connection to the BMS or data platform and can expose the required values through the Myrspoven AI-API. In practice, Myrspoven can onboard buildings through: * Dedicated vendor integrations, such as Siemens and Schneider. * Protocol-based integrations through Web Port and its driver ecosystem. * External partners that deliver data and setpoints through the Myrspoven AI-API. ## Contents * [**BMS Integrations**](/integrations/overview/bms-integrations) — BMS and SCADA integrations, read/write scope, protocol coverage, and connection requirements. * [**Energy data**](/integrations/overview/energy-data) — options for ingesting consumption data, including BMS pickup, Mestro, Metry, and manual upload. Higher resolution improves optimization results. * [**Myrspoven API**](/integrations/api) — API access for data ingestion and setpoint pickup. ## Requirements on the building side Requirements depend on the integration model and the data source. A typical project may need: * Access to the external API, BMS, SCADA system, or data provider that holds the required values. * BMS read and write access when myCoreAI is configured to optimize and control setpoints. * API credentials or an agreed authentication method for read-only third-party providers. * A virtual server in the building network when an on-premise edge component is used. * Outbound network access from that server to the Myrspoven cloud. No inbound firewall openings. * A technical point of contact for commissioning and signal mapping. Signal list, data ownership, and setpoint scope are agreed during a technical survey and do not change without explicit configuration. # Energy data ## Overview There are several ways to get energy data flowing into Myrspoven, depending on how your meters are connected and how granular your data is. This page covers what's supported, what to expect at each resolution, and why higher-resolution data unlocks better results. ### Integration options #### BMS (Building Management System) The simplest and most efficient method. If your energy meters are already connected to a BMS, Myrspoven retrieves signals directly from it — no extra integration work needed. If your meters are not yet on the BMS but could be, we strongly recommend connecting them there. #### Third-party energy providers For energy data that comes from an energy company rather than a BMS, Myrspoven currently integrates with **Mestro** and **Metry** in Sweden. These services typically deliver hourly data when available, and daily or monthly data otherwise. Third-party providers usually charge for data access — the cost depends on your contract with them. #### Manual upload If you can't share data automatically — or if you use a third-party provider that Myrspoven doesn't yet support — you can upload energy data manually. Most resolutions are supported, but data within each upload must use a consistent resolution. ### Granularity levels Myrspoven supports a range of data resolutions, because not every site can provide real-time data. We always recommend the highest resolution you can offer — higher granularity unlocks better analysis, more accurate reporting, and stronger optimization. | Resolution | Best for | Notes | | ------------- | --------------------------------------------- | ---------------------------------------------- | | **Real-time** | Control, reporting, analysis, troubleshooting | Instantaneous or accumulated consumption | | **Hourly** | Reporting, analysis, troubleshooting | Accumulated or hourly consumption per hour | | **Daily** | Daily reporting comparisons | Limited for building-level impact analysis | | **Monthly** | Reporting only | One value per month — analysis is very limited | ### Why low-resolution data limits what Myrspoven can do Daily and monthly data still work, but the trade-offs are real. Higher resolution makes a measurable difference in three areas. **Energy control.** Without detailed data, advanced machine learning can't be used to optimize energy use; Myrspoven falls back on simpler heuristic methods. These work, but they require deep expertise to tune and don't adapt as well to new systems or unexpected conditions. **Reporting.** Reporting on dynamic features like load shifting becomes harder. Reports end up based on simplified models or raw invoices, which are harder to interpret. Climate-compensated energy reporting also loses precision at lower resolutions — workarounds like SMHI normalization factors exist but only apply in Sweden. **Future capabilities.** More advanced functionality — precise energy optimization, detailed system breakdowns, enhanced reporting — depends on having granular data to work from. Examples include breaking down energy usage for component-level analysis, and fine-tuning HVAC systems for maximum efficiency. For sites aiming for the best possible optimization and reporting, higher-resolution data is the single biggest input you control. ### Requesting a new third-party integration If you'd like Myrspoven to support an energy provider we don't currently integrate with, get in touch with your Myrspoven representative. We evaluate new integrations on a case-by-case basis depending on coverage, demand, and feasibility. *** # Mestro Mestro is a Swedish energy-data platform that consolidates meter readings from utilities and submeters. When meters are read through Mestro rather than the Building Management System (BMS), myCoreAI ingests energy data directly from Mestro instead of relying on manual uploads. ## When to use this integration The Mestro integration fits when: * Meters are read by an energy company or aggregator that delivers data into Mestro, not wired into the BMS. * An active Mestro account already covers the buildings in scope for optimization. * Hourly readings are required and the BMS does not see the meters. If meters are already on the BMS, that route is simpler and avoids a separate data contract. See [Energy data — Overview](/integrations/overview/energy-data). ## Data resolution Mestro typically delivers: * **Hourly** values when the underlying meter supports it. Hourly is the resolution myCoreAI needs for both optimization and reporting. * **Daily or monthly** values otherwise — usable for reporting but constrains what myCoreAI can do on the optimization side. See the [overview page](/integrations/overview) for what each resolution unlocks. ## Requirements * An active Mestro account covering the buildings in scope. * Read permission for Myrspoven against the Mestro tenant (typically granted in the Mestro portal or via an API credential). * A confirmed mapping of Mestro meter IDs to buildings and signals in myCoreAI. Myrspoven handles the access and meter-mapping steps during onboarding. ## Cost Mestro charges for data access on their side; the cost depends on the customer's contract with them. Myrspoven does not charge separately for the integration. ## Troubleshooting Missing values, delayed data, or wrong units almost always originate on the data-feed side rather than inside myCoreAI. Contact Myrspoven to check what is arriving from Mestro and resolve mapping or gap issues. [Manual upload](/integrations/overview/energy-data/manual-upload) is available as a fallback for affected periods. # Metry [Metry](https://metry.io/) is a Swedish energy-data platform that consolidates meter readings from utilities and aggregators. When meters are read by the energy company rather than wired into the Building Management System (BMS), myCoreAI pulls hourly readings from Metry instead of routing through the building automation layer. See the [Energy data overview](/integrations/overview/energy-data) for how energy data flows into myCoreAI across BMS, third-party, and manual paths. ## When Metry is the right route Metry applies when one or more of the following is true: * Meters are billed and read by the energy company, not connected to the BMS. * A Metry account already consolidates the building's meter readings. * Hourly resolution is required but the meters are not exposed on the BMS. When meters are already on the BMS, that path is preferred — myCoreAI reads them directly with no extra integration. ## Resolution * **Hourly readings** when the underlying utility provides them. Required for optimization and detailed reporting. * **Daily or monthly readings** otherwise. Usable for reporting but limits optimization — see the [overview](/integrations/overview/energy-data#why-low-resolution-data-limits-what-myrspoven-can-do). myCoreAI treats Metry-sourced meters like BMS meters for analysis and reporting. The data pipeline tags them separately to preserve provenance. ## Requirements * An active Metry account covering the connected buildings. * Read access granted to Myrspoven from inside the Metry account. Myrspoven walks customers through the exact step at onboarding. * A confirmed mapping between Metry meter IDs and the buildings represented in myCoreAI. ## Cost Metry bills data access directly per their contract. Myrspoven does not charge separately for the integration. ## Alternatives * **Mestro** is the other supported third-party provider in Sweden. New providers are evaluated case by case — see [Requesting a new third-party integration](/integrations/overview/energy-data#requesting-a-new-third-party-integration). * When automated integration is not possible, [manual upload](/integrations/overview/energy-data/manual-upload) is available. # Manual upload Most energy data flows into Myrspoven automatically — from a BMS, from a third-party energy provider, or directly from meters. When automated data transfer isn't possible, you can upload energy data manually instead. ## When to use manual upload Common reasons to upload manually: * You don't have a way to share energy data through an automated channel. * You use a third-party energy provider that Myrspoven doesn't currently integrate with. See [Requesting a new third-party integration](/integrations/overview/energy-data#requesting-a-new-third-party-integration) if you'd like us to support a new provider. * Historical data has been corrected or rescaled — for example, units changed from megawatts (MW) to kilowatts (kW). Previously uploaded data will appear in different numerical values in this case (1 MW = 1000 kW). * A time period contains missing data that needs to be backfilled. ## How uploaded data is handled Data you upload is treated as the **most accurate and up-to-date source** for that signal. If you upload data for a time period that already has data in the system, the existing values within that period are automatically replaced by the new upload. The system will always reflect the latest reliable data you've provided — there's no manual merge step. If you have two separate intervals of data that need to be updated, you must upload the data in two separate batches to avoid losing the data in between. ## Supported data format The minimum structure for an upload is two columns: 1. **Timestamp** 2. **Energy value** The system automatically converts units when the uploaded units differ from those stored for the signal — for example, an upload in kWh against a signal stored in MWh. If a conversion isn't possible (for example, mismatched dimensions), you'll be notified during the upload process and the upload will be rejected. {% hint style="info" %} The in-app instructions are canonical. The upload form in BackOffice includes step-by-step guidance on the exact file format and field requirements. If anything on this page differs from what the upload form shows, follow the form — it's always the most up to date. {% endhint %} # BMS Integrations ## Overview myCoreAI connects to a building's existing Building Management System (BMS) to read sensor and meter values and to write the setpoints it has been configured to control. The BMS keeps operational control; only the agreed signals are touched. **Asset and facility management:** myCoreAI improves user comfort and energy efficiency on the BMS already installed — no controls-hardware replacement. **Technical operations:** myCoreAI exposes setpoint behavior, bounds, and overrides as auditable signals. The BMS remains the single source of operational truth. **Integrators:** myCoreAI connects over standard protocols (REST, OPC UA, BACnet, Modbus, or a vendor SDK), with a Myrspoven edge available where direct access isn't viable. ### How the integration works The communication flow between Myrspoven and the building can happen in one of two main ways: 1. **Direct BMS connection.** myCoreAI connects to the BMS over a network-reachable interface — This is most common when the building can be controlled via a cloud platform or when the local BMS is reachable from the internet through the local firewall. Data flows in both directions on the agreed signal list. 2. **Via Myrspoven edge.** Where direct access isn't viable — closed networks, legacy protocols, segmented IT environments — a small edge application runs on a virtual server inside the building's network and bridges the BMS to the Myrspoven servers. The edge application polls the Myrspoven servers and sends data/retrieves setpoint updates, so no inbound firewall rules are required. In both scenarios the BMS keeps operational control. myCoreAI reads only the signals it has been configured to read, and writes only the setpoints it has been configured to write. ### Read and write Reads run continuously — typically every minute, and at most every five minutes, depending on the integration. (Reporting and the UI dataset are sampled down to hourly.) Common reads include data from indoor sensors (temp, CO₂ and humidity), outdoor temperature, energy meters, current setpoints, and equipment status. Writes are limited to the setpoints agreed during startup. Typical setpoints are heating-circuit supply temperature setpoints, air handling unit (AHU) supply temperature and fan setpoints, cooling setpoints, and zone-level terminal unit setpoints where the BMS exposes them. Write operations occur whenever an optimization run has successfully produced new setpoint values. Each writable setpoint has minimum and maximum bounds agreed up front; myCoreAI cannot push a setpoint outside those bounds. Manual overrides from the BMS take effect immediately, and myCoreAI adapts on the next read. Writes can also be paused per building — reads and reporting continue, but actuation stops. ### Supported BMS platforms and protocols The platforms below are in production today. They are common delivery paths, not a hard limit on what Myrspoven can connect to. | Platform | Vendor | Connection | Status | Detail | | ---------------------------------------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | --------- | | **Web Port** | Kiona | Local Web Port server (Windows) → Myrspoven Web Port-Cloud; Modbus / BACnet / industrial protocols on the local side | In production | Web Port | | **EcoStruxure Building Operation (EBO)** | Schneider Electric | On-premise via Myrspoven edge, or cloud via Schneider SmartConnector; dedicated Read / Write / Overwrite-Bindings folders on the EBO side | In production | Schneider | | **Building X (BPCloud)** | Siemens | JSON:API over HTTPS, OAuth2 client credentials. Semantic mapping of tagged equipment/points → Myrspoven components and signals | In production | Siemens | | **Desigo CC** | Siemens | Legacy on-prem path; requires manual virtual-signal setup in the BMS | In production (legacy) | Siemens | ### Broader protocol coverage through Web Port Web Port acts as a protocol gateway. It supports a broad set of drivers for building automation and industrial protocols. That expands the practical integration surface well beyond the named vendors on this page. If a building exposes the required signals through a Web Port-supported driver, Myrspoven can often integrate without needing a dedicated vendor-specific connector. Final fit still depends on signal availability, write scope, network access, and project requirements. See [Web Port](/integrations/overview/bms-integrations/web-port) and [Web Port driver support](https://kiona.com/products/web-port/driver-support). For platforms not listed here, contact Myrspoven to assess the best path — direct connector, Web Port, or Myrspoven AI-API. ### What's needed to onboard a new building The building owner or integrator typically provides: * A **signal list** for reads and an allowed-setpoint list for writes. Produced together during the technical survey. * A **point of contact** at the BMS integrator for commissioning. For a building with a Local BMS behind firewall that needs Myrspoven edge, the additional requirements are: * A **virtual server** in the building's network for the Myrspoven edge (when the Myrspoven edge solution is used). * **Outbound network access** from that server to the Myrspoven cloud. * **BMS access** — read and write — on a supported protocol. * **Temporary VPN access** during edge installation and configuration. No operational traffic uses the VPN. ### Updates/maintenance of Myrspoven edge To streamline updates of the Myrspoven edge installations we use [Octopus Deploy](https://octopus.com/). We install an Octopus tentacle on the virtual machine in your network that checks regularly with our Octopus server if there is a new version to download and install. It will make outbound requests using https and download updated software when available. It can also update itself when needed. ### Security All BMS connections are encrypted. Write scope is restricted to the agreed setpoint list and cannot be widened without explicit configuration. The edge polls outbound only — no inbound ports are opened on the building's network. *** # Schneider myCoreAI integrates with Schneider Electric **EcoStruxure Building Operation (EBO)** following the same pattern as other BMS integrations: myCoreAI reads sensor and meter values out of EBO and writes a limited, agreed set of setpoints back. This page covers what is specific to EBO. ## Integration model On the EBO side, a dedicated **Myrspoven** top-level folder holds three subfolders: * **Read** — every value myCoreAI reads from EBO (indoor temperatures, pressures, energy meters, equipment status, current setpoints). * **Write** — every setpoint myCoreAI writes back into EBO. * **Overwrite Bindings** — bindings that route written values to the actual EBO points, with a fallback template that takes over if writes stop. Two connection paths are supported: 1. **On-premise** via the Myrspoven edge — a virtual server in the building network bridging EBO to the Myrspoven cloud. 2. **Cloud-based** via a Schneider SmartConnector. This path requires an additional failsafe (see [Failsafe time](#failsafe-time-cloud-integrations)). EBO retains control of the building. myCoreAI only reaches the signals listed in Read, Write, and Overwrite Bindings. ## Monitoring Two surfaces provide a quick health check. **myPortal Blueprint view.** Each sensor carries a color-coded status. | Colour | Meaning | | ---------- | ---------------------------------------------- | | Black | Sensor disabled or broken | | Red | One degree or more above the threshold | | Orange | Above the threshold | | Light blue | Below the minimum threshold | | Blue | One degree or more below the minimum threshold | **EBO ProcessViewer.** The **Myr\_D** and **Myr\_DS** processes sit under the Myrspoven folder. * **Myr\_D** — binary on/off indicator. Green means myCoreAI is running. * **Myr\_DS** — indicates a successful write into EBO. Brief red states are normal and clear within 15 minutes. Persistent red: confirm the write process is enabled, then check the **spov** process for an active error. The cloud icon above each sensor in EBO shows the setpoint chosen by myCoreAI. To pause optimization on a single circuit, open the cloud display's control panel and deactivate that circuit. The loop reverts to its original setpoint. ## Sensor readings out of range 1. **Check the bottleneck list.** It surfaces sensors running too cold or too hot. Adjust the sensor's Min/Max, or disable a sensor in a bad location. 2. **Account for the environment.** Drafts, poor insulation, and direct sunlight produce misleading readings. Fix the physical cause before adjusting the model. 3. **Choose the right scope.** To shift the whole building warmer, raise Max on all sensors. To stop a single outlier from dominating, lower its Min. 4. **Adaptive min/max is provisional.** Under building settings, adaptive min/max limits how far myCoreAI may deviate from the original setpoint. Remove the restriction once the underlying issue is resolved. ### RMSE and automatic fallback Each building has an **RMSE limit** (default 1.7) tracking sensor deviation from expected behavior. When the limit is exceeded, myCoreAI deactivates automatically and the building reverts to EBO's original control logic. To restore optimization: 1. Fix the underlying sensor issue. myCoreAI does not resume while large deviations remain. 2. Remove the **Myr\_DS** lock by double-clicking it. ### SmartConnector dropped its connection Symptoms: read process turns red, signals start dropping, orange dot appears on **Myr\_DS** and **Myr\_D**. Recovery: restart the SmartConnector. ## Verifying data accuracy in EBO When commissioning or auditing a building, walk through the three Myrspoven folders and confirm the values. **Read folder** (`Myrspoven → Read`) For a Read signal, the left arrow (`<-`) in the Signalkey indicates the source of the value; the bidirectional arrow indicates the logging point used downstream. **Write folder** (`Myrspoven → Write`) * Every value must match what appears in the EBO image. Mismatch: check the Signalkey. For a Write signal, the left arrow shows the EBO write value read back; the right arrow shows the write value held on the Myrspoven side. **Overwrite Bindings folder** (`Myrspoven → Overwrite Bindings`) * Values must match the corresponding Write folder values. Mismatch means the binding key is wrong. * Missing or faulty values mean the Signalkey needs checking. For an Overwrite Binding, the left arrow points to the **Myr\_ut** template (holding the fallback value); the right arrow points to the signal being written. ## Failsafe time (cloud integrations) SmartConnector-based integrations require a **Failsafe Time** parameter — a watchdog on the data flowing from myCoreAI into the cloud connector. * **Duration:** 900 seconds (15 minutes). * **Behavior:** if no updated value arrives within the window, the failsafe deactivates the cloud-side integration and reverts to default values. The building continues on EBO's own logic rather than stale setpoints. The failsafe guarantees that an outage on the myCoreAI side cannot leave EBO running indefinitely on outdated values. ## What partners provide To onboard an EBO building: * The agreed signal list — read points and writable setpoints. * An EBO user with access to the **Myrspoven** folder structure (Read, Write, Overwrite Bindings). * Either a virtual server for the Myrspoven edge or a SmartConnector setup. * A point of contact at the Schneider integrator for commissioning. For general troubleshooting not specific to EBO, see [Troubleshooting](/troubleshooting/overview). # Siemens The Siemens integration covers two platforms. **Siemens Building X (BPCloud)** is the cloud platform and the recommended path for new sites — detailed below. **Siemens Desigo CC** is the legacy on-prem platform, still supported but requiring manual virtual-signal setup in the BMS; summarized at the end. The two paths share no prerequisites. ## Siemens Building X (BPCloud) ### What the integration does myCoreAI connects to a Building X tenant over its public JSON:API to discover equipment and points, read current and historical values, and write numeric setpoints where permitted. Discovery maps Building X equipment, devices, and points into Myrspoven systems, components, and signals automatically. * **API style:** JSON:API over HTTPS * **Auth:** OAuth2 client credentials * **Base URL:** `https://api.bpcloud.siemens.com/` ### Required credentials Per building: | Property | Description | | ----------------------------- | ------------------------------------------------------------ | | `ClientId` | OAuth2 client ID for the service account | | `ClientSecret` | OAuth2 client secret (treat as credential) | | `SiemensBuildingXPartitionId` | Building X partition UUID — tenant scope for all API calls | | `ExternalBuildingId` | The building's location GUID in the Building X structure API | {% hint style="warning" %} **Security.** `ClientSecret` is shared over an agreed secure channel only (password-manager share or encrypted handoff). If exposed in chat, email, or a ticket, the secret is rotated in Building X / Auth0 and re-shared. {% endhint %} ### Required API permissions * **Structure API (read):** `equipment`, `equipment-types`, `locations`, `point-groups`, `point-groups/{id}/points` * **Operations API (read):** `devices`, `devices/{id}/points`, `points/{id}`, `point-value-resource` (current and history) * **Operations API (write):** `POST points/{id}` — only when myCoreAI writes setpoints Read-only access is sufficient for analysis and reporting. Write access is required only when myCoreAI is actively optimizing the building. ### Discovery Discovery runs in two deterministic phases. Raw data is fetched first; interpretation happens in a separate pass. The result is auditable and reproducible run-to-run. **Phase 1 — snapshot collection** 1. Fetch the equipment list and equipment-type catalog for the partition. 2. Resolve the building's location scope and filter equipment to that building. 3. Build a device-to-equipment map from `isControlledBy` relationships. 4. Fetch devices in the building location. 5. Build point-group enrichment maps (tags, equipment IDs, device IDs by point ID). 6. For each device, fetch its points and resolve the owning equipment. **Phase 2 — signal and component tagging** 1. Seed components from equipment using the known equipment-type mappings. 2. Convert each point to a signal and normalize its point-group tags. 3. Match against the rule catalog (equipment-type GUID + required/forbidden tags) to assign a signal position and component type. 4. Fall back to the equipment's default component binding when no rule matches. 5. Post-process: merge duplicates, deduplicate signal names, remove incompatible assignments. ### Point-groups and fallback strategy Building X point-groups bind points to equipment deterministically. A point-group ID encodes the entity type — `Equipment-{id}` or `Device-{id}`. The preferred path is `GET /structure/partitions/{partitionId}/point-groups`. Some tenants restrict this endpoint and return HTTP 403; the integration auto-detects this and falls back to per-entity probing. No configuration required. ### Reading and writing values **Current values** are read with a three-level fallback per signal: 1. Point-group endpoint (batched — fewest requests) 2. Batch point-values endpoint 3. Per-point history endpoint (last value, last-resort) The value parser handles strings, numbers, booleans, and JSON elements. `"on"/"off"` and `"open"/"closed"` normalize to 1/0. NaN and infinity are rejected. **Historical values** are fetched via the point-value-resource endpoint with a UTC date range. Pagination is automatic. **Writes** are accepted only for finite numeric values. ### Supported equipment and signal types Signal mapping is driven by a rule catalog keyed on equipment-type GUIDs and semantic tags. | Equipment family | Myrspoven system | Example signal positions | | -------------------------------- | ----------------- | ------------------------------------------------------------------ | | Air handling unit (AHU) | Ventilation | Supply/return air temperature, pressure, flow, CO₂, setpoints | | Terminal unit (VAV/CAV) | Ventilation | Zone control, comfort observables, damper position | | Hydronic circuit | Heating | Supply/return temperatures, setpoints, valve position, pump status | | Cooling (chiller, cooling tower) | Cooling | Chiller temps, condenser water, cooling-tower signals | | Heat exchanger | Heating / Cooling | Supply/return, bypass and isolation valve positions | | Energy meter | Energy | Energy consumption points | | Observable sensors | Observables | Weather, room comfort, CO₂, occupancy | Equipment outside this list still completes discovery; unmatched points are not auto-bound and may need a rule extension. The diagnostics file is the starting point for that extension. ### Onboarding checklist * Provision an OAuth2 service account (client credentials grant) in the Building X / Auth0 tenant. * Grant read access — and write access if applicable — to the relevant partition. * Share `ClientId`, `ClientSecret`, `SiemensBuildingXPartitionId`, and `ExternalBuildingId` with Myrspoven through the agreed secure channel. ## Legacy: Desigo CC (on-prem) Older Siemens deployments use on-site Desigo CC rather than Building X. The integration model differs fundamentally: instead of a cloud API with structured equipment metadata, myCoreAI communicates through virtual signals created inside the BMS itself. This path is still supported but is no longer recommended for new sites. Desigo CC sites are onboarded case-by-case with Myrspoven, as the exact virtual-signal layout depends on which signals are read versus written. High-level steps: 1. Run discovery against the BMS to enumerate available signals. 2. Select signals to read and write. 3. Create the required virtual signals inside the BMS (one-time manual setup per building). 4. Re-run discovery to pick up the virtual signals. 5. Confirm the resulting structure in Myrspoven. Virtual-signal folder layout, watchdog handling, and fallback behavior are coordinated case-by-case with Myrspoven to avoid disrupting the live BMS. # Web Port Web Port is a Building Management System (BMS) gateway. myCoreAI uses it to read signals, write setpoints to control PLCs over Modbus, BACnet, and other industrial protocols. This page covers the full integration: installing a local Web Port server, connecting it to Myrspoven's Web Port-Cloud, configuring devices and tags, and finalizing signal flow in myPortal. ## Why Web Port matters Web Port is not just a single vendor integration. It is a protocol gateway with driver support for a wide range of building and industrial devices. That means Myrspoven is not limited to a short vendor list when Web Port is the delivery path. If the local system exposes the required signals through a supported driver, Myrspoven can often integrate through Web Port instead of needing a dedicated connector for that BMS brand. Final fit still depends on signal availability, write scope, network access, and commissioning requirements. See [Web Port driver support](https://kiona.com/products/web-port/driver-support) for the current driver coverage. ## Components The integration has three parts: 1. **Local Web Port.** A Windows service running on-site (or behind a VPN) that talks directly to control cabinets and DUCs. Can also be partner-hosted as a cloud service. 2. **Myrspoven's Web Port-Cloud.** A shared cloud Web Port instance. The local Web Port connects upward to it; myCoreAI reads tags from there. 3. **myPortal.** Generates the final signal and fallback scripts that wire the building into myCoreAI. ## Prerequisites * A Windows host to run Web Port as a service. Windows 10 or later recommended. Older versions require .NET Framework 4.8 or later (from [Microsoft](https://dotnet.microsoft.com/en-us/download/dotnet-framework/net481)). * A Web Port license file (`WebPort.lic`) from [market.webport.se](https://market.webport.se/webport). * Network access from the host to on-site I/O devices and to Myrspoven's Web Port-Cloud at `https://myrspoven.webport.se`. * Administrator rights on the host (required to install Web Port as a Windows service). * A Myrspoven contact for cloud-side credentials, the signal-list template, and the Myrspoven edge build. ## Install the local Web Port {% stepper %} {% step %} ## Download the latest release Download the latest Web Port server release from the [Web Port release page](https://iwmac.zendesk.com/hc/sv/articles/5100183398684-Senaste-releasen-Web-Port). {% endstep %} {% step %} ## Run the installer Run the installer. The vendor's full [installation walkthrough](https://iwmac.zendesk.com/hc/en-gb/articles/6253490179996-Installation#Server) covers every screen. Key choices: * **Drivers:** select the drivers required for the site's protocols (Modbus TCP, BACnet, etc.). * **Run mode:** **Run as a Windows service** so Web Port starts with the host. * **Server port:** default `8090`. Change only on port conflicts. {% endstep %} {% step %} ## Place the license file Place the `WebPort.lic` file in the Web Port data directory. {% endstep %} {% step %} ## Sign in Open `http://localhost:8090` and sign in. {% endstep %} {% endstepper %} {% hint style="warning" %} **Rotate the default credentials immediately.** Web Port ships with a default administrator login. After the first sign-in, create a new admin account and disable or rotate the default before the host is exposed beyond localhost. {% endhint %} ## Configure the local Web Port ### Connect to Web Port-Cloud Skip this section for partner-hosted cloud Web Port — go straight to [Create an I/O device](#create-an-io-device). {% stepper %} {% step %} ## Connect from the local Web Port On the local Web Port: 1. Open **System settings → Communication → Node setup**. 2. Click **Connect portal**. 3. Fill in: * **Name:** company or property name. * **Description:** e.g. "Web Port-Cloud Myrspoven". * **Portal address:** `https://myrspoven.webport.se/` 4. Save. {% endstep %} {% step %} ## Activate the connection in Web Port-Cloud Activate the connection on the Myrspoven side: 1. Sign in to [https://myrspoven.webport.se](https://myrspoven.webport.se/). 2. Open **System settings → Communication → Node setup**. 3. Select the new node. 4. Tick **Active device** and save. An active connection shows green on both sides. {% endstep %} {% endstepper %} ### Enable trend logging Trend logging must be on, otherwise no signal history is stored. 1. Open **System settings → Trend → Basic settings**. 2. Enable **Trend support** and save. ### Verify the host time zone Incorrect Windows time zones cause signal timestamps to drift and break downstream analysis. Verify before continuing. ### Create an I/O device An I/O device links Web Port to a control cabinet or DUC. At least one TCP/IP device is required. When each cabinet or DUC has its own IP, Web Port talks to each one directly. The example uses Modbus TCP — creation is identical regardless of driver. {% stepper %} {% step %} ## Add the device 1. Open **System settings → Communication → Device**. 2. Click **Add device**. 3. Fill in: * **Name:** the control cabinet name, or the DUC number suffixed with the building name (e.g. `DUC1-ExampleBuilding`). * **Description:** optional. * **Driver:** the driver for the site (Modbus in this example). 4. Save. The device appears in the list and stays red until configured. {% endstep %} {% endstepper %} ### Configure the I/O device This example covers Modbus TCP. Other drivers expose different fields — see the relevant [driver manual](https://iwmac.zendesk.com/hc/sv/articles/10579102738332-Drivrutinsmanualer-Web-Port). {% stepper %} {% step %} ## Open the device configuration Open the new I/O device. {% endstep %} {% step %} ## Set the Modbus fields Scroll to **Slave Address**, **Modbus type**, **(TCP) Host**, **(TCP) Port**. {% endstep %} {% step %} ## Fill in the values Set: * **Slave Address:** `1` for the master or first DUC, `2` for the next, and so on. * **Modbus type:** usually **Modbus TCP**. * **(TCP) Host:** the IP of the control cabinet or DUC. * **(TCP) Port:** `502` is standard for Modbus. If closed on the target IP, escalate to the site owner or network team before continuing. {% endstep %} {% step %} ## Save and verify Save. A reachable IP with the port open turns the driver green with state **OK**. {% endstep %} {% endstepper %} ### Create a tag list The simplest approach is an empty list, populated manually. {% stepper %} {% step %} ## Open Tags Open **System settings → Tags**. {% endstep %} {% step %} ## Create the list Click **New tag list**. {% endstep %} {% step %} ## Name and save **Name:** same convention as the I/O device — building name plus the device. Save. To edit later, click the tag icon to the left of the name, or click the row and choose **Edit**. {% endstep %} {% endstepper %} ### Create tags Tag creation is identical across protocols — only the address format changes. {% stepper %} {% step %} ## Create a new tag Click **New tag**. {% endstep %} {% step %} ## Fill in the fields Fill in: * **Name:** structure `BuildingName_Unit_Sensor_Property` — e.g. `ExampleBuilding_HC1_AHU1_TE1_SP`. Consistent prefixes keep signal lists portable across buildings. Avoid Å, Ä, Ö — the database sometimes replaces them with an underscore. * **I/O device:** the device the tag belongs to. * **Address:** maps the tag to the underlying object and controls read/write access. * **Data type:** `INT` for analog I/O; `DIGITAL` for digital signals (0/1). * **Raw min/max** and **End min/max:** scale the raw value. * **Unit:** SI unit. * **Format:** four decimals is standard. * **Description:** what the tag represents. * **Trend log:** must be enabled. 300-second interval is sufficient. {% endstep %} {% step %} ## Save Save the tag, then the tag list. {% endstep %} {% endstepper %} ### Filter signals Exclude any signal not used for optimization or reporting. Fewer irrelevant signals means cleaner mapping later and less noise downstream in myCoreAI. ## Configure Web Port-Cloud These steps happen in [myrspoven.webport.se](https://myrspoven.webport.se/) and wire the cloud Web Port to myCoreAI. ### Create a group Each building gets its own group. Group members inherit access to Web Port's API and to the building's tags, and are linked to myCoreAI. {% stepper %} {% step %} ## Create the group 1. Open **System settings → Groups**. 2. Click **New group**. 3. **Group name:** building name plus protocol suffix — e.g. `ExampleBuilding_Modbusgroup`. 4. Leave the rest at defaults and save. {% endstep %} {% endstepper %} ### Create users Three users per building: **discovery**, **read**, **write**. {% stepper %} {% step %} ## Create a user 1. Open **System settings → Users**. 2. Click **New user**. 3. Set the username: * `BuildingName_discovery` * `BuildingName_read` * `BuildingName_write` 4. Set a strong, unique password per user and store it in a password manager. Never reuse passwords across buildings. No leading or trailing spaces. 5. Assign the user to the building's group and save. 6. Repeat for the remaining users. {% endstep %} {% endstepper %} ### Grant permissions #### Tag permissions {% stepper %} {% step %} ## Create the tag permission 1. Open **System settings → Access → Permissions**. 2. Click **New permission → New tag permission**. 3. Set: * **User/Group:** the building's group. * **Tag filter:** the building's name followed by `_*` (e.g. `ExampleBuilding_*`). Restricts the permission to that building's tags. * **Permissions:** **ADMIN**. 4. Save. {% endstep %} {% endstepper %} #### Function permissions {% stepper %} {% step %} ## Create the function permission 1. Open **System settings → Access → Permissions**. 2. Click **New permission → New function permission**. 3. Set: * **User/Group:** the building's group. * **Function:** **API access**. * **Permissions:** **ADMIN**. 4. Save. {% endstep %} {% endstepper %} ## Install the Myrspoven edge The Myrspoven edge reads tags from Web Port and forwards them to myCoreAI. It runs on the same host as Web Port or on a host with network access to it. {% stepper %} {% step %} ## Obtain the build Obtain the latest Myrspoven edge build from Myrspoven. {% endstep %} {% step %} ## Create the folder Create `C:\Myrspoven` on the host. {% endstep %} {% step %} ## Copy and extract the package Copy the edge package into `C:\Myrspoven\MyrspovenEDGE` and unzip it. Name the unzipped folder `Myrspoven Edge`. Delete the zip once extraction is verified. {% endstep %} {% step %} ## Create the scheduler folder Open Windows Task Scheduler and create a `Myrspoven` folder. {% endstep %} {% step %} ## Add the scheduled tasks Inside it, create the scheduled tasks supplied by Myrspoven (names, actions, and triggers are predefined). {% endstep %} {% step %} ## Configure credentials Configure the credentials the scheduled tasks run as. {% endstep %} {% step %} ## Test the edge Test the Myrspoven edge manually from a command prompt before relying on the triggers. Confirm signals appear in myCoreAI within the expected interval. {% endstep %} {% endstepper %} ## Finalize in myPortal The last steps happen inside myPortal: {% stepper %} {% step %} ## Select the building Select the building. {% endstep %} {% step %} ## Open the Web Port Script tool Open **Tools → Web Port Script**. {% endstep %} {% step %} ## Generate the scripts Follow the in-app instructions to generate the signal script and fallback script. {% endstep %} {% step %} ## Adjust if needed Adjust the script in a text editor if needed. {% endstep %} {% step %} ## Paste into Web Port Paste the script into the local Web Port. {% endstep %} {% endstepper %} {% hint style="info" %} myPortal's in-app instructions are canonical. On any conflict with this page during script generation, myPortal wins. {% endhint %} ## Troubleshooting * **Web Port won't start as a service.** Check the Windows Event Log. Most common causes: missing or expired license file, or another process holding the configured port. * **Signals collected but timestamps look wrong.** Re-check host time zone and confirm Trend Basic Settings is enabled. * **Myrspoven edge runs manually but not from Task Scheduler.** Verify the scheduled task's credentials have read access to the Web Port data directory and outbound network access. * **Driver shows red, not OK.** Confirm the target IP is reachable from the host and the configured TCP port (502 for Modbus) is open end-to-end. # API Most buildings connect to myCoreAI through their Building Management System (BMS) or the Myrspoven edge. Some sites instead expose data — energy meters, indoor climate sensors, occupancy systems — through a vendor API. This page orients on when an API integration applies, its shape, and where the full reference lives. ## When an API integration applies myCoreAI uses an API integration when: * Energy data comes from a third-party platform (for example **Mestro** or **Metry**) rather than the BMS. * Indoor climate sensors are owned by a third-party platform that exposes a cloud API. * The BMS itself exposes a network-reachable REST API, OPC UA endpoint, or vendor SDK that myCoreAI can read from and write to directly. Bringing meters or sensors onto the BMS is the simpler path when possible — fewer moving parts, no third-party provider cost, one connection to maintain. An API integration is the right choice when the data only lives outside the BMS, or when the BMS itself is the API. ## Shape of an API integration All three cases share the same shape: Myrspoven holds credentials to read from (and where relevant, write to) the vendor's API on an agreed schedule. Once ingested, the signals are treated identically to BMS signals — myCoreAI's model and the myPortal dashboards are transport-agnostic. The customer-provided inputs are also consistent across vendors: * An account or API key with read access, and write access where myCoreAI must push setpoints back. * A confirmed mapping of meter IDs, sensor IDs, or signals to buildings and zones. * A technical point of contact for commissioning. Exact credentials, endpoints, and ID formats are vendor-specific and documented per building during the technical survey. ## Cost Third-party platforms typically charge for API access under their own contract. Myrspoven does not charge separately for the integration. Adding a vendor connector that isn't already supported is evaluated case by case — request one via Myrspoven. ## Security API credentials are stored in Myrspoven's cloud and used only for the agreed integration. Scope never widens beyond the configured read/write signals. See [Security](/trust-and-security/overview). ## Related * BMS — direct BMS connections, including REST / OPC UA / BACnet shapes. * Energy data — Mestro, Metry, and manual upload. * Indoor climate — third-party sensor-vendor API integrations. * Full API reference — see the [Developer reference](/developer-reference/myrspoven-ai-api). # June 2026 **Version 2026.6** *** ### Highlights June completes the **OpenMeteo** migration — every building now runs on the new weather provider, for more stable and accurate predictions. A new data integration went live (**ProptechOS**), sensor onboarding got richer (Fabege room sensors, Propeye), and we began rolling out **single sign-on via Keycloak** across myPortal and BackOffice. Under the hood, the optimizer is faster and more resilient. *** ### myPortal — Customers * **Single sign-on (Keycloak)** — myPortal now authenticates through Keycloak, the foundation for a unified, more secure login across Myrspoven products. * **Sensor map** — design improvements to the floor-plan view, and floor-plan blueprints are now supported for placing sensors. * **Insights** — corrected the outdoor-temperature series in the climate trend. **Fixes** * Access pages occasionally failed to load (including when page styling was served from cache) — resolved. * User lists now display correctly even when a user has no name set. ### BackOffice & Integration - Partners #### **New integrations** * **ProptechOS** — new building data provider with full discovery, read, write, and historical support. * **Fidelix Analytics** — custom unit parser plus correct unit and data-type mapping. #### **BackOffice** * **Manual setpoints** — now shows optimizer status with an enable/disable toggle, and supports write signals without transformation tables (including self-referencing transformations). * **Comfort schedule** — night cooling can now *raise* AHU pressure via a negative pressure factor, not only lower it (requested by Hemsö). * **Partner superusers** can now edit all of their company's building groups, not only the ones they belong to. * **Blueprints** — create and manage floor-plan blueprints for sensor placement. **Fixes** * Long signal names no longer break the Comfort Schedule UI. * Building groups now shown. ### Smart Control * **All buildings now use OpenMeteo** — the weather-provider migration begun in May is complete, giving more stable and accurate weather inputs to every building. * **Smarter ventilation grouping** — buildings where more than half the circuits are ventilation now switch to ventilation-based grouping automatically. * **Faster optimizer** — per-run data fetch cut from 225 hours to 48; baseline ventilation handling reworked for speed. * **More resilient** — the optimizer now handles signals being enabled or disabled mid-run without disruption. * **Dew point safety margin** — added and validated the +2 °C condensation guard on chilled-water setpoints. **Fixes** * Comfort schedule no longer lowers too far when a signal's min/max bounds are low. * Ventilation supply temperature on no-cooling systems is now clipped by outdoor temperature. ### Data Platform * **Meter pipelines now on Spark** — extending May's Spark migration to district-heating and metering data, for faster, more scalable processing. * **Building analysis overview** — a new weekly aggregation job and square-metre (m²) KPI normalization, complementing May's daily aggregator. * **Faster deviation summaries** — deviation data is now preaggregated, cutting query time and memory use. * **Infrastructure** — Airflow upgraded with CDC table compaction and maintenance tuning. # May 2026 **Version 2026.5** *** ### Highlights May marks a milestone for **myLoadshift**: over **150 VAV buildings** are now actively load-shifting heating against ENTSO-E day-ahead electricity prices (delivered via the Vanta Energia signal) — load shifting is a working production solution at scale. The **Siemens** integration is live, and buildings are being migrated to **OpenMeteo** as the new weather provider. A significant **AI safety improvement** of the AI optimization. A significant change to the AI's guardrails ensures buildings are no longer affected by checks on components the AI doesn't actually control. *** ### myPortal — Customers * Cleaner graphs for **AI-disabled** signals — Signals where AI control is disabled no longer surface graph suggestions in myPortal, reducing visual noise. * **Timezone display preference** — Users can set a preferred timezone for how times are displayed (default UTC). * **Sensor Map — type switcher** added to the signal list, making it easier to filter by signal type. * **Insights climate chart** — Outdoor temperature now displays a clean "no data" state when readings are unavailable, rather than rendering an empty series.
### BackOffice & Integration - Partners #### **New integrations** * **Siemens Building X integration** — Now live. * **Fidelix** — Discovery support added. * **OpenMeteo** — Now the new weather data provider; existing buildings are being migrated, improving stability and predictions. #### **BackOffice** * **Manual setpoint values** — A new BackOffice page lets you create manual setpoint values for write processes. * **Batch delete empty components** with clearer deletion status feedback. * **No writes to AI-disabled signals** — The platform now refuses to send values to signals where AI control is disabled, preventing accidental overrides. ### Smart Control * **AI guardrails** — Previously, a group of sensors tied to a non-controlled system could still trigger guardrail crashes, meaning the AI could disrupt parts of the building it had no control over. The optimizer now only evaluates AI-managed components against guardrails, removing this class of crash. * **Heating with dew point** — Dew point can now influence comfort bounds when relevant, improving setpoint quality in humid conditions. Important before summer and cooling season. * **Max-change heating anchored to latest write** — Even when feedback lags slightly, reducing oscillation. * **Stability and accuracy pass** across the optimizer: min/max validation now only applies to active AI-managed signals; duplicated signal names handled cleanly; weather-only rows no longer trigger spurious drop-row checks; verifies the data-storage connection before sending values. ### myLoadshift Load shifting is now a working, production-grade solution running across our VAV fleet. * **150+ VAV buildings load-shifting against electricity price** — All VAV buildings in optimization now use ENTSO-E spot prices (delivered via the Vanta Energia signal) to control heating, shifting load away from high-price hours. * **Load shift prices persisted to optimization tables** — Prices are stored alongside optimization data, making downstream analysis and dashboards reliable. Load-shifting moves HVAC energy use in time so the building consumes more during cheap hours and less during expensive ones. The optimizer does this by multiplying its energy penalties by a time-varying price curve, so cheap hours look "cheaper to use" and peak hours look "more expensive to avoid" — comfort bounds are unchanged.

The resulting policy and the price curve driving it are visualized here: the top panel shows group climate against the comfort bounds, and the Control Variable panel below overlays the optimized policy with the normalized load-shift price. The tooltip reports both the raw market price and the normalized multiplier applied at that timestep.

{% file src="/files/t0bdG6oWN1zOU4UVNGos" %} ### Data Platform * **Trino to Spark** — Maintenance pipeline and AI vs Baseline now runs on Spark, with tuning for spot-instance survival on heavy tables. * **Overview aggregator** — A new daily aggregator producing building-level analysis data, paving the way for richer Insights views. * **Optimization, metric, and meter tables partitioned by building** — Significant query performance improvement for data platform and **Insights**. * **AI vs Baseline reimplemented on Spark**, with optimization, metric, and meter tables now partitioned by building for significantly faster queries. These changes aren't directly user-visible but enable richer capabilities and more reliable operation going forward. # April 2026 **Version 2026.4** *** ### Highlights This release focuses on making AI performance more visible and verifiable, both for customers in myPortal and for partners in BackOffice. The new AI Performance view provides a cleaner, more complete picture across all building systems. *** ### myPortal — Customers #### **AI Performance** *(replacing AI vs Baseline)* * The new AI Performance view lets customers monitor and compare AI-controlled system performance across their building. * Components are grouped by system, such as Heating and Ventilation, with individual time-series graphs showing how the AI manages each signal. * Customers can filter by component type and date range, and drill into any signal for a detailed breakdown. * The view also includes a side-by-side comparison of actual AI behavior vs. the estimated without-AI counterfactual, plus weather context and air quality data.
#### **Sensor Map** *(signal list for blueprint-free buildings)* * For buildings without a floor plan, the Sensor Map now displays as a full signal list. * Customers can see all apartment and zone sensors in one scrollable view, with live comfort status, current temperature values, AI-enabled toggles per sensor, and editable min and max setpoints. * From the same view, users can search, filter by group, flag bottlenecks, and save custom sensor groups or create trends — the same capabilities as the map view.
### BackOffice & Integration - Partners #### **Integrations** * **Fabege** — Integration with write and discovery capabilities significantly improved. * **Siemens Building X** — Discovery enriched with point-group tags and improved HVAC tag aliases for better SignalPosition mapping. * **Propeye** — Historical read support added. #### **AI Control Page** * A new diagnostic view in BackOffice highlights and helps debug AI Control configuration issues per building. #### **Signal History Gap-fill** * Preview and insert missing data gaps in signal history directly from BackOffice. * Useful when BMS data readings have been faulty, or to upload historical energy meter data essential to evaluations. # March 2026 **Version 2026.3** *** ### Highlights This release introduces AI vs. Reference view to compare AI optimization performance against a baseline period, with outdoor temperature normalization and data quality indicators. We also upgraded CO2 Detailed, showing concrete ventilation runtime savings opportunities per building. Edit Signals gets a significant upgrade, now displaying your system's own naming alongside Myrspoven's standard positions. On the integration side, we complete the transition to the new `AiControlStatus` metadata scheme and add support for Siemens Building X, Fidelix Analytics, and improved Ouman and Fabege integrations. *** ### myPortal — Customers * Improved and refined Signal Viewer based on the new metadata scheme. * Signals now show your system's own naming alongside Myrspoven's standard labels, making it easier to recognize what you're looking at.
### BackOffice & Integration - Partners #### **Metadata scheme update** * Myrspoven is retiring the "Role" and "Classification" signal properties, replacing them with a single new field: `AiControlStatus` (Controlled / Observed / Disabled). {% file src="/files/SbG7DzbkceOoQe8RHR86" %} #### **Integrations** * **Fabege** — Integration improvements. * **Siemens Building X** — New integration added. * **Ouman** — Historical read support added. * **Fidelix Analytics** — Added as a supported integration source. ### Smart Control * Improved AHU control logic to prioritize heat recovery over direct heating, reducing energy waste. ### Insights #### **AI vs Reference** * New view comparing AI optimization performance against a reference period, with outdoor temperature normalization. * Data coverage indicators show how well outdoor/indoor temperatures are represented in both Myrspoven and reference data. * Quality indicators highlight when a baseline is insufficient vs. sufficient for a reliable comparison. * Select daytime window and period to focus on a specific time interval. * Filter by technical systems, sensors, and meters.
#### **CO2 Detailed** * New building summary showing opportunities to reduce ventilation runtime per building. * Provides actionable insights on reducing ventilation start/stop cycles or adjusting flow/pressure at specific times based on CO₂ level analysis.
# February 2026 **Version 2026.2** *** ### Highlights This release introduces the new **Insights** page, which provides clear analysis across **climate, signals, and ventilation**. It is powered by our evolving Data Platform, which we have enhanced over the past few months to deliver reliable, well-structured data. The release also brings increased reliability, performance, and data accuracy throughout the system.
*** ### myPortal — Customers * Faster, more responsive views for large datasets — especially Zone Assets in buildings with areas greater than 10,000 m². * Improved handling and display of sensor values, with clearer units and error messages. ### BackOffice & Integration - Partners * Added **Yggio** as a building data provider to support seamless integration. * Enhanced visualization of faulty data in the **Dataset Viewer**, including clear indicators for frozen periods. * Focused improvements to Zone Assets building integration tools, including the **Components Editor**. ### Smart Control * Greater robustness in optimization and training workflows, with improved handling of data issues — resulting in higher uptime and more consistent savings. * Improved handling of non-office periods, especially around end-of-year holidays when many systems are offline. Optimization now continues reliably during these periods instead of failing on missing data. ### Insights A new Insights menu with three views. These pages are still in development, and more views will be added soon. #### **Climate** * Display historical climate data (temperature, CO�₂ level, relative humidity) with up to one year of history. * Show climate thresholds to assess optimization performance.
#### **R/W Discrepancies** * Pinpoint deviations that require attention to ensure optimal energy savings results. * Tap to select Office hours / All hours.
#### **CO2 Detailed** * Information about CO₂ levels during the day/week. * Suggestions for changing start/stop times for ventilation based on CO₂ level analysis.
# December 2025 **Version 2025.2** *** ### Highlights * This release delivers improved reliability and reporting accuracy through enhanced optimizer stability, refined Golden Reports visuals, and more accurate sensor handling. * Users benefit from a smoother myPortal experience with better navigation, consistent temperature units, clearer time settings, and improved filtering. * The BackOffice also gains powerful diagnostic and monitoring capabilities, including a new Zone Asset Analysis tool. *** ### myPortal — Customers * **UI & UX** — loader on main page, quick improvements to insight filters, and sorting signals by value in Building Overview. * **Units & time** — user-selected temperature units (°C/°F) applied consistently; SignalHistory can now show local building time or UTC. #### **Fixes** * Sensor map now shows average signal value (not bottleneck value). * Tooltip fixes for temperature range variables. * Prevents table state resets when editing signal values. * Minimum humidity sensor values default to 0 to avoid misleading negative values. ### BackOffice & Integration - Partners * **Zone Asset Analysis tool** — new view for analyzing zone assets and relationships, to speed up diagnosing problems in complex buildings. * **Components** — improved signal position naming consistency and a number of maintenance updates.
### Smart Control * Multiple deployments with ongoing bug fixes and stability improvements to the optimization and training pipelines (general reliability and performance improvements). ### Golden Reports * Bar chart and baseline displays cleaned up to better reflect expected values. # November 2025 **Version 2025.1** *** ### Highlights * This release brings improvements to Golden Reports, especially valuable during the reporting season. * We have also added features that help manage periods of rapidly changing outdoor temperatures (typically in spring and autumn) and mitigate indoor climate issues by allowing ventilation to be used for heating. *** ### myPortal — Customers * Historical min-max view in prediction graphs for longer time spans. * Cleaned and stabilized the test suite, improving diagrams and visualizations. ### BackOffice & Integration - Partners * Removed an unused internal tool from the Process Viewer. * Removed changelog from BackOffice front page. * Case-insensitive matching in signal upload. * Better signal validation feedback and test coverage when uploading signal files during integration. ### Smart Control * Introduced heat-with-ventilation factor improvements that allow ventilation usage to support heating, which is relevant in some buildings. This brings settings flexibility and supports a better indoor climate. ### Golden Reports * Golden Reports dashboards support "no ventilation" components. * Golden Report uptime calculation corrected. * Golden Report dashboards: can pick end-of-month or first-next-month date. * Golden Report baseline and potential energy computation adjusted. {% file src="/files/iUrFh7spbXhhQwvOqObU" %} # Climate compensation Heating and cooling energy use is dominated by outdoor conditions. A cold January looks worse than a mild one even when the building runs identically. Climate compensation removes the weather component so periods can be compared on a like-for-like basis — month against month, winter against winter, and a building against itself before and after myCoreAI took control. ## What climate compensation does myCoreAI normalizes measured energy use against an outdoor-temperature reference. Instead of reporting raw kWh, it reports energy *per unit of heating demand*. Weather largely cancels out, and the remainder reflects the building and its control strategy. The principle is applied in three places: * **Per-building efficiency metrics** comparing AI-on against AI-off periods at equivalent outdoor temperatures. * **Regression-based savings estimates** for the heating season — energy is fit against outdoor temperature (or Heating Degree Days) separately for each control mode, and the gap between fits is the saving. * **Reference comparisons** against normalized consumption for similar buildings. ## Heating Degree Days (HDD) HDD is the standard normalization input. For each day, myCoreAI computes the gap between the building's base temperature (the outdoor temperature above which no heating is needed) and the day's average outdoor temperature, summing only the hours where outdoor temperature is below the base. A cold day produces a high HDD; a mild day produces a low one; a warm day produces zero. Energy divided by HDD expresses consumption per degree of heating demand — comparable across periods and weather conditions. Cooling Degree Days work symmetrically for district cooling. ## Resolution and accuracy | Resolution | Method | Result | | --------------- | -------------------------------------------- | --------------------------------------------------------------------------------- | | Hourly or daily | Regression against outdoor temperature / HDD | Cleanest normalization; short cold snaps do not distort the fit | | Monthly | National normalization factors | Works for top-level reporting; cannot isolate which week or system drove a change | Higher-resolution energy data is the single biggest improvement to climate-compensated reporting. ### Worked example A district-heated office in central Sweden consumes 180 MWh in a cold January and 140 MWh the following January under myCoreAI control. Raw figures suggest a 22% reduction. After myCoreAI normalizes both months against HDD using the building's base temperature, the second January's compensated consumption is 155 MWh — a 14% reduction once the milder weather is accounted for. The 14% figure is the one that reflects control performance; the 22% figure conflates weather and control. ## Where compensated figures appear * The **savings analysis** view in myPortal plots energy against outdoor temperature directly, with separate trend lines for AI-on and AI-off periods — a visual form of the same normalization, with weather on the x-axis. Raw, uncompensated consumption remains available in meter readings, invoices, and exports. Raw shows what the building consumed; compensated shows how it performed once weather is removed. # Golden reports The Golden Report is myCoreAI's recurring performance report for buildings under AI control. It shows what the building used, what myCoreAI influenced, what was saved, and how indoor climate held up. New reports are generated monthly. Use this page for the concepts shared across all energy sources. Use the sub-pages for source-specific heuristics, assumptions, and fallback values. ## What the report covers For each building, the Golden Report breaks energy use into: * **District heating** * **District cooling** * **Electricity** For each energy source, the report shows: * **Total consumption** during the period. * **myCoreAI-controlled share** during the period. * **Savings at uptime** and **potential savings**. The report also includes: * **Energy efficiency** metrics. * **Indoor climate** compliance for temperature and CO₂. ## Shared concepts across all energy pages These concepts mean the same thing in heating, cooling, and electricity. ### Uptime Uptime is the share of the period when myCoreAI actively controlled the relevant systems. Low uptime lowers two things: * The **myCoreAI-controlled share** * The **savings at uptime** ### myCoreAI-controlled share This is the part of the energy source myCoreAI could influence. It is calculated as the relevant HVAC energy use, weighted by uptime. ### Baseline The baseline is the estimate of how the building would have operated without myCoreAI. It is based on the building's historical control logic. That usually means supply curves, setpoints, and similar pre-AI behavior. ### Efficiency Efficiency measures how myCoreAI performed against the baseline over the same controlled hours. It is calculated at component level, then aggregated for the reporting period. ### Savings at uptime Savings at uptime is the energy avoided during the hours myCoreAI was in control. It is the difference between estimated baseline use and actual use over those same hours. ### Potential savings Potential savings is the full-period version of savings at uptime. It scales the realized savings to 100% uptime. Use it to judge the upside from better uptime. ### Auxiliary consumption Auxiliary consumption is energy use outside the heating, cooling, and ventilation loads myCoreAI controls. It is shown separately so controlled and non-controlled energy do not get mixed together. ### Indoor climate compliance Indoor climate compliance shows how often the building stayed within its configured comfort bounds. Read it next to savings. Lower energy use should not come at the cost of comfort. ## Energy-source pages The energy pages focus on heuristics, assumptions, and source-specific calculation details: * [Heating](/evaluation-and-reporting/golden-reports/heating) — district-heating splits, tap-water estimate, and component assumptions. * [Cooling](/evaluation-and-reporting/golden-reports/cooling) — district-cooling splits, `Other` estimate, and component assumptions. * [Electricity](/evaluation-and-reporting/golden-reports/electricity) — ventilation-electricity split and scope limits. ## Portfolio reports Portfolio reports add a layer above the per-building view: * Aggregated energy use across buildings. * Portfolio-level efficiency metrics. * Cross-building comparisons. ## AI insights Each building also gets AI-generated insights. These point to performance patterns and remaining opportunities. They support the numbers. They do not replace them. ## How to read your report Start with **uptime**. Low uptime explains low realized savings fast. Then compare **savings at uptime** with **potential savings**. The gap shows the value left on the table. Read **indoor climate** beside savings. Comfort still matters. Then check the relevant energy page for the assumptions behind the number. ## Improving accuracy The biggest accuracy gains come from better inputs: * **Higher-resolution energy data** * **Building-specific energy splits** * **A real tap-water figure** for district heating Share these with your Myrspoven representative. # Headline figures This page explains the headline figures at the top of the Golden Report. Use it to understand report coverage, active AI control, and what the summary numbers do and do not include. For shared report concepts like uptime, baseline, efficiency, and savings, see [Golden reports](/evaluation-and-reporting/golden-reports). ## Portfolio coverage **Total building area.** The combined floor area of every building included in this report. This is the denominator behind any per-m² figure you see later on. **Complete energy data per energy type.** The share of total building area for which we have usable energy data, broken down by energy source (district heating, district cooling, electricity). A building only counts toward this figure if its data for that source is complete enough to feed the report's calculations. If complete coverage for a given energy source is low, the consumption and savings figures in that section of the report are based on a smaller subset of buildings than the headline total area suggests. Read those numbers with that caveat in mind. ## AI coverage **Active systems.** The number of building systems — typically air handling units, but also other controllable subsystems — that myCoreAI is actively writing setpoints to, compared to the total number of systems integrated with Myrspoven. The integrated total is the upper bound: it covers everything we can see, including systems that are connected for monitoring only. A gap between "active" and "integrated" usually points to systems that are connected for monitoring but have not yet been handed over for control. It's a useful starting point for a conversation with your Myrspoven representative if you'd like to expand myCoreAI's footprint. ## Per-energy-source figures Headline figures that are specific to a single energy source — consumption, the myCoreAI-controlled share, savings at uptime, and potential savings — are explained on the energy-source pages, because the methodology differs slightly between them: * [Heating](/evaluation-and-reporting/golden-reports/heating) * [Cooling](/evaluation-and-reporting/golden-reports/cooling) * [Electricity](/evaluation-and-reporting/golden-reports/electricity) ## A note on assumptions Several headline and per-source figures rely on default assumptions — the share of electricity that powers ventilation, the split of district heating between heating circuits and AHUs, the tap-water estimate, and so on. The energy-source pages list the defaults they use. If you have building-specific figures for any of these, share them with your Myrspoven representative and we'll use yours instead of the defaults. # Report metrics This page explains the main metrics used in the Golden Report and in myPortal. Use it to understand what each reported metric measures and how to read it. ## Reported metrics Customer-facing metrics fall into three groups: energy used and saved, control reliability, and indoor climate. ### Energy and savings * **Total consumption** — energy used during the reporting period, broken down per source (district heating, district cooling, electricity). * **myCoreAI-controlled share** — portion of consumption falling within hours myCoreAI was actively running, weighted by uptime. * **Savings at uptime** — measured savings against a baseline of how the building would otherwise have been operated, over the hours myCoreAI was in control. * **Potential savings** — the same figure scaled to 100% uptime. Shows the gap between realized savings and what is available. * **Energy efficiency** — normalized efficiency per energy source. Enables comparison of a building against itself over time and against reference data. * **Auxiliary consumption** — energy use that is not heating or cooling, reported separately so it does not mix into the source breakdown. ### Control reliability * **Uptime** — share of the reporting period during which myCoreAI was actively controlling the building. Savings only describe the hours covered by uptime. ### Indoor climate * **Temperature compliance** — share of time indoor temperatures stayed inside the building's configured comfort bounds. * **CO₂ compliance** — same, for CO₂ where measured. Comfort bounds are configured per building. Compliance figures are reported alongside savings: savings at the cost of comfort are not savings. ## Calculation Methodology differs per energy source. District heating, district cooling, and electricity each carry their own assumptions, default splits, and fallback constants. The per-source pages under the Golden Report document each calculation. * **Baseline** — myCoreAI measures savings against a model of how the building would otherwise have been operated, not against the prior year's meter reading. The baseline accounts for weather and occupancy where data allows. * **Uptime weighting** — "myCoreAI-controlled share" and "savings at uptime" are weighted by the hours myCoreAI was in control. The "potential" variant strips that weighting. * **Defaults vs. building data** — without a building-specific figure for inputs like the heating-circuit / air handling unit (AHU) electricity split or tap-water consumption, myCoreAI uses a default. Supplying the real figure replaces the default and tightens the report. Confirm with Myrspoven. # Heating This page covers the source-specific heuristics and assumptions behind district heating in the Golden Report. ## Abbreviations * **AHU** — air handling unit ## What gets measured District heating is split into three buckets: * **Tap water** * **Other** * **Heating** `Heating` is the remainder after tap water and `Other`. `Other` covers district-heating use outside heating circuits and air handling units. ## How energy is distributed across uses The remaining heating energy is split between: * **Heating circuits** * **Air handling units** The default split is **60% heating circuits** and **40% air handling units**. If you have a better building-specific split, Myrspoven uses that instead. ### Tap-water estimate Tap-water use is estimated as the average of the **two lowest district-heating months**. This usually captures warm months, when space-heating demand is low. The estimate requires: * At least **8 months** of energy data * Data for **July and August** The estimate is capped at **5 kWh/m²/month**. If data is missing, tap water defaults to **1.6 kWh/m²/month**. ## What myCoreAI controls The myCoreAI-controlled share is the heating used by: * **Heating circuits** * **Air handling units in heating mode** That total is then weighted by uptime for the period. ## Source-specific calculation details Heating calculations are done separately for each component type. * **Heating circuits** use hourly averages, then aggregate across controlled circuits and time stamps. * **Air handling units** use hourly averages in heating mode, then aggregate across controlled units and time stamps. ## Improving accuracy Two inputs improve accuracy most: * Your real **tap-water figure** * Your real **heating-circuit / AHU split** Share them with your Myrspoven representative to replace the defaults. # Cooling This page covers the source-specific heuristics and assumptions behind district cooling in the Golden Report. ## Abbreviations * **AHU** — air handling unit ## What gets measured District cooling is split into three buckets: * **Cooling circuits** * **Air handling units in cooling mode** * **Other** `Other` covers cooling uses outside those HVAC components. ## How energy is distributed across uses A monthly `Other` amount is set aside first — either a figure you provide or the estimate described below. The remaining cooling energy is split between: * **Cooling circuits** * **Air handling units** The default split is **50% / 50%**. If you have a better building-specific split, Myrspoven uses that instead. ### Other-cooling estimate If you do not provide an `Other` figure, it is estimated as the average of the **two lowest district-cooling months**. This assumes those months mostly reflect non-HVAC cooling use. The estimate requires at least **8 months** of energy data. If less data is available, `Other` defaults to **0**. ## What myCoreAI controls The myCoreAI-controlled share is the cooling used by: * **Cooling circuits** * **Air handling units in cooling mode** That total is then weighted by uptime for the period. ## Source-specific calculation details Cooling calculations are done separately for each component type. * **Cooling circuits** use hourly averages, then aggregate across relevant components and time stamps. * **Air handling units** use hourly averages during cooling mode, then aggregate across relevant units and time stamps. ## Improving accuracy Two inputs improve accuracy most: * Your real **Other cooling** figure * Your real **cooling-circuit / AHU split** Share them with your Myrspoven representative to replace the defaults. # Electricity This page covers the source-specific heuristics and assumptions behind electricity in the Golden Report. ## What gets measured Electricity powers many loads in a building. This report only breaks out the share assumed to power **air handling unit fans**. The rest stays outside the myCoreAI-controlled electricity calculation. ## How energy is distributed across uses The default assumption is: * **50%** of total electricity goes to AHU fans * **50%** goes to everything else The second half includes lighting, plug loads, tenant equipment, and other non-controlled loads. If you have a better building-specific split, Myrspoven uses that instead. ## What myCoreAI controls The myCoreAI-controlled share is the electricity used by air handling units. That total is then weighted by uptime for the period. ## Source-specific calculation details Electricity calculations are performed at the AHU level. They use hourly averages, then aggregate across relevant components and time stamps. This methodology only covers **ventilation electricity**. It does not separately break out electricity used for heating or cooling, such as heat pumps or electric chillers. ## Improving accuracy The biggest improvement is a real **ventilation-electricity split** for the building. If you have sub-metered ventilation electricity, share it with your Myrspoven representative to replace the default. # Overview Reference material for developers and system integrators working with myCoreAI programmatically — connecting a building, exchanging data with the Myrspoven cloud, or building tooling on top of an existing integration. The section has two parts: a **narrative page** that explains which integration surface applies to a building and how it behaves, and the **OpenAPI reference** that documents the first-party Myrspoven AI-API endpoint by endpoint. **Integrators:** start with **Getting started with system integration** in the Integrations chapter — it explains how the edge, the Myrspoven cloud, and myCoreAI fit together before any endpoint detail becomes useful. **Tooling developers:** the Myrspoven AI-API exposes data and setpoint exchange over HTTP. The OpenAPI reference is authoritative for endpoints, request/response schemas, and authentication. ## Contents ### Myrspoven AI-API Explains the surfaces myCoreAI integrates over: the first-party Myrspoven HTTP API, the Myrspoven edge for on-premise BMS connectivity, and third-party BMS/SCADA vendor APIs. Covers authentication, environments, error handling, and rate limits. ### OpenAPI reference The machine-readable specification for the first-party Myrspoven AI-API — endpoints, parameters, schemas, and authentication. This is the authoritative source for endpoint-level detail; the narrative page provides the surrounding context. ## Out of scope * **BMS and vendor setup** (Schneider, Siemens, Web Port, etc.) lives in the **Integrations** chapter. * **Operational runbooks** — VPN credentials, server hardening, deployment procedures — are not public and are handled directly with Myrspoven. * **Internal tooling and pipelines** — Myrspoven's own build, test, and deploy process — is out of scope for partner documentation. ## Conventions * Times are ISO 8601 in UTC unless stated otherwise. * "The Myrspoven cloud" refers to the hosted backend; "the edge" refers to the on-premise component; "myCoreAI" refers to the AI agent running in the cloud. * Credentials in examples are placeholders. Working credentials are shared through a secure channel during integration. * For third-party APIs, vendor docs win for endpoint-level detail where they disagree with these pages. ## Getting help Report errors or gaps to Myrspoven. # Myrspoven AI-API myCoreAI exchanges data and setpoints with each building over one of a few surfaces — the first-party Myrspoven AI-API, a third-party BMS/SCADA vendor API, or the Myrspoven edge running on-premise. This page describes each surface and points to vendor documentation where a third party owns the API. For the conceptual data-flow model, see [Getting started with system integration](/integrations/overview). ## Available API surfaces ### Myrspoven AI-API (first-party) The Myrspoven cloud exposes a first-party HTTP API for exchanging building data with myCoreAI — reading current values and setpoints, discovering signals, writing setpoints, and uploading signal data. A connector on the building side integrates by calling this API; for example, the SmartConnector running in Schneider EcoStruxure Building Operation (EBO) uses it to read optimized setpoints and push building values back. The API is documented in the **OpenAPI reference** in this section, which is authoritative for endpoints, request/response schemas, and authentication. ### Third-party BMS/SCADA APIs Some BMS and SCADA platforms expose their own HTTP or vendor API — for example Siemens Desigo and Web Port. Where one is used, myCoreAI integrates over that API to discover points, read real-time and historical values, and write setpoints. The API surface — endpoints, schemas, parameter formats — is owned by the vendor, and **the vendor's documentation is the authoritative reference**. Integration scope, credentials, and enablement are arranged with Myrspoven during onboarding. ### Myrspoven edge (on-premise) Where connecting through a connector or a reachable vendor API isn't viable, the Myrspoven edge runs in the building owner's environment, connects to the BMS locally, and exchanges data with the Myrspoven cloud. The edge communicates outbound only — it pulls the setpoints and work it needs and posts values and results back — so no inbound firewall openings are required on the building side. ## Authentication and credentials The Myrspoven AI-API uses OAuth2 bearer tokens. A client ID and secret are issued by Myrspoven and shared through a secure channel — never over email or chat. The OpenAPI reference documents the token flow. Where a third-party vendor API requires authentication (typically a service account for write access), credentials are created on the vendor side and shared with Myrspoven through a secure channel. Read-only endpoints on some platforms operate without authentication. Writes always require a dedicated service account. Required scopes and permissions are specified by Myrspoven per integration during onboarding. ## Environments Integrations are configured per building against a single production environment. Changes that would affect a live building are coordinated with Myrspoven, and the safe way to test is to pause writes for the building under test. ## Error handling For the first-party Myrspoven AI-API, response codes and error schemas are documented in the OpenAPI reference. For third-party surfaces, error handling follows the conventions of the vendor that owns the surface. When myCoreAI cannot reach the BMS it stops writing setpoints and the BMS continues to run on its own logic — the building keeps operating normally; only optimization pauses until the connection is restored. ## Rate limits Read and write cadence is agreed per building during startup. Reads typically run every one to five minutes; setpoint writes run on a fixed cadence — typically every 15 minutes — stepping through the latest optimization output. Where a third-party vendor imposes its own rate limits, they are documented by the vendor and tuned in coordination with Myrspoven. ## Getting help For integration needs beyond the surfaces described here, contact Myrspoven directly. # AiApi ## GET /AiApi/Ping > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/Ping":{"get":{"tags":["AiApi"],"responses":{"200":{"description":"Success","content":{"text/plain":{"schema":{"type":"string"}},"application/json":{"schema":{"type":"string"}},"text/json":{"schema":{"type":"string"}}}}}}}}} ``` ## POST /AiApi/StoreSignalsDataBatch > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/StoreSignalsDataBatch":{"post":{"tags":["AiApi"],"requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/StoreSignalsDataBatchRequest"}},"text/json":{"schema":{"$ref":"#/components/schemas/StoreSignalsDataBatchRequest"}},"application/*+json":{"schema":{"$ref":"#/components/schemas/StoreSignalsDataBatchRequest"}}}},"responses":{"200":{"description":"Success"}}}}},"components":{"schemas":{"StoreSignalsDataBatchRequest":{"type":"object","properties":{"buildingId":{"type":"integer","format":"int32"},"type":{"type":"string","nullable":true},"signals":{"type":"array","items":{"$ref":"#/components/schemas/StoreSignal"},"nullable":true},"buildingDataProviderId":{"type":"integer","format":"int32","nullable":true}},"additionalProperties":false},"StoreSignal":{"type":"object","properties":{"key":{"type":"string","nullable":true},"name":{"type":"string","nullable":true},"signalData":{"type":"array","items":{"$ref":"#/components/schemas/StoreSignalData"},"nullable":true}},"additionalProperties":false},"StoreSignalData":{"type":"object","properties":{"dateUTC":{"type":"string","format":"date-time"},"value":{"type":"number","format":"double"}},"additionalProperties":false}}}} ``` ## GET /AiApi/GetSetPoints > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/GetSetPoints":{"get":{"tags":["AiApi"],"parameters":[{"name":"buildingId","in":"query","schema":{"type":"integer","format":"int32"}}],"responses":{"200":{"description":"Success"}}}}}} ``` ## GET /AiApi/GetWriteSignals > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/GetWriteSignals":{"get":{"tags":["AiApi"],"parameters":[{"name":"buildingId","in":"query","schema":{"type":"integer","format":"int32"}}],"responses":{"200":{"description":"Success"}},"deprecated":true}}}} ``` ## GET /AiApi/GetSignal > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/GetSignal":{"get":{"tags":["AiApi"],"parameters":[{"name":"buildingId","in":"query","schema":{"type":"integer","format":"int32"}},{"name":"signalName","in":"query","schema":{"type":"string"}}],"responses":{"200":{"description":"Success"}}}}}} ``` ## POST /AiApi/UpdateSignal > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/UpdateSignal":{"post":{"tags":["AiApi"],"requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/UpdateSignalRequest"}},"text/json":{"schema":{"$ref":"#/components/schemas/UpdateSignalRequest"}},"application/*+json":{"schema":{"$ref":"#/components/schemas/UpdateSignalRequest"}}}},"responses":{"200":{"description":"Success"}}}}},"components":{"schemas":{"UpdateSignalRequest":{"type":"object","properties":{"buildingId":{"type":"integer","format":"int32"},"signalId":{"type":"integer","format":"int32"},"update":{"$ref":"#/components/schemas/SignalProperties"}},"additionalProperties":false},"SignalProperties":{"type":"object","properties":{"min":{"type":"number","format":"double","nullable":true},"max":{"type":"number","format":"double","nullable":true}},"additionalProperties":false}}}} ``` ## GET /AiApi/GetBuilding > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/GetBuilding":{"get":{"tags":["AiApi"],"parameters":[{"name":"buildingId","in":"query","schema":{"type":"integer","format":"int32"}}],"responses":{"200":{"description":"Success"}}}}}} ``` ## POST /AiApi/UpdateBuilding > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/UpdateBuilding":{"post":{"tags":["AiApi"],"requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/UpdateBuildingRequest"}},"text/json":{"schema":{"$ref":"#/components/schemas/UpdateBuildingRequest"}},"application/*+json":{"schema":{"$ref":"#/components/schemas/UpdateBuildingRequest"}}}},"responses":{"200":{"description":"Success"}}}}},"components":{"schemas":{"UpdateBuildingRequest":{"type":"object","properties":{"buildingId":{"type":"integer","format":"int32"},"update":{"$ref":"#/components/schemas/BuildingProperties"}},"additionalProperties":false},"BuildingProperties":{"type":"object","properties":{"isAiActive":{"type":"boolean","nullable":true},"temperatureFocus":{"type":"number","format":"double","nullable":true},"ventilationFocus":{"type":"number","format":"double","nullable":true}},"additionalProperties":false}}}} ``` ## GET /AiApi/GetSignals > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/GetSignals":{"get":{"tags":["AiApi"],"parameters":[{"name":"buildingId","in":"query","schema":{"type":"integer","format":"int32"}},{"name":"kind","in":"query","schema":{"type":"string"}}],"responses":{"200":{"description":"Success"}}}}}} ``` ## GET /AiApi/GetCurrentObservablesValueByBuildingId > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/GetCurrentObservablesValueByBuildingId":{"get":{"tags":["AiApi"],"parameters":[{"name":"buildingId","in":"query","schema":{"type":"integer","format":"int32"}}],"responses":{"200":{"description":"Success"}}}}}} ``` ## GET /AiApi/GetMinMaxChanges > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/GetMinMaxChanges":{"get":{"tags":["AiApi"],"parameters":[{"name":"buildingId","in":"query","schema":{"type":"integer","format":"int32"}},{"name":"timestamp","in":"query","schema":{"type":"string","format":"date-time"}}],"responses":{"200":{"description":"Success"}}}}}} ``` ## GET /AiApi/GetAiSettings > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/GetAiSettings":{"get":{"tags":["AiApi"],"parameters":[{"name":"buildingId","in":"query","schema":{"type":"integer","format":"int32"}}],"responses":{"200":{"description":"Success"}}}}}} ``` ## POST /AiApi/UpdateAiSetting > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/AiApi/UpdateAiSetting":{"post":{"tags":["AiApi"],"requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/UpdateAiSettingsRequest"}},"text/json":{"schema":{"$ref":"#/components/schemas/UpdateAiSettingsRequest"}},"application/*+json":{"schema":{"$ref":"#/components/schemas/UpdateAiSettingsRequest"}}}},"responses":{"200":{"description":"Success"}}}}},"components":{"schemas":{"UpdateAiSettingsRequest":{"type":"object","properties":{"buildingId":{"type":"integer","format":"int32"},"aiSettingId":{"type":"integer","format":"int32"},"value":{"type":"integer","format":"int32"}},"additionalProperties":false}}}} ``` # LoadShift ## POST /LoadShift/UploadLoadShiftSignal > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/LoadShift/UploadLoadShiftSignal":{"post":{"tags":["LoadShift"],"requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/UploadLoadShiftSignalRequest"}},"text/json":{"schema":{"$ref":"#/components/schemas/UploadLoadShiftSignalRequest"}},"application/*+json":{"schema":{"$ref":"#/components/schemas/UploadLoadShiftSignalRequest"}}}},"responses":{"200":{"description":"Success"}}}}},"components":{"schemas":{"UploadLoadShiftSignalRequest":{"type":"object","properties":{"signalName":{"type":"string","nullable":true},"dataPoints":{"type":"array","items":{"$ref":"#/components/schemas/UploadLoadShiftSignalDataPoint"},"nullable":true},"batchTimestampUtc":{"type":"string","format":"date-time","nullable":true}},"additionalProperties":false},"UploadLoadShiftSignalDataPoint":{"type":"object","properties":{"timestampUtc":{"type":"string","format":"date-time"},"value":{"type":"number","format":"double","nullable":true},"values":{"type":"object","additionalProperties":{"type":"number","format":"double","nullable":true},"nullable":true,"deprecated":true}},"additionalProperties":false}}}} ``` ## POST /LoadShift/GetMostRecentBatch > ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"paths":{"/LoadShift/GetMostRecentBatch":{"post":{"tags":["LoadShift"],"requestBody":{"content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetMostRecentLoadShiftBatchRequest"}},"text/json":{"schema":{"$ref":"#/components/schemas/GetMostRecentLoadShiftBatchRequest"}},"application/*+json":{"schema":{"$ref":"#/components/schemas/GetMostRecentLoadShiftBatchRequest"}}}},"responses":{"200":{"description":"Success"}}}}},"components":{"schemas":{"GetMostRecentLoadShiftBatchRequest":{"type":"object","properties":{"signalName":{"type":"string","nullable":true}},"additionalProperties":false}}}} ``` # Models ## The BuildingProperties object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"BuildingProperties":{"type":"object","properties":{"isAiActive":{"type":"boolean","nullable":true},"temperatureFocus":{"type":"number","format":"double","nullable":true},"ventilationFocus":{"type":"number","format":"double","nullable":true}},"additionalProperties":false}}}} ``` ## The GetMostRecentLoadShiftBatchRequest object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"GetMostRecentLoadShiftBatchRequest":{"type":"object","properties":{"signalName":{"type":"string","nullable":true}},"additionalProperties":false}}}} ``` ## The SignalProperties object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"SignalProperties":{"type":"object","properties":{"min":{"type":"number","format":"double","nullable":true},"max":{"type":"number","format":"double","nullable":true}},"additionalProperties":false}}}} ``` ## The StoreSignal object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"StoreSignal":{"type":"object","properties":{"key":{"type":"string","nullable":true},"name":{"type":"string","nullable":true},"signalData":{"type":"array","items":{"$ref":"#/components/schemas/StoreSignalData"},"nullable":true}},"additionalProperties":false},"StoreSignalData":{"type":"object","properties":{"dateUTC":{"type":"string","format":"date-time"},"value":{"type":"number","format":"double"}},"additionalProperties":false}}}} ``` ## The StoreSignalData object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"StoreSignalData":{"type":"object","properties":{"dateUTC":{"type":"string","format":"date-time"},"value":{"type":"number","format":"double"}},"additionalProperties":false}}}} ``` ## The StoreSignalsDataBatchRequest object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"StoreSignalsDataBatchRequest":{"type":"object","properties":{"buildingId":{"type":"integer","format":"int32"},"type":{"type":"string","nullable":true},"signals":{"type":"array","items":{"$ref":"#/components/schemas/StoreSignal"},"nullable":true},"buildingDataProviderId":{"type":"integer","format":"int32","nullable":true}},"additionalProperties":false},"StoreSignal":{"type":"object","properties":{"key":{"type":"string","nullable":true},"name":{"type":"string","nullable":true},"signalData":{"type":"array","items":{"$ref":"#/components/schemas/StoreSignalData"},"nullable":true}},"additionalProperties":false},"StoreSignalData":{"type":"object","properties":{"dateUTC":{"type":"string","format":"date-time"},"value":{"type":"number","format":"double"}},"additionalProperties":false}}}} ``` ## The UpdateAiSettingsRequest object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"UpdateAiSettingsRequest":{"type":"object","properties":{"buildingId":{"type":"integer","format":"int32"},"aiSettingId":{"type":"integer","format":"int32"},"value":{"type":"integer","format":"int32"}},"additionalProperties":false}}}} ``` ## The UpdateBuildingRequest object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"UpdateBuildingRequest":{"type":"object","properties":{"buildingId":{"type":"integer","format":"int32"},"update":{"$ref":"#/components/schemas/BuildingProperties"}},"additionalProperties":false},"BuildingProperties":{"type":"object","properties":{"isAiActive":{"type":"boolean","nullable":true},"temperatureFocus":{"type":"number","format":"double","nullable":true},"ventilationFocus":{"type":"number","format":"double","nullable":true}},"additionalProperties":false}}}} ``` ## The UpdateSignalRequest object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"UpdateSignalRequest":{"type":"object","properties":{"buildingId":{"type":"integer","format":"int32"},"signalId":{"type":"integer","format":"int32"},"update":{"$ref":"#/components/schemas/SignalProperties"}},"additionalProperties":false},"SignalProperties":{"type":"object","properties":{"min":{"type":"number","format":"double","nullable":true},"max":{"type":"number","format":"double","nullable":true}},"additionalProperties":false}}}} ``` ## The UploadLoadShiftSignalDataPoint object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"UploadLoadShiftSignalDataPoint":{"type":"object","properties":{"timestampUtc":{"type":"string","format":"date-time"},"value":{"type":"number","format":"double","nullable":true},"values":{"type":"object","additionalProperties":{"type":"number","format":"double","nullable":true},"nullable":true,"deprecated":true}},"additionalProperties":false}}}} ``` ## The UploadLoadShiftSignalRequest object ```json {"openapi":"3.0.1","info":{"title":"AI API - Production","version":"v1"},"components":{"schemas":{"UploadLoadShiftSignalRequest":{"type":"object","properties":{"signalName":{"type":"string","nullable":true},"dataPoints":{"type":"array","items":{"$ref":"#/components/schemas/UploadLoadShiftSignalDataPoint"},"nullable":true},"batchTimestampUtc":{"type":"string","format":"date-time","nullable":true}},"additionalProperties":false},"UploadLoadShiftSignalDataPoint":{"type":"object","properties":{"timestampUtc":{"type":"string","format":"date-time"},"value":{"type":"number","format":"double","nullable":true},"values":{"type":"object","additionalProperties":{"type":"number","format":"double","nullable":true},"nullable":true,"deprecated":true}},"additionalProperties":false}}}} ``` # Overview Myrspoven publishes its security, privacy, and compliance posture at [trust.myrspoven.com](https://trust.myrspoven.com/). The portal is the single source of truth for commitments, certifications, and documentation available on request. This page points to it and outlines what the rest of the chapter covers. **Procurement and legal:** the trust portal holds the formal artifacts — ISO/IEC 27001:2022 certificate and scope, subprocessor list, security overview, privacy statement, questionnaire responses.\ **Technical operations and integrators:** this chapter covers the operational details that come up during onboarding and day-to-day use — building connectivity, myPortal access, incident handling. ## Where to look For formal artifacts, start at [**trust.myrspoven.com**](https://trust.myrspoven.com/). The portal is kept current; this documentation site is not. The trust portal covers: * **Certifications.** Myrspoven is certified to ISO/IEC 27001:2022. Certificate and scope are on the portal. * **Security overview.** Protection of customer data and building connections — hosting region, encryption, access control, incident handling. * **Privacy and data handling.** Personal data processing, retention, data subject rights, and the current product privacy statement. * **Subprocessors.** Third parties involved in delivering the service. * **Authentication and access controls.** Controls enforced by Myrspoven and those configurable by the customer. * **Vulnerability disclosure.** Reporting process and response expectations. * **Questionnaire responses.** Standard responses to common procurement questionnaires, available on request. ## What's in this chapter The pages in this chapter complement the trust portal with operational, customer-facing detail: * Building connectivity from a security standpoint — outbound-only connections, scoped setpoint writes, no inbound exposure of the Building Management System (BMS). * myPortal user access — per-user accounts, MFA, role-based permissions. * Handling of suspected security issues. The trust portal owns the formal posture. The pages below cover practical operation. ## Reporting a security concern Suspected security issues affecting customer data or buildings are reported to the Myrspoven representative immediately and flagged as urgent. Vulnerability reports follow the disclosure process linked on [trust.myrspoven.com](https://trust.myrspoven.com/).