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 prettyeasy.
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
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.
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.
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.
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:
Add the following LFDI on your utilities website: 58F371CB4CF0FC393B459559576904D1F7E338EE
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.
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.
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:
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.
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…