Test Luxtronik2-Controller V0.22.x

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

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:

ich weiß nicht ob der Regler es so toll findet zwei man täglich zu rebooten aufgrund dieses Schreibens der Werte.
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 🤦‍♂️

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!

Chriz

@TbsJah

leider kommt auch mit dem Script "Please Wait" im Regler. Hab extra meine Frau davor gestellt als ich das Script gestartet habe. Denn ich müsste sonst einmal die Treppe runter bis in HWR rennen und schaffe das manchmal nicht schnell genug ;)

6.10.2026, 18:36:37.613	[info ]: javascript.0 (1007) script.js.LuxtronicTest: Compiling TypeScript source
6.10.2026, 18:36:37.621	[info ]: javascript.0 (1007) script.js.LuxtronicTest: source code did not change, using cached compilation result...
6.10.2026, 18:36:37.624	[info ]: javascript.0 (1007) script.js.LuxtronicTest: === START LUXTRONIK RAW TCP TEST (SOFT-MODE) ===
6.10.2026, 18:36:37.625	[info ]: javascript.0 (1007) script.js.LuxtronicTest: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
6.10.2026, 18:36:37.629	[info ]: javascript.0 (1007) script.js.LuxtronicTest: [READ] Verbunden. Sende Lese-Befehl (3003)...
6.10.2026, 18:36:37.640	[info ]: javascript.0 (1007) script.js.LuxtronicTest: [TEST] Aktueller Wert Parameter 105: 440 (44 °C)
6.10.2026, 18:36:37.641	[info ]: javascript.0 (1007) script.js.LuxtronicTest: [TEST] Versuche Testwert zu schreiben: 445 (44.5 °C)
6.10.2026, 18:36:37.643	[info ]: javascript.0 (1007) script.js.LuxtronicTest: [WRITE] Verbunden. Sende Schreib-Befehl für Parameter 105 -> Wert: 445
6.10.2026, 18:36:37.643	[info ]: javascript.0 (1007) script.js.LuxtronicTest: [WRITE] Paket gesendet! Lasse Socket für die Wärmepumpe offen...
6.10.2026, 18:36:40.643	[info ]: javascript.0 (1007) script.js.LuxtronicTest: [WRITE] Beende ioBroker-Wartezeit. Schließe Socket sanft.
6.10.2026, 18:36:40.643	[info ]: javascript.0 (1007) script.js.LuxtronicTest: [TEST] Warte 3 Sekunden auf interne Verarbeitung...
6.10.2026, 18:36:43.646	[info ]: javascript.0 (1007) script.js.LuxtronicTest: [READ] Verbunden. Sende Lese-Befehl (3003)...
6.10.2026, 18:36:48.645	[error]: javascript.0 (1007) script.js.LuxtronicTest: ❌ [READ TIMEOUT] Die Wärmepumpe antwortet nicht!
6.10.2026, 18:36:48.646	[error]: javascript.0 (1007) script.js.LuxtronicTest: [TEST ABBRUCH] Skript fehlgeschlagen: Lese-Timeout

Schade ich würde mich so freuen wenn das klappen würde.

Nochmals vielen Dank für deine individuelle Hilfe.
Kann ich dir vielleicht irgendwo wenigstens nen Kaffee Tippen oder so? :)

TbsJah

@Chriz
Danke für deine Hilfe, die Ursache zu finden. Davon haben am Ende alle etwas! Wir müssen hier leider klassisches Reverse Engineering betreiben und versuchen uns schrittweise heranzutasten. :)

Vorab noch einmal die dringende Bitte: Führe die Tests mit dem Adapter und dem Skript nur dann durch, wenn deine Anlage im Leerlauf ist!

Ok - liegt an der X.90 Firmware 😭😭😭😭😭😭😭
Hab bei mir auch gerade auf 2.90 aktualisiert und kann das Problem 1 zu 1 nachvollziehen

Ich habe wieder wieder auf die vorherige Firmware zurückgesetzt da in der 2.90 ein Firmwarebug vorhanden ist...

So leid es mir tut, es gibt aktuell bei Versionen mit X.90 keine Lösung für das Schreiben außer wieder downzugraden.

TbsJah

🚨 BREAKING CHANGE / WICHTIGER HARDWARE-HINWEIS 🚨

Kritischer Firmware-Bug in Alpha Innotec / Novelan Steuerungen (V1.90.x & V2.90.x)
Der Hersteller hat mit den Firmware-Versionen V1.90.0 und V2.90.0 einen massiven Fehler im lokalen Luxtronik-Protokoll (Port 8889) eingeführt. Sobald ein Smart-Home-System (egal ob ioBroker, Home Assistant etc.) versucht, einen Parameter-Wert auf die Wärmepumpe zu schreiben, friert der Controller ein und erzwingt nach ca. 10 Sekunden einen harten Neustart (Reboot) der Anlage. Lesevorgänge sind hiervon nicht betroffen.

👉 Maßnahme des Adapters: Um deine Hardware vor ständigen Neustarts und möglichen Schäden zu schützen, wurde ein Schutzschild (Firewall) in den Adapter eingebaut.
Sobald der Adapter die Firmware V1.90.x oder V2.90.x erkennt, werden sämtliche Schreibbefehle hart blockiert. Im ioBroker-Log wird stattdessen eine entsprechende Warnung ausgegeben.

👉 Lösung für betroffene Nutzer: Bitte wende dich an den Hersteller-Support oder deinen Installateur und bitte um ein "Over-the-Air" (Remote) Downgrade auf die vorherige, stabile Version (V1.89 bzw. V2.89). Wer die alte Firmware-Datei noch lokal besitzt, kann diese per USB-Stick am Display flashen. Sobald die Anlage wieder auf V.89 läuft, gibt der Adapter die Schreibbefehle automatisch wieder frei!

✨ Neue Funktionen & Verbesserungen (Features)

Hardware-Schutzschild implementiert: Dynamische Firmware-Überprüfung vor jedem Schreibvorgang zum Schutz vor dem Reboot-Bug der Firmware-Versionen 1.90.x und 2.90.x.
Visibilities (Sichtbarkeiten) komplett überarbeitet: Die interne Logik für den Befehl 3005 wurde neu geschrieben (dynamische Erkennung von 1-Byte und 4-Byte Arrays). Der Adapter liest die Sichtbarkeits-Flags nun bei allen Firmware-Versionen fehlerfrei aus. Das Ausblenden von nicht vorhandener Hardware im Objektbaum funktioniert nun auch bei V1.x und V2.x Anlagen ohne Abstürze oder Timeouts!

🛠 Fehlerbehebungen (Bugfixes & Refactoring)

Adapter-Konfiguration (UI): Veraltete Warnhinweise bei der Checkbox "Nicht unterstützte Parameter ausblenden" wurden entfernt, da diese Funktion nun über alle Generationen hinweg stabil läuft.
Netzwerk / WebSocket: Die experimentelle Passwort-Übergabe für Port 8214 wurde restlos entfernt, da das Kommunikations-Problem nachweislich am Firmware-Bug von Alpha Innotec liegt. Die WebSocket-Verbindung für echte V3.x-Firmwares arbeitet wieder sauber über den bewährten Standard-Handshake.

Chriz

@TbsJah
das ist ja total krass, wie bist du darauf gekommen?

Tatsächlich funktioniert es bei mir nun auch mit der 1.89 die mir der Support von AIT geschickt hat.
Mir wurde auch gesagt sie haben das an die Qualitätsabteilung und den Support weitergeleitet.

Falls dort noch was kommt, gebe ich dir Rückmeldung.
Soweit bin ich erstmal total happy, dass ich mein Script wieder laufen lassen kann :)

Vielen lieben Dank @tbsjah, wenn ich dir irgendwie was donaten kann, lass nen link oder so hier.

TbsJah

0.15.1 (2026-10-10)

🛠 Bugfixes & Enhancements

Admin UI (ZIP Control): Completely revised the explanatory text for the Circulation Pump (ZIP) settings in jsonConfig.json. Clarified the exact behavior of the "Disable base ZIP values" (zip_lWP_aktiv) option to prevent unintentional power cuts to external Wi-Fi relays (like Shelly) while maintaining EEPROM hardware protection.
Testing Framework: Updated @iobroker/testing to version 6.3.0 to meet current repository standards.
Changelog Formatting: Fixed Markdown header formatting to comply with ioBroker "Test and Release" requirements.

0.15.0 (2026-10-10)

####🚀 Features

Modularized State Mapping: Restructured the massive stateMapping.ts into smaller, logically separated files (e.g., info.ts, settings.ts, actions.ts) to significantly improve code maintainability, readability, and scalability.
Improved Admin UI (ZIP Control): Added comprehensive, scenario-based documentation to the Circulation Pump (ZIP) settings in the Admin interface (jsonConfig.json). It now clearly differentiates between continuous power setups (Scenario A) and heat-pump-powered setups (Scenario B). This prevents users from accidentally cutting power to external Wi-Fi relays (like Shelly) when using the EEPROM hardware protection feature.
New Telemetry Data added: The adapter now automatically reads and creates crucial system values based on the BenPru standard: Compressor frequency (Index 231), Current heat output (Index 257), and Current power consumption (Index 268).
Extended Shutdown Codes (Outage History): The internal database for heat pump shutdowns has been massively expanded. The adapter now recognizes and translates all 32 official Luxtronik shutdown reasons (e.g., Inverter pause, Hot gas pause, Limit power consumption) into detailed clear text (English & German). This ensures much more precise troubleshooting in the object tree and highly informative Telegram alerts.

####🛠 Bugfixes & Enhancements

Critical Startup Crashes Fixed: Resolved multiple UNCAUGHT_EXCEPTION errors and communication aborts where the adapter crashed directly during initialization (onReady) or the polling loop. This was caused by missing hardcoded virtual data points (e.g., Regelung_Aktiv, thermalenergy_total, energy_total, opStateCoolingString) that were dropped during the state mapping modularization.
ZIP Optimization Defaults: Fixed an issue where the circulation pump (ZIP) was unintentionally shut down (Hardware timers forced to 0 ON / 60 OFF) directly after installation. The logic and default values for zip_lWP_aktiv have been clarified to ensure users relying on the Luxtronik's internal power supply do not experience unexpected offline states of their smart relays.
Visibility Filter (Command 3005) fixed: Resolved a major logic flaw in the cleanupStates function. Previously, the adapter ignored unsupported hardware components (like missing cooling or solar modules) but failed to delete their remnants from the ioBroker object tree. Obsolete datapoints and empty folders are now rigorously removed upon startup.
Precise Visibility Mapping implemented: The hide-logic (Command 3005) no longer relies on broad folder names. Instead, it now uses the exact, manufacturer-specific visibility index (visiIndex) for every individual module to accurately show or hide features.
HUP Optimization (Temperature Spread Control): Dynamic voltage adjustment of the heating circulation pump during heating operation now only triggers after the state has been active for at least 10 minutes and compressor 1 (VD1) is actively running. This prevents premature voltage shifts during startup phases before the thermal spread has stabilized.
Outage & Malfunction Monitoring: Fixed tracking logic in checkAndSendOutageNotifications: Luxtronik outage code 0 (Heat pump malfunction / WP-Störung) is no longer erroneously skipped. Both low flow issues and direct heat pump shutdowns now reliably dispatch alarms via Telegram and the ioBroker Notification Center.

Homer.J.

kann es sein das der Datenpunkt Betriebsstunden Kühlung nicht mehr vorhanden ist?

Grüße

TbsJah

0.17.2 (2026-10-11)

🛠 Bugfixes & Enhancements

Log copManager: Fixed an issue regarding the log output in the COP calculation engine.

0.17.1 (2026-10-11)

🛠 Bugfixes & Enhancements

Code Quality & CI/CD: Fixed ESLint no-prototype-builtins pipeline failures in objectManager.ts by replacing direct .hasOwnProperty() calls with safe Object.prototype.hasOwnProperty.call() methods.

0.17.0 (2026-10-11)

🚀 Features

COP & Efficiency Calculator: Introduced a comprehensive COP (Coefficient of Performance) calculation engine to track heat pump efficiency.
External Smart Meter Support: Users can now choose to use internal Luxtronik estimates or link high-precision external sensors (e.g., Shelly 3EM or M-Bus heat meters) via ioBroker Object IDs for power consumption and thermal energy generation.
Granular Live Metrics: The adapter now dynamically analyzes the active operating state to split and calculate live daily COP values for "Total", "Heating", and "Hot Water" independently.
Persistent Time Rollovers: Implemented a robust "snapshot" system with absolute virtual counters. The adapter automatically detects day, month, and year rollovers to persist data and guarantee accurate long-term calculations, even across adapter restarts or ioBroker reboots.
Dedicated Efficiency UI: Added a new "Efficiency / COP" configuration tab to easily manage energy data sources and toggle the calculation engine.
Connection & Polling Status: Added a new system datapoint info.lastUpdate. This state continuously tracks the exact timestamp of the last successful data retrieval, making it easy to monitor the adapter's health and polling activity in visualisations like VIS or Lovelace.

🛠 Bugfixes & Enhancements

Object Tree Creation: Fixed an issue where hidden data buckets for the COP calculation were not created because parent directories were missing.
Timestamp Formatting: Resolved a strict type mismatch error in the ioBroker log by correctly formatting info.lastUpdate as an ISO string instead of a numeric timestamp.
State Properties & Code Quality: Resolved strict TypeScript and ESLint warnings (missing JSDoc annotations, missing read/write object definitions) in the new COP manager.
Modernized ioBroker API: Replaced deprecated setStateAsync method calls with the modern, promise-based setState standard across the COP calculation engine.
Config UI Sorting: Ensured the newly generated configuration tabs maintain a logical and consistent order across rebuilds.
Internal Mapping: Restructured the info folder mapping to cleanly accommodate adapter-level metadata alongside hardware telemetry.

0.16.1 (2026-10-11)

🚀 Features

Enhanced UI Layout: Improved the "Datapoints" settings tab layout to display up to 4 items side-by-side on larger screens for a better overview and improved usability.

🛠 Bugfixes & Enhancements

State Cleanup Logic Fixed: Resolved an issue where unchecked datapoints (e.g., Room Thermostats) were not removed from the ioBroker object tree. The isStateEnabled logic now correctly handles undefined config states for dynamically generated checkboxes.

0.16.0 (2026-10-11)

🚀 Features

Dynamic Admin UI Generation: The "Datapoints / Objects" configuration tab in the adapter settings is now fully auto-generated during the build process (prebuild). This ensures the UI is always 100% in sync with the underlying TypeScript state mappings.
Category Master Switches: Added master toggle switches to the adapter settings. Users can now enable or disable entire hardware categories (e.g., Solar, Cooling, Ventilation) with a single click. This keeps the ioBroker object tree clean and significantly reduces unnecessary polling for unused features.
Dynamic Protection for Critical States: System-critical datapoints are now protected dynamically via a required: true flag in the codebase. They are permanently locked (grayed out) in the UI and cannot be accidentally deleted or disabled by the user or the visibility filter.

🛠 Bugfixes & Enhancements

Cycle Optimization Logic (Hot Water): Fixed a logic flaw where the adapter erroneously applied an artificial hot water target temperature increase while the heat pump was already actively running a hot water cycle. The trigger is now strictly limited to the end of regular heating cycles.
Build Process Optimized: Integrated the UI generation script (generateConfig.ts) seamlessly into the NPM prebuild lifecycle, automatically patching the jsonConfig.json before typescript compilation.

TbsJah

Moin zusammen,

es gibt ein frisches Update für den Adapter! 🚀

Die wichtigsten Neuerungen kurz und knapp:

Datenpunkte & Struktur: Die Auswahl und Anzeige der Datenpunkte wurde komplett überarbeitet. Es stehen euch ab sofort wesentlich mehr Datenpunkte zur Verfügung!

Neues Feature - COP / JAZ: Die Effizienz eurer Wärmepumpe kann nun direkt im Adapter berechnet und getrackt werden.

Damit ihr direkt einen Eindruck bekommt, habe ich euch zwei Screenshots angehängt (die neue Datenpunkt-Struktur und den neuen Reiter für die COP-Konfiguration).

Alle weiteren technischen Details und Fixes unter der Haube stehen wie gewohnt unten im Changelog.

Viel Spaß beim Testen – Feedback wie immer gerne hier im Thread! 👋

Community Forum

NEWS

Test Luxtronik2-Controller V0.22.x

0.13.1 (2026-10-02)

0.13.0 (2026-10-02)

🛠 Troubleshooting / Error Analysis

Raw TCP Test Script (`Test_Script.ts`)

Execution in ioBroker:

Result Evaluation:

🚨 BREAKING CHANGE / WICHTIGER HARDWARE-HINWEIS 🚨

✨ Neue Funktionen & Verbesserungen (Features)

🛠 Fehlerbehebungen (Bugfixes & Refactoring)

0.15.1 (2026-10-10)

🛠 Bugfixes & Enhancements

0.15.0 (2026-10-10)

0.17.2 (2026-10-11)

🛠 Bugfixes & Enhancements

0.17.1 (2026-10-11)

🛠 Bugfixes & Enhancements

0.17.0 (2026-10-11)

🚀 Features

🛠 Bugfixes & Enhancements

0.16.1 (2026-10-11)

🚀 Features

🛠 Bugfixes & Enhancements

0.16.0 (2026-10-11)

🚀 Features

🛠 Bugfixes & Enhancements

Support us

281

33.1k

84.2k

1.4m

Community Forum

NEWS

Test Luxtronik2-Controller V0.22.x

0.13.1 (2026-10-02)

0.13.0 (2026-10-02)

🛠 Troubleshooting / Error Analysis

Raw TCP Test Script (Test_Script.ts)

Execution in ioBroker:

Result Evaluation:

🚨 BREAKING CHANGE / WICHTIGER HARDWARE-HINWEIS 🚨

✨ Neue Funktionen & Verbesserungen (Features)

🛠 Fehlerbehebungen (Bugfixes & Refactoring)

0.15.1 (2026-10-10)

🛠 Bugfixes & Enhancements

0.15.0 (2026-10-10)

0.17.2 (2026-10-11)

🛠 Bugfixes & Enhancements

0.17.1 (2026-10-11)

🛠 Bugfixes & Enhancements

0.17.0 (2026-10-11)

🚀 Features

🛠 Bugfixes & Enhancements

0.16.1 (2026-10-11)

🚀 Features

🛠 Bugfixes & Enhancements

0.16.0 (2026-10-11)

🚀 Features

🛠 Bugfixes & Enhancements

Support us

281

33.1k

84.2k

1.4m

Raw TCP Test Script (`Test_Script.ts`)