Unknown message types 0x45/0x2b

[aplund]

I get these known message type errors, but the integration generally seems to work. They tend to repeat periodically. I'm using the version tagged v0.2.6

Traceback (most recent call last):
  File "/var/lib/hass/.venv/lib/python3.11/site-packages/airtouch2/protocol/at2plus/control_status_common.py", line 74, in from_bytes
    subtype = ControlStatusSubType(subheader_bytes[0])
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/enum.py", line 712, in __call__
    return cls.__new__(cls, value)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/enum.py", line 1135, in __new__
    raise ve_exc
ValueError: 69 is not a valid ControlStatusSubType
2024-01-02 15:45:49.876 WARNING (MainThread) [airtouch2.at2plus.At2PlusClient] Unknown status message type: subtype=0, data=45:00:00:34:00:00:00:00:41:43:34:38:00:00:00:00:00:00:00:00:00:00:00:00:18:00:00:00:23:0c:00:00:00:00:00:00:00:00:00:00:41:74:63:68:32:50:4d:00:36:17:22:48:22:00:22:02:00:00:00:00
2024-01-02 15:45:51.700 WARNING (MainThread) [airtouch2.protocol.at2plus.control_status_common] Unknown message type in header (0x2b)
Traceback (most recent call last):
  File "/var/lib/hass/.venv/lib/python3.11/site-packages/airtouch2/protocol/at2plus/control_status_common.py", line 74, in from_bytes
    subtype = ControlStatusSubType(subheader_bytes[0])
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/enum.py", line 712, in __call__
    return cls.__new__(cls, value)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/enum.py", line 1135, in __new__
    raise ve_exc
ValueError: 43 is not a valid ControlStatusSubType
2024-01-02 15:45:51.708 WARNING (MainThread) [airtouch2.at2plus.At2PlusClient] Unknown status message type: subtype=0, data=2b:00:00:00:00:04:00:06:80:80:07:ff:81:81:07:ff:82:82:07:ff:83:83:07:ff:90:ff:02:f1:91:ff:07:ff```

[nathanvdh]

Yeah it's expected, you have some newer version of the protocol with messages that I don't have documentation for. I didn't want to silently ignore them. I'm not going to reverse engineer the airtouch2+ protocol / work out what they are, as I don't have a 2+ system and have no motivation. I will leave this issue open in case someone else ever wants to try and work stuff like this out.

If anyone is missing a feature they would like then I am happy to help get it working.

[aramshaw]

@nathanvdh - I'm happy to look into this. Are you able to let me know where to start to reverse engineer the airtouch2+ protocol / work out what they are. Can you point me to any online docs?

I should say I was about to provide exactly the same error message.

[nathanvdh]

@aramshaw you need to find out what causes the message to be sent (is it periodic, does it happen when something changes, what change triggers the message to be sent), that will give you the first clue about what the message is. Then you need to work out what the contents of the message are, you basically want to dump the contents every time you receive it (you can see the contents printed as hex in the log message above) and see what has changed between each message, and whether you did something to cause that change. vbindiff is a good simple TUI interface for doing diffs on binary files, ImHex is a more powerful GUI tool.

E.g. if you were reverse engineering a message that contained the aircon's set temperature, it would probably be sent every time you change the set temperature, and if you increased the temperature by 1 degree you would probably see a value in the messsage contents go up by 1.

[aramshaw]

@nathanvdh - this is a bit more than I was expecting - hex decoding!

Let me have a look and see what I can do but no promises it's a bit above my pay grade.

[nathanvdh]

Yeah reverse engineering is a pretty difficult task. There was a specification document that I was working from (posted in this thread https://community.home-assistant.io/t/airtouch-2-plus/263744) for airtouch2+ but this message wasn't in it... Hence why it's not implemented. I don't even have an airtouch2+ system so I couldn't even reverse engineer it myself if I wanted to.

Maybe the fact that it's something that's NOT in that documentation will be a hint to what it is? But who knows... maybe there's similar state in a different message.

[gavintweedie]

Version 0.2.10
I've found a bit of a pattern with this error. I've noticed my aircon seemingly not cooling as well, but everything looks fine.

Then I notice on the temp graph for the airtouch that it hasn't changed for hours, too level... and it corresponds with a change in the 0x2b errors. The 0x2b errors are periodic, normally every 30seconds but occasionally a minute apart. Some form of keepalive perhaps?

Happy to grab more captures or try and provide information that might help identify what it is.

For example,

2025-03-25 16:21:19.130 WARNING (MainThread) [airtouch2.protocol.at2plus.control_status_common] Unknown message type in header (0x2b)
2025-03-25 16:21:19.131 WARNING (MainThread) [airtouch2.at2plus.At2PlusClient] Unknown status message type: subtype=0, data=2b:00:00:00:00:04:00:06:80:80:07:ff:81:81:07:ff:82:82:07:ff:83:83:07:ff:90:ff:02:dc:91:ff:07:ff
2025-03-25 16:21:49.276 WARNING (MainThread) [airtouch2.protocol.at2plus.control_status_common] Unknown message type in header (0x2b)
2025-03-25 16:21:49.277 WARNING (MainThread) [airtouch2.at2plus.At2PlusClient] Unknown status message type: subtype=0, data=2b:00:00:00:00:04:00:06:80:80:07:ff:81:81:07:ff:82:82:07:ff:83:83:07:ff:90:ff:02:dd:91:ff:07:ff
2025-03-25 16:23:49.614 WARNING (MainThread) [airtouch2.protocol.at2plus.control_status_common] Unknown message type in header (0x2b)
2025-03-25 16:23:49.615 WARNING (MainThread) [airtouch2.at2plus.At2PlusClient] Unknown status message type: subtype=0, data=2b:00:00:00:00:04:00:06:80:80:07:ff:81:81:07:ff:82:82:07:ff:83:83:07:ff:90:ff:02:dc:91:ff:07:ff
<... no errors ..>
2025-03-25 17:44:28.753 WARNING (MainThread) [airtouch2.common.NetClient] Connection lost, reconnecting
2025-03-25 17:45:34.223 WARNING (MainThread) [airtouch2.protocol.at2plus.control_status_common] Unknown message type in header (0x2b)
2025-03-25 17:45:34.223 WARNING (MainThread) [airtouch2.at2plus.At2PlusClient] Unknown status message type: subtype=0, data=2b:00:00:00:00:04:00:06:80:80:07:ff:81:81:07:ff:82:82:07:ff:83:83:07:ff:90:ff:02:db:91:ff:07:ff
2025-03-25 17:46:04.232 WARNING (MainThread) [airtouch2.protocol.at2plus.control_status_common] Unknown message type in header (0x2b)
2025-03-25 17:46:04.232 WARNING (MainThread) [airtouch2.at2plus.At2PlusClient] Unknown status message type: subtype=0, data=2b:00:00:00:00:04:00:06:80:80:07:ff:81:81:07:ff:82:82:07:ff:83:83:07:ff:90:ff:02:da:91:ff:07:ff

[aramshaw]

@nathanvdh - FYI - am working on this. There are a few new message types I working on de-coding. I also uncovered that when the messages are not handled it can interfere with getting the A/C active.

Unknown message type in header (0x2b) - seems to be the availability of the Favourites - which are basically shortcuts for fan settings across the zones, e.g. night time, day time.

Another new message type is # 0x31 -this is a status for the Favourites - what is active now

[gavintweedie]

@aramshaw how are you progressing with this? I have no favourites setup but still get the 0x2b. Do you have them setup?

[aramshaw]

@gavintweedie - Honestly I did okay but got a bit stuck and haven't closed it out. I was able to get to the 0x2b message structure but I made so many changes to the code to generate de-bug messaging that backing it out to make a clean pull request became too big a task. I'll have another go over the next couple of weeks.

[aramshaw]

@nathanvdh @gavintweedie - I did some more work on this (with substantial assistance from Claude) and seem to have fixed the issue.

(I also just saw this thread: #5 and the spec there. More notes below)

What I Found

• 5 unknown message types (0x2B, 0x31, 0x10, 0x40, 0x27) that seem to require proper acknowledgments
• These messages are not in the spec referenced above.
• Without these ACKs, the controller refuses new connections from both HA and mobile apps
• Complete protocol documentation with working implementation

What I did

I'm a 100% newbie to contributing to public git projects so I forked the original code to a repo on my git account and made the changes to a branch there: https://github.com/aramshaw/airtouch2-python/tree/fix-undocumented-airtouch2%2Bcommands

It includes

• docs on the protocol
• a fix for the unknown message types that I have been running for 48hrs with no new errors.

BTW I tweaked homeassistant-airtouch2plus that I used to be able to edit and update the airtouch2 package locally. Basically I copy the airtouch2 SRC files into a sub-directory of the airtouch2plus custom_compontent so the integration references those instead of the installed.

@nathanvdh - let me know if you want to use this as I just saw the updates on the other thread and I'm not sure how you want it included.

[gavintweedie]

@aramshaw seems you've made some good progress. I'm seeing much less disconnections/unavailabilities with my TCP keepalive changes too, however I did have one today and it lined up with a 0x2b error which I think your changes will solve by acking as required.

I wonder if your changes will negate the need for the keepalives completely. I'm going to run another couple of days with my changes, then I might revert to the your version without keepalives and I'll give you some feedback. I'm running airtouch2+ FYI. Which unit do you have to rest against?

[aramshaw]

@gavintweedie - I think the root cause of unavailability is not ack'ing some message types, especially on first connection. I found in testing that doing the wrong thing would basically stop the Airtouch2+ from communicating at all to either HA or mobile app. In one case I needed to power cycle the controller to get the mobile app working again. My HA-Airtouch2+ connection seems stable now.

Not sure of the question you're asking but this is my Airtouch2+ system details.

Happy to help.

[gavintweedie]

@aramshaw I think you are right. The last ~40hrs I've had no periods of graphs not updating but I do have this logged 4 times recently that wasn't logging before implementing keepalives:

Logger: airtouch2.common.NetClient
Source: runner.py:154
First occurred: July 25, 2025 at 6:58:07 PM (4 occurrences)
Last logged: 1:44:53 AM

Connection lost, reconnecting

I think what's happening is:

1. Failure to Ack by client is causing device to silently lock/drop/ignore all messages on existing TCP sessions.
2. Because the TCP session isn't actually closed in any way, the NetClient side thinks it's still available and keeps sending commands there which get ignored by the device.
3. Keepalives aren't stopping the sessions dropping they are actually discovering that the far end is not replying and dropping the TCP session on the client, causing the client to establish a new TCP session which isn't "locked" from step 1. This also makes sense as I found I could always recover the addon by "reloading" the plugin, which created a new TCP session.

I think 3 is allowing detection of the issue and repair of bad TCP session through reconnect, while 1 is fixing root cause.

I think we should consider both to catch other reasons for TCP sessions breaking (NAT timeouts etc) which should be much more rare than what your fix for this root cause will be. I think I'll submit the keepalive stuff under a different PR not the unknown message ones because the keepalive fix is in NetClient which lives in https://github.com/nathanvdh/airtouch2-python not here

My version is the same as yours, however MHI AC being controlled:

Will fire up your code (without my keepalive addon) today and run it for a few days and let you know how I go.

[aramshaw]

@gavintweedie - I think you're far more experienced at this than I so I'll take your advice.

Note that the branch with my changes is here: https://github.com/aramshaw/airtouch2-python/tree/fix-undocumented-airtouch2%2Bcommands

Not sure how you're handling using the local airtouch2 library instead of pip version but I put it in a sub-directory and use it when the directory exists. See this branch: https://github.com/aramshaw/homeassistant-airtouch2plus/tree/fix-undocumented-commands

Let me know if there is a better way.

I hope I'm doing this correctly.