Spring / Summer 2018 and onwards software

[hamishmb]

Hi all,

As we haven't changed much with the river system, I actually haven't changed the software at all since December!

However, as we've got it going again (ish) now, I'm sure we'll find things to implement and - here might be a good space to make note of things I need to do.

Hamish

[hamishmb]

Currently, I propose that I make a class for readings, rather than using the tightly-formatted strings of the moment - it's getting too complicated and difficult to manage as we add new features. Also, I want to fix a bug where the G4:M0 (butts level) probe readings keep showing up in the sumppi logs even when they haven't changed at all - hogging disk space and making logs hard to read.

Hamish

[hamishmb]

Additional thing: when the butts are full, and the sump is high, make the reading interval lower (perhaps 60 seconds), rather than the 5 minutes we have at the moment - too slow to respond.

[hamishmb]

I have updated the software to include the following fixes/improvements:

• Version bumped to 0.9.2.
• Copyright updated for 2018.
• A class for readings has been created.
  • As yet incomplete - need to think more about what will be required of it.
  • Any thoughts Terry?
  • Not yet in use.
  • Documentation has been written.
  • Need to implement fully before we can disable repeated readings messages from the butts probe even if the readings are the same.
• When both the butts and the sump are full, set the reading interval to 1 minute, instead of 5 minutes.
  • This gives the software a chance to respond to changes eg if the sump is overflowing and the float switch just sunk.
• Updated basic/overall docs for coretools.py to reflect the changes.

.

I will deploy this software on our new system when I come into the model town tomorrow.

Hamish

[TerryJC]

• As yet incomplete - need to think more about what will be required of it.
• Any thoughts Terry?
• When both the butts and the sump are full, set the reading interval to 1 minute, instead of 5 minutes.
  • This gives the software a chance to respond to changes eg if the sump is overflowing and the float switch just sunk.

.

Hamish,

You seem to have all the bases covered for the current requirements. Looking to the future, I think it would be useful if the Staff GUI Web Interface was able to trigger readings on a particular sensor at any time to help with diagnosis if things seem to be going wrong. It isn't essential by any means, because the stalest data we will have will be no more than 5 minutes old, but it could be useful if things are clearly going wrong, but the current data set doesn't give enough granularity to see why.

[hamishmb]

Hi,

That is true, but implementing the Reading class would allow me to refactor and improve existing code significantly, as well as do some work ahead of time for when we want to improve fault detection or take action on many different readings from different sensors. Okay, I'll have a think about how triggering readings can be done.

Hamish

[hamishmb]

Also, I updated the software today to incorporate yesterday evening's fixes.

Hamish

[hamishmb]

Update:

Support for the 2nd SSR (the one for the main circulation pump) has now been implemented for BCM pin 18 (please verify this is correct Terry). I have also partially tested it at home and updated some of the documentation.

If I have time on Thursday I plan to deploy this on the pis when I update their system software.

Hamish

[TerryJC]

18 is correct.

[hamishmb]

Hi,

Seeing as I've finished my exam, I thought I'd make a start on some of the next features I have on my list. One of these is writing readings files in CSV format, but as far as I remember, we never arrived at a definitive answer of what we wanted.

I can do other stuff first, so there's no hurry to decide on this, but what exactly was it that we wanted for the format?

Hamish