search

litinoveweedle / SmartIR

⏻ Control Home Assistant climate, media and fan devices via IR/RF controllers (Broadlink, Xiaomi, MQTT, LOOKin, ESPHome)
MIT License
42 stars 12 forks source link

Preset support #27

Open ehedlund76 opened 3 weeks ago

ehedlund76 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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: https://github.com/smartHomeHub/SmartIR/pull/709 and example of json codes file with eco preset mode: https://github.com/smartHomeHub/SmartIR/blob/39e4bf4b3f6219af9e06837eddeff8f167f81936/codes/climate/1162.json

litinoveweedle commented 3 weeks ago

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.

Is this understanding correct?

ehedlund76 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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:

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

@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 commented 1 week ago

@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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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

ehedlund76 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 3 days ago

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

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 commented 3 days ago

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 commented 1 day ago

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 commented 22 hours ago

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