Open GitCray opened 1 year ago
Hey, I also have the issue. My workaround for now is to just turn off auto night mode and manually enable it (sending /usr/bin/autonight.sh on through SSH). For some reason the curl command to do it works when auto night is enabled, but does not when it is disabled.
I tried to add a script to the /etc/init.d folder to enable automatically nightmode (I want it always on, personally) but when I reboot it gets deleted for some reason. I really need to quickly learn about embedded Linux hahah.
I've seen this too. It tends to happen when there is a white object in view of the camera, and it can't tell the difference between that and light.
@GitCray You can find the docs on what most of the autonight parameters are here.
For the others, you can find my best guess here.
I did try to write something to automatically adjust the parameters if the camera was flapping in and out of autonight mode, but it needed more work. If anyone is interested in picking up where I left off, I can share my code.
@DannySauval if you want to make a change to the /etc/init.d folder that persists reboots, then you need to add it to your SD card in /config/overlay/etc/init.d/ and it will be copied over to the camera on every restart. If you do want to learn more about how this project is set up, the Buildroot docs are comprehensive. This project has been a really fun way for me to get deep into embedded Linux!
@martinbutt Just a quick note, as I haven't seen anyone else mentioning this, files don't have to be put on an SD card to be made persistent. You can simply put them in the /config/overlay/
directory on the camera itself. I don't have an SD card in my cameras, everything in my /config/overlay/
dir gets copied to the appropriate location on reboot.
I would be interested in taking a crack at your code. I'm pulling my hair out lately around sunrise and sunset, my cameras bounce between night mode on and off constantly for about 30 minutes. One of the cameras has a window in frame, and the other one gets the light coming in from another window, so they go crazy and it often results in the API crashing and/or a desync between actual night mode status and the value written in the /tmp/night_mode_enabled
file, and/or the ir_cut filter getting stuck and requiring a reboot to reset things.
I'm loving this project, but the documentation is sorely lacking and google has been very little help. It took me ages to find the autonight.c file in the ingenic_videocap repo because I was searching for "openmiko autonight". For some reason this issue wasn't coming up in my searches and I was completely baffled about what those mysterious parameters were for.
@HaLo2FrEeEk yes you are right, you could add the files to /config/overlay/
instead of an SD card.
Here is the patch file for my first pass at this. auto-calibrate-nightmode.patch.txt. The part that detects the camera is flipping too often works. The idea is that it will adjust the settings gradually until it finds a point where it is no longer flipping. I didn't find time to tweak the parameters and get it working.
The night mode issue seems to be the only major one left, so it you make headway on that it would be great! I also love this project, and didn't want to see it fall away. If you have documentation updates/suggestions, let me know.
Interesting idea! I'll take a look at this a bit later.
For the time being I just watch
ed the exposure, iridix, and WB values right as the camera started switching back and forth and observed that it never goes lower than 890000. I just changed the -2
param's first argument to 890000 and I haven't had a bounce yet. I'm sure this is not the ideal solution long-term but it worked for now.
I still have no idea what the "iridix" value represents, google just comes up with random stuff, nothing relevant. And further, the wait time portions of the -2 and -3 params seem to be ignored somehow. I see in the code how they're used, so I don't know why it doesn't work. I agree with your best guess for what they do, it should maintain the state for that number of seconds before switching, but it doesn't seem to actually do that, it just switches as soon as the values go outside of the range. Perhaps it's not seconds but a smaller time scale?
As far as documentation improvements, that's not really my strong suit, but I do have a plan to make a video "tutorial" about setting up a Wyze V2 camera with OpenMiko and the various settings that I had to figure out, as well as some other cool stuff that can be done. Eventually...
Perhaps it's not seconds but a smaller time scale?
It's this sleep
in the main loop that implements the wait period, so it should be seconds.
Let me know how you get on.
Yeah, with the following config, mine only works one way - flips to night mode, but doesn't flip back.
AUTONIGHT_PARAMS="-j 3 -w 3 -1 1200000 -2 930000,14,10 -3 3000,17,8"
WyzeCam v2. Release v1.0.0-alpha.2
In certain situation with weak lighting, for example, a 0.12w light, the camera is going crazy switching constantly to and from night mode.
What are those parameters mean? How can I configure it to be less sensitive or something like that? AUTONIGHT_PARAMS="-j 3 -w 3 -1 1200000 -2 930000,14,10 -3 3000,17,8"