How to Limit HTTP (POST/GET) Request?

It is roughly 6 per minute - not sure if that is a lot or not

It's a lot considering you have it set to repeat every 30 seconds. The most you should get is 3 (assuming I'm right about the the ST timeout). There's something else that we're missing here.

Are you seeing 6 per GET request (since you are sending to 2 different devices each time)?

1 Like

I haven't used RM 3.0 yet so I'm hesitant to say this...but I think you are seeing more GET requests than expected because Everytime there is a new active event (potentially every 20 seconds) it executes the True portion...regardless of the delay in your false statement.

I'm headed to bed but I think you can overcome this by using a global variable. Have the true statement test the variable (if = 1 for example) before executing, and then in that same statement change it to 0. Then in your false statement have it set the variable to 1 but after a delay. Both would need cancel on truth changes.

I know...a bit confusing but it seems right in my head. I will try to set this up on my Dev hub tomorrow and post a screenshot.

1 Like

I don't know why but I love seeing pictures like this.

It reminds me off home.

1 Like

You don't need a global variable, instead you can just use Private Boolean.

2 Likes

It is 6 GET request for each device. I think I could potentially do more if I time things right - it really depends on my motion activity.

Good idea! Really appreciate the help! Will try to look over the docs for RM 3.0 to figure out how to do this.

This was my first thought, but I couldn't figure out how to use it without needing an additional rule. If either the T or F statement set it to false, wouldn't that pretty much disable the rule altogether without a way to reenable it within the same rule?

This seems really strange to me. If you have a sensor that can only generate an active event every 20 seconds and a repeat for every 30 seconds, how can you be getting 6 GET's. Look at the logs for your motion sensor to confirm the inactive timeout.
If it's really 20 seconds, please enable logging on your rule and then capture a screenshot of your logs showing the 6 GET requests and motion sensor events in a minute timeframe.

Private Boolean does not impact the running of a rule directly. It is really just a boolean variable available to be used in a ruleā€™s conditions and/or actions. I have used PB in a laundry notification rule, to make sure there are no false notifications. If the power exceeds a certain threshold, set PB to True (this is in the True Action.). In the False Action, only if the PB is true, then send the notification and set the PB back to false.

Just an example of one use of PB.

1 Like

Thanks for the clarification Dan. I always assumed because it said "disable with pb" it meant the entire rule was disabled. I learn something new everyday.

1 Like

You can use the state of PB in the rule and in conditional actions. The disable option does entail a second rule, which has its uses also.

2 Likes

Ahh...so the pb is essentialy a variable local to that rule....but...can also be used to disable the rule if that option is chosen under Restrictions. No wonder so many of the examples that included PB's thatI looked at in the past didn't make sense to me.

1 Like

So after I send the initial GET request - I set the private boolean to true and then I can have it turn off after a delay (in select actions for False)? Does that sound right?

If I understand PB's correctly now, you would need to use a simple conditional (if) statement as well.

TRUE section
If pb = true
Then
send get (repeat)
set pb = false

FALSE section
set pb=true (delayed with cancel on truth change)

Honestly though, I think your focus needs to be why you are receiving that many GET's in minute and not how to counteract it. There is an underlying anomaly you need to address first. Just my opinion, but good luck.

2 Likes

With this config

I got 11 GET requests over 2.5 minutes. The raspberry pi screen is set to sleep 1 minute after inactivity - each GET requests resets this 1 minute timer.

These are the GET requests logs received by the Pi

10.0.2.4 - - [20/Jun/2019 12:07:31] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:08:01] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:08:31] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:08:44] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:09:01] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:09:14] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:09:22] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:09:31] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:09:44] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:09:52] "GET /wake HTTP/1.1" 200 -

xscreensaver-command: not active: idle timer reset.

10.0.2.4 - - [20/Jun/2019 12:10:02] "GET /wake HTTP/1.1" 200 -

Here is a video of the test: Dropbox - Link not found

Does this seem more reasonable? Or should we try to reduce the number further.

If a rule's PB is false and the rule is restricted by PB then none of the True or False actions will ever happen, correct?

If a rule is restricted nothing happens, irrespective of how it is restricted. So yes, PB false with PB restriction prohibits rule from running.

Okay....so, are what you and @ogiewon talking about is using the rules PB WITHOUT restricting by it? It had never occurred to me to use it that way. That's very interesting. Thanks!!

@stephack, don't feel bad, you're not the only one who's been thinking of PB totally differently this whole time.

1 Like

Private Boolean removes the need for a virtual switch in many circumstances. That was its original purpose. Another rule can set it, so no need for virtual switch for two rules to coordinate.