Add support for Tuya sensors using the Tuya reporting.

[Smanar]

This kind of sensors, don't use standard zigbee reporting but the Tuya cluster instead.
For exemple the Tuya ZigBee Multi-Sensor 4 in 1 Smart PIR Motion (_TZ3210_zmy9hjay) #4511

[Smanar]

Some tuya sensor have for exemple an endpoint 0x02 with temperature cluster, but using the endpoint 0x01 and the cluster 0xEF00 for reporting.
You can read the value on the temperature cluster, but no report.

The reporting is fixe, it can be modified, or disabled.

[manup]

Why is the reporting exposed via REST API? Not sure if I understand this correctly, but this shouldn't be a client responsibility. Just configure reporting if it is available, I don't see the benefit in disabling reporting or do I miss something?

[Smanar]

Good question, it is exposed because it was added at the end, with the others commands.
I can't use the same way than for zigbe device, because for exemple I have no way to check if the reporting is activated or not. So the only thing I can do is sending the command in "blind mode" everytime deconz is starting.
And this setting can be at "true" by defaut.

Will try to get some more informations.

[manup]

Interesting, isn't there a Tuya command to also read configuration? Sending the configuration once per deCONZ session is ok in some cases, it's being done for other devices as well, but should only be triggered when the device is actually awake. Ideally reporting should be configured during the setup phase.

[Smanar]

isn't there a Tuya command to also read configuration?

No see yet, if you use some "not finshed" request, some device answer with the actual value.
Some devices make a setting list if you use the "reset" request, like the siren, but not used yet.

But I have realy no clue for this one.

Ideally reporting should be configured during the setup phase

I think too.

• More chance for the device be awake
• No need to send this request at every start
• If it fails, just need to re include the device

I m waiting an answer to be sure if you disable this setting it realy disable TOTALY the reporting (but only for humidity and temperature for this sensor)

If yes, I will make the modification to send the request in blind mode at inclusion.

[manup]

Sounds like a plan :) I bet they have some commands to query the configuration, perhaps undocumented. I guess in future it will be helpful to sniff the traffic of a Tuya gateway to see how they handle these devices.

[Smanar]

Have made some change for the reporting be configured during inclusion.
The command is send

13:10:12:210 Send Tuya request: Dp_type: 0x01, Dp_identifier 0x70, data: 01

But I have no return from the device, can't say if it s normal or not, but the device is working after a re-inclusion.

[manup]

Good job on the DP identifier constants, for the remaining magic values it would be nice to have a separate PR to replace them with constants too.

[Smanar]

Yes it s on the TODOLIST, value are already in the tuya.h file, and used in the rest of code.

I need to rewrite the complete tuya.cpp code to separate, the dp_type and the dp_value, but the code still move too much, for exemple Smanar@2e40d7f.

[manup]

Beside the wrong debug print the PR looks good.
Please change the PR headline and description to be specific, "some sensor, some feature" could be anything ;)