Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Last update 6.2 was "breaking" #448

Closed
Apollon77 opened this issue Mar 31, 2021 · 8 comments
Closed

Last update 6.2 was "breaking" #448

Apollon77 opened this issue Mar 31, 2021 · 8 comments

Comments

@Apollon77
Copy link
Collaborator

Since the last update you need to use the new "dp-refresh" event and listen to it ... else you miss data.
So formally it was more a 7.0 then 6.3 :-(

The example in readme and other documentation should be updated

@Apollon77 Apollon77 changed the title Last update 6.3 was "breaking" Last update 6.2 was "breaking" Mar 31, 2021
@codetheweb
Copy link
Owner

In theory this shouldn't be breaking since dp-refresh is only used instead of data if dps index 1 is missing:

tuyapi/index.js

Line 579 in 8d30a6f

if (packet.commandByte === CommandType.STATUS && packet.payload && packet.payload.dps && typeof packet.payload.dps[1] === 'undefined') {

That metric could definitely be improved though to prevent false positives.

@Apollon77
Copy link
Collaborator Author

I have several users that use my ioBroker adapter that complain that they do not get data updates anymore as before. I now added also dp-refresh and let the users test. lets see what happens

@Apollon77
Copy link
Collaborator Author

I got confirmation that now it is workign again for the users ... so in fact before the 6.2 it was enough to listen to the data event, not you need dp-refresh AND data ...

@Apollon77
Copy link
Collaborator Author

BTW. Reasons are devices like the "LSC WLAN Video Doorbell" with this shema definition:

[{"type":"boolean","read":true,"write":true,"name":"basic_flip","id":103,"role":"switch"},{"type":"boolean","read":true,"write":true,"name":"basic_osd","id":104,"role":"switch"},{"type":"number","states":{"0":"0","1":"1","2":"2"},"read":true,"write":true,"name":"motion_sensitivity","id":106,"role":"level"},{"type":"number","states":{"0":"0","1":"1","2":"2"},"read":true,"write":true,"name":"basic_nightvision","id":108,"role":"level"},{"type":"string","read":true,"write":false,"name":"sd_storge","id":109,"role":"text"},{"type":"number","min":1,"max":5,"scale":1,"read":true,"write":false,"name":"sd_status","id":110,"role":"value"},{"type":"boolean","read":true,"write":true,"name":"sd_format","id":111,"role":"switch"},{"type":"string","encoding":"base64","read":true,"write":false,"name":"movement_detect_pic","id":115,"role":"text"},{"type":"number","min":-20000,"max":20000,"scale":1,"read":true,"write":false,"name":"sd_format_state","id":117,"role":"value"},{"type":"boolean","read":true,"write":true,"name":"motion_switch","id":134,"role":"switch"},{"type":"string","read":true,"write":false,"name":"doorbell_active","id":136,"role":"text"},{"type":"boolean","read":true,"write":true,"name":"record_switch","id":150,"role":"switch"},{"type":"number","states":{"0":"1","1":"2"},"read":true,"write":true,"name":"record_mode","id":151,"role":"level"},{"type":"string","encoding":"base64","read":true,"write":false,"name":"doorbell_pic","id":154,"role":"text"},{"type":"number","min":1,"max":10,"read":true,"write":true,"name":"basic_device_volume","id":160,"role":"level"}]

As you can see there is only IDs [103,104,106,108,109,110,111,115,117,134,136,150,151,154,160] ... so there is no id 1 in ... and for such devices the 6.2 was indeed breaking

@codetheweb
Copy link
Owner

Hmm... any ideas what metric we could use instead?

I went ahead and deprecated versions between 6.2.x and 7, then published 7; so hopefully that clears stuff up.

@Apollon77
Copy link
Collaborator Author

Thank you for your clear statement to semantic versioning :-))

For the refresh in general I experimented a bit with a user and in the end really ended up in checking if the schema I know contains any of the fields from ones defined for refresh in library and if yes use refresh (still waiting for a user report to see if that worked) and else do that "get via set command and "null" as value directly what is the refresh fallback.

Additionally i added a "device disonnected after refresh command before response" detection and never send a refresh then again ... but still waiting toget more user reports ...

@codetheweb
Copy link
Owner

Ok, please do let me know what the results of those changes are once you have some feedback. :)

@stevoh6
Copy link
Contributor

stevoh6 commented Apr 6, 2021

Hi, Im sorry that I missed some devices. Please share your testing results and @codetheweb if you want I can help to improve it ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants