v0.7 does a lot of things to work around the absolute abomination that is ENTSO-E API. It's throwing 503s whenever it wants (it's not like a maintenance/release window, it's happening constantly), it returns partial data, some batches are missing etc. This totally messed up market tab charts - there're times when Finnish import is missing, but export to Latvia shows (messing up the net flow), Auvere data is missing, but aggregated to rest of oil shale blocks and so on. The new version switches to more graunular data blocks (weekly instead of monthly), adds block retries and fallbacks, but I'm sure there are cases even this does not help.

v0.6 adds predictive model showing probabilities of survival over period of time. The counter starts from the previous UMM with status BROKEN, not with the last red day on heatmap. This is a bit counterintuitive, but look at the tooltips on heatmap - for example, it's a common case for BROKEN status to end and then MAINTENANCE ticket is logged for startup procedures. Also switched to weighted average algorithm when calculating days' statuses on heatmap.

The above plot illustrates the Weibull distribution used for predictive model. It plots the days survived on x-axis, count of runs with that many days and the Weibull survival function fitted over the 10 year data.

v0.5 feels like the first stable release. Added Market tab. Fixed some bugs, tuned some algorithms. The algorithm that is calculating streaks was heavily affected by rapid fire of UMMs that come with outages, sometimes there are very short delays in between that break the streaks and bring averages down. I know the numbers have been changing one way and the other way and that is not good in the trust business. But then again, every iteration I've made feels more fair than the previous - regardless of in what direction the numbers change. It's not my intention to make things look good or bad, my intention is to provide as accurate info as I possibly know how to provide. And there is a lot of nuance to it, there always is when you dig deep enough.

Status algorithm overhaul. The previous algorithm looked at UMMs (Urgent Market Messages) and painted the period red for a BROKEN status, yellow for MAINTENANCE, and green for uptime. This penalized the station whenever a UMM was logged, even if capacity was only slightly reduced.

I decided to ditch the BROKEN/MAINTENANCE distribution and make the algorithm capacity-aware. The new mapping is:

• Green: Full capacity (≥ 250 MW)
• Yellow: Reduced capacity (50 MW to 249 MW)
• Red: Not operational (< 50 MW)

The max capacity stated in a UMM is like a speed limit on a German highway: if there is no limit, you can go as fast as your plant allows (Auvere is capped at 274 MW). If there is a limit, your actual generation can be lower, but you shouldn't exceed the limit. It is strictly an upper bound, not what the station actually generates at any given time.

We are looking at periods when this upper limit is set, as that invariably means there is a problem. I tuned the ranges to allow for normal fluctuations (260 MW is still fully operational). The cap rarely drops below 50 MW without hitting 0 MW—33 times to be exact. Since anything under 50 MW is below the boiler's minimum stable load, the plant is functionally offline at that point.

I expected the differences between the algorithms to be larger, meaning capped operation is less common than I thought. Regardless, the capacity-aware algorithm is a significant improvement. Here is a graphical representation of the differences:

The gap at the beginning represents the period when station output was capped due to dust emissions (check heatmap tooltips for detailed info).

There is also an interesting plot from testing the new algorithm. It shows the station tripping, a few attempts to restart at a 100 MW cap, a maintenance period, and a stepped startup. My initial algorithm used only the very last UMM in a chain (here setting the cap at ~225 MW), which masked the initial downtime and made the station look considerably better. Tracking the exact steps exposed the reality.

Smaller things: reworked the maintenance messages panel and the aggregate stats to fit the new calculations. Not entirely happy with it yet, but I want to push the status overhaul out and deal with smaller adjustments on the fly.

During maintenance with reduced capacity (plant partially working), pie chart with actual production is still shown. Added comparison and changelog pages.

v0.2 was the first version to actually experience Auvere outage (I don't have any test data) so multiple issues were fixed on the fly when maintenance started. v0.2 uses the 12:00 status check only for heatmap which I consider good enough, averages are based on actual periods (uptime is broken by 2h restart in the middle of the night). Added yearly status breakdown to show if the plant is improving or not. Added lifetime stats pie chart. Added ongoing and upcoming maintenance messages. There is a known deficiency which makes uptime figures worse - in some cases maintenance messages are logged when plant is operating at reduced capacity - current algorithm still counts it as downtime (but then what should be the threshold?). The difference is shown on the graph below (the capacity-aware approach uses 50% threshold).

v0.1 used the following algorithm for heatmap and stats: if the plant is up at 12:00 (no maintenance messages logged that cover 12:00), the plant is considered to be up for the whole day. This caused significant skewing of averages and streaks (you might notice this in early screenshot published on kroonika.delfi.ee).