WebUI(s) need some love

[ngardiner]

WebUI(s) need some love

[MikeBishop]

Piling onto the WebUI requests, I'd love to see this eventually switch from fully refreshing to exposing a set of REST APIs and using Javascript to just update the values on the page periodically.

[ngardiner]

Commit 10eacfa introduces AJAJ client-side API calls to avoid the refreshing of the page which itself was starting to present some issues in terms of trying to avoid a refresh during user input. This new approach should be much more friendly going forward and introduces a RESTful API as well (which is yet to be documented and far from complete).

Currently only front-page elements are implemented this way, and with the exception of the Tesla login prompt which is next on the to-do list.

[AndySchroder]

Trying to understand, are you hoping to eliminate the lighttpd/php based web interface, or is there a reason to have two? I'd personally rather not have the lighthttpd/php version, but trying to understand the direction of your work.

[ngardiner]

Yes, this is definitely the aim. The lighttpd/php web server has too many external dependencies and a complex method of shuttling information back and forward between the TWCManager script and the external PHP script.

The challenge is that front-end presentation is far from my forte and the inbuilt web server is a bit unweildy without the appropriate framework and structure in place, which would take me longer than many others to sort out. That said, I'm still committed to doing it, just at a slower pace than the core functionality unless someone else has some time to devote to it.

[AndySchroder]

Looking at the web interface, I have MaxAmps of 80. However, in config.json, I have "wiringMaxAmpsPerTWC": 26 . Why is MaxAmps 80 on the web interface? Is this just the TWC limit and not the building wiring limit?

[ngardiner]

MaxAmps is a value communicated by the Slave TWC to us advising us of the maximum that it can support. From our side, wiringMaxAmpsPerTWC is a constant for all slaves, and whilst we could, should and will! display it, it would make sense to display it once only. MaxAmps for a Slave TWC can differ per TWC based on the hardware used.

[AndySchroder]

I'd vote to still show a column of wiringMaxAmpsPerTWC for each TWC, even if they are all the same, then for the total, show wiringMaxAmpsAllTWCs. The sum of wiringMaxAmpsPerTWC may be greater than wiringMaxAmpsAllTWCs, but then people at least have a visual of how their hardware is being bottlenecked. Also, you may change it in the future so that each TWC could have a different wiring amps, so why not build the GUI for that?

Also, I'd vote to rename MaxAmps to MaxTWCAmps.

[ngardiner]

True, @AndySchroder. It is entirely possible that it may differ per TWC in the future.

[ngardiner]

Totally agree @MikeBishop. This would be ideal.

[hopfi2k]

I've been trying to "convert" the frontend into a flask app, but that would require some serious code rewriting. As a step towards that goal, I've modified code to support static (local) content (bootstrap, css, javascript - instead of CDN downloading) and hacked something together that looks decent (but still shows some original content at the bottom, that I haven't fully converted yet). I'd vote for providing a proper REST API and furthermore maybe a WebSocket server to push realtime data (power generated, grid power, etc.), as this is doesn't require AJAX loading all over the place...but that's just my 2cents. If you are interested, I could spent some time helping with the front end...

[MikeBishop]

I like the concept, but note that we don't always know the association between the TWC and the car it's charging. Sometimes the TWC can report the VIN (mine can), and assuming the VIN is also on the connected account, you can get that info. However, TWCManager doesn't fetch the battery level very frequently unless you ask it to, so this might be stale.

[ngardiner]

This requirement has really picked up now with @hopfi2k's assistance and with the addition of theme support for 1.2.1. I might close off this particular (vague) issue and we can continue to collaborate in the more recent issue with @hopfi2k's responsive UI contributions.