Clearer hvac_action about hawundasmart HOT 11 CLOSED

Yes I think using the idle state is probably the right thing to do :) preheating is already used for the adaptive start feature, but using idle to mean 'not off but not currently heating' seems good to me. I'll go ahead and make that change 👍

from hawundasmart.

Ok thanks, when I get time I'll fiddle around and see what other values heat can be set to, but seems like that might be a better field to use for the hvac action 👍

from hawundasmart.

Nice one - seems to do as expected. Will keep an eye on it over the week and report back if I spot any quirks

from hawundasmart.

Do you have pump delay enabled? I think the default is 2 minutes. What I'm wondering is if the flag that I assumed meant heat demand actually means 'pump on', which would explain why you're seeing the two go out of sync for a couple of minutes.

from hawundasmart.

Yep I have a 3 min pump delay on my connection box.

from hawundasmart.

Ok that makes sense then :) I kinda like this behavior more than the wundasmart app as it's giving you a bit more information about what's actually going on. The heating isn't really heating until the pump comes on, so having the hvac_action lag until the pump comes on makes sense to me.

I'm not sure what the wundasmart app is doing, but I suspect it's something simple like saying it's on if the temp is below the set temp - I seem to remember reading that what's displayed in the app doesn't take the switching differential into account either, whereas this should.

What do you think? Maybe you could just change your card to display exactly what you want using a combination of both the mode and the action? FWIW I'm using the mini-climate-card (https://github.com/artem-sedykh/mini-climate-card) which lets you do all sorts of custom logic to show different icons etc based on different states.

from hawundasmart.

My findings above were for TRV controlled rooms rather than UFH ones (didn't test on UFH). I assumed that TRV controlled rooms would have no delay, hence my assumption that the library wasn't checking the heat status at the right time - my bad. But it makes sense for there to be a delay to allow for the valve to open etc.

I understood the pump delay to be set per smart connection box to control the pump relay at that manifold. I wonder if the TRV delay is hardcoded in... but either way doesn't matter for the scope of this issue.

I agree that accurate representation of whether heat is being outputted is best. Would be great to know if heat is being requested but not yet delivered (e.g. pump delay). It looks like there are 'preheating' & 'idle' states available for hvac_action in HASS - do you think one of these are appropriate?

(Edit) I’ve been thinking ‘idle’, whilst not perfect, would be best match to cover off switching differential and pump delays. Thoughts?

from hawundasmart.

Just tested this & it works as per the commit description.

I was actually envisaging different behaviour - let me know what you think..

HVAC action to give as much context to whether heat is being demanded or not. So:

heat: 4 = hvac action - off
heat: 7 = hvac action - on
heat: 6 = hvac action - idle

My thinking is - whether the heating is off via auto/schedule or off via manual it's then the same hvac action state, as the outcome for the user is the same (same behaviour before the commit).

However - idle is then used to give immediate feedback that the system is in-between off & heating states (e.g. for switching differential & pump/TRV delay). This addresses the lack of feedback observed in the initial issue and gives clearer context that something is in fact happening. The Hass iconography for idle state seems to work well for this use case - i.e. idle waiting for next state:

from hawundasmart.

What do states 7 and 6 mean? I've not seen those before.

7 = 00000111
6 = 00000110

# tp appears to be the following flags:
# - 00000001 (0x01) indicates a manual override is set until the next manual override
# - 00000100 (0x04) indicates the set point temperature has been set to 'off'
# - 00010000 (0x10) indicates a manual override has been set
# - 00100000 (0x20) indicates heating demand
# - 10000000 (0x80) indicates the adaptive start mode is active

So 7 is 0x1 | 0x2 | 0x4, set point = 0, ???, manual override until next manual override
and 6 is 0x2 | 0x4, set point = 0, ???

Looks like the only difference between 6 and 7 is whether you've set the manual override to be until the next manual override or until the next scheduled change, so I don't think that should result in a different hvac action (and according to my current understanding of the flags, both should show as off)

from hawundasmart.

Prior to your library I used to poll for the 'heat' value of a room:

syncvalues.cgi:
121;1699974009;t_lo:16.00;t_norm:18.00;t_hi:19.00;heat:4;temp_pre:0;prg:2;lock:0;temp:18.00;ntemp:19.00;ntime:1699997400;es_avgtime:0;zone:2;relays:0;hb0:0;hb1:0;enable:121;tmax:27;tmaxh:5;settime:7200;pic:1;loc_in:1;loc_out:3;alarm:0;name:Bedroom;tbl:ffffffffafaaaaaaaaaaeaffffffffffafaaaaaaaaaaeaffffffffffafaaaaaaaaaaeaffffffffffafaaaaaaaaaaeaffffffffffafaaaaaaaaaaeaffffffffffafaaaaaaaaaaeaffffffffffafaaaaaaaaaaeaff;

or via

/getregister.cgi?121@heat

<cmd status="ok"> <device id="0"> <reg vid="121" tid="heat" v="4" min="0" max="65535"/> </device> </cmd>

My observations from deduction were as follows:

4 corresponds to off
7 corresponds to heat is being delivered
6 corresponds to heat not yet delivered (pump delay & I believe switching dif)

from hawundasmart.

@mutasim seems to work ok, let me know how you get on

from hawundasmart.