Echo Show 5 with Unifi Protect [SOLVED]
-
(c) 2018 Microsoft Corporation. All rights reserved. C:\Users\stenc>cd.. C:\Users>cd.. C:\>cd monocle C:\monocle>monocle-gateway.exe ****************************************************************** * __ __ ___ _ _ ___ ___ _ ___ * * | \/ |/ _ \| \| |/ _ \ / __| | | __| * * | |\/| | (_) | .` | (_) | (__| |__| _| * * |_| |_|\___/|_|\_|\___/ \___|____|___| * * * ****************************************************************** ------------------------------------------------- MONOCLE RUNTIME ENVIRONMENT ------------------------------------------------- VERSION = 0.0.4 OS/ARCH = win32\x64 PROCESS = monocle-gateway (PID=18340) TIMESTAMP = 2019-07-18T12:51:27.948Z ------------------------------------------------- MONOCLE GATEWAY SERVICE (Version: 0.0.4) ------------------------------------------------- [Monocle Starting] [Monocle Connecting] [Monocle Started] [RTSP Server Starting] [RTSP Server Listening] 0.0.0.0:8555 (RTSP) [RTSP Server Listening] 0.0.0.0:443 (RTSP-TLS) [RTSP Proxy Started] (PID=30516) [RTSP Server Listening] 0.0.0.0:8554 (PROXY) [RTSP Server Started] [Monocle Connected] [RTSP Server Registered] ------------------------------------------------- MONOCLE RTSP SERVICE - INITIALIZED ------------------------------------------------- FQDN = 440e1290-b99b-4e3d-ad59-139d53424742.mproxy.io HOST = 192.168.98.1 PORT = 443 ------------------------------------------------- ------------------------------------------------- INITIALIZE RTSP STREAM: Drive ------------------------------------------------- - NAME : Drive - LABEL : PRIMARY - URL : rtsp://192.168.0.250:7447/882J4xdeDv7f79fS - UUID : STREAM:ae4033f8-5c7c-47e9-89b3-6362c16d3467 - SESS : 16cd93bc-f632-402f-bbc7-10de0dc4b7eb - MODIF : Thu Jul 18 2019 13:50:14 GMT+0100 (GMT Daylight Time) - TAGS : @proxy ------------------------------------------------- 2019-07-18T12:52:12.066Z [INFO] [RTSP PROXY] REGISTERING STREAM [Drive/PRIMARY]; (STREAM:ae4033f8-5c7c-47e9-89b3-6362c16d3467) 2019-07-18T12:52:12.072Z [DEBUG] <RTSP-PROXY> [REQUEST] --> [REGISTER] rtsp://192.168.0.250:7447/882J4xdeDv7f79fS 2019-07-18T12:52:12.073Z [TRACE] <RTSP-PROXY> [REQUEST] --> [HEADERS] { "cseq": "1", "transport": "reuse_connection=0;preferred_delivery_protocol=udp;proxy_url_suffix=STREAM:ae4033f8-5c7c-47e9-89b3-6362c16d3467" } 2019-07-18T12:52:12.074Z [DEBUG] <RTSP-PROXY> [RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined) 2019-07-18T12:52:12.076Z [TRACE] <RTSP-PROXY> [RESPONSE] <-- [HEADERS] { "cseq": "1", "date": "Thu, Jul 18 2019 12:52:12 GMT" } 2019-07-18T12:52:27.947Z [INFO] [RTSP PROXY] STREAM [Drive/PRIMARY] WILL BE DE-REGISTERED IN 4 MINUTES 2019-07-18T12:53:27.949Z [INFO] [RTSP PROXY] STREAM [Drive/PRIMARY] WILL BE DE-REGISTERED IN 3 MINUTES 2019-07-18T12:54:27.951Z [INFO] [RTSP PROXY] STREAM [Drive/PRIMARY] WILL BE DE-REGISTERED IN 2 MINUTES 2019-07-18T12:55:27.952Z [INFO] [RTSP PROXY] STREAM [Drive/PRIMARY] WILL BE DE-REGISTERED IN 1 MINUTES 2019-07-18T12:56:27.952Z [INFO] [RTSP PROXY] DE-REGISTERING STREAM [Drive/PRIMARY]; NO LONGER IN USE 2019-07-18T12:56:27.957Z [DEBUG] <RTSP-PROXY> [REQUEST] --> [DEREGISTER] rtsp://192.168.0.250:7447/882J4xdeDv7f79fS 2019-07-18T12:56:27.958Z [TRACE] <RTSP-PROXY> [REQUEST] --> [HEADERS] { "cseq": "1", "transport": "reuse_connection=0;preferred_delivery_protocol=udp;proxy_url_suffix=STREAM:ae4033f8-5c7c-47e9-89b3-6362c16d3467" } 2019-07-18T12:56:27.960Z [DEBUG] <RTSP-PROXY> [RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined) 2019-07-18T12:56:27.961Z [TRACE] <RTSP-PROXY> [RESPONSE] <-- [HEADERS] { "cseq": "1", "date": "Thu, Jul 18 2019 12:56:27 GMT" } -
OK, looks like gateway is setup and working, no obvious errors on startup … camera is tagged and working … camera stream request received successfully … but … the Alexa device is not making a TCP connection to the gateway to request the stream.
Please see my comments on this thread as its pretty much the same symptoms and potential issues. (firewall, isolated network, DNS rebinding, etc.)
https://forum.monoclecam.com/topic/211/monocle-works-but-not-monocle-gateway/2Also you should be able to just use the
@tunneltag … I think it should work fine with the Unifi cameras.Thanks, Robert
-
Thanks - I disabled the firewall just to check - no change, everything is on the same network.
I can also ping everything ok as in your DBS Rebinding article.
-
This is what I see when I use @tunnel
------------------------------------------------- INITIALIZE RTSP STREAM: Drive ------------------------------------------------- - NAME : Drive - LABEL : PRIMARY - URL : rtsp://192.168.0.250:7447/QbqYYlx76uNKCLFh - UUID : STREAM:ae4033f8-5c7c-47e9-89b3-6362c16d3467 - SESS : db9c7fc1-8c6b-43df-8259-477bc707ed48 - MODIF : Thu Jul 18 2019 14:31:35 GMT+0100 (GMT Daylight Time) - TAGS : @tunnel ------------------------------------------------- ------------------------------------------------- RTSP STREAM MODIFIED: Drive Any existing RTSP steams will be shut down and a new stream instance will be registered. ------------------------------------------------- 2019-07-18T13:31:42.332Z [DEBUG] <RTSP-PROXY> [REQUEST] --> [DEREGISTER] rtsp://192.168.0.250:7447/QbqYYlx76uNKCLFh 2019-07-18T13:31:42.333Z [TRACE] <RTSP-PROXY> [REQUEST] --> [HEADERS] { "cseq": "1", "transport": "reuse_connection=0;preferred_delivery_protocol=udp;proxy_url_suffix=STREAM:ae4033f8-5c7c-47e9-89b3-6362c16d3467" } 2019-07-18T13:31:42.333Z [DEBUG] <RTSP-PROXY> [RESPONSE] <-- [451 (Invalid parameter)] <cseq=1> (session=undefined) 2019-07-18T13:31:42.334Z [TRACE] <RTSP-PROXY> [RESPONSE] <-- [HEADERS] { "cseq": "1", "date": "Thu, Jul 18 2019 13:31:42 GMT"' -
Any this is the ping results.
Microsoft Windows [Version 10.0.17134.885] (c) 2018 Microsoft Corporation. All rights reserved. C:\Users\stenc>ping 440e1290-b99b-4e3d-ad59-139d53424742.mproxy.io Pinging 440e1290-b99b-4e3d-ad59-139d53424742.mproxy.io [192.168.98.1] with 32 bytes of data: Reply from 192.168.98.1: bytes=32 time<1ms TTL=64 Reply from 192.168.98.1: bytes=32 time<1ms TTL=64 Reply from 192.168.98.1: bytes=32 time<1ms TTL=64 Reply from 192.168.98.1: bytes=32 time<1ms TTL=64 Ping statistics for 192.168.98.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\Users\stenc> -
Oh I should add I’m running Unifi Protect NVR built in to a Unifi Cloud Key G2+
-
If you are comfortable with it, please try the openssl test mentioned in this thread:
https://forum.monoclecam.com/topic/206/unknowed-brand-ipcam/24This should test that the monocle gateway is listening on port 443 and returning you a valid certificate. Try running this test from a different computer than where the gateway is running so that you are testing across the local network.
It seems a number of users are having this same issue lately – I’m just hoping its not an Amazon change that has broken things.
Thanks, Robert
-
Just installing now - will test and report.
-
I get this (cert details left out)
C:\GNU\GetGnuWin32\bin>openssl s_client -showcerts -connect 440e1290-b99b-4e3d-ad59-139d53424742.mproxy.io:443 CONNECTED(0000025C) depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify error:num=20:unable to get local issuer certificate --- Certificate chain 0 s:/CN=*.mproxy.io i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 -----BEGIN CERTIFICATE----- MIIFTjCCBDagAwIBAgISA0txqJQBvCxIB1rUs4MhJfjtMA0GCSqGSIb3DQEBCwUA Z0o8QmrvM94AeGBnWXjArU2V -----END CERTIFICATE----- 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 -----BEGIN CERTIFICATE----- MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/ KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg== -----END CERTIFICATE----- 2 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 -----BEGIN CERTIFICATE----- MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/ KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg== -----END CERTIFICATE----- --- Server certificate subject=/CN=*.mproxy.io issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 4402 bytes and written 437 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: ABEA739174ABEE243A5675F200112AE5C83C87F8CE5B58CD83BE7AF530949A4E Session-ID-ctx: Master-Key: C7AA8298D3F1CB55C2AAC0C1E8D27DB7AAFFA28B0B88D50615A731DA925DD9330E497657FFAB2AA34431C6AF2545B7B7 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: Start Time: 1563465028 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- -
I have this working working with a unify video controller that is hosted ona Windows Server 2012R2. Able toview all 4 unify cameras on the Show-5. Re: the certificates, is it possible that the certs further up the chain are not in the expected certificate stores? Im not sure how this would work in a Linux environment (i.e. the Unifi Protect), but under Windows, I definitely had a similar error when one of the certs in the chain was not in the expected certificate store - (Trusted Root Certificates in the case of Windows)
-
@autodrivel Thanks for the info - I’m at the end of my knowledge base now so hoping the Devs ill have some ideas, show5 would be a fantastic tool to view Protect system with.
-
@Monocle Hi - do my test results give any clues ?
-
The test appeared to be successful. I plan on setting up a test feed to you to try that will use the same certificates with a known working camera feed and hopefully this can tell us if this really is a certificate related issue – which would be a little odd since it seems to work for most users no matter if its Windows, Linux or OSX.
I won’t be able to get this done for a couple of days, but its coming and I’ll let you know when its available to try.
Thanks, Robert
-
@g7pfv Hope it helps in some way.
A couple of things to be aware of with the Show when viewing camera feeds:- There is a time lag of between 2 and 5 seconds, on the feed - This has been mentioned elsewhere and may be deal breaker for some use-cases (e.g. door-bell monitor). Received wisdom on this forum is that it is mostly down to the Show, as a combination of the designed streaming behaviour (i.e. it buffers a few seconds before showing anything) and the relatively low computing power of the unit - viewing the same stream in VLC (for example) shows no lag - but typically the computer on which VLC is running is far more powerful than the Show.
- There is no facility to either show combined feeds or automatically rotate between feeds. Again I suspect that the former is simply beyond the compute power of the Show and the latter is not (yet?) in the Amazon Skill.
I have promised myself that I will sort out a combined stream as a project this summer - I will post results on the forum.
-
@autodrivel thanks - will look at this once I can actually view a camera !
-
@Monocle Thank you Robert - sterling service response for a free beta platform (far better than many paid services )
-
There is another thread here in the forums talking about an Amcrest NVR that can output a single stream with a matrix view of cameras. I have one on order to test it out for myself. Of course native support by Alexa for a multiple camera view would be better, but until then …
Thanks, Robert
-
OK, here is a test feed to try with your Echo Show 5.
This first test does not require any tags.
Here is the RTSP URL:
rtsp://demo.mproxy.io:443/resortHere it is configured in my camera settings in the Monocle Web Portal:
I have tested this on the new Echo Show 5 and it seem to be working fine from here.
Thanks, Robert
-
@Monocle said in Echo Show 5 with Unifi Protect:
rtsp://demo.mproxy.io:443/resort
Setup as your config - Alexa just responds with some blurm about knowing 500 demos, do I need to do anything in the gateway config etc ?
I can’t open this feed with VLC - its as if it does not exist. and can’t ping it.
Ignore me - works fine once I have discovered the new device in Alexa !!!
-
OK, so the test feed is working ok?
If so, then this validates the same SSL certificate chain that your gateway instance is using.The next test step is for me to setup a demo feed that we will route though your gateway and see what happens.
I’ll probably get this setup tomorrow.PS, VLC won’t view this stream because its encrypted. Ping may not work as IGMP may be blocked on this server.
Thanks, Robert
