Slow trickle of MQTT messages

[tris]

Something appears to have changed around July 16-17 which slowed the usual 1+ message/second from MQTT to a trickle of 0.2/sec. (See also #64, #67, and my stopgap solution in #69.)

Interestingly, upon opening the Android or iOS EcoFlow apps, the usual flood of messages returns to all MQTT clients. So, the theory goes, the official clients are doing something that we're not. What is it?

1. The app connects with a more extensive client ID string: iOS_{uuid}_{user_id}_{hex_32bytes}_{timestamp_millis}_{HEX_32BYTES} (or ANDROID_ -- same pattern).
2. The iOS app subscribes to at least /app/{user_id}/2/biz/data/response, /app/{user_id}/+/thing/property/get_reply, /app/{user_id}/biz/data/response, /app/{user_id}/{device_sn}/thing/property/get_reply (redundant).
3. The Android app subscribes to at least /app/device/status/{device_sn}, /app/device/progress/{device_sn}, /app/device/property/{device_sn} (we only subscribe to property).
4. Upon connect, the app publishes "operateType":"latestQuotas" to /app/{user_id}/{device_sn}/thing/property/get, and receives a response on /app/{user_id}/{device_sn}/thing/property/get_reply.
5. Every 20 seconds, the app publishes "operateType":"getAllTaskCfg" and "operateType":"setRtcTime" to /app/{user_id}/{device_sn}/thing/property/set, and receives responses to these operations on /app/{user_id}/{device_sn}/thing/property/set_reply.

I've tried mimicking 2 through 5, with limited success -- I do get a response to setRtcTime, but I don't get a response to latestQuotas or getAllTaskCfg -- and the rate of messages to the property topic remains unchanged.

The only thing left is the client ID. I tried generating some random hex strings to make ours fit the same format, but the broker refuses authorization. So... if someone could figure out what those need to be, maybe we'll be back in business.

Note that we had to tweak the client ID once already last year (in #26).

[grubjack]

After update the firmware to v3.1.3.08, often receive zero metrics