motion sensor triggers script to often

[AriePiet]

Hi guys,

I have a motion sensor (pir) connected to a wemos, it sends t's dat to Domoticz, works perfect. On Domoticz i havesetup a switc (motion sensor) and when activated it should run a script.
The script start a camera record for 5 minutes. So far so good!

But when during this 5 minutes the switch is activated again, the scripts runs again after the first run.

Is there a way to surpress this? Thus after the inital trigger the motion sensor should be ignored for a predfined time?

[jvdz]

What is the script that you use?
You could test in the script for the time passed since the last change and when that is less than 5 minutes you skip the recording.

[waltervl]

And you can do that for example with code example:

Code: Select all

if (domoticz.devices('My PIR').lastUpdate.minutesAgo > 5) then
      -- your code to record camera for 5 minutes
end

[AriePiet]

Sorry for the late reply, was away for my work.

Anyway, my script looks like below. Any idea how to use your suggestion into that?
To make sure that the scrpit does not start during a current run, i use the PID file option, which works great.

#!/bin/bash
#
# =======================================================
# Start PID file creation and check for running instances
# =======================================================
PIDFILE=/home/pi/domoticz/scripts/hik-tuin-vid.pid
#
# ----- script running? -----
[[ -s $PIDFILE ]] && exit
#
# no, create pidfile
echo $BASHPID > $PIDFILE
#
# =================
# End PID file check
# =================
# Start Variables
# =================
# currenttime - Check the current time to let the script run or not
# DATE - Datetime stamp, i always start with this variable, otherwise you might encounter problems in your script, if the path is changed
# IP - the ip address of your camera
# PORT - the port on which the camera operates
# Rec_Time - duration of recording in seconds
# PATH - where the recording will be saved
# FILENAME - Name of the file/recording - Datetime is added! (format/extension for me is always mp4)
# Telegram_bot_id - Telegram bot id, bot from who you'll receive notifications
# Telegram_chat_id - Telegram chat id, this can be a personal or a group chat id. Howto set-up is not covered in this script!
# Ret_days - Amount of days to save previous recordings, play around with this
#
currenttime=$(date +%H:%M)
DATE=`date '+%Y-%m-%d_%H-%M'`
IP=1.1.1.1
PORT=554
Loginname=[username]
Password=[password]
Rec_Time=300
PATH='/DATA/media/videos/achtertuin'
FILENAME="achtertuin-$DATE.mp4"
Ret_days=7
starttime=01:00
endtime=06:30
#
# ================
# End variables
# ================
# Start time check
# ================
#
if [[ "$currenttime" > "$starttime" ]] || [[ "$currenttime" < "$endtime" ]]
then
#
# ===============
# End time check
# ===============
# Start recording
# ===============
#
#/usr/bin/ffmpeg -i rtsp://$IP:$PORT/onvif1 -vcodec copy -t $Rec_Time -y $PATH/$FILENAME;
/usr/bin/ffmpeg -i rtsp://$Loginname:$Password@$IP:554/Streaming/Channels/101/ -vcodec copy -t $Rec_Time -y $PATH/$FILENAME;
#
# ======================
# End Recording
# ======================
# Start Clean-up
# Remove recording(s) (To prevent you harddisk from filling up) and to remove the PID file.
# =========================================================================================
#
/usr/bin/find $PATH -type f -name '*.mp4' -mtime +$Ret_days -exec /bin/rm {} \;
/bin/rm /home/pi/domoticz/scripts/hik-tuin-vid.pid
#
# =============
# End Clean-up
# =============
#
exit 0
else
#
# Remove the PID file for the second exit (when the script did not run, because of time window).
# ==============================================================================================
#
/bin/rm /home/pi/domoticz/scripts/hik-tuin-vid.pid
exit 0
fi

[waltervl]

This is a bash script that runs outside Domoticz.

How do you trigger the bash script now from Domoticz? With device action script (through Edit button on device widget)?

[lost]

Any idea how to use your suggestion into that?

I suppose this bash script is triggered by setting it as an "on" action script in PIR switch setup?

If so, IMO, you have the event system that stops the process because ffpmeg is not started in background so script does not finish quickly but should last until current capture ends. If so, you may see logs that complains for event system locked for more than 10s. Then process killed much earlier than you expect so able to restart at next PIR trigger.

As your script is designed to end only when ffmpeg finishes (otherwise, if you add "&" at the end of your ffpmeg call line, your PID check would not do it's job), you may try to add "&" at the end of PIR switch setup line to have the whole script started in background but then not locking domoticz events.

If this does not work (never tried this myself), you'll have to rework you script to have it start ffmpeg in background and, as the script will end soon, instead of checking script PID file, you'll have to keep ffmpeg PID that was started & then check if still active to decide if script must exit immediately or not. This check should replace current one.

Something like this, to have ffmpeg started in background (notice "&" at end of line) and get it's PID (if ffmpeg starts OK, PID zeroed in case of ffmpeg returning an error, no issue as PID's starts at 1 for init process so no possible zero PID) after some basic error checking:

Code: Select all

/usr/bin/ffmpeg -i rtsp://$Loginname:$Password@$IP:554/Streaming/Channels/101/ -vcodec copy -t $Rec_Time -y $PATH/$FILENAME &
[ $? -eq 0 ] && echo -n !$ > my_ffmpeg.pid || echo -n 0 > my_ffmpeg.pid

Will store ffmpeg pid in a file for next script call to check if stored PID exists (if so, a directory /proc/PID will exist on a Linux system), for instance like this, from script beginning (with preceding pid file check existence for 1st script call):

Code: Select all

[ -f my_ffmpeg.pid ] && [ -d /proc/$(cat my_ffmpeg.pid) ] && exit

You may test this quickly from a console using sleep command for instance:

Code: Select all

sleep 10 & [ $? -eq 0 ] && echo -n $! > sleep.pid || echo -n 0  > sleep.pid

Then, whithin 10s (background launched sleep process still active) this check will print "ok", afterwards this'll be "ko" (sleep will have exited):

Code: Select all

[ -f sleep.pid ] && [ -d /proc/$(cat sleep.pid) ] && echo ok || echo ko

[AriePiet]

If i try that, then the script stops (or hangs) after fmpeg finishes i gues at the the point of the & or right after that.

I changed my script to:

/usr/bin/ffmpeg -i rtsp://$Loginname:$Password@$IP:554/Streaming/Channels/101/ -vcodec copy -t $Rec_Time -y $PATH/$FILENAME &
[ $? -eq 0 ] && echo -n !$ > hik-tuin-vid.pid || echo -n 0 > hik-tuin-vid.pid

Where i point to my actual pid file name, which is nescessarry i guess, even though with a different name it still fails.

Below what i see when i run the script manually:
frame= 381 fps= 27 q=-1.0 size= 2560kB time=00:00:14.95 bitrate=1402.2kbits/
frame= 382 fps= 27 q=-1.0 Lsize= 2669kB time=00:00:14.99 bitrate=1457.8kbits
/s speed=1.06x
video:2666kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.093659%

[habahabahaba]

The way is to run your script not as an "on" action script in PIR switch setup but to wright Dzvents script where to check ".lastUpdate.minutesAgo > 5" as waltervl said

[lost]

Where i point to my actual pid file name, which is nescessarry i guess, even though with a different name it still fails.

If you did not modify the test to check the exact ffmpeg PID (not just a file presence as you former did) that was last started & stored, this'll of course not work!

You may launch script manually from a shell, after adding a "set -x" (or just some script sections between a "set -x" and a "set +x" for debug) at the head to get full script prints/branches taken... and see if immediate restarts exits as expected + check pid file content.

I believed you were quite used to bash for choosing to use it, but if that's not the case... can't debug this for you!

You may also go Lua/dzVent and use system calls to ffmpeg as other suggested, to be able to limit ffmpeg calls (a bit over capture duration, to avoid having to check some ffmpeg pid) as otherwise suggested using Domoticz Lua/dzVent integration to make this easier. But also take care not to lock the event system with a script that does not return quickly, so calling ffpmeg from Lua using os.system() will also need the "&" at the end of the command string. Check domoticz logs does not complain...

[AriePiet]

@lost

I think i got it, it's running now like it should, but with some other issues not related to my initial problem.
I am going to adjust my script and extend it with other things and fix other things too.

@habahabahaba

Regarding; Lua/dzVent, no idea howto do/use it

Thank you for the useful info, if i have it running like i want, i let you guys know.

[lost]

Good! Best is to have it work with some scripting language you can handle, at least for now.

But what makes Domoticz interesting vs other home management SW is the embedded scripting possibilities. I don't mention Blockly as a graphical stuff for beginners, if you can already write bash stuff... but Lua (a language designed for being embedded in other programs in the first place, that is also used in some games to handle some user made stuff/automations) and it's Domoticz specific derivative dzVent.

As Lua is not specific to Domoticz, many ressources can be found on the web, an interpreter may also be installed to test some code snippets out of domoticz as you would do in Python for instance... It's a table based language and useful domoticz internals are made accessible through table items reads/additions, see wiki:
https://wiki.domoticz.com/LUA_commands

+Lua is much easier to read than bash IMO, and easy to learn! You also avoid the complexity of accessing domoticz managed hardware though the HTTP/JSON API as external scripts in bash would need (using utilities like curl):
https://wiki.domoticz.com/Domoticz_API/JSON_URL%27s

There is also dzVent, a Domoticz specific Lua extension, but don't use it myself (when I started with Domoticz 10 years ago, dzVent was not to current level and Lua more widely used... another reason is my brain is a bit reluctant to it's syntax!):
https://wiki.domoticz.com/DzVents:_next ... _scripting

Anyway, whatever the language used, one constant: Mostly 2 types of scripts, defined by the file name (if not using webUI editor) for Lua:
-Time scripts, that are triggered every minute by domoticz event system.
-Device scripts, that are triggered on any device change (=> need to test/filter on device idx or name).

There is also variable type scripts, triggered on user variables change, but that's IMO for corner-case usage: User variables, created from domoticz webUI, can be used to keep data from one device or time script run to another so mostly useful from the script that use them and mostly for pure Lua as dzVent add a more generic way to setup some persistent data (file based).

See directory ~/domoticz/scripts/
From there, 1 subdir per supported script language with "demo/example" scripts inside.

You have also Python as a possibility, but for scripts Lua/dzVent is IMO much better option than python ; python is only mandatory for plugins but that's mostly designed to handle devices/protocols that are not supported in domoticz core, so usually much more complex code compared with user scripts to glue devices/actions together... so better forget it's existence.

I hereupper talked about in webUI script edition or setting up script files in the ~/domoticz/scripts/LANGUAGE directory: IMHO, prefer second possibility!

Reason: In webUI edition puts scripts in domoticz database, not files as separate edition. I myself never managed to hang Domoticz with some script programming errors (Lua interpreter and Domoticz event system/data handling looks quite robust), but others did... and then? Much easier (and less risky) to move/rename a faulty script file before restarting domoticz than getting around something in DB that is automatically loaded at startup!

[AriePiet]

It's up and running now for some time and it seems to do exactly what i want.

I think the issue was, that in the orignal script i worked with a pid file for the whole script, where in the new script the PID is created only for the FFMPEG process. This way the process runs in the background and Domoticz doesn't care about he script, but only looks at the settings of the switch itself. In this switch it's the off delay time.

Thanks for helping and pointing me in the right direction!