I think I've hit a stumbling block, or at least when it comes to any over/undershooting adjustments. I just can't figure out a way of effectively circumventing the fact that the midea unit turns itself off when changing serviceman settings. I've tried adding a building block to the automations that slightly adjust the WCC, in that I've included a sequence action to turn the CH back on. It doesn't work though, I guess because it still does both actions at the same time so it hasn't actually 'exited' the serviceman settings before the sequence action can operate.

It is very annoying that they've designed the controls like this. The only thing I can think of doing just having set flow temperatures at particular OATs which then won't involve any alteration to serviceman settings. That said setting up automations to then dial up or down dependent upon IAT are seemingly problematic as all I can do with automations that change the value of a setting, is to specify a particular value rather than say reduce it by 1 etc.

Any other ideas welcome....

I've just defaulted back to turning off all of the automations and just running the same set curve for the time being.

Posted by: @benson

↑

The midea unit turns itself off when changing serviceman settings.

Are weather curve parameters changed through serviceman mode ? Not in my controller (I think).

Posted by: @tasos

↑

Are weather curve parameters changed through serviceman mode ?

They are on my Midea unit. I wonder if your more recent unit is different?

Posted by: @benson

↑

I think I've hit a stumbling block, or at least when it comes to any over/undershooting adjustments.

Can you remind of the end to end details of how you connect to your heat pump? My auto-adapt script doesn't turn the unit off, even though it adjusts things that manually are found in the FOR SERVICEMAN menu, which means it can be done without turning off the unit. 

Posted by: @cathoderay

↑

Can you remind of the end to end details of how you connect to your heat pump? My auto-adapt script doesn't turn the unit off, even though it adjusts things that manually are found in the FOR SERVICEMAN menu, which means it can be done without turning off the unit.

Via the modbus using the svenar (ESP home?) controller. It is odd how yours works, and this device doesn't.

@tasos definitely in the serviceman settings unfortunately. Sounds like you might have a newer model perhaps.

@benson - can you provide a bit more detail, or links, or even links to the code used? Then I can compare to what I use, to see if I can spot any differences.

So I just put the yaml for the svenar through Claude and it came up with the following:

Begins:

Looking at this YAML configuration for your Midea ASHP, I can see several potential issues that could cause the serviceman mode to turn off when weather compensation curve settings change.

## Key Issues Identified

### 1. **No State Preservation in Weather Compensation Curve Numbers**

The weather compensation curve number controls (registers 6 for Zone 1 and Zone 2) don’t have any `on_value` triggers or safeguards. When these values change, they directly write to the Modbus register without any validation or state management beyond the basic lambda functions.

### 2. **Global Variable State Management**

The global variable `unmasked_curve_selection` is used to track the full register value, but there’s a potential race condition. If both zones are updated rapidly or simultaneously, the second update might use a stale value of `unmasked_curve_selection`.

### 3. **Potential Register Conflict**

The weather compensation curve is stored in register 6, which is split between two zones. If the heat pump’s serviceman mode is somehow linked to specific register values or expects them to be set in a particular order, changing them could trigger a mode reset.

## Specific Problems in the Code

### Write Lambda Issue

```yaml
write_lambda: |-
uint16_t value = id(unmasked_curve_selection); // Uses global variable
uint8_t value_byte = x;

value &= 0xFF00; // Clears lower byte
value |= value_byte; // Sets lower byte
```

**Problem**: If both Zone 1 and Zone 2 curves are changed in quick succession, the second change might overwrite the first before the global variable is properly updated.

## Recommendations

### 1. **Add Debouncing/Throttling**

Add a throttle filter to prevent rapid successive writes:

```yaml
number:
- platform: modbus_controller
# ... existing config ...
name: "${entity_prefix} Weather Compensation Curve Zone 1"
id: "${devicename}_weather_compensation_curve_zone_1"
filters:
- throttle: 2s # Wait 2 seconds between updates
```

### 2. **Add Update Interval Control**

Increase the `update_interval` on the modbus_controller to reduce polling frequency during changes:

```yaml
modbus_controller:
- id: "${devicename}"
address: 0x1
modbus_id: heatpump_modbus
setup_priority: -10
update_interval: 30s # Increase from 10s to 30s
```

### 3. **Add State Validation**

Create a script to validate the state before and after changes:

```yaml
script:
- id: update_curve_zone_1
mode: queued
then:
- logger.log: "Starting curve update for Zone 1"
- delay: 500ms
- lambda: |-
// Your write logic here
- delay: 2s
- logger.log: "Curve update complete for Zone 1"
```

### 4. **Check for Conflicting Settings**

The serviceman mode might be sensitive to the relationship between:

- Weather compensation curve values (register 6)
- Weather compensation switches (register 5, bits 12-13)
- Emission type settings (register 272)

Ensure these are set in the correct order or with appropriate delays.

### 5. **Add Safeguards**

Consider adding validation in the `write_lambda`:

```yaml
write_lambda: |-
// Validate curve value is in acceptable range
if (x < 1 || x > 9) {
ESP_LOGE("curve", "Invalid curve value: %d", x);
return {};
}

// Add a small delay before writing
delay(100);

uint16_t value = id(unmasked_curve_selection);
uint8_t value_byte = x;

value &= 0xFF00;
value |= value_byte;

ESP_LOGI("curve", "Writing curve value: %d (full register: %d)", x, value);

esphome::modbus_controller::ModbusCommandItem set_payload_command =
esphome::modbus_controller::ModbusCommandItem::create_write_single_command(
${devicename}, 0x6, value);
${devicename}->queue_command(set_payload_command);

return {};
```

## Most Likely Cause

Based on the code, the most probable cause is **rapid successive writes to register 6** causing the heat pump’s controller to temporarily lose synchronisation or enter a protection mode. The Midea ASHP controllers can be sensitive to rapid register changes, particularly for critical settings like weather compensation curves.

**Suggested Fix**: Add throttling filters to both weather compensation curve number entities and increase the delay between writes to at least 2-3 seconds.​​​​​​​​​​​​​​​​

Ends.

@cathoderay https://github.com/svenar-nl/Midea-heat-pump-ESPHome/blob/master/heatpump.yaml

Yikes...I don't even know how you managed to find that 😆 . I also don't know if there's any way I can change the code on the physical device I have? I can approach Mr Sven to see if he has any ideas potentially?

Posted by: @benson

↑

Yikes...I don't even know how you managed to find that 😆 . I also don't know if there's any way I can change the code on the physical device I have? I can approach Mr Sven to see if he has any ideas potentially?

lol I have been stalking his repo for a while and am currently building my own smart controller for my Grant Aerona3 

Just had a look at his repo and there is no way to raise an issue on his git-repo so you would need to email him through his website.

@cathoderay is definitely onto something using minimal modbus but I just can’t walk awat from home assistant it is like a drug lol! I have a ton of esp32 chips lying around I might just build a simple controller that can control the ashp and publish the readout to HA. That said my little touchscreen project should do that.

Posted by: @grantmethestrength

↑

Ends.

Indeed. Over and out. Echo Sierra Papa. Another lesson in why you do not want to use AI. It goes off the rails right at the beginning: register 6 is for the fixed weather compensation curves (1-8).  We are interested in the end point settings for the custom curve (curve 9). I suspect incorporating any of the AI suggested fixes would do a lot more than just turn the unit if, they might well terminate it permanently.  

The curve 9 end point settings are in the yaml file (thanks for the link), at lines 2722 and 2734, registers 265 and 266, but I can't make out how they are used.

There are two things in particular I want to look at: how it makes the modbus connection (the 'handshaking'), and how it writes to the register. The code I use for the latter (having used minimalmodbus to make the connection) is for example:

        if aIAT - dIAT >= 3:     # house is too warm, lower ends of WCC by 3 degree C
            instrument.write_register(265, leftBase - 3, 0)  
            instrument.write_register(266, rightBase - 3, 0)

where aIAT is actual IAT, dIAT is the desired IAT, leftBase is the default left hand setting and rightBase is the default right hand setting.

@benson - no harm at all in trying to contact Mr Sven. He may not even know the problem exists, because I suspect few people are trying to do what you are trying to do. The registers are in the code because, so far as I can see, all the registers are in the heatpump.yaml file (itself quite an achievement!), whether they are directly used or not. Even the first run drying out the floor settings are in there, how many people will use them?  

Note: edited for clarity

@grantmethestrength yes I remember you mentioning. Sounds impressive what you are doing. Hats off to you, and cathoderay...definitely lagging behind with respect to both of your knowhow when it comes to the more advanced stuff like coding.

I feel like this is another stupid question but could he apply a firmware upgrade remotely to all of his devices, if it was an issue with the coding? How would I know if the device is firmware upgradeable?

@benson it is based on an esp32 so yes it is updateable but you would probably need to do it yourself or send it back for an update. I haven’t used this particular one but I am assuming you had initial instructions to place a yaml file into esphome and then compile and then upload it to the device. If you get an update you would just do the same process.