Belgium (Fluvius) v1.7 datagrams: capacity tariff #69

wimleers · 2023-02-08T12:28:40Z

Hiya!

Thanks for this superb Homebridge plugin! 🤩 Especially love the Eve history support: it's far better than the dashboard that https://fluvius.be/ offers, because that will lag anything between 12 hours and 4 days 🙃

On January 1, the "capacity tariff" (capaciteitstarief) launched in Belgium. This added extra information to the P1 datagrams, which homebridge-p1 does not know how to interpret:

[2/8/2023, 12:48:45 PM] [P1] Electricity Delivered: Last Updated: set to "Wed Feb 08 2023 12:48:48" (from "Wed Feb 08 2023 12:48:47")
[2/8/2023, 12:48:46 PM] [P1] warning: 1-0:1.4.0: ignoring unknown key
[2/8/2023, 12:48:46 PM] [P1] warning: 1-0:1.6.0: ignoring unknown key
[2/8/2023, 12:48:46 PM] [P1] warning: 0-0:98.1.0: ignoring unknown key
[2/8/2023, 12:48:46 PM] [P1] Electricity Delivered: Last Updated: set to "Wed Feb 08 2023 12:48:49" (from "Wed Feb 08 2023 12:48:48")
[2/8/2023, 12:48:47 PM] [P1] warning: 1-0:1.4.0: ignoring unknown key
[2/8/2023, 12:48:47 PM] [P1] warning: 1-0:1.6.0: ignoring unknown key
[2/8/2023, 12:48:47 PM] [P1] warning: 0-0:98.1.0: ignoring unknown key
[2/8/2023, 12:48:47 PM] [P1] Electricity Delivered: Last Updated: set to "Wed Feb 08 2023 12:48:50" (from "Wed Feb 08 2023 12:48:49")
[2/8/2023, 12:48:48 PM] [P1] warning: 1-0:1.4.0: ignoring unknown key
[2/8/2023, 12:48:48 PM] [P1] warning: 1-0:1.6.0: ignoring unknown key
[2/8/2023, 12:48:48 PM] [P1] warning: 0-0:98.1.0: ignoring unknown key

This is labeled version 1.7 of Belgium's DMSR implementation. See the official spec for details.

This PR provides a sample datagram — I'm happy to provide more if that's useful!

If you would like me to contribute the code to interpret and expose these values: I'm happy to help, but look to you for implementation guidance.

I also did some digging and found these PRs against other projects that may be helpful references:

ebaauw · 2023-02-08T13:44:02Z

Interesting. I also see mention of a water meter in the document, but your meter doesn't seem to report that? Would be cool to expose a separate accessory for water consumption, similar to natural gas consumption.

If I understand correctly:

1-0:1.4.0 is the high-water mark of the current consumption (in kW) per 15 minutes. This could simple be exposed as an additional characteristic Consumption Peak (cf. Total Consumption Normal and Total Consumption Low).
However, since the price per kWh depends on this peak consumption, it might make sense to base Eve history on this instead of/in addition to the current consumption. I see some challenges, though:
- How to recognise that a new 15-min period has started (or do they simply start at the quarter hour?);
- Not sure if the Eve app will like a history entry per 15 min instead of per 10 min;
- If "in addition to" it would have to be a separate accessory.
1-0:1.6.0 is the highest value of 1-0:1.4.0 in the last month, incl. a time stamp of when this occurred. This could simply be exposed as two addtional characteristics, Concumption Monthly Peak and Time Monthly Peak.
0-0:98.1.0 is a series of highest values over past periods, incl. the start and enddate of the period. This repeating data would have to be exposed as a service per entry.

How would you use this info? Would you actually want to check your invoice against historical peak values in HomeKit (and need for 1-0:1.6.0 and 0-0:98.1.0 to be exposed)? Would you want to set an automation or alarm when the peak value exceeds a threshold (which would probably too late, as you've exceeded the threshold)? Would set an automation or alarm when the current value comes close to a threshold (to prevent exceeding the threshold)? Would you simply use the history to analyse your usage pattern and change your behaviour?

ebaauw · 2023-02-10T09:50:33Z

Are you sure you captured the telegram correctly? I get a CRC error trying to parse it?

wimleers · 2023-02-10T11:11:38Z

I'm happy to recapture it. I copy/pasted it and manually added the trailing \rs that your other sample telegrams contained.

I also see mention of a water meter in the document, but your meter doesn't seem to report that?

Correct, I was also surprised to read that in the document! Unfortunately, the reality is that 99% of Belgium doesn't yet have digital watermeters — I believe only Antwerp has a significant deployment, the rest only has pilots.

Would be cool to expose a separate accessory for water consumption, similar to natural gas consumption.

Indeed! Some day 😄

1-0:1.4.0 is the high-water mark of the current consumption (in kW) per 15 minutes. This could simple be exposed as an additional characteristic Consumption Peak (cf. Total Consumption Normal and Total Consumption Low).

An additional characteristic sounds perfect! But note that 1-0:1.4.0 is not the high water mark — it's the average current consumption (in the current 15 minute window). 1-0:1.6.0 is the highest 1-0:1.4.0 value in the current month.

Looking at the example on the last page of the document makes this more clear:

1-0:1.4.0(02.351*kW)
1-0:1.6.0(200509134558S)(02.589*kW)

→ 2351 W is the current window's average consumption, and the peak for this month was 2589 W, at 2020-05-09 13:45:58 (and it was Summer time).

So I would propose Consumption Average Live + Consumption Peak, or Consumption Window + Consumption Window Peak. Or something along those lines 😊

However, since the price per kWh depends on this peak consumption, it might make sense to base Eve history on this instead of/in addition to the current consumption.

No, the price per kWh is still charged based on Tariff = Normal vs Tariff = Low, which you already show 👍 This the the consumption price you pay.

The capacity tariff is an additional cost charged based on the peak capacity used, independent of how much you consume. IOW: you pay more if your usage requires a bigger pipe/thicker cables in the infrastructure!

(In fact, they are legally forbidden from charging more for the distribution network infrastructure across the entire population. Say that they receive €1 billion/year pre-capacity tariff, then that's still going to be true today, it's just going to be charged differently. The rationale being: incentivize people to spread their load across the day, to reduce the need for expensive new infrastructure as the economy electrifies.)

I see some challenges, though:

How to recognise that a new 15-min period has started (or do they simply start at the quarter hour?);

It's simply "the last 15 minutes" — i.e. the last 15*60=900 seconds.

Not sure if the Eve app will like a history entry per 15 min instead of per 10 min;

We don't need to do that: I think we could simply align it to the 10 minute windows that Eve uses? That'd mean that every currentUnixTimestamp % 600 (modulo 10 minutes), we would write that value to Eve's history. Seeing for every 10 minute window which the highest value was sounds amazing!

If "in addition to" it would have to be a separate accessory.

That's fine. I propose Electricity Capacity — that seems to be in line with the current Electricity and Electricity Delivered?

1-0:1.6.0 is the highest value of 1-0:1.4.0 in the last month, incl. a time stamp of when this occurred. This could simply be exposed as two addtional characteristics, Concumption Monthly Peak and Time Monthly Peak.

👍 Sounds good!

0-0:98.1.0 is a series of highest values over past periods, incl. the start and enddate of the period. This repeating data would have to be exposed as a service per entry.

These are the consumption peaks (the 1.6.0 values) of the last 13 months — or for as many months as there is data. Using the example on the last page of the document:

0-0:98.1.0(3)(1-0:1.6.0)(1-0:1.6.0)(200501000000S)(200423192538S)(03.695*kW)(200401000000S)(200305122139S)(05.980*kW)(200301000000S)(200210035421W)(04.318*kW)

The period preceding the current period ended on 2020-05-01 00:00:00 and had its consumption peak of 3695 W on 2020-04-23 19:25:38 (Summer time).
The period preceding that period ended on 2020-04-01 00:00:00 and had its consumption peak of 5980 W on 2020-03-05 12:21:39 (Summer time).
The period preceding that period ended on 2020-03-01 00:00:00 and had its consumption peak of 4318 W on 2020-02-10 03:54:21 (Winter time).

Or in the telegram I provided, i.e. using my actual consumption:

0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)

⚠️ → this seems to provide the data not in reverse order, but in chronological order! 🙃
⚠️ → this seems to show that not the running 15 minute window is used, but 00–15, 15–30, 30–45 and 45–00!

The oldest period ended on 2023-01-01 00:00:00 and had its consumption peak of 3921 W on 2022-12-16 18:15:00 (Winter time).
The second oldest period ended on 2023-02-01 00:00:00 and had its consumption peak of 2962 W on 2023-01-31 19:15:00 (Winter time).

How would you use this info? Would you actually want to check your invoice against historical peak values in HomeKit (and need for 1-0:1.6.0 and 0-0:98.1.0 to be exposed)? Would you want to set an automation or alarm when the peak value exceeds a threshold (which would probably too late, as you've exceeded the threshold)? Would set an automation or alarm when the current value comes close to a threshold (to prevent exceeding the threshold)? Would you simply use the history to analyse your usage pattern and change your behaviour?

Yes, you would want to check your invoice against this.
This is new territory for all inhabitants. I'm not sure yet! But yes, I can imagine automations would be helpful. Everyone pays a minimum capacity tariff, which allows you to use up to 2500 W. Everything above that costs extra. Ideally you can keep it below that every month, then you pay the least. I can imagine different potential strategies: A) warn when getting close (90%?) of 2500 W ("very frugal" strategy), B) warn when getting close to your current 13-month average, because that'd cause your capacity tariff to stay at that level instead of decreasing ("steady" strategy"), C) warn when getting close to the lowest month of your last 13 months, because ("frugal" strategy)
… but these alarms are not only tricky to realize in HomeKit, they could also simply be annoying/impractical. I propose to do that at a later time. For now, while people (myself included) are still familiarizing ourselves with the actual impact, being able to analyse my usage pattern every once in a while and change my behavior accordingly would be more than enough. And the Support Normal vs Low tariff consumption? #1 valuable thing for that is likely: Eve history of the last 15 min window peak logged at whichever granularity Eve supports (i.e. 10 minutes).

Sorry for the delayed response — but obviously writing this took long! Looking forward to your thoughts! 😊

wimleers · 2023-02-10T11:27:24Z

Oh, and here is a super short summary of how to interpret and act on those values from somebody who works at Fluvius! :) https://twitter.com/RubenPeene/status/1607322694294315008

See #69.

ebaauw · 2023-02-10T14:16:37Z

I'm happy to recapture it. I copy/pasted it and manually added the trailing \rs that your other sample telegrams contained.

Please do. I want to make sure that the checksum computation still works.

1-0:1.4.0 is the high-water mark of the current consumption (in kW) per 15 minutes. This could simple be exposed as an additional characteristic Consumption Peak (cf. Total Consumption Normal and Total Consumption Low).

An additional characteristic sounds perfect! But note that 1-0:1.4.0 is not the high water mark — it's the average current consumption (in the current 15 minute window). 1-0:1.6.0 is the highest 1-0:1.4.0 value in the current month.

How to recognise that a new 15-min period has started (or do they simply start at the quarter hour?);

It's simply "the last 15 minutes" — i.e. the last 15*60=900 seconds.

Ah, so it's a running average. Makes sense. I was put off track since "your" telegrams shows the historic values on 15-minute boundaries, but the example in Twitter shows random times.

So I would propose Consumption Average Live + Consumption Peak, or Consumption Window + Consumption Window Peak. Or something along those lines 😊

It's power (W), not consumption (Wh). Unfortunately, Eve displays these as Current Consumption vs Total Consumption.

However, since the price per kWh depends on this peak consumption, it might make sense to base Eve history on this instead of/in addition to the current consumption.

No, the price per kWh is still charged based on Tariff = Normal vs Tariff = Low, which you already show 👍 This the the consumption price you pay.

The capacity tariff is an additional cost charged based on the peak capacity used, independent of how much you consume. IOW: you pay more if your usage requires a bigger pipe/thicker cables in the infrastructure!

So, it's like connection costs (aansluitkosten)?

Not sure if the Eve app will like a history entry per 15 min instead of per 10 min;

We don't need to do that: I think we could simply align it to the 10 minute windows that Eve uses? That'd mean that every currentUnixTimestamp % 600 (modulo 10 minutes), we would write that value to Eve's history. Seeing for every 10 minute window which the highest value was sounds amazing!

Indeed, we can show the running average over the last 15 minutes every 10 minutes. It won't add up to the total consumption, but it would be great for analysing your historical usage.

0-0:98.1.0 is a series of highest values over past periods, incl. the start and enddate of the period. This repeating data would have to be exposed as a service per entry.

These are the consumption peaks (the 1.6.0 values) of the last 13 months — or for as many months as there is data. Using the example on the last page of the document:

⚠️ → this seems to provide the data not in reverse order, but in chronological order! 🙃
⚠️ → this seems to show that not the running 15 minute window is used, but 00–15, 15–30, 30–45 and 45–00!

Not in the example on Twitter.

Updated the parser to handle the new keys, combining 1-0:1.6.0 and 0-0:98.1.0:

{
  "type": "/FLU5\\253770234_A",
  "version": "5.0",
  "msg_text": "",
  "electricity": {
    "id": "1SAG1105302451",
    "lastupdated": "2023-02-05T19:14:49",
    "tariff": "low",
    "consumption": {
      "low": 343.023,
      "normal": 330.621
    },
    "power": 155,
    "avg_power": 222,
    "avg_power_peaks": {
      "2022-12-16T18:15:00": 3921,
      "2023-01-31T19:15:00": 2962,
      "2023-02-01T13:45:00": 1911
    },
    "failures": {},
    "l1": {
      "voltage": 242.3,
      "current": 1.87,
      "power": 155
    }
  },
  "electricityBack": {
    "id": "1SAG1105302451B",
    "lastupdated": "2023-02-05T19:14:49",
    "tariff": "low",
    "consumption": {
      "low": 95.132,
      "normal": 240.444
    },
    "power": 0,
    "l1": {
      "power": 0
    }
  },
  "gas": {
    "id": "7F2122090451",
    "lastupdated": "2023-02-05T19:09:59",
    "consumption": 481.628
  }
}

Not sure if it makes sense to expose the peaks to HomeKit, if we already create Eve history for the average power.

- Bug fix: RangeError: The value of "value" is out of range. It must be >= -32768 and <= 32767. Received 41948 when history entry contains illegal value. Now invalid value is simply not reported to Eve and default has been changes to unsigned int16 (from signed int16). See ebaauw/homebridge-p1#70. - Add `averagePowerDelegate` parameter for Homebridge P1 support for capacity tariff in Flanders, see ebaauw/homebridge-p1#69. - Refactor consumption history (again...)

wimleers · 2023-02-12T10:41:45Z

Please do. I want to make sure that the checksum computation still works.

Here you go, several telegrams:

/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114300W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.580*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.499*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.499*kW)
1-0:32.7.0(244.6*V)
1-0:31.7.0(002.67*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!37BF
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114301W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.580*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.502*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.502*kW)
1-0:32.7.0(244.9*V)
1-0:31.7.0(002.68*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!0482
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114302W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.580*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.499*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.499*kW)
1-0:32.7.0(244.7*V)
1-0:31.7.0(002.67*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!3047
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114303W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.580*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.498*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.498*kW)
1-0:32.7.0(245.0*V)
1-0:31.7.0(002.67*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!41CD
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114304W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.581*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.496*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.496*kW)
1-0:32.7.0(244.7*V)
1-0:31.7.0(002.66*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!2239
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114305W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.581*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.497*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.497*kW)
1-0:32.7.0(244.9*V)
1-0:31.7.0(002.66*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!706E
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114306W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.581*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.501*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.501*kW)
1-0:32.7.0(244.4*V)
1-0:31.7.0(002.68*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!9B49
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114307W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.581*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.500*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.500*kW)
1-0:32.7.0(244.5*V)
1-0:31.7.0(002.68*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!4057
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114308W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.581*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.501*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.501*kW)
1-0:32.7.0(244.6*V)
1-0:31.7.0(002.67*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!6CC0
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114309W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.581*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.501*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.501*kW)
1-0:32.7.0(244.7*V)
1-0:31.7.0(002.68*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!C3BB
/FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212114310W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.581*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.497*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.497*kW)
1-0:32.7.0(244.4*V)
1-0:31.7.0(002.67*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212113959W)(00516.848*m3)
!A1E2

Ah, so it's a running average. Makes sense. I was put off track since "your" telegrams shows the historic values on 15-minute boundaries, but the example in Twitter shows random times.

I know, it's very confusing. Hence my question here: https://twitter.com/wimleers/status/1624007742942855173. You can see in the PRs of other projects too that they're seeing values like mine.

So, it's like connection costs (aansluitkosten)?

We call them "netkosten" in Flanders. See https://www.vreg.be/nl/jaarafrekening for all aspects, but especially see the "netkosten" box. There's 3 kinds: i) distribution ("distributienettarieven") ii) transmission ("transmissietarieven") and iii) transport ("transporttarieven"). The changes that went into effect on January 1, 2023 (the "capacity tariff") is explained in a video here: https://www.vreg.be/nl/nieuwe-nettarieven.

More concretely, the documented prices for 2023 tell me that in my region (Ghent → Imewo) it'll cost me:

€43.5071/kW/year capacity tariff including 6% VAT.
€40.1029/mWh/year
⇒ my current peak is 3921 W and assuming I import 2 mWh from the grid this year that'd mean €43.50713.921 + €40.10292 = €170.59 + €80.21 = €250.80 for "netkosten"

Indeed, we can show the running average over the last 15 minutes every 10 minutes. It won't add up to the total consumption, but it would be great for analysing your historical usage.

Yes — this is perhaps what I'm most excited about 😄

Not in the example on Twitter.

Updated the parser to handle the new keys, combining 1-0:1.6.0 and 0-0:98.1.0:
[…]
    "avg_power": 222,
    "avg_power_peaks": {
      "2022-12-16T18:15:00": 3921,
      "2023-01-31T19:15:00": 2962,
      "2023-02-01T13:45:00": 1911
    },

Looking good!

Not sure if it makes sense to expose the peaks to HomeKit, if we already create Eve history for the average power.

I think that at least initially, just the history is more than enough!

wimleers · 2023-02-12T10:53:53Z

git cloned e07fc82 and npm linked it.

Looking good!

[2/12/2023, 11:50:54 AM] [P1] Restarting child bridge...
[2/12/2023, 11:50:54 AM] Got SIGTERM, shutting down child bridge process...
[2/12/2023, 11:50:54 AM] [P1] Electricity Delivered History: saved 869 history entries (1 to 868)
[2/12/2023, 11:50:54 AM] [P1] Gas History: saved 869 history entries (1 to 868)
[2/12/2023, 11:50:59 AM] [P1] Child bridge process ended
[2/12/2023, 11:50:59 AM] [P1] Process Ended. Code: 143, Signal: null
[2/12/2023, 11:51:06 AM] [P1] Restarting Process...
[2/12/2023, 11:51:06 AM] [P1] Launched child bridge with PID 68983
[2/12/2023, 11:51:06 AM] Registering platform 'homebridge-p1.P1'
[2/12/2023, 11:51:06 AM] [P1] Loaded homebridge-p1 v1.3.2 child bridge successfully
[2/12/2023, 11:51:06 AM] Loaded 3 cached accessories from cachedAccessories.0E981C41ADC8.
[2/12/2023, 11:51:06 AM] [P1] homebridge-p1 v1.3.2, node v18.14.0, homebridge v1.6.0, homebridge-lib v6.3.8
[2/12/2023, 11:51:06 AM] [P1] config.json: {"serialPort":"192.168.0.219:23","name":"P1","platform":"P1"}
[2/12/2023, 11:51:06 AM] [P1] config: {"dsmr22":false,"port":8088,"timeout":5,"serialPort":"192.168.0.219:23","name":"P1","platform":"P1"}
[2/12/2023, 11:51:06 AM] [P1] Electricity: cached Electricity v1.3.2 1SAG1105302451
[2/12/2023, 11:51:06 AM] [P1] Electricity Delivered: cached Electricity v1.3.2 1SAG1105302451B
[2/12/2023, 11:51:06 AM] [P1] Gas: cached Gas v1.3.2 7F2122090451
[2/12/2023, 11:51:06 AM] Publishing bridge accessory (name: P1, publishInfo: {
  username: '0E:98:1C:41:AD:C8',
  port: 54199,
  pincode: '***-**-***',
  category: 2,
  bind: [ 'en0', [length]: 1 ],
  mdns: undefined,
  addIdentifyingMaterial: true,
  advertiser: undefined
}).
[2/12/2023, 11:51:06 AM] [P1] exec: sw_vers 
[2/12/2023, 11:51:06 AM] Homebridge v1.6.0 (HAP v0.11.0) (P1) is running on port 54199.
[2/12/2023, 11:51:06 AM] [P1] exec: system_profiler SPHardwareDataType
[2/12/2023, 11:51:06 AM] [P1] exec: ioreg -l | grep product-description
[2/12/2023, 11:51:06 AM] [P1] hardware: Mac mini (M1, 2020)
[2/12/2023, 11:51:06 AM] [P1] os: macOS Monterey 12.3.1 (21E258)
[2/12/2023, 11:51:06 AM] [P1] restored 3 accessories from cache
[2/12/2023, 11:51:07 AM] [P1] npm registry: request 1: GET /homebridge-p1/latest
[2/12/2023, 11:51:07 AM] [P1] connected to 192.168.0.219:23
[2/12/2023, 11:51:07 AM] [P1] warning: ignoring invalid telegram
[2/12/2023, 11:51:07 AM] [P1] npm registry: request 1: 200 OK
[2/12/2023, 11:51:07 AM] [P1] latest version: homebridge-p1 v1.3.2
[2/12/2023, 11:51:08 AM] [P1] telegram:
FLU5\253770234_A

0-0:96.1.4(50217)
0-0:96.1.1(3153414731313035333032343531)
0-0:1.0.0(230212115112W)
1-0:1.8.1(000345.668*kWh)
1-0:1.8.2(000356.281*kWh)
1-0:2.8.1(000252.468*kWh)
1-0:2.8.2(000096.645*kWh)
0-0:96.14.0(0002)
1-0:1.4.0(00.000*kW)
1-0:1.6.0(230208183000W)(02.604*kW)
0-0:98.1.0(2)(1-0:1.6.0)(1-0:1.6.0)(230101000000W)(221216181500W)(03.921*kW)(230201000000W)(230131191500W)(02.962*kW)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.452*kW)
1-0:21.7.0(00.000*kW)
1-0:22.7.0(00.452*kW)
1-0:32.7.0(243.9*V)
1-0:31.7.0(002.50*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313232303930343531)
0-1:24.4.0(1)
0-1:24.2.3(230212115007W)(00516.848*m3)
!80A3

[2/12/2023, 11:51:08 AM] [P1] raw data: {"type":"FLU5\\253770234_A","checksum":"80A3","version_be":"5.0","id":"1SAG1105302451","lastupdated":"2023-02-12T11:51:12","consumption_t1":345.668,"consumption_t2":356.281,"consumption_back_t1":252.468,"consumption_back_t2":96.645,"tariff":2,"avg_power":0,"avg_power_peak":{"2023-02-08T18:30:00":2604},"avg_power_peaks":{"2022-12-16T18:15:00":3921,"2023-01-31T19:15:00":2962},"power":0,"power_back":452,"l1_power":0,"l1_power_back":452,"l1_voltage":243.9,"l1_current":2.5,"breaker":"connected","max_power":999900,"max_current":999,"msg_text":"","d1_type":"gas","d1_id":"7F2122090451","d1_breaker":"connected","d1_lastupdated":"2023-02-12T11:50:07","d1_consumption":516.848}
[2/12/2023, 11:51:08 AM] [P1] data: {"type":"FLU5\\253770234_A","version":"5.0","msg_text":"","electricity":{"id":"1SAG1105302451","lastupdated":"2023-02-12T11:51:12","tariff":"low","consumption":{"low":356.281,"normal":345.668},"power":0,"avg_power":0,"avg_power_peaks":{"2022-12-16T18:15:00":3921,"2023-01-31T19:15:00":2962,"2023-02-08T18:30:00":2604},"failures":{},"l1":{"voltage":243.9,"current":2.5,"power":0}},"electricityBack":{"id":"1SAG1105302451B","lastupdated":"2023-02-12T11:51:12","tariff":"low","consumption":{"low":96.645,"normal":252.468},"power":452,"l1":{"power":452}},"gas":{"id":"7F2122090451","lastupdated":"2023-02-12T11:50:07","consumption":516.848}}
[2/12/2023, 11:51:08 AM] [P1] FLU5\253770234_A v5.0
[2/12/2023, 11:51:08 AM] [P1] Electricity: Electric Current: set to 2.5 A (from 2.51 A)
[2/12/2023, 11:51:08 AM] [P1] Electricity: Voltage: set to 243.9 V (from 244.2 V)
[2/12/2023, 11:51:08 AM] [P1] Electricity: Last Updated: set to "Sun Feb 12 2023 11:51:12" (from "Sun Feb 12 2023 11:50:57")
[2/12/2023, 11:51:08 AM] [P1] Electricity Delivered: Total Consumption: set to 349.113 kWh (from 349.111 kWh)
[2/12/2023, 11:51:08 AM] [P1] Electricity Delivered: Total Consumption Low: set to 96.645 kWh (from 96.643 kWh)
[2/12/2023, 11:51:08 AM] [P1] Electricity Delivered: Current Consumption: set to 452 W (from 457 W)
[2/12/2023, 11:51:08 AM] [P1] Electricity Delivered: Last Updated: set to "Sun Feb 12 2023 11:51:12" (from "Sun Feb 12 2023 11:50:57")

ebaauw · 2023-02-12T12:43:31Z

Here you go, several telegrams:

Mystery solved: the initial / is a separator between telegrams, and not part of the telegram, nor of the checksum calculation. It shouldn't have been included in telegrams.js.

See #69.

- Add accessory for Capacity tariff, see #69. - Simulate 1000W current consumption when using `telegram` for testing, - Add missing error reporting for `telegram` setting.

- Add accessory for Capacity tariff, see #69.

ebaauw · 2023-02-12T13:36:51Z

Could you try beta v1.3.3? It should create an additional Electricity Capacity accessory (and Water as well, when reported by the smart meter).

Note that Eve history entries for Total Consumption contain average power in 0.1 W, but Eve computes and displays the consumption in Wh instead. In the day view, you see a column per hour, so the actual average power for that hour is the consumption value; in the hour view, you see a column per 10 minutes, so you need to multiple the consumption value by 6 to get the average power for those 10 minutes.
I'm not sure how useful this will be. I think maybe it would be better to show a line, liike for Temperarure, Humidiy, and Air Pressure, rather than consumption bars. Maybe exposing the average power as Air Pressure makes the historic data more accessible, even when it's nonsense semantically.

wimleers · 2023-02-13T11:27:54Z

Just installed it. I see Electricity Capacity now 👍 Will collect data for a while and report back!

ebaauw · 2023-02-19T14:28:19Z

Published v1.3.3.

Add sample datagram.

aec1520

ebaauw merged commit 59ad29b into ebaauw:main Feb 10, 2023

wimleers mentioned this pull request Feb 10, 2023

Eve history crash: RangeError: The value of "value" is out of range. It must be >= 32768 and <32676. Received 35940 #70

Closed

ebaauw added a commit that referenced this pull request Feb 10, 2023

Support capacity tariff in Flanders

ff35d99

See #69.

ebaauw added a commit that referenced this pull request Feb 10, 2023

Add support for water consumption

41a6577

See #69.

ebaauw added a commit that referenced this pull request Feb 12, 2023

Update telegrams.js

82de90c

See #69.

ebaauw added a commit that referenced this pull request Feb 12, 2023

Update P1Platform.js

66cb7ca

- Add accessory for Capacity tariff, see #69. - Simulate 1000W current consumption when using `telegram` for testing, - Add missing error reporting for `telegram` setting.

ebaauw added a commit that referenced this pull request Feb 12, 2023

Update P1Accessory.js

f923ec1

- Add accessory for Capacity tariff, see #69.

ebaauw added a commit that referenced this pull request Feb 12, 2023

Update P1Service.js

4e68b60

- Add accessory for Capacity tariff, see #69.

wimleers mentioned this pull request Feb 23, 2023

Feature request: making the Electricity Capacity accessory more useful #72

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Belgium (Fluvius) v1.7 datagrams: capacity tariff #69

Belgium (Fluvius) v1.7 datagrams: capacity tariff #69

wimleers commented Feb 8, 2023 •

edited

Loading

ebaauw commented Feb 8, 2023

ebaauw commented Feb 10, 2023

wimleers commented Feb 10, 2023 •

edited

Loading

wimleers commented Feb 10, 2023

ebaauw commented Feb 10, 2023

wimleers commented Feb 12, 2023 •

edited

Loading

wimleers commented Feb 12, 2023 •

edited

Loading

ebaauw commented Feb 12, 2023

ebaauw commented Feb 12, 2023

wimleers commented Feb 13, 2023

ebaauw commented Feb 19, 2023

Belgium (Fluvius) v1.7 datagrams: capacity tariff #69

Belgium (Fluvius) v1.7 datagrams: capacity tariff #69

Conversation

wimleers commented Feb 8, 2023 • edited Loading

ebaauw commented Feb 8, 2023

ebaauw commented Feb 10, 2023

wimleers commented Feb 10, 2023 • edited Loading

wimleers commented Feb 10, 2023

ebaauw commented Feb 10, 2023

wimleers commented Feb 12, 2023 • edited Loading

wimleers commented Feb 12, 2023 • edited Loading

ebaauw commented Feb 12, 2023

ebaauw commented Feb 12, 2023

wimleers commented Feb 13, 2023

ebaauw commented Feb 19, 2023

wimleers commented Feb 8, 2023 •

edited

Loading

wimleers commented Feb 10, 2023 •

edited

Loading

wimleers commented Feb 12, 2023 •

edited

Loading

wimleers commented Feb 12, 2023 •

edited

Loading