Possible for mini hacks to work with WC3 beta fw? #458
Replies: 6 comments 29 replies
-
|
All of my wz_mini v3s are running the Wyze RTSP Beta 4.61.0.3 firmware with zero problems. You may want to review your wz_mini.conf file and/or the README for appropriate settings. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I see my post is not clear. The reason I am looking at the mini hacks firmware, is the hope that the RTSP implementation on it, is BETETER than what Wyze has done via their own beta firmware. I do have mini hacks working, on the wc3 that has the beta (RTSP) firmware. However, the RTSP mini hacks implementation is not working. The WC3 beta firmware RTSP stream works, I can turn it on/off from Wyze app. No problems. This is what I was referring to in particular. Are you using the RTSP stream from minihacks from from the Wyze beta FW? If it's that latter, could you test the minihacks RTSP and see if it works for you, and the stream has both audio and video. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
Hmmm... Now that you mention it, I may indeed be streaming from the Wyze app and not wz_mini. I'll double check what I actually have going on and report back. |
Beta Was this translation helpful? Give feedback.
-
|
Sooo.... After trying the various possibilities using VLC with a Wz_mini 4.61.0.3 v3 and RTSP set to 'off' in the Wyze app, I was still getting a stream on 554 using the stock Wyze /live v. /unicast single stream URL. Audio was enabled in wz_mini.conf and functional. I changed to the /unicast URL with the same results. I then switched to port 8554 in wz_mini.conf with the same results, though VLCs cache began not playing nice at that point due to what it seemed to perceive as multiple streams from the same source and/or IP conflicts (or both) since I was doing all of this on one camera. What could not be tested to absolutely differentiate between stream sources was the port in the Wyze app itself, though the general conclusion indicates the wz_mini config is the primary source of the stream in general. -- at least according to VLC. A quick and dirty TinyCam comparison basically confirmed VLCs results, but each were a little squirrely in their own particular way still leaving a question or two. I didn't do any testing with Blue Iris which introduces a slightly different convention to how it handles RTSP. That would be the platform to maybe drill down a little further into this simply for the path variation testing flexibility it offers. Better yet, maybe use all three platforms simultaneously. rtsp://192.168.1.57:554/'live' streams fine with audio - RTSP active in Wyze app Port 8554 also worked when tested using the /'live' url which indicates wz_mini over-rides the Wyze app port but still recognizes the path..., or isn't necessarily all that particular once the initial authentication is established. I saw no discernable difference in image quality among the tests but wasn't really focusing on that. I'm curious how the same tests play out on my BI server and may have time later to mess around there a little. I know it uses the http:// v. rtsp:// method to establish the path but don't really understand how that works. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting infos there!! What I was trying to do is to use RTSP from mini hacks, so use a different port with /unicast, the reason being is that there are some "optimizations" that can be done in RTSP on mini hacks (bitrate etc) vs Wyze app which is just on/off. However, port 8554 with /unicast doesn't not work for me as I am getting just audio and no video (video is black). Did not try the RTSP default port with /unicast, nor the 8554 port with /live. I will check on this later today and run through some of the scenarios above that you mention. I'm also testing this on a single camera. |
Beta Was this translation helpful? Give feedback.
-
|
I'm running FW 4.61.0.3 on the WC3 and have the following settings for mini hacks. RTSP_LOGIN USERmh Testing with RTSP turned ON in Wyze App results: rtsp://USERwyze:[email protected]:554/live rtsp://USERwyze:[email protected]:554/unicast rtsp://USERmh:[email protected]:8554/unicast rtsp://USERmh:[email protected]:8554/live RTSP turned OFF in Wyze App results: rtsp://USERwyze:[email protected]:554/live rtsp://USERwyze:[email protected]:554/unicast rtsp://USERmh:[email protected]:8554/unicast rtsp://USERmh:[email protected]:8554/live |
Beta Was this translation helpful? Give feedback.
-
|
And just for the record, here's the Wyze RTSP firmware Codec info for comparison and convenient reference.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks, this is also what I saw, only the Audio is different which makes me wonder which is better in terms of the quality that it provides? |
Beta Was this translation helpful? Give feedback.
-
|
Given the mic in the cam, I highly doubt there will be much difference in the end result of either audio codec! |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, this is what I think too, but maybe if one is more compressed over the other, that one would not sound as clear/good. I'll post back if I find out anything! |
Beta Was this translation helpful? Give feedback.
-
So now that you mention it, I recall reading that larger cards that 32GB are supported, but there is some manual work to format them in order for it to work properly. I will look into this if I consider using this in the future though! |
Beta Was this translation helpful? Give feedback.
-
|
I'm getting contradictory results this morning using multiple platforms compared to those I posted yesterday. The most glaring being port 554 is not open using wz_mini with the /live MRL unless it is enabled in the Wyze app. Which stream it actually is will require additional investigation, but disabling RTSP in the Wyze app immediately kills both the video and audio indicating it is the 4.61.0.3 BETA stream. The other default wz_mini ports all still show open according to a port scan even though the Wyze app is no longer recognizing the SD card for whatever reason. I'm unable to get a stream from port 8554 with either MRL today. Power cycling the camera does not appear to boot from the SD card today, though the wz_mini ports are still accessible as though it does. I can only assume that's a Wyze app or 4.61.0.3 issue since wz_mini functionality is still available -- with the apparent exception of the RTSP server on port 8554. The only explanation I can offer for yesterday's results is the possibility of misinterpreting what I was seeing due to a certain level of haste in the process, or the fact that I was doing everything with VLC on an Android TV box which admittedly began providing mixed signals the more I got into it. Now to determine why the SD card is not recognized while wz_mini functions remain active. |
Beta Was this translation helpful? Give feedback.
-
|
I'm a bit lost. So I would like to use the camera with the mini hack fw on the SD card. Via wifi, as usual. However, in some instance as I was doing RTSP testing I was using the POE dongle that gives it both power and ethernet. So for these both instances to work, booting with just a microUSB for power, or booting via the POE dongle, what do my settings need to be? I am using the bonding feature as I want it to have the same IP whether it's on Wifi or on Ethernet (POE dongle) basically as I want BI to capture on the back, so I can't have 2 different IPs. |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand the bonding and have nothing to offer on the subject. I didn't realize it could be used for assigning the same IP address to two individual pieces of hardware and thought it was just a basic failover method that would resort to a backup hardware connection and the IP address already issued to it -- or obtain one accordingly when failover occurred. Its application relative to Blue Iris is another conversation altogether, but I would be putting my eggs in one basket or the other for the most reasonably reliable performance of the system instead of anticipating the need for the bonding which may or may not respond as intended. Unless there is redundant powering to the camera to accommodate a failover from POE to an otherwise functioning wi-fi network, I still don't see a practical application for it. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's a good point (if using the dongle and power on the POE switch is out, well power is out on the camera). However, I understood the implementation in such a manner that if I use the POE dongle, or after, I remove the dongle and just use a charging cable (so wi-fi) the bonding feature would set up a virtual NIC with a unique MAC, this would stay the same whether using WiFi or Ethernet. So, in my case useful if I move the camera from the POE dongle location, to one with just power, the BI backend would be able to work with the camera as it would be the same IP. In practice however, this didn't work. If I remove the POE dongle, and just used a charging cable, it would no longer connect to wifi. At this point, I will use the WC3 with the Wyze beta FW as I was; the RTSP issue as well as the Wyze app not seeing the SD card are two things that won't work for me. We will see in the future if I have an application for the POE dongle. Cheers for all the testing on your side, it's been very helpful!! |
Beta Was this translation helpful? Give feedback.
-
|
My pleasure. I thoroughly enjoyed the exercise and also learned a lot in the process! But you now have me thinking about the bonding... LOL |
Beta Was this translation helpful? Give feedback.
-
|
As a possible solution to your bonding issue, you may have success failing over to Wi-Fi from ethernet by simply setting 'wlan0' as the default PRIMARY instead of 'eth0'. Could it be that simple? Probably not. LOL Your general issue of Wi-Fi not re-activating when disconnecting from the ethernet adapter would be remedied by disabling the USB/ETH function in the wz_mini.conf file and rebooting the camera to establish the change prior to disconnecting the adapter. This will automatically re-activate the Wi-Fi driver and initiate dhcp discovery for an IP address, albeit a different one than was assigned to the ethernet adapter -- which obviously is what you are attempting to avoid with the bonding in the first place The bonding aside, and not knowing any details of your Blue Iris implementation, having an 'A' and 'B' IP address profile in Blue Iris for the same camera would certainly be simple enough to set up and manage, if not even simpler than the bonding. And I just read the entire README history and noticed several references to RTSP difficulties and improvements along the way including not working under certain circumstances. None addressed the issues we attempted to sort through here. Perhaps they've been acknowledged somewhere, but not anywhere I'm aware of -- certainly not here to the extent of our interest in the subject. Taking that into consideration along with your blessing, I'll escalate it when I have time to do so in an appropriate manner. I'm still not sure about the protocol around here except for what appears to be a mandatory lack of urgency about anything. LOL Cheers to you as well! |
Beta Was this translation helpful? Give feedback.
-
|
So after reviewing everything we've covered here, I'd say the answer to the original question is obviously yes, but with the major caveat that the Wyze Beta RTSP server overrides the mini-hacks RTSP functionality (even when disabled in the Wyze app), thus rendering the wz_mini RTSP features essentially non-functional when installed with the Wyze 4.61.0.3 RTSP platform -- which defeats the whole purpose of using wz_mini with 4.61.0.3 at all, unless of course using it for the USB/ETH/POE functionality and perhaps any number of other more esoteric reasons. Even if wz_mini could disable the Wyze RTSP server on bootup, a failover to the Wyze firmware would still require either a configuration toggle for the RTSP service in the web GUI or a restart some other way -- or removal of the wz_mini SD card followed by a Wyze only firmware reload that would presumably start the RTSP server automatically as normal. All of this considered, I've found 4.61.0.3 to be very reliable and an extremely solid performer only made better by the USB/ETH/POE capabilities available with wz_mini -- and frankly, the only reason to use it now that I know the Wyze BETA was doing the heavy lifting all along anyway. This is important information, at least IMHO. I'm surprised it isn't more widely known or acknowledged. It sure would have made my day a lot more productive in more practical areas of activity if it were! |
Beta Was this translation helpful? Give feedback.
-
|
I hope this gets documented somewhere in the notes; I'd say that the people most likely to come here and use mini hacks are already using the RTSP beta FW. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. With your permission I'd be more than happy to follow up with a summary of our activity and perhaps introduce the subject to the 'Issues' section to see what illumination the developers may be able to provide. |
Beta Was this translation helpful? Give feedback.
-
|
No problem at all, would be great if this would get resolved and we could use the beta with mini hack RTSP!! |
Beta Was this translation helpful? Give feedback.
-
|
Just a quick follow-up note regarding your 'audio only' stream issue. I couldn't leave well enough alone and continued messing around with this -- mainly trying figure out what was going on between my various instances of VLC and the varying degrees of consistency in the results being provided. After again trying several of the permutations already explored above, I did encounter the 'audio only' condition basically by coincidence. In this particular case. it had already been disabled in wz_mini.conf and the camera rebooted. Audio remained without video along with stability issues between what the app was doing and what the web GUI and other monitoring was telling me should be happening. (I generally write that off as cloud delay and just being impatient.) The short version is a power cycle to reload wz_mini was required to settle things down and actually apply the audio setting changed via the web interface. I made several attempts by rebooting both with the web interface and the Wyze app after saving the configuration again each time without success. I can't help but wonder how many other soft reboots were equally as ineffective during all the other experimentation. It could certainly explain some of the inconsistent results I initially experienced. Then again, I haven't pulled the SD card to look at log entries for explanations, either. Should probably look further into it just because. Anyway, just thought I'd toss that out for consideration if you're also still playing around with the Beta. I didn't load the stock firmware again to make a comparison in behavior, but would put money on it working correctly compared to the "hybrid" relationship between the Beta and wz_mini RTSP functions. |
Beta Was this translation helpful? Give feedback.
-
Is it possible for the mini hacks to work with the beta (RTSP) wyze cam 3 firmware?
I loaded up my cam but don't get any video feed, even when I turn off RTSP in the wyze app?
Any workaround for this (i.e. use a different RTSP port in mini hacks) or chance to get this working with the RTSP beta firmware. I'd like to stay on this as a backup in case I pull out the SD card.
Not sure if I posted this in the correct section
Beta Was this translation helpful? Give feedback.
All reactions