Web console

[whaleygeek]

I've left a placeholder in the device_classes branch, I hope to write a web console for this, that people can use in demos. It will be based on python bottle (a free single-file web server) and have all of the same functionality as the new setup_tool.py program. But I don't want to spend time on this yet until all the new device_classes branch functionality is tested on real hardware and merged back to master, as that will enable lots of other things to happen.

Here are my notes about what it will probably do

# REQUIREMENTS
# - zero install (probably python bottle)
# - simple monitor/control interface
#   - live status display of all registered devices with values and states
#   - turn on/off devices that have a switch
# - simple setup tool interface
#   - enter/exit learn mode for legacy
#   - change discovery status
#   - rename/delete devices in registry (e.g. from auto learn)

[whaleygeek]

Work on this has started in the branch web_console

It'll make a really great demo, and also make it easier to use devices remotely if the Pi is placed somewhere in the house where it gets best signal strength for all the Energenie devices (which will often make it less accessible to logging into)

[whaleygeek]

This work on the web_console is mostly self contained in the web_console folder now. It's going to be a relatively slow burn project, and I'm using parallel feature branches in order to get other changes done and tested and back onto master quickly. In particular, master has recently had two feature branch updates that support a whole range of new Energenie products that have recently hit the market.

I'm trying to get the web_console to a minimum viable product (basic framework with the gaps in the right place) quite quickly, so that I can gap-fill each bit of actual functionality gradually as I work on it.

The MVP won't be a pretty user interface, but it should be functional, and hopefully should make it possible to exercise via a web interface all the device interactions possible at the moment with the command line setup_tool.py program. It'll make a better demo anyway, and you could then always re-skin it yourself by adding a load of HTML and CSS into the .tpl template files.

[whaleygeek]

The web console (branch web_console) is almost at MVP level. Device control and monitoring is working.

Next step is to add in modes, and implement legacy learn, mihome discovery, and logging mode.

The web interface is intentionally quite anaemic, but functional.

Modes will ensure that, for example, when you start legacy learn, fetching any web page will take you back to the learning monitor screen, until you stop it and return to normal mode.

Logging might be a bit challenging, trying to avoid getting too sucked into ajax, but might have to have a tiny bit, so that incoming messages can be streamed as they arrive to a web page.

[whaleygeek]

Just tested the new web console with real devices - the device watch works really well, as does the on/off functionality. The UX is pretty thin, but it works good enough as a step towards a MVP web interface.

[whaleygeek]

The web console now supports 'sticky modes', which is a simple way to put the library into a mode for legacy learn, mihome discovery, and logging.

It's a bit of a poor-mans way to do it, as the polling will need to be initiated from the client end, in order to avoid getting into the concurrency design just yet. But it works good enough with the device listing, so I think it will work fine with the other modes too.

A 'sticky mode' means that if you initiate legacy learn mode, if you then try to navigate to another page, it will redirect you back to the legacy learn mode until you explicitly turn it off. All modes are mutually exclusive. The basic mode mechanism is implemented and working with some placeholder pages.

Next step is to implement the legacy learn mode pre-entry ui (house code and device index) and then the transmit poll loop. It will then be possible to 'learn' legacy OOK devices like the ENER002 (and MiHome devices with OOK support like the 3kW relay) from the web interface, making it possible to set up a system entirely over the web interface.

[whaleygeek]

Web console legacy learning and mihome discovery working in simulation. Took a 'poor-mans web' view of this, as all I want to develop here is a MVP web offering for others to improve on. The device list page has buttons to set the mihome discovery mode, and each fetch of the /list page does one receive poll (and the radio has a buffer anyway and the library leaves the radio in receive mode most of the time). This should be good enough.

Also took off the watch/unwatch buttons (no point for them), all devices that generate data are automatically watched, and their readings will be updated in the web interface.

Remaining work: logging mode - planning this to be naive MVP, of just returning messages in the /list poll and render each time round the refresh loop, and give the user a DOWNLOAD and a DELETE button to get the whole log. Also can give them a link to view the present contents of the energenie.csv log file at that point in time. This will be good enough.

[whaleygeek]

Very simple logger interface implemented in web_console and working. This still needs to be tested

remaining work before merge to master:

1. test legacy_learn, mihome_discovery, new watch semantics, and logger with real devices
2. write simple user instructions in README.md for running the web_console