Should be as simple as:
panel_iframe:
esphome:
title: ESPHome
icon: mdi:code-brackets
url: https://addres.to.your.hass.io:6052
I’m using nginx and have a proxy pass to my esp instance (e.g. xxxx.duckdns.org/esphome) and using this address in the iframe doesn’t work as other add ons do. Using the local address works but isn’t the goal.
Which lib do you use for sonar support (I’m guessing NewPing)? Would all of the following sonars be supported: HCSR04+ (the 3.3V variant), US-100, JSN-SR04T V2? Since according to Andreas Speiss’s youtube video all of them are supported by the NewPing lib.
For nginx you need to enable websocket support. See Using NGINX as a WebSocket Proxy
No library 
The arduino libraries are usually quite low quality (plus they don’t use esphomelib’s advanced abstractions, like the GPIOPin class). Besides, sonarr is literally just measuring time and multiplying by a number. So yes, your sensors should all be supported since they all work the same way.
1 Like
Thank you! Very nice!
I’ve always used websocket support with iframe links as most addons require it.
Here is my iframe config:
panel_iframe:
esphome:
title: ESPHome
icon: mdi:memory
url: https://xxxxx.duckdns.org/esphome
NGINX config:
location /esphome/ {
proxy_pass https://192.168.0.xxx:6052;
proxy_redirect http:// https://;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
With this configuration, if i click the ESPHome iframe link, i get the following:
This is both from local browser and external browser.
it is your nginx setup that makes the problem.
you can better redirect:
https://xxxxx.duckdns.org:6052 to https://192.168.0.xxx:6052
I forgot to mention, I do have a DNS record set within Pi Hole to point xxxxx.duckdns.org to my LAN address, so LAN clients don’t route through my public IP, so this would make no difference internally?
when you did set that up right you should not notice any difference between using the ip as url, or use the url when you are local.
at least that is the theory.
but then you need to make sure that all devices in your home always look at your local DNS server before they look elsewhere.
that also means that every browser call from your lan must go through your PI.
That’s correct. I’ve confirmed that local clients resolve my duckdns to the local IP address fine. I have also setup DHCP clients to point to the Pi Hole address as the primary DNS server.
but for external connections everything goes through nginx.
so you need to set that up right.
and my experience is that you can better forward a port.
https://duckdns:6052 to http://localip:6052 instead of
https://duckdns/esphome to //localip:6052
i had the same problems when i tried to do that with appdaemon.
if there is anything on the server that isnt 100% relative your solution will break.
Yeah I understand, but I’m trying not to forward more ports. 
I’ll persist in trying different configurations. I’ve had to do the same with Pi Hole, Configurator, Node-RED, Terminal, etc. They all required different configurations to work with NGINX and an iframe, but I just haven’t figured out ESP yet.
yeah, nginx can be a big pain in the but 
as long as you know it is your nginx setup that is troubling you and not something else, you know at least where to look
I think I have a better understand of what’s happening now. I’ve used this site to check the flow:
I’m receiving the following result with the current setup:
| Status code | Scheme | Host | Path | |
|---|---|---|---|---|
| 301 | HTTPS | xxxx.duckdns.org | /esphome | |
| 302 | HTTPS | xxxx.duckdns.org | /esphome/ | |
| 404 | HTTPS | xxxx.duckdns.org | /login |
So it seems to be to do with the redirect URI to the login page. It’s not appending the /esphome/ to the URI path…
and that happens a lot. (and for sure in login parts)
otto probably never thought of using the server this way.
off course you can ask if otto wants to make changes, but if he doesnt want to open his network on the same way, he cant garatee it will work. so he makes a change, you test, runin to something else, he changes again, you test again etc.
that takes up a lot of involvement from both sides.
i think if you really want to open esp to the world, you better use a port forward. that would save all a lot of time.
allthough the wisest move would be not to open anything that configure your home to the outside (but thats another story that we shouldnt discuss here in this topic)
Yeah it’s more of a luxury than anything. I’ll probably spend a little more time but if I don’t figure it out I’ll happily resort to local access only. It’s more just trying to scratch that itch now hehe… thanks for the follow up. 
1 Like
Yeah so putting it into a subdirectory won’t work. I have no idea how you even got that to work with the other services, but usually in the HTTP services world it’s quite hard to put services in subdirectories.
The reason your solution isn’t working is because ESPHome redirects to /login on the first visit, which of course then doesn’t get redirected by nginx again to the proper location. The same will be for all static resources as they use absolute URLs as well.
The usual solution to this (that I’ve also used many times before) is using subdomains. For example esphome.xx.duckdns.org and pihole.xx.duckdns.org etc. It’s not hard to do with nginx and will make way less trouble with most services.
Also, I don’t know of a reason why you wouldn’t want to open up another port on your router. Having the nginx proxy in front of ESPHome doesn’t magically make things safer (because the ESPHome addon uses nginx internally too).
it makes things saver if you use just 1 proxy server and all other stuff behind it.
and normally also easier, because you can connect locally behind that proxy without ssl.
thanks for pointing out the subdomain option. didnt think of that.
Hi,
Will the additional ports open get the same security level as the default 443?
that depends on your settings in nginx. if you configure that right they will.
although i must say that port 443 on its own has no security at all when you dont create the security.