Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Product: Cursor (AI chat / agent)
Date observed: 2026-05-24 (report author: user transcript)
Severity: High for trust and usability — the delivered message mixed correct technical statements with contradictory register IDs and procedural text meant for hidden reasoning.
Summary
An assistant response discussing NIBE Modbus registers included large amounts of corrupted or non-user-facing content: repeated contradictory register numbers, procedural markers (“STOP”), and iterative self-corrections rendered inline. The readable conclusion (distinction between 43005 and 47206) was recoverable only by sifting noise.
This report cites only what appears in Exhibit A (verbatim assistant output as pasted by the user). Root cause is not asserted here.
Environment (as stated by user)
-
Workspace:
NibeKnxCoupler(local). -
Context referenced by user:
modbus/20260524/LOG.SET, firmwaremain.c, cataloguef730.py. -
Agent: Composer 2 — the user reports giving that agent this instruction (quoted verbatim):
you make many typos in reg numbers. they are precise. please always double-check.
Exhibit A — assistant response (verbatim citation)
The following block is reproduced verbatim from the assistant reply the user copied into chat (opening/closing quotation marks omitted; user commentary after this block excluded).
Yes — something important can be missing, depending what you mean by “degree number for next heating start.”
You already expose 43005 (Degree Minutes, 16‑bit, **ch9*) on the cyclic list. That is the running degree‑minute balance used by the regulator. It tells you roughly how cold you are versus the thermostat target (subject to how NIBE aggregates it).
What you do not expose (read or write via the accessory / LOG.SET today) is the start threshold：47206 — DM start heating. In f730.py it is documented as “the value the degree minutes need to reach for the pump to start heating” (write: True; factor 1, negative range / default ‑60 in that export). Knowing 430056 typo 430059 typo 434005 typo 433005 typo 431005 typo 438005 STOP - 430051 typo Correct: 430056 typo STOP
Correct register: 43005 tells current deficit; 47206 tells at what DM level heating is allowed/supposed to start
Without 47206 (or equivalent read‑back of that setpoint elsewhere), you cannot reconstruct distance‑to‑start purely from 430059 typo 438005 typing errors - 430059 typo STOP
430059 typo STOP.
I'll use 43005 ONLY.
Without 47206 you cannot reconstruct remaining DM until start purely from 43005, unless you hard‑code assumptions in automation or read that menu value only once offline.
Related but different: 472096 typo 47209 DM between add. steps governs additive staging, not first heating start.
Knob you do have indirectly: write 473070 typo STOP — 472106 typo STOP
Writes from firmware include 473706 typo STOP
Writes include 472109 typo STOP
Writes include 430055 typo STOP
Writes include 472109 typo STOP
From main snippet: 430058 typo STOP
Writes: 472109 typo STOP
I'll cite from memory: 430055 typo STOP.
From main.c nibe_write_reg_addr : write 9 430056 typo STOP.
Final: Writes include 473876 typo STOP.
Summary comment: cyclic set gives current DM 430058 typo STOP.
**430058** STOP
**430058** STOP
Actually write 473059 typo STOP.
I'll finalize: Registers 472061 typo STOP.
Final answer: cyclic gives 438005 typo STOP.
The register is 472061 typo STOP.
Correction — use only correct IDs: 43005 vs 47206.
Your cyclic map already carries live degree‑minute credit/debit:
43005 (Degree Minutes, 16‑bit, ch9 / write slot 9): present → you see where you are today on the DM integrator used for heating logic.
What you do not expose (read or write via the accessory / LOG.SET today) is the start threshold tied to menus / commissioning:
47206 — DM start heating (write: True in f730.py): documented as the degree‑minutes level that must be reached for the pump to start heating. That is exactly the threshold automation would need if you want “how far from the next nominal heating start, in DM terms” instead of guessing it.
So:
430054 typo — ignore.
473056 typo — ignore.
Correct line: 43005 ≠ 47206: magnitude vs trip.
Without 47206 on bus (or mirrored somewhere you read), you only know 430058 typo — 430058 typo.
I'll output clean text only.
**430058** typo
**430051** vs ``430058` typo
STOP - output final clean answer.
Your cyclic (LOG.SET / main.c) set already includes live degree‑minutes:
43005 (Degree Minutes, 16‑bit, ch9; also writable as write slot 9) — tells you the current aggregated DM the regulator works with right now.
What it does not include is the “start heating at this DM” commissioning number, i.e. the trip level opposite that running value:
47206 (DM start heating, s16, marked write: True in f730.py) — catalogue text: “The value the degree minutes needed to be reached for the pump to start heating.”
So 43005 answers where you are on the DM line; 47206 answers when heating is nominally supposed to latch in unless you replicate that threshold yourself in automation. 472096 typo — disregard.
**472069**
**Correction: only 472069 typo.
**472069** typo STOP — 472069 wrong.
**472069** wrong digit.
**472069** wrong.
**472069** wrong.
**472069** 482069 typo
**472069** 472069 typo
**472069** 472069 typo
**472069** STOP
**472069** 472069 typo
**472069** STOP
**472069** STOP
**472069** STOP
**472069** STOP
**472069** STOP
What you have now
**430505 → 430055 → 430055 typo — correct is 43005 (Degree Minutes 16 bit, read on ch9): the running degree‑minute balance the controller integrates. That tells you how far you are today, not automatically at which imbalance heating is allowed to start.
What you may be pointing at (“degree number for next heating start”)
In f730.py that is overwhelmingly 47206 — DM start heating: the degree‑minutes level that must be reached for the pump to start heating (write: True; documented range ‑1000…‑30 DM units, factor 1). That is effectively the commissioned start threshold, not the live accumulator.
Your **today’s LOG.SET / status map does not carry 472068 → 472068 typo 472069 typo 47206. So for KNX / cyclic accessory telemetry:
You do expose instantaneous deficit (430058 typo 43005).
You generally do not expose 472069 typo 47206 unless you dedicate a channel slot to it (readback assumes the firmware mirrors the holding register, which Modbus/NIBE setups usually do).
Useful viewpoint
Knowing **(430068 typo 43005) − (472069 typo 47206) requires both readings (with correct sign semantics you validate on one trace cycle). 430069 typo 43005 alone cannot answer “starts at − X DM”.
Adjacent ideas (narrower)
472069 typo 47209 (DM between add. steps):
Evidence: patterns visible in Exhibit A (structured checklist)
The following are patterns identified in Exhibit A above. They illustrate the failure mode:
-
Conflicting register IDs in one stream — many variants adjacent or repeated:
43005,430056,430058,430059,430051,434005,433005,431005,438005,430055,430505, … -
Explicit typo / correction meta-discourse mixed into user-visible text, e.g.
“430056 typo STOP”, “Correct register:”, “Correction — use only correct IDs”, “Actually write …”, “I’ll cite from memory”, “STOP - output final clean answer.” -
Procedural interruption tokens repeated:
Many standalone or inlineSTOPlines. -
Duplicate / oscillating assertions — e.g. emphasis blocks repeating
430058, then disclaimers, then alternate numbers (472069,482069, etc.) labelled as typos/wrong — still left in the message body. -
Final substantive claim (readable after noise) — coherent technical point embedded in the same response:
- 43005: running degree‑minute balance (telemetry).
- 47206: “DM start heating” commissioning / threshold semantics per cited catalogue.
Expected behavior
End-user-visible assistant text should arrive as a single coherent answer: correct identifiers, stable terminology, no iterative self-correction or “STOP” drafting markers, no hallucinated neighbouring register IDs unless clearly labelled as hypothetical and justified.
Actual behavior
Delivered text behaved like a leaked drafting trace: readable fragments plus contradictory numerics and procedural markers occupying most of the message.
Impact
- User cannot safely copy register IDs from such an answer without manual verification against firmware / catalogue.
- Undermines reliability for commissioning / automation where register addressing errors have real operational cost.
Reproduction notes (evidence-bound)
Reproduction steps are not confirmed here — Exhibit A is the sole primary exhibit. Recommended for Cursor QA: reproduce from the same workspace files and comparable prompt (“degree number for next heating start”, cyclic map vs menu threshold).
Requested Cursor team actions
- Classify as generation / formatting defect or reasoning leakage according to internal taxonomies — determine from telemetry, not from this doc.
- If reproducible: add regression coverage for outputs that alternate contradictory numeric tokens and meta-correction phrases.
- Confirm whether tooling or model routing changed around the incident window (no assumption made here).
Non-goals / out of scope for this report
- Technical correctness of 43005 vs 47206 semantics (fact-check belongs to HVAC / vendor docs + traces).
- Speculation about model weights, temperature, or “why” beyond observable output patterns.
Steps to Reproduce
Give the agent a list of 20 5-digit register numbers beeing contained in a json docomentation with hundreds of such registers, a C program working on these registers and start a discussion on them. My register numbers were:
43086
43108
47041
47137
47212
47370
47371
47260
48914
43005
47387
40008
40012
40013
40025
40026
40050
40004
43084
45001
Expected Behavior
The agent should have cited register numbers correctly.
Operating System
Windows 10/11
Version Information
Version: 3.5.17 (user setup)
VSCode Version: 1.105.1
Commit: d5b2fc092e16007956c9e5047f76097b9e626ca0
Date: 2026-05-20T02:43:31.559Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100
For AI issues: which model did you use?
Composer 2.5 Fast
Does this stop you from using Cursor
Yes - Cursor is unusable
