We need to do research on what cards should automatically update #742

Closed
opened 2026-05-05 09:52:32 +00:00 by a22erigr · 5 comments
Collaborator

Description

In issue #702 the card TemperatureView now updates automatically.
The next step is to decides what cards automaticly should be updated and how often this should occur.

What needs to be done

  • research what cards needs to be automatically updated.
  • If a card needs to be updated state how often this update should occur.
## Description In issue #702 the card TemperatureView now updates automatically. The next step is to decides what cards automaticly should be updated and how often this should occur. ## What needs to be done + research what cards needs to be automatically updated. + If a card needs to be updated state how often this update should occur.
Collaborator

ParkingView:

-Data is fetched once
-Suggested interval: every 1–2 minutes
-Reason: Parking availability can change frequently
-Auto-update can be added

**ParkingView:** -Data is fetched once -Suggested interval: every 1–2 minutes -Reason: Parking availability can change frequently -Auto-update can be added
Collaborator

The table below shows what cards should be automatically updated. This excludes the TemperatureView and should exclude the ClockView since the update is implemented but because it was recently created and still needs review.

Card Reason How often?
ClockView It is a clock every second
TemperatureGraphView Forecast/sensor graph should stay fresh 30-60
TemperatureAllView Depends if it shows historical or live data 1 - 5 min
TemperatureWeekView Not necessary, but would work 5-15 mins
SMHIForecastView SMHI Forecast updates only a few times per day 30-60 mins
SMHITemperatureView data changes but not every second 10 - 30 mins
ParkingView Parking availability can change 15 - 60 secs
BookingView Room availability can change 1-5 min
ScheduleView Can be updated but not frequently and rarely 60+ min, or manually -> not auto
The table below shows what cards should be automatically updated. This excludes the TemperatureView and should exclude the ClockView since the update is implemented but because it was recently created and still needs review. | Card | Reason | How often? | |---------|---------|---------| | ClockView | It is a clock | every second | | TemperatureGraphView | Forecast/sensor graph should stay fresh | 30-60 | | TemperatureAllView | Depends if it shows historical or live data | 1 - 5 min | | TemperatureWeekView | Not necessary, but would work | 5-15 mins| | SMHIForecastView | SMHI Forecast updates only a few times per day | 30-60 mins | | SMHITemperatureView | data changes but not every second | 10 - 30 mins | | ParkingView | Parking availability can change | 15 - 60 secs | | BookingView | Room availability can change | 1-5 min| | ScheduleView | Can be updated but not frequently and rarely | 60+ min, or manually -> not auto |
Collaborator
  • TemperatureAllView
    • Updates over time
      • every 15 seconds
  • ParkingView
    • Shows parking availability
    • Changes often
      • Update every 15- 30 seconds
  • SMHITemperatureView
    • Data updates a few times per day
      • Update every 5-10 minutes
  • SMHIForecastView / TemperatureGraphView
    • Changes are not frequent
      • Update every 10-30 minutes
  • BookingView
    • Data can change, not frequently
      • Update every 60 seconds
+ TemperatureAllView + Updates over time + every 15 seconds + ParkingView + Shows parking availability + Changes often + Update every 15- 30 seconds + SMHITemperatureView + Data updates a few times per day + Update every 5-10 minutes + SMHIForecastView / TemperatureGraphView + Changes are not frequent + Update every 10-30 minutes + BookingView + Data can change, not frequently + Update every 60 seconds
Collaborator

Reasoning looks solid, i think the high end of the updating frequency could be preferred to keep the amount of data being fetch as low as possible while still keeping the cards fresh

Reasoning looks solid, i think the high end of the updating frequency could be preferred to keep the amount of data being fetch as low as possible while still keeping the cards fresh
Author
Collaborator

Great review. I agree that the high end should be used

Great review. I agree that the high end should be used
Sign in to join this conversation.
No milestone
No project
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Andras/BoundlessFlowCampus2K#742
No description provided.