Monatsrückblick Juli / August 2026 ist online!

[TbsJah]

Aktuelle Test Version	0.7.3
Veröffentlichungsdatum	07.09.2026
Github Link	TbsJah/ioBroker.luxtronik2-controller
npm	iobroker.luxtronik2-controller

Beschreibung
Grundlage war der Luxtronik2 Adapter von @unclesam. Dieser ist aktuell etwas in die Jahre gekommen, bzw. hatte ich sehr viele Scripte drumherum gebaut, welche ich nun zu einem eigenen Adapter zusammengefasst habe.

Der Adapter läuft bei mir seit einiger Zeit stabil an meiner LWD50A, daher der Entschluss, ihn hier für alle zu veröffentlichen. Testen passiert natürlich auf eigene Gefahr!

Transparenzhinweis: Bei der Entwicklung und dem Code-Rewrite hatte ich Unterstützung von KI.

Dieser ioBroker-Adapter ermöglicht die lokale Steuerung und Überwachung von Wärmepumpen mit Luxtronik 2.x Steuerung (z. B. Alpha Innotec, Novelan). Der Adapter ist vollständig in TypeScript geschrieben.

Features

• Native TCP-Kommunikation: Direkte Verbindung zur Wärmepumpe ohne zusätzlichen Overhead.
• Verdichter-Schonung (Takt-Optimierung): Zusammenlegung von Heiz- und Warmwasserzyklen zur Reduzierung der Verdichterstarts.
• Integrierte Aktionen (Makros): Vordefinierte Steuerungslogiken für Zwangsheizen, Warmwasseranforderung und die Zirkulationspumpe (ZIP) inkl. automatischem Rückfall auf Standardwerte.
• Benutzerdefinierte Datenpunkte: Messwerte (Index 3004) und Parameter (Index 3003) können über die Adapter-Konfiguration hinzugefügt werden. Unix-Zeitstempel werden automatisch formatiert.
• Automatisches Objekt-Management: Abgewählte oder gelöschte Datenpunkte und leere Ordnerstrukturen werden bei einem Adapter-Neustart automatisch aus ioBroker entfernt.
• Benachrichtigungssystem: Fehlercodes der Wärmepumpe können direkt an Telegram oder das ioBroker-Benachrichtigungssystem gesendet werden.
• Bewegungsmelder-Kopplung: Möglichkeit zur bedarfsgesteuerten Aktivierung der Zirkulationspumpe über vorhandene ioBroker-Bewegungssensoren.
• ZIP Steuerung über externe Aktoren

Bilder

Spoiler

Changelog

Spoiler

0.7.3 (2026-09-07)

Bugfixes
-(Fixed) Timer Table Register Conflict: Resolved conflicting Luxtronik register IDs for Domestic Hot Water (DHW) Monday–Sunday schedules (WW_MoSo_Start1 to End5). These were previously mapped to registers 507–516 (colliding with Circulation timer registers) and have now been corrected to registers 406–415.

-(Fixed) Time-String Conversion on State Change: Fixed a parsing bug where manual updates to time strings (HH:MM / HH:MM:SS) on states marked with isDurationFormat or time-related roles were passed directly as strings instead of converting to seconds since midnight, preventing user-entered schedule values from persisting in the controller.

0.7.2 (2026-09-07)

Bugfixes

• (Fixed) Unintended Configuration Overwrites: Fixed a critical architectural flaw where the adapter blindly forced default values (e.g., hot water target temperature, heating curve) to the heat pump on every startup. The adapter is now 100% passive (read-only) upon installation until features are explicitly enabled.

• (Fixed) Strict Opt-In Logic: All internal condition checks for background automations (cycle optimization, ZIP optimization, idle resets) were refactored to strict opt-in logic (=== true), preventing unintended actions when settings have never been saved.

• (Fixed) Live Toggle for Cycle Optimization: Fixed an issue where the ioBroker switch Actions.Regelung_Aktiv was ignored during runtime. The optimization loop now evaluates this switch dynamically, allowing users to toggle the feature live via their dashboard.

• (Fixed) Hardware ZIP Timer Disable: Fixed a bug where a mismatched configuration key (zip_hardware_timer_disable instead of zip_lWP_aktiv) prevented the adapter from correctly disabling the hardware circulation pump timer for flash memory protection.

• (Fixed) "Heating after hot water" Reset: Restored missing logic that properly resets the "Heating after water" status back to false at the end of a cycle, preventing the system from getting stuck in this mode.

Features & Change

• (Changed) Forced DHW Safety Limit: Reduced the internal safety limit for temporary hot water target adjustments during forced DHW runs from 75°C to 70°C to better protect the system's high-pressure switch.

0.7.1 (2026-09-07)

Bugfixes

• (Fixed) Status Display: Fixed a logical evaluation bug where the operating state "Heating" (Code 0) was incorrectly overwritten and displayed as "No demand" (Code 5). Thanks to @michiproep for reporting!

• (Fixed) Temperature Values: Fixed a related issue where temperature readings of exactly 0 °C (e.g., average temperature, return target temperature, cooling release) were incorrectly replaced by internal fallback values (e.g., 1.5 °C).

0.7.0 (2026-09-04)

Features & Changes

• (Changed) Cycle Optimization & Forced Hot Water: To force a hot water cycle, the adapter now temporarily increases the hot water target temperature instead of modifying the hysteresis. This crucial safety improvement allows users to manually revert changes directly on the heat pump display without needing an installer password.
• (Changed) Disable default: Disabled reset to default values in idle mode by default on initial start
• (Removed) Hysteresis Protection: Removed all dynamic manipulations of the hot water hysteresis (e.g., during idle or active DHW cycles) to ensure installer-level settings remain untouched.
• (UI/Docs): Added detailed explanations and trigger rules for "Intelligent Cycle Optimization" and "Heating after hot water" directly to the admin configuration page.

Bugfixes

• Fixed adapter checker warning [W0066] by downgrading @types/node dependency to v22

0.6.6 (2026-08-31)

review / fix findings reported by claude based checker.
Extended minimum limit for temperature_outdoor_min from -20°C to -25°C
Lowered minimum allowed value for heating_curve_parallel_offset (base point) from 20°C to 15°C
Disabled dynamic cycle optimization / regulation by default on initial start

0.6.5 (2026-08-07)

• review / fix findings reported by claude based checker.

0.6.4 (2026-07-23)

• Refactoring

0.6.3 (2026-07-23)

Features & Enhancements

• External Actor Support for ZIP (100% Flash Safe): Added the ultimate hardware protection feature. Users can now configure a list of external actors (e.g., Shelly or Zigbee relays) via their object IDs in the Admin UI. When motion is detected, the adapter switches these relays directly, completely bypassing the heat pump and reducing Luxtronik EEPROM write cycles to absolute zero.
• External Actor Schedule Compliance: External ZIP actors now dynamically respect the Luxtronik ZIP time tables (Week, 5+2, or Individual days). Motion triggers will be cleanly ignored if they occur outside the permitted time windows, unless the user explicitly checks the "Disable Hardware ZIP Timers" option in the configuration.
• Hot Water Sync for External Actors: The adapter now automatically activates external circulation pump relays when the heat pump begins a hot water generation cycle, maximizing comfort at the tap with zero impact on flash memory wear.
• Global EEPROM Flash Protection (Read-Before-Write): Implemented a global interceptor for all hardware write commands (writePumpSafe). The adapter now caches the current heat pump parameters in real-time and strictly blocks any duplicate or redundant write requests before they are sent over the network.
• Automated Hardware-Safe ZIP Defaults: The adapter can now automatically enforce hardware-safe circulation pump schedules upon startup. Accounts for Luxtronik firmware behavior by intelligently setting the first start block to 00:01:00 (60 seconds) to prevent invalid zero-run rejections, while keeping ON-time at 0 min and OFF-time at 60 min.
• Admin UI - Flash Wear Statistics & Guidance: Expanded the ZIP configuration page with detailed educational information. Added hard data explaining that internal ZIP control causes between 4 and 14 physical write operations per activation, highly recommending the new external actor setup.
• Write Cycle Monitoring: Introduced two new virtual data points under System Info (write_cycles_today and write_cycles_total) to transparently track physical write operations sent to the heat pump. The daily counter automatically resets every night at midnight.
• Cooling Extension & Intelligent Status: Comprehensive integration of new cooling data points (e.g., cooling_status, cooling_configured, opStateCooling). Added the dynamically calculated opStateCoolingString.
• Admin UI - Notification Testing: Added a dedicated "Send Test Message" button to the configuration interface to easily verify Telegram and ioBroker Notification Center setups directly from the UI.
• Hardened ZIP Macro Execution: Reaffirmed and secured the ZIP demand-driven macro to exclusively use the deaeration program (Entlüftungsprogramm).
• New Flow Rate Datapoints: Added flow rate tracking for the heat source (flow_rate_heat_source, ID 173) and cooling (flow_rate_cooling, ID 254) to the state mapping.
• Extended Admin UI: All newly added cooling data points and the heat source flow rate can now be individually enabled or disabled via new checkboxes in the adapter configuration (jsonConfig.json).
• New Hardware Supported: Officially added the MSW2-9S heat pump to the model recognition (HP_TYPES).

Bugfixes

• Motion Sensor Cooldown Logic: Fixed an issue where the 10-minute anti-cycling cooldown for motion sensors was perpetually stuck when using external relays. The logic now correctly monitors the virtual Activate_Zip state's timestamp instead of the bypassed internal ZIPout state.
• Virtual State Reset: Fixed a bug where the Activate_Zip button/state remained true after an external relay timer expired, which broke subsequent cooldown calculations. It now cleanly resets to false when the run cycle finishes.
• External Actor State Detection: Fixed a logic flaw where the adapter incorrectly checked the internal heat pump state (ZIPout) instead of the external relay state to determine if the circulation pump was already running. It now dynamically checks getForeignStateAsync for configured actors, cleanly preventing redundant switch commands and allowing silent timer extensions if motion is re-detected.
• Timer Formatting in Objects: Fixed a bug where timer schedules (Heating, Hot Water, Circulation) were incorrectly displayed as raw seconds (e.g., 60 or 0). Applied the internal duration formatter (isDurationFormat: true) globally so all time tables natively and persistently display as HH:MM:SS (e.g., 00:01:00) in the ioBroker object tree.
• Admin UI i18n Compliance: Fixed missing language definitions (E5611) in the jsonConfig.json dropdown menus to strictly comply with the latest ioBroker repository checks.
• TypeScript/Linter Strictness: Fixed strictly typed linter errors (e.g., @typescript-eslint/no-floating-promises, no-redundant-type-constituents, and template literal typings) by correctly handling asynchronous database calls, replacing any with unknown, and strictly casting types.
• Missing Imports: Resolved compilation errors regarding missing helper functions (e.g., getDpPath) during module refactoring.
• Cooling Operating Hours: Fixed the hours_cooling datapoint. The value is now correctly read from real-time telemetry data (raw_value), resolving an issue where the timestamp "Jan 1, 1970" was incorrectly shown.
• Config Cleanup: Fixed an incorrect identifier in the admin UI (changed sync_Gerätezeit to sync_deviceTime) and removed unused/dead checkboxes.

Technical Changes (Under the Hood)

• Separation of Concerns (zipManager): Completely refactored the motion sensor and circulation pump logic. Extracted the event handling and startup initialization out of main.ts into zipManager.ts. It now also dynamically handles iterations over arrays of external actors.
• Network Queue Isolation: Extracted the core transmission queue (queueWrite, processQueue) from the main adapter class into rawFunctions.ts, achieving 100% isolation of TCP/WebSocket network logic from ioBroker state management.
• Comprehensive Code Refactoring (DRY): Created dedicated convert.ts and utils.ts modules to centralize time string formatting (timeStringToSeconds, formatTimerSecondsToTime) and generic helper functions (getNumber, delay).
• Global Time Refactoring: Centralized the duration and time calculation for status texts in the updateStatusStrings function.
• i18n Support for State Names: Updated the internal state definition (name: string | { en: string; de?: string }) to fully support translation objects, allowing natively translated datapoint names in the ioBroker object tree.

0.6.2 (2026-07-17)

Added

• Bilingual support (i18n): Full support for English and German (adapter settings, state names, dropdown menus, and dynamic status texts).
• Language selection: Added a new dropdown menu in the adapter settings to freely choose the preferred output language for the ioBroker object tree.
• Firmware 3.x compatibility: Implemented an intelligent fallback system that dynamically calculates the status texts (heatpump_state_string) and runtime (heatpump_duration) from the main operating state. This is required because modern Luxtronik controllers no longer transmit the old LCD text lines.

Fixed

• Incorrect heating state (Frost protection): Fixed an issue where a switched-off heating system was incorrectly displayed as "Frost protection". The code now evaluates the correct index for the heating operating state (opStateHeating / 125) instead of incorrectly calculating it via the parameter.
• Timer display: Restored the clean HH:MM:SS formatting in the ioBroker UI without the annoying "s" (seconds) by introducing an internal isDurationFormat flag.
• Timer glitch fixed: When the compressor is idle, 00:00:01 (1 second) was often incorrectly displayed. This is now cleanly filtered to 00:00:00.
• ioBroker Repo-Checker warnings: Added the missing write: true property to the timer table selection states (role: "level") to fix the E1011 error.

Technical

• Fixed ESLint warnings (dot-notation) for object properties.

0.6.1 (2026-07-17)

• Implemented fallback mechanism: Index 80 lc is used if 117-120 are empty.
  

[Susanne007]

Hallo zusammen,

herzlichen Dank für den neuen Adapter. Ich musste nun auch auf diesen umsteigen, da nach dem Firmwareupdate auf V3.92.1 der alte luxtronic 2.0 Adapter nicht mehr tut.

Ich habe aber gleich folgendes Problem: Der Adapter verändert mir meine eingestellte Heizkurve. Das möchte ich jedoch gar nicht. Kann man das irgendwie ausstellen?
Ich möchte generell nur "lesen" von meiner WP und erstmal nichts schreiben oder setzen.

Ich bekomme auch nach jedem Neustart des Adapters wie Warnung:
luxtronik2-controller.0
2026-08-27 22:53:57.558 warn State value to set for "luxtronik2-controller.0.Settings.06_SystemSettings.temperature_outdoor_min" has value "-22" less than min "-20"

Ich setzte dann wie von dir im anderen Thread beschrieben im Objekt-Editor das Limit auf -22. Dann hören auch die Warnungen im Log auf. Nach jedem Neustart ist der Wert aber wieder auf -20 und die Warnung kommt wieder.

[TbsJah]

@Susanne007 sagte:

Schau ich mir an
Deine Werte kannst du auch in der Konfig Seite setzen. Dann sollte nichts mehr überschrieben werden. oder erst einmal die Steuerung ausstellen

[Smolo]

@TbsJah sagte:

@Susanne007 sagte:

Schau ich mir an
Deine Werte kannst du auch in der Konfig Seite setzen. Dann sollte nichts mehr überschrieben werden. oder erst einmal die Steuerung ausstellen

Die Steuerung von Geräten sollte bei solchen Adaptern im Default immer deaktiviert sein um Probleme zu vermeiden.

Ich habe ihn grad bei mir Installiert und es schaut bezüglich Lesen ganz gut aus...Danke dafür :-) Allerdings gleich folgende Logmeldungen:

Roth ThermoTerra F6 (Sole Wärmepumpe)
MSW2-6S
V3.89.4

[TbsJah]

@Smolo sagte:
Die Steuerung von Geräten sollte bei solchen Adaptern im Default immer deaktiviert sein um Probleme zu vermeiden.

Stimmt, ist mir wohl für den eigenen Test durchgerutscht. 🤷🏼
Wird in der kommenden Version als Default mit aus gesetzt.

@Smolo sagte:
Ich habe ihn grad bei mir Installiert und es schaut bezüglich Lesen ganz gut aus...Danke dafür :-) Allerdings gleich folgende Logmeldungen:

Ich habe min Werte gesetzt für die Eingabe Werte.
Die kann ich noch weiter heruntersetzen.
Aber inwiefern macht eine Hysterese von 0,5 °C denn Sinn? Da läuft die Pumpe doch eigentlich nahezu durchgehend.

Kommt auch in der nächsten Version.
Instanz für den Adapter solange am besten auf Error stellen dann müllt dein Logo nicht zu.

[Smolo]

@TbsJah sagte:

@Smolo sagte:
Die Steuerung von Geräten sollte bei solchen Adaptern im Default immer deaktiviert sein um Probleme zu vermeiden.

Stimmt, ist mir wohl für den eigenen Test durchgerutscht. 🤷🏼
Wird in der kommenden Version als Default mit aus gesetzt.

Top

@Smolo sagte:
Ich habe ihn grad bei mir Installiert und es schaut bezüglich Lesen ganz gut aus...Danke dafür :-) Allerdings gleich folgende Logmeldungen:

Ich habe min Werte gesetzt für die Eingabe Werte.
Die kann ich noch weiter heruntersetzen.
Aber inwiefern macht eine Hysterese von 0,5 °C denn Sinn? Da läuft die Pumpe doch eigentlich nahezu durchgehend.

Meine Hysterese HR steht bei 1,5k (das ist bei meiner WP auch der Standardwert!) die Logmeldungen sind daher für mich nicht ganz einleuchtend. Ich kann mir höchstens vorstellen das es ein Problem wegen dem Nachkomma gibt und nicht wegen dem zu kleinen Wert.

Grundsätzlich solltest du da aber auch nicht eingreifen gegenüber der WP. Die Werte welche sie liefert solltest du auslesen wie Sie kommen d.h. die Wertebereiche sind auch entsprechend zu definieren. Ich würde hier lediglich viel zu große Werte oder Minusbereiche im Adapter ausschließen zwecks Fehleingaben. Speziell das automatische Übersteuern und unterschiedliche Wertebereiche sind keine gute Kombination ;-)

Nachtrag:

Deine 20 Grad vs. meiner gesetzten 18 Grad Rücklauf sind übrigens auch eine solche Thematik. Ich habe bei mir eine passive Kühlung integriert. Die WP Steuerung hat allerdings einen Bug in der installierten Version weil die Heizung bei Deaktivierung der Kühlung anspringt obwohl sie eigentlich deaktiviert ist und das kann ich nur mit dem niedrigeren Soll stoppen.

Kommt auch in der nächsten Version.
Instanz für den Adapter solange am besten auf Error stellen dann müllt dein Logo nicht zu.

Ich warte noch bis zur nächsten Version... wenn das soweit ist kann ich auch endlich meine WP Updaten

[TbsJah]

@Smolo sagte:
Meine Hysterese HR steht bei 1,5k (das ist bei meiner WP auch der Standardwert!) die Logmeldungen sind daher für mich nicht ganz einleuchtend.

Ein Komma sollte hier eigentlich absolut kein Problem darstellen, meine Anlage läuft beispielsweise problemlos auf 1,6 K.

Was mich an der Fehlermeldung allerdings stutzig macht, sind die Werte 0,81 und 1 bei der HUP. Entweder nutzt deine Solepumpe intern ein anderes Register (was ich mir bei demselben Regler kaum vorstellen kann), oder die Werte benötigen bei deinem Setup eine andere Konvertierung.

Könntest du dazu bitte ein Issue auf GitHub erstellen und zusätzlich deinen Dump (die Rohdaten) dort anhängen? Alternativ könntest du testweise eigene Datenpunkte für die im Log gemeldeten Warnungen anlegen, wie hier im Screenshot gezeigt:

Hier geht's zur Issue-Erstellung auf GitHub

@Smolo sagte:

Grundsätzlich solltest du da aber auch nicht eingreifen gegenüber der WP. Die Werte welche sie liefert solltest du auslesen wie Sie kommen ...

Noch eine kurze Anmerkung dazu, warum der Adapter hier meldet:
Ein Großteil der festgelegten Wertebereiche stammt direkt aus der offiziellen Dokumentation von Luxtronik – diese Grenzen sind also vom Hersteller bereits strikt vorgegeben. Andere Bereiche habe ich so definiert, wie sie in der Praxis für mich und meine Anlage Sinn ergeben, um Anlagenfehler zu vermeiden.

Ein Beispiel: Die HUP funktioniert hardwareseitig nicht mit weniger als 3V und lässt sich auch nicht anders einstellen. Der ZWE funktioniert hingegen überhaupt nur, wenn die HUP aktuell mit 7V läuft. Solche Abhängigkeiten sind leider nirgends offiziell dokumentiert. Da über den Adapter die Werte für den Regler durch den Anwender auch manuell gesetzt werden können, müssen (aus meiner Sicht) zwingend Grenzen etabliert werden, die weder unter- noch überschritten werden dürfen. Das dient rein dem Schutz vor bekannten Fehleingaben.

Wenn für bestimmte Konstellationen aber Bereiche erweitert oder angepasst werden müssen, meldet das einfach, dann passe ich es an! :)

@Smolo sagte:

Deine 20 Grad vs. meiner gesetzten 18 Grad Rücklauf sind übrigens auch eine solche Thematik. Ich habe bei mir eine passive Kühlung integriert. Die WP Steuerung hat allerdings einen Bug in der installierten Version weil die Heizung bei Deaktivierung der Kühlung anspringt obwohl sie eigentlich deaktiviert ist und das kann ich nur mit dem niedrigeren Soll stoppen.

Da muss ich kurz nachhaken, das habe ich nicht ganz verstanden: Meinst du hier einen echten Bug in der Steuerung bzw. der Firmware der Heizung selbst, oder vermutest du einen Bug in der Logik des Adapters?

[TbsJah]

Neue Version

0.6.6 (2026-08-31)

• review / fix findings reported by claude based checker.
• Extended minimum limit for temperature_outdoor_min from -20°C to -25°C
• Lowered minimum allowed value for heating_curve_parallel_offset (base point) from 20°C to 15°C
• Disabled dynamic cycle optimization / regulation by default on initial start

[Smolo]

@TbsJah sagte:

@Smolo sagte:
Meine Hysterese HR steht bei 1,5k (das ist bei meiner WP auch der Standardwert!) die Logmeldungen sind daher für mich nicht ganz einleuchtend.

Ein Komma sollte hier eigentlich absolut kein Problem darstellen, meine Anlage läuft beispielsweise problemlos auf 1,6 K.

Mit der neuen Version kamen jetzt keinerlei Fehlermeldungen mehr.

Was mich an der Fehlermeldung allerdings stutzig macht, sind die Werte 0,81 und 1 bei der HUP. Entweder nutzt deine Solepumpe intern ein anderes Register (was ich mir bei demselben Regler kaum vorstellen kann), oder die Werte benötigen bei deinem Setup eine andere Konvertierung.

Der Wert steht bei mir jetzt aktuell 3 und 7. Ich habe mal einen Historienwert drauf gelegt und beobachte das.

Könntest du dazu bitte ein Issue auf GitHub erstellen und zusätzlich deinen Dump (die Rohdaten) dort anhängen? Alternativ könntest du testweise eigene Datenpunkte für die im Log gemeldeten Warnungen anlegen, wie hier im Screenshot gezeigt:

Hier geht's zur Issue-Erstellung auf GitHub

Kannst du mir bezüglich Dumb auf die Sprünge helfen woher ich diesen beziehen soll? Ich schicke ihn dir dann gerne zu.

@Smolo sagte:

Grundsätzlich solltest du da aber auch nicht eingreifen gegenüber der WP. Die Werte welche sie liefert solltest du auslesen wie Sie kommen ...

Noch eine kurze Anmerkung dazu, warum der Adapter hier meldet:
Ein Großteil der festgelegten Wertebereiche stammt direkt aus der offiziellen Dokumentation von Luxtronik – diese Grenzen sind also vom Hersteller bereits strikt vorgegeben. Andere Bereiche habe ich so definiert, wie sie in der Praxis für mich und meine Anlage Sinn ergeben, um Anlagenfehler zu vermeiden.

Ein Beispiel: Die HUP funktioniert hardwareseitig nicht mit weniger als 3V und lässt sich auch nicht anders einstellen. Der ZWE funktioniert hingegen überhaupt nur, wenn die HUP aktuell mit 7V läuft. Solche Abhängigkeiten sind leider nirgends offiziell dokumentiert. Da über den Adapter die Werte für den Regler durch den Anwender auch manuell gesetzt werden können, müssen (aus meiner Sicht) zwingend Grenzen etabliert werden, die weder unter- noch überschritten werden dürfen. Das dient rein dem Schutz vor bekannten Fehleingaben.

Das ist vollkommen verständlich und korrekt. Komisch wird es nur wenn der Adapter von allein Werte ändert und man den Ausgangspunkt dann natürlich nicht kennt und auch nicht weiß ist das jetzt dauerhaft oder nicht. z.B. das Thema Zwangswarmwasser...im Code habe ich entnommen das er hier kurzfristig die Hysterse auf 1k setzt das ist doch korrekt oder?

Wenn für bestimmte Konstellationen aber Bereiche erweitert oder angepasst werden müssen, meldet das einfach, dann passe ich es an! :)

@Smolo sagte:

Deine 20 Grad vs. meiner gesetzten 18 Grad Rücklauf sind übrigens auch eine solche Thematik. Ich habe bei mir eine passive Kühlung integriert. Die WP Steuerung hat allerdings einen Bug in der installierten Version weil die Heizung bei Deaktivierung der Kühlung anspringt obwohl sie eigentlich deaktiviert ist und das kann ich nur mit dem niedrigeren Soll stoppen.

Da muss ich kurz nachhaken, das habe ich nicht ganz verstanden: Meinst du hier einen echten Bug in der Steuerung bzw. der Firmware der Heizung selbst, oder vermutest du einen Bug in der Logik des Adapters?

Nein das war auf die Firmware der Heizung bezogen. Ich hatte im Sommer den "lustigen" Effekt das die Heizung angesprungen ist wenn ich die Kühlung deaktiviert habe und das trotz der deaktivierter Heizung!

[TbsJah]

@Smolo sagte:

Kannst du mir bezüglich Dumb auf die Sprünge helfen woher ich diesen beziehen soll? Ich schicke ihn dir dann gerne zu.

Unter Actions - dann werden alle Werte für beide Register welche abgerufen werden können in das Log geschrieben

@Smolo sagte:

Thema Zwangswarmwasser...im Code habe ich entnommen das er hier kurzfristig die Hysterse auf 1k setzt das ist doch korrekt oder

Das stimmt, damit Heizen und Warmwasser während eines Verdichterstarts abgearbeitet werden. Der vorher eingestellte Werte wird nach Ablauf wieder eingestellt.
Das aber auch nur wenn die Regelung aktiv ist.

[Smolo]

@TbsJah sagte:

@Smolo sagte:

Kannst du mir bezüglich Dumb auf die Sprünge helfen woher ich diesen beziehen soll? Ich schicke ihn dir dann gerne zu.

Unter Actions - dann werden alle Werte für beide Register welche abgerufen werden können in das Log geschrieben

@Smolo sagte:

Thema Zwangswarmwasser...im Code habe ich entnommen das er hier kurzfristig die Hysterse auf 1k setzt das ist doch korrekt oder

Das stimmt, damit Heizen und Warmwasser während eines Verdichterstarts abgearbeitet werden. Der vorher eingestellte Werte wird nach Ablauf wieder eingestellt.
Das aber auch nur wenn die Regelung aktiv ist.

Ich finde das etwas gefährlich speziell weil manche nicht ins Installateurmenü kommen und dann im Fall der Fälle die Hysterese nicht zurückstellen können außer über deinen Adapter. Zusätzlich bekommt man das dann natürlich nicht mit das hier extern der Hysterse Wert verändert wurde.

Hast du dir mal die beiden Optionen angeschaut ob das Thema mit dem Extra Warmwasser zu regeln?`

[Smolo]

@TbsJah sagte:

@Smolo sagte:

Kannst du mir bezüglich Dumb auf die Sprünge helfen woher ich diesen beziehen soll? Ich schicke ihn dir dann gerne zu.

Unter Actions - dann werden alle Werte für beide Register welche abgerufen werden können in das Log geschrieben

LogMeldungen habe ich bisher keine mehr mit dem 0.66 Adapter. Soll ich dir den Dump trotzdem noch zuschicken?

[TbsJah]

@Smolo sagte:
Ich finde das etwas gefährlich speziell weil manche nicht ins Installateurmenü kommen und dann im Fall der Fälle die Hysterese nicht zurückstellen können außer über deinen Adapter. Zusätzlich bekommt man das dann natürlich nicht mit das hier extern der Hysterse Wert verändert wurde.

Hast du dir mal die beiden Optionen angeschaut ob das Thema mit dem Extra Warmwasser zu regeln?`

Vielen Dank für den berechtigten Einwand und die Screenshots! Das Argument mit dem passwortgeschützten Installateurmenü ist absolut valide.

Ich habe mir die beiden Funktionen ("Extra Warmwasser" und "Schnellladung") auf dem Regler natürlich schon genauer angesehen. Leider habe ich bisher keine Möglichkeit gefunden, diese speziellen Funktionen direkt per Code über die Schnittstelle zu provozieren.

Daher existiert aktuell der Workaround über die temporäre Parameteranpassung der Hysterese im Adapter. Dass hier extern eingegriffen wird, wird zur Nachvollziehbarkeit immerhin als Info im Log ausgegeben.

Um das Risiko bei einem eventuellen Adapterabsturz zu minimieren und das Ganze transparenter zu gestalten, werde ich für die nächste Version folgende Anpassungen umsetzen:

• ListenpunktBessere Dokumentation & Opt-in: Ich werde das Verhalten auf der Konfigurationsseite detaillierter beschreiben. Außerdem wird dieser Eingriff ein zusätzlicher, optionaler Punkt, den man bei aktiver Regelung erst explizit einschalten muss.

• ListenpunktSollwert statt Hysterese: Als technische Alternative könnte der Adapter einfach den Warmwassersollwert temporär erhöhen, anstatt die Hysterese anzupassen. Der große Vorteil: Sollte der Adapter während dieses Vorgangs tatsächlich abstürzen, kann der Anwender den Sollwert ganz einfach über das normale Benutzermenü direkt am Regler wieder korrigieren – ganz ohne Installateur-Code.

[TbsJah]

@Smolo sagte:
LogMeldungen habe ich bisher keine mehr mit dem 0.66 Adapter. Soll ich dir den Dump trotzdem noch zuschicken?

Wenn es jetzt sauber läuft, musst du dir die Mühe eigentlich nicht mehr machen 😊

Interessiert hätte es mich aus Entwicklersicht aber ehrlich gesagt schon, wie diese krummen Werte (gerade die 0,81 und 1 bei der HUP) überhaupt zustande gekommen sind. Falls du also mal zwei Minuten Zeit und Lust hast, kannst du mir den Dump gerne trotzdem per PN oder im GitHub-Issue anhängen – rein aus Neugier und um zu prüfen, ob bei deiner Firmware oder deinem Anlagentyp eventuell eine andere Skalierung oder Registerbelegung vorliegt.

Wenn für dich aktuell aber alles rund läuft, können wir es natürlich auch gerne einfach so belassen!

[Smolo]

@TbsJah sagte:

@Smolo sagte:
Ich finde das etwas gefährlich speziell weil manche nicht ins Installateurmenü kommen und dann im Fall der Fälle die Hysterese nicht zurückstellen können außer über deinen Adapter. Zusätzlich bekommt man das dann natürlich nicht mit das hier extern der Hysterse Wert verändert wurde.

Hast du dir mal die beiden Optionen angeschaut ob das Thema mit dem Extra Warmwasser zu regeln?`

Vielen Dank für den berechtigten Einwand und die Screenshots! Das Argument mit dem passwortgeschützten Installateurmenü ist absolut valide.

Ich habe mir die beiden Funktionen ("Extra Warmwasser" und "Schnellladung") auf dem Regler natürlich schon genauer angesehen. Leider habe ich bisher keine Möglichkeit gefunden, diese speziellen Funktionen direkt per Code über die Schnittstelle zu provozieren.

Eventuell hilft ein Dump vor und nach der Aktivierung der Option so das man die Flags vergleichen kann?

Daher existiert aktuell der Workaround über die temporäre Parameteranpassung der Hysterese im Adapter. Dass hier extern eingegriffen wird, wird zur Nachvollziehbarkeit immerhin als Info im Log ausgegeben.

Um das Risiko bei einem eventuellen Adapterabsturz zu minimieren und das Ganze transparenter zu gestalten, werde ich für die nächste Version folgende Anpassungen umsetzen:

• ListenpunktBessere Dokumentation & Opt-in: Ich werde das Verhalten auf der Konfigurationsseite detaillierter beschreiben. Außerdem wird dieser Eingriff ein zusätzlicher, optionaler Punkt, den man bei aktiver Regelung erst explizit einschalten muss.

• ListenpunktSollwert statt Hysterese: Als technische Alternative könnte der Adapter einfach den Warmwassersollwert temporär erhöhen, anstatt die Hysterese anzupassen. Der große Vorteil: Sollte der Adapter während dieses Vorgangs tatsächlich abstürzen, kann der Anwender den Sollwert ganz einfach über das normale Benutzermenü direkt am Regler wieder korrigieren – ganz ohne Installateur-Code.

Das hört sich auf jeden Fall besser an.

[TbsJah]

0.7.0 (2026-09-04)

Features & Changes

• (Changed) Cycle Optimization & Forced Hot Water: To force a hot water cycle, the adapter now temporarily increases the hot water target temperature instead of modifying the hysteresis. This crucial safety improvement allows users to manually revert changes directly on the heat pump display without needing an installer password.
• (Changed) Disable default: Disabled reset to default values in idle mode by default on initial start
• (Removed) Hysteresis Protection: Removed all dynamic manipulations of the hot water hysteresis (e.g., during idle or active DHW cycles) to ensure installer-level settings remain untouched.
• (UI/Docs): Added detailed explanations and trigger rules for "Intelligent Cycle Optimization" and "Heating after hot water" directly to the admin configuration page.

Bugfixes

• Fixed adapter checker warning [W0066] by downgrading @types/node dependency to v22

[TbsJah]

Sehr interessante Frage bezüglich dem Unterschied von den beiden Wasser Einstellungen
Link Github

[TbsJah]

0.7.2 (2026-09-07)

Bugfixes

• (Fixed) Unintended Configuration Overwrites: Fixed a critical architectural flaw where the adapter blindly forced default values (e.g., hot water target temperature, heating curve) to the heat pump on every startup. The adapter is now 100% passive (read-only) upon installation until features are explicitly enabled.

• (Fixed) Strict Opt-In Logic: All internal condition checks for background automations (cycle optimization, ZIP optimization, idle resets) were refactored to strict opt-in logic (=== true), preventing unintended actions when settings have never been saved.

• (Fixed) Live Toggle for Cycle Optimization: Fixed an issue where the ioBroker switch Actions.Regelung_Aktiv was ignored during runtime. The optimization loop now evaluates this switch dynamically, allowing users to toggle the feature live via their dashboard.

• (Fixed) Hardware ZIP Timer Disable: Fixed a bug where a mismatched configuration key (zip_hardware_timer_disable instead of zip_lWP_aktiv) prevented the adapter from correctly disabling the hardware circulation pump timer for flash memory protection.

• (Fixed) "Heating after hot water" Reset: Restored missing logic that properly resets the "Heating after water" status back to false at the end of a cycle, preventing the system from getting stuck in this mode.

Features & Change

• (Changed) Forced DHW Safety Limit: Reduced the internal safety limit for temporary hot water target adjustments during forced DHW runs from 75°C to 70°C to better protect the system's high-pressure switch.

0.7.1 (2026-09-07)

Bugfixes

• (Fixed) Status Display: Fixed a logical evaluation bug where the operating state "Heating" (Code 0) was incorrectly overwritten and displayed as "No demand" (Code 5). Thanks to @michiproep for reporting!

• (Fixed) Temperature Values: Fixed a related issue where temperature readings of exactly 0 °C (e.g., average temperature, return target temperature, cooling release) were incorrectly replaced by internal fallback values (e.g., 1.5 °C).

[TbsJah]

0.7.3 (2026-09-07)

Bugfixes
-(Fixed) Timer Table Register Conflict: Resolved conflicting Luxtronik register IDs for Domestic Hot Water (DHW) Monday–Sunday schedules (WW_MoSo_Start1 to End5). These were previously mapped to registers 507–516 (colliding with Circulation timer registers) and have now been corrected to registers 406–415.

-(Fixed) Time-String Conversion on State Change: Fixed a parsing bug where manual updates to time strings (HH:MM / HH:MM:SS) on states marked with isDurationFormat or time-related roles were passed directly as strings instead of converting to seconds since midnight, preventing user-entered schedule values from persisting in the controller.

[Smolo]

Ich habe eventuell einen Bug gefunden bin mir aber etwas unsicher ob es doch an etwas anderem lag. Ich habe letzte Woche die Hysterese Warmwasser auf 6k aktiviert hatte den Wert in die Historie gepackt. Als ich heute reingeschaut habe war er wieder bei 10k was mich extrem gewundert hat. Das einzige was die Logs vor einer Woche hergegeben hatten war die Tatsache das ich den Adapter zwischen Info / Silly umgestellt hatte. Gibt es eine Möglichkeit das der Adapter zuerst schreibt und danach einliesst und so eventuell einen alten Wert reinschreibt? Ich hatte den Wert nämlich direkt an der WP geändert und nicht über den Adapter und vorher war dieser Wert auf 10k eingestellt.