If I rember correct, adoptopenJDK is available as 32bit for raspbian and confirmed working for openHAB.
Thanks, I will look into it.
Sorry, it is Zulu17
There was a 32bits version of adoptopenJDK available for arm as well. I installed it, upgrade to OH4 and it’s working like a charm. I don’t know if Zulu is better or not… but for now, it’s working. Txs.
1 Like
If it works, don’t change it 
1 Like
I used this binding for a long time without any problem. Today after an unexpected shutdown of my openhabian I had an error with the bridge thing telling me I have to remove the token to generate another one. I deleted the files in userdata/thinq but now I have the following error:
Generic Error in the LG API communication process
Tried almost everything (restart, delete of the bridge etc) without success.
Any suggestion?
I need more detail about the error (generally, aggregated messages in the log) to determine the real situation. But, based what you said, the exception should be:
- Error Openning LGThinq Token File. Try to delete it (in data directory) to the bridge automatically recreate it.
- Error Handling Token Configuration File.
- or, Error refreshing LGThinq Token. Try to delete it (in data directory) to the bridge automatically recreate it.
Generally, the binding will complain about Token when its try to open the file, but it’s corrupted, or if LG API return an error code saying the token is invalid. For this cases, you must to:
- disable the bridge
- go to OH_USERDATE/thinq
- remove thinqbridge-<BRIDGE_NAME>.json
- enable the bridge
The file should be created again with a valid token.
Try it out and let me know if it works.
It was a time problem. After the restart the clock was not synchronized. I discovered the problem by putting the logs in TRACE mode. I had also to delete the dryer thing and rediscover it after I created a new thing for the bridge.
Thanks a lot
Hi, folks ! I have good news !
I finally implemented some very cool features in this binding. I will summarize here these features and in the specific device channels (AC/HP, Fridges/Freezer, WM/DR/Tower) I will give more details about the changes specific for the devices.
– Addeded new “More Information” Channels Group:
- Enable Extended Info Collector - You can enable or disable the polling collector for extra-info. Notice that this channels was created to automate the collector buy rule and/or scheduler system.
- Current Power - The binding is supporting right now power consumption monitor. For now, only AC has it’s full mapped in channels. For the other devices, I will implement in a sequence if it supports: Fridges/Freezer apparently doesn’t support. WM V1/V2 supports, but not the instant power. They supports historical energy (by day, week, month, etc.) and I’m still thinking how to put this information in channels.
- Remaining Filter - analyses the condition of the device’s filter for some models that supports it like: AC/HP and Fridges. For now, only AC/HP was implemented. Fridges are coming in the row.
– Fine tuning binding polling system:
- Polling period when device if off - The default (and min) value is 10s, but you can change for any value you desired to reduce the band and cpu consumed to get status from LG API when the binding is turned off. Notice this is very usefull when you centralize the control of the device in OH.
- Polling period when device if on: The default (and min) value is 10s, but you can change for any value you desired to reduce the band and cpu consumed to get status from LG API when the binding is turned on. Notice that when the device in ON, is not a good practice to set up this config with higher values (more than 60s p. exemplo), because when the device is running, sensor reported from it could change dinamically.
- Enable Extra Info on power off - this config disable the extra-info (filter, power consumption, etc) when the device is turned off. Notice that to pull the extra-info data, the binding needs to call different endpoints compared to the Dashboard information. Then, when enabled, you will increase 2x the requests to LG API. So, it’s reasonable to keep this flag off because when the device is turned off, no changes will occur in extra-info.
You already know, but it doesn’t hurt to remember that it’s a good practice to backup the configuration and the current binding to prevent undesirable situations. After the backup and installation of the new binding, remove the Thing and discovery it again. It’s not necessary to delete the itens and links, because when you recreate the Thing, the OH will remember the old links if you keep the same name/id of the thing.
Enjoy and Cheers.
2 Likes
is it possible to read the current (not the setpoint) temperature for fridge/freezer with Extended Info Collector?
I don’t think so, @Constantinos_Contis. Normally, if LG App doesn’t have the information, the device doesn’t provide it. But, if you believe your Fridge provides this information by LG App or other way, let me know then I can try to get it.
By the way, it’s unbelievable LG Fridge doesn’t providing current temperatura. Figuring out that the Fridge must control the current temperature to know the time to stop cooling, it would be the very first sensor available to export, but the models of Fridge I tested didn’t provide the current temperatura by LG API.
Hello, @nemer. Very happy with the binding overall. I had a similar problem to one earlier, the binding went offline. As you suggested to another user, I:
- Disabled the binding,
- Deleted the thinqbridge-LG_Thinq_Bridge.json file
- Enabled the binding
I first receive the error “Generic Error in the LG API communication process” and within the logs:
2023-06-09 16:24:13.938 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' updated: UNINITIALIZED
2023-06-09 16:24:13.938 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' changed from OFFLINE (BRIDGE_OFFLINE) to UNINITIALIZED
2023-06-09 16:24:13.943 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' updated: UNINITIALIZED (HANDLER_MISSING_ERROR)
2023-06-09 16:24:13.944 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2023-06-09 16:24:13.944 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' updated: UNINITIALIZED
2023-06-09 16:24:13.945 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' changed from OFFLINE (BRIDGE_OFFLINE) to UNINITIALIZED
2023-06-09 16:24:13.950 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' updated: UNINITIALIZED (HANDLER_MISSING_ERROR)
2023-06-09 16:24:13.950 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2023-06-09 16:24:13.950 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'lgthinq:bridge:LG_Thinq_Bridge' updated: UNINITIALIZED
2023-06-09 16:24:13.950 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:bridge:LG_Thinq_Bridge' changed from OFFLINE (HANDLER_INITIALIZING_ERROR): Error refreshing LGThinq Token. Try to delete it (in data directory) to the bridge automatically recreate it. to UNINITIALIZED
2023-06-09 16:24:13.954 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'lgthinq:bridge:LG_Thinq_Bridge' updated: UNINITIALIZED (DISABLED)
2023-06-09 16:24:13.954 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:bridge:LG_Thinq_Bridge' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2023-06-09 16:24:13.955 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' updated: UNINITIALIZED (BRIDGE_UNINITIALIZED)
2023-06-09 16:24:13.955 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2023-06-09 16:24:13.955 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' updated: UNINITIALIZED (BRIDGE_UNINITIALIZED)
2023-06-09 16:24:13.955 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
After again disabling and reenabling the binding (without deleting the json file), the error “Error refreshing LGThinq Token. Try to delete it (in data directory) to the bridge automatically recreate it.”
Thoughts on this issue?
my LG App does not provide door info for my fridge but through the binding i can get the door open/close info just fine.So i though maybe there are some more “hiden” info inside api that we can use…
I updated to the 3.5.0-SNAPSHOT, created a new thing then the bridge began working. I had to relink my things (only a washer and dryer, so not many items created).
1 Like
Hummm… I will try to handle better in the binding this kind of situation in order to the binding fix itself.
Yes, but in this case, I’ve already sniffed the data exchange through the LG API and Fridge V2. There is no current temperature exchanged. These are the information Fridge expose:
“refState”:{
“atLeastOneDoorOpen”:“CLOSE”,
“displayLock”:“UNLOCK”,
“freezerTemp”:5.0,
“fridgeTemp”:3.0,
“tempUnit”:“CELSIUS”,
“expressMode”:“OFF”,
“activeSaving”:“OFF”,
“freshAirFilter”:“IGNORE”,
“monStatus”:“NORMAL”,
“smartSavingMode”:“SMARTGRID_DD_ON”,
“smartSavingRun”:“STOP”,
“waterFilter”:“0_MONTH”
}
Some of them are not handled by the LG App, like atLeastOneDoorOpen (as you montioned), smartSavingMode, displayLock and smartSavingRun. But the only temperature exposed are freezerTemp and fridgeTemp that is the setpoint.
Hi @nemer, awesome new features. Amazing job, congrats!
I was running a forked version from your binding since a while, but now I had to replace it with your latest version.
It took me sometime to realize that the channels now have a prefix (‘dashboard#’), but after that everything seems to be working fine besides one small issue I remember having fixed in my old fork.
I’m going to throw away my fork, it will be a hell to merge all changes you have made over it.
So I am trying to make a new fork to try copying whatever fix or improvement I have made and then submit a PR to you.
However I couldn’t find these latest features in your repo, I could notice you have now two branches, but none of them seems to have anything related to the “extended information”.
Could you please share some information about where are the latest version?
I also would like to help making this binding “official” and available on the OpenHab library.
Let me know if you are looking for help on that.
I’m going to throw away my fork, it will be a hell to merge all changes you have made over it.
It’s a good choice
So I am trying to make a new fork to try copying whatever fix or improvement I have made and then submit a PR to you.
Yes, it’s the better approach. I’m currently paused the implementation until next week, because I have some billed stuff to delivery and pay my accounts :-). Then, it’s a good time to send some PR’s if you want it.
However I couldn’t find these latest features in your repo, I could notice you have now two branches, but none of them seems to have anything related to the “extended information”.
Could you please share some information about where are the latest version?
I was not pushing the last features because they are not fully finished. I has just pushed the last code version in the branch: lgthinq-initial-contrib
Notice that this branch is a hybrid OH dependency version, anchored in the OH4 version. So, by default, maven you generate the target packed to OH4 depedency. But if you have OH3 server, then you can force maven to generate for OH3 dependencies with the command:
mvn clean install -pl :org.openhab.binding.lgthinq -Dohc.version=3.4.0 -Doh.java.version=11 -Dkaraf.version=4.3.7
I also would like to help making this binding “official” and available on the OpenHab library.
Let me know if you are looking for help on that.
Help is always welcomed :-D. However I have to organized myself about the tasks needed to finish this first scope of the binding and send to official avaliation. I will keep you in touch.
Regards.
Hi @nemer ,
No worries, I know how it is. I am also busy with work (with someone paying for it). But I will try to do something during this week, let’s see.
Great, I could see you just pushed latest changes.
Sounds good!
Thanks and regards,
Hi Nemer, I am using the latest version of org.openhab.binding.lgthinq-3.5.0-SNAPSHOT.jar and I have an issue with my aircon. If I switch ON the AC with the remote control the channel power keeps the status OFF (if I activate it from OH everything works fine). Could you please check? Thank you. Regards