Request help for writing configs for custom devices

[Artjosh]

Hello, i need to make tuya-local work with more than 20 custom devices made by a company that im working with, all devices powered by tuya....
So im trying all by my self to soon pull request them to this integration.
Lets talk about the first one:

"active_time": 1695069031,
"biz_type": 0,
"category": "gykzq",
"create_time": 1694436899,
"icon": "smart/icon/bay1631708374715LSoc/1f2c8e46535aa3d5675c71ebc0bd12bb.png",
"id": "xxxxxxxxxxxxxxx",
"ip": "",
"lat": "xxxxxx",
"local_key": "xxxxxxxxxxxxxx",
"lon": "xxxxxxx",
"model": "LSST6000",
"name": "Smart Sensor FT",
"node_id": "0198",
"online": false,
"owner_id": "xxxxxxxxxx",
"product_id": "youtmdgg",
"product_name": "Smart Sensor FT",
"status": [
    {
        "code": "on_off",
        "value": false
    },
    {
        "code": "mode",
        "value": false
    },
    {
        "code": "initial_state",
        "value": "desligado"
    },
    {
        "code": "photo_level",
        "value": 0
    },
    {
        "code": "pir_level",
        "value": 1
    },
    {
        "code": "load_timer",
        "value": 1
    }
],
"sub": true,
"time_zone": "+08:00",
"uid": "xxxxxxxxxxxxxxx",
"update_time": 1695674784,
"uuid": "xxxxxxxxx",
"mapping": {
    "102": {
        "code": "on_off",
        "type": "Boolean",
        "values": {}
    },
    "103": {
        "code": "mode",
        "type": "Boolean",
        "values": {}
    },
    "104": {
        "code": "initial_state",
        "type": "Enum",
        "values": {
            "range": [
                "desligado",
                "ligado",
                "ultimo_estado"
            ]
        }
    },
    "107": {
        "code": "photo_level",
        "type": "Integer",
        "values": {
            "unit": "",
            "min": 0,
            "max": 30,
            "scale": 0,
            "step": 1
        }
    },
    "109": {
        "code": "pir_level",
        "type": "Integer",
        "values": {
            "unit": "",
            "min": 1,
            "max": 8,
            "scale": 0,
            "step": 1
        }
    },
    "110": {
        "code": "load_timer",
        "type": "Integer",
        "values": {
            "unit": "s",
            "min": 1,
            "max": 3600,
            "scale": 0,
            "step": 1
        }
    }
}

im able to use tinytuya to change all thoses DP though code, and im already able to use the first and second DP though the HA UI, but not yet both at same time... idk why or what im missing
first i tried creating a yaml file with this(and it actually works fine/perfect)

name: Smart Sensor FT
products:
  - id: youtmdgg
    name: Smart Sensor FT
primary_entity:
  entity: switch
  dps:
    - id: 102
      type: boolean
      name: switch

then i tried adding the rest of the DPS, this way, and it just recognized 1 entity....
ofc i were already thinking this first secondary entity isnt right, because as the first one it is boolean and it had already worked as switch in the primary entity, but i was trying a different entity just to see if i put the second diferent it would recognize it, idk, and to see if i could see other type of card available for that entity... but ofc it wasnt working too

name: Smart Sensor FT
products:
  - id: youtmdgg
    name: Smart Sensor FT
primary_entity:
  entity: switch
  dps:
    - id: 102
      type: boolean
      name: switch
secondary_entities:
  - entity: binary_sensor
    name: Mode Sensor
    dps:
      - id: 103
        type: boolean
        name: mode
  - entity: sensor
    name: Initial State
    dps:
      - id: 104
        type: enum
        name: initial_state
        mapping:
          - dps_val: "desligado"
            value: "Off"
          - dps_val: "ligado"
            value: "On"
          - dps_val: "ultimo_estado"
            value: "Last State"
  - entity: sensor
    name: Photo Level
    dps:
      - id: 107
        type: integer
        name: photo_level
  - entity: sensor
    name: PIR Level
    dps:
      - id: 109
        type: integer
        name: pir_level
  - entity: sensor
    name: Load Timer
    dps:
      - id: 110
        type: integer
        name: load_timer

then i tried to change the one with binary sensor to switch, it didnt recognized too,

but then i moved this second DPS to be together with the primary entity(inside), and it worked, ofc that not in the right manner, but for test purposes....(i tried to choosing only one DP only at time( 1 per time) as a primary entity, and it works well too) )

so what im missing is how to use them all in the same .yaml file being them as 1 entity each or something like that
to me be able to use them as a card/button at the dashboard

after that i tried several yaml file configurations, looked into others devices configs and nothing... wasted more than 4 hours on this yesterday, made more than 30 yaml file and nothing works....
if you could point me into the right way on doing this i would be glad..
even a whole .yaml file to work with thoses DPS as different entities to me be able to use diferent cards/buttons etc,i would love, to me uses as guide to write the next ones... if you need more info or something please let me know

[make-all]

Each entity type has specific requirements for the naming of the dps inside them. These requirements are listed in custom_components/tuya_local/devices/README.md

There is a pytest test in tests/test_device_config.py that can catch issues like this, with 20 devices in your plans, I would recommend getting pytest working locally.

I think the following should work (first line is only required the first time you do this):

pip install -r requirements-dev.txt
pytest tests/test_device_config.py

It is also recommended to use venv, if you are doing other python development then you should already be familiar with that, but if this is the only thing you are using python for, then messing up your global environment isn't going to be a concern.

You can also run pytest with no arguments to run all the tests, but if you are only adding new config files the other tests are not relevant to what you have changed, and it takes a long time to run all of them. This will be done when you submit the PR, so if you can't get it set up locally, it is not the end of the world, just with so many devices it might help to have the tests locally.

[Artjosh]

I totally forgot about answering this discussion... sorry.. with this msg by you i was able to make this work already on 5 devices, one is already on my fork... Thank you so much, soon all them and + will be at my fork to maybe someday i git push to the main repo <3
Lemme ask one final question, what about making an auto descovery feature to the new devices? even maybe auto discovering sub devices that are only available through gateway? I mean i have to configure each new device through the gateway puting the gateway id/localkey/ip/Protocol Version+ subnode ID , so if we had a feature on making this auto discovery using the tinytua service of an tuya cloud project, then gathering all the necessaries info to make this autoDiscovery/auto config feature?

OR MAYBE SOMETHING LIKE THAT, RIGHT? bc i see that the tinytua wizard only provides the cloud info and there it only shows(obvisly) the ipv4 host ip for the gateway device, not the local ip that is needed to this config.. so idk how could i retrieve this ip though tinytua to maybe create this feature.... maybe someday i will dig more about it and try to implement this feature....
Thank you for spending your time on replying all this

[make-all]

Discovery is planned, but there are a number of challenges that make it not a simple task even with tinytuya doing the heavy lifting.

Many users use this integration specifically because they do not want to use the cloud, or have trouble signing up for and keeping active iot.tuya.com accounts, so it would have to be designed to be an optional extra, not a replacement for the current config. Then there is the local IP address - this actually requires local discovery, which can also use tinytuya, but it conflicts with the same feature in localtuya, because the protocol is broadcast based, and the discovery ports can only be opened once, so again, this needs to be optional. Lastly there is the fact that tinytuya is not asynchronous, so any processes that take a lot of time, like discovery, cause problems like #407 if implemented the simplest most obvious way.

So I have been leaving these features until I have a decent block of time to work on the integration, currently new device requests are coming as quickly as I can handle them and I don't really have time to extend to new features like this.