Not idiotic. Idiotic is spending hours debugging DHCP when the network cable is unplugged.
This is very promising. I have taken the C++ part for a spin, and the demo-code works, but as soon as I add app.make_gpio_binary_sensor(“Cabinet Motion”, 2, binary_sensor::device_class::MOTION); I get a "
src\main.cpp:27:69: error: ‘esphomelib::binary_sensor::device_class’ has not been declared" - can you point me to docs or a solution?
Furthermore, I am not running MQTT server with HA, and need to adjust the initial topic prefix, in mqtt_client_component.h but that seemed silly.
Thanks again
binary_sensor::device_class::MOTION does not exist anymore, just use App.make_gpio_binary_sensor(“Cabinet Motion”, 2, "motion");. But you should really use esphomeyaml for the simple stuff (like gpio binary sensors), read here: https://esphomelib.com/esphomeyaml/changelog/v1.10.0.html
Well done on the addon upgrade @OttoWinter. 
I have a question regarding reverse proxy and esphome; is it possible to configure so that I can access esphome through an iframe? I’ve tried so many combinations of the configuration but not having much luck!
You need to have websocket proxy. This is done in Apache2 through something like:
ProxyPreserveHost On
ProxyRequests off
ProxyPass / http://localhost:6052/
ProxyPassReverse / http://localhost:6052/
RemoteIPHeader X-Forwarded-For
RewriteEngine on
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.*) wss://localhost:6052/$1 [P,L] RewriteCond %{HTTP:Upgrade} !=websocket [NC]
Sadly it doesn’t seem to work still since websockets happens at different entry points.
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)