> For the complete documentation index, see [llms.txt](https://docs.myrspoven.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.myrspoven.com/troubleshooting/common-issues.md). # 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.md) 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.myrspoven.com/troubleshooting/common-issues.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.