As you are working on improving the remote access for emon, I recommend that you take a look at remote.it . Apart from their product, their technical support is super responsive. And the time difference to the US West Coast makes it all the more convenient.
They offer remote network services …
So maybe an RPi running emon image (with remote.it also installed) on a remote network could access and present the webpage of OpenEVSE (connected on that same remote network) on my local Windows laptop.
I’ve found it easy to try out remote.it. Hook up an RPi running emon on my local network and install the remote.it connection application. Then from my Windows laptop I can access that RPi not directly but via remote.it back to my local network. I recommend that you give it a go.
Re yr question as to what controls I consider are missing from Demand Shaper …
Assuming the EV is parked at home, it would be sub-optimal to charge to full at albeit cheap night rates because next day there would be no ‘space’ for any free charge from solar. So best only to charge up to a limit (set by the user) that covers next day’s driving needs (which is independent of whether or not the sun will shine strongly next daylight). I now have a script running on emon as a service that interrogates the Tesla EV mobile App data and inputs it to emoncms. It shows whether or not the Tesla EV is online and the latest (or last time online) battery % charge and battery range – see screenshot.
Hopefully it will be possible via MQTT (and a script?) to input commands to OpenEVSE/DemandShaper to charge at cheap night rates but only up to a user defined battery charge level or range. Being pragmatic, it need not be sophisticated as to timing – approx 1am to 5am is always much less costly.
The capability I’ve described above looks very much like that of the Open Vehicle Monitoring System – another gizmo and costing close to £200.