Combining LWT heating and cooling entities.

[miguelangel-nubla]

Right now, with the system set to cooling, both thermostats show as "on", heating and cooling.

Could it be possible to mix HC_LWT Abs_Cooling and HC_LWT Abs_Heating into a single entity?
Mode command could link to HC_Mode Heating_Cooling_Auto, and current status (for reporting) can be read from HC_Mode Climate_Cooling and HC_Mode Climate_Heating entities which work as expected for cooling, heating, and auto modes.

[Arnold-n]

This applies to E-systems: I tried hard to make this a single climate entity, but it did not work nicely - for example HA would not select the right color for heating and cooling. Also, the Daikin system really has separate settings and feedback for cooling and for heating. So I decided to only rewrite the climate entities (when heating/cooling mode changes) to add and remove the "on" button but not the "off" button for climate entities in E systems depending on heating/cooling mode, and make the "on" visualization depending on whether the climate entity is really active or not. This gives you the option to also control the cooling setpoint in heating mode . This works only after adding climate entities to your dashboard and then setting switch HA_Setup to off in HC_Setup folllowed by EEPROM_ESP_Save_Changes in HC_Bridge. Could this switch still be on in your system?

[miguelangel-nubla]

Ok that makes sense, different setpoints for heating and cooling is not supported by HA yet.
I don't understand the HA_Setup thing, reading the docs:

Enables proper initial set-up of HA dashboards (or otherwise controls may be incomplete)

What does it do exactly and why it is needed?

[Arnold-n]

This is at the moment needed only for Daikin E series, but may become necessary for Daikin F series later too. It ensures that more functionality is available (all climate entities, including on/off buttons), some of which is later (temporarily) removed depending on system status: in heating mode the "on" button disappears in the cooling climate entity.

And HA_Setup in on state enables a few buttons which are really only needed during setup.

[miguelangel-nubla]

in heating mode the "on" button disappears in the cooling climate entity.

That sounds reasonable.

---

Excuse my insistence but I really don't get the point of HA_Setup, especially the description "proper initial set-up of HA dashboards". I believe I will not be the only one confused about it.

Maybe I'm missing something but turning other entities unavailable does not fit HA architecture IMO.
You can always disable entities you don't want to touch, or simply not add them to a dashboard.

[Arnold-n]

This relates to the three subdevices HC_Room, HC_LWT, and HC_LWT2. If you add for example the HC_LWT (sub)device to one of the dashboards manually, this will add 2 climate entities, one for cooling and one for heating. If you would do this in regular mode, for example in heating mode, the active heating entity will get 2 buttons: heating and off, and the not-active cooling entity will get 1 button, off - which will then not become visible in HA. If the system switches to cooling mode, the cooling entity configuration will be redefined to have cooling and off buttons, but they will not become visible, while the heating entity configuration will be redefined to have only the off button, and the system can no longer be switched on or off. There is no way to make the cooling button inactive in heating mode, which I think would be a better solution.

If you do this in HA_Setup mode as intended, cooling will (temporarily) get 2 buttons, cooling and off, and both entities will get a button bar.

This has the unwanted effect that (for now) cooling seems active too if heating is active:

When HA_Setup is switched off, the intended behaviour occurs that only the active mode gets a button to switch it on, and that only one of these 2 climate entities is active when Altherma_On is switched on (Altherma_On may have to be switched off and one once if both are still active after dashboard configuration):

Overall I would have preferred the old way (<HA2023.02) where the operating mode and the on/off state were separate button bars, and a single climate entity might be used, but this discussion makes clear that separate button bars will not be re-introduced (and hiding things in "more info" would be even worse).

As for making entities unavailable, there are several reasons why I do this:
-Control entities: are not available when the bridge Control_Function is off,
-kWh/start counters are made unavailable when Counter_Request_Function is off as these counters are not updated then,
-HC_Room climate entities and RT_Modulation/RT_Modulation_Max: when in LWT control mode, these cannot be used and are thus made unavailable,
-Cooling related entities are not available for systems without cooling capacity,
-Additional zone related entities are not available if the system operates in single-zone mode,
-several more 'risky' buttons during HA_Setup phase are made unavailable afterwards, and MQTT_Rebuild is not available during MQTT throttling in first 2 minutes after a bridge restart, and
-the Daikin_Restart_Careful button is not available if the Altherma is currently heating or cooling, i.e. if Altherma_On is on (this may not really be needed as the Daikin interface allows a restart during operation).

To me making entities unavailable is the same as disabling them; why do you think it does not fit the HA architecture? Would you know a better way?

[miguelangel-nubla]

Thanks for the detailed explanation.

Bear with me as I hope you understand this conversation is not an attack, but a honest attempt at improving P1P2MQTT and ease its usage and development.

Devices

First off regarding this:

If you add for example the HC_LWT (sub)device to one of the dashboards manually, this will add 2 climate entities.

Why would you add a whole device to a dashboard?
Are you aware you can include the cards you like, referencing the entities you need manually?
The device thing in HA is mainly to hierarchically organize devices, which the current implementation with many HC_* devices does not make much sense in my opinion.

Climate entity

Regarding the climate entity, I understand what you are trying to achieve and the fact that the current HA implementation for climate entities does not cover the use case here.

My issue is that the default lovelace climate card(UI) or current implementation in HA side should not warrant destroying the "Model-View-Controller" separation in home assistant.
That would invalidate the whole point of HA, the expandability and cross-compatibility.

the not-active cooling entity will get 1 button, off - which will then not become visible in HA.

cooling will (temporarily) get 2 buttons, cooling and off, and both entities will get a button bar.

Overall I would have preferred the old way (<HA2023.02) where the operating mode and the on/off state were separate button bars, and a single climate entity might be used, but home-assistant/core#85187 (comment) makes clear that separate button bars will not be re-introduced

Then what about users using other lovelace climate cards (such as mushroom or many others)?
What about when the climate entity is exposed to Google Home or Alexa?
The presentation there will be diferent.
Would issues with the presentation there warrant a climate entity hack to make them behave as we would like to, breaking the specification?
I think not, the specification is what enables the expandability of HA, hence the separation between the climate entity and the desired presentation (lovelace card).
And the issues with the presentation and control are to be expected everywhere, since a climate entity represents the idea of a zone thermostat, which the Altherma is not.

The root of the problem is that climate entities where never intended for this use case, they are supposed to be used as thermostats, which in this case would be used to control/represent individual rooms/zones (and the corresponding valves controlling them).

I don't want to say to not use a climate entity, but strictly speaking it should not be as it will lead to issues with whatever interacts with it (as we have seen with the core Thermostat card).

In same sense, this leads me to the HA_Setup switch, which is the workaround to a workaround:

When HA_Setup is switched off, the intended behaviour occurs that only the active mode gets a button to switch it on, and that only one of these 2 climate entities is active when Altherma_On is switched on

Worst case scenario that should be the only behaviour.

My take

How I would do it:
As stated before the current device thing does not make sense.
Devices:

1. The bridge, with entities:
   • All the entities relevant to the bridge only such as restart, wifi signal, enable control switch, write eeprom etc. All them available all the time unless they actually can't be used or are not available. Read bellow I expand on unavailable vs disabled.
   • All of them organized in diagnostic, config or default categories.
2. The heat pump, with entities:
   • All field settings with entity_category set as diagnostic.
   • Every value that can be modified such as sensor.hc_lwt_abs_heating should be a number instead with entity_category set as config.
   • Every other display only sensor set without entity_category.
   • A climate entity meeting the spec, meaning showing modes from select.hc_mode_heating_cooling_auto, target temp corresponding setpoint (sensor.hc_lwt_abs_cooling or sensor.hc_lwt_abs_heating), etc.

All of these entities should have reliable naming for entity_id and unique_id, simplest that comes to mind: [domain].[configurable-prefix]_[groups]_[name].

• sensor.hc_lwt_abs_cooling as number.myaltherma_climate_lwt_abs_cooling_setpoint for:
  [domain]: number
  [configurable-prefix]: myaltherma
  [group]: climate
  [subgroup]: lwt
  [subgroup]: abs mode
  [name]: cooling_setpoint
• select.hc_mode_heating_cooling_auto as select.myaltherma_climate_mode for:
  [domain]: select
  [configurable-prefix]: myaltherma
  [group]: climate
  [name]: mode

Doing it that way is generally more expandable, and specifically:

• You have control over any setting at any given time, such as cooling and heating setpoints regardless of climate mode.
• You can display specific sensors or controls of interest to you, for example using auto-entities:

type: custom:auto-entities
card:
  type: entities
  title: Altherma
  show_header_toggle: false
filter:
  include:
    - entity_id: sensor.myaltherma_climate_.*
sort:
  method: name

• You can present your entities and configure your cards as you see fit for your model and use case and distribute them across your dashboard as needed.
• You have a climate entity that does match the spec in case you want to interact with it in unexpected ways, such as exposing it to Assist.

When the entities match the spec and the base data is organized, then and only then we should worry about presentation. If the current HA thermostat card is not a good fit I am sure it can be solved with some custom card. Link to example custom climate card.

Unavailable vs disabled

Generally speaking entities are supposed to become unknown when it does not have a valid state (such as not yet read) and unavailable when they don't have a valid value (due to network error, timeout, controller offline, etc).
As such, many users including myself actively monitor and have notifications specifically looking for unavailable or unknown entities.

Disabled on the other hand "forgets" about the entity. It is a clear instruction to not process/record changes which reduces the load and to everything else to ignore it.

A unknown or unavailable entity requires my attention. A disabled one does not, but I have the option to enable it and track/use it anytime when needed.

Therefore these use cases look fine to me:

-Control entities: are not available when the bridge Control_Function is off,
-kWh/start counters are made unavailable when Counter_Request_Function is off as these counters are not updated then,
-HC_Room climate entities and RT_Modulation/RT_Modulation_Max: when in LWT control mode, these cannot be used and are thus made unavailable,
-Cooling related entities are not available for systems without cooling capacity,
-Additional zone related entities are not available if the system operates in single-zone mode,

This should be unavailable only those first two minutes:

-several more 'risky' buttons during HA_Setup phase are made unavailable afterwards, and MQTT_Rebuild is not available during MQTT throttling in first 2 minutes after a bridge restart, and

And in my opinion this should never be unavailable, but disabled manually in any case:

-the Daikin_Restart_Careful button is not available if the Altherma is currently heating or cooling, i.e. if Altherma_On is on (this may not really be needed as the Daikin interface allows a restart during operation).

[Arnold-n]

Many thanks for your detailed feedback and suggestions. I really appreciate it - it's definitely not an attack. I am relatively new to HA, and have tried to make using the bridge with HA as easy as possible, without having to know much on how to configure everything in HA.

Before responding in detail, I'd like to better understand what you are saying, being a relative HA novice:

You have a climate entity that does match the spec in case you want to interact with it in unexpected ways, such as exposing it to Assist.

Which "specification" are you referring to? I am primarily using the documentation at www.home-assistant.io, but it's not really a specification prescribing how things must be done, only how things can be done.

Unavailable vs disabled

Generally speaking entities are supposed to become unknown when it does not have a valid state (such as not yet read) and unavailable when they don't have a valid value [..]
Disabled on the other hand "forgets" about the entity. It is a clear instruction to not process/record changes which reduces the load and to everything else to ignore it.

How do you disable an entity? Via MQTT discovery an entity can only be made unavailable with the availability option or can be deleted by deleting the config message, but I would not know how to disable an entity via MTT.

When HA_Setup is switched off, the intended behaviour occurs that only the active mode gets a button to switch it on, and that only one of these 2 climate entities is active when Altherma_On is switched on

Worst case scenario that should be the only behaviour.

Sorry, I do not grasp what you are saying here, can you please explain?

[miguelangel-nubla]

Which "specification" are you referring to? I am primarily using the documentation at www.home-assistant.io, but it's not really a specification prescribing how things must be done, only how things can be done.

Yes, that is a good point. The most formal specification you are going to find is at https://developers.home-assistant.io/docs/core/entity/climate/, and usage at https://www.home-assistant.io/integrations/climate/ but it is constantly expanded and improved. I can see why it can be confusing to new users. Once you are a regular HA user you get the "idea" behind it and everything makes more sense.

In that particular instance I meant:

• I haven't seen anywhere that changing the modes available is out of the official "spec", but I assure you developers will mostly take for granted that not to be the case.
• The original climate entity you described might only had a HVACMode.OFF mode, which again, as far as I know is technically nowhere forbidden, but informally it is. It does not make sense for such an entity to exist.

As I write this I see the confusion so let me try to change the reasoning route in hope of explaining myself better:

Everything in HA is a entity, a value, a button, a automation... it is the base element on which to expand.
There are very basic entities denoted by its domain, such as sensor, which is a readonly value, number which is like a readwrite integer, switch which represent a relay etc.
All the entities are independent, and HA uses devices to logically group them.
You can represent almost all the data for the Altherma with those. Setpoints as number.setpoint_cooling, number.setpoint_heating, climate enabled as switch.climate_running, current temp as sensor.current_temp etc and that would be perfectly fine.
However some patterns repeat very commonly, such as thermostats having all current temp, target and on/off switch, so the climate domain is created to ease that task. Now instead of 3 entities those can be represented with one. It is a "higher order" entity. Other parts of HA can expect climate entity to have those 3 properties and to develop around that.
In my example I mentioned Assist, so in this case I can ask Assist to tell me current temp. Assist knows what I am asking and knows what to give me.
Now imagine P1P2MQTT comes and creates a climate entity without current temp. Assist dead. It negates the benefit achieved by exposing a climate. I might as well ask assist directly about the simpler entities.
It is obviously exaggerated but you see where I am going with this?

There is no reason to go the hacky climate entity in this case, just using "simpler" entities would enable all functionality, and having those right enables power users to combine them and do their own advanced entities using templates by themselves.

How do you disable an entity?

That is expected of the user. Via the UI, click on an entity, then gear icon->enabled. It is not on MQTT discovery on purpose, only the user should control that. The device/integration/addon must send state to MQTT anyway for if and when HA (the user) wants to know about it again.

When HA_Setup is switched off, the intended behaviour occurs that only the active mode gets a button to switch it on, and that only one of these 2 climate entities is active when Altherma_On is switched on

Worst case scenario that should be the only behaviour.

Sorry, I do not grasp what you are saying here, can you please explain?

I mean that, as described earlier in this same reply, at the very least the available properties/behaviour of the entity should be stable. Only having OFF as a mode is hacky, but additionally being in that state on purpose and only sometimes is way worse from a compatibility perspective.

[miguelangel-nubla]

When HA_Setup is switched off, the intended behaviour occurs that only the active mode gets a button to switch it on, and that only one of these 2 climate entities is active when Altherma_On is switched on

Worst case scenario that should be the only behaviour.

I messed up here I should have written:
Worst case scenario should be that both climates have both ON and OFF, which is confusing but at least gives you total control and "entity stability" at the expense of one of the climates reporting ON incorrectly.