Alexa Suddenly Stopped with Unifi
-
OK after doing a bit of digging over at Unifi, I ran across a thread that addresses this issue in detail. First off, the folks over at Ubiquiti think that they added a feature and “feel” it is up to the “3rd” party vendors to make their software conform to UI’s code changes.
And I would have to say that about 99.9% of people using RTSP streams and Unifi and/or Protect UI for surveillance are VERY pissed off.
Some are submitting support tickets as I have done.Here is the Ticket that I submitted:
“Using Monocle Gateway to stream RTSP for camera connectivity to TV’s. After Last Protect Update, ALL RTSP streams via Alexa and Firestick have Stopped working. Stream from Monocle over to evostream.com looks good but comes back with an error on the RTSP stream and will not display. Apparently, you (Ubiquiti), has BROKEN that feature and now you BLAME it on the 3rd party apps??? Fixing Something that BREAKS EVERYONE’s RTSP stream is 1. NOT good business, and 2. Poor Judgment on the release without giving users a way to revert if we so wanted. WE (THE COMMUNITY) EMPLORE UBIQUITI TO EITHER DISABLE THE NEW ADDED FEATURE THAT BREAKS RTSP OR GIVE THE USERS THE OPTION OF USING YOUR NEW BROKEN FEATURE IF THEY SO DESIRE. THERE ARE FAR TOO MANY USERS THAT DEPEND ON RTSP STREAMS TO JUST KILL IT AND GIVE THE “FEATURE” REASON.”
THANK YOU
Dave
Let’s see what they do, if anything. they are known for ignoring major issues, i.e. their topology map for bridges … etc…
Dave Nugent BS MS
Fiber Optics/Network Design Engineer -
Hi @Dave1137
It will be interesting to see how Ubiquiti Support responds and if they are willing to roll-back the recent change.
This is not my area of expertise but reading between the lines I think Ubiquiti is heading in a good direction with eventual migration from AAC to Opus. Along with the introduction of “low latency video”, this seems to be part of continuing improvements to stream quality, scalability, and overall user experience. It’s unfortunate that UI released the changes without warning and some 3rd party clients were affected, but I do believe they’re still operating within the RTSP protocol.
All that said, Monocle’s troubleshooting tips (https://monoclecam.com/troubleshoot/tips) state that Alexa devices only support AAC and G.711 encoded audio streams, and that AAC is preferred (at least at the time of writing). So if UI does eventually make a wholesale switch to Opus, some transcoding might be required for future Alexa integration by any means. Hopefully UI will make such a change optionable in the system settings.
As you’ve noted and your gateway logs indicate, the current problem seems to be with the connection handshake. Other 3rd party clients were either already working fine with Protect 2, or have been able to make the needed adjustment to support UI’s change.
We need to hear from Robert @Monocle on whether he can fix this in the gateway. It would be nice, but my expectations are guarded. Monocle Gateway has been in beta 4 years, does not seem to be progressing towards commercial launch, may be insufficiently supported through donations, and Robert’s activity on this forum seems to come only in monthly intervals.
-
@GreggC Excellent post and yes I agree with you in moving forward and getting away from old protocols. And yes, since UI protect (although most likely proprietary) and VLC using RTSP still pull the cams up, I agree that it is with-in the RTSP RFC. It just would have been nice to offer an option, like they do for “legacy” and “new” interfaces. It’s not a big DEAL for me, since I know how to pull them up when I want. However, it is a big deal for those running enterprise nets that use RTSP for surveillance. It was not right just slamming the door and expect the vendors to jump to fix their software.
Anyway at this point it’s wait and see. I also agree with you on Monocle. It would have been nice for him to jump in on this thread with a heads up in the issue, rather than let us sit here wondering who’s issue it is. And now we know 😁.
-
Hi Guys … I apologize for not seeing/responding this thread until now. Based on what I’m reading in this thread it certainly sounds like (at least at surface level) some issue with the audio stream. Many camera’s continue to include the AUDIO stream in the RTSP communication even if the microphone is disabled. So it does not surprise me that the Unifi cameras behave this way. When using the
@noaudiotag in conjunction with Monocle Gateway, monocle attempts to remove the audio stream from the SDP (stream descriptor) . Maybe this is why some claim that disabling audio may have gotten it working. Incompatible audio streams have definitely been a problem with other camera vendors.To try and shed a little light on how Monocle and Monocle Gateway handle streams … neither the Monocle server nor the local Monocle Gateway software actually read or decode the actual audio and video stream data. Monocle Gateway simply tunnels/proxies the stream on a secure port to meet the Amazon Alexa requirements. It’s the endpoint Alexa/Echo device that do all video/audio decoding. In addition to this Monocle Gateway can optionally attempt to transform (modify) the SDP (stream descriptor) as part of the DESCRIBE step in the RTSP negotiation. These modifications to the SDP are added using the tags such as
@noaudio. So its basically Monocle Gateway reading the SDP from the camera and then attempting certain modifications to make Amazon happy. However, none of this actually affects the raw stream or codecs being used. Amazon has to support the camera’s stream data and codecs or it will fail. And sadly when a camera fails to stream on Alexa, it fails silently … meaning no errors codes nor any insight is provided as to why it fails. It’s literally a black box which makes troubleshooting stream failures very difficult to near impossible.In the past, I had considered for Monocle Gateway to take a more active role and providing options for transcoding camera streams using something like FFMPEG under the hood. This could allow Monocle Gateway to accept a wider range of camera streams and then transcode the output stream to a known working Alexa/Amazon compatible format. When I played with this type of transcoding implementation in the past, the performance was not great and it significantly increased the stream latency. This also increased the complexity and system requirements for the host system that would need to run Monocle Gateway. Hardware supported H.264 video encoding and decoding would probably be needed to even come close to a usable camera stream. Maybe its worth trying to revisit this option and see what’s possible.
Lastly, I don’t have any Unifi cameras to test with. I should probably get one. What would you suggest is a good Unifi camera model to represent a good test platform to try and benefit the majority of users? I do have other Ubiquity network equipment including the UDM-PRO where I could run their NVR application.
I too am frustrated in general by Ubiquity’s lack of follow thru on some of their hardware/software promised features and frustrated with some of their lacking support for features one would expect in prosumer / small business networking equipment. (Mac-assigned DHCP and overriding hostnames come to mind). However, I understand where they are coming from if they are adhering to the RTSP specification and if they have not removed any existing working codecs. Amazon on the other hand I don’t have the same understanding/forgiveness for. In all my experience with Monocle there are just so many camera streams that are incompatible despite meeting the technical requirements that Amazon states and trying to get anything debugged is mostly pointless. The lack of any ability to debug problems with streams is also frustrating and defeating. The inconsistency of behavior between different hardware models and platforms that Amazon puts out is also a nightmare.
<RANT>
Monocle Gateway has been in beta 4 years, does not seem to be progressing towards commercial launch
This is due in part to the inconsistent behavior and support from Amazon and a lack of any meaningful improvements in their support for IP cameras. If anything its only gotten worse since the original launch. When we first started we did not even need the Monocle gateway for most cameras but with the release of new Echo devices this became an absolute requirement for some models but not others. As of the last time I checked there is no support for RTSPS or H.265 codecs which many camera’s now ship with by default. There was also a strong feeling (earlier on) that Amazon could and potentially would pull the rug out from us at any time and leave us with no viable means to continue support. So I think these things were discouraging factors that gave us pause in trying to monetize the solution as we did not want to accept monies and not be able to properly support the product with Amazon’s revolving door of product releases and inconsistent support. With all that said … I am still very interested in maintaining the solution and keeping it running and hopefully finding some time soon to roll out some further improvements. Monetization is just not a high priority unless we can deliver a better experience for the majority of users.
</RANT>
Thanks, Robert
-
@Monocle - Robert, thanks for your reply. I can appreciate the situation with Amazon. Glad to hear you still want to improve Monocle anyway. It’s a neat solution.
I also understand your thoughts regarding transcoding. That’s a tall order.
For proof of concept, supply chain issues aside, the G3-Flex is a relatively inexpensive 1080P POE model that represents the basic Protect feature set well. It will work with your UDM-Pro for live view and RTSP even without a hard-drive.
Please note that with UniFi, there are two ways to do RTSP. The first is where the cameras are stand-alone and have not been adopted to a Protect NVR. In that case, you log into each camera’s web UI to configure its RTSP capability.
The second is where you adopt the cameras to Protect, and then RTSP is delivered as a service of the NVR, not the cameras. That’s how most people use it, and is where we are running into a problem now as per this thread.
Again, what seems to have introduced the problem is that Ubiquiti has recently added a second (albeit empty) audio track to the stream coming from the NVR. I haven’t tested to see if that’s also the case with cameras in stand-along mode.
-
@Monocle , All,
So just to pile on…
I have an UNVR.
Updated to 2.01 on June 3rd. Noticed a week ago my Alexa cam commands weren’t working.
I did the obligatory restart of the monocle program on my Win7PC. Did a reboot. No change.Finally had a chance to look at it. And finally checked the Monocle forum.
My VLC shortcuts in my PC are all still working well. They are OG, and have lived through many Protect updates and switching from UCKGen2+ to the UNVR w/o touching them.
My FireTV Cube(s) , I side loaded an android UI Protect app on there about a year ago, and it’s still working well. (The sticks just don’t have the HP to run the app well, need the Cube. Yes , even the 4K won’t run it well). I’ve changed all my 4Ksticks over to Cubes during the holiday sales, it works pretty good with the side loaded UI Protect app. Far better solution than buying a bunch of their ViewPorts.
But after tinkering , and finding this thread, yup, in the same boat, my Alexa access to the cams via Monocle are for-caca.
Robert, thanks for you post. Sorry to hear of the struggle. It certain answers the question why we haven’t seen a change to a paid version. I feel your frustrations.
-
@Monocle First off, thanks for the hard work you’ve put into Monocle/Monocle Gateway. It’s been rock solid with my Protect & Hikvision cams up until this latest amazon snafu.
Since Monocle Gateway stopped working with my Echo Shows, I’ve been using Scrypted plus the necessary plugins to get it working with my cameras & the Echo Shows. It’s nice that it works, but there is a lot that I miss about Monocle, mainly that the streams include audio which I have to turn down every time I start a stream, and, unfortunately, the streams crap out pretty often. Monocle could stay streaming on my Shows for days, which was great for a passive monitoring system.
All that is to say, you might want to reach out to the developer of Scrypted, koush, to potentially bounce ideas off of each other about your projects. He’s extremely active on the Scrypted discord, if you’re interested.
-
@pineapplebigshot I would have to agree. The overall solution was GREAT and I especially loved the gateway and HOW it actually operated, nice out of the box thinking. I have some friends that work at AWS, perhaps they can shed some light on what and why. I am thinking that Amazon is just pushing for their line of cams and are eventually going to lock all the others out. They want the home consumer, not the Prosumer or corporate.
Just my 2 cents…
-
Hi All
Been monitoring this thread but unable to reply as the forum sign up process was broken but now working.
As with others I have the same same issue post the Protect update and I have done a bit of tinkering based on what lots of other have said and can agree with others that I believe the issue is with the additional audio stream “upgraded” by Unifi.
The additional Opus audio stream is now the second channel in the stream with AAC being bumped to the 3rd channel within the stream.
I confirmed this by using several docker containers “datarhei/restreamer” & “aler9/rtsp-simple-server”.
Essentially you configure an input video stream in re streamer which is the direct RSTP URL for protect, re-streamer then asks which audio channel to use (select AAC).
Once the “input” stream is configured you then select and output stream (in this case the simple-rstp-server) configuration is fairly straightforward.
Test by connecting VLC to the streamer provided by simple-rstp-server.
Once tested add/modify the cameras in your account on the monocle website to use the URLs that connect to to the simple-rstp-server (instead on the URLs that connect directly to the protect device)
Cameras can then be displayed in the same way on your Show devices.
Obviously this is not a long term solution (and add some lag) but proved effective in validating the second audio channel is the issue as re-streamer is dropping that channel when out putting to simple-rstp-server.
@Monocle Would it be possible/easy to add additional tags so when using @proxy the channel with the stream can be selected something like “v0:a1” (first video channel and second audio channel, (assuming starting from zero) as I believe that would solve the issue?
-
As a side note you can also view the stream directly from re-streamer by launching bing on the alexa and navigating to the URL provided by re streamer for HTTP viewing. However the URL is really long so it doing this bookmark the site once added!
-
Yes … I think something like this could be possible while using Monocle Gateway.
@ Everyone
I have ordered a G3 Flex and G4 Pro camera to test with and try to find a workable solution. It should be here in the next week or so.
Thanks, Robert
-
Thanks Robert that’s amazing, if I can assist in anyway please let me know.
-
@RS said in Alexa Suddenly Stopped with Unifi:
Hi All
Been monitoring this thread but unable to reply as the forum sign up process was broken but now working.
As with others I have the same same issue post the Protect update and I have done a bit of tinkering based on what lots of other have said and can agree with others that I believe the issue is with the additional audio stream “upgraded” by Unifi.
The additional Opus audio stream is now the second channel in the stream with AAC being bumped to the 3rd channel within the stream.
I confirmed this by using several docker containers “datarhei/restreamer” & “aler9/rtsp-simple-server”.
Essentially you configure an input video stream in re streamer which is the direct RSTP URL for protect, re-streamer then asks which audio channel to use (select AAC).
Once the “input” stream is configured you then select and output stream (in this case the simple-rstp-server) configuration is fairly straightforward.
Test by connecting VLC to the streamer provided by simple-rstp-server.
Once tested add/modify the cameras in your account on the monocle website to use the URLs that connect to to the simple-rstp-server (instead on the URLs that connect directly to the protect device)
Cameras can then be displayed in the same way on your Show devices.
Obviously this is not a long term solution (and add some lag) but proved effective in validating the second audio channel is the issue as re-streamer is dropping that channel when out putting to simple-rstp-server.
Good to know, I might try this tomorrow if I get some time. Is this a one of step or so you need those containers running? I am using unraid so will see how far I can get.
FYI I have access to G4 Pro, G4, G3 Flex and G3 Instant if need to test.
-
Hi
For this to work the containers need to remain running.
Although I stress this is not a great solution it adds at least 30 secs lag.
I did it just as a diagnostic process not really as a solution even if only temporary.
If using re streamer I would would suggest just viewing it directly via the bing browser for now until @Monocle can hopefully provide and update. However this means forgoing the voice commands.
Full kudos and gratitude to @Monocle for his/there commitment to purchasing the cameras etc to try and provide a solution.
-
Yes , Much thanks for @Monocle for purchasing the UI cams… I’ve been using Monocle GW for a few years now. Sorry to hear of the issues. Been waiting for something to try. I’m just using the canned GW on a win7 machine. I have an assortment of G3 cams on a UNVR that runs the latest release FW and Protect. So I’m up for trying any setting changes in my Monocle setup in the portal for testing. I use VLC for select streams on my PCs. Still working fine The Monocle GW was/is a great game changer for my Amazon show devices.
-
Ditto, Alexa has stopped after an update.
I have two cloud keys, one updated, the other not and updated is broken, while older is working great.
Couldn’t add the relevant sections of the logs due to the over eager spam filter, but in summary I find that after an update (due to dual audio), the @noaudio has stopped working as expected, before (within the working logs), it stripped any description of the audio channel (no “m=audio …” descriptor in headers forwarded to Alexa within client response). Meanwhile the nonworking stream still has one of the two audio streams remaining (seems the code only removed the first one).In summary, seems Unifi has introduced a second stream, and Monocle is having issues filtering it out.
As I couldn’t add logs directly due to spam filter, here is the pastebin:
pastebin.pl/view/40882d18 -
Unifi Camera Update …
Please see : https://forum.monoclecam.com/topic/1242/unifi-camera-update -
@Monocle I have and Thank YOU Robert. Grabbing image as I write this
D
