Multi Split Lockout Resolver

[smdev0925]

Multi-split AUTO mode lockout — findings, and an automation that resolves it

System: 4 × SRK25ZS-WF indoor units on a single SCM80-series outdoor unit.
Integration version: 2026.9.6

First, thank you for this integration — and particularly for the External Temperature Source work in the recent release. That turns out to be one half of a complete fix for AUTO mode on multi-splits, and I think the other half could be resolved within the integration. I wanted to share what I've been working on in case it's useful.

The problem

On a multi-split, one outdoor unit serves several heads and can obviously only run in one mode at a time. Whichever head claims the compressor first wins, and any head asking for the opposite mode is locked out — its room drifts while the entity still shows auto and looks perfectly healthy. Until your cool_hot_judge sensor, nothing surfaced this in HA.

Sadly it's worse than a simple first-come-first-served race, because MHI's AUTO mode latches its heat/cool decision. On my system a lockout will persist while the head holding the mode sits idle, needing nothing itself.

What works

The units already decide heat-versus-cool per room, with their own inbuilt hysteresis and their own sensor. Second-guessing that from the same sensor is just running a competing thermostat — I tried, and it oscillated every 15 minutes chasing the overshoot from its own previous switch.

However, three signals, all from your integration, are enough:

• cool_hot_judge — what a head is asking the outdoor unit for. This is the demand signal.
• the compressor-demand binary sensor — whether the compressor is actually running for that head.
• External Temperature Source — feeds a real room reading to the unit, so its AUTO logic decides from the room rather than from ceiling-level return air warmed/cooled by its own output.

That last one is critical rather than cosmetic. On my bedroom head a cool setpoint of 23.5 held the room at about 21 measured independently — roughly 2.5 °C out. That bias doesn't just affect the display, it appears to feed the unit's own AUTO decision, which is the vote everything else depends on. Provide stability to the temperature inputs and the vote becomes trustworthy. A genuinely excellent addition!

The approach

Using the first two signals, and reading no temperatures or setpoints at all:

1. cool_hot_judge - all votes unanimous → no lockout, do nothing.
2. cool_hot_judge split, someone calling the compressor → the side running the compressor keeps it.
3. Votes split, nothing calling → the side that most recently ran goes to fan_only for four minutes, dropping its latch, then back to its previous mode.

Which side ran most recently comes from the demand sensors' last_changed, so nothing needs storing between runs.

My Automation Code: GIST LINK HERE

It's early days — only a few hours of runtime so far — but it's resolved every lockout I've thrown at it, and the head that stands down (goes to fan_only) rejoins on whatever mode is now running rather than reclaiming its own.

Happy to test anything on a real four-head multi-split if that's ever useful. I'm a web developer by trade and although I haven't got a dev HA instance running, I would be able to get my head around it if you were to bear with me.

Looking forward to hearing your thoughts... thanks!
Shane :)

[blues-sechseck]

Hi Shane — thank you for writing this up so carefully, and for the kind words.

This is exactly the shape I was hoping someone would arrive at. You've read both
signals correctly: Cool Hot Judge goes to unknown when a head is off or in
fan_only, which is precisely the property your stand-down relies on, and
Compressor Demand really is this head's demand rather than the outdoor unit's
state — on a multi-split the compressor can be running for a sibling while that
sensor reads off. One correction to your header: Compressor Demand is enabled by
default, only Cool Hot Judge needs turning on. Worth fixing so nobody goes
hunting for a sensor they already have.

On the other half being resolved in the integration: I'd rather it wasn't, and I
don't think it can be. Each indoor unit is its own config entry, so the
integration has no view across the heads — it can't see a lockout, only report
what one unit says. And I've kept to the line that inference and control logic
belongs in automations rather than in the integration, because that's where you
can read it, trace it and change it without waiting for a release. Your
automation is the argument for that, not against it.

What I would like to do is give it a home. I've just added a
blueprints/
directory to the repo for exactly this. Yours is the first thing that would go in
it, and I'd be glad to take it under your name if you're up for that.

Converting it isn't quite mechanical, so here's what it would actually involve —
tell me if you'd rather I did the fiddly part and you reviewed the result:

• It would be two blueprints, not one. A blueprint is a single automation, so
  the resolver and the watchdog stay separate and share the helper.
• The input_text becomes an input. Blueprints can't create helpers, so the
  user makes one and selects it, and the header says to do that first.
• The fleet list is the awkward part. Blueprint inputs have no repeating
  groups, and each head needs three entities that belong together. Either fixed
  slots — say six optional climate/judge/demand triples, robust and a bit ugly —
  or one target selector of climate entities with the other two derived per head
  via device_entities(device_id(...)), which is much nicer to configure but
  matches on entity id and so breaks the moment someone renames one. I lean
  towards the slots, but it's your automation and you may know your users better.

Three things I noticed reading it, all small:

• If one head is explicitly in cool while another is explicitly in heat, both
  sides end up in protected_modes, so no rotation can ever pass that condition —
  and nothing is logged either. That's the state a user is most likely to create
  by hand, so it may be worth a log line saying "locked by manual modes" rather
  than silence.
• The restore step calls set_hvac_mode even when the head is already back in the
  target mode. The integration doesn't dedupe that, and every write takes the
  unit's ~60 s command lease, so an equality check first would save a round trip.
• Your restart protection is real but accidental: after a Home Assistant restart
  every last_changed is young, so everything reads as calling and nothing
  rotates for release_grace_minutes. That's a good property — I'd note it in the
  header, otherwise someone lowers that value and loses it without noticing.

One upgrade note: 2026.9.7 is out and adds a correction for the bias you
measured. Setting 23.5 and landing at 21 is the return-air sensor reading the
unit's own output; the release lets you name a source entity and give it an
overshoot figure, so the setpoint you dial in is closer to where the room actually
settles. Given how much your design leans on that vote being trustworthy, it
should be worth having.

And yes please to the testing offer — four heads on one outdoor unit is a system I
can't reproduce here, I have two. Anything that depends on more than two votes is
something I currently have to reason about rather than measure.

[smdev0925]

Yes. I agree. Thank you — that is a much better home than a gist. I am happy for you to add my name.

In case you missed it, I made the gist more simple after your review, and this changes your items 1 and 2.

There is now one automation only. The watchdog and the input_text helper are both removed. The helper kept a record of the heads that the automation set to fan_only. It was necessary only when the automation set the heads to off. An off head gives no vote, no judge value and no demand value, so nothing can find it again. A head in fan_only is different. You can see it, and it does no damage. So the record made the code more complex and gave too little in return. The remaining risk is now written in the header.

Please do the conversion. I am a web developer, but I have not written a blueprint. I would only guess at the correct method. On the fleet list, I cannot advise you and have no opinion on slots against automatic selection. Please choose.

One thing from my system may help decide... If a head loses its judge sensor, it stops voting. The automation then finds no conflict and stays quiet. That looks exactly the same as "there is no lockout" — the room becomes uncomfortable slowly, and no person thinks the automation is the cause. So whichever method you use, it is better if a head with missing sensors is reported and not ignored.

An observation on AUTO, as an aside

I am testing how AUTO behaves at the ends of its range. It appears to apply a fixed band around the set point.

With the set point at 22 °C:

• All units heat to 23.5 °C, then stop.
• If the mode then changes to cooling, all units cool to 20.5 °C, then stop.

That is 1.5 °C of hysteresis on each side of the set point.

I have an external temperature source configured, with Overshoot Cool at 2 and Overshoot Heat at 1. I cannot yet see a difference from the default values? I would guess a single-split in AUTO does the same thing, but I have no way to test that, and it may not be something that can be changed. I report it only in case it is useful.

Thanks again!

Shane :)

[smdev0925]

Apologies — I should have read the code before asking that. I can see now that no overshoot is applied in AUTO: mode 0 falls through to return 0.0 in _resolve_overshoot.

The question I should have asked is what the reasoning is. Is AUTO deliberately excluded?

Thanks again,
Shane :)

[blues-sechseck]

Both done — and thanks for simplifying it first, that took two of my three
notes with it.

It is in as a blueprint, under your name: blueprints/automation/smdev0925/mhi-multi-split-mode-lockout.yaml (#337). That URL is also what you paste into Import blueprint.
One change worth knowing about, because it is the only part that is not your
automation any more. Your version carried one entity triple per head, which a
blueprint cannot ask for as a group, so it now takes three lists — climate
entities, Cool/Heat Status sensors, Compressor Demand sensors — and pairs them
up by device. Order does not matter and renaming an entity does not break
it. That pairing has a test of its own, because with the lists in different
orders the wrong version would still run happily, just reading one head's vote
off another head's sensor.

Everything else is yours, including the numbers and the reasons in the header.
I left those as prose rather than trimming them: the release grace, the
four-minute stand-down and the cooldown are all scar tissue from a specific
failure, and someone who shortens one without knowing that will rediscover it.

Why AUTO gets no overshoot

You read the code right — mode 0 falls through and returns 0.0. It is
deliberate, and the reason is that the correction has a direction.

The overshoot correction exists because the unit's thermostat band sits below
the setting in cooling: it keeps calling until roughly 1–2 K under it. So we
hand it a room temperature that is deliberately too cold, and its stop point
moves to where the room actually reaches what you asked for. In heating it is
the mirror image, and the correction goes the other way.

In AUTO the unit decides for itself, minute to minute, which of those two it is
doing. A single number cannot be right for both: whichever sign it has, it is
correct in one direction and doubly wrong in the other — it would push the unit
past the setting instead of stopping it there. And the moment we could tell
which way it is going, we would already be back to what your automation does
with cool_hot_judge, only inside the integration where you cannot see it or
switch it off.

So AUTO is left alone rather than guessed at. If it turns out AUTO has its own
band worth correcting, the honest form is a third field, measured in AUTO —
not the cooling number reused.

[smdev0925]

Thank you for the blueprint - this is wonderful! I have loaded it and will continue to test.

In the meantime, I have two tiny changes I'd like to propose:

Within the setup it asks the user to choose their "Cool/Heat Status sensors". I feel it needs to be clear that we are asking the user to choose the [cool_hot_judge] sensors. Just a minor wording change.

Manually running the blueprint/automation skips the check conditions. Perhaps we could guard against that?

      - alias: Nothing to resolve - reached only on a manual run
        conditions:
          - condition: template
            value_template: "{{ not conflict or in_use | count > 0 }}"
        sequence:
          - action: logbook.log
            data:
              name: MHI Mode Lockout
              message: >-
                Manual run ignored - nothing to resolve.
                {{ 'The heads do not disagree' if not conflict
                   else in_use | map(attribute='entity') | map('replace', 'climate.', '') | join(', ')
                        ~ ' still running, so the mode is not free' }}.

I really appreciate the explanation of why AUTO gets no overshoot. That makes total sense, and it does also suggest a possible route.

The idea: exposed the Cooling and Heating overshoot values as diagnostic sensors so an automation can read them, and then add a single AUTO overshoot entity that an automation can write. The integration simply applies that single value on mode 0, exactly as it does for cool and heat today, without needing to know how the value was chosen.

An automation/blueprint outside the integration would do the choosing. When a head's cool_hot_judge changes, it reads the configured cooling or heating overshoot and writes the matching value into that head's AUTO overshoot entity. The direction decision stays where you said it belongs — visible, and easy to switch off.

The obvious drawback is that a stale AUTO overshoot value is worse than none. If the automation stops, the last value written remains applied, and once the unit changes direction that value has the wrong sign.

One way to resolve this could be for the integration to clear the AUTO overshoot to 0.0 whenever a head's direction changes, and let the automation write the new value if one is running. That only needs the integration to notice that the direction changed, not which way it went. And if nothing writes a new value, the head runs uncorrected. I feel a solution would need to be integration-side because the failure case is the automation not running, so it cannot be the thing that cleans up after itself.

The only other thought I had was a possible race condition between the automation providing a new value and the integration clearing the overshoot as the direction changes — I don't know if that's even something worth worrying about?

Thanks again,
Shane :)

[blues-sechseck]

Thank you — and good catches, both of them.

The label is simply wrong: the sensor is called Cool Hot Judge in Home
Assistant, so that is what the field should ask for. And you are right about
the manual run — the checks sit in the automation's conditions, which a manual
trigger skips by design, so it walks straight into the part that assumes there
is something to resolve. Your branch is the right shape and goes in first, so a
manual run says what it found instead of doing nothing quietly.

On the AUTO overshoot, I think you have found the real obstacle, but it is one
step further back than the plumbing.

You are right that the integration could notice the direction: Cool Hot Judge
is the unit's own vote, not a guess, and reading it is no worse than what your
automation already does. What is missing is the number. The cooling and heating
figures are measured — each is the distance between what the unit's thermostat
does in that mode and what the room actually reaches. Reusing the cooling
figure in AUTO assumes AUTO's band sits where cooling's does, and nobody has
checked that. If it does not, the correction is wrong in a mode where the user
cannot see why.

Your race is real, by the way, and it is a symptom of the same thing: if the
value has to be written from outside and cleared from inside, the order of the
two on a direction change is not guaranteed. That argues for the number living
in one place, whichever place that turns out to be.

So the useful next step is a measurement rather than a mechanism, and you have
the system for it: run a head in AUTO with no correction, let it settle, and
compare the setting against an independent thermometer in the room — once while
Cool Hot Judge says cooling, once while it says heating. If those two gaps
land on the figures you already use for cool and heat, reusing them is
justified and the rest is straightforward. If they do not, we would have learnt
something worth more than the feature.

No hurry at all — and thank you for testing the blueprint. Anything else you
run into with it, keep it coming.

[smdev0925]

Morning Daniel,

I will test this and report back. I expect a hysteresis of 1.5 °C each side of the set point in auto mode. Both overshoot offsets are set to +1.5 °C at the moment, cooling and heating.

There is a PR waiting for you — #344. The integration had trouble with a 1.5 °C overshoot: a changed value did not reach the unit until the mode changed. I traced it and sent a fix. The same PR turns the overshoot field into a number box with a 0.25 °C step, which is the resolution of byte 5. 1.5 is already on that grid, so my own setting does not move.

Apologies, I do not have a full test harness set up yet, so please check it. Still getting used to everything :)

Thanks again,
Shane :)

[smdev0925]

Hiya!

I've had a chance to test the system in AUTO mode with an external thermometer, and what we got was some yo-yo-ing!

Setup

Mode	AUTO
Set point	23 °C
Room temperature	external sensor, injected by the integration
Indoor units running	1 of 4 — the other three were switched off

I activated AUTO, boosted the thermostat to kick it into heating, then set it to 23 °C and waited.

What it does

Phase	Turning point (HA)	Same point in Smart M-Air	Δ from set point
Heating	24.8 °C	25.2 °C	+1.8 K
Idle	—	—	—
Cooling	20.8 °C	21.2 °C	−2.2 K
Idle	—	—	—

Then round it goes again. Each loop lasts about two hours in total, and the swing is roughly 4 K peak to peak.

Thoughts

Now, I don't know if this is perhaps an inherent defect in the unit's firmware itself, or a side effect of having external temperature sensors running, but I do think at this point that if we were to artificially correct the temperature inputs we could prevent the yo-yo-ing.

Also, this was a test on one head only, with the other three switched off. Bearing in mind that the four heads obviously share one outdoor unit and one reversing valve: while this head runs in heat, any other head calling for cooling gets hot refrigerant instead, so it blows warm air into the room it is meant to be cooling — exacerbating the yo-yo effect.

I surmise the EEVs on the idle heads are held part open while they wait for the direction to change, so hot gas keeps bleeding into their coils. The EEV Pulses / EEV Position diagnostics should show that. I can enable them on the idle heads and run a longer test if that would help, though I suspect you already know far more about this than I do! No idea whether it is even resolvable, as I am acutely aware that I am suggesting ideas that fight against the heads' own firmware — all ideas welcome!

I include the screenshot of the yo-yo-ing for your reference.

As an aside, the ~0.4 °C gap between HA and the app appears to have been discussed in #218 — byte 5 in 0.25 K steps against the 0.1 K indoor table — and is expected?

[blues-sechseck]

Shane — that is exactly the measurement I asked for, and it turns out to answer
a bigger question than the one we were asking. Your +1.8 is not a control error.
It is in the manufacturer's own documentation.

What the service databook says about AUTO (ZS-WF series, which is yours):

• Cooling is controlled to the temperature you set. Heating is controlled to
  that temperature plus 2 °C. In automatic operation only, and dry gets +1.
• The mode changes only after the thermostat has been off for 20 minutes,
  and only once the room is more than 1 K away from the setting: below SP−1
  it goes to heating, above SP+1 to cooling, and in between it keeps whatever it
  was doing.

Put those together with 23 on the dial and the loop you photographed is not a
fault, it is the design:

1. Heating aims at 25. You measured the turning point at 24.8.
2. 25 is above the SP+1 threshold of 24, so after 20 minutes of thermostat-off
   the mode flips to cooling. It cannot not flip - heating always ends above its
   own upper threshold.
3. Cooling aims at 23, undershoots by its own band (0.6-1.3 K on the units
   measured), and keeps drifting through the 20-minute wait until it is past
   SP−1. You measured 20.8.
4. Back to heating, and round again - two hours a lap, which is what you saw.

So there is a hysteresis, and it is doing its job; it simply cannot help here,
because the heating half lifts the room over the switching threshold every
single time.

Which is why no overshoot field would have saved it. The correction shifts
the room temperature the unit is fed by a constant, so both turning points move
the same way: c = −0.2 would centre your band on 23 and leave all 4 K of width
exactly where it is. And the direction-aware version you proposed would put both
flip points on the setpoint, so the outdoor unit's reversing valve would change
over continuously with four heads hanging off it. That is a worse problem than
the one being fixed, and it is why the write-from-outside race you spotted never
gets to matter.

It is also not the injected sensor. Both numbers live in the unit's own
control, so the same loop runs on its internal sensor. For what it is worth, the
same injection in plain cool on a unit here gives a band 0.35 K wide.

What I would do on your system: don't use AUTO. In cool and heat the
setpoint means what it says, the overshoot correction works, the band is a
fraction as wide - and the direction decision is already yours, made in the open
by your own lockout automation, where you can see it and switch it off. AUTO is
the one mode that takes that decision back and charges you 4 K for it.

If you want the comfort back, the lever is a blueprint, not the unit. In
cool and heat the band is 0.35 K wide - measured here, switch-on to
switch-off - and the overshoot correction centres it on your setting. So an
automation that picks the direction itself and drives the unit explicitly holds
a room inside about half a kelvin, against AUTO's four. What it needs is a
deadband (±1 K is what the unit uses), a minimum dwell after each changeover
(the unit's own 20-minute guard does not apply once you drive the modes
explicitly, so yours is the only thing protecting the reversing valve), and on
a multi-split it has to cooperate with the lockout resolver rather than fight
it - which is your automation, so you are further along that road than anyone.

I am not planning to write it, and I would not put it in the integration: a
changeover is a mechanical decision, and it belongs where you can see it and
switch it off - the same argument I made to you about the AUTO overshoot. But
if you or anyone reading this wants to build it, it is the single biggest
comfort gain available here, and I will happily host it in blueprints/ beside
yours.

Your measurement is in the README now, numbers and all - what auto does
with a setting, why it cycles, and why no correction fixes it. It was in the
service documentation and nowhere a user would ever look. That is the part of
this I did not have before you ran the test.

Two things still worth having:

• EEV position on the idle heads: yes, please. It explains nothing about
  this trace, since three heads were off, but the bleed you describe is the
  lockout question itself and nobody has measured it. Run it long.
• An AUTO band from a single-split would tell us whether any of this is
  multi-split specific. Yours is the first AUTO band anyone has measured at all.

And your aside is right, with one digit moved. The gap is 0.5, not 0.4: your
reading is snapped to the 0.25 grid before it goes out (24.8 becomes 24.75), the
unit echoes it back half a kelvin high in a coarser field (25.25), and the app
rounds that to 25.2. Expected, and nothing to chase.

Both of your blueprint fixes are in, by the way - the field asks for Cool Hot
Judge sensors now, and a manual run says what it found instead of walking into
the resolver.

[blues-sechseck]

Your overshoot fix is released as well, in 2026.9.9-beta3 — a changed value now reaches the unit as soon as you save it, rather than at the next mode change.

[smdev0925]

Hi Daniel,

Thank you for all of your input on this and for the highly detailed explanation — the maths is the part that I am not so good at!

I do wonder why the engineers at MHI thought it would be a good idea to let the units yo-yo like that, because in the context of my setup it renders that mode useless!

With that in mind I have begun building and testing a second blueprint that hands the mode switching to Home Assistant instead. It reads each unit's own setpoint — the setpoint stays the user's, and nothing writes one — and switches the unit to the opposite mode once the room has drifted a set distance past it. Lockout handling is in there as an optional toggle, reusing the rules from the mode lockout resolver I sent you earlier. I am building and testing it on my fork (click for the link). The two must not run on the same units at the same time. They suit very different use cases, and mechanically they would deadlock: the resolver treats an explicit cool or heat as your instruction and never overrides it, whereas the new blueprint produces nothing else. I have documented that in the header of both.

It's going to take me a while to test — the sort of faults it will have only show up over days rather than minutes, and I would rather find them here than in your issue tracker. I'll raise a PR once it's somewhere near right.

On the EEVs, I have been doing some testing there too. These are the integration's relative EEV Position figures rather than a calibrated valve opening.

System state	Bedroom	Kitchen	Living room	Office
Nothing running — all four in FAN	78 %	78 %	78 %	78 %
Office on COOL, others in FAN or locked out	0 %	0 %	0 %	56 %
Kitchen on HEAT, other three in FAN	24 %	78 %	24 %	24 %
Kitchen on HEAT, two in FAN, Office locked out asking for COOL — at the start	24 %	45 %	24 %	24 %
…after 5 minutes	20 %	45 %	20 %	22 %
…after 10 minutes, settled	16 %	38 %	16 %	16 %

With nothing running: every valve rests at 78 %. That is 200 of 255, or 0xc8 — exactly the idle figure in your operating-data table. And your "load ⇒ 95 / 102" is 37 % to 40 %, which is where my Kitchen settles at 38 %. So those numbers agree.

With the direction set to Cooling: every unit that does not need cooling has its valve fully shut at 0 %. This is true whatever mode the unit itself is in — fan, or locked out asking for heat. Only the working unit is open, at 56 %.

With the direction set to Heating: the idle units do not shut. They sit open at 16-24 %, and a locked-out unit is treated no differently from one in fan. So a unit left in FAN or locked out on COOL will bleed heat into the room while anything else is heating.

That last point may be worth a note in the module reference. Under 0x13 it currently says:

0x13 reads 0 on an indoor unit whose compressor is not running, and a normal value on an active one at the same moment.

which true holds for cooling but not in heating.

As for why MHI did this, my guess is that it's about refrigerant migration rather than the fan. In heating, an idle indoor coil is the coldest point in the system, so a fully shut EEV would let liquid collect there and starve the units that are running. In cooling the idle coil isn't the cold spot, so it can be shut completely. Happy to be corrected!

Thanks again,
Shane :)

---

Screenshots for reference

All FAN:

Kitchen on HEAT, all others on FAN:

Kitchen on HEAT, two on FAN, one locked out (wanting cooling). The idle units, locked out or not, were exhausting warm air into the room:

Initially:

After 5 mins:

After 10 mins of running:

Office on COOL, others on FAN or locked out:

[blues-sechseck]

Shane — the 0x13 note is wrong as written, and your version is the right
shape. Mine was measured with one head cooling and one idle, and I generalised
it from that. Your heating rows show idle valves sitting at 16-24 % while a
cooling system shuts them to 0, and a locked-out head behaving no differently
from one in fan is something I'd never have caught here. That paragraph gets
corrected, with your measurement as the source.

Your all-fan row is a nice cross-check as well: 78 % is 0xc8, exactly the
idle figure in the table — different system, four heads, same number.

The migration argument sounds right to me, but I can't confirm it from
anything I have. Nothing here says why the valve stays open in heating.

On the blueprint: no rush at all, and thanks for keeping it out of the tracker
while it settles. Documenting the deadlock in both headers is the right call —
that's the failure people would otherwise find the hard way.

[smdev0925]

Hi Daniel,

Just a small heads up — I've opened a PR with my AUTO mode replacement blueprint. The testing has been extensive and I think it's at the point where it just needs time in service to turn up anything I've missed. The full details of how it works are in the PR.

Getting the method right took dozens of attempts, mostly because of the EEV behaviour: in cooling the valves of the units that aren't cooling close, but in heating they all stay open, so a unit waiting for cooling sits there blowing warm air into the room it's meant to be cooling. Working with that rather than against it is what most of the redrafting was about.

Also, nice work on 2026.10-beta1. I've been running it and the external temperature sensors hold much more reliably now — possibly thanks to the work around the override (#388, #378).

Thanks again,
Shane :)

[blues-sechseck]

Both blueprints are in now, the resolver (#337) and the AUTO replacement (#394), so I'm closing this. Thanks again, Shane, for all the testing behind them.