Is Odin aware of scheduled native Legionella Prevention cycles?

[Birkemosen]

System

• Mitsubishi Ecodan hydrobox with FTC6
• Outdoor unit: PUD-SHWM100YAA
• Asgard connected through CN105
• Native Legionella Prevention configured on the Mitsubishi main remote controller

Question

Is Odin currently aware of native Legionella Prevention cycles initiated by the FTC6?

The FTC6 main remote controller allows the following LP parameters to be configured:

• Target temperature
• Frequency in days
• Start time
• Maximum runtime
• Duration at maximum temperature

However, the controller does not show the calendar date of the next LP cycle. The recurrence phase is therefore unknown until an LP cycle is actually observed.

Asgard can detect when the FTC enters the native Legionella Prevention operating mode, while Odin currently appears to treat LP as outside its control and planning.

This may cause Odin to:

• Schedule normal DHW shortly before a native LP cycle.
• Plan space heating during a period where the heat pump will be occupied by LP.
• Schedule another DHW run shortly after LP has already heated the cylinder.

Possible solution: LP awareness without LP control

Could Odin support a user-entered mirror of the visible FTC6 LP settings?

For example:

native_lp:
  enabled: true
  target_temperature: 60
  frequency_days: 7
  start_time: "13:00"
  maximum_runtime_minutes: 180
  duration_at_target_minutes: 30

Because the date of the first upcoming LP cycle is unknown, the schedule would initially have an unsynchronized state:

LP configuration known
LP recurrence phase unknown
Next expected LP unknown

Asgard could then report when native LP is actually detected:

{
  "native_lp_active": true,
  "native_lp_started_at": "2026-08-09T01:00:00+02:00"
}

After the first observed LP cycle, Odin could synchronize the recurrence phase and predict subsequent events using:

next expected LP date =
    last observed LP calendar date
    + configured frequency in days

next expected LP time =
    configured MRC start time

Using the configured start time is preferable to adding the interval directly to the observed timestamp, since the FTC may enter the reported LP operating mode a few minutes after the configured start time.

Suggested state model

UNSYNCHRONIZED
  LP settings are configured, but no native LP cycle has been observed.

SYNCHRONIZED
  A native LP start has been observed and future cycles can be predicted.

EXPECTED
  A predicted LP period is approaching and is included in Odin's plan.

ACTIVE
  Asgard reports that native LP is currently running.

COMPLETED
  Asgard reports that LP has ended and Odin recalculates the DHW plan.

MISSED
  No LP was observed within a suitable tolerance around the predicted time.
  The schedule returns to UNSYNCHRONIZED until another LP is observed.

Expected Odin behaviour

Odin would not start, stop, postpone or modify native LP. The FTC6 would remain fully responsible for LP execution.

Odin would only treat a synchronized LP prediction as a fixed, non-controllable DHW event and could:

• Avoid normal DHW shortly before LP when stored hot water is sufficient.
• Still schedule normal DHW when comfort constraints require it.
• Reserve the expected LP period when planning space heating.
• Account for the expected heat-pump interruption.
• Recalculate after Asgard reports LP completion.
• Avoid another unnecessary DHW cycle immediately after LP.

Before the first LP observation, Odin should make no assumption about the next LP date.

Duration handling

The configured maximum runtime is an upper limit rather than necessarily the expected duration.

An initial implementation could reserve the maximum configured LP period. A later implementation could learn the typical duration from observed cycles while retaining the configured maximum runtime as a hard upper bound.

Suggested responsibility split

FTC6 / main remote controller
  Stores the real LP settings
  Maintains the internal recurrence phase
  Executes native Legionella Prevention

Asgard
  Detects actual native LP start and completion
  Persists the latest observed LP timestamps
  Reports actual LP state to Odin

Odin
  Stores a mirror of the visible LP settings
  Starts in an unsynchronized state
  Learns the recurrence phase from the first observed LP
  Predicts later LP cycles
  Optimizes ordinary DHW and space heating around them

Is Odin already LP-aware in this way?

If not, would an initially unsynchronized, observation-synchronized LP schedule be a reasonable addition?

[gekkekoe]

Hi!

Currently it's not possible to read the legionella schedule over cn105. Odin/Asgard are therefore not aware when it will execute, only when it is executing.

See:
https://github.com/gekkekoe/heatpump-optimizer#2-known-limitations--expectations

The problem with prediction is, that user can change settings and you would require at least 2 cycles to derive the schedule. I don't know if we can solve this cleanly.

Odin does schedule dhw when it detects dhw tank to be too low (start of LP), but next hour it will see that the LP did increased it and drops the dhw planning. Odin should therefore not plan dhw after LP (finished). If you are seeing please try to record some logging

The missed timeslot is around 1-3 hours for LP and Odin only discard it for the current hour, but re plains every hour. So in the last LP hour, it will increase output if needed for heating for example. It's more ideal if we know it in advanced, but to do it reliably, its a bit difficult.

The most basic solution could be that you enter the schedule yourself in Odin and approximate how many hours it takes. But its also not ideal since it's probably faster in summer than winter.

I will have a look, but it's not trivial as explained.

[Birkemosen]

Thanks. The basic solution you mention is essentially what I had in mind.

Odin would not derive the schedule from observed cycles. The user would enter the FTC6 start time, frequency and maximum runtime manually. This would be entirely optional. Without these settings, Odin would continue behaving exactly as it does today.

The first detected LP cycle would only establish the calendar phase. For example, if the user has entered “every 7 days at 01:00”, one observed cycle is enough to predict the next date.

The maximum runtime could be used as a conservative planning window. I understand that the actual duration varies seasonally and that Odin only replans hourly, so the benefit for heating may be limited.

The main benefit would be advance awareness: Odin could avoid ordinary DHW shortly before an expected LP cycle and avoid relying on heating or cooling during the configured maximum window.

If the FTC6 settings are changed, the user would need to update the mirrored settings in Odin. If an expected LP cycle is not detected, Odin could discard the prediction and return to an unsynchronized state.

In my case, the FTC6 settings are:

Target temperature: 65 °C
Maximum runtime: 1 hour
Duration at target: 3 minutes
Frequency: 14 days
Start time: 03:00

After the first observed LP cycle, Odin could therefore treat the expected 03:00–04:00 period every 14 days as a fixed, non-controllable DHW event.

If the expected cycle is not detected, Odin could discard the prediction and return to an unsynchronized state until another LP cycle is observed. The goal would not be to predict the exact duration, but simply to give Odin advance notice so it can avoid obvious DHW and heating or cooling scheduling conflicts.

[gekkekoe]

It's added to the todo list. Will try to have it included before next heating season

(currently doing a large rewrite)

[Birkemosen]

Thanks sounds good :)