-
Notifications
You must be signed in to change notification settings - Fork 1
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
Command ordering #2
Comments
Hi @Sentient2k7 Yes, you are right I will fix the CRC algorithm in the documents. Documentation is not complete I have much more information but don't have time to add everything. Can I ask you what are you trying to implement? And for which device? |
Hi @paveldn I was trying to implement my AC into Home Assistant as it doesn't seem to have a supported integration available. I have a Haier AS35FBBHRA Split-type AC (I think it is from the FLEX series). |
@Sentient2k7 you can use my ESPHome Haier AC integration which will be picked up by Home Asistant automatically. https://esphome.io/components/climate/haier.html I can help you with it in case you need help |
I did take a look at the source for that integration but it appears it will have the same issues I was experiencing. in smartair2_climate.cpp I saw this code: haier_protocol::HaierMessage Smartair2Climate::get_power_message(bool state) { The 0x4D02 and 0x4D03 messages return an error on my device. On a quick read, it appears 0x4D5F is used for sending requests in your integration, but on my device it is just 0x60 I ended up installing PCAPdroid on my phone and capturing the packets between SmartAir2 and the AC to find the correct codes. For now I have a working integration, but if there is any info/testing you would like me to do let me know. |
Hi @Sentient2k7 |
Hello all,
Just wondering if anyone had any information on the order that commands need to be sent?
From what I've gathered it looks like it's possible to connect, receive the initial status messages and then send an 'off' command.
When I try this, I get frametype=3 (invalid command).
If I send an INIT (frametype=73) message, I get a 74 message back - as expected.
If I send a HELLO (frametype=1, 4D01) message, I get a 6 message back - as expected.
but when i send an OFF (frametype=1, 4D03) message, I get a 3 message back - indicating an error.
Sent message is FF FF 0A 00 00 00 00 00 00 01 4D 03 5B
Return message is FF FF 0A 40 00 00 00 00 00 03 00 00 4D E3 E1 - basically nothing useful to understand the error.
One thing I have noticed is that E3 E1 doesnt appear to be correct for CRC16/MODBUS - I'd expect it be 99 E5
Update:
The CRC is calculated with CRC16 (not CRC16/MODBUS) and includes all bytes except Frame Separator (FF FF) and Checksum/CRC on the return messages..
Update 2:
I have now solved the issue above - the off/on commands on my device are not 4D02 and 4D03.
Not sure if its possible to determine a protocol version or similar from any of the messages, but I have now determined that the follow are correct for my device:
Off - FF FF 0C 00 00 00 00 00 00 01 5D 01 00 00 5B
On - FF FF 0C 00 00 00 00 00 00 01 5D 01 00 01 5C
The text was updated successfully, but these errors were encountered: