Xcel Energy ITron Gen 5 Riva

RTL-SDR is what I used. It was a little flakey, but it worked from pretty far away (on the same side of the house, but through two walls).

I think the flakeyness was all in the software. What I was really looking for was electricity and not gas though. So ultimately, when it stopped working, I disconnected the SDR.

It is a solved problem, but I don’t think many people have taken the time to make it easy to use. Once someone gets it working, they stop, usually. So there is a lack of documentation and “turn key” solutions. You’re going to have to get your hands dirty and give it a go. I would suggest making a new thread though, since this one is about the electricity meter.

1 Like

For gas, I used this add on

For the meters config, I used

- id: "insert your id here without quotes"
  protocol: scm+
  name: Gas Meter
  type: gas
  multiplier: 0.01
  unit_of_measurement: CCF

Works flawlessly. But will absolutely require the right meter, and an SDR tuned to the right frequency.

Edit 2: I should note that I also use this to get my water meter. I just add my meter ID and the rest of the configuration and and it’s worked for well over a year now with little trouble.

The main source of issues people have with SDRs is crappy power on Raspberry Pis. A powered USB hub solved all of my issues.

Hi All,

Looking for assistance with the error shown below. Meter is connected to Wifi, EULA accepted. Meter setup says: “Ready to Go.”

INFO: Connected to MQTT Broker!
Traceback (most recent call last):
  File "/opt/xcel_itron2mqtt/main.py", line 88, in <module>
  File "/opt/xcel_itron2mqtt/xcelMeter.py", line 243, in run
  File "/opt/xcel_itron2mqtt/xcelEndpoint.py", line 180, in run
    reading = self.get_reading()
  File "/opt/xcel_itron2mqtt/xcelEndpoint.py", line 88, in get_reading
    self.current_response = self.parse_response(response, self.tags)
  File "/opt/xcel_itron2mqtt/xcelEndpoint.py", line 75, in parse_response
    value = root.find(f'.//{IEEE_PREFIX}{k}').text
AttributeError: 'NoneType' object has no attribute 'text'
[21:41:46] INFO: Service Xcel iTron2MQTe exited with code 1 (by signal 0)
s6-rc: info: service legacy-services: stopping

Thanks, Dallas

I’m using a TP-link Deco setup and I added an outdoor AP (wired backhaul) right next the meter. It worked pretty great for about 3 weeks in March, but hasn’t worked for almost a month again. My router doesn’t seem to see the meter, even through the energy dashboard on the Xcel site shows that my meter is connected to the WIFI. Its almost as if something in the DHCP client on the meter has gotten jammed up. I’ve tried a number of different test/diagnostic setups, including a fully standalone router broadcasting a simple SSID using only 2.4Ghz. In the logs, I see the meter attempting to connect to the wifi and exchanging the WPA keys, but the meter never makes a DHCP request. Eventually, my router de-auths the meter for inactivity (reason code 4). Ive had a ticket open with Xcel for a few weeks, but so far we’ve not had any luck. Has anyone found a way to reboot/restart the wifi stack on the meter? My working theory is that the meter’s DHCP client has died, or is unresponsive. Help/suggestions/Wild Ass Guesses welcome!

1 Like

I had pretty much given up on a reliable wifi connection for my meter, but I did notice a high level of dropped packets on the access point that it connects to. In searching I came across a few other instances of my hardware (TP-Link Omada) having issues with IOT devices and packet loss. One person mentioned that a hard reset fixed it for them, so as a last ditch I fully reset my access points and redeployed my Wifi networks. I’m over 3 weeks now without a gap in data from the meter.

I think there’s a possibility that TP-Link hardware/firmware has some issue with these devices. I had another ESP32 based device misbehaving that has been solid since the reset too.

Has anyone run into the issue where the smart meter connects, the status shows connected on Xcel’s website, but you get the same reading for an hour+?

It’s connected to WiFi, has an address, MQTT is connected, and is returning data… but the data doesn’t change values?

Well, got a hold of the xcel team that’s supposed to be in charge of the smart meter programs and they were absolutely no help unfortunately.

They said the meter needs to be on 2.4 GHz (it is). They can see the device and they’re telling me I shouldn’t have an issue. I asked them to escalate and the rep said she’d send a note to the program managers and they’d contact me if they could help. So we’ll see what happens. :-/

Side note: I also tried downloading the HEC app from Xcel. I registered that and it shows up in my Launchpad but even that doesn’t provide a reading for live usage. I keep getting error codes 10 and 12 (meter not connected, phone not connected to the same wifi network as meter) but I’m on the same network as the meter. Live usage is still blank.

I’m really out of ideas.

If it’s any consolation, I had this same problem. I was able to talk to the meter for a few months, then all of a sudden it stopped working. The meter was “connected” to the router, but with no IP address. The Xcel web page still showed the meter was connected, and the status display on the meter itself did too. I looked at the packets in wireshark and saw the wifi auth/assoc messages and the 4-way WPA handshake, but no DHCP messages. No IP address, so can’t talk to the meter. Came to the same conclusion as you did - the meter’s dhcp client was dead or inoperative. I banged my head against it for months to no avail. Unenrolled / re-enrolled the meter a few times. Tried a different router. Xcel and Itron were no help. My next step was to try banging on the meter with a hammer. Then one day about 6 months later I noticed that the itron was able to get an IP address and I was able to communicate with it again. I have no idea what happened, it doesn’t seem to be connected to anything I did. It’s been working again for a month or so. So I don’t really have any suggestions as to what to do, but sometimes it helps knowing that other people have had the same problem!

I think I’m in a similar boat to some others maybe,
about a month ago I stopped getting updates from my meter (using the xcel_itron2mqtt container)
My meter is connected to wifi with a valid IP, I can scan the ports and get 8081 as open. If I “reconnect” from my router, it does so successfully.
My meters appears to be “stuck”.
I added some logging to the container to see the responses, which there are responses, but the time period that the responses are from are always starting at 1718240042

INFO: Got endpoint response:

I have to conclude that I’m just getting stale data from the meter for some reason.

I had the issue above where my meter was communicating but the data it was providing wasn’t updating.

Try asking Xcel’s launchpad support team to reboot the agent on the meter. That was my issue. Hasn’t been a problem since. I tried to inquire further if there was something I could do to reboot this on my own but it sounds like they have to do it. Might be a known issue.

For anyone else, before asking Launchpad to do this, make sure you have the same symptoms as we are having: Your meter connects to your router, you’re getting data, the data just doesn’t refresh. This is not the same as having a meter that won’t connect to your router, doesn’t get an IP assigned, or isn’t connecting to Home Assistant.

I lost communication to my iTron meter after upgrading to 7.0 and 7.1 as well.
I poll the meter from configuration.yaml

  - sensor:
      name: "Smart Electric Meter Power"
      unique_id: xcel_meter_power
      command: "OPENSSL_CONF=/ssl/itron/openssl.conf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url --cert /ssl/itron/cert.pem --key /ssl/itron/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'"
      unit_of_measurement: "W"
      device_class: "power"
      scan_interval: 5
      command_timeout: 5
  - sensor:
      name: "Smart Electric Meter Consumption"
      unique_id: xcel_meter_consumption
      command: "OPENSSL_CONF=/ssl/itron/openssl.conf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url --cert /ssl/itron/cert.pem --key /ssl/itron/key.pem 2>&1 | grep -o   '<value>.*</value>' | grep -Eo '[0-9]+'"
      unit_of_measurement: "kWh"
      value_template: "{{ value | multiply(0.001) | round(3)}}"
      device_class: "energy"
      state_class: "total_increasing"
      scan_interval: 5
      command_timeout: 5

I’m running Hass.io on a rasberry pi 4 and Interesting enough I was able to see live data from the meter when executing the same command from terminal.

OPENSSL_CONF=/ssl/itron/openssl.conf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url --cert /ssl/itron/cert.pem --key /ssl/itron/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'

No idea why it works in terminal but not via command line in my configuration.yaml but for now I’m back at 6.4

Were you able to execute the command from a terminal window on Core 2024.7, or was it from Core 2024.6 that you got live data.

I was able to get my command to work in 2024.7.1 from the terminal.

OPENSSL_CONF=/ssl/itron/openssl.conf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url --cert /ssl/itron/cert.pem --key /ssl/itron/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'

Mine also stopped working as of the latest two updates.

All, I ran into the same thing. But running the command in the terminal seems to work. I wonder if these most recent updates did something to other command line sensors? I had gotten this working earlier, but I am not a code or linux expert… my gut says something along the lines of a permission issue? I’ll keep tinkering and if I find something that works I’ll update.

Hey all, I just figured I’d give a little update of where I’m at. Just trying to troubleshoot where the command is failing I removed the pipes and grep commands from the end of the “curl” statement and ran it. It’s now responding with an error code 35. Error code 35 for curl is:

A TLS/SSL connect error. The SSL handshake failed. The SSL handshake can fail due to numerous different reasons so the error message may offer some additional clues. Maybe the parties could not agree to a SSL/TLS version, an agreeable cipher suite or similar.

I should clarify that all commands still run fine from the terminal (I’m using the Studio Code Server add-on). I’m updating the command in the configuration.yaml file and restarting to get my error results.

May run through the detailed updates for this main revision to see if something got messed up with the openssl or something. That’s just me spitballing. My other command line sensors are still working other than the curl with an openSSL call.

Edit: I did see that HA 2024.7 DID bump cryptography to 42.0.8 which moved HA from OpenSSL version 3.2.1 to 3.2.2. Still not sure what impact that could have.


So, another topic had been spun out of the release topic for 2024.7 regarding this. Please see here for additional detail (Command Line Sensor broke in 2024.7, How do I fix?).

In summary, the 2024.7 release bumped the cryptography package for HA, which did move OpenSSL version from 3.2.1 to 3.2.2. In 3.2.2, the cipher we have been using is no longer supported

--ciphers ECDHE-ECDSA-AES128-CCM8

Can’t remember where that cipher came from (documentation or just someone’s recommendation), but I think we will have to update that to get this back online!

All, as I had hoped there are smart people out there who solved the issue. Please refer to this post Command Line Sensor broke in 2024.7, How do I fix? - #9 by Nic3Quick

Basically you need to add 1 line to the openssl.cnf file the command references to open up access to lower security class ciphers that the one we use needs. To steal from the linked thread, the openssl.cnf should now read as follows:

openssl_conf = openssl_init

ssl_conf = ssl_sect

system_default = system_default_sect

Options = UnsafeLegacyServerConnect

I made this update and things are now working again.

1 Like

That resolved my issue! Thanks for digging into that!

That fixed my issue too. Thanks!