You should order the 5 pins configuration for the CN105 connector
I’m thinking of one (perhaps basic) thing: i use xiaomi BLE module as external temperature sensor for my climate. I have homeassistant sensor in my esphome for that purpose: original solution says that i can use this for updating value:
- platform: homeassistant
name: "Temperature Sensor From Home Assistant"
entity_id: sensor.temperature_sensor
on_value:
then:
- lambda: 'id(hp).set_remote_temperature(x);'
But what i’m not sure right now is this:
“on_value” option only sends temperature when value changes, correct? If so, what if temperature doesn’t change for a while? I mean - yaml from echavez has built-in option to go back to internal temperature sensor after a while (30 min.) if ti doesn’t receive anything from external one. How can i “make” sensor to update at least once every 30 minutes to prevent going back to internal sensor?
Why the heck can you only order one max from that seller?!
Until yesterday, I had a perfectly good working version of the code for my MiniSplit. After the 2024.6.1 ESPHome update, I can no longer update this device. I have a total of 6 D1-minis deployed and the other 5 updated perfectly.
Here is my complete code with just redactions where necessary:
substitutions:
name: d1m-srms
friendly_name: SR_MiniSplit
esphome:
name: ${name}
esp8266:
board: d1_mini
# Enable logging
logger:
baud_rate: 0
# Enable Home Assistant API
api:
encryption:
key: !secret api_key1
# Synch time with Home Assistant
time:
- platform: homeassistant
id: homeassistant_time
ota:
platform: esphome
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: ${name} Fallback Hotspot
password: !secret wifi_password
# Optional manual IP
manual_ip:
static_ip: ###.###.#.###
gateway: 192.168.1.1
subnet: 255.255.255.0
web_server:
port: 80
captive_portal:
mqtt:
broker: !secret mqtt_broker
username: !secret mqtt_username
password: !secret mqtt_password
external_components:
- source: github://geoffdavis/esphome-mitsubishiheatpump
# Text sensors with general information.
text_sensor:
# Expose ESPHome version as sensor.
- platform: version
name: ${name} ESPHome Ver
# Expose WiFi information as sensors.
- platform: wifi_info
ip_address:
name: ${name} IP
ssid:
name: ${name} SSID
bssid:
name: ${name} BSSID
# Sensors with general information.
sensor:
# Uptime sensor.
- platform: uptime
name: ${name} Uptime
# WiFi Signal sensor.
- platform: wifi_signal
name: ${name} WiFi Signal
update_interval: 60s
switch:
- platform: restart
name: "D1M-Restart - SRMS"
climate:
- platform: mitsubishi_heatpump
name: "${friendly_name}"
supports:
mode: [HEAT_COOL, COOL, HEAT, FAN_ONLY]
fan_mode: [AUTO, LOW, MEDIUM, HIGH]
swing_mode: ['OFF', VERTICAL, HORIZONTAL]
and lastly the complete error message:
INFO ESPHome 2024.6.1
INFO Reading configuration /config/esphome/d1m-srms.yaml...
INFO Detected timezone 'America/New_York'
INFO Generating C++ source...
Traceback (most recent call last):
File "/usr/local/bin/esphome", line 8, in <module>
sys.exit(main())
^^^^^^
File "/esphome/esphome/__main__.py", line 1079, in main
return run_esphome(sys.argv)
^^^^^^^^^^^^^^^^^^^^^
File "/esphome/esphome/__main__.py", line 1066, in run_esphome
rc = POST_CONFIG_ACTIONS[args.command](args, config)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/esphome/esphome/__main__.py", line 484, in command_run
exit_code = write_cpp(config)
^^^^^^^^^^^^^^^^^
File "/esphome/esphome/__main__.py", line 193, in write_cpp
generate_cpp_contents(config)
File "/esphome/esphome/__main__.py", line 205, in generate_cpp_contents
CORE.flush_tasks()
File "/esphome/esphome/core/__init__.py", line 681, in flush_tasks
self.event_loop.flush_tasks()
File "/esphome/esphome/coroutine.py", line 246, in flush_tasks
next(task.iterator)
File "/esphome/esphome/__main__.py", line 185, in wrapped
await coro(conf)
File "/esphome/esphome/coroutine.py", line 80, in coro
ret = yield from _flatten_generator(gen)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/esphome/esphome/coroutine.py", line 118, in _flatten_generator
val = gen.send(to_send)
^^^^^^^^^^^^^^^^^
File "/data/external_components/3b4567cc/components/mitsubishi_heatpump/climate.py", line 66, in to_code
serial = HARDWARE_UART_TO_SERIAL[config[CONF_HARDWARE_UART]]
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'UART0'
It appears to be an error with the external component, but I have not seen any others post an error yet. Has anyone else experienced this or does someone know what I need to do to fix it.
- Note - The Mini Split still communicates with Home Assistant and I can still control the unit from my dashboard, BUT I’d really like to be able to make updates and stay current, so fixing this is a priority.
Thanks. Hopefully someone has an answer.
Art
There is a GitHub Issue for this problem: esphome 2024.6.0 changed the definition of HARDWARE_UART_TO_SERIAL · Issue #152 · geoffdavis/esphome-mitsubishiheatpump · GitHub
In the comments you can find a patched version for the external component:
github://ghisch/esphome-mitsubishiheatpump@patch-1
For me the patched version did work. I hope it will be merged soon.
Just want to share that I have been reading comments, made sure I ordered the right parts and got it setup on my Mitsubishi AC today
To share the link I got them:
D1 Mini: https://www.aliexpress.com/item/32651747570.html?spm=a2g0o.order_list.order_list_main.101.67781802v3BCvC
Make sure to ignore all the v4, v3, Pro versions. Take only the D1 Mini Type C or micro USB versions.
Connector (5P): https://www.aliexpress.com/item/1005002904897793.html?spm=a2g0o.order_list.order_list_main.95.67781802v3BCvC
Guides that I followed:
- Hacking A Mitsubishi Heat Pump Part 1 - Chris Davis’ Blog
- Hacking A Mitsubishi Heat Pump Part 2 - Chris Davis’ Blog
- Integrating Mitsubishi Air-Con (HVAC) with Home Assistant via NodeMCU running Tasmota – isaiahchia
Used these to flash to the D1 Mini: GitHub - gysmo38/mitsubishi2MQTT: Mitsubishi to MQTT with ESP8266 module + GitHub - SwiCago/HeatPump: Arduino library to control Mitsubishi Heat Pumps via connector cn105
My result (model MSY-GE10VA)
Very nice!
Note that not all mitsubishi climates have CN105 connector. I have one (newer) model which has smaller one (also original wifi module is different), also it has 12V power output, not 5V, so original voltage regulator gets quite hot (too hot), so i replaced it with switch-mode version to prevent overheating. I can’t tell model of connector though…i just cut wires of existing (original) wifi model and connected my module to that.
So I have added this repo, it compiles correctly but now when it wants to push to the board it says
‘‘ERROR Error auth result: Error: Authentication invalid. Is the password correct?’’
if I do not put any line and just
Enable over-the-air updates.
ota:
- platform: esphome
I also get error saying it needs a password
my previous config was this
Enable over-the-air updates.
ota:
- password: “xxxxxxxxxxxxxxxx” #OPCIONAL
platform: esphome
tried the new config from esphome website
Example configuration entry
ota:
- platform: esphome
password: !secret ota_password
and put
ESPHome
ota_password: xxxxxxxxxxxxxxxx
in the secrets file but is also not working
what am I doing wrong here ?
Just to clarify is cn105/cn100 port only available with mitsubishi electric? Is there workaround for mitsubishi heavy industries ac?
My warning was for mitsubishi electric, yes. Couldn’t say for “heavy industries” models, though, since i don’t have any.
You already get 5 in 1 order, but I can order multiple?
Sorry i was busy,
If you have a Kumo, you may have MHK1 or MHK2 thermostats that you’d like to keep using, at least for the temperature sensors. This is a github project that uses and ESP32 as a man in the middle between the MHK and the CN105 jack, just like the Kumo interface: GitHub - akamali/mhk1_mqtt: Control Mitsubishi heat pump over the CN105 port using MHK1 and MQTT
It does talk to HA via MQTT, but the nice thing is it keeps the MHK1 thermostat as a point of local control, so it can override HA if it’s down, or the wife demands a non-HA option. You can also override the temp output of the MHK with a local HA sensor. It’s a nice piece of work.
Thanks! Any specifics on the cable I need? Is there a pre wired one to buy? Is soldering required to connect to the Atom s3?
Can you use the standard project with the Airzone CN105 splitter and use the main regular project?
This is the cable that fits on m5 stack products. you then need the CN105 connector solderd on that cable its this type PAP-05V-S be sure to order the the crimp terminals
There is not much documentation there for the “airzone” unit. I’m not sure it would use the same commands as the HVAC unit, so the software may not work.
You’re right. I’ve got it coming so should know if it works.
That said the diagram they should have a wireless controller (their own other air zone product which competes with kumo cloud) and a MKH2. So given this it should work to connect an MKH2 and a modified Wemo D1 or alternative.