Some devices use feature flag dps to indicate the availability of features, so a single tuya firmware can cover a number of device variants.
These feature flags can either be booleans, or some kind of encoded string (hex, binary - which can be handled as hex missing a lot of bits, base64) or possibly a bitfield, so any interpretation of them should be after decoding.
Design idea:
For mappings, add a property available that takes an attribute name from the same entity, which should be a boolean value to indicate whether to include that mapping in the values list or not.
For entities, the special attribute available should be a boolean value that indicates whether the entity should be available or not. It needs to be investigated whether it is possible to make such entities hidden by default, as HA only checks for that at startup which may be before data has been received from the device. If not possible, such entities will show as unavailable even if the device is returning some data for them, and the user will need to hide them themselves.
Some devices use feature flag dps to indicate the availability of features, so a single tuya firmware can cover a number of device variants.
These feature flags can either be booleans, or some kind of encoded string (hex, binary - which can be handled as hex missing a lot of bits, base64) or possibly a bitfield, so any interpretation of them should be after decoding.
Design idea:
available
that takes an attribute name from the same entity, which should be a boolean value to indicate whether to include that mapping in the values list or not.available
should be a boolean value that indicates whether the entity should be available or not. It needs to be investigated whether it is possible to make such entities hidden by default, as HA only checks for that at startup which may be before data has been received from the device. If not possible, such entities will show as unavailable even if the device is returning some data for them, and the user will need to hide them themselves.