Some newbie (sensor) questions

[DamijanD]

Hi.

As a proud owner of new atom (with 2 zones + melcloud) I first need to say big thanks to @gekkekoe for implementation and @fonske for HW delivery.

And now some sensor questions:

• 3-way Valve and 3-way Valve 2: shouldn't this be one sensor with state: position1(heating) or position2(DHW) at least this is how I see it - so this is the same 3-way valve in different positions
• What is the difference between Estimated Output Power ( 4.737 kW) and Output Power (4.000 kW) I have noticed that later is always floor of the first one?
• Water Pump Status this is internal pump, and Water Pump 2 Status is external pump. I am missing the second external water pump - each zone has one. Via melcloud I can get IdleZone1 and IdleZone2. And this is the only thing that I am missing in this device/implementation.
• In HomeAssistant by default I get 2 entities for each zone:ecodan_heatpump_zone_1_temperature and ecodan_heatpump_zone_1_climate what is the difference between the two?

And some newbie observations/questions:

• if you want static IP, that needs to be set in firmware
• when you first start it, it could mess up your settings (DWH was set to 50° and room temp was set to 16°)
• as this is my first EPShome device there are some other questions:

1. How can I upgrade firmware via web interface. On http://[IP of the device] there is no upgrade option
2. ESPHome integration for HA: will it detect device by itself or do I need to add it manually? If I add it will it add new device to HA as well (I don't want a duplicate to be created)?

[F1p]

3-way Valve/3-way Valve 2:
Some models of package have more than one, usually 3-way valve 1 is for DHW/Heating where valve 2 might be for boiler & heat pump combo system

What is the difference between Estimated Output Power ( 4.737 kW) and Output Power (4.000 kW)
Estimated Output Power is based on a Formula the ESP is performing, "Output Power" is provided by the FTC and is rounded to floor 1kW - is it the same with input power (don't think input implemented in this repo)

Water Pump Status this is internal pump, and Water Pump 2 Status is external pump. I am missing the second external water pump - each zone has one.
Pump 1 = Primary Water, Pump 2 = Zone 1 (not connected though), Pump 3 = Zone 2, Pump 4 = Hot Water, Pump 13 = Zone 1 for me

I don't think all the pumps were implemented in this repo, you could make a pull/feature request

Via melcloud I can get IdleZone1 and IdleZone2. And this is the only thing that I am missing in this device/implementation.
I don't think Gekkekoe has a 2 zone system so didn't implement, you could make a pull/feature request

[gekkekoe]

thx @F1p for answering most questions.

• the climates are the entities to control/set temps.
• see esphome for static ip config examples. You can also bind a ip to your esp, the. it's kinda static.
• updates can be done via cmd line. see main page of the repo. It can also be done via HA. If you want update via the web, recompile using Arduino lib (I would advise against this)
• HA will auto detect, but you can add it manually (when. you deleted the entity)
• for missing sensors, make a PR or request it. I am a bit busy lately.

[gekkekoe]

So have been giving this some thoughts.
we could probably even detect the running state by determining setpoint < current temp right ? Are there scenario where a zone is not running under those conditions ?

[merlin051]

Just chipping in - I think a buffer tank would be an exception to this rule

[gekkekoe]

Just chipping in - I think a buffer tank would be an exception to this rule

Ah good point, then need to derive it from the multi status then.

[F1p]

So have been giving this some thoughts. we could probably even detect the running state by determining setpoint < current temp right ? Are there scenario where a zone is not running under those conditions ?

And in AA it can be running at +1 over setpoint too

[DamijanD]

So have been giving this some thoughts. we could probably even detect the running state by determining setpoint < current temp right ? Are there scenario where a zone is not running under those conditions ?

And in AA it can be running at +1 over setpoint too

And only one Zone can have AA - so other zone usually uses WC which does not require to have room temperature sensor at all, but if you have it, it is actually almost not used. From my experience it never stops heating if above setpoint. But if it is in idle state (because DWH or something else) then it won't start heating until current temp is lower or equal set point.

[gekkekoe]

@DamijanD and others with multi zone systems, please give https://github.com/gekkekoe/esphome-ecodan-hp/tree/adjust_climates_for_multizones a spin and report back if its working correctly.

Be sure to enable zone2.yaml, that triggers a required substitution

[DamijanD]

After few days I don't see anything different. Today was first day that we had situation when only Z2 was working, but I didn't see any difference with behaviour:

[gekkekoe]

hmm weird, so the multi zone byte would have been 3 (z2 working).
When you include yaml, it should have set the identifier as follows:
zone1: 2
zone2: 3

Zone 1 can only be active only if one of the following conditions apply:

esphome-ecodan-hp/components/ecodan/climate.cpp

Line 53 in 9c57780

if (this->climate_zone_identifier == ClimateZoneIdentifier::SINGLE_ZONE

                        if (this->climate_zone_identifier == ClimateZoneIdentifier::SINGLE_ZONE
                            || static_cast<uint8_t>(ClimateZoneIdentifier::MULTI_ZONE_BOTH) == status.MultiZoneStatus
                            || static_cast<uint8_t>(this->climate_zone_identifier) == status.MultiZoneStatus) {

For zone 1, the zone identifier should have been 2, so first condition is false
It's also not 1 for both.

So I'm having the impression that you are not running the latest code or the subst went wrong.
Can you check in .esphome/build/src/main.cpp and look for heatpump_climate_z1->set_zone_identifier and see what parameter number is supplied there ? It should be 2. If its missing then you are running main branch.

You might need to do a clean before compile. Also it can take up to 2 mins before all status are published, so we could have a small lagging window.

[DamijanD]

code looks ok:


Is it possible that we are missing part where we set it back to idle? If maybe after DHW cycle we get brief "Both" and then we get from "Both" to Z1 or Z2 ? Even though it does not look like it:

[gekkekoe]

hmm weird, but we know that the status was 3. (seen via translation, this value is instant, no delay).
Could be small window where it turns to idle, but idle means off. So that does not compute. The set back to idle is done by the next get multi zone status. But the climates only see the 'current' state, so that's not possible as well.

Only cause I can think of is when you change a climate setting, it has a no-update time before it accepts new states (60s). So if you change (set new target temp) the climate within 60s ago, this might have happen. But this is all guessing.

Do you have logging with time for the multibyte byte and climate for zone 1?

[gekkekoe]

I think I've found it, had the modification on mode instead of action....
Please rebuild and retest (just pushed a fix on the branch)

[gekkekoe]

merged thnx for confirming

[F1p]

Maybe not strictly true because your showing mode heating/cooling, i like to show Idle = Off because visually i know that zone is not working and same with DHW climate

[DamijanD]

IMHO: If you check the main controller on HP
pause symbol should match Idle (and when heating is on but zones don't need actual heating there is pause symbol)
stop symbol should match Off

[gekkekoe]

I prefer idle, because the controls are still available (you still can set a new setpoint).

[F1p]

I prefer idle, because the controls are still available (you still can set a new setpoint).

suggestion Off = Prohibit active?

[F1p]

@DamijanD are you able to check status of message 0x28, byte 11 please?
It is observed on startup that MELCloud writes message 0x34 byte 11 and i think this 0x28 byte turns on because of it

[DamijanD]

Yes I can observe that byte.
Just general value of 0x28[11] or do I need to do something with melcloud as well (some action which should cause 0x34 message)?

[F1p]

Yes I can observe that byte. Just general value of 0x28[11] or do I need to do something with melcloud as well (some action which should cause 0x34 message)?

Observe before, then unplug MELCloud and plug back in, observe after please

[DamijanD]

byte 11 is 0 all the time, but after unplug/plug it was 1 (probably only for one reading as we read every ~21s and the duration of that state was for 23s)
default: RES { .Hdr { FC, 62, 02, 7A, 10 } .Payload { 28, 00, 00, 00, 00, 00, 00, 01, 00, 01, 00, 00, 00, 00, 00, 00 } .Chk { E8 } }
after pl: RES { .Hdr { FC, 62, 02, 7A, 10 } .Payload { 28, 00, 00, 00, 00, 01, 00, 01, 00, 01, 00, 01, 00, 00, 00, 00 } .Chk { E6 } }

Hope it helps...

[F1p]

That is my observed behaviour - it seems the MEL is writing 0x34 byte 11 on connection, which triggers 0x28 byte 11 for one cycle, like you saw
We don't know why/what this is though

[gekkekoe]

so we found another set cmd, now see if we can find what it sets...