BETA and MINOR auto-update are now 02_05_02

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:

  • Miscellaneous fixup/improvements to new Graph+
  • Fix boundary condition in base64encode
  • Add group=all to query

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 ec:fa:bc:25:0e:dc 0h 55m 13s

This is what it looks like when I ping the device:
% ping
ping: cannot resolve Unknown host

% ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=2.755 ms
64 bytes from icmp_seq=1 ttl=255 time=19.357 ms
64 bytes from icmp_seq=2 ttl=255 time=73.340 ms
64 bytes from icmp_seq=3 ttl=255 time=47.805 ms
— 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
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=66.057 ms
64 bytes from icmp_seq=1 ttl=255 time=11.106 ms
64 bytes from icmp_seq=2 ttl=255 time=24.358 ms
— 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;
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;



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:


(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!

1 Like

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;
1 Like