New Release 5.0.23 Limits ON/OFF commands one every five minutes

[marksmanaz]

I know you were trying to limit state queries but ON/OFF commands are now limited also. Is this intentional to the new design? If so you killed a major functionality of this node.

Thanks

[bbindreiter]

Yes it's intentional. People are running scripts that set device states every X minutes to the same value.

The rate limit we've seen in the past is due to too many commands to the Alexa API and we had to limit the requests on our side so they'll lift their limiting maybe again.

Maybe you have a good idea on how to better limit on pur side?

[smcgann99]

I have to agree with marksmanaz this will cripple the nodes for many uses. Shouldn't any limiting by Amazon be per user, and not affect everyone ? I have a flow for playing media which needs to request states if for example a track is skipped. Why the limit of 5 minutes, it is way too long ? The RBE node can block repeated messages, can't this functionallity be added to nodes ?

[bbindreiter]

Yes, I guess they are rate-limiting per access token, so per user. But the thing is that in general there are millions of requests coming from this node and Amazon doesn't like that, understandably. I'm speculating here, but I guess to them it doesn't make any difference how many requests are coming from each user, all they care about is how many in total.

Hi, can you please describe your use case in detail so I, and everyone else, can think of how this can be finetuned.

[smcgann99]

My flow was based on the example music player included with alexa-remote2. Having just checked the flow, your limit changes are the least of the problems now ! After the recent changes by Amazon to prime music service, it is no longer possible to pick a play list, skips are limited and shuffel & repeat comands are now disabled - Thanks Amazon !! ;-(

I guess you may still be able to build in some kind of RBE function, to block repeated (same) messages though.

[marksmanaz]

What if you limit the amount of queries and commands per hour rather than each query and command per device per five minutes? Give each user/token 60 queries/command per hour and let them decide how to use them best for their situation.

[bbindreiter]

I see your point, but that would still allow polling of device states every 1 minute, which is exactly what we need to get rid of.

[smcgann99]

I have for example a node which sets muliple device states back to default values (smart bulbs) and then another following that which turns them all off. I'm assuming that this will not work with the upgrade ?

[bbindreiter]

That will work as the request payloads differ.

Requests with the exact same payload will be limited to 1 per 5 minutes. So you could set something to off and then to on again immediately after. But to set it to off again you'd need to wait 5 minutes.

[marksmanaz]

I see your point, but that would still allow polling of device states every 1 minute, which is exactly what we need to get rid of.

But as it is now I could have 5 devices and query them each every five minutes staggered and still have made 60 queries in an hour; one every minute and still make on/off command as well. I know everyone's situation is different but a hourly quota for all requests works better for me and it would limit the over all requests to the API. You are just forcing users to manage their allotted quota for themselves. If they make 60 request in the first five minutes in the hour they are screwed for the rest of the hour. It's up to them to spread them out responsibly.

[marksmanaz]

I think the problem is people want to know the state of their sensors and are querying them every 2 to 5 seconds to detect a state change. That is what happens when people use proprietary cloud based devices that cant be polled locally. In all my installations I use mqtt to monitor state change of sensors locally. I bet if you just limited the state queries that would be enough. On/off request may not be the problem.

[marksmanaz]

Is there anyway to get that type of data from amazon to break down the request types being made?

[bbindreiter]

I think the problem is people want to know the state of their sensors and are querying them every 2 to 5 seconds to detect a state change. That is what happens when people use proprietary cloud based devices that cant be polled locally. In all my installations I use mqtt to monitor state change of sensors locally. I bet if you just limited the state queries that would be enough. On/off request may not be the problem.

You may be right. In the beginning I planned to only limit queries, but I was explicitly asked to think about set requests as well. For instance, you could set the same value in a script that runs every minute. Now to circumvent the limitation it'd be necessary to remember the last state and only execute the node when it changes. I am willing to lower the 5 minutes of set requests in a future update when we hear back from Amazon.

Is there anyway to get that type of data from amazon to break down the request types being made?

Not aware of any.

[smcgann99]

Now to circumvent the limitation it'd be necessary to remember the last state and only execute the node when it changes.

I think this is the only way to prevent some bad scripts for spoiling things for everyone ;-)

[XLixl4snSU]

Should've read the changelogs before upgrading. I use this node to turn on and off lights im my rooms and a rate limit of 5 minutes is wayyy to much, why is this restriction enforced on turning something on/off instead of only polling device states? I mean I can tell echo devices to turn on and off lamps as often as I want.

Did Amazon threaten you with consequences? If that's the case you should publicly disclose what they demand so we can work on a solution as a community.

[bbindreiter]

If I get feedback that we have significantly reduced the load we can start thinking about relaxing the set state requests, maybe 3 minutes.

Is turning on/off the light 3 times within 5 minutes common?

It's possible to enter a room -> turn lights on, leave the room -> turn lights off. 300s after you've turned them on first it's possible to turn them on again.

[XLixl4snSU]

Sometimes you come back to a room because you forgot something. Sitting 5 Minutes in the dark is not an option. But since this is open source everybody who needs more frequent access can just use an old version or remove the restriction in a fork. But I understand that with maintaining such a project comes a certain responsibility.

[richsimpson]

My use case that is failing since the update is a Switchbot lock.

I was using the node in one flow to check state every 5 minutes to set a Boolean in Hass.

For a lock or unlock command, I ignore the status as it may be old and not updated. So a 'goodnight' routine will just try to lock, then immediately attempt to check the state via the node and update in Hass. 5 minutes later the routine will check the Hass state and either do nothing (if it locked ok) or attempt to lock again (if it remains unlocked).

What I am seeing is the 5-minute update may be repeated when the door locks (within the 5 mins) and so the routine fails. The next 5 minute one also fails. And I then end up in a loop of attempts at offset 5 min intervals that never resolves.

Or If an unlock command has run and not captured the updated status due to the rate limit, the routine sees the state as locked still and doesn't then lock the door - nor check it 5 mins later....

Updated my setup to use Webhooks for the main Boolean change - via IFTTT but likely to find a better way. Now I can avoid the limit for the status check - have that running only every 30 mins now as a backup to the webhooks.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.