Neuer Installer und neuer Fixer: übersichtliche Oberfläche und `iob docker`

[TbsJah]

0.10.1 (2026-09-20)

🚀 Features & Improvements

• (Feature) Heating State String: Added the configured heating curve parallel offset to the status string (e.g., "Offset +3 °C") for better transparency.

🐛 Bugfixes

• (Fixed) Heating State String: Corrected a logic issue where the status incorrectly displayed "Reduced 0 °C" during a scheduled reduction window, even if the actual reduction delta was set to 0 K. It now correctly displays "Normal (Timer)".

0.10.0 (2026-09-20)

🚀 Features & Improvements

• (Added) Low Flow Outage Alerts: Implemented active monitoring for "low flow" (Durchfluss) shutdowns in the outage history. The adapter now proactively sends a notification when the heat pump stops due to flow issues, as the controller usually treats these as soft outages rather than hard errors. Includes a 60-minute cooldown to prevent notification spam.
• (Improved) Admin UI: Integrated a direct recommendation link for the OpenDTA analysis tool into the description text of the Backup & Diagnostics tab.

🛠 Chores / Under the Hood

• (Fixed) ESLint Validation: Added missing JSDoc comments in the backup manager to resolve code validation warnings during development.

0.9.2 (2026-09-20)

🛠 Refactoring & Under the Hood

• DTA Backup Logic & UI: Restructured the "Backup & Diagnostics" settings tab. Removed obsolete text log buttons (procerr, procparam) which are blocked on newer firmwares. Reclassified the DTA manual download buttons into "Live DTA" (forces a new memory flush via /NewProc) and "Existing DTA" (fetches the last auto-saved historical log via /proclog which might be 2-3 hours old).
• Automated Backup Naming: The automated background backup job now dynamically prefixes the downloaded file as either dta_live_ or dta_history_[...] depending on which endpoint was successfully queried, clearly indicating the recency of the data.

0.9.1 (2026-09-20)

🚀 Features & Improvements

• (Added) Backup & Diagnostics Tab: Introduced a new tab in the adapter settings for easy access to heat pump data. Added a recommendation and link for the OpenDTA project to help users analyze their downloaded .dta files.
• Automated DTA Backup: Integrated a time-based background cron job to fully automate the retrieval and storage of DTA log files directly into the ioBroker file system.
• Admin UI Diagnostics: Added a dedicated "Backup & Diagnostics" tab in the adapter settings featuring manual download buttons for DTA files and system logs, along with a recommendation link for the OpenDTA analysis tool.
• Intelligent Firmware Fallback: Improved the DTA download logic to automatically detect the heat pump's firmware version. It seamlessly supports newer models (via /NewProc) while automatically falling back to legacy endpoints (/proclog, /procdta, or /Webclient/procdta) for older heat pumps.

0.9.0 (2026-09-20)

🐛 Bugfixes
🔴 IMPORTANT:

• (Fixed) HUP Dynamic Voltage Control: Fixed an issue where the digital relay state (HUPout) was queried instead of the actual nominal voltage (heating_system_circ_pump_voltage_nominal). This previously caused the calculation logic to produce target voltages below the hardware limit (e.g. 1.25V), triggering "less than min 3" validation warnings in the log.
• (Fixed) Admin UI Backup Links: Fixed multiple issues with the manual download links in the Backup tab. The IP address placeholder was corrected (from {host} to ${data.host}) to resolve correctly. Additionally, 404 Not Found errors on newer firmware versions were fixed by routing links to the root web directory (/procdta, /procparam, /procerr) instead of the legacy /Webclient/ directory.

🚀 Features & Improvements

• (Added) German Translations for Error & Outage Codes: Added full German translations for all entries in ERROR_CODES and OUTAGE_CODES.
• (Improved) Multi-Language History Logs: The error log (Fehlerspeicher) and outage history (Abschaltungen) now dynamically output descriptions and fallbacks in the configured adapter language (de / en).
• (Added) Backup & Diagnostics Tab: Introduced a new tab in the adapter settings for easy access to heat pump data.
• (Added) Manual Downloads: Added direct buttons to manually download the parameter backup (procparam) and error log (procerr) via the heat pump's web server. The manual DTA download was split into two distinct steps ("1. Trigger DTA generation" and "2. Download DTA Log") to better reflect the hardware behavior.
• (Added) Automated DTA Backup & Custom Storage: Implemented a new scheduling feature (cron) to automatically trigger and download live DTA logs, saving them directly to the ioBroker file system. The default storage location is the root directory of the adapter's file system, but users can specify a custom subfolder (e.g., backup) which is automatically created and sanitized.
• (Improved) Firmware Agnostic Backup Downloads: The automated DTA backup manager now features an intelligent fallback mechanism. It attempts to download logs from both the root directory (/procdta) and the legacy subfolder (/Webclient/procdta), ensuring compatibility across all Luxtronik firmware versions (V1, V2, V3).

🛠 Refactoring & Under the Hood

• (Development) TypeScript Definitions: Added missing @types/node-schedule to the dev dependencies to resolve ESLint type-checking errors during the build process.

[TbsJah]

@smolo @mrmorpheus
Wichtiger Hinweis zum HUP-Fehler:
In der Version 0.9.0 habe ich einen Bug behoben, der höchstwahrscheinlich die Ursache für die falschen HUP-Werte war. Lief bei euch in den letzten Tagen schon die Heizung und konntet ihr mal prüfen, ob die Werte jetzt passen?

[TbsJah]

Neue Funktion
Backup DTA Download

[Smolo]

@TbsJah sagte:

@smolo @mrmorpheus
Wichtiger Hinweis zum HUP-Fehler:
In der Version 0.9.0 habe ich einen Bug behoben, der höchstwahrscheinlich die Ursache für die falschen HUP-Werte war. Lief bei euch in den letzten Tagen schon die Heizung und konntet ihr mal prüfen, ob die Werte jetzt passen?

Hey,

gestern hatte er bei mir noch mal 0V vermerkt (0.81) mit dem Update (0.10.1) hat er jetzt wieder auf 10v korrigiert. Ich werde das beobachten.

[TbsJah]

0.11.0 (2026-09-21)

• Improvements:
  • Added global rounding to 2 decimal places for all calculated telemetry values (e.g., converting operating seconds to hours). This provides a cleaner ioBroker state tree and prevents excessively long floating-point numbers from cluttering history databases (like InfluxDB).

0.10.4 (2026-09-21)

• Update Readme

0.10.3 (2026-09-21)

• Features & Improvements:

  • Optimized the automated DTA backup process by directly utilizing the /NewProc file stream, eliminating unnecessary artificial delays and stabilizing the heat pump controller.
  • Streamlined the backup configuration: Removed the custom file path input to prevent file system conflicts. Backups are now securely stored in the universally accessible global 0_userdata.0/luxtronik_backups/ directory.
  • Added a clear information box in the adapter configuration, explaining where to find the generated backup files within the ioBroker UI.

• Fixes:

  • Fixed the persistent not an object of type "meta" crash during DTA backups. The storage architecture was migrated away from isolated adapter namespaces to the robust, native 0_userdata.0 global storage, completely resolving folder creation permission issues on existing instances.
  • Corrected the dynamic file naming logic (dta_live_... vs. dta_history_...) to accurately reflect whether a live memory dump or a fallback history log was downloaded.

0.10.2 (2026-09-21)

• 🚀 Features:

  • Implemented automated DTA file backup management with customizable cron schedules and automatic meta-directory creation in the ioBroker file system.

• 🛠 Chores / Under the Hood

  • Enhanced TypeScript type checking, resolved strict ESLint warnings, and upgraded Node.js type definitions to support Node.js version 22.
  • Optimized image scaling and layout rendering in jsonConfig.json for cleaner adapter settings presentation.

[Smolo]

@TbsJah sagte:

0.11.0 (2026-09-21)

• Improvements:
  • Added global rounding to 2 decimal places for all calculated telemetry values (e.g., converting operating seconds to hours). This provides a cleaner ioBroker state tree and prevents excessively long floating-point numbers from cluttering history databases (like InfluxDB).

0.10.4 (2026-09-21)

• Update Readme

0.10.3 (2026-09-21)

• Features & Improvements:

  • Optimized the automated DTA backup process by directly utilizing the /NewProc file stream, eliminating unnecessary artificial delays and stabilizing the heat pump controller.
  • Streamlined the backup configuration: Removed the custom file path input to prevent file system conflicts. Backups are now securely stored in the universally accessible global 0_userdata.0/luxtronik_backups/ directory.
  • Added a clear information box in the adapter configuration, explaining where to find the generated backup files within the ioBroker UI.

• Fixes:

  • Fixed the persistent not an object of type "meta" crash during DTA backups. The storage architecture was migrated away from isolated adapter namespaces to the robust, native 0_userdata.0 global storage, completely resolving folder creation permission issues on existing instances.
  • Corrected the dynamic file naming logic (dta_live_... vs. dta_history_...) to accurately reflect whether a live memory dump or a fallback history log was downloaded.

0.10.2 (2026-09-21)

• 🚀 Features:

  • Implemented automated DTA file backup management with customizable cron schedules and automatic meta-directory creation in the ioBroker file system.

• 🛠 Chores / Under the Hood

  • Enhanced TypeScript type checking, resolved strict ESLint warnings, and upgraded Node.js type definitions to support Node.js version 22.
  • Optimized image scaling and layout rendering in jsonConfig.json for cleaner adapter settings presentation.

Bei der Release häufig kommt nicht mal NPM hinterher ^^

Update auf 0.11 ist heute Morgen eingespielt worden. Danke.

[TbsJah]

Ja, stimmt schon 😂
Aber jetzt erst einmal alle Fehler behoben (welche ich gefunden hatte)
Und Erweiterungen eingefügt

[Smolo]

Ich hab grad noch was gefunden^^ allerdings keine Zeit das per bei GitHub zu dokumentieren das geht erst wieder in 2-3 Tagen. Die neue Funktion für /proclog etc. funktioniert bei meiner WP nicht hier kommt nur ein 404 HTTP. Keine Ahnung ob die Funktion in V3.89.4 fehlt oder das gerätespezifisch ist?

[TbsJah]

Sollte nicht fehlen
eventuell anderer Aufruf

Was eigentlich immer gehen sollte ist http://IP_VON_LWP/NewProc bzw http://IP_VON_LWP/proclog (das ist aber dann -3h)

[Smolo]

@TbsJah sagte:

Sollte nicht fehlen
eventuell anderer Aufruf

Was eigentlich immer gehen sollte ist http://IP_VON_LWP/NewProc bzw http://IP_VON_LWP/proclog (das ist aber dann -3h)

Sehr seltsam.

Im Browser Funktioniert "NewProc" bei "proclog" kommt allerdings 404.

Wenn ich im Adapter NewProc verwende sag mir Edge allerdings "...kann nicht sicher herunter geladen werden."

[Chriz]

Hey @tbsjah

Vielen vielen Dank für das erneuern des Adapters.

Ich habe im alten Adapter von UncleSam eigentlich immer nur die Datenpunkte für den WW Sollwert und WW Hysterese mit einem kleinen JavaScript verändert.

Nun ist es so das ich in deinem Adapter im Log, bei jedem Schreibvorgang, Fehler bekomme:

luxtronik2-controller.0
2026-09-29 17:31:45.970	error	Failed to finalize downstream state change command event pipeline execution loop: Timeout writing TCP parameter 74.

luxtronik2-controller.0
2026-09-29 17:31:40.669	error	Failed to finalize downstream state change command event pipeline execution loop: Timeout writing TCP parameter 105.

Eine weitere Auswirkung ist dass der Luxtronik Controller anscheinend neu startet. per Webinterface verliere ich dann nämlich für 1min die Verbindung.

Die Werte werden vom Script in die Datenpunkte geschrieben
Dann springen die Werte aber nach ein paar Sekunden wieder zurück zum Ursprungswert, um dann bei dem vermutlichen Reglerneustart doch den Wert vom Script anzunehmen. Gleiches gilt bei händischem Schreiben der Werte.

Ich vermute also das die WP Steuerung bei jedem schreiben der Werte einen Neustart durchführt. Das würde auch erklären warum er heute jedesmal beim Schreiben von Werten die thermische Desinfektion gestartet hat. Diese ist nämlich auf Dienstag eingestellt und da der Regler neu startet denkt er vermutlich das er noch desinfizieren muss obwohl das gerade geschehen ist. Habe die thermische Desinfektion nun auf Mittwoch gelegt und damit war erstmal gut. Wobei mich das Problem natürlich weiterhin beschäftigt.

Vielleicht könntest du ja mal drauf schauen.
Hier mal ein paar Eckdaten:

Von deinem Adapter selbst habe ich alle Funktionen ausgeschaltet, da ich nur die Datenpunkte brauche und den Rest über mein Javascript steuere.

Hast du, oder auch gern jemand anderes, eine Idee was das ist bzw. wie ich den Adapter ohne Fehler zum laufen bekomme?

Vielen Dank schon jetzt, allein fürs Lesen ;)

[TbsJah]

@Chriz sagte:
Nun ist es so das ich in deinem Adapter im Log, bei jedem Schreibvorgang, Fehler bekomme:

luxtronik2-controller.0
2026-09-29 17:31:40.669	error	Failed to finalize downstream state change command event pipeline execution loop: Timeout writing TCP parameter 105.

Eine weitere Auswirkung ist dass der Luxtronik Controller anscheinend neu startet. per Webinterface verliere ich dann nämlich für 1min die Verbindung.

Der positive Punkt ist dass das lesen funktioniert und die Werte aktualisiert werden 👌
Das nächste Positive ist dass es mit dem alten Adapter von @unclesam auch funktioniert hat.
Also liegt es an meinem Adapter und nicht an deiner Anlage

Daher diese Vermutung
Der alte Luxtronik-Controller (V1.x) hat einen extrem schwachen, Single-Threaded-Netzwerkchip. Er kann strikt immer nur eine einzige TCP-Verbindung auf Port 8889 gleichzeitig verarbeiten.

Wie der alte Adapter es gemacht hat: Er hatte eine starre, globale Warteschlange. Es wurde alles hintereinander gemacht.

Der neue Adapter arbeitet asynchron. Es kann passieren, dass das regelmäßige Polling (updateData liest Werte) startet. Exakt in dieser Sekunde triggert die Takt-Optimierung oder der Nutzer einen Schreibbefehl (queueWrite). Der Adapter öffnet einen zweiten TCP-Socket, während der erste noch offen ist. ZACK! Die Steuerung der Wärmepumpe ist überfordert, der Netzwerk-Stack stürzt ab und das gesamte Gerät rebootet.

Weil die Anlage rebootet, bricht die Verbindung wortlos ab und der Adapter wirft den Timeout writing TCP parameter Fehler aus.

Daher habe ich für 1.x Firmware Anlagen (und nur für die) das Abfragen und Schreiben strikt getrennt.
Ich hoffe dass das schon die Lösung ist 🙏🏻

Prüfe bitte die neue 0.11.2

• Features & Verbesserungen:

  • Legacy Schreib-Modus (V1.x): Neue Option in den Verbindungseinstellungen für alte Wärmepumpen (Firmware V1.x). Dieser Modus verhindert den Fehler Timeout writing TCP parameter bei Controllern, die nach einem Schreibbefehl keine Netzwerk-Bestätigung (ACK) zurücksenden.
  • Dynamischer Hardware-Schutz: Der Adapter erkennt nun die installierte Firmware und passt die Pausenzeiten beim Schreiben dynamisch an (500ms für alte V1.x Anlagen, schnelle 100ms für moderne Anlagen).
  • Sicheres Runden von Werten: Alle Zahlenwerte, die an die Anlage gesendet werden, werden nun strikt zu Ganzzahlen gerundet. Dies verhindert Speicherfehler und Abstürze bei alten Controllern, die keine Fließkommazahlen verarbeiten können.
  • Visibility-Filter Hinweise: Der Hilfetext für das automatische Ausblenden nicht unterstützter Parameter wurde angepasst, um V1/V2-Nutzer vor Timeout-Fehlern zu warnen.

• Fehlerbehebungen (Bugfixes):

  • Wärmepumpen-Abstürze behoben: Es wurde ein globaler Lock zwischen dem Lese-Zyklus (Polling) und der Schreib-Warteschlange eingebaut. Lese- und Schreibvorgänge können sich nun nicht mehr überschneiden. Dies verhindert fatale Socket-Kollisionen, die alte V1.x Anlagen zum Absturz und Neustart gezwungen haben.
  • Objekt-Bereinigung repariert: Das Löschen von verwaisten Datenpunkten beim Adapter-Start erfolgt nun sequenziell statt parallel. Dadurch wird die ioBroker-Datenbank nicht mehr überlastet und alte Datenpunkte verschwinden zuverlässig aus dem Objektbaum.

[Chriz]

Danke für die ausführliche Nachricht! Top.

So habe ich deinen Adapter installiert, das führte aber zu Version 0.12.1.
Kann ich davon ausgehen dass das auch i.O. ist?
Ich bin nämlich zu doof eine bestimmte Version zu installieren. Weder per Github noch NPM hab ich es hinbekommen. Gemini meinte dann ich soll es machen wie im Screenshot. Nur so bin ich überhaupt an deinen Adapter rangekommen ;-)

Edit:
Hat leider nicht funktioniert, ein manuelles Schreiben des WW Sollwertes hat wieder die gleichen Fehler produziert.

luxtronik2-controller.0
2026-09-30 15:49:49.533	error	Failed to finalize downstream state change command event pipeline execution loop: Timeout writing TCP parameter 105.

Auch das Webinterface "lost connection". Also gehe ich da auch von einem Reglerneustart aus. :(

[TbsJah]

Mist!
Bei dem alten Adapter hatte es aber funktioniert? Wie?
Passiert das bei allen Werten?

[TbsJah]

@chriz noch eine Bitte
Bitte installiere über NPM oder über ioBroker direkt
Nicht über Datei oder GitHub! Dann kann ich bereits eventuelle Fehler bei der Installation ausschließen

Und noch einmal die Frage
Per UncleSam Adapter hat das Schreiben der Werte funktioniert? Wenn ja, wie hast du sie beschrieben

[TbsJah]

0.13.1 (2026-10-02)

• Fix (Circulation/ZIP): Fixed a bug where the Virtual_ZIP_Status datapoint would remain stuck on true when using external relays (e.g., Shelly), even though the hardware relay was correctly turned off. The state reset logic has been decoupled and is now guaranteed to execute, ensuring the ioBroker interface stays perfectly synchronized with the actual hardware state.

0.13.0 (2026-10-02)

• Bugfixes:
  • Critical DHW Target Fix: Fixed an issue where the hot water target temperature was incorrectly written to parameter 2 instead of 105. This resolves unexpected temperature jumps (e.g., to 65°C) and socket timeouts on various heat pump models.
  • Write Queue Timeout: Added a maximum wait timeout to the write queue lock for legacy V1.x firmware to prevent potential infinite loops during read-write collisions.
  • Backup Manager Multi-Instance Fix: The automated DTA backup cron job is now safely scoped to the specific adapter instance, preventing conflicts when running multiple heat pumps on the same ioBroker host.
• Under the Hood / Refactoring:
  • Centralized Typings: Completely refactored the TypeScript architecture by introducing a centralized LuxtronikAdapter interface (types.ts). Replaced all fragmented, local interfaces across sub-modules to ensure strict, project-wide type safety and better maintainability.

[TbsJah]

@chriz Das Thema hat mir keine Ruhe gelassen 🤦‍♂️
Bei der Überprüfung des kompletten Codes sind mir ein paar Sachen aufgefallen, die nun behoben sind. Hoffentlich löst die jetzige Version 0.13 damit dein Problem mit dem Schreiben.

Wenn nicht, habe ich ein TypeScript erstellt, mit dem du dich direkt im JS-Adapter mit der Wärmepumpe zum Testen verbinden kannst (komplett am Luxtronik-Adapter vorbei). Wichtig: Vor dem Ausführen unbedingt die Luxtronik-Instanz(en) stoppen, da sonst der Port blockiert ist!
Da finden wir dann hoffentlich schnell den Fehler.
Das Skript ist hier zu finden: Link

Spoiler

🛠 Troubleshooting / Error Analysis

Raw TCP Test Script (Test_Script.ts)

In rare cases (especially with older firmware versions like V1.x), connection drops or timeouts can occur when writing values (e.g., Timeout writing TCP parameter 105).

To determine whether the issue lies with the adapter or the heat pump itself, this repository includes an isolated test script (Test_Script.ts in the src folder). This script bypasses the adapter completely and communicates directly with the Luxtronik controller via raw TCP sockets. It tests read and write access by reading the hot water target value, slightly increasing it as a test, and immediately restoring the original value.

Execution in ioBroker:

1. 🛑 IMPORTANT: You must stop all running Luxtronik adapter instances in ioBroker (set them to "Red")! Older Luxtronik controllers only allow a single simultaneous network connection. If an adapter continues to run in the background, the port is blocked, and the script will inevitably run into a timeout.
2. Copy the content of the Test_Script.ts file into a new script in the ioBroker JavaScript adapter (select Type: TypeScript).
3. Adjust the HOST constant at the very top of the script to match the IP address of your heat pump.
4. Start the script and check the ioBroker log output.

Result Evaluation:

• ✅ SUCCESS: The script completes quickly and the heat pump acknowledges the write command. This means your system (and its firmware) accepts write commands without errors.
• ❌ TIMEOUT / ERROR: The script hangs during reading/writing or is rejected. This means the system physically refuses TCP communication. Common causes for this are blocked ports (by Loxone, FHEM, or other smart home systems), firmware protection mechanisms, or a crashed network card in the heat pump (a hard power reset of the heat pump often helps here). The adapter cannot bypass this deep-level network issue.
  

[Chriz]

@tbsjah
bitte entschuldige die späte Rückmeldung aber ich war nicht daheim.
Und auch vielen Dank für das extreme Engagement was du hier an den Tag legst, das ist nicht selbstverständlich und ich bin dir wirklich sehr dankbar.

Leider kommt auch mit der neuen Version der Fehler. Version ist v0.13.1 über NPM installiert. (komisch das es jetzt mit NPM auf Anhieb geklappt hat, letzte Woche, ging da gar nichts, da musste ich über Benutzerdefiniert gehen.

luxtronik2-controller.0
2026-10-05 12:56:43.022	error	Failed to finalize downstream state change command event pipeline execution loop: Timeout writing TCP parameter 105.

Ich probiere mal dein Script jetzt.

SO Script sagt es stimmt was nicht ;(

5.10.2026, 13:14:26.131	[info ]: javascript.0 (1019) script.js.LuxtronicTest: Compiling TypeScript source
5.10.2026, 13:14:30.031	[info ]: javascript.0 (1019) script.js.LuxtronicTest: TypeScript compilation successful
5.10.2026, 13:14:30.051	[info ]: javascript.0 (1019) script.js.LuxtronicTest: === START LUXTRONIK RAW TCP TEST ===
5.10.2026, 13:14:30.052	[info ]: javascript.0 (1019) script.js.LuxtronicTest: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
5.10.2026, 13:14:30.055	[info ]: javascript.0 (1019) script.js.LuxtronicTest: [READ] Verbunden. Sende Lese-Befehl (3003)...
5.10.2026, 13:14:30.067	[info ]: javascript.0 (1019) script.js.LuxtronicTest: [TEST] Aktueller Wert Parameter 105: 430 (43 °C)
5.10.2026, 13:14:30.067	[info ]: javascript.0 (1019) script.js.LuxtronicTest: [TEST] Versuche Testwert zu schreiben: 435 (43.5 °C)
5.10.2026, 13:14:30.070	[info ]: javascript.0 (1019) script.js.LuxtronicTest: [WRITE] Verbunden. Sende Schreib-Befehl (3002) für Parameter 105 -> Wert: 435
5.10.2026, 13:14:30.070	[info ]: javascript.0 (1019) script.js.LuxtronicTest: [WRITE] Paket gesendet. Warte auf ACK (Bestätigung)...
5.10.2026, 13:14:30.570	[info ]: javascript.0 (1019) script.js.LuxtronicTest: [WRITE] Legacy-Timeout (500ms) erreicht. Schließe Verbindung.
5.10.2026, 13:14:30.571	[info ]: javascript.0 (1019) script.js.LuxtronicTest: [TEST] Warte 2 Sekunden auf interne Verarbeitung der Luxtronik...
5.10.2026, 13:14:32.573	[info ]: javascript.0 (1019) script.js.LuxtronicTest: [READ] Verbunden. Sende Lese-Befehl (3003)...
5.10.2026, 13:14:37.572	[error]: javascript.0 (1019) script.js.LuxtronicTest: ❌ [READ TIMEOUT] Die Wärmepumpe antwortet nicht! Läuft der ioBroker Adapter noch im Hintergrund und blockiert den Port?
5.10.2026, 13:14:37.572	[error]: javascript.0 (1019) script.js.LuxtronicTest: [TEST ABBRUCH] Skript fehlgeschlagen: Lese-Timeout

Ich verstehe nicht warum ich Werte schreiben kann, die werden auch übernommen, aber beim schreiben geht der Regler in ein Reboot. Danach ist der Wert geschrieben, sowohl am Display des Reglers, wie auch in deinem Adapter sehe ich das.
Ich würde ja den Error sogar ignorieren, aber aus zwei Gründen kann ich es nicht:

1. ich weiß nicht ob der Regler es so toll findet zwei man täglich zu rebooten aufgrund dieses Schreibens der Werte.
2. Ich kann die Thermische Desinfektion dann nicht nutzen, denn der Regler denkt aus irgendeinem Grund, nach seinem Neustart, er muss die thermische Desinfektion noch starten. Diese hat er aber bereits nachts gemacht. An diesem Tag würde bei jedem Schreiben der Werte(ergo Reglerreboot) die Wärmepumpe eine neue Desinfektion starten

Man sieht es hier auch ganz schön in meinem Grafana Panel:

Nachts gegen 0Uhr startet die reguläre Desinfektion und um 7Uhr heute morgen wurde der Sollwert und die Hysterese umgestellt, darauf folgte eine erneute Desinfektion. Das macht er jetzt jedesmal wenn ich den Wert neu schreibe. Abbrechen kann ich es nur indem ich am Regler die Desinfektion für den Tag ausschalte.

Zum alten Adapter von UncleSam:
Beschrieben habe ich die Werte mit exakt dem gleichen Script, oder halt per Hand. Der Adapter hat aber dauerhaft Fehler produziert, die ich immer ignoriert habe und auch ignorieren konnte(da kein Reglerneustart).
Mein IOB Log ist aber riesig geworden dadurch.

Meine laienhafte Vermutung:
Beim Schreiben der Werte stürzt der Regler sofort ab, schafft es aber gerade so noch die Werte zu speichern.
Die Frage ist warum ist das so?
Im Display der Luxtronik steht dann übrigens auch "Please Wait". Ist aber wahrscheinlich nicht relevant oder?

Der Einzige Adapter der noch "Interesse" an Daten der WP hätte wäre EVCC, aber die WP ist dort nicht konfiguriert. Das kann es also auch nicht sein - Und müsste der UncleSam Adapter dann nicht auch für einen neustart sorgen, wenn hier noch irgendwas anderes mit reinspielt???

Webinterface habe ich auch nicht offen gehabt bei den Tests.

PS: Ich schreibe soviel um möglichst keine Infos auszulassen, ob die immer relevant sind weiß ich nicht. Sorry dafür :-/

[TbsJah]

Ich schau es mir heute Abend an
Bitte erst einmal nicht schreiben! Ein Neustart darf nicht passieren - das muss eine andere Ursache haben.

[TbsJah]

@Chriz sagte:

luxtronik2-controller.0
2026-10-05 12:56:43.022	error	Failed to finalize downstream state change command event pipeline execution loop: Timeout writing TCP parameter 105.

Meine laienhafte Vermutung:
PS: Ich schreibe soviel um möglichst keine Infos auszulassen, ob die immer relevant sind weiß ich nicht. Sorry dafür :-/

Top, da ist weder etwas Laienhaft noch zu viel geschrieben!

Ursache könnte sein das wir mit dem jetzigen Script der Anlage quasi die Tür vor der Nase zugeschlagen haben 🤦‍♂️

Spoiler

Warum stürzt dein Regler ab (und bei UncleSam nicht)?
Wenn wir einen Wert an die Wärmepumpe senden, warten wir (oder das Test-Skript) auf ein "Okay" (ACK) der Anlage. Die V1.9 Firmware ist extrem langsam und sendet dieses Okay oft nicht oder viel zu spät.

Unser Adapter / Skript: Wenn nach 500ms (oder 5 Sekunden) keine Antwort kommt, trennen wir die Verbindung hart (client.destroy()), um nicht hängenzubleiben. Dieses harte Trennen sendet ein TCP-RST-Paket (Reset) an die Anlage. Die alte Luxtronik-Firmware versucht in exakt diesem Moment, intern den neuen Wert zu speichern oder zu antworten, greift ins Leere, stürzt ab und startet komplett neu ("Please Wait").

Der alte UncleSam Adapter: Die Bibliothek, die UncleSam genutzt hat, hatte kein Timeout für das Schreiben einprogrammiert! Er hat den Wert gesendet und die Verbindung einfach auf ewig offen gelassen. Dadurch kamen im ioBroker zwar zig Fehlermeldungen (weil die Warteschlange irgendwann voll war), aber die Wärmepumpe durfte die TCP-Verbindung in ihrem eigenen, lahmen Tempo abbauen, weshalb sie nicht abgestürzt ist!

Wir simulieren jetzt genau dieses Verhalten, lassen die Verbindung nach dem Senden aber sanft ausklingen, anstatt sie abzuwürgen.

Bitte probiere dieses angepasste Skript aus (IP wieder eintragen). Es liest den Wert, schreibt den Testwert, schließt die Verbindung aber nicht hart, sondern lässt der Anlage alle Zeit der Welt, den Befehl in Ruhe zu verdauen.

import * as net from 'net';
import { Buffer } from 'buffer';

// ==========================================
// ⚠️️ HIER DIE IP DER WÄRMEPUMPE EINTRAGEN!
// ==========================================
const HOST = '192.168.178.x'; // <--- ANPASSEN
const PORT = 8889;

const CMD_READ = 3003;
const CMD_WRITE = 3002;
const PARAM_ID = 105; // Warmwasser-Sollwert

// --- Hilfsfunktion zum Lesen ---
function readParam105(): Promise<number> {
    return new Promise((resolve, reject) => {
        const client = new net.Socket();
        let dataBuffer = Buffer.alloc(0);
        let hasResolved = false;

        const timeout = setTimeout(() => {
            if (!hasResolved) {
                console.error('❌ [READ TIMEOUT] Die Wärmepumpe antwortet nicht!');
                client.destroy();
                reject(new Error('Lese-Timeout'));
            }
        }, 5000);

        client.connect(PORT, HOST, () => {
            console.log('[READ] Verbunden. Sende Lese-Befehl (3003)...');
            const buf = Buffer.alloc(8);
            buf.writeInt32BE(CMD_READ, 0);
            buf.writeInt32BE(0, 4); // Kein Wert beim Lesen
            client.write(buf);
        });

        client.on('data', (data) => {
            dataBuffer = Buffer.concat([dataBuffer, data]);
            
            if (dataBuffer.length >= 8 + (PARAM_ID + 1) * 4) {
                const cmd = dataBuffer.readInt32BE(0);
                if (cmd === CMD_READ) {
                    const rawValue = dataBuffer.readInt32BE(8 + PARAM_ID * 4);
                    hasResolved = true;
                    clearTimeout(timeout);
                    client.end(); // Sanftes Schließen (FIN) statt hartes Destroy (RST)
                    resolve(rawValue);
                }
            }
        });

        client.on('error', (err) => {
            console.error(`[READ ERROR] ${err.message}`);
            hasResolved = true;
            clearTimeout(timeout);
            client.destroy();
            reject(err);
        });
    });
}

// --- Hilfsfunktion zum Schreiben (SANFT) ---
function writeParamSoft(paramId: number, value: number): Promise<void> {
    return new Promise((resolve) => {
        const client = new net.Socket();
        let hasResolved = false;

        client.connect(PORT, HOST, () => {
            console.log(`[WRITE] Verbunden. Sende Schreib-Befehl für Parameter ${paramId} -> Wert: ${value}`);
            const buf = Buffer.alloc(12);
            buf.writeInt32BE(CMD_WRITE, 0);
            buf.writeInt32BE(paramId, 4);
            buf.writeInt32BE(value, 8); 
            
            client.write(buf, () => {
                console.log('[WRITE] Paket gesendet! Lasse Socket für die Wärmepumpe offen...');
                
                // Wir reißen die Verbindung NICHT ab. Wir beenden nur nach 3 Sekunden
                // den Befehl für den ioBroker, lassen den TCP-Socket für die Pumpe 
                // aber sauber ausklingen (client.end anstatt client.destroy).
                setTimeout(() => {
                    if (!hasResolved) {
                        console.log('[WRITE] Beende ioBroker-Wartezeit. Schließe Socket sanft.');
                        hasResolved = true;
                        client.end(); // <--- DAS ist der Lebensretter für V1.x!
                        resolve();
                    }
                }, 3000);
            });
        });

        client.on('data', (data) => {
            if (data.length >= 4 && data.readInt32BE(0) === CMD_WRITE) {
                console.log('[WRITE] Erfolgreiche Bestätigung (ACK) empfangen!');
                hasResolved = true;
                client.end();
                resolve();
            }
        });

        client.on('error', (err) => {
            console.error(`[WRITE ERROR] ${err.message}`);
            if (!hasResolved) {
                hasResolved = true;
                resolve(); // Wir crashen das Skript nicht
            }
        });
    });
}

// --- Hauptablauf ---
async function testLuxtronik() {
    try {
        console.log('=== START LUXTRONIK RAW TCP TEST (SOFT-MODE) ===');
        
        // 1. Ist-Zustand lesen
        const originalRaw = await readParam105();
        console.log(`[TEST] Aktueller Wert Parameter 105: ${originalRaw} (${originalRaw / 10} °C)`);

        // 2. Test-Wert generieren (+ 0,5 °C)
        const testRaw = originalRaw + 5; 
        console.log(`[TEST] Versuche Testwert zu schreiben: ${testRaw} (${testRaw / 10} °C)`);
        
        // 3. Test-Wert schreiben (Sanfte Methode)
        await writeParamSoft(PARAM_ID, testRaw);

        // 4. Kurz warten
        console.log('[TEST] Warte 3 Sekunden auf interne Verarbeitung...');
        await new Promise(r => setTimeout(r, 3000));

        // 5. Überprüfen, ob es geklappt hat
        const checkRaw = await readParam105();
        console.log(`[TEST] Neuer Wert Parameter 105 nach dem Schreiben: ${checkRaw} (${checkRaw / 10} °C)`);

        if (checkRaw === testRaw) {
            console.log('✅ ERFOLG! Wert akzeptiert!');
        } else {
            console.log('❌ FEHLER! Wert ignoriert.');
        }

        // 6. Originalwert wiederherstellen
        console.log(`[TEST] Stelle ursprünglichen Wert wieder her: ${originalRaw} (${originalRaw / 10} °C)`);
        await writeParamSoft(PARAM_ID, originalRaw);
        
        console.log('=== ENDE LUXTRONIK TEST ===');
    } catch (e: any) {
        console.error(`[TEST ABBRUCH] Skript fehlgeschlagen: ${e.message}`);
    }
}

testLuxtronik();

Führe dieses Skript bitte einmal aus (vorher wieder Adapter stoppen). Behalte das Display deiner Wärmepumpe im Auge. Wenn sich der Wert im Skript ändert und das "Please Wait" auf dem Display diesmal ausbleibt, dann haben wir das Problem zu 100 % isoliert und können exakt dieses sanfte Schließen direkt in die nächste Adapter-Version einbauen!