search

codetheweb / tuyapi

🌧 An easy-to-use API for devices that use Tuya's cloud services. Documentation: https://codetheweb.github.io/tuyapi.
MIT License
2.07k stars 341 forks source link

more on REFRESH #469

Closed msillano closed 3 years ago

msillano commented 3 years ago

I've tested a second device that handles the REFRESH, a wifi plug. The behavior is the same as the previous device: see ISSUE#460. I can't found on my devices any difference between:

In my experience, REFRESH is a device command, not a DP capability. It triggers an immediate resampling and the device sends all DPs that are changed: options like dp, schema ... have no effect.

That looks very different from the expected behavior of that command and these options as described in the tuyApi documentation. Or am I misleading the documentation?

I have implemented a refreshCycle, that works as fast as 1 sec, ISSUE#56 using therefresh(), but I don't know if there are more general and better solutions.

Best regards m.s.

codetheweb commented 3 years ago

The schema and dps options are included to mirror the options on get(). They control what data TuyAPI returns, not the request that is sent to the device. I agree that the options are a little unwieldy but I think it makes sense to keep them that way for now so it matches get(). Having said that, I'm surprised there's no difference in the shape of return values that you're getting. Could you post your test script and debug log?

msillano commented 3 years ago

I'm actually having a lot of "fun" with tuyaDAEMON, maybe because it's very simple but powerful, especially in custom applications, maybe because I have a lot of time (I'm retired). This, in short, the whole story here.

        // for tests
           const REFONLY      = { payload: {operation: "REFRESH"}};
           const REFONE        = { payload: {operation: "REFRESH", dps:20}};
           const REFMANY     = { payload: {operation: "REFRESH", requestedDPS:[18,19,20]}};
           const REFSCHEMA = { payload: {operation: "REFRESH", schema:true}};

P.S. That is not exact. Looking at data better I noticed that we can found duplicated responses in cases REFONE and REFSCHEMA but not in case REFONLY. Also the rule "DPs that are changed" is stricty valid only for REFONLY.
Sic stantibus rebus, for me the better solution is to use REFONLY only (sic!) to reduce the band.

On my collection of 41 tuya devices, only 2 accept REFRESH, so I can't do more tests.

Best regards

m.s.

codetheweb commented 3 years ago

Cool, thanks for the data.