-
Notifications
You must be signed in to change notification settings - Fork 836
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help decoding Hitachi PC-LH3B #1060
Comments
Looking at your spreadsheet, it looks like the bit order needs to be switched. I worked that out from your temperature range data. i.e. https://docs.google.com/spreadsheets/d/1x82Cb3-GtOMM5oTVOFdNY9mqwLnJ-qElhOj8MId7mrA/edit#gid=0&range=Q6:Q18 For starters, lets get the basic(simple) sending/decoding of a message working. |
Here is the rawData for POWER OFF AND here for POWER ON 30C LOUVER 1 MODE HEAT |
Thanks. I'll knock up something to handle the basic part of the protocol in a few. |
* Supports Hitachi PC-LH3B * Add send & decode routines. * Update ancillary support routines. * Add synthetic and real unit test cases. For #1060
@MinePlugins Can you please download & test this branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/hitachi_PC-LH3B It should decode your remote and covert it to a 23-byte array/hex code, Hopefully with the bits in the correct order (LSB). e.g. The byte containing the temp should noticeably increase linearly. If it does, you can update your spreadsheet to use that data. It might some things easier to decode etc. |
Thank's I'll try soon !! |
This is when I use the new protocol but when I change temp on remote rawData protocol is not found: |
Interesting. The "UNKNOWN" one is significantly shorter. I'll try to work out how best to handle it. |
I've updated that branch to hopefully handle the shorter (136 bit / 17 byte) version. |
I updated the google sheet, now temp grow with constant and temp is temp on remote - 7 When I change Mode 👍 |
Wow. This is going to get very messy at this rate. This is yet another size/length. Can you please test/capture different operations on the remote and report (Inc raw data) for any different bit lengths you find. Rather than me adding them one by one. I may need to rethink how we try to manage this protocol. This is certainly in bizarre territory now. |
|
Thanks for that. I think that's a record. I've never come across an A/C remote which produces 5 distinct different length codes. I'll try to work something out soon. I think I'm going to have to rename the protocol, removing "184" from it as it clearly doesn't use that bit length all the time. Do you know what buttons/actions those three raw data entries correspond to per chance? |
1 = cancel timer |
Thanks. I'll try to get to it soon. |
* Rename the protocol as bit size isn't constant. * Support all known state/bit sizes thus captured. * Add unit test cases For #1060
@MinePlugins Can you please download and test the latest version in that branch? I think I've covered all the different sizes of messages you've reported. Also, I think I've worked out the checksum alg. for this protocol. Can you confirm that in your findings? |
* very basic IRHitachiAc3 class added. * Enough code to verify the checksum/integry check for the protocol. * Add integrity check to `decodeHitachiAc3()` * Fix up some incorrect comments. For #1060
Branch updated to add the integrity checks. |
Hello due to the Corona virus a don't have the remote so I have only the data in sheet to work with, thanks you a lot |
And yes it's what I'm finding |
Understood. Be safe. Update us when you can. |
* Supports Hitachi PC-LH3B * Add send & decode routines. - Support all known state/bit sizes captured so far. * Update ancillary support routines. * Add synthetic and real unit test cases. * very basic IRHitachiAc3 class added. - Enough code to verify the checksum/integrity check for the protocol. - Add integrity check to `decodeHitachiAc3()` For #1060
Just a friendly ping to see if you've been able to get access to the remote yet. |
No, no for the moment the remote is in a local that been closed until coronavirus end... |
As the PR to add support has been merged, I'm going to mark this closed for now. The virus will be with us for many months it seems. When you eventually get around to it, please give it a test and let me know. You can still update this issue and I'll see it. Or create a new one. |
No problem sir |
Good luck with Covid-19 in your corner of the world |
_v2.7.5 (20200409)_ **[Features]** - Detailed support for `HITACHI_AC1` protocol. (#1056, #1061, #1072) - update sharp to match Sharp AH-A5SAY (#1074) - Experimental support for AIRWELL protocol. (#1069, #1070) - SamsungAC: Add Breeze (Aka WindFree) control (#1062, #1071) - Support for Daikin FFN-C A/C (#1064, #1065) - Add basic support for HITACHI_AC3 protocol. (#1060, #1063) - Add support for `SYMPHONY` 11 bit protocol. (#1057, #1058) - IRMQTTServer: Improve Home-Assistant discovery by sending a 'device' with the discovery packet (#1055) **[Misc]** - Clean up support status of various protocols. - Add `decodeToState()` unit tests to all supported protocols (#1067, #1068) - Add Gree AC example code. (#1066)
_v2.7.5 (20200409)_ **[Features]** - Detailed support for `HITACHI_AC1` protocol. (#1056, #1061, #1072) - update sharp to match Sharp AH-A5SAY (#1074) - Experimental support for AIRWELL protocol. (#1069, #1070) - SamsungAC: Add Breeze (Aka WindFree) control (#1062, #1071) - Support for Daikin FFN-C A/C (#1064, #1065) - Add basic support for HITACHI_AC3 protocol. (#1060, #1063) - Add support for `SYMPHONY` 11 bit protocol. (#1057, #1058) - IRMQTTServer: Improve Home-Assistant discovery by sending a 'device' with the discovery packet (#1055) **[Misc]** - Clean up support status of various protocols. - Add `decodeToState()` unit tests to all supported protocols (#1067, #1068) - Add Gree AC example code. (#1066)
FYI, This has been included in the new v2.7.5 release of the library. |
Hi, I'm back, I have the remote ! |
Congrats. Try the latest version of the library. It should send & decode the hex values. When you've worked out how the functions map to the codes and collected the data etc, you can create a new issue and we can work on adding detailed support for it, together. |
Thank's I will do that the next week. |
Hello, I attemp to decode the IR of my remote for the A/C with PC-LH3B remote,
I created a Google Sheet like recommended and user Auto_analyse_raw_data.py:
`Found 275 timing entries.
Potential Mark Candidates:
[3396, 516]
Potential Space Candidates:
[1660, 1268, 428]
Guessing encoding type:
Looks like it uses space encoding. Yay!
Guessing key value:
kHdrMark = 3396
kHdrSpace = 1660
kBitMark = 476
kOneSpace = 1236
kZeroSpace = 395
Decoding protocol based on analysis so far:
kHdrMark+kHdrSpace+1000000000001000000000000000001011111101111111110000000011000111001110001001000101101110000100001110111111111100000000111011010001001011
Bits: 136`
Can I have some help or explaination for this protocole
The text was updated successfully, but these errors were encountered: