I saw in the Tasmota logs, that you have provided, that on the first row the “model:” key appears with value of “-1” and in next row you’re passing it with a value of “1”. This can be a reason it doesn’t work … Try fixing it and try again … 
1 Like
Hah, that did it. Sorry, have been busy and hadn’t had time to pull it out and work on it lately. Thanks so much 
2 Likes
Hi, Atanasov. 
I’ve successfuly flashed a BlitzWolf@ BW-RC1 with tasmota-ir and almost everything work. I can control my cooler (Elektrolux, protocol: “ELECTRA_AC”) by hand from the termostat card using the icons. But in the middle of the card I can see a constant temperature (the target temperature, instead of seeing the continuously changing temperature sent by the temperature_sensor. I use the same sensor in an other thermostat (a heater) and in this case the termostate can automatically switch on/off the heater using a relay. And the middle of the card I can see the measured temperature. I dont know what is the reason that this is not working in your case. The program can’t read or convert of the temperature or there is something I don’t know oe understand? In this case thre is no automatic switcing on/off of the cooler … Could you look after the possible reason? The temperature sensor is a xiaomi temperature and humidity sensor whose measured value is read by a ESP32 developing kit, programmed by esphome. I like your solution very much and congratulation for it!!
I correct what I written before. The temperature is OK in the middle of the card. But it has no decimal value only integer compared to the display of my heater, where there is 1 decimal value too. I use the same sensor for both of the climate card so this was misleding me. The only problem of mine remained the fact that if I set the target temperature above and below of the momentary one, there is no automatic switchig on/off of the cooler by hassio compared to my heater. Is it deliberate by design and all the control left for the climate hardwae?
Hi, @Laszlo_Tegzes! I’m glad, that the component works well for You!
Sorry, for the late reply. Some times I don’t have enough time to respond, or I just forget for the community forum. Please, excuse me.
As for Your latest question, initially (when I made this component for my use) it had that functionality (if I got it right). I mean it had the functionality to monitor the temperature and if it goes up, more than the target temperature, it was stooping the AC, and if the temp goes down it was starting the AC. This was “breaking” the main advantage of the ACs - their efficiency. I did a small test, although I already knew what the result will be. I measured the consumption before and after that “functionality”. The result was that regular wall mounted ACs, are better in maintaining consistent temperature and low energy consumption by just reheating/recooling the air, when the AC unit decide, while they maintain their normal cycle of heating/cooling their outside body. Just turning the AC on or off isn’t energy efficient. Even can be very bad thing in the winter, when outside AC body get icy, while heating inside, and you stop the AC, before the outside body get deiced. This might result in very slow heating the room or even not heating the room at all. It is easy to put back this functionality, but it might lead to bigger energy consumption, and might not have the expected result, if the temperature sensor isn’t calibrated well. Also there might be big temperature difference between the place, where the temperature sensor is placed, and the place where a normal people stand. Like if the sensor is too high, the temperature, that the sensor is reporting will be higher, and if the sensor is placed too low the temperature reported will be, respectively, too low. From my observation, best results are achieved, when current temperature exceeds the target temperature and the AC mode is set to FAN and FAN SPEED is set to low, but just leaving the control in AC’s hands is even more economic and good, so … I don’t know … I just removed this functionality … If there is a reason to put it back, I can do it …
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).
Thank you for you answer! 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. .
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!
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 … All variant of automations are achiavable with using automations.yaml like if humididity is bigger than 60% climate.climate_id set_hvac_mode dry … My custom integration just represents regular AC remote control in HA. All automations are left for outside the component (like in automations.yaml). Cleaner and better solution.
Hi,
Thank You again for your fast answer!
I checked what You wrote last time and Yes! everything is working and OK in automatition.
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.
- After jumping here and there the new value is set and remains there.
- 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.
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!
I’ll have to inspect why it is jumping like that. Actually, I haven’t used my component with automations, yet. When I find the reason for this behavior, I’ll fix fix it.
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.
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 …
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 …
I hope this helps!
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. According to Your suggestion I’ll change the automatition. Yes this way everything will be nicer and cleaner!
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
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