It is fixed

I'm just getting a blank page, other than for the summary coloured sections at the bottom.  I was hoping to use one in a forum reply, but it would be of no use currently.

when the heat pump can talk with Melpump/Melcloud again the two will synchronise that state in one way or another so that either Melpump/Melcloud recognises the pump should be in holiday mode and updates the state retrospectively or the heat pump knows it's not in holiday mode and tells Melpump/Melcloud to sort itself out to reflect this.

Okay, thanks for explaining - it would be the former. The heat pump current state is always reported actual, regardless of attempts to change it.

• Both in my adapter and the official MELCloud adapter there is retry logic, to compensate for potential write failures caused by a rejection in the FTC as it could reject the command when "busy" or a malformed packed in the serial communication (due to electrical interference for example) and it is limited to a fairly conservative quantity.
• MELPump and Home Assistant both work in a optimistic approach, where the change is considered successful until proven otherwise (confirmed by the next read)
• I don't have evidence to suggest that MELCloud has any retry logic if the command was unable to reach the heat pump due to a connectivity issue
• MELPump has retry logic, where if that optimistic state was proven unsuccessful shortly after it will perform another attempt

...

I don't think either will take precedence, it is last received.

...

Thanks, @f1p. My issue with understanding is a matter of what's being changed and how - something I don't know, so in need of illumination.

It seems to me a matter of whether we're talking about an event or a state, and forgive me if I oversimplify my explanation for the benefit of non-coders who may also be reading.

If there's a schedule to trigger an event - like "start heating the hot water" - then understandably that action will start when the trigger is hit either by the local schedule or the Internet one, whichever happens first if both want to try controlling it. If that schedule is only an Internet one and the trigger can't be sent to the heat pump for some reason (e.g. Internet connectivity issues), the heat pump won't do anything when it and the Internet can see each other again. However, if that event puts the heat pump in a particular state (e.g. holiday mode), when the heat pump can talk with Melpump/Melcloud again the two will synchronise that state in one way or another so that either Melpump/Melcloud recognises the pump should be in holiday mode and updates the state retrospectively or the heat pump knows it's not in holiday mode and tells Melpump/Melcloud to sort itself out to reflect this.

For various schedules, I simply don't know if it's events or states that matter (probably sometimes both) and, if it's a state needing to be synchronised how the precedence will work.

Of course, I may be overcomplicating things here. It wouldn't be the first time.

and I believe if that occurs then the in house settings take precedence

I don't think either will take precedence, it is last received. Now this will be for the likes of temperature setpoints, because in the case of prohibit windows, that is not something which via MELCloud can command.

Regarding schedule conflicts, the main issue is that internet time is used for triggering actions from the internet services like MELCloud & MELPump, where on the main controller it will be using local time.
And they are almost certainly not aligned exactly which results in this whichever command was received last.


The final part is how the MELPump CN105 Adapter works, because enabling MELPump App Control Mode (also known as Server Control Mode) will ignore all FTC schedules, thus preventing scheduling conflicts

set my schedules up using the ftc5

I would say Yes, to this. What users find though is there are not enough change points permitted within the FTC for tariffs like Octopus Cosy and this is why there is a use case for internet controlled schedules.

...

question re schedules, if i want to run schedules for hot water and slight temp variations throughout the day, if i use melcloud or melpump, do i need to set anything via the FTC5, ie if there are schedules on there do they need to be removed and the mode left in "run" or "scheduled". i'm basically thinking of avoiding conflicts between the FTC5, melpump and melpump. 

This might be one for @f1p to chip in on for confirmation about the CN105 dongle but my understanding is as follows:

• With standard operation as Mitsi intended, the scheduling in Melcloud and the scheduling on the in house display are NOT integrated. It is possible to make changes to schedules on the in house display that conflict with the Melcloud scheduling, and I believe if that occurs then the in house settings take precedence. It is also certainly true that there are some types of scheduling that can only be done in house, and any scheduling done via Melcloud requires that the Internet connection be up when Melcloud needs to send the trigger.
• With Melpump being used in the mode that uses the Mitsubishi API for data, all the details of the previous point still apply even though more information is exposed.
• With Melpump being used in conjunction with the CN105 dongle - and here is where I'd need @f1p's confirmation - I believe there is still a disconnect with the in house schedules and so there remains a potential for conflicts between schedules. If this arises, I am less sure that the in house schedule will always take precedence, and I think Melpump still needs your Internet connection to be up to talk real time with the dongle when a trigger occurs.
• Given the CN105 dongle can also be managed locally (e.g. via Home Assistant), this would remove the issue of the Internet connection being down when a trigger needs to be sent, but if my previous point is correct - that the CN105 dongle doesn't actually store schedule information - this would mean any schedules created in Home Assistant would be independent of the in house schedules.
• I don't believe any conflicts arising from any of these scenarios would cause any harm; just produce unpredictable and confusing results.

Does that help at all?