Working Schedule does not work

[Thormir84]

I've tried to set the working schedule for motion detection, but i think it doesn't work correctly.

I have set days and hour but the motion detection keeps sending notifications and recording videos.

What's wrong?

[black00019]

Hi the issue is also open? I have open a similar issue on Dietpi- MotionEye Github: https://github.com/MichaIng/DietPi/issues/6101

The project is under development?

[Thormir84]

The issue still exists for me, but i did not receive any feedback.

[MichaIng]

Thanks for reporting. There is quite much stuff to do/review here, and this is not my main project. If anyone is able to read Python, HTML and in case Jinja2 templates, please test and have a look into it.

Are you guys seeing any errors either in browser console when applying/changing these settings or in motionEye logs?

journalctl -u motioneye

[black00019]

I have this error: Feb 04 09:38:17 DietPi motion[1260512]: [0:motion] [NTC] [ALL] conf_load: Processing thread 0 - config file /etc/motioneye/motion.conf Feb 04 09:38:17 DietPi motion[1260512]: [0:motion] [NTC] [ALL] config_camera: Processing camera config file camera-1.conf Feb 04 09:38:17 DietPi motion[1260512]: [0:motion] [NTC] [ALL] motion_startup: Logging to syslog Feb 04 09:38:17 DietPi motion[1260512]: [0:motion] [NTC] [ALL] motion_startup: Motion 4.3.2 Started Feb 04 09:38:17 DietPi motion[1260512]: [0:motion] [NTC] [ALL] motion_startup: Using default log type (ALL) Feb 04 09:38:17 DietPi motion[1260512]: [0:motion] [NTC] [ALL] motion_startup: Using log type (ALL) log level (WRN) Feb 04 09:38:20 DietPi motion[1260512]: [1:ml1:Studio] [CRT] [NET] motion_init: Substream not available. Image sizes not modulo 16.

DietPi motion[1260512]: [1:ml1:Studio] [CRT] [NET] motion_init: Substream not available. Image sizes not modulo 16.

[Thormir84]

I have no error.

[hardwareadictos]

Same issue here, getting notifications whatever the working schedule is....

[Erpiovra87]

Hi! any update? same problem here

[ezequielitalia]

Hi! If you need some help for testing please let me know... I've the same issue. Running: motionEye Version | 0.43.1b1 Motion Version | 4.6.0 OS Version | Linux 5.10.0-28-amd64

[arseniov]

+1

Same issue here, I am running 0.43.1b1 on Docker :edge image and working schedule doesn't seem to be working at all. Whatever hour/schedule I set, motion detection is always on.

[Marijn0]

I think I found the problem, change active to ACTIVE in:

https://github.com/motioneye-project/motioneye/blob/2862efef79d9c107379459cea9edbb7bbc3d9161/motioneye/motionctl.py#L232

Solved the problem for me.

[Marijn0]

Here is the output of my journalctl -u motioneye when I enable motion detection in the working schedule:

May 25 18:38:03 raspberrypi motion[28489]: [0:cn0] [DBG] [STR] webu_parseurl: Sent url: /1/detection/status May 25 18:38:03 raspberrypi motion[28489]: [0:cn0] [DBG] [STR] webu_parseurl: Decoded url: /1/detection/status May 25 18:38:03 raspberrypi motion[28489]: [0:cn0] [DBG] [STR] webu_parseurl: camid: >1< cmd1: >detection< cmd2: >status< parm1:>< val1:>< parm2 :>< val2:>< May 25 18:38:03 raspberrypi motion[28489]: [0:wu0] [INF] [ALL] webu_answer_ctrl: Connection from: 127.0.0.1 May 25 18:38:03 raspberrypi meyectl[27974]: DEBUG: motion detection is disabled for camera with id May 25 18:38:03 raspberrypi meyectl[27974]: DEBUG: must enable motion detection for camera with id 1 (outside working schedule) May 25 18:38:03 raspberrypi meyectl[27974]: DEBUG: enabling motion detection for camera with id 1

And this is what I get when I deactivate motion detection in the working schedule:

May 25 18:36:13 raspberrypi motion[28231]: [0:cn0] [DBG] [STR] webu_parseurl: Sent url: /1/detection/status May 25 18:36:13 raspberrypi motion[28231]: [0:cn0] [DBG] [STR] webu_parseurl: Decoded url: /1/detection/status May 25 18:36:13 raspberrypi motion[28231]: [0:cn0] [DBG] [STR] webu_parseurl: camid: >1< cmd1: >detection< cmd2: >status< parm1:>< val1:>< parm2 :>< val2:>< May 25 18:36:13 raspberrypi motion[28231]: [0:wu0] [INF] [ALL] webu_answer_ctrl: Connection from: 127.0.0.1 May 25 18:36:13 raspberrypi meyectl[27974]: DEBUG: motion detection is disabled for camera with id

The problem here (I think) is that motioneye thinks motion detection is disabled while this is not the case. When I run:

curl http://localhost:7999/1/detection/status Camera 1 Detection status ACTIVE

This gives ACTIVE in capital letters and motioneye only searches for active,

url = f'http://127.0.0.1:{settings.MOTION_CONTROL_PORT}/{motion_camera_id}/detection/status'

 request = HTTPRequest(
     url,
     connect_timeout=_MOTION_CONTROL_TIMEOUT,
     request_timeout=_MOTION_CONTROL_TIMEOUT,
 )
 resp = await AsyncHTTPClient().fetch(request)
 if resp.error:
     return utils.GetMotionDetectionResult(None, error=utils.pretty_http_error(resp))

 resp_body = resp.body.decode('utf-8')
 enabled = bool(resp_body.count('active'))

When I edit: enabled = bool(resp_body.count('active')) to: enabled = bool(resp_body.count('ACTIVE'))
and when I deactivate motion detection I get this:

May 25 19:07:23 raspberrypi motion[30826]: [0:cn0] [DBG] [STR] webu_parseurl: Sent url: /1/detection/status May 25 19:07:23 raspberrypi motion[30826]: [0:cn0] [DBG] [STR] webu_parseurl: Decoded url: /1/detection/status May 25 19:07:23 raspberrypi motion[30826]: [0:cn0] [DBG] [STR] webu_parseurl: camid: >1< cmd1: >detection< cmd2: >status< parm1:>< val1:>< parm2 :>< val2:>< May 25 19:07:23 raspberrypi motion[30826]: [0:wu0] [INF] [ALL] webu_answer_ctrl: Connection from: 127.0.0.1 May 25 19:07:23 raspberrypi meyectl[30817]: DEBUG: motion detection is enabled for camera with id May 25 19:07:23 raspberrypi meyectl[30817]: DEBUG: must disable motion detection for camera with id 1 (during working schedule) May 25 19:07:23 raspberrypi meyectl[30817]: DEBUG: disabling motion detection for camera with id 1

Problem solved I think......

[zagrim]

Good catch! That would explain this well. Seems like response.body.lower().count('active') was accidentally changed to resp_body.count('active') (.lower() being dropped off) during refactoring here.

[Marijn0]

Thanks, hope someone can fix this in dev?

[zagrim]

There's the PR, I hope someone can do a quick test with that.

[MichaIng]

Merged, we'll push a new beta soon. I'll just test and in case merge #2903 as well.