-
-
Notifications
You must be signed in to change notification settings - Fork 151
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
Floodlight v2 - HL_CFL2 add support #1112
Comments
I have a few of these also and I'm not getting any stream data from them. It does pull metadata correctly though. |
@bcwik9 I was able to get this working using the dev branch and the following settings: I am using Unraid, and run this in a docker container there so, YMMV.
This allowed me to set the bitrate for the HL_CFL2 (QUALITY_FRONT_YARD_CAM) and a global value for everything else. Really hoping for higher bitrate support though, it would be nice. Now, just stuck with figuring out the balance of WAN traffic to these things (currently all blocked), since blocking WAN in on the cams will kill the RTSP streams for whatever reason. |
That ended up working, thanks for this @lonjee ! |
The Fingers crossed someone can figure out how to get higher resolution streams out of these cams. |
Yes, thank you @lonjee for that temporary workaround. I just bought 3 and love being able to see them I have it working on the docker |
I'm really hoping for a solution here. The workaround above doesn't really work for my needs, since the quality is very poor and the FPS is less than 1 frame per second. |
Could someone see if the HD stream works on the dev build? |
wyze-bridge | [WyzeBridge] WARNING: invalid escape sequence ':' |
Mine is also not working on dev branch:
|
Same, more of the same as above
|
Thanks @dreondre @bcwik9 @derekslenk! New dev image should be up in a few minutes. |
I just don't know what to make of this, besides it not working (driveway, sideway, backyard are all the floodlight v2's)
|
Actually, will delete that maybe, I might still be using sha |
@derekslenk it seems to be request the correct New dev build should be up in a few minutes |
Unfortunately, I am just getting
aka lots of the same. Hopefully someone else has better luck? eta, just saw this swing through
|
hmm, can you post the output of |
output from my
|
My camera info is alternating between
and
|
Here's my output if it helps: {"command":"camera_info","payload":"","response":{"1":1,"10":1,"11":2,"12":1,"13":1,"14":5,"15":2,"16":5,"17":2,"18":2,"19":0,"2":3,"20":1440,"21":2,"22":-4,"23":127,"24":100,"25":1,"26":1,"27":2,"28":2,"29":0,"3":30,"30":0,"31":100,"32":100,"33":1,"34":-1,"35":-1,"36":0,"37":0,"38":0,"39":0,"4":5,"40":0,"41":0,"42":0,"43":0,"44":0,"45":1,"46":30,"47":2,"48":50,"49":2,"5":20,"50":1,"51":0,"52":0,"53":0,"54":1,"55":255,"56":300,"57":0,"58":2,"59":1,"6":1,"60":0,"7":1,"8":1,"9":1},"status":"success","value":{"1":1,"10":1,"11":2,"12":1,"13":1,"14":5,"15":2,"16":5,"17":2,"18":2,"19":0,"2":3,"20":1440,"21":2,"22":-4,"23":127,"24":100,"25":1,"26":1,"27":2,"28":2,"29":0,"3":30,"30":0,"31":100,"32":100,"33":1,"34":-1,"35":-1,"36":0,"37":0,"38":0,"39":0,"4":5,"40":0,"41":0,"42":0,"43":0,"44":0,"45":1,"46":30,"47":2,"48":50,"49":2,"5":20,"50":1,"51":0,"52":0,"53":0,"54":1,"55":255,"56":300,"57":0,"58":2,"59":1,"6":1,"60":0,"7":1,"8":1,"9":1}} {"command":"camera_info","payload":"","response":"[-20021] AV_ER_SENDIOCTRL_ALREADY_CALLED","status":"error","value":null} |
Same issue on the nightly build:
|
Thanks everyone. I added a temporary patch that should just ignore the wrong bitrate as a temporary solution till we can figure out a way to read the actual bitrate value from the camera. |
Thanks for checking this out! I just tested the latest dev branch but still no luck. I'm getting the same messages from the API camera_info as posted above: {"command":"camera_info","payload":"","response":{"1":1,"10":1,"11":2,"12":1,"13":1,"14":5,"15":2,"16":5,"17":2,"18":2,"19":0,"2":3,"20":1440,"21":2,"22":-4,"23":127,"24":100,"25":1,"26":1,"27":2,"28":2,"29":0,"3":30,"30":0,"31":100,"32":100,"33":1,"34":-1,"35":-1,"36":0,"37":0,"38":0,"39":0,"4":5,"40":0,"41":0,"42":0,"43":0,"44":0,"45":1,"46":30,"47":2,"48":50,"49":2,"5":20,"50":1,"51":0,"52":0,"53":0,"54":1,"55":255,"56":300,"57":0,"58":2,"59":1,"6":1,"60":0,"7":1,"8":1,"9":1},"status":"success","value":{"1":1,"10":1,"11":2,"12":1,"13":1,"14":5,"15":2,"16":5,"17":2,"18":2,"19":0,"2":3,"20":1440,"21":2,"22":-4,"23":127,"24":100,"25":1,"26":1,"27":2,"28":2,"29":0,"3":30,"30":0,"31":100,"32":100,"33":1,"34":-1,"35":-1,"36":0,"37":0,"38":0,"39":0,"4":5,"40":0,"41":0,"42":0,"43":0,"44":0,"45":1,"46":30,"47":2,"48":50,"49":2,"5":20,"50":1,"51":0,"52":0,"53":0,"54":1,"55":255,"56":300,"57":0,"58":2,"59":1,"6":1,"60":0,"7":1,"8":1,"9":1}} Here's a snippet from my regular log as well:
|
Has anyone been able to confirm if the higher res size works on the latest dev builds? |
Hi, I pulled the latest |
I can confirm the same as @bcwik9 🚀 DOCKER-WYZE-BRIDGE v2.7.0 X86_64 DEV BUILD [2024-04-19t15:01:20.134z] ac54b8d [WyzeBridge] 🔍 Could not find local cache for 'auth'
|
Thanks, I made a few changes to the frame_size. Could someone give it another try? |
Awesome progress, thank you! The resolution is much improved! I am able to get a stream in Frigate via RTSP as well, though it's < 1 FPS. HLS stream via the web-ui does not appear to work. Here's my log:
|
Ahh, I think I had a typo. can you give it a few minutes for the new image to build and try again? |
I'm getting the same result. Resolution looks great, but HLS doesn't work and framerate is very low. |
Is it the same with the other streams like rtsp or webrtc? |
Actually forget what I said, HLS is working and FPS has improved. I think I needed to let wyze bridge fully boot. Again, amazing work and thank you for taking a look at this @mrlt8! |
I just rebooted and for whatever reason, the HLS stream doesn't start working immediately for the floodlight. It seems to take about 10 to 15 minutes. My Doorbell V2 camera HLS stream comes up as soon as the app starts. Odd behavior but one I can definitely live with |
* update docker/login-action * flush buffer when going out of sync * HD support for HL_CFL2 #1112 * Reduce sleep interval for video #1042 * AAC_ELD as AAC for v4 #1145 * limit clock syncs if video is slow * Use frame_size=5 for floodlight #1112 * Use K10050 to check HL_CFL2 bitrate #1112 * fix paho mqtt v2.x changes #1145 * don't specify sample rate if aac_eld #1145 * ignore bitrate for HL_CFL2 #1112 * K10058TakePhoto payload #1153 * access token * Adjust sleep interval on frame error #1042 * check for slow frames when no audio #1042 * Adjust frame_size for HL_CFL2 #1112 * fix typo #1112 * less aggressive buffer clean * changelog
Got RTSP working for both now in generic camera. |
I noticed there is no button to turn the floodlight on and off. There is one on the garage door opener though, even though mine doesn't have one. |
Could someone try the latest dev build to see if the bitrate issue has been resolved? |
@mrlt8 Just tried, and it did not load. Container crashed.
|
hmm, EVENT_API was removed after v2.9.x can you try pulling a fresh dev image?
|
I believe the error is gone
|
I recently installed the new floodlight v2 camera.
https://www.wyze.com/products/wyze-cam-floodlight
It looks like the web UI is able to pull a screenshot from the camera of when it last detected motion, but no luck refreshing on the fly or getting a video stream. The problem seems similar to the doorbell v2 prior to it being implemented.
I looked at the pull request for the doorbell v2 to see if there were obvious changes that could be made to the code, but nothing really stood out to me (I'm too new at this 🙃 ). It looks like some code was already added to support this camera. Let me know if anyone would like me to test any changes.
I am running this in a docker container (portainer).
debug logs for the camera:
The text was updated successfully, but these errors were encountered: