Temporary Top Up logic

[Penri]

Patrick

As it happens I do need to go into WMT tomorrow, it's only a short walk for me.

I'll be there for 14:30 and will turn on the water feed to the solenoid, when done (and I don't spot any plumbing mishaps) I'll send you a txt so you can try the solenoid control manually. I'll confirm whether it works or not by txt.

When that first stage has been a success, you can put it into auto mode and I'll stay to witness it switching on at 15:00 or thereabouts.

I would rather not wait around until 16:00 for it to turn off so would be grateful it you could monitor the rising water level in the Hanham Butts and whether the solenoid switches off successfully remotely and let me know via this thread. If anything looks untowards just call or txt me.

For this trial I will close the manual gate valve so the water remains in the Hanham Butts, if you could have an occasional glance at the level remotely during the week, I'll be WMT mid afternoon Thursday 29th and hope to see a reasonable level of water in the butts.

Does that sound like a workable plan to you?

Penri

[PatrickW]

Yes, I think that should work. The main thing is to have someone see the correct function of the water inlet under manual control, and check whether the reported water level matches the apparent actual water level. I suppose it would be worth turning the solenoid on and off several times, to see if there are any mechanical issues.

I'll send you my phone number.

[PatrickW]

I've just realised a bit of an oversight in all this:

The Pis run in the UTC time zone, not GMT/BST, and the logic is just using the local time on the Pi. Therefore, rather than opening the valve at 15:00, it will open it at 16:00. I'm not sure what the desired way of handling this would be.

[Penri]

Add an hour to UTC time for now.

[PatrickW]

So, change activation time to 14:00? (i.e. 15:00 BST)
And failsafe end time to 15:00 (i.e. 16:00 BST).

[PatrickW]

Status update:

The temporary top-up logic was tested on the lhbuttspi on-site. I stopped the existing logic with kill -s SIGINT <pid> (equivalent to Ctrl+C). Once it had stopped, I renamed the rivercontrolsystem directory to rivercontrolsystem-old-2021-04-24. Then I rsync-ed the new logic over from a fresh git clone on my machine and rebooted the Pi. The control software on the NAS is down, and I don't have my SSH key authorised on the NAS, so we had to wait for the control software framework on the Pi to give up trying to connect to the NAS.

The logic ran, and it flipped between its two states when the manual override was changed between "off" and "on", as it should.

However, the solenoid did not operate. Therefore, we did not proceed to test the operation without the manual override.

Penri did not have the tools on hand to check whether there was a physical fault, so we will try again another time.

Meanwhile, I will go through the rivercontrolsystem.log that was produced from the test run, and double check I haven't made any silly mistakes in the software.

I have reinstated the previous logic under rivercontrolsystem, for now, leaving the "new" logic in rivercontrolsystem-new-temp-top-up-2021-04-24. The re-instated logic is confirmed to be running and reporting its status to the database after a reboot of the Pi.

Further update:

After checking, I haven't spotted any problems relating to device control in the software.

• We know from the log output that the logic went into the correct states.
• The unit tests show that each of these states calls the enable or disable method on the solenoid device object it has been given.
• The solenoid is present in the site config, configured to use pin 5.
• On the real hardware, the logic was outputting an "OK, in <state name>" status to the database, which shows that the solenoid device object had been found in the devices dictionary. (If wasn't, there would be a "CRITICAL ERROR" message printed and logged, and the status in the database would say "Error: No solenoid. In <state name>".)
• We know that the device object class works as far as setting GPIO pin state, because it's the same one that's used for sumppi's pumps.

So, I suspect the problem lies in the physical realm.

[hamishmb]

Patrick, your SSH key was meant to be authorised on the NAS box, sorry about that. Email your public key to me and I'll sort it for you.

[PatrickW]

Hamish, it's probably just as well I didn't have access, because I have since learnt from your recent post about the NAS control software in the July 2020 onwards - River System Status topic that you needed to actively prevent the logs from being lost when restarting, so I might not have done that. Nonetheless, I'll send my key.

[Penri]

Afternoon all,

In order that I can efficiently debug the hardware for both the solenoid and the Wendy butts pump SSR I need to be able to control them directly via a S/W interface, preferably on my phone as part of the Engineering GUI Hamish put together.

[PatrickW]

A manual software control sounds do-able. It requires the logic on sumppi and lhbuttspi to be amended to check for device control requests from the database, and the Engineering GUI to be modified to add controls and presumably some form of authentication.

I have no familiarity with the Engineering GUI (I don't even remember what language it is written in!) so that might take a bit of time.

I'll get back to you.