-
Notifications
You must be signed in to change notification settings - Fork 561
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
Conversation
…pecifying DPS where entity detection failed, restoring DPS values on reconnect and also supporting devices which don't report DPS status until it has been set once.
@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
Probably better to land #944 specifically for the number entity change first; then this. |
@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. |
@rospogrigio - Just wondering if you had any feedback/thoughts on this PR? |
@CloCkWeRX was right, now please solve the conflicts and then we can merge this. |
@rospogrigio Sorry i hadn't seen the merge of #944 - Conflicts resolved. |
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. |
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. |
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? |
@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. |
Yea, they were added before this update rolled out. I can try readding them
if that makes a difference.
…On Wed, Sep 14, 2022, 2:46 PM sibowler ***@***.***> wrote:
@craigcabrey <https://github.com/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.
—
Reply to this email directly, view it on GitHub
<#956 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAG2MZI47SHW3DD7U5BV2ELV6ITQ3ANCNFSM53RZPJSQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
No, you shouldn't need to re-add them. Are you running 4.1.0 straight, or also including the fixes from #1022? |
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 |
@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! |
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:
Fixes: