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:
<Reading
xmlns="urn:ieee:std:2030.5:ns"
href="/upt/1/mr/1/r">
<qualityFlags>01</qualityFlags>
<timePeriod>
<duration>1</duration>
<start>1718240042</start>
</timePeriod>
<value>3605</value>
</Reading>
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
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.
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?
It’s upthread.
Did you get the email address?
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.
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!