How to Limit HTTP (POST/GET) Request?


Yeah, that's gonna be a real PITA to code and seems pretty silly, IMHO. Once you tell whatever system the motion sensor is active, it should assume that it still is until you tell it that it isn't. It shouldn't need reminding.


One could probably use the "repeat action" to send more requests then one on trigger.

But why not use the monitor off timer on the pi? Say when triggered by the http request it stays on for, say 5 minutes. Then you set your motion sensor to stay active for 5 minutes on motion. Then using a rule you set a repeat action every 6 minutes as long as motion is true.

Btw,I would love to see the script for the wake on http, got a Pi running MagicMirror2 and wouldlike to wake it witha a http request :grin:


This is all that the Pi is doing. I am using XScreenSaver which I have set to sleep the screen in 1 minute of inactivity. The command "xscreensaver-command -deactivate" basically simulates activity (i.e mouse movement). I basically have this command execute whenever the page :5000/wake is execute.

from flask import Flask, request
import os

app = Flask(__name__)

@app.route("/wake", methods=['GET'])
def wake():
    os.system("xscreensaver-command -deactivate")
    return "Awake"

if __name__=='__main__':'')


Wouldn't it be easier just to tell the Pi when to wake the screen up and then when to turn it off rather than telling it to constantly stay on. Seems like it would be more reliable to me. Then you could guarantee when it would turn off, not just guess at the minute. For example, maybe it's tied to a light also, so it turns off immediately if a light in the room turned off.


The Pi currently turns off if nobody is using it after a minute (like a screensaver). Having the screen turn on when motion is present or a door opens works fine - the problem is with the amount of messages being sent.

I plan on using a wired motion sensor integrated with Hubitat via Konnected. So when motion is present the Konnected board will send a message to Hubitat which will send the GET request to the Pi. The problem is that I can send hundreds of messages in a given hour. And with multiple Pi's this can increase substantially. I basically want to limit the amount of messages sent once per minute not for functionality rather for efficiency.

Having the Pi turn on when motion is present and turn off when motion is no longer present would work fine as well but it does not resolve the issue with the amount of messages being sent. And I wouldn't want the screen to turn off if motion stops and someone is using the screen.

Light switch might work for the main keypad but I am not sure about the bedroom. I still want the keypad to illuminate at night time without having to turn on the lights. I do plan on having brightness tied to the light switch though.

I am having the condo currently renovated so I still have to install and setup everything once its ready. I am slowly getting components and setting things up.


Maybe this would work for your purpose


I set it up according to @broberg's screenshot but it doesn't seem to be resending the GET command every 15 seconds while motion is active. Currently - while motion remains active it doesn't resend every 15 seconds but if motion becomes inactive and then active again it will resend. Any tips on how to resolve this?

Here is a video of what's going on

As you can see when the motion sensor initially becomes active the screen turns on. I keep the motion sensor active but it doesn't resend - eventually the screen goes to sleep and I let the motion sensor become inactive. Once the motion sensor becomes inactive and active again then it resends.

It seems that rule machine isn't resending the get command as specified - if so could this be a bug @bravenel @bobbyD - any assistance on this would be much appreciated!


That's because the repeat has to be before the actions you want to repeat.


It works - thanks @bravenel & @broberg. Is it also possible to limit the number of GET request I send? So the hub doesn't send more then once every 25 seconds (or any specified seconds amount)?

I am worried that I might overload the hub by having it tied into the motion sensor. If the motion continually goes active/inactive this can add up.

Would adding a delay (for 25 seconds) after the last GET request do the job? Or is there a better way to do this?


What is the timeout of the motion sensor? It won't go from True to False until the sensor times out. So, if you had a Iris V2 for example, you wouldn't get the false until there was no motion for 30 seconds. What you might want to do is put a delay on the false with a cancel on truth change. That way, you could build in your own longer timeout to keep your rule reporting that motion is active.


Yes, you can repeat n times and then stop.


You already have a ~29 second wait after the get requests now. Adding a delay after the Get's won't get you anything. :wink: hehe But seriously, it would be redundant.


For testing I am using a ST Motion Sensor but when I deploy the Raspberry Pi - I will be using Konnected on hard wired motion sensors that don’t have any delay (so they will produce lots of events).

So I should put a delay under select actions for false where I have stop action for this rule?



There's not delay timing built into the Konnected board or driver?


I don’t think so - don’t see an option to specify a delay. Perhaps @nate can confirm.


No, there is no delay. Nobody has ever asked for a delay -- typically people want it fast and accurate.


You can add the motion device to a Motion Zone using the built in Zone Motion Controllers app. This was how I was able to setup proper motion inactive delays to my Konnected sensors in the past.

Edit: it would need to be the Motion Aggregator type in the app.


Thanks for clarifying @nate. I guess delay isn’t the right word - for instance when the ST motion sensor detects motion it will become active and then inactive a few seconds after motion has stopped - typically wired sensors become inactive immediately. This will result in significantly more motion events so having it wait a few seconds before reporting inactive could potentially remediate this?

I am not sure if these extra motion events will result in any performance degradation on the Hubitat hub. But I could see it happen in a large install with 20+ motion sensors and multiple rules.

Hopefully my scenario makes sense.


In the false action, just add a “delay n seconds with cancel” before your existing false action. This will prevent the rule from reacting to a chatty motion sensor input.


When I had this setup I only had 8 sensors going and it did help fill up my logs quickly but didn't have an impact on my hub performance. This was many f\w revisions ago so I can't speak for the current environment.