Echo Show 5 not working.....

JWealthall

Reolink cameras appear to work if you use the _sub stream instead of the _main

Monocle

That is because the Echo Show 5 is limited to 1080P and lower streams. So the sub stream is almost always lower then 1080p.

JWealthall

@Monocle indeed :) It’s 720p apparently. Was only putting it out there in case someone was trying with Reolink cameras

Monocle

@JWealthall

Thank you for contributing! I was just giving the technical reason for this to help future readers understand why :-) Thanks, Robert

rook

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”.

Monocle

@rook

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.io

Thanks, Robert

rook

@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.

Monocle

@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

rook

@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 :)

lux4rd0

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

mattp

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)

Monocle

@mattp

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

mattp

@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.

Monocle

@mattp

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 7447

Basically 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

mattp

@Monocle

Ok, I think i might be getting close now. The host is fine, but I’m using a docker with a MACVLAN network which I forgot won’t allow connectivity to the host’s IP (the .100 IP) by design.

As this was throwing errors using the bridge network and I needed to move it onto a MACVLAN to get it to work, it looks as if the caveat on the docker monocle container is that it needs to use host net, which I can’t as I use host 443 for something else and proxy pass the gateway to the docker instance.

I’ll install the gateway on a spare RPI tomorrow and change my apache config to pass to that, and see if that solves it.

mattp

Couldn’t help myself and installed it now. Working fine on the RPI, so it was the docker networking. Whilst it would have been neat to keep it all together with my other home automation stuff, the RPI works fine and I’ll leave it.

Thanks a lot for your help, the answer was right there staring me in the face the whole time!

Monocle

@mattp

One snag on the RPi plan. The gateway will need direct access to port 443. Meaning it can’t sit behind an Apache or NGINX server as a proxy. Those web servers won’t proxy RTSP properly as well as the gateway presents it own SSL certificate fully managed inside the gateway. So it will need a dedicated IP interface. You could (via Linux config) add a secondary IP address to the network interface on the RPi and then have Apache use one IP and Monocle Gateway use the other. Some custom configuration for the gateway would need needed, but that is pretty minor.

Seems like the Docker approach could be made to work … somehow?

-Robert

mattp

My apache server is proxying the gateway no problems (it’s on another box) using the mod_ssl ignore settings:

SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
SSLProxyCheckPeerCN off

This tells apache to ignore downstream certificates as my apache server does the SSL termination.

My setup is an apache virtual host with it’s own certificate for monocle --> gateway on the PI --> unifi video container.

I’ve got no doubt I can work around the docker, there’s a bunch of good stuff on various forums on how to hack around the MACVLAN issue but to be honest it’s all just too hard to remember the next time I have to troubleshoot something, compared to the PI.

Monocle

@mattp

OK, I have not personally fully tested trying to run Apache as a proxy server. So if there is a way to get it fully working, I would love to understand the steps.

If Apache is performing the SSL termination, then are you using a custom FQDN setting in the Monocle Gateway’s properties to override the auto-generated DNS hostname? If not, then I don’t understand how Apache is delivering the correct certs to the requesting Alexa devices.

Thanks, Robert

lux4rd0

@mattp Will keep watching this space to see if you happen to come across a path forward on this. Fortunately I have enough hosts to run Docker on that one of them has an open port 443 to use against host networking. But it would be nice to define a different port. I expect it also has something to do with the Amazon devices not having any flexibility on that port as well. It’s not expecting to have something in the middle :)

Thanks!!

_DS