Open Sentient2k7 opened 2 months ago
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 am now happy that it is working to my satisfaction but the code definitely needs a tidy-up.
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) { if (state) { static haier_protocol::HaierMessage power_on_message(haier_protocol::FrameType::CONTROL, 0x4D02); return power_on_message; } else { static haier_protocol::HaierMessage power_off_message(haier_protocol::FrameType::CONTROL, 0x4D03); return power_off_message; } }
The 0x4D02 and 0x4D03 messages return an error on my device. The correct functions for my model are 0x5D010001 (on) and 0x5D010000 (off).
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. Is there a DEVICE_VERSION or PROTOCOL_VERSION call that might be useful?
Hi @Sentient2k7 Why are you trying to use the smartAir2 version of the protocol? You need to use the hOn protocol. It will do exactly what you need. Here you can see examples of configuration Example of climate configuration for hOn protocol. You can start with a minimum and add more features later.
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