Xcel Energy ITron Gen 5 Riva

It was an LFDI generated with the certificate using the sample code.

The LFDI is the certificate fingerprint left-truncated to 160-bits (20 octets)

So that’s basically just the SHA1 fingerprint of your self-signed certificate. This should be pretty easily scriptable.

I think an intended use is something like if you buy an EV charger and you want it to charge when rates are lowest, so they tell you to go to Xcel’s site and enter the LFDI off the label on the EV charger and that authorizes it to talk to your meter (don’t want random devices on your network talking to your meter). We just have to print our own labels, which in this case is pretty easy.

I have my meter on wifi, excited to help test! Randomly received an email from Xcel today –

Congratulations!
 
Your enrollment in Xcel Energy Launchpad has been confirmed and you are now able to utilize or connect your eligible in-home devices to your smart meter over your Wi-Fi network. Third party services may not be available at this time.

To manage your enrollment, visit your Billing Accounts in My Account. You will be able to manage your smart meter connection, enroll in eligible services once available, and add authorized devices.  
 
Thank you for your participation in Xcel Energy Launchpad. ```

The SDK provides a Mosquitto MQTT integration and python libraries for interacting with the devices. It appears to have docker containers and integration examples. The README kicks off as follows:

energy-launchpadsdk-cloud
A Code repository holding our public cloud SDK for xcel energy's home area network and a technical support forum for client sdk developers.

Getting started
To get started with energylaunchpad cloud, once invited to this repository you can simply download repository as a zip. Or you can just clone the whole repo.

I’ve never written a Home Assistant integration, but for you integrators out there, this doesn’t look like a monster undertaking. Famous last words I’m sure. If I get some free time I might poke at the SDK a bit and see if I can tease out something interesting, but no promises :slight_smile:

That was my take on it also.

I am in UTC they just swapped my meter out for the Gen5 Riva as well, Im guessing no one has figured out how to get the SCM data from these new meters yet?

You can get data out of it, but I haven’t tried to transform it into anything useful yet. It’s a bit finicky to setup and the meter itself has been pretty unreliable as far as reachability.

These instructions work for me on Ubuntu 22.04.

Generate a self-signed certificate:
openssl req -x509 -nodes -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365 -subj '/CN=my-integration-cert'

Grab the SHA1 fingerprint:
openssl x509 -noout -fingerprint -sha1 -inform pem -in cert.pem

Now, remove all the : from the output and that’s your LFDI. Add this LFDI to the Xcel Manage Meters and Devices page.
See updated instructions: Xcel Energy ITron Gen 5 Riva - #82 by pdubs10

After an unknown amount of time (a few days, maybe sooner?), you can use this certificate to query the API. The meter uses some wonky encryption, so you’ll need to configure OpenSSL to allow that.

openssl.cnf

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = UnsafeLegacyRenegotiation

Then:
export OPENSSL_CONF=/path/to/that/openssl.cnf

curl should work after this.

For me that looked like:
curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --verbose --url https://METER_IP_HERE:8081/upt --cert c.pem --key k.pem
and then you can browse through the hierarchy there. Each response has an href to more info.

Like I said, the meter seems to become unreachable somewhat randomly so it doesn’t inspire a ton of confidence. Ultimately I’d like to build a little python client to simplify this and then it would be pretty simple to pipe that into MQTT or the like.

When you say unreachable does it drop off the network? stop replying to queries?

Wifi shows it as connected, but when I try to connect it times out on port 8081. Comes back later just fine though. It shouldn’t be an issue, but I have 3 access points it could potentially be getting signal from. I suppose that could potentially be confusing it? If it keeps up I’ll give it its own SSID on a single access point and see if that helps.

Hi – friend and I were looking at ours and troubleshooting here in Denver. It appears as if the meter goes into powersave/sleep mode very quickly, which we’re guessing is why it often shows as disconnected on Xcel’s website.

In the documentation, it looked as if there are references to url’s that function as a ‘keep alive’ url

This is how me and my buddy made this work in Homeassistant:

The steps highlighted by pdubs10 helped a lot. But it seemed like the generated certificate was not compatible with our meters. We took a shortcut and used a cert/key provided as an example on the Xcel SDK site. We have been successfully polling our meter for the past few days, without any issues.

Here are the steps to pull data into HA:

  1. Add the following LFDI on your utilities website: 58F371CB4CF0FC393B459559576904D1F7E338EE

  2. Create cert.pem (contents below)

  3. Create key.pem (contents below)

  4. Create a CLI Sensor in HomeAssistant

    • platform: command_line
      unique_id: elecmerter
      name: “Elec meter”
      command: ‘/usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://HOST_IP:8081/upt/1/mr/3/r --cert /FILE_PATH/cert.pem --key /FILE_PATH/key.pem 2>&1 | grep -oPm1 “(?<=)[^<]+”’
      scan_interval: 91
      command_timeout: 16
  5. To test if the cert and key are able to communicate with your meter, open the HA ssh addon.
    5a) run the following command: curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure -v --url https://HOST_IP:8081/upt --cert /FILE_PATH/cert.pem --key /FILE_PATH/key.pem
    5b) < HTTP/1.1 200 OK response means it worked, you can follow the HREF chain to find data based on your meter version.

cert.pem File:
-----BEGIN CERTIFICATE-----
MIIBXjCCAQOgAwIBAgIJAK7D1P+OutH1MAoGCCqGSM49BAMCMBwxGjAYBgNVBAMM
EUhBTkFnZW50U2ltdWxhdG9yMB4XDTIyMDcyMDIzMDgzM1oXDTM0MDcyMDIzMDgz
M1owHDEaMBgGA1UEAwwRSEFOQWdlbnRTaW11bGF0b3IwWTATBgcqhkjOPQIBBggq
hkjOPQMBBwNCAARUAkP91eEmI17OmpXCnT5owCy4YaVaKQJGc9C95xDLKNNVgI3p
9NBs5z1W5BpTQrrUeywcOov0sSmdRdHUsQeAoy4wLDAOBgNVHQ8BAf8EBAMCB4Aw
GgYDVR0gAQH/BBAwDjAMBgorBQEEAYLGMwEBMAoGCCqGSM49BAMCA0kAMEYCIQCr
+o3pClk7IZj7QI+4SveL1qJJk2gA+vgyiPwuHVwEyAIhAPBLhxGn/qJUAArtNftz
+BSapy7ghQpZNIU8dW9lOKl5
-----END CERTIFICATE-----

key.pem File:
-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgW/+d+GstSyV5rgn3
8gRaZdSzd45LC59qH50u+87YMGigCgYIKoZIzj0DAQehRANCAARUAkP91eEmI17O
mpXCnT5owCy4YaVaKQJGc9C95xDLKNNVgI3p9NBs5z1W5BpTQrrUeywcOov0sSmd
RdHUsQeA
-----END PRIVATE KEY-----

2 Likes

where do the cert and key files get saved in HA? is there a specific file path/folder where they would need to be? Can they be created through the file editor in HA? Thank you for any help.

No specific path requirements, I have them saved in the /config directory and added that directory to configuration.yaml:

homeassistant:
allowlist_external_dirs:
- /config

Yes, the cert and key file can be created via File Editor in HA.

1 Like

Got this to work finally. I’m running on a Raspberry Pi, so might be some differences. The command_line sensor command wouldn’t work for me with the “grep -oPm1”, as “P” wasn’t recognized. I had to change me command to the following:

sensor:
  - platform: command_line
    unique_id: elecmerter
    name: “Xcel meter”
    command: "/usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://METER_IP:8081/upt/1/mr/3/r --cert /config/cert.pem --key /config/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'"
    scan_interval: 91
    command_timeout: 16

I’m not a smart coder man, so there may be better ways, but this got it to work. May do a bit more tinkering, but this is pulling the “value” tag.

4 Likes

Just a head’s’ up that there’s been some decent updates to SDK on GitLab:

https://gitlab.com/xcel-energy-launchpad/energy-launchpadsdk-client/-/blob/main/GettingStarted.md

A lot more information now available than I’ve seen previously, just starting to read.

…including nice documentation on Riva Gen5

https://gitlab.com/xcel-energy-launchpad/energy-launchpadsdk-client/-/blob/main/docs/Itron_SDK_Xcel_2030.5_Metering.pdf

1 Like

I used the above to pull into the Energy Dashboard, and for some reason comparing hourly consumption with the Xcel website my numbers (energy dashboard) were all double what was reported on the Xcel site.

Haven’t done the experiment yet, but wondering what the difference between “https://METER_IP:8081/upt/1/mr/3/r” and “https://METER_IP:8081/upt/1/mr/2/r” might be based on this site: https://gitlab.com/xcel-energy-launchpad/energy-launchpadsdk-client/-/blob/main/docs/meterReadingList.xml

for now I’ve modified my config file for the command line sensor to basically divide the number by 2 to get closer.

sensor:
  - platform: command_line
    unique_id: xcel_meter
    name: Xcel Meter
    command: "/usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://METER_IP_ADDRESS:8081/upt/1/mr/3/r --cert /config/cert.pem --key /config/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'"
    unit_of_measurement: "kWh"
    value_template: "{{ value | multiply(0.0005) | round(1) }}"
    scan_interval: 91
    command_timeout: 16

also… the process of getting the different tariffs working is a real pain… hopefully some of this helps.

edit… derp. just read the PDF Brendan linked. the upt/mr/2/r would show how much you have delivered to the meter…

Have you put the data into a utility meter helper and then applied the tariffs there?

Yeah. I used the utility helper. My understanding is after that I needed to create an automation which would change the “select.UtilityMeter” helper to the right tariff at the right time… then create another variable that changes the price at the same time… At this point, when the utility meter helper produces the different tariff meters, and then loading those into the energy monitor, I most likely could have gotten away with a static price for each tariff, but all the guides said I needed a variable price sensor. It certainly wasn’t very clear.

For the life of me I cannot get a curl command to return anything other than a 404 Not Found.

Connection accepted, TLS handshake negotiated, but…can’t find anything at reasonably known resource locations documented in GitLab documentation or posted in this thread…

Any advice?

bash> curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --verbose --url "https://10.0.0.232:8081/upt/0/mr?s=0&l=10" --cert cert.pem --key key.pem
*   Trying 10.0.0.232:8081...
* TCP_NODELAY set
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 10.0.0.232
 (10.0.0.232) port 8081 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ECDHE-ECDSA-AES128-CCM8
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [248 bytes data]

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [82 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [1803 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [148 bytes data]
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [12 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [7 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-CCM8
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: [NONE]
*  start date: Aug 15 19:48:31 2021 GMT
*  expire date: Dec 31 23:59:00 9999 GMT
*  issuer: C=US; O=Itron; CN=IEEE 2030.5 MICA; serialNumber=7
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
} [5 bytes data]
> GET / HTTP/1.1
> Host: 10.0.0.232:8081
> User-Agent: curl/7.68.0
> Accept: */*
> 
{ [5 bytes data]
* Mark bundle as not supporting multiuse
< **HTTP/1.1 404 Not Found**
< Date: Fri, 27 Jan 2023 20:26:42 GMT
< Content-Length: 0
< 

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

Anything at /upt? On mine the ID is not 0.

Can you try running the CURL from the Terminal & SSH addon and not bash?

And yes, try just /upt and see it gives you a HREF