That’s a pitty. I switched to non-file based configuration for the thing, especially because if found it far easier to enter a new pin in the OH UI compared to changing the thing config. It might be caused by some internal changes in 4.x. I also like the idea of the pin channel. We just need somebody to find the time to implement and test it 
I wrote a telegram dialog to send new code via telegram to get it in the file.
If code would be channel I could send it there. But not to a web UI created thing
Some things I noteced to “changed” behavior:
Earlier Version
=> Textual Things File readed, Thing created
=> Login done by binding ==> Waiting 2FA
=> 2FA Code send to device
=> 2FA changed in text file
=> 2FA registered by binding, device online
Actual Version
=> Textual Things File readed, Thing created
=> Login done by binding ==> Waiting 2FA
=> 2FA Code send to device
=> 2FA changed in text file
=> Next Text file seems to be read, because changes in Name are registered by openhab. But new code ist not taken into account, so device still stucks with 2FA needed.
Work-Around (with advantages if having a lot of devices):
=> Move textual file away from config
=> Create thing in UI
=> Enter 2FA after Login
=> If device online delete thing in UI
=> move textual thing file to config again
=> As long name of thing is exactly the same like in manual thing earlier => textual thing takes the tokens and login stuff and is online directly.
The problem is that OH4 sais, that it re-reads the thing file, but it does provide the old values to the thing. I wrote a question in the dev section, to discuss this: Changes in thing config files not populated in OH4
The binding does 3 retries in case of errors. In that case here he icloud api responded, that your credentials are invalid. So in general it is a good behaviour that the binding does not blindly tries to re-authenticate with “invalid” credentials in a short sequence. It is a bit tricky to provide a bullet proof solution here… One could think of a more complex retry logic which increasing intervals, so that e.g. it is retried every few hours in such a case.
Good idea. I don’t know enough to propose a Pull Request.
I have created a rule using the exec binding to restart the iCloud binding bundle based on the expiration of a 20 minute timer that is triggered when the account thing goes offline.
Hi, thanks for care about this issue.
When bridge goes offline, I saw always same behavior with warnings in the log:
2023-09-02 02:20:25.444 [WARN ] [l.handler.ICloudAccountBridgeHandler] - Unable to refresh device data
java.net.ConnectException: null
at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:573) ~[java.net.http:?]
at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123) ~[java.net.http:?]
at org.openhab.binding.icloud.internal.ICloudSession.request(ICloudSession.java:139) ~[?:?]
at org.openhab.binding.icloud.internal.ICloudSession.post(ICloudSession.java:98) ~[?:?]
at org.openhab.binding.icloud.internal.FindMyIPhoneServiceManager.refreshClient(FindMyIPhoneServiceManager.java:64) ~[?:?]
at org.openhab.binding.icloud.internal.handler.ICloudAccountBridgeHandler.lambda$1(ICloudAccountBridgeHandler.java:121) ~[?:?]
at org.openhab.binding.icloud.internal.handler.ICloudAccountBridgeHandler.callApiWithRetryAndExceptionHandling(ICloudAccountBridgeHandler.java:185) ~[?:?]
at org.openhab.binding.icloud.internal.handler.ICloudAccountBridgeHandler.lambda$0(ICloudAccountBridgeHandler.java:116) ~[?:?]
at org.openhab.core.cache.ExpiringCache.refreshValue(ExpiringCache.java:101) ~[?:?]
at org.openhab.core.cache.ExpiringCache.getValue(ExpiringCache.java:72) ~[?:?]
at org.openhab.binding.icloud.internal.handler.ICloudAccountBridgeHandler.refreshData(ICloudAccountBridgeHandler.java:389) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
Caused by: java.net.ConnectException
at jdk.internal.net.http.common.Utils.toConnectException(Utils.java:1055) ~[java.net.http:?]
at jdk.internal.net.http.PlainHttpConnection.connectAsync(PlainHttpConnection.java:198) ~[java.net.http:?]
at jdk.internal.net.http.AsyncSSLConnection.connectAsync(AsyncSSLConnection.java:56) ~[java.net.http:?]
at jdk.internal.net.http.Http1Exchange.sendHeadersAsync(Http1Exchange.java:239) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.lambda$responseAsyncImpl0$9(Exchange.java:472) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.checkFor407(Exchange.java:404) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.lambda$responseAsyncImpl0$10(Exchange.java:476) ~[java.net.http:?]
at java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:934) ~[?:?]
at java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:950) ~[?:?]
at java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2340) ~[?:?]
at jdk.internal.net.http.Exchange.responseAsyncImpl0(Exchange.java:476) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.responseAsyncImpl(Exchange.java:380) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.responseAsync(Exchange.java:372) ~[java.net.http:?]
at jdk.internal.net.http.MultiExchange.responseAsyncImpl(MultiExchange.java:408) ~[java.net.http:?]
at jdk.internal.net.http.MultiExchange.lambda$responseAsyncImpl$7(MultiExchange.java:449) ~[java.net.http:?]
at java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:934) ~[?:?]
at java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:950) ~[?:?]
at java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2340) ~[?:?]
at jdk.internal.net.http.MultiExchange.responseAsyncImpl(MultiExchange.java:439) ~[java.net.http:?]
at jdk.internal.net.http.MultiExchange.lambda$responseAsync0$2(MultiExchange.java:341) ~[java.net.http:?]
at java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150) ~[?:?]
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) ~[?:?]
at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773) ~[?:?]
at jdk.internal.net.http.HttpClientImpl$DelegatingExecutor.execute(HttpClientImpl.java:157) ~[java.net.http:?]
at java.util.concurrent.CompletableFuture.completeAsync(CompletableFuture.java:2673) ~[?:?]
at jdk.internal.net.http.MultiExchange.responseAsync(MultiExchange.java:294) ~[java.net.http:?]
at jdk.internal.net.http.HttpClientImpl.sendAsync(HttpClientImpl.java:654) ~[java.net.http:?]
at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:552) ~[java.net.http:?]
... 16 more
Caused by: java.nio.channels.UnresolvedAddressException
at sun.nio.ch.Net.checkAddress(Net.java:149) ~[?:?]
at sun.nio.ch.Net.checkAddress(Net.java:157) ~[?:?]
at sun.nio.ch.SocketChannelImpl.checkRemote(SocketChannelImpl.java:816) ~[?:?]
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:839) ~[?:?]
at jdk.internal.net.http.PlainHttpConnection.lambda$connectAsync$0(PlainHttpConnection.java:183) ~[java.net.http:?]
at java.security.AccessController.doPrivileged(AccessController.java:569) ~[?:?]
at jdk.internal.net.http.PlainHttpConnection.connectAsync(PlainHttpConnection.java:185) ~[java.net.http:?]
at jdk.internal.net.http.AsyncSSLConnection.connectAsync(AsyncSSLConnection.java:56) ~[java.net.http:?]
at jdk.internal.net.http.Http1Exchange.sendHeadersAsync(Http1Exchange.java:239) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.lambda$responseAsyncImpl0$9(Exchange.java:472) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.checkFor407(Exchange.java:404) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.lambda$responseAsyncImpl0$10(Exchange.java:476) ~[java.net.http:?]
at java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:934) ~[?:?]
at java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:950) ~[?:?]
at java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2340) ~[?:?]
at jdk.internal.net.http.Exchange.responseAsyncImpl0(Exchange.java:476) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.responseAsyncImpl(Exchange.java:380) ~[java.net.http:?]
at jdk.internal.net.http.Exchange.responseAsync(Exchange.java:372) ~[java.net.http:?]
at jdk.internal.net.http.MultiExchange.responseAsyncImpl(MultiExchange.java:408) ~[java.net.http:?]
at jdk.internal.net.http.MultiExchange.lambda$responseAsyncImpl$7(MultiExchange.java:449) ~[java.net.http:?]
at java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:934) ~[?:?]
at java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:950) ~[?:?]
at java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2340) ~[?:?]
at jdk.internal.net.http.MultiExchange.responseAsyncImpl(MultiExchange.java:439) ~[java.net.http:?]
at jdk.internal.net.http.MultiExchange.lambda$responseAsync0$2(MultiExchange.java:341) ~[java.net.http:?]
at java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150) ~[?:?]
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) ~[?:?]
at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773) ~[?:?]
at jdk.internal.net.http.HttpClientImpl$DelegatingExecutor.execute(HttpClientImpl.java:157) ~[java.net.http:?]
at java.util.concurrent.CompletableFuture.completeAsync(CompletableFuture.java:2673) ~[?:?]
at jdk.internal.net.http.MultiExchange.responseAsync(MultiExchange.java:294) ~[java.net.http:?]
at jdk.internal.net.http.HttpClientImpl.sendAsync(HttpClientImpl.java:654) ~[java.net.http:?]
at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:552) ~[java.net.http:?]
... 16 more
2023-09-02 02:20:25.447 [INFO ] [tatus
Maybe the error management could be optimized? For me looks like the api had not been asked due to errors
I know this is a later topic, but I think it might resonate more here… 
Does anyone else encounter this (iCloud things permanently turning offline) issue?
Had sometimes with 5 minutes refresh interval. Less / no issues anymore as set refresh to 6 minutes.
Dear Colleagues,
i’m getting devices not account being disconnected time to time with below error:
Thing ‘icloud:device:3ec2e3e3f5:bb512bbf’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Reported offline by iCloud webservice
if I disable and enable it’s back to online for a few minutes
i´ve the same and i assume, this happens when the device is sleeping after a while of inactivity.
Any one facing the same and have solved it?
COMMUNICATION_ERROR - Reported offline by iCloud webservice
I don’t think it has to do with inactivity. I have 2 iPhone 14s that find my phone still works on even though they have an error status in openHAB. My iPhone 15, which I got recently and was installed on OH 4+ doesn’t work. IMO something is up with the binding. Phones that were installed a few major versions back work but show and error. A newer phone installed under 4.1 doesn’t work, but shows good status.
I also have IPhone 15 with OH4.1 For me it works in general. The problem pops up every few month for an older phone. Disabling and reenabling the device worked for me every time. The offline status is reported by icloud - it’s not clear when. But I still think there is an issue in the binding, which does not recover from that state.
So if you like to help, activate debug or tracing logging for the binding and post logs here when the issue arrises.
I posted my trace on the GitHub issue. For me, it’s not an issue of the phones dropping out after a while. My 15 stays online and never goes off. The only issue is the find my phone feature fails immediately when initiated with a timeout error code (see trace log on GitHub). It seems like whatever OH is sending to the iCloud API for that command is not what the server is expecting.
Marty
which version are you using?
4.1. My symptoms started on 4.0.x. Not sure which one.
For what it’s worth, I use the PyiCloud python module now, and I’ve been getting an increasing number of errors trying to connect recently. It may be an issue (or “feature” from Apple’s perspective) on Apple’s end.
1 Like
Which one?
I’m still facing issues … sad about.