Xcel Energy ITron Gen 5 Riva

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

command_line:
  - 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 https://192.168.7.3:8081/upt/1/mr/1/r --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 https://192.168.7.3:8081/upt/1/mr/3/r --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 https://192.168.7.3:8081/upt/1/mr/1/r --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 https://192.168.7.3:8081/upt/1/mr/1/r --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.


Edit:

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

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = UnsafeLegacyServerConnect
CipherString = DEFAULT@SECLEVEL=0

I made this update and things are now working again.

2 Likes

That resolved my issue! Thanks for digging into that!

That fixed my issue too. Thanks!

This fixed worked for my install also. Thanks for sharring

I sent an email to the launchpad team and they had me rebooted and running pretty quickly. No additional info on a cause.
I’m using zaknye’s container from xcel_itron2mqtt which had polling set to 5 seconds. In the energy launchpad github issues trackers there was mention that either Xcel or Itron’s design goal was for instantaneous usage at 1 second and all other data at 5 seconds. Zaknye’s agent pulled everything at 5 seconds, so that should have been good. But just because I don’t really care about that many data points I slowed the polling rate down to every 10 seconds. I got up and running again yesterday, so we’ll see how this goes.

Do you have the launchpad email handy?

1 Like

It’s upthread.

Did you get the email address?

It appears to be [email protected]

Sunday afternoon I sent an email to [email protected].

I stated my service address and account number and asked them to restart the meter.

By 8:00 am Monday they had restarted the meter and it now works nicely.

1 Like

I didn’t realize this until I found some brilliant Redditor’s post, but if you have an iPhone you can download the Xcel “My Energy Connection” app and update the Wifi from within the app.

The redditor mentioned there are a lot of false negatives, which I can confirm. I updated the Wifi in the app and while it said connection unsuccessful, my Eero immediately sent a push notification that an iTron device was online!

OP: https://www.reddit.com/r/homeassistant/comments/1b45nxj/energy_my_simple_energy_dashboard_xcelenvoy_solar/

I’ve been reading this topic for a few months, I have to throw this out there. I have an ITron Gen 5 Riva… but not Xcel has anyone found a way to get the data without an API? I just have HA on a Le potato with a RTL-SDR dongle. I have rtlamr2mqtt turned on… I get this…

[2024-09-16 14:09:48] 14:09:48.927543 decode.go:60: Preambles: 00000000000000001110010101100100,111110010101001100000,0001011010100011,01010101010101010001011010100011
[2024-09-16 14:09:48] 14:09:48.927781 main.go:124: GainCount: 29
[2024-09-16 14:47:35] 14:47:35.211647 main.go:343: Receiver context cancelled.
[2024-09-16 14:47:35] 14:47:35.213084 main.go:320: read tcp 127.0.0.1:60664->127.0.0.1:1234: i/o timeout
[2024-09-16 14:47:35] io.ReadFull
[2024-09-16 14:47:35] main.(*Receiver).Run.func2
[2024-09-16 14:47:35] 	/go/pkg/mod/github.com/bemasher/[email protected]/main.go:181
[2024-09-16 14:47:35] runtime.goexit
[2024-09-16 14:47:35] 	/usr/local/go/src/runtime/asm_arm64.s:1223
[2024-09-16 18:49:38] Shutdown detected, killing process.
Traceback (most recent call last):
  File "/usr/bin/rtlamr2mqtt.py", line 415, in <module>
    listen_mode()
  File "/usr/bin/rtlamr2mqtt.py", line 392, in listen_mode
    for amrline in rtlamr.stdout:
  File "/usr/local/lib/python3.10/codecs.py", line 319, in decode
    def decode(self, input, final=False):
  File "/usr/bin/rtlamr2mqtt.py", line 152, in shutdown
    if not external_rtl_tcp and rtltcp.returncode is None:
NameError: name 'external_rtl_tcp' is not defined
[2024-09-17 18:07:34] Using "/data/options.json" config file
[2024-09-17 18:07:34] Fetching default MQTT configuration from http://supervisor/services/mqtt
[2024-09-17 18:07:34] Starting in LISTEN ONLY Mode...
[2024-09-17 18:07:34] Using "/data/options.json" config file
[2024-09-17 18:07:34] Fetching default MQTT configuration from http://supervisor/services/mqtt
[2024-09-17 18:07:34] Configured MQTT sender:
[2024-09-17 18:07:34]  > hostname => core-mosquitto
[2024-09-17 18:07:34]  > port => 1883
[2024-09-17 18:07:34]  > username => addons
[2024-09-17 18:07:34]  > client_id => rtlamr2mqtt
[2024-09-17 18:07:34]  > base_topic => rtlamr
[2024-09-17 18:07:34]  > availability_topic => rtlamr/status
[2024-09-17 18:07:34]  > tls => None
[2024-09-17 18:07:34] Starting rtl_tcp with /usr/bin/rtl_tcp 
[2024-09-17 18:07:36] Starting rtlamr with ['/usr/bin/rtlamr', '-msgtype=all', '-format=json']
[2024-09-17 18:07:36] You should see all utility meters after this line:
[2024-09-17 18:07:36] 18:07:36.576466 decode.go:45: CenterFreq: 912380000
[2024-09-17 18:07:36] 18:07:36.578884 decode.go:46: SampleRate: 2359296
[2024-09-17 18:07:36] 18:07:36.578954 decode.go:47: DataRate: 32768
[2024-09-17 18:07:36] 18:07:36.578972 decode.go:48: ChipLength: 72
[2024-09-17 18:07:36] 18:07:36.578986 decode.go:49: PreambleSymbols: 32
[2024-09-17 18:07:36] 18:07:36.579001 decode.go:50: PreambleLength: 4608
[2024-09-17 18:07:36] 18:07:36.579017 decode.go:51: PacketSymbols: 736
[2024-09-17 18:07:36] 18:07:36.579032 decode.go:52: PacketLength: 105984
[2024-09-17 18:07:36] 18:07:36.579061 decode.go:59: Protocols: scm,scm+,idm,r900
[2024-09-17 18:07:36] 18:07:36.579081 decode.go:60: Preambles: 111110010101001100000,0001011010100011,01010101010101010001011010100011,00000000000000001110010101100100
[2024-09-17 18:07:36] 18:07:36.579213 main.go:124: GainCount: 29
[2024-09-17 18:42:06] 18:42:06.426947 main.go:343: Receiver context cancelled.
[2024-09-17 18:42:06] 18:42:06.429430 main.go:320: read tcp 127.0.0.1:44328->127.0.0.1:1234: i/o timeout
[2024-09-17 18:42:06] io.ReadFull
[2024-09-17 18:42:06] main.(*Receiver).Run.func2
[2024-09-17 18:42:06] 	/go/pkg/mod/github.com/bemasher/[email protected]/main.go:181
[2024-09-17 18:42:06] runtime.goexit
[2024-09-17 18:42:06] 	/usr/local/go/src/runtime/asm_arm64.s:1223
[2024-09-17 19:15:19] Shutdown detected, killing process.
Traceback (most recent call last):
  File "/usr/bin/rtlamr2mqtt.py", line 415, in <module>
    listen_mode()
  File "/usr/bin/rtlamr2mqtt.py", line 392, in listen_mode
    for amrline in rtlamr.stdout:
  File "/usr/local/lib/python3.10/codecs.py", line 319, in decode
    def decode(self, input, final=False):
  File "/usr/bin/rtlamr2mqtt.py", line 152, in shutdown
    if not external_rtl_tcp and rtltcp.returncode is None:
NameError: name 'external_rtl_tcp' is not defined
[2024-09-17 19:15:25] Using "/data/options.json" config file
[2024-09-17 19:15:25] Fetching default MQTT configuration from http://supervisor/services/mqtt
[2024-09-17 19:15:25] RTLAMR2MQTT Starting...
[2024-09-17 19:15:26] RTL SDR Device 0bda:2838 found on USB port 001:008 - Index: 0
[2024-09-17 19:15:26] No USB device specified in the config file, using the first found.
[2024-09-17 19:15:26] Configured MQTT sender:
[2024-09-17 19:15:26]  > hostname => core-mosquitto
[2024-09-17 19:15:26]  > port => 1883
[2024-09-17 19:15:26]  > username => addons
[2024-09-17 19:15:26]  > client_id => rtlamr2mqtt
[2024-09-17 19:15:26]  > base_topic => rtlamr
[2024-09-17 19:15:26]  > availability_topic => rtlamr/status
[2024-09-17 19:15:26]  > tls => None
[2024-09-17 19:15:26] Resetting USB device: /dev/bus/usb/001/008
[2024-09-17 19:15:26] Reset sucessful.
[2024-09-17 19:15:26] Sending message to MQTT:
[2024-09-17 19:15:26]  > topic => rtlamr/status
[2024-09-17 19:15:26]  > payload => online
[2024-09-17 19:15:26]  > retain => True
[2024-09-17 19:15:27] Unknown exception connecting to MQTT broker: [Errno -5] No address associated with hostname
[2024-09-17 19:15:27] Trying to start RTL_TCP: /usr/bin/rtl_tcp  -s 2048000
[2024-09-17 19:15:27] RTL_TCP started with PID 10
[2024-09-17 19:15:32] RTL_TCP is ready to receive connections!
[2024-09-17 19:15:32] Trying to start RTLAMR: /usr/bin/rtlamr -msgtype=scm -format=json -filterid=131078691 -unique=true
[2024-09-17 19:15:32] RTLAMR started with PID 15
[2024-09-17 19:15:32] 19:15:32.851893 decode.go:45: CenterFreq: 912600155
[2024-09-17 19:15:32] 19:15:32.852899 decode.go:46: SampleRate: 2359296
[2024-09-17 19:15:32] 19:15:32.853386 decode.go:47: DataRate: 32768
[2024-09-17 19:15:32] 19:15:32.853886 decode.go:48: ChipLength: 72
[2024-09-17 19:15:32] 19:15:32.854515 decode.go:49: PreambleSymbols: 21
[2024-09-17 19:15:32] 19:15:32.855060 decode.go:50: PreambleLength: 3024
[2024-09-17 19:15:32] 19:15:32.856532 decode.go:51: PacketSymbols: 96
[2024-09-17 19:15:32] 19:15:32.857272 decode.go:52: PacketLength: 13824
[2024-09-17 19:15:32] 19:15:32.858040 decode.go:59: Protocols: scm
[2024-09-17 19:15:32] 19:15:32.858787 decode.go:60: Preambles: 111110010101001100000
[2024-09-17 19:15:32] 19:15:32.858979 main.go:124: GainCount: 29

(post deleted by author)

Doesn’t really tell you much on that. Just states your settings for your RTL dongle, the RTL2AMR add-on, and that it crashed. I don’t see any meters there.

That said, I don’t believe the iTrons broadcast on 433 or 915 MHz. Some might! But I haven’t seen it. I highly doubt it’s on the 433 MHz band but it’s worth checking. The utility meters I’ve seen use 915 MHz and use one of SCM, SCM+, or r900 protocols.

Let’s assume it does broadcast, you’d first need to figure out which frequency it’s using. You’ll want to set the frequency to 433 and see if any meters pop up (read the documentation for RTL2AMR, I know it’s in there). Then 915 MHz and see if there’s anything there. Again, read the docs to find out how to search for meters. You’ll database will get hammered if you’re logging everything, so you should really find the meters for your house and configure just those.