new auto-night-mode binary tuning #332
Comments
|
Doesn't seem to work for me either. |
|
I can confirm it works on my cameras (which I admit is hardly helpful :-P). I'll need a bit more detail to help. @khseal can you confirm the autonight application is running after you've started it? Also, it'd be helpful if you could do the following:
|
|
[root@DAFANG:~]# /system/sdcard/bin/autonight -v Binary work. 548 is light on and 188 light off. But nothing happens, the camera mode does not switch. |
|
It looks like your values are significantly different than on my camera. You can modify the on/off setpoints via the The -O parameter will set the trigger on point. The night mode will be turned on when the windowed average drops below that value. The -F parameter will set the trigger off point. The night mode will be turned off when the windowed average goes above that value. If you're curious, doing a Currently the default thresholds are 40 and 45. I chose these values arbitrarily based on my cameras, so they're likely wrong once we account for sensor/ADC variance. I'll make note of your numbers. Hopefully others can report their numbers as well. And then we'll have (perhaps) saner defaults. It'd probably be a good idea to have these numbers adjustable via the web interface, but I haven't dug into that side of things yet. |
|
my numbers are quite different: Current value: 3056.28 low of ~200 to a high of 3000 edit: I actually tested at my install location, and setting |
|
I have the same parameters as you. Yesterday I tested in the evening and when the light was turned on, the parameter was low. |
|
@nphil That's a good idea, I'll add some calibration function to the autonight application. I'm also going to go back and make sure my assumptions on how the sensor is connected to the ADC are sound. @khseal Are you saying that you're still unable to get the autonight application to switch into night mode? If so, try running the application on the command line with your -O and -F values and see if it ever prints out it's setting night mode on or off. |
|
After writing the parameters to the config, it all worked for me. |
jmtatsch
changed the title
|
Does anybody have an idea. When I have the command /system/sdcard/bin/autonight -v with the lights on or off it gives a result of about 700. Window (5) Avg: 698.16 |
|
That's curious. Is there something occluding the light sensor on your camera? Another thought is to try one of the other ADC devices via the |
|
Sorry for my ignorance. What am I doing wrong [root@DAFANG:dev]# /dev/jz_adc_aux_1 -D |
|
Oh, sorry. That would be the command line option for autonight so something like: |
|
Hi. However, /dev/jz_adc_aux_1 (and 2) behave better and can be calibrated. In my case the night threshold is below 650. |
|
@ivanfor thanks for the details. It's odd that the device is different. I wonder if the /dev/jz_adc_aux* devices aren't constrained to actual physical devices (and yours ends up being detected in a different order than mine). I'll do some digging to figure that out. Worst case, hopefully I can add some code to autonight that'll pick the right device. I suppose it's also possible there are hardware revisions that might have changed which ADC the light sensor is connected to, but that seems less likely. |
|
Thanks guys, I think my sensor is broken no matter which one I take, the value don't change |
|
I have one camera that works well during the day: But mostly reads garbage at night: Any ideas why that might be? |
|
I've got some ideas, but it'll be hard to know for sure without digging around in the kernel driver. Do you see any jz_adc_aux messages showing up in your kernel logs? There are some suspect things in the driver: int jz_adc_aux_sample_volt(enum aux_ch channels,struct jz_adc_aux *jz_adc_aux)
{
unsigned long tmp;
unsigned int sadc_volt = 0;
if (!jz_adc_aux) {
printk("jz_adc_aux is null ! return\n");
return -EINVAL;
}
INIT_COMPLETION(jz_adc_aux->read_completion);
jz_adc_aux->cell->enable(jz_adc_aux->pdev);
enable_irq(jz_adc_aux->irq);
restart:
tmp = wait_for_completion_interruptible_timeout(&jz_adc_aux->read_completion, HZ);
if (tmp > 0) {
sadc_volt = readl(jz_adc_aux->base) & 0xfff;
} else if(tmp == -ERESTARTSYS){
goto restart;
}
else {
sadc_volt = tmp ? tmp : -ETIMEDOUT;
}
if (sadc_volt < 0) {
printk("jz_adc_aux read value error!!\n");
return -EIO;
}
disable_irq(jz_adc_aux->irq);
jz_adc_aux->cell->disable(jz_adc_aux->pdev);
sadc_volt = sadc_volt * VREF_ADC / AUXCONST;
return sadc_volt;
}This code is responsible for fetching the ADC value and then doing a bit of math on it and returning it in millivolts (?). It's curious the code takes steps to not return right away on error (in the first if block) but then has enough if block that returns on error right after that, but before the ADC and IRQ have been disabled. It seems like it might be a cut/copy error, maybe? I wonder if this is causing a subsequent read to return garbage? I also noticed the jz_adc_aux_sample_volt() function uses readl() to read the value from the ADC register, but the jz_adc_aux_read_value() function above it uses readw(). Both immediately mask the bottom 12 bits, so maybe it doesn't matter. But it's curious that it does it both ways. It's also curious that jz_adc_aux_read_value() doesn't appear to be called anywhere else, so may be vestigial. Finally, I also noticed that the VREF_ADC is modifiable via ioctl(). Perhaps this value is modified in different versions of the cameras, so that might explain why we've seen different values. Unfortunately, the driver doesn't have a mechanism for me to read back the current VREF_ADC value. So it looks like I'll have to get the kernel building to get to the bottom of that one too :-/. Hopefully I can get some time this this weekend and take a look. I'm not sure how easy it'll be to build and boot a kernel to debug the driver. As a quick fix, it might make sense to have the autonight application test the sanity of the value it just read back and ignore (or try again) if it read the wrong value. EDIT: spelling |
|
I have the same situation as @tijo1987 , autonight always reads around 860 regardless of actual light condition. The other ADC devices don't return meaningful numbers either. The Dafang camera is brand new. |
|
@amagnolo I'm not sure why this might be. Could it be the kernel version your camera shipped with is different than mine? What does |
|
|
hm, |
|
@jthwho was the uname output useful? |
|
I suppose there is a hardware change, which changed the way how the ADC is readed. Maybe some Pin needs to be HIGH or LOW to allow a correct measurement. There is a way we can try to find out the issue:
I suppose we may find a solution like this |
|
@amagnolo I haven't had a chance to look at this yet. @EliasKotlyar suggestion of running the original firmware would certainly be helpful, if you're able to get to the serial header. |
|
Unfortunately I don't think I can connect to serial headers, I'm not even sure what they are. |
|
@b0ssman, |
|
@nik0, |
|
you compiled it or you use the one I provided?
|
|
Hi. |
|
@nik0 I can run this command in the browser and night vision comes on, however it does not do automatically, even though Autonight is enabled https://user:pass@[ip-address]/cgi-bin/action.cgi?cmd=ir_led_on |
|
@ark-git If your camera is newer, you likely don't have a light sensor. See #332 (comment) and #332 (comment) for more information |
|
I have a Wyze Cam V2 which was detecting night mode when it was with the default Wyze Cam V2 software. |
|
@ark-git the v2 does not have a light sensor. the stock firmware is using software to detect whether to turn on/off nightvision, something this custom software can't do yet. |
|
Is there a command line (from ssh) for the above commands so that I can create a script to run these commands? |
|
Anyway to tell if the camera has light sensor or not? I got a Xiaofang 1S and auto night doesn’t seem to work. I’ve also ran “autonight -v” and the value is always 816 regardless if my lights are on or off. So it seems like it doesn’t have a light sensor but I’d like to get some confirmation |
|
Hi. I have tried to do something similar on Xiaofang as yawor did on his Dafang and I want to share. So I have decided to go the easiest possible way just by creating a voltage divider: List of used components: Using this configuration and "-O 200 -F 300" it does work, but if there is a surface somewhere near it toggles, so something like "-O 300 -F 400" is also good. During the day (cloudy) it is something like "2500". "Populated" PCB: End result: |
|
Hello I have Dafang with light sensor but there is problem with readings from autonight - some are good, some are much to high... sometimes the readings from jz_adc_aux_1 are good, sometimes from jz_adc_aux_0 Maybe there is way to eliminate this higher values? |
|
Hi @piotrdal, I re-compiled the |
|
I'll try, it would be great, I plan to use this sensor to turn on light :-) |
|
I use home assistant to turn night mode on and off, based on sunrise/sunset. It works perfectly and has removed a real hassle I had with these cameras. NOTE: This assumes the following:
|
|
As a workaround I just leave the camera in night mode 24/7 :) Would the software be developed to do analysis of the video to automatically turn on night mode on the newer models? |
|
@aartrost what exactly is your recompiled autonight file doing? will autonight be working with dafang without light sensor? |
|
there is a new autonight version which doesn't need the physical light sensor here for testing #699 |
The only thing added to my version of autonight is the following code: It discards any incoming values that are over 9999 and keeps waiting until a value below this threshold comes in. This will only apply to people who have installed their own light sensors and will have no effect on camera's without a sensor. |
Thanks Mate. This work for me perfectly. I will probably change the trigger so that only when by hue lights are off in these locations sunset is true then camera will go to night mode as I do not want to have the night mode on when lights are on |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
and others
I do not work to switch night vision. =(
The text was updated successfully, but these errors were encountered: