Values not updating - even with scan interval set

beta-j commented 1 year ago

The problem

I've been getting power readings from a Zemismart WiFi Home Power Monitor device for around three months using localtuya. Suddenly as of three days ago (16th January 2023), all device readings are not updating until I open the Tuya app on my phone. While the app is open all values are updated in near real-time, but when the app is closed, the last reading keeps being shown.

I've read of similar issues that where resolved by setting a Scan Interval in the integration config. However, I've had a scan interval set since day one of using the device and it's still not working as expected. I've tried changing the scan interval to longer or shorter periods but it doesn't seem to be having any effect.

Environment

Localtuya version: v5.0.0.0
Home Assistant Core version: 2023.1.5
[x] Was the device working with earlier versions of localtuya ? Which one? 4.1.1
[x] Are you using the Tuya/SmartLife App in parallel ?

Additional Information

I know of one other user who has been experiencing the exact same issue on a separate HA install.

Problem disappears when reverting integration to version 4.1.1, and reconfiguring the device.

CloCkWeRX commented 1 year ago

Possibly #1248 / #1258 ? Scan interval was inadvertedly set to a string value in some cases. 2x possible PRs available to fix.

beta-j commented 1 year ago

Possibly #1248 / #1258 ? Scan interval was inadvertedly set to a string value in some cases. 2x possible PRs available to fix.

Sounds likely - One thing I noticed was that when I rolled back to version 4.1.1 I got an error saying that the scan interval should be set to an integer value. I just re-typed the scan interval value and it accepted it. So it sounds like it's possible that v5.0.0 was saving the value as a string.

GitTimeraider commented 1 year ago

Nice, will try to see whether manually adjusting the stuff from your PR will make it work :P

GitTimeraider commented 1 year ago

Possibly #1248 / #1258 ? Scan interval was inadvertedly set to a string value in some cases. 2x possible PRs available to fix.

Tried some of the PRs... but sadly nothing. Energy IDs still do not update unless the smart life app updates the values to the online enviroment. So still remains a thing

tjafbe commented 1 year ago

I noticed something odd. I have had 3 Tuya plugs working even on v5.0.0 without issue. I never use the smartlife app, but just today I opened it again and looked at the power consumption in the msartlife app for 2 out of 3 smartplugs. These 2 now stopped updating their values in home assistant while the 3rd one I didn't open in the smartlife app is still working fine. I have the official Tuya integration also running in parallel. These 2 plugs now also no longer update their power values in the official Tuya integration. Seems like as soon as you use the smartlife app something is changed in how the plugs behavior?

liangleslie commented 1 year ago

@tjafbe you're probably on to something. Noticed the exact same thing. Restarted my plug and power consumption was updating regularly as usual

edit: seems like the plugs are still not updating after restarting, not sure what changed with the app edit 2: tried to do some troubleshooting -- using tinytuya to call updatedps() does get the plug to update the readings, which are picked up by status(). Not sure why the readings are not refreshed otherwise...

liangleslie commented 1 year ago

Worked around the issue with an ugly hack for the time being until a proper solution is found... Added update_dps within the heartbeat loop in the pytuya module and it seems to force the switches to refresh the DPs.

Not sure if this would cause any issues or have any implications on other tuya devices that are working fine though

rinocavallanti commented 1 year ago

where did you add exactly? in which command line?. thank you

liangleslie commented 1 year ago

I replaced heartbeat method on line 794 with:

    async def heartbeat(self):
        """Send a heartbeat message."""
        try:
            self.debug("Updating DPS 18, 19, 20")
            await self.update_dps([18,19,20])
        except:
            pass
        return await self.exchange(HEART_BEAT)

rinocavallanti commented 1 year ago

fantastic! it seems to work fine. Thank you very much

liangleslie commented 1 year ago

I replaced heartbeat method on line 794 with:

    async def heartbeat(self):
        """Send a heartbeat message."""
        try:
            self.debug("Updating DPS 18, 19, 20")
            await self.update_dps([18,19,20])
        except:
            pass
        return await self.exchange(HEART_BEAT)

As expected, this caused some issues where a device would disconnect after a while and not be able to reconnect (at least for me)

Possibly #1248 / #1258 ? Scan interval was inadvertedly set to a string value in some cases. 2x possible PRs available to fix.

Turns out this was indeed the problem, and the easiest workaround (and probably friendlier to future updates) for now is to:

open /config/.storage/core.config_entries in a text editor
search for the device entry
look for the "scan_interval" key (if it doesn't exist, use config flow to edit the device and set this to an integer)
remove the quotes around the value, i.e. "15" should be changed to 15

energy readings should start updating at the interval set. @rinocavallanti

smeagol-github commented 1 year ago

Hi all

I had this issue with the scan_interval but it didn't fix the issue for me.

I had to adjust line 814 to add 3.4 into the self.version list:

    if self.version in [3.2, 3.3, 3.4]:  # 3.2 behaves like 3.3 with type_0d

MikeatLorne commented 1 year ago

This approach also worked for me but I did not include the that were showing in the email - must have been a formatting issue. I have now just seen the correct version in github without the . Anyway my sensors are now updating according to the period set (in integer format). - so what caused the problem? integers vs string OR needing to include version 3.4 at line 814?

smeagol-github commented 1 year ago

I suspect both. There is another bug open for the string/int thing for the pytuya module I saw that advised to cast before committing or reading the values - I’d reference that but I can’t find it just now. #1260 EDIT: No1260 I noticed that my Tuya device firmware auto upgraded recently and for that reason I suspect the 3.4 did more to help me than the string/int.

CodingGhost commented 1 year ago

I have the same problem, it only updates sporadically even with scan interval set. also checked if its a string but its not...

elm- commented 1 year ago

I was facing the same issue, no errors or warnings. scan_interval is a integer. When I call update updatedps() (via tinytuya) it works as expected.

In the documentation of tinytuya it says as much:

# NOTE Some smart plugs require an UPDATEDPS command to update power data

For now I'll add a script that runs to fix this every x seconds, but a device setting to force_updatedps as part of scan_interval probably makes sense to add? If there that makes sense, happy to try to provide a PR.

Edit: Nevermind, I should have read the code in context =), the updatedps is already done, just due to the protocol issue mentioned in [https://github.com/rospogrigio/localtuya/issues/1253#issuecomment-1416684725](the above comment), needed to add v 3.4 to the list of protocols for DPS refresh.

Is this tracked already somewhere as a PR to fix/reason why 3.4 is excluded?

rospogrigio / localtuya