NetHomePlus cloud's get_token is no longer functional

[mill1000]

Originally reported here: mill1000/midea-ac-py#482

It appears the NetHomePlus cloud's get_token has shutdown or is broken.

Related #288

[marianogoldman]

Data point: getToken is dead on the legacy backend for owner accounts too, and it isn't the ID mismatch

Ruling out a few hypotheses from this thread with measurements from an account that owns the devices (4× 0xAC V3, Surrey-branded OEM, Argentina).

1. The rest of the legacy API is healthy — only getToken is gone. On mapp.appsmb.com, /v1/user/login/id/get, /v1/user/login and /v1/appliance/user/list/get all respond correctly and list all four appliances. Only /v1/iot/secure/getToken returns 9999 system error. So this is not an auth or account problem.

2. It fails on both app_ids that share that backend. Also tested app_id 1117 (Midea Air, app key ff0cf6f5f0c3471de36341cab3f7a9af) by subclassing NetHomePlusCloud and overriding APP_ID + _Security.APP_KEY. Same 9999. Since both are the same server, adding 1117 to msmart wouldn't help.

3. The ID mismatch doesn't explain the 9999. Tried applianceCodes absent, with the LAN device ID, and with each of the four cloud appliance IDs from appliance/user/list/get; udpid in both endians; regions US/DE/KR. All 9999. In this account the cloud appliance ID is identical to the LAN device ID, so @mabelisle's case can't be the cause here.

4. The 1010 migration path works, including for a non-Midea-branded OEM unit. Paired the device directly in the SmartHome app under a fresh account and got a valid token/key immediately, confirming @douflou's result. Worth recording that the brand not being in the app's supported-brands list was not an obstacle.

5. One caveat for the discovery rewrite: the first cloud success can be the wrong one. getToken returned a token/key pair for the little-endian udpid, and the device rejected it with Error packet received. Big endian worked. So looping over endians and accepting the first pair the cloud returns isn't enough — the current _authenticate_device already validates with a real authenticate(), and that property is worth keeping in whatever replaces it, since the cloud will hand you a plausible-looking pair for the wrong udpid.