Hello developer community,
this is one of a few Ideas I like the AC to consider.
Some bindings, like the ZWave and Zigbee one and also MQTT, but also some services like the Hue emulation are in need of a custom status report page.
For ZWave/Zigbee that is for example a Mesh representation (see also Habmin), for MQTT a realtime log of received and matched topics. For the hue emulation a self-test report page with a detailed list of exposed items and current known clients to debug if Amazon Echos have indeed tried to register for example.
We can now model dozen of APIs to somehow allow all possible data streams and on the UI side implement dozen of widgets to render those.
Proposal: Own html endpoints
My proposal is instead to allow bindings and services to register their own endpoint in a standardized way, for example “http://my-openhab:80/extension/hueemulation” or “http://my-openhab:80/extension/mqtt.generic”.
Services/Bindings are then allowed to ship own html content on those endpoints. If we correctly configure Jetty this will not be a security risk, even if the binding is somehow malicious:
The use of the http headers
X-XSS-Protection will prevent any external calls / embedding of external content or spying on a master document that embeds such html pages.
<button>s with “btn” classes etc.)
How to present those endpoints
A future UI would iframe-embed or XHR-embed those pages. I have made a proposal for trying out what I suggest in my Paper UI NG design study:
What about textual only users
The proposed pages are presenting an extended status that you need to visualize. The console is not enough or extremely hard to support (I mean, everything is possible, imagine an ASCII rendered ZWave mesh, but nah…). This proposal is to reduce help requests on the forum, where in the MQTT case for instance a typo in the command/state topic is periodically causing a 20 posts long find-the-problem thread. Pros (textual users) don’t do such mistakes.