Preset support

[ehedlund76]

Hi

Could you please consider adding support for presets to this excellent form of SmartIR?

Look at this fork for inspiration: https://github.com/Zen3515/SmartIR/tree/support-preset-modes

[litinoveweedle]

Hello,

that is interesting idea, I think this could be done. (I am using presets heavily in other climate integrations) Just to fully understand it, could you please write use case? i.e. how it should work for user? Thank you.

[ehedlund76]

Thank you for quick and positive respons. My AC/heatpump have a eco-mode and hi-power-mode. These are custom hvac modes that, according to the ha docs for climate entity, are preset modes. To describe how one of these modes work; when hi-power-mode heating and cooling is faster but also more power demanding. Eco-mode is the opposite. In the cold winter here in Norway I use hi-power-mode a lot, but its not possible from ha, only original remote control. For me as a user it works as dedicated "on/off" buttons on the remote. In ha it probably should be availible as aditional presets/modes I think. I will have to record all the aditional remote ir codes for this to work and update my custom json code file. Maybe take a look at this post: smartHomeHub#709 and example of json codes file with eco preset mode: https://github.com/smartHomeHub/SmartIR/blob/39e4bf4b3f6219af9e06837eddeff8f167f81936/codes/climate/1162.json

[litinoveweedle]

Ok, so your proposal is to overcome HA limit of hardwired (not customizable/extendable list of HVAC modes), by using preset modes. Preset modes are completely customizable, you can define them as you like.

• You would define two new presets: eco and hi-power.

• You would also need to define, which preset is the default one.

• You will need to extend device data json files by one new level/hierarchy:

• hvac_mode

  • (preset_mode)
    • fan_mode
      • (swing_mode)
        • temperature
          -> code to send

• then by selecting preset mode in the HA, the correct code for given hvac_mode->preset_mode->fan_mode(->swing_mode)->temperature will be send.

Is this understanding correct?

[ehedlund76]

Yes, exactly. Default preset would probably be "none". I understand this is how, or at least one way, ha climate entity with presets is supposed to work as described here : https://developers.home-assistant.io/docs/core/entity/climate/.

[litinoveweedle]

There is another way of using preset modes and it is to use them as profiles. In this way by activating given preset you can in one click set combination of the hvac mode, fan mode, swing_mode and temperature. This seems to be also the way, how the presets are used in fan entity.

I would like to provide presets for the both climate and fan entity in coherent way. So any thoughts on how to implement it are welcome. ;-)

[ehedlund76]

Hi, I've studied myAC/heatpump docs and found that eco and hi-power actually is working according to your description of profiles. For instance is hi-power in heat mode incressing the the temperature setting by two degrees and sending the airflow downwards. I think I don't need presets😊 This could be done with an automation, a script or a scene. I suggest to close the issue.

[litinoveweedle]

Hello, thank you for the info. Actually I would probably go to implement presets at some time, as those are really useful to overcome HA limits caused by hardcoded list of hvac_modes. I just need to think about it a bit more. One way how to implement those is as we described - as another layer of the device data codes. The other usage - to used those as profiles - I am not sure if this will works, as HVAC always sent whole setting as a one command. So without possibility to link your script or scene towards one code via SmartIR you want be able to set your HVAC device...

So please let me know and reopen this issue - as I am mentioned I am willing to implement presets anyway, ;-)

[ehedlund76]

Thank you! I think a another layer of device codes is the most intuitive use of presets, and a good approach to overcome the hardcoded list of hvac_codes in HA. I already have the device codes recorder for eco and hi-power, but I'm not able to utilize them. Instead I have an automation to circumvent this. I have a helper for the desired temperature, an IR-controller and indoor and outdoor temperature sensors. The automation is adjusting the HVAC mode and fan speed automaticly based on the season, outside temperature, and indoor temperature. To mimic hi-power:

1. When it's really cold outside and the indoor temperature is dropping the automation is adjusting the temperature 2 degrees above the desired temperature and the fan speed to max.
2. When it's really hot outside and the indoor temperature is rising the automation is adjusting the temperature 1 bellow above the desired temperature and the fan speed to max.
   When indoor temperature is according to the desired temperature hi-power is disabled.

If SmartIR had preset support my automation would have been a lot easier than it is now. I also think that my AC/heatpump maybe working somewhat different when Hi-power is enabled on the remote.

[litinoveweedle]

Thank you for the discussion and information provided. I will think about the best way ho to implement this also for fan modes, but so far I think that implementation described here is the way forward. Please give me some time, as I am now trying to release version with many bugfixes and other wanted feature, so I will postpone my work on this for few days. I will then prepare for you branch with preset modes implemented and ask you for testing, as my AC is don't have any features allowing to test preset.

[ehedlund76]

I think profiles as you describe it is more like rememberred settings, like "my comfort" or "away" with a fixed temperature, fan-speed, swing mode and HVAC mode. My AC/heatpump also has functions for this. I just press a memo button to remember the current settings and a "my comfort" to activate the remembered setting. I've never used scenes, but it sounds to me that I could have used scenes to mimic profiles.

[ehedlund76]

Thank for taking the time to discuss this with me. I will for sure test this as soon as posible when you have prepared it.

[litinoveweedle]

So the intial support for preset modes is now in. Please replace climate.py in your HA instalation by one form here

You will need to provide modified device data json in the format as we discussed:

1. add array listing preset modes (see example bellow:)

....
    "operationModes": [
        "heat",
        "cool",
        "fan_only"
    ],
    "presetModes": [
        "none",
        "eco",
        "hi-power"
    ],
    "fanModes": [
        "low",
        "mid",
        "high",
        "auto"
    ],
...

2. you will need to provide enhanced structure of the commands with one new level in this order:

hvac_mode -> preset_mode -> fan_mode -> swing_mode -> temperature: command

Please put your modified json file into custom_codes/climate folder. Then restart HA a you are free to test. ;-) Report any bugs to this thread, thank you.

[ehedlund76]

Thank you, I will test it the next couple of days. I just have one question. Is "none" also a preset in the structure or does your code handle that preset is not provided for the default one?

[litinoveweedle]

You are welcome, looking forward to the test results.

regarding preset, there is no HA limitation on the integration (to my knoweldge) on hadling presets. Therefore the rule I implemented is:

• if the presets are used (i.e. declared in the device data json file), than one of the presets shall be active.
• the names of presets are completely free, altough translation and icons support for custom names is not there (yet)
• the first preset in the list is the one which will be set as active on the first start. Following starts will restore last selected preset.
• the structure for commands (is preset are enable) has to always have that one additional preset level included.

so there i no special preset 'none' or or no present set, handled differently. I probably caused confusion by naming that first one 'none', feel free to name it 'litinoveweedle' or any name you like. ;-)

[ehedlund76]

Hi, I've altered my device codes file, replaced climate.py, and done some testing. Presets are working and it seems to me that the device codes are sent correctly. Well done! Som adjustments probably needs to be done:

1. It is not possible to change HVAC mode when the chosen HVAC mode does not support the active preset. For instance my HI-POWER preset should only work when heating or cooling, but not in dry or auto. To switch from heating with HI-POWER on I have to choose another preset first, then switch to dry or auto.
2. When HVAC mode is changed I think the preset always should fallback to default (first in list of presentModes). This is actually how my AC/heatpump is working, and probably other models as well. You should always have to activate another preset than default when switching HVAC mode
3. When the device is off and a preset other that default is set it is not possible to turn on the device in a HVAC mode not supporting the preset. Have to switch preset first. I think preset should fallback to default when device is turned off. This is also how my AC/heatpump is working.
4. This is probably an old bug. It's possible to chose a fan mode that is not supported by the chosen HVAC mode. No Ir signal is sent, luckily, but the setting sticks anyways.

I have a suggestion for the structure of the device codes file. To me it would make more sense having presets as the top-level and to make it optional:
(preset_mode) -> hvac_mode-> fan_mode -> swing_mode -> temperature: command

In this way you can preserve all old device code files, and add/append presets if you like.
"presetModes": ["none","hi-power","eco"] -> none means there is no preset-mode to look for in the hierarchy.
Heres an implementation for inspiration: https://github.com/Zen3515/SmartIR/blob/support-preset-modes/custom_components/smartir/climate.py

[litinoveweedle]

Hello, thank you for testing.

1. Shouldn't we then change the order of the commands to:
   preset mode -> hvac mode -> fan mode -> swing mode - temperature
   This would allow for some hvac mode not needing presets. Ha, just finished reading your post and I see, that we come to same conclusion. But I am still not completely decide, this has some drawback as well... I will try to think this though.

2. understand that seems reasonable

3. that makes sense as it is interlinked to the behavior described in 1. Solving 1. we would solve 3.

4. I will have to look at this. whole the _send_code was rewritten for presets, so I am not sure if this is old mode.

The example you linked is not much usable right now, as for many different reasons the way how the climate codes in send_command are handled now is completely different to the original SmartIR. As I mentioned please give me day or two, I will try to think about it. I will come back to you with another preview soon. Thank you so far for help and cooperation.

[Zen3515]

I was considering updating the SmartIR code to meet the latest Home Assistant requirements when I discovered your repository. I'm so glad to see that someone has taken on this task!

I haven't had a chance to read through your code yet, but from what I recall, Home Assistant does require significant changes to accommodate the new climate interaction methods.

In any case, I'm excited about the prospect of using presets with a well-maintained integration, as I've been relying on my own fork for quite some time.

Thank you for your hard work on this!

[litinoveweedle]

@Zen3515

Hey, you are very welcome and thank you for kind words. I use this repo as well for my own AC control, so it is in my own interested to have working integration. The key is to have community around to help. with bug reports, testing and pull request. The problem with the original repository was, that the maintainer stopped accepting PR long time ago. But this is beauty of FOSS, anyone can fork and try to keep wheels spinning (at least for little while) ;-) So give a star and stay connected. ;-)

[litinoveweedle]

@ehedlund76 hello and sorry for slight delay. I was hopefully able to fix most of the reported issues.

I make the whole data file hopefully more versatile. When searching for any given IR command each level (hvac mode, preset mode, fan mode, swing mode, temperature) is searched by same mechanism:

1. for exact key name
2. for the new implemented catch all key - searching for '-' (dash)
3. if nothing found so far, search continue for any mode in the order they are defined (in hvac_mode, preset_modes,...)
4. if nothing is found error is thrown.

If catch all key is used, than given value (mode, temp) attribute is not internally set/changed. So when going back to tree in which original key exists previous value is used.

based on this you can choose how you would like to implement preset mode when it is not supported by given hvac mode:

1. you can defined two preset modes ('eco', 'high_power') and use "-" as preset mode key for fan, dry, etc hvac modes
2. you can defined three preset modes ('none', 'eco', high_power') and use only 'none' as key for example for fan, dry, etc. hvac modes

I tested it rather quick (but without presets) and it seems to be still backwards compatible... I would welcome your feedback.

[ehedlund76]

Hi @litinoveweedle
Thank you for providing a new version. I've tested short and can confirm it's backward compatible. But unfortunately it's not working with presets, at least not with my device codes file. I'm not able to change HVAC mode or preset mode in any way. I've tried to turn it off, but then it's not psobble to turn it back on.
I've attached a couple of variants that I've tried. One (99997.json) without preset in the first section, and one (99996.json) with preset in the first section.
99997.json
99996.json

[litinoveweedle]

Hello I just checked both of your files and there are not in a valid format.

the format is still hvac_mode->preset_mode->fan_mode->swing_mode->temperature.

in case that given hvac_mode doesn't support any preset mode, you can you "-" as preset mode name. Or you can define preset mode "none" and use it as a default preset mode for all hvac modes. (it will be default, when it will be listed as first in the preset_modes list.

[ehedlund76]

Ok, my bad. I thought we concluded on switching the order of presets and hvac modes in the structure😊 I'll get back to testing.

[litinoveweedle]

I explore that possibility as well, but rather decided to keep it the same way so far.

[ehedlund76]

Hi @litinoveweedle

I've adjusted the format of my device codes files in two alternate ways, and done some testing. So far I've focused on the UX behaviour, and haven't checked if the correct IR-signales are sent.

Config. 1: With a defined preset mode "none" as first mode in the preset list, and then used as default mode for all hvac modes
This configuration is working very well. Changing settings is working as expected. The only bad behaviour I've detected is:
a) If a valid preset is chosen and then switched to one that is not supported for the current hvac mode it falls back to none instead of sticking to the previous valid setting
b) It's possible to choose a fan speed that is not supported, and it sticks. This is probably a general bug

Config. 2: Without a defined preset mode "none", and then used "-" as key on hvac modes that doesn't support presets
I'm not sure if this is supposed to be working as configured, but it's how I understood your instruction, so I've tested it.
Since there is no defined default preset, one of the presets in the list is allways selected, even if their not supported for the current hvac mode. I'm able to switch hvac modes and choose presets like in config 1, but since the there is no way to deselect a preset, it probably is allways on if supported. I think the only way to make this config work is to define "-" in the preset list.

[ehedlund76]

Hi @litinoveweedle
I'm away from home till next saturday, but will leave my ac automations running with presets activated. I'll check the logs for any funny business when I get back home, and report it to you.

[litinoveweedle]

Hello @ehedlund76 , thank you for thorough testing. Regarding your findings:

Config1
a) I do not know if I understand your description fully, but to me it seems right - at least what I indented. Simply the rule is - if given preset mode is not supported for the new selected hvac mode, than preset mode is switched to the first one supported (preset modes are tested one by in the order they are listed in the "preset_modes" array).
b) regarding the fan speed/mode, I am really puzzled by this. I do not see anything in the code, how the fan mode, not supported under given hvac and preset mode could be selected. Moreover I know you did reported that earlier as well and from that time whole command selection logic was rewritten, so I am really curious how this bug could survive. Could you please share your latest json files and let me know how to try to reproduce this one?

Config2:
The "-" is the way, how I tried to address situation, when given feature is missing under the upper mode and it doesn't make sense to create default mode (like to 'none' one). When the mode is not available, then even if still reported as selected in HA, it is not commanded on the device. I will maybe change the way how it is indicated in the HA later.

I will be off as well until beginning of the next week, so no worries, take your time and thank you once more for testing.

[ehedlund76]

Hi @litinoveweedle

I don't know how most ac types work when changing hvac mode, but mine is reverting back to no preset, for instance when switching from cooling to heating. That makes sense to me. For instance when its hot in the summer I turn on hi-power cooling, sometimes at night it gets cold and I switch to heating. I'm not expecting hi-power heating to be enabled by default. My ac always default to no preset when switching hvac mode. But then again, I'm not sure if this normal behaviour for an AC. I guess it's a design choice.

I've tested different combinations of fanmodes and hvac modes, and am quit embarrassed to say that I must have reported this error by mistake. I'm not able to reproduce it. I'm sorry to have lead you astray.

[litinoveweedle]

Hello,
sorry for later reply. I understand your reasoning regarding switching back to default preset, but I am trying to keep this 'functionality' generic, having same logic for change in any parameter (preset, fan mode, swing mode, temperature)... So when given mode is possible (exists n the command leaf structure), than keep all modes as they are, except for the changed one. So when you will change hvac mode, swing mode will stays. The same is for preset mode.

There are two possibilities how to fix it

• make simple automation script triggered by hvac mode change. (I would preffer this one, as user can use versatile HA automation logic to make exactly what is wanted).
• create some configuration parameter defining which modes shall be kept and which shall revert to defaults. (I don't like this, as the point is to keep this integration versatile).

Regarding the supposed fan modes and hvac modes issue - no worries and thank you for testing, I am glad that this issue is gone for good. ;-)

[ehedlund76]

Hi
I think you've decided on well thought design choices for preset support. It's been running now in my ac automation for about a week now. The integration has been working very well, as it shoould, and there are no errors in the system log.

I will adapt my automations to handle hvac changes and presets accordingly.

Thank you for providing this functionality!

[litinoveweedle]

Hello, thank you very much for kind words and especially for the detailed testing! If you agree I would merge this branch with master and release it in the next release. I will also need to amend json data files documentation (or better create it, as it is currently non existent). I will keep this topic open, until I will release the version with the preset support. If you find any related issue please let me know.

[ehedlund76]

Sure, I'd really appreciate preset support in the master branch. I've attached my device codes file for my Toshiba AC with all supported HVAC modes and presets. It could be included in the master branch as well if you like.
99997.json

[litinoveweedle]

Hello @ehedlund76

there was recently issue reported with the #47 Fahrenheit support. To fix it I extended considerably our development branch. Would you be please so kind and retest it if it is still working with your setup?

Please note:

• that at minimum you need to replace: init.py, controller.py and climate.py
• strict checks of the data files is now implemented. If any error is reported it shall be fixed first.

I am sorry for this late request, but I would like to release preset support but now I am not fully sure it will be working... Thank you for your help.

Update, I just check your attached data files, and it is passing added syntax check ok, so just functional test is needed. Thank you

[ehedlund76]

Hi

Of course, I'll set it up for testing first thing tomorrow. I'm happy to help!

[ehedlund76]

Hi @litinoveweedle

I'm happy to report that all is working as ut should. In addition to my two "production" devices I've added a dummy devices to test with no presets with this branch.

Well done!

I noticed you have corrected issue #35 I reported earlier. Thank you. Could you review my last comment in #35 about dry mode as well?

[litinoveweedle]

Thank you for spotting this! I added this into preset branch as well. I just merged preset branch into master, including your submitted device file as now 1266.json. Thank you very much for massive preset support will be release in the next release. I still need to create documentation for the climate json format including the preset mode. ;-o

[ehedlund76]

Hi again

Thank you so much for your superb work!

I didn't find 1266.json in the master or preset branch, but was able to locate it in the code_checking branch. Anyways; When you're updating the codes list I've been using a Tuya Zigbee IR blaster (ZS06) for my setup.

[litinoveweedle]

Sorry you are correct, I will merge it as well. Regarding that comment about the Tuya remote, is any change in the file required? I don't fully get it, sorry.

[ehedlund76]

No changes needed. It was just for the name of the controller with the json file in the table of climate codes.

[litinoveweedle]

That table is now generated automatically from the content of the all valid code files. I always wanted to automate this stuff. So the controller is taken directly from the file. So the question is if we need additional field describing exact remote type.

[ehedlund76]

Ah, I understand. I think the supportedController field covers what is needed, for instance ZHA in my case. It probably isn't needed to know the exact remote.

[litinoveweedle]

Yep, I have same understanding, those codes shall be hopefully generic.

[ehedlund76]

I suggest to close this "issue" now. It is running without any errors, and is functioning as expected.

Erik

[litinoveweedle]

Hello @ehedlund76 , I would like to release this in the release, but I think that users deserve some documentation. Would you be please so kind and propose some documentation for the new Climate format? I promise to review it and include in the release. Thank you.

[litinoveweedle]

Ok, I added some initial docs for extended climate format. I am closing this now. Thank you again for the help with all the testing. Feature is now included in the latest beta and will be released soon.