Steam online, API timeout and full shutdown after a period

[Mithrox]

The problem

The last couple months (estimated) the Steam Online API integration has been working less than optimal. When you configure a set of accounts to check status on (for myself I have 25 accounts selected from my friend list), it will work okayish for a day or two, and then it will show unavailable more and more often, and over time just completely time out with a permanent unavailable.

If you leave the integration disabled for more than 24 hours, you can restart it and the cycle starts over again. I read somewhere that Steam API has 100.000 requests for day as limit, so my question he is; can we set a timer on when we check status for Steam? It would be sufficient with 1 time per minute, for a 24 hour period it would mean 36.000 API calls per day (if it require one call per account).

Last year this integration was "slower" in the sense that it had a 30 seconds update frequency, but I do think it's now quicker than 30 seconds, and maybe it should be reverted to keep the API session alive and not forcing it to timeout/close down.

What version of Home Assistant Core has the issue?

core-2023.6.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Core

Integration causing the issue

Steam Online

Link to integration documentation on our website

https://www.home-assistant.io/integrations/steam_online

Diagnostics information

Logger aiohttp.server.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

File "/usr/local/lib/python3.11/site-packages/steam/api.py", line 171, in download
    raise HTTPError("Server connection failed: {0} ({1})".format(reason, code))
steam.api.HTTPError: Server connection failed: Too Many Requests (429)

Logger: homeassistant.config_entries
Source: config_entries.py:429
First occurred: 12:07:45 (1 occurrences)
Last logged: 12:07:45

Config entry '<account-name>' for steam_online integration not ready yet: Server took too long to respond; Retrying in background

Additional information

No response

[home-assistant[bot]]

Hey there @tkdrob, mind taking a look at this issue as it has been labeled with an integration (steam_online) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `steam_online` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign steam_online` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

steam_online documentation steam_online source _{^{(message by IssueLinks)}}

[tkdrob]

Hello. Valve has been aggressively limiting requests. Polling 25 friends may not be a good choice. This integration does not currently take 429 errors into account however and should. If there are some friends that you don't need for automations, I suggest removing them from the integration. You can also disable polling for the integration and then run an automation with a time pattern to set your own slower polling rate. I am of course happy to hear your results and what you have done to make it stable.

[Mithrox]

Hello. Valve has been aggressively limiting requests. Polling 25 friends may not be a good choice. This integration does not currently take 429 errors into account however and should. If there are some friends that you don't need for automations, I suggest removing them from the integration. You can also disable polling for the integration and then run an automation with a time pattern to set your own slower polling rate. I am of course happy to hear your results and what you have done to make it stable.

Hi, and thank you for your reply.

I did have an automation which did this for the previous implementation, but it seems to be working differently now. Can I ask you how you should disable the polling, and what type of automation you would run now to trigger an update? I have slimmed it down to 17 right now, but ideally I'd like to stay around 20, and with a 1 min refresh (or even 30 sec) it would not make for issues if it's still 100k pr day.

A question though, would it be an option to implement a refresh setting in the integration, where you could set your own interval based on how many accounts you want to monitor?

Edit: And can I ask what the poll timer is defaulting to now?

[Mithrox]

I do also get this error quite often when I try to configure, I need to then restart HA and then try again

If you're talking about self-automating the process, I assume you mean disable the polling here?

And then use Reload for the whole service on your own given timer/automation?

Edit: Previously I used to do a reload_config_entry and it works when you do it on every single entity, but I assume there is a sensible way to reload the whole integration, that I am just not finding?

[Mithrox]

One drawback of reloading the entities every 2-3-4 minutes is that you get this pattern. So it gets broken up with a few seconds of unavailable every time you reload them. I wish there was a way to use the native polling, but lower the frequency so we do not hit the limit, at least within a certain about of accounts being monitored.

[tkdrob]

Follow my thumbs up and use an automation with a time pattern trigger and the homeassistant.update_entity service. I have not used this much so I think selecting all entities is not the best choice. I think the device should be used instead but check the docs.

[Mithrox]

Follow my thumbs up and use an automation with a time pattern trigger and the homeassistant.update_entity service. I have not used this much so I think selecting all entities is not the best choice. I think the device should be used instead but check the docs.

I have changed to update_entity now, I will see how that works, and I have put it on a 3 min timer with 10 accounts, it brings me to 4800 requests pr day, hopefully it should not be too many.

I am curious though how the built-in polling frequency has been tuned, is there a timer on it, and COULD that timer be made accessible so we could throttle it? It would save a lot of extra automation part if we had it in the GUI for the actual integration.

[Mithrox]

A little update. I have now reduced down to 10 accounts and I have changed it to a 2 min timer (also tried 4-5 min timer) and it just comes up as unavailable over and over again, as well as when reloading the sensor/entity. It can look like Steam has done some very significant changes to their API, is there a way to find out if that has now made this integration void for now? I would love to do that myself, but my abilities doesn't stretch to that level, so I am hoping maybe you would have some way to see if this can be adapted or if it's not usable anymore @tkdrob. Thanks.

[tkdrob]

It's working for me. Keep in mind that the summer sale is here. If you continue to pole, Valve probably has an extension built in to the 429 or timeout. I believe it is IP based. Just lay off it for a while.

[Mithrox]

It's working for me. Keep in mind that the summer sale is here. If you continue to pole, Valve probably has an extension built in to the 429 or timeout. I believe it is IP based. Just lay off it for a while.

Are you using the native polling now, or have you setup the automation with update_entity? And how many accounts have you put in? I have left it off first for 48 hours and it went straight back to a string of unavailable with some quick real status in between. I am leaving it off for a couple extra days now to see if Steam has done some weird weekly threshold or something.

[TNTPro]

I am having the same problems and I am only monitoring 1 account. I certainly don't think that I am reaching steams api limit.

[Mithrox]

I am having the same problems and I am only monitoring 1 account. I certainly don't think that I am reaching steams api limit.

I won't say "Great" but at least it's good it's more than me who has this issue :)

It did work more or less good until some weeks back (maybe 2023.6 or around there), but now it's just going into more and more unavailable until it stops completely.

[Mithrox]

The problem persists, and as the one above also have an issue with just 1 user account, it seems weird that it should reach it's limit. I am though asking again, is it possible to implement a throttling mechanism on the integration so we can balance it with longer timeouts between checking status? I know it's not there now, but would that be an option to implement @tkdrob?

I now have 9 accounts enabled and its worked perfectly for now the 18th of July until today, but today I am getting more and more "unavailable" states across the 9 accounts, and so it seems I am reaching some sort of limit again. One would actually think it's a weekly limit or something, but in the Steam documentation it still says this:

"You are limited to one hundred thousand (100,000) calls to the Steam Web API per day"

Would any change to the integration be possible, or are we stuck with it not being able to use for even a single account anymore, or could a change to the implementation for at least test-purposes be an option? From the look of the logbook it seems the integration is now checking on a 30 seconds basis, would a 60 seconds basis be possible to test out?

[tkdrob]

From your original post, it looks like you are getting 2 completely different errors. 429 and timeouts. So are you still getting both? 100,000 calls would be about 1 call per second but each call is not always just for one account. Some of the data comes from different endpoints.

If you are getting timeouts, well that's Steam for you and nothing can be done. Previous issues opened for that were promptly closed as they should be. There would be much more to be done with the underlying code. I am not aware of an async library for Steam that does things more efficiently with the API calls. That may not even solve the issue anyways.

Now this is an open source project and worth the time for those who want to make something work. I've been busy with other things and this is not immediately in my sights on things to do. It was my goal to make a config flow and optimize the integration without having to make a PyPI package. That has been done.

[Mithrox]

From your original post, it looks like you are getting 2 completely different errors. 429 and timeouts. So are you still getting both? 100,000 calls would be about 1 call per second but each call is not always just for one account. Some of the data comes from different endpoints.

The only errors I get is the 429 Too many requests, it's not showing up as often yet, but they tend to come more and more close before it stops completely (still working now, but expecting it to give more and more unavailable over night).

I know full well you're doing this for free and on your own time, and I am super grateful for all the hard working coders who are involved with HA. I wish I could participate, but I am becoming an old man (even though I still game) and so I struggle with learning coding these days. I was merely asking if it were possible to implement a user-based throttle function so we could limit the amount of calls being made.

I know the reload function in an automation can be used, but even with a longer reload period, I still got the same issue after a few days like I do with the native integration with polling enabled.

[tkdrob]

The user-based throttle function you are seeking has been discussed above. What still would be implemented is an exponential back-off when we hit 429 errors. A function like that should belong in the PyPI package IMO. That would not be available for manipulation by the user.

Edit: or some other calculation. This might be available in API returned data or it might not be. Some APIs actually tell us how many calls are still available.

[Mithrox]

One would think that if 100.000 per day is what they write, it should be correct. But as our previous discussion show, with 1 (or 9 in my case), its not nearly 100k per day with 30 sec refresh timer (which the logbook suggests). So apparently Steam isn't following their own documentation.

I guess this is what you were referring to above here, but probably not available from Steam:

(https://www.rfc-editor.org/rfc/rfc6585#section-4). 429 Too Many Requests

The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting").

The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.

For example:

HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600

Too Many Requests

I only allow 50 requests per hour to this Web site per logged in user. Try again soon.

Note that this specification does not define how the origin server identifies the user, nor how it counts requests. For example, an origin server that is limiting request rates can do so based upon counts of requests on a per-resource basis, across the entire server, or even among a set of servers. Likewise, it might identify the user by its authentication credentials, or a stateful cookie.

Responses with the 429 status code MUST NOT be stored by a cache.

[tkdrob]

One would think that if 100.000 per day is what they write, it should be correct. But as our previous discussion show, with 1 (or 9 in my case), its not nearly 100k per day with 30 sec refresh timer (which the logbook suggests). So apparently Steam isn't following their own documentation.

Not necessarily true but they could have changed it without updating the docs. If you never had this issue for months and then it started happening, then yes their docs are probably out-of-date.

[Mithrox]

"The Steam servers accept 200 request in five minutes or on average one request every 1.5 seconds."

There seem to be several posts suggestion they are looking at bulks on shorter periods too, so the 100k pr day may be correct, but has to be spread out (which this integration kinda does though).

[Mithrox]

Same overnight again, it's now closing in on full stop, as is seen by the logbook visualization. I'll stop the sensor again for a few days and then just do a very long reload automation again.

[Mithrox]

Since I have no way of seeing the amount of API calls from the integration itself, I setup another way of getting this data and sensors. I use Node Red to send the API request for each account I want to monitor, and then I store the status in an input_text helper in HA, and presenting it as the sensor instead of the sensor from the integration. It seems to work fine, no blocker at all there, even though I did not disable the integration before next rounds of unavailable's started coming. I currently have 3 accounts set to check status every 1 minute, and 7 more to check every 2 minutes.

I hope someone smarter than me can work out why the integration don't work, as it's a much more smooth way of getting the information, this is just a workaround until it's up and running stable again - if ever.

Thanks for your responses @tkdrob, I really appreciate your interaction and efforts.

@TNTPro If you use Node Red and need any help in getting this way working, just let me know.

[Mithrox]

Just an update, I have no run the Node Red way of getting the status for about 2 weeks (since the last post here). I have had zero issues with timeout, and I now check 3 accounts every 1 minute and 9 more accounts every 2 minutes. Referring to @TNTPro post above here, he only has 1 account being monitored and he still get the timeout issues, can there be some other function of the integration causing this issue on a regular basis for us? It looks like the API limits wouldn't be the problem since it works with 12 accounts on a regular schedule.

I can try to increase the amount of accounts I am checking to see if I reach a limit somewhere, but since it requires quite a bit more setup with helper node and flows, it's not something I'd need to do unless for testing purposes.

[tannerkrewson]

Thanks for making this thread! Personally, mine only go unavailable for very short periods of time, but very often, so I made a template sensor that uses the previous non-unavailable value:

template:
  - sensor:
    - name: steam_12345_filtered
      state: "{{ states('sensor.steam_12345') if states('sensor.steam_12345') != 'unavailable' else states('sensor.steam_12345_filtered') }}"
      attributes:
        game: "{{ state_attr('sensor.steam_12345', 'game') if state_attr('sensor.steam_12345', 'game') != 'unavailable' else state_attr('sensor.steam_12345_filtered', 'game') }}"

[Mithrox]

Thanks for making this thread! Personally, mine only go unavailable for very short periods of time, but very often, so I made a template sensor that uses the previous non-unavailable value:

So you're saying yours never fully stop in the end? Mine has longer and longer timeouts/unavailable until in the end it just remains unavailable

The other method I use now, with Node Red rest calls still works perfectly so the integration does something different since it returns unavailable even with just one account.

[tannerkrewson]

I’m checking four accounts, and no, my unavailables don’t get longer and longer, they’re just constant little slivers

On Sun, Aug 27, 2023 at 7:02 AM Mithrox @.***> wrote:

Thanks for making this thread! Personally, mine only go unavailable for very short periods of time, but very often, so I made a template sensor that uses the previous non-unavailable value:

So you're saying yours never fully stop in the end? Mine has longer and longer timeouts/unavailable until in the end it just remains unavailable

The other method I use now, with Node Red rest calls still works perfectly so the integration does something different since it returns unavailable even with just one account.

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/95702#issuecomment-1694636753, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACANVM3KW4TONLG2WBS6UXTXXMSL7ANCNFSM6AAAAAAZ3LLI2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Scarriffle]

Hey I am checking 20 accounts, and it worked since june, but since 2 weeks i have also problems with it. it starts with a short data gap, it gets bigger and bigger until it has no more data for a certain time

[Mithrox]

I am happy to see I was not the only one that saw this then, it's exactly the same as I was seeing on my end.

My work-around through API calls through Node Red is working fine, no timeouts, so there has to be more load through the integration for some reason.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Johnyboy1984]

Good day,

Even after all Home Assistant updates, the problem still persists. I'm currently querying 10 users on Steam.

Home Assistant Core: 2024.1.2 Home Assistant Supervisor: 2023.12.0 Home Assistant Operationg System: 11.3 Frontend: 20240104.0

Logger: homeassistant.components.steam_online Source: helpers/update_coordinator.py:332 Integration: Steam (documentation, issues) First occurred: 15:38:19 (8 occurrences) Last logged: 16:15:39

Error fetching steam_online data: Server connection failed: Too Many Requests (429) Error fetching steam_online data: Server took too long to respond

[tkdrob]

Cut down the number of requested accounts in the options. That has been the theme for this entire issue. Some day, a debouncer can be used to slow the requests down. Nothing else can be done since Valve lowered the limits greatly.

[Johnyboy1984]

Good day,

What is the maximum number of accounts you should request?

[tkdrob]

Good day,

What is the maximum number of accounts you should request?

All trial and error. This issue is full of what people have done and whether it worked or not.

[mkanet]

Just a note. I only track 3 account. These accounts will frequently show unavailable (all at the same time); but seem to stay that way for very long. There is definitely something wrong with this integration that needs to be adjusted/fix in the integration itself. It wasn't doing this a couple of months ago.

[Mithrox]

I have run my own way of getting account status for months now, and just a few days ago it stopped working. What I do is use Node Red to send JSON request, then parse the data I get back and then put that into sensors. It was great for 20+ accounts, but now it stops working with 1 account if I check more than once within a minute or so. I used to have 3 accounts I checked every 1 minute and then about 15 accounts I checked every two minutes, so basically 21 accounts every 2 minutes.

I haven't been able to find anything about actual data on the Steam API, but it's clear they are doing some major throttling now, it's ridiculous. I just wanted to put this there, so you understand it's not just about the HA integration, but actually the Steam API.

[mkanet]

Isn't there a developer who maintains this integration who can take a look at this? Or, are we SOL? Its kind of lame try to add workarounds to the actual issue.

[Mithrox]

Maybe you should read what I said over again? The integration is using Steam API and Steam is throttling badly, it throws up 429 errors (too many requests) after the first request. So it's not the developers fault.

I wish the integration would have a choice for refresh rate though, and a function to keep last state until it get a new valid reply.

[mkanet]

Maybe you should read what I said over again? The integration is using Steam API and Steam is throttling badly, it throws up 429 errors (too many requests) after the first request. So it's not the developers fault.

I wish the integration would have a choice for refresh rate though, and a function to keep the last state until it gets a new valid reply.

🙄 I went ahead and fixed the issue directly in the source files using the API guidelines described below: https://steamcommunity.com/discussions/forum/1/3492005739881311668/ According to findings on the ArchiSteamFarm github, extension developers will need to forcibly cap the number of matches returned to 2000 (via the "count" parameter), and introduce other delays to guarantee only 1 request every 4 seconds.

A quick description of what I did:

• I made the necessary changes to the source code; specifically coordinator.py
• Dropped the source files to \config\custom_components\steam_online
• Reboot Home Assistant

...and, whala! It started working correctly right after HA reboot! It's been working ever since.

For a quick fix, just follow these instructions:

1. Download: https://1drv.ms/u/s!Ao1OD_Zte2lpo4ZJkh1bdSogoDZpzg?e=Om55Jh
2. Extract the folder steam_online (and its contents) from the downloaded zip file to: \config\custom_components\ so it ultimately looks like: `\config\custom_components\steam_online
3. Reboot

You can see the changes I made if you look at the modified coordinator.py when compared to the original one coordinator (original).py with a Diff tool.

Hopefully, an official HA Core Integration developer can make these changes to the official repo. I can't do it myself.

Enjoy!

PS: A special thanks to ArchiSteamFarm GitHub developers who originally identified what specifically was causing the issue and how to fix it.

WARNING: I need to do a little more testing. I think I actually need the original Steam integration GUI even for the custom integration that replaces it. More soon...

[Mithrox]

Good work. The 2000 calls, is that a 6 hour or 24 hour limit? And did you test how quick you can send the next request after the first one?

[mkanet]

Good work. The 2000 calls, is that a 6 hour or 24 hour limit? And did you test how quick you can send the next request after the first one?

Okay, I finally got it working 100% for me now. It's been working without issues. However, I only have 3 Steam entities to test with.

I added an intelligent dynamic rate-limiter. I also made existing API calls more efficient by not retrieving the same game icons over and over again. Hopefully, these enhancements will work for people with more entities too. Please test and let me know. It should be significantly better than the original Steam integration.

Instructions:

Download: steam_online.zip

Then, extract the folder inside the zip file and its contents to your Home Assistant folder: \config\custom_components. The full path should ultimately be \config\custom_components\steam_online. Hopefully, you guys already know how to do this (use SMB or SSH). Ultimately, the folder and its contents should look similar to this:

Reboot.

After you reboot, navigate to Home Assistant's GUI: Settings/Devices & services/Steam. Check to see if it looks something similar to the below screenshot that says "Custom Integration". That's how you'll know you're using the enhanced version of Steam Integration instead of the builtin one. If it doesn't say "Custom Integration", that means you will need to remove your current regular Steam integration from the GUI, then reboot one more time.... Then, add the Steam integration again via the GUI.. except this time it should hopefully use the enhanced one you manually added.

That's it. I'm crossing my fingers that it works for everyone here. If it does, hopefully, we can convince a real Home Assistant Core Developer to use my enhanced code.

[nopantsfriday]

@mkanet I've implemented your fix. No errors for me in 24 hours using 14 entities. I will add more entities now and keep you posted.

[mkanet]

@mkanet I've implemented your fix. No errors for me in 24 hours using 14 entities. I will add more entities now and keep you posted.

Thanks for confirming. I didnt want to submit a PR for this without getting confirmation that it works.

[nopantsfriday]

@mkanet I've implemented your fix. No errors for me in 24 hours using 14 entities. I will add more entities now and keep you posted.

Thanks for confirming. I didnt want to submit a PR for this without getting confirmation that it works.

No errors in 24 hours using 22 entities.

[nopantsfriday]

I have to withdraw my statement. I guess 22 entities are creating too much requests. steam.api.HTTPError: Server connection failed: Too Many Requests (429) In general your version works fine except that it will also hit the request limit when using too many entities to check. According to the web Valve allows 100.000 API hits per day. I've backed down to the 14 entities which I really would like to track and see how it goes from here.

[mkanet]

I have to withdraw my statement. I guess 22 entities are creating too much requests. steam.api.HTTPError: Server connection failed: Too Many Requests (429) In general your version works fine except that it will also hit the request limit when using too many entities to check. According to the web Valve allows 100.000 API hits per day. I've backed down to the 14 entities which I really would like to track and see how it goes from here.

Thanks for the feedback. Yeah, I forgot to tell you that there's no way around their API limits. The changes I made at least prevented the integration from wasting API requests on stupid things like refreshing the same images/icons. I also added a smart rate-limiter to at least back away from sending API queries temporarily until the rate limit clears.

@nopantsfriday How long does it take after you start Home Assistant when 22 entities cause the error? If you can, please let me know what is the maximum number of entities can it safely handle. I might be able add something where it warns you when you added too many entities.

[nopantsfriday]

Hey @mkanet

Thank you for your patience!

Thanks for the feedback. Yeah, I forgot to tell you that there's no way around their API limits. The changes I made at least prevented the integration from wasting API requests on stupid things like refreshing the same images/icons. I also added a smart rate-limiter to at least back away from sending API queries temporarily until the rate limit clears.

No worries. That's what I understood from your comment.

@nopantsfriday How long does it take after you start Home Assistant when 22 entities cause the error? If you can, please let me know what is the maximum number of entities can it safely handle. I might be able add something where it warns you when you added too many entities.

I'll try my best to find it out. First I thought that 14 entities would not hit the daily limit but I am down to 13 now and the entities start to become unknown every few minutes again. I guess I did not see that in the beginning. From now on I'll have a look at the history / logbook to identify this. The new approach is to start with 3 entities and increasing it by one entity every 24 hours / couple of days.

Not sure if it helps you but that's what I am seeing in the logs:

2024-02-19 15:00:32.843 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 256, in _handle_refresh_interval
    await self._async_refresh(log_failures=True, scheduled=True)
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 412, in _async_refresh
    self.async_update_listeners()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 183, in async_update_listeners
    update_callback()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 492, in _handle_coordinator_update
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 989, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1110, in _async_write_ha_state
    state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1050, in __async_calculate_state
    attr.update(self.extra_state_attributes or {})
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/steam_online/sensor.py", line 84, in extra_state_attributes
    if level := self.coordinator.data[self.entity_description.key]["level"]:
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^`

Ideally Valve would support webhooks but I don't see this coming. Ultimately, the best solution to this problem would be intelligent rate limiting, which calculates the API requests and adjusts the update frequency so that the daily limit is not exceeded.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[nopantsfriday]

@mkanet 11 entities are working fine for me.

[mkanet]

@mkanet 11 entities are working fine for me.

Yeah, they are working for me too. :-) I'm going to see if I can submit a PR to Steam Integration with the changes I made. If you don't hear from me in a few weeks, can you please send a friendly reminder message here?

Just to be clear, this fix isn't meant to completely circumvent Steam API limits, it's just much more efficient than it used to be during polling.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[mkanet]

Sorry, i havent had time to provide the necessary PR. Im just replying here to keep this issue open until I get a chance to do that.