Ethernet connection to V3 cam?

I bought these so I could test the adapter with a V2, but they will also work with a pc.

USB 2.0 Male to Micro USB Female Connector Adapter (2 Pack) https://a.co/d/5sDMiA8

Success with the second adapter.

192.168.2.245 00:e0:4c:36:06:5b (Realtek Semiconductor)

Yay ; )

2 Likes

Congratulations! Say goodbye to drop outs and hello to 250kB/s bitrates.

If you were unable to return the faulty adapter, what are your plans for it? If you were just going to toss it, Iā€™d be interested in it to investigate the problem. Iā€™ve read that it just involved bad surface mount soldering, but have no confirmation of it being something that simple. If it is, it may be an easy fix for all the bad ones out there,

Went back to Amazon. Would be interesting to know what difference there is. Must be something that they changed to deserve a new number and all.

Gotcha. The number is an Amazon inventory/ item identification number. The newer one likely just represents a new batch of adapters. Odd that the old ones are also still listed, though all of mine still work perfectly.

Regardless, good to hear you were able to return your faulty one and are now in business.

Iā€™d still like to examine one of the bad ones. Almost has to be something simple between the Realtek adapter and the interfacing to the external connectorization.

Iā€™d guess that the old ones probably remain listed because they still have a bunch of them and they work OK for other applications. Worked for you. Not sure why I need the ā€œupgradedā€ version.

Iā€™m still getting the regular drop-offs if I block the cams from Internet access. Was hoping that the mini-hack would stop that but I guess the camā€™s still doing what it does beyond that and still looking for something that it canā€™t find. Itā€™s faster to come back up at least and no more WiFi drops which I do have on some others that I canā€™t move to cable.

Just remember, this isnā€™t replacing the Wyze firmware, just supplementing it. The cameras still need the internet for all the Wyze functions.

2 Likes

Yep, understand. Was hoping with its own RTSP server it might avoid it but if the cam goes offline for whatever reason, then I guess the server will too.

There have been several lengthy discussions about this in different forums with varying methods of mitigation yielding varying results.

The V3s use lots of ports for various functions. Elimination of those functions in the software is a start toward eliminating reliance on the associated ports and any dropouts that may be associated with those functions being active,

A local NTP source also seems to help since correct time is one of the first things the camera wants to establish.

iā€™ve not seen anyone methodically close each port one at a time to identify mandatory ports, but discussion indicates an authentication handshake is periodically required along with maintaining active connections for the Google and Alexa APIs.

Blue Iris has several RTSP function options that may or may not affect the V3 dropouts. Iā€™ve never tried massing with them and havenā€™t read any discussion about it one way or another.

Thereā€™s always the option of using V2s with RTSP firmware which evidently operate just fine in a CCTV environment.

1 Like

Yes, I dug into it some at one point. Think we may have talked about it in the RTSP beta thread. They look for a number of things - NTP, DNS, Wyzeā€™s P2P servers, etc. Some like NTP you can redirect locally at your firewall/router and that works fine but you canā€™t provide what theyā€™re looking for from the P2P side. At least I canā€™t. Maybe someone who better knows what they need could.

Iā€™m having some problems keeping the mini-hack running well with the external adapter. Keeps dropping off a lot. As in pretty much offline most of the time. It will run for a few seconds and then back offline. Over and over. But thatā€™s only as seen by the app and BI. If I access the cam via the web interface at the same time, then it appears to be up and running with a steady connection. I can see the time changing second-by-second and everything looks fine. Tried rebooting from the web interface (canā€™t get it connected from the app) and repowering at my switch but it comes back up doing the same again. Going to have to pull it down and take a look. Unfortunately, I have it up a tree so have to climb back up there. Might not have been the best choice of application until I can test it a little more. ; )

I also switched another V3 cam to the mini-hack but itā€™s running on WiFi for now. It also drops off repeatedly but with the more normal pattern where itā€™s up, drops off for some seconds, then comes back up OK fairly quickly.

BTW for quick and easy outdoor protection, found that the UCTRONICS adapter fits in these:

Iā€™ve used them as extra protection (beyond cable seal and tape) for camera connections in very exposed locations (trees, etc.) where a box doesnā€™t work as well. Stayed completely dry inside.

1 Like

I gather these cams are still confined to the local network? Unless no WAN connectivity is available in the particular environment, wouldnā€™t it actually be easier to simply allow the necessary requests and be done with it? Otherwise, you may want to try V2s. Theyā€™ve been on sale for $19.99 lately and work well enough, though do require some weatherproofing if intended for outdoor use ā€“ which obviously drives up the per unit cost.

As for your V3 drop offs, Iā€™ve found bad wifi and poor quality cables/adapters to be the main causes ā€“ aside from no WAN connectivity, of course. Thereā€™s also the possibility of BI settings being somehow involved or something weird in the wz_mini.conf file. Seems unusual to see the problem in one medium but not another, though.

Try hammering the snot out of the camera with 1024 bit packets overnight and see what the results are in the morning.

ping xxx.xxx.xxx.xxx -l 1024 -t
End with ctrl C to see the results

I had a POE V3 in a remote location with a dropout issue. It was hardwired to a router/bridge via POE injector which was then backhauled to my main network over a wifi link. 43,000 1024 bit pings later to the router address, exactly two were dropped, but there were still several dozen cam dropouts. This essentially eliminated the wifi link as the problem. After jumping through several more hoops, I narrowed it down to the UCTRONICS adapter simply not liking the TP-LINK POE injector which worked just fine with a Reolink 811A (and still does, btw). I moved the V3 with the same UCTRONICS adapter to a different location on the main network powered by a POE switch and it has been rock solid since.

We need to also keep in mind that all these cheapie adapters and 10 cent cables are basically pure junk on a good day, Homebrew RJ45s can also be problematic unless youā€™ve done a bunch of em and/or have a decent tester to check them.

Iā€™m pretty confident in the security of my network and personally donā€™t have major concerns about these things making their occasional outbound requests. It certainly eliminates one major variable when chasing causes of their already notorious propensity for dropouts.

The security of my cell phone on the other handā€¦

1 Like

After a lot of messing around with it, my V3 cam running mini-hacks with the adapter hasnā€™t had any drops overnight running under BI. Unfortunately, I fiddled with so many things between the mini-hacks/pfsense/BI that Iā€™m not sure that I can say exactly what helped fix it. In any case, good now.

Allowing Internet access will fix (most of) the regular every 3 or 4 minutes drop-offs that are seen related to that. What I had running with the mini-hacks/adapter was different. Even with access provided it was offline as much as it was online and I had no access via the app at all. I was wrong above when I said that it was fine looking at it in the web interface. It and VLC as well are just more tolerant of pauses in the stream. Watching more closely later I could see the time stopping and then jumping forward as it resumed. BI just says ā€œNaaaā€¦ no goodā€ and shows the cam offline and then takes some time to pick it up again so you see it a lot more. Not sure what accounts for the app not being able to get to it but it couldnā€™t at all. Maybe timing as well. But itā€™s all working well now.

Yes, marginal WiFi also will cause them to drop. I have that with one of mine thatā€™s a little more remote.
Thatā€™s easy to understand and kind of is what it is.

For the time being I can live with having to give them access and segregate them in other ways but Iā€™d rather not if I can avoid it. Thereā€™s a good discussion of the regular drop-offs without Internet access and what needs to be done to eliminate them down the page some at the link below. Looks like something may be in the works for the mini-hacks to stop that behavior.

Thatā€™s awesome! Iā€™ve been following most of that stuff but lost track over the past couple of weeks just trying to figure out why only one of three of my V2s will accept wz_mini. Itā€™s all way above my pay grade until it gets integrated into the latest release which I can usually fumble through with success.

But back to V3s, one of my POEs coincidentally locked up this morning on BI with a ā€˜no signalā€™ error, but was still active and accessible via the app. I restarted via the app and it came back up on BI. Havenā€™t checked any logs to see what may have been going on. Donā€™t really know where Iā€™d look for correct logging anyway. Just know there was an error generated and itā€™s probably logged somewhere!

And as for sketchy wifi, and realizing this is supposed to be an ethernet discussion, adding an external antenna to a V3 is actually pretty simple of you have even marginal soldering skills. There are a couple of decent YouTube vids if youā€™re interested. This is one of the better ones. A little slow, but quite thorough. I did one of my V3s and it definitely improves the RF capability of the cam. (I chose the lower left side rear corner for the location myself.) And if you do happen to slice into the ā€˜Oā€™ ring he mentions or mangle the double sided tape that attaches the bezel, re-sealing is simple with a small bead of silicon and is probably a better seal anyway.

External Antenna for V3

Hereā€™s mine. Antenna size is exaggerated by the camera angle/proximity.

Ok. Enough monopolizing this thread. Iā€™ll go now!

2 Likes

Thatā€™s kind of cool and doesnā€™t look too hard to do. Did it help much?

Think Iā€™m going to run cable to that one of mine. That and the one that I put up already here were the main reason for me to be looking at the adapter. Iā€™m using one to complement a license plate cam that I have. The Wyze obviously doesnā€™t work well for that but I can run it in color at night without any extra lights or light showing on it to better see the make and color of cars. The LPR cam you donā€™t see anything at night but the plate. My other cams looking that way are all on IR at night so I donā€™t get color. Had an extra cable out to the tree so put it to use:

Thanks again for all your help btw.

1 Like

Does anyone else see about a 6-7 second delay of the stream using the UCTRONICS adapter? That is, a little behind the actual time all of the time. If the rest of my cams are showing 12:00:07, itā€™s showing 12:00:00 and what I see in the video is of that timing. The other V3s I have running mini-hacks donā€™t show the same delay. Only the one running with the adapter.

Otherwise, mine has continued to work well.

Only with their app. Typically real time for me with upwards of a 230~255 kB/s bitrate at 22fps in BI.

1 Like

Throughput is fine on mine too. The stream just appears delayed by about 6-7 seconds for the cam running with the adapter. If I restart from the app or re-power from my swtich, then it starts out in-time with the rest but then gradually falls behind again until it gets to about that 6-7 second point. From there seems to stay stable.

Whatā€™s it using for a time server? Discrepancy between BI and the app maybe? Does it re-sync from the app command? RTSP ā€˜onā€™ in the app?

Sorry. Just thinking out loudā€¦

Itā€™s using whatever of the time servers programmed in for NTP. I donā€™t have it blocked or NTP redirected at the moment. Itā€™s not just the time, itā€™s whatā€™s shown by the cam as well. Whatā€™s shown is correct for the time, itā€™s just behind time. If that makes sense.

Syncā€™ing time from the app does not change it.

The stream itself is fine otherwise. In Bi I do see the little warning triangle come and go some on the first page of the video tab where it shows the connection speed and all but itā€™s very quick and not dropping out.