Hi @jkmonroe , I have a synology setup running docker as well. Did you work off a guide to set this up, or do you mind sharing some tips to get it going?
Thanks!
Hello CaptainKirk,
Thank you for sharing this document, it got me past the part where I was lost (GitGui openning, I had no clue where to go from there)
I was happy to see my doorbell feed show up in VLC:
With it being displayed incorrectly, since Wyze appears to not be able to figure out how to make it display correctly, I stumbled upon a setting in VLC to rotate the feed:
Nice.
Now to figure out how to ‘consume’ these feeds into Blue Iris or the like…hopefully.
SJ
Stream redirection is one of the things VLC does well.
@ michealespinola and @ calvinnelms -
To preface, i have a 918+.
I installed GIT from the Package Center and enabled SSH (Control Panel → Terminal/SNMP). I ssh’d in using an administrative account, changed directories into my docker folder (under volume1 in my case), and ran the git clone command to get the files pulled down. I edited the docker compose yml to change ports, add my Wyze creds, remove the network config, and then ran it with sudo.
Once I got the Docker containers created, I stopped them and created a new network using the Docker GUI, added both containers to that network, and restarted everything. I can control both containers from the GUI like normal to stop/start/restart/etc.
I hooked the cameras into my HASS instance using the ‘generic’ camera platform and into my Synology Surveillance Station using ‘User Define’. It’s only been a day but I’ve had no outages so far, and I’m excited I can put my pool cam into Surveillance Station to record 24/7.
2 Likes
Just tried the docker/kroo project on my mac and it worked well but a few caveats:
- Uses a lot of CPU, even when not streaming. Adding filters to the docker file should help to avoid re-streaming unnecessary cameras
- Requires the wyzecam to have constant internet connectivity. So it’s not a true “local” setup since it requires the Wyze cloud to be up
- Since it bounces the stream through the cloud it uses quite a bit of bandwidth – once to upload to the cloud, then to download from the cloud
1 Like
The internet is only needed for auth and it seems to phone home from time to time. Depending on your firewall you could automate a rule that enables/disable for auth and then once every 6 hours or so for just a few minutes. The video only goes to the cloud if your cameras are on a different subnet than my script is running. Perhaps the docker version uses the cloud since the docker is in its own subnet. I hadn’t even noticed. It’s odd you have high CPU usage because all it’s doing is muxing the raw h264 frames into an FLV container. I only have 2 Wyze cameras along with a few Amcrest cameras running into Frigate which is doing object detection on a Google Coral. There are several other services running on this same server too. It’s only a 3rd gen i5 and I only get about 20% usage with ALL of this stuff running on the same server running Debian.
Thank you @jkmonroe , I will give this a shot.
This docker plugin doesn’t play well with Tinycam pro. It will drive the camera so hard it will go offline after awhile and have something like lag going on.
Mine are running 24/7 into Frigate with zero lag (yes, zero) and no stability issues at all. Doesn’t TinyCam Pro already support Wyze Cams using the exact same TUTK SDK that the docker container is using?
It sure does. Not sure what jsh is trying to do.
I’ve been monkeying around with this and have my cameras up and running in Docker, mostly. I have a mixture of v2 & v3, and am consuming the RTSP feeds into iSpy. The problem I’m running into now is that occasionally I will drop one of the v3’s and it is a PITA to get it back. I have previously been using MeMu & TinyCam and was able to resolve any dropped connections with a reboot of the TinyCam webserver or the MeMu VM. The Docker error is the same - "ERR: No one is publishing to path ‘mycameraname’. Rebooting the camera does not appear to work in this case. The camera is up and running just fine in the Wyze software, but I cannot get it to reconnect consistently in Docker either with VLC or in iSpy. Any ideas? Is there are command line to reload just the failed camera without forcing the whole Docker image to reload?
WAIT JUST A MINUTE…Are you all saying that the video from Wyze cam v3 will play in Tiny Cam Pro without running all this RTMP → RTSP docker tutk junk? IF SO THEN what are the Tinycam Pro parameters and URL?
Care of
Sure does, and it’s been that way for a long time.
You don’t even need the pro version. Try it out, free.
The one advantage the pro version gives, is allow viewing from a web browser.
1 Like
TinyCam Pro does WORK with Wyze Cam v3. but NOT version 11.1. Upgraded to 15.2.1 and the correct android verion for my phone and PRESTO.
@jkmonroe I am walking through your guide (installing on ds1821). After downloading the git repo, adjusting the yml, and running docker-compose up, I receive the following error at step 2/7:
W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease Temporary failure resolving 'deb.debian.org'
W: Failed to fetch http://security.debian.org/debian-security/dists/buster/updates/InRelease Temporary failure resolving 'security.debian.org'
W: Failed to fetch http://deb.debian.org/debian/dists/buster-updates/InRelease Temporary failure resolving 'deb.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package ffmpeg
E: Unable to locate package unzip
The command '/bin/sh -c apt-get update && apt-get install ffmpeg unzip g++ -y && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 100
Did you run into this when you were installing?
Thank you!
I guess it depends on how you have your docker networks configured. Try putting back the network config in your docker-compose and see if that works.
edit - to add to this, and for some context, when I built the docker-compose on my setup I could not get the containers talking with each other in my pooled network nor could I ‘link’ the 2 together, so I created a dedicated network and joined both containers which worked.
FYI, TUTK is the protocol that Wyze chose for their cameras. Tinycam used the official TUTK SDK to gain access to the local stream. If I recall the SDK used by the Tinycam dev got leaked to some other GitHub project. Kroo then made use of this same SDK in his project. If Tinycam doesn’t support the V3 then it’s probably just that the dev hasn’t bothered to implement it.
The problem that I have experienced with V3 and Tinycam pro is dropping out. You would think that streaming directly from the cloud it would be very stable. I feel like Tinycam could use an update to fix little things like that.
Actually much more simple and innocent than that. Alexey of TinyCam just used the available Wyze reverse engineered protocol developed and donated to the public by the NBLavoie team. For some inexplicable reason it’s taken YEARS for other groups to recognize how great it is and implement it in other projects like this. Nobody took anything as far as I understand.