Penri wrote: ↑03/08/2019, 23:36I’ve just spent a long time typing up an analysis of the results only for the forum to time me out as I submitted, loosing it all, grrrr.
If I know that my posting is likely to take a while or I get called away half-way through I try to remember to save it as draft. I still get caught though.
Penri wrote: ↑03/08/2019, 23:36I concentrated on the files before yesterday and noted that the both butts probes and float switches all looked good, the Gate Valve showed activity (by the way does a negative gate position reading (I saw -58 mean a spurious Closed or an Open at 58%?), but the Sump was reporting an unchanging 550mm,
I've noticed -58 in the values before, but it always seemed to recover OK. I don't think anything in the system is going to react to the erroneous value (it's just for reporting purposes), so I didn't worry about it. If it's a problem, the gate valve code could be modified to reject -58 as a reading (it always seems to be -58), or even any negative value.
Penri wrote: ↑03/08/2019, 23:36Looking back through the files in this group, it appears to have been at that level since 09:07 on the 25Jul19. Before that time is was varying as we would expect.
A simple explanation would be a stuck float but when I checked the sump on Tuesday 30Jul19 and saw that it was overflowing I’m positive I didn’t observe the float below the water surface.
Other explanations welcome.
This is more serious and I cannot think why it might occur.
Penri wrote: ↑03/08/2019, 23:36As I understand it if the sump level was reported at 550mm the control algorithm would not have opened the Gate Valve, so in that respect the system was operating as expected.
I was interested by your comment on the 04:00 re-boot Hamish, it certainly wasn’t me at that time of day, but I will own up to multiple soft and hard re-starts of the system in part and as a whole yesterday and today. Could it be that the RPi clocks didn’t re-sync, particularly if I took individual devices down. Whether it’s associated or not I did see that in the G4:M0 03Aug19 file the first time-stamp is 03:06 and the second 02:17.
On a positive note, I have long suspected that the Stage Butts sub-system was suffering from a slow leak, the probe measurements does not appear to bear that out. Any water they capture, albeit slowly, seems to stay put.
If the resync isn't working then all the bets are off wrt to the Readings. As it is at the moment, the Pis are only synced at boot-up. Hamish and I were discussing the idea of devolving that job to the Software Framework and doing it each time the software started up. A better idea might be a cron job or a Python apscheduler job to sync the clocks on a regular basis (every day perhaps).