@ollo69 The latest version already supports vane control through the set_vane_horizontal and set_vane_vertical services. There’s also a PR open for adding this into upstream home-assistant https://github.com/home-assistant/core/pull/32672
@xti9 Ecodan support is merged to upstream home-assistant and it’s on its way to 0.107.
@snowatom I’ve considered the configuration.yaml approach a sort of a second rate solution. You can add the integration through the user interface without much effort. If you really want to use the configuration.yaml you can find the header like this:
Login to MELCloud with Remember me selected and English as your language.
Hit F12 to open Developer Tools.
Go to Network tab in the Developer Tools.
Filter by XHR and open a device in the MELCloud user interface.
Open the Get?id=xxxxxxxxxx&buildingID=xxxxxxxxxxxxx and go to request headers.
Find the header from the list and copy its value.
Both approaches produce roughly the same config or config entry, but the configuration.yaml one is just a pain. I’ve configured my setup through the HA user interface.
Thank you so much (not in a million years would I have figured this one out myself). Will it then work the same, as my previous custom component ? - I’ve read something about needing to upgrade token every now and then, and passwords not being remembered, which I have no issues with, on the custom component.
There are several differences compared to oOZz’s work. Mostly mode names, swing modes vs services, etc. You’ll notice the differences pretty quick if you have automations.
I’ve never seen an expired token this far. If the token expirations start causing issues I’ll figure something else out.
This is my personal opinion, I like to have the option to control swing from Lovelace interface using Climate badge, for this reason I managed using Swing feature. With service this is not possible.
I also added a couple of sensors (WiFi signal and Error status), expecially the first is usefull for me to check that there are no issue in wi-fi connection.
Thanks. Trying out your melcloudexp til the 0.107 is released. Have added to folder of melcloudexp to custom_components folder. What is mean by setting up thorugh UI with a config-flow?
Managed. This is great mate!
Would be good should the water-heater also be based on a thermostat.
The services water_heater.turn_on, water_heater.turn_off apply to the whole ecodan system or to the domestic hot water only? Would you consider a similar service to turn on or off the climate control? This would allow automations based on a schedule to turn on/off the house heating.
The climate/thermostat card is a lot more comprehensive compared to the water heater card. I didn’t dare to go for incorrect entity type to get a better UX tho.
The power toggle controls the entire system. I don’t remember whether I have explained the Ecodan turn_on/off saga on any public forum yet so I’ll just give that a go:
It does not seem to be possible to turn on/off the zones individually through MELCloud and from what I’ve understood the local HMI doesn’t do much more. If anyone figures out a way to do this through MELCloud please share this forbidden knowledge.
I had wired the zone climate power toggle to the system level power toggle in the first attempts at supporting Ecodan devices. As it turned out no one liked that. Having a power toggle on the zone climates implies you can toggle just the zone on/off. I removed the power toggle just to avoid any confusion.
The only way you can effectively turn a zone off is to set the target temperature below ambient and ensure the zone(s) is set to heat. Not ideal, but given the circumstances that’s the best you can do. The best approach I can think of would be to add an input_number entity for setting the target temperature and using automations to set the zone climate target temperature to 10°C for off and input_number value for on. Not seamless, but usable.
Yes you seem to be right. Although Ecodan itself will let you run/pause/time either the tank or heating functions, this doesn’t seem possible form their cloud software. Even the timer on the cloud software only set ‘presets’ and therefore seems as though the principle that could be adopted is only one where you lower the target temperate to effectively turn off either tank or heating. Bit odd…
I have found a workaround which requires more hardware though. The Ecodan takes as input the command to activate or dis-activate heating (as a thermostat input). I have hardwired that to an ESP based relay board (sonoff converted to ESPhome) and can turn on and off the switch to turn on and off the heating in any way I need. Let me know should anyone need more info.
Hello @vilppuvuorinen, thanks for the integration! I have first installed the experimental version (running on home assistant v.106.6) and now I am using the official integration in v107.
In my case I have an issue with the status of the 2 zones, as they are mentioned to be “off” even when they are actually “on”. I attach screenshot of the two views, side by side.
Did you receive any feedback about the same issue?
In the screenshot I am also including the extra data that I am pulling by using the API (view-only). There is a lot of info available, maybe in the future you might look at adding more parameters to the integration.
I was using your old integration that only add the climate.* and it was working great. I decided to upgrade it using melcloudexp. Removed the old folder from custom_components. Moved the new one “melcloudexp” and did the configflow but it does not find any devices. I have 4 Air-to-Air Mitsubishi Kirigamine. It was working before. I’m in 0.107.6
@guidods This is the first time I’m hearing about this issue. The first point here is that it looks like I haven’t exposed the off mode through the water heater operation modes. An awkward start.
What usually happens on startup is that the operation mode is out of sync for a good minute or so. Otherwise I can’t figure out anything quick. Could you provide me the list devices and get device captures from the MELCloud API via a private message? I’ll figure this issue out and add the anonymized caps to the test suite.
I’m already looking into adding the flow control mode for the zones. It would add some of those values. There’s also a PR open for the client library for some additional parameters that I haven’t had time to look at yet. I’m not 100% on board with adding every possible value as a sensor as there’s a ton of those values in the responses.
@DeviDarkL If you are on 0.106.0 or later home assistant I recommend dropping the custom component and using the MELCloud integration available in upstream home assistant. It’s lacking only the vane control services at this point compared to the experimental version.
In any case you could try removing and adding the integration again. Let me know if the issue persists.
Hey, i’m on 0.107.6. I’ve removed the Ooze custom component and tried MELCloud integration and the experimental one. Using integration UI both say “This integration has no devices.” It doesnt seem to find my ACs
Have you assigned the devices to areas in MELCloud? oOZz’s integration seems to be doing a better job at iterating for devices. This is definitely the case if a device appears in home assistant after it has been removed from its area.
I have been using your plugin now for a while together with my Mitsubishi Kirigamine FH25 and it’s working great. Before testing your plugin I have also been using oOZz’s plugin…
One thing I have noticed with both plugins is that the “i-see sensor” stops spinning when changing operation mode, from example cooling to heating.
I just wonder if this is something you have noticed that have used these plugins?
@DeviDarkL: I didn’t quite get the custom component updated over the weekend. I tried to do some other updates to the client lib and at the end of the day (or weekend in this case) I got nothing finished. I’ve now updated the client lib and the custom component is pointing to the new version. I’d appreaciate it if you could test it out.
The update frequency for the energy reading is slow. Like really slow. The value is updated on average less than once every hour. You should use the utility_meter integration instead to graph energy consumption during desired intervals. Like daily, weekly and so on.
@anasazi: Nice catch. I have no idea how you could have noticed something like this. I had to go take a look at my unit right away and the sensor is indeed stationary.
It does look like the operation mode is somehow connected to the sensor tho. I’ll have to check if there are additional operation modes that map to something like “heat with scanning”. Current implementation should match the MELCloud user interface and therefore the sensor should also stop if the mode is changed through MELCloud UI. I really need to look into this.
