Brian, I believe I did that. I used a dns entry in the cloud that points to my local cameras. For some reason, I can get to the image URL off network or on network using the same address via a web browser.
The problem is that when that EXACT same address is in the HE Tile URL, it works on network but gives me a broken connection off network if and only if the URL is in an image tile in a dashboard. The rest of the dashboard works and that URL works as long as I just paste it into a web browser when away. As a workaround, is there a way to make tapping that broken tile launch a web browser to display the URL since that is working? That is what I do not understand.
Yeah I'm seeing the same thing in my setup, My DNS works fine outside the network through another app, if I'm local in the network I have no issues, If I'm on my mobile device not on the local network the images do not show for my cameras.
Could it be related to hairpin NAT? My dns name is same as home and away. When I access it from home I put a local hosts entry on my router 192.168.1.x myhost.mydomain.com
Where that internal address runs the web server in accessing when on the internet. I run a Edge Router X.
For me its not a really big deal since I use my other app to access all the cameras in my house when mobile. But there is something strange going on with this setup. Shouldn't have to jump through all the hoops to get the images to work remotely
I do have another app that displays my cameras as well. I just thought having an image in the dashboard was slick. Per what @brianwilson said, I can see a reverse NAT issue rearing its head depending upon what HE is doing with cloud dashboard access.
I'm using a UDM Pro as my router on the edge of my network. Is there any chance that HE could deal with an IPv6 global address in that tile? That would subvert our issue if it is a NAT/IPv4 thing.
I've not seen any evidence that HE does IPv6. I tend to offer all my services IPv4 and IPv6. Check out my bulletin board server as an example. https://community.scottibyte.com/.
Oh and for my other Ipv4 services I tend to do NginX Reverse Proxy.
Cloud dashboards aren't doing anything different from local dashboards. My dashboards look the same local or cloud, the images use the same URL's.
If you use camect, you can use this to proxy through to your box to get a snapshot, or here is an example that works for Hikvision cameras - adjust your snapshot URL's/methods to get to your internal content to meet your needs.
So, my camera images are not SSL and I am not accessing my NVR (QVR Pro) to get the images. Instead, I am going directly to the camera port 80 to pick up a JPEG/MJPEG images. I have a firewall rule to access the camera at the right port. It works with my FQDN from inside my network but not from the WAN side.
therein is the problem, mixed content is not allowed by browsers. You could solve it either with what @brianwilson mentions above or using something like the free service from Cloudflare.
That's a big help. I had not realized that I was dealing with the mixed content issue. I wonder where I should implement SSL. Right now I connect to each camera individually. Any ideas?
Either through a proxy like the one from brianwilson, or using a free service like Cloudflare that can forward SSL traffic to a non-http server. Those would be the two best options. If you also then lock down so only cloudlfare IPs are allowed to be forwarded you make the port-forward hole in your security at least a little bit less dangerous.
I have a final solution. I am going to document this for everyone, so please bear with my verbosity.
I had used an image template tile in a dashboard to display an image from one of my cameras since RTSP is not supported as an embedded format in a dashboard. I decided to display JPG images from several of my security cameras in different dashboards.
I selected the option in the image tile to enable a 5 second refresh on the image. This worked fabulously from inside my network, but failed miserably from the HE Cloud dashboard when outside my network.
As @markus so adeptly pointed out and @dpdurst also noted, you cannot mix https and http resources in the same page on most modern browsers. I knew this, but overlooked this feeling as though I had some firewall issue.
Realize that most network based cameras today usually offer a video stream via RTSP and a snapshot frame capability via http. You won't find a camera typically with an SSL certificate installed on it to allow https.
So, I created what I believe is the leanest approach to a solution.
I have a registered domain name. Mine is on google, but you can go to Cloudflare or another provider and register a domain name. My domain name at google is a mere $12 a year.
You need the registered domain in order to register SSL certificates. I use "Lets Encrypt" certificates because they are FREE self signed certificates, the only downside being they expire every three months.
Create a DNS name at your DNS provider for each of your cameras. If you have a typical ISP with one IPv4 address, then all your camera names will map to that one WAN address of your router. What??? Don't worry.
Go over to https://nginxproxymanager.com/ and run an instance of NginX Proxy Manager on a Raspberry Pi or your NAS (something that is up and running 24x7 on your network). NginX Proxy manager is a Docker image that is NginX Reverse proxy with a beautiful management front end and a mechanism that lets you register Lets Encrpypt SSL certificates on it and also handles auto-renewal of said certificates.
Create a VLAN. Allow this VLAN access to the WAN and allow Established and related sessions from your MAIN LAN to this VLAN. Deny all traffic originating on this VLAN back to your MAIN LAN. What??? This is an IoT network. I put my cameras, smart speakers and other untrusted things on it for security purposes. My VLAN name is ATF-Corral. Inject Humor
So, now you use NginX Proxy Manager to create a proxy for each of your cameras. Basically, the DNS name points to the camera local LAN address on port 80 on the IoT VLAN. Be sure to request an SSL certificate for each of the proxies. Also turn on the force SSL Switch.
So, this doesn't really encrypt the image coming back from the camera, but it allows the embedded URL for the image to be https which will get around the problem that @markus described.
You can also use NginX Proxy Manager's built in Web GUI to create a redirection host which can bury the camera string and authentication in NginX Proxy Manager instead of exposing it in a tile.
If all this scares you, tag up with me and I will be glad to answer your questions. The end result that I have are dashboard images with camera shots that refresh every 5 seconds both inside and outside my network.
Great information! in my case I use foscam cameras inside the house, so for me I just changed the HTTPS port for the two I'm using and can either connect via http or https either way. The other solution I use is tinycam pro to monitor all the internal cams I have.
So several ways in my case to make this work I decided to keep it simple and just keep the front door and garage camera on the local tablet dashboard and the remote dashboard for tablet or cell phone I have all my hubitat devices setup. I'll continue to use my tinycam pro app for the internal camera's including the front door and garage cam to view if needed when away from the house.
That brings up another question. If I decide to load Hubitat Mobile on some wifi tablets around the house, does that cause an issue with presence?
I recall that on installation, the mobile app will ask which mobile device to connect to. In the case of a tablet, I don't want it using mobile presence. I want to reserve that for just our phones.
Ok, so displaying camera images in tiles worked for my Reolink and GW Security cameras just fine. I have an Amcrest camera where I have an issue. The URL for the Amcrest camera is:
This works from a browser. This does not work from a dashboard tile. If I authenticate the browser instance in another tab and change the above to eliminate the credentials, it then works since that browser instance is authenticated.
I want to use this on the HE Mobile app. Any ideas?
What I did is just access hubitat from the tablet locally, go to dashboards open up the one I wanted and then saved to desktop, That way I don't have to load up the entire app on the device. I just want to run the dashboard with nothing else. I'm on Android as well.
I do the same as @dpdurst mentions. I don't use the app for dashboards. A 'direct to dashboard' browser link is faster, and with no header gives a much better look. This part is taken from the dashboard guide I wrote up here.
Dashboard access - There are several ways to access the HE Dashboards outside of the HE app. Using a browser to go directly to a dashboard can be faster then navigating the app. The documentation above shows how to access those links via the HE menus, below is another way .
Note - this will create a local link if you are local, or a cloud link if you are not on your Wi-Fi. Please see below for information on which one to use.
Open the app, and clicking full screen button
Then click your dash to open it in your default browser. For Chrome/Android click the 3 dots and then "Add to Home Screen". For iOS Click the Safari icon to open the page in Safari, then click the share button and finally "Add to Home Screen". Doing this will remove the URL header, and the Hubitat footer, to give you a much cleaner looking dash. It will also go directly to that given dashboard improving the user experience.
Local/Cloud - In the dashboard app (shown in documentation) you can link to both a local and cloud dash directly. It is not recommended to use Cloud dashboard link while on the home LAN. This will create extra traffic on the hub and can potentially create slow downs, and lock ups. When you are on your local WiFi be sure to use only local links on all devices. This is mostly important when using links outside the HE app as describe above.
There is no limit to how many links you can have on your device (you can even create a folder for them). If your device is going to be use both Local and Cloud, it is recommended to use separate links if going "direct to dash", and not through the HE app. You can still use both interchangeably.
