diy solar

diy solar

Using RF to read ITRON utility meters

svetz

Works in theory! Practice? That's something else
Joined
Sep 20, 2019
Messages
7,199
Location
Key Largo
The power company reads your ITRON meter via packet radio protocol using the Encoder receiver transmitter (ERT) protocol developed by Itron for automatic meter reading using radio frequencies (RF) and you can too using a cheap USB dongle!

Here's a link to how to the GitHub project: https://github.com/bemasher/rtlamr

I finally had some time to try out the dongle I got from Amazon, and I had it up and running pretty quickly. Here's the dongle out of a hub next to the antenna on a tripod:

Capture.PNG

Basically there's two software packages: rtl_tcp and rtlamr which you can get precompiled. The protocol information can be found here, The two that look useful to me are IDM (time of use data) and SCM (usage information).

Here's a sample from my ITRON Centron C3A2H output using the -msgtype=all and cutting out all of my neighbors meters:

{Time:2020-02-05T14:23:21.097 IDM:{Preamble:0x555516A3 PacketTypeID:0x1C PacketLength:0x5C HammingCode:0xC6 ApplicationVersion:0x04 ERTType:0x08 ERTSerialNumber: 37023436 ConsumptionIntervalCount:83 ModuleProgrammingState:0x5F TamperCounters:00000A02B007 AsynchronousCounters:0x00 PowerOutageFlags:010000010A00 LastConsumptionCount:635437056 DifferentialConsumptionIntervals:[418 0 32 298 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] TransmitTimeOffset:1954 SerialNumberCRC:0x0B42 PacketCRC:0x0553}}
{Time:2020-02-05T14:32:51.859 SCM+:{ProtocolID:0x1E EndpointType:0x08 EndpointID: 37023436 Consumption: 266 Tamper:0x0000 PacketCRC:0x365B}}
{Time:2020-02-05T14:32:52.030 SCM+:{ProtocolID:0x1E EndpointType:0x08 EndpointID: 37023437 Consumption: 9696 Tamper:0x0000 PacketCRC:0x1475}}
{Time:2020-02-05T14:32:52.204 SCM+:{ProtocolID:0x1E EndpointType:0x08 EndpointID: 37023438 Consumption: 210 Tamper:0x0100 PacketCRC:0xDF08}}

I was a little surprised that the meter's deliver, dnn, and receive numbers consisted of 3 messages with sequential EndpointIDs based on the meters id (37023436/7/8 ).

The IDM messages are either broadcast at random intervals or more likely the radio wasn't on the correct frequency all the times. I've seen times of 3 to 10 minutes on the IDM information and for SCM+ information 2 to 6 minutes. Possible that can be be fine tuned by only listening for specific IDs or adjusting the software.
 
Last edited:
Trying to figure out the IDM fields... here's BeMasher's definitions:
  • Consumption Interval Count Interval counter indicates when a received message is reporting a different interval from the last.
  • Last Consumption Count Total power consumed.
Here's what I'm seeing, the data altered a bit to be more readable. Del is the kWh what the grid has supplied and rec is the kWh what was exported to the grid (they match the meter readings outside). I've ignored the dnn values since I don't know what they are.

...exporting power
15:32:46.832 IDM:{ConsumptionIntervalCount:97 LastConsumptionCount:635437056 DifferentialConsumptionIntervals:[426 0 32 302 288 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 0 416 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] }
15:38:04.056 SCM+:{del: 266 rec: 213
15:40:47.836 IDM:{ConsumptionIntervalCount:99 LastConsumptionCount:635437056 DifferentialConsumptionIntervals:[426 0 32 302 320 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 208 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]}
15:44:03.002 SCM+:{del: 266 rec: 213
15:49:08.558 SCM+:{del: 266 rec: 214
15:50:48.284 IDM:{ConsumptionIntervalCount:101 LastConsumptionCount:635437056 DifferentialConsumptionIntervals:[428 0 32 302 320 0 0 0 0 256 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 256 104 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]}

...importing power with some solar
17:36:09.885 SCM+:{del: 267 rec: 215
17:36:48.609 IDM:{ConsumptionIntervalCount:122 LastConsumptionCount:635437056 DifferentialConsumptionIntervals:[430 0 32 310 0 32 0 448 14 256 144 2 384 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0] }

...It's dark outside!
18:55:11.307 SCM+:{del: 270 rec: 215
18:58:44.479 IDM:{ConsumptionIntervalCount:138 LastConsumptionCount:635437056 DifferentialConsumptionIntervals:[430 0 32 510 416 120 3 464 64 1 408 30 1 308 49 192 452 13 256 206 6 240 130 1 424 60 386 204 27 448 64 1 384 29 0 288 5 256 0 0 0 0 0 0 0 0 0]}
...
19:46:28.831 SCM+:{del: 271 rec: 215
19:49:45.822 IDM:{ConsumptionIntervalCount:148 LastConsumptionCount:635437056 DifferentialConsumptionIntervals:[430 0 33 66 192 71 2 160 39 257 80 18 0 276 7 448 170 10 352 323 3 384 62 258 0 28 384 480 25 321 278 14 64 216 6 224 103 260 32 29 129 460 38 192 446 2 0]}
19:50:47.337 IDM:{ConsumptionIntervalCount:149 LastConsumptionCount:635437056 DifferentialConsumptionIntervals:[430 0 33 71 64 76 2 112 37 1 120 18 256 288 8 320 126 5 160 171 10 48 60 1 488 32 0 460 15 0 410 24 352 226 6 384 103 3 120 65 0 468 30 193 102 13 480] }

ConsumptionIntervalCount seems to match the definition okay. LastConsumptionCount isn't changing even though the meter shows kWhs consumed, so probably not BeMasher's definition. I know the IDM message is supposed to be used for TOU, so the DifferentialConsumptionIntervals might have something to do with that. 9 bits, so 0-511. Definitely the ending digits are changing as power is imported from the grid. It's a mystery!
 
Last edited:
There's a breakdown of how the fields are decoded in the patent. Doesn't look like the DifferentialConsumptionIntervals is going to give me anything more granular.
 
rtlamr author here. Looks like your meter is transmitting NetIDM which has the same preamble, length and checksum, but different internal structure. The intervals will probably make more sense if you try parsing your meter's IDM messages as NetIDM instead.
 
rtlamr author here.
Hi there! Thank you so much for the work you did on this! It was my first foray into SDR and a heck of a lot of fun! You rock!
It's been running now for almost a year to get the delivered/received meter readings and except for the occasional windows update resetting the driver it's been working pretty well.

Looks like your meter is transmitting NetIDM which has the same preamble, length and checksum, but different internal structure. The intervals will probably make more sense if you try parsing your meter's IDM messages as NetIDM instead.
Huh! I'll give that a shot! Thanks for the tip! It would be nice to see if there's anything useful in what I see as the DifferentialConsumptionIntervals.
 
Last edited:
I don't mean to hijack this thread, but I have a question about "consumption" in the SCM+ packet on my ITRON (C1SR) electric meter. I've had some difficulty picking my meter out of the dozen or so that show up using rtl_433, but am 95% certain I found mine based on RSSI level. Trouble is none of the dozen or so received meter serial numbers match any numbers printed on my meter. That includes the kWh meter reading itself, which is my actual question. What does SCM+ "consumption" represent in kWh? Do I need some sort of conversion?
 
Marv: Usually meters transmit higher precision than they display. In my case, my meter transmits two more digits than it displays.
 
Hey, thanks for the quick reply! What I thought was my meter was actually my neighbor's meter (the one with the strongest signal) about 35 feet away through a glass window in my room. My meter is only 25 feet away but has to go through 3 interior walls. And yes, the meter is transmitting the 2 least significant digits but not displaying them on the meter. So all is good as far as rtl_433 goes.

I tried to use your rtlamr but couldn't receive any data. I believe I have it set up correctly as you've documented on GitHub, but I think my meter may require different settings than yours.

My meter is an Itron C1SR (same as yours I think), but the frequency that works on rtl_433 is 915000000 with a sample rate of 1000000. I'm also using a gain setting of 40db. It looks like your default frequency is 912000000 with a different sample rate. I did add parameters to rtlamr to change the frequency and sample rate to what works for me on rtl_433 but still no output from rtlamr. I plan to do some more experimentation but wondered if you had any suggestions.

I got into these electric meters kind of by accident. I was decoding my Honeywell security sensors and noticed all the neighborhood electric meters coming in too. It looked too interesting to pass up.
 
hmm... still no output, but I'm not sure what to expect, since I haven't seen rtlamr working.

Here's my output from both rtl_tcp and rtlamr. Neither says anything further. I get something every few seconds on rtl_433.

C:\rtl_tcp
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Tuned to 100000000 Hz.
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
client accepted!
set freq 915000000
set sample rate 1048576

C:\>rtlamr -centerfreq=915000000 -symbollength=32 -tunergain=40
18:49:53.701411 decode.go:45: CenterFreq: 915000000
18:49:53.704043 decode.go:46: SampleRate: 1048576
18:49:53.704043 decode.go:47: DataRate: 32768
18:49:53.704043 decode.go:48: ChipLength: 32
18:49:53.705041 decode.go:49: PreambleSymbols: 21
18:49:53.705041 decode.go:50: PreambleLength: 1344
18:49:53.707040 decode.go:51: PacketSymbols: 96
18:49:53.708040 decode.go:52: PacketLength: 6144
18:49:53.708040 decode.go:59: Protocols: scm
18:49:53.709041 decode.go:60: Preambles: 111110010101001100000
18:49:53.710038 main.go:119: GainCount: 29

And here's an example of what I get using rtl_433.

Found Rafael Micro R820T tuner
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Sample rate set to 1000000 S/s.
Tuner gain set to Auto.
Tuned to 915.000MHz.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2021-02-07 18:29:22
model : IDM PacketTypeID: 0x1C PacketLength: 92 ApplicationVersion: 4 ERTType : 0x17 ERTSerialNumber: 69341084
ConsumptionIntervalCount: 190 ModuleProgrammingState: 0xBC TamperCounters: 0x020100230900 AsynchronousCounters: 0x00
PowerOutageFlags: 0x000000000000 LastConsumptionCount: 2087207 DifferentialConsumptionIntervals: 4, 4, 5, 3, 2, 3, 4, 4, 3, 4, 18, 16, 18, 26, 26, 13, 5, 4, 5, 3, 3, 5, 4, 5, 6, 5, 5, 5, 3, 4, 3, 5, 4, 5, 4, 3, 4, 5, 4, 4, 8, 3, 4, 3, 3, 8, 9
TransmitTimeOffset: 1775 MeterIdCRC: 0x0B63 PacketCRC : 0x87D4 Meter_Type: Electric Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2021-02-07 18:29:22
model : NETIDM PacketTypeID: 0x1C PacketLength: 92 ApplicationVersion: 4 ERTType : 0x17 ERTSerialNumber: 69341084
ConsumptionIntervalCount: 190 ModuleProgrammingState: 0xBC TamperCounters: 0x020100230900 Unknown_field_1: 0x00000000000000
LastGenerationCount: 31 Unknown_field_2: 0xD92702 LastConsumptionCount: 16818224 DifferentialConsumptionIntervals: 1027, 128, 4102, 258, 4160, 2310, 8400, 3330, 8256, 2563, 96, 5128, 320, 12308, 641, 4120, 1025, 8272, 2053, 128, 3080, 320, 8208, 1024, 12320, 769, 8320
TransmitTimeOffset: 1775 MeterIdCRC: 0x0B63 PacketCRC : 0x87D4 MeterType : Electric Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2021-02-07 18:29:22
model : SCM+ id : 69341084
Protocol_ID: 0x1E Endpoint_Type: 0x07 Endpoint_ID: 69341084 Consumption: 2087208 Tamper : 0x0201 crc : 0xCD0B
Meter_Type: Electric Integrity : CRC
 
Marv: rtlamr only decodes scm when -msgtype is not specified, try with -msgtype=scm+,idm
 
Success! rtlamr -centerfreq=915000000 -symbollength=32 -tunergain=40 -msgtype=scm+,idm

{Time:2021-02-07T19:55:33.717 IDM:{Preamble:0x555516A3 PacketTypeID:0x1C PacketLength:0x5C HammingCode:0xC6 ApplicationVersion:0x04 ERTType:0x07 ERTSerialNumber: 69355852 ConsumptionIntervalCount:72 ModuleProgrammingState:0xBC TamperCounters:020000220800 AsynchronousCounters:0x00 PowerOutageFlags:000000000000 LastConsumptionCount:3083651 DifferentialConsumptionIntervals:[7 4 4 6 11 12 13 10 4 5 6 5 6 12 8 5 4 4 6 5 4 4 3 3 4 4 5 3 4 4 3 4 4 4 4 5 4 4 6 8 7 11 2 4 3 4 3] TransmitTimeOffset:3025 SerialNumberCRC:0x6774 PacketCRC:0xFB91}}
{Time:2021-02-07T19:55:33.964 SCM+:{ProtocolID:0x1E EndpointType:0x07 EndpointID: 69355852 Consumption: 3083651 Tamper:0x0200 PacketCRC:0xC92E}}

Consumption 3083651 is apparently 30836.51 kWh with 30836 displayed on the meter LCD itself.

Many thanks!
 
If you're interested in some python to decode the data and put it in influxdb, here are the main functions I use. I have another script that puts the messages in a RabbitMQ message queue and this one reads the messages and processes them:
Python:
def round_down_time_to_nearest_x_minute(tm, minute=1):
    result = tm - datetime.timedelta(minutes=tm.minute % minute,
                                     seconds=tm.second,
                                     microseconds=tm.microsecond)
    return result

def process_message(line):
    if len(line) < 5:
        return
    data=json.loads(line)
    msg_type = data["Type"]
    #print("msg_type:" + str(msg_type))
    if msg_type.upper() == 'SCM':
        message = [{"measurement":"consumption", "time": data['Time'], "tags": {"meter": data['Message']['ID'], "meter_type":data['Message']['Type'] }, "fields": {"value": data['Message']['Consumption']}}]
        #print("message:" + str(message))
        influx_client.write_points(message)
    elif msg_type.upper() == 'IDM':
            #print("IDM:" + str(line))
            meter = data['Message']['ERTSerialNumber']
            meter_type = data['Message']['ERTType']
            last_consumption = data['Message']['LastConsumptionCount']
            diff_consumption_data = data['Message']['DifferentialConsumptionIntervals']
            reading_time = data['Time']
            reading_datetime = dateutil.parser.parse(reading_time)
            for i, value in enumerate(diff_consumption_data):
                consumption_time = reading_datetime - datetime.timedelta(minutes=5*i)
                adjusted_time = round_down_time_to_nearest_x_minute(consumption_time, 5)
                message = [{"measurement":"diff_consumption_full", "time": adjusted_time, "tags": {"meter": meter, "meter_type":meter_type }, "fields": {"value": value}}]
                influx_client.write_points(message)

The spacing isn't quite right but I can send you the files if you want.
 
Yes, I would like to try your python program. The timing of your post is perfect. I've written a python script to take a csv output from rtlamr, do some consumption calculations, and send a json over to influx. It's "sort of" working but my python script is clunky, to say the least. My goal is to graph the change in the consumption readings between transmissions with Grafana. That's also "sort of" working. I was planning on spending this weekend working on my code.
 
Here's my current code for retrieving data from my rtlamr csv file and sending it to influx. Then Grafana retrieves it from influx and displays it. I'm still experimenting with the best kind of graph to display it. A line graph is misleading because it suggests consumption between data points.

import datetime from influxdb import InfluxDBClient import time ifuser = "user" ifpass = "password" ifdb = "database" ifhost = "localhost" ifport = 8086 measurement_name = "meter2" new_reading = 0 old_reading = 0 reading2 = 0 reading = 0 meter_data = open('meter.csv', 'r') while True: line = meter_data.readline() # print(line) if not line: # check for EOF time.sleep(60) # print("waiting on next transmission") else: # meter.csv has a new transmission data = line.split(',') date_time = data[0] reading = data[7] new_reading = int(reading) diff = new_reading - old_reading if diff > 10000: # discard initial non-diff consumption reading diff = 0 old_reading = new_reading watt_hours = diff * 10 # convert to watthours # print(str(date_time) + " " + str(watt_hours)) if watt_hours != 0: body = [ { "measurement": measurement_name, "fields": { "datetime": date_time, "consumption": watt_hours } } ] # connect to influx ifclient = InfluxDBClient(ifhost,ifport,ifuser,ifpass,ifdb) # write the measurement ifclient.write_points(body)
 

Attachments

  • usage_wh.PNG
    usage_wh.PNG
    270.4 KB · Views: 5
Last edited:
I cleaned this up a bit - I've since migrated to the rabbitMQ message queuing system so it's a bit mashed up but this is what I used for a long time. It does require rtl_tcp running as well in a separate process but I think you've already got that part figured out (based on your c:\rtl_tcp command). You'll have to adjust your rtlamr_location since you're on windows.

Python:
#!/usr/bin/env python3
import os
import sys
import json
import subprocess
import time
from influxdb import InfluxDBClient

rtlamr_location = '/usr/bin/rtlamr'

RTL_TCP_SERVER    = os.getenv('RTL_TCP_SERVER',"127.0.0.1:1234")
RTLAMR_MSGTYPE    = os.getenv('RTLAMR_MSGTYPE',"all")
RTLAMR_FILTERID   = os.getenv('RTLAMR_FILTERID',"")
RTLAMR_UNIQUE     = os.getenv('RTLAMR_UNIQUE',"true")
METERMON_SEND_RAW = os.getenv('METERMON_SEND_RAW',"False")
METERMON_SEND_BY_ID = os.getenv('METERMON_SEND_BY_ID', "False")



# Delay. Useful for now while I try and figure out systemd targets. I've had
# issues where if both powermon and rtlamr start immediately at boot, no data is
# reported. The delay solves the problem but I don't like it.
time.sleep(2)

prev_diff_consumption = []

influx_client = InfluxDBClient(<params>)

# for development
#TL_TCP_SERVER = "sdr-vm2:1234"
if RTL_TCP_SERVER != "":
    proc = subprocess.Popen([rtlamr_location, '-server='+RTL_TCP_SERVER, '-format=json', '-msgtype=all'],stdout=subprocess.PIPE)
    # I added the gain setting here after seeing it in your post
else:
    proc = subprocess.Popen([rtlamr_location, '-format=json', '-msgtype=all'],stdout=subprocess.PIPE)

meter_diff_consumption_dict = {}

while True:
    line = proc.stdout.readline()
    #print("data: " + str(line))
    if not line:
        break # no need to wait 60 seconds here

    tic = time.perf_counter()
    data=json.loads(line)
    msg_type = data["Type"]
    #print("msg_type:" + str(msg_type))
    if msg_type.upper() == 'SCM':
        message = [{"measurement":"consumption", "time": data['Time'], "tags": {"meter": data['Message']['ID'] }, "fields": {"value": data['Message']['Consumption']}}]
        #print("message:" + str(message))
        influx_client.write_points(message)
        toc = time.perf_counter()
        print(f"SCM message processed in {toc - tic:0.4f} seconds")
    elif msg_type.upper() == 'IDM':
        #print("IDM:" + str(line))
        meter = data['Message']['ERTSerialNumber']
        meter_type = data['Message']['ERTType']
        last_consumption = data['Message']['LastConsumptionCount']
        diff_consumption_data = data['Message']['DifferentialConsumptionIntervals']
        most_recent_consumption = diff_consumption_data[0]
        
        # the other algorithm I posted previously using enumerate is better than what I removed here.
 
Even though I've had rtlamr running full-time for a couple of weeks, I haven't been able to get rtlamr-collect working. I run into a problem with the download and build process "go get github.com/bemasher/rtlamr-collect". Here's what I get back:

pi@raspberrypi:~/go $ go get github.com/bemasher/rtlamr-collect
# github.com/influxdata/influxdb-client-go/api/http
src/github.com/influxdata/influxdb-client-go/api/http/service.go:100:14: undefined: "net/http".NewRequestWithContext
pi@raspberrypi:~/go $


When I installed rtlamr earlier with a similar process "go get github.com/bemasher/rtlamr" I didn't have any problem. So, of course, the only thing I have in go/bin is my rtlamr.

Any idea what that error message means? Has something maybe changed in influxdb causing the rtlamr-collect build process to fail?
 
Data logging stopped working today... another Windows update and it's no longer reading the SDR. <sigh>

Found the instructions, ran zadiag, but AirSpy isn't working so I know the logger won't work.
Downloaded the latest version and installed it, didn't work, rebooted, reseated it... excellent... AirSpy started working. But not rtlamr... so banged on it, swore, reset, and finally something did something. That is it started working. Whew!

Possibly time to try @bemasher 's suggestion of using netidm? First, recap what I've been doing....

Previously I'd been running: rtlamr.exe -filterid="xxx736,xxx738" -msgtype=scm+ -single=true -format=json
On the itron I'd get two different records (Note the different endpointIDs) representing the power exported (deliver) and imported (receive):
deliver:

JSON:
{
    "Time": "2021-03-13T12:55:57.84838-05:00",
    "Offset": 0,
    "Length": 0,
    "Message": {
        "FrameSync": 5795,
        "ProtocolID": 30,
        "EndpointType": 8,
        "EndpointID": xxx736,
        "Consumption": 12836,
        "Tamper": 1,
        "PacketCRC": 3208
    }
}
receive:

JSON:
{
    "Time": "2021-03-13T12:57:01.8458933-05:00",
    "Offset": 0,
    "Length": 0,
    "Message": {
        "FrameSync": 5795,
        "ProtocolID": 30,
        "EndpointType": 8,
        "EndpointID": xxx738,
        "Consumption": 7209,
        "Tamper": 258,
        "PacketCRC": 47228
    }
}

The Consumption is the important field needed for the logging as it shows the imported and exported power. Those are the values that appear on the meter display. ✅

Trying it with the suggestion of netidm the meter returned some interesting data, most obvious of which a new field "LastConsumptionCount" which shows consumption in wh. So that's pretty cool!

Unfortunately, the meter is a lot slower at reporting these records. It never returned with the xxx738 record even though in my test the xxx736 rolled by a few times, so couldn't get the exported values. Downloaded, built, and tested the latest version just in case, but no joy.

Possibly the ITRONs are just funky, there is a field LastGeneration which is different than LastConsumption for my neighbors... but check out my values (JSON truncated):
JSON:
{
    "Message": {
        "ERTType": 8,
        "LastGeneration": 12132,
        "LastConsumptionCount": 12836092,
    }
}
The meter shows 7209, not 12132. So, that's probably why I picked SCM back then, without it I can't get my exported power readings.
 
Last edited:
Back
Top