Tibber Binding

I’m looking for the channel to show the average daily price that applies if either you don’t have a Pulse or you do but it fails to transmit data.
I feel the channel description (incl. binding docs) on that are ambiguous and need some more documentation.

There are channels daily_Cost and live_accumulatedCost but what exactly is the difference ?
Is it the same without and with Pulse ? If so, will having a Pulse affect daily_Cost, too ?

As described in docs, all Tibber Pulse channels (denoted as Live) are in fact so, i.e. live measurements, recorded every 2 seconds. So, LiveAccumulatedCost will be the accumulated cost from midnight to the time of record.

Daily cost, as described under the subscription/query part, will only be updated around transition of day, reporting last day cost. Timing of record depends whether or not one actually have a Tibber subscription or not.

Thanks but my question is in fact more about the semantics of those channels, I probably should have made that clearer.

Assume I have a Pulse and a Tibber subscription with the hourly changing tariff.
liveAccumulatedCost and for the previous day (turnover @midnight) dailyCost tell me my cost.

However, now I want to know what my cost would have been if I had had no subscription to the hourly changing tariff with Tibber or if my pulse hadn’t been working. In both cases Tibber will charge me a tariff which is a fixed value for the day (I think, or is it the whole month ?).
Now that value I want to know.
If I wasn’t subscribed to the hourly tariff, I could (probably) read the aforementioned channels. But I am, so they show my real cost and not the “what-if-pulse-was-broken” values which are what I’m looking for.

In Germany:
You get billed (and AFAICT the data from the Tibber API should reflect it) according the hourly prices and [ real consumption (data from your Pulse) OR fictive consumption according to “Standardlastprofil” (standard load profile) [ based on your consumption derived from previous year OR based on your ‘real’ consumption computed from your monthly meter readings you input into your Tibber app ] ].

Missing values from your Pulse will be billed according to “Standardlastprofil” and the total consumption during the data gap.

Without Pulse, it doesn’t make sense to ask for real time cost as the cost (and the data from the Tibber API) for the current month will be recalculated at the beginning of the next month based on the meter reading you provide at the end of the current month.

Details: Tibber ⚡ Stromlieferung

Can I somehow determine what the weighted price would have been if Standardlastprofil was applied ?
Ultimately I want to see how much I’ve saved by moving consumption to cheaper hours.

You would have to calculated it: https://www.bdew.de/media/documents/2000131_Anwendung-repraesentativen_Lastprofile-Step-by-step.pdf - not quite trivial, but not rocket science either.

For an implementation based on KNIME Analytics Platform (kind of using a sledgehammer to crack a nut … - but I like KNIME :slight_smile: ) cf. Thread for discussing money saved with OpenHAB - #8 by Ap15e.

For a Power BI implementation check out Power-BI-Report für Tibber-Freunde - Off Topic - TFF Forum - Tesla Fahrer & Freunde - I don’t like Power BI and haven’t checked the Power BI implementation for correctness (does it use the dynamized standard load profile?).

Is it really based on the consumer’s own past consumption? Tibber says otherwise: Standardlastprofile in der Tibber-Verbrauchsabrechnung | Tibber Support Center (german only). It’s SLP for everyone (it would make sense, since I don’t think Tibber would incorporate some kind of BI for every single customer)

… which is why there must be a price that applies per day (or month?), based on SLP. That’s what Tibber charges when it has no pulse data or the customer has no pulse and charging is based on the classic way by reading the meter.
There must not be a need to calc it myself, it must be published somewhere, and that’s what I’m looking for.

In case of ‘no Pulse’ and no willingness to manually enter the monthly meter readings into the Tibber app:
To create the monthly bill, Tibber must use historical consumption data and your (dynamized) SLP. As soon as Tibber gets the yearly meter reading from the ‘Messstellenbetreiber’ (metering point operator), all previous bills will be recalculated based on your personal SLP. To avoid additional payments, one does well to provide Tibber with monthly meter readings …

There must be an easier way to get this.
All I want is the average price Tibber applies for the day for a customer with an unknown profile.
Isn’t that what you pay when you don’t have a Pulse ?
It must be published somewhere …

In Germany, all customers are associated with a load profile (e.g., H0 for private households). As soon as the hourly prices for tomorrow are published by epexspot, Tibber could calculate and publish a price per kWh for tomorrow based on the H0 profile for tomorrow - but: without Pulse the energy consumption per day gets calculated based on H0 at the beginning of the next month for the previous month (I’m not sure whether the monthly bills are final in the sense that there will be no recalculation at the end of a year), so knowing the price/kWh for a specfic day doesn’t help at all to optimize your costs.

To give a simple example:
Billing period 2023-07-01 - 2023-07-31
price based on H0: 20 ct/kWh for all days exept 2023-07-15
2023-07-15: price based on H0: -50 ct/kWh
Consuming 50 kWh on 2023-07-15 and no consumption on the remaining days of the month doesn’t earn you 25 EUR as - for billing purposes - the consumption on 2023-07-15 and on the remaining days will be recalculated according to the daily H0 profiles for the whole month.

That’s not what I want it for. I’m looking for a reference to compare my consumption to.

AFAICT Tibber doesn’t provide what you are looking for (Tibber Developer). You might find Energietools useful (haven’t checked it for correctness - the spelling error in the title (“Standart…”) doesn’t exactly inspire confidence …). Of course, an Excel tool isn’t optimal, but exporting the profile data for some years to come to a database won’t take much time.

Same issue(?) here: Neither channel today_prices nor live_accumulatedCost is available to me. The suggestion

does not solve the problem for me.

I understand that live_accumulatedCost may not be available to me since the start of my Tibber electricity delivery is not reached yet. But can this probably be the reason for today_prices not being available as well? On the other hand the channels current_total and tomorrow_prices are available. Then why wouldn’t be today_prices?

As a workaround I currently copy tomorrow_prices into my own today-price item a few seconds before midnight and use that for price calculations and automations for the current day.

So, you have the channels available (show advanced), and have items linked which only show NULL? Would then point in the direction of not having an active subscription yet.

Up until now, I haven’t been using the today_prices channel active. Recreated my thing, added a linked item to the channel, and after some time I received data for the channel/item.

Uh, no. The channel today_prices is not in the list of available channels (only tomorrow_prices pops up when clicking ‘Show advanced’); haven’t noticed so far since I do textual configuration of my items and copy-pasted the demo items from the Add-on documentation. live_accumulatedCost, on the other hand, is available but shows NULL.

Which version of the binding are you using?

As you do not have today_prices available under advanced, either you are using a version prior to implementing today_prices, or you haven’t succeeded deleting/recreating your Tibber API thing as described above.

NULL value for accumulated cost would be explained by subscription not active yet.

I’m using version 3.4.4. of the binding.

today_prices was introduced after version 3.4, so you would need to update to OH4.

today_prices was introduced after version 3.4, so you would need to update to OH4.

Updating to OH4 did the job. Thanks.