LG Washer: new "pause" button logic is not quite right about ha-smartthinq-sensors HOT 25 CLOSED

Please start providing integration diagnostics generated when your device is in pause state. I don't think this will help me a lot, but I will take a look...

from ha-smartthinq-sensors.

This make sense, so probably on resume I have to take parameter for the wakeup command from the current state and not from the program parameter. I will release a new version with this change when I will have some available time...

from ha-smartthinq-sensors.

Closing, noting that I haven't yet tested on my dryer, which could of course be different again. It might be a while before it's next used (high summer here now). If it turns out there's a problem, I'll either reopen this then or open a new issue.

from ha-smartthinq-sensors.

(I haven't yet tested the same behaviour / issue on the dryer, but can if needed or on the next time it's used)

from ha-smartthinq-sensors.

Are you using the last version (v0.38.0)?
If with this version the issue is still present, the only way to solve the problem is that you capture the traffic from LG App and post here the right command used to restart the running program.

from ha-smartthinq-sensors.

Yeah, I updated to 0.38.0 yesterday

from ha-smartthinq-sensors.

Here's a timeline like before:

Steps taken:

1. enable debug logging in component
2. set up the wash load from the front panel, for remote start
3. push remote start in HA
4. pause via front panel
5. resume via front panel
6. pause via LG app
7. resume via LG app
8. pause via HA
9. resume via LG app

I left a good clear minute between each of the pause / resumes to ensure time for polling updates.

Some observations:

• pause via the front panel causes the door to unlock, pause via remote leaves the lock indicator lit. There doesn't seem to be an entity here to show this, though.
• the state value for the "pause" entity retains the value from yesterday once enabled, and changes when pressed in HA.
• the state value for the "remote start" entity gets set when pressed, immediately goes unavailable, and reappears when the button is enabled again while pause remotely, but apparently not when paused from the front panel.
• Not shown in the timeline above, (but included in the logs) I did another pause from the front panel while writing this observation. A pause from the front panel shows in the LG app as paused, without a resume button, so can presumably only be restarted locally.

What's the best way to share the file, it won't seem to attach here?

from ha-smartthinq-sensors.

I have mentioned you from a gist.. not sure whether there are credentials in this log. LMK if something else is needed.

Hopefully this gives you some clues, otherwise I can set up waydroid and try to capture traffic from the lg app, but that will have to wait a little while.

from ha-smartthinq-sensors.

In diagnostic sensitive data are "redacted", so you can safely extract and attach it here,
This issue was also present in original FR #627, but changing the value for initial_bit on resume fixed it, so I didn't expect this behavior. Anyway i want to have a look to diagnostic to see if initial_bit for your device have a different representation, if I'll find nothing I need captured trafic.

from ha-smartthinq-sensors.

Did you find the gist? https://gist.github.com/dcarosone/08b49b7d5dd223c523d7cd8258d889e9

from ha-smartthinq-sensors.

Yes, I was looking it now, and seems that is sending INITIAL_BIT_ON also when device is in pause, so probably this is the issue. I will further investigate on this.

from ha-smartthinq-sensors.

Anyway if you could attach integration diagnostics (that is not debug log) could help my analysis.

from ha-smartthinq-sensors.

I analyzed your logs, but what is missing (and main point of this issue) is "Resume via HA". In first case (Remote start via HA) it is normal that is sent INITIAL_BIT_ON because in this case the program is started and not resumed.

from ha-smartthinq-sensors.

I analyzed your logs, but what is missing (and main point of this issue) is "Resume via HA". In first case (Remote start via HA) it is normal that is sent INITIAL_BIT_ON because in this case the program is started and not resumed.

I see, I'm sorry. I thought the point was to try and get clues about what the LG app was sending, and that what HA was sending was already known. I can repeat the experiment (but not today).

Anyway if you could attach integration diagnostics (that is not debug log) could help my analysis.

Again, sorry; the distinction wasn't clear, and the UI shows "enable debug logging" but completely hides "integration diagnostics" and I had to go searching to discover the difference.

config_entry-smartthinq_sensors-f45f95bd30a7ef260d06a111fbb5d5a4.json.txt

from ha-smartthinq-sensors.

In integration log there are no information about the commands sent by LG app, just the status change. The only reason to analyze the integration log is to verify if commands sent by integration are as expected.
To capture LG app commands, the procedure is more complex and is explained in readme.
Of course if commands send from integration are as expected but do not work properly, the only solution is to capture commands from LG app to understand the right format.

from ha-smartthinq-sensors.

Ok, next time I will capture a pause and resume via HA, in a few days time. Otherwise, I will set up waydroid as above to capture the LG app.

from ha-smartthinq-sensors.

Ok, well, the plot thickens.

I retested with the next load. On the first go, it paused and resumed from HA as desired! I started questioning my sanity. I checked the deployment history in nix to confirm which version it had been running the first time.

Then I remembered that the first time, when it restarted, it was past the "washing" stage. So I waited, and paused again while it was in the rinsing stage. This time, it started over on resume like previously.

Attached are integration diagnostics during each of the pauses

config_entry-smartthinq_sensors-f45f95bd30a7ef260d06a111fbb5d5a4-pause1.json

config_entry-smartthinq_sensors-f45f95bd30a7ef260d06a111fbb5d5a4-pause2.json

from ha-smartthinq-sensors.

https://gist.github.com/dcarosone/08b49b7d5dd223c523d7cd8258d889e9#file-ha-debug-log has the debug messages during the two pauses above

from ha-smartthinq-sensors.

@FilippoS1973 would you mind testing the same situation in your environment too? Does the pause / resume behaviour change further into the wash cycle?

from ha-smartthinq-sensors.

Honestly I'm becoming crazy with remote start function, seems that every single washer/dryer have different way to manage parameters for this command 🤐.
Please try last release and let me know what happen, if this doesn't work the only solution is to capture command from LG app executing some different cases.

from ha-smartthinq-sensors.

from ha-smartthinq-sensors.

Now pause botton is not available. So no way to test it.

Can you provide more details? Is not available starting from which version? Do you enable remote start?

from ha-smartthinq-sensors.

from ha-smartthinq-sensors.

Ok, this is correct. I wait a refresh polling before enable the button to be sure that we are in consistent state.

from ha-smartthinq-sensors.

With 0.38.3, it now pauses and resumes properly, even in later stages of the cycle! Excellent.

The latency for the pause/remote-start button activation can be seen too.

from ha-smartthinq-sensors.