Add support and ACKs for AirTouch2+ modes #16
Conversation
The AirTouch2+ controller requires the CRC checksum to be calculated from the address field to the end of the data payload. The previous implementation used an incorrect offset, resulting in invalid checksums and causing the controller to reject messages and lock out the client. This commit corrects the checksum calculation in `message_common.py` to use the proper starting offset (`CommonMessageOffsets.ADDRESS`). It also adds the `get_data_from_offset` method to the `Buffer` class, which was necessary to support the corrected checksum logic and resolve a subsequent `AttributeError`.
Cleans up ACK handling for several control status message subtypes. - Fixes rate limiting to remove special handling for 0x2B. - Comments out legacy ACK generation code that was found to be unnecessary. - Minor formatting fixes
testing: the ACK handling of 0x45 messages
…handling of Favourite status in the future
Fix undocumented airtouch2+commands
|
Thank you. Just confirming I am alive and have seen this. I'm very preoccupied with other things in my life at the moment. I plan to take a look at this but I don't know when I'll get a chance. My first bit of feedback is - what you have written in the GitHub description is a very nice summary describing that you've added support for 3 new message types. It would be good if this was reflected in the commits - currently there are 16, it would be nice if it was 3 commits, one for each message type, with the commit messages basically what you've written in the GitHub comment text. |
|
"very preoccupied with other things in my life at the moment" - all good mate. I persevered on the PULL request because I committed to @gavintweedie, and myself, to get it done. You would be shocked, and saddened, if you knew how long it took me to add these few measly lines to your excellent base code. Lots of learning, false turns, restarts. It was not a direct sequence of steps from start to finish and the commits were really just my way of backing up what seemed like progress at the time. I think if you look at the changes in my pull request it will be clear what was done, and not too much to review. I'd do what you asked (3 x commit) if I was better at Git than I am. Sorry. (Sure glad I don't get paid by the line of code.) |
|
Hi, I've taken a look. Can you clarify for me which messages need a response (ack)? I find it very strange that you would need to put something other than 0x80 or 0x90 into the first byte of the top-level Message Header's 'Address' field. It's even stranger to me that this would only be for 2 of the several new message types you describe. You say it needs to be 0xC0 - the identifer for control/status messages - but this is already present in a later field in the header, so that seems redundant to me. Have you intercepted traffic between the mobile app the server to see exactly what their official app is responding with? I was using pcapdroid to do this. Another special-case you have is that the 0x10 ack requires a 2-byte payload but all the others only 1-byte. Seems odd - why should that message be special? Does it really not work if you only send a 1-byte empty payload, the same as the others? My initial approach is going to be to make the smallest possible change that stops the server from abandoning us, like it seems to if we don't respond. So I'm just going to hard-code a list of message types that require acking and ack them, even if there's no decode/encode support for them. If the new message types actually provide functionality that you want, we can add that later. |
|
Hi @nathanvdh - sorry - I did mention at the outset that this sort of comms was (way) above my paygrade and I did use a fair bit of AI support so doubtless there is some AI slop in there. But the code has been working well on my system for a couple of weeks now. I have additional change for a broadcast message that I have not submitted a PULL for (0x27). To your specific questions;
It's your code base and I defer to you in all things in it. (I'm on vacation to the end of Sep and don't have access to my dev system so am limited in my ability to review details.) |
|
Hi, I've pushed a commit to the There's a test in tests/protocol/at2plus/messages/test_ack.py that demonstrates what bytes I'm sending, and shows how it's the same for all messages. Run all the tests, including this one, with I see in your code there's a cooldown for sending repeat acks - why are you doing that? How have you decided what's required? How do you even know these 'acks' are required? Did you try just sending one of the control messages or the status request message repeatedly to see if that keeps the keeps the server from ignoring us? I've read back through some of the discussion in other issues and never found your reasoning behind why you thought messages need acking, nor how you then found which specific ones needed it. |
|
@nathanvdh I've removed @aramshaw repo and reset things back to yours, and manually adjusted airtouch2-python with your changes. Will report back if it fixes the core issues here (server ignoring client / dropouts). |
|
Ok thanks, I expect there will be issues given I've ignored a lot of what aramshaw said... But who knows. |
|
Had a 0x27 unknown already, which is expected since this change is just sorting the acking. Hasn't caused a dropout however which is good. Usually see a dropout within a few hours of switching off for the evening, so will report back in the morning. |
|
That's fine 0x27 doesn't need acknowledgement according to aramshaw, so I deliberately haven't handled it yet. |
|
Morning update. Temps continued to update overnight which they didn't use to, so that's an improvement. However connection was lost. Logs below. 20:29:55 Turned off (from heating) turned off triggered by action Climate: Set HVAC mode Temp updated overnight, at 6:55 attemped to turn on via home-assistant, no response even after multiple attempts. Woke touchpad and turned on, and able to adjust temp etc remotely now via home-assistant.
|
|
Multiple disconnects today, had the touchpad stop responding once too which hasn't happened before. Reboot fixed it.
|
3 participants
0x2B - Extended Status - System status including available favorites, timers, and system counters.
0x31 - Favorite Status - Provides the names of all configured favorite scenes and indicates which one is currently active. This message is sent when the active favorite changes.
0x45 - System Identity Broadcast - Broadcasts system identity information. The payload contains the string "Polyaire Atch2PM", likely identifying the manufacturer and "AirTouch 2 Plus Module". This message appears to be sent periodically (e.g., every ~24 hours).