Thanks, I'll give it a try.
I spent some time tinkering with this app too, in an attempt to revive it, and for me scheduling this new function did it. I think re-initializing the entire app is a bit extreme. Only regenerating the certificate used for the mqtt connection was enough for me.
The big question still remains - why the hell does the mqtt connection go stale after a while, with no error, or any other indication. I was able to reproduce this issue without Hubitat, so maybe LG would know better.
def reregister() {
register()
def certAndSubData = getCertAndSub()
logger("debug", "getCertAndSub = ${certAndSubData}")
state.cert = certAndSubData.certificatePem
state.subscriptions = certAndSubData.subscriptions
}
2 Likes
For sure I knew there are other ways better than this. I'm not a developer so since I did it, it was working fine. I'll look at our suggestion this weekend Thank you.
You are right everything was running fine until last year. I don't know what change LG did.
I found a similar solution, I added a small command/function in the device driver (I'm only using a fridge) that calls parent.register and used RM to call it periodically. And so far it has been usable.
But I agree with your question, why does it go 'stale'?
So right now I have only register() on a 2 hour schedule and it's been running for 3 days without issues. 
I also tried 6 hours and eventually went stale. I think 2 hours is reasonable, and it doesn't need any certificate to be regenerated.
Since LG doesn't document their API, I can only assume they implemented this "stale clients check" to avoid clogging their mqtt broker with messages for clients that never come back.
Where do I specify this in the code? Thank you!
Should be:
if (hasV1Device)
schedule("0 */1 * * * ? *", refreshV1Devices)
else
schedule("0 45 */2 * * ? *", register)
And then you'd need to re-initialize the Thinq integration app to create the schedule and confirm that is there:
1 Like
Thanks for the info. I went back and grabbed the raw groovy programming from the link you provided in your message, then pasted that in the ThinQ Integration and changed the code to read:
Then I re-initialized the Thinq app by opening the app and logging into the LG site and added the URL hit next and confirmed my 2 devices (I've got a washer and dryer). All worked well. The only question I have is... when I go to the Scheduled jobs in the Logs, I see the following... (and it seems like it's running every minute... and it's "refreshV1Devices" not "register" like you have in your picture above.)
Hm, do you have any "v2" devices?
No - just the V1 devices.
I thought this stale mqtt connection only affects v2 devices. Unfortunately, I don't have any v1's to test. Do also not get any updates from your devices after a while?
Yep- unfortunately, it's been an issue with v1 devices for years. I've worked around it in the past by running a webcore piston every 5 mins reinitializing my 2 devices.
Then just remove the "else" so it applies to any device, not just v2's and see what happens!
1 Like
Has anyone been able to make an automation that announces when a cycle is complete? I am trying to announce to my sonos speakers that the wash or dry has completed
I used to have rules set up but I deleted them because the dog doesn't like it when the Google lady speaks. I think it basically looked like this:
Dryer rule:
Trigger:
- Dryer CurrentState = "drying"
Actions:
- Wait for event: Dryer CurrentState= "power off"
- Send notification through your Sonos speaker
(you can also use CurrentState = "end" if you have any issues with it not detecting the "power off" event)
The washer rule is the same with the washer device in place of the dryer device.
1 Like
That worked, thanks!
I’ve had everything working for ages but noticed that my error logs have been getting spammed with ThinQ Errors. Anyone else seeing this and if so, any potential solutions? Would going the Azure Private Key route prove more reliable and less errors, and if so, how the heck do you get that to work. Traditionally I just log into ThinQ Cloud servers.
Here’s an example error (some numbers changed):
AMerrorThinQ Integration lgEdmPost(https://aic.lgthinq.com:46030/api/rti/rtiMon, [cmd:Mon, cmdOpt:Start, deviceId:d12121212-1763-11e8-b7f6-12121212121, workId:d12121212-b2a1-4a13-8d37-1212121212], true) - NOT_CONNECTED_DEVICE
Today I finally migrated off of the LG Thinq App/driver that was deprecated several years ago. My main reason for integration was to simply let us know via voice when the wash and dryers were done. I had used Echo Speaks to accomplish this along with this deprecated driver and app.
As some of you know, LG’s implementation has been unreliable to put it kindly. I managed to do this by loading the ThinQ app on many iPhone, and buried in the settings is a connection to both Google and Alexa. I was able to easily reconnect the ThinQ Skill on Alexa to my washers and dryer once again. I wouldn’t bother trying to do it directly through the ThinQ app as traditionally that caused many login headaches.
After reconnection, you can go into your Echo/Alexa devices, make sure they’re added there and click on their settings. Note that the Alexa App may show the LG Devices as unresponsive, even if they are turned on. The very top part wants to alert you to marketing stuff. You can click that area and on a following page deselect that. But there’s also a notifications section. If you click that you can add your echo devices that you want to be alerted to via voice. Now when my wash or drier finishes, it automatically sends out voice alerts telling me “your [device] is done.”
1 Like
TBH, the LG ThinQ app/driver have been working reliably for me. When I first installed it back in March, I also noticed quite a bit of flakiness, but I found that if I click initialize in the driver page it would work again. So I wrote a simple webcore piston that reinitializes the washer and dryer drivers every 10 minutes. Has worked flawlessly since…. Except it seems when new terms/conditions need to be accepted. At that point, I just have to load the LG app and login/accept.
1 Like
I've been seeing connection errors as well, and from reading other threads, I think this is due to the DNS caching issue on the hub and not anything with this app or LG. There's a long discussion about it here:
It seems the hubs are holding on to DNS results longer than they should, and when cloud service IP addresses change (due to load balancing or other reasons), the hub can't connect to the service anymore. A reboot fixes it.
I expect a fix will be coming soon as the issue is affecting a lot of users, but in the meantime I'm probably going to set up an automatic reboot after two connection errors get logged.
2 Likes
