Second, isn't it the users responsibility to manage battery life, and not yours by restricting access? For instance, my argus 2s are plugged to a solar panel and constantly at max charge during the day, it's a shame I can't access it via web browser...

I'm using Argus Eco and PT cameras from a few weeks only, and very strongly agree with that statement. Reolink people should be aware that we have not chosen these models by whim, but because the required position of the camera doesn't make possible a plug or a POE, but this should not imply such cutting of many basic features whose relationship with the battery is not clear, and moreover when most, if not all, of battery-power users have solar panels as well.

It looks as the battery-powered cameras were the "poor relation" with respect to the rest of Reolink devices, thus using the charging issue as an excuse to cut some features that actually could be easily implemented but we, users, need: web browser access, "common user" type, motion detection area (!!!), saving to FTP server (!!!) or privacy mask, to say the most obvious ones for me.

Escapes me what most of these have to do with battery level but, anyway, if the phone and PC applications are able to know the battery status and whether the camera is connected to a power source (solar panel or other), I don't see what problem would be to implement something as simple as:

- Define what charging threshold would each "problematic" feature require.
- If the user configures some feature requiring a given battery level and it is likely to fall below the threshold, notify the user that feature will be on hold until battery recharging.
- Moreover, there could be an overall, user-defined, threshold for battery warning, although never less than the default, factory defined, one (this would cover the case the user was a long distance away from the camera and would prefer to have some security margin to deal with the issue).

As Vincent Le Bourlot and other participants have said, it is the users responsibility to manage battery.

I have just checked the recordings taken by my 510WA (firmware version v3.0.0.412_21063012) and I would say it seems to be working fine in this respect. For example, a recent picture sent by mail of a vehicle entering my property was timed at 16:29:50, while the video recording started at 16:29:28, when the vehicle still was beyond detection distance. Of course, although this is good enough for my needs, YMMV.

+1. This is a real need.

I got the same impression when I configured my 510A, but later I noticed that the predefined servers list also had a last 'Custom' option. Selecting that one I was then able to add my preferred NTP server. Of course, you have another model, so YMMV.

Hi, Cynthia, just to know... how many claims about a problem do you require to consider that solving it is worthwhile? Other users may not mention it for many reasons, in the first place because after seeing how you manage our feedback they may feel that complaining here is useless. If fact I wrote some weeks ago (topic/how-to-arrange-cameras/) about the need to fix those differences between apps and clients whithout even a response. If you really want to know and measure that interest, why not use an issue tracking tool, just as many other developers do?

In order to reduce false alarms, it's advised to combine the methods of setting up the proper sensitivity and defining proper motion detection areas on Reolink Client software.
[/quote]

Although tweaking sensitivity may do the trick in some situations it is not by no means a solution because it also affects distance and on time catching of real intrusions, so defeating the purpose of having a camera to detect them as soon as possible. The same is true for detection areas, of course very useful to mark where you don't want to get an alarm, but no at all to discern about what is causing it.

[quote quote=1458619]
Intensive motion like rain/snowflakes, insects attracted by IR lights, may also cause frequent alarms which may not have a good solution to it.

In this and previous threads you have already received an excellent idea to largely reduce this problem.

In my case, birds seem to be curious about my Argus 2 cameras with camouflage skins installed on the top of a tree. The Argus Eco sometimes show wasps, in daytime, or spiders, at night, but I wouldn't call it 'attack', really. In fact, a bit windy night is usually enough to remove spiderwebs. Also the pair of E1 Zoom I use indoors capture some flying bug (or a gecko foot over the lens), but all of these are not a problem because they trigger only a few alarms, moving shadows and branches blowing in windy days being far worse, but fortunately my 510A cameras have made a great difference at this respect. Even if at first they 'caught' some spiderwebs as 'vehicles' or 'persons', detection has improved quite a bit and now is pretty good to me. Anyway, actually my main problem with lenses is related to muddy rain, because dried droplets blur the image at night (not so during the day) but I'm not sure about the best cleaning method to avoid damaging them.

Mac 8.2.6 client version doesn't have it either.

Maybe this was obvious to everyone else, but it sure tripped me up.

No, you are not alone on this. At least since I have got my 510A I've been racking my brains with exactly the same issue, although in my case aiming for wild boars and foxes... and cats, of course. Thanks for pointing out what ”Any Motion” means.

They are different software.

Cynthia, as a former sysadmin and systems manager I know they are different applications. And maybe this is the problem, precisely: it should be a same application (taken as a same design concept and set of features) albeit developed and running in a variety of platforms, even if some of those features may be harder to obtain in a given development environment. But what doesn't make sense is to give a better user experience to users in a platform and not so good to others, or, worse yet, to give a different and more complete experience to a same user while using the app instead of the client. At least in the iOS vs Mac case there are important features lacking on the latter, as the already commented reordering function, or the bandwidth being consumed by a camera during the connection, useful for troubleshooting, or Time Lapse management, and some others. If one had to be chosen (and I am not saying it needs to be so), I would say it should even be the other way around, because no for nothing playing back or downloading, to say the least, is more at ease in a desktop computer.

We are sorry to tell you that the order of the cameras cannot be changed. If you need to change the order, the only way is to delete the camera and add them again one by one.

This is an often repeated request. Do you think deleting a bunch of cameras, ten in my case, and adding them again is THE way to do that, really? If the app does it, why not the clients?