Thanks for writing here — the step-by-step testing you did was useful.
I probed the MELCloud API directly to see exactly what it does with the holiday-mode start time. Here’s what I found, and it shifts the picture a little:
The flow card and the Homey settings page call the same MELCloud endpoint. The settings page isn’t bypassing the API — both go through it. So the difference you’re seeing isn’t “settings vs API”
The start time isn’t being truncated to whole minutes. When I set a start with seconds (e.g. 23:33:44), MELCloud stored it verbatim, seconds and all. And when I set a start that was already a few seconds in the past, MELCloud still accepted it and turned the holiday-mode flag on. So “hh:mm:00 has already gone past” isn’t quite what’s happening under the hood.
What does differ: the flow card uses “now” as the start, whereas in the settings page you pick a start time in the future. That’s the real distinction between your working and non-working cases.
So the API stores everything correctly. The one thing I can’t see from the API is whether your physical unit actually flips into holiday mode — that live state isn’t exposed. If the unit genuinely doesn’t switch on an immediate (“now”) start, that would be the unit’s own firmware behaviour: some units only trigger when the clock reaches the start time, so a start that’s already a moment in the past is simply never crossed. That would match what you saw — but I’d rather confirm it than guess. On my side: I see immediate effects – devices off with are turned on, or the other way.
For remind: holiday mode doesn’t work with Home API yet.
By the way I’ll improve the flow card in the next release, by adding an optional time setting.
Adding a start time to the card is a great compromise. Thanks for your detailed internal analysis of the situation. Your explanation is very clear.
I agree that the system turned the holiday mode flag on - using the AND flow card showed that. As you understand, the problem was that the system did not actually switch into holiday mode (DHW still working, for example). In a way this makes the problem even worse - the system indicates it is in HM when it actually is not.
After sending my previous message I wondered if the problem was a clock-time mismatch between my Homey and Melcloud (or my local controller). I guess the time passed to the API is picked up from Homey’s clock - if that is running late compared to Melcloud/controller then the time will already have gone past. HM turns on, but the physical change of mode never occurs.
If you are adding a start time, is it possible to add an end date and time too (if the API supports it)? That way you match the full capability provided by the App settings. It will be useful to have an end time because the Heat Pump gives priority to DHW when it changes mode. Having an end time means I can ensure the peak demand (initial heating of water after a long gap) occurs at a time of cheap power (and ensure the battery is full before the ASHP starts work, too).
Hi @David_Piper, available in testing, I’ve added a new card with duration + end time.
Start date/time isn’t accurate in the flow context because in the automation philosophy, that’s a trigger which starts actions – if you want to simply start and end the holiday mode at a given date and time, the app settings are enough, no need for any flow.
Except, I have a whole bunch of devices I want to follow the same holiday mode. I have a “holiday mode” flow that does most of the work, but I still have to do the Melcloud ASHP manually. I want the holiday flow to control the holiday mode for all relevant devices - using settings I can’t do that. I don’t use the homey date and time, I use calendar entries to drive the start and end date AND TIME of “away mode”. I have a “holiday preparation” flow that uses the calendar entries to either “programme” the device (as Melcloud could be) or that sets up the calendar app entries to trigger more specific flows at the right date and time.
For example, if we are away in winter time, I want the ASHP to power up and the rad valves to open up at the same time. I know the load in the house is going to increase, so I want the battery to charge as much as possible during off-peak times for cheap energy.
A workable alternative would be to use the Melcloud app settings as “the calendar” - but then I would need flow cards to tell me when the holiday start and end dates and times are. Either way I would dearly like to either set the settings or read the settings in a flow - whichever is easier.
@David_Piper, the cards contain a zone selector, which allows a control at device level if you want. App settings also allow to set for devices individually. Doesn’t it address your need?
But not all the devices that I need to control are Melcloud devices, so I need a way of coordinating holiday mode settings from one homey app to another. As far as I know, flows are the only way of achieving this. If you have alternatives I am happy to evaluate them.
What I mean is that since for you the trigger is a time, the right place is not the action card, but the « date and time » trigger one, which can trigger any device action you want. Start date on the action card is useless or a duplicate of the trigger (which is, by definition, not the action card).
First of all, thank you very much for all the work you are putting into the MELCloud Home integration. It has become really useful, and I really appreciate the time and effort you dedicate to developing and maintaining it.
I’m using a Mitsubishi Ecodan connected through MELCloud Home. I can select “Fixed flow temperature – cooling” as the thermostat mode, but I cannot find any action card that allows me to set the actual cooling flow temperature, for example changing it from 14°C to 15°C.
Is this function already supported and I am simply missing the correct card, or is it not yet available for Ecodan devices connected through MELCloud Home?
If it is not available yet, do you know whether the MELCloud Home API exposes this setting, and is it something you might be able to add in a future version?
Indeed that’s something possible with the classic MELCloud API, but I’ve simply not found how to set such a value even in the official MELCloud Home app, hence the limitation.
if you send me a screenshot where you can set it in the official app, I should be able to implement.
Unfortunately, the flow temperature cannot be changed in the official MELCloud Home app either. It can only be adjusted directly from the physical Ecodan controller.
So I understand that this setting is probably not exposed by the MELCloud Home API and therefore cannot currently be implemented in Homey.
Sounds strange to me, maybe the API exists but until it’s publicly expose, I can’t do nothing… I don’t have a air-to-water device, so I cannot monitor myself, but don’t hesitate to ping me in case the Home app evolves.
By the way I’m still waiting for a 2-zone device to handle it in Homey.
