Broken timestamp sensors due to datetime objects and zigpy conversion to str #519
Description
HA Core issue:
My comment from there:
Likely caused by #454 and zigpy/zha-device-handlers#4047.
We get the value from here via zigpy: zha/application/platforms/sensor/init.py#L288
I think it is possible that zigpy normalizes the value to str (CharacterString is the ZCL type) when either (1) updating the attribute initially via "reports attribute" (unlikely, since this is a Tuya device) or (2—more likely) when read_attributes is called on the (local) ZCL attribute (later) here: zigpy/zcl/init.py#L587-L599?
I believe we had a similar issue with Aqara plugs rounding their power measurement values after some time when the local attribute was polled. First, it was updated via update_attribute from some special Aqara data, which doesn't change the type/value. Later, that attribute was polled by ZHA, causing a read_attributes call, which then updated the value in zigpy cache, removing some decimal points due to the specified type.
(This issue is just here, so we can keep track of this and how we want to fix this.)
E.g. reverting to keeping str in zigpy cache or changing types of ZCLAttributeDef to datetime objects where applicable?