Tasmota MQTT IRHVAC Controller

I’ll share with you my practice, that has nothing to do with automation at all, but will give you some insight how many people (like me) are using their ACs (and I think it is the most economic in my case). In my country we have 4 seasons. I’m turning on my AC in the beginning of October (on heat) and I’m stopping it in the end of April or in the beginning of May. In this period I’m just adjusting the temperature up and down so it feels warm, because outside temperature may vary between 20 and -20 degrees Celsius. Then it stays turned off for month, month and a half and in June I turn it on on cool until the beginning/middle of September. In this period of time I just adjust the temperature (outside temp may vary between 25 and 40 degrees). :slight_smile:

Thank you for you answer! :slightly_smiling_face: OK. I agree with you. If the hvac control the whole process after it has been switched on and set must be the best economical method.

But there is an other issue you should solve and I would be very happy if you could do it. :slightly_smiling_face:.

The original climate object in the HA has some control possibilities I’ like to use in some automatism. They are: climate.set_aux_heat , climate.set_preset_mode , climate.set_temperature , climate.set_humidity , climate.set_fan_mode , climate.set_hvac_mode , climate.set_swing_mode , climate.turn_on , climate.turn_off.

If I wanted to use for instance to switch on/off the hvac automaticali or set its required temperature to a special value I failed. My experiance was that the switching on/off wasn’t possible by climate.turn_on/off at all. When for instance I wanted to set the required temperature by using climate.set_temperature command the required temperate jumped to the value I ask for for a second, than after it was back to the value set on the card. Probably the card graphical settings overrule the command very soon because it is continuously refreshing the graphically set values. Could you solve this problem and let all the above mention commands to be used in some automatism? After that your work would be perfect! :slightly_smiling_face:

Currently almost all of the above is working well … climate.set_aux_heat is this, that I removed and I explained why. It is not related to wall mounted Air Conditioners. climate.set_preset_mode currently supports only away mode, climate.set_temperature is supported, climate.set_humidity is not supported, because it will interrupt the main ‘set_hvac_mode’ it has to change the mode to dry, lets say while it is in heat/cool/vent mode, set_fan_mode is patially supported, because there are too many different fan modes that can be supported (around 10 different modes), set swing modes are supported (both, horisontal, vertical, off), climate.turn_on and climate.turn_off are supported too by setting climate.set_hvac_mode off or heat/cool/auto/dry … :slight_smile: All variant of automations are achiavable with using automations.yaml like if humididity is bigger than 60% climate.climate_id set_hvac_mode dry … :slight_smile: My custom integration just represents regular AC remote control in HA. All automations are left for outside the component (like in automations.yaml). :slight_smile: Cleaner and better solution. :slight_smile:

Hi,

Thank You again for your fast answer! :slightly_smiling_face:

I checked what You wrote last time and Yes! everything is working and OK in automatition. :slightly_smiling_face:

A have only one not too important observation of mine.

In my original climate thermostat panel if I set the temperature by automation using the “climate.set_temperature” then in the panel the required temperature suddenly jumps to the new value and remains there.

In your case after the service command “climate.set_temperature” issued the required temperature value and its graphical representation stars jumping here and there between the old value and the new one. Depending on where you put the “climate.set_temperature service” in the list of services (see below) there are two possibilities.

  1. After jumping here and there the new value is set and remains there.
  2. The last jump ends at the original value meaning it looks you couldn’t set it to the new value.

It looks as two processes were controlling (competing) to set the new value.

The important thing is, that checking the tasmota consol meanwhile it turns out that the correct temperature command was sent to the hvac and it is working according to it. But the hvac panel isn’t showing the real actual value in the second case. If I use the series of services what you can see below after the jumping the panel shows the correct value at the end. I know this is only a cosmetic thing, but I wanted to let You know this phenomena. :slightly_smiling_face:

Other question:
Is it possible to substitute the list of command (services) below to be written in a shorter way?

action:
  - service: climate.set_hvac_mode
    data:
      entity_id: climate.elektrolux_irhvac
      hvac_mode: 'cool'
  - service: climate.set_temperature
    data:
      entity_id: climate.elektrolux_irhvac
      temperature: '26'
  - service: climate.set_swing_mode
    data:
      entity_id: climate.elektrolux_irhvac
      swing_mode: 'vertical'
  - service: climate.set_fan_mode
    data:
      entity_id: climate.elektrolux_irhvac
      fan_mode: 'auto'

Hi! Thank You for the feedback! :slight_smile:
I’ll have to inspect why it is jumping like that. Actually, I haven’t used my component with automations, yet. :slight_smile: When I find the reason for this behavior, I’ll fix fix it. :slight_smile:

As for the question for shortening the services names … I’ve used the original component service names. I’ll test if I can shorten it. :slight_smile:

I can suggest a better solution. You can add the following script (shortened version from above), in your scripts.yaml

ir_hvac2:
  sequence:
  - data_template:
      payload: '{"Vendor":"{{ protocol }}","Model":{{ model }}, "Power":"{{ power }}","Mode":"{{ mode }}","Celsius":"{{ celsius }}","Temp":{{ temp }},"FanSpeed":"{{ fan_speed }}","SwingV":"{{ swing_v }}","SwingH":"{{ swing_h }}"}'
      topic: 'cmnd/{{ room }}Multisensor/IRhvac'
    service: mqtt.publish

Then instead of using the climate.tasmota_irhvac functionality, in automations use script.ir_hvac2 as below:

  action:
  - data:
      celsius: 'on'
      fan_speed: max
      mode: heat
      model: -1
      power: 'on'
      protocol: ELECTRA_AC
      room: kitchen
      swing_h: 'off'
      swing_v: 'off'
      temp: 23
    service: script.ir_hvac2

IMPORTANT:
fan_speed, mode, model, protocol, swing_h and swing_v should be set according to your AC remote values.
swing_h and swing_v can be ‘auto’ or ‘off’ in most cases.
mode can be ‘heat’, cool, ‘dry’, ‘auto’ and other according to your AC remote values.
room is included in the topic of the script, if you’re using the naming convention like “room” + “Multisensor”. If you don’t then change according your Tasmota device topic … :slight_smile:

Using this method it is way shorter than calling multiple separate services on same AC, and is done all with one command send. Will update the thermostat card too. And if your AC beeps on command receive, it will beep just once … :slight_smile:
I hope this helps! :slight_smile:

You can also pre-populate some values in your script, or if you have more than one AC models, you can create separate scripts for each model, with pre-populated model, protocol and celsius. This will shorten service data too. Following one of my AC models, this would look like:

kitchen_ac:
  sequence:
  - data_template:
      payload: '{"Vendor":"ELECTRA_AC","Model":-1, "Power":"{{ power }}","Mode":"{{ mode }}","Celsius":"On","Temp":{{ temp }},"FanSpeed":"{{ fan_speed }}","SwingV":"{{ swing_v }}"}'
      topic: 'cmnd/kitchenMultisensor/IRhvac'
    service: mqtt.publish

And now the sctipt data is way more short:

  action:
  - data:
      fan_speed: max
      mode: heat
      power: 'on'
      swing_v: 'off'
      temp: 23
    service: script.kitchen_ac

Thank You. :slightly_smiling_face: According to Your suggestion I’ll change the automatition. Yes this way everything will be nicer and cleaner! :slightly_smiling_face:

1 Like

Hey @gh0s7, is possible to use this code with the tasmotized YTF IR bridge from Tuya?
I’m trying to use it with your code but it doesn’t receive the signal.
How can i address it to the device?

EDIT!!

I’ve found it.
It was only the order of the “command_topic” and “the state_topic”:
He send it perfectly well.

If you follow the instructions of tasmota website and the youtube chanels, they will say to leave the %topic%/%prefix%/ as they were.
But as per the code, they are inverted.

It should be like this:

  • tasmota_IR/cmnd/irhvac
    (tasmota_IR is my unique mqtt name for the device).

I can’t get what you are talking about … These are the real topics of my kitchen multisensor that I’m using to send and receive IR codes:
command_topic: “cmnd/kitchenMultisensor/irsend”
state_topic: “tele/kitchenMultisensor/RESULT”

Hey @gh0s7

You mentioned in your january posts that you fixed the issue with hassio not displaying modes. I’m currently having that exact issue. Despite my attempts to troubleshoot my possible mistake while editing the code to my make AC, i wasn’t able to to find where i did wrong. So i copy pasted your code to my configuration.yaml to see wether the mode options will show up or not. And they didn’t. I’m using latest hassio on a rpi 3. What am i doing wrong?

Can you tell me your HA version and show me you AC config in configuration.yaml :slight_smile:

Between downgrading and upgrading to 0.103 to 0.104 to latest i couldn’t get it to work. Then i thought it may have to do with folder permissions. Since i created the tasmota_irhvac folder using the file editor(configurator) and uploaded files individually using the browser upload feature. So installed the samba plugin and removed all files and cleaned my configuration.yaml and after that i uploaded the unpacked folder using the samba share protocol. After restarting the server and putting in the code into configuration.yaml suddenly it started to work. Just so everyone knows i’m on 0.107.5 and everything is working fine.

Thanks @gh0s7 for this wonderful custom component

1 Like

I’m glad it is working now! I’m not sure what might be the cause for not working on v0.103 and 0.104. It was working on these versions before some time, when I tested it. I also like your feedback, that it is working fine on v0.107.5, because I was thinking to update my test machine to this version and test it.

Many thanks for this. so perfect and easy to setup.
I have been using SmartIR with Tasmota IR but this is something else… super.
I have few questions

  • is it supposed to update the entity when using the original remote if you use the IRrecv?
  • can it show the swing and fan speed in homeKit component?

here is also the contraption I made to control my A/C units and it works perfectly
I’m using TasmotaIR.bin v8.1

I used

  • ESP8266-01 4$
  • Hi-Link 3.3v. 6$
  • DHT11 6$
  • IR Diode Emitter 1$ x5 diodes
  • IR Ricever 1$
  • 2N2222 Transistor. 1$. x10 Transistors

I designed and 3d printed the cases.

Thanks.

2 Likes

Hello everybody.

I am trying to use tasmota_irhvac for a long time, but had no success.
My hardware is a Raspberry Pi 4 4Gb with Ubuntu 19.10 x64 (Official) and Hassio on Docker.
Everything works like a charm, except the tasmota_irhvac.

I downloaded the [Tasmota IRHVAC for HA v0.103+] from Github, put it inside folder “\config\custom_components\tasmota_irhvac” using Samba Share and gave all permitions with “chmod 777”.

My configuration.yaml:

climate:
  - platform: tasmota_irhvac
    name: ClimateBedroom
    availability_topic: "homeassistant/climate/bedroom/LWT"
    command_topic: "homeassistant/climate/bedroom/cmnd/irhvac"
    state_topic: "homeassistant/climate/bedroom/RESULT"
    protocol: "LG"
    min_temp: 18
    max_temp: 30
    target_temp: 23
    initial_operation_mode: "off"
    away_temp: 25 
    precision: 1.0 
    supported_modes:
      - "cool"
      - "dry"
      - "fan_only"
      - "auto"
      - "off" 
    supported_fan_speeds:
      - "medium"
      - "high"
      - "min"
      - "max"
    supported_swing_list:
      - "off"
      - vertical #up to down
    default_quiet_mode: "Off" #optional - default "Off" string value
    default_turbo_mode: "Off" #optional - default "Off" string value
    default_econo_mode: "Off" #optional - default "Off" string value
    hvac_model: "-1" #optional - default "1" string value
    celsius_mode: "On" #optional - default "On" string value
    default_light_mode: "Off" #optional - default "Off" string value
    default_filter_mode: "Off" #optional - default "Off" string value
    default_clean_mode: "Off" #optional - default "Off" string value
    default_beep_mode: "Off" #optional - default "Off" string value
    default_sleep_mode: "-1" #optional - default "-1" string value

But when I restarted, had the notification:

The following integrations and platforms could not be set up:

  • climate.tasmota_irhvac

Please check your config.

Was tested on HA 0.106 and now on 0.107.7.

Am I missing something ?

Thanks for the help.

  • is it supposed to update the entity when using the original remote if you use the IRrecv?
  • can it show the swing and fan speed in homeKit component?

For the first question tasmota_irhvac already support this feature. :slight_smile:
For your second question - I don’t know. You’re able to access this info trough home assistant, but I don’t know how this homeKit works and if it is possible to tell this component to get this info.

Hi! tasmota_irhvac does not support such config key like availability_topic . Probably this is the reason. Maybe if you check the logs, you will see what exactly is going on, but be sure that including the availability_topic will 100% prevent the component from being setup. :slight_smile:

Hi, I made this beautiful project, but I have a problem, because I discovered that my AC HISENSE when it changes temperature transmits the “power” and “mode” function to OFF. Instead, to turn the AC in mode on / off, the “power” function transmit ON.You can help me?Thanks

@gh0s7Thanks for that wonderful project! Just built it with a Wemos D1 mini, an IR receiver and transmitter powered via BC337.
Flashed with Tasmota, and all seems to work great.
When pressing remote button I receive them:

But the card looks like this:

image

And when I change something, I only received

12:53:41 MQT: stat/tasmota_23115D/RESULT = {"Command":"Unknown"}

This is the part of the config:

climate:
  - platform: tasmota_irhvac
    name: DaikinEG
    command_topic: "cmnd/tasmota_23115D/"
    state_topic: "tele/tasmota_23115D/RESULT"
    protocol: "DAIKIN"

This is a complete received line:

{"IrReceived":{"Protocol":"DAIKIN","Bits":280,"Data":"0x0x11DA2700C50000D711DA2700425C03B311DA27000029C000A0000006602000C00200E3","Repeat":0,"IRHVAC":{"Vendor":"DAIKIN","Model":-1,"Power":"On","Mode":"Dry","Celsius":"On","Temp":96,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"On","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}

Any idea what’s wrong?

2 Likes