Echo Show 5 with Unifi Protect [SOLVED]
-
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
-
@Monocle Yes test feed works well - Much appreciated, was just me being an idiot - look forward to continued testing and perhaps a resolution (fingers crossed) - thanks for the time given to this so far.
-
OK, the next test will involve running the same demo feed thru your instance of Monocle Gateway. However, I had to fix a couple of minor issues to get it working.
So, first. You will need to replace your “
monocle-gateway.exe” file with a newly compiled one from this link:
https://www.dropbox.com/sh/m91e8z2wa1s89d7/AACRqcwLvdTFA-5gsBo9ItrKa?dl=0&lst=(The new version should be “0.0.4-1” instead of “0.0.4”)
Now, we will need to update the demo RTSP URL to use port 554 instead of 443. Port 443 is already encrypted whereas port 554 is the raw unencrypted feed.
rtsp://demo.mproxy.io:554/resortYou will also need to add the
@tunneltag to the camera config as shown below:
Thanks, Robert
-
@Monocle I get the camera is not responding, text from gateway below:-
C:\montest>monocle-gateway ****************************************************************** * __ __ ___ _ _ ___ ___ _ ___ * * | \/ |/ _ \| \| |/ _ \ / __| | | __| * * | |\/| | (_) | .` | (_) | (__| |__| _| * * |_| |_|\___/|_|\_|\___/ \___|____|___| * * * ****************************************************************** ------------------------------------------------- MONOCLE RUNTIME ENVIRONMENT ------------------------------------------------- VERSION = 0.0.4-1 OS/ARCH = win32\x64 PROCESS = monocle-gateway (PID=30276) TIMESTAMP = 2019-07-25T17:54:45.543Z ------------------------------------------------- MONOCLE GATEWAY SERVICE (Version: 0.0.4-1) ------------------------------------------------- [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=14896) [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: Demo ------------------------------------------------- - NAME : Demo - LABEL : PRIMARY - URL : rtsp://demo.mproxy.io:554/resort - UUID : STREAM:46292276-3aa7-41df-989b-56f943da7031 - SESS : 5377b0b2-52e2-44a5-b93c-a790caeaf6a4 - MODIF : Thu Jul 25 2019 18:52:26 GMT+0100 (British Summer Time) - TAGS : @tunnel ------------------------------------------------- -
OK, so we have come full circle back to the original issue. The Alexa device is not attempting to connect to your gateway. This could be for any number of reasons but the most common are FIREWALL blocking access to port 443. DNS REBINDING preventing DNS resolution of host address
440e1290-b99b-4e3d-ad59-139d53424742.mproxy.ioinside your local network, the Alexa devices and Monocle Gateway on separate networks preventing access to each other (such as a guest network or pretected VLAN) or some other network security appliance/device blocking access. I know you have tested these before, but something is blocking Alexa’s access to the Monocle Gateway.When you do the ping test/openssl test are you doing that from the same computer where you are running Monocle Gateway or from another computer? Is same, then try from another computer on the network.
Just to verify, is IP address
192.168.98.1the correct IP for this computer running Monocle Gateway and the IP address that the Alexa device should be able to reach?I’ll work on setting up a Monocle Gateway instance for us to test with in the cloud.
Thanks, Robert
