Allow plugins ability to augment the html displays?

[jonathan]

Hi Dan,

I've written a plugin that logs the water pressure for the system, and displays a graph of that on the home page, so it's easy to correlate with the history.  It seems to be working pretty well, but I needed more access to the home page html than seems to be offered by the plugin architecture.

I believe the limits of the plugin architecture WRT the display, are adding completely new pages, adding a bit of text to the footer, or adding to the status text on the timeline.  Did I miss something or is this really the limit?

In order to display the graph I want to insert and populate an additional table row in the schedule table, aligned with the program display for system maintenance purposes.  Right now I manually add a <script src="..."> tag to home.html, and use this to attach events to generate the UI changes (jQuery listeners and DOM MutationObservers).

Maintaining even this single line of code different from the trunk isn't ideal, so I started thinking about a more general way to accomplish this.  For instance adding a global variable which would contain a list of scripts to inject, something like:

gv.plugin_scripts = [];

Each plugin could augment register the need to inject scripts into the home page by populating this variable:

gv.plugin.append(["home", "pressure_monitor.js"]);

When any UI page is loaded, it would check for any relevant script injection requests and process them.  The result in this case would be to generate a <script src="static/scripts/pressure_monitor.js"></script> tag in the home page.

WDYT?  Would this be granting too much power to plugin developers?

- Jonathan

[dan]

An interesting proposal.
let me give it some thought and I will get back to you.

Could you provide a screen shot of what you have?

Would adding e.g. a chart to the footer work for you?

Dan

[jonathan]

Here's a screenshot of what I've got now: https://photos.app.goo.gl/U5b5yFgVt1Lw6rFeA

The reason for inserting into a table row instead of the footer is so that the graph naturally lines up with the timeline, despite what kind of width changes the first couple of table rows go through.

Here are some other interesting scenarios that would require full control to modify the interface:

- a "federated view" plugin that displays activity (adds table rows) from other systems in the timeline (display only, no effect on execution.) I have three systems running off a single pump, I have to switch tabs a lot to ensure the programs are mutually exclusive.
- illustrating sunrise/sunset or hourly temperature readings as timeline background colors
- adding new menu items, e.g. a "test mode" interface that provides simpler on-off control and bigger buttons for mobile experiences in the field. This avoids scrolling with wet hands and accidentally leaving the system in manual mode after testing. New feature like this could be developed, tested, and evaluated prior to becoming part of the main program.
- restricting certain features, e.g. disabling manual mode or putting an automatic timeout on it. I've trained myself over the years through losing plants that manual mode is a dangerous way to test stations - now I have other people using the interfaces and starting the same brutal training process.

Are there any existing plugins that could benefit from improve UIs using this feature?

[dan]

Those sound like some really good ideas.
Could you make a pull request for a new branch incorporating your changes?

I can't think of any current plugins that might use the new features but I'm sure there would be new ones that would.

Dan

[jonathan]

The improvement is actually simple (just two lines of code), but I also updated the proto plugin to illustrate how this works and make it easier for plug in authors to get started. See https://github.com/Dan-in-CA/SIP/commit/...eedaac3881. I'm still testing it with my custom plugins, if I find no issue I'll do a pull request. If you see any possible improvements let me know. I'm not sure how it will work with the plugin manager - simply adding the .js file to the manifest should be sufficient to allow installation and enablement, no?

Found another very handy scenario - testing plug ins! I've written one to try to help identify the issue with 318 and I'm now using it to verify my fix before committing. The plugin would be easier to share for user verification than a random source code fix.

[dan]

Very cool!
I will check it out.

Dan

[jonathan]

I checked in some further improvements, and created an example plugin that adjusts the schedule background to show local sunrise and sunset times. Validation that the mechanism is practical. I haven't tested the installation and the correctness of the manifest. (Plugin management features don't work on my Windows dev environment.)

The plugin code is here: https://github.com/jonathan-marsh/sip_pl...al_display

[dan]

I puled your SIP updates and installed diurnal_display plugin.
When I try to load the plugin I get:
Ignoring exception while loading the diurnal_display plug-in.
cannot import name 'UTC' from 'datetime' (/usr/lib/python3.9/datetime.py)

Running Python 3.9.2  Pi OS bullseye.

I will try with a newer Python version.

Dan

Same import error on windows with Python 3.10.11.

[jonathan]

Thanks for taking a look. It looks like .UTC was added in python 3.11. Seems it's the same as datetime.timezone.utc which should work in earlier versions as well. I've posted the change and verified it still works in 3.12.

[dan]

I have had occasional problems from using the latest Python features before Raspberry Pi OS can support them.

However the latest RasPi OS (bookworm) does include Python 3.11.2.

I will take a look at your update.