RaymondMouthaan commented 4 years ago

Hello @crankyoldgit,

Thank you for this great piece of work!!!

Recently I bought a mobile air conditioner which I like to control from Tasmota on a Wemos D1 mini. After a few hours of trail and error, I managed to find a vendor which works with the hvac. By means it responses to most common commands from vendor TROTEC, but my guess is that the actual IR codes of TROTEC are slightly different from the original remote control, since the IOS app that comes with the hvac doesn't respond on any command from TROTEC, while with the original remote control does.

So this gave me the idea to add the support for my hvac, based on vendor `TROTEC. However after reading the documentation how to add support for a new device, I am stuck on how to proceed and hope you are willing to help me pointing in the right direction.

Below you find the specification of the hvac and the different IRSend, IRRecvDump and IRhvac (TROTEC based) commands per remote control button. I was thinking to duplicate the TROTEC module and modify the IR codes with codes of the Duux Blizzard, but I just can't find and figure out which values need to be changed.

Your help is very much appreciated.

Regards, Ray

Duux Blizzard - HVAC

Specifications

Model: DXMA04
Rate Voltage: 220-240V
Rated frequency: 50Hz
Rating power input: 1150W/5.1A
Refrigerant: R290 (14g)
Suction/Discharge: 0.85/2.2Mpa
Max. Pressure of coil: 9.6MPa
Manufacturer: Duux BV - P.O. Box 145, 5400 AC, Uden, The Netherlands
Website: https://duux.com/en/
Product page: https://duux.com/en/product/blizzard-smart-10k-btu/
IR Remote control: https://duux.com/en/product/blizzard-afstandsbediening/

Power

Power Toggle

IRsend

IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F20DF","DataLSB":"0x00FE04FB","Repeat":0}

IRRecvDump

Timestamp : 000676.773
Library   : v2.7.7

Protocol  : NEC
Code      : 0x7F20DF (32 Bits)
uint16_t rawData[71] = {8964, 4508,  514, 590,  542, 590,  592, 536,  516, 562,  570, 588,  592, 536,  492, 612,  542, 586,  594, 536,  518, 1716,  594, 1642,  570, 1692,  490, 1744,  540, 1672,  594, 1692,  516, 1718,  514, 590,  570, 534,  624, 1666,  546, 534,  596, 558,  516, 614,  570, 534,  598, 532,  516, 1720,  598, 1664,  570, 508,  624, 1664,  570, 1664,  568, 1664,  600, 1664,  570, 1664,  594, 40946,  8992, 2216,  596};  // NEC 7F20DF
uint32_t address = 0xFE00;
uint32_t command = 0x4;
uint64_t data = 0x7F20DF;

IRhvac

Power on

IRhvac {"Vendor": "TROTEC", "Power": 1}

Power off

IRhvac {"Vendor": "TROTEC", "Power": 0}

Operation Mode

Modes: automatic, cooling, fan, dehumidify

Change Operation Mode

IRsend

IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F00FF","DataLSB":"0x00FE00FF","Repeat":0}

IRRecvDump

Timestamp : 001401.508
Library   : v2.7.7

Protocol  : NEC
Code      : 0x7F00FF (32 Bits)
uint16_t rawData[71] = {9044, 4450,  622, 508,  542, 562,  622, 484,  648, 508,  542, 590,  594, 508,  622, 508,  568, 562,  570, 534,  622, 1640,  594, 1640,  594, 1640,  596, 1666,  594, 1642,  594, 1640,  596, 1666,  542, 562,  594, 536,  594, 536,  542, 538,  566, 588,  618, 512,  542, 562,  568, 564,  618, 1618,  540, 1720,  542, 1694,  594, 1644,  538, 1720,  490, 1744,  594, 1642,  518, 1744,  492, 41022,  8992, 2242,  516};  // NEC 7F00FF
uint32_t address = 0xFE00;
uint32_t command = 0x0;
uint64_t data = 0x7F00FF;

IRhvac

Auto

IRhvac {"Vendor":"TROTEC","Power": 1,"Mode":"Auto"}

Cooling

IRhvac {"Vendor":"TROTEC","Power": 1,"Mode":"Cool"}

Dehumidification

IRhvac {"Vendor":"TROTEC","Power": 1,"Mode":"Dry"}

Ventilation

IRhvac {"Vendor":"TROTEC","Power": 1,"Mode":"Fan"}

Fanspeed

Modes: low, medium, high

IRsend

IRSend {"Protocol":"NEC","Bits":32,"Data":"0x007FA05F","DataLSB":"0x00FE05FA","Repeat":0}

IRRecvDump

Protocol  : NEC
Code      : 0x7FE01F (32 Bits)
uint16_t rawData[67] = {8936, 4534,  516, 616,  568, 538,  594, 534,  516, 616,  570, 534,  596, 534,  514, 618,  566, 536,  596, 534,  514, 1722,  594, 1668,  568, 1666,  514, 1722,  594, 1668,  568, 1666,  516, 1722,  592, 1666,  570, 1642,  540, 1722,  592, 536,  516, 616,  566, 540,  592, 536,  516, 616,  566, 538,  592, 562,  490, 616,  568, 1668,  516, 1722,  568, 1692,  568, 1668,  514, 1722,  566};  // NEC 7FE01F
uint32_t address = 0xFE00;
uint32_t command = 0x7;
uint64_t data = 0x7FE01F;

IRhvac

Fanspeed Low

IRhvac {"Vendor":"TROTEC","Power": 1,"FanSpeed":"Low"}

Fanspeed Medium

IRhvac {"Vendor":"TROTEC","Power": 1,"FanSpeed":"Medium"}

Fanspeed High

IRhvac {"Vendor":"TROTEC","Power": 1,"FanSpeed":"High"}

Temperature

IRsend

Temerature Up

IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007FA05F","DataLSB":"0x00FE05FA","Repeat":0}

IRRecvDump

Timestamp : 001175.682
Library   : v2.7.7

Protocol  : NEC
Code      : 0x7FA05F (32 Bits)
uint16_t rawData[71] = {8994, 4454,  592, 534,  572, 536,  594, 536,  568, 588,  544, 534,  598, 532,  518, 614,  568, 536,  570, 560,  516, 1720,  570, 1692,  544, 1690,  516, 1720,  570, 1690,  546, 1690,  514, 1720,  572, 1690,  570, 534,  598, 1662,  546, 532,  626, 532,  516, 614,  572, 508,  624, 532,  542, 588,  572, 1662,  570, 560,  572, 1664,  594, 1640,  598, 1664,  568, 1666,  594, 1640,  596, 40968,  8966, 2244,  514};  // NEC 7FA05F
uint32_t address = 0xFE00;
uint32_t command = 0x5;
uint64_t data = 0x7FA05F;

Temperature Down

IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F609F","DataLSB":"0x00FE06F9","Repeat":0}

IRRecvDump

Timestamp : 001208.983
Library   : v2.7.7

Protocol  : NEC
Code      : 0x7F609F (32 Bits)
uint16_t rawData[71] = {8914, 4532,  596, 560,  544, 562,  570, 534,  596, 560,  516, 586,  572, 508,  622, 534,  568, 562,  570, 534,  596, 1690,  544, 1692,  568, 1666,  570, 1690,  546, 1690,  568, 1642,  594, 1666,  568, 536,  596, 1666,  568, 1668,  592, 536,  570, 534,  596, 534,  596, 534,  570, 536,  622, 1662,  518, 562,  594, 536,  594, 1640,  570, 1718,  516, 1692,  592, 1644,  568, 1668,  568, 40972,  9018, 2216,  592};  // NEC 7F609F
uint32_t address = 0xFE00;
uint32_t command = 0x6;
uint64_t data = 0x7F609F;

IRhvac

IRhvac {"Vendor":"TROTEC","Power": 1,"Temp": 19}

Timer

IRsend

IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F807F","DataLSB":"0x00FE01FE","Repeat":0}

IRRecvDump

Timestamp : 001261.802
Library   : v2.7.7

Protocol  : NEC
Code      : 0x7F807F (32 Bits)
uint16_t rawData[71] = {9016, 4480,  570, 560,  592, 538,  544, 536,  594, 562,  592, 510,  544, 562,  570, 586,  620, 512,  518, 586,  544, 1718,  542, 1692,  568, 1666,  546, 1716,  518, 1690,  594, 1594,  620, 1688,  572, 1692,  514, 614,  570, 534,  598, 506,  570, 586,  598, 506,  624, 506,  596, 536,  596, 482,  648, 1640,  596, 1638,  596, 1616,  622, 1664,  544, 1690,  568, 1644,  568, 1718,  492, 41018,  9044, 2192,  568};  // NEC 7F807F
uint32_t address = 0xFE00;
uint32_t command = 0x1;
uint64_t data = 0x7F807F;

IRhvac

unknown

Night Mode

IRsend

IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007FC03F","DataLSB":"0x00FE03FC","Repeat":0}

IRRecvDump

Protocol  : NEC
Code      : 0x7FC03F (32 Bits)
uint16_t rawData[71] = {9020, 4450,  598, 510,  566, 588,  596, 508,  622, 484,  568, 614,  568, 508,  624, 506,  544, 588,  596, 510,  622, 1640,  568, 1666,  594, 1640,  596, 1668,  540, 1694,  618, 1642,  542, 1696,  540, 1720,  592, 1644,  516, 588,  620, 512,  566, 538,  542, 590,  590, 540,  514, 588,  542, 588,  592, 538,  492, 1746,  566, 1668,  544, 1744,  516, 1720,  488, 1746,  518, 1718,  518, 40994,  9020, 2216,  568};  // NEC 7FC03F
uint32_t address = 0xFE00;
uint32_t command = 0x3;
uint64_t data = 0x7FC03F;

IRhvac

unknown

NiKiZe commented 4 years ago

Are the IRRecvDump parts here from IRRecvDumpV2 when using the original remote for the Hvac?

Do you have any model number for the remote? And does the remote have any kind of display?

RaymondMouthaan commented 4 years ago

@NiKiZe,

Thanks for your response!

Indeed the dumps are made using IRRecvDumpV2 using the original remote (see image below). I couldn't find any model number on the remote, on the pcb the YJ-A081TR is printed, but Google didn't give anything useful on that. 08_DXMA0203-Blizzard-remote_1920x1920

NiKiZe commented 4 years ago

Many AC remotes has "internal state" which keeps temperature, fan speed, mode etc. And on each button press this full state is sent to the AC.

In your case it seems that the 7 buttons are only sent as "key press" and there is no state at all. And it seems to be standard NEC protocol. Getting "full AC support" with this seems hard.

Does the app send IR codes as well, and if so, what do you get if you try to capture those?

RaymondMouthaan commented 4 years ago

Yes, I guess the remote doesn't keep states. The hvac keeps its states, for instance when the fan speed is set to high, turning it off and back on the fan speed remains high.

Further more the hvac has WiFi and an app which can control the hvac and get its state, but is goes via WiFi.

The goal eventually is to control the hvac via Homebridge -> Node-RED -> Wemos (Tasmota). On the Wemos a temp/hum sensor to measure ambient temp/hum and based on these controlling the hvac. The idea is based on https://www.tado.com/gb-en/smart-ac-control-overview.

RaymondMouthaan commented 4 years ago

The pcb of the remote looks like this and the chip used is SC6121-001

NiKiZe commented 4 years ago

So emulating the original remote is probably of limited use? But you can do that by using sendNEC. Don't know how to use that in tasmota tho. Maybe it is better to try and breakdown the WiFi protocol? But that is out of scope for this lib.

NiKiZe commented 4 years ago

In regards to Trotec, could it be that it is similar in timings to NEC and the AC is just confused? Or does it switch to specific/same settings each time you send the same message?

crankyoldgit commented 4 years ago

A quick way to confirm if the A/C unit holds the state vs. the remote (also) holds the state is to use IRrecvDumpV2 to record two sequential "+" button/temps presses. If they are the same, then it's a dumb remote, and you will need just send the codes as-is. If they are different codes, then there is a hope of adding it to the library similar to most other A/C units. i.e. Able to construct arbitrary states for the A/C unit.

crankyoldgit commented 4 years ago

Fanspeed

Modes: low, medium, high

IRsend

IRSend {"Protocol":"NEC","Bits":32,"Data":"0x007FA05F","DataLSB":"0x00FE05FA","Repeat":0}

IRRecvDump

Protocol  : NEC
Code      : 0x7FE01F (32 Bits)
uint16_t rawData[67] = {8936, 4534,  516, 616,  568, 538,  594, 534,  516, 616,  570, 534,  596, 534,  514, 618,  566, 536,  596, 534,  514, 1722,  594, 1668,  568, 1666,  514, 1722,  594, 1668,  568, 1666,  516, 1722,  592, 1666,  570, 1642,  540, 1722,  592, 536,  516, 616,  566, 540,  592, 536,  516, 616,  566, 538,  592, 562,  490, 616,  568, 1668,  516, 1722,  568, 1692,  568, 1668,  514, 1722,  566};  // NEC 7FE01F
uint32_t address = 0xFE00;
uint32_t command = 0x7;
uint64_t data = 0x7FE01F;

Let's take the above for example. You're getting a single NEC code (0x7FE01F) here. Yet you seem to indicate that the A/C unit supports high, medium, & low for speeds. If it's the same code (0x7FE01F) for each button press, then the remote doesn't store the state of the A/C. It's a dumb/simple remote, like a typical/old TV remote etc. If that code changes, then yes, we can do something about it. Otherwise, you're going to probably be stuck blinding sending that code to toggle/change fan speeds when want to, and have to rely on proximity to the A/C device to tell what mode it's in.

As for how to send NEC codes via Tasmota, please check here: https://tasmota.github.io/docs/Tasmota-IR/

They use our library, but we don't explicitly know the ins & outs of their interface the provide to users, you really need to talk to them if you have usage problems (with Tasmota). We can help, but I'll be googling just as much as you would be. ;-)

RaymondMouthaan commented 4 years ago

All IRSend commands in my first post are commands send through Tasmota web command:

Same goes for all IRhvac TROTEC commands. Using these commands in more details this means:

For example consider the following scenario: 1) Initial state: hvac is turned off

2) IRhvac {"Vendor":"TROTEC","Power": 1,"FanSpeed":"Low"}

Turns 'on' the hvac and sets the fan speed to 'Low'

3) IRhvac {"Vendor":"TROTEC","Power": 1,"FanSpeed":"Medium"}

sets the fan speed to 'Medium'

4) IRhvac {"Vendor":"TROTEC","Power": 1,"FanSpeed":"High"}

sets the fan speed to 'High'

5) IRhvac {"Vendor":"TROTEC","Power": 1,"FanSpeed":"Low"}

sets the fan speed to 'Low'

6) IRhvac {"Vendor":"TROTEC","Power": 1,"FanSpeed":"High"}

sets the fan speed to 'High'

When all commands starts with an initial state turn off, the expected behaviour happens as well.

So somehow the TROTEC code "knows" the state of the hvac somehow so basically the TROTEC works, but sending these commands do not make the IOS app respond. The app "thinks" the hvac is still off.

So I think the IR codes defined in the TROTEC code are slightly different from the original codes. Modifying them in such way that it sends the Duux codes might work perfectly?

RaymondMouthaan commented 4 years ago

@crankyoldgit, thanks for your reply!

I'll try as you suggested, but please have a look at my previous post, especially from step 5 to 6.

crankyoldgit commented 4 years ago

So somehow the TROTEC code "knows" the state of the hvac somehow so basically the TROTEC works, but sending these commands do not make the IOS app respond. The app "thinks" the hvac is still off.

I know nothing of this IOS app you speak of. How does it work? I'm assuming via WIFI? Is there a "refresh" or "reconnect" etc to get what ever the current state of the A/C unit is?

FYI, please avoid screen shots where possible (unless asked), text is much better as it allows us to cut-n-paste if need be. etc.

crankyoldgit commented 4 years ago

@crankyoldgit, thanks for your reply!

I'll try as you suggested, but please have a look at my previous post, especially from step 5 to 6.

From what I can gather, yes, it seems like there are distinct codes/messages for each "mode" for your A/C unit at least.

TROTEC seems to control the device correctly. It seems the issue you're reporting boils down to: "My IOS app doesn't reflect the same state as the actual A/C unit is now in after I send it IR commands" is that correct?

RaymondMouthaan commented 4 years ago

I know nothing of this IOS app you speak of. How does it work? I'm assuming via WIFI? Is there a "refresh" or "reconnect" etc to get what ever the current state of the A/C unit is?

Yes, the app comes with the hvac and when controlling the hvac with it's original IR remote the app gets updated (my guess the app requests an update from the hvac through WiFi, or the hvac pushes an update to the app).

TROTEC seems to control the device correctly. It seems the issue you're reporting boils down to: "My IOS app doesn't reflect the same state as the actual A/C unit is now in after I send it IR commands" is that correct?

Yes, exactly ... to be more precise .. non of the TROTEC commands make the app respond.

crankyoldgit commented 4 years ago

Also which version (and build type) of Tasmota are you using? i.e. there are several different builds for each version. e.g. standard, minimal, full IR support etc etc Paging @s-hadinger who (I think) looks after the IRremoteESP8266 integration in Tasmota.

RaymondMouthaan commented 4 years ago

Also which version (and build type) of Tasmota are you using? i.e. there are several different builds for each version. e.g. standard, minimal, full IR support etc etc Paging @s-hadinger who (I think) looks after the IRremoteESP8266 integration in Tasmota.

I am compiling a custom firmware based upon 'tasmota-ircustom', which is based on the latest dev branch of Tasmota and tried all hvac vendors listed, the only one which works is TROTEC.

NiKiZe commented 4 years ago

Please correct me if I'm wrong, but it seems that you have tested different protocols, and it just happens that it responds to Trotec, it might be a leftover from firmware development, and not really intended to work?

crankyoldgit commented 4 years ago

Yes, exactly ... to be more precise .. non of the TROTEC commands make the app respond.

Does your IOS app respond if you send it via the "NEC" codes? We need to confirm that to test my theory (below). Note: It's just a theory.

As far as I can tell from the data you've collected, IRrecvDumpV2 indicates the codes are NEC codes. (Correct?) Look at the rawData you've provided they look like NEC codes to me. The Trotec protocol we support uses a different frequency and different header timings. So, if Trotec is working for you, it's not technically by design. Thus the A/C unit might actually support two different protocols, NEC & Trotec. It could be the wifi-connected part is only expecting NEC codes (produced by the actual remote) and talks to the "main" A/C logic/control system via another method, where as the A/C unit itself probably accepts the Trotec codes directly, bypassing the "wifi part".

If the IOS app responds to you replaying the "NEC" codes to it, then that would support this theory.

If that theory is true/is the case, then there is not a lot we can do to get your IOS app to stay in sync.

e.g. Imaging, if you will, that there is a tiny ESP8266/wifi-ir-connected microcontroller already on your A/C unit. It accepts commands via wifi (IOS app) and via a "dumb"/simple IR remote using NEC protocol "button only" messages. It converts it's own internal state in to a "Trotec" IR message (maybe even using this library, who knows) and sends it to the non-wifi part of the A/C to control it. What you might be doing is bypassing their "smart" wifi-ir-controller hardware, and talking directly to the dumb(er) hardware. In that scenario, the "smart" part of the A/C unit doesn't know what the actual state is of the "dumb" part of the A/C. It works because it assumes only it is talking to the A/C unit, not someone with another full functionality/detailed (trotec) remote etc.

crankyoldgit commented 4 years ago

I am compiling a custom firmware based upon 'tasmota-ircustom', which is based on the latest dev branch of Tasmota and tried all hvac vendors listed, the only one which works is TROTEC.

Cool. Thanks for the info. I suspected as much, but wanted to be sure.

NiKiZe commented 4 years ago

The unit itself does have a display (and maybe buttons as well)? If so, does that display update according to what you send when using Trotec?

RaymondMouthaan commented 4 years ago

Please correct me if I'm wrong, but it seems that you have tested different protocols, and it just happens that it responds to Trotec, it might be a leftover from firmware development, and not really intended to work?

Yes, I started to flash the Wemos with Tasmota irremote firmware and tried all vendors, just to see whether one of them makes the Duux respond. After trying all of them, the only vendor that seems to work was TROTEC, but the IOS app doesn't respond on these commands (as explained above).

RaymondMouthaan commented 4 years ago

The unit itself does have a display (and maybe buttons as well)? If so, does that display update according to what you send when using Trotec?

Yes, the hvac itself has similar buttons (7x) as the remote and a display and several indicators displaying the state of the hvac. This display (with temperature) and indicators do respond on the TROTEC commands as well on the IRSend commands.

NiKiZe commented 4 years ago

The unit itself does have a display (and maybe buttons as well)? If so, does that display update according to what you send when using Trotec?

Yes, the hvac itself has similar buttons (7x) as the remote and a display and several indicators displaying the state of the hvac. This display (with temperature) and indicators do respond on the TROTEC commands as well on the IRSend commands.

What if you send a Trotec message, and then press something on original remote, would that get you correct state in the app?

crankyoldgit commented 4 years ago

Yes, the hvac itself has similar buttons (7x) as the remote and a display and several indicators displaying the state of the hvac. This display (with temperature) and indicators do respond on the TROTEC commands as well on the IRSend commands.

That is still consistent with my theory. i.e. Wifi support is a bolted-on extra, without direct integration (i.e. feedback) to the A/C unit.

I have 2 Internet Points riding on my bet that I'm right. ;-) (because it's a very cheap way to add app/wifi support to an existing A/C unit for <$5 of hardware and use a cheaper remote too) so they can sell it to punters for more $$$.

crankyoldgit commented 4 years ago

For the record, technically "Help, my IOS app doesn't update" really is outside of the remit of us providing support from the Library's perspective. I'm helping as much as we can so a) we learn more, and b) try to see if they is any way to improve your situation, because it's always nice when things co-operate. (We are all frustrated end-consumers too! ;-P)

TL;DR: We may not be able to fix/workaround your devices fundamental design decisions, but we will if we can.

RaymondMouthaan commented 4 years ago

The unit itself does have a display (and maybe buttons as well)? If so, does that display update according to what you send when using Trotec?

Yes, the hvac itself has similar buttons (7x) as the remote and a display and several indicators displaying the state of the hvac. This display (with temperature) and indicators do respond on the TROTEC commands as well on the IRSend commands.

What if you send a Trotec message, and then press something on original remote, would that get you correct state in the app?

A few more tests:

Scenario 1 1) Initial state: hvac off 2) IRhvac {"Vendor":"TROTEC","Power": 1}

turns on hvac, but IOS app remains off 3) IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F00FF","DataLSB":"0x00FE00FF","Repeat":0}
changes operation state on the hvac AND updates IOS app goes to state on and displays identical state and indicators as shown on the display of the hvac itself.

Scenario 2 1) Initial state: hvac off 2) IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F20DF","DataLSB":"0x00FE04FB","Repeat":0}

turns on hvac AND IOS app goes on with the same state and indicators as displayed on the hvac itself 3) IRhvac {"Vendor":"TROTEC","Power": 1,"Mode":"Dry"}
changes operation state on the hvac to dry mode, but does NOT update the IOS app.

Scenario 3 1) Initial state: hvac off 2) IRhvac {"Vendor":"TROTEC","Power": 1}

turns on hvac, but IOS app remains off 3) Pressing fan speed button on the remote, makes the hvac change the fan speed AND update the app update accordingly.

crankyoldgit commented 4 years ago

IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F00FF","DataLSB":"0x00FE00FF","Repeat":0}

[Q] What button press does this code represent?

Pressing fan speed button on the remote, makes the hvac change the fan speed AND update the app update accordingly.

Do you mean the just the fan speed updates accordingly, or the entire state of the A/C updates according on the IOS app?

RaymondMouthaan commented 4 years ago

For the record, technically "Help, my IOS app doesn't update" really is outside of the remit of us providing support from the Library's perspective. I'm helping as much as we can so a) we learn more, and b) try to see if they is any way to improve your situation, because it's always nice when things co-operate. (We are all frustrated end-consumers too! ;-P)

TL;DR: We may not be able to fix/workaround your devices fundamental design decisions, but we will if we can.

still try to understand your theory, while I am doing tests as above and building the circuit for IRRecvDumpv2. But your help is very much appreciated 👍

crankyoldgit commented 4 years ago

still try to understand your theory, while I am doing tests as above and building the circuit for IRRecvDumpv2. But you help is very much appreciated 👍

It could also be "The wifi part only update/fetches the state of the A/C from the A/C when it sees an NEC message, not a TROTEC" message.

crankyoldgit commented 4 years ago

Hmm .. maybe what we need is a Neutral/No-OP/do nothing NEC code that the A/C sees .. which does nothing, but forces it to update the WIFI/App status. i.e. Send a "don't change anything" NEC message after every IRhvac Trotec message.

RaymondMouthaan commented 4 years ago

IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F00FF","DataLSB":"0x00FE00FF","Repeat":0}

[Q] What button press does this code represent?

Change Operation Mode

IRsend

IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F00FF","DataLSB":"0x00FE00FF","Repeat":0}

Pressing fan speed button on the remote, makes the hvac change the fan speed AND update the app update accordingly.

Do you mean the just the fan speed updates accordingly, or the entire state of the A/C updates according on the IOS app?

I mean when pressing the fan speed button on the remote, makes the havc change its fan speed and the app shows that the hvac is turned on + all other indictors like operation mode, fan speed etc are update in the app accordingly. Basically the IRsend command makes the app 'active' again.

crankyoldgit commented 4 years ago

Ta. That goes with what my latest idea is. The wifi-side/part only fetches the status info from the non-wifi A/C side when it gets an NEC message. And that the non-wifi part of the A/C also accepts TROTEC protocol.

Try this:

Initial state: hvac off
IRhvac {"Vendor":"TROTEC","Power": 1}
IRsend {"Protocol":"NEC","Bits":32,"Data":"0x00FF00FF","Repeat":0} // Which is a effectively a '0' NEC code. or IRsend {"Protocol":"NEC","Bits":32,"Data":"0x7E817E81","Repeat":0} // Which happens to be a valid NEC code for "Power on" on my stereo. ;-)

Maybe we will get lucky and either of those codes won't cause an action on the A/C unit, but force the wifi/app-side to update.

RaymondMouthaan commented 4 years ago

3. IRsend {"Protocol":"NEC","Bits":32,"Data":"0x7E817E81","Repeat":0}

Both IRsend commands do nothing, not even a beep on the hvac to indicate that it "understood" the IR code.

crankyoldgit commented 4 years ago

Just because I used a different format (i.e. no DataLSB clause) Does the shortened IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F00FF","Repeat":0} cause a beep? i.e. Did I produce a valid Tasmota command.

I assuming that we did, that means it probably needs a "valid" existing code from your remote. Is there a button you can press on the remote that doesn't (significantly) change the A/C much? If so, try that maybe instead?

RaymondMouthaan commented 4 years ago

Just because I used a different format (i.e. no DataLSB clause) Does the shortened IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F00FF","Repeat":0} cause a beep? i.e. Did I produce a valid Tasmota command.

I assuming that we did, that means it probably needs a "valid" existing code from your remote. Is there a button you can press on the remote that doesn't (significantly) change the A/C much? If so, try that maybe instead?

Just to clarify things:

Power toggle (without DataLSB): IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F20DF","Repeat":0} and IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F20DF","DataLSB":"0x00FE04FB","Repeat":0} both work and makes the hvac beep, once it receives it.

In contrast to IRsend {"Protocol":"NEC","Bits":32,"Data":"0x7E817E81","Repeat":0} and IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F00FF","Repeat":0} which both do nothing with the hvac (no beep).

crankyoldgit commented 4 years ago

Power toggle (without DataLSB): IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F20DF","Repeat":0} and IRsend {"Protocol":"NEC","Bits":32,"Data":"0x007F20DF","DataLSB":"0x00FE04FB","Repeat":0} both work and makes the hvac beep, once it receives it.

Ta. It was a long shot, but worth a try just in case to rule out that as a possible cause of a problem.

crankyoldgit commented 4 years ago

Slightly off topic: Our TROTEC implementation has a "Sleep" setting (on or off), which is probably your "Night" mode. I have no idea how you access that via IRhvac on Tasmota. If they use our common A/C api (which I think they do, a value of Sleep: -1 would be off, and >=0 would be on. e.g. https://github.com/crankyoldgit/IRremoteESP8266/blob/117f0ed6bad30f6f7b5523abbd708f5e92a1093a/src/IRac.cpp#L1748

Looking back at your earlier data, the NEC code you have for Timer (0x007F807F) might be a good candidate for sending after a Trotec message to trick the wifi part to update. It probably doesn't change the operation noticeably. Perhaps you can send it twice, if it is a simple Timer on/off toggle operation etc. FYI the common A/C api (that I think tasmota uses) does NOT support timers. i.e. there is no way from the IRhvac interface to twiddle with that setting. It is available via direct use of this library however. e.g. https://github.com/crankyoldgit/IRremoteESP8266/blob/117f0ed6bad30f6f7b5523abbd708f5e92a1093a/src/ir_Trotec.cpp#L146-L149

RaymondMouthaan commented 4 years ago

I placed the IR receiver circuit close to the IR receiver of the hvac, so that when I press a button on the remote, both hvac and the circuit receive the same code. The Wemos is flashed with IRrecvDumpv2.

1) Initial state of the hvac is off, also the app shows off.

2) Pressing Power ON on the original remote

Timestamp : 001180.902
Library   : v2.7.7

Protocol  : NEC
Code      : 0x7F20DF (32 Bits)
uint16_t rawData[71] = {8940, 4508,  514, 590,  566, 564,  538, 592,  540, 564,  566, 592,  538, 566,  514, 592,  540, 588,  514, 618,  514, 1722,  488, 1748,  514, 1772,  462, 1746,  514, 1726,  514, 1746,  488, 1748,  514, 616,  514, 590,  540, 1722,  514, 588,  542, 588,  542, 590,  514, 590,  542, 588,  542, 1694,  568, 1694,  518, 586,  620, 1642,  516, 1718,  568, 1666,  570, 1694,  516, 1718,  566, 40974,  8990, 2220,  590};  // NEC 7F20DF
uint32_t address = 0xFE00;
uint32_t command = 0x4;
uint64_t data = 0x7F20DF;

Turns on the hvac
App show the state and indicators identical to the hvac

3) Pressing fan speed button

Timestamp : 001211.183
Library   : v2.7.7

Protocol  : NEC
Code      : 0x7FE01F (32 Bits)
uint16_t rawData[71] = {8994, 4478,  570, 534,  596, 534,  568, 564,  568, 534,  596, 536,  592, 536,  570, 534,  596, 534,  594, 536,  570, 1668,  592, 1642,  594, 1668,  566, 1668,  592, 1644,  568, 1696,  540, 1698,  588, 1646,  568, 1694,  540, 1694,  566, 564,  540, 564,  568, 564,  564, 566,  540, 540,  564, 590,  538, 592,  514, 590,  540, 1722,  512, 1748,  488, 1722,  516, 1746,  488, 1746,  488, 41052,  8966, 2242,  568};  // NEC 7FE01F
uint32_t address = 0xFE00;
uint32_t command = 0x7;
uint64_t data = 0x7FE01F;

sets fan speed from high to 'medium' on the hvac and updates the app likewise

Sometime while doing these tests I get protocol UNKNOWN of 37 bits:

Timestamp : 001394.285
Library   : v2.7.7

Protocol  : UNKNOWN
Code      : 0x21FB5199 (37 Bits)
uint16_t rawData[73] = {8940, 4504,  544, 560,  654, 478,  564, 590,  518, 562,  568, 558,  654, 478,  546, 562,  568, 562,  644, 488,  544, 1690,  568, 1670,  570, 1690,  546, 1692,  566, 1696,  544, 1690,  544, 310,  86, 1296,  566, 564,  544, 564,  568, 1690,  544, 562,  544, 586,  564, 564,  544, 564,  568, 562,  540, 1698,  568, 1692,  544, 562,  568, 1692,  544, 1718,  516, 1722,  542, 1666,  570, 1692,  540, 41002,  8940, 2270,  542};  // UNKNOWN 21FB5199

And sometimes after a protocol NEC I get:

Timestamp : 001393.001
Library   : v2.7.7

Protocol  : NEC (Repeat)
Code      : 0xFFFFFFFFFFFFFFFF (0 Bits)
uint16_t rawData[3] = {8940, 2244,  570};  // NEC (Repeat) FFFFFFFFFFFFFFFF
uint64_t data = 0xFFFFFFFFFFFFFFFF;

Not sure if means something useful?

RaymondMouthaan commented 4 years ago

Slightly off topic: Our TROTEC implementation has a "Sleep" setting (on or off), which is probably your "Night" mode. I have no idea how you access that via IRhvac on Tasmota. If they use our common A/C api (which I think they do, a value of Sleep: -1 would be off, and >=0 would be on. e.g.

https://github.com/crankyoldgit/IRremoteESP8266/blob/117f0ed6bad30f6f7b5523abbd708f5e92a1093a/src/IRac.cpp#L1748

Looking back at your earlier data, the NEC code you have for Timer (0x007F807F) might be a good candidate for sending after a Trotec message to trick the wifi part to update. It probably doesn't change the operation noticeably. Perhaps you can send it twice, if it is a simple Timer on/off toggle operation etc. FYI the common A/C api (that I think tasmota uses) does NOT support timers. i.e. there is no way from the IRhvac interface to twiddle with that setting. It is available via direct use of this library however. e.g.

https://github.com/crankyoldgit/IRremoteESP8266/blob/117f0ed6bad30f6f7b5523abbd708f5e92a1093a/src/ir_Trotec.cpp#L146-L149

When the hvac is in operation state cooling then this command works:

IRhvac {"Vendor": "TROTEC", "Power":"On", "Sleep": 1}

set the sleep indicator on the hvac, but after few seconds it goes back to operation mode 'Auto'.

RaymondMouthaan commented 4 years ago

Some more IRRecvDumpv2 dumps:

1) hvac has initial state: Cooling, Fan speed low and temperature 18 degrees.

2) Pressing Temperature UP on the original remote:

Timestamp : 000390.121
Library   : v2.7.7

Protocol  : NEC
Code      : 0x7FA05F (32 Bits)
uint16_t rawData[71] = {8966, 4504,  568, 564,  572, 532,  598, 534,  566, 562,  572, 520,  610, 532,  596, 536,  570, 532,  598, 534,  594, 1642,  596, 1642,  592, 1666,  594, 1616,  594, 1692,  568, 1666,  568, 1668,  570, 1694,  542, 540,  592, 1692,  542, 538,  592, 564,  540, 590,  540, 566,  566, 562,  540, 592,  514, 1724,  536, 590,  490, 1746,  488, 1724,  538, 1746,  488, 1746,  488, 1746,  516, 41024,  8966, 2270,  518};  // NEC 7FA05F
uint32_t address = 0xFE00;
uint32_t command = 0x5;
uint64_t data = 0x7FA05F;

Timestamp : 000390.226
Library   : v2.7.7

Protocol  : NEC (Repeat)
Code      : 0xFFFFFFFFFFFFFFFF (0 Bits)
uint16_t rawData[3] = {8964, 2268,  522};  // NEC (Repeat) FFFFFFFFFFFFFFFF
uint64_t data = 0xFFFFFFFFFFFFFFFF;

Timestamp : 000396.802
Library   : v2.7.7

Protocol  : UNKNOWN
Code      : 0xA7C5D5C7 (36 Bits)
uint16_t rawData[71] = {8988, 4506,  570, 562,  540, 566,  540, 590,  540, 590,  538, 592,  514, 564,  542, 614,  514, 618,  488, 616,  516, 1720,  514, 1748,  488, 1748,  514, 1746,  488, 1746,  488, 1722,  540, 1746,  490, 1746,  486, 616,  516, 1746,  490, 640,  514, 590,  542, 588,  514, 614,  518, 562,  568, 560,  568, 1668,  570, 586,  542, 1694,  570, 1692,  544, 1666,  570, 1668,  570, 1716,  542, 40972,  8968, 2266,  544};  // UNKNOWN A7C5D5C7

Timestamp : 000396.899
Library   : v2.7.7

Protocol  : NEC (Repeat)
Code      : 0xFFFFFFFFFFFFFFFF (0 Bits)
uint16_t rawData[3] = {8964, 2270,  516};  // NEC (Repeat) FFFFFFFFFFFFFFFF
uint64_t data = 0xFFFFFFFFFFFFFFFF;

this sets the temperature on the hvac to 19 degrees, please note I had to press the button twice, since the first press shows blinking 18 deg to indicate current set temperature. The second press actual increases the current temp from 18 deg to 19 deg.

3) Pressing Temperature UP again on the original remote:

Timestamp : 000516.013
Library   : v2.7.7

Protocol  : UNKNOWN
Code      : 0xBA7DAD95 (37 Bits)
uint16_t rawData[73] = {80, 6480,  8936, 4560,  540, 590,  512, 566,  542, 616,  488, 642,  488, 616,  516, 614,  488, 642,  490, 588,  542, 614,  490, 1720,  542, 1746,  490, 1744,  490, 1722,  542, 1744,  490, 1746,  488, 1722,  568, 1720,  516, 588,  542, 1720,  516, 588,  544, 586,  516, 614,  518, 562,  570, 560,  568, 588,  542, 1694,  540, 590,  542, 1692,  544, 1692,  544, 1718,  544, 1690,  544, 1692,  570, 40970,  8968, 2268,  544};  // UNKNOWN BA7DAD95

Timestamp : 000516.119
Library   : v2.7.7

Protocol  : NEC (Repeat)
Code      : 0xFFFFFFFFFFFFFFFF (0 Bits)
uint16_t rawData[3] = {8964, 2268,  520};  // NEC (Repeat) FFFFFFFFFFFFFFFF
uint64_t data = 0xFFFFFFFFFFFFFFFF;

Timestamp : 000517.137
Library   : v2.7.7

Protocol  : NEC
Code      : 0x7FA05F (32 Bits)
uint16_t rawData[71] = {8990, 4480,  568, 588,  516, 588,  544, 562,  570, 564,  564, 590,  516, 586,  544, 586,  544, 588,  518, 562,  570, 1694,  542, 1718,  544, 1694,  544, 1716,  542, 1692,  544, 1666,  596, 1692,  518, 1716,  544, 588,  544, 1692,  568, 562,  544, 536,  596, 560,  568, 536,  570, 560,  570, 560,  568, 1666,  572, 558,  568, 1642,  596, 1692,  518, 1714,  570, 1642,  570, 1716,  520, 40996,  8968, 2266,  544};  // NEC 7FA05F
uint32_t address = 0xFE00;
uint32_t command = 0x5;
uint64_t data = 0x7FA05F;

this sets the temperature on the hvac to 20 degrees, please note I had to press the button twice, since the first press shows blinking 19 deg to indicate current set temperature. The second press actual increases the current temp from 19 deg to 20 deg.

Hope this gives more insight :-)

crankyoldgit commented 4 years ago

Not really. The NEC (Repeat) code(s) are just how the protocol works. i.e. think "It sends this special code to indicate the button is still held down" etc. The UNKNOWN ones are also red-herrings. They are just NEC messages that for some reason (I'm not going to look into why) are not matching the spec correctly.

All the data you've provided thus far points to:

The physical IR remote uses the NEC protocol, and it has simple (dumb) button operation. (same code for each press/button)
The A/C accepts both NEC and Trotec protocols.
The A/C only updates it's wifi status/info when it receives a known NEC message or a physical button press on the A/C unit.
You can set the A/C's settings via Trotec.
The A/C unit maintains the "state" of the settings when using the NEC/Remote messages. i.e. NEC/remote message are "simple". Where as Trotec allows the remote to control the entire state in a single message.

So, I don't think there is anything we can do to force your A/C unit's wifi component to update using the TROTEC protocol. It has to be one of the pre-defined NEC messages. Thus the only way it seems you can get it to update your app after using tasmota to change the A/C via trotec, is to send at least one pre-defined NEC messages.

So, you've got few options as far as I can see it at the moment:

If you want your iPhone etc to be up-to-date:

Send a IRhvac Trotec message, and then follow it up with at least one pre-existing IRsend NEC message. or
Send only the NEC messages just like you would be if pressing the physical buttons on the actual remote. (i.e. No easy way set arbitrary values like temp etc). Just a sequence of +1's or -1's effectively .. or "change to the next mode" etc.

or If you don't care about the iPhone being in sync:

Just use IRhvac/Trotec and that's it.

The library does not support a IRhvac interface for "simple"/dumb protocols that operate like how they are using the NEC protocol. It could be done with your own program/project, where you emulate the A/C's on-board controller/state engine etc, but we won't add it to the library directly.

Other things you could try that are out of scope for this library & support etc.: 1) See if there is some URL, TCP, or UDP protocol message you can send the A/C to force/trigger an update of it's state from the other half of it's brain. 2) See if there is a URL/TCP/UDP to control the settings directly avoiding IR totally. That would be more reliable than using IR. e.g. Just like your app does. Look into tools like tcpdump or wireshark etc to see if you can work out how that app & a/c communicate over the network. 3) Try to send semi-random NEC commands to the A/C unit hoping to find a command that does nothing and causes it to update it's wifi part. (For point "1." earlier)

(EDIT: Clean up some poor English and typos)

crankyoldgit commented 4 years ago

Hope this gives more insight :-)

Nope. Sadly, the data just adds more support for my last update/explanation/theory etc.

NiKiZe commented 4 years ago

To add on to what crankyoldgit said above, does setting e.g. temp via Trotec, and then temp button once also update the WiFi part? If not send one degree higher or lower, and then 2 temp presses to change it one degree to the correct, not as reliable, but maybe a workaround for you.

crankyoldgit commented 4 years ago

To add on to what crankyoldgit said above, does setting e.g. temp via Trotec, and then temp button once also update the WiFi part? If not send one degree higher or lower, and then 2 temp presses to change it one degree to the correct, not as reliable, but maybe a workaround for you.

I did think of that, but they'd have to track what the desired temp is and do some pre-processing. e.g. "I want 20C, so send 19C using trotec, then send the "temp up/+1" NEC code." But they would have to handle the corner cases. i.e. You can't set the lowest temp that way. Assuming "16C" is the lowest temp. You'd have to send "16C", and then "temp down/-1", or "17C" and then "temp down/-1" to achieve 16C. Because sending 15C (which would convert to 16C at the A/C) or 16C, then temp up/+1 would result in 17C etc.

Either way, I'm not going to add that sort of horrible hack to the library to support a manufacturers poor design decisions on how their WIFI interface works. i.e. We have to draw a line somewhere ;-)

crankyoldgit commented 4 years ago

Sigh, it would be even worse. Mode changes and power changes would require that you send a temp up then down to maintain a neutral overall change, assuming those commands don't cause the unit to turn on (if it was off etc) and you would have to track what the existing temp was because of the boundary conditions described above if you're at the end of the temp spectrum.

I.e. It gets uglier and uglier the more I think about it. :-P

crankyoldgit commented 4 years ago

@RaymondMouthaan PS, you might be able automate sending the subsequent NEC command (if you find a suitable one/sequence) using Tasmota's rules. I've done some pretty awesome/advanced stuff using that, but it's not trivial or intuitive sometimes.

RaymondMouthaan commented 4 years ago

Thanks guys for all the time it took for helping me out here!

I guess it's not so easy I was hoping for to simple duplicate the implementation of TROTEC and modify the raw data with the once of the Duux, so that it sends the codes which also interacts with app. The app is not mandatory for me, so can live without it.

Using TROTEC might be the solution (with possible some additional IRSend command) but I need to do some more testing on that part.

Like you suggested, even better / nicer is to communicate with the api via WiFI of the hvac instead of using IR. I need to do some more investigation on this.....

crankyoldgit commented 4 years ago

I guess it's not so easy I was hoping for to simple duplicate the implementation of TROTEC and modify the raw data with the once of the Duux

Alas no. Trotec (and most other A/Cs) send the whole config of the A/C in each message. e.g. "On, cool, 19C, Low Fan" all in one 32-bit message for example. We work out what (figurative and literal) bits of the message mean "cool" and "19C" etc so we can construct a new code the A/C understands with all that info in it. You remote's messages are things like "add one to the temp". Similar to a traditional TV remote for volume/channel change etc. There is no single state/message/code we can construct to tell the a/c to do "On, cool, 19C, Low Fan". e.g. On "normal" ac remotes, pressing the "temp up" button twice, results in different numeric codes because they contain the actual desired temperature. Not a relative command.

NiKiZe commented 4 years ago

To add on to what crankyoldgit said above, does setting e.g. temp via Trotec, and then temp button once also update the WiFi part? If not send one degree higher or lower, and then 2 temp presses to change it one degree to the correct, not as reliable, but maybe a workaround for you.

... Either way, I'm not going to add that sort of horrible hack to the library to support a manufacturers poor design decisions on how their WIFI interface works. i.e. We have to draw a line somewhere ;-)

Want to be clear that I did not want it to sound like a suggestion of adding that to the official code. ;)

crankyoldgit commented 4 years ago

Want to be clear that I did not want it to sound like a suggestion of adding that to the official code. ;)

Haha. It was mostly clear... Mostly. :-P

crankyoldgit / IRremoteESP8266

Help on adding support Duux Blizzard HVAC #1176

Duux Blizzard - HVAC

Specifications

Power

Power Toggle

IRsend

IRRecvDump

IRhvac

Power on

Power off

Operation Mode

Change Operation Mode

IRsend

IRRecvDump

IRhvac

Auto

Cooling

Dehumidification

Ventilation

Fanspeed

IRsend

IRRecvDump

IRhvac

Fanspeed Low

Fanspeed Medium

Fanspeed High

Temperature

IRsend

Temerature Up

IRRecvDump

Temperature Down

IRRecvDump

IRhvac

Timer

IRsend

IRRecvDump

IRhvac

Night Mode

IRsend

IRRecvDump

IRhvac

Fanspeed

IRsend

IRRecvDump

Change Operation Mode

IRsend