This contains very minor changes to 02_05_00 and 02_05_01 which have been in ALPHA and BETA since October 2. The changes from 02_05_01 are:
Expect auto-update MAJOR to follow soon.
@overeasy just letting you know the graph+ is getting the the Request error 05ac like the original graph when using https. I use Grafana and don’t need this option but letting you know.
Just installed IotaWatt today. A couple of hours later it auto updated (no surprise there). However, it has now registered with my DNS server as ESP_250EDC and not as IotaWatt (as it did when it first connected to wifi.
Restarting the IotaWatt device hasn’t changed that.
Hi @blitz1986,
I’m not getting that with my https through Nginx. Would you mind posting your nginx config and the error you are getting?
Need a little more information to understand the issue. What do you mean by “registered with my DNS server”? What happens when you try to browse to HTTP://iotawatt.local, and if you try to use the IP address?
When I first installed the device, I was able to access it by entering the “iotawatt.”. Everything worked as expected. After the update, I can no longer access it by specifying “iotawatt.”.
The logs for the device contains this:
12/20/19 17:59:26z device name: IotaWatt
12/20/19 17:59:26z MDNS responder started for hostname IotaWatt
12/20/19 17:59:26z LLMNR responder started for hostname IotaWatt
However, the “DHCP Leases” table for my router (OpenWrt) now shows this:
Hostname, IP address, MAC address, remaining leasetime
ESP_250EDC 172.16.1.204 ec:fa:bc:25:0e:dc 0h 55m 13s
This is what it looks like when I ping the device:
% ping iotawatt..com
ping: cannot resolve iotawatt..com: Unknown host
% ping esp_250edc.graabek.com
PING esp_250edc..com (172.16.1.204): 56 data bytes
64 bytes from 172.16.1.204: icmp_seq=0 ttl=255 time=2.755 ms
64 bytes from 172.16.1.204: icmp_seq=1 ttl=255 time=19.357 ms
64 bytes from 172.16.1.204: icmp_seq=2 ttl=255 time=73.340 ms
64 bytes from 172.16.1.204: icmp_seq=3 ttl=255 time=47.805 ms
^C
— esp_250edc.graabek.com ping statistics —
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.755/35.814/73.340/26.999 ms
% ping 172.16.1.204
PING 172.16.1.204 (172.16.1.204): 56 data bytes
64 bytes from 172.16.1.204: icmp_seq=0 ttl=255 time=66.057 ms
64 bytes from 172.16.1.204: icmp_seq=1 ttl=255 time=11.106 ms
64 bytes from 172.16.1.204: icmp_seq=2 ttl=255 time=24.358 ms
^C
— 172.16.1.204 ping statistics —
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.106/33.840/66.057/23.414 ms
Entering esp_250edc. or the IP address in the browser address field now gets me to the device and entering iotawatt. no longer works. I can also ping it as esp_250edc. or the IP address.
I have now tried deliberately changing the device name. This was recorded in the device logs.
12/20/19 22:41:44z device name: IotaWatx
12/20/19 22:41:44z MDNS responder started for hostname IotaWatx
12/20/19 22:41:44z LLMNR responder started for hostname IotaWatx
…
12/20/19 22:52:22z device name: IotaWatt
12/20/19 22:52:22z MDNS responder started for hostname IotaWatt
12/20/19 22:52:22z LLMNR responder started for hostname IotaWatt
Once the lease period expired and the device got a “new” IP address. the device was again listed in the “Active DHCP leases” table with its “real” name.
In other words, everything is now as it was before the update, but I thought I’d informalities you in case anyone else has a device that “loses” its hostname after the upgrade.
I believe the hostname was probably ESP_250EDC before the upgrade. That is typical for a new unit because the hostname is set by WiFimanager during the initial WiFi connection activity while the IoTaWatt is still in AP mode.
Nothing has changed in the IoTaWatt with respect to hostnames and WiFi connection for a very long time. There have been upgrades to the underlying core and lwip, so I’ll keep an eye out for other anomolies, but I do think this is a phenomena caused by initial WiFi connection.
Does both original and graph+
server {
listen 80;
server_name XXXXXXXXXXXXXXXXXXXXX;
index index.html index.htm;
error_log /var/log/nginx/XXXXXXXXXXXXXXX.log;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://192.168.0.21:80;
}
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/XXXXXXXXXXXXXXXX/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/XXXXXXXXXXXXXXXXXXX/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
Can you try changing the proxy_pass to:
proxy_pass http://192.168.0.21/;
(the port should default to 80, I’m mostly interested in the trailing slash)
Actually, that probably wont do it, I think the problem is that the data packets are chunked and you have not specifies HTTP 1.1. So can you add:
proxy_http_version 1.1;
after the proxy_pass statement?
Tried both suggestions individually. proxy_http_version 1.1; did the trick. All is working as it should now. Thanks!
I went ahead and added basic authorization using Nginx if you haven’t already. Works nicely, I removed the password in Iotawatt configuration.
sudo apt install apache2-utils (or sudo yum install httpd-tools for Centos)
sudo htpasswd -c /etc/apache2/.htpasswd iotawatt_user
Will ask for password, just enter your password twice
Add the following to your iotawatt conf file under
location / {
auth_basic "Restricted Area";
auth_basic_user_file /etc/apache2/.htpasswd;