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.
- 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.
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>
meter.run()
File "/opt/xcel_itron2mqtt/xcelMeter.py", line 243, in run
obj.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
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!
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.
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.
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
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’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.
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.
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!
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: