Periodically send update dps command #549
Conversation
vmartinv
force-pushed
the
update_interval
branch
from
93504af to
a1eea63
Compare
vmartinv
force-pushed
the
update_interval
branch
2 times, most recently
from
4a9958e to
d59ee11
Compare
|
Code updated, now the storage shouldn't grow that much. (context here) |
Some troubles here... after updating the common.py the connection to the plugs gets lost - reload integration doesn't help. THe log gets flooded with messages like this every second: |
Looks like the code was altered... Copy the whole folder again, add the changes and reboot. |
Did that - completely removed the original component and replaced it by yours - the error mentioned before does not occur anymore, but the integration itself is also not working... the consumption data is still refreshing accordingly, but the state of the plugs (on /off) is not - by clicking on the button in HA, the plugs toggle only once, but the state doesn't change in HA and also further clicking the button has no function. Furthermore, some plugs go offline shortly after. Something must be wrong., although log shows no errors anymore... |
|
Might be also related to your previous change in init.py (fix auto-update ip feature), which I was not using until today's try. Until todays change I was using all files original, the only change was in pytuya/init.py (send update dps command with heartbeat). That was working, but flooding the database. If I use all files from your commit and just replace your init.py with the original one again (so eliminating the auto-update ip) I again have the error from above (Exception in callback _SelectorDatagramTransport._read_ready()). Also, nothing is working, plugs are unavailable. Therefore I assume, that there must be some incompatibility with it on my side. |
vmartinv
force-pushed
the
update_interval
branch
from
54c840a to
6476c0c
Compare
|
@AdmiralStipe My bad, I updated the code. What about now? |
Well, it works without errors now, but the database flooding is the same as before - state_change with {} is still registered every second in average.
|
|
That's something that is expected with many plugs i guess. |
Sure thing, but as I understood, Martin is able to alter the code in a way, that useless state_change records (empty ones) are not written to the database. It saves space and prolongues the disk life expectancy (less writing) at the same time. |
If you mean when it shows 0W then i agree maybe that could be ignored or atleast an option for that. |
No, not when it shows 0W... in "normal" operation the plug sends the state, when it changes (otherwise not)... when HA receives that, it acts correspondingly and also writes the state change to the database, which is correct. |
Ok then i understand. |
Fixed this with a workaround. |
Fixed what? I don't think this template reduces number of writings to the database and consequently database size, which was my request... |
I talked about my problem there my plugs show 0W for everything below 3W or something not your problem.
|
Excuse me, I'm new to this. I have localtuya and 2 devices are no longer usable, but I restart homeassistant and they are available again. Would this code work for me? where should i put it? thanks since now. |
|
Works perfectly for my Kogan wifi smart plugs. @rospogrigio @postlund what do we need to get this PR merged? |
it is the same thing that I have been wondering for some time @rospogrigio |
Sorry guys I didn't follow this thread with much attention because I'm not having these issues. I did not merge this because it seemed to me that this fix was working partially and somebody still has issues, but if you confirm that it's working fine I'll merge and release it. |
|
@rospogrigio - It's been working fine for me. But I'm only about a week into bringing this change onto my system. |
|
Tested and works flawlessly here too. |
|
@vmartinv can you please merge in the other commits into your fork? I'm not sure if there's a way for me to do this, my git knowledge is limited. |
|
@rospogrigio the user-facing logic in the PR has not changed. You can see the config flow GUI change here and this is implemented in yaml using There was some discussion about HA database bloat; this has been addressed by only returning values that have changed when calling The stability issues have been resolved; they were caused by polling all known dps values (e.g. [1,9,18,19,20,21]) with the 0x12 refresh command which caused the device to become unresponsive periodically. The resolution is a whitelist of known-good dps values (currently If there are future dps values that need to be added to this whitelist, or values that prove unstable for future devices and need to be removed, it is proposed that it becomes a user-editable list (in the form of a correctly formatted string e.g. |
|
merged |
|
|
|
@vmartinv this needs some supporting edits to README.md and info.md, in the YAML setup instructions (updating to include scan_interval with a comment as to when/why to use) and in the config flow gui instructions (updated screenshot showing refresh interval and comments about when/why to use). Probably needs a brief mention in the Energy monitoring values section too. Is this something you can do and include in the PR for us? If not, I'll fork the repo and submit another PR to accompany this one some time this weekend. Edit: 30 seconds seems to be a good value to put in the examples, and matches with the current Xiaomi integration defaults for their power plugs. |
|
I am testing this PR and it seems to be working fine. Before I merge it, I'd ask you to update the README.md and info.md documenting the new option and its impact on the DB size, please. |
To accompany PR rospogrigio#549
To accompany PR rospogrigio#549
|
@rospogrigio I can't substantiate any significant impact on the database size, since commit If you do not agree, I'll edit PR #667 to include a comment but I really do not think it is warranted. |
|
I'd really like to get rid of this: |
|
@jeremysherriff I think you can configure your PR to be on top of mine (stacked pull requests) |
|
OK PR merged, now I'll proceed with the other 2... |
|
My entity still only updates when the app is open, time to dig into the logs. |
|
This is sadly not working for me either. When i add one of my smart plugs with energy monitoring with todays new update, only two DPS show up. The ones that would contain the energy consumption information are missing. When i tried this a few months ago when i tried localtuya for the first time, a lot more DPS would show up and provide data as long as the app was running. Am i overlooking something that i should do? |
|
@InsanityFlea @codingcatgirl please open new issues, posting your YAML or screenshots of your config as appropriate and we'll try to help. |
|
@jeremysherriff |
|
Thanks, fix works perfectly for me <3 |
|
It should be sent for devices with firmware of 3.4 also as it was not updating for my new Nedis plug, locally updated the code to allow update_dps to be ran for 3.3 and 3.4 and consumptions values started coming. Also there's somekind of bug with self._dev_config_entry[CONF_SCAN_INTERVAL]) not being INT when configured from UI - there were errors in logs about str being compared to int on common.py line 273 ( self._dev_config_entry[CONF_SCAN_INTERVAL] > 0 ) |
Problem
There has been some reports of devices not updating their state unless the app is open (#547, #539).
Solution
Several users found out that periodically sending the update dps command (available in tinytuya) forces the state to be updated. I implemented this feature here.
Update:
Upon request, the feature can now be controlled through the config and is disabled by default:
example using yaml:
Testing
The command is being sent but I don't have any devices that experienced this problem to verify it works.
UPDATE: this has been verified to be working with several devices
example log: