[netatmo] Binding does not reconnect after connection loss

[gletellier]

This issues is discussed in the forum here : https://community.openhab.org/t/no-update-of-netatmo-items/57576/13

Context

There has been a lot of connectivity errors on netatmo's side recently.
These connectivity problems are logged as :
2018-11-22 21:49:37.404 [ERROR] [nternal.handler.NetatmoBridgeHandler] - Unable to connect Netatmo API : 502 Bad Gateway" in openhab logs.

The problem is that when the Netatmos server are back online, the binding does not update sensors values.

Just restarting the container does not restore the connection. Deleting and re-creating the container is necessary to have the binding work again.

Your Environment

Openhab 2.4.0.M6 running in docker (amd64-debian)

[Clifford-Foster]

Seems as if the binding doesn't request a refresh token either.

[tzweistein]

Hi,
I have same issue.
Checking on Netatmo Forum I found they changed the API, so maybe the OH2.3 Netatmo binding need some update (out of my range)?
https://forum.netatmo.com/viewtopic.php?f=5&t=6912

[lolodomo]

This issue is now very old, I am not sure whether I already encountered it myself.
@clinique @Novanic : do you think the code is clean and handle reconnecting properly ?
If yes, we can close this issue.

[lolodomo]

@gletellier : do you still encounter this problem with recent versions of the binding ?

[Novanic]

I have never noticed this problem. But I have only a Presence camera where missing status updates aren't notable.

Actually I can't imagine that it still occurs, because the binding refreshes everything about every 5 minutes. But on the otherside it could be that the whole binding crashed so that there aren't any reconnect attempts.

Maybe someone could try to simulate / force reproduce it by using something like WireMock or by disconnecting the internet connection.

[clinique]

I often see also Bad gateway errors around 00AM and 02AM but it does not seem to affect the binding.

[lolodomo]

I see the refresh token job is run every 90 minutes (by default). The only case that could lead to this job not being rescheduled would be an uncaught exception in scheduleTokenInitAndRefresh. Only RetrofitError exception is currently caught. Are we sure that this is the only possible exception that could be thrown by this code:

                initializeApiClient();
                getPartnerApi().partnerdevices();
                connectionSucceed();

Maybe we could make safer the code by catching Exception in addition to RetrofitError to be sure that the job will not stop to be rescheduled due to an exception other than RetrofitError ?

[lolodomo]

I don't know in practice if getPartnerApi() could return null in particular circunstances ? If true, this could lead to a NPE not caught and the job stopping being rescheduled.

When adding null annotations, I didn't manage this case, probably because I didn't know what should be done in case it occurs.

@clinique ?