Monocle Gateway is a small service that runs on your local network to coordinate communication, encryption and security between your Alexa enabled devices and local IP cameras. The Monocle Gateway is a replacement for the previous proxy workaround service and is fully integrated with the Monocle platform.
Just a quick update, the following commands have been added to the install.sh script in the upcoming 0.0.4 release to address this issue.
# Set group ownership and permissions of config directory
chgrp -f -R monocle /etc/monocle
chmod -f -R g+rw /etc/monocle
When the install script runs, it does create a monocle system user account (a user account with no logon capabilities) as well as a monocle group. So the commands above simply set the group ownership to the monocle group and file permissions to allow read and write access to the monocle group.
setcap is a utility available in newer Debian distros (Ubuntu, Raspbian, etc) and we use it to allow the monocle-gateway executable to run and serve on port 443 which is a protected port in most Linux distros. You may need to find another way to allow the monocle-gateway to access and host on port 443. I’m not familiar with the QNAP NAS and which Linux distro it uses. You can try commenting out that line in the install script and see what happens. You could run the monocle-gateway as a root user which should allow access to port 443 for testing, but you would be better off to find a proper solution to enable port 443 and not run the process with root access for long term use.
What makes you think it is memory getting filled up? Does it start and then crash?
Did you test the gateway and check the log?
Mine had a port conflict i saw and fixed before it would work.
Also, when using the gateway, i believe you use the cameras ip address and not the pc of the gateway. Can you confirm you have unique ips?
Ha, you are right. It is in there. Something about it being the indented pull out text made me ignore it (that’s my bad), that and when I had previously installed it months ago on my main desktop for testing I didn’t run into that issue as the dependency was already installed.
The Emby server is doing some transcoding on the feeds. So hopefully your Emby server has enough muscle to get the job done. I have not tested on any small devices such as the RaspberryPi or other ARM based systems. I installed Emby server on an Intel i7 NUC for testing. So it does have hardware acceleration support enabled.
This is not for ARM based systems, but the Dockerfile is available in the GitHub repository and could easily be modified to create an ARM based image. We do already have ARM 32-bit and ARM 64-bit builds of the software published.
Hey there so I have still been struggling with this. I got delayed b/c of a project at my house. I have tried @hangup @proxy @proxy-tcp in all matter of combinations.
This is what I found, @hangup @noaudio @tunnel is the optimal configuration. However, after a few switches between cameras, none work. If I go onto the monocle dashboard and change a config, suddenly the cameras start working again for a period of time. That is really odd behavior.