LG Washer: new "pause" button logic is not quite right

[dcarosone]

Describe the bug

The new pause button entity was much appreciated, but the logic is not quite right:

• when the washer is running, the pause button becomes available
• when the pause button is pressed, the washer goes to paused state, and the pause button becomes unavailable again
• the remote start button becomes available instead
• but pushing the remote start button restarts the cycle, rather than resuming

Expected behavior

Pause / Play behaviour, probably on the same button like the front panel.

Screenshots

here's a timeline of all entities, with a wash running. The pause button was pressed (in HA) at 12:14:43.

the pause button entity goes from 'unknown' (which can be pressed) to unavailable, the remote start button does the inverse.

then the remote start button is pushed at 12:15:09, and the washer cycle starts over with state change update at 12:15:40.

If applicable, add screenshots to help explain your problem.

Environment details:

• Environment (HASSIO, Raspbian, etc): NixOS
• Home Assistant version installed: Core 2024.1.6
• Component version installed: 0.38.0
• Last know working version: n/a: (new feature)
• LG device type and model with issue: washer/dryer F1P2CR_EAP-FL Firmware: clip_hna_v1.9.198
• LG devices connected (list): also RC90V9_AUS-Dryer (DRYER)

[dcarosone]

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

[ollo69]

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.

[dcarosone]

Yeah, I updated to 0.38.0 yesterday

[ollo69]

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...

[dcarosone]

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?

[dcarosone]

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.

[ollo69]

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.

[dcarosone]

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

[ollo69]

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.

[ollo69]

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

[ollo69]

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.

[dcarosone]

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

[ollo69]

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.

[dcarosone]

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.

[dcarosone]

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

[dcarosone]

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

[dcarosone]

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

[ollo69]

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...

[ollo69]

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.

[FilippoS1973]

Now pause botton is not available. So no way to test it. This happens after first edition already positively tested from my side Il Dom 18 Feb 2024, 17:06 ollo69 ***@***.***> ha scritto:

…

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. — Reply to this email directly, view it on GitHub <#696 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOFYIF5I7CFVPHA5ZEY7GUTYUIRJRAVCNFSM6AAAAABDDEQNM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGM3TCOJUGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ollo69]

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?

[FilippoS1973]

I noticed that for a few seconds the buttons are not clickable (grey colour). this occurs at the beginning of the program and after the buttons have been used. It's like it takes a while to recap. this fits because it happens via colud I suppose. for the rest everything works perfectly, I also tested cross-app pause/resume functioning and it works. Il Dom 18 Feb 2024, 17:48 ollo69 ***@***.***> ha scritto:

…

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? — Reply to this email directly, view it on GitHub <#696 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOFYIF36C3EEZG4OGCRCW2LYUIWHDAVCNFSM6AAAAABDDEQNM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGM4DENZTGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ollo69]

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

[dcarosone]

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.

[dcarosone]

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.