Open cmroche opened 3 years ago
I also have one "Gree" copy or compatible device ("Wilfa Lillehammer 10/9" marketed in Finland) and these are MY LIRC raw-mode decoded values, that i use to control my device.
So i think this is maybe some "new protocol".
HEAT19_fan2_ifeel1: 9064 | 4442 | 708 | 497 | 719 | 487 708 | 1599 | 708 | 1598 | 709 | 500 713 | 1598 | 700 | 503 | 708 | 499 705 | 1602 | 708 | 1596 | 713 | 497 708 | 497 | 710 | 499 | 704 | 500 707 | 500 | 706 | 500 | 705 | 499 683 | 522 | 708 | 498 | 707 | 500 706 | 514 | 693 | 1601 | 706 | 1601 707 | 501 | 705 | 499 | 708 | 499 707 | 499 | 710 | 498 | 707 | 1599 706 | 498 | 707 | 1604 | 706 | 493 714 | 499 | 708 | 1616 | 695 | 498 707 | 19902 | | | |
736 | 498 | 707 | 499 | 707 | 499 709 | 499 | 705 | 499 | 701 | 504 708 | 499 | 706 | 500 | 705 | 499 707 | 499 | 706 | 1600 | 705 | 502 705 | 500 | 713 | 495 | 707 | 1609 700 | 502 | 704 | 494 | 709 | 507 704 | 499 | 708 | 500 | 723 | 483 712 | 495 | 707 | 498 | 702 | 505 707 | 499 | 706 | 499 | 706 | 500 706 | 498 | 714 | 1591 | 704 | 505 707 | 1600 | 708 | 1608 | 702 | 199379
6087 | 2935 | 706 | 497 | 709 | 499 707 | 499 | 708 | 1600 | 707 | 1600 706 | 493 | 712 | 499 | 707 | 499 708 | 1601 | 709 | 500 | 706 | 1593 714 | 497 | 708 | 498 | 707 | 1604 707 | 498 | 707 | 1596 | 712 |
Somewhere(on the internet) i found this value list, Type: Gree35_67AC / Altname: CUSTOM23 / Header: 9000 / HeaderSpace: 4500 / Mark0: 600 / Mark1: 600 / Space0: 600 / Space1: 1690 / Carrier: 38000 / Delta: 200 / Syntax: HB035TB032T,HB035T / Marks: 600,600,9000,600,0,0,0,0 / Spaces: 1690,600,4500,0,0,0,0,0
All other (functions) will work on "default" values, however i can't turn my device OFF, some in this library there is somerthing wrong with that.
Just to clarify, the sequence you posted is coming from your remote right? What is "LIRC decoded values" (I'm not sure what LIRC means in this context).
@Juhani-H Ping ^^
Hi, yes sequence is coming from remote (YAN-?1F1?). Lirc decoded values i mean that these are the raw measured values (no decoding used, only measure time between pulses), device that i used was Raspberry Pi2 + "LIRC"-program lirc.org),
So in my data it shows that values should be around:
Thanks;
I think this explains what is happening. The main message and the IFeel message, even if sent in sequence are acting like two completely different protocols, with their own HDR_MARK and HDR_SPACE timings. If you keep decoding you will notice about every 5 minutes the remote resends a much smaller messages similar to just this, which uses 6000 for HDR_MARK, and 3000 for HDR_SPACE. Trying to use the 9000 and 4000 defaults for this message will cause it not the be readable by the AC.
6087 | 2935 | 706 | 497 | 709 | 499
707 | 499 | 708 | 1600 | 707 | 1600
706 | 493 | 712 | 499 | 707 | 499
708 | 1601 | 709 | 500 | 706 | 1593
714 | 497 | 708 | 498 | 707 | 1604
707 | 498 | 707 | 1596 | 712 |
The default values of 9000 and 4000 will work for the main state message, and align with the values lirc computed for you.
Wow, i just found that your right, last section that my first posted sequence is actually IFeel part.. because if i look without IFeel function, that 6000 ---> part is missing..
Probably my receiver didn't get complete message (IFeel-part), only part of that.. because my all timings that has IFeel ON are like this.. 6088 2929 713 1600 708 500 706 499 717 1586 712 1600 706 499 708 497 709 499 706 1596 713 500 707 1601 707 499 706 499 708 1593 713 498 708 1614 695
Any info about how to decode the IFeel sequence? or where is the CLOCK/TIME signal? (or is it only in REMOTE, so AC doesnt get it).
But still almost all functions are working with default values, but OFF and "WINTER" mode doesn't work.. But if i sent those with Raspberry and IR-led those work..
Any clues why it wont work..?
name OFF
9055 4446 679 536 694 500
709 1601 705 505 705 497
706 498 707 498 707 544
678 1585 709 497 708 1599
707 499 706 494 715 500
707 513 693 499 708 499
708 499 707 501 702 506
707 499 707 1600 706 500
710 498 706 501 701 505
707 497 708 499 708 1600
701 507 705 1594 715 498
707 500 707 1603 707 499
708 19903
733 503 708 501 706 499
704 502 709 499 706 499
709 497 707 499 708 494
712 498 703 502 707 500
707 526 682 495 710 1604
702 500 717 493 708 499
707 499 708 504 703 500
708 498 680 527 707 499
722 484 706 499 704 507
705 497 708 1597 713 1597
707 1616 692 499 707
and WINTERMODE.. name heat22_talviON 9081 4456 665 524 681 523 707 1600 683 1641 693 493 688 524 707 499 707 499 707 500 707 1601 703 1607 682 524 708 499 682 524 708 498 707 498 701 506 768 439 707 500 705 500 707 500 707 1597 712 1599 707 500 710 497 684 521 709 500 706 499 712 1598 706 500 683 1641 667 524 700 506 706 1599 708 498 708 19909
737 497 707 497 724 483
682 522 707 500 708 494
713 497 708 498 708 500
706 499 706 1596 678 524
682 523 707 514 704 1606
698 499 685 522 705 503
681 524 684 537 692 498
708 500 707 500 707 509
709 488 697 509 707 1608
704 500 682 522 708 493
714 499 682 525 706 199383
6079 2947 706 1596 686 522
707 501 708 1601 706 1601
709 497 682 523 703 495
707 1600 706 499 708 1613
703 498 704 503 705 1612
679 523 709 1614 697
This references work done for #86 . I've been able to make this work in practice using an ESP8266 with an SHT30 temp sensor, pinging the heatpump approx every minute to update the temperature.
In doing this though I actually couldn't get it to work with the default provided timings.
Using IRrecvDumpV3 I did a differential comparison of the raw results from the YAC1FBF remote, and a test rig I built using arduino-heatpump to transmit (basically transmitting and demodulating on 1 halves of a breadboard). The results showed notably different timing resutls.
This is from the YAC1FBF remote
But using arduino-heatpumpir I am getting these results (the results are highly repeatable over many samples, also ignore the JVC decoding, we're only interested in the RAW output):
It's a big discrepency in kHdrMark and kHdrSPace between both samples.
When I make this change though to arduino-heatpumpir to more closely match my remote it suddenly started working.
Old timings:
This is what I am using now:
However I only have 1 specific Gree device, so I'm wondering if this represents a change in Gree timing perhaps requiring us to treat this like a whole new protocol, or if the Gree timings are just wrong.