Hello All,
I'm using the excellent echavet/MitsubishiCN105ESPHome integration to control my ACs.
One small pet peeve: the ordering of the fan modes when using the HA selector. They show as per the image below
I would like them to be in logical order (or any custom order really). Is that possible ? If yes how, if not, why 
?
I can probably live with it but it's grating my OCD.
Feel free to suggest another place if this is not the right sub-forum to post that one in.
Did you try reading through the Esphome documentation???
Somewhere within your Esphome code/config you should see an array of your fan modes listed and whatever order they appear in your code, that's most likely the exact same order that they appear in as default like you're seeing currently. Try editing that list from first/last the way you want it to appear and see if that does the trick.
Also, it really helps a lot more if you can also include your current Esphome config from the very start and then people like myself could have just looked through it for you but, its not included so i cant do much more than give you best guesses....
Hey thanks for the reply - sorry I deactivated the notifications so I never saw it until now.
Yes I tried that but it does not make a differnce in the UI.
Here is the ESPHome code
esphome:
name: ac-office-t
friendly_name: ac_office_t
esp32:
board: esp32dev
framework:
type: esp-idf
uart:
id: HP_UART
baud_rate: 2400
# Wired to the board's TX0/RX0 header pins (UART0 native pins).
# NOTE: these are shared with the onboard USB-serial chip — this only works when
# the board is powered from VIN (5V), NOT over a USB cable (USB would drive RX0 and
# fight the AC's TX line). Flashing is OTA, and logger baud_rate: 0 keeps the console
# off these pins.
tx_pin: GPIO1 # TX0 -> AC RX
rx_pin: GPIO3 # RX0 -> AC TX
external_components:
- source: github://echavet/MitsubishiCN105ESPHome
# Climate entity configuration
# Room temperature is on the climate entity's `current_temperature` attribute; the
# sub-sensors below add standalone entities (power/energy/compressor/outside-temp/
# runtime), confirmed reporting on the living-room unit.
climate:
- platform: cn105
id: hp
name: "Office AC"
update_interval: 2s
# This AC model only supports Cool, Dry, Fan and Auto — there is no Heat mode.
supports:
mode: [AUTO, COOL, DRY, FAN_ONLY]
# These units have a vertical vane only — no horizontal swing.
swing_mode: ["OFF", VERTICAL]
fan_mode: [QUIET, LOW, MIDDLE, MEDIUM, HIGH, AUTO]
compressor_frequency_sensor:
name: "Office AC Compressor Frequency"
entity_category: diagnostic
outside_air_temperature_sensor:
name: "Office AC Outside Temp"
input_power_sensor:
name: "Office AC Power"
kwh_sensor:
name: "Office AC Energy"
runtime_hours_sensor:
name: "Office AC Runtime Hours"
entity_category: diagnostic
# Discrete vertical vane position (swing / 1-5 / auto) as its own select entity.
vertical_vane_select:
name: "Office AC Vertical Vane"
# Default logging level (DEBUG during bring-up to see CN105 packets; lower to INFO once working).
# baud_rate: 0 is REQUIRED here: the AC is on TX0/RX0 (GPIO1/3), the same pins the logger's
# hardware console uses — any console output would corrupt the 2400-baud CN105 signal. Logs
# still stream over WiFi/API. (Also avoids a watchdog crash from the console UART flooding
# during a failed-connect reconnect loop.)
logger:
level: DEBUG
baud_rate: 0
# Enable Home Assistant API
api:
encryption:
key: "blabla"
ota:
- platform: esphome
password: "blabla"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# ESP32 wifi power-save can make the device connect then silently drop off the
# network — disable it for an always-powered controller.
power_save_mode: none
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Ac-Test Fallback Hotspot"
password: "blabla"
captive_portal:
THe order in the esphome config file has no impact on the UI.