Results Database Server
Re: Results Database Server
It's starting to sound like we're talking at cross purposes to me - as your explanation went on I was slowly getting more confused.
I think maybe it would be best to do a short video call to get us all on the same page? Agreed that we don't want to overthink, but we do need to agree on what to do before I implement it
I think maybe it would be best to do a short video call to get us all on the same page? Agreed that we don't want to overthink, but we do need to agree on what to do before I implement it
Hamish
Re: Results Database Server
I'm all for a video conference. Patrick, do you have MS Teams? There is a Linux version.
Terry
Re: Results Database Server
I don't have Microsoft Teams. Could install it in a VM. I did that with Skype once. I think I still have a Microsoft account somewhere.
I'm open to a video call later on if you guys think it will help.
I will have another stab at a written response though, because I might not get any of these words to come out of my mouth in the right order.
My understanding is that, ideally, we would just use a long, fixed reading interval all of the time, to avoid having to store lots of readings.
I think the whole reason for changing the interval over time is that sometimes there is a need to get quite rapid updates on the state of each water vessel in order to prevent the control algorithms from "overshooting". Therefore, directly or indirectly, the control algorithms define the reading interval(s), because they are where the requirement to vary the interval(s) derives from. (Irrespective of whether it is a global interval or a per-Pi interval.)
Are we seeing eye to eye on this one point?
I'm open to a video call later on if you guys think it will help.
I will have another stab at a written response though, because I might not get any of these words to come out of my mouth in the right order.
To me, setting the reading interval isn't about keeping things in sync. That's a separate thing. Noteworthy, but separate.
My understanding is that, ideally, we would just use a long, fixed reading interval all of the time, to avoid having to store lots of readings.
I think the whole reason for changing the interval over time is that sometimes there is a need to get quite rapid updates on the state of each water vessel in order to prevent the control algorithms from "overshooting". Therefore, directly or indirectly, the control algorithms define the reading interval(s), because they are where the requirement to vary the interval(s) derives from. (Irrespective of whether it is a global interval or a per-Pi interval.)
Are we seeing eye to eye on this one point?
Re: Results Database Server
Hamish and myself both have MS Teams installed under Linux using I installed Teams using this resource: ... ms-linux/ .
Why don't you get it installed and setup and then let us know, so we can send you an invite to the 'Wimborne Model Town' Team'? We'll then start a Meeting at a mutually beneficial time.
Like Hamish, I think that this discussion is better with all of us in a Meeting, to avoid misunderstandings.PatrickW wrote: ↑23/05/2020, 12:53I will have another stab at a written response though, because I might not get any of these words to come out of my mouth in the right order.
To me, setting the reading interval isn't about keeping things in sync. That's a separate thing. Noteworthy, but separate.
My understanding is that, ideally, we would just use a long, fixed reading interval all of the time, to avoid having to store lots of readings.
I think the whole reason for changing the interval over time is that sometimes there is a need to get quite rapid updates on the state of each water vessel in order to prevent the control algorithms from "overshooting". Therefore, directly or indirectly, the control algorithms define the reading interval(s), because they are where the requirement to vary the interval(s) derives from. (Irrespective of whether it is a global interval or a per-Pi interval.)
Are we seeing eye to eye on this one point?
Terry
Re: Results Database Server
I've just got to sort some laundry out, then I'll take a look at Teams.
Re: Results Database Server
I think I understand what you're saying Patrick, but yeah a meeting with Teams or Jitsi would be easier I think.
Drop me a text if you need to get my attention though - I don't have notifications enabled so I have to check manually.
Drop me a text if you need to get my attention though - I don't have notifications enabled so I have to check manually.
Hamish
Re: Results Database Server
I'm going for Teams ATM, because we have a ready-made forum.
I'll undertake to send you a text.
I'll undertake to send you a text.
Terry
Re: Results Database Server
Hmm, it has just occurred to me that I've somehow forgotten to implement the "System Tick" table that we discussed, and instead have investigated the readings tables to find the latest tick that was used when restoring from the database.
I'm having some trouble finding our older discussions on some of these things, like what the "Software Status" column is to be used for, so we may have already agreed to do this. This implementation seems to work okay, and the readings tables have a "Measure Time" column, so are we happy to keep it this way anyway?
I'm having some trouble finding our older discussions on some of these things, like what the "Software Status" column is to be used for, so we may have already agreed to do this. This implementation seems to work okay, and the readings tables have a "Measure Time" column, so are we happy to keep it this way anyway?
Last edited by hamishmb on 20/07/2020, 12:49, edited 1 time in total.
Hamish
Re: Results Database Server
Hamish,
The System Tick isn't needed for normal use; it was intended to make it easier to create synchronised charts. Since every reading is timestamped with the current time when it was measured, then every reading in the Results Database will have slightly different timestamps. It's possible to create charts from this, as Phillip demonstrated, but gets a bit messy when you try to expand the data out to individual readings.
The System Tick isn't needed for normal use; it was intended to make it easier to create synchronised charts. Since every reading is timestamped with the current time when it was measured, then every reading in the Results Database will have slightly different timestamps. It's possible to create charts from this, as Phillip demonstrated, but gets a bit messy when you try to expand the data out to individual readings.
Terry
Re: Results Database Server
Right, so we still want the "System Tick" table? That's fine, and won't be difficult to do
Hamish