-
-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wyze Cam OG not working #677
Comments
I just got my new Wyze Cam OG going as well and it's not showing up on the bridge either. I am assuming it is not yet supported? |
Same issue here. |
Same issue here. I have the new Pan v3 also, which worked right away. Wyze Cam OG is not working. |
Thanks for the data points! The OG seems to be using a different P2P protocol than all the other cameras (similar to the Doorbell Pro). |
Do you think it will be possible to find a way to access the stream via docker at some point in the future? |
Same here, hopefully something is worked out within the 30 day return window otherwise they are going back :( |
Unfortunately, this could be Wyze purposely finding ways to now allow this kind of access to streams (So they can keep pushing their Cam Plus subscriptions) |
Sadly I tend to agree it may well be wyze intentionally changing for the new hardware to force the subscription. It started to become clear when the lite version was only offered for v2 and v3 cams and the new hardware omitted the lite option. I really don’t need all the extras. For next house I’m considering going with something like amcrest poe cams if I can get some cables run before they drywall it. Or I’ll breakdown and get a couple HomeKit compatible cams since we really won’t need much in new location. |
I believe the protocol change has more to do with the fact that the OG/3X and the Doorbell Pro seem to be designed and/or produced by "gwell", whereas the other cameras were mostly Hualai cameras. |
Hey thanks for getting back to us. Do you anticipate we will eventually be able to bring these OG into the bridge container? Is this work in flight or out of scope at the moment? That would help me decide wether to return these or hold on to them. Thank you. |
Potentially, but it may be more cloud dependent than our current solution (which could also mean it gets blocked by wyze). Can you test: |
|
same |
Here is my docker log, It only picks up the 3 V3 Cams: 2023/01/21 03:56:01 [WyzeBridge] 🚀 STARTING DOCKER-WYZE-BRIDGE v1.11.3
|
I pushed a new commit to the dev branch. Could you try using that to see if it recognizes the OG in the bridge and lets you access the webrtc endpoint? |
Am I able to test the dev branch using the Home Assistant plugin? If so, I could test right now |
You should be able to access the DEV branch using this repo https://github.com/mrlt8/edge-repo |
Thanks, got the edge-repo setup in Home Assistant. Dev branch is still only showing 6 of my 7 cameras - OG is not listed. |
and not seeing the OG listed anywhere in logs. Doesn't appear to be detecting it |
I tried the same with dev branch and not seeing my new OG camera listed |
Is there a Discord or other chat room we can use to coordinate testing? |
Still not detected after these latest commits. {"cam":"og-cam","result":"cam not found"}
|
On 1.11.5 it seems that it's no longer able to fetch cameras
|
Wyze Cam OG is being detected in 1.11.6! |
So, the OG is at least showing up on the page, but here is the log entry about it |
Also, thanks for everyone willing to test alpha features and I will update this thread with ways to test in the future as integration develops more. |
I also have a OG that I can help test with if needed as well as 2 local v3's and 2 remote v3's. I'm not familiar with reverse engineering but have compiled and loaded custom firmware for the v2 cams. It's a shame these are so different, the little spotlight is cool and the picture quality especially at night is pretty impressive for the price. |
What container project are/would you [be] using? docker-android, redroid? While I realize you're just being practical (I would be doing the same, if I had time), wouldn't your proposed approach require at least 1GB (or for speed maybe even 1.5-2GB) of RAM? And the bootup speed be in the realm of at least 30 full seconds? I guess I'm just curious what you're using to defeat the major drawbacks of using a full-blown Android solution in this context.
That would be excellent. Please, the sooner the better since people often (I've done it, lol) suddenly go missing and all of their proposed work is lost, never to be heard from again. 😜 Thank you for your hard work!!! |
I have not been able to run an android emulator in a docker container on my main dev machine which is an m2 macbook pro so that is slowing me down at the moment. I have tried all readily available android emulator docker solutions. As far as I can tell there is no way to avoid using a full android emulator so take it or leave it or come up with a new solution. I will post the new repo soon, I have it in progress but its not ready for public consumption. |
Keep in mind you may also be able to release it on the play store, or at least give access to an APK that can be installed manually, to allow a real device to run it. I'm sure I'm not the only one that has a handful of old Android devices lying around 😂 This bridge just needs to be able to connect to the Android bridge, whether emulator or real device. I also have an Android Things dev device. |
That's your main problem: Mac M2 I hate to say it, but due to Apple's extreme proprietary nature, Mac OS isn't exactly what most users on here are going to be using, ever. |
I have no intention of releasing it to the play store. If you want to use it on a spare android device then you can load it manually.
I know how platform architectures work and was not asking for a recitation of my problem but feel free to offer a solution if you wish to comment further. The problem is not apple silicone, but the lack of support from androids command line tools which enable you to automate an emulator on any ARM based device. We also do not have x86 versions for the libraries at all. They are also JNI libraries meaning you basically have to use a real device or emulator to get the JVM environment correct. Again, solutions are welcome but rather not more problems or issues already stated |
Are there any updates available? I have 2 OG cams and would be happy to help with the testing. |
Cryze is my project for accessing Wyze Gwell based cameras like the OG Cam, Video Doorbell Pro and I am sure there are others. I have a working prototype and am currently working on a full integration with other projects like this one. Feel free to check that repo periodically as I iron out the kinks and get things release ready. |
Awesome news! Thank you!
From: carTloyal123 ***@***.***>
Sent: Wednesday, February 21, 2024 3:06 PM
To: mrlt8/docker-wyze-bridge ***@***.***>
Cc: dinan5 ***@***.***>; Comment ***@***.***>
Subject: Re: [mrlt8/docker-wyze-bridge] Wyze Cam OG not working (Issue #677)
Cryze<https://github.com/carTloyal123/cryze> is my project for accessing Wyze Gwell based cameras like the OG Cam, Video Doorbell Pro and I am sure there are others. I have a working prototype and am currently working on a full integration with other projects like this one. Feel free to check that repo periodically as I iron out the kinks and get things release ready.
-
Reply to this email directly, view it on GitHub<#677 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ARAH6ECNZAQ2YENSFINDE2LYUZHSBAVCNFSM6AAAAAAT7SO4VKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJXHAYTENZVHA>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
Can you add some documentation on how to install this? I have docker / portainer but not super familiar on adding things on my own yet. |
Are the Wyze Cam Pan v3 cameras Gwell based?
[mg]
…On Wed, Feb 21, 2024 at 12:10 PM dinan5 ***@***.***> wrote:
Awesome news! Thank you!
From: carTloyal123 ***@***.***>
Sent: Wednesday, February 21, 2024 3:06 PM
To: mrlt8/docker-wyze-bridge ***@***.***>
Cc: dinan5 ***@***.***>; Comment ***@***.***>
Subject: Re: [mrlt8/docker-wyze-bridge] Wyze Cam OG not working (Issue
#677)
Cryze<https://github.com/carTloyal123/cryze> is my project for accessing
Wyze Gwell based cameras like the OG Cam, Video Doorbell Pro and I am sure
there are others. I have a working prototype and am currently working on a
full integration with other projects like this one. Feel free to check that
repo periodically as I iron out the kinks and get things release ready.
-
Reply to this email directly, view it on GitHub<
#677 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ARAH6ECNZAQ2YENSFINDE2LYUZHSBAVCNFSM6AAAAAAT7SO4VKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJXHAYTENZVHA
>.
You are receiving this because you commented.Message ID:
***@***.******@***.***>>
—
Reply to this email directly, view it on GitHub
<#677 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABEIMUQNHMJ7SHPLSBDRU2DYUZID5AVCNFSM6AAAAAAT7SO4VKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJXHAZDCMJYGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
@talormanda as mentioned, I am in the process of getting the project ready for full release. Once that is done, check back to the Cryze repo for install instructions. @quistuipater do you know the model number of the OG cam? Or have the mac address of one? I think they all start with "GW_" Edit: yes, the OG and doorbell pro both have the GW model number so it should be safe to assume they are both Gwell Based at the very least. |
No, the Pan v3 works with this bridge, it is not Gwell |
Gracias.
[mg]
…On Thu, Feb 22, 2024 at 6:46 AM Joe ***@***.***> wrote:
@quistuipater <https://github.com/quistuipater>
Are the Wyze Cam Pan v3 cameras Gwell based?
No, the Pan v3 works with this bridge, it is *not* Gwell
—
Reply to this email directly, view it on GitHub
<#677 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABEIMUSJJE3553ILDV67JBTYU5K4JAVCNFSM6AAAAAAT7SO4VKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJZGYYDINRQGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Do you still need a MAC address or you got the info you needed? |
I am good, I had mis-read that and I forgot about the list of devices on the home page. Thank you! |
is there any update on this? is anyone working on to solve this issue? |
Please read the entire thread before posting questions. I have a project that addresses the OG cam and Video Doorbell Pro V1 reference above. @imbkr |
In some fairness it doesn't appear the documentation really ties it all together. E.g. what to do after the APK is installed in the emulator. (Just to name one) |
Correct that Cryze is not fully fleshed out as it is a hobby project and is a large undertaking (feel free to clone and make pull requests if you want progress on your own watch. The question was if there was someone/something working towards a solve for this which indeed there is and has been mentioned multiple times in this thread hence my reply. @nbetcher you should not have to worry about the APK at all. If you want clarity on setup please address it to the main Cryze repo |
has there been a solution in this repo yet? |
I've got a hard fork of cryze that is working. It's a bit CPU thirsty but it is actually streaming video to my NVR. I'm activly working on getting hardware acceleration working to try to reduce the footprint. github.com/xerootg/cryze_v2 |
That's great! thanks. Will try it. |
I'm actively working on it, expect it to both change fundamentally and for there to be issues. I'm likely going to be pulling the raw h264 frames out of android into a third container to handle the RTSP side, possibly today and likely by tomorrow. The CPU consumption of Android's MediaCodec without hardware acceleration is absolutely mind boggling and I really don't feel like recompiling android for the possibility that it might be slightly more performant. I'm using just over 1 core per camera on an i7-12650H which I find totally unacceptable. I did a spike where I rendered the raw output into a MJPEG stream and that was actually worse than double encoding like it does now. |
Well, we really appreciate the effort you are putting into it, thank you again! |
Alright, the raw streamer in my cryze fork seems pretty solid. its been running for a couple days. I got it to stream the raw h264 packets to a tcp client, like ffmpeg, so you'll need to use an intermediary to use my fork like go2rtc (which I am using with frigate). I seriously doubt the gwell cameras will ever be supported outside of an android emulator, as tencent's library uses message queueing to a proprietary backend to get the stream contents. I'm probably going to get a different doorbell after this experience, I'm disappointed in Wyze. The whole gwell API and integration of the gwell products into the wyze platform screams outsourcing chaos. |
Yeah, this is great work. And this is as far as I ever wanted to take it either for the exact same reasons that you mentioned. My whole goal was to use my video doorbell pro in HomeKit, but now that there are cheaper HomeKit secure video enabled doorbell cameras, I would much rather get one of those instead of mess with the horrendous software stack that Wyze is using. Repo is very clean and well done, great work! @xerootg |
This is exactly why I started going to tapo and reolink. If I hadn't gotten my doorbell pros for free, I wouldn't be using them as the current option. As nice as wyze is as a company, I don't think their development team knows anything about what's going on.....and this is really evident because anytime you would suggest a really simple feature, it was met with strong backlash about how they can't do it. They are definitely outsourcing. |
Thanks @carTloyal123 !! Maybe you'll get some use out of it anyway ;) Well, all that said, I'm almost done stripping the gwell/iotvideosdk down to the minimum needed to maintain a stream. I've still got some little nags around stalled video streams and token renewal, but it's quite obvious the stack wyze used on these cameras was not designed for long-running stream reading. I'm not going to put effort into transcoding on the container unless someone needs it, it's quite difficult to do hardware interop into a container that doesn't even share a common libc. So all that to say, if you're using my cryze fork, let me know over in my repo and I'll keep working on stabilizing it for as long as it holds my attention. I might even try running the android stack in a stripped down android container to give me a bit more control and use less memory! @mrlt8 I don't know if you want to keep these gwell camera support issues open. There's a solution now and your solution seems to work well for the TUTK cameras. I can confidently say nobody is going to port the tencent iotvideo API to python anytime soon. |
Not seeing the Wyze Cam OG showing up on the bridge. Running docker compose up (without the -d) I don't even see it listed in the initial "Connecting to..." section.
I also did FRESH_DATA=true on my yml.
The text was updated successfully, but these errors were encountered: