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.