search

crankyoldgit / IRremoteESP8266

Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://github.com/shirriff/Arduino-IRremote/
GNU Lesser General Public License v2.1
2.94k stars 831 forks source link

Super long Daikin IR Protocol with IRMQTTServer #582

Closed sheppy99 closed 5 years ago

sheppy99 commented 5 years ago

I'm trying to use your example to send a very long raw code to a Daikin AC unit, but can't get it to work. According to a capture from IRrecvDumpV2 the protocol is unknown and 317bits. Do you know of anything ESP8266 based that can send something as long as this, or can IRMQTTserver be modified to send this using either MQTT or HTTP? Looking at the IR LED with an old digital camera shows the server sends the example codes but not my RAW code Sadly it seems my remote ARC477A1 may be a new longer IR string than usual IRrecvDumpV2 output attached Off.txt Fan.txt

crankyoldgit commented 5 years ago

I'll take a detailed look at your captures later, but in the meantime, the answer is, yes. This library/ESP8266 can send RAW messages that long.

e.g.

uint16_t rawData[633] = {10024, 25180, ...};  // As reported by IRrecvDumpV2
irsend.sendRaw(rawData, 633, 38000);

See: https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRsendDemo/IRsendDemo.ino

IRMQTTServer "as is" will not process an MQTT message that big, you'll need to increase the MQTT_MAX_PACKET_SIZE value as described here: https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRMQTTServer/IRMQTTServer.ino#L30 (Arduino IDE) or https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRMQTTServer/platformio.ini#L6 (PlatformIO IDE) i.e. Something much larger than 512 bytes. No idea what size, probably several Kbytes at least judging by the size of your capture.

See https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRMQTTServer/IRMQTTServer.ino#L70 for the MQTT sendRaw format.

But, the HTTP interface should accept it as is. Using raw (protocol type 30): http://your_irmqtt_server_address/ir?code=38000,10024,25180,rest,of,your,raw,code,from,irrecvdumpv2,here,without,spaces,etc&type=30 (See https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRMQTTServer/IRMQTTServer.ino#L417)

sheppy99 commented 5 years ago

Thanks very much for the reply, you are correct it does work with HTTP. I've spent days trying to get this working! Changing MQTT_MAX_PACKET_SIZE to 4096 has allowed me to send MQTT to it too from OpenHAB with a rule using the MQTTAction binding and very long strings. Let me know if there is an easier way than simply recording the RAW commands and playing them back, its a Daikin US07 unit I've got and a lot of the good stuff can't be accessed directly using the APi. However its easy to translate the dump files into MQTT strings with notepad++

crankyoldgit commented 5 years ago

Excellent.

Doing some basic analysis on one of your messages:

IRremoteESP8266/tools$ ./auto_analyse_raw_data.py -f /tmp/Off_Modified.txt 
Found 633 timing entries.
Potential Mark Candidates:
[10024, 3500, 446]
Potential Space Candidates:
[35166, 25180, 1732, 1328, 472]
DANGER: Unexpected and unused mark timings!
Guessing encoding type:
Looks like it uses space encoding. Yay!

Guessing key value:
kHdrMark   = 10024
kHdrSpace  = 1728
kBitMark   = 418
kOneSpace  = 1315
kZeroSpace = 451
kSpaceGap1 = 35166
kSpaceGap2 = 25180

Decoding protocol based on analysis so far:

kHdrMark+UNEXPECTED->GAP(25180)UNKNOWN(3494)UNEXPECTED->kHdrSpace+1000100001011011111001000000000010000000010111101100001100001110000101000011000000000001001000000000110101101000001001000000000000000000011111011010101110101111GAP(35166)
  Bits: 160
  Hex:  0x885BE400805EC30E143001200D682400007DABAF (MSB first)
        0xF5D5BE00002416B004800C2870C37A010027DA11 (LSB first)
  Dec:  778471974416934118888308974746022257436401707951 (MSB first)
        1403469348913642123458598093193973739523595033105 (LSB first)
  Bin:  0b1000100001011011111001000000000010000000010111101100001100001110000101000011000000000001001000000000110101101000001001000000000000000000011111011010101110101111 (MSB first)
        0b1111010111010101101111100000000000000000001001000001011010110000000001001000000000001100001010000111000011000011011110100000000100000000001001111101101000010001 (LSB first)
UNKNOWN(3500)UNEXPECTED->kHdrSpace+10001000010110111110010000000000000000000001000001100100000000000000010100000000000000000110000000000110000000000000000010000011000000010000011011100111
  Bits: 152
  Hex:  0x885BE4000010640005000060060000830106E7 (MSB first)
        0xE76080C1000060060000A0002608000027DA11 (LSB first)
  Dec:  3040906149399945345039324598523235616207996647 (MSB first)
        5159878732993999603745427977512764575190604305 (LSB first)
  Bin:  0b10001000010110111110010000000000000000000001000001100100000000000000010100000000000000000110000000000110000000000000000010000011000000010000011011100111 (MSB first)
        0b11100111011000001000000011000001000000000000000001100000000001100000000000000000101000000000000000100110000010000000000000000000001001111101101000010001 (LSB first)

Total Nr. of suspected bits: 312

Looking at the values collected/decoded. Yes, the existing decoder/encoder will not work for this protocol.

I'll code something basic up for your model. If you are prepared to put in the effort decoding the state[]s once we have it, we can look at doing a full decoder/encoder for it.

Can we start by getting the make/model numbers of all the pieces involved? i.e. remote & head unit(s).

sheppy99 commented 5 years ago

Very happy to work on a full implementation with you - I’ll get the exact model numbers and anything else you need tomorrow afternoon. It’s got a lot of options which should help anyone following later. If you can let me know what you would like IR dumps of I’ll create some more. Is it easiest to send files on here? I’m in New Zealand (GMT + 13) with an early start tomorrow so it’s bedtime shortly.

crankyoldgit commented 5 years ago

I'm working on some rough decoding of what you've already provided. So no dumps yet till it detects/decodes it into a state[] in the dump program, please. Otherwise we will be drowning in data. :)

crankyoldgit commented 5 years ago

@sheppy99 If you want to try out the code in this branch: https://github.com/markszabo/IRremoteESP8266/tree/daikin2 It should (maybe) in theory decode your remote messages down to a 39 byte state[] array.

If it does, then we can start looking at how to deep decode the messages. For some hints on how to collect/represent the data, take a look at the recent Whirlpool A/C issue (#572)

Let me know how it goes for you.

sheppy99 commented 5 years ago

That mainly works, and the decoder gives a result every time. I wonder if the timing is totally accurate as the AC doesn't always respond first time, so I will experiment later today with slightly different timings to see if it works more reliably. I'll also get the model numbers later today, and assuming the timing changes make things reliable I'll capture a bunch of modes and settings and add them to a single text file. I have the WiFi option so I can use it to check the IR has sent some of the correct settings.

crankyoldgit commented 5 years ago

Re: sending. Yes, the timings could well be off. I only based it on one sample. Feel free to adjust. Let me know your findings. Also note, it is summer where we are, and IR signals are quite susceptible IR noise. I've noticed that I have trouble presently with signals that are controlling my TV/Stereo/AC etc are prone to random failure when I know they are "good" timings etc. The other thing than timing, is there could be something else in the protocol we are missing. Such as, If there is some other odd "noise" the IRrecvDumpV2 program isn't reporting due to settings. e.g. A short pre-amble to the message with a LONG gap after it (i.e. more than 15ms). Try modifying kMinUnknownSize (at https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRrecvDumpV2/IRrecvDumpV2.ino#L108) to something quite low. e.g. 5) and try a capture again. The other Daikin protocol has a short 5-6 pulse message at the start. We could be missing that.

Re: Decoding. I'm glad it's working for you. First thing to check for is a sequence of temps (lowest to highests) to see if we've got the bit ordering correct. i.e. some byte in the state[] should typically increase by 1 each for each diff. temp. If not, we may have it backwards. I strongly suggest putting the captured data into a Google Spreadsheet. That way anyone can see it, and it's formatted nicely, and we can label rows/columns etc. It's always up-to-date. It helps. Trust me. (See other issues/PRs where this has been done)

Re: Wifi. Why are you going via IR then? Use wifi. Much more reliable and you get confirmation. Much better for Home Automation. ;-)

sheppy99 commented 5 years ago

Re:sending I've put the 4 raw captures I have into a spreadsheet and the average timings are pretty close, however I am using an old Wemos D1 Arduino style and as the individual captures wonder a bit I think its clock might be a bit iffy, I have 2 new Huzzah's that should arrive tomorrow so I'll do further experiments to see if I can find anything on the new ones. I just tried setting kMinUnknownSize at 5 and found nothing extra.

Re:Decoding I've put a bunch of cooling mode captures into a google sheet - how can I get the link to you? 2 bytes seem to increase by 2 with temperature, and as this unit can do half degree increments and the remote only sends in whole degrees it has 2 be one of them

RE: WiFi. A lot of the stuff I need to work isn't available on WiFi, the Fan speed or direction can't be changed, powerful mode isn't available, and turning it off with WiFi bypasses the automatic filter cleaning and mold guard which are 2 of the main reasons I bought it. I can however use it to check the IR command has worked. My intention is to use IR to turn it on powerful to cool the bedroom during the free off peak power hour, and then use IR to switch to quiet fan speed overnight. I also need IR to turn it off for filter cleaning. Most of this I did with my previous AC using OpenHAB and an Iguanaworks USB multi channel IR sender, but it can't cope with the raw codes so I'm working on a better solution.

crankyoldgit commented 5 years ago

Good news on the "nothing extra". That means it's probably just a timing issue which you can tweak at, or a hardware issue, or something environmental. I can't really help with that obviously.

For the Google Sheets link, go to sharing, and make it read-only (view) to any one with the link. https://www.google.com.au/search?q=how+to+share+a+google+sheet+link

The D1 is probably fine clock-wise, it's more likely the IR receiver module. They can vary in quality a lot. Unless you use an oscilloscope, you are never likely to be sure what the problem is. Thankfully the protocols/methods involved are all try to accept large-ish margins of error in the analogue signal.

sheppy99 commented 5 years ago

Here's the link to the sheet, I'll add to it hopefully later today or tomorrow once the Huzzah's arrive. I'm getting a photo transistor later today and will connect it to my oscilloscope see if I can confirm the frequency is 38,000 Hz in case that is the cause of the unreliability. Can you take a quick look at the sheet and confirm the byte order is likely correct? From row 28 onwards I think I've isolated the temperature byte and powerful bit, assuming the checksum is at the end.

crankyoldgit commented 5 years ago

I'm pretty sure it will be 38kHz, but it's worth while to verify that.

Yes, typically the checksum is the last byte of data.

I think you've found the temp alright. The other daikin implementation has it as a multiple of 2 for the temp (see https://github.com/markszabo/IRremoteESP8266/blob/master/src/ir_Daikin.cpp#L183) e.g.

18C = 2 * 18 = 2 * 0x12 = 36 = 0x24
19C = 2 * 19 = 2 * 0x13 = 38 = 0x26

Based on the data collected thus far, I'm pretty sure we have the bit-ordering correct. So, capture away! Some tips for early on:

I'd strongly suspect that the location and storage of values will be quite similar for the older Daikin format, so examine the code for clues. Ditto, the checksum is probably calculated similarly. Engineers will likely re-use elements from protocol to protocol. ;-)

Good luck. Let me know when you've worked out the bare-minimum basics. e.g. temp (mostly done), operating mode, power, fan speed, and checksum (that one's a hard requirement for being able to send custom/modified messages) Timers/clocks/fan angles/special modes are not that critical.

sheppy99 commented 5 years ago

I've just installed recvDumpV2 on a new Huzzah and taken the average of 4 dumps to come up with slightly modified timings. I'll do further testing and further work on decoding, I'll also see if I can use elements from the original Daikin protocol so give me a few clues

sheppy99 commented 5 years ago

As its finally stopped raining I'm busy outside for the moment, but am still working on this when I get time. I'll update once I have made progress.

crankyoldgit commented 5 years ago

Thanks for the update.

crankyoldgit commented 5 years ago

@sheppy99 Friendly ping on your progress.

FYI: I've pushed version v2.5.4 of the library which includes what support we have so far for Daikin2.

sheppy99 commented 5 years ago

@crankyoldgit I've made a little progress over the holiday including sorting out the checksum and discovering that its a lot easier to work out individual bits if I unset the clock first. Haven't finished it yet but will try and make further progress today

crankyoldgit commented 5 years ago

Hi @crankyoldgit can I have your email please? wanted to contact you regarding a project. Thanks!

@klccjeremy I tend to not give out my email address unless needed. If the project is related to this library, just create a new issue.

sheppy99 commented 5 years ago

@crankyoldgit I've made quite a bit of progress, can you take a look at the google sheet and let me know if the format works for you please.

crankyoldgit commented 5 years ago

@crankyoldgit understand that. It is a private project that I need programmer to do it for me. Maybe you can drop an email to me at [redacted] if you're not comfortable to post your email here?

@klccjeremy I'm not really interested in doing private project work. Sorry.

crankyoldgit commented 5 years ago

@crankyoldgit I've made quite a bit of progress, can you take a look at the google sheet and let me know if the format works for you please.

@sheppy99 It's a good start! Not entirely intuitive to me, but I can work a lot of it out. I've requested comment access to the sheet, and I'll point out the confusing bits/parts that need more clarification there.

klccjeremy commented 5 years ago

@crankyoldgit understand that. thanks anyway =)

crankyoldgit commented 5 years ago

@sheppy99 I've started coding up some of the "deep" decoding of the Daikin2 protocol. If you care to follow along with the daikin2-deep branch you can test it out as I go.

sheppy99 commented 5 years ago

Great, although I’m unlikely to be able to do anything until late next week due to outside work. One thing I’d like to try if you get time to add it is the sleep timer function, which needs current time to be also working. That command calls up a special sleep program that drops the temperature slightly overnight then raises it again before waketime

crankyoldgit commented 5 years ago

@sheppy99 With that last commit to the branch, the library should now be able decode/construct almost all the aspects you have worked out. Please test it and let me know.

I'll send this off for code review shortly to get the ball rolling.

sheppy99 commented 5 years ago

@crankyoldgit I just tried to compile it and I get "exit status 1 'IRDaikin2' was not declared in this scope" which seems to be coming from half way down IRrecvDumpV2 in this section "#if DECODE_DAIKIN2 if (results->decode_type == DAIKIN2) { IRDaikin2 ac(0); ac.setRaw(results->state); description = ac.toString(); }

endif // DECODE_DAIKIN2"

crankyoldgit commented 5 years ago

Interesting. I suspect your copy of the branch is out of sync, or your IDE is using the standard (release) library, not the daikin2-deep branch's version.

Can you try a clean git clone and git checkout daikin2-deep, then recompile?

I just confirmed it compiles under PlatformIO okay, and the automated Travis build completed successfully. e.g. https://travis-ci.org/markszabo/IRremoteESP8266/jobs/478755870#L2218

sheppy99 commented 5 years ago

Thanks for checking. I downloaded the zip file from the link above, and then opened the sketch from that folder in Arduino IDE, so maybe it is using the wrong version. I just installed Platformio on Atom in case that worked, and whilst it compiles and uploads one version before trying to upload another and failing, I can't see anything on the serial monitor. I'll have to try this again later in the week when I have spare time. Unfortunately I know nothing about Platform io or using it to open things direct from GiT which has always been a mystery to me.

sheppy99 commented 5 years ago

After deleting a couple of old libraries, one of which was in a place I didn't expect it I have a successful compilation. IRMQTTServer when it receives a Daikin2 message gives "53,11DA270001EFC3F0280C8004B016240000BEDEF311DA270000082600A0000006600000C19260F9" over MQTT which is the same result as before, IRrecvDumpV2 gives the same thing down the serial port. This is likely a very stupid question, but how do I get to all the new settings?

crankyoldgit commented 5 years ago

@sheppy99 There will be no outward change in IRMQTTServer but you should see the decode results in IRrecvDumpV2. Check that the code you are compiling/uploading includes the code stanza you listed back in this comment: https://github.com/markszabo/IRremoteESP8266/issues/582#issuecomment-453791863

sheppy99 commented 5 years ago

Managed a quick look this morning and IRrecvDumpV2 is showing results at the beginning of the window, something I missed yesterday by not scrolling back. I got the following results from a quick test

`Timestamp : 000008.129 Encoding : DAIKIN2 Code : 11DA2700013042F0280C8004B016240000BECEA311DA270000092600A0000006600000C19260FA (312 bits) Mesg Desc.: Power: On, Mode: 0 (AUTO), Temp: 19C, Fan: 10 (Auto), Swing (V): 14 (Auto), Swing (H): 190 (Auto), Clock: 9:20, On Time: Off, Off Time: Off, Sleep Time: Off, Beep: 3 (Off), Light: 3 (Off), Mold: Off, Clean: On, Fresh Air: Off, Eye: Off, Quiet: Off, Powerful: Off, Sensor: Off, Purify: Off, Econo: Off Library : v2.5.4' All seems correct apart from: Mold Guard is ON - Byte 8, Bit 4 set Intelligent Eye Position Sense is ON - Byte 36 bit 1 set Air Purifier is ON - Byte 36 bit 4 set I'll do further tests on Tuesday / Wednesday, happy to recompile before testing in case there is an error in the code for the 3 functions above

crankyoldgit commented 5 years ago

Can you re-confirm the bit numbering please? In the spreadsheet and here, you state that bit 4 is mold. (starting from bit 0 (LSB)), that's the 5th bit. The example you just listed has 0x28 in byte 8. That's 0b00101000. I think you mean the Bit 3. i.e. 0b00001000 Can you please check the other bit offsets used in the spreadsheet as I've counted on those when doing the code.

sheppy99 commented 5 years ago

You are correct Byte 8 Bit 3 is Mold Guard, NOT bit 4 which I listed. Intelligent Eye Position Sense is Byte 36 bit bit 1, Air Purifier is Byte 36 bit 4. I'll do more testing and work in the "tests" tab of the google sheet tomorrow. One thing I've noticed is it occasionally stops decoding and reports that it has 317 bits rather than 312 bits when its working. It takes a few commands before it works again.

crankyoldgit commented 5 years ago

If you can, please provide a copy of the longer non-decoded message(s) here. i.e. full IRrecvDumpV2 output.

I can't think of any good reason why the ESP stops decoding for a bit then starts working again. Could be hardware/environment related. shrug

sheppy99 commented 5 years ago

EDIT: See additional information at the bottom of the post

I just redownloaded the zip file from the link 2 comments back, recompiled and reuploaded. Using IRDumpV2 the first decode worked, so I turned mold guard ON and it failed to decode. See below

`Timestamp : 000551.659 Encoding : UNKNOWN Code : B8A43CCF (317 bits) Library : v2.5.4

Raw Timing[633]:

uint16_t rawData[633] = {10154, 25050, 3624, 1594, 590, 1150, 590, 278, 586, 282, 584, 284, 586, 1150, 586, 286, 584, 288, 582, 284, 582, 288, 584, 1154, 582, 288, 584, 1158, 582, 1156, 582, 286, 582, 1154, 584, 1158, 582, 1154, 582, 1156, 582, 1156, 584, 286, 582, 288, 580, 1156, 584, 286, 580, 290, 580, 288, 578, 292, 578, 292, 578, 292, 576, 290, 576, 294, 574, 296, 572, 296, 572, 1168, 574, 294, 572, 296, 572, 298, 570, 302, 568, 300, 568, 302, 566, 302, 568, 1172, 566, 1168, 570, 1168, 570, 294, 572, 1164, 572, 1166, 574, 292, 574, 1162, 574, 294, 572, 1166, 574, 296, 572, 298, 572, 296, 570, 300, 568, 1170, 568, 300, 570, 300, 568, 302, 566, 302, 566, 306, 564, 1176, 564, 1172, 564, 1166, 570, 1166, 572, 298, 570, 298, 568, 300, 566, 1170, 570, 300, 566, 1168, 570, 300, 568, 302, 568, 300, 568, 302, 564, 1174, 566, 1172, 568, 296, 570, 300, 566, 300, 568, 306, 564, 304, 562, 306, 564, 304, 562, 308, 562, 308, 562, 306, 560, 312, 558, 1180, 560, 310, 560, 310, 560, 1180, 560, 306, 562, 308, 558, 308, 560, 312, 558, 310, 558, 310, 558, 314, 556, 312, 554, 316, 552, 1186, 554, 1182, 558, 308, 558, 1182, 560, 308, 558, 1180, 562, 1176, 560, 306, 564, 1174, 564, 304, 566, 302, 564, 306, 562, 308, 560, 310, 560, 1182, 560, 302, 564, 306, 568, 1174, 564, 308, 562, 306, 562, 306, 558, 310, 560, 312, 558, 310, 556, 312, 556, 316, 554, 312, 556, 314, 552, 318, 554, 312, 554, 316, 552, 320, 552, 320, 546, 322, 548, 324, 546, 318, 548, 322, 548, 1188, 550, 1186, 554, 1184, 554, 1184, 556, 1178, 562, 308, 560, 1182, 560, 306, 560, 1178, 562, 1172, 564, 1172, 568, 300, 566, 304, 564, 1170, 570, 1170, 566, 302, 566, 1172, 566, 300, 568, 1168, 568, 300, 568, 1166, 574, 298, 568, 302, 566, 35032, 3628, 1592, 590, 1146, 592, 282, 586, 280, 586, 284, 586, 1150, 588, 284, 588, 284, 584, 284, 584, 282, 584, 1156, 584, 284, 584, 1158, 582, 1152, 582, 284, 584, 1154, 582, 1154, 584, 1154, 584, 1154, 584, 1152, 586, 280, 584, 286, 582, 1158, 584, 284, 580, 288, 580, 288, 578, 290, 578, 292, 578, 288, 578, 292, 574, 294, 576, 294, 574, 294, 574, 296, 574, 298, 570, 296, 572, 300, 570, 300, 568, 302, 564, 304, 566, 304, 564, 1174, 566, 302, 564, 302, 564, 1170, 568, 1170, 570, 1170, 570, 300, 570, 296, 570, 304, 566, 1172, 568, 1168, 572, 296, 570, 298, 568, 1172, 570, 298, 568, 300, 568, 302, 566, 304, 566, 302, 566, 304, 566, 308, 560, 304, 564, 306, 560, 308, 558, 310, 560, 308, 560, 310, 558, 314, 556, 312, 556, 1184, 558, 312, 554, 1182, 558, 310, 558, 310, 558, 310, 558, 314, 556, 310, 558, 314, 554, 314, 554, 312, 554, 318, 554, 314, 554, 318, 550, 316, 550, 320, 548, 322, 548, 320, 548, 316, 550, 322, 546, 1188, 552, 1184, 554, 316, 552, 316, 552, 316, 552, 318, 552, 320, 550, 320, 546, 320, 548, 326, 544, 322, 546, 324, 544, 1192, 550, 1186, 552, 316, 552, 318, 548, 320, 550, 320, 548, 320, 548, 322, 546, 322, 546, 324, 546, 326, 542, 324, 544, 326, 542, 328, 542, 326, 542, 330, 540, 330, 540, 326, 542, 330, 540, 1198, 540, 328, 542, 328, 540, 328, 540, 330, 538, 332, 538, 1200, 542, 1194, 544, 326, 544, 1194, 546, 322, 546, 326, 542, 1196, 546, 320, 548, 324, 544, 1192, 548, 320, 546, 320, 546, 322, 546, 324, 546, 326, 542, 1198, 546, 1190, 550, 320, 546, 318, 550, 1192, 548, 320, 548, 1188, 554, 314, 552, 1190, 552, 314, 552, 314, 552}; // UNKNOWN B8A43CCF`

The second command which was Off worked, flicking it back on with the cooling button worked, and toggling Mold Guard OFF and ON again worked. I'll now revise the test sheet with the results

EDIT: after posting this I noticed the odd random set of IR appearing but after moving it to a quieter location the errors continued without the false commands being received, tweaking the timings to be more like the raw data hasn't helped either. Judging by my results with the AC unit I'd say the IR transmission isn't as robust as my Fujitsu was, and it only became reliable after I changed to a stick on IR emitter.

sheppy99 commented 5 years ago

All tests completed, only powerful and econo mode don't work. I need to work on decoding the remaining bytes, including how the one off timers compare to the daily timers which I'll do as time allows. I'm back working outside tomorrow which should take most of the week, after that's done I'll do further decoding. Thanks for your work, we've made a lot of progress

crankyoldgit commented 5 years ago

@sheppy99 I've added another commit which fixes the Econo setting and changes fresh air "low" to "on". I couldn't find any issue at all with Powerful & Mold. The powerful data you provided behaves exactly as expected.

Please download the daikin2-deep branch and try it out: https://github.com/markszabo/IRremoteESP8266/tree/daikin2-deep

Regarding the UNKNOWN raw data above, yes, the timings are different. Notably the average timings for that sample are:

BitMark = 563;  // Current is 418
OneSpace = 1172;  // Current is 1315
ZeroSpace = 306;  // Current is 451

Those are quite a bit different.

If the issues of failed send/decoding persists, I think we need to do some extensive re-sampling/averaging of multiple remote captures done in optimal environmental conditions. e.g. A couple of meters away, in a cool env. without any sunlight etc. i.e. no strong heat (IR) sources.

sheppy99 commented 5 years ago

Thanks, later in the week, or earlier if it gets too hot to work outside I’ll give it a test and also change the timings to see if that helps. I’ll also double check the powerful bit

sheppy99 commented 5 years ago

The last changes fixed Econo Mode, and Powerful is also working. The decoding errors are still present most of the time when changing Econo / Quiet mode which is on the same button. Will do further decoding and analysis when I get time. A quick look at the raw timings suggests there could be 2 extra bits appearing, and as I'm sending the same codes I'll see if I can work out which ones to see if there is a pattern,

crankyoldgit commented 5 years ago

FYI: You can't trust the "bit" size when the message is reported as UNKNOWN. It's basically counting the pairs of mark+space as bits when it encounters a message it doesn't know. Not actual data bits.

sheppy99 commented 5 years ago

I’ll do the comparison using raw timings to make sure - from memory one of them had at least 1 extra bit so I’ll do it all in a spreadsheet with the remote clock not set so I can work out if there’s a pattern to it. Fortunately this remote seems to send the same command out if I press the currently selected mode button

sheppy99 commented 5 years ago

I've just had a quick look at the unknown decoding issue, how much does the raw timing have to be out before it considers a bit to be invalid? For example if a one is set at 500 and a zero is set at 1800 how far away from these values are they before they are considered corrupt?

crankyoldgit commented 5 years ago

Typically there is a ~25% tolerance. (See https://github.com/markszabo/IRremoteESP8266/blob/master/src/IRrecv.h#L35) and +50us extra for Marks and -50us for Spaces (see https://github.com/markszabo/IRremoteESP8266/blob/master/src/IRrecv.h#L24) e.g. The "306" average from the recent data of a "one" is just out of range. We can change them on a per-protocol basis if needed.

sheppy99 commented 5 years ago

OK, I'll see how it behaves after tweaking the timings. I'll also work on finalising the rest of the bytes. Still got a heap of work to do outside so it won't be straight away. Is there an easy way of using the work we've done so far via IR MQTT Server? Currently I send one of 3 IR strings and use the WiFi APi for the rest, but this locks me out of a lot of the IR only advanced modes without having an IR string for everything. I could work out a convoluted OpenHAB rule to add the current time to a set of preconfigured strings and then somehow work out the checksum but I'm guessing there is an easier way using the ESP to do the heavy protocol lifting?

crankyoldgit commented 5 years ago

If you are asking "Is there a way I can set/send individual settings for Daikin2 etc via IRMQTTServer?". The answer is no. There isn't a way at present. I've thought about it before, and even tried to code a universal solution for the AC units, and there isn't any easy way at present. i.e. I gave up as I didn't really need it myself. It's really out-of-scope for the library. It's more a case of, "yes, you can totally create a project and write one yourself using the library.". In fact, some external projects have done just that. e.g. EasyESP and Tasmota.

One of the issues is all the A/C settings are different model to model and vendor to vendor. About the only thing common to ALL of them is Cool/Heat/Fan/Dry mode, temp, and a fan speed. Even having a reliable On/Off setting isn't common. :-( Supporting operations/settings beyond that is a huge amount of work as it has to be custom for each model. Writing a one-program-does-all is a lot of work, and then people want it to support OpenHab/Home Assistant/NodeRed/JSON/plain http/MQTT//etc. It's more work than I alone have time for.

FYI/Background: IRMQTTServer evolved out of code I wrote to handle my personal needs interfacing with Home Assistant. I prettied it up, and made it available to handle pretty much every protocol. I don't futz around with my A/C settings at all. I basically set it to a single "on" mode that works for my env. and an "off". e.g. "Okay Google, Turn on the Air Conditioner". I don't personally need to tell it to set it to XX degrees and a fan speed of Y, and swing mode of Z", hence IRMQTTServer doesn't support it. Feel free to add it though. ;-)

sheppy99 commented 5 years ago

That all makes sense. I’ll work on decoding the rest of the bytes for completeness and then investigate Tasmota and ESPEasy which I already use but not for IR. it may make more sense given my interest in advanced modes and timers to put the work into getting OpenHAB to do the checksum and time calculations in hex and then send it out that way. In my situation the AC is on the other side of the room to the sensor so I get better results by changing the set temperature depending on what I want it to do rather than turning it on and leaving it

sheppy99 commented 5 years ago

Thinking about this again, is there a way of getting your library to take a hex string in and add in the headers and checksums before sending the result? That way whatever software is being used sets the raw codes and what we’ve been working on adds in what’s needed to make it work. Further research suggests that OpenHAB doesn't work well with hex, so getting it to work out the checksum is quite a mission

crankyoldgit commented 5 years ago

Yes, that it can do. e.g.

IRDaikin2 ac(IR_TX_PIN_YOU_WANT);
ac.begin();
ac.setRaw(array_with_the_daikin2_code_in_it);  // Set the IRDaikin2 object with your hex code with a bad checksum etc.
ac.send();  // Will calculate the checksum for array_with_the_daikin2_code_in_it and send it.

You'll need to convert your String into the uint8_t[39] array before calling setRaw(). However there is code to do that in IRMQTTServer that you can use as it does/needs that. e.g. the array is the same as used by sendDaikin2() etc.

Edit: Added the call to .begin();

sheppy99 commented 5 years ago

Thanks I’ll experiment the next time its raining

sheppy99 commented 5 years ago

Will it recalculate the 2 checksums with this command over mqtt? Presumably the 53 tells it to use the Daikin2 settings

ir_server/send/53,11DA270001D082F0280C8004B016240000BEDE9311DA270000382400A0000006600000C1906025

Recreating that with my wanted options without the checksum is relatively trivial as its just a simple string followed by an MQTT publish command