Heat / Cool option instead of Auto

[DanielNagy]

So it looks like new HA release has some major updated to the Climate dialogs. https://www.home-assistant.io/blog/2023/09/06/release-20239/

It would be cool if we could switch the Actron Que intergration from using the "Auto" Dialog which has a magic number averaged from the Cool / Heat set points, to the new "Heat Cool" Dialog showing actual set temps, as per the above screenshot, and be actually reflective of what the Actron Que unit's master display shows.

Another example dialog update.

Thanks

[cameronmonks]

I'd love to see this too!

[MikeJMcGuire]

Cool, will have a look.

[DanielNagy]

Mike, I've had a little bit of playing with mqtt to understand how the new dialog/ui's work and interact with mqtt.

Although there is a new "heat_cool" mode option we can add, it doesnt appear that we need to implement it. We are able to just continue using "Auto" to line up with the setting on the Actron Que Controller / App. ie.

To enable the Cool and Heat set temps on the dialogs, it appears we need the following defined in the config for mqtt

  "temperature_high_command_topic": "nagyque123/temperaturecool/set",
  "temperature_low_command_topic": "nagyque123/temperatureheat/set",
  "temperature_high_state_topic": "nagyque123/temperaturecool",
  "temperature_low_state_topic": "nagyque123/temperatureheat",

I've named them cool instead of high, and heat instead of low, just for a little more clarity on my testing.

Also, the original "temperature" command / states need to be removed.

"temperature_command_topic": "nagyque123/temperature/set",
"temperature_state_topic": "nagyque123/settemperature",

It's worth calling out that this WILL break peoples automations that use the Call service: set target temperature. If they are not removed, the "Call Service" climate: set target temperature will still include the "Temperature" item(along with the additional target high/low) , which is redundant and not used from a dialog UI perspective (and will appear in the Call Service/Automations).

I noticed a potential HA bug with call service. Even though the "Target Temperature high" and "Target temperature low" are tickboxes, you HAVE to check and set both values for high and low, or else is complains.

If you set both temperatures in the call service, it works correctly. Not ideal. Maybe confirm you see this action before we raise a bug against HA.

Below is my testing "homeassistant/climate/nagyque" topic used to save you some time to play with.

{
  "name": "Nagy Conditioner",
  "unique_id": "hass-nagy-AC",
  "device": {
    "identifiers": [
      "hass-nagy123"
    ],
    "name": "Nagy Que Air Conditioner ",
    "model": "Add-On",
    "manufacturer": "NagyAir"
  },
  "modes": [
    "off",
    "auto",
    "cool",
    "fan_only",
    "heat"
  ],
  "fan_modes": [
    "high",
    "medium",
    "low",
    "auto"
  ],
  "action_topic": "nagyque123/compressor",
  "mode_command_topic": "nagyque123/mode/set",
  "fan_mode_command_topic": "nagyque123/fan/set",
  "min_temp": "12",
  "max_temp": "30",
  "temp_step": "0.5",
  "fan_mode_state_topic": "nagyque123/fanmode",
  "mode_state_topic": "nagyque123/mode",
  "current_temperature_topic": "nagyque123/temperature",
  "availability_topic": "hass-nagyque123/status",
  "temperature_high_command_topic": "nagyque123/temperaturecool/set",
  "temperature_low_command_topic": "nagyque123/temperatureheat/set",
  "temperature_high_state_topic": "nagyque123/temperaturecool",
  "temperature_low_state_topic": "nagyque123/temperatureheat"
}

[cameronmonks]

Hi Mike, do you have any plans to add this? I'd love to see it if you do, but will look at other ways to achieve it if its not in the pipeline. Thanks!

[MikeJMcGuire]

I'll have a look this weekend. I may add a configuration option that defaults to the current state, so that people can turn this feature on if they want to use it.

[MikeJMcGuire]

Ok, have made the changes. Waiting for a test window (I don't have a Que myself) to test it, and will then release it.

[DanielNagy]

I can test tomorrow.. just let me know how 😂

[MikeJMcGuire]

I can test tomorrow.. just let me know how 😂

I run a dev version of the container locally, but using the credentials of someone else who has a Que. I just need to wait for a good time for me to turn his AC on/off remotely :)

I can point you at the dev container if you can run standalone docker containers on an x64 platform. You'd just need to create an options.json file with all of the HA add-on config.

[MikeJMcGuire]

There's a new configuration option SeparateHeatCool. If you set that to true (not the default), it will change to the individual heating/cooling temperatures. If you leave it blank or false, it will work as it does today. You can change the configuration item as needed and it will just reset the entity config. Just doing some final testing now on other platforms and then will upload it. Let me know how you go.

[MikeJMcGuire]

Ok, v2023.11.1 is up now. Download that, set the SeparateHeatCoolTargets to true, and give it a go.

[cameronmonks]

Thanks Mike, confirming it works perfectly!

[DanielNagy]

Can also confirm it works great.

Looks like Home Assistant still hasnt caught onto the fact the Automation Service - Climate: Set Target Temperature still fails unless you select BOTH targets. Whats the point of the checkbox if both Target temperature's are required, Home Assistant? lol. fyi - HVAC Mode is not optional, and it runs fine with it deselected.

Well - I assume thats a HA bug, not a Mike Bug, given that i noted that in an earlier comment.

One thing I was unable to work out when testing raw mqtt commands, is how to switch from the Low/High Target setpoint graphics, to handle when mode is set back to Heating, or Cooling. (Ie, like the Que Screen does...)

ie

But in saying that - I moved the heat set point to match the cool set point. and after the update from que servers, it separated 2 degrees.. So even though it is operating in "cool" mode, behind the scenes it is still adhering to the 2 degree gap.

Maybe i'm over thinking it, and honestly, will be running this in Auto mode from now on.

Anyways, This has simplified my automations.

Morning - Set to 19/21 Bedtime - Set to 17/21

And a separate automation if HVAC mode = heat, at 2pm set to 21/23 (when we go back to winter, will look at automating this based on the days forcast, or if temp is still at 19., 3pm because power tarff changes to peak at 3pm)

Oh - Silly question as i was never able to work it out. Is it possible to set the "Control all zones" option to true? (There's a option in the mobile app, that locks all zones to the same target setpoints. As soon as you manually change one, that toggles off). I automate against the "main" Air Conditioning object, and when that "Control all zones" option is false, there is bizzare behavour. ie, I am able to lower the low set point, and it reflects in the zones, and raise the high set point, and it is reflected in the zones, however, if i raise the low set point, it only is reflected in the main unit, not the zones, and same if i lower the high set point.

ie, i change the set point to 17 / 27.5, and the zones updated successfully.

i changed the set point to 18/21, and it is reflected on the main hometab of the mobile app (and obviously Home assistant), but not the individual zones (see screenshot above)

To your knowledge, is there a way to re-enable that "Control all zones" interfacing the API? If so - we could possibly fix the above issue. My thought being if the "main" Air conditioner object is updated, then assume we want to control all zone setpoints.

ie, as soon as i toggle Control all zones, it fixes itself up

[MikeJMcGuire]

I'm not surprised about it needing both temperatures still. Even when I use the HA interface to just adjust high or low, it will send both temperatures via MQTT even though only one was adjusted.

[DanielNagy]

Yep. Thought as much.

Any thoughts on the "control all zones"?

[MikeJMcGuire]

The control all zones thing - I found what I thought was a read-only bit of info on the cloud service, turns out its read/write. I've created a new switch to control the Control All Zones setting. Will upload later today.

[DanielNagy]

Great,

Along with the switch, I think it would also be worthwhile to add some logic so if the Main "Air Conditioner" setpoints are changed, to set "Control all zones" to true as well. That should fix the bizaire behavour I am currently seeing where you can set the setpoints further out, but not closer together.

Ie this one top one is the main AC control object.

If individual zones are setpoints changed - the "Control all zones" appears to already be set to False by the cloud service.

[MikeJMcGuire]

Ok, give that a go.

[DanielNagy]

Ok. So the "control all zones" switch worked as described.

But when it is off, it doesn't change to on when changing the master temps.

[MikeJMcGuire]

Interesting, it did during testing. How was the temperature adjusted? The code to turn on control all zones is triggered after receiving an Mqtt message from HA to adjust temperature for the master unit.

[MikeJMcGuire]

Let me know the specifics of the test and I’ll retest tonight.

[MikeJMcGuire]

Just looking at the code again, if the AC is off of in fan mode, it doesn’t adjust the temp and therefore doesn’t enable control all zones.

[DanielNagy]

Mode is auto Fan is auto.

Set one of the zones high to 25

Control all zones turned off automatically.

Adjusted master temp high to 28. All zones moved to 28 (as before even with control all zones turned off.)

Adjust master temp to 21. Only master temp changed. Control all zones doesn't turn on.

[MikeJMcGuire]

Adjusted master temp high to 28. All zones moved to 28 (as before even with control all zones turned off.)

Adjust master temp to 21. Only master temp changed. Control all zones doesn't turn on. What's master temp in this context, when you can set high and low individually? It's either in the high/low mode or the single temp mode (HA).

[DanielNagy]

MQTT Explorer shows this

actronque18xxx/settemperature/high updates when i change the main controller to high setpoint of 21.. but nothing else changed.

[MikeJMcGuire]

Where are you changing the temperature from? HA or the unit itself?

[DanielNagy]

Master controler context being this one underlined in green.

Made the change here.

[MikeJMcGuire]

Yeah, that's the test that I do where it works. If I change either the high or low temp via the HA interface, HA sends an MQTT command to the add-on. The add-on processes it, sends the temperature change to the Que web service, and then sends the Control All Zones on command to the Que web service. Granted it takes sometimes 5-10 seconds to see control all zones turn on (it has to wait for the data to be updated by Que), but that's the testing.

Silly question - this is a Que and not a Neo?

Can you access the add-on logs (from the console, or via portainer)? You should see the add-on receive the MQTT message from HA, change the temp, and then change the control all zones setting.

[MikeJMcGuire]

I'll keep trying various combinations to see if I can get it to not set it.

[MikeJMcGuire]

Ok, give that a go. If i did it repeatedly, it would miss the change sometimes. Looks like it depended on how quickly the queue processing was working for sending queued commands. I've also added some logic so that it doesn't try turn control all zones on if its already on (just unnecessary API calls).

[DanielNagy]

Perfect - that seems to work now!

Yeah - i generally wait 30 seconds post a change due to the 30second polling. or rather, until i see them update.

This is a QUE, not a neo.

[MikeJMcGuire]

Awesome! Thanks for the help!

[DanielNagy]

No thank you.. This is a great addition.

And the control all zones thing has frustrated me so many times when a zone is manually adjusted on a zone controller. this way, my scheduled automations will reset that back to ON :)