@Wayne-TP 

This is not what I observe, otherwise I would just return or sell all thermostats. The sound of valve closing is exactly when my current system reports "not heating" = off. And the other way around. Also I can accurately hear when the water is flowing and when it's not (or just sipping, which seems to be fine). For example, today the boiler is running for 7 hours and the radiator which should be off is a little cold to the touch (valve in "mode 2” below) exactly like the one next to it which is closed by analog means. Knowing the exact opening percentage would be nice, though.

 

You (TP-Link) need to understand that not everyone has constant supply e.g. from municipal heating plant. We have gas boilers, heat pumps etc. which work only when necessary. To automate our homes we need information from each thermostat if it's currently open (heat demand) or closed (even if not completely).

 

Basically right now there are three modes:

1. OFF in the app, effectively anti-freeze

2. ON in the app, when the measured room temperature is higher than needed and the valve is (mostly) closed. It's on standby, ready to be opened when needed. Valve must not report it's ON and "heating" when in fact it's not!

3. ON in the app and actually heating the room.

 

The only difference between 1 and 2 is the temperature! If you set the same value in 2 as anti-freeze, what's the difference? Only in reporting.

 

Also could you please confirm that my issue has been forwarded to the relevant teams and recorded as a potential bug? Again - it is illogical. Matter is in Beta so it is really important to give them feedback.

Home Assistant entities are exactly the same, just the reported state differs. Via unofficial integration it's "off" now, while via Matter it's "heat". So definitely Matter implementation in Kasa hub is causing this:
hvac_modes: off, heat
min_temp: 5
max_temp: 30
current_temperature: 20.8
temperature: 20
friendly_name: XXXXX
supported_features: 385

 

Similarly via "official" HA integration for TP-Link I just installed, it's "heat". But this time there's also:
hvac_action: idle
... which can be used in my automation instead of off/heat. And further confirms that Matter is broken as of now.

 

  @Wayne-TP Also could you please confirm that my issue has been forwarded to the relevant teams and recorded as a potential bug? Again - it is illogical. Matter is in Beta so it is really important to give them feedback.

 

Schedule is now in Home Assistant. It is only setting the target temperature (just like I'd do manually), while heat/idle is managed by valves themselves. I really need that reading. Could you please confirm that potential bug has been reported to the devs?

  @Wayne-TP 

Could you please confirm that potential bug has been reported to the devs? Or are you going to ignore it altogether on behalf of your employer?

  @Wayne-TP 

 

I found the following on Home Assistant forum:

"The HA Matter integration supports hvac_action if the device provides the “ThermostatRunningState” attribute, so this isn’t a limitation in HA:"

https://community.home-assistant.io/t/nest-thermostat-hvac-action-in-matter-integration/601480/7

 

I briefly searched the ”Matter Application Cluster Specification 1.3” and found this:

"4.3.9.34. ThermostatRunningState Attribute

This attribute SHALL indicate the current relay state of the heat, cool, and fan relays.

Unimplemented outputs SHALL be treated as if they were Off."

 

This is different from ThermostatRunningMode which seems to be on the higher level:

"4.3.9.27. ThermostatRunningMode Attribute

This attribute SHALL indicate the running mode of the thermostat. This attribute uses the same val-

ues as SystemModeEnum but can only be Off, Cool or Heat. This attribute is intended to provide

additional information when the thermostat’s system mode is in auto mode."

 

And, the most important, OFF in RunningMode is defined as "The Thermostat does not generate demand for Cooling or Heating" - DEMAND seems to be the key for the logic and is in line with how I think it should work.

 

By the way, Tapo and Kasa apps interpret it differently: with no heat demand in idle, Tapo shows "heating off" (while main switch is still "on" in blue), but Kasa says "heating to X" even with X lower than measured in the room (main switch "on" in green). I switched to Tapo as its UI is so much better!

 

Could you please consult the devs again?

 

I find lack of this information to be quite annoying. My old system did report percentage of the vale "open state" so if it was 0% it's closed (and not heating the room) and 100% was fully open. It was good as it allowed to monitor what the system is doing and identify issues like air in the heater (if it reports open but it's cold then you know something is wrong.)
Kasa only reports "heating" as a "ready" state ("not off") And only place that shows if the valve was opened is on the historical chart. 
 

in that case heating/off/antifreeze is more like a mode. But there is no information about a state (opened and how much/closed)
 

My request would be to be able to see:

- is that particular valve open (heating) or not - might simply change the icon color on the list

- on the detail page for that valve - how much is it opened? 5% 100%?

- ability to set offset for that valve - not the temperature offset but how much it should be opened (compensated). I use external T315 for most rooms. So if there are some issues in how the valve works, or how the heater is connected, it can be compensated so that they heat uniformly. 

  @Maciej54 

Kasa app does not show heating status (except in history chart), but Tapo does.

And of course Home Assistant, but through TP-Link plugin (unofficial) instead of Matter. There is also unofficial Tapo plugin in HACS but it's broken right now and seems a bit abandoned, only older version still works.

 

There is no option to display valve %, probably because the hub does not share this info with the cloud service or locally. It would be nice to have it, but it's not a deal breaker for me.