Echo Show 5 not working.....
-
@davep said in Echo Show 5 not working.....:
However it does mean that the PC has to be on and the service running which is a bit of a PITA and may mean that I’ll return the echo 5, I’ll give it a few days and make a decision as the screen itself looks quite low res (I’ll wait until I find my glasses before I can confirm that)
I fear this will be the case. This is the first “Echo” device that requires using the Monocle Gateway, but all of the newer generation FireTVs already require this. Its unfortunate and a hassle but I fear this is the way forward. I would not be too surprised if a firmware update comes out one day that forces all existing Echo Show’s into the same behavior requiring the Monocle Gateway.
Thanks, Robert
-
@davep said in Echo Show 5 not working.....:
I think that Amazon have messed with allowing cams on the new Show 5 so gateway may be the only way around the problem, I’m thinking of running a raspberry pi as a 24/7 gateway server… but then it may be even more trouble than the show 5 is worth
It’s most likely Amazon enforcing stricter connectivity requirements. They already do this with all the current generation FireTVs. All camera streams must connect using valid SSL/TLS certificates only on TCP port 443 and only using a valid public DNS hostname. Stupid requirements for local camera streams but Monocle Gateway is intended to satisfy these requirements for you … albeit at the cost of having to run it on a computer 24x7. A Raspberry Pi 3B/3B+ will work great as a dedicated little gateway server. I also have some new Raspberry Pi4s on order to test with them – but I don’t expect any significant difference apart from possibly the advantage of Gigabit hardwired ethernet on the new Model 4s.
Thanks, Robert
-
@Monocle said in Echo Show 5 not working.....:
Based on your screenshot of the Monocle Gateway, the Echo Show 5 is not attempting to connect to the Monocle Gateway. Your tags look fine, but we would expect to see incoming TCP connection attempts immediately after the “INITIALIZE RTSP STREAM” messages.
Make sure your new Echo Show 5 is on the same network and can access the Monocle Gateway. Many users have “Guest” networks or protected VLANS that may limit access to the computer running Monocle Gateway.
Thanks, Robert
I’ve sorted that out it was an IP address issue with my show but now have a new issue it will try and do this the usual three times and then timeout at a resolution of 720p or 1080p
-
I’ll add this is using the @proxy tag and if I use @tunnel it does the same but just takes longer to timeout which can be seen below.
-
Was having the same problem like everyone. Just drop the resolution down. My cameras are 4MP are higher. Show 5 won’t handle the stream that large.
-
{{ PANEL(warning, ATTENTION): I have posted an update on these requirements and our additional findings about the ECHO SHOW 5 here: http://monoclecam.com/echo-show-5. }}
-
Reolink cameras appear to work if you use the _sub stream instead of the _main
-
That is because the Echo Show 5 is limited to 1080P and lower streams. So the sub stream is almost always lower then 1080p.
-
@Monocle indeed :) It’s 720p apparently. Was only putting it out there in case someone was trying with Reolink cameras
-
Thank you for contributing! I was just giving the technical reason for this to help future readers understand why :-) Thanks, Robert
-
quite interesting… I am running the gateway on a raspberry 3 and the startup procedure looks good:
Jul 16 23:28:27 raspberrypiMASTER monocle-gateway[17604]: ****************************************************************** Jul 16 23:28:27 raspberrypiMASTER monocle-gateway[17604]: * __ __ ___ _ _ ___ ___ _ ___ * Jul 16 23:28:27 raspberrypiMASTER monocle-gateway[17604]: * | \/ |/ _ \| \| |/ _ \ / __| | | __| * Jul 16 23:28:27 raspberrypiMASTER monocle-gateway[17604]: * | |\/| | (_) | .` | (_) | (__| |__| _| * Jul 16 23:28:27 raspberrypiMASTER monocle-gateway[17604]: * |_| |_|\___/|_|\_|\___/ \___|____|___| * Jul 16 23:28:27 raspberrypiMASTER monocle-gateway[17604]: * * Jul 16 23:28:27 raspberrypiMASTER monocle-gateway[17604]: ****************************************************************** Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: ------------------------------------------------- Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: MONOCLE RUNTIME ENVIRONMENT Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: ------------------------------------------------- Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: VERSION = 0.0.4 Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: OS/ARCH = linux/arm Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: PROCESS = monocle-gateway (PID=17604) Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: TIMESTAMP = 2019-07-16T21:28:28.727Z Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: ------------------------------------------------- Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: MONOCLE GATEWAY SERVICE (Version: 0.0.4) Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: ------------------------------------------------- Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: [Monocle Starting] Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: [Monocle Connecting] Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: [Monocle Started] Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: [RTSP Server Starting] Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: [RTSP Server Listening] 0.0.0.0:8555 (RTSP) Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: [RTSP Server Listening] 0.0.0.0:443 (RTSP-TLS) Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: [RTSP Proxy Started] (PID=17613) Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: [RTSP Server Listening] 0.0.0.0:8554 (PROXY) Jul 16 23:28:28 raspberrypiMASTER monocle-gateway[17604]: [RTSP Server Started] Jul 16 23:28:29 raspberrypiMASTER monocle-gateway[17604]: [Monocle Connected] Jul 16 23:28:29 raspberrypiMASTER monocle-gateway[17604]: [RTSP Server Registered] Jul 16 23:28:29 raspberrypiMASTER monocle-gateway[17604]: ------------------------------------------------- Jul 16 23:28:29 raspberrypiMASTER monocle-gateway[17604]: MONOCLE RTSP SERVICE - INITIALIZED Jul 16 23:28:29 raspberrypiMASTER monocle-gateway[17604]: ------------------------------------------------- Jul 16 23:28:29 raspberrypiMASTER monocle-gateway[17604]: FQDN = a08d6cc4-cd8e-4062-a197-54b260e71af1.mproxy.io Jul 16 23:28:29 raspberrypiMASTER monocle-gateway[17604]: HOST = 192.168.1.3 Jul 16 23:28:29 raspberrypiMASTER monocle-gateway[17604]: PORT = 443 Jul 16 23:28:29 raspberrypiMASTER monocle-gateway[17604]: -------------------------------------------------No errors so far. DNS Rebind is also fine. (can ping myself)
But none of my cams is working (foscam, vivotek, unnamed china cams).
Even though VLC can stream on RTSP.I tried all the @tunnel, @proxy,… TAGS . Even the logging displays no error, but “alexa” is telling me so.
Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: INITIALIZE RTSP STREAM: vivo Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: ------------------------------------------------- Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: - NAME : vivo Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: - LABEL : PRIMARY Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: - URL : rtsp://192.168.1.101:554/live2.sdp Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: - UUID : STREAM:c11faadd-9d51-4d08-b677-1fc2d5f6c3fe Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: - SESS : f35f2fbb-f1b4-5aed-4654-b8c51e24e24f Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: - MODIF : Tue Jul 16 2019 23:15:56 GMT+0200 (CEST) Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: - TAGS : @hangup,@tunnel Jul 16 23:30:44 raspberrypiMASTER monocle-gateway[17604]: -------------------------------------------------Resolution is at 1920 or below. Installed Token Key in /etc/monocle.
I am running out of ideas…I think I will wait for the next Echo Show Gen 2 Sale.edit: I just checked another post with some suggestions that I also checked…
root@raspberrypiMASTER:/etc/monocle # nslookup a08d6cc4-cd8e-4062-a197-54b260e71af1.mproxy.io Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: a08d6cc4-cd8e-4062-a197-54b260e71af1.mproxy.io Address: 192.168.1.3 root@raspberrypiMASTER:/etc/monocle #OpenSSL also reports a lot of keys, which seems “correct”.
-
It looks like you have verified everything is working properly on the Monocle Gateway side of things. And based on the log data we can see that the cameras are tagged and the system is sending down the streaming requests when you ask Alexa for a camera feed.
On a side note, you may want to test the ping, nslookup and openssl tests from a separate computer to make sure you can access the Monocle Gateway running on the RPI across your network. I suspect it will all be fine – but worth a check just to make sure.
At this point if you are not seeing any TCP connection coming into the Monocle Gateway (recorded in the gateway’s log) then its telling us that the actual Alexa devices are not able to connect for some reason. Are the Alexa devices on the same network? Not on a guest wireless or isolated VLAN? The symptoms suggest that the Alexa device is unable to connect to the Monocle Gateway.
One more thing to check … in the Monocle Web portal under your camera, there is a “Camera Feed History” button that will show you the response information that we send to Amazon when a camera request is made. Lets just verify that the “response.proxy” URL is the same host as your Monocle Gateway’s DNS hostname.
a08d6cc4-cd8e-4062-a197-54b260e71af1.mproxy.ioThanks, Robert
-
@Monocle, Robert
First of all… thanks for your response.
-
checked nslookup /openssl from a different workstation. ALL PASS
-
same VLAN.
-
I have to admit that this raspberry also runs the “PiHole DNS”, but I don’t think this is the root cause. I actually disabled PiHole while I was debugging.
The “Camera Feed History” is interesting, I didn’t see it untill you told me.
[ { "timestamp": "2019-07-17T17:29:59.373Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://192.168.1.101:554/live.sd", "proxy": "rtsp://a08d6cc4-cd8e-4062-a197-54b260e71af1.mproxy.io:443/STREAM:c11faadd-9d51-4d08-b677-1fc1d4f6c2fe?session=c802e93c-6b32-4459-bf40-5a53469e6c86", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] }Or other cam (unknown china cam)
[ { "timestamp": "2019-07-17T17:34:39.060Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://192.168.1.56:554/user=admin_password=_channel=1_stream=1.sdp", "proxy": "rtsp://a08d6cc4-cd8e-4062-a197-54b260e71af1.mproxy.io:443/STREAM:b89dc1e5-ad5d-4d0a-a8c7-d2d99af010d9?session=b6280471-a3dc-40ee-bbad-6538f9162204", "resolution": { "width": "192", "height": "192" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ]Nevermind. I will get a an Echo Spot when it is on sale.
Thanks again for your support. -
-
@rook said in Echo Show 5 not working.....:
Thanks again for your support.
I understand the frustration … Amazon does not make it easy to diagnose problems like this. I think we have done just about everything I can think of … apart from network packet sniffing the Alexa device to see if she is actually attempting to make the TCP connection to the gateway.
A couple of other users a reporting similar problems, I just hope its not a change on Amazon’s side that is preventing this from working in some way. It’s still fully working for me on all my test devices – including the new Echo Show 5, but this is a concern.
Thanks, Robert
-
@Monocle
Hi Robert,I had to retry it with an Echo 2. (the big screen).
And actually one CAM (no name china cam) got a response without the gateway. Even though it is puffering all the time. At least I was able to get a single screenshot.VIVOTEK, FOSCAM are still failing. Nevermind, I will close this project for myself now :)
-
Came here with the same issue of my new Echo Show 5 not connecting while my new Echo Show (2nd Gen) and Echo Spots all worked. I’ve been using a Docker deployed Gateway because of using UBNT Unifi cameras and at first thought it was resolution issues - but alas - as mentioned up above - using “@tunnel” as a tag in the camera config and all is good now. Just dropping a note here to say Thank You!! :)
_DS
-
I’ve been messing around for hours now trying to figure out what’s going wrong with getting my echo show 5 to display feeds from my ubiquiti cameras. Looking @ the logs and following all the steps, all appears to be working (DNS address is fine and pingable, my gateway initialises the RTSP stream, however it appears to get some kind of host unreachable error from the show 5, which is weird given the echo is on the same subnet / network as the gateway and unifi-video servers and all is working via VLC when I plug in the streams. I’ve even tried reducing the resolution to the lowest setting given the suggestions in this thread.
Any ideas?
06T12:58:08.751044149Z 06T12:58:08.751061632Z ------------------------------------------------- 06T12:58:08.751064484Z INITIALIZE RTSP STREAM: Back Door 06T12:58:08.751066569Z ------------------------------------------------- 06T12:58:08.751068787Z - NAME : Back Door 06T12:58:08.751083956Z - LABEL : PRIMARY 06T12:58:08.751091893Z - URL : rtsp://192.168.0.100:7447/5c7265ffe4b0726382487c31_2 06T12:58:08.751094483Z - UUID : STREAM:77f8f0e6-7b02-4673-9863-2d713920028a 06T12:58:08.751111689Z - SESS : b393918e-b80e-4abb-92d1-5dc379bbe711 06T12:58:08.751136049Z - MODIF : Tue Aug 06 2019 12:56:55 GMT+0000 (UTC) 06T12:58:08.751157795Z - TAGS : @tunnel 06T12:58:08.751177706Z ------------------------------------------------- 06T12:58:08.751194189Z 06T12:58:09.165839306Z 2019-08-06T12:58:09.165Z [INFO] [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT SOCKET CONNECTED 06T12:58:09.293504008Z 2019-08-06T12:58:09.293Z [INFO] [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT ATTACHED TO STREAM: Back Door (STREAM:77f8f0e6-7b02-4673-9863-2d713920028a) 06T12:58:12.299903221Z 2019-08-06T12:58:12.299Z [ERROR] [192.168.0.89:57646 <SyFwYlvXr>] [RTSP ENDPOINT SOCKET ERROR] [192.168.0.89:57646 <SyFwYlvXr>] Error: connect EHOSTUNREACH 192.168.0.100:7447 06T12:58:12.299978751Z [ '[192.168.0.89:57646 <SyFwYlvXr>]', 06T12:58:12.299984323Z '[RTSP ENDPOINT SOCKET ERROR]', 06T12:58:12.299986603Z '[192.168.0.89:57646 <SyFwYlvXr>]', 06T12:58:12.299988879Z { Error: connect EHOSTUNREACH 192.168.0.100:7447 06T12:58:12.299991177Z at Object._errnoException (util.js:1031:13) 06T12:58:12.299993332Z at _exceptionWithHostPort (util.js:1052:20) 06T12:58:12.299995504Z at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1195:14) 06T12:58:12.299997618Z errno: 'EHOSTUNREACH', 06T12:58:12.299999637Z code: 'EHOSTUNREACH', 06T12:58:12.300001559Z syscall: 'connect', 06T12:58:12.300003473Z address: '192.168.0.100', 06T12:58:12.300005492Z port: 7447 } ] 06T12:58:12.300082757Z 2019-08-06T12:58:12.300Z [ERROR] PROXY ENDPOINT ERROR; Error: connect EHOSTUNREACH 192.168.0.100:7447 06T12:58:12.300173362Z [ 'PROXY ENDPOINT ERROR;', 06T12:58:12.300181113Z { Error: connect EHOSTUNREACH 192.168.0.100:7447 06T12:58:12.300183682Z at Object._errnoException (util.js:1031:13) 06T12:58:12.300185843Z at _exceptionWithHostPort (util.js:1052:20) 06T12:58:12.300188030Z at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1195:14) 06T12:58:12.300190347Z errno: 'EHOSTUNREACH', 06T12:58:12.300192333Z code: 'EHOSTUNREACH', 06T12:58:12.300194333Z syscall: 'connect', 06T12:58:12.300196226Z address: '192.168.0.100', 06T12:58:12.300198478Z port: 7447 } ] 06T12:58:12.300214210Z 2019-08-06T12:58:12.300Z [INFO] [192.168.0.89:57646 <SyFwYlvXr>] RTSP ENDPOINT SOCKET CLOSED [192.168.0.89:57646 <SyFwYlvXr>] 06T12:58:39.294438531Z 2019-08-06T12:58:39.294Z [WARN] [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT SOCKET TIMEOUT 06T12:58:39.304254638Z 2019-08-06T12:58:39.304Z [INFO] [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT SOCKET CLOSED 06T12:58:39.304269048Z 2019-08-06T12:58:39.304Z [INFO] [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT DETACHED FROM STREAM: Back Door (STREAM:77f8f0e6-7b02-4673-9863-2d713920028a) -
Well that error is a little different than the usual posts here :-)
It appears from the log file that the gateway is unable to establish a TCP connection to IP address “
192.168.0.100” on port “7447”.I assume the answer is YES, but let’s just verify that this is the correct IP address of the camera and the correct RTSP port? (Most cameras use RTSP port 554.)
Thanks, Robert
-
It’s the address of my unifi video server, which manages all the unifi cameras centrally, and essentially takes over their interfaces and sends out its own RTSP streams for the cameras on port 7447. The rest of the URL points to the RTSP stream for that particular camera and resolution. It’s an ubiquiti thing.
I can’t stream direct off the camera without un-managing it, which isn’t going to work given it defeats the purpose of the unifi-video platform.
-
This error is just odd. It’s telling us that the TCP connection is failing. So it’s not even getting to the RTSP application layer protocol.
Can you try running this command from the same host that the Monocle Gateway is running on?
telnet 192.168.0.100 7447Basically we just want to see if TELNET can establish a socket connection to the Unifi server.
If you have FFMEPG installed, you can also test the RTSP stream like this:
ffplay -rtsp_transport tcp "rtsp://192.168.0.100:7447/5c7265ffe4b0726382487c31_2"Thanks, Robert
