notes on refresh()

[msillano]

I have a device (a AC power meter), protocol 3.3, who accepts refresh(), so I done some tests (see also ISSUE#54 ISSUE#56).

Tuya refresh objectifs

On Tuya ecosystem the refresh is used to optimize the data update when a faster rate is required to enhance the user experience.

To reduce resource use, the fast refresh is limited only when required: for example, smartLife uses a rate of 5 sec. only when the user interface is visible.

refresh() in tuyapi 7.1.0

Are possible 3 different call of refresh():

• tuya.refresh(); called also 'refresh'
• tuya.refresh({dps: 2}); called also 'dp-refresh'
• tuya.refresh({schema: true}); called also 'shema-refresh'

test

I made many tests with my device, also at very fast rate (1 s). example:
RFR 20 {"operation":"RFR", "dps":"20"} repeat every 1 sec:

14 Apr 16:04:58 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"20":2301},"t":1618409097}
14 Apr 16:04:59 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"20":2299},"t":1618409098}
14 Apr 16:05:00 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"18":58},"t":1618409099}
14 Apr 16:05:00 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"20":2300},"t":1618409099}
14 Apr 16:05:01 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"18":57},"t":1618409100}
14 Apr 16:05:02 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"19":43},"t":1618409101}
14 Apr 16:05:02 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"20":2299},"t":1618409101}
14 Apr 16:05:03 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"19":44},"t":1618409102}
14 Apr 16:05:03 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"20":2298},"t":1618409102}
14 Apr 16:05:05 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"18":58},"t":1618409104}
14 Apr 16:05:05 - [info] [tuya-smart-device:AC meter] dp-refresh from device: {"devId":"48644******","dps":{"20":2299},"t":1618409104}

For my device is valid the following:

RULE1: A refresh() triggers a new data sampling. In response the device sends ONLY ALL changed DPs.

This rule is coherent with Tuya refresh objectives and minimizes the bandwidth use.

more notes

1. the data are sent in separate messages.
2. all three styles of call ('refresh', 'dp-refresh', 'schema-refresh') have the same behavior: following RULE1. (e.g. @16:05:01 I ask for dp 20, and I get dp 18; @16:05:04 I get nothing).
3. I like clean and fast code, so I don't like fallbacks and 'magic numbers': they always cause problems. For that, I investigate the arrays at lines 103 and 733 of the index.js code. I changed it, I eliminate the 20 dp, I make the arrays empty: nothing changed in my device behavior, always RULE1.

conclusions

We know: any tuya device can have its own behavior: tuya devices use a poll of common code, but they are designed by different manufacturers, with objectives and exigences very different. (e.g.: some manufacturers try to promote their apps, reducing the performance of their products in Tuya environment).
Usually is very dangerous to do generalizations based on few cases. With tuya devices, impossible.

Best Regards
m.s.

[codetheweb]

Thanks for investigating this.

Are you recommending that something be changed, or just posting your findings?

Usually is very dangerous to do generalizations based on few cases. With tuya devices, impossible.

Absolutely. But

I changed it, I eliminate the 20 dp, I make the arrays empty: nothing changed in my device behavior, always RULE1.

is also potentially only supporting a small subset. :)

[Apollon77]

Yes also my finding was that devices even my react strange up to "reboot themself" when being queried for the wrong data via refresh method. So be careful

I have better results for "Other" fileds then the hard defined "refresh" ones with the "query via "set null"" way

[msillano]

Codetheweb, Apollon77: Suggestion? yes: simplify.

To handle the tuya devices I make some radical choices:

1. I build an environement to define and test the tuya devices, tuyadaemontoolkit. It produces some artifactcs for documentation and JSON objects.
2. In production, a big JSON structure ('alldevices'), build using the objects maked by tuyadaemontoolkit, maps all used devices and relates DPs capabilities. It controls the device msg processing. So a 'bad' command for any device can not be send. Never.

In that contest, I pose to tuya experts the question:

• It is useful to have refresh, dp-refresh, schema-refresh? For now I found usefull only refresh (refresh()). (see example)

More general:

• The efforts to get SCHEMAs from any device I think are useless. SCHEMA is a legacy from the dawn of the MQTT. It was abandoned by the builders. Why? why not useful now. So...
• Too many fallbacks make the code slow and unreliable: if I know a DP doesn't accept GET but processes SET(null) I send it SET(null) instead of GET. Simple, robust, valid for any future Tuya changement...

It's a challenge: Tuya strives to make things complicated ... and we react.

Best Regards
m.s.

[Apollon77]

The topic is in my eyes if the library is there to offer conventient functionalities for the library users or if it offers pure "tech functionality". In second case any developer that want to use the libra yneeds to dive very deep into the prtocol and limitations and specialities and need to implement things (like "do the DP support refresh or set(Null) or is normally pushed" is a good example.
For now the library here and also the python one more try to offer the convenient way and therfor it has all these fllbacks and such. In the end "easy to use first".

[codetheweb]

In production, a big JSON structure ('alldevices'), build using the objects maked by tuyadaemontoolkit, maps all used devices and relates DPs capabilities. It controls the device msg processing. So a 'bad' command for any device can not be send. Never.

I like this idea, but it's just not really compatible with the way TuyAPI works now.

Too many fallbacks make the code slow and unreliable: if I know a DP doesn't accept GET but processes SET(null) I send it SET(null) instead of GET. Simple, robust, valid for any future Tuya changement...

Yes and no. The fallbacks need to be in place for the different types of devices.

As @Apollon77 mentions above, the goal of this project is to provide a bit of a middle ground between implementing everything from scratch and having everything handled for you.

Longer answer in the README.