Posted by: @f1p

↑

...

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.

Posted by: @majordennisbloodnok

↑

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

Anyone else having issues getting Melpump to display their 'interactive' charts via the Share as URL option?

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.

Thanks for reporting, there is a known issue following a security adjustment

Posted by: @f1p

↑

Thanks for reporting, there is a known issue following a security adjustment

It is fixed