Luxtronik2 Write Commands Timeout with Firmware V1.90.0

[Schmider112]

Hi everyone,

after updating i got the following issue. The integration is no longer usable.

Description:
Write commands to the heat pump consistently fail with timeout errors.
The integration successfully establishes connection but cannot send write commands.

Environment:

• Home Assistant Version: 26.8.2
• Luxtronik2 Integration Version: 2026.08.18
• Luxtronik Library Version: Tested 0.3.10, 0.3.11, 0.3.12
• Heat Pump Model: Novelan Wärmepumpe WZS81H
• Heat Pump Firmware: V1.90.0
• Network: Local network, stable connection

Issue Details:
When attempting any write command (e.g., switching cooling mode, changing DHW target temperature),
the following error occurs:

Heat pump reboots after every command sent.Alpha Innotec has integrated myuplink as the portal. Perhaps that is the cause.

[rhammen]

Thanks for the detailed report — the log screenshot is genuinely useful here.

🔍 What the log shows

Reading the "first occurred at" timestamps in order:

Time	Event
21:49:44	parameter/calculation parse warnings start → reads are working
21:51:24	HA: "Something is blocking Home Assistant from wrapping up the start up phase"
21:52:14	first Write error: timed out
21:53:14	first Failed to connect: timed out + Error fetching data: timed out
22:06:21	parse warnings still arriving → reads recovered

So reads worked before the write and worked again after it, and the connect failure lands exactly 60 s (our socket timeout) after the write failure. That matches your own observation that the heat pump reboots on every command: the broken connection is a consequence of the write, not the cause of it. The blocked HA startup is the same stall seen from the other side — setup waits on the socket, so an unresponsive controller holds up the config entry.

⚠️ First: please restore the pinned library

You mention testing luxtronik 0.3.10 / 0.3.11 / 0.3.12. The integration pins luxtronik==0.3.14, and running an older one is what produces this flood:

Parameter '1194' not in list of parameters       (767x)
Calculation '260' not in list of calculationss   (39x)
Module Luxtronik.Parameters is logging too frequently

Those two log lines are commented out in 0.3.14 and the parameter table is longer, so on the pinned version they disappear entirely. They are not the bug, but the volume adds latency to every poll and makes the real errors hard to read. Please go back to 0.3.14 before we dig further.

🧪 The test that would settle this

Between your previous version and 2026.08.18 we changed how the write acknowledgement is read from the socket (commit 591ade9, shipped in 2026.08.05). Previously a truncated or missing ack raised a parse error and failed immediately; now the read loops until the expected bytes arrive, so the same controller behaviour blocks for the full 60 s timeout and surfaces as Write error: timed out.

That change does not make a heat pump reboot — but it may well be why this went from a quick visible error to a minute-long stall that takes the whole integration down with it.

Could you install 2026.07.30 — the last release before that change — and try one write? Either result tells us a lot:

• ✅ The write fails instantly with a protocol/parse error instead of hanging → your controller sends a truncated acknowledgement, and we can fix this properly with a short dedicated ack timeout.
• ❌ The write still hangs for 60 s → the controller goes completely silent, our change is not involved, and the cause is on the firmware/portal side.

(2026.07.30 also predates two smaller write-path changes from 2026.08.10, so a clean result there narrows it to one of three rather than to a single commit — still a big step forward.)

📋 Also helpful

1. A diagnostics download (Settings → Devices & Services → Luxtronik → ⋮ → Download diagnostics). We have one other WZS on V1.90.0 in our collection (from Smart Grid Status always shows evu_locked on Luxtronik 2.0 (SG1.1) #669) and a second sample to compare against would help a lot.
2. Confirm the reboot on the controller itself: does the display actually restart, and does Info → Abschaltungen show an entry at the moment of the write? (Note the display shows local time, the registers UTC.)
3. myUplink — if it can be disabled temporarily, please try a write with it off. If the portal holds its own permanent connection to port 8889, a second writer is a plausible trigger for the crash, and that would be very good to rule in or out.

V1.90.0 on a WZS81H is a controller generation we have very little data on, so these answers are valuable well beyond this one issue.

[Schmider112]

Hi,

I've attached the log. Luxtronik is back on PIP 0.3.14. Downgrading to 2026.7.3 isn't possible without further ado, since I no longer have a backup.

I don't see anything on the controller itself; it just displays the message “Please wait,” and the pump restarts.

MyUplink cannot be disabled separately; I can only disable remote maintenance entirely. The manufacturer recommends disconnecting the network cable if you do not want remote maintenance.

config_entry-luxtronik2-01KWPF0KRZZAHB7Y7N1DB2GJ0S.json

[rhammen]

Thanks for going back to 0.3.14 and for the diagnostics — that's a second WZS on V1.90.0 in our collection, which is genuinely valuable.

Good news on the downgrade: you don't need a backup for this. The integration version is independent of your HA configuration, so you can drop to 2026.07.30 and come back to 2026.08.18 afterwards without losing anything. Your entities, settings and history stay exactly as they are.

🔽 Option A — via HACS (recommended)

1. HACS → Integrations → Luxtronik
2. Open the ⋮ menu (top right of the repository page) → Redownload
3. In the version dropdown, pick 2026.07.30
4. Confirm, then restart Home Assistant

To go back afterwards, do exactly the same and pick 2026.08.18 (or whatever is latest).

If 2026.07.30 doesn't appear in the list, enable Show beta versions in the same dialog — the list is otherwise limited to the most recent entries.

📦 Option B — manual, via ZIP

If HACS gives you trouble:

1. Download luxtronik2.zip from the 2026.07.30 release
2. Delete the folder config/custom_components/luxtronik2/ (⚠️ only that folder — not config/)
3. Unpack the ZIP so that you end up with config/custom_components/luxtronik2/manifest.json again
4. Restart Home Assistant

Note that HACS will then show an update as available again; installing it simply brings you back to the current version.

🧪 What to test on 2026.07.30

Just one single write — for example changing the hot-water target temperature — and then look at the log:

• ✅ The write fails immediately with a protocol/parse error instead of hanging for 60 s → your controller sends a truncated acknowledgement, and we can fix that properly with a short, dedicated ack timeout.
• ❌ The write still hangs for 60 s → the controller goes completely silent and our change from 2026.08.05 is not involved; the cause is then on the firmware/portal side.

Either answer moves us forward, so please don't worry about "getting it wrong".

🔌 On myUplink

Understood that it can't be switched off separately. Unplugging the network cable, as the manufacturer suggests, would actually be a perfectly valid test for us — if a write succeeds with the cable out and fails with it in, then a second writer on port 8889 is the trigger. Only worth doing if you're comfortable with it; the A/B test above has priority.

🖥️ On the controller

Thanks for checking. "Please wait" plus a restart, with nothing in Info → Abschaltungen, tells us the controller is doing an uncontrolled reboot rather than a logged shutdown — which fits the picture of the write itself crashing it.

[rhammen]

Follow-up after analysing the diagnostics — and one correction to what I wrote earlier.

🔁 Correction: this is the same pump as #669

I said this would be a second WZS on V1.90.0 for our collection. It isn't — it's the same physical unit and the same Home Assistant installation as the dumps you attached to #669 (heatpump_id c5a763f40f, same config entry, created 2026-07-04). So V1.90.0 is still a single-unit sample for us. That takes nothing away from the dump's value, as it turns out.

🎯 Your dump contains the failing write, line by line

This is the first dump we have ever received that includes the debug log, and it captures the whole event:

Time	Event
15:26:41.693	write command sent to the controller
15:27:41.725	connection dropped — exactly 60.03 s later, our socket timeout
15:27:45.320	Write error: timed out, value reverted
15:28:45.416	next poll: Failed to connect: timed out (another 60 s)
15:29:45.383	back online, poll completes in 0.12 s

Three conclusions:

1. The controller sends no acknowledgement at all. Not a short or garbled one — nothing. The log line we write on every acknowledgement is simply absent, so we sat waiting for the first four bytes until the timeout expired.

2. Your network and the controller are otherwise perfectly healthy. Every poll before and after takes 0.12–0.16 seconds with no fragmentation. The 60 seconds is entirely the controller not answering, followed by roughly two minutes of it being unreachable. That is your reboot, seen from our side.

3. The write itself probably did work. Parameter 2 ID_Einst_BWS_akt (the hot-water setpoint) reads 49.0 °C in this dump, against 48.0 °C in your July dumps — exactly one step up, matching the write we reported as failed. It's not conclusive, since six weeks passed between the dumps, but the picture fits: the controller stores the value and then crashes, before it gets around to answering us.

Can you confirm that? If your hot-water target is now 49 °C, that settles it — and it would mean your writes are actually landing despite the error message.

🔄 Revised view of the downgrade test

This weakens my own hypothesis, so in fairness: our 2026.08.05 change only makes a difference for a truncated acknowledgement. Against a controller that answers with total silence, the older code would have waited out the same 60 seconds. I now expect the test to come back ❌.

It's still worth running — it's cheap and it settles the question — but please treat it as optional rather than the priority. The instructions in my previous comment still stand.

🔧 What we can fix on our side

We cannot stop your controller from crashing on a write; that is firmware behaviour and belongs with the manufacturer. What we can do is stop it from taking the integration down with it:

• A short, dedicated timeout for the acknowledgement (a few seconds instead of the 60 s connection timeout), so a silent controller produces a quick error rather than a minute-long stall.
• Re-reading the parameter after reconnecting, so that when the value did stick — as it appears to here — we report success instead of wrongly reverting your entity.

Together those would turn this from "the integration is dead for two minutes and lies about the result" into "one brief error while the pump restarts". I'll open a separate issue for that work.

📎 One small request for future dumps

Both your dumps arrived as invalid JSON — a block just after "run_as_root": true had been removed along with its closing brackets, so the file no longer parses. No harm done, I repaired it by hand, but it's worth knowing that no manual editing is needed: the integration already removes your IP address, serial number and device identifiers before writing the file. From version 2026.08.18 it also replaces the serial with an anonymous id (c5a763f40f in your case). So next time you can upload the download untouched.

Thanks again — this dump moved the issue further than the previous three combined.

[rhammen]

One more update — and a revised test plan that replaces the one in my earlier comment. Please read this one instead.

⚠️ Where we stand: honestly, we do not fully understand this yet

Everything below is our current working hypothesis based on the information available today. It has already changed twice while analysing your dump, and it may change again. I would rather tell you that than pretend we have it pinned down.

The hypothesis: your controller crashes on receiving a write command, stores the value, reboots, and never sends the acknowledgement we wait for. Our integration then sits waiting for the full 60-second timeout and reports a failure — even though the value probably did arrive.

What makes us doubt that our update caused it: the actual bytes we send for a write are byte-for-byte identical in every version you could have been running — 2026.07.04, 2026.07.30 and 2026.08.18 all send the same three numbers, and all three then wait for the acknowledgement on the same 60-second timeout. So on a controller that stays silent, every one of those versions hangs for 60 seconds; on a controller that answers, every one of them succeeds. We have not yet found a change on our side that could flip that.

Which points at something changing on the controller's side — and you named a candidate in your very first sentence: myUplink. If Alpha Innotec activated that portal on your unit over the summer, a second permanent connection to port 8889 fits "the pump reboots on every command" considerably better than anything in our changelog. That would make the timing with our update a coincidence.

But we cannot yet rule out that we broke something in a way we have not spotted. Hence the questions and the test below.

❓ Three questions (these are worth more than any test)

1. Which version did you update from? Your July diagnostics show 2026.07.04. Did you go straight from that to 2026.08.18, or did you install 2026.07.30 in between? This one answer halves the number of suspect changes.
2. Had you ever successfully changed a setting from Home Assistant before this? Roughly when was the last one that worked? You opened Smart Grid Status always shows evu_locked on Luxtronik 2.0 (SG1.1) #669 on the day you installed, about a sensor reading — so it is entirely possible that no write was ever attempted before August. If so, there may be no regression at all and we are chasing the wrong thing.
3. When did myUplink appear on your controller? Before or after the integration update?

🧪 Test plan (revised — ignore the 2026.07.30-only test from my earlier comment)

The downgrade instructions from my previous comment still apply; only the versions change. Please test one write per version and report the result.

Step 1 — install 2026.07.30 (the previous stable release), try one write:

• ✅ Write works → the cause is in one of two changes from early August. Continue with step 2.
• ❌ Write still fails → jump to step 3 instead.

Step 2 — install 2026.08.08, try one write:

• ✅ Works → the cause is a change from 2026-08-10, and we know exactly which one.
• ❌ Fails → the cause is a change from 2026-08-05, and we know exactly which one.

(2026.08.08 is a pre-release, so you have to enable Show beta versions in the HACS download dialog to see it.)

Step 3 — only if step 1 also failed: install 2026.07.04, the version from your July dumps, try one write:

• ✅ Works → the cause is in the write-confirmation rework from mid-July.
• ❌ Fails → then no version of ours ever worked on this controller, which strongly supports the myUplink/firmware explanation and closes the question of a regression.

Afterwards please return to 2026.08.18 — you lose nothing by moving between versions, your settings and history stay intact.

🔎 One thing you can check right now, for free

Is your hot water target temperature currently 49 °C? It was 48 °C in your July dumps, and the write we see failing in your log was exactly that setting. If it now reads 49, your writes are landing despite the error message — which tells us the damage is limited to a wrong error and a two-minute stall, not to lost settings.

Thanks for your patience with this. You are our only source of data on V1.90.0, so every one of these answers is worth a great deal.

[rhammen]

Two fixes for this are now available in 2026.08.21. It is a pre-release, so you need to enable Show beta versions in the HACS download dialog to see it.

🔧 What changed

1. A write no longer stalls for a minute (#764). We were waiting for the controller's acknowledgement under the connection timeout — 60 seconds — even though that acknowledgement is only eight bytes. It now has its own 5 second limit. On your unit that turns a 60 second freeze, long enough to block Home Assistant's startup, into a quick error.

For calibration: on a healthy controller that acknowledgement arrives in 3–4 milliseconds (measured on an Alpha Innotec MSW4-16). Yours never sends it at all, so 5 seconds is already enormously generous.

The error message now also says which timeout fired, e.g. No write acknowledgement for parameter 105 within 5.0s, instead of a bare "timed out" that looked identical to a network problem.

2. A failed write no longer rides along on the next one (#763). Until now, a write that failed stayed in the queue, so your next write of any setting re-sent the failed one too — meaning two commands, and on your controller two crashes. Worth having regardless of the root cause.

⚠️ What this does not fix

Your controller still reboots when it receives a write. That is firmware behaviour and we cannot change it from here. What we fixed is our side of it: a brief error instead of a minute-long stall that took the whole integration down.

You will still see the write reported as failed, even though the value appears to arrive — the confirming read cannot succeed while the controller is restarting. That is the next thing we want to fix, and how we fix it depends on your answers below.

🙏 Still very useful, if you have the time

The questions from my previous comment still stand — especially whether a write from Home Assistant ever worked on this pump, which decides whether we are looking at a regression at all.

And one new, easy request. If you:

1. install 2026.08.21,
2. enable debug logging for the integration (Settings → Devices & Services → Luxtronik → ⋮ → Enable debug logging),
3. change one setting,
4. then download diagnostics again,

the file will contain the full write sequence, and we will see exactly where your controller stops responding. Your previous dump was the single most useful thing we have received on this issue — a second one on the new version would tell us whether the shorter timeout behaves as intended on real hardware.

Thanks again for your patience with this one.

[Schmider112]

Hello,

Thank you for the detailed feedback. Unfortunately, downgrading to 7.30 or 07.04 was unsuccessful. After restarting, I received an error message. I’m not entirely sure when the error first occurred, since I rarely use the integration during the summer. It’s quite possible that it hasn’t been working since the firmware update. When I tested turning on the heater, it was active after the restart. The command is being received. I updated the integration regularly and promptly as soon as I received the notification. I installed the beta and downloaded the logs. I hope this helps.

)

[Schmider112]

config_entry-luxtronik2-01KWPF0KRZZAHB7Y7N1DB2GJ0S-2.json

[rhammen]

Thank you — that dump answered several questions at once, including one where we were wrong.

✅ The new timeout works exactly as intended

Your log shows three writes, and all three behaved identically:

21:52:07,030  Done: self.client.parameters.set (1 parameter(s))
21:52:12,035  Disconnected
21:52:12,036  Debounced write of dhw_target_temperature failed …
              Write error: No write acknowledgement for parameter 2 within 5.0s

5.005 s, 5.006 s, 5.006 s — against the 60.03 s in your previous dump. So the minute-long freeze is gone, and the new message tells us precisely which parameter and which limit was involved. That is the first confirmation from real hardware that the change does what it should. Thank you for taking the trouble.

🙏 The downgrade could never have worked — that was our fault, not yours

You did nothing wrong. Your error message says it exactly:

Config entry Luxtronik @ …:8889 for luxtronik2 has version 10 which is higher than the current version 9

We raised the config entry version from 9 to 10 in 2026.08.18, for an unrelated entity rename. Home Assistant refuses to load a configuration entry that is newer than the installed integration understands, and it refuses before the integration gets any say in it. So 2026.07.30 and 2026.07.04 were both guaranteed to fail from the moment you installed 2026.08.18.

I asked you to run that test twice without realising we had made it impossible. Apologies for the wasted effort.

🔄 A correction on "your writes are landing"

I previously suggested your writes were probably reaching the controller despite the error, because the hot water setpoint had moved from 48 to 49 °C. Your new dump makes that doubtful: parameter 2 still reads 49.0 °C, unchanged, after two more writes of it. So either you re-applied the same value both times — plausible, since the field resets to 49 after each failure — or those writes did not stick after all. I cannot tell which, and I should not have stated it as confidently as I did.

Your own observation still stands, though, and it is the more reliable evidence: "when I tested turning on the heater, it was active after the restart". So at least some commands do arrive.

⏱️ What is still not fixed

Your log measures it precisely: after each write, the controller is unreachable for 122 to 143 seconds, and our reconnect attempt still waits the full 60 seconds. So a write still reports as failed even when it worked, because the confirming read cannot succeed while the controller is restarting. We now know exactly how long that window is, which is what we needed to fix it properly.

🧪 The one test worth doing next — and it is easy

You said at the start that myUplink might be the cause, and we still cannot rule that in or out. You also mentioned the manufacturer suggests unplugging the network cable — but that would disconnect Home Assistant too, so no write could be attempted.

There is a better version of that test: cut the heat pump off from the internet, but leave your local network intact. Home Assistant keeps reaching the pump over your LAN, while myUplink loses its connection to the portal. Two ways to do it — whichever is easier for you:

• Unplug the internet cable from your router (the WAN port, the one going to your modem/fibre box). Simplest option, nothing to configure. Note this takes your whole household offline for the few minutes of the test, so please open Home Assistant locally (by its IP address, not through Nabu Casa or a remote address) before you unplug — otherwise you will lose access to it as well.
• Or block just the heat pump's internet access in your router settings. Most routers can do this per device ("no internet access", "parental controls", "block WAN access" or similar). Slightly more fiddly, but nothing else in your house is affected.

Then try one write:

• ✅ The write succeeds and the pump does not restart → myUplink holding a second connection to the pump is the trigger. That would be a real finding, and something the manufacturer can act on.
• ❌ It still restarts → myUplink is ruled out, and the cause is in the controller firmware itself.

One router setting, no reinstalling, nothing to undo afterwards beyond removing the rule.

🛠️ Fallback, ready when you need it

If the router test tells us nothing, the old-version test is still possible after all. I have prepared a one-off package of 2026.07.30 with only the config entry version raised to 10, so Home Assistant will accept your existing configuration instead of refusing it. Nothing else in it differs from the real 2026.07.30.

⬇️ Download luxtronik2.zip

This is packaged exactly like a normal release download, so the steps are the same ones from my earlier comment:

1. Delete the folder config/custom_components/luxtronik2/ (⚠️ only that folder — not config/).
2. Unpack the ZIP so that you end up with config/custom_components/luxtronik2/manifest.json again.
3. Restart Home Assistant and try one write.

If the integration loads at all, you know you are running the test package — the genuine 2026.07.30 cannot load on your system, which is the whole problem. In diagnostics it reports version 2026.07.30.

To go back afterwards: HACS → Luxtronik → ⋮ → Redownload → 2026.08.21, then restart. HACS will also offer it as an "update" on its own, which is expected.

One harmless side effect: the two aux heater energy sensors are recreated under their older names, and the current ones stay behind as unused leftovers. Returning to 2026.08.21 sorts that out.

This package is only for this test. It is safe for exactly this pair of versions, because the change between them did not touch your stored configuration. Please do not keep it installed longer than the test needs.

Please do not downgrade Home Assistant itself to work around the version error. That is considerably riskier than an integration downgrade, and you mentioned you no longer have a backup.

[rhammen]

Update: this is not a single-controller problem, and there is one thing left to test

A second user reports the identical failure on a different model and a different
firmware line:

	this issue	second report
Model	Novelan WZS81H	Novelan LD5 REV 230V
Firmware	V1.90.0	V2.90.0
Integration	2026.08.18 / 2026.08.21	2026.07.30
Writes fail	always	12 out of 12 captured

Their captured log shows every write failing, at exactly the four times a Home
Assistant automation switches something:

06:00:00  write goes out
06:01:00  TimeoutError waiting for the acknowledgement (60 s socket timeout)
06:01:14  Failed to connect: [Errno 113] Host is unreachable
06:02:xx  back, as if nothing had happened

What the logs actually say

The debug log posted in this issue is the clearest evidence we have:

21:39:30 .. 21:51:30   thirteen polls, each "Finished fetching ... in 0.112 seconds (success: True)"
21:52:07               write goes out
21:52:12               no acknowledgement (5 s ack timeout), we disconnect
21:53:30               Failed to connect: timed out
21:54:30               Connected again, polls back to 0.112 s

Three things follow from this:

1. The connection is provably healthy right up to the write. Thirteen
   consecutive polls in 0.112 s.
2. The controller is idle when the write arrives — 36 s after the last read
   finished. It is not busy with something we interrupted.
3. The controller does not close the connection; it goes silent. The error
   is TimeoutError, not ConnectionResetError and not an empty read. A FIN or
   RST would mean the controller saw the write and rejected us. Instead the
   whole network stack disappears (Errno 113 Host is unreachable is an IP-layer
   error) and comes back about two minutes later. That is a reboot, not a
   refusal.

Note on the library versions you tried

Switching between 0.3.10 / 0.3.11 / 0.3.12 cannot change this. The integration
only imports the data vectors from python-luxtronik:

from luxtronik.calculations import Calculations
from luxtronik.parameters import Parameters
from luxtronik.visibilities import Visibilities

The socket layer is the integration's own lux_helper.py, not
luxtronik.Luxtronik. Those three versions only differ in parameter
definitions, which is why the behaviour did not change. Nothing lost — it is
just worth ruling out so nobody spends more time on it.

The one open question

I compared our write path against python-luxtronik byte for byte. For a single
parameter the twelve bytes we send are identical to what the library sends:
struct.pack(">iii", 3002, index, value), one sendall, then eight bytes read
back. Same order, no extra traffic.

Exactly one difference remains that the controller can actually observe:

• python-luxtronik opens a connection, performs one operation, closes it.
  Both the released 0.3.14 and the main rewrite work this way. main even
  documents why: "Locking is being used to ensure that only a single socket
  operation is performed at any point in time. This helps to avoid issues with
  the Luxtronik controller, which seems unstable otherwise."
• The integration keeps one connection open permanently and writes on the
  same socket that has already served read commands.

So: does the write kill the controller because of what it is, or because of
which socket it arrives on? That is a yes/no question, and the script below
answers it without anyone having to guess.

---

The test

One file, no Python installation required, and it detects the reboot itself
by probing the controller's port until it answers again. You do not have to
export or read any log afterwards.

It uses the real python-luxtronik 0.3.14 rather than a re-implementation, so
there is no room for "your script sends something slightly different".

What it touches: one parameter, 105 ID_Soll_BWS_akt (the hot water
setpoint). It lowers it by 1.0 °C and sets it back afterwards. It refuses to
write if that value cannot be read or is outside 20–75 °C.

When to run it

Please pick a moment where all of this is true:

• A two-minute outage of the heat pump is acceptable. If the hypothesis
  holds, the controller will reboot — twice per run. Not during a shower, not
  during a defrost cycle, not on the coldest evening of the week.
• The pump is idle — not actively heating hot water and not in a cooling
  cycle. A quiet moment gives the cleanest measurement.
• The Luxtronik integration is disabled in Home Assistant (Settings →
  Devices & services → Luxtronik → ⋮ → Disable). Its polling would otherwise
  interfere with the reachability probe. Re-enable it afterwards.
• You have about 25 minutes, because the three modes should be roughly 10
  minutes apart so the controller is fully settled between them.

You do not need to change anything in your configuration, and nothing is
installed into Home Assistant.

Where to run it

On any ordinary computer on the same network as the heat pump — your laptop
or desktop is fine. It does not have to be the machine running Home Assistant,
and nothing runs on the heat pump itself. Windows, macOS and Linux all work.

1. Expand the collapsed section at the bottom of this comment and save the
   script as luxtronik_write_test.py somewhere you can find it again, for
   example your Downloads folder. On Windows, check that Notepad did not save
   it as luxtronik_write_test.py.txt — choose "All files" in the save dialog.
2. Open a terminal: PowerShell on Windows (Start → type "PowerShell"),
   Terminal on macOS or Linux.
3. Go to the folder you saved it in:

   cd Downloads

4. You need the heat pump's IP address — the same one the integration uses.
   Home Assistant → Settings → Devices & services → Luxtronik shows it, and it
   is the address you would type in a browser to reach the controller.

Install uv (one command, brings its own Python)

# Linux / macOS
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

If the next command says uv: command not found or uv is not recognized,
close the terminal and open a new one — the installer adds uv to your PATH and
an already-open window does not pick that up.

Run the three modes, in this order

uv run luxtronik_write_test.py <heatpump-ip> --mode R   # control: reads only
uv run luxtronik_write_test.py <heatpump-ip> --mode B   # what the integration does
uv run luxtronik_write_test.py <heatpump-ip> --mode A   # what python-luxtronik does

Mode	What it does	Why
R	reads, writes nothing	control. If the controller reboots here, stop and say so — then even reading is a problem
B	reads the parameter block, then writes on that same socket	reproduction. This is what the integration does, so this is where the reboot is expected
A	writes on a fresh socket that has issued no other command	the variable. This is what python-luxtronik does

Each run performs two writes — the change and the restore — so you get two
samples per mode.

If a run stops before restoring (it says so explicitly), please set the hot
water setpoint back by hand on the controller. It will be 1 °C below where it
started.

What to send back

Just paste the console output of all three runs into this issue. Nothing else —
no diagnostics, no log exports.

How we will read the result

Outcome	Conclusion
B reboots, A does not	the persistent connection is the trigger. Small, well-founded fix on our side
both reboot	the write itself is what does it. The integration cannot prevent that; it belongs with Alpha Innotec, and we focus on limiting the damage
neither reboots	the write in isolation is harmless and something about the surrounding sequence matters. We go a level deeper

Reference: a controller that does not have the problem

Alpha Innotec MSW4-16, firmware V3.92.1, same script, both write modes:

[00:22:18]     3002 sent: parameter 105 = 490 (raw)
[00:22:18]     ack in 0.048s (cmd=3002 echoed_index=105)
[00:22:49]   RESULT: controller stayed reachable - no reboot
[00:23:59]   mode A: opening a FRESH connection for the write
[00:23:59]     ack in 0.057s (cmd=3002 echoed_index=105)
[00:24:29]   RESULT: controller stayed reachable - no reboot

---

luxtronik_write_test.py — save this as luxtronik_write_test.py (click to expand)

#!/usr/bin/env python3
# /// script
# requires-python = ">=3.11"
# dependencies = ["luxtronik==0.3.14"]
# ///
"""Does a single parameter write reboot the Luxtronik controller?

Run with:  uv run luxtronik_write_test.py <ip> --mode R|B|A

Three modes, meant to be run in this order:

  R  read only, no write at all          - control: proves this script is safe
  B  read, then write on the SAME socket - reproduction: what the HA integration does
  A  write on a FRESH socket             - the variable: what python-luxtronik does

The script measures the reboot itself: after each write it probes the
controller's TCP port until it answers again, and reports how long it was gone.
Nothing has to be read from any log afterwards.

Safety:
  * only ONE parameter is touched (default 105 ID_Soll_BWS_akt, the domestic hot
    water setpoint), lowered by 1.0 degC and restored afterwards
  * refuses to run if that parameter cannot be read or is outside 20..75 degC
  * a write is never attempted while the value is unknown
"""

from __future__ import annotations

import argparse
import socket
import struct
import sys
import time
from datetime import datetime

from luxtronik import Luxtronik

LUXTRONIK_PARAMETERS_WRITE = 3002

# Upstream python-luxtronik sets no socket timeout at all, so a controller that
# reboots without acknowledging the write would block us forever. Bound it.
SOCKET_TIMEOUT = 10.0

PROBE_INTERVAL = 2.0
PROBE_TIMEOUT = 2.0
PROBE_WINDOW = 180.0

PLAUSIBLE_MIN = 20.0
PLAUSIBLE_MAX = 75.0


def log(msg: str) -> None:
    print(f"[{datetime.now():%H:%M:%S}] {msg}", flush=True)


def port_open(host: str, port: int, timeout: float = PROBE_TIMEOUT) -> bool:
    """True if a TCP connection to the controller can be established."""
    try:
        with socket.create_connection((host, port), timeout=timeout):
            return True
    except OSError:
        return False


def measure_downtime(host: str, port: int) -> float | None:
    """Probe the controller until it answers again.

    Returns seconds of unreachability, or None if it never went away.
    """
    start = time.monotonic()
    went_down_at: float | None = None

    # One character per probe, no carriage returns: the whole point of this
    # script is that its output gets pasted into an issue, and a progress line
    # that redraws itself turns into unreadable soup once it is copied.
    print("    ", end="", flush=True)

    while time.monotonic() - start < PROBE_WINDOW:
        alive = port_open(host, port)
        print("." if alive else "X", end="", flush=True)

        if not alive and went_down_at is None:
            went_down_at = time.monotonic()
        elif alive and went_down_at is not None:
            print()
            return time.monotonic() - went_down_at

        # Stop early if it stayed up for a while - nothing is going to happen.
        if went_down_at is None and time.monotonic() - start > 30.0:
            print()
            return None

        time.sleep(PROBE_INTERVAL)

    print()
    return time.monotonic() - went_down_at if went_down_at is not None else None


def send_write(sock: socket.socket, index: int, raw_value: int) -> None:
    """Send one 3002 write and wait for its two-int acknowledgement."""
    sock.sendall(struct.pack(">iii", LUXTRONIK_PARAMETERS_WRITE, index, raw_value))
    sent = time.monotonic()
    log(f"    3002 sent: parameter {index} = {raw_value} (raw)")
    try:
        # Deliberately a single recv(4) per int, exactly as python-luxtronik
        # 0.3.14 does it - this script imitates that client, it does not improve
        # on it. A short read is therefore possible and is itself a finding, so
        # struct.error is reported rather than allowed to become a traceback.
        cmd = struct.unpack(">i", sock.recv(4))[0]
        echoed = struct.unpack(">i", sock.recv(4))[0]
    except struct.error as err:
        log(f"    SHORT/garbled acknowledgement after {time.monotonic() - sent:.1f}s ({err})")
        raise OSError("short acknowledgement") from err
    except (TimeoutError, OSError) as err:
        log(f"    NO acknowledgement after {time.monotonic() - sent:.1f}s ({err})")
        raise
    log(f"    ack in {time.monotonic() - sent:.3f}s (cmd={cmd} echoed_index={echoed})")


def write_fresh(lux: Luxtronik, host: str, port: int, index: int, raw: int) -> None:
    """Mode A: a brand new connection that has issued no other command."""
    log("  mode A: opening a FRESH connection for the write")
    with socket.create_connection((host, port), timeout=SOCKET_TIMEOUT) as sock:
        send_write(sock, index, raw)


def write_after_read(lux: Luxtronik, host: str, port: int, index: int, raw: int) -> None:
    """Mode B: read the parameter block first, then write on that same socket."""
    log("  mode B: reading the parameter block first, then writing on that socket")
    with socket.create_connection((host, port), timeout=SOCKET_TIMEOUT) as sock:
        lux._socket = sock  # noqa: SLF001 - reuse upstream's own read implementation
        lux._read_parameters()  # noqa: SLF001
        log("    parameter block read OK, socket stays open")
        send_write(sock, index, raw)
    lux._socket = None  # noqa: SLF001


def run_write(mode: str, lux: Luxtronik, host: str, port: int, index: int, raw: int) -> None:
    writer = write_fresh if mode == "A" else write_after_read
    try:
        writer(lux, host, port, index, raw)
    except OSError:
        pass  # the interesting part is what the controller does next
    log("  probing the controller until it answers again ...")
    down = measure_downtime(host, port)
    if down is None:
        log("  RESULT: controller stayed reachable - no reboot")
    else:
        log(f"  RESULT: controller was unreachable for {down:.0f}s -> REBOOT")


def main() -> int:
    ap = argparse.ArgumentParser(description=__doc__)
    ap.add_argument("host")
    ap.add_argument("--port", type=int, default=8889)
    ap.add_argument("--mode", choices=["R", "B", "A"], required=True)
    ap.add_argument("--parameter", type=int, default=105)
    ap.add_argument("--delta", type=float, default=-1.0)
    ap.add_argument("--skip-restore", action="store_true")
    args = ap.parse_args()

    socket.setdefaulttimeout(SOCKET_TIMEOUT)

    log(f"target {args.host}:{args.port}, mode {args.mode}")

    if not port_open(args.host, args.port):
        log("cannot reach the controller at all - is the IP right?")
        return 1

    log("reading all parameters (fresh connection, closed afterwards) ...")
    lux = Luxtronik(args.host, args.port)
    param = lux.parameters.get(args.parameter)
    if param is None or param.value is None:
        log(f"parameter {args.parameter} could not be read - refusing to write")
        return 1

    current = float(param.value)
    log(f"parameter {args.parameter} ({param.name}) currently reads {current} degC")

    if args.mode == "R":
        log("RESULT: read-only mode finished, nothing was written")
        log("  now checking the controller stayed reachable ...")
        down = measure_downtime(args.host, args.port)
        log(
            "  control OK - a plain read does not disturb the controller"
            if down is None
            else f"  WARNING: controller was gone for {down:.0f}s after a READ - stop here"
        )
        return 0

    if not PLAUSIBLE_MIN <= current <= PLAUSIBLE_MAX:
        log(f"{current} degC is outside {PLAUSIBLE_MIN}-{PLAUSIBLE_MAX} - refusing to write")
        return 1

    target = current + args.delta
    raw = param.to_heatpump(target)
    log(f"test write: {current} -> {target} degC (raw {raw})")

    run_write(args.mode, lux, args.host, args.port, args.parameter, raw)

    if args.skip_restore:
        log(f"NOT restoring - parameter {args.parameter} is left at {target} degC")
        return 0

    log("waiting 30s for the controller to settle before restoring ...")
    time.sleep(30)
    if not port_open(args.host, args.port):
        log("controller still unreachable - NOT restoring, please set it back by hand")
        return 1

    restore_raw = param.to_heatpump(current)
    log(f"restore write: {target} -> {current} degC (raw {restore_raw}) - second sample")
    run_write(args.mode, lux, args.host, args.port, args.parameter, restore_raw)

    log("done - please paste this whole output into the issue")
    return 0


if __name__ == "__main__":
    sys.exit(main())

---

Regardless of the outcome

Two things are worth doing on your side already, and they are independent of
this test:

• 2026.08.21 shortens the wait for a write acknowledgement from the full
  connection timeout (60 s by default) to 5 s. It does not stop the controller
  from rebooting — that is firmware behaviour — but it stops a write from
  blocking Home Assistant for a minute, which was long enough to delay startup.
• Writing less helps. If you switch modes on a schedule, add a condition so
  the automation only writes when the value actually needs to change. And the
  controller's own timer programs can do hot water and cooling schedules without
  Home Assistant writing anything at all.

[Speed884]

Hello,

I have the same problem.

Heatpump:
Novelan LAD9 with Luxtronik 2.0

I use HA Integration 2026.08.18. -> all works
After Firmware Update on the Luxtronik Controller to V2.90.0-12815 i have the same reboot on the controller when writing.

The process works as follows:

• The command is changed via Home Assistant (HA), e.g. from 50°C → 51°C.
• The Luxtronik controller freezes for approximately 10 seconds.
• The controller then shuts down and restarts.
• After the restart, the changed temperature setting is active → 51°C.

If “Remote Maintenance” is disabled, the myUplink connection is lost. However, the connection to the Home Assistant integration still remains active.

The restart issue still occurs as well.

I could test everything you want!

[Schmider112]

I cut the internet connection. Unfortunately, the writing process keeps crashing.
Thanks for providing the folder. I tried swapping it in my HA directory, but an error message appears after the restart.

Do I need to load a different version via HACS after the swap?

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 798, in __async_setup_with_context
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/luxtronik2/init.py", line 95, in async_setup_entry
await hass.config_entries.async_forward_entry_setups(entry, PLATFORMS)
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 2786, in async_forward_entry_setups
await integration.async_get_platforms(platforms)
File "/usr/src/homeassistant/homeassistant/loader.py", line 1140, in async_get_platforms
if platform := self._get_platform_cached_or_raise(platform_name):

File "/usr/src/homeassistant/homeassistant/loader.py", line 1232, in _get_platform_cached_or_raise
raise ModuleNotFoundError(
...<2 lines>...
)
ModuleNotFoundError: Platform luxtronik2.switch not found


Thanks for your great support