Temporary Top Up logic

[PatrickW]

As an interim measure to alleviate the burden of manually adding mains water due to current water losses, Penri asked if we could have a daily top-up under software control.

As per an email discussion with Penri, I have written some "Temporary Top Up" logic for the Lady Hanham SAC, which is supposed to use mains water to top the butts up to 500mm every day at about 15:00. Penri will leave the gate valves manually open in such a way that all three Lady Hanham butts groups will fill, but the logic will only pay attention to the level in the G1 group.

State diagram for the Temporary Top Up logic, from the documentation on GitLab:


Progress [updated 2021-04-22]:

• ✔ Logic written
• ✔ Unit tests written
• ✔ Unit tests passing
• ✔ Unit tests added to unittests.py
• ✔ Documentation compiles
• ✔ Tested logic on Virtual Machines
• ✘ Code review not yet done [but see below]
• ✘ Not yet merged into 'master' branch and released [but see below]
• ✘ Not yet deployed on-site

I propose to deploy it at 14:00 on a day when Penri is available to observe the effects.

Normally what happens next is that Hamish does a code review and merges the new branch into master and then, perhaps, tags it as a new release. However, we are conscious that Hamish does not have much time at the moment.

There are a couple of options to avoid burdening Hamish with the code review and merge:

1. Make Terry do it!
2. Install the 'temporary-top-up' branch onto the Raspberry Pi, without doing a code review or merging it into master.
3. Burden Hamish with it anyway.
4. Mention it to Hamish, and then Hamish decides it's not a burden and does it anyway, but really it is still a burden.

The second option would work fine (excepting any bugs missed for lack of a code review); but means the software is technically "unreleased". Which may well be the most appropriate thing for an interim measure. What does everyone else think?

For the actual deployment process, I would welcome any input about details I may have missed, as I have never done it before.

As I understand it, there is a site-wide updater that currently doesn't work, so the process is manual. I cannot locate the documentation for the site-wide updater anyway.

My thinking is:

1. Check we have a way to manually shut off the mains water inlet, or the solenoid valve
2. Check what version of the software is currently installed. Make a note of this in case it needs reverting.
3. Stop the currently installed software
4. git pull and git checkout the temporary-top-up branch onto the Pi
5. Restart the software

If it goes wrong:

• Stop the software
• Shut off the solenoid/water supply if necessary
• git checkout the previously-installed version of the software
• Restart the software

[Penri]

Patrick

Borrowing from your post:
My thinking is:
Check we have a way to manually shut off the mains water inlet, or the solenoid valve
- There's a stop-cock and a check valve in place, both currently closed.
Check what version of the software is currently installed. Make a note of this in case it needs reverting.
Stop the currently installed software
git pull and git checkout the temporary-top-up branch onto the Pi
Restart the software

If it goes wrong:
Stop the software
Shut off the solenoid/water supply if necessary
- I could do that
git checkout the previously-installed version of the software
Restart the software

If I could suggest a minor addition that could make integration testing easier at WMT. Could you add an On/Off control for the solenoid so that when you first integrate the S/W and I'm on site I could call you when I have the water feed to the solenoid turned on, you can then enable the solenoid remotely and I could tell you whether it was operating.

[hamishmb]

Unfortunately manual overrides are not yet properly supported, but one could do this by crafting a record into the database using phpmyadmin.

I'll review it for you when I have time, but I don't know when that will be so I wouldn't wait for me to do it. Unfortunately it will take me longer than usual, as I need to catch up on other things now, but I promise I will do it eventually. Create the merge request and all, and I'll get to it when I can.

[PatrickW]

Currently I do not believe the solenoid valve is controllable via the database, because I haven't written that feature into the temporary top-up logic.

I can see two ways to get a manual override control:

1. I could add to the logic the ability to accept database control input for the solenoid, and then write a separate program to issue manual device control commands via the database, or take the less 'finished' approach Hamish suggested, using phpmyadmin.
2. I could have the logic read the desired solenoid state from a local file, containing the word "on", "off" or "auto". The file would be stored in, e.g., rivercontrolsystem/overrides/device/S0, for example, and the logic would default to "auto" if the file did not exist, or to "off" if it contained anything besides "on", "off" or "auto".

The effort to add database control seems a bit disproportionate to the benefits. But, it would lay the groundwork for being able to do manual overrides via a web interface in the future, if that's a direction we want to go in. But I'm not sure it's worth doing that for a set of control logic that's supposed to be temporary.

The file approach would probably be much quicker to implement, with less to go wrong. It does not preclude the addition of database control later, and would give us a nice command line interface for free. (echo "off" > /path/to/file)

I'm inclined to take the file approach, if there is agreement on that.

Clarification edit: Simply adding the database control to the logic is not in itself much harder than adding a file-based override. (Possibly slightly easier.) But it requires either another program, or messing about with phpmyadmin, in order to actually use the database control, and that's the part that's non-trivial which makes me prefer the file-based override.

[hamishmb]

File-based override seems good to me. It can always be left in - I did this when I made the (still not fully working) site-wide updater. It's just convenient.

[PatrickW]

File-based override added. The state diagram now looks like this:


I still need to test in VMs.

[Penri]

I like this way of presenting the design intent, even I think I can understand it!

Good work.

[PatrickW]

The diagram is (roughly speaking) drawn in the manner prescribed for state diagrams by UML, as implemented by Dia (the diagram editor). I like having a diagram for this sort of thing, so I'm glad it's appreciated! The diagram is included in the sphinx docs for the software.

I have tested the logic in the virtual machine now. Seems to be working well, and the manual override is working in its various permutations, although of course the GPIO output to the solenoid can't be tested in the virtual machine. To keep the design simple, the override can take up to one full reading interval to come into effect (so, about a minute, as things are currently configured).

It's now in a state where I'd be happy to try deploying it, so I suppose we need to arrange a date.

Shall I come on-site, or would it be better to do it remotely, using the VPN? Penri, you can choose the day. I'll more likely than not be able to accommodate it.

[Penri]

Hello Patrick

I'm a little tied up and not going to be around next week but I can be at WMT on Saturday 24Apr21 (day after tomorrow), thereafter the earliest is the morning of Friday 30Apr21, then almost any day after that. Let my know what suits an I'll schedule around it.

Penri

[PatrickW]

Any of those dates is fine by me, really. Is this something that's worth you making a special trip for on Saturday, or would you rather do it when you're already going to be there? I can't really judge that, so I'll just go along with what you say. For my part, it doesn't make a difference.