IRForum

It is likely that the other library is using a different bit order/byte boundary.

the signal is 67 data bits - so it is not clear where the first byte boundary should start.

yes, it seems to work differently but it shows me correctly on serial port the temperature, mode and fan setted starting from the code received from my remote so I can assure that it is working very well. At the start of the application, it asks for a "mode". The correct one for GREE is 4.
I think could be a good idea to see into the code of this library in order to undestand better.
Let's keep in touch

If you select the LSB format from the Power-tools menu, you will get a more similar format - but in reverse. Let me know.

I just checked the code and we use use a particular bit layout when there are an unever number of bits - as it is impossible to second guess the original developers.

Hopefully the existing LSB format will be better??

For Reference only:

The LSB8 format will not work for signals which dont have bit lengths that are not multiples of 8.
In these cases users should use only MSB and LSB formats and calculate the checksum manually using bits instead of Hex bytes/nibbles.

It's possible to me to create a custom protocol, modifying parameters shown in the attached image?
I ask it because seems that some parameters have to be different :
PAUSE SPACE: 20460
HEADER MARK: 9300
HEADER SPACE: 4520
BIT MARK: 660
ZERO SPACE: 470
ONE SPACE: 1605
MARK_THRESHOLD_BIT_HEADER = 2000;
SPACE_THRESHOLD_ZERO_ONE = 800;
SPACE_THRESHOLD_ONE_HEADER = 2400;
SPACE_THRESHOLD_HEADER_PAUSE = 8000;

other information:

GREE Protocol specification: https://forum.mysensors.org/uploads/fil ... 0-gree.pdf
I saw that this specification are valid for LSB reading bits from the right to the left.

GREE Library working for a lot of people (from feedback): https://github.com/dpressle/MySensors/b ... t/Test.ino
I will test it in the weekend.

I hope them could help to improve AnalysIR in order to have another protocol to decode.

@ruirem

Thanks to the spec you linked, I have now managed to cater for the Gree protocol in AnalysIR. I will send you a new configuration to replace the current Gree one.

Using LSB8 you will now get the values as expected. I cross referenced some fields them against the doc you posted and they seem to match. I havent verified every field.

I cannot include the checksum calculation in AnalysIR as it is proprietary to this protocol only and not reusable.

Thanks again for your input on this.

I'm happy to write that with your new settings I'm able to command my AC!!!
Thank you!!!

In order to make clearer the situation, I understood that exists two kind of protocol GREE:

1- the one of my ACs that accept the codes with the settings you sent me (GREE32_64AC)
2- the one included on AnalysIR (GREE32_67AC)

The purchase of AnalysIR has been the best software purchase in my life!!! And your support is very incredible!

Thank you very much!

From what I see there is only one protocol.

GREE32_64AC

In this there is one signal which only has 32 data bits and another that has 64 data bits.


The difference between the 64 & 67, is the 3 bits that are always fixed. So for AnalysIR, we treat these 3 bits as special Trailers/Header (Or lead out) - this allows us to get a multiple of 8 data bits, which mean that the Reverse engineering tool can now be used effectively. It oals means it can be automatically decoded using our internal signal syntax.

Thanks for your input in resolving what was one of the most difficult AC protocols to crack.