Sorry for the very long time to reply (again) - it took me a while to figure out a test environment to run this PR in, and by the time I did it appears not to work with the head version of HA so I made a local edit to fix that. (The HA specific package for HTTP status codes was removed, I can post more details if helpful).
I’ve been using this setup for a month on a test machine now, and gathered some feedback.
I’m currently just to control the ASHP zone flow temperatures dynamically. (The overall heating system is managed in a Loxone miniserver, which has it’s own flow compensation curve; I’m using HA to relay those target flow temps into MELcloud). This is working really well in the current cold snap, so that’s great!
So a few thoughts/comments:
This works fine for me programmatically, but from a UI point of view in the HA dashboard the 6 heating controls for 2 zones is confusing. So long as I’m running this on a different HA instance, that doesn’t impact me so much, but I imagine if this were in the main release and on my main HA instance I might find it annoying.
Also, in general, I don’t want these controls visible in the UI, as accidentally changing flow target temp while flinging through the UI dashboard on a phone could be dangerous, and result in too hot UFH flow temperature and damage to wood floor finishes. Maybe these internal controls should be marked as hidden by default in the UI and just there for people writing automations and calling services programmatically?
Having a way to configure a hard-stop min/max on the zones would also help.
I can’t seem to use it to change ASHP mode from heat to cool and back. This is presented as an independent option on both the zone controls, so I’ve tried setting those in the UI and programmatically (in Dev Tools). And also tried turning “on” the cooling specific zone controllers, but none of them result in a mode change on the ASHP itself.
In the MELcloud app this is a single global setting for the unit, not a per-zone setting, so not sure if that has something to do with it.
If I recall correctly I had had this working on the experimental fork of the component, so maybe something changed. I can try and re-verify that if helpful (although again I guess that fork will need bringing up to date again).
Let me know what further input would be helpful, and thanks again for all the work on this!
@joth Responses below. Overall this stuff is a bit weird overall because I don’t have an ATW device myself. Although it would be pretty sweet to have one installed if I had the spare cash
I have to admit the whole 6 climates thing is a mess. It is just difficult to detect the desired setup from device config.
The idea here is to attach the relevant controls to the dashboards and forget about the rest. I’m thinking the dashboard setup as a configuration step that you’ll have to do some way or another anyways.
This way you don’t see extra modes or have to remember how the modes map.
Another approach would be to add a state property “control mode” concept for thermostat/flow/curve. This approach makes it just a little weird when you want to automate mode change and temperature set at the same time.
To sum it up: modeling an ATW device is a mess and you are going to see 6 things for 2 zones no matter what. It’s more about where those things are, how simple the setup is and how usable the end result will be.
I’m not so sure if the flow controls are actually only internal. Min/max limits were briefly discussed in this topic not so long ago. They don’t fit the entity model and my suggestion is using an automation. There could be an integration providing such limiter for any arbitrary state property as well.
The zone specific controls target the same property. If you set one, both are set to the same value. If something doesn’t work, it’s most likely because I accidentally broke it.
A possibility to avoid the Ecodan curve setting using could be to create an own curve, generated into the integration, and always operate on the flow temperature control.
This is also a way to open to the replacement of the external ambient temperature sensor, the Ecodan sensor is poor, slow and often affected by the machine temperature in the various working conditions.
I updated the password in my MelCloud account for a more secure one. Is there a way to upgrade the password in the HA Integration? If I delete the integration and re-add it with the new password, all the entity names might get messed up…
The integration does not store the password. The password is used to fetch an auth token and only the token is stored.
You don’t need to delete the integration if you want to refresh the token either. You can add a new MELCloud integration with with the same email. If the a MELCloud config with the same email is found, the existing token is updated and the registration process is aborted. The existing entities are not modified. This process can be used to refresh the token if it expires.
I had initially planned to build something that would bypass the cloud. Wiring into the proprietary connector is not something I am super excited about. The cloud solution works way too good for me. Maybe emulating the an IR remote would be the best non-intrusive middle ground.
Anyways regarding the external curve option, I think the natural approach would be to get the flow control support merged and to build something using automations or appdaemon. Adding this stuff to the integration does not seem natural. I have a temperature curve setup for heating up the cars based on the temperature and it works like a charm.
Getting the flow control / Ecodan entity split PR or something else accomplishing the same goal just not moving too fast. Someone owning an ATW unit would need to help me out here and sort out the bugs and inconsistencies in that branch.
As this integration uses MELcloud that does not directly belong to the possibilities. You can however indirectly influence the flow temperature adapting the thermostat settings.
I’m still seeing the energy sensors displaying 0 regularly but after some time they are refreshed and are numbers presented. If I look at the history the data should be available:
The temperature sensors have no problems. Does anyone recognise this? I’m using scan_interval: 60 and command_timeout: 20.
If I zoom in at the sensor it looks like a pattern of 1 minute (un)availability:
hey guys, thank you to eveyone that posted here, it was a great big help for me to get my energy consumption imported in home assistant for a air-to-water zubadan/ecodan heat pump. gona post it here just in case it can help anyone else
- platform: rest
name: heat_pump_api
resource: https://app.melcloud.com/Mitsubishi.Wifi.Client/user/ListDevices?id=YOUR_ID&buildingID=YOUR_BUILDING_ID
method: GET
headers:
X-MitsContextKey: 'YOUR_CONTEXT_KEY'
value_template: "OK"
scan_interval: 60
json_attributes_path: "$..Devices[?(@.DeviceID==YOUR_DEVICE_ID)].Device"
json_attributes:
- CurrentEnergyConsumed
- DailyHeatingEnergyConsumed
- DailyCoolingEnergyConsumed
- DailyHotWaterEnergyConsumed
- DailyEnergyConsumedDate
- platform: template
sensors:
heat_pump_power:
friendly_name: "Heat Pump Power"
# availability_template: "{{ is_state('sensor.heat_pump_api', 'OK') }}"
availability_template: >-
{{ (states("sensor.heat_pump_api") not in ["unknown", "unavailable"]) and (state_attr('sensor.heat_pump_api', 'CurrentEnergyConsumed') != None) }}
value_template: "{{ state_attr('sensor.heat_pump_api', 'CurrentEnergyConsumed') }}"
device_class: power
unit_of_measurement: "kW"
heat_pump_daily_heating_energy_consumed:
friendly_name: "Daily Heating Energy"
# availability_template: "{{ is_state('sensor.heat_pump_api', 'OK') }}"
availability_template: >-
{{ (states("sensor.heat_pump_api") not in ["unknown", "unavailable"]) and (state_attr('sensor.heat_pump_api', 'DailyHeatingEnergyConsumed') != None) }}
value_template: "{{ state_attr('sensor.heat_pump_api', 'DailyHeatingEnergyConsumed') }}"
device_class: energy
unit_of_measurement: "kWh"
heat_pump_daily_cooling_energy_consumed:
friendly_name: "Daily Cooling Energy"
# availability_template: "{{ is_state('sensor.heat_pump_api', 'OK') }}"
availability_template: >-
{{ (states("sensor.heat_pump_api") not in ["unknown", "unavailable"]) and (state_attr('sensor.heat_pump_api', 'DailyCoolingEnergyConsumed') != None) }}
value_template: "{{ state_attr('sensor.heat_pump_api', 'DailyCoolingEnergyConsumed') }}"
device_class: energy
unit_of_measurement: "kWh"
heat_pump_daily_hot_water_energy_consumed:
friendly_name: "Daily Hot Water Energy"
# availability_template: "{{ is_state('sensor.heat_pump_api', 'OK') }}"
availability_template: >-
{{ (states("sensor.heat_pump_api") not in ["unknown", "unavailable"]) and (state_attr('sensor.heat_pump_api', 'DailyHotWaterEnergyConsumed') != None) }}
value_template: "{{ state_attr('sensor.heat_pump_api', 'DailyHotWaterEnergyConsumed') }}"
device_class: energy
unit_of_measurement: "kWh"
heat_pump_daily_energy_consumed:
friendly_name: "Daily Heat Pump Energy"
availability_template: >-
{{ (states("sensor.heat_pump_api") not in ["unknown", "unavailable"]) and (state_attr('sensor.heat_pump_api', 'DailyHotWaterEnergyConsumed') != None) }}
value_template: "{{ state_attr('sensor.heat_pump_api', 'DailyHeatingEnergyConsumed') + state_attr('sensor.heat_pump_api', 'DailyCoolingEnergyConsumed') + state_attr('sensor.heat_pump_api', 'DailyHotWaterEnergyConsumed') }}"
device_class: energy
unit_of_measurement: "kWh"
