[Netatmo] Rest call failed: statusCode=MAXIMUM_USAGE_REACHED

[jp-Ll]

I have the following Netatmo devices in my OH3.3 system:

• 6 Netatmo cameras (5x Presence, 1x Welcome),
• Video Doorbell and
• Netatmo Weather Station (1x indoor, 1x outdoor, wind, rain)

Reconnect Interval for Netatmo Account is set to 600.

There are warnings in the log saying I have reached the maximum user usage:

2022-09-06 09:38:51.368 [WARN ] [al.handler.capability.HomeCapability] - Error gettting Home informations : Rest call failed: statusCode=MAXIMUM_USAGE_REACHED, message=User usage reached
2022-09-06 09:38:51.440 [WARN ] [andler.capability.SecurityCapability] - Error retrieving last events of camera '70:ee:50:6f:xx:xx' : Rest call failed: statusCode=MAXIMUM_USAGE_REACHED, message=User usage reached
[same message for the other 5 cameras]
2022-09-06 09:45:21.369 [WARN ] [handler.capability.WeatherCapability] - Error retrieving weather data '70:ee:50:17:yy:yy' : Rest call failed: statusCode=MAXIMUM_USAGE_REACHED, message=User usage reached

Regardless of the warnings, the Binding/Things/Channel/Items work properly.

Are there any parameters to limit the number or the interval of Rest calls so that the maximum usage limit will not be reached?

Many thanks for your help!

Kind regards,
Joachim

---

openHAB 3.3.0 Release Build
Netatmo binding 3.3.0
Raspberry / Linux/5.10.103-v7l+ (arm)
Java Raspbian 11.0.16

[MrMontesa]

Same here. But for me it just started on 17th sept. Checked logs from beginning of July

swa@nuc:/var/log/openhab$ ls -al openhab.log*
-rw-r--r-- 1 openhab openhab    17518 Sep 18 12:16 openhab.log
-rw-r--r-- 1 openhab openhab    13217 Jul 28 21:18 openhab.log.1.gz
-rw-r--r-- 1 openhab openhab    54602 Aug 10 12:43 openhab.log.2.gz
-rw-r--r-- 1 openhab openhab     9306 Aug 10 21:29 openhab.log.3.gz
-rw-r--r-- 1 openhab openhab    11571 Aug 12 12:23 openhab.log.4.gz
-rw-r--r-- 1 openhab openhab   116862 Sep 12 14:08 openhab.log.5.gz
-rw-r--r-- 1 openhab openhab    21171 Sep 16 15:28 openhab.log.6.gz
-rw-r--r-- 1 openhab openhab    46611 Sep 18 12:12 openhab.log.7.gz
-rw-r--r-- 1 root    root    76830720 Jan 20  2021 openhab.logs.20200120.tar
swa@nuc:/var/log/openhab$ zcat openhab.log.*.gz |grep MAXIMUM_USAGE_REACHED | cut -d " " -f1 | sort -u
2022-09-17
2022-09-18
swa@nuc:/var/log/openhab$ grep MAXIMUM_USAGE_REACHED openhab.log
2022-09-18 12:13:27.746 [WARN ] [handler.capability.WeatherCapability] - Error retrieving weather data '70:ee:50:65:57:06' : Rest call failed: statusCode=MAXIMUM_USAGE_REACHED, message=User usage reached
2022-09-18 12:13:27.854 [WARN ] [al.handler.capability.HomeCapability] - Error gettting Home informations : Rest call failed: statusCode=MAXIMUM_USAGE_REACHED, message=User usage reached

Similar setup: OH3.3.0 Release with release Netatmo binding running on debian x86_64 host.
The MAC from the error message is my Netatmo indoor station.
Let me know if I can be of any help troubleshooting.

Thanks Sebastian

[lolodomo]

@clinique : does Netatmo communicate on what are the API limits?

We could have a counter of the requests in the last hour, and show it in a channel?
This could help to understand how many requests were done when the user reached the limit.

[clinique]

I found some elements here :
Per user limits

50 requests every 10 seconds
500 requests every hour

This means 8 requests per minute in average as a limit. I think this can be reached quite easily. We'll have to see how to be cautious on this.

[lolodomo]

This means 8 requests per minute in average as a limit. I think this can be reached quite easily. We'll have to see how to be cautious on this.

Oh yes, especially if you own several devices.
Look at how many devices @jp-Ll declares.

[clinique]

Yes, I suspect it's the getEvents request of security modules and persons that may multiply the number of requests. I'm going to take a look at this.

[lolodomo]

In complement to @clinique PR that reduces the number of requests, I propose to create another PR that will allow the user to monitor the number of requests executed during the last hour. The chance is that any executed request is finally handled by a unique method in the code and this method is even localized in the bridge handler. As a consequence, it will be very easy to implement that feature through an advanced new channel, that is probably just few lines of new code.

[lolodomo]

that is probably just few lines of new code

I thought I will do it in 10 minutes but ... no.
Unfortunately, this is not so easy because there is no more thing static definition (something very unusual - probably the only binding doing that at this level), everything is built dynamically in that binding, even the thing definition. Just adding a channel becomes not so easy.

[clinique]

that is probably just few lines of new code

I thought I will do it in 10 minutes but ... no. Unfortunately, this is not so easy because there is no more thing static definition (something very unusual - probably the only binding doing that at this level), everything is built dynamically in that binding, even the thing definition. Just adding a channel becomes not so easy.

I'll do it if you want.

[lolodomo]

For information, with the new monitoring channel, I can see that I was before at an average of 103 requests per hour and now with the different improvements I am now at around 82 requests per hour' with my setup.
@jp-Ll and @MrMontesa : will be interesting that you retry with the coming new 3.4 milestone.

[clinique]

Minus 20%. Not that bad ! Thanks for reporting @lolodomo

[lolodomo]

What value do you get @clinique with your own setup ?

I have now blocks of 3 requests, rather than 4 before.

PS: note that it is when running snapshot built last night, so not with the last fix.

[clinique]

This means that the event is served by the buffer instead of issuing a dedicated request.
I just installed latest milestone in production this morning. Will give you a feed-back when I'll have a bit of history.

[lolodomo]

Note that my home refresh interval is set to 150s, rather than the default 180s.
The problem could be reached by users setting this interval at a too much small value. @jp-Ll and @MrMontesa : did you update that setting or did you keep the default 180s ?

[MrMontesa]

Hey guys,
Thanks for investigating this issue. Currently I dont have any of the messages in my log, but I have to admit that the battery of my rain sensor drained and the thing is offline. This might reduce API calls as well.
My update interval is the default with 180s.

Will test the new milestone as soon as the Shelly DEV merged some buxfixes, so I can test both.
Thanks for your help.

[lolodomo]

@clinique : did you check how many requests you generate ?
Here is how it behaves for me:

[clinique]

Mine look like this :

Highest 140. Usually around 120 per hour.

[lolodomo]

For documentation, the 3 requests occurring at each refresh for security stuff: homesdata, homestatus and getevents.
Question to @clinique: is the homesdata request really needed ? It looks like the homestatus request retrieves almost all the data from the other request.