How to treat Hub devices

[MarkPaxton]

Hello, I didn't want to make this a feature request because I didn't know if it /should/ be a feature or know enough to know if it is a good idea. It is 2 proposals:

1. Represent Hubs and 1st class devices visible in HA with settings:

• "Memory mode" DP which indicates (as far as I know) whether to cache last known values of a subdevice or not
• List of connected devices (and signal strength?) I know this is available via tiny tuya and it would be real benefit to be able to have this data visible somehow
• Ignore "poll only" setting on subdevices, and implement it only for "poll only" on the hub. I think this could be the cause of connection exhaustion/problems on the hubs as in poll mode (prior to pooling) it helped not to maintain a connection, but in the new connection pooling mode, we want to be able to maintain only one connection to the hub and not have subdevices constantly close/reopen it.

Thanks! Do let me know if this could be done?

[make-all]

1. If hubs expose any settings they can be 1st class devices now.
2. These are cloud-only functions, so not relevant to local tuya protocol support
3. The connection handling and config flow need an overhaul to properly support hubs. I don't want to keep applying band aids of treating options specially for subdevices.

[MarkPaxton]

Ok so my hub exposes DPS 38:

  "category": "cz",
        "product_name": "Hombli Smart Bluetooth Bridge USB",
        "product_id": "k4zi8ys4focv0car",
        "biz_type": 0,
        "model": "HBSB-0209",

 "38": {
                "code": "relay_status",
                "type": "Enum",
                "values": {
                    "range": [
                        "off",
                        "on",
                        "memory"
                    ]
                }
            }

Re (3) it's the .subdev_query() method in tinytuya which would be the most useful to integrate when you do the hub overhaul. If there's anything I can do to help, I can do my best. :)