Browser compatibility

The good news is that the pages served by the IoToWatt work fine in

  • Chrome on the Mac.

However, the following browsers all have difficulties for me – certain user interface elements are silently missing, like the “input/output status” content in the status tab.

  • Safari on Mac
  • Firefox on Mac
  • Safari on iOS/iPad
  • Firefox on iOS/iPad

Where should issues like this be reported to? There are many other little things about the web app that could be improved, and I’d happy to log some bugs.

Browser compatibility is an ongoing problem, but sometimes it’s not simply the browser. I confess that I don’t even try to test all the combinations, but Safari/iPad is one that I use daily, so this is probably complicated by something specific to your configuration.

Problems with the status display are typically more related to the json status response not parsing. That can be caused by some bad arithmetic “NaN” or sometimes in older releases by embedded spaces or other special characters in the name of an input or output.

So to get to the bottom of it, could you please:

Post a failed status display.
Post your input and output configuration displays
Run the following command in your browser and post the Json response:
Tell me what release you are on or what your auto-update class is in the device setup.

Regarding reporting problems. I’ll take a shot at them here because it’s a lot easier to post diagnostic materials and screenshots with this forum software.


Based on your quick response (thank you!), I have taken a closer look. It turns out that some of the files have a hard time loading, specifically:

  • getall
  • list.json
  • tables.txt
  • config.txt

Chrome is marginally more successful than Firefox is, but often one or two of them time out. Actually the browser just continues waiting, so I’m not sure where the hang is (open socket, reuse previous connection, nothing in response to HTTP header …) … The funny thing is, if I access any of them via curl, they show up just fine. If could be insufficient WiFi, but it only happens for those files (all others load just fine) and curl works. I also notice they are loaded “torwards the end” of loading several files in rapid succession per network tools in Chrome and Firefox.

What’s the concurrency model for the embedded code? (Pointer to a document or even just code would be fine) If this was my embedded code – and I known I’m bad at writing concurrent embedded code – I would guess I somehow get my requests mixed up and don’t recall I still need to respond to something. I do run the thing with all 14 channels blasting…



P.S on your question:

curl -v 'iotawatt.local/status?stats=yes&inputs=yes&outputs=yes'
* Hostname was NOT found in DNS cache
*   Trying
* Connected to iotawatt.local ( port 80 (#0)
> GET /status?stats=yes&inputs=yes&outputs=yes HTTP/1.1
> User-Agent: curl/7.37.1
> Host: iotawatt.local
> Accept: */*
(takes about 2 seconds here)
< HTTP/1.1 200 OK
< Content-Type: text/json
< Content-Length: 861
< Connection: close
* Closing connection 0
{"stats":{"cyclerate":642.5792,"chanrate":39.91013,"runseconds":8276,"stack":16992,"version":"02_02_30","frequency":60.01661},"inputs":[{"channel":0,"Vrms":125.2309,"Hz":60.01785},{"channel":1,"Watts":"934","Irms":"8.346","Pf":0.893173},{"channel":2,"Watts":"113","Irms":"1.070","Pf":0.844585},{"channel":3,"Watts":" 3","Irms":"0.075"},{"channel":4,"Watts":" 0","Irms":"0.000"},{"channel":5,"Watts":" 0","Irms":"0.000"},{"channel":6,"Watts":" 0","Irms":"0.000"},{"channel":7,"Watts":"315","Irms":"3.387","Pf":0.743809},{"channel":8,"Watts":" 0","Irms":"0.000"},{"channel":9,"Watts":"10","Irms":"0.121"},{"channel":10,"Watts":" 3","Irms":"0.036"},{"channel":11,"Watts":" 0","Irms":"0.040"},{"channel":12,"Watts":"261","Irms":"2.284","Pf":0.911627},{"channel":13,"Watts":" 0","Irms":"0.027"},{"channel":14,"Watts":"17","Irms":"0.221","Pf":0.619787}],"outputs":[]}

I don’t see a scenario where those files are loaded together. The first two are related to the graph function, and the second to the configuration. Loading the config app should access
index.htm (/)

Then when that all gets put together, clicking status will start doing status queries. It’s possible that you are having problems with multiple concurrent requests, but without knowing what version you are running, I can’t speculate further.

The TCP on the ESP8266 isn’t very robust and not well documented. There is a limit to how many connections it can maintain, but there are no clear metrics that I can find to define that. The firmware attempts to limit the active connections, but there’s no direct control. I have found that a good WiFi connection is essential to minimizing those problems. With a good connection, there should be few problems. Some have found that changing the WiFi channel in the router to avoid conflict with other neighboring networks has helped.

If you want to look at the code, it’s at

I wasn’t quite clear; only two of the four files are in the same page.

Perhaps a better way of putting it: here’s a screenshot from Chrome with timing. This one worked:

Some of those files seem to download at the same time, but later requests then peter out with very long waiting periods. The content actually comes back comparatively quickly.

I don’t know exactly what this all means. I will play around with it some more, and if something interesting pops up, I’ll post it here.