Skip to content

3.4.1
Compare
Choose a tag to compare
@elden1337 elden1337 released this 22 Feb 07:37
· 117 commits to main since this release
3.4.1
b321c47

Downloads for this release

Hotfix 3.4.1. Read below.

Only applies if you installed 3.4.0

With 3.4.0 a nasty bug which wasn't caught in testing was introduced. Sorry about that.
What it did was adding to the peaks history constantly and not capping on your max number of registerd peaks per month (like 1, 3 or 5). This caused home assistant database to eventually get a timeout on saving the very large data set to the database, and thus the peaks vanished.

To fix this (after installing 3.4.1) you can do the following. You must have access to your home assistant db, in the case below sqlLite (the standard). If you have another type of db to store your data you must probably adjust the dialect of the query accordingly.

SELECT sa.shared_attrs
FROM   "states" s
       INNER JOIN states_meta sm
               ON sm.metadata_id = s.metadata_id
                  AND sm. entity_id = "sensor.peaqev_peak"
       INNER JOIN "state_attributes" sa
               ON sa.attributes_id = s.attributes_id
WHERE  s.last_changed_ts < 1708542011
ORDER  BY s.state_id DESC
LIMIT  1;

Then export the shared_attrs you get from the sql query and have a look there to determine what to put into the service in the next step.

service: peaqev.update_current_peaks
data:
  import_dictionary:
    6h3: 2.72
    18h14: 2.72
    19h22: 2.44

The peaks history which went amok in 3.4.0 (that's what caused this issue) should be fine a couple of seconds/minutes after the peaqev.update_current_peaks, but if not you can manually update the history with this service.

service: peaqev.update_peaks_history
data:
  import_dictionary:
    "2024_2": [2.72,2.72,2.44]
    "2024_1": [3.74,4.22,4.16]
    "2023_12": [2.95,2.93,3.05]
    "2023_11": [2.73,2.74,2.7]
    "2023_10": [2.35,2.29,2.33]
    "2023_9": [2.08,1.8,1.88]
    "2023_8": [1.97,1.83,1.82]
    "2023_7": [1.87,1.8,1.82]
    "2023_6": [2.31,2.07,2.04]
    "2023_5": [2.24,2.13,2.14]
    "2023_4": [2.97,2.38,2.74]
    "2023_3": [2.8,2.83,3.06]
    "2023_2": [2.32,2.28,2.31]

The rest of this doc is from 3.4.0.

Greetings!

In this release I focus on fixing an old sin, the calculation of observed peak (allowed to charge to) with the norwegian tiered (trinn) prices that increase in steps instead of the Swedish version which generally increases linear to the consumption.

The algorithm behind it was more complex to work out than anticipated, so if issues do arise, tell me.

Other than that preparations for future versions where I attempt to introduce defer of charge for segmented peak pricing (when peak-cost is lower at night or at weekends etc) and some changes to the max-min calculation that some of you may use. Now it will only look ahead a specified (different depending on time of day) hours and not affect hours for tomorrow night which has caused some issues with cars not being charged.

Changes:

The new norwegian calculation:

Without this new calculation, the norwegian peaks were stopped at the lowest of the registered peaks (called the observed peak). With the business model of tiers (trinn), this is suboptimal since it can mean that you are charged for the tier at 5kW, but Peaqev only let's you charge up until for example 3kW because of your currently lowest peak.
This is now taken care of and all the currently available Norwegian locales have their current tiers added.

Affected locales:

  • NO_AskerNett
  • NO_Linja
  • NO_GlitreEnergi
  • NO_LNett
  • NO_Tensio
  • NO_AgderEnergi
  • NO_Elvia
  • NO_Lede
  • NO_BKK
  • NO_Mellom
Tiers in examples (2,5,10,15,20)kW

Example 1:
Incoming peakvalues: [2.05,2.7,2.81]
Average: 2.52Kw
Next tier limit: 5kW

The most common spread, with three daily averages quite close to one another (but perhaps not on this level). In this case the observed peak can increase from 2.05-4.9kW to sustain the cost.
------------

Example 2:
Incoming peakvalues: [0.05, 14.6, 14.6]
Average: 9.75kW
Next tier limit: 10kW

In this case the observed peak can now only increase to 0.5kW, otherwise the two larger ones which are already above the desired tier range will put the average above 10kW.
------------

Example 3 (if there is only a single peak registered):
Incoming peakvalues: [2.5]
Next tier limit: 5kW

If lacking multiple peaks the response would be 4.9kW in this case to stay just below the next tier.

Full Changelog: 3.3.3...3.4.0

🥇 Has Peaqev helped you save money? Sponsoring me on Github, PayPal or BuyMeACoffee would be much appreciated.

📔 First time here? Do check the getting-started wiki for the most common questions

💬 Join my Discord-server to interact with other peaq-users.

Assets 3
Loading