Improvements on aggregated data for TempService

Andras commented

2026-03-27 16:10:04 +00:00

Owner

TempService only has /latest och /all.

We need to have aggregated data under /year, /year/week ,/year/month

The aggregated data should be put into a (cached) DBS, so we don't need to compute them in real time, as that would create performance issues.

TempService only has /latest och /all. We need to have aggregated data under /year, /year/week ,/year/month The aggregated data should be put into a (cached) DBS, so we don't need to compute them in real time, as that would create performance issues.

Andras added the

enhancement

backEnd

labels

2026-03-27 16:10:04 +00:00

a24timsv added the

Team 1

label

2026-03-31 10:52:42 +00:00

b24johka self-assigned this

2026-04-07 09:10:16 +00:00

b24hugst was assigned by b24johka

2026-04-07 09:10:35 +00:00

b24hugst commented

2026-04-07 14:59:16 +00:00

Collaborator

I've created a cache and a http GET endpoint for the /temperature/year. Although I'm having a hard time getting it work as the only year right now is 2026. I'll continue tomorrow and try to get some function to work at least and leave the rest for a new issue maybe. If I don't get anything to work at all and it feels clunky I'll just delete the branch and give the issue to someone else.

b24hugst commented

2026-04-09 08:37:26 +00:00

Collaborator

After a meeting with our group I now understand that it's supposed to be mock data (fake data), and I also have a better understanding on what files to edit, so I'll continue with this problem anyway and give it another shot.

b24hugst added reference #20-aggregated-data-for-tempservice

2026-04-10 10:03:58 +00:00

b24hugst referenced this issue

2026-04-10 10:22:00 +00:00

#20 Average temperature for year, and a cache #227

b24hugst commented

2026-04-13 07:21:17 +00:00

Collaborator

As the /year is now functioning(I think). I'll start working on /year/month. Would be very nice if you could make that into another issue @b24johka so the branches don't get mixed up.

As the **/year** is now functioning(I think). I'll start working on **/year/month**. Would be very nice if you could make that into another issue @b24johka so the branches don't get mixed up.

b24hugst referenced this issue

2026-04-13 11:46:21 +00:00

#20 Average temperature for year, and a cache #227

b24hugst changed reference from ~~#20-aggregated-data-for-tempservice~~ to #20-aggregated-data-for-tempservice

2026-04-13 12:41:04 +00:00

b24hugst changed reference from ~~#20-aggregated-data-for-tempservice~~ to #20-aggregated-temp-for-month-year

2026-04-13 12:41:09 +00:00

b24hugst commented

2026-04-13 12:54:46 +00:00

Collaborator

/year/month is now also working. So only /year/month/week to go.

b24hugst referenced this issue

2026-04-13 13:45:29 +00:00

#20-aggregated-temp-for-month-year #267

a24timsv commented

2026-04-20 06:48:45 +00:00

Collaborator

Is this issue still ongoing? I can see and test the yearly temps but months gives error 400. The logs for the tempService container gives outputs that it did retrieve temps however (see Images below).

I noticed that that April works, which is good, but does only April work? This also might not be in this issue, but shouldn't the View for month temp have selectable months? The same with years?

Would like an update so that I just know how we are doing on this issue?

Is this issue still ongoing? I can see and test the yearly temps but months gives error 400. The logs for the tempService container gives outputs that it did retrieve temps however (see Images below). I noticed that that April works, which is good, but does only April work? This also might not be in this issue, but shouldn't the View for month temp have selectable months? The same with years? Would like an update so that I just know how we are doing on this issue?

image.png

62 KiB

image.png

62 KiB

b24hugst commented

2026-04-20 07:07:34 +00:00

Collaborator

@a24timsv Yeah it's still /year/month/weeks that has to be implemented for the issue to be complete. I divided them a little since I had some troubles. I think only April works because that's the only month that's been saved so far. Although it shouldn't give a 400 http error. I didn't get much done on this last week as I got sick and worked on another issue but I'll look into it this week.

Yes the views for months and years should absolutely have selectable months and years, but I thought it would be better to put that as a new frontend issue instead as I wanted to focus purely on backend here.

I don't know about the 400 error. It shouldn't happen. Maybe something changed in the structure when I was sick. I will try to fix it!

@a24timsv Yeah it's still **/year/month/weeks** that has to be implemented for the issue to be complete. I divided them a little since I had some troubles. I think only April works because that's the only month that's been saved so far. Although it shouldn't give a 400 http error. I didn't get much done on this last week as I got sick and worked on another issue but I'll look into it this week. Yes the views for months and years should absolutely have selectable months and years, but I thought it would be better to put that as a new frontend issue instead as I wanted to focus purely on backend here. I don't know about the 400 error. It shouldn't happen. Maybe something changed in the structure when I was sick. I will try to fix it!

a24timsv commented

2026-04-20 07:55:48 +00:00

Collaborator

It's fine, I'm just trying to cleanup and check for abandoned issues. I can create a separate issue with the frontend components so that they have selectable years, months and weeks. The 400 error might be because the View defaults to a month that doesn't exist/have data.

Either way, it would be nice to have some faked history data so that the other variables can be tested. Maybe the mockup data can add temps to previous years in the database so something can be seen at least?

It's fine, I'm just trying to cleanup and check for abandoned issues. I can create a separate issue with the frontend components so that they have selectable years, months and weeks. The 400 error might be because the View defaults to a month that doesn't exist/have data. Either way, it would be nice to have some faked history data so that the other variables can be tested. Maybe the mockup data can add temps to previous years in the database so something can be seen at least?

a24timsv referenced this issue

2026-04-20 08:00:29 +00:00

Add selectables to tempService year, month and week #429

b24hugst commented

2026-04-20 08:31:50 +00:00

Collaborator

I did include that whenever there's no data, it returns a 404 error instead, which the frontend handles to output "NO DATA" in a card.

I think 400 is something else that I'll look into now. And yes it would be nice to have some faked history data. Do you think it would be wise to have a new issue for that as well?

I did include that whenever there's no data, it returns a 404 error instead, which the frontend handles to output "NO DATA" in a card. I think 400 is something else that I'll look into now. And yes it would be nice to have some faked history data. Do you think it would be wise to have a new issue for that as well?

b24hugst commented

2026-04-20 08:37:41 +00:00

Collaborator

Yeah the 400 error in month is because someone wrote "February" as a string, instead of 2 as an integer. After I changed it now shows this instead:

![image](/attachments/85e5cc6f-2200-45d0-b086-199ca0d54d3e) Yeah the 400 error in month is because someone wrote "February" as a string, instead of 2 as an integer. After I changed it now shows this instead: ![image](/attachments/1a52c01f-c862-459e-9f99-90b6b17b5e0d)

image.png

7.3 KiB

image.png

27 KiB

a24timsv commented

2026-04-20 11:58:12 +00:00

Collaborator

That explains it.

Another issue was found when @a24julot made the frontend components changeable in #429. When selecting year and month it displays the month correctly but the year is always 2026. No matter what year is selected (example of year 5555).

That explains it. Another issue was found when @a24julot made the frontend components changeable in #429. When selecting year and month it displays the month correctly but the year is always 2026. No matter what year is selected (example of [year 5555](http://localhost/app/api/temperature/5555/4)).

b24hugst commented

2026-04-20 13:07:17 +00:00

Collaborator

I think I found the issue. I updated her branch in the pull request.

b24hugst commented

2026-04-21 13:47:10 +00:00

Collaborator

@a24timsv Could you or @b24johka create another issue for the /month/week part and assign it to me? Gonna get weird with the branch naming otherwise. I will start on it after tomorrow's merge.

a24timsv referenced this issue

2026-04-21 14:47:54 +00:00

Add /month/week endpoint for TempService #484

b24hugst referenced this issue

2026-04-27 10:23:57 +00:00

#484-weekly-aggregated-temperature #580