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

Support Passive DPS devices, Restoring state after power off & NumberEntity enhancements #956

Merged
merged 12 commits into from
Sep 5, 2022

Conversation

sibowler
Copy link

@sibowler sibowler commented Jul 14, 2022

This change adds some features and addresses some issues introduced by HA updates. A number of these changes are focused around 'passive DPS' devices; which require a known DPS to be set to a valid value before they will start being returned as part of the status updates. I've debugged the communications between the Tuya App and the device (in my case an Arlec Security Light) and this is how the device is initialised.

Incorporated zombie fix changes from PR #817 and #491 as in further testing with Kogan and Arlec devices, the RESET command was needed to make these 'wake up' when they are disconnected from the internet.

I also found that the exact DPIDs passed to the RESET command needed to be exactly correct or the devices didn't wake up. So I added a configuration item to allow a user to specify the DPIDs to be used to RESET the device, which should allow this change to work with a wider variety of devices. The real credit for this change goes to @Elendilon who did the initial RESET implementation and @lloydw who did a recent port of changes, which made it a lot easier to integrate into this service.

With the Zombie and passive device changes in this PR, I've been able to successfully test/integrate the following devices without them requiring internet access:

Arlec Security Light - MAL315HA
Arlec Smart Plug-in Socket PC399HA
Kogan Smart Powerboard
Kogan Smart PowerPlug with USB

New Features:

  • Manually specify DPS to setup - used where automatic detection doesn't work.
  • Manually specify DPS to be used in RESET command - used when device doesn't respond to status requests
  • Specify default value - Used to initialise a device when reconnecting/after power loss. If not specified, the entity type will default to an appropriate value (either off, a minimum value, or the first state in a select)
  • Restore state on reconnect - Used to restore the state last seen by HA when a device reconnects. This is useful where a device doesn't persist states between power offs. Currently configured for basic entities (Switch, Number, Select), but can be extended to others in the future.
  • Step size to NumberEntity - Allow configuring the increment between numbers.

Fixes:

@sibowler
Copy link
Author

@rospogrigio - Got the formatting right first go, this time around :) All ready for your review.

… a zombie mode to start responding to commands. Added configurable DPS for Reset command as found devices wouldn't 'wake up' unless they had exactly the right entries
@CloCkWeRX
Copy link

Probably better to land #944 specifically for the number entity change first; then this.

@sibowler
Copy link
Author

@CloCkWeRX - That's fair enough. I hadn't seen that PR before i did this one.

Essentially whether this one gets merged first or that one - it's the same outcome, so I'm happy. One difference though, is that I moved the constants into the const file (which I should've done when I introduced the NumberEntity). But that change can still be merged after #944 if that goes first.

@sibowler
Copy link
Author

@rospogrigio - Just wondering if you had any feedback/thoughts on this PR?

@rospogrigio
Copy link
Owner

Probably better to land #944 specifically for the number entity change first; then this.

@CloCkWeRX was right, now please solve the conflicts and then we can merge this.
Bye!

@sibowler
Copy link
Author

sibowler commented Aug 31, 2022

@rospogrigio Sorry i hadn't seen the merge of #944 - Conflicts resolved.

@rospogrigio
Copy link
Owner

Mmm I have just tried this PR in my setup and it got broken: all my switches work but all my covers are unavailable. Need to put this on hold until we figure out what is the problem. Any suggestion on how to debug this is appreciated.

custom_components/localtuya/cover.py Outdated Show resolved Hide resolved
@lloydw
Copy link

lloydw commented Sep 5, 2022

Thanks for pushing this through to approval @sibowler, lots of users will be really pleased with these fixes! Thanks for accepting the PR @rospogrigio and the great work you do maintaining this project.

@rospogrigio rospogrigio merged commit 7142304 into rospogrigio:master Sep 5, 2022
@craigcabrey
Copy link

How is this expected to work? I upgraded to the latest version & began to block my two tuya lights from the internet again. But I'm seeing the same behavior from before: zombie state & non-responsive.

Any documentation on where these DPID values come from & what they represent / should be set to?

@sibowler
Copy link
Author

@craigcabrey - It might not work with every device. Did you add them to localtuya before blocking them from the internet?

Even with these changes, i've still got tuya fan devices which i've not been able to make work. But in this case, even the native tuya app - which tends to be good at waking up these kinds of devices when they're disconnected from the internet - wasn't able to wake them up.

@craigcabrey
Copy link

craigcabrey commented Sep 14, 2022 via email

@sibowler
Copy link
Author

No, you shouldn't need to re-add them. Are you running 4.1.0 straight, or also including the fixes from #1022?

@jonilam
Copy link

jonilam commented Oct 21, 2022

Hi @sibowler,

I am running version 4.1.1. and I have two different models of GU10 light bulps and a Ledvance ceiling light that are not working with localtuya after power loss. I debugged this a bit with tuyadebug and noticed that first they don't have any DPS available, but if I set single datapoint with localtuya.set_dp to the devices, ceiling light and other GU10 light bulp model start to "advertise" all of the datapoints (all datapoints available in tuyadebug) and after that they also work without any issues. With the other GU10 light bulp model only that datapoint which was set becomes available, so to get device working properly I need to add all datapoints with localtuya.set_dp.

Based on the description of this pull request, did I understand correctly that the first GU10 light bulp model and ceiling light should work properly with the "Specify default value" feature and that the second GU10 light bulp model should work with "Restore state on reconnect" feature? Should these be in use/available for the light entities and if so how those can be configured?

@sibowler
Copy link
Author

Hi @sibowler,

I am running version 4.1.1. and I have two different models of GU10 light bulps and a Ledvance ceiling light that are not working with localtuya after power loss. I debugged this a bit with tuyadebug and noticed that first they don't have any DPS available, but if I set single datapoint with localtuya.set_dp to the devices, ceiling light and other GU10 light bulp model start to "advertise" all of the datapoints (all datapoints available in tuyadebug) and after that they also work without any issues. With the other GU10 light bulp model only that datapoint which was set becomes available, so to get device working properly I need to add all datapoints with localtuya.set_dp.

Based on the description of this pull request, did I understand correctly that the first GU10 light bulp model and ceiling light should work properly with the "Specify default value" feature and that the second GU10 light bulp model should work with "Restore state on reconnect" feature? Should these be in use/available for the light entities and if so how those can be configured?

It will be usable for light entities - but i haven't written it yet. I didn't have a device to test with when i wrote the initial code... But I do now! Just need to resolve these other errors that are occurring for some users, that seems to be related to the new RESET code and then I can get to working on that enhancement for light devices.

@jonilam
Copy link

jonilam commented Oct 21, 2022

Hi @sibowler,
I am running version 4.1.1. and I have two different models of GU10 light bulps and a Ledvance ceiling light that are not working with localtuya after power loss. I debugged this a bit with tuyadebug and noticed that first they don't have any DPS available, but if I set single datapoint with localtuya.set_dp to the devices, ceiling light and other GU10 light bulp model start to "advertise" all of the datapoints (all datapoints available in tuyadebug) and after that they also work without any issues. With the other GU10 light bulp model only that datapoint which was set becomes available, so to get device working properly I need to add all datapoints with localtuya.set_dp.
Based on the description of this pull request, did I understand correctly that the first GU10 light bulp model and ceiling light should work properly with the "Specify default value" feature and that the second GU10 light bulp model should work with "Restore state on reconnect" feature? Should these be in use/available for the light entities and if so how those can be configured?

It will be usable for light entities - but i haven't written it yet. I didn't have a device to test with when i wrote the initial code... But I do now! Just need to resolve these other errors that are occurring for some users, that seems to be related to the new RESET code and then I can get to working on that enhancement for light devices.

Great. Let me know if you need tester

@sibowler
Copy link
Author

@jonilam - I've made some changes to fix some RESET issues that some devices were facing. One of the side effects is that it has enabled my previously unresponsive TUYA bulbs to start working. All I needed to do was put the relevant DP_IDs in the Device RESET DP_IDs list.

If you'd like to try the changes, they are published in PR #1273

@jonilam
Copy link

jonilam commented Feb 21, 2023

@jonilam - I've made some changes to fix some RESET issues that some devices were facing. One of the side effects is that it has enabled my previously unresponsive TUYA bulbs to start working. All I needed to do was put the relevant DP_IDs in the Device RESET DP_IDs list.

If you'd like to try the changes, they are published in PR #1273

I have been testing your changes for a couple of days and so far all earlier unresponsive devices have been working without any issues. Thank you!

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

Successfully merging this pull request may close these issues.

6 participants