Wyze Cam OG not working
mr-bobdobalina opened this issue · 131 comments
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.
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).
Currently looking into alternate methods to access the stream.
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)
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.
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: http://localhost:5000/webrtc/ogcam-name
Tried this link http://192.168.2.101:5000/webrtc/Driveway2 and got {"cam":"Driveway2","result":"cam not found"} but if I try a V3 Cam I can pull it up fine.
Tried this link http://192.168.2.101:5000/webrtc/Driveway2 and got {"cam":"Driveway2","result":"cam not found"} but if I try a Cam V2 or V3 I can pull them up fine.
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
- Serving Flask app 'frontend'
- Debug mode: off
2023/01/21 03:56:01 [WyzeBridge] 📚 Using 'user' from local cache...
2023/01/21 03:56:01 [WyzeBridge] ♻️ Refreshing camera data for thumbnails
2023/01/21 03:56:01 [WyzeBridge] 📚 Using 'auth' from local cache...
2023/01/21 03:56:01 [WyzeBridge] ☁️ Fetching 'cameras' from the Wyze API...
2023/01/21 03:56:01 [WyzeBridge] WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. - Running on all addresses (0.0.0.0)
- Running on http://127.0.0.1:5000
- Running on http://172.17.0.4:5000
2023/01/21 03:56:01 [WyzeBridge] Press CTRL+C to quit
2023/01/21 03:56:06 [WyzeBridge] 💾 Saving 'cameras' to local cache...
2023/01/21 03:56:06 [WyzeBridge]
🎬 STARTING ALL 3 CAMERAS
2023/01/21 03:56:12 [WyzeBridge] ☁️ Pulling "Front Door Cam" thumbnail
2023/01/21 03:56:13 [WyzeBridge] 192.168.2.215 - - [21/Jan/2023 03:56:13] "GET /api/sse_status HTTP/1.1" 200 -
2023/01/21 03:56:17 [WyzeBridge] ☁️ Pulling "Driveway Cam" thumbnail
2023/01/21 03:56:23 [WyzeBridge] ☁️ Pulling "Back Yard Cam" thumbnail
2023/01/21 03:56:23 [WyzeBridge] SET WB_IP to allow WEBRTC connections.
2023/01/21 03:56:23 [WyzeBridge] Starting rtsp-simple-server v0.21.1
2023/01/21 03:56:23 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - front-door-cam on 192.168.101.75 (1/3)
2023/01/21 03:56:23 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - driveway-cam on 192.168.101.217 (1/3)
2023/01/21 03:56:23 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - back-yard-cam on 192.168.101.234 (1/3)
2023/01/21 03:56:30 [Back Yard Cam] 📡 Getting 120kb/s HD stream (H264/20fps) via LAN mode (WiFi: 73%) FW: 4.36.9.139 🔒 (DTLS) (2/3)
2023/01/21 03:56:30 [Back Yard Cam] 🔊 Audio Enabled - ALAW/16,000Hz
2023/01/21 03:56:30 [Driveway Cam] 📡 Getting 120kb/s HD stream (H264/20fps) via LAN mode (WiFi: 36%) FW: 4.36.9.139 🔒 (DTLS) (2/3)
2023/01/21 03:56:30 [Driveway Cam] 🔊 Audio Enabled - ALAW/16,000Hz
2023/01/21 03:56:30 [Back Yard Cam] WARNING: Skipping smaller frame at start of stream (frame_size=1)
2023/01/21 03:56:30 [Driveway Cam] WARNING: Skipping smaller frame at start of stream (frame_size=1)
2023/01/21 03:56:30 [Front Door Cam] 📡 Getting 120kb/s HD stream (H264/20fps) via LAN mode (WiFi: 36%) FW: 4.36.9.139 🔒 (DTLS) (2/3)
2023/01/21 03:56:30 [Front Door Cam] 🔊 Audio Enabled - ALAW/16,000Hz
2023/01/21 03:56:30 [Front Door Cam] WARNING: Waiting for keyframe
2023/01/21 03:56:32 [RTSP][FRONT-DOOR-CAM] ✅ '/front-door-cam' stream is UP! (3/3)
2023/01/21 03:56:32 [RTSP][DRIVEWAY-CAM] ✅ '/driveway-cam' stream is UP! (3/3)
2023/01/21 03:56:33 [RTSP][BACK-YARD-CAM] ✅ '/back-yard-cam' stream is UP! (3/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"}
2023/01/22 22:49:37 [WyzeBridge] ♻️ FORCED REFRESH - Ignoring local 'user' data
* Serving Flask app 'frontend'
* Debug mode: off
2023/01/22 22:49:37 [WyzeBridge] ♻️ FORCED REFRESH - Ignoring local 'auth' data
2023/01/22 22:49:37 [WyzeBridge] ☁️ Fetching 'auth' from the Wyze API...
2023/01/22 22:49:37 [WyzeBridge] WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
* Running on all addresses (0.0.0.0)
* Running on http://127.0.0.1:5000
* Running on http://192.168.1.147:5000
2023/01/22 22:49:37 [WyzeBridge] Press CTRL+C to quit
2023/01/22 22:49:38 [WyzeBridge] 💾 Saving 'auth' to local cache...
2023/01/22 22:49:38 [WyzeBridge] ☁️ Fetching 'user' from the Wyze API...
2023/01/22 22:49:38 [WyzeBridge] 💾 Saving 'user' to local cache...
2023/01/22 22:49:38 [WyzeBridge] ♻️ FORCED REFRESH - Ignoring local 'cameras' data
2023/01/22 22:49:38 [WyzeBridge] ☁️ Fetching 'cameras' from the Wyze API...
2023/01/22 22:49:39 [WyzeBridge] 💾 Saving 'cameras' to local cache...
2023/01/22 22:49:39 [WyzeBridge]
🎬 STARTING ALL 7 CAMERAS
2023/01/22 22:49:39 [WyzeBridge] SET WB_IP to allow WEBRTC connections.
2023/01/22 22:49:39 [WyzeBridge] Starting rtsp-simple-server v0.21.1
2023/01/22 22:49:39 [WyzeBridge] 🎉 Connecting to WyzeCam Pan V2 - living-room-cam on 192.168.1.45 (1/3)
2023/01/22 22:49:39 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - mom-driveway on 192.168.2.2 (1/3)
2023/01/22 22:49:39 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - back-yard-cam on 192.168.1.162 (1/3)
2023/01/22 22:49:39 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - mom-porch on 192.168.74.4 (1/3)
2023/01/22 22:49:39 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - mom-backyard on 192.168.74.7 (1/3)
2023/01/22 22:49:39 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - food-cam on 192.168.1.40 (1/3)
2023/01/22 22:49:39 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - bedroom on 192.168.1.43 (1/3)```
On 1.11.5 it seems that it's no longer able to fetch cameras
2023/01/24 16:51:46 [WyzeBridge] 🚀 STARTING DOCKER-WYZE-BRIDGE v1.11.5
2023/01/24 16:51:46 [WyzeBridge] 🔍 Could not find local cache for 'user'
* Serving Flask app 'frontend'
* Debug mode: off
2023/01/24 16:51:46 [WyzeBridge] 🔍 Could not find local cache for 'auth'
2023/01/24 16:51:46 [WyzeBridge] WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
* Running on all addresses (0.0.0.0)
* Running on http://127.0.0.1:5000
* Running on http://192.168.1.147:5000
2023/01/24 16:51:46 [WyzeBridge] ☁️ Fetching 'auth' from the Wyze API...
2023/01/24 16:51:46 [WyzeBridge] Press CTRL+C to quit
2023/01/24 16:51:46 [WyzeBridge] 💾 Saving 'auth' to local cache...
2023/01/24 16:51:46 [WyzeBridge] ☁️ Fetching 'user' from the Wyze API...
2023/01/24 16:51:47 [WyzeBridge] 💾 Saving 'user' to local cache...
2023/01/24 16:51:47 [WyzeBridge] 🔍 Could not find local cache for 'cameras'
2023/01/24 16:51:47 [WyzeBridge] ☁️ Fetching 'cameras' from the Wyze API...
2023/01/24 16:51:48 [WyzeBridge] 1 validation error for WyzeCamera
ip
value is not a valid integer (type=type_error.integer)
Wyze Cam OG is being detected in 1.11.6!
It shows a recent snapshot but it isn't able to load the WebRTC stream - gives a 404 error for both WebRTC and HLS.
All other cams working normally.
So, the OG is at least showing up on the page, but here is the log entry about it
2023/01/24 21:32:40 [WyzeBridge] 🎉 Connecting to WyzeCam OG - carport on (1/3)
2023/01/24 21:32:40 [Carport ] IOTC_ER_UNLICENSE
Type validation should be fixed in v1.11.6.
IOTC_ER_UNLICENSE is probably because the camera isn't registered with tutk when it tries to look for it remotely. It may be using Tencent's IoTVideoSdk like the doorbell pro (#276) for NAT punching/p2p.
can someone try the :5000/webrtc/<og-cam-name> endpoint?
The WebRTC endpoint on v1.11.6 results in an Internal Server Error with this popping up in the log:
2023/01/25 02:38:24 [WyzeBridge] Exception on /webrtc/og-cam [GET]
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/urllib3/connection.py", line 174, in _new_conn
conn = connection.create_connection(
File "/usr/local/lib/python3.10/site-packages/urllib3/util/connection.py", line 72, in create_connection
for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
File "/usr/local/lib/python3.10/socket.py", line 955, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/urllib3/connectionpool.py", line 703, in urlopen
httplib_response = self._make_request(
File "/usr/local/lib/python3.10/site-packages/urllib3/connectionpool.py", line 386, in _make_request
self._validate_conn(conn)
File "/usr/local/lib/python3.10/site-packages/urllib3/connectionpool.py", line 1042, in _validate_conn
conn.connect()
File "/usr/local/lib/python3.10/site-packages/urllib3/connection.py", line 358, in connect
self.sock = conn = self._new_conn()
File "/usr/local/lib/python3.10/site-packages/urllib3/connection.py", line 186, in _new_conn
raise NewConnectionError(
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPSConnection object at 0x7f2e07471270>: Failed to establish a new connection: [Errno -2] Name or service not known
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/requests/adapters.py", line 489, in send
resp = conn.urlopen(
File "/usr/local/lib/python3.10/site-packages/urllib3/connectionpool.py", line 787, in urlopen
retries = retries.increment(
File "/usr/local/lib/python3.10/site-packages/urllib3/util/retry.py", line 592, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='wyze-mars-service.wyze.com', port=443): Max retries exceeded with url: /signaling/device/GW_GC1_D03F276F3BEF?use_trickle=true (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f2e07471270>: Failed to establish a new connection: [Errno -2] Name or service not known'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 2525, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 1822, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 1820, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 1796, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
File "/app/frontend.py", line 144, in webrtc
if (webrtc := wb.get_kvs_signal(name)).get("result") == "ok":
File "/app/wyze_bridge.py", line 566, in get_kvs_signal
wss = wyzecam.api.get_cam_webrtc(self.auth, cam.mac, mars)
File "/app/wyzecam/api.py", line 231, in get_cam_webrtc
resp = requests.get(
File "/usr/local/lib/python3.10/site-packages/requests/api.py", line 73, in get
return request("get", url, params=params, **kwargs)
File "/usr/local/lib/python3.10/site-packages/requests/api.py", line 59, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.10/site-packages/requests/sessions.py", line 587, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.10/site-packages/requests/sessions.py", line 701, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.10/site-packages/requests/adapters.py", line 565, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='wyze-mars-service.wyze.com', port=443): Max retries exceeded with url: /signaling/device/GW_GC1_D03F276F3BEF?use_trickle=true (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f2e07471270>: Failed to establish a new connection: [Errno -2] Name or service not known'))
2023/01/25 02:38:24 [WyzeBridge] 192.168.1.158 - - [25/Jan/2023 02:38:24] "GET /webrtc/og-cam HTTP/1.1" 500 -
2023/01/25 02:38:25 [WyzeBridge] 🎉 Connecting to WyzeCam OG - og-cam on (1/3)
2023/01/25 02:38:26 [OG Cam] IOTC_ER_UNLICENSE
No change when trying :5000/webrtc/OG
I pulled fresh API data and the OG got a very recent snapshot, but not able to load video from it.
Multiple IOTC_ER_UNLICENSE entries in log at each connection attempt.
Made some tweaks to avoid IOTC_ER_UNLICENSE and swapped back to the default api.
Dev or Latest branch?
Dev branch
Got it, now the OG camera doesn't show up detected in list anymore
It should still be there, the bridge just won't attempt to connect to it directly since they're using a different p2p protocol.
Do you get anything on :5000/webrtc/<cam-name>?
The OG cameras are detected now on my end, however I do get a "Not supported" error for one of them in the log.
WebRTC endpoint: {"cam":"og-cam","result":"Camera does not support WebRTC"}
Interesting that one of the OG cams (Litter Cam) shows up as "Not Supported" while the other OG cam shows up as connecting before being removed.
2023/01/25 04:49:00 [WyzeBridge] 💔 Litter Cam [GW_GC1] is not supported
2023/01/25 04:49:00 [WyzeBridge]
🎬 STARTING ALL 8 CAMERAS
2023/01/25 04:49:00 [WyzeBridge] SET WB_IP to allow WEBRTC connections.
2023/01/25 04:49:00 [WyzeBridge] Starting rtsp-simple-server v0.21.1
2023/01/25 04:49:01 [WyzeBridge] 🎉 Connecting to WyzeCam OG - og-cam on (1/3)
2023/01/25 04:49:01 [WyzeBridge] 🎉 Connecting to WyzeCam Pan V2 - living-room-cam on 192.168.1.45 (1/3)
2023/01/25 04:49:01 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - mom-driveway on 192.168.2.2 (1/3)
2023/01/25 04:49:01 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - back-yard-cam on 192.168.1.162 (1/3)
2023/01/25 04:49:01 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - mom-porch on 192.168.74.4 (1/3)
2023/01/25 04:49:01 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - mom-backyard on 192.168.74.7 (1/3)
2023/01/25 04:49:01 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - food-cam on 192.168.1.40 (1/3)
2023/01/25 04:49:01 [WyzeBridge] 🎉 Connecting to WyzeCam V3 - bedroom on 192.168.1.43 (1/3)
2023/01/25 04:49:01 [OG Cam] IOTC_ER_UNLICENSE
2023/01/25 04:49:02 [WyzeBridge] Removing camera
hmm, that's weird. Not sure why only some cams are missing some fields..
Updated the dev branch so that it doesn't remove the weird GW_GC1_ prefix from the Mac address.
Throwing my OG telephoto in the ring.
As predicted, same as the others with the regular OG's
(This is on the dev branch)
2023/01/26 20:08:25 [WyzeBridge] 💔 street cam [GW_GC2] is not supported
2023/01/26 20:08:25 [WyzeBridge]
🎬 STARTING ALL 2 CAMERAS
2023/01/26 20:08:25 [WyzeBridge] ☁️ Pulling "Front Porch Cam" thumbnail
2023/01/26 20:08:26 [WyzeBridge] ☁️ Pulling "Driveway Cam" thumbnail
2023/01/26 20:08:26 [WyzeBridge] Starting rtsp-simple-server v0.21.1
2023/01/26 20:08:26 [WyzeBridge] [ON-DEMAND] ⌛️ WyzeCam V3 - front-porch-cam on 192.168.50.56 (1/3)
2023/01/26 20:08:26 [WyzeBridge] [ON-DEMAND] ⌛️ WyzeCam V3 - driveway-cam on 192.168.50.96 (1/3)
Thanks for the confirmation @warmon6!
Has anyone been able to get the OG to show up in the official web view or is the OG not supported there?
I hadn't even bothered to check until now, but they do indeed show up and play in the official web view!
Thanks for the confirmation @warmon6!
Has anyone been able to get the OG to show up in the official web view or is the OG not supported there?
Is there any data you need out of the official webview that would help? Do you need an OG camera to test? I could probably set up one and share it with you if you think that would help get it working.
Thanks for the confirmation @warmon6!
Has anyone been able to get the OG to show up in the official web view or is the OG not supported there?
My OG works on webview
out of absolutely sheer docker ignorance, how do I pull from the edge-repo on the command line via docker run ? (OG/OG 3X/V3 Pan user willing to test) thanks
First off, the fact that this add-on exists and works is amazing. So thank you for that. I am running HAOS, and I have a number of Wyze cameras connected (2 of mine and 4 that are shared) and working beautifully. I also have 3 new OG cameras (1 OG and 1 OG Telephoto locally, and another shared OG). The three OGs are not working. I am running the latest update that was pushed today (v1.11.8/9/10). Is there anything I can do to test or contribute?
Same issue, running Docker Wyze bridge v 1.11.10 on home assistant 2023.2.3 with 4 Wyze v3 working fine and 4 Wyze OG not working. Also getting a lot stop reading issues.
2023/02/10 20:38:01 [RTSP][BABY-CAM] 📕 Client stopped reading
2023/02/10 20:38:03 [RTSP][BACK-YARD-CAM] 📕 Client stopped reading
2023/02/10 20:38:04 [RTSP][OFFICE-CAM] 📕 Client stopped reading
2023/02/10 20:38:06 [RTSP][BABY-CAM] 📖 New client reading
2023/02/10 20:38:08 [RTSP][BACK-YARD-CAM-2] 📖 New client reading
2023/02/10 20:38:09 [RTSP][OFFICE-CAM] 📖 New client reading
2023/02/10 20:38:10 [RTSP][BACK-YARD-CAM-2] 📕 Client stopped reading
2023/02/10 20:38:11 [RTSP][BABY-CAM] 📕 Client stopped reading
2023/02/10 20:38:14 [RTSP][OFFICE-CAM] 📕 Client stopped reading
First off this is an awesome project. It's been very helpful. I'm using this method for both of the HAOS instances I manage that have wyze cams.
The only thing that would be even better, is if we could add the OG cams to the supported device list.
I was on the dev branch but, after 2 weeks of hoping the dev branch would get updated again and perhaps It might start working, I've moved back to normal branch . But I'd be happy to switch back to test any further changes.
Would truly love to get these OG cams marked as supported.
Also;
When I try :5000/webrtc/<og-cam-name>
It loads the player view. It circles for a while and act as if it might load the feed But ultimately it never loads The camera stream.
@mrlt8 do you have any update on this? If you'd like help with getting information for this camera I'd be willing to purchase one and help out with it. Depending on where you're located and shipping, I may be willing to purchase one for each of us as a contribution to the project.
I just updated my Bridge to 2.x and noticed that the api thumbnail is now working for my regular OG. However it gives a 404 for my OG Telephoto. Video streams still not working for either.
Running 2.0. Getting the following. Stream does not work. Thumbnail does but its the last motion event.
[WyzeBridge] 🎉 Connecting to WyzeCam OG - Pet Cam on
[pet-cam] [-10] IOTC_ER_UNLICENSE
[WyzeBridge] Pet Cam will cooldown for 10s.
OG/Doorbell Pro are not supported at this time.
Wondering if the OG's are being actively pursued to add or not. Trying to figure out if I should bother setting them up or not.
I have some HTTP proxy logs, and limited wireshark logs, with the ability to capture additional traffic between the Wyze app and the OG cam. How can I help with researching or adding support?
I'm willing to contribute changes, if someone can point me in the right direction for building and testing changes.
The OG is most likely using a different "IoTVideoSdk" platform. The SDK seems to be from Gwell/Tencent like the doorbell pro which @carTloyal123 was looking into.
Unfortunately, there isn't much information or any documentation in English:
https://github.com/GWTimes/IoTVideo-PC
https://github.com/GWTimes/GWP2PSDK
https://cloud.tencent.com/document/product/1131/42244
Isn't it this? https://www.tencentcloud.com/document/product/494/7244
All we need the tencent API for is to obtain the access key (enr) and get the local IP and UDP port, is that right? The wyze API response shows only a "placeholder" for the OG camera enr, and no ip.
Once we have the IP, port, and enr (is this the same as tencent's access key?), then there's a small handshake negotiation that happens between device and app, and after that the video starts to stream over UDP. This is presumably where the GWP2P or the iotvideo SDK comes in.
https://github.com/GWTimes/IoTVideo-Android looks a bit more informative.
So, high level, how would you describe what needs to happen in order to make progress towards support?
- How much of it is shared between GW and other wyze cams? E.g. it seems you already have "IOTC" in the stack somewhere, so that's not new.. we can get the thumbnails, so that's not new, etc. Where exactly is the separation between them?
- once we have the access key for the camera, is that all that's missing? Or do we still need a way to communicate with the camera P2P (the UDP handshake and streaming mentioned above)?
I just want to make sure I'm working in the right things, and not chasing something that's irrelevant or already in place.
@carTloyal123 anything new to share, or roadblocks you've hit that I can help get past?
Any progress on getting the Wyze OG to work?
I also was happy to see progress for the OG recently and would like to see more. I understand that it is not promising so far, but I'm invested in one of these now and would rather not send it along to the obsolete hardware box yet.
This is a very useful and needed project. Thanks a lot. Hope OG cameras are Supported soon (I've got a bunch of them) your bridge solution can finally free the feed from a specific webui/app.
Let us know how we can help in getting Support for OG cameras
Just FYI, I upgraded to 223 and partially connected. I see a still image with "The media could not be loaded, either because the server or network failed because the format is not supported. X" My other V3's and V2's work fine.
Is there anyway we can help moving forward the support for the new OG camera ?
Hi everyone, sorry for the radio silence. I have not looked much further into the new cameras since I posted a while ago. The python Tencent library looks very promising and I had not come across that. If someone wants to give that a shot that would be awesome but I will not be able to give this much time for the next several weeks/months sadly. I was working on this to get a stream from the video doorbell pro and basically was stuck at trying to reverse engineer the mechanism to even enable the camera video stream to start. I hope to have time to look at these at some point but for now I will just be in the background/checking this thread.
I have time sporadically (hard to know when), but I'm still not confident in my understanding of the various components of this project (see my questions above). Being new to the project, I just haven't wrapped my head around all the moving parts, and how each piece of the logs and/or network captures corresponds to equivalent pieces of the python code here.
What I've seen so far in my wire dumps is that the wyze api does not send the actual encryption key or the local ip address for these cameras, like it does for the other cameras, so I haven't been able to determine how the app discovers those. Once we have those, it seems like we should be able to proceed with getting the video stream. It appears to be over MQTT, but I haven't confirmed that yet. I also lost my logs of this, so I'll have to recreate my dev environment to get back to that.
I also was happy to see progress for the OG recently and would like to see more.
Just FYI, I upgraded to 223 and partially connected. I see a still image with "The media could not be loaded, either because the server or network failed because the format is not supported. X"
Is there anyway we can help moving forward the support for the new OG camera ?
Where is it that people are saying this, "support" and "progress"? I'll be honest, I don't follow this project's commits closely, but from what I could tell, there is no progress. And that would follow what I understand about the original problem. Which leads to my response to these replies to:
I was working on this to get a stream from the video doorbell pro and basically was stuck at trying to reverse engineer the mechanism to even enable the camera video stream to start.
What I've seen so far in my wire dumps is that the wyze api does not send the actual encryption key or the local ip address for these cameras, like it does for the other cameras
My understanding is that @mrlt8 is not interested in reverse engineering or implementing an implementation of a reversed-engineered solution (totally speculation). I say this only because the currently-supported cameras are implemented by Python library derived directly from a leaked copy of the library from the ThroughTek (Tutk) IoT SDK [1].
These new cameras do not use the Tutk IoT SDK and instead use Gwell Times. Most of you know this already, but going back to what I originally said...
It makes me think that, unless someone comes up with the library from the original Gwell Times SDK (which I believe is floating around on Github, maybe?), AND an SDK key, AND @mrlt8 is willing to spend all of that time implementing another SDK (take a look at the amazing work he's done already in https://github.com/mrlt8/docker-wyze-bridge/tree/25a2bdfa2ad7f992de4db5cac55923fbb68779a6/app/wyzecam and that's despite the massive, massive amounts of heavy-lifting that the Tutk SDK's native library already handles), reverse engineering the packet dumps won't be of any help for an actual implementation.
I don't know how easily getting an SDK key will be though. That might be the tougher of the two things to accomplish.
Nothing I've said here about @mrlt8 represents any degree of accuracy. I'm not a developer or contributor on this project. I am a software developer, but I don't have the time or A/V / mathematical knowledge to accomplish the end result. These are just my impressions and interpretation since @mrlt8 has been a bit quiet on the topic.
[1] See
docker-wyze-bridge/app/wyzecam/iotc.py
Line 55 in 25a2bdf
While I was a huge fan of the original v2 and v3 cams (and still own more cams than I actually need), I have little interest/need for any of the gwell cameras. These newer models are very cloud dependent and have a higher chance of becoming ewaste if wyze drops support and/or goes under.
However, I am still working on an alternate way to add support for the newer cameras - the floodlight pro and the unreleased doorbell/outdoor cam also seem to be from yet another manufacturer so I'd like to find a solution that could potentially work across multiple platforms.
As for the gwell related credentials, has anyone looked into
https://wyze-mars-service.wyzecam.com/plugin/mars/v2/regist_gw_user/?
I can provide the signature keys for the relevant app-ids if needed.
my Micro Center is selling these for $15..picked up a few. How are things looking for eventual support of gwell cameras?
@mrlt8 i think the common platform with the new cameras even between the different mfg's is the Realtek Ameba Pro 2 IOT Platform:
https://www.amebaiot.com/en/amebapro2
https://github.com/ambiot/ambz2_sdk
https://github.com/aws-samples/amazon-kinesis-video-streams-producer-embedded-c
Also looks like the tiny cam pro developer has figured out support too. may be worthwhile decompiling that app.
Thanks! Will try to take a look when I get a chance!
Thanks! Will try to take a look when I get a chance!
I've done some very preliminary inspection of how TInycam is accomplishing this and I believe the developer applied for, and received, the Tencent SDK to interface with the Gwell cameras. The Tencent SDK is definitely inside of Tinycam, along with some heavy mathematical obfuscation methods, likely to mask the developer's SDK key.
Some interesting strings:
https://wyze-mars-service.wyzecam.com/
wyze-mars-asrv.wyzecam.com
wyze-test-list.cloudlinks.cn
The rest of the class is very, very, VERY heavily obfuscated, and even AI-based decompilation would struggle given the degree of nesting.
Either way, it appears the developer went the legitimate route and just obtained an SDK and a key for it.
It should also be noted that even TinyCam's implementation only runs/supports the new OG/Doorbell Pro on ARM devices. There is no x86 support. And the TinyCam DEV had been hired to actually do work for Wyze, not sure what or the end result of that. This is me asking as much as suggesting, it seems like support for the Gwell/Tencent products, such as the OG and Doorbell Pro, are highly unlikely to be supported due to the complications/limitations?
It should also be noted that even TinyCam's implementation only runs/supports the new OG/Doorbell Pro on ARM devices. There is no x86 support. And the TinyCam DEV had been hired to actually do work for Wyze, not sure what or the end result of that. This is me asking as much as suggesting, it seems like support for the Gwell/Tencent products, such as the OG and Doorbell Pro, are highly unlikely to be supported due to the complications/limitations?
He got hired by wyze? where did you read that?
He got hired by wyze? where did you read that?
I am not so sure about the no x86 support either. I am viewing my doorbell cam with TinyCam pro, I am on a chromebook, but it does work and my chromebook is not ARM, it is an Intel I5-8350U
I am not so sure about the no x86 support either. I am viewing my doorbell cam with TinyCam pro, I am on a chromebook, but it does work and my chromebook is not ARM, it is an Intel I5-8350U
Merely am quoting the developer of Tinycam. https://www.reddit.com/r/tinycam/comments/159x0gg/comment/juuy0di/?utm_source=share&utm_medium=web2x&context=3
have we got any news ? how can we help to move this forward? Thanks
It sounds like to me there are two ways to actually push this forward. The first would be for someone to reach out to Wyze/Alexey and see if we can cooperate and be on the same team here. The second would be for someone to spend a decent amount of time trying to implement the Realtek SDK and/or the Tencent SDK into the bridge which will seemingly be quite difficult given many unknowns about the credentials and auth management needed. I am happy to do the first and see if we can get anywhere by gaining knowledge from Alexey and Tinycam. If that does not go anywhere then people can speak up on what they know or how much they can contribute to getting anywhere with adding the new SDKs and figuring out the auth steps that will be needed. @mrlt8 how does this sound to you?
Or a third option: just ask Alexey how the authentication and credentialing is to see if the second option is more practical.
@nbetcher Sure, but this is still basically the first option.
I have reached out to Alexey on LinkedIn to see what insight he is willing to provide.
An update: I have successfully backed out the wyze information needed to get the p2p accessId and accessToken and this is working in python. With these two pieces of information along with a deviceId, p2purl (known) and the aformentioned iotvideo SDKs we might get somewhere.
At the moment, I am trying to load up the iotvideo sdk in python similar to the tutk library that is already implemented. This is where I could use some help probably from @mrlt8 since my knowledge is being stretched. I have the .so files for the libraries but I can not call any functions by name after loading them with ctypes CDLL. I am curious if you could offer some insight or if you would be interested in taking a stab at it yourself.
Regardless, half of the equation is pretty much done which is getting the credentials from Wyze so that is progress. I will keep pushing on getting these libraries to play nice in python but until then happy coding!
@carTloyal123 that's awesome 😎
- Do you have your WIP committed somewhere to peruse or experiment with?
- Where did the .so file come from? (i.e., extracted from an android APK, iOS app, some other backchannel, etc? More directly: what platform was it intended for?
- If the .so file was not actually written for Python's C API you'll need to do some wrapping, in order to act as a bridge between the Python runtime and the C library, so that the Python runtime can call the wrapper, which will import this C library and call the target code in that library. Have you already done this? See https://docs.python.org/3/extending/extending.html
Not committed anywhere yet, I will put it in a PR for this repo soon. Libraries are currently from the wyze app apk on android and since they only support ARM platforms it seems like they do not like to be loaded. I have been trying using an aarch64 machine but still no luck. The issue is not being able to wrap them, that is trivial, the issue is working out how to even execute the binaries on a platform other than android. There is a windows dll which might be useful but I have not tried it. Since Tutk has an x86_64 version it works fine but that is not the case here for the iotvideo sdk.
I do have some more ideas to test to get these binaries working but we will see. I think it might be an issue with my setup since I can't even load the Tutk library from this repo🙃
Yes for sure, an arm or other .so file will not load on an x86 or other architecture. But Android re-bundles APKs based on the device that is installing the app. So if you installed it from an arm device, you would only get the arm libraries.
Best case would be to install it on an x86 or x86_64 device, and extract the so files from there. Then it should be able to load on a target system assuming the arch matches (or is compatible).
On my device for example, I have:
/data/app/~~UaTVuHj6tdXhp4vEFFTVCQ==/com.hualai-pN8RQUbB4pQPzWA8Lyj66w==/:
-rw-r--r-- 1 system system 105254430 2023-08-18 05:10 split_config.arm64_v8a.apk
But installing on another arch should provide other arch splits.
As far as I can tell that actually is not the case. Each apk comes with all the needed binaries for every architecture. At runtime the developer has to check the current platform ABI and load the desired library if available. You can see this quite clearly by decompiling any apk. There are folders for each architecture type and browsing the decompiled code shows system calls to check ABI and selectively load binaries.
Now this brings me to the really interesting finding that someone on this thread is running tinycam on their x86 Chromebook and viewing their doorbell. @ramboton would you be able to do some digging by chance on this? I'm not super familiar with what android does to install apps but there has to be a place to store all the libraries somewhere and if you wanted to see if you can find that that would be awesome. You're looking for a folder called 'x86' or 'x86_64' and the file will be called 'libiotvideo.so'. I am guessing that the Chromebook has an emulation layer but hopefully I am wrong and we can magically find the x86 files we need.
I've been an android developer for over 10 years. The file I showed listed above is named "split" because it is from an "APK split", which works exactly as I described, and it is very well documented. If the app was published as an APK initially by the developer, then yes it must include all architectures it will support, but that hasn't been the best or most common practice for many years. If the developer publishes the app to the play console as an AAB (Android app bundle), then the play store will automatically deconstruct it and create all the splits needed and will deliver only what is relevant to your device when you install it.
That said, the AAB that was uploaded must have the architecture support to begin with, so if they never intended to support an architecture, play store won't magically create it for you. If it can be installed on an x86 device (i.e. an emulator would be my first suggestion), then the split will be present there.
According to apkmirror, they only publish 2 variants, arm64-v8a + armeabi-v7a:
https://www.apkmirror.com/apk/wyze-labs-inc/wyze/wyze-2-44-5-330-release/
And trying to open Google Play store on an x86 emulator to install it, gives this:
So they simply don't support the x86 ABI.
If it was working previously on an x86 Chromebook, that would have been using the Chrome OS android apps support, which works by using ARM translation (like an emulator): https://developer.android.com/topic/arc/device-support#arm-translation
This is all fine. Either way the issue still remains that we need a way to load the libiotvideo.so library that comes with Wyze or TimyCam. I assume this is possible since @mrlt8 has been able to do the same thing for the TUTK binary. It also looks like @mrlt8 has combined the tutk and iotcapi binaries into one so I would definitely like to know more about that if possible. So far the iotvideo sdk requires at least 5 binaries so it would be great to only end up with one. @mrlt8 did you have to do anything special to get elf headers corrected from the tutk binary?
It was my understanding that @mrlt8 obtained the C library from some other undisclosed source, I do not believe it came from the mobile apps, but from some other private or internal source. 🤔 but now I can't find the reference to that information to backup that notion.
The amd.lib and arm.lib files in the docker app dir are described as:
amd.lib: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8dc56493821b4c11df52c05f77bedd7d12339ef5, not stripped
arm.lib: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=0fa09d0d94da421c35c658683d7a3d7807e422af, not stripped
So this being the case, it's possible that your ARM lib might work on a raspberry pi, or other ARM based host? But for it to work on an intel or AMD based architecture, we'll need to find another source for x86, x86_64, or amd64 libs.
It doesn't appear that iOS apps would contain an x86 binary either, unless the app is intended to run on the Simulator. Otherwise it's all ARM based. If there were a macOS app, that would surely support x86, but I do not see one.
The tutk library that we use comes from the SDK which is compiled for linux:
Library files (.\Lib)
To provide the greatest portability, TUTK IOTC platform supports many popular platforms and corresponding development environment. The corresponding libraries are listed as following for use when linking executable files.
| Platform | Directory |
|---|---|
| Android | .\Lib\Android |
| Google Native Client | .\Lib\NaCl |
| iOS | .\Lib\iOS |
| Linux (Embedded Linux) | .\Lib\Linux<SOC> |
| MAC OS | .\Lib\MAC |
| Windows | .\Lib\Windows |
| WinRT | .\Lib\WniRT |
https://www.sunipcam.com/sdk/Readme.htm
I don't believe it's possible to use the andorid (bionic) library directly in linux and we'd need to run some kind of emulation or convert it to glibc with something like https://github.com/Cloudef/android2gnulinux
The iOS libraries may have potential to run natively on MacOS with the ma1/m2, but not sure if it could be done in a docker container?
Thanks @mrlt8 for the update. That is most helpful since I think I was assuming the binary had come from an android/ios app.
Looks like android2gnulinux might be an option. At the moment I am pretty fascinated by https://github.com/libhybris/libhybris/tree/master/hybris so I am going to see if I can get a basic example of this working. From what I can tell this should be a decent way to generate C bindings, then wrap in Python when needed. It will be a long process but does at least offer some hope that this is possible. Let me know if anything else comes up or other comments!
So, I have been looking into running android libs on normal linux systems and there is some possibility that that is possible but I have hit a number of dead ends. I am going to explore my second thought which is create a basic android app that acts as a proxy for the iot video lib. I think this has much more potential since the android app can be packaged up nicely and emulated on any platform with qemu or other tool. The idea is the create an android app and expose the iotvideo library through a websocket/REST api to the outside world, implementing features as needed. Will come back with more once I have spent some more time with this second idea.
Apologies for falling behind in the conversation — and although I did skim through all replies since my last, I was unable to answer this question — I'm confused though, why are we bothering with the TutK SDK (which is already fully implemented and in this project) when the it's the Tenscent SDK that is used for the Wyzecam OG/etc?
Tutk SDK is of course done. We are only talking about the iotvideo.so library found in the GWell repos and in the wyze/tinycam apks
the SOC in the OG is the same as this dev board (AMB82-MINI)
doc is here https://device.report/m/f97fabeccb918a1d2e6c4183aeca88e7ba92ae3eff1dec7f4bbc47ef76dba633_optim.pdf
I'm not an expert in audio-video processing, but I assume that both the audio and video have timestamps. Is it possible to buffer them individually and, once we have a buffer built up, compare these timestamps when combining them into one stream? Can we adjust the buffered content to compensate for a delay in either the video or audio?
The raw h264 bytes don't contain any PTS/DTS/timestamps. The tutk AV module does include the timestamp to the micro second with each frame, but I don't believe it's possible to pass that to ffmpeg?
I believe the current sync issue seems to come from the mismatch in the number of video/audio frames if/when the camera drops a frame or is slow. When that happens, the muxer seems to pause the audio till it receives the next video frame causing the audio to lag behind or, if using the wallclock to set the timestamps, the audio will continue while the video slowly drifts behind as the camera starts producing frames and muxer doesn't seem to realize the video is behind since it's using the wallclock to set the timestamp as they arrive..
Just chiming in to voice support for an OG solution. I have both a M2 Mac and PC that I am happy to test on if it is helpful.
Sorry for the delay, hope to have something up for testing soon.
Amazing, is this something to test for the doorbell pro and cam og?
@mrlt8 anything others can help with?
I'm happy to test with OG Cam as well. Thanks!
Will need to look into it, but I believe the doorbell pro/pro 2 require a wake command so I don't think they'll be supported.
@mrlt8 that makes sense. Are you using the iotvideo sdk for the og cam or some other approach to interface with it?