Also in the Denver area with solar. Got my meter to finally connect to Wi-Fi last night and got the MQTT to HA integration setup. I only see one meter in Launchpad and on my network and based on the readings it appears to be the main Xcel meter. I sent a message to Xcel as well asking how to connect the PV meter so I can figure out how much is coming from my PV vs how much less energy we are actually using.
My Envoy is connected to my network via Ethernet and directly addressable. They have a developer site that you can enroll in using their free tier - https://developer.enphase.com/
Their documentation is good, API is easy to query and the .json-formatted replies can give you a lot of data.
I’m seeing the same thing with my meter dropping off for several hours at a time then suddenly deciding to work again. When it connects, it shows good to excellent connection so it’s not a signal issue. Tried locking it to a specific AP to keep it from wondering to other further APs in my house but it still seems to freak out and forget how to connect for hours at a time. This causes the MQTT container to stop so I get a bunch of gaps in the data.
Have you figured out your connection issue? Are you using the Xcel API to ping the meter in an automation in HA instead of the MQTT container? When it’s working I see updates from the meter in HA every 5 seconds so I was wondering if the meter is not happy with the higher update frequency which is causing it to drop.
I think the meter is supposed to support even once a second, at least Itron was suggesting that at one point: New Itron OpenWay Riva ‘Smart’ Meters Combine RF Mesh, PLC and Wi-Fi Communications and Poll Data Once per Second. | Smart Grid Awareness
Do you have automatic channel selection on? I’ve had issues with some devices where they drop off when the channel moves. Pinning the channel seems to help with them.
While I have the smart meter, I haven’t tried setting up the MQTT API component yet.
That’s right, I poll the meter using 3 command line entities triggered by an automation. I only poll the meter for the 3 values I want every 3 minutes, so I’m pretty sure that I’m not overloading the meter agent. I’m on day 5 of stable readings after the meter had a 3 day seizure.
Nothing is resolved as far as I know, but I did contribute to the raised issue on the old Gitlab project page. A member of the iTron SDK team responded, “Itron is investigating this issue with the port dropping. We are collecting logs and other diagnostic information from other users. I will add your issue to our troubleshooting, and if we need additional information I will reach out” but that was 2 months ago and nothing since. The project has since been moved to Github, so I don’t expect anything further from that raised issue.
My wifi is using the least populated channel in my immediate vicinity and does not switch automatically. I can look at the wifi status page and see that the meter has been connected continuously since the last router reboot 20 days ago. Whatever the issue, it is not wifi flakiness in my case.
1 Like
I have left the MQTT docker off for a few weeks but still seeing my meter drop off the wifi for several hours. I locked it to the closest AP and don’t have channel switching enabled so it should have a solid consistent connection. My AP shows it has Excellent connection all the time then it just disappears so it seems to be an issue with the meters.
Would you mind sharing your automation recipes or the endpoints you are using? I would prefer having HA poll the meter periodically over having a separate docker container because the intermittent connection causes the docker to shutdown because it can’t find the meter.
I am trying to decode the API endpoints listed above and poke around on my meter in Postman but I am not quite understanding how the authentication works. I am more familiar with OAuth and API key methods.
The automation I use is simple: Trigger is “time pattern” with “/3” in the minutes entry so that it triggers every 3 minutes of every hour. Action is “Call Service: Update Entity” for my command line sensors. You can see my command line sensors above in Post 195. Note the long scan time (one year in seconds) so that it only updates when the automation calls it.
My meter has now completely stopped responding to polling. Everything shows correctly as it should: wifi shows connected on Xcel Energy Launchpad, constant strong connection to my router, using the same commands as were successful before. Now I get “no route to host” no matter what. It’s been a week since my last successful poll of the meter. Pretty sure it’s not coming back.
no route to host means that your routers and switches can’t locate where the IP should resolve to.
Is it possible the DHCP lease is expiring and the meter isn’t renewing it?
It’s a good thought, but I have my router’s DHCP set to assign all my devices an infinite static lease (I am running DD-WRT on my router) based on MAC address. The lease did not and will not expire.
Yesterday morning, I decided to try doing yet another manual query of the smart meter from my linux-based database server. Lo and behold, I got a response back where I had been getting “no route to host” for the previous 10 days! Nothing, and I mean nothing, changed on my end. It has to be a buggy meter agent. I’ve complained to Xcel several times and always been told they will forward it to “the team” for further response. I have never received a response back in any form. I know they think it’s something that I am doing wrong, but the only variable I can identify is the wonky meter agent.
Could that be an issue? What if the meter doesn’t support leases without expiry? I run with static leases, but they have normal 24hr expiry. Never-expire leases aren’t usually recommended, so I could see that potentially causing issues if they have some custom network stack.
My DHCP leases are set at the default 24hr period and I am seeing the same issue where the meter just drops off my network for hours at a time. I have tested the signal at my meter and it is very solid. I also have wireless cameras on the same side of the house as the meter and they have no issue streaming live video so I know the signal is decent.
Seems like a bug on the meter side but since there’s only a few of us tech heads that are actually fiddling with these meters, I get the sense Itron and Xcel do not feel super motivated to address this issue any time soon. My hope is that they have some kind of internal energy dashboard product they are working on that would allow you to see live stats if your not tech savvy enough to ping the meter. This would motivate them to get this worked out since many more customers would be impacted by this issue.
After updating my Home Assistant OS today to 10.5, my setup stopped working. The following command has a failed to connect error when running it in SSH:
OPENSSL_CONF=/config/xcelenergy_meter/openssl.conf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://10.0.0.2:8081/upt/1/mr/3/r --cert /config/xcelenergy_meter/certs/.cert.pem --key /config/xcelenergy_meter/certs/.key.pem 2>&1
curl: (7) Failed to connect to 10.0.0.2 port 8081 after 3058 ms: Couldn't connect to server
Anyone have any ideas on how to fix this?
if you have the USB wifi, you can set it up using the following link
https://support.enphase.com/s/article/Reconnecting-your-Envoy-ManualWifi
Then once you are on the network Home Assistant 2023.9. or later should see it or manual config and you can access using your cloud creds.
Just set this up now still waiting to see what values come in to the system as it has all the devices
Woah, I don’t remember all those endpoints existing in the original docs, or even probing the meter for the list of available URLs and going through them one by one.
I may have to experiment with these to see if they will respond on my meter. Luckily, the way I set up the endpoints just means there will be some YAML additions for URL and type settings for home assistant and we’re good to go.
I appreciate this insight. My networking knowledge is self-taught and I admit that I am not aware of best practices. None of my other equipment ever seemed to be negatively affected by the infinite leases. I changed my DHCP settings to 24 hour leases and while the issue is not solved, both times the meter has dropped off since the change have been for shorter intervals. I’ll take any improvement, so thanks again.
Regarding the meter endpoints, those users in Denver should keep in mind that our iTron meters all have Version 1 of the Metering Agent, which only has 3 endpoints as discussed above. Version 2 has 7 and Version 3 has 22 endpoints. Both presumably have fewer bugs and better stability but that is not what Xcel deployed here.
Alright, I feel like I’m taking crazy pills.
Ignore the problem, turns out I mistyped the friggin IP address…
- I’ve set up my meter, it’s hooked up to my network and I can ping it.
- I have my
cert.pem,key.pem, andopenssl.confin/config/xcel/ - I can run the following two curl commands and get the related values from both my HomeAssistant Blue and my desktop terminals.
OPENSSL_CONF=/config/xcel/openssl.conf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://172.16.5.11:8081/upt/1/mr/1/r --cert /config/xcel/cert.pem --key /config/xcel/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'
OPENSSL_CONF=/config/xcel/openssl.conf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://172.16.5.11:8081/upt/1/mr/3/r --cert /config/xcel/cert.pem --key /config/xcel/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'
- My
command_line.yamllooks like this:
- sensor:
unique_id: xcel_meter
name: Xcel Meter
command: "OPENSSL_CONF=/config/xcel/openssl.conf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://172.16.5.11:8081/upt/1/mr/3/r --cert /config/xcel/cert.pem --key /config/xcel/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'"
unit_of_measurement: "kWh"
value_template: "{{ float(value) | multiply(0.001) | round(3) if is_number(value) }}"
device_class: 'energy'
state_class: 'total_increasing'
scan_interval: 5
command_timeout: 5
- sensor:
unique_id: xcel_meter_load
name: Xcel Meter Load
command: "OPENSSL_CONF=/config/xcel/openssl.conf /usr/bin/curl --ciphers ECDHE-ECDSA-AES128-CCM8 --insecure --url https://172.16.5.11:8081/upt/1/mr/1/r --cert /config/xcel/cert.pem --key /config/xcel/key.pem 2>&1 | grep -o '<value>.*</value>' | grep -Eo '[0-9]+'"
value_template: "{{ float(value) if is_number(value_json) }}"
unit_of_measurement: "W"
device_class: 'power'
scan_interval: 5
command_timeout: 5
- I have
command_line: !include command_line.yamlin myconfiguration.yaml The two sensors continue to have an Unknown status
Anybody have thoughts/suggestions?
1 Like
This is the best way to do it. Dont worry about any external docker containers just use the build in capabilities of HA.
I’ve been trying to figure this out and going through the thread.
Ultimately I found this writeup, which worked perfectly right after I completed the instructions:
3 Likes
I found this thread in 2021, forgot about until using my afternoon to try to get RTL433 going again, read this all and then found your post. I guess we will see when XCel lets my meter in.