ebaauw / homebridge-p1

Homebridge plugin for DSMR end-consumer (P1) interface
Apache License 2.0
53 stars 11 forks source link

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

Closed wimleers closed 1 year ago

wimleers commented 1 year ago

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 commented 1 year ago

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:

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 commented 1 year ago

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

wimleers commented 1 year ago

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)
  1. 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).
  2. 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).
  3. 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!

  1. 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).
  2. 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?

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

wimleers commented 1 year ago

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

ebaauw commented 1 year ago

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.

wimleers commented 1 year ago

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:

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 commented 1 year ago

git cloned https://github.com/ebaauw/homebridge-p1/commit/e07fc82b69da3b0f48562ee47d4296ec5d177397 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 commented 1 year ago

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.

ebaauw commented 1 year ago

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 commented 1 year ago

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

ebaauw commented 1 year ago

Published v1.3.3.