You should not need to open any ports on your router.
Do you have Monocle Gateway installed on a computer inside your network? That is what is needed first. The Monocle Gateway service running on this computer must listen on port 443 and the Alexa devices must be able to access this computer (on port 443) inside your local network.
The Monocle Gateway service does communicate over the Internet to coordinate when an Alexa device requests a camera stream, but you don’t need to expose any inbound ports for this to work. All the streaming data is maintained locally inside your private network.
If you have the Monocle Gateway installed locally and your camera tagged (@tunnel) to use the gateway, you can copy the log data to this post and I can review it for any errors. Make sure to include the part of the log that includes the startup messages as well as the period of time that covers you asking Alexa for the camera feed.
You can restart the Monocle Gateway service either using the Windows Service Manager (GUI) tool or by using the following command in a command/shell window from the directory where you have the Monocle Gateway files:
As far as we know, Reolink Argus cameras don’t support RTSP and all other ReoLink cameras require using our Monocle Gateway software to achieve compatibility. Or course Amazon could fix the issue in Alexa or Reolink could fix it in an updated firmware, but at this point we are not aware of any such fixes. So it should be able to work now, but you would have to use the Monocle Gateway locally.
The initial delay seems to be entirely based on the RTSP player and likely H.264 decoding built into the Alexa hardware devices. Some camera, mostly based on the Dahua hardware like Amcrest seem to only have around a 5 second delay while others often have closer to 10 second delays. In my testing using a high resolution versus a low resolution seemed to have little impact on improving this latency.
I have also tested these types of RTSP streams using Raspberry Pi hardware and that too has similar stream startup latency – so I’m just guessing that a combination of the hardware and software codecs just perform better on full desktop/laptops versus the limited capacity of the low power ARM-based devices.
So could it be further improved? Yes, I’m sure there is room for improvement in the optimization on these devices for RTSP streams and the supported video and audio codecs. Will Amazon improve it? Well, thats impossible to know – but there really has not been any significant improvement (that we have witnessed) in streaming performance and compatibility since the first release of the Echo Show Gen 1.
PS. Does the Monocle Gateway add latency to the streaming. Well, possibly … but minimal. From what we have seen in testing it does not add any more than 1 second to the streaming latency. Of course it could be worse in sub-optimal network conditions.
Unfortunately not. I believe the latency is due to the platform and RTPS/Codec implementation on the small embedded device. I have tested similar camera stream on a Raspberry Pi (embedded ARM-based device) and experienced similar latency.
Thank you for the information, would say perfect timing as I’ve just purchased a PI4. Will be setting up gateway service to run on this alongside Pihole and vpn.
Again, many thanks and hopefully Alexa device will now play ball and I can concentrate on getting actual IE geek camera to work.
I do have firewall rules on my router that prevent the camera from communicating outside my LAN. Would that prevent the data stream connection to the Echo Show in any way?
No, the IP camera should not be exposed outside of your local network.
However, both the Alexa device and IP camera must be on the same internal network and be able to communicate with each other. If they are on separate VLANS or on a “Guest” WiFi network, this could cause an issue.